diff --git a/docs/plans/counter-asic-3-status.md b/docs/plans/counter-asic-3-status.md
index 48eab90a..da1d22f2 100644
--- a/docs/plans/counter-asic-3-status.md
+++ b/docs/plans/counter-asic-3-status.md
@@ -371,7 +371,7 @@ Packs zip (eight packs, packs-ca3-v4-sub2) sha256 69c36772cd79e44e2ddd589466d9c6
 
 AP-F8-2 FIXED (the hash lane, ca3-v4-amend 8bdcbdd8, 13:31:10Z, origin and build, gate GREEN): sub-version number unchanged at 2 because the stream is unchanged for every non-exhausting seed (re-export diff 0 on v4-devnet-epoch0, v4-era-0 and v4-era-5; the id a788661687db4bb3 and the seven fingerprints stand; the packs zip sha256 69c36772... holds), so the attack-pass census at 13 of 64 continues on it. The route: the deterministic repair would have rewritten every seed whose attempt 0 fails (a'), about two thirds of seeds, a new stream and a restarted census against the 19:00Z line, so the second route main allowed was taken. The bound: MAX_ATTEMPTS_V4 = 256 for the class v4 shape (v2 and v3 keep 32, keyed on the shape); at the measured rejection rate of about two thirds per attempt, 32 attempts exhaust at about 2e-6 per epoch seed (one undrawable epoch every few decades at one an hour), 256 at under 1e-45, the worst-case draw about half a second on one core. After the cap the draw is total: the seed takes the last-resort program, deterministic and accepted as drawn, the candidate at attempt 256 with every or, mul and mulhi of the base program and the shadow block rewritten to xor, so every register stays fresh from the init words on and (a') holds by construction; no consensus path panics for the v4 shape. The test class_v4_draw_is_total_with_the_last_resort (the last resort on real (a')-rejected candidates, every load fresh after it, no lossy op left, the chain path over 64 seeds without a panic, the cap per class asserted) green on the Mac, the box-2 suite running; the hash lane's 4,096-seed census with the attempt histogram on box 2; the attack-pass lane's 10^6 count is the control; the string with the attack-pass lane with seed igneum-f9/331672 named. CI: 526fa757 success; 8bdcbdd8 queued. The spec and ledger text for the bound and the probability in the ledger entry. The PC 1 variant and fetch job carry 8bdcbdd8's packs (byte-identical to 07a809a7's); the PC 2 kit published at 13:04Z is the same packs. Per tier: a miner never sees the draw (the node draws once an hour, half a second at worst); a chip maker gains nothing from the last resort (a 1e-45 event); the auditor reads the bound and its probability in the spec. SUITE LINE AT 8bdcbdd8: box 2, route line "13:31:21 build-remote: box 2 (build@142.132.249.238) for class suite, priority normal", rc 0, 80 s, 62 lib + 7 derive + 4 mixer + 19 packs + 2 recheck + 7 scratch = 101 passed, 0 failed, the total-draw test included; ledger entry 32e96c9a; CI on 526fa757 success, the newest push's run queued and owned by the hash lane.
 
-THE 12 GB SETTLED-CLAIM LINE ON c4459193 (the fleet lane, 13:27Z): the floor reads right and the card proves, THE NODE REFUSES. p12-vast on c4459193 (sha 45be9b02, string read back) synced 13:22:47Z on the kept copy; first claim 13:23:01Z "segment 164198..164205 (8 shards, fresh) margin=414 tip=287564 settledNumber=0x28185 settledDaa=0x46317 settledBy=finality candidates=5"; proof complete 13:25:19Z on the 3060 (8 of 8 shards, 135.9 s, peak 8,487 MiB); submission refused "statement differs from the node's at hex offset 472 (lengths 616 vs 616); ours ...2b1a81cb413236cf... node ...0000". The node's start line on this binary reads "proving v1: ... shard program id unknown, aggregator id unknown" where 5899f603 on the same override file reads the ids; the statement is built with zeros and every proof fails its check. This blocks the paid line on any card and, after the sweep, every standing prover; with the node lane (the fix) and the shipper (the cut) since 13:27Z; the pod and proof files held for the node lane's read. The cut set is therefore NOT complete on c4459193. THE CAUSE (the node lane, 13:4xZ): no commit on the line lost the ids and the binary is not the difference; on every build including 5899f603 the statement's ids come from the override object's two fields (absent on the live sixteen-field file), else IGNEUM_PROOF_PROGRAM_IDS, else the verifier host's --mode id when IGNEUM_PROOF_VERIFIER is set. hub-1 runs with IGNEUM_PROOF_VERIFIER=/opt/igneum-floor/bin/igneum-prove-host in its process environment, so the host hands it the ids; the pod's c4459193 node was started bare for the kept-datadir read, so program_ids answered None and the statement carried zeros; a bare 5899f603 reads "unknown" too. The start environment, not the binary. What the child commit fixes anyway: the binary embeds the verifying keys it verifies carried proofs with, so it knows the ids it expects; the child resolves them in that order and last from the embedded keys, with a test whose known-failed shape is the bare node's None and the zero-id statement; the diff two files (resolve_program_ids in igneum/exec/src/proving.rs and its call in kaspad/src/daemon.rs; nothing in acceptance, the version check, relay or peer handling); its exec suite running, the string and sha256 about 13:52Z. Gate carry: the digest and mixed-version gates are outside the diff's territory and carry from c4459193, but rule 4a runs every gate on every candidate from its build, so both run again on the child's binary and the fleet's set with them; the re-run that bears on the diff is the 12 GB line itself, the pod's already-proved claim submitted against a node that names the ids. Per tier: a solo miner on a bare node never proves, so feels nothing; a standing prover beside hub-1's environment was never affected; a prover on a bare node could not be paid on any build until the child. THE CONTROL (the fleet lane, p12-vast): the same c4459193 (sha256 45be9b02d1b002f5, string read back) on the same kept copy, killed and restarted 13:30:28Z with IGNEUM_PROOF_VERIFIER=/opt/igneum-floor/bin-0317/igneum-prove-host (sha 71bc2438) and HOME on the floor: the start line reads "proving v1: ... shard program id 0x2b1a81cb413236cf..., aggregator id 0x474678f3...", no panic, synced 13:31:49Z (155,725 blocks, 4 peers); the bare start of the same binary on the same copy at 12:36:11Z read "unknown". The ids are the start environment on the pinned build, not the binary. The submission verdict against the ids-naming node: the prover restarted 13:31:56Z and claims fresh (the 13:23Z proof held as evidence, past its margin), the first chain proof about 2.5 minutes on the 3060, the verdict line about 13:36Z; the bare-child line runs the minute the child's string and sha land (about 13:52Z). THE CONTROL'S VERDICT (13:33:56Z): against c4459193 restarted with the verifier set, the 3060's first proof "RESULT seg 164286 chain ... 8 shard records, chain_len 8, proof 1272909 bytes, shards 44.9 s, aggregation 39.7 s, wall 110.6 s, peak 8423 MiB", "shards accepted 8 of 8", no "FAILED: statement": the statement check passes, so the zero-id refusal at 13:25Z was the bare start's environment and nothing in the binary, the pin included. The submission then read "segment_refused ... segment already paid; end to end 113.1 s": the claim race (a 24 GB box proved the same fresh segment inside the 3060's 113 s, the shape of p2-4070-1 this morning); the settled floor does not reserve a claim per key, so a 12 GB prover on the open devnet wins only when no faster box picks its segment; the prover runs on (claim 164342..164349, settledNumber 0x28208 by finality, margin 470) and the paid line goes out the minute a race is won, minutes to tens of minutes of races, not the floor. Per tier: a 12 GB card proves and verifies on the pin; whether it is paid on the open devnet is the race against bigger cards, which is the settled floor's design today and a question for the claim rule, not this cut. THE LATE-JOIN COMMIT (N9's second half, the node lane): 70e4601e on the box mirror as branch proof-hold-fix, from c4459193, two files (igneum/exec/src/proving.rs, protocol/flows/src/v10/proving.rs); the gap was the fetch side on the joiner (the served record ran the native check against the joiner's trailing exec state before anything was stored, the check refused it, the proof was never held, the body rule read "not held" for 20 s and failed the IBD); the fix holds the proof by hash before the checks (the pool entry still needs them) and the serve side says when it holds fewer than asked; the exec suite 32 passed at 13:26Z with the known-failed shape first, the flows check green 13:28Z, igneumd on build-1 at the 0321 worktree path built 13:32Z, sha256 17649eeb2f7d1290, string read back; with the testnet lane (the resume form, B alone); it joins the 0.3.21 staging as its own commit. THE INTEROP FACT stands from the void run: the 5899f603 hub accepted 235 object-byte-5 blocks from the 8097d600 node with 0 rejected, one digest on all five nodes on the live sixteen-field file. The gates: the digest test and the kaspa-pow vector test (the amended devnet epoch-0 id 1a4230699a6b9c60 must equal, c120d7963abdcd96 must differ, the v3 control unchanged) on the box; the mixed-version Devnet 2 gate (the amended 0.3.20 node beside a 5899f603 node for ten minutes on the live file without the v4 fields) after the Mac build; the fresh-join canary the 0.3.20 cut's |
+THE 12 GB SETTLED-CLAIM LINE ON c4459193 (the fleet lane, 13:27Z): the floor reads right and the card proves, THE NODE REFUSES. p12-vast on c4459193 (sha 45be9b02, string read back) synced 13:22:47Z on the kept copy; first claim 13:23:01Z "segment 164198..164205 (8 shards, fresh) margin=414 tip=287564 settledNumber=0x28185 settledDaa=0x46317 settledBy=finality candidates=5"; proof complete 13:25:19Z on the 3060 (8 of 8 shards, 135.9 s, peak 8,487 MiB); submission refused "statement differs from the node's at hex offset 472 (lengths 616 vs 616); ours ...2b1a81cb413236cf... node ...0000". The node's start line on this binary reads "proving v1: ... shard program id unknown, aggregator id unknown" where 5899f603 on the same override file reads the ids; the statement is built with zeros and every proof fails its check. This blocks the paid line on any card and, after the sweep, every standing prover; with the node lane (the fix) and the shipper (the cut) since 13:27Z; the pod and proof files held for the node lane's read. The cut set is therefore NOT complete on c4459193. THE CAUSE (the node lane, 13:4xZ): no commit on the line lost the ids and the binary is not the difference; on every build including 5899f603 the statement's ids come from the override object's two fields (absent on the live sixteen-field file), else IGNEUM_PROOF_PROGRAM_IDS, else the verifier host's --mode id when IGNEUM_PROOF_VERIFIER is set. hub-1 runs with IGNEUM_PROOF_VERIFIER=/opt/igneum-floor/bin/igneum-prove-host in its process environment, so the host hands it the ids; the pod's c4459193 node was started bare for the kept-datadir read, so program_ids answered None and the statement carried zeros; a bare 5899f603 reads "unknown" too. The start environment, not the binary. What the child commit fixes anyway: the binary embeds the verifying keys it verifies carried proofs with, so it knows the ids it expects; the child resolves them in that order and last from the embedded keys, with a test whose known-failed shape is the bare node's None and the zero-id statement; the diff two files (resolve_program_ids in igneum/exec/src/proving.rs and its call in kaspad/src/daemon.rs; nothing in acceptance, the version check, relay or peer handling); its exec suite running, the string and sha256 about 13:52Z. Gate carry: the digest and mixed-version gates are outside the diff's territory and carry from c4459193, but rule 4a runs every gate on every candidate from its build, so both run again on the child's binary and the fleet's set with them; the re-run that bears on the diff is the 12 GB line itself, the pod's already-proved claim submitted against a node that names the ids. Per tier: a solo miner on a bare node never proves, so feels nothing; a standing prover beside hub-1's environment was never affected; a prover on a bare node could not be paid on any build until the child. THE CONTROL (the fleet lane, p12-vast): the same c4459193 (sha256 45be9b02d1b002f5, string read back) on the same kept copy, killed and restarted 13:30:28Z with IGNEUM_PROOF_VERIFIER=/opt/igneum-floor/bin-0317/igneum-prove-host (sha 71bc2438) and HOME on the floor: the start line reads "proving v1: ... shard program id 0x2b1a81cb413236cf..., aggregator id 0x474678f3...", no panic, synced 13:31:49Z (155,725 blocks, 4 peers); the bare start of the same binary on the same copy at 12:36:11Z read "unknown". The ids are the start environment on the pinned build, not the binary. The submission verdict against the ids-naming node: the prover restarted 13:31:56Z and claims fresh (the 13:23Z proof held as evidence, past its margin), the first chain proof about 2.5 minutes on the 3060, the verdict line about 13:36Z; the bare-child line runs the minute the child's string and sha land (about 13:52Z). THE CONTROL'S VERDICT (13:33:56Z): against c4459193 restarted with the verifier set, the 3060's first proof "RESULT seg 164286 chain ... 8 shard records, chain_len 8, proof 1272909 bytes, shards 44.9 s, aggregation 39.7 s, wall 110.6 s, peak 8423 MiB", "shards accepted 8 of 8", no "FAILED: statement": the statement check passes, so the zero-id refusal at 13:25Z was the bare start's environment and nothing in the binary, the pin included. The submission then read "segment_refused ... segment already paid; end to end 113.1 s": the claim race (a 24 GB box proved the same fresh segment inside the 3060's 113 s, the shape of p2-4070-1 this morning); the settled floor does not reserve a claim per key, so a 12 GB prover on the open devnet wins only when no faster box picks its segment; the prover runs on (claim 164342..164349, settledNumber 0x28208 by finality, margin 470) and the paid line goes out the minute a race is won, minutes to tens of minutes of races, not the floor. Per tier: a 12 GB card proves and verifies on the pin; whether it is paid on the open devnet is the race against bigger cards, which is the settled floor's design today and a question for the claim rule, not this cut. THE PROVING-IDS CHILD: 55768f88 on release-0.3.20-node (c4459193's child; resolve_program_ids reads the override's fields, then the env or the host, then the embedded verifying keys; one call in the daemon), pairing igneum-pow 8c728ca3 at byte 5; the exec suite 32 passed at 13:29Z with a_bare_node_resolves_its_program_ids_from_the_embedded_keys (known failed first: the bare node's None and the zero-id statement), kaspad check green 13:33Z; igneumd and igneum-miner built on build-1 at 13:35Z, sha256 279b1b690e854fc9, the string read back; the node lane's digest and mixed-version gates on it from 13:37Z (lines about 13:52Z); the fleet has the path, sha and string for its full set from the same minute; ledger N14 on ca3-v4-node. THE PIN CANDIDATE IS 55768f88. THE LATE-JOIN COMMIT (N9's second half, the node lane): 70e4601e on the box mirror as branch proof-hold-fix, from c4459193, two files (igneum/exec/src/proving.rs, protocol/flows/src/v10/proving.rs); the gap was the fetch side on the joiner (the served record ran the native check against the joiner's trailing exec state before anything was stored, the check refused it, the proof was never held, the body rule read "not held" for 20 s and failed the IBD); the fix holds the proof by hash before the checks (the pool entry still needs them) and the serve side says when it holds fewer than asked; the exec suite 32 passed at 13:26Z with the known-failed shape first, the flows check green 13:28Z, igneumd on build-1 at the 0321 worktree path built 13:32Z, sha256 17649eeb2f7d1290, string read back; with the testnet lane (the resume form, B alone); it joins the 0.3.21 staging as its own commit. THE INTEROP FACT stands from the void run: the 5899f603 hub accepted 235 object-byte-5 blocks from the 8097d600 node with 0 rejected, one digest on all five nodes on the live sixteen-field file. The gates: the digest test and the kaspa-pow vector test (the amended devnet epoch-0 id 1a4230699a6b9c60 must equal, c120d7963abdcd96 must differ, the v3 control unchanged) on the box; the mixed-version Devnet 2 gate (the amended 0.3.20 node beside a 5899f603 node for ten minutes on the live file without the v4 fields) after the Mac build; the fresh-join canary the 0.3.20 cut's |
 | Main's rulings (7 October, morning) | no generator change to v4 on the live devnet; the record's null is the window model with numbers, sent by the hash lane to the attack-pass lane so AP-F8-1 re-gates against it; a fault beyond the model (a low-entropy source at site 15) stops at the coordinator with the two options priced (a 0.3.19 class amendment before the flip, or the flip held at the floor), nothing shipping without the project lead's word; the tighter tail, an acceptance bound on the hot-set share, is a CLASS V5 item (sent to the v5 lane a6410f3b8abefb762 with the 64-seed census as its gate; the bound's number follows from the model) |
 
 ### AP-F4-1, the weak-day MUL draw (the attack-pass lane, 7 October, morning): PASS against v4, a class v5 rule