refresh_tracked_coins admits hint-matched coins as XCH, so a fabricated coin reaches the spend selector

[MichaelTaylor3d]

Task

WalletBackend::refresh_tracked_coins admits hint-matched coins straight into coins with
asset_id = NULL, so a coin anybody can fabricate is counted as XCH and reaches the
spend-input selector. This is the same attack dig-node#380 closes on the peer ingest path, on the
coinset oracle path, and it is live on origin/main today with no peer involved.

Context

crates/dig-wallet/src/sage/rpc.rs, in refresh_tracked_coins:

let mut fetched = self.fallback.coin_records_by_puzzle_hashes(&phs).await?;
fetched.extend(self.fallback.coin_records_by_hints(&phs).await?);
let rows: Vec<CoinRow> = fetched.iter().map(fallback_coin_to_row).collect();
self.db.upsert_coins(&rows).await?;

coin_records_by_hints returns coins hinted to the wallet's p2 hashes. A hint is a memo: any
spend may attach any hint to any coin, so this set is attacker-controllable in full, needing only
the victim's public address.

fallback_coin_to_row produces asset_id = None, and asset_id IS NULL means XCH
(db.rs:1021). The row is therefore fed to unspent_coins(None) / unreserved_unspent_coins(None)
— the spend-input selector at rpc.rs:2933 and rpc.rs:3319.

singleton::reconstruct_all runs afterwards and attributes what it can, but it is
best-effort and non-subtractive: a coin it cannot reconstruct is left exactly as admitted, i.e.
as XCH. So the failure direction is a wrong figure, not incompleteness.

What it costs

The same three consequences #380 enumerates, reachable without touching a peer:

1. a fabricated XCH balance;
2. a send kill-switch — selection is largest-first, the fabricated coin is unspendable by
   anyone, so it is chosen forever and never leaves the set;
3. anything downstream that trusts coins as the believed set.

Scope

Deliberately NOT fixed in #393, which closes the peer
ingest path only. Fixing it here would have widened a money-path PR that already carries a
measured acceptance bar, so it is logged rather than folded in.

The remedy is very likely the mechanism #393 builds rather than a new one: route hint-matched
arrivals through cat_admission_pending and let promotion decide, so this tier inherits the same
proof. Worth confirming that shape before implementing — a second, differently-shaped guard on the
oracle tier would be a rival implementation of the same distinction.

Evidence

Read on origin/main @ e094078. Not exploited; no coin was fabricated to demonstrate it.

Parent: #390

[MichaelTaylor3d]

Escalated: this is live on main and is not fixed by #393.

The staging design in #390 closes the derived-hash tier. This tier is separate and still admits directly, so the same attack works today with the same economics: anyone may CREATE_COIN at any puzzle hash, hints are attacker-controllable, no malicious peer is required, and only the victim's public address is needed.

Two things make this tier worse than the one #393 fixes:

1. asset_id = NULL MEANS XCH (db.rs:1021), so a fabricated coin does not merely inflate a display — it lands in unspent_coins(None), which is the spend-input selector (rpc.rs:2933, :3319). It becomes a spend input the wallet cannot solve.
2. Selection is largest-first, and the coin is unspendable, so it never leaves the selection set. That is a permanent send kill-switch, not a transient wrong number.

The remedy is almost certainly to route this tier through the same staging table, not to build a second guard. Six review rounds on this family produced one durable lesson: a guard each of 22 coins readers must remember to apply is a guard that will be missed — and this ticket is that miss, one tier over, in code that predates the whole discussion.

Filing detail lives here rather than on the private super-repo because the ticket already exists publicly. Do not add a reproduction recipe to this thread; the mechanism above is enough to act on, and the exploit shape is already recorded privately with the #383 family.

[MichaelTaylor3d]

Folded into #393 (round 7). Do not dispatch this separately.

