The node's replica is ~8,380 blocks behind its own peers, and a stale-replica zero balance is indistinguishable from an empty wallet

[MichaelTaylor3d]

Found by: the #377 proof lane, measuring the operator wallet
Related: https://github.com/DIG-Network/dig_ecosystem/issues/3166

The node's replica is ~2 days behind, and its balance reads look identical to a healthy node's

Measured 2026-08-30 on this machine's installed node:

node's own replica height	9,211,798
its own peers' reported height	9,220,177
gap	~8,380 blocks — about two days

dign wallet balance --asset dig --json answers:

{ "balance": 0, "synced": false, "source": "fallback", "peak_height": null }

Why this is worth its own ticket rather than a note

A funded wallet would produce that same output. The zero is not evidence of an empty wallet — it
is evidence of a node that cannot see. The only fields that distinguish the two are synced: false
and source: "fallback", and neither is surfaced anywhere a person looks.

The proof lane only established the wallet was genuinely empty by asking coinset.org directly,
with a control: the same query shape against the DIG treasury puzzle hash returns 357 records, so
a zero from that source is a reading rather than a broken instrument. Without that independent check
the measurement would have been unfalsifiable.

The consequence for the mirror-coin work

A node this far behind cannot observe its own create confirm. §25.4 requires confirmation by
observing the CREATED coin (never the funding coin — that is legacy bug 5, where a competing spend
satisfies the wait identically). A replica two days stale will not see a coin minted a minute ago, so
the pass would record Pending and stay there.

That makes this a step-8 dependency for #412, not just
background hygiene: the real-machine proof requires watching a coin appear, and this node currently
cannot.

Scope

1. Establish why the replica is not catching up. Two days is not a transient gap, and the node
   reports its peers' higher height — so it knows it is behind and is not closing it.
2. Make the staleness legible where a person reads a balance. A 0 from a stale replica and a
   0 from an empty wallet must not render identically. synced: false and source: "fallback"
   already carry the fact; nothing user-facing uses them.

Acceptance

The node's replica tracks its peers' peak within a normal margin on a real machine, and a balance
read from a stale replica says so rather than returning a bare zero that a reader will take as an
answer.

[MichaelTaylor3d]

Resolved — the node is synced after updating to 0.172.0

Measured just now on this machine, after the user installed the pending updates:

dign wallet sync-status
  phase:              synced
  peak_height:        9222266
  chia_peer_count:    8
  chia_peer_peak_height: 9222266

The node's replica height and its own peers' reported height are EQUAL — not merely close — with 8 chia peers. The ~8,380-block (~2 day) gap this ticket was filed for is gone.

What actually fixed it, stated honestly

I do not have proof of the mechanism. The two candidates are that 0.172.0 changed something in the sync path, or that the old process had simply been running long enough to fall behind and a restart cleared it. The install did both at once, so this measurement cannot separate them.

That matters for whether to close: if it was a restart, the condition can recur silently. So the symptom is resolved and the cause is unproven.

The half of this ticket that is NOT resolved

The second scope item stands untouched: a stale-replica zero balance is still indistinguishable from an empty wallet. dign wallet balance answers 0 with synced: false and source: fallback in both cases, and neither field is surfaced anywhere a person reads.

That is what made the original measurement nearly unfalsifiable — establishing the operator wallet was genuinely empty required querying coinset directly, with a control (the DIG treasury hash returning 357 records) to prove the zero was a reading rather than a dead instrument.

Recommend keeping this open on that half, retitled to the reporting defect, rather than closing on the sync recovery. A zero that cannot distinguish "nothing there" from "cannot see" is a money-surface problem independent of how far behind the replica happens to be today.

[MichaelTaylor3d]

Lane owns this in the wallet batch: branch loop/batch-wallet, draft PR #454. Progress and evidence land on the PR; this ticket closes on its merge.

[MichaelTaylor3d]

Half fixed, half explicitly NOT — PR #454 (2026-08-31)

Scope clause 2 — "make the staleness legible where a person reads a balance" — DONE

control.wallet.balance now carries two additive fields: network_peak_height (the peak this
node's own held Chia peers announced) and stale_by (blocks behind that peak).

stale_by is null unless BOTH the answer's height and the network peak are known, because a zero
and an absence are opposite claims — zero says this figure is level with the network, absence
says nothing bounds this figure. The exact reading in this ticket, balance 0, synced false, peak_height null, is the second one, and there was previously no field that could say so.

The human line was the real defect surface, and it was worse than the ticket recorded. It read:

balance {} · pending {} · {}
result["balance"].as_u64().unwrap_or(0)

so a missing or non-numeric balance field printed a confident 0 — the reassuring-zero-from-a
key-that-does-not-exist shape. And the qualifier was the word syncing, which reads as progress
rather than as a warning. It now renders unknown for an unreadable field and prefixes every
non-current figure with NOT CURRENT, naming the as-of height and the gap.

Tests, and what makes each load-bearing.

• a_stale_zero_and_an_empty_wallet_zero_do_not_render_alike — asserts the two lines DIFFER, and
  carries the empty-wallet control in the same test: an implementation that scare-marked every
  balance would satisfy "the stale line warns" alone and fails on "the synced line does not". A
  third bounded-but-behind case pins that the gap and the height are named.
• an_unreadable_balance_field_renders_unknown_not_zero — with a synced control proving a measured
  zero still prints as 0, so this cannot be satisfied by never printing zero.
• stale_by_distinguishes_an_unknown_gap_from_a_zero_gap — five cases including both unknown
  directions and the ahead-of-peers saturation.
• balance_wire_carries_the_staleness_gap_additively — the wire, with an old-consumer parse.

One correction worth recording: this ticket says ~8,380 blocks; 9,220,177 − 9,211,798 is 8,379.
The test caught the off-by-one when it was written to the ticket's figure.

Scope clause 1 — "establish why the replica is not catching up" — NOT DONE

That is a diagnosis of a specific real machine's node. This lane worked in a worktree, does not have
that host, and did not re-measure it. Reporting it as unverified rather than claiming it. It
needs a lane with access to the machine, and it remains the step-8 dependency for
#412.

The fix above does not make the replica catch up. What it does is ensure that while the replica is
behind, nobody reads its zero as an answer.