dig-node drops every CAT coin at ingestion, so $DIG balance reads a confident zero on a funded wallet

[MichaelTaylor3d]

Task

dig-node's wallet replica drops every CAT coin at ingestion, so control.wallet.balance returns a confident 0 for $DIG on a wallet that holds it, and the arrival ledger never records a CAT receipt. Fix the ingestion so subscribed CAT coins are stored, without widening the guard into accepting arbitrary puzzle hashes.

Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3166
Siblings: DIG-Network/dig-app#291 (the user-visible symptom) · DIG-Network/dig-app#292 (blocked by this — CAT arrival notifications can never fire)

The user reported it directly

"i noticed that the dig-app is not displaying the DIG CAT balance, it says zero when i know i have sent DIG to it"

A surface that says zero when money is present is a surface lying about money. It is indistinguishable, to the user, from a wallet that was drained.

Reproduced against real funds, 2026-08-27

Live node on the user's machine, dig-node 0.154.0, phase: synced, peak_height: 9206707:

dign wallet balance xch17s7wd45k6vpmpwcqu26x43x5kac6u3n6pprjl9ssal6qp3dlvmjqf4snk5 --asset dig
  -> {"balance":0,"pending":0,"source":"db","synced":true}
dign wallet balance <same address> --asset xch
  -> {"balance":43348979998,"synced":true}

Mainnet truth for that same address (inner puzzle hash f43ce6d6…c5bf66e4), via api.coinset.org get_coin_records_by_hint: three unspent $DIG coins totalling 1 010 000 CAT mojos = 1 010 $DIG, all at puzzle hash 71e4312fad7361ced8fd7c166b0431f0ae0bd768713d31e0485e877798801dfa — verified independently as curry(CAT2_MOD, CAT2_MOD_HASH, DIG_ASSET_ID, f43ce6d6…), so canonical $DIG and not another CAT.

The node's own replica:

select asset_id, count(*) from coins group by asset_id;  -> (NULL, 959)
select hint,     count(*) from coins group by hint;      -> (NULL, 959)
select puzzle_hash, count(*) from coins where spent_height is null group by puzzle_hash;
  -> only the three BARE p2 hashes
select count(*) from arrivals;                           -> 5, all XCH

Not one of 959 coin rows has ever carried an asset_id or a hint.

Root cause — one line

crates/dig-wallet/src/sage/sync.rs:705, in apply_coin_states:

let rows: Vec<CoinRow> = states
    .iter()
    .filter(|s| subscribed.contains(&s.coin.puzzle_hash))
    .map(coin_state_to_row)
    .collect();

subscribed is the set of bare p2 puzzle hashes passed to request_puzzle_state (sync.rs:875, subscribe_when_finished = true). Chia's puzzle-state subscription returns coins matching a puzzle hash or a hint — which is exactly how every Chia wallet finds its CATs. A $DIG coin arrives with coin.puzzle_hash = 71e4312f…, which is not in subscribed, so it is dropped and counted into the "peer pushed coin states outside the subscribed puzzle-hash set" warning as though the peer were hostile.

The guard's predicate is narrower than the subscription it guards. Because nothing survives it, the CAT attribution pass at sync.rs:719 (design B.6, #407) — which uncurries a candidate's parent spend to fill in asset_id/hint — has never had a candidate to run on. That is why both columns are 100% NULL rather than merely sometimes NULL.

Scope, and what must NOT happen

Keep the guard. SubscribedHashes' own doc-comment states the threat correctly: the socket is untrusted, a co-resident process that binds 127.0.0.1:8444 becomes the chain source on the next connect, and an unfiltered upsert lets it invent coins at hashes the wallet never asked about. Do not relax the filter to "accept anything".

This is not a one-character widening, and there is a real design fork. CoinState carries no hint field, so the node cannot re-derive locally which subscribed hash a hinted coin belongs to. Two shapes worth weighing before building (§1.10 — settle the shape first):

• Admit on parent uncurry. Accept a coin whose parent spend uncurries to a CAT whose inner puzzle hash is subscribed. This is the strongest predicate — it proves ownership from the chain rather than trusting the peer — and sync.rs:719 already knows how to compute it. The cost is that admission now needs the parent spend, which is a further peer read.
• Grow subscribed with derived CAT puzzle hashes. For each subscribed p2 hash and each known asset id, add curry(CAT2_MOD, CAT2_MOD_HASH, asset_id, p2_hash). Cheap and local, but it only covers assets the node already knows about, so a CAT the user has never held stays invisible.

Whichever is chosen, say why in the PR, and state what an untrusted peer can still cause.

Evidence (§2.6)

