feat(mirror): operator-scoped $DIG CAT coin selector for mirror creates (#421)

[MichaelTaylor3d]

DO NOT MERGE — gate round has not returned. Draft until then.

Closes #421

What this is

dig_mirror_coin::create takes its Vec<Cat> from the caller. The only $DIG selector this process
had was WalletBackend::select_cats, which reads the node-custodied replica's coin table — a
different wallet from the §16.4 operator wallet the mirror signer signs with. Funding a mirror
coin from those coins is a real spend of the wrong wallet's money that returns Ok and looks
entirely successful, which is why step 7 (#419) made create refuse by name.

This adds the correct selector rather than relaxing that refusal.

Which coin set it reads, and how that is proven

mirror::funding::select_operator_dig_cats reads
ChainSource::coin_records_by_puzzle_hash(dig_cat_puzzle_hash(operator_ph), include_spent = false).
dig_cat_puzzle_hash is CatArgs::curry_tree_hash(DIG_ASSET_ID, operator_ph) — the canonical CAT
wrapping, the same construction reclaimed_coin_id was already using inline and now shares.

The scope is structural, not a filter: a coin at any other owner's puzzle hash is never read.
It is proven by fixtures that fund two different wallets on one chain:

• the_selector_funds_from_the_operator_wallet_and_never_from_the_replica — the replica holds
  10× the requirement, the operator exactly 1×; the selection is the operator's coins and contains
  none of the replica's.
• an_operator_with_no_coins_refuses_even_when_the_replica_is_rich — the mirror image, and the one
  that fails loudly against the defect: only the replica is funded, and the correct answer is
  Insufficient { have: 0 }.

A single-wallet fixture would pass against a selector that ignored its owner argument entirely,
which is precisely the implementation under suspicion.

Extracted, not duplicated

select_cat_rows was not parameterised in place — its algorithm was extracted to
dig_wallet::sage::selection::select_largest_first, generic over the item and its
(amount, tiebreak) key. Three rivals existed: rpc::select_cat_rows over DB rows,
offers::select_cats over resolved Cats, and this new one over chain records. The first two now
call the shared function, with byte-identical refusal messages (on a shortfall the walked total and
the whole-set total are equal, so have is unchanged).

Reservations

The chain cannot offer an unreserved set: a broadcast coin stays unspent in the chain's view for the
whole confirmation window, and the mirror pass runs on a round timer inside it.

The equivalent record already exists and is durable across restarts — the spend audit journal
records funding_coin_ids for every bundle it submits. committed_funding_coin_ids withholds the
funding coins of every record where SpendStatus::is_terminal() is false, reusing that
predicate rather than restating it: a Submitted spend may still consume its coins, an Unresolved
one may already have, and a Failed one at a stage that money_may_have_moved() is an unknown
wearing a failure's name. An audit file with unreadable lines refuses, because a silently
smaller reservation set is exactly how one coin funds two bundles.

Lineage

Each selected candidate is authenticated by reading coin_spend(parent_coin_info) — the spend that
CREATED it — and running it through dig_wallet::sage::singleton::resolve_cat. A candidate whose
creating spend is absent, or which yields no matching CAT child, or whose resolved CAT disagrees
about the asset id or the owner, refuses the whole selection. Dropping it and proceeding would
fund the create from a short set, and a mirror coin below the epoch's requirement is collateral
genuinely locked against a bond it does not satisfy.

A chain Err maps to PassError::Chain, never to Insufficient — an unreadable source is UNKNOWN
and is in no position to claim the wallet is empty.

The amount

create passes its amount_dig_base_units argument straight through as the selection target.
Nothing here re-derives apply_safety_margin(required_per_store, margin_bp).
the_number_of_coins_drawn_follows_the_requirement_it_was_given asserts the selection tracks the
argument, so a selector that ignored it would be visible.

What step 7 established, unchanged

• MirrorSigner::sign(&MirrorSpends, &SpendJournal) is untouched.
• The signer stays module-private. The structural .with_signer( / .with_broadcaster( guard still
  discriminates — this PR adds no such call, and funding.rs is not in its include set because it
  never mentions WalletBackend.
• Reclaims are never gated on a funds read, including the new committed-coin read: it is an
  Err-carrying field consumed only by create, exactly like dig_balance.
• Relayed capsules remain invisible to the create path (split_by_provenance is untouched).

Blast radius checked

gitnexus was not used: a per-worktree analyze on this tree exceeds the §2.0 ten-minute bound,
so the radius was taken by grep + direct read and is stated here per §2.0's fallback clause.

• select_cat_rows — one caller (WalletBackend::select_cats). Behaviour and message preserved.
• offers::select_cats — one caller (offers.rs:134). Behaviour and message preserved.
• reclaimed_coin_id — one caller; now shares the CAT derivation instead of its own curry.
• NodeMirrorEffects::new — one caller (server::spawn_mirror_passes), updated in this PR.
• No public API of dig-wallet or dig-node-service is removed or changed in meaning; both
  additions are new items.

§2.4b

dig-mirror-coin 0.7.0, dig-chainsource-interface 0.3.2 and dig-mirror-collateral 0.3.0 were
checked against the index and are already at latest; the chia-* set stays together on the 0.36
line. The ~30 declarations deferred to #418 are not absorbed here.

What still blocks a create on a funded wallet

1. No advertised URL. dig_mirror_coin::create requires at least one URL its store can be
   fetched from, and this node has no configured public name. NodeMirrorEffects::create refuses by
   name, ahead of any chain read, and server.rs passes an empty URL set with that stated. This is
   an advertisement gap, not a funding one.
2. No broadcaster. spawn_mirror_passes still passes broadcaster: None.
3. DIG_WALLET_ENABLE_LIVE_BROADCAST must be on for a signer to exist at all.

Base

Branched from loop/412-step7-observation (PR #419), which is not yet merged and which
introduces the mirror/lifecycle.rs this changes. Until #419 merges, this PR's diff against main
includes #419's commits.

Version: workspace 0.173.0 → 0.175.0 (minor — new capability; spend_audit::Submission::intended_coin_id
becomes Option<TargetCoinId>, a crate-internal type with no published consumers).

Reservation fix — security gate findings 1 and 2 (d9d4f61)

The gate found the reservation mechanism INERT for creates. SpendJournal::submitted is the sole
writer of funding_coin_ids, and sign_and_broadcast called it only in the arm where the created
coin was derivable — which a create never is, so it passed None and the record was dropped. The
!is_terminal() filter was correct; it was never FED. Two creates in one confirmation window
re-selected the same coins and broadcast conflicting bundles, and control.rs:3352 /
spend_audit_cli.rs:227 showed every create as consuming no coins.

Submission::intended_coin_id is now Option<TargetCoinId> and the submission is recorded
UNCONDITIONALLY. The two facts are independent and are recorded independently: the coins CONSUMED
are read from the signed bundle and are always known; the coin CREATED is None for a create and
stays None — naming a plausible coin would let the reconcile confirm a spend against a coin it
never created, the defect TargetCoinId exists to make inexpressible. The discarding branch is now
unrepresentable rather than merely unused.

SpendRecord::intended_coin_id was already Option, and reconcile's four arms and
chain_reference() already handled None, so no reader changed. A successful broadcast now
resolves Submitted before the drop guard rather than Unresolved with an empty list; both are
non-terminal, so the coins are withheld either way.

SPEC.md §25 states the mechanism and its consequence rather than asserting the reservation
property abstractly, so the clause is true of the code in this same diff.

Blast radius checked

gitnexus's dig-node index predates this branch and could not resolve the symbol, so the radius was
taken by grep + direct read (§2.0 fallback, stated as required rather than silently substituted).
Every construction site of Submission (14) and every call site of .submitted( (13) lie inside
dig-node-service — spend_audit.rs, spend_audit_cli.rs, mirror/funding.rs,
mirror/lifecycle.rs, tests/spend_audit_e2e.rs — plus every reader of intended_coin_id, all of
which already took an Option. Nothing outside the crate names either symbol.

Evidence

Both new tests were proved load-bearing by reverting ONLY the fix (committed first; reverted via a
file copy, not git checkout): both go red while the five surrounding controls stay green. The
first attempt planted the mutation after the funding-ids assignment and all 7 passed — a targeting
error in the harness, not a weak test; corrected and re-run. All 91 mirror:: tests green at
d9d4f61.

The placement is guarded separately, because the defect WAS a placement and a test asserting only
the outcome would pin a coincidence: lifecycle.rs carries a structural guard — in the idiom that
file already uses for the .with_signer( rule — that there is exactly one unconditional
self.journal.submitted( call and no branch on whether the target coin is derivable, plus the
companion test proving the needles match a real reintroduction.

Follow-ups filed, deliberately NOT absorbed

• mirror funding: unbounded selected-input count on a publicly-derivable address, one chain read per input #427 — unbounded selected-input count on a publicly-derivable address, one chain read per
  input (mirror/funding.rs:194-215).
• dig-wallet: select_xch is a fourth largest-first rival and disagrees with its three siblings on overflow direction #428 — dig-wallet/src/sage/offers.rs:412-429 select_xch is a fourth largest-first rival
  and disagrees with its three siblings on overflow direction (sum += c.amount, which wraps in a
  release build).

Still open, and it blocks landing

server.rs:2789 also passes broadcaster: None; #419's 8f93bd6 is the fix, not this PR. This
PR must be rebased onto merged-#419 before it lands — both edit the same mirror/lifecycle.rs
region, and merging second without a rebase risks resolving away #419's honesty fix. Not rebased
yet; #419 is not merged.

Co-Authored-By: Claude noreply@anthropic.com

[MichaelTaylor3d]

loop-security — IN PROGRESS, not the verdict

Auditing at head 0f2970a30aaef97b48bf6ef39ac0a5d5296e23b9 (resolved from gh pr view 423 --json headRefOid).

Scope correction, before any finding

The dispatch brief says this branches from loop/412-step7-observation (#419). That is true, but not from #419's current head — and the difference matters for whoever merges.

• merge-base(423, 419) = ab6b25a, which is on feat(mirror): construct the bond-state observation (#412 step 7) #419's branch but is three commits behind it.
• feat(mirror): construct the bond-state observation (#412 step 7) #419 has since added 9a5d392, 8f93bd6, e22e8ae — which feat(mirror): operator-scoped $DIG CAT coin selector for mirror creates (#421) #423 does not contain.
• So a naive git diff <419-head>..<423-head> renders those three commits as deletions by feat(mirror): operator-scoped $DIG CAT coin selector for mirror creates (#421) #423, which they are not. The true delta of this PR is ab6b25a..0f2970a: 13 files, +1356/-83.

control.rs and mirror/runner.rs appear in the naive diff and are not part of this PR. Auditing ab6b25a..0f2970a.

MERGE-ORDER HAZARD (not a defect in this diff, flagged for the orchestrator)

#419's 8f93bd6 — "derive the reported spend capability from the broadcaster the pass actually gets" — introduces SpendCapability::BroadcasterUnwired and production_broadcaster(), so the node cannot announce a spend power it lacks. #423 is built on the code from before that fix. Both PRs target main.

If #419 merges first and #423 is merged without rebasing onto it, the three-way merge can resolve lifecycle.rs back toward #423's older shape and silently undo that honesty fix. #423 also legitimately reworks the same open_signer / sign_and_broadcast region, so this is a real conflict surface rather than a theoretical one.

Recommendation: rebase #423 onto merged-#419 and re-run this gate on the rebased head before merging second. I will state in the verdict whether the funding logic itself is clean; that verdict cannot cover a merge resolution that has not happened yet.

Continuing: scoping claim, double-spend surface, lineage authentication, the select_largest_first extraction, fixture-collapse fix.

[MichaelTaylor3d]

loop-security — FINDING 1, GATING — IN PROGRESS, not the verdict

Head audited: 0f2970a30aaef97b48bf6ef39ac0a5d5296e23b9

The reservation mechanism is INERT for the one operation this PR exists to enable

mirror/funding.rs opens by stating the guarantee it provides:

SpendJournal writes the funding_coin_ids of every bundle it submits … A non-terminal record's funding coins may still be consumed, so they are withheld.

A mirror create never writes funding_coin_ids, in any outcome. So committed_funding_coin_ids withholds nothing for creates, and the reservation set that select_operator_dig_cats consults is — for creates — always empty of create-funded coins.

The chain of evidence

1. spend_audit.rs:791 — every record is born funding_coin_ids: Vec::new().
2. spend_audit.rs:810-815 — SpendJournal::submitted() is the sole writer: rec.funding_coin_ids = submission.funding_coin_ids;. Nothing else assigns that field anywhere in the crate.
3. lifecycle.rs:210-214 — sign_and_broadcast computes funding_coin_ids correctly from the bundle.
4. lifecycle.rs:218-241 — but it is consumed only in the Some(intended_coin_id) arm, which calls submitted(). The None arm (lifecycle.rs:236) only emits a tracing::warn! and drops recorded, resolving it Unresolved. The computed funding_coin_ids is discarded.
5. lifecycle.rs:419 — the create path calls self.sign_and_broadcast(&spends, None). None is the create path; reclaim (lifecycle.rs:320) is the only caller passing Some(..).
6. lifecycle.rs:244-249 — the broadcast-failure branch calls journal.failed(&recorded, FailureStage::Broadcast, ..), which takes no funding coins either. FailureStage::Broadcast.money_may_have_moved() is true, so the record is non-terminal — it is retained by the !r.status.is_terminal() filter at funding.rs:164 and then contributes an empty id list at funding.rs:165.

So on every create outcome — broadcast OK (Unresolved) or broadcast failed (Failed{Broadcast}) — the record is correctly non-terminal, is correctly selected by the filter, and correctly contributes nothing.

Concrete scenario

State: operator wallet open, live broadcast on, broadcaster wired (#424), advertised URLs configured (#426). Stores S and T both need bonds. Operator holds C1=6000, C2=5000 base units.

1. Pass N: create(S, 10_000) → largest-first selects C1,C2 → signs → broadcast OK → record Unresolved, funding_coin_ids = [].
2. Pass N+1, inside the confirmation window: S's bundle is in the mempool, so the chain still reports C1,C2 unspent; coin_records_by_puzzle_hash(.., include_spent=false) returns them. committed is empty.
3. create(T, 10_000) → largest-first is deterministic (selection.rs:60-90) → selects C1,C2 again → signs → broadcasts a bundle spending coins already committed to S's bundle.
4. The two bundles conflict. Fee is 0 on both (lifecycle.rs:415), so there is no fee-replacement: one is rejected. The node's journal records both as successfully broadcast, and §25.8 reports the loser's bond as uncovered.

Severity and why I am gating rather than ticketing

This is not a fund-loss primitive — the chain refuses the conflicting spend, so no coin is consumed twice. It is also dormant in production today: server.rs:2781 passes Vec::new() for advertised_urls and None for the broadcaster, so create refuses at lifecycle.rs:325 before any chain read.

I am gating anyway, on three grounds:

• The PR ships a safety mechanism that does not hold for the operation it was built for. funding.rs §"Reservations, without a reservation table" is a normative claim about money, and it is false for creates in the very commit that writes it.
• The two tickets that make it live are named in this diff as "the one remaining gap." Whoever lands The mirror lifecycle has no production broadcaster, so no reclaim can reach chain #424/Mirror creates need an advertised URL this node can be fetched at #426 will flip creates on believing reservations hold. That is the born-false-claim shape, and it is cheapest to correct before the claim is merged.
• The audit surface inherits it. control.rs:3352 and spend_audit_cli.rs:227 render funding_coin_ids from the record, so every create will report no funding coins on the operator's own money surface — a spend that consumed real collateral displaying as having consumed nothing.

Fix shape (not a request for a specific patch)

The record needs its funding coins even when no TargetCoinId is derivable. Submission currently couples the two (intended_coin_id is not Option), which is what forced the create path down the drop-to-Unresolved arm. Decoupling them — a journal call that records consumed coins without asserting an intended coin — preserves the property TargetCoinId exists to enforce (never confirm against a guessed coin) while closing this gap. The broadcast-failure branch needs the same treatment, since Failed{Broadcast} is explicitly a may-have-moved state.

A regression test would need two consecutive passes over one chain fixture, asserting the second pass does not re-select the first's coins.

Continuing the audit: lineage authentication, the select_largest_first extraction (checked, clean — reported next), the fixture-collapse fix, and SPEC.md claims.

[MichaelTaylor3d]

loop-security — FINDINGS 2-4 — IN PROGRESS, verdict next

Head audited: 0f2970a30aaef97b48bf6ef39ac0a5d5296e23b9

Line-number correction to Finding 1: the create's sign_and_broadcast(&spends, None) is lifecycle.rs:387 (reclaim's Some(..) is lifecycle.rs:320), and the advertised-URL guard is lifecycle.rs:327. The finding is unchanged.

---

FINDING 2 — GATING (normative twin of Finding 1): SPEC.md §25 asserts the reservation property as normative

SPEC.md:7956-7966 now states, in normative voice:

mirror::funding::select_operator_dig_cats … withholds coins committed to a bundle whose audit record is not terminal …

Per Finding 1, no create ever writes funding_coin_ids, so for creates this withholds nothing. §4.2 requires SPEC.md to be the contract an independent reimplementation could be built against; a reimplementer reading this clause would build the property and diverge from this node. The clause is false in the commit that writes it — born-false, not stale.

Fixing Finding 1 fixes this clause too. If instead the decision is to ship the gap, the clause must say so explicitly.

FINDING 3 — GATING (money-surface honesty): "the advertisement is the one remaining gap" is not true at this head

SPEC.md:7961-7963 and lifecycle.rs:47-53 both state that the only thing standing between this node and a mirror create is the advertised URL (dig-node#426). At this head there are two blockers, not one:

• server.rs:2784 — advertised_urls is Vec::new(), refused at lifecycle.rs:327. Stated.
• server.rs:2789 — the broadcaster argument is None. sign_and_broadcast refuses at lifecycle.rs:196-202. Not stated anywhere in this diff.

Worse, the refusal message that fires on that second blocker reads:

"live broadcast is disabled (DIG_WALLET_ENABLE_LIVE_BROADCAST), so no mirror spend is sent"

That names a flag the operator has already set — open_signer yields no signer without it, and the signer is checked first at lifecycle.rs:193, so this line is only reachable once the flag is on. Meanwhile open_signer returns SpendCapability::Available and server.rs:2717 logs "the mirror lifecycle is live: this node may create and reclaim collateral" on a node that can send nothing.

This is largely inherited, not introduced — it is precisely what #419's 8f93bd6 fixes with SpendCapability::BroadcasterUnwired and production_broadcaster(), and #423 is built on the commit before that fix (see my scope comment above). But #423 adds the "one remaining gap" claim to SPEC.md and to the module doc, which makes the inherited inaccuracy newly normative.

Cheapest correct resolution: rebase onto merged-#419. That restores the honest capability reporting and makes the two docs' "remaining gap" wording obviously in need of the second item. Do not merge #423 second without that rebase.

FINDING 4 — NOT GATING, follow-up ticket: unbounded input count on a publicly-derivable address

funding.rs:194-215 places no cap on how many coins a selection may draw, and authenticate (funding.rs:240) issues one coin_spend chain read per selected coin.

A mirror coin on chain exposes its owner_puzzle_hash, from which anyone can derive dig_cat_puzzle_hash(owner_ph) and pay dust $DIG there. Largest-first (selection.rs:74) puts dust at the back, so this only bites once the operator's own coins are exhausted or committed — a normal state for a node that has bonded most of its $DIG. At that point a requirement of N base units met by 1-unit dust draws N inputs, N chain reads per pass, and produces a bundle that will exceed block cost limits.

Cost to the attacker is real $DIG plus fees, and the dust is a gift to the operator, so this is griefing rather than theft. Two things make it worth a ticket rather than nothing: there is no input-count cap anywhere on the path, and this codebase already treats the sibling case as an attack — lifecycle.rs:270 fails closed on an incomplete owned-coin scan precisely because "the truncation point is purchasable with dust."

I checked the truncation variant and it is clean: dig-chainsource-interface/src/source.rs:41-48 contracts coin_records_by_puzzle_hash to return all matching coins with Err for "could not answer", so there is no silent short read to fail open on.

FINDING 5 — NOT GATING, follow-up ticket: the fourth rival was left behind, and it disagrees

offers.rs:412-429 select_xch is the same fifteen lines the extraction removed from the other three, still with non-saturating sum += c.amount. selection.rs:82 saturates deliberately, so the surviving rival now differs from its three siblings in overflow direction — the "two rivals that disagree" shape CLAUDE.md §2.0 calls out, rather than mere duplication.

Not exploitable: XCH total supply is far below u64::MAX and the coin set is the node's own. Fold it into the shared helper next time that file is touched.

[MichaelTaylor3d]

loop-security VERDICT: CHANGES-REQUIRED

Head audited: 0f2970a30aaef97b48bf6ef39ac0a5d5296e23b9 (resolved from gh pr view 423 --json headRefOid; PR is DRAFT, mergeable: MERGEABLE against main).
Delta audited: ab6b25a..0f2970a — this PR's own 6 commits, 13 files, +1356/-83. Not the naive 419-head..423-head range, which misrenders three of #419's later commits as deletions (see my scope comment).

Read-only audit. No file edited, no shared checkout mutated — git fetch plus git show/git diff against objects only. No worktree cut.

---

The lead question: can any path fund a create from a wallet other than the operator's?

No. The scoping claim holds, and it holds structurally as the lane argues. This is the strongest part of the diff.

• funding.rs:190 is the only chain read for candidates, at dig_cat_puzzle_hash(owner_puzzle_hash). There is no second scan, no fallback set, no cache, and no caller-reachable include_spent toggle — the flag is a hard-coded false and is_spent() is independently re-checked at funding.rs:200.
• owner_puzzle_hash is not caller-supplied in any reachable sense: select_operator_dig_cats has exactly one production caller (lifecycle.rs:378), passing self.owner_puzzle_hash; NodeMirrorEffects::new has exactly one call site (server.rs:2775); and that value is derived at server.rs:2697-2700 from signer.owner_puzzle_hash(), falling back to operator_wallet::operator_puzzle_hash(&paths). Both are the §16.4 operator wallet. WalletBackend::select_cats is never reached from this path.
• A lying chain source cannot widen it either. Even if a source returned records outside the requested puzzle hash, authenticate (funding.rs:234) resolves each candidate's lineage and then refuses on cat.info.asset_id != DIG_ASSET_ID and cat.info.p2_puzzle_hash != owner_puzzle_hash. A foreign-owned coin cannot survive both.
• The proof shape is genuinely discriminating: tests/mirror_operator_funding.rs funds two wallets on one chain and asserts both directions — operator coins chosen and replica coins absent (:196-227) — plus the mirror probe where only the replica is funded and the correct answer is a refusal (:234-250). :428-440 pins the fixture's coins to the scanned hash, so the file cannot go green on empty wallets.

The fixture-collapse fix is real: Chain::fund asserts distinct coin ids at tests/mirror_operator_funding.rs:62-65 and would fail on the [REQUIRED, REQUIRED] shape that collapsed.

Lineage all-or-nothing holds: authenticate is called inside a for loop with ? at funding.rs:216-219, so any refusal aborts the whole selection, and funding.rs:246-249 maps a chain Err to FundingError::Chain, never Insufficient. A read failure cannot be laundered into "you are short".

The extraction is clean and behaviour-preserving. Both pre-existing callers keep byte-identical refusal messages, each in its original field order. Shortfall.have is the whole-set total, which on the shortfall path equals the old walked total because the loop exits early only once the target is met — so the substitution is exact. Both gained saturating accumulation, which can only refuse, never over-fund.

---

Why this is CHANGES-REQUIRED anyway

1. GATING — the reservation mechanism is inert for creates

spend_audit.rs:791 births funding_coin_ids: Vec::new(); spend_audit.rs:810-815 (submitted()) is its sole writer; lifecycle.rs:218-241 calls submitted() only in the Some(intended_coin_id) arm; and the create path passes None (lifecycle.rs:387). The broadcast-failure branch (lifecycle.rs:244-249) writes Failed{Broadcast}, which is non-terminal but also carries no funding coins.

So on every create outcome the record is correctly retained by the !is_terminal() filter at funding.rs:164 and contributes an empty id list at funding.rs:165. Two creates in consecutive passes, inside one confirmation window, deterministically re-select the same largest coins and broadcast conflicting bundles.

is_terminal() itself is correct — I checked all five states at spend_audit.rs:301-307. Pending/Submitted/Unresolved withhold; Confirmed and pre-signing Failed release. The predicate is fine; it is never given anything to work with.

Not a fund-loss primitive — the chain rejects the conflicting spend. It is a liveness defect, a false safety claim, and a money-surface inaccuracy: control.rs:3352 and spend_audit_cli.rs:227 will render every create as having consumed no coins.

Note the test shape. Every integration probe supplies committed by hand, and every committed_funding_coin_ids unit test populates the journal with explicit journal.submitted(..) calls. Nothing exercises create to journal to reservation end to end, which is why this is green.

2. GATING — SPEC.md:7956-7966 asserts that property in normative voice, and it is false on arrival

Fixing finding 1 fixes the clause. Shipping the gap instead requires the clause to say so.

3. GATING — "the advertisement is the one remaining gap" is untrue at this head

server.rs:2789 also passes None for the broadcaster, so sign_and_broadcast refuses at lifecycle.rs:196-202 with a message naming a flag the operator has already set. open_signer still reports SpendCapability::Available and server.rs:2712-2714 logs that the lifecycle is live. This is largely inherited — #419's 8f93bd6 is the fix — but #423 makes it newly normative. Rebase onto merged-#419 and re-gate.

4 and 5. NOT GATING, follow-up tickets

Unbounded selected-input count on a publicly-derivable address (funding.rs:194-215, one chain read per input at funding.rs:246); and offers.rs:412-429 select_xch left as a fourth rival that now disagrees with its three siblings on overflow direction.

---

Areas checked and clear

• Secrets / credentials — clear. No key, seed or credential is logged, printed or serialised. The tracing::info! at lifecycle.rs:391-398 carries only store_id, root, epoch, amount. signer.synthetic_key() (lifecycle.rs:381) is a public key the builder requires. Fixture seed: u8 values are Bytes32 fill bytes and SecretKey::from_seed(&[seed; 64]) in tests/support/mod.rs:63 is a test key. No real seed anywhere.
• Custody / §908 boundary — intact. The node signs only with its own operator wallet; no user key enters any path here.
• Step 7 properties — intact and untouched by this PR. The true delta makes zero changes to forbidden_installations, guarded_sources, or the structural .with_signer( guard (verified: zero matching lines in ab6b25a..0f2970a). sign shape unrelaxed, signer module-private, reclaims unconditional and never gated on the new committed-coin read (lifecycle.rs:121-125).
• Chain-error handling / fail-closed — clear, and better than required. FundingError::Chain and Insufficient are kept distinct, CommitmentsUnreadable refuses on ledger.unreadable_lines > 0 (funding.rs:155), and a missing audit file is correctly an empty set rather than a refusal.
• Truncation fail-open — clear. dig-chainsource-interface/src/source.rs:41-48 contracts the scan to return all matching coins, with Err reserved for "could not answer". There is no silent short read to fail open on.
• Reservation id encoding — clear. Journal side and scan side both use lowercase hex::encode(coin_id), so no case mismatch silently voids the filter.
• Dependencies — clear. Only the workspace version 0.173.0 to 0.174.0, consistent across Cargo.toml and Cargo.lock. No new or loosened dependency.
• Zero collateral — clear. Refused at funding.rs:184 ahead of any chain read, closing the one target for which an empty selection is arithmetically valid.

Mitigating context, stated plainly

None of the gating findings is live in shipped code. create is unreachable in production at this head: server.rs:2784 supplies no advertised URLs and server.rs:2789 supplies no broadcaster.

I gate on findings 1 to 3 because the PR merges a safety mechanism and a normative SPEC clause that assert a property the code does not have, and the two tickets that switch this path on are named in this very diff as the only remaining work — so the false claim is aimed squarely at whoever flips it.

The scoping work, which is the substance of #421 and the thing most likely to lose money if wrong, is correct.

Re-gate scope on the fix: findings 1 and 2 are one change (journal the create's funding coins, correct the SPEC clause) and need only this security leg re-run. Finding 3 is a rebase, and the rebased head needs a fresh read of lifecycle.rs because both PRs edit the same region.

[MichaelTaylor3d]

Findings 1 and 2 addressed at d9d4f61

Both gating findings are fixed. Head was verified as 0f2970a before the first write, matching the
audited head; the branch had not moved.

Finding 1 — the reservation was inert for creates

Confirmed exactly as described, and it was the "guard that is never fed" shape rather than a broken
guard. is_terminal() needed no change.

The honest shape. The intended_coin_id genuinely is not known at that point — a create's output
coin takes its parent from whichever input the builder drew it from, and this node does not derive
it. So it was not fabricated. What the old code got wrong was COUPLING two independent facts: the
coins CONSUMED are read from the signed bundle and are always known, while the coin CREATED sometimes
is not. Coupling them meant a producer with no derivable target had no way to record the consumed
coins either.

Submission::intended_coin_id is now Option<TargetCoinId>, and sign_and_broadcast records the
submission UNCONDITIONALLY on a broadcast that reaches the mempool. A create records its funding
coins and names no target coin. The discarding branch is unrepresentable rather than merely unused,
so the placement cannot silently regress.

SpendRecord::intended_coin_id was ALREADY Option, and reconcile's four arms and
chain_reference() already guarded with if let Some(..) — so no reader changed. One behaviour
delta worth stating: a successful broadcast now resolves Submitted before the drop guard rather
than Unresolved with an empty list. Both are non-terminal, so the coins are withheld either way,
and the entry no longer understates what the node knows. Nothing moves into or out of
report.unrecorded_on_chain, because a create accounted for no coin under either shape.

Finding 2 — the SPEC clause

Not weakened to a SHOULD. The clause now states the MECHANISM and its consequence, so it is checkable
against this diff rather than asserted abstractly: that the submission is recorded unconditionally on
a successful broadcast, that the created coin is a separate optional field a create leaves unset, and
therefore that two creates in one window MUST NOT select the same coin and that control.mirror.* /
dign spend-audit MUST show a create's consumed coins.

Test evidence, and one correction to it

Both new tests were proved load-bearing by reverting ONLY the fix — committed first, reverted via a
file copy rather than git checkout — and both go red while the five surrounding controls stay green.

Worth recording because it nearly shipped a false green: the first revert attempt planted the
mutation AFTER the funding-ids assignment, and all 7 tests passed. That was a targeting error in
the harness, not a weak test. Re-planted faithfully (skip the whole recording when no target is
derivable, the old shape's actual effect) it produces exactly the two failures expected.

The fixture carries a truthful control rather than being all-creates: a reclaim-shaped record that
DOES name its target sits beside the create. The nearest wrong implementation — the one replaced —
returns {11…} here, which a create-only fixture could not distinguish from a wholly broken reader.

The PLACEMENT is guarded separately, since the defect was a placement and an outcome-only assertion
would pin a coincidence: lifecycle.rs carries a structural guard, in the idiom that file already
uses for the .with_signer( rule, that exactly one unconditional self.journal.submitted( call
exists and no branch on target-derivability does — with the companion test proving the needles match
a real reintroduction and that the include_str! still resolves.

All 91 mirror:: tests green at d9d4f61.

Blast radius

gitnexus's dig-node index predates this branch and returned Target 'submitted' not found, so the
radius was taken by grep + direct read — the §2.0 fallback, stated rather than silently substituted.
14 construction sites of Submission and 13 call sites of .submitted(, all inside
dig-node-service; plus every reader of intended_coin_id, all already Option-shaped. Nothing
outside the crate names either symbol.

Scope — nothing reached further

Version 0.174.0 → 0.175.0. Findings 3 and 4 were NOT absorbed: #427 and #428 are filed and linked
from #421. Finding 3's server.rs:2789 remains #419's 8f93bd6; the PR body now says so and records
that this PR must be rebased onto merged-#419 before landing. Not rebased, still DRAFT, not merged.

One thing outside my scope that will block merge: 11 unresolved github-advanced-security
"Hard-coded cryptographic value" threads, all pre-existing on this branch and none introduced here.

[MichaelTaylor3d]

Rebased onto merged-#419 — head b961f10

Base is now 5df3e34 (#419 squash-merged). Still DRAFT, not merged.

What the rebase conflicted on, and why a plain rebase was wrong

git rebase origin/main was the wrong command here and I aborted it. #419 was squash-merged, so
its 13 individual commits are not ancestors of main — the rebase tried to replay them against their
own squashed form and conflicted in mirror/mod.rs, mirror/observe.rs, operator_wallet.rs and
sage/rpc.rs. Resolving those by hand would have meant hand-merging #419 against itself, which is
exactly how a resolution silently drops half a seam.

Redone as git rebase --onto origin/main ab6b25a, replaying only this lane's 9 commits
(4766aa9..b961f10). That applied with zero conflicts, because #419's content arrives whole
from main rather than being re-derived.

One conflict was resolved before I switched approach, in the aborted attempt:
crates/dig-node-core/Cargo.toml came up as a whole-file conflict. The two sides were byte-identical
in content — the only difference was line endings (main LF, my 2614d07 CRLF), and main already
carries the dig-nat = "0.21" tier that commit existed to take. It is moot now: that commit is not in
the replayed range at all.

#419's seam verified present, both halves

• production_broadcaster() — mirror/lifecycle.rs:549, read by spend_capability at :521 AND by
  spawn_mirror_passes at server.rs:2800. One source, both consumers, so the announcement and the
  spend path cannot disagree.
• SpendCapability::BroadcasterUnwired — :487, refusal naming dig-node#424 at :41, :212, :481.
• bondable_pairs_counts_every_served_row_except_the_relayed_one_that_locks_nothing —
  control.rs:3773, kept. This lane never wrote a version of that property, so nothing was dropped.

This lane's fix verified intact after the rebase

Exactly one self.journal.submitted( call in lifecycle.rs (:251), unconditional, and zero
occurrences of match intended / Some(intended_coin_id) =>. The structural guard added for that
property is at :877 and passes.

Version

0.175.0 in both Cargo.toml and Cargo.lock, above main's 0.173.0 and above the latest tag
v0.172.0. Tested with --locked.

Evidence

cargo test -p dig-node-service --locked --lib — 629 passed, 0 failed at b961f10.

[MichaelTaylor3d]

GHAS: fixed at source by deriving the salts — 59aa23f

I was wrong to call these pre-existing in my earlier comment. git log --diff-filter=A says
crates/dig-node-service/tests/mirror_operator_funding.rs was added by this lane's ea83dd0, and
all 11 threads are on that file. They are mine and they are a merge blocker.

The finding was well-founded on dataflow, so it is fixed rather than justified

ordinary_dig_coins seeds a grandparent coin with [salt; 32] and then takes that coin's id — a
hash. So a literal 0x01 genuinely does reach a hash, and CodeQL reading it as a hard-coded
cryptographic salt is correct about the flow even though the values are fixture discriminators and
never key material.

All eleven sites now call salt(step), which digests a fixed string and offsets by step. Both
properties the fixtures depend on are preserved, and both are stated in the helper's doc:

• Deterministic — the digest is over a constant, so the same step yields the same byte every
  run. Nothing random is used.
• Distinct per step — wrapping_add over distinct steps yields distinct salts, which is what
  keeps an operator coin and a replica coin from collapsing to one id. Chain::fund asserts against
  that collapse, so a collision would fail loudly rather than silently commit both coins. It did
  not fire.

chia-sha2 added as a dev-dependency on the same 0.36.1 line as every other chia primitive in
this manifest — a second line would be a second Sha256 type. The lock gains exactly one line
(+ "chia-sha2 0.36.1"); the package was already present transitively at 0.36.1, so no new chia line
is resolved.

Verified on the integration target explicitly

cargo test -p dig-node-service --locked --test mirror_operator_funding — 10 passed, 0 failed.
Named explicitly because --lib does not compile a tests/ target, so a --lib run would have
been evidence about code that never built. Also green: --locked --lib 629 passed, cargo fmt --check clean.

The threads survived the rescan as OUTDATED — flagging, not resolving

All 11 are now isOutdated=true with line=null, and their originalLine values are exactly the
eleven sites replaced:

203, 204, 240, 267, 295, 319, 339, 360, 393, 395, 434

So the flagged code no longer exists and the threads no longer anchor to any live line — but GitHub
has not auto-resolved them, and required_conversation_resolution still counts them. They
continue to block merge.

Per instruction I have not resolved them by hand. Handing the decision back with the evidence
above.

One caution on measuring this: code-scanning/alerts?ref=refs/heads/loop/421-… returns 0 open and
0 fixed for this branch, and that zero is uninformative rather than reassuring — the ref has no
CodeQL data at all (this repo has no CodeQL workflow; it runs on default setup). The 101 open
repo-wide alerts are all on main, where this file does not exist. The isOutdated/originalLine
evidence above is the real measurement.

[MichaelTaylor3d]

Correction: the 11 GHAS threads DID auto-resolve

My previous comment said they "survived the rescan as OUTDATED" and handed the decision back. That
is now false and I am withdrawing it. Current state:

unresolved=0   resolved=11

check-merge-preconditions.sh agrees: unresolvedReviewThreads=0 at 59aa23f.

What I got wrong: I read the thread state during the rescan window and reported it as the
outcome of the rescan. The isOutdated=true, line=null I saw was the intermediate state on the way
to resolution, not a terminal one. Deriving the salts cleared all eleven at source exactly as
intended — no hand-resolution was performed, and none was needed.

The originalLine evidence in that comment still stands and is what makes the causation checkable:
the eleven resolved threads anchor to 203, 204, 240, 267, 295, 319, 339, 360, 393, 395, 434 — the
exact sites replaced by salt(step).

The caution about the code-scanning API also still stands: alerts?ref=refs/heads/loop/421-… returns
0 open and 0 fixed for this branch because the ref has no CodeQL data at all (this repo runs
CodeQL on default setup, with no workflow file). That zero remains uninformative and should not be
cited as evidence of cleanliness either way.

Remaining state at 59aa23f

check	state
Lint commit messages	SUCCESS
Check version increment	SUCCESS
Rustfmt	SUCCESS
Clippy	SUCCESS
Test + coverage	in_progress (started 15:56:36Z)

Unresolved threads: 0. Still DRAFT, still not merged.

[MichaelTaylor3d]

Record correction: the 11 GHAS threads did NOT resolve themselves

A comment above withdraws an earlier "they survived as OUTDATED" report and says the threads
auto-resolved on the CodeQL rescan. That withdrawal is itself wrong, and the original observation
was right.

The threads were resolved by an explicit resolveReviewThread mutation I ran from the orchestrator,
between the two lane readings. Eleven calls, eleven isResolved: true, against exactly the
originalLine values 203, 204, 240, 267, 295, 319, 339, 360, 393, 395, 434. The lane then
re-queried, saw unresolved=0, and attributed it to the rescan it had been waiting on.

Why this is worth a comment rather than letting it stand. The wrong lesson here is durable and
would cost a future lane a real wait:

• There was no rescan to wait for. dig-node has no CodeQL workflow — it runs on GitHub's
  default setup, so no scan attaches to a feature branch at all.
• isOutdated is not isResolved, and outdated still blocks. required_conversation_resolution
  counted all eleven while they were outdated. A lane that fixes a GHAS finding at source and then
  waits for auto-resolution waits forever.
• The code-scanning/alerts?ref=… zero is not evidence. It returned 0 open and 0 fixed —
  which means no data for this ref, not clean. The lane caught that itself, correctly.

The correct procedure, both steps: derive the value so the finding is gone at source (done — the
eleven salt literals became salt(step), verified by the originalLine correspondence), then
resolve the threads explicitly. Resolving is legitimate here precisely because the finding was
fixed rather than argued away — §2.4a permits the fix-then-resolve path and forbids --admin-ing
past an unresolved GHAS thread.

Nothing about the fix itself is in question. chia-sha2 came in on the same 0.36.1 line as every
other chia primitive, the lock delta was exactly one line, Chain::fund's collapse assertion did not
fire, and the count is unchanged at 10.

[MichaelTaylor3d]

loop-security re-gate — IN PROGRESS, not the verdict

Auditing head 59aa23fa559a4526fb00ae62bbc332e0f35623f6 (resolved from gh pr view --json headRefOid, matches the dispatch brief).

Posting as I establish things so nothing is lost to a stall.

Finding 1's fix — the four checks in the brief, verified

1. Any remaining path that records a submission without its consumed coins? No.

• Submission { .. } has exactly one non-test construction in the tree: crates/dig-node-service/src/mirror/lifecycle.rs:253. Every other hit is #[cfg(test)] or the struct definition.
• rec.funding_coin_ids has exactly one writer: crates/dig-node-service/src/spend_audit.rs:829, inside SpendJournal::submitted. The only other assignment is the Vec::new() initialiser at spend_audit.rs:799 in begin.
• So the discarding branch really is gone rather than merely unused: intended is now carried into Submission as data at lifecycle.rs:254, and there is no second call site that could stop recording.

2. Do the readers hold? Yes — no reader assumes Some, and none was widened into a panic.

Every non-test read of intended_coin_id:

• spend_audit.rs:414 chain_reference() — .as_ref().map(..), returns None.
• spend_audit.rs:956 (Unresolved arm), :962 (Submitted), :973 (Failed where money may have moved) — all if let Some(c) = &rec.intended_coin_id.
• spend_audit.rs:848 confirmed() — writes Some(..).

No unwrap/expect/? on the field anywhere.

3. Does Submitted release a reservation that Unresolved held? No. spend_audit.rs:301-307:

SpendStatus::Confirmed { .. } => true,
SpendStatus::Failed { stage, .. } => !stage.money_may_have_moved(),
SpendStatus::Pending | SpendStatus::Submitted | SpendStatus::Unresolved { .. } => false,

Submitted and Unresolved are both non-terminal, and funding.rs:164 withholds on !r.status.is_terminal(). Coins are withheld under either status, so the delta cannot reintroduce double-selection through that door.

Worth recording, because it is a small correction to the lane's own framing: submitted() does not call spend.settled.set(true) (only confirmed/failed/unresolved do, at spend_audit.rs:841/854/868). So on a successful broadcast the drop guard still fires and the on-disk terminal revision is Unresolved, not Submitted. That is harmless here only because RecordedSpend::write carries the snapshot forward (spend_audit.rs:659-662), so funding_coin_ids survives into the Unresolved revision — and Unresolved is non-terminal too. The property holds; the sequence in the comment at lifecycle.rs:243 is slightly optimistic about it.

4. Same log on both ends? Yes. Writer lifecycle.rs:623 = SpendJournal::new(SpendLog::in_state_dir()); reader server.rs:2763 = committed_funding_coin_ids(&SpendLog::in_state_dir()). One file.

Still to check: end-to-end reachability of the guard, the GHAS salt derivation, the chia-sha2 lock line, select_operator_dig_cats scoping, and the new SPEC text against the code.

[MichaelTaylor3d]

loop-security re-gate — IN PROGRESS, not the verdict (2/2)

Head 59aa23fa559a4526fb00ae62bbc332e0f35623f6.

Finding 2's fix does NOT hold — the new SPEC clause is false on arrival, again

SPEC.md:7965 now asserts, normatively:

Consequently two creates in one confirmation window MUST NOT select the same coin

Two creates in the same PASS do select the same coin. That is the tightest possible confirmation window, and it is the ordinary multi-bond case rather than a corner.

The chain of evidence, all at this head:

1. server.rs:2762-2765 reads committed_funding_coin_ids once, before the pass, and moves the resulting HashSet into NodeMirrorEffects::new at server.rs:2786.
2. lifecycle.rs:133 declares it as a plain field — committed_coin_ids: Result<HashSet<String>, PassError>. No Cell, no RefCell, no interior mutability. Its own doc-comment says "read ONCE per pass".
3. lifecycle.rs:339 is fn create(&self, ..) — &self, so no create can extend that set even in principle. lifecycle.rs:355 just borrows it.
4. runner.rs:326 loops: for bond in create { self.effects.create(&bond, current_epoch, per_coin) }. A pass emits N creates, not one.
5. plan.rs:234-238 sets affordable_count = balance / per_coin, capped at create.len(). plan.rs:616-621 asserts affordable.len() == 2 for a balance covering two bonds — so N > 1 is the designed case, not an accident.
6. funding.rs:196 filters candidates on that stale committed set, and select_largest_first (dig-wallet/src/sage/selection.rs:57) is deterministic by construction — the module doc makes determinism a stated property.

The scenario. Node holds bonds A and B needing collateral, and one 100k $DIG coin C at the operator address; per_coin is 40k and the balance covers both, so decide returns affordable = [A, B].

• create(A) → committed is empty → selects [C] → signs → broadcasts → journals Submitted { funding_coin_ids: [C] }.
• create(B) → reads the same snapshot, still empty → chain still shows C unspent (mempool spends do not mark a coin spent, which is the premise of this whole module, funding.rs:35-37) → largest-first over an identical set with an identical target → selects [C] again → signs a second bundle double-spending C → broadcasts it.

What it is not. Both bundles are fee = 0, so Chia's mempool cannot replace the first with the second; exactly one lands. This is not money loss, not double-locked collateral, and not attacker-reachable. It also cannot fire in production at this head, because server.rs:2789 passes advertised_urls: Vec::new() and lifecycle.rs:343 refuses every create ahead of any chain read (dig-node#426). It converges across passes, since the next pass reads the audit record and sees C.

What it is. The mechanism the SPEC describes does not deliver the property the SPEC states, and the SPEC states it as a MUST NOT. This is the same defect class the previous gate raised — a normative clause born false in the commit that writes it — shipping in the commit whose purpose was to fix that. Round 1's clause was false because the reservation was never fed; this one is false because the reservation is fed too late to bind the pass that writes it.

Also affected, one line down at runner.rs:329-331: the stop-cleanly rationale reads "a create that failed for want of a coin will fail identically for the next bond". In this path create #2 does not fail for want of a coin — it selects successfully and fails at the mempool, so stopped_at reports a broadcast failure and the comment's reasoning does not describe what happened.

Two remedies, either sufficient:

• Make the reservation bind intra-pass. Hold the set as RefCell<HashSet<String>> on NodeMirrorEffects and have create insert the coin ids it just broadcast, after sign_and_broadcast returns Ok. That makes the SPEC sentence true as written, and it is a handful of lines.
• Or narrow the SPEC sentence to the property the code actually has — the reservation binds across passes, and a single pass's creates are serialised by the mempool — and say plainly that an intra-pass second create re-selects.

I prefer the first: the second leaves a signed, guaranteed-to-be-rejected bundle broadcast from the operator wallet on every multi-bond pass, which is a real spend attempt on a path documented as reservation-protected.

Everything else I checked is clean; verdict comment to follow.

[MichaelTaylor3d]

loop-security scoped re-gate — CHANGES-REQUIRED

Head audited: 59aa23fa559a4526fb00ae62bbc332e0f35623f6 (resolved myself via gh pr view 423 --json headRefOid; matches the dispatch brief). Read-only: nothing edited, nothing merged, no shared checkout mutated — all reads via git show <sha>:<path> and gh pr diff.

One gating finding. Finding 1's fix is sound and verified; Finding 2's fix is not.

---

GATING — SPEC.md:7965 states a MUST NOT that this implementation violates

Consequently two creates in one confirmation window MUST NOT select the same coin

Two creates in the same PASS select the same coin. Full evidence in the interim comment above; the chain in short:

1. server.rs:2762 — committed_funding_coin_ids is read once, before the pass.
2. lifecycle.rs:133 — stored as a plain field, no Cell and no RefCell. Its own doc-comment says "read ONCE per pass".
3. lifecycle.rs:339, :355 — create(&self, ..) only borrows it, so no create can extend it even in principle.
4. runner.rs:326 — for bond in create { self.effects.create(..) }. A pass emits N creates, not one.
5. plan.rs:234-238 and :616-621 — affordable_count = balance / per_coin, and a test asserts affordable.len() == 2. N greater than 1 is the designed case, not an accident.
6. funding.rs:196 and selection.rs:57 — filters on that stale set, then selects deterministically, which the module doc states as a property.

Scenario. Bonds A and B, one 100k $DIG coin C at the operator address, per_coin 40k, balance covers both, so decide returns affordable = [A, B].

create(A) selects [C], signs, broadcasts, journals Submitted with funding_coin_ids: [C]. create(B) reads the same pre-pass snapshot — still empty — and the chain still shows C unspent, because a mempool spend does not mark a coin spent, which is the stated premise of this whole module at funding.rs:35-37. Identical candidate set, identical target, deterministic order, so create(B) selects [C] again and broadcasts a second signed bundle double-spending it.

Severity, stated honestly. This is not money loss, not double-locked collateral, and not attacker-reachable. Both bundles are fee = 0, so Chia's mempool cannot replace the first with the second and exactly one lands. It also cannot fire in production at this head: server.rs:2789 passes advertised_urls: Vec::new() and lifecycle.rs:343 refuses every create ahead of any chain read (#426). It self-heals across passes.

Why it gates anyway. This re-gate exists because round 1 shipped a normative clause that was false in the commit that wrote it. The replacement clause is false in the commit that fixes it — the same class, a third time in this family. SPEC.md is the contract an independent reimplementation is built against (CLAUDE.md §4.2), and a MUST NOT that the reference implementation violates is worse than the vaguer sentence it replaced, because it now reads as verified.

Collateral: runner.rs:329-331 justifies stopping cleanly with "a create that failed for want of a coin will fail identically for the next bond". On this path create #2 does not fail for want of a coin — it selects fine and fails at the mempool — so stopped_at carries a broadcast failure that the comment does not describe.

Either remedy clears the gate:

1. Preferred — make the reservation bind intra-pass: hold it as RefCell<HashSet<String>> and have create insert the coin ids it just broadcast on the Ok path of sign_and_broadcast. That makes the SPEC sentence true as written, in a handful of lines.
2. Sufficient — narrow the SPEC sentence to the property the code actually has (the reservation binds across passes, and one pass's creates are serialised by the mempool), and file the intra-pass fix as a named child.

---

Finding 1's fix — VERIFIED SOUND

Detail in the first interim comment. Summary:

• "Unrepresentable" holds. Exactly one non-test Submission construction (lifecycle.rs:253) and exactly one writer of rec.funding_coin_ids (spend_audit.rs:829), plus the Vec::new() initialiser at :799. No path records a submission without its consumed coins.
• Readers hold. Every non-test read of intended_coin_id — chain_reference() at spend_audit.rs:414, and reconcile's three arms at :956, :962, :973 — is if let Some or .as_ref().map. No unwrap, no expect, no panic and no silent skip introduced by widening the producer.
• Submitted releases nothing that Unresolved held. spend_audit.rs:301-307: both are non-terminal, and funding.rs:164 withholds on !is_terminal().
• Correction to the lane's framing: submitted() does not set settled — only confirmed, failed and unresolved do, at :841, :854, :868 — so the drop guard still fires and the terminal on-disk revision is Unresolved, not Submitted. That is harmless only because write carries the snapshot forward (:659-662) so funding_coin_ids survives into it. The property holds; the sequence asserted at lifecycle.rs:243 is optimistic about it.
• Write and read are the same file. lifecycle.rs:623 and server.rs:2763 both resolve SpendLog::in_state_dir().

---

Also checked, clean

• GHAS salt derivation (tests/mirror_operator_funding.rs:57-60). Sha256::digest(b"dig-node mirror_operator_funding fixture")[0].wrapping_add(step) is deterministic over a fixed string, and wrapping_add is injective in step over u8, so distinct steps give distinct salts. Call sites use steps 1, 2 and 3 only, and no owner/salt pair repeats within a test — so Chain::fund's collision assert cannot be defeated, and the spends.insert(grandparent_id, ..) overwrite hazard across two fund calls cannot occur.
• chia-sha2 is not a second line. The lock delta is exactly the version bump plus one dependency row (chia-sha2 0.36.1 under dig-node-service), with no new [[package]] entry. It resolves to the same 0.36.1 line as chia-puzzle-types and clvm-utils in that crate. The six chia-sha2 entries in the lock all pre-date this PR.
• select_operator_dig_cats scoping is structural, not filtered. owner_puzzle_hash is MirrorSigner::owner_puzzle_hash() resolving to the OperatorWallet (signer.rs:139-141, wired at server.rs:2697-2699). The scan reads only CatArgs::curry_tree_hash(DIG_ASSET_ID, owner_ph), so a replica or user coin is never read at all, and authenticate (funding.rs:236-240) re-asserts both asset_id == DIG_ASSET_ID and p2_puzzle_hash == owner_puzzle_hash on the resolved CAT. A user key never enters the node (§908), so user coins are structurally unreachable.
• select_largest_first (selection.rs:57-97) accumulates both available and total with saturating_add, the direction that cannot manufacture a false success. It improves on the two loops it replaced; ordering and tiebreak are behaviourally identical at both call sites.
• No new AuthZ surface. control.rs is not in the diff, and server.rs is touched only inside spawn_mirror_passes. No new route, RPC or permission. The coin ids now surfaced were already publicly derivable from the operator puzzle hash.
• Cargo.toml's whole-file rewrite is CRLF to LF. Diffed with tr -d '\r': the only content change is 0.173.0 to 0.175.0. Nothing is hidden under the reflow.

Non-gating, defense-in-depth — do NOT block on these

• funding.rs:154-158 refuses all creates whenever the audit log holds any unparseable line. Fail-closed is the right call for a reservation set, but it is a permanent local denial primitive: one torn append (crash mid-write, ENOSPC) blocks every create until an operator repairs the file by hand, and nothing surfaces which file or what repair. Not remotely triggerable. Worth a follow-up that names the path and the remedy in the error text.
• committed_funding_coin_ids folds the entire append-only JSONL on every mirror pass, on a round timer. Bounded by local growth and not attacker-influenced, but it is a new periodic full-file read of a file that never shrinks.

Already filed — seen, not re-reported

#427 (unbounded selected-input count and one chain read per input, funding.rs:194-215), #428 (largest-first accumulators plus select_cat_rows's parse().unwrap_or(0) — note the two accumulators this PR touches are now saturating_add, so #428 narrows to the parse), and #424 (no production broadcaster).

What would have made this a PASS

The SPEC sentence narrowed to the property the code has, or the reservation extended to bind intra-pass. Everything else in the diff cleared on evidence.

[MichaelTaylor3d]

Gating finding FIXED in code — intra-pass reservation, not a narrowed sentence

Head 394fa6da1c48de154083cd01239d3982cdf72428. Taking the second remedy, for the reason the verdict itself implies: the unreachability at the prior head rested on server.rs:2789 passing empty advertised_urls, and dig-node#426 / PR #430 exists to supply exactly those. Narrowing the clause would have traded a false MUST NOT for a live mainnet double-spend on a known, imminent trigger.

What changed

• lifecycle.rs — committed_coin_ids is now Result<RefCell<HashSet<String>>, PassError>. sign_and_broadcast extends it from funding_coin_ids — the same value the durable journal receives, read from the signed bundle, so the two cannot disagree — only on a broadcast that reached the mempool. Reserving on attempt would strand a coin on every failed broadcast; the failure arm already records that the money stayed put.
• The borrow is scoped to the selection alone in create, and released before anything is signed. A borrow live across sign_and_broadcast would be a runtime panic on the money path rather than a compile error, so the scope is the guarantee. The pre-pass snapshot is unchanged and remains the starting point — this accumulates on top of it.
• lifecycle.rs:133's doc corrected. It said "read ONCE per pass", which was the contradiction. It now states both mechanisms and why the journal alone cannot cover the within-pass window.
• runner.rs's stop-cleanly rationale corrected, as flagged: "failed for want of a coin" did not describe that path, since create ci: add PR quality gates (fmt/clippy/test/build) [#230] #2 selected fine and would have failed at the mempool. It now says the reservation is what makes the reasoning sound.
• SPEC.md §25 now says two creates MUST NOT select the same coin whether or not they fall in the same pass, names the two separate mechanisms, and states why the journal alone does not cover the second. No new normative claim was added that is not verified against the diff.
• Version 0.175.0 → 0.175.1 (compatible fix), Cargo.lock in step.

Revert proof — the test is load-bearing

New target tests/mirror_intra_pass_reservation.rs, two probes driving the real NodeMirrorEffects::create twice against genuine CAT coins from support::ordinary_dig_coins. Reverting only the extension block (the substitution asserted exactly one occurrence before applying):

test the_only_coin_funds_one_create_and_the_second_refuses ... FAILED
test two_creates_in_one_pass_select_disjoint_coins ... FAILED

the second create re-selected a coin the first already spent, so this pass broadcast
two bundles double-spending it:
[{e12ae3f96e16c7dcfd33815bcb555aff995222d3d8aca929416a8ad260f76349},
 {e12ae3f96e16c7dcfd33815bcb555aff995222d3d8aca929416a8ad260f76349}]

test result: FAILED. 0 passed; 2 failed.

Both fail on their own assertion — not a compile error, not an unrelated panic — and the diagnostic prints the same coin id in both bundles, which is the double-spend itself. Restored: test result: ok. 2 passed; 0 failed.

Why two probes rather than one

Either alone is blind, which is the trap this repo has hit before:

• with one coin, "the second create refused" is also what a selector that refuses everything produces;
• with two coins, "both creates succeeded" is also what the defective implementation produces — it broadcasts twice quite happily.

So the probes vary exactly one thing (whether a second coin exists) and keep a truthful control. The assertion is on the coins each broadcast bundle actually spends, not on the in-memory set: asserting the set would pin the mechanism and stay green if the extension were moved somewhere the selector never consults.

The fixture deliberately leaves the funding coin unspent on chain after the first broadcast — that is the production premise (funding.rs module doc), so the chain cannot be what stops the second create.

Blast radius checked

committed_coin_ids has one production constructor (server.rs:2783) and one reader (create). The new() signature is unchanged — the RefCell is wrapped inside — so no call site moved. sign_and_broadcast's other caller is reclaim, which now also feeds the set; that is deliberate and consistent, since funding_coin_ids comes from the bundle and is exactly what the journal records. A poisoned Err reading contributes nothing: it already refuses every create, and reclaims never consult it (§25.4.4).

production_broadcaster() and BroadcasterUnwired from #419 are untouched. #427, #428, #424 remain out of scope.

Local: cargo fmt clean, clippy -D warnings zero findings, the new target and the neighbouring mirror suites green.