The PR#393 security gate (verdict)
found a second instance of this same defect and reproduced it with a probe: the catch-up path
also admits a derived-hash coin as asset_id: None (= XCH) into coins.

• sync_supervisor.rs:1381-1386 passes addresses ∪ derived CAT hashes as one vector
• sync.rs:1047 rebuilds the admission set from that widened vector
• sync.rs:765's first disjunct is true for every derived-hash coin
• sync.rs:448 types it XCH

Measured at head 44bacb6e: XCH balance = 999999999, unspent selectable (XCH) = 1.

So there are three tiers of the same root cause, not two — this ticket's refresh_tracked_coins,
the catch-up path, and the frame path that PR#393 already closed. The gate independently reached the
same conclusion recorded here earlier: route every tier through the one staging table rather than
building a second and third guard. Three guards that must agree is how this family reached six
rounds; one admission point that cannot be widened is the shape to aim for.

The invariant the fix has to enforce structurally: the set used for subscription/coverage and the
set used for admission into coins are different sets, and must never be the same value.

The gate also confirmed this ticket is accurately stated and that PR#393 does not worsen it.

Closes with PR#393.

[MichaelTaylor3d]

FIXED — folded into #393, head 46fa77b, still DRAFT
pending the round-7 security gate.

What it was

refresh_tracked_coins fetched coins two ways — by puzzle hash (coins at the wallet's own p2
hashes) and by HINT — and upserted both straight into coins. A row with no asset_id means
XCH in this schema, and a hint is chosen freely by whoever creates the coin, so an attacker holding
nothing but the victim's public address bought a fabricated XCH balance for one mojo per displayed
base unit. Worse than a wrong figure: selection is largest-first and nobody can spend the coin, so
it is a permanent XCH send kill-switch. No peer required — the coinset oracle serves this tier.

The fix, and why it is not a third guard

Routed through the same staging table as the peer frame path. Three guards that must agree is
what produced this defect at three tiers; one admission point that demands a lineage proof is the
shape that cannot be widened.

• shared row-level router — crates/dig-wallet/src/sage/cat_discovery.rs:196-260
• wired into the point-read tier — crates/dig-wallet/src/sage/rpc.rs:3105-3145
• promotion of an unpredicted claim — crates/dig-wallet/src/sage/cat_discovery.rs:424-450

A coin at the wallet's own p2 hash is still admitted directly: it is genuinely ours and genuinely
XCH. A hinted coin is staged and admitted only once its parent spend proves what it is.

A first cut of this was wrong, and the suite caught it. Staging only coins at a derived hash for
a known asset dropped every non-$DIG hinted CAT, and the hint read is the wallet's only path to
one — refresh_tracked_coins_feeds_cat_selection_and_build_sign failed. Unpredicted coins are now
staged with an empty sentinel and proven from the parent spend alone: the reconstruction must name
this coin id and hint it to an address this wallet controls.

Proof it is load-bearing

Router bypassed ((fetched_rows.clone(), Vec::new())), everything else untouched:

test a_hinted_coin_is_staged_while_a_coin_at_our_own_hash_is_admitted ... FAILED
  only the coin at our own puzzle hash is admitted        left: 2   right: 1
test refresh_tracked_coins_feeds_cat_selection_and_build_sign ... FAILED
  a coin found by HINT is staged, never upserted into `coins`    left: 1   right: 0

Restored by file copy, git status --porcelain empty afterwards.

The regression test carries an honest XCH coin at the wallet's own hash alongside the fabricated
one, because this is a placement fix: "the balance is short" is satisfied identically by a
correct re-route and by a refresh that fetched nothing. The fabricated coin is also asserted
present in staging, so "absent from coins" cannot be satisfied by dropping it on the floor.

cargo test -p dig-wallet: 685 + 22 + 8 passed, 0 failed. Clippy and workspace check clean.

SPEC §18.11a now binds all three tiers, and states the coverage/admission separation as a normative
invariant: SPEC.md:5408-5502.

Parent: #390