igneum/docs/plans/counter-asic-3-gate/node-gates.md

# Counter ASIC 3.0: the node-side gates for class v4 (`mx8+sh256x27`)

6 October 2026, worker "ca3-v4-node". The rows in the shape of `docs/plans/counter-asic-2-rollout.md` section 7. Trees: main `ca3-v4-node` a522d04 (igneum-pow, the workers, the harness, on ca3-coord 3213ee9), fork `ca3-v4-node` 5f7e0543 (on release-0.3.13-node bb43e9a8, the current release tip, which contains release-0.3.12-node). Builds: the Mac built igneumd and igneum-miner (`target-ca3v4/release`, `--features kaspad/igneum-pow`, warm from an APFS clone of the 0.3.13 target dir, under `with-lock.sh build`, nice 19, 4 jobs) and `igneum-bench` (the Metal worker, `swiftc -O`); the suites went to PC 2. The Mac's installed app was not touched (its miner stays paused); nothing was published; the live devnet was not touched. The Mac's load average during the runs: 5 to 12 (other agents' builds); the gates here count blocks, lines and ids, not rates, so the load does not move them.

| # | Gate | Evidence required | State |
|---|---|---|---|
| G4 | the fast-time 3-node network mining across a v4 activation | 0 rejected blocks, 0 forks, every node's first lines show the switch, blocks on both sides of the boundary; the gate fires on one finished and one failed case | GREEN. Run 1 (15:54:32 to 15:59:21Z, `node infra/fast-time/class-v4.mjs --secs 420 --activation 150 --v3-activation 60 --epochs-after 2` under `with-lock.sh run`; three nodes, one real CPU miner each with `--engine igneum-pow`, every node verifying the other two): 3 of 3 nodes print both switch lines (`Program class v4 from the override file: active from epoch 3 (DAA score 150 rounded up to the epoch boundary at 180, epochs of 60 DAA)` and the v3 line for epoch 1 at DAA 60); templates class 2 for epoch 0, class 3 for epochs 1 and 2, class 4 for epochs 3 to 5; the switch seen at DAA 180, 163.9 s wall; 181 blocks before and 128 after DAA 180 (309 in all, selected chain 177 / 127); program ids agree on all three miners (e0 v2 `8f8806638d59850f`, the same v2 id as 2.0's three runs; e1 v3 `29ced0d031cc121b`, e2 v3 `341fd4076256cd7b`, e3 v4 `070ca0f94e7f8f88`, e4 v4 `b8cbe1ef7ab1d748`, e5 v4 `9321cbd9c54c0b83`; no v2 or v3 id reappears under v4); rejected 0/0/0 on the miners and 0/0/0 on the nodes (103, 103, 102 accepted); one sink `4da9ac669effdfab` on all three at 308/308/308 blocks, one tip each; digest `59a3eb5383bfbf23...` on all three; program and cache ready on one core: v2 epoch 0 199 ms, the first v3 epoch 187 ms (its own day cache), the first v4 epoch 2 ms (the v3 day cache reused across the N5 boundary, no rebuild). Summary `class-v4-20261006-1553Z-cpu.json`. Run 2, the known-failed case (15:59:46 to 16:02:17Z, `--activation never --v3-activation 60 --secs 150`): every node prints `Program class v4 from the override file: never`; the harness reports `SUMMARY FAIL: NO v4 epoch seen` with five checks down (`v4_switch_line_names_the_rounded_epoch`, `template_switched_at_the_first_v4_epoch`, `blocks_after_the_boundary`, `v3_and_v4_programs_seen`, `program_ids_differ_across_the_switch`), exit 1; the v3 side of that run was clean (epochs 0 v2, 1 and 2 v3; 0 rejected; one sink 166/166/166). Summary `class-v4-20261006-never-failed-case.json`. Re-run on the program-id fix 7c22d0d (16:32:39 to 16:38:08Z, igneumd and igneum-miner rebuilt on the fixed igneum-pow, the harness with the id assertion; load average about 90 from other agents' builds, which moves the wall times, not the counts): PASS, every check true; 3 of 3 v4 and v3 switch lines; 181 / 125 blocks across DAA 180 (305, selected chain 168 / 120); rejected 0/0/0 and 0/0/0; one sink `b7881306c83b1206` at 305/305/305; the PROGRAM ID rows, one per v4 epoch, the three miners' id against the CLI's same-seed, same-era class v4 and class v3 ids (`igneum-pow show --epoch-hex <seed> --program-class v3|v4 --era-hex <era>`): e3 seed `bd597eca...` miners `30544487d1289d6e` (3 of 3) = cli v4 `30544487d1289d6e`, cli v3 `1ae1c9f0eda0cef5`; e4 `782b6b0d...` miners `53e36801cc6fafcf` = cli v4, cli v3 `af81f6e844959460`; e5 `2d307b52...` miners `876e155e3fb59983` = cli v4, cli v3 `b4f25c4678496a78`: every v4 id equals the chain's class v4 id and differs from the v3 id of the same seed and era. Summary `class-v4-20261006-id-rerun.json`. The assertion's known-failed case (`--id-check-against v4`, 16:38 to 16:43:05Z): the same network shape PASSES every other check (181 / 121 blocks, 0 rejected, one sink 301/301/301, the three PROGRAM ID rows OK) and the harness reports `SUMMARY FAIL` with exactly `FAILED CHECK v4_ids_differ_from_the_same_seed_v3_id`, exit 1. Summary `class-v4-20261006-id-failed-case.json` |
| G4b | the Mac mines v4: a real Metal miner across a v4 boundary through the miner's `--prepare-packs` flow, and the app passes that flag to the Metal worker | the prepare lines on both sides, the worker's `prepared` line for the v4 pack, found or accepted blocks on v4, no `need` or mismatch line, no exit 42 or 44; the app's `miner_args` pushes `--prepare-packs` for every worker | GREEN. Run 3 (16:02:37 to 16:07:58Z, `--metal proto-metal/igneum-bench --genesis-bits 0x1e010000 --secs 480 --activation 150 --v3-activation 60`; node 0's miner is `igneum-miner --worker igneum-bench --prepare-packs <dir> --exit-on-seed-change`, the app's own shape; `igneum-bench` built from this tree at a522d04's `main.swift`, sha256 30c70754...; CPU miners on nodes 1 and 2): 5 PREPARE lines, each 5 to 6 DAA before its boundary, two `class v3` (DAA 60, 120) and three `class v4` with the pack directory and `class=v4 era=<hex>` (DAA 180, 240, 300); the worker's `prepared` lines for the three v4 packs: `prepared ca4245b5... 430.2 program 193.9 dataset 236.2 race 0.0 variant base class v4 loads/hash 128 cache-fill 1.4 build 70.1` (the first, the v4 day built from the pack's memhard.metal on the GPU: 1.4 ms cache fill, 70.1 ms build), then 138.6 and 175.3 ms with the day resident (program compile alone, the 256-instruction shadow block in the kernel text; a v3 prepare was 61.7 ms); every swap `swapped with no pause` at DAA 60, 120, 180, 240, 300 (prepared 2 to 5 s earlier); 301 blocks accepted by the Metal miner, 123 after the switch, every one re-checked on the CPU: `mismatched=0`; `need` 0; no class or era mismatch line, no `PACK OUT OF DATE`, no prepare-failed, no exit 42 or 44 (0 such lines in the miner's log); the chain 182 / 122 blocks across DAA 180 (304), rejected 0/0/0 and 0/0/0, one sink `4e1aa3fbf1f4a54b` on all three at 303/303/303, 3 of 3 v4 switch lines; program ids e3 v4 `2bcecca6f867c3b5`, e4 `21b78e63fc0e9251`, e5 `3855570a5ba12fc9` agreed by the Metal miner and the CPU miners; the Metal miner's STATUS at 309 s: 18.58 MH/s wall, 293 accepted, 0 rejected (a rate under a load average of 5 to 12 with the CPU miners and other agents' builds beside it: an order of magnitude, not a measurement). The app side: `app/igneum-app/src/engine.rs` `miner_args` pushes `--prepare-packs` for every worker (line 1478, the 0.3.11 fix; unit test `every_worker_gets_the_prepare_directory_in_the_platform_form`), confirmed unchanged on ca3-coord 3213ee9. Summary `class-v4-20261006-metal.json` |
| G5 | the PC-built Windows workers and the Mac workers from the same commit | every sha256 listed; the two Windows workers carry the resource block; no packaging, no DMG, no manifest | GREEN on the program-id fix 7c22d0d (packfile.h and main.swift moved, so the workers were rebuilt from it; the earlier pair from a522d04 is superseded): igneum-worker-cuda.exe 3bc8ad8f69ad97d6a9491a734ef16e3cf10b3884d442fb1e5a490c751ae578c5 (1,536,512 bytes), igneum-worker-opencl.exe 16ef015470d7a45c5af5488dcc68a29c5e95f94487eb05e26f1bf418e6dd511f (478,208), `verify-exe.py`: both carry the coin icon and the version block; the Mac worker igneum-bench f9ca4b075a9a9c25afd8feeccd1339fbb6bb4c3728ffeddab9f549cd3c1725a4 (665,128, the binary of the G4 re-run); the node and app binaries of job build-20261006-155958 stand (the fork did not change). The a522d04 row for the record: the build job builds the node and the app only (`push-build-inputs.sh` writes two build units, `jobbuild.rs` has no worker unit), so the Windows workers were cross-built on the Mac from the committed tree a522d04 with `proto-cuda/nvrtc/build-windows.sh` under the build lock (mingw-w64, static, windres resource block), as 0.3.11's G5 row was: igneum-worker-cuda.exe e563126ed1d8ab8f6803ead89acca5b6fcb03203e6b87b70e0aec85e8e1046e4 (1,536,512 bytes), igneum-worker-opencl.exe 7fce1249d443aaf73a29b7474c1ef4084f3529b5bec3a2dc6bb97e624561a5e8 (478,208), `verify-exe.py`: both carry the coin icon and the version block (a first build of the same sources before the commit gave 26400edf... and 438e608a...: mingw stamps a link time, so the pair is not bit-reproducible; the sizes match the 0.3.11 pair, 1,536,512 and 478,208, and the sha256s differ from 0.3.11's 2b3b8c92... and edc4a75d...: the generator-4 rule is in them). The Mac worker from the same tree: igneum-bench 30c70754097dafbc3144a0c0f192526a0638089e5dde49ce46abb7a948dceade (665,128 bytes, built 16:47Z from `main.swift` as committed in a522d04, the binary G4b mined with). The same build job's (build-20261006-155958) node and app outputs from fork 5f7e0543, every sha256 verified against the PC's lines on fetch: igneumd.exe 140be25e486fe1634500b6e66eedfaca9fa6561d652f3e219b5a7a2bc377e766 (51,752,448), igneum-miner.exe ceb1e691ad57f58d09d5a0ff4cb5658aea0604d23ceb90b6a847a2c36a0bf81c (11,118,080), igneum-app.exe bfa3b871f17b69fd0c0c01a6f9fcac8964efb54dc10fd25db13422ba8f96d51f (3,065,344, PE and resource block ok); Linux igneumd d44b735869b129401d68f18786b4a5f16c22d00b682bd41a8e5022a01f7d7527 (49,603,112), igneum-miner a7985111d4972f4b67a9409b831a8c7af746508ebb3b19fc927aaddcfa2e2413, igneum-app 222f30c00bb9725f3127452f3d52403b380e25abaf9fba5c925839574cf1dabc; kept under the job's --out dir with --no-place. No packaging, no DMG, no manifest |
| G6 | the node change on a fork branch from the current release tip with suites green on PC 2, with the igneum-pow feature | the build job id and its SUMMARY line; the v4 engine test named in the output | GREEN. PC 2 job `build-20261006-155958` (fork ca3-v4-node 5f7e0543, main a522d04; published 15:59:58Z after the clear file and under the mkdir lock, taken 15:58:50Z, released 16:08:06Z after the closing report; the installed app untouched, the prover left on), `node tools/build-job.mjs run --target 1ccfe586 --node vendor/igneum-node-ca3v4 --node-tests "kaspa-consensus kaspa-consensus-core igneum-exec kaspa-pow igneum-miner kaspa-p2p-flows" --app-tests igneum-app --no-place`: `done exit 0 after 392 s: node ca3-v4-node 5f7e0543 app 0.3.11: every stage ok; 9 files uploaded (46 MB); 6 min of 40`; the test stage 50 s, exit 0 on both units: kaspa-consensus 98 passed (3 ignored; `ban_is_decided_by_the_carrying_block_so_nodes_agree_on_every_voter_list ... ok`, so 2.0's flake did not recur and no re-run was needed), kaspa-consensus-core 109 + 7 (`override_params_carry_the_program_class_v4_activation ... ok`), igneum-exec (its per-crate line is not in the relay's upload of the report, which keeps the stage's tail; the unit exited 0, so it passed), kaspa-pow 15 (`program_class_v3_seeds_hash_their_own_program_over_their_own_cache ... ok` and `program_class_v4_seeds_hash_the_shadow_program_over_the_v3_day_cache ... ok`, both `#[cfg(feature = "igneum-pow")]`), igneum-miner (the same: not in the upload, in the exit-0 unit), kaspa-p2p-flows 33, igneum-app 112 + 26 + 8. The feature: `build-job.mjs` and `push-build-inputs.sh` carry no `--features` for the test units (the manifest's `tests` entries are `dir` and `packages` only; the build units have `kaspad/igneum-pow`), and the PC's `jobbuild.rs` runs `cargo test --release -p ... ` in ONE invocation per unit, where `igneum-miner` depends on `kaspa-pow` with `features = ["igneum-pow"]`, so cargo's feature unification turns the feature on for kaspa-pow's test target in that invocation: the two engine tests above ran on PC 2 with the feature, named in the report, which is the evidence main asked for. The same two suites also pass on the Mac with the flag explicit (`cargo test --release -p kaspa-pow --features igneum-pow`: 15; `-p kaspa-consensus-core`: 109 + 7). What the tool lacks: a `features` key on a test unit; not added here (a change to the PC's installed app would be needed to honour it) |

