routing.rs reports synced: false for every non-wallet-scoped read, so an absence can never be warranted

[MichaelTaylor3d]

Task

routing.rs returns synced: false for every non-wallet-scoped read. So coin_record can never warrant an absence, and a consumer that correctly refuses to treat an unwarranted absence as fact is stuck reporting unknown forever.

Why this surfaced

dig-app just fixed the opposite defect (#2919): it was treating "the chain source returned nothing" as "it does not exist", which made a surface assert a falsehood about the chain — a user told their DID does not exist when the truth was the node could not see it.

The fix introduced AbsenceWarrant { Warranted, Withheld }, so an absence is only believed when the source can vouch for it. Correct, and it now runs into this.

The consequence today: a genuinely-failed mint reports as unknown rather than rejected. That is the safe direction and the fix is not wrong — but it means the honest answer is unreachable, not merely rare. A user whose mint really did fail is told the node cannot see, forever.

Scope

Disclose a real sync state on non-wallet-scoped reads so a warranted absence becomes possible.

The design question to settle first: what does "synced" mean for a read that is not wallet-scoped? A wallet-scoped read has a clear notion of caught-up; a general coin read may need a different, honestly-narrower claim — for example "this source is at height H and H is within N of the peak it corroborates". Answer that before wiring a boolean, because a synced: true that overstates is worse than the current false: it converts a conservative unknown into a confident falsehood.

Fail toward false. If the node cannot establish that it is caught up, it must keep saying so — the current behaviour is over-conservative, not unsafe, and that ordering must survive the fix.

Related

• dig-app chain/source.rs — AbsenceWarrant / AbsenceWitness, the consumer side.
• dig-app account/chain_mint.rs — the gated conclusion.
• The corroboration work in chia-query 0.12.0 is adjacent: it grades a positive answer across peers. This is the absence half at the node boundary.

Evidence

A test that fails without the fix: a node that is genuinely caught up warrants an absence for a coin that does not exist, and a node that is not caught up still withholds it.

[MichaelTaylor3d]

Verification sweep verdict: NOT SATISFIED — leaving open (2026-09-01)

Verified against code on origin/main (aa9ec72), not against this ticket's own comments.
Line numbers in the body are stale; every symbol below was re-located by name.

The defect is unchanged and still structural.

crates/dig-wallet/src/sage/routing.rs:49 route(db_synced, scoped_to_wallet) sends every
non-wallet-scoped read to Source::Fallback regardless of sync state —
routing.rs:57: (_, false) => Source::Fallback.

And the Source::Fallback arm hard-codes the sync claim to false, with a comment stating exactly
why: crates/dig-wallet/src/sage/rpc.rs:1531 — synced: false, / peak_height: None, under
"The DB neither produced this figure nor bounds its freshness, so its flag and its peak say nothing
about it." The same literal synced: false repeats on the other fallback-served reads at
rpc.rs:1678, 1784, 1813, 1917, 1958, 2042, 2096.

So the composition holds: not wallet-scoped → Fallback → synced: false, always. A consumer
that refuses to treat an unwarranted absence as fact stays at unknown forever, which is the
situation this ticket describes.

What DOES exist, so the next reader starts ahead — and it is more than the body records.

The wallet-scoped arm no longer trusts the latched sync flag either. rpc.rs:1486 reports
synced: self.replica_answer_is_current(peak_height).await rather than db.is_synced(), and
replica_answer_is_current (rpc.rs:1089) is a real freshness comparison against the replica's
peak. Its doc comment records the incident behind it (rpc.rs:1032-1057): a synced: true resting
on initial_sync_complete told a client a stale balance was settled.

That is the shape the fix wants, one axis over. This ticket asks the same question for a read
that is not wallet-scoped, and replica_answer_is_current is the existing precedent for answering
it honestly — a height-versus-peak claim rather than a latched boolean. The design question the body
poses ("what does synced mean for a read that is not wallet-scoped?") now has a sibling
implementation to model on, not a blank page.

Still missing:

1. Any honestly-narrower sync claim on the fallback tier — synced there is a literal, not a
   measurement.
2. Any absence-warrant concept at the node boundary. A repo-wide grep for
   AbsenceWarrant / warranted finds only dig-node-core/src/download.rs's
   absence_established / MissOutcome::Inconclusive — that is absence of content over peers,
   a different subject from absence of a coin on chain. It is, however, a good local model for
   the answered-empty vs could-not-consult split this needs.
3. The acceptance test. Nothing asserts that a caught-up node warrants an absence and a
   not-caught-up node withholds it.

routing.rs has not been touched since 0ea5d25 (#189, the tier-disclosure change) — so nothing
has moved here since this ticket was filed.

The fail-toward-false ordering in the body still binds, and note that the current literal is
not merely conservative — it is unconditional, which is why the honest answer is unreachable
rather than rare.

[MichaelTaylor3d]

Addendum — a live draft PR is rewriting the exact functions this ticket needs (single-writer warning)

Found while scanning open PRs after posting the verdict above, so it is not in it.

DIG-Network/dig-node PR #492 (loop/490-stale-siblings, DRAFT, Closes #490) — "the coins
reads say when their answer is not current" — is teaching control.wallet.coins, .coinsByParent,
.coinById and .arrivals the staleness contract #454 gave control.wallet.balance. Its file
list includes crates/dig-wallet/src/sage/rpc.rs, which is where every synced: false literal
cited above lives.

Two consequences for whoever takes this ticket:

1. Do not open a lane on sage/rpc.rs while fix(wallet): the coins reads say when their answer is not current (#490) #492 is in flight — that is a single-writer
   collision on the same file.
2. fix(wallet): distinguish unknown from zero across the wallet surface #454's staleness contract is the second precedent I should have cited, alongside
   replica_answer_is_current. Between them the repo now has an established way to say "here is
   the figure and here is what bounds its freshness" — which is exactly the honestly-narrower claim
   this ticket's Scope section asks someone to design. The design question may be substantially
   answered by the time fix(wallet): the coins reads say when their answer is not current (#490) #492 lands; re-read that PR before treating it as open.

This does not change the verdict — #492 discloses staleness on wallet-scoped coins reads,
whereas this ticket is about a non-wallet-scoped read being able to warrant an absence at all.
Different axis, adjacent machinery.

[MichaelTaylor3d]

Lane open — the shape is settled, and it is NOT a change to synced (2026-09-02)

Branch loop/290-fallback-sync-honesty, off origin/main @ 476055fb. Recording the design
before the implementation lands, because the conclusion inverts this ticket's own title.

synced: false on a fallback answer is CORRECT. It is a category error, not a lie.

The field is documented as "the replica produced this answer AND the replica is following the
chain right now" (rpc.rs, WalletBalanceResult::synced). On a Source::Fallback answer the
first clause is definitionally false, so false is the honest value under the field's own
contract. Flipping it would be the overstating this ticket's own Scope section warns against —
"a synced: true that overstates is worse than the current false" — and it would collide
head-on with #495 / PR #500, which is narrowing that same claim in the opposite direction.

What was never computed is peak_height. Its contract already covers the fallback tier —
WalletCoinsResult::peak_height reads "the chain peak height THIS answer reflects, when known" —
and the seven fallback arms simply hardcode None. WalletCoinByIdResult::peak_height's doc
saying "None on a Source::Fallback one" records the implementation gap, not a requirement.
Same class of hardcoded pessimism the title names, one field over.

Why that field is the warrant carrier, per this repo's own SPEC

SPEC.md's control.wallet.coinById row already says:

A consumer MUST NOT present coin: null as a statement about the CHAIN while stale_by is
null [...] The definite reading — no such coin exists on chain — is reserved for an answer
whose tier can bound its own height.

And stale_by(answer_height, network_peak) (control.rs:1669) returns None unless BOTH are
known. So with peak_height hardcoded None, a SPEC-obeying consumer can never take a definite
reading from a non-wallet-scoped read. That composition is the defect, stated in the repo's own
normative voice.

The fix

A fallback arm that ACTUALLY CONSULTED the chain tier reports the height the node's own held Chia
peers announce, taken concurrently — ChainPeerTier::peak_height, already reachable via the
existing private chain_peer_tier() and already read on every Db-tier answer by
replica_answer_is_current. It is cached peer-announcement state, so no extra egress on a
rate-limited open read.

This is not the latched-replica failure stale_by exists to catch. initial_sync_complete latches
and can sit thousands of blocks behind (#416 measured 8,380); a full node's current view cannot.

The seven arms split two ways, and the split is the substance of the change:

method	class	peak_height
balance_for_address fallback arm	live consult	measured bound
coins_for_address fallback arm	live consult	measured bound
coin_by_id — cached hit	cached	stays None
coin_by_id — live miss	live consult	measured bound
coin_spend — cached hit	cached	stays None
coin_spend — live consult	live consult	measured bound
coins_by_parent	live consult	measured bound

The two cached arms keep None deliberately. A cached record was taken at an earlier, unrecorded
moment — permanent by design for spent coins (dig_ecosystem#3044/#3050) — so stamping the current
peer peak on one would claim it is level with the network when nothing measured that. That is this
same defect mirrored, and over-applying the fix would introduce it.

Fail-toward-withheld survives, structurally rather than by assertion

ChainPeerTier::peak_height is None until a held peer says something. A node with no peer
measurement therefore keeps reporting peak_height: null, stale_by: null, and the absence stays
unwarranted. There is no arm in which the node claims a bound it did not take.

No wire-contract change

peak_height is already Option<u32> on all five reads, published by
dig-node-control-interface 0.30 and put there for exactly this purpose by #490 / PR #492
(merged adf03d81), which added network_peak_height and stale_by. Going from always-null to
sometimes-a-number is additive per §5.1. No contract release, no consumer cascade.

Boundary against #495 / PR #500

Different field, different producer, opposite direction. #500 rewrites
control.wallet.syncStatus's phase (SyncPhase::Synced, FollowingEvidence,
replica_answer_is_current's internals) to stop a synced: true that OVERSTATES on the
wallet-scoped path. This ticket computes a peak_height that was never measured on the
non-wallet-scoped path. These are two changes, not one. The only overlap is textual — both edit
crates/dig-wallet/src/sage/rpc.rs, in different regions (#500 around replica_answer_is_current
and the Db arms; this one in the Fallback arms). Whichever merges second merges main and re-reads
its versions from disk. This branch does not adopt #500's types and is not built on its head.

Acceptance

The regression test asserts the WARRANT is reachable, not that a literal changed — a test asserting
synced == false, or peak_height == None on a fallback arm, passes under the defect. It uses the
existing chain_peer_tier_override seam: a node whose peer tier announces a peak warrants an
absence for a coin that does not exist; the same node on ChainPeerTier::UNOBSERVABLE still
withholds it; and a cached hit withholds it regardless.

Also updated in the same unit of work: the five SPEC.md method rows that currently state a
"fallback" answer reports peak_height: null.

[MichaelTaylor3d]

Correction to the comment above — synced IS the field, and the narrower fix would have landed on nobody

Posting against myself within the hour, because the shape I locked above was checked against the
producer and not against the consumer.

What I asserted, and why it was half right

I argued synced: false on a fallback answer is correct under the field's own contract, so the fix
was to compute peak_height and let stale_by carry the warrant. The contract reading holds. The
routing conclusion did not: I never measured which field the consumer reads.

The measurement

dig-app, crates/dig-app-core/src/chain/source.rs, ControlChainSource::absence_warrant:

match self.last_freshness() {
    Some(freshness) if freshness.synced => AbsenceWarrant::Warranted,
    Some(freshness) => AbsenceWarrant::Withheld { .. },
    None            => AbsenceWarrant::Withheld { .. },
}

believe_absence(method, synced, source) gates on the same bool, and dig-app's Freshness carries
{source, synced, peak_height} — it does not read stale_by or network_peak_height at all.

So populating peak_height alone leaves every consumer-side warrant exactly as withheld as before.
The ticket's stated consequence — "a genuinely-failed mint reports as unknown rather than
rejected" — would have survived a merged, green, correct-looking PR. That is the fix-that-lands-on-
nobody shape, and it is only visible from the consumer's side.

dig-app already wrote down what it needs

Its own rustdoc names the producer-side cause and the exact remedy:

The cause is producer-side, in dig-node's crates/dig-wallet/src/sage/routing.rs:
route(_, scoped_to_wallet = false) => Source::Fallback [...]

| control.wallet.coinById | no | false, always |
| control.wallet.coinsByParent| no | false, always |

and records that guarding coin_record on those numbers "does not narrow anything; it closes
profile creation permanently." This ticket's title was right and my refinement of it was wrong.

Corrected shape

On the five LIVE-consult arms, both fields derive from one measurement:

chain_peer_tier().peak_height	synced	peak_height
Some(h)	true	Some(h)
None	false	None

The two cached arms are unchanged — false / None — because nothing recorded when that row was
taken, and stamping the current peak on a cached answer would be this same defect mirrored.

One Option<u32>, both fields derived from it, so {synced: true, peak_height: null} has no
constructor on these arms rather than merely no fixture. That is the same invariant PR #500 is
establishing for the sync phase, which makes the two changes structurally aligned rather than
opposed: #500 stops the wallet-scoped phase OVERSTATING; this stops the non-wallet-scoped reads
UNDERSTATING; both enforce that a currency claim never travels without the height that bounds it.

Why this is not the overstating the Scope section warns against

The evidence is a concurrent measurement of the CHAIN, not of the replica: a full node answered just
now, and this node's own held peers independently name the tip at the same moment. It is not the
latched-initial_sync_complete failure — that flag can sit thousands of blocks behind (#416 measured
8,380); a full node's current view cannot.

Fail-toward-false survives structurally. ChainPeerTier::peak_height is None until a held
peer says something, so a node that cannot establish a chain view keeps reporting false / null
and the absence stays withheld. No arm claims a bound it did not take.

The residual risk is stated rather than talked down: the coinset oracle could serve a materially
stale answer while this node's own peers sit at the tip, and Source::Fallback does not say which
sub-tier answered a given read. Weighed against the harm it replaces — a warrant no read can ever
carry, which this repo's own SPEC calls out as turning "every consumer-side freshness guard into an
unconditional refusal" — the direction is right, and it will be gated up accordingly (reviewer +
security + adversarial refutation), because these are money reads feeding mint verdicts.

Follow-on, to be filed against dig-app once this lands

dig-app's believe_absence deliberately omits the guard on coin_record and
coin_records_by_parent because the warrant was not obtainable. Once it is, that reasoning
expires and those two reads should acquire the guard — otherwise dig-app keeps believing
unwarranted absences on exactly the path #2919 was about. Its rustdoc measurements against dig-node
0.118.1 also go stale on this merge. Filed as a cross-linked child in dig-app's own queue, not here.

[MichaelTaylor3d]

Lane progress — dig-node#290

• Branch loop/290-fallback-sync-honesty, head 04db3c8b (more commits landing).
• DONE: helper WalletBackend::chain_tier_answer_height() in crates/dig-wallet/src/sage/rpc.rs; five live-consult Source::Fallback arms now derive synced + peak_height from that ONE Option<u32>; the two cache-served arms unchanged and commented as to why; SPEC.md §18.7b + the balance/coinById/coinSpend rows rewritten; versions root 0.254.0, dig-wallet 0.49.0.
• RED, against unmodified production code: test result: FAILED. 139 passed; 2 failed; 0 ignored; 0 measured; 633 filtered out — both failures left: (false, None) / right: (true, Some(9140652)).
• SCOPE CORRECTION taken mid-lane: synced is in scope after all, because dig-app's ControlChainSource::absence_warrant gates on synced and reads neither stale_by nor network_peak_height.
• NEXT ACTION: read /tmp/green290b.txt for the full-suite result, then clippy + cargo check -p dig-node-service, then open the DRAFT PR.

[MichaelTaylor3d]

Lane COMPLETE — DRAFT PR #510, head 6a4c753c, branch loop/290-fallback-sync-honesty. Handed back to the gate; NOT merged, NOT undrafted.

• RED (unmodified production code): 139 passed; 2 failed; 0 ignored; 0 measured; 633 filtered out, both left: (false, None) / right: (true, Some(9140652)).
• GREEN (whole crate): 773 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out.
• cargo clippy -p dig-wallet --all-targets -- -D warnings 0; cargo fmt -p dig-wallet --check 0; cargo check -p dig-node-service 0.
• Five live-consult fallback arms bounded from ONE chain_tier_answer_height() measurement; the two cache-served arms unchanged. SPEC.md §18.7b + three method rows rewritten. Versions root 0.254.0, dig-wallet 0.49.0.

[MichaelTaylor3d]

Resume-ready progress — implementation landed, gate round in flight (2026-09-02)

Branch loop/290-fallback-sync-honesty · head 6a4c753cab39b1b0ea2fc47715aa9f89fd2ad51f
PR #510 — DRAFT, closingIssuesReferences: [290] verified parsed.
Versions read from disk after the fact: root 0.254.0, dig-wallet 0.49.0.

DONE

Five live-consult fallback arms in crates/dig-wallet/src/sage/rpc.rs now derive BOTH fields from
one measurement — chain_tier_answer_height() -> Option<u32> at rpc.rs:1086:

let bound = self.chain_tier_answer_height().await;
... synced: bound.is_some(), peak_height: bound

so {synced: true, peak_height: null} has no constructor on these arms — the two fields are the
same value read twice, not two independent decisions. The two CACHE-served arms
(coin_by_id's cached_coin_record_by_id hit, coin_spend's both-halves-cached hit) keep
false/None, because nothing recorded when those rows were taken.

All seven sites were re-verified against the code rather than taken from the plan.

RED, against unmodified production code — 139 passed; 2 failed; 633 filtered out, both failing
left: (false, None) / right: (true, Some(9140652)). GREEN, whole crate — 773 passed; 0 failed; 0 filtered out. Clippy -D warnings clean, fmt --check clean, cargo check -p dig-node-service
clean. Counts quoted rather than exit statuses: a cargo filter matching nothing exits 0.

SPEC.md's five method rows rewritten. Three dig-wallet tests moved, each with its reasoning,
none deleted. control.rs needed no test changes — its fixtures build the structs directly.

Wire contract confirmed, not assumed: dig-node-control-interface 0.30.0 src/results.rs
554/704/835/913/985 already declare peak_height: Option<u32>. Additive per §5.1, no release.

IN PROGRESS

Gated UP to the full triple, three fresh contexts, because this RELAXES a conservative claim on
money reads that feed mint verdicts: loop-reviewer (correctness), loop-security (the bound's
forgeability), and an adversarial loop-decider prompted to REFUTE. A cheap watcher is on CI —
check-merge-preconditions.sh returned EXIT=2 (UNREADABLE, TLS handshake timeout) on the first
read, which is neither green nor blocked and was not treated as a verdict.

The refutation brief explicitly asks the decider to argue the opposite case: that permanent
synced: false was correct, that dig-app keying its warrant on synced rather than stale_by is
itself the defect, and that this PR therefore entrenches a consumer error in the wrong repo. If that
lands, the fix moves to dig-app and this PR should not merge.

NEXT ACTION

Collect the three verdicts. On PASS from all three plus green CI, hand back to the orchestrator —
this lane does not merge and does not undraft. On CHANGES-REQUIRED, dispatch a scoped fix and
re-gate only the leg the fix touches.

Also filed on merge, not before

dig-app's believe_absence deliberately omits its guard on coin_record and
coin_records_by_parent because the warrant was unobtainable. Once it is obtainable that
reasoning expires, and its rustdoc measurements against dig-node 0.118.1 go stale. Cross-linked
child to be filed in dig-app's own queue once the shipped behaviour is fixed, so the ticket cites
real code rather than a design that could still move.

[MichaelTaylor3d]

Adversarial gate REFUTED the fix — and I confirmed its central fact independently

Full verdict on the PR: #510 (comment)

Not merging. My design premise on this ticket was false, and the crate had already written down
why.

Verified by direct read, not taken on the gate's word

chia-query 0.20.0 src/peer/pool.rs:

170:  /// The pool's shared `peak_height` is a `fetch_max` across every session
232:      peak_height: Arc<AtomicU32>,
421:  pub fn peak_height(&self) -> u32 { self.peak_height.load(Ordering::Relaxed) }
884:  last_peak.fetch_max(new_peak.height, Ordering::Relaxed);
885:  let prev = peak.fetch_max(new_peak.height, Ordering::Relaxed);

Monotone, untimestamped, cleared only when the whole client drops. A high-water mark, not a
reading.

And the decisive one — dig-wallet/src/sage/chain.rs:138-142, the #351 liveness gate, which gates
peer_count on freshness and deliberately passes the peak through raw:

peer_count: fresh.then_some(count),
// The peak is reported exactly as the peers gave it. It was already honest on the
// fleet -- it froze when they died -- and it is documented as "what the peers announced"
// rather than as a claim about now.
peak_height: raw.peak_height,

The crate documents this field as explicitly NOT a claim about now. PR #510 makes it exactly
that, and its own doc asserts the opposite (rpc.rs:1055: "it is not a latch, it is a read").
Consequence, reachable with no adversary and already measured on the #3159 fleet: peers die,
peer_count honestly goes None, the peak stays frozen forever, and every fallback read reports
synced: true, stale_by: 0 from two frozen copies of one number — on a node holding zero peers.

The sharpest finding, which I had missed

replica_answer_is_current (rpc.rs:1153) already reads this same field — to accuse the replica
of being behind, where a stale-high peak fails toward synced: false. Safe. My change reuses the
identical measurement inverted, to certify an answer current, where the same staleness fails
toward synced: true. Unsafe. That polarity flip is the whole defect, and it also settles the
#500 separability question against me: #500 rewrites the one existing consumer of this field, so the
two PRs are the two polarities of one measurement and only the safe one had been checked.

The fix, when the remaining gates return

1. Gate the bound on peer LIVENESS at the money-read call site — a peak may warrant only while
   peer_count is Some, i.e. inside PEER_LIVENESS_WINDOW. Narrow by design: it leaves
   ChainPeerTier::peak_height untouched for replica_answer_is_current and control.rs's
   network_peak, and it follows this file's own established pattern of putting the narrowing at
   the money read rather than in the shared predicate.
2. Reconcile the eighth site — chain_peak() (rpc.rs:2183) is a live chain consult still
   hardcoding synced: false. My brief enumerated Source::Fallback struct constructions rather
   than live consults, so it was missed. Left as-is, one node would answer synced: true on
   coin_by_id and false on control.wallet.peak at the same moment.
3. Correct the born-false claims in rpc.rs's new doc and in the five SPEC.md rows. State the
   bound for what it is: a high-water mark of peer announcements, usable only while the peer tier is
   live.
4. File separately, do not chase here: fetch_max is an unquorumed maximum across untrusted
   peers — one NewPeakWallet pins it permanently — which sits upstream in chia-query and is in
   tension with NC-12's agreement-across-peers requirement. It affects replica_answer_is_current
   too, where it currently fails safe.

Holding the fix until the correctness and security gates return, so every finding lands in one pass.
Dispatching a fixer into a worktree two gates are still reading would break single-writer and void
their reads.

[MichaelTaylor3d]

Correctness gate: CHANGES-REQUIRED — and it found the scope error the refutation missed

Second of three gates. It reached blocking defect #1 independently — same latch, same
fetch_max, same #351 evidence — which is the corroboration that matters, since two fresh contexts
converging on one root cause is stronger than either alone. It then found three more.

The one that changes this family's SHAPE — verified by direct read

I claimed "no contract release needed" because peak_height is already Option<u32> on the wire.
I checked the field's TYPE and not the field's CONTRACT. From the published crate,
dig-node-control-interface-0.30.0/src/results.rs:

875:  /// A `fallback` answer MUST report [`synced`](Self::synced) `false` and
      /// [`peak_height`](Self::peak_height) `null` however caught-up the node's own replica is,
      /// because the oracle produced the figures and the replica neither produced them nor
      /// bounds their freshness.

832:  /// Whether THESE coins reflect a caught-up local view; always `false` for a fallback answer.
834:  /// The peak height these coins reflect, or `null` when none applies (every fallback answer).

That is a normative MUST in the published contract, and this PR violates it. So this is not an
additive change inside an existing shape — it is a contract amendment, and §4.1 release-first
applies: dig-node-control-interface must publish the amended contract FIRST, then dig-node bumps to
it. This is a two-repo family, not a one-repo fix. My original scoping was wrong, and this is the
second time on this ticket that checking the producer without checking what depends on it produced a
wrong shape.

Also blocking

• rpc.rs:333,337,373,375,397,399,441,452 — eight public field doc-comments still say "always
  false" / "Always None" for a fallback answer. The SPEC was swept; the crate rustdoc was not.
  Exactly the born-false-claim class, in eight places.

Medium

SPEC.md's control.wallet.peak row rationale is now false and contradicts §18.7b — the
implementer flagged this and left it, and I let that stand; the gate says it is not survivable as-is.
Three further tests (rpc.rs:6052, 7000, 7408) assert the superseded rule on live arms, and
coins_for_address (rpc.rs:1751) has no positive test of the new bound at all.

Where the two gates disagreed, resolved

The refutation called chain_peak() (rpc.rs:2183) a missed eighth site; the reviewer confirmed the
seven-arm classification with no eighth. Both are right about different questions. I read it:
chain_peak is a live chain consult that hardcodes synced: false, but it constructs a ChainPeak,
not a Source::Fallback result — so it is not an eighth construction site, and its synced carries a
genuinely different meaning ("the node's own replica is caught up", which the fallback height cannot
establish). It may legitimately differ. What is NOT acceptable is differing silently: the fix must
either reconcile it or state in SPEC why the two endpoints answer differently about the same node at
the same moment.

Confirmed sound by the reviewer, so the fix round should not re-litigate

Seven-arm live/cached classification · the pairing invariant by construction · the new tests genuinely
at the decision · the three modified tests preserving their subjects (the rewritten one is stronger)
· control.rs unaffected · the consumer reach into absence_warrant · version bumps.

Honest limit on this verdict

The reviewer ran no build and no test suite — every test judgement is from reading fixtures. Worth
knowing before treating "the new tests are at the decision" as measured rather than read.

Status

Two of three gates in, both blocking. Security still running. Fix round is held until it returns so
all findings land in one pass and no writer enters a worktree a gate is still reading.

[MichaelTaylor3d]

Security gate: CHANGES-REQUIRED. All three gates blocking. My premise has now been falsified three times.

Verdict: #510 (comment)

The finding that ends this design — and I verified it myself

This crate already ruled against exactly the anchor I chose. crates/dig-wallet/src/sage/sync.rs:299-301:

"Anchoring on the supervisor's chia_peer_peak_height would import the vulnerability being
fixed: it is a monotone MAX over unverified claims, and quorum::eligible anchors on the MEDIAN
precisely because a max is one-frame-pinnable."

And it built the alternative: PeakCeiling (sync.rs:309), a quorum-median anchor, fixed for a
session's life and re-corroborated on rotation, with WriteAuthority::Corroborated(PeakCeiling)
unconstructible without one.

So the design in PR #510 is not merely under-gated — it is a rival implementation of a question
this crate answered properly, in the opposite direction, in a paragraph written to reject it. That
is a §2.0 already-shipped failure and a centralize-rivals failure at once, and it was findable by
reading a file two directories from the one I was editing.

The escalation that makes it GATING rather than pre-existing: a forged absence was already reachable,
but it carried synced: false and was therefore inert. This PR would have made it actionable.

And the justification collapses on its own terms — also verified

Three of the five arms I called "live consults" are oracle-only by construction.
chain.rs:717-728, 765-769: coin_records_by_puzzle_hashes (→ balance, coins) and
coin_records_by_parent (→ coinsByParent) call CoinsetFallback directly with no peer branch at
all. Only coin_record_by_id and coin_spend carry if let Some(peers) = &self.peer_reads.

So on three of five arms the peer peak describes a party that did not answer the read. My whole
justification — "a full node answered just now and my own peers name the tip at the same moment" —
is simply untrue there. stale_by also collapses to x - x = Some(0) structurally, since
control.rs takes network_peak from the same value, so the wire would report "level with the
network" computed from one number minus itself.

Cleared, with the bound named — so the fix round does not re-litigate these

Zero outbound rounds per read (existing_client() is a lock-and-clone; the tier read is a registry
read plus an AtomicU32 load) · rate-limiter ordering untouched, the call sits strictly inside the
bounded region · both cached arms return early with false/None · §908 clean, no key or signing
token in the diff · the synced: bound.is_some(), peak_height: bound pairing is the right shape and
should survive whatever replaces the anchor · tests not vacuous (PEERS_PEAK = REPLICA_PEAK + 12
stops a wrong-measurement implementation passing by coincidence).

Where this leaves the ticket

Three premises of mine, each falsified by measurement rather than by argument:

1. "the peer peak is a concurrent measurement" — it is a monotone, never-expiring fetch_max;
2. "no contract change is needed" — dig-node-control-interface 0.30.0 results.rs:875 carries a
   normative MUST that a fallback answer report synced: false / peak_height: null;
3. "these arms are served by peers" — three of five never touch a peer.

I am not guessing a fourth time. The shape is going to a fresh loop-decider with all three verdicts
and the confirmed facts, to settle whether an honest warrant is obtainable here at all — and if so
whether it rests on PeakCeiling, on a per-answer bound from the answering party, or only on the two
peer-served arms (coinById, coinSpend) which happen to be the ones this ticket's mint-watch case
actually needs. dig-app keying its warrant on synced while this repo's SPEC reserves the definite
reading for stale_by is on the table as the real defect.

PR #510 stays DRAFT and unmerged. Its test scaffolding and pairing invariant are salvageable; its
anchor is not.