Nothing calls latch_ever_funded, so a funded auto-created wallet is still reported disposable

[MichaelTaylor3d]

Task

autoseed::latch_ever_funded is wired, persistent and idempotent — but nothing calls it. No balance observer exists, so in the shipped build a funded auto-created wallet is still reported disposable.

SPEC.md §16.4 carries an explicit NOT YET SATISFIED block saying exactly this. This ticket closes that block.

Why a SPEC note is not enough on its own

The implementer raised this and is right: a SPEC that documents an unwired contract invites a future reader to implement against the paragraph and miss the caveat. The paragraph reads as a specification of behaviour; the caveat is one block away and easy to skim past.

It is also the pattern this ecosystem hit three separate times on 2026-08-20 — a conformance claim that passes because the thing it governs never occurs (Tier2Bribed has no producer; dig-sex §12 asserted profit-first conformance; this latch). CLAUDE.md now requires a conformance list to distinguish satisfied from vacuously satisfied. This is the tracked half of that requirement.

What the latch is for

ever_funded is monotonic and never clears. Once set, no surface may describe the wallet as disposable, whatever the current balance reads — a balance of zero is not evidence a wallet never mattered.

The wallet in question was created without the user asking, and its recovery phrase has never been shown to anyone. So "disposable" is the most dangerous thing a surface could say about it, and the latch is what stops that being said.

Scope

Call latch_ever_funded from wherever the node first observes a non-zero balance for the wallet. The observation point is the design question worth settling before writing: a wallet-sync callback, a periodic reconcile, or the status read — they differ in how quickly the latch is set after funds arrive, and a gap between "funded" and "latched" is a window where the wrong sentence can still be shown.

Fail toward latching. If it is unclear whether funds were observed, latch. The cost of latching a never-funded wallet is that it stops being called disposable; the cost of the reverse is a user losing money they could not recover.

Context

• crates/dig-wallet/src/autoseed.rs — latch_ever_funded, is_disposable, and the wallet.meta.json sidecar.
• SPEC.md §16.4 — the NOT YET SATISFIED block this closes.
• Parent design decision: Auto-create the mnemonic seed on start when none exists -- fail closed on an unreadable path #277 (#issuecomment-5358477734).
• The consuming surface is dig-app, which is where "disposable" would be rendered.

Evidence

A test that fails without the fix: observe a non-zero balance for an origin: auto wallet, restart, and assert is_disposable() is false. Today it stays true forever.

Delete the NOT YET SATISFIED block in the same unit of work — a stale caveat is worse than none, because the next reader trusts it.

[MichaelTaylor3d]

Independently reproduced 2026-08-24, with the call-site evidence, while measuring the custody
population for https://github.com/DIG-Network/dig_ecosystem/issues/1701.

Confirmed on origin/main:

• latch_ever_funded is defined once, at crates/dig-wallet/src/autoseed.rs:296.
• Its only three callers are at :944, :955 and :980 — all below the #[cfg(test)] at :689,
  so every one of them is a test.
• Zero production callers.

So ever_funded reads false on every wallet on every install regardless of history, and
is_disposable() collapses to origin == Auto. A funded auto-minted wallet is still reported
disposable — precisely the outcome the monotonic-latch design exists to prevent.

The design, the tests and the fail-closed reasoning are all correct. Only the call site is missing,
which is why this is invisible to the suite: the_funded_latch_ends_disposability_permanently and
latching_a_wallet_with_no_sidecar_records_it_as_not_disposable both pass, because they call the latch
themselves. The tests prove the latch works; nothing proves it is ever invoked.

The operational consequence, which is the reason this is worth more than a dead-code nit

No argument may cite ever_funded in either direction until the call site is wired. A false there
is not evidence a wallet was never funded — it is evidence that nothing ever wrote to the field. Tonight's
custody count deliberately treated the flag as carrying zero evidential weight and answered the
funding question from chain state instead: 16 addresses (2 blobs × unhardened indices 0–7), both
assets, 32 coinset queries with include_spent_coins: true, plus a positive control (a real puzzle hash
from block 9190788 returning 84 records) and a negative control (a well-formed bogus hash returning 0
with success: true).

That is the shape any future check needs to take while this stands.

A regression test for the fix should assert the latch is called on the first observed non-zero
balance, not merely that the latch mutates state when called — otherwise the new test has the same
blind spot as the existing two.

Related: https://github.com/DIG-Network/dig_ecosystem/issues/3139 (the auto-seed epic that creates these
wallets) and DIG-Network/dig-node-control-interface#21 (StatusResult cannot
carry wallet_ever_funded, so the flag is not observable over the control plane either).

[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]

Fixed — PR #454 (2026-08-31)

latch_ever_funded now has a production caller. New module
crates/dig-node-service/src/wallet_funded.rs holds the decision as a pure function; the mirror
pass (server.rs, spawn_mirror_passes) is the observation point, because it already reads the
operator wallet's own balance on a timer — so the latch costs no extra chain read and cannot drift
from the figure the node acts on.

SPEC §16.4's NOT YET SATISFIED block is deleted in the same unit of work and replaced with the
observation-point contract, as this ticket requires.

A deliberate deviation from this ticket's wording — please read before approving

This ticket says: "Fail toward latching. If it is unclear whether funds were observed, latch."

Implemented literally, that latches on the "cannot say" outcome — which is the state every node is
in on its first pass, before its replica has caught up. Every auto-created wallet in the ecosystem
would latch within seconds of first boot, and is_disposable would answer false unconditionally,
for ever. That is a conformance claim that passes because the thing it governs never occurs — the
exact vacuity this ticket's own body cites (Tier2Bribed, dig-sex §12, this latch) as the
pattern to avoid. The fix would have reproduced the defect it was written to close, in the opposite
direction.

The instruction's purpose is served without that cost, because of an asymmetry the wording does
not rely on: nothing anywhere records "not funded". The latch is monotonic and has no clearing
path, so declining to latch on an unknown defers a decision rather than making the wrong one,
and the next observation that sees money latches. There is no state this can settle into in which a
funded wallet is called disposable — only a window before the first usable read.

And the direction that actually matters is covered without a currency gate:
FundingObservation::classify answers Funded for a non-zero figure from either tier, so a
stale replica or an unbounded chain-fallback answer that shows money latches immediately. synced
gates only the ZERO case, which is the one case where "nothing" and "I cannot see" decide anything
different.

Net rule: only evidence of money latches; a current measured zero withholds; an unknown defers.

Tests

• a_current_zero_is_evidence_of_emptiness_and_an_unsynced_zero_is_not — all three outcomes, plus
  the control that a non-zero figure classifies as funded from either tier, so synced cannot creep
  into gating the money case.
• only_evidence_of_money_latches — asserts both non-latching cases alongside the latching one,
  because an implementation that latched unconditionally and one that never latched would each
  satisfy a single-direction test.
• observing_funds_makes_an_auto_wallet_permanently_non_disposable — end to end over the real
  sidecar on disk. Asserts the disposable pre-state, asserts a measured-empty observation does NOT
  latch (without which the final assertion could not fail), then latches and re-reads from the
  filesystem, which is the restart this ticket asks for.