## The cut preconditions (the coordinator's second brief, 6 October 2026 evening)

| # | Gate | Evidence required | State |
|---|---|---|---|
| P1 | the rehearsal plan and the v4 override object for the rented fleet | `docs/plans/counter-asic-3-rehearsal.md`; the objects with their digests | WRITTEN (not run: the fleet agent runs it): the publish object (the live 13 fields plus the floor `N6` and the window 86,400; digest on the devnet network id `65a42ab2e63d93ac02acf761b411b31acac6c9413bbd0c6a2f4cced10509efdf` at the worked example N6 = 219,600, fork 0562a7f2), the rehearsal object (every earlier switch at 0, window 3,600, floor 14,400; digest on suffix 400 `aef46983dfd121d5ecbefd056ff02d001b89315bd0547b4e1007b0b0ee7eee2c`) and the re-cut for the hour (600-DAA epochs, window 600, floor 2,400; digest on suffix 400 `a15db4f0d6a5cc891582760ef5593e69014a5133261def84647cb7617528764f`, the value the 16 fleet boxes printed); CORRECTED 18:4xZ: the digest folds the network id in, and the first values (`ac8e60ce`, `bc2142b1`, `d23394e7`) were read on throwaway suffixes; CORRECTED 18:5xZ: the rehearsal chain inherits the devnet's genesis bits (the object sets none; the fast-time harness lowers them), so its miners are the GPU workers, not 1-thread CPU miners (the fleet's 16 CPU miners at about 80 kH/s against about 2^27 hashes a block held the height at 0 for 20 minutes); the id assertion on a worker box reads the id from the exported pack's program.h (the `program pack checked ... <dir>` line names it), the Mac side unchanged; `override-v4-publish-example.json` and `override-v4-rehearsal.json` in this directory |
| P2 | miner-signalled class activation, implemented behind the override, the fast-time gate with three cases and the failed case | `docs/plans/counter-asic-3-node.md` section 6; `infra/fast-time/class-v4-signal.mjs` | GREEN on the Mac: two of three signalling never flips (7 epochs, 6,166 to 7,583 bps), all three flips at epoch 3 (the first full window, 10,000 bps, the same line on 3 of 3 nodes, the id assertion), nobody signalling flips at the floor epoch 5 and not before; the known-failed case fails on eight checks. Rows and summary files: node doc section 6.4; `class-v4-signal-{no-flip,flip,floor,failed-case}.json` |
| G6 (signalling) | the fork change on PC 2 with the igneum-pow feature | the job ids and their lines | GREEN on fork 0562a7f2 (main f39a8eb), three PC 2 jobs under one clearance ("PC 2 open for G6", 17:27Z), the mkdir lock taken 17:28:15Z and released 17:38:58Z, then 17:39:41Z to 17:55:31Z; prover on, app untouched. Job 1 `build-20261006-173017` (the six crates and the app): every build stage ok, the app tests 112 + 26 + 8, but kaspa-consensus 97 passed and 1 FAILED on 2.0's known flake `ban_is_decided_by_the_carrying_block_so_nodes_agree_on_every_voter_list` (`UnexpectedDifficulty(.., 487111630, 487128802)` in `mine_on_all`, the 0.3.10 cut's section 11 case, which also passed on the Mac and in this morning's job 155958), and cargo stopped the unit there. Treated as 2.0 did: job 2 `build-20261006-174027` (kaspa-consensus alone, 17:40 to 17:46Z): `RESULT test node [kaspa-consensus] exit 0 19 s`, `done exit 0 after 345 s ... every stage ok`. Job 3 `build-20261006-174823` (the five crates and the app, 17:48 to 17:55Z): `RESULT test node [kaspa-consensus-core igneum-exec kaspa-pow igneum-miner kaspa-p2p-flows] exit 0 35 s` and `RESULT test app/igneum-app [igneum-app] exit 0 5 s`: kaspa-consensus-core 110 + 7 (`override_params_carry_the_program_class_v4_activation ... ok`, the signal window test inside it), igneum-exec 18, kaspa-pow 15 (`program_class_signal_rule ... ok` is consensus-core's; kaspa-pow's `program_class_v4_seeds_hash_the_shadow_program_over_the_v3_day_cache ... ok`, the feature on), igneum-miner 18, kaspa-p2p-flows 33, igneum-app 112 + 26 + 8; the job's own closing line reads `failed ... upload incomplete` because the relay's blob service refused one of the nine uploads (`igneum-app.exe.zst FAILED: blob PUT: no url in the reply: service_unavailable`, the shipper's 17:25Z fault) AFTER both test stages had closed with exit 0, so the STAGE and RESULT lines are the evidence, as the shipper's warning said. Where the runs went: these three on PC 2 under the clearance given before the build-server rule arrived (18:0xZ); no further Linux build or suite is needed by this brief; the next one from this lane goes to igneum-build-1 through tools/build-remote.sh |