• The user's own node reporting 1 010 $DIG for that address, on a real machine. That is the bar.
• A regression test that a CoinState at a CAT-wrapped puzzle hash derived from a subscribed inner hash is stored, and one that a CoinState at an unrelated puzzle hash is still dropped. The second must go RED if the guard is removed — a test that only proves the first pins nothing, because "accept everything" passes it.
• A test that the stored CAT row gains its asset_id, so the attribution pass is proved to run rather than merely to exist.

Report

Say which shape was chosen and what the admission predicate now proves. If the fix changes how many peer reads a sync performs, say so — the ingestion path runs against every coin state the peer pushes.

[MichaelTaylor3d]

This and #382 are two of the three defects in one series, and PR#383 fixes all three. I have added
Closes #380 to that PR so this ticket does not survive its own fix.

The three, in the order they defeat each other:

1. CAT asset_id attribution never runs in production, so $DIG balance reads zero on a funded wallet #382 — sync_supervisor.rs:2277 passed None where a CatAttributor belongs, so the
   attribution pass never ran in production.
2. dig-node drops every CAT coin at ingestion, so $DIG balance reads a confident zero on a funded wallet #380, this one — apply_coin_states discarded every hinted CAT coin the catch-up had asked
   for: a CAT coin sits at the CAT puzzle hash while the subscription set holds p2 hashes. Evidenced by
   566 warnings in the installed node's own logs over five days, 138–188 coins per catch-up.
3. A third, in chia-query — its peer tier returns a placeholder coin
   (puzzle_hash: 0x00…00, amount: 0) from get_puzzle_and_solution while returning the puzzle and
   solution faithfully. Every CAT driver derives child coin ids from that coin, so parse_children
   matched nothing and reported not-a-CAT: not_a_cat: 183, lineage_unavailable: 0. Filed
   separately as https://github.com/DIG-Network/dig_ecosystem/issues/3174 because it exposes every other
   consumer of that call.

Fixes 1 and 2 alone still read zero — which is why this looked like two separate bugs. Only the
third explains why correcting the first two changed nothing.

Verified on the real wallet: before {"balance":0,...}, after {"balance":3856455,...} — 8 coins,
3,856,455 mojos, matching api.coinset.org exactly. 3,856.455 $DIG.

Your note that #292 is blocked by this is right and still holds: CAT arrival notifications cannot fire
while CAT coins never enter the replica.

[MichaelTaylor3d]

Re-homed by the #383 split. This ticket — the CAT ingestion drop — is now closed by #390 (PR-B), not by PR#383.

PR#383 becomes PR-A: the attributor wiring alone, closing #382. It will not carry Closes #380.

Why the split: five rounds on #383, each fixing one defect and creating the next. That is evidence the unit was too large, not that any single round was careless. #382's fix is independently mergeable and independently verifiable against the real wallet; CAT discovery is a different change that needs its own gate round.

And the last round is why #380 needs a different shape than it had. Round 5 discovered CAT coins by subscribing to the derived puzzle hash and admitting them straight into coins. The derivation is sound — the curry commits injectively to (CAT2 mod, asset id, inner p2) — but it proves "only this wallet can spend this, as this asset", not "this coin is a unit of that asset". Anyone may CREATE_COIN at any puzzle hash, so a fabricated balance cost 1 mojo per displayed base unit and needed only your public address.

#390 keeps the discovery and adds the missing half: stage first, promote only what a lineage proof establishes.

[MichaelTaylor3d]

Measured 2026-08-28 on a real machine against live mainnet. PR #383 was split per the round-6
shape decision; PR-A is #391.

PR-A fixes the defect named in #382 — ChiaPeerSession::run passed a hard-coded None where a
CatAttributor belongs, so CAT attribution never ran in production. That fix is real and proven: the
production pass, run over this wallet's eight real $DIG coins with real mainnet reads, attributes all
eight and produces 3,856,455 mojos, matching api.coinset.org exactly.

But the user-visible symptom is NOT fixed by PR-A alone, and this is the finding worth recording:

rows in the live replica	959, across exactly 3 distinct puzzle hashes (the p2 set)
rows at the $DIG CAT outer hash 6ce1cdf8…	0
rows with any asset_id	0
coins on chain hinted to that p2	136, across 51 distinct puzzle hashes
unspent at the $DIG CAT hash	8, totalling 3,856,455 mojos

apply_coin_states filters on subscribed.contains(&s.coin.puzzle_hash), and subscribed is the p2
set — so every hinted CAT coin is dropped at ingest and the attribution pass has nothing to name. That
drop is #380, and it is upstream of everything PR-A does.

Consequence for closing: #382 should stay open until a person can see a non-zero $DIG balance,
which needs the ingestion half too. PR #391 deliberately carries no Closes keyword for either
ticket.

Full evidence: #391 (comment)