registry: POW-05 reviewed (binding review section 5a, master 38a29345); merged onto master's copy under rule 26

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/design/consensus-proof-stages.md

@@ -0,0 +1,52 @@
+# The consensus proof in stages: rewards and payouts from inputs to outputs (P22, ZKP-04 and ZKP-08, the proof side)
+
+8 October 2026, 19:0x UK, the enforced-proving lane, under the coordinator's order of 18:5x UK ("P22 stage 3 starts now, not 18:00 tomorrow, with the earliest clock its dependencies allow"). The register row: "Negative test six, proof side: derivation inside the aggregator guest (P22 stage 3)". This document is the staged design the spec's section 7 names (`docs/spec/proving-enforcement.md`), each stage a claim about one input, the check that holds it until the next stage, the code that carries it, its clock and the dependency that sets the clock. Every figure is stated (code read) or owed with its clock. Nothing here changes any network: every stage changes both guests' public values and so both program ids, which means every stage ships only through a key succession (`docs/design/key-succession.md`), and the first succession height is main's word.
+
+## 0. What the proof says today, read from the code
+
+A shard proof's public values (`igneum_prove_core::shard::ShardOutput`, 328 bytes) commit to the roots the shard started and ended on, its transactions' commitment, its receipts root, its gas and its prover. The rewards the segment credited before its first transaction, the proving pool credit and the payouts the carrier applied are inputs to shard 0 (`ShardInput.rewards`, `.proving_pool_credit`, `.payouts`); they shape the post-root and appear nowhere in the statement. The aggregator (`igneum_prove_core::agg::aggregate`) chains the shards on roots, links and transaction commitments and carries the provers' addresses out; it never sees the rewards or the payouts. The node vetoes any statement whose roots are not the ones its own execution landed on (`check_record`, `check_segment_record`), and its own execution used the rewards and payouts consensus derived; so a proof over other rewards or payouts matches no node's statement and pays nothing. That is ledger P22's answer and the native veto of negative test six, team-tested on 8 October (`enforced_a_statement_over_altered_rewards_or_payouts_is_vetoed_native_derivation_is_the_check`).
+
+What the proof does not say: which rewards and payouts it applied. A verifier holding only the proof and the chain's headers cannot tell whether the post-root followed from the rewards consensus prescribes. That is what the stages add.
+
+## 1. Stage 1: the inputs as a commitment the proof carries (in code, 8 October 2026)
+
+Shard 0's statement gains `inputs`, keccak-256 over the rewards list, the proving pool credit and the payouts list, in order (`inputs_commitment` in `igneum_prove_core::shard` and, byte for byte, in `igneum_exec::proving`); every other shard's `inputs` is zero and the aggregator asserts it; the aggregator carries shard 0's commitment out as `BlockOutput.inputs`; the node's `BlockStatement` carries it and `check_segment_record` vetoes a segment statement whose commitment is not the one over the rewards and payouts this node derived ("inputs" in the veto's diff). The layouts grow by 32 bytes: the shard statement 328 to 360, the block statement 340 to 372.
+
+What it proves: the proof names the inputs it applied, and every node checks them against its own derivation. What it does not prove: that those inputs are the ones consensus prescribes; the node's derivation is still the authority. Why it is worth a stage: a third party holding the proof and the node's derivation can now see which of the two a disagreement is in, and stages 2 and 3 replace the node's derivation one list at a time without touching the proof's shape again.
+
+Branch: `p22-stage-1` (main repo, the guest core, the host's known-failed test `the_inputs_commitment_binds_the_rewards_and_payouts_through_shard_0_and_the_aggregator`, the vector pinned in both crates) and `p22-stage-1-node` (the fork, off `key-succession-node` 291ee6ae: the mirror function, the statement bytes, the native block statement, the veto, the tests `p22_stage_1_inputs_commitment_vector` and `p22_stage_1_a_statement_over_altered_inputs_is_vetoed_by_its_commitment`). Suites on build-2 tonight. Ships through the first key succession that follows it (new program ids).
+
+## 2. Stage 2: the payouts derived inside the aggregator (clock 14:00 UK, 9 October 2026, as the branch; shipping with a succession)
+
+The payouts a carrier applies are a pure function of (a) the carried shard records of the segment's blocks, in sequence order, (b) the segment's plan (its shard count) and pool credit, (c) the paid map before the carrier, and (d) the rules of spec 7.7 item 6 and 7.8 item 9 (`carried_payouts`, `shard_parts`, `split_pool_credit`). Stage 2 moves (d) into the aggregator guest: the guest takes the carried records' bytes and the prior paid set as inputs, derives the payouts list itself and commits to the derivation's inputs (the records' commitment and the prior paid set's commitment) beside the `inputs` of stage 1, so a proof over an invented payouts list is impossible unless its invented records pass the same checks.
+
+The honest limit, stated: a shard record's validity rests on a BLS signature (`ProofRecord::verify_signature`, BLS12-381 G2 under the record's domain) and on the sortition (`assign`, the eligible window's keys drawn from the epoch seed). Neither exists in the guest today: no BLS verifier in SP1 guest code here, and the sortition needs the window's blue blocks, which are consensus data. So stage 2 as it can ship next is a commitment over the carried records' bytes and the prior paid set with the payouts derived from them by the rules, and the node's native check remains: this node's `carried_payouts` over the same records must give the same list (it checks the signatures and the sortition natively, as today). What the proof then says: "from these records and this paid set, these payouts follow by the rules"; what it does not say: "these records are valid". The costed step after it is BLS12-381 verification inside the guest (an SP1 precompile exists for BLS12-381 field operations; the pairing in guest code is the measurement owed: cycles per signature on one shard record, on build-1's CPU prover, before the step is scheduled).
+
+Tests, known-failed first, on branch `p22-stage-2`: the guest derives the node's payouts for a fixture with carried records (the fixture format gains `carried_records` and `paid_before`); a changed record, a changed paid set or a changed pool credit changes the commitment; the node's `check_segment_record` vetoes a segment statement whose derivation inputs differ from its own; the seven refusals hold unchanged.
+
+## 3. Stage 3: the rewards derived inside the aggregator from consensus data it verifies (the design by 18:00 UK, 9 October 2026; the code clock from the primitive's cost)
+
+The rewards a segment credits are a pure function of consensus data: the mergeset's blocks and which are blue (`SegmentBlock.is_blue`), each block's miner address (from its coinbase payload) and subsidy at its DAA score (`emission_table().block_subsidy`), the silent-builder reading (`finality_silent_builder`, a pure function of the block's past), the signing bonus and the pool split (`silent_split_units`, `split_producer`). Stage 3 moves that derivation into the aggregator guest, which means the guest verifies the headers and coinbase payloads of the mergeset and the facts about them it needs:
+
+| Fact the rewards need | Where it comes from | What the guest must verify |
+|---|---|---|
+| the mergeset and its blue set | GHOSTDAG over the block's past | a header chain to the segment's chain block and the mergeset's membership and blueness, which is the GHOSTDAG computation or a commitment to its result that the header carries (today's header carries `blue_score` and `blue_work`, not the blue set); the primitive that does not exist |
+| each block's miner | its coinbase payload | the coinbase transaction's inclusion under the header's merkle root (a merkle path per block: cheap) |
+| each block's subsidy | its DAA score and the emission table | the header's `daa_score` (in the header: free once the header is verified) and the table as a guest constant |
+| the silent-builder reading | the finality vote key hash and the builder's signing history over the block's past | a commitment the header would have to carry (it does not today) |
+| the signing bonus and the pool split | the object's parameters and the coinbase's split section | guest constants (the object's digest as an input) and the coinbase payload (verified with the miner) |
+
+The two facts without a header commitment (the blue set, the silent-builder reading) decide the clock: either the header gains a commitment to them (a consensus change, its own height switch, its own digest move) or the guest computes GHOSTDAG over the past, which is the measurement owed before any clock is named: cycles for a mergeset of k blocks with the header window the computation needs, on the CPU prover. The honest expectation, labelled approximate: tens of millions of cycles per block for the merkle paths and the subsidy table, and GHOSTDAG over a window of thousands of headers beyond what a per-block proof should carry, which points at the header commitment. The design document of 18:00 UK tomorrow carries the measurement and names the code clock from it; until then stage 3's clock is "after the header commitment's own succession", not a time.
+
+## 4. What the served text says at each stage
+
+| Stage | The served label on negative test six's proof side | The sentence the plan's boundary keeps |
+|---|---|---|
+| 0 (today) | PENDING, team-tested natively | a proof of execution is not a proof of authenticated consensus inputs |
+| 1 | PENDING, the inputs named by the proof and checked natively | the same |
+| 2 | PENDING, the payouts derived in the proof from records checked natively | the same |
+| 3 | team-tested, once the guest verifies the consensus data the rewards need | the sentence narrows to canonical history and data availability, which no stage here touches |
+
+## 5. The dependency every clock carries
+
+Each stage changes both guests' public values, so both program ids, so each ships only as a key succession: the node embeds the new pair beside the old, the object names the height and the window, the proofs of both pairs verify across the window. The first succession (the re-pinned guest of 8 October, afd952e89) is the rehearsal; stages 1 to 3 ride later successions, one or several, as main schedules them. Without a named height a stage is built and tested on its branch and waits; the clocks above are the branches' clocks, not activation clocks.

docs/plans/igneum-2.0-register.md

@@ -109,6 +109,16 @@ Built 8 October 2026, 18:3x BST (the founder's order: no feature left out, no st
 | 103 | Pins the finish line missed (checked against the 37 pages, 18:1x BST) (p. 8 to 24) | The funded maintenance plan and the committed-funding line (p. 24). Owner: the founder. | main / the founder | the founder's | open | | COM-07 (P13, DEFERRED) |
 | 104 | Architecture and product (review 2) (p. 15 to 17) | Key succession: a succession field in the object (the pinned program ids and verifier versions with an activation height and a window; below the height the old pair, across the window either pair, from its end the new pair; the payment rule on the same floor; the manifest carrying both pairs with the height; never on every network; the daemon refusing to start if it embeds neither pair the object names), designed and tested on the fast-time harness before any devnet carries it, so a re-pin is a scheduled transition and never a genesis (main's order, 18:1x BST) | enforced-proving lane (a6e8f84588b809d62) with the node lane (a283f5f0d364ceef0) | the design doc tonight; the node branch with its known-failed tests and the fast-time case by 18:00 tomorrow | in flight: docs/design/key-succession.md tonight; the re-pinned guest (afd952e89, shard 0x282dcfce, aggregator 0x3fd721e8) waits on it | docs/design/key-succession.md | ZKP-02, EVM-08 |
 
-## Coverage at 18:3x BST: 104 pins, 104 owned, open 30, in flight 35, landed 34, passed 5. Cases: 128 in 16 suites, every case owned; run under the standard: 0 passed, 63 RUNNING (team-run tonight with evidence, not yet under the standard's procedure), 64 NOT RUN, 1 DEFERRED (P13).
+| 105 | External source review of the mining algorithm (docs/analysis/review-2026-10-08/, on master at 0ae450bd; it examined the Mac checkout's older V2 to V4 crate, not class v6, and says so) | Finding A01 "The supplied snapshot is not the planned v6" (on master at 0ae450bd, the harness run on build-2 to its end with every anchor it asserts agreeing with the tree, the v5 and v6 vectors outside its model); the review's harness is the cross-check evidence; the verdict reads fixed by construction, not applicable, or known open with a clock, and nothing reads PASS without the native test | node lane (a283f5f0d364ceef0); the node lane carries the verdict into the 23:30 freeze | carried into the 23:30 freeze by the node lane | RUNNING tonight (main's dispatch, 18:5x BST) | docs/analysis/review-2026-10-08/ | POW-01 (the review's harness as cross-check; the native test decides) |
+| 106 | External source review of the mining algorithm (docs/analysis/review-2026-10-08/, on master at 0ae450bd; it examined the Mac checkout's older V2 to V4 crate, not class v6, and says so) | Finding A02 "Accepted short programs need not connect all 32 lanes" (on master at 0ae450bd, the harness run on build-2 to its end with every anchor it asserts agreeing with the tree, the v5 and v6 vectors outside its model); the review's harness is the cross-check evidence; the verdict reads fixed by construction, not applicable, or known open with a clock, and nothing reads PASS without the native test | hash lane (a690540514aa453d7); the node lane carries the verdict into the 23:30 freeze | 22:30 | RUNNING tonight (main's dispatch, 18:5x BST) | docs/analysis/review-2026-10-08/ | POW-02, POW-03 (the review's harness as cross-check; the native test decides) |
+| 107 | External source review of the mining algorithm (docs/analysis/review-2026-10-08/, on master at 0ae450bd; it examined the Mac checkout's older V2 to V4 crate, not class v6, and says so) | Finding A03 "Per-hash address diversity can conceal per-site concentration" (on master at 0ae450bd, the harness run on build-2 to its end with every anchor it asserts agreeing with the tree, the v5 and v6 vectors outside its model); the review's harness is the cross-check evidence; the verdict reads fixed by construction, not applicable, or known open with a clock, and nothing reads PASS without the native test | census lane (the hash lane's harness hand); the node lane carries the verdict into the 23:30 freeze | 22:30 | RUNNING tonight (main's dispatch, 18:5x BST) | docs/analysis/review-2026-10-08/ | POW-03 (the review's harness as cross-check; the native test decides) |
+| 108 | External source review of the mining algorithm (docs/analysis/review-2026-10-08/, on master at 0ae450bd; it examined the Mac checkout's older V2 to V4 crate, not class v6, and says so) | Finding A04 "The acceptance interpreter omits the shadow that runtime executes" (on master at 0ae450bd, the harness run on build-2 to its end with every anchor it asserts agreeing with the tree, the v5 and v6 vectors outside its model); the review's harness is the cross-check evidence; the verdict reads fixed by construction, not applicable, or known open with a clock, and nothing reads PASS without the native test | hash lane (a690540514aa453d7); the node lane carries the verdict into the 23:30 freeze | 22:30 | RUNNING tonight (main's dispatch, 18:5x BST) | docs/analysis/review-2026-10-08/ | POW-02 (the review's harness as cross-check; the native test decides) |
+| 109 | External source review of the mining algorithm (docs/analysis/review-2026-10-08/, on master at 0ae450bd; it examined the Mac checkout's older V2 to V4 crate, not class v6, and says so) | Finding A05 "Header binding and final digest deserve independent cryptographic review" (on master at 0ae450bd, the harness run on build-2 to its end with every anchor it asserts agreeing with the tree, the v5 and v6 vectors outside its model); the review's harness is the cross-check evidence; the verdict reads fixed by construction, not applicable, or known open with a clock, and nothing reads PASS without the native test | attack seat (a3832b1c3b274b310); the node lane carries the verdict into the 23:30 freeze | 23:00 | RUNNING tonight (main's dispatch, 18:5x BST) | docs/analysis/review-2026-10-08/ | POW-05, POW-06 (the review's harness as cross-check; the native test decides) |
+| 110 | External source review of the mining algorithm (docs/analysis/review-2026-10-08/, on master at 0ae450bd; it examined the Mac checkout's older V2 to V4 crate, not class v6, and says so) | Finding A06 "Different V3 eras can have the same program_id" (on master at 0ae450bd, the harness run on build-2 to its end with every anchor it asserts agreeing with the tree, the v5 and v6 vectors outside its model); the review's harness is the cross-check evidence; the verdict reads fixed by construction, not applicable, or known open with a clock, and nothing reads PASS without the native test | hash lane (a690540514aa453d7); the node lane carries the verdict into the 23:30 freeze | 22:30 | RUNNING tonight (main's dispatch, 18:5x BST) | docs/analysis/review-2026-10-08/ | POW-01 (the review's harness as cross-check; the native test decides) |
+| 111 | External source review of the mining algorithm (docs/analysis/review-2026-10-08/, on master at 0ae450bd; it examined the Mac checkout's older V2 to V4 crate, not class v6, and says so) | Finding A07 "CUDA dispatch needs explicit canonical-group constraints" (on master at 0ae450bd, the harness run on build-2 to its end with every anchor it asserts agreeing with the tree, the v5 and v6 vectors outside its model); the review's harness is the cross-check evidence; the verdict reads fixed by construction, not applicable, or known open with a clock, and nothing reads PASS without the native test | hash lane (a690540514aa453d7); the node lane carries the verdict into the 23:30 freeze | 22:30 | RUNNING tonight (main's dispatch, 18:5x BST) | docs/analysis/review-2026-10-08/ | POW-02 (the review's harness as cross-check; the native test decides) |
+| 112 | External source review of the mining algorithm (docs/analysis/review-2026-10-08/, on master at 0ae450bd; it examined the Mac checkout's older V2 to V4 crate, not class v6, and says so) | Finding A08 "An operation described as bijective is not always bijective" (on master at 0ae450bd, the harness run on build-2 to its end with every anchor it asserts agreeing with the tree, the v5 and v6 vectors outside its model); the review's harness is the cross-check evidence; the verdict reads fixed by construction, not applicable, or known open with a clock, and nothing reads PASS without the native test | hash lane (a690540514aa453d7); the node lane carries the verdict into the 23:30 freeze | 22:30 | RUNNING tonight (main's dispatch, 18:5x BST) | docs/analysis/review-2026-10-08/ | POW-02 (the review's harness as cross-check; the native test decides) |
+| 113 | External source review of the mining algorithm (docs/analysis/review-2026-10-08/, on master at 0ae450bd; it examined the Mac checkout's older V2 to V4 crate, not class v6, and says so) | Finding A09 "A naive stronger rejection test can exhaust all candidates" (on master at 0ae450bd, the harness run on build-2 to its end with every anchor it asserts agreeing with the tree, the v5 and v6 vectors outside its model); the review's harness is the cross-check evidence; the verdict reads fixed by construction, not applicable, or known open with a clock, and nothing reads PASS without the native test | hash lane (a690540514aa453d7); the node lane carries the verdict into the 23:30 freeze | 22:30 | RUNNING tonight (main's dispatch, 18:5x BST) | docs/analysis/review-2026-10-08/ | POW-04 (the review's harness as cross-check; the native test decides) |
+
+## Coverage at 19:0x BST: 113 pins (104 of the plan, 9 of the review), 113 owned, open 30, in flight 44, landed 34, passed 5. Cases: 128 in 16 suites, every case owned; run under the standard: EVM-02 to 06 and VER-03, 04, 05, 06, 08 PASS (10), ECO-05 FAIL, VER-01 and VER-02 FAIL by design and disclosed, 62 RUNNING, 52 NOT RUN, 1 DEFERRED (P13).
 
 The pass criteria are the Test and Acceptance Standard's (docs/plans/igneum-2.0-test-standard.pdf, 128 cases, approved as proposed by the founder on 8 October 2026 with P13 deferred; the live registry docs/plans/igneum-2.0-test-registry.json): a row reads passed only when its cases pass under the standard. The plan's own conditions, per section: D1 an independent operator reproduces the baseline from the served kit alone; D2 the candidate improves against re-optimised adversaries within the preset limits, else published as a failure; D3 the best supported advantage inside the chosen envelope with uncertainty published; D4 the model names credible conditions for sustained commodity participation and where it fails; D5 specified behaviour with no emergency change and no privileged intervention; the launch requirements live; the claim ladder earned rung by rung.