| P3 | the 0.3.15 digest rule (main's ruling, 20:1x UK): an absent class v4 field contributes nothing to the digest, so publish 1 (the binary) splits no handshake and publish 2 (the sixteen-field file) is the one sweep | the compat case and the refusal case on real nodes; the pinned fixtures | GREEN on fork ca3-v4-order-fix 713ef876 (with the order-test race fix 791ff22c; both handed to the shipper for release-0.3.15-node): `infra/fast-time/digest-compat.mjs` (18:58Z, suffix 995, the live thirteen-field file copied, never written): the fixed node and a 0.3.14 node (`target-0314/release/igneumd`) on the thirteen-field file print ONE digest `a89be8a7e64b7d5a...` and peer (n0 has 2 peers, the old node 1: the compat case); the fixed node on the sixteen-field file (the exec pin, the floor 219,600, the window 86,400) prints `db9a85f9ff08f72f...` and has no peer, the handshake's `Refusing peer ...: consensus params digest mismatch` line in the log (the refusal case, the rule's known-failed case: present fields move the digest). On the devnet network id the sixteen-field object digests to `1dddfa5574d5536109a5ae68dc415b55e954bd11208608440845e19670505871` (the fixed Mac binary's start line = the pinned test value), the thirteen-field live file to `b18ed271f75dd464...` (0.3.14's value), fourteen fields `23e76936...`; no file `c562d70e...` (0.3.11 to 0.3.15 unchanged). Box line on 713ef876: kaspa-consensus 98, consensus-core 111 + 7, rc 0. The rehearsal object sets both fields, so its `a15db4f0` on devnet-400 stands. The shipper's independent readings on the 0.3.15 Mac binary (release-0.3.15-node = 4c6b129d + 0562a7f2 + 2e5d3d30 + 791ff22c + 713ef876, 19:0xZ): the same three values, and at tonight's live floor 226,800 the sixteen-field object reads `2c1162e2...`, the publish-2 digest if the floor stays there (recomputed at the publish); the 0.3.14 binary exits at parse on the sixteen-field file, which is why the file follows the binary; its suite on igneum-build-1 at 713ef876: kaspa-consensus 97 + the recorded flake alone 1 of 1, consensus-core 111 + 7, igneum-exec 20, kaspa-pow 15 with both engine tests, igneum-miner 18, p2p-flows 33. Summary `digest-compat-20261006.json` |

| P4 | the two 0.3.15 node faults found on the live devnet (the canary's version 1026, the pruned hub's sync panic), fixed in the same fork tree | the unit tests; the node-cut compat gate on real nodes (a MINING new node beside a 0.3.14 node on the live object, the old node accepting the new node's blocks; a clean new node joining through the old hub; a clean OLD node joining through the NEW node, which must survive serving a sync from the genesis; the new node restarted and re-synced; every header version the block version; no panic); the ledger rows | GREEN on fork ca3-v4-order-fix 7961c5f1 (= 791ff22c + 713ef876 + 17c60367 the signal gate + 7961c5f1 the retention error; the shipper's release-0.3.15-node). The gate `infra/fast-time/node-compat.mjs` (20:15:5x to 20:19:04Z, suffix 994, the live object plus CPU genesis bits, the 0.3.14 binary `target-0314/release/igneumd` as the old side): SUMMARY PASS: one digest `b0afb2ee93d0d627` on all five nodes; accepted old/new 120/75, rejected 0/0; header versions {0: the genesis, 2: 195}; counts 195/195/195/195/195 at the end (the clean new node through the old hub, the clean old node served from the genesis by the new node, which stayed alive, and the restarted new node all at 195); no `wrong block version`, reject or panic line in any log. The known-failed case on the canary binary 713ef876 beside 0.3.14 (20:00 to 20:02Z): SUMMARY FAIL, `HandleRelayInvsFlow flow error: wrong block version: got 1026 but expected 2, disconnecting` on the old nodes, `P2P, got reject message: wrong block version` on the new, counts 138 against the new node's 101, the restarted new node never re-synced (the fleet's p2-3090-1). Unit tests: `block_template_uses_current_block_version` (2 on the thirteen-field state, 1026 with both v4 fields), `program_class_signal_rule`, `a_sync_request_below_retention_is_an_error_not_a_panic`; the box on 7961c5f1: kaspa-consensus 99, consensus-core 111 + 7, rc 0 (the shipper's six-crate line: exec 20, miner 18, pow 15, p2p-flows 33). Ledger rows N1 and N2 in `docs/fud-ledger.md`. RECEIVE SIDE (the clean canary, 21:3x UK: a 7961c5f1 node accepted and relayed a version-1026 block off a poisoned peer and was disconnected by every 0.3.14 peer): fork f1ea7a38 gates the header version RULE like the stamp (signalling inactive: the version must be exactly 2, 0.3.14's rule; active: the low byte); test inside `cheap_checks_run_before_the_pow_engine` (a 1026 header refused with `WrongBlockVersion(1026, 2)` before the engine on the old-format network, accepted with both fields installed); box on f1ea7a38: kaspa-consensus 99, consensus-core 111 + 7, rc 0. The gate with a POISONED peer (`--poisoned <713ef876 igneumd>` mining into the new node, 20:42:5x to 20:45:42Z): SUMMARY PASS: the new node refused the poisoned blocks 12 times (`HandleRelayInvsFlow flow error: wrong block version: got 1026 but expected 2, disconnecting`), the old hub's log carries no reject and no 1026 block (header versions {0: the genesis, 2: 180}), the new node stayed the hub's peer and mined 72 accepted blocks, counts 180 on every clean node including the clean joins and the restart. The stale blocks on the live devnet: a 0.3.14 node holding 1026 blocks is disconnected by its 0.3.14 peers by THEIR rule when it relays them, which no new-node change alters; new nodes are immune from f1ea7a38; the fleet wipes the poisoned datadirs. Owed: a truly pruned serving node in a harness (hours of fast-time chain at pruning depth 13,838). Summaries `node-compat-20261006-fixed.json`, `node-compat-20261006-canary-failed-case.json`, `node-compat-20261006-poisoned-peer.json` |

| P5 | the dependency pass for 0.3.15.1 (the night battery's audit, mirror branch fbb72e5: the fork's lock file) | `cargo audit` before and after on the box; the six-crate suite | DONE on fork `ca3-v4-deps` f8f0f1df (from 7961c5f1): `cargo audit` on igneum-build-1 before: 6 vulnerabilities (crossbeam-epoch RUSTSEC-2026-0204, h2 2026-0258, quinn-proto 2026-0185, ruint 2026-0220, rustls 2026-0285, tracing-subscriber 2025-0055; the battery's 22 counts advisory paths), 16 warnings (unmaintained, unsound, yanked); the three peer-reachable crates first (h2 0.4.6 to 0.4.20, quinn-proto 0.11.14 to 0.11.19, rustls 0.23.39 to 0.23.45 with rustls-webpki 0.103.15), then crossbeam-epoch 0.9.21 and ruint 1.20.1 (rand_pcg added), every one a patch or minor bump by the audit's own solution line; after: 1 vulnerability, 16 warnings; the one left is tracing-subscriber 0.2.25, pinned by ark-relations 0.5.1 through ark-groth16 and ark-snark (a 0.2 to 0.3 major bump outside the fork's pins, which name 0.3 in bridge/Cargo.toml), named here, not taken. The six-crate suite on the box on the new lock: kaspa-consensus 99, consensus-core 111 + 7, igneum-exec 20, kaspa-pow 15, igneum-miner 18, kaspa-p2p-flows 33, rc 0 (80 s). The 16 warnings are unmaintained or unsound transitive crates (async-std, atty, bincode 1, derivative, instant, mach, paste, proc-macro-error, rustls-pemfile, anyhow, event-listener, faster-hex, lru, chacha20, spin), none with a bump to take, each a dependency choice for 0.3.16 |

Summary files in this directory: `class-v4-20261006-1553Z-cpu.json` (G4 run 1), `class-v4-20261006-never-failed-case.json` (G4 run 2, the failed case), `class-v4-20261006-metal.json` (G4b), `class-v4-20261006-id-rerun.json` (G4 on the program-id fix, with the id assertion), `class-v4-20261006-id-failed-case.json` (the id assertion's failed case).