diff --git a/docs/evidence.md b/docs/evidence.md index d9bcc7764..ad5c0eead 100644 --- a/docs/evidence.md +++ b/docs/evidence.md @@ -33,13 +33,13 @@ Every row carries its release evidence packet at the end of its Result cell: par | # | Claim | Where it is made | Status | Version or commit | Reproducible test | Result, date, machine | Independent verification | |---|---|---|---|---|---|---|---| -| 1 | The Igneum 2.0 devnet (`igneum-devnet-4`): genesis 7c36b833 stamped 8 October 2026, chain id 4465 (eth_chainId 0x1171), 18 decimals, every upgrade on from block zero (class v5, the era VDF, finality v3, calibrated fees, enforced proving); the release manifest (/release.json) carries its commits and is regenerated at its first block | This page; the live page; /build | TEAM-REPORTED; activated: the first block f3dc319c at DAA 0, mined at 17:14 UK on 8 October 2026 and accepted on the seed at 17:17 | the release manifest (/release.json): node 4cdcc488 on release-2.0.0-node, igneum-pow 1c420786, digest be5f4068 | the node's own start line and its first block (the node lane's read of build-1's seed) | 8 October 2026, 17:14 UK: the first block f3dc319c at DAA 0 on node 4cdcc488; an earlier object of the same genesis minted at the wrong decimals and is dead | none yet. Packet: parameters the manifest's network block (genesis 7c36b833, digest be5f4068, 18 decimals); procedure the node's start line and eth_getBalance over the public RPC; raw result the first block f3dc319c and the miner's balance 2,535,047,024,800,000,000 wei after it; reproduction none yet; review scope none; unresolved an earlier object of the same genesis is dead and its chain is not served | -| 2 | Proof verification is enforced in consensus on the Igneum 2.0 devnet from block zero (Deliverable 5's prerequisite): the node's start line reads "consensus proof verification from DAA score 0 (verifier_in_consensus set)" and names the shard program id and the aggregator id; a block carrying a statement without a valid proof is refused | `docs/plans/igneum-2.0.md` D5; this page; the litepaper (Proving) | TEAM-REPORTED; activated: on from block zero, the chain running since 17:14 UK on 8 October 2026 | node 4cdcc488 on release-2.0.0-node (the manifest); the program ids are the ELF manifest's (`proving/igneum-prove/elf/manifest.json`) | the node's own start line; the no-rescue exercise itself (D5) is Open | 8 October 2026: on from block zero in the 2.0 devnet's object, the chain running since 17:14 UK; the earlier devnet ran with the rule off; no block yet refused for a false proof on the record | none yet. Packet: parameters verifier_in_consensus set from DAA 0, the shard program id 0x2b1a81cb and the aggregator id 0x474678f3 (the ELF manifest); procedure the node's start line; raw result the line itself; reproduction none yet; review scope none; unresolved no hostile submission has yet been refused on the record (D5's exercise) | -| 3 | The 64-register window per lane costs a GPU under 1 percent of rate at stock, and at most 5 percent per load with the liveness chain | The litepaper (class v6); `docs/plans/igneum-2.0.md` D1 (the placed 64-register rows) | TEAM-REPORTED; tested by the team | `docs/analysis/class-v6/connected-state.md` section 4; `docs/design/class-v6-rotating-family.md` section 10.0e | The class v5 nvcc harness and the kit worker, both packs on the same card minutes apart, 250 batches of 2^24, nvidia-smi at 1 Hz, vectors PASS on every row (`connected-state.md` section 4); the per-load rows of the full chain against the base (`class-v6-rotating-family.md` 10.0e) | 8 October 2026, rented RTX 5090 (575 W cap) and RTX 4090 (450 W cap) at stock: energy per hash +0.6 percent on the RTX 5090 and -0.9 percent on the RTX 4090, inside the run-to-run noise; under 1 percent of rate; 80 to 87 registers per thread, no spill (all measured). Per load: RTX 5090 16.7 nJ base, 17.6 nJ full chain; RTX 4090 26.0 nJ, 27.0 nJ (measured). The lock row on the project's own rigs is owed | none yet. Packet: parameters a rented RTX 5090 and RTX 4090 at stock, the liveness chain, class v4; procedure the hash lane's harness rows in connected-state.md section 4; raw result energy per hash +0.6 percent and -0.9 percent, at most 5 percent per load; reproduction none yet; review scope none; unresolved two cards, one day, no AMD or Apple row | -| 4 | Reorganising the same work around live state (the connected-state variant, experiment D2(a)) does not reduce a specialised chip's edge: KILL as a class | `docs/plans/igneum-2.0.md` D2(a); this page | TEAM-REPORTED; tested by the team (a published failure) | `docs/analysis/class-v6/connected-state.md` (the verdict, section 6) | The census, liveness and GPU rows in `connected-state.md` sections 2 to 4; the chip side priced on the drawn program by synthesis (a model, never a lower bound) | 8 October 2026, verdict 17:25 UK: the window is necessary (63 of 64 registers live at every address, measured) but only its width reaches the chip, +1.2 pJ per lane-op at N5 (synthesised); the window moves the chip's edge 1.10x node for node against a 1.25x gate (modelled); the GPU side +0.6 percent energy per hash on the RTX 5090, -0.9 percent on the RTX 4090 at stock (measured). Rearranging the dependency graph of the same operations moves neither side | none yet. Packet: parameters the connected-state generator variant behind a flag, the census TSVs; procedure connected-state.md; raw result +1.2 pJ per lane-op at N5 on the chip side, the GPU side unmoved; reproduction none yet; review scope none; unresolved the chip side is modelled, not measured | -| 5 | "A GPU-secured network for Ethereum-compatible applications and verifiable computation." served on every page | Every page | PROPOSED; designed (served) | `docs/plans/igneum-2.0.md` (the objective: the positioning line) | `node tools/ci/ledger-text-check.mjs`: the sentence pinned (R0) on the home page, the litepaper and this page | 8 October 2026: on this page; the home page and the litepaper carry it as their 2.0 text lands (designed) | none yet. Packet: parameters none (a served sentence); procedure the ledger-text check pins it on every page; raw result the check's count; reproduction not applicable; review scope the three external reviews the founder accepted; unresolved none | -| 6 | The chip claim as served: "Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes." Under it the three statements, separate: energy ("Current modelling estimates a 1.5x to 3.1x energy-efficiency advantage for the specialised designs assessed as complete machines against the GPU tier, from a board on commodity DRAM at 1.5x to an SRAM-store die at 3.1x (1.5x to 2.3x on the GPU's own node)." Per machine on the same node and a node ahead: the DRAM board 1.5x to 1.6x and 1.8x, the hybrid 1.9x to 2.1x and 2.4x to 2.6x, the die 2.3x and 3.1x; across the adversary's lane-count choice the same-node bracket is 1.5x to 2.1x and a node ahead 1.8x to 2.6x; 3x to 6x per dollar of hardware at list price. MODELLED: the GPU side measured, the chip's core placed and routed, the rest of the machine modelled, no chip measured, hardware cost approximate within 2x), economic and response capability, rotation an optional improvement. Class v5 derives the dataset from chain state; whether that excludes a specialised design is under evaluation (Deliverable 3), since a design that tracks state is not excluded by staleness. The dataset policy (PROPOSED; the genesis size is the founder's decision, pending; no size served as decided): "The dataset’s size is a one-off hardware ticket on specialised designs and a running energy tax on commodity cards: at 4 to 5.5 GiB a locked Blackwell card pays 12 to 14 percent more energy per hash than at 1 GiB (an 8 GB AMD card under 3 percent of rate), while the board on commodity DRAM pays nothing and the SRAM designs pay a hardware cost that does not change their outcome. So the genesis size is the founder’s decision on that scoring, pending (this lane’s recommendation 4 GiB, the largest size that keeps every entry card and a 12 GB card’s mining and proving together), and every later step is scored at 5 percent against it and taken only when the chain’s own state outgrows the dataset, not on a calendar." (PROPOSED; the energy-against-size curve on the litepaper: 1, 2, 4 and 5.5 GiB at stock and at the lock measured on an RTX 5090 against its own 1 GiB control, +0.7 and +4.3 percent at stock, +11.7 and +13.4 at the lock for 4 and 5.5 GiB, the 2 GiB knee cell a paired read in flight; the exclusions by memory; the SRAM tickets modelled). The energy ratio is not the pass criterion: the coexistence model ([docs/analysis/class-v6/coexistence-model.md](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/coexistence-model.md)) is, and its first run's result is served with its conditions: A specialised supplier may earn a normal return; ordinary GPUs remain sufficiently close in total cost, widely obtainable and useful outside mining that new operators can still compete. On today's modelled rows that holds for the chip anyone can build, a stored-dataset board on commodity DRAM, at a productive life of one to three years: its cost per accepted unit of work sits within the range of the best GPU owner and entrant, it passes six of the seven conditions (a third of the network in boards now costs less than a year's revenue at the final hardware price), and a fleet of it holds a minority of the network with GPU entrants still setting the price. For the SRAM-store die the outcome turns on its hardware cost per unit of work, not its energy advantage: at the reconciled machine cost, set by the power train and the shadow core rather than the die, it fails the cost, hardware, fleet and margin conditions at every point of the band, a modest fleet holds about two fifths of a growing network and three fifths of a flat one on arrival and takes every flat or shrinking network within five years, and the only coexistence-shaped outcome is private supply in a growing network; what holds it is the investment decision, since its economics are project economics. A third design, a DRAM board with the hottest half of the dataset in on-board SRAM, sits between the two: it coexists only in a growing network at cheap GPU electricity and fails the cost conditions in a flat or shrinking one, and the dataset's size floor is a real lever on it where it was none on the SRAM die. What holds the die is the investment decision, not the hash; every chip figure here is modelled, not measured, and the chip's hardware cost per unit of work is approximate within 2x. | The litepaper (the chip model) | MODELLED; designed (the bracket modelled; the GPU side tested by the team) | `docs/design/class-v6-rotating-family.md` section 10 (10.0h to 10.0n, 8 October 2026); `docs/plans/igneum-2.0.md` D3 and D4 | the scoring rule in the close (the minimum over workloads of the maximum over free adversarial designs of the GPU's joules per hash over the adversary's, under the 10 percent GPU-cost budget at the lock, the verifier limit, cross-vendor correctness and hardware accessibility); the placed rows are D3's | the GPU side measured: the RTX 5080 at its 1,100 MHz lock 2.06 microjoules per hash and the RTX 5090 at its 1,300 MHz lock 2.33 (8 October 2026, the project's own rigs and rented pods); the chip side synthesised and claimed, its placed gated row pending | none yet. Packet: parameters the placed full 18-family core on ASAP7, claimed node scaling, the GDDR7 board, the RTX 5090 at its 1,300 MHz lock on class v4; procedure class-v6-rotating-family.md section 10 and coexistence-model.md; raw result the energies and verdicts as served; reproduction none yet; review scope three external reviews of the close, findings taken; unresolved no chip measured, hardware cost approximate within 2x, the k lane's 32-lane placed row pending | -| 7 | Mining and proving together on one card needs a 16 GB card at the proposed 5.5 GiB dataset (the genesis size is pending the founder’s decision; at a smaller dataset the miner holds less and the rule is not yet measured): the miner holds about 6.1 GiB and a compressed shard proof peaks at about 7.5 GiB, so 8 GB and 12 GB cards time-share (the app pauses the miner for the proof). NVIDIA proves; AMD and Apple mine | The litepaper (Proving, vs RandomX); the miner page | TEAM-REPORTED; tested by the team | `docs/analysis/class-v6/coexist-rows.md` (the 5.5 GiB ds55 miner beside igneum-prove-host-0317, compressed at threshold 2^26, the served sm_86 and sm_89 floors) | the RESULT rows in that file, verbatim from the runs | rented RTX 3060 12 GB: 26.82 MH/s at 117.4 W with 6,129 MiB resident; the compressed shard 13.2 s, peak 7,525 MiB (6,129 + 7,525 = 13,654 MiB against 12,288); rented RTX 4060 8 GB: 18.84 MH/s, 6,116 MiB resident; the shard 8.2 s, peak 7,532 MiB; 8 October 2026 | none yet. Packet: parameters the 5.5 GiB ds55 miner, igneum-prove-host-0317 compressed at threshold 2^26, sm_86 and sm_89; procedure coexist-rows.md; raw result the RESULT rows verbatim; reproduction none yet; review scope none; unresolved two cards on one day, the 6 October rows stand as 1 GiB-dataset rows | +| 1 | The Igneum 2.0 devnet (`igneum-devnet-4`): genesis 7c36b833 stamped 8 October 2026, chain id 4465 (eth_chainId 0x1171), 18 decimals, every upgrade on from block zero (class v5, the era VDF, finality v3, calibrated fees, enforced proving); the release manifest (/release.json) carries its commits and is regenerated at its first block | This page; the live page; /build | TEAM-REPORTED; activated: the first block f3dc319c at DAA 0, mined at 17:14 UK on 8 October 2026 and accepted on the seed at 17:17 | the release manifest (/release.json): node 4cdcc488 on release-2.0.0-node, igneum-pow 1c420786, digest be5f4068 | the node's own start line and its first block (the node lane's read of build-1's seed) | 8 October 2026, 17:14 UK: the first block f3dc319c at DAA 0 on node 4cdcc488; an earlier object of the same genesis minted at the wrong decimals and is dead Case: GOV-01 | none yet. Packet: parameters the manifest's network block (genesis 7c36b833, digest be5f4068, 18 decimals); procedure the node's start line and eth_getBalance over the public RPC; raw result the first block f3dc319c and the miner's balance 2,535,047,024,800,000,000 wei after it; reproduction none yet; review scope none; unresolved an earlier object of the same genesis is dead and its chain is not served | +| 2 | Proof verification is enforced in consensus on the Igneum 2.0 devnet from block zero (Deliverable 5's prerequisite): the node's start line reads "consensus proof verification from DAA score 0 (verifier_in_consensus set)" and names the shard program id and the aggregator id; a block carrying a statement without a valid proof is refused | `docs/plans/igneum-2.0.md` D5; this page; the litepaper (Proving) | TEAM-REPORTED; activated: on from block zero, the chain running since 17:14 UK on 8 October 2026 | node 4cdcc488 on release-2.0.0-node (the manifest); the program ids are the ELF manifest's (`proving/igneum-prove/elf/manifest.json`) | the node's own start line; the no-rescue exercise itself (D5) is Open | 8 October 2026: on from block zero in the 2.0 devnet's object, the chain running since 17:14 UK; the earlier devnet ran with the rule off; no block yet refused for a false proof on the record Case: ZKP-01 | none yet. Packet: parameters verifier_in_consensus set from DAA 0, the shard program id 0x2b1a81cb and the aggregator id 0x474678f3 (the ELF manifest); procedure the node's start line; raw result the line itself; reproduction none yet; review scope none; unresolved no hostile submission has yet been refused on the record (D5's exercise) | +| 3 | The 64-register window per lane costs a GPU under 1 percent of rate at stock, and at most 5 percent per load with the liveness chain | The litepaper (class v6); `docs/plans/igneum-2.0.md` D1 (the placed 64-register rows) | TEAM-REPORTED; tested by the team | `docs/analysis/class-v6/connected-state.md` section 4; `docs/design/class-v6-rotating-family.md` section 10.0e | The class v5 nvcc harness and the kit worker, both packs on the same card minutes apart, 250 batches of 2^24, nvidia-smi at 1 Hz, vectors PASS on every row (`connected-state.md` section 4); the per-load rows of the full chain against the base (`class-v6-rotating-family.md` 10.0e) | 8 October 2026, rented RTX 5090 (575 W cap) and RTX 4090 (450 W cap) at stock: energy per hash +0.6 percent on the RTX 5090 and -0.9 percent on the RTX 4090, inside the run-to-run noise; under 1 percent of rate; 80 to 87 registers per thread, no spill (all measured). Per load: RTX 5090 16.7 nJ base, 17.6 nJ full chain; RTX 4090 26.0 nJ, 27.0 nJ (measured). The lock row on the project's own rigs is owed Case: GPU-03 | none yet. Packet: parameters a rented RTX 5090 and RTX 4090 at stock, the liveness chain, class v4; procedure the hash lane's harness rows in connected-state.md section 4; raw result energy per hash +0.6 percent and -0.9 percent, at most 5 percent per load; reproduction none yet; review scope none; unresolved two cards, one day, no AMD or Apple row | +| 4 | Reorganising the same work around live state (the connected-state variant, experiment D2(a)) does not reduce a specialised chip's edge: KILL as a class | `docs/plans/igneum-2.0.md` D2(a); this page | TEAM-REPORTED; tested by the team (a published failure) | `docs/analysis/class-v6/connected-state.md` (the verdict, section 6) | The census, liveness and GPU rows in `connected-state.md` sections 2 to 4; the chip side priced on the drawn program by synthesis (a model, never a lower bound) | 8 October 2026, verdict 17:25 UK: the window is necessary (63 of 64 registers live at every address, measured) but only its width reaches the chip, +1.2 pJ per lane-op at N5 (synthesised); the window moves the chip's edge 1.10x node for node against a 1.25x gate (modelled); the GPU side +0.6 percent energy per hash on the RTX 5090, -0.9 percent on the RTX 4090 at stock (measured). Rearranging the dependency graph of the same operations moves neither side Case: POW-04 | none yet. Packet: parameters the connected-state generator variant behind a flag, the census TSVs; procedure connected-state.md; raw result +1.2 pJ per lane-op at N5 on the chip side, the GPU side unmoved; reproduction none yet; review scope none; unresolved the chip side is modelled, not measured | +| 5 | "A GPU-secured network for Ethereum-compatible applications and verifiable computation." served on every page | Every page | PROPOSED; designed (served) | `docs/plans/igneum-2.0.md` (the objective: the positioning line) | `node tools/ci/ledger-text-check.mjs`: the sentence pinned (R0) on the home page, the litepaper and this page | 8 October 2026: on this page; the home page and the litepaper carry it as their 2.0 text lands (designed) Case: GOV-08 | none yet. Packet: parameters none (a served sentence); procedure the ledger-text check pins it on every page; raw result the check's count; reproduction not applicable; review scope the three external reviews the founder accepted; unresolved none | +| 6 | The chip claim as served: "Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes." Under it the three statements, separate: energy ("Current modelling estimates a 1.5x to 3.1x energy-efficiency advantage for the specialised designs assessed as complete machines against the GPU tier, from a board on commodity DRAM at 1.5x to an SRAM-store die at 3.1x (1.5x to 2.3x on the GPU's own node)." Per machine on the same node and a node ahead: the DRAM board 1.5x to 1.6x and 1.8x, the hybrid 1.9x to 2.1x and 2.4x to 2.6x, the die 2.3x and 3.1x; across the adversary's lane-count choice the same-node bracket is 1.5x to 2.1x and a node ahead 1.8x to 2.6x; 3x to 6x per dollar of hardware at list price. MODELLED: the GPU side measured, the chip's core placed and routed, the rest of the machine modelled, no chip measured, hardware cost approximate within 2x), economic and response capability, rotation an optional improvement. Class v5 derives the dataset from chain state; whether that excludes a specialised design is under evaluation (Deliverable 3), since a design that tracks state is not excluded by staleness. The dataset policy (PROPOSED; the genesis size is the founder's decision, pending; no size served as decided): "The dataset’s size is a one-off hardware ticket on specialised designs and a running energy tax on commodity cards: at 4 to 5.5 GiB a locked Blackwell card pays 12 to 14 percent more energy per hash than at 1 GiB (an 8 GB AMD card under 3 percent of rate), while the board on commodity DRAM pays nothing and the SRAM designs pay a hardware cost that does not change their outcome. So the genesis size is the founder’s decision on that scoring, pending (this lane’s recommendation 4 GiB, the largest size that keeps every entry card and a 12 GB card’s mining and proving together), and every later step is scored at 5 percent against it and taken only when the chain’s own state outgrows the dataset, not on a calendar." (PROPOSED; the energy-against-size curve on the litepaper: 1, 2, 4 and 5.5 GiB at stock and at the lock measured on an RTX 5090 against its own 1 GiB control, +0.7 and +4.3 percent at stock, +11.7 and +13.4 at the lock for 4 and 5.5 GiB, the 2 GiB knee cell a paired read in flight; the exclusions by memory; the SRAM tickets modelled). The energy ratio is not the pass criterion: the coexistence model ([docs/analysis/class-v6/coexistence-model.md](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/coexistence-model.md)) is, and its first run's result is served with its conditions: A specialised supplier may earn a normal return; ordinary GPUs remain sufficiently close in total cost, widely obtainable and useful outside mining that new operators can still compete. On today's modelled rows that holds for the chip anyone can build, a stored-dataset board on commodity DRAM, at a productive life of one to three years: its cost per accepted unit of work sits within the range of the best GPU owner and entrant, it passes six of the seven conditions (a third of the network in boards now costs less than a year's revenue at the final hardware price), and a fleet of it holds a minority of the network with GPU entrants still setting the price. For the SRAM-store die the outcome turns on its hardware cost per unit of work, not its energy advantage: at the reconciled machine cost, set by the power train and the shadow core rather than the die, it fails the cost, hardware, fleet and margin conditions at every point of the band, a modest fleet holds about two fifths of a growing network and three fifths of a flat one on arrival and takes every flat or shrinking network within five years, and the only coexistence-shaped outcome is private supply in a growing network; what holds it is the investment decision, since its economics are project economics. A third design, a DRAM board with the hottest half of the dataset in on-board SRAM, sits between the two: it coexists only in a growing network at cheap GPU electricity and fails the cost conditions in a flat or shrinking one, and the dataset's size floor is a real lever on it where it was none on the SRAM die. What holds the die is the investment decision, not the hash; every chip figure here is modelled, not measured, and the chip's hardware cost per unit of work is approximate within 2x. | The litepaper (the chip model) | MODELLED; designed (the bracket modelled; the GPU side tested by the team) | `docs/design/class-v6-rotating-family.md` section 10 (10.0h to 10.0n, 8 October 2026); `docs/plans/igneum-2.0.md` D3 and D4 | the scoring rule in the close (the minimum over workloads of the maximum over free adversarial designs of the GPU's joules per hash over the adversary's, under the 10 percent GPU-cost budget at the lock, the verifier limit, cross-vendor correctness and hardware accessibility); the placed rows are D3's | the GPU side measured: the RTX 5080 at its 1,100 MHz lock 2.06 microjoules per hash and the RTX 5090 at its 1,300 MHz lock 2.33 (8 October 2026, the project's own rigs and rented pods); the chip side synthesised and claimed, its placed gated row pending Case: ADV-01 | none yet. Packet: parameters the placed full 18-family core on ASAP7, claimed node scaling, the GDDR7 board, the RTX 5090 at its 1,300 MHz lock on class v4; procedure class-v6-rotating-family.md section 10 and coexistence-model.md; raw result the energies and verdicts as served; reproduction none yet; review scope three external reviews of the close, findings taken; unresolved no chip measured, hardware cost approximate within 2x, the k lane's 32-lane placed row pending | +| 7 | Mining and proving together on one card needs a 16 GB card at the proposed 5.5 GiB dataset (the genesis size is pending the founder’s decision; at a smaller dataset the miner holds less and the rule is not yet measured): the miner holds about 6.1 GiB and a compressed shard proof peaks at about 7.5 GiB, so 8 GB and 12 GB cards time-share (the app pauses the miner for the proof). NVIDIA proves; AMD and Apple mine | The litepaper (Proving, vs RandomX); the miner page | TEAM-REPORTED; tested by the team | `docs/analysis/class-v6/coexist-rows.md` (the 5.5 GiB ds55 miner beside igneum-prove-host-0317, compressed at threshold 2^26, the served sm_86 and sm_89 floors) | the RESULT rows in that file, verbatim from the runs | rented RTX 3060 12 GB: 26.82 MH/s at 117.4 W with 6,129 MiB resident; the compressed shard 13.2 s, peak 7,525 MiB (6,129 + 7,525 = 13,654 MiB against 12,288); rented RTX 4060 8 GB: 18.84 MH/s, 6,116 MiB resident; the shard 8.2 s, peak 7,532 MiB; 8 October 2026 Case: GPU-05 | none yet. Packet: parameters the 5.5 GiB ds55 miner, igneum-prove-host-0317 compressed at threshold 2^26, sm_86 and sm_89; procedure coexist-rows.md; raw result the RESULT rows verbatim; reproduction none yet; review scope none; unresolved two cards on one day, the 6 October rows stand as 1 GiB-dataset rows | ## Count by status diff --git a/docs/plans/igneum-2.0-test-registry.json b/docs/plans/igneum-2.0-test-registry.json new file mode 100644 index 000000000..e384b9e2c --- /dev/null +++ b/docs/plans/igneum-2.0-test-registry.json @@ -0,0 +1,3998 @@ +{ + "title": "IGNEUM 2.0 - Test and Acceptance Standard", + "version": "1.0", + "date": "2026-10-08", + "status": "PROPOSED - NOT EXECUTED", + "basis": "IGNEUM_2.0_Plan.pdf, 37 pages, 8 October 2026", + "suites": [ + { + "code": "GOV", + "title": "Release identity and evidence", + "source": [ + 5, + 21, + 23, + 25, + 26, + 27 + ], + "gate": "G0 / all gates", + "owner": "Release lead + independent assurance", + "fixtures": "F0 manifest; F1 source/build archives; F9 evidence vault", + "summary": "Prevent a favourable result from being attached to the wrong code, assumptions or public claim.", + "tests": [ + { + "id": "GOV-01", + "title": "Freeze the release and its claims", + "setup": "Candidate source, binaries, public documentation and the 2.0 plan are available; no run is yet accepted.", + "steps": [ + "Record exact commits, binary hashes, dependencies, genesis/network identity, mining class, datasets, execution fork, verifier IDs and fee rules in F0.", + "Map every promised capability and plan requirement to a test ID; distinguish supported mining, proving and wallet combinations.", + "Sign the manifest with protocol, product and independent review owners before confirmatory runs." + ], + "accept": "Every material rule and claim has an unambiguous version and test. Conflicts or unknown activation rules produce BLOCKED, not an inferred default. Changes create a new manifest and invalidate affected results.", + "evidence": "Signed F0; source-to-test map; claim inventory; unresolved-field register.", + "priority": "BLOCKER", + "profile": "P00", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 5, + 21, + 23, + 25, + 26, + 27 + ], + "gate": "G0 / all gates", + "owner": "Release lead + independent assurance", + "manual_page": 18 + }, + { + "id": "GOV-02", + "title": "Approve thresholds before results", + "setup": "This manual supplies proposed test thresholds, not source-approved protocol parameters.", + "steps": [ + "Approve or replace every P-profile before confirmatory testing; give each change a rationale and independent approver.", + "Register hardware cohorts, mandatory economic worlds, customer workloads, peer dimensions and exclusion rules.", + "Lock the profile hash and hold out seeds/workloads from the developers doing optimisation." + ], + "accept": "No decision-critical field is TBD. Numeric limits are frozen, commercially meaningful and not chosen from observed results. A weakened limit after failure requires a new protocol, full affected rerun and explicit claim downgrade review.", + "evidence": "Approved profile register; timestamped holdout commitments; change log.", + "priority": "BLOCKER", + "profile": "P00", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 5, + 21, + 23, + 25, + 26, + 27 + ], + "gate": "G0 / all gates", + "owner": "Release lead + independent assurance", + "manual_page": 18 + }, + { + "id": "GOV-03", + "title": "Reproduce builds outside the founding team", + "setup": "Provide public source and documented build instructions to three unaffiliated operators.", + "steps": [ + "Build on clean declared environments without private files, tokens or founder assistance.", + "Compare reproducible payload hashes; isolate signatures, notarisation and permitted non-deterministic wrappers.", + "Run reference vectors and restart a node using only documented artifacts." + ], + "accept": "All independent builds reproduce the same consensus payload or an independently explained, pre-approved wrapper difference; reference outputs match exactly. Missing private prerequisites block release.", + "evidence": "Build logs; dependency lockfiles; binary comparison; operator attestations.", + "priority": "BLOCKER", + "profile": "P00; P02", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent reproduction", + "status": "NOT RUN", + "source": [ + 5, + 21, + 23, + 25, + 26, + 27 + ], + "gate": "G0 / all gates", + "owner": "Release lead + independent assurance", + "manual_page": 18 + }, + { + "id": "GOV-04", + "title": "Preserve raw and negative evidence", + "setup": "Enable append-only storage for run outputs and a separate analysis workspace.", + "steps": [ + "Capture failed, aborted and successful runs with timestamps, seeds and environment hashes.", + "Recompute one published figure from raw records on a clean machine.", + "Modify a retained artifact deliberately and test integrity verification." + ], + "accept": "Every headline can be regenerated; tampering is detected; exclusions have pre-registered reasons. Failed or missing runs remain visible and are never replaced silently by a successful retry.", + "evidence": "Artifact manifest; hashes; reproduction script; exclusion ledger; negative-run archive.", + "priority": "BLOCKER", + "profile": "P00", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 5, + 21, + 23, + 25, + 26, + 27 + ], + "gate": "G0 / all gates", + "owner": "Release lead + independent assurance", + "manual_page": 19 + }, + { + "id": "GOV-05", + "title": "Prove the test oracle detects broken behaviour", + "setup": "Create controlled defective variants on an isolated network only.", + "steps": [ + "Disable proof verification, change one reward, accept an expired authority set and alter one hash output in separate mutants.", + "Run the corresponding ZKP, INC, FIN and POW tests without telling the runner which mutant is active.", + "Confirm the baseline still accepts authorised valid cases." + ], + "accept": "Every deliberately introduced fault is caught by its mapped test; valid controls pass. Any undetected critical mutant blocks acceptance of that test family until the oracle is repaired.", + "evidence": "Mutation catalogue; blinded run results; baseline controls; oracle review.", + "priority": "BLOCKER", + "profile": "P01", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 5, + 21, + 23, + 25, + 26, + 27 + ], + "gate": "G0 / all gates", + "owner": "Release lead + independent assurance", + "manual_page": 19 + }, + { + "id": "GOV-06", + "title": "Enforce scope and optional-feature discipline", + "setup": "Inventory FP32 experiments, receipts/oracles and all retained or excluded mining levers.", + "steps": [ + "Mark each capability CORE, CLAIMED-OPTIONAL or EXCLUDED before release testing.", + "For excluded code, check binaries, protocol activation and product copy for accidental enablement or implied availability.", + "For each claimed option, require the complete associated test set rather than a demonstration." + ], + "accept": "Every core and claimed-option obligation passes. Excluded items are shown as EXCLUDED, never PASS and never counted as achievements. Removing a failed core requirement prevents an all-2.0-pass claim.", + "evidence": "Scope manifest; activation scan; product-copy comparison; exclusions register.", + "priority": "BLOCKER", + "profile": "P00", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 5, + 21, + 23, + 25, + 26, + 27 + ], + "gate": "G0 / all gates", + "owner": "Release lead + independent assurance", + "manual_page": 19 + }, + { + "id": "GOV-07", + "title": "Independent review and finding closure", + "setup": "Nominate reviewers with declared conflicts and scopes covering cryptography, consensus and hardware.", + "steps": [ + "Provide pinned code, raw data, adversarial models and prior failures, including negative results.", + "Track each finding to remediation and an independent retest; do not use the author as sole approver.", + "Have reviewers state unreviewed surfaces and model limitations in their signed conclusions." + ], + "accept": "No unresolved critical or high-severity finding affects the claimed release. A finite review is described by scope, not as proof of universal security. Independent reproduction and review are both evidenced.", + "evidence": "Signed scoped reports; conflict declarations; finding/retest ledger.", + "priority": "BLOCKER", + "profile": "P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent specialist review", + "status": "NOT RUN", + "source": [ + 5, + 21, + 23, + 25, + 26, + 27 + ], + "gate": "G0 / all gates", + "owner": "Release lead + independent assurance", + "manual_page": 20 + }, + { + "id": "GOV-08", + "title": "Invalidate stale evidence and control public status", + "setup": "Create a simulated post-test change to a verifier, mining class, dataset and fee rule.", + "steps": [ + "Calculate affected test dependencies and invalidate their former PASS statuses.", + "Regenerate public status pages from F0 and the evidence register.", + "Attempt to publish a rank-one, guaranteed-profit or automatic-chip-death claim without the required evidence." + ], + "accept": "Affected gates return to NOT RUN or BLOCKED. Public claims retain version, limits and date; unsupported claims are withheld. No stale result remains attached to a different release.", + "evidence": "Dependency impact report; regenerated status page; rejected claim examples.", + "priority": "BLOCKER", + "profile": "P00", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 5, + 21, + 23, + 25, + 26, + 27 + ], + "gate": "G0 / all gates", + "owner": "Release lead + independent assurance", + "manual_page": 20 + } + ] + }, + { + "code": "GPU", + "title": "Whole-system GPU measurements", + "source": [ + 6, + 7, + 8, + 14, + 18, + 23 + ], + "gate": "G1 / G2", + "owner": "GPU lead + three independent operators", + "fixtures": "F2 retail-hardware cohort; F3 paired benchmark workloads; F9 calibrated evidence", + "summary": "Close the pending measurements and evaluate the actual configuration, including costs hidden by kernel-only results.", + "tests": [ + { + "id": "GPU-01", + "title": "Cover the declared commodity population", + "setup": "Freeze the P02 cohort, supported role matrix and the final v6 configuration.", + "steps": [ + "Inventory physical SKU, usable memory, driver, operating system, firmware, cooling and acquisition channel.", + "Run mining on every supported cohort cell and proving on every separately advertised prover cell.", + "Include lower-memory, used-generation and all advertised vendor cases; retain unsupported results separately." + ], + "accept": "All declared cells are tested, with no after-the-fact removal of weak cards. At least the P02 minimum coverage is met. Mining-only support is never reported as proof-generation support.", + "evidence": "Cohort manifest; compatibility matrix; raw results by SKU and role.", + "priority": "GATE", + "profile": "P02", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 6, + 7, + 8, + 14, + 18, + 23 + ], + "gate": "G1 / G2", + "owner": "GPU lead + three independent operators", + "manual_page": 21 + }, + { + "id": "GPU-02", + "title": "Reproduce Ember clock-lock savings", + "setup": "Use paired stock and tuned runs on the same board, host, workload and ambient conditions.", + "steps": [ + "Warm to stability; randomise stock/tuned order and run P02 repeated sessions.", + "Measure accepted work, calibrated wall energy, device telemetry and rejected work.", + "Calculate paired energy and rate changes with run-level uncertainty, retaining failed tuning attempts." + ], + "accept": "Tuning preserves correctness and meets approved P03 operating limits. The historical 34-41% saving and under-2% rate-loss statement is reproduced only for qualifying configurations; otherwise that claim is corrected. Existing savings are not counted twice.", + "evidence": "Raw power/time series; paired analysis; tuning settings; claim-by-SKU table.", + "priority": "GATE", + "profile": "P02; P03", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 6, + 7, + 8, + 14, + 18, + 23 + ], + "gate": "G1 / G2", + "owner": "GPU lead + three independent operators", + "manual_page": 21 + }, + { + "id": "GPU-03", + "title": "Measure the real 64-register GPU cost", + "setup": "Build the baseline and window variant with identical dataset, reads and semantic workload.", + "steps": [ + "Inspect compiled register allocation, spills, occupancy and memory traffic on each supported backend.", + "Measure paired complete-system energy and accepted throughput, including host work.", + "Repeat during proving coexistence and expose any memory or scheduling cliff." + ], + "accept": "Any production window meets P03 budgets for every mandatory SKU; no hidden spills or correctness changes. Zero GPU cost is claimed only where measurement supports it within uncertainty. Results feed the redesigned adversary, not an old core estimate.", + "evidence": "Compiler reports; allocation traces; paired energy/rate data; coexistence runs.", + "priority": "GATE", + "profile": "P02; P03", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 6, + 7, + 8, + 14, + 18, + 23 + ], + "gate": "G1 / G2", + "owner": "GPU lead + three independent operators", + "manual_page": 21 + }, + { + "id": "GPU-04", + "title": "Find the memory-clock operating ladder", + "setup": "Use safe vendor-supported settings only; record operator permission and original settings.", + "steps": [ + "Sweep approved core and memory operating points while holding workload constant.", + "Measure error rate, accepted throughput, wall energy and thermal equilibrium.", + "Repeat the selected knee after reboot and restore defaults after a failed or interrupted tuning session." + ], + "accept": "Selected profiles are stable, reproducible and not dependent on unsafe clocks. Every accepted hash remains correct; saved settings restore predictably. Tuning failure leaves a working safe configuration.", + "evidence": "Clock ladder; safe bounds; thermal/error logs; reboot and rollback record.", + "priority": "BLOCKER", + "profile": "P01; P02", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 6, + 7, + 8, + 14, + 18, + 23 + ], + "gate": "G1 / G2", + "owner": "GPU lead + three independent operators", + "manual_page": 22 + }, + { + "id": "GPU-05", + "title": "Test dataset fit and support-horizon costs", + "setup": "Test 5.5, 8.5 and 11.5 GiB only as source-proposed candidates; F0 determines activated sizes.", + "steps": [ + "Measure allocation plus driver, display, prover and OS headroom on the 8 GB and other cohort tiers.", + "Run near-full-memory, fragmentation, restart and next-epoch construction scenarios.", + "Compare time-sharing/eviction with concurrent mining/proving, including reload cost." + ], + "accept": "Every advertised combination completes without OOM or silent corruption. Unsupported future sizes are identified before activation. GPU exclusions and lost proving capacity appear in ECO evaluation; retirement of a tier is not a success metric.", + "evidence": "Memory budget per SKU; OOM traces; support horizon; concurrency cost table.", + "priority": "BLOCKER", + "profile": "P01; P02; P06", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 6, + 7, + 8, + 14, + 18, + 23 + ], + "gate": "G1 / G2", + "owner": "GPU lead + three independent operators", + "manual_page": 22 + }, + { + "id": "GPU-06", + "title": "Measure accepted work under ordinary connectivity", + "setup": "Use the same hardware against clean, delayed, lossy and intermittent links in F4.", + "steps": [ + "Measure kernel rate and accepted work separately under home and datacentre link profiles.", + "Include reconnects, template changes, expired submissions and pool failover.", + "Attribute loss to network, local software, validation and protocol causes." + ], + "accept": "Results use accepted work, never kernel rate alone. Ordinary-link incremental rejection stays within P10; all losses remain priced in ECO. Unreachable links may pause but must not claim paid work.", + "evidence": "Per-submission ledger; network trace; rejection reasons; accepted-work comparison.", + "priority": "GATE", + "profile": "P02; P10", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 6, + 7, + 8, + 14, + 18, + 23 + ], + "gate": "G1 / G2", + "owner": "GPU lead + three independent operators", + "manual_page": 22 + }, + { + "id": "GPU-07", + "title": "Survive sustained thermal and power operation", + "setup": "Run the selected profile on actual reference machines for the P02 soak period.", + "steps": [ + "Track wall power, temperatures, clocks, memory and accepted work continuously.", + "Inject safe power interruptions, process restarts and normal competing desktop load.", + "Check restored settings and compare late-run efficiency with the first stable period." + ], + "accept": "No invalid work or unsafe persistent settings; P02/P10 stability limits hold. Thermal throttling, crashes and recovery time remain in throughput and energy denominators. A crash-free short benchmark cannot substitute for the soak.", + "evidence": "Seven-day time series; crash reports; settings-restoration checks; drift analysis.", + "priority": "BLOCKER", + "profile": "P01; P02; P10", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 6, + 7, + 8, + 14, + 18, + 23 + ], + "gate": "G1 / G2", + "owner": "GPU lead + three independent operators", + "manual_page": 23 + }, + { + "id": "GPU-08", + "title": "Reproduce the full baseline independently", + "setup": "Three unaffiliated operators receive F0, F2 and F3, including the final miner/prover build.", + "steps": [ + "Repeat identical-SKU paired runs with documented meter calibration and environment differences.", + "Recompute joules and total cost per accepted work from the shared raw schema.", + "Investigate divergence before accepting a pooled headline or uncertainty band." + ], + "accept": "Reproductions meet P02 tolerance and exact correctness. No unexplained divergence or selectively missing low-end cell remains. Report manufactured GPU measurements separately from modelled specialist estimates.", + "evidence": "Three signed reproduction packs; reconciliation report; final baseline table.", + "priority": "GATE", + "profile": "P02", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent reproduction", + "status": "NOT RUN", + "source": [ + 6, + 7, + 8, + 14, + 18, + 23 + ], + "gate": "G1 / G2", + "owner": "GPU lead + three independent operators", + "manual_page": 23 + } + ] + }, + { + "code": "POW", + "title": "Proof-of-work correctness and coupling", + "source": [ + 7, + 9, + 10, + 23 + ], + "gate": "G2 / technical readiness", + "owner": "Cryptography + GPU lead", + "fixtures": "F0 rule set; F3 independent CPU/GPU oracles; F5 mutation corpus", + "summary": "Find semantic disagreements and structural shortcuts before treating a harder-looking program as a stronger defence.", + "tests": [ + { + "id": "POW-01", + "title": "Match independent execution across every backend", + "setup": "Implement an independently written reference evaluator, not a wrapper around the production GPU path.", + "steps": [ + "Execute the P01 corpus across every family, boundary seed and supported backend.", + "Exercise zero, maximum, sign, shift, rotate, overflow and unaligned-address cases allowed by the spec.", + "Minimise every mismatch and rerun it on clean builds." + ], + "accept": "Bit-for-bit agreement for all valid cases and identical rejection for invalid cases. One unexplained mismatch is a blocker. Large sample counts are evidence of testing, not proof that unseen disagreements cannot exist.", + "evidence": "Reference implementation review; seeds/vectors; backend matrix; mismatch archive.", + "priority": "BLOCKER", + "profile": "P01", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 9, + 10, + 23 + ], + "gate": "G2 / technical readiness", + "owner": "Cryptography + GPU lead", + "manual_page": 24 + }, + { + "id": "POW-02", + "title": "Validate generated programs and index folding", + "setup": "Use the frozen grammar, opcode semantics and index-fold rule; include boundary and malformed programs.", + "steps": [ + "Enumerate small constrained programs and fuzz the full generator at P01 depth.", + "Check bounds, valid dependencies, address distribution and forbidden encodings.", + "Compare source-level operations with optimised compiled code for removed or altered work." + ], + "accept": "No accepted program violates semantics, termination or memory bounds. Distribution claims have predeclared tests and effect-size limits; passing randomness checks is not treated as a cryptographic proof.", + "evidence": "Generator/fuzzer logs; reduced counterexamples; disassembly comparison; index tests.", + "priority": "BLOCKER", + "profile": "P01", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 9, + 10, + 23 + ], + "gate": "G2 / technical readiness", + "owner": "Cryptography + GPU lead", + "manual_page": 24 + }, + { + "id": "POW-03", + "title": "Test whether live state is unavoidable", + "setup": "Take the 64-register candidate and the cheapest independently proposed storage organisations.", + "steps": [ + "Trace value liveness across dependent reads and final output, distinguishing distinct information from duplicated values.", + "Try banking, compression, recomputation, fewer ports and time-multiplexed contexts.", + "Quantify the best complete-system cost/throughput trade-off rather than the reference register count." + ], + "accept": "Production selection is supported by measured or physically modelled penalties after these alternatives. G2 requires the P03 improvement; an attractive source-level register count alone does not pass.", + "evidence": "Liveness traces; alternative implementations; Pareto table; reviewer analysis.", + "priority": "GATE", + "profile": "P03; P04", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Experiment + independent hardware review", + "status": "NOT RUN", + "source": [ + 7, + 9, + 10, + 23 + ], + "gate": "G2 / technical readiness", + "owner": "Cryptography + GPU lead", + "manual_page": 24 + }, + { + "id": "POW-04", + "title": "Evaluate connected-resource restructuring", + "setup": "Use a candidate initially matched to baseline instruction count, read count and dataset size.", + "steps": [ + "Connect state, addresses, arithmetic and lane communication according to the written hypothesis.", + "Measure GPU cost and allow the specialist reviewer to redesign the entire core.", + "Repeat on held-out program seeds and compare the worst supported adversary, not only the original design." + ], + "accept": "The selected upgrade meets P03 and improves the adversarial result outside declared uncertainty. A negative experiment remains a negative outcome; adopting a different design requires a new frozen comparison.", + "evidence": "Matched workloads; GPU runs; redesigned core estimates; held-out results.", + "priority": "GATE", + "profile": "P03; P04", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Controlled experiment", + "status": "NOT RUN", + "source": [ + 7, + 9, + 10, + 23 + ], + "gate": "G2 / technical readiness", + "owner": "Cryptography + GPU lead", + "manual_page": 25 + }, + { + "id": "POW-05", + "title": "Prevent amortised cheap winning attempts", + "setup": "Prepare valid templates, nonces, intermediate-state captures and independent acceptance checks.", + "steps": [ + "Vary nonce, payout identity, transactions, roots and other committed fields after expensive work.", + "Try replay, precomputation, shared prefixes, partial evaluation and many cheap suffix candidates.", + "Price any valid strategy against fresh evaluation; independently review all bindings." + ], + "accept": "Invalid modifications are rejected. Any valid cost-saving strategy is incorporated into ADV and must still meet P04/ECO gates. No unresolved shortcut is hidden behind passing reference vectors.", + "evidence": "Attack implementations; valid/invalid controls; work-cost analysis; binding review.", + "priority": "BLOCKER", + "profile": "P01; P04", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 9, + 10, + 23 + ], + "gate": "G2 / technical readiness", + "owner": "Cryptography + GPU lead", + "manual_page": 25 + }, + { + "id": "POW-06", + "title": "Bound verifier work and malformed-input cost", + "setup": "Use ordinary CPU validators with a manifest-defined resource budget and untrusted submissions.", + "steps": [ + "Submit shortest/longest programs, malformed encodings and adversarial memory references.", + "Measure verification time, peak memory and work amplification across valid and invalid inputs.", + "Sustain the approved hostile request rate while ordinary valid traffic continues." + ], + "accept": "All semantics remain correct and P09 resource budgets hold. Invalid traffic cannot cause unbounded allocation, crashes or disproportionate free work. Rate limits must not replace consensus validation.", + "evidence": "CPU profiles; adversarial corpus; allocation traces; valid-traffic latency.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 9, + 10, + 23 + ], + "gate": "G2 / technical readiness", + "owner": "Cryptography + GPU lead", + "manual_page": 25 + }, + { + "id": "POW-07", + "title": "Constrain any mixed-resource or FP32 branch", + "setup": "If this branch is excluded, verify that it is unreachable and not claimed; if included, use a separate frozen candidate.", + "steps": [ + "Specify exact rounding, fusion, special values and backend behaviour before compiling.", + "Differentially test all supported architectures and allow numerical-domain simplification in the specialist model.", + "Include verifier cost and candidate energy in P03/P04, not just arithmetic-unit area." + ], + "accept": "Included branches achieve exact agreed semantics and all hardware budgets. An excluded branch earns no performance credit. No approximate operation or unspecified compiler choice enters consensus.", + "evidence": "Scope decision; semantic specification; vectors; simplified datapath model.", + "priority": "BLOCKER", + "profile": "P00; P01; P03", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Conditional implementation test", + "status": "NOT RUN", + "source": [ + 7, + 9, + 10, + 23 + ], + "gate": "G2 / technical readiness", + "owner": "Cryptography + GPU lead", + "manual_page": 26 + }, + { + "id": "POW-08", + "title": "Keep rejected mechanisms out of the shipped claim", + "setup": "Inventory long programs, select trees, SM gating, wider reads, sealed classes, random epoch lengths, per-tier scoring and VRF draws.", + "steps": [ + "Retain their historic negative tests and realistic SRAM instruction-memory control.", + "Inspect the release for reintroduction through renamed settings or hidden paths.", + "Require a new written hypothesis and complete adversarial retest for any proposed return." + ], + "accept": "Excluded levers remain excluded unless separately approved and retested. Flip-flop instruction-memory area is never presented as the cost of a realistic SRAM implementation.", + "evidence": "Decision register; binary/config scan; negative-control results.", + "priority": "GATE", + "profile": "P00; P03", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 9, + 10, + 23 + ], + "gate": "G2 / technical readiness", + "owner": "Cryptography + GPU lead", + "manual_page": 26 + } + ] + }, + { + "code": "ADV", + "title": "Programmable specialist adversaries", + "source": [ + 8, + 10, + 12, + 22, + 23 + ], + "gate": "G3", + "owner": "Independent hardware team", + "fixtures": "F2 reference GPUs; F6 RTL/physical models; all published families", + "summary": "Give the opponent permission to adapt, share resources and remain operational; test cost rather than imagined chip death.", + "tests": [ + { + "id": "ADV-01", + "title": "Build a multi-family programmable opponent", + "setup": "Provide the complete published family bank and future known parameter schedule to the reviewer.", + "steps": [ + "Design one programmable architecture that supports all retained families, including firmware and emulation paths.", + "Optimise clocks, lanes, ports and pipelines without requiring a graphics-card layout.", + "Verify its outputs against POW vectors before measuring any advantage." + ], + "accept": "At least the P04 design diversity is evaluated; every estimated competitive design is functionally validated. Inability of one narrow design to adapt is not evidence that all chips expire.", + "evidence": "Architecture reports; functional simulations; adaptation matrix; reviewer signature.", + "priority": "GATE", + "profile": "P01; P04", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent hardware study", + "status": "NOT RUN", + "source": [ + 8, + 10, + 12, + 22, + 23 + ], + "gate": "G3", + "owner": "Independent hardware team", + "manual_page": 27 + }, + { + "id": "ADV-02", + "title": "Price shared, reduced and reconstructed memory", + "setup": "Allow multiple engines to share a dataset and to store selected fractions rather than a complete per-engine copy.", + "steps": [ + "Sweep sharing factors, memory fractions, caches and recomputation depth across many simultaneous hashes.", + "Include construction/update amortisation, bandwidth contention and retained state.", + "Take the most favourable feasible point for the specialist into the complete-board model." + ], + "accept": "No omitted feasible trade-off materially lowers the accepted cost estimate. Any winning alternative is included in P04 and ECO; capacity alone is not accepted as an energy bound.", + "evidence": "Sweep definitions; energy/bandwidth data; best-feasible envelope; excluded-design reasons.", + "priority": "GATE", + "profile": "P04", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Model + adversarial implementation", + "status": "NOT RUN", + "source": [ + 8, + 10, + 12, + 22, + 23 + ], + "gate": "G3", + "owner": "Independent hardware team", + "manual_page": 27 + }, + { + "id": "ADV-03", + "title": "Attack with data-local and hybrid execution", + "setup": "Permit distributed memories, state migration and companion CPU/GPU/FPGA components.", + "steps": [ + "Compare moving computation, intermediate state or fetched data to each read location.", + "Test specialised mining alongside outsourced proof generation rather than assuming one physical GPU does both.", + "Include interconnect, host, synchronisation, idle and conversion costs." + ], + "accept": "The cheapest feasible combined system is included in the adversarial envelope and economic model. A worker identity or account is never treated as proof of a single physical device.", + "evidence": "Hybrid architecture diagrams; traffic traces; system cost and energy ledger.", + "priority": "GATE", + "profile": "P04", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent system modelling", + "status": "NOT RUN", + "source": [ + 8, + 10, + 12, + 22, + 23 + ], + "gate": "G3", + "owner": "Independent hardware team", + "manual_page": 27 + }, + { + "id": "ADV-04", + "title": "Measure profitable selective participation", + "setup": "Use all declared families plus held-out generated programs and the protocol difficulty rule.", + "steps": [ + "Identify favourable execution paths and add cheap fallbacks for other periods.", + "Simulate entry/exit around profitable periods, including idle time, compilation and re-entry costs.", + "Evaluate revenue and costs across the full schedule, not just average program energy." + ], + "accept": "Intermittent specialists meet P04/ECO limits when evaluated on full-period economics. A weak tail cannot be concealed by a favourable mean; known valid shortcuts must be priced.", + "evidence": "Per-program advantage distribution; policy simulator; full-period returns.", + "priority": "GATE", + "profile": "P04; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 10, + 12, + 22, + 23 + ], + "gate": "G3", + "owner": "Independent hardware team", + "manual_page": 28 + }, + { + "id": "ADV-05", + "title": "Validate physical and complete-board costs", + "setup": "Use feasible process/library assumptions and documented component boundaries; no fabricated foundry access.", + "steps": [ + "Model SRAM macros, ports, wiring, clocking, memory PHYs, external memory, host and power conversion.", + "Run place-and-route where available; mark unmodelled items as uncertainty rather than zero.", + "Compare against a calibrated existing hardware block or equivalent validation case." + ], + "accept": "No decision-critical cost is omitted. Physically unvalidated or proprietary estimates are labelled and independently bounded; synthesis alone cannot earn a manufactured-chip claim.", + "evidence": "Netlist/physical reports; macro assumptions; bill of materials; model calibration.", + "priority": "GATE", + "profile": "P04", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent physical-design review", + "status": "NOT RUN", + "source": [ + 8, + 10, + 12, + 22, + 23 + ], + "gate": "G3", + "owner": "Independent hardware team", + "manual_page": 28 + }, + { + "id": "ADV-06", + "title": "Separate process advantage from specialisation", + "setup": "Evaluate same-node, one-node-ahead and two-node-ahead scenarios with explicit technology definitions.", + "steps": [ + "Use independently justified process factors, voltages, memory and packaging assumptions for each design.", + "Allow reusable IP and modular revisions; credit GPU improvement consistently.", + "Evaluate measurement confidence and model-parameter sensitivity separately." + ], + "accept": "P04 primary limits hold for all competitive-reference cells; two-node futures are reported and pass the predeclared economic stress envelope. A model range is never labelled a statistical confidence interval without justification.", + "evidence": "Node-specific reports; factor provenance; uncertainty and sensitivity tables.", + "priority": "GATE", + "profile": "P04; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 10, + 12, + 22, + 23 + ], + "gate": "G3", + "owner": "Independent hardware team", + "manual_page": 28 + }, + { + "id": "ADV-07", + "title": "Evaluate lifetime without forced obsolescence", + "setup": "Assume multi-year productive survival and known schedule support before testing optional retirement penalties.", + "steps": [ + "Price firmware, emulation, memory expansion, companion hardware and incremental redesign.", + "Include 1-, 3- and 5-year productive lifetimes plus idle/resale possibilities.", + "Grant a retirement credit only if all feasible cheaper adaptations lose competitiveness." + ], + "accept": "The primary case does not require chip death or a fresh full development bill per family. Every retirement credit has a documented adaptation comparison; incompatible and unprofitable are reported separately.", + "evidence": "Lifetime/adaptation ledger; revision costs; feasible-alternative analysis.", + "priority": "GATE", + "profile": "P04; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 10, + 12, + 22, + 23 + ], + "gate": "G3", + "owner": "Independent hardware team", + "manual_page": 29 + }, + { + "id": "ADV-08", + "title": "Independently challenge the best-cost envelope", + "setup": "Publish the non-sensitive model and negative results; commission an unaffiliated second hardware reviewer.", + "steps": [ + "Reward cheaper valid designs and reproduced shortcuts, not confirmation of the preferred number.", + "Re-run P04 with the strongest submitted feasible design, including a low-cost funded-development case.", + "Record unresolved modelling disagreements and future technology exclusions." + ], + "accept": "Both reviews accept the scoped envelope or all material disagreements are resolved transparently. Passing supports only evaluated designs and conditions, never a universal bound on all future silicon.", + "evidence": "Two review reports; challenge log; final envelope; unresolved-limit statement.", + "priority": "GATE", + "profile": "P04", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent challenge/review", + "status": "NOT RUN", + "source": [ + 8, + 10, + 12, + 22, + 23 + ], + "gate": "G3", + "owner": "Independent hardware team", + "manual_page": 29 + } + ] + }, + { + "code": "ROT", + "title": "Epochs, seeds and memory transitions", + "source": [ + 7, + 11, + 19, + 21 + ], + "gate": "G5 / G2", + "owner": "Consensus + GPU leads", + "fixtures": "F0 activation rules; F4 fault network; F5 historical and boundary vectors", + "summary": "Transitions must agree across nodes and remain usable during failures; crossing a boundary is not a chip-retirement test.", + "tests": [ + { + "id": "ROT-01", + "title": "Agree across every hourly boundary", + "setup": "Use real nodes, CPU/GPU miners and independent clocks around successive program boundaries.", + "steps": [ + "Submit valid work immediately before, at and after the activation boundary under clock skew and delayed delivery.", + "Restart nodes from both sides and replay the same headers.", + "Compare selected seed, program, validity, rewards and local wall-clock dependence." + ], + "accept": "All honest nodes derive identical consensus outcomes from the frozen rule. Late work is handled exactly as specified; no wall-clock ambiguity or cross-backend split occurs.", + "evidence": "Boundary vectors; node/miner traces; acceptance and reward matrix.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 11, + 19, + 21 + ], + "gate": "G5 / G2", + "owner": "Consensus + GPU leads", + "manual_page": 30 + }, + { + "id": "ROT-02", + "title": "Cross weekly and family boundaries together", + "setup": "Use the retained schedule in F0, including coincident program, parameter and family changes.", + "steps": [ + "Run every known family transition and all coincident-boundary combinations on production code.", + "Interrupt downloads, compilation and restart during activation; include mixed old/new clients.", + "Repeat selected cases under real elapsed time and the remainder under disclosed accelerated time." + ], + "accept": "Deterministic activation, documented old-client behaviour and no unsafe fallback. Compilation/setup costs satisfy P03; accelerated runs are not reported as years of operating history.", + "evidence": "Transition matrix; code-path evidence; compile timing; old-client logs.", + "priority": "BLOCKER", + "profile": "P01; P03; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 11, + 19, + 21 + ], + "gate": "G5 / G2", + "owner": "Consensus + GPU leads", + "manual_page": 30 + }, + { + "id": "ROT-03", + "title": "Test miner-voted bring-forward governance", + "setup": "Freeze eligibility, threshold, windows and activation semantics before testing; do not invent a no-veto rule.", + "steps": [ + "Attempt threshold-minus-one, threshold, conflicting proposals, duplicate votes and coalition withholding.", + "Partition voters, restore them and test vote-key substitution through pools.", + "Verify adoption and refusal behaviour of already running nodes." + ], + "accept": "The actual mechanism enforces F0, with authenticated voting and no conflicting activation. Any coalition capable of blocking or manipulating changes is disclosed; labels such as no veto do not override arithmetic.", + "evidence": "Executable governance model; signed-vote corpus; coalition/partition results.", + "priority": "BLOCKER", + "profile": "P00; P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 11, + 19, + 21 + ], + "gate": "G5 / G2", + "owner": "Consensus + GPU leads", + "manual_page": 30 + }, + { + "id": "ROT-04", + "title": "Resist seed selection and faster evaluators", + "setup": "Provide the specified seed pipeline and delay proof implementation plus independently parameterised fast-adversary models.", + "steps": [ + "Try withholding candidate seeds, grinding alternatives, replaying delay proofs and biased checkpoint selection.", + "Vary adversarial speed advantage and outage duration; trace influence on program choice.", + "Validate inputs, parameters and proofs against independent vectors." + ], + "accept": "No invalid seed or proof is accepted; selection advantage stays within the approved threat-model bound. Missing bounds block this gate. A delay mechanism is not credited as generic ASIC resistance.", + "evidence": "Seed/grinding simulations; speed sensitivity; proof vectors; threat-model signoff.", + "priority": "BLOCKER", + "profile": "P00; P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 11, + 19, + 21 + ], + "gate": "G5 / G2", + "owner": "Consensus + GPU leads", + "manual_page": 31 + }, + { + "id": "ROT-05", + "title": "Continue or pause correctly when finality stops", + "setup": "Stop checkpoint signing while mining continues, then cross seed and family boundaries.", + "steps": [ + "Remove the required signing weight and observe the documented fallback or safe pause.", + "Prevent access to any founder seed service; restart from persisted state.", + "Restore the stated fault assumptions and verify deterministic recovery." + ], + "accept": "Mining/seed behaviour matches F0 without manufacturing certificates or reinterpreting finality. Safety holds during the outage; liveness is required only after its stated assumptions return.", + "evidence": "Fault timeline; seed/certificate history; node-state comparison; recovery log.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 11, + 19, + 21 + ], + "gate": "G5 / G2", + "owner": "Consensus + GPU leads", + "manual_page": 31 + }, + { + "id": "ROT-06", + "title": "Activate datasets without hidden exclusions", + "setup": "Freeze memory sizes, support horizon and sync/update procedure; test all advertised roles.", + "steps": [ + "Construct the next dataset while current work remains active; test slow disks, low free memory and interruption.", + "Try stale-state/dataset submissions and maliciously expensive state growth where coupling exists.", + "Measure data transfer, restart and excluded-card costs before approving progression." + ], + "accept": "No invalid stale work is accepted, no supported card silently fails, and P06 is met. Hardware retirement and sync burden are included in the economic decision, not treated as automatic chip protection.", + "evidence": "Dataset hashes; memory/update traces; stale-work tests; exclusion decision.", + "priority": "BLOCKER", + "profile": "P01; P06", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 11, + 19, + 21 + ], + "gate": "G5 / G2", + "owner": "Consensus + GPU leads", + "manual_page": 31 + }, + { + "id": "ROT-07", + "title": "Ablate redundant rotation layers", + "setup": "Use matched baseline and ablated variants in the lab; do not change a running public network.", + "steps": [ + "Remove each weekly/family component independently and measure adversarial cost, GPU setup and verifier complexity.", + "Include favourable-period specialists and all retained known families.", + "Keep a layer only with a distinct, independently supported benefit or a documented non-resistance purpose." + ], + "accept": "Every retained layer has explicit justification and full boundary coverage. Redundant complexity is removed or its rationale recorded; the security model does not double-count the same versatility cost.", + "evidence": "Ablation report; decision log; complexity/cost comparison.", + "priority": "GATE", + "profile": "P03; P04", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 11, + 19, + 21 + ], + "gate": "G5 / G2", + "owner": "Consensus + GPU leads", + "manual_page": 32 + }, + { + "id": "ROT-08", + "title": "Pass the no-new-rules counterfactual", + "setup": "Freeze the complete published rule bank and known schedule for the five-year evaluation.", + "steps": [ + "Allow a programmable adversary to know and survive all planned changes.", + "Remove assumed future emergency instructions and manual retirement actions from the model.", + "Run the required ECO scenarios and link them to independent network-transition tests." + ], + "accept": "Competitiveness survives the approved envelope without future rescue assumptions. Any result that needs unannounced changes fails this claim; ordinary bug maintenance is distinguished from anti-chip intervention.", + "evidence": "Frozen-rule model; scenario results; excluded-rescue audit; G5 evidence.", + "priority": "GATE", + "profile": "P04; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 7, + 11, + 19, + 21 + ], + "gate": "G5 / G2", + "owner": "Consensus + GPU leads", + "manual_page": 32 + } + ] + }, + { + "code": "ECO", + "title": "Five-year coexistence economics", + "source": [ + 8, + 13, + 18, + 24, + 26 + ], + "gate": "G4", + "owner": "Economics lead + independent reviewer", + "fixtures": "F6 adversarial costs; F7 scenario model; F2 operator costs", + "summary": "Test the world after specialised hardware exists, including new entrants and an already-funded competitor.", + "tests": [ + { + "id": "ECO-01", + "title": "Reconcile complete cost per accepted work", + "setup": "Use benchmark outputs, current-source cost inputs recorded at execution time and separate reference scenarios.", + "steps": [ + "Calculate hardware annualisation, electricity, host, cooling/hosting, failures, fees, downtime and residual value.", + "Use actual accepted work and independently verify units and period conversions.", + "Cross-check formulas using hand-worked fixtures, edge cases and a second implementation." + ], + "accept": "All material costs and rejected-work effects appear once; model totals reconcile to raw inputs. No GPU upgrade is free, development cost is not double-counted, and burn is not mislabelled operator income.", + "evidence": "Versioned model; unit fixtures; independent reconciliation; input sources.", + "priority": "GATE", + "profile": "P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 13, + 18, + 24, + 26 + ], + "gate": "G4", + "owner": "Economics lead + independent reviewer", + "manual_page": 33 + }, + { + "id": "ECO-02", + "title": "Separate existing-owner and new-entrant viability", + "setup": "Use both installed hardware and purchasable replacement hardware in every mandatory cohort.", + "steps": [ + "Evaluate marginal operation separately from recovery of a new purchase.", + "Stress resale at zero, hardware failures, financing and replacement cycles.", + "Report break-even power price and total cost relative to the strongest feasible specialist." + ], + "accept": "P12 competitiveness conditions hold for the predeclared cohorts in required sustainable worlds. Existing-owner profitability cannot substitute for viable new entry; cards outside the envelope remain visible.", + "evidence": "Owner/entrant curves; price-date records; break-even tables; cohort outcomes.", + "priority": "GATE", + "profile": "P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 13, + 18, + 24, + 26 + ], + "gate": "G4", + "owner": "Economics lead + independent reviewer", + "manual_page": 33 + }, + { + "id": "ECO-03", + "title": "Let the specialist keep its sunk development", + "setup": "Use three development cases: fully funded elsewhere, source-range low and source-range high.", + "steps": [ + "Evaluate private mining, public hardware sales and a hybrid business model.", + "Allow shared IP, incremental revisions, multi-year survival and resale where justified.", + "Re-evaluate GPU entry after the specialist fleet is already installed." + ], + "accept": "The coexistence claim does not depend on recovering the original chip research bill. Required P12 cases meet the approved envelope even at zero incremental development cost; failures cannot be hidden by the $23M/$340M source thresholds.", + "evidence": "Business-model variants; sunk-cost case; full cash-flow and adaptation records.", + "priority": "GATE", + "profile": "P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 13, + 18, + 24, + 26 + ], + "gate": "G4", + "owner": "Economics lead + independent reviewer", + "manual_page": 33 + }, + { + "id": "ECO-04", + "title": "Model entry, exit and difficulty response", + "setup": "Use independently reviewed dynamic operator policies, not fixed market shares.", + "steps": [ + "Let agents buy, sell, switch off, re-enter and choose tasks based on declared costs and expected income.", + "Apply the actual difficulty/reward rules and test optimistic and adversarial liquidity/capital availability.", + "Compare equilibrium and transient outcomes across independent starting conditions." + ], + "accept": "Mandatory worlds satisfy P12 without an imposed GPU share or artificial specialist capacity limit. Concentration, oscillations and excluded regions are reported; model behaviour matches unit and conservation checks.", + "evidence": "Agent policies; sensitivity seeds; market-share paths; independent model review.", + "priority": "GATE", + "profile": "P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 13, + 18, + 24, + 26 + ], + "gate": "G4", + "owner": "Economics lead + independent reviewer", + "manual_page": 34 + }, + { + "id": "ECO-05", + "title": "Stress success, contraction and cheap electricity", + "setup": "Freeze mandatory scenarios before results: revenue bands, tariff range, lifetimes and demand states.", + "steps": [ + "Run the P12 factorial grid plus adversarial combinations selected by the independent reviewer.", + "Test a large successful network as well as weak-revenue and heterogeneous-tariff cases.", + "Distinguish feasible sustained-entry worlds from collapse scenarios with no rational profitable operator." + ], + "accept": "No small-network or token-appreciation assumption props up the primary claim. Required viable worlds pass the envelope; collapse worlds show honest contraction and safety, not fabricated profits. Failure regions are explicit.", + "evidence": "Scenario register; full result cube; boundary plots; failed-world explanations.", + "priority": "GATE", + "profile": "P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 13, + 18, + 24, + 26 + ], + "gate": "G4", + "owner": "Economics lead + independent reviewer", + "manual_page": 34 + }, + { + "id": "ECO-06", + "title": "Fund security and proving as issuance falls", + "setup": "Use the frozen supply, halving, fee, burn and reward rules rather than source prose assumptions.", + "steps": [ + "Reconcile revenue reaching miners, internal provers, developers and burns over the full horizon.", + "Test flat/declining fees and no external proving income; separately introduce external demand.", + "Calculate capacity and security-provider coverage after each reward transition." + ], + "accept": "Recurring compensation is explicit and internally consistent; mandatory sustainable scenarios meet P12. Burned amounts are never counted as payments, and external operator income is not assumed to fund internal work automatically.", + "evidence": "Issuance/fee ledger; scenario cash flows; funding-shortfall report.", + "priority": "GATE", + "profile": "P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 13, + 18, + 24, + 26 + ], + "gate": "G4", + "owner": "Economics lead + independent reviewer", + "manual_page": 34 + }, + { + "id": "ECO-07", + "title": "Price memory growth and honest-card displacement", + "setup": "Use GPU-05 and ROT-06 costs with the cheapest specialist adaptation.", + "steps": [ + "For each dataset increment, compare specialist cost increases with excluded cards and lost proving capacity.", + "Include ordinary-owner replacement, resale and reloading expenses.", + "Run alternate bounded schedules without assigning automatic chip death." + ], + "accept": "The retained schedule meets P06/P12 and has an evidence-backed net competitiveness benefit. A schedule that mainly harms accessible GPUs fails; excluded tiers and mitigations are documented before activation.", + "evidence": "Per-step cost/retention table; alternative schedules; approval record.", + "priority": "GATE", + "profile": "P06; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 8, + 13, + 18, + 24, + 26 + ], + "gate": "G4", + "owner": "Economics lead + independent reviewer", + "manual_page": 35 + }, + { + "id": "ECO-08", + "title": "Reproduce and adversarially audit the model", + "setup": "Give an independent economist or qualified analyst the code, inputs and frozen success criteria.", + "steps": [ + "Recalculate required worlds and perturb favourable assumptions against the team.", + "Check dependence on discounts, utilisation, capital limits, artificial prices and future upgrades.", + "Publish the sensitivity range and state which conclusions are conditional." + ], + "accept": "Material results reproduce, required scenarios pass and no unacknowledged assumption dominates the claim. The model supports a bounded coexistence conclusion, not a percentage probability that no chip will appear.", + "evidence": "Independent report; rerun outputs; model limitations; approved claim envelope.", + "priority": "GATE", + "profile": "P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent economic review", + "status": "NOT RUN", + "source": [ + 8, + 13, + 18, + 24, + 26 + ], + "gate": "G4", + "owner": "Economics lead + independent reviewer", + "manual_page": 35 + } + ] + }, + { + "code": "EVM", + "title": "Execution and developer compatibility", + "source": [ + 15, + 25, + 34, + 35, + 36, + 37 + ], + "gate": "Technical readiness", + "owner": "Execution lead + independent implementer", + "fixtures": "F0 execution-fork semantics; F5 transactions/contracts; F4 multi-node network", + "summary": "Keep familiar applications while making every difference and metering rule explicit and reproducible.", + "tests": [ + { + "id": "EVM-01", + "title": "Match the selected EVM semantics", + "setup": "Pin the intended execution fork, revm version and all Igneum deviations in F0.", + "steps": [ + "Run the applicable upstream execution/state fixtures plus independently written deviation tests.", + "Execute identical blocks on multiple nodes and compare roots, receipts, logs, gas and failure outcomes.", + "Minimise mismatches and distinguish intended differences from implementation defects." + ], + "accept": "All applicable vectors match; every deviation has a documented test and developer consequence. No claim of universal Ethereum equivalence or Ethereum settlement security is inferred.", + "evidence": "Fixture/version inventory; root/receipt diffs; deviation matrix.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 15, + 25, + 34, + 35, + 36, + 37 + ], + "gate": "Technical readiness", + "owner": "Execution lead + independent implementer", + "manual_page": 36 + }, + { + "id": "EVM-02", + "title": "Preserve transaction binding and replay protection", + "setup": "Use signed transfers, contract calls and deployment transactions with boundary field values.", + "steps": [ + "Alter chain identity, nonce, signature, fee caps and recipient after signing.", + "Replay across nodes, forks and distinct test networks; resubmit around reorganisation.", + "Check mempool admission and final consensus execution independently." + ], + "accept": "Unauthorised, wrong-network or duplicate spends are rejected according to F0. Valid replacements follow the declared rule; mempool filtering alone is not evidence of consensus enforcement.", + "evidence": "Signed corpus; admission/execution outcomes; account-state reconciliation.", + "priority": "BLOCKER", + "profile": "P01", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 15, + 25, + 34, + 35, + 36, + 37 + ], + "gate": "Technical readiness", + "owner": "Execution lead + independent implementer", + "manual_page": 36 + }, + { + "id": "EVM-03", + "title": "Test two-dimensional fees and proving limits", + "setup": "Freeze fee dimensions, estimator rules, abort behaviour and refund policy.", + "steps": [ + "Run workloads near and beyond execution and proving budgets, including state-heavy pathological cases.", + "Compare estimated fees with charged fees and validate rollback/receipt status on abort.", + "Mutate a block producer to omit or undercharge expensive work." + ], + "accept": "Deterministic metering, charged amounts and aborted state agree across nodes and proofs. Resource bounds hold; fee estimates meet P09 for accepted supported cases. Undercharged invalid blocks cannot bypass consensus.", + "evidence": "Metering traces; fee fixtures; estimator errors; invalid-block rejection.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 15, + 25, + 34, + 35, + 36, + 37 + ], + "gate": "Technical readiness", + "owner": "Execution lead + independent implementer", + "manual_page": 36 + }, + { + "id": "EVM-04", + "title": "Exercise block context and randomness assumptions", + "setup": "Use contracts sensitive to timestamp, height/context, randomness and ordering.", + "steps": [ + "Compare the declared Igneum semantics with developers' documented expectations.", + "Test boundary transitions, miner-influenced inputs and adversarial ordering in the isolated network.", + "Run dependency reviews for applications using these values for economic decisions." + ], + "accept": "Semantics match F0 and differences are surfaced in compatibility documentation. No source of miner influence is marketed as unbiased randomness; incompatible applications are not included in the compatibility claim.", + "evidence": "Context-contract results; threat notes; compatibility exclusions.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 15, + 25, + 34, + 35, + 36, + 37 + ], + "gate": "Technical readiness", + "owner": "Execution lead + independent implementer", + "manual_page": 37 + }, + { + "id": "EVM-05", + "title": "Run representative contract integration journeys", + "setup": "Use versioned transfer/token, NFT, multisignature, exchange and upgrade-pattern fixtures where supported.", + "steps": [ + "Deploy, initialise, transact, revert and upgrade each contract using ordinary tooling.", + "Exercise events, logs, balances, storage and call traces across node restart/reorganisation.", + "Compare expected application invariants with native execution and proved results." + ], + "accept": "Supported journeys preserve their stated invariants; all deviations are documented. Example deployment success alone cannot stand in for application-level correctness or financial audit.", + "evidence": "Contract fixture hashes; transaction journeys; invariant and state comparisons.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 15, + 25, + 34, + 35, + 36, + 37 + ], + "gate": "Technical readiness", + "owner": "Execution lead + independent implementer", + "manual_page": 37 + }, + { + "id": "EVM-06", + "title": "Validate wallets, RPC and indexers", + "setup": "Pin supported RPC methods and response semantics; use normal developer clients and an independent indexer.", + "steps": [ + "Test fee estimation, pending/final states, subscriptions, pagination and reconnects.", + "Reindex from genesis or the documented trust anchor after pruning and restart.", + "Compare logs, receipts and balances with independently validated chain state." + ], + "accept": "No missing/duplicate canonical records; unsupported methods are explicit. UI states distinguish included, executed, proven and finalised. Malformed RPC input cannot crash validators or leak secrets.", + "evidence": "RPC conformance report; reindex comparison; reconnect/edge-case logs.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 15, + 25, + 34, + 35, + 36, + 37 + ], + "gate": "Technical readiness", + "owner": "Execution lead + independent implementer", + "manual_page": 37 + }, + { + "id": "EVM-07", + "title": "Handle execution denial-of-service workloads", + "setup": "Create bounded pathological bytecode, calls, state growth, storage and precompile inputs.", + "steps": [ + "Measure CPU, memory, disk and proving cost against charged budgets.", + "Saturate admission with invalid/expensive requests while valid workloads continue.", + "Restart mid-execution and verify atomic state recovery." + ], + "accept": "P09 limits hold with no unbounded free work or divergent rollback. State remains consistent after crash; availability under overload follows the declared admission policy, not silent dropping of accepted transactions.", + "evidence": "Resource profiles; adversarial corpus; state recovery comparisons.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 15, + 25, + 34, + 35, + 36, + 37 + ], + "gate": "Technical readiness", + "owner": "Execution lead + independent implementer", + "manual_page": 38 + }, + { + "id": "EVM-08", + "title": "Verify controlled execution and verifier upgrades", + "setup": "Prepare two authorised versions and malicious, stale or unknown versions.", + "steps": [ + "Cross activation with mixed clients, queued transactions and proofs from both versions.", + "Bind each accepted proof to the correct execution semantics and program identity.", + "Exercise a failed software distribution without altering consensus activation." + ], + "accept": "No unknown or wrong-version execution is accepted. Pre/post-boundary handling is deterministic and documented; software delivery cannot silently redefine transaction semantics or proof acceptance.", + "evidence": "Upgrade vectors; mixed-version traces; manifest/version bindings.", + "priority": "BLOCKER", + "profile": "P01; P08; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 15, + 25, + 34, + 35, + 36, + 37 + ], + "gate": "Technical readiness", + "owner": "Execution lead + independent implementer", + "manual_page": 38 + } + ] + }, + { + "code": "ZKP", + "title": "Consensus-enforced proof validity", + "source": [ + 16, + 20, + 24, + 25, + 36, + 37 + ], + "gate": "Technical readiness / G5", + "owner": "Proving + protocol leads; independent cryptography review", + "fixtures": "F0 pinned programs/verifiers; F5 valid and hostile proof corpus; unmodified validators", + "summary": "The validator, not merely the official producer, must reject unauthorised or invalid proof records and rewards.", + "tests": [ + { + "id": "ZKP-01", + "title": "Reject missing and invalid proofs", + "setup": "Start from a native-correct statement and an independently verified valid proof.", + "steps": [ + "Submit the statement with no proof, truncated bytes, random bytes and targeted proof mutations using a modified producer.", + "Submit the genuine proof as a positive control through ordinary network paths.", + "Inspect block acceptance and resulting reward/state on unmodified validators." + ], + "accept": "Every invalid proof record is rejected and earns no reward; valid controls succeed. A producer-side filter is not sufficient. Record rejection semantics exactly as defined by F0.", + "evidence": "Hostile record corpus; validator decisions; before/after balances; positive controls.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 16, + 20, + 24, + 25, + 36, + 37 + ], + "gate": "Technical readiness / G5", + "owner": "Proving + protocol leads; independent cryptography review", + "manual_page": 39 + }, + { + "id": "ZKP-02", + "title": "Bind program, verifier and security parameters", + "setup": "Use valid proofs from authorised and unauthorised programs and parameter sets.", + "steps": [ + "Swap program digest, verifier version, security settings and verification key where applicable.", + "Attempt downgrade through configuration, serialized metadata or an old node path.", + "Test authorised boundary transitions and unsupported future identities." + ], + "accept": "Only explicitly authorised combinations are accepted in the correct epoch. No implicit trust in producer-supplied metadata or lower-security fallback; all accepted settings have scoped soundness review.", + "evidence": "Identity/parameter matrix; rejection traces; cryptographic review.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 16, + 20, + 24, + 25, + 36, + 37 + ], + "gate": "Technical readiness / G5", + "owner": "Proving + protocol leads; independent cryptography review", + "manual_page": 39 + }, + { + "id": "ZKP-03", + "title": "Bind network, epoch, job and state roots", + "setup": "Prepare valid proofs for distinct chains, epochs, jobs and initial/final states.", + "steps": [ + "Replay each proof under another network, job, epoch, shard range or state commitment.", + "Alter public inputs while retaining the proof and test valid-but-wrong-context statements.", + "Check duplicated and reordered records across forks and replayed sync data." + ], + "accept": "Every misbound proof is rejected; valid authorised replays follow only explicitly allowed semantics and never create extra rewards. Native reexecution cannot conceal missing proof-context binding.", + "evidence": "Binding matrix; public-input hashes; replay traces; reward reconciliation.", + "priority": "BLOCKER", + "profile": "P01", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 16, + 20, + 24, + 25, + 36, + 37 + ], + "gate": "Technical readiness / G5", + "owner": "Proving + protocol leads; independent cryptography review", + "manual_page": 39 + }, + { + "id": "ZKP-04", + "title": "Prevent reward and payout substitution", + "setup": "Use proofs that commit to authorisation and all reward-relevant fields required by F0.", + "steps": [ + "Alter payout key, amount, beneficiary, source work or fee allocation independently.", + "Supply correct execution over malicious producer-provided consensus/reward inputs.", + "Compare consensus-derived rewards with the proved/publicly authenticated derivation." + ], + "accept": "Unauthorised payout changes and incorrect consensus inputs are rejected; no statement accepted merely because execution over supplied inputs is internally correct. Legitimate authorisations are preserved.", + "evidence": "Mutation cases; reward derivation trace; signature/proof binding review.", + "priority": "BLOCKER", + "profile": "P01", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 16, + 20, + 24, + 25, + 36, + 37 + ], + "gate": "Technical readiness / G5", + "owner": "Proving + protocol leads; independent cryptography review", + "manual_page": 40 + }, + { + "id": "ZKP-05", + "title": "Make proof payment idempotent across races", + "setup": "Use competing provers submitting valid results for the same work and simulate retries/reorganisations.", + "steps": [ + "Submit simultaneous duplicates, reordered receipts and repeated messages after disconnects.", + "Crash validators between validation and reward application, then recover.", + "Reconcile canonical payouts against the exact F0 duplicate policy." + ], + "accept": "Only the authorised total payment is made; no double payout, lost accepted entitlement or fork-retained balance. Transactions and payout records recover atomically.", + "evidence": "Concurrency schedule; canonical payment ledger; crash/recovery evidence.", + "priority": "BLOCKER", + "profile": "P01", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 16, + 20, + 24, + 25, + 36, + 37 + ], + "gate": "Technical readiness / G5", + "owner": "Proving + protocol leads; independent cryptography review", + "manual_page": 40 + }, + { + "id": "ZKP-06", + "title": "Verify aggregation coverage and completeness", + "setup": "Build valid multi-shard workloads plus omitted, duplicated, overlapping and misordered shard sets.", + "steps": [ + "Attempt an aggregate with a correct outer proof but wrong coverage/public-input construction.", + "Alter shard ranges, roots and aggregation-program identity.", + "Verify native execution, aggregate validity and coverage commitments independently." + ], + "accept": "Only complete, correctly ordered authorised coverage is accepted. No valid proof of the wrong computation becomes an accepted chain result; aggregation failures do not fabricate successful delivery.", + "evidence": "Coverage corpus; aggregate/public-input verification; rejection ledger.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 16, + 20, + 24, + 25, + 36, + 37 + ], + "gate": "Technical readiness / G5", + "owner": "Proving + protocol leads; independent cryptography review", + "manual_page": 40 + }, + { + "id": "ZKP-07", + "title": "Review soundness and verifier resource limits", + "setup": "Provide proof-system code, parameters, patches and the pinned verification path to an independent specialist.", + "steps": [ + "Review soundness assumptions, parameter margins and consequences of performance patches.", + "Fuzz deserialization and adversarial proofs; measure verification CPU and memory under load.", + "Cross-check an independent verifier or reference path and test crash containment." + ], + "accept": "P09 review and resource requirements pass with no unresolved critical/high finding. Random proof rejection counts are not described as evidence of a particular cryptographic security level.", + "evidence": "Scoped soundness review; parameter sheet; fuzzer corpus; verifier profiles.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent cryptographic review + testing", + "status": "NOT RUN", + "source": [ + 16, + 20, + 24, + 25, + 36, + 37 + ], + "gate": "Technical readiness / G5", + "owner": "Proving + protocol leads; independent cryptography review", + "manual_page": 41 + }, + { + "id": "ZKP-08", + "title": "Preserve authority and audit all acceptance paths", + "setup": "Inspect block import, sync, RPC, light verification, database restoration and fast paths.", + "steps": [ + "Try bypassing validation via each path with a proof rejected by the normal path.", + "Remove the dominant prover/aggregator and have independent replacements process available inputs.", + "Attempt to use proof-production status as ordering, voting or finality authority." + ], + "accept": "No bypass accepts invalid work; proofs alone confer no unauthorised consensus control. Replacement and pause behaviour meet F0/P07/P08 without privileged keys or a trusted aggregator shortcut.", + "evidence": "Path coverage report; bypass corpus; replacement run; authority checks.", + "priority": "BLOCKER", + "profile": "P01; P07; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 16, + 20, + 24, + 25, + 36, + 37 + ], + "gate": "Technical readiness / G5", + "owner": "Proving + protocol leads; independent cryptography review", + "manual_page": 41 + } + ] + }, + { + "code": "CAP", + "title": "Sustained proving and delivery", + "source": [ + 17, + 18, + 24, + 25 + ], + "gate": "Technical readiness / commercial track", + "owner": "Proving lead + independent operators", + "fixtures": "F3 meaningful workload catalogue; F4 network; F8 external job harness", + "summary": "A correct fast shard is only one stage; capacity, latency, payment and retries must work together.", + "tests": [ + { + "id": "CAP-01", + "title": "Reproduce the historical consumer-shard result", + "setup": "Recover the exact source-era workload/build if available; keep it separate from the release-candidate workload.", + "steps": [ + "Attempt independent reproduction of the 4,717,439-cycle workload and reported 3060/4060/4070 results.", + "Record proof format, memory, energy, host and whether aggregation/compression are included.", + "Repeat on the final release and label all configuration changes." + ], + "accept": "Historical figures are either reproduced within P02 tolerance or corrected/labelled non-reproduced. Release acceptance uses the current complete workload, never an unmatched historical time or a smaller substituted shard.", + "evidence": "Historical/current manifests; proof verification; timing and memory records.", + "priority": "GATE", + "profile": "P02; P07", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 17, + 18, + 24, + 25 + ], + "gate": "Technical readiness / commercial track", + "owner": "Proving lead + independent operators", + "manual_page": 42 + }, + { + "id": "CAP-02", + "title": "Prove on the actual mining configuration", + "setup": "Use final dataset sizes, registers, clocks, drivers and proof pipeline on every advertised proving tier.", + "steps": [ + "Run mining alone, proving alone, concurrent execution and supported time-sharing.", + "Measure wall energy, memory headroom, reloads, proof latency and forgone accepted mining work.", + "Induce memory pressure and GPU task failure without losing wallet control." + ], + "accept": "Every advertised mode completes correctly and meets P06/P07. Net output includes opportunity cost; unsupported concurrency is not claimed. Mining-only vendor support remains separately labelled.", + "evidence": "Four-mode results; OOM/failure logs; memory and opportunity-cost ledger.", + "priority": "BLOCKER", + "profile": "P01; P06; P07", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 17, + 18, + 24, + 25 + ], + "gate": "Technical readiness / commercial track", + "owner": "Proving lead + independent operators", + "manual_page": 42 + }, + { + "id": "CAP-03", + "title": "Measure the entire request-to-payment path", + "setup": "Assign a unique job ID and immutable timestamps to every stage of F3/F8 jobs.", + "steps": [ + "Record request, input availability, assignment, execution, shard proof, aggregation, verification, delivery and payment.", + "Compare monotonic elapsed time with any protocol/DAA clock and document their relationship.", + "Reconcile failed, censored, retried and abandoned jobs with the original request denominator." + ], + "accept": "No hidden stage or missing job; latency distributions and cost cover the complete path. Delivery, finality and payment are reported separately; protocol seconds are not silently relabelled wall-clock seconds.", + "evidence": "Stage event ledger; clock calibration; end-to-end latency/cost report.", + "priority": "GATE", + "profile": "P07", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 17, + 18, + 24, + 25 + ], + "gate": "Technical readiness / commercial track", + "owner": "Proving lead + independent operators", + "manual_page": 42 + }, + { + "id": "CAP-04", + "title": "Sustain meaningful load without queue growth", + "setup": "Freeze W: payload mix, input sizes, execution work and per-hour demand; prohibit tiny-workload substitution.", + "steps": [ + "Run 72 hours at W and a separate 24 hours at 1.2W on the declared fleet.", + "Measure arrival/completion counts, backlog trend, oldest-job age, deadlines and all retries.", + "Use held-out workloads and an independent observer to detect discarded or delayed requests." + ], + "accept": "P07 completion, tail-latency and bounded-backlog criteria hold. Capacity is stated for the tested W/fleet, not as universal TPS. A queue that grows indefinitely or shrinks through silent loss fails.", + "evidence": "Request/completion reconciliation; backlog series; held-out results; observer report.", + "priority": "GATE", + "profile": "P07", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 17, + 18, + 24, + 25 + ], + "gate": "Technical readiness / commercial track", + "owner": "Proving lead + independent operators", + "manual_page": 43 + }, + { + "id": "CAP-05", + "title": "Overload and recover without false acceptance", + "setup": "Start at W and inject 2W for 15 minutes with valid and invalid jobs, then return to W.", + "steps": [ + "Observe admission, explicit backpressure, reservations and deadline estimates.", + "Track accepted jobs to valid completion or the pre-agreed failure/refund outcome.", + "Measure recovery time and ensure ordinary users are not silently starved." + ], + "accept": "P07 overload policy and recovery limits hold; no accepted job vanishes or earns an invalid reward. Rejected demand is reported separately from delivery success, preventing denominator manipulation.", + "evidence": "Overload timeline; admission/refund logs; backlog-drain proof.", + "priority": "BLOCKER", + "profile": "P01; P07", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 17, + 18, + 24, + 25 + ], + "gate": "Technical readiness / commercial track", + "owner": "Proving lead + independent operators", + "manual_page": 43 + }, + { + "id": "CAP-06", + "title": "Calibrate assignment windows to paid completion", + "setup": "Use a heterogeneous proving fleet, including the slowest advertised consumer tier.", + "steps": [ + "Measure actual completion distributions with network delay, competing load and failed attempts.", + "Test the chosen exclusive window, open claiming and faster challengers after expiry.", + "Compare assignment frequency, paid completions and wasted work by tier." + ], + "accept": "P07 fairness and wasted-work limits hold for advertised tiers. A provisional 10-DAA-second window is not treated as approved. Fair assignment counts alone cannot pass; payment outcomes and operator margins matter.", + "evidence": "Window sweep; paid-completion distribution; wasted-work and margin report.", + "priority": "GATE", + "profile": "P07; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 17, + 18, + 24, + 25 + ], + "gate": "Technical readiness / commercial track", + "owner": "Proving lead + independent operators", + "manual_page": 43 + }, + { + "id": "CAP-07", + "title": "Reassign work when inputs or providers disappear", + "setup": "Remove input providers, assigned provers and the dominant aggregator independently and together.", + "steps": [ + "Have replacement operators retrieve authenticated inputs without founder files.", + "Retry expired assignments while preserving idempotent reward and customer outcomes.", + "Restore providers and test late submissions racing with replacements." + ], + "accept": "P07/P08 replacement deadlines hold when availability assumptions permit. Otherwise a truthful bounded pause/refund occurs; no fake proof, double payment or hidden privileged input source is used.", + "evidence": "Failure schedule; input hashes; reassignment and payout ledger; recovery trace.", + "priority": "BLOCKER", + "profile": "P01; P07; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 17, + 18, + 24, + 25 + ], + "gate": "Technical readiness / commercial track", + "owner": "Proving lead + independent operators", + "manual_page": 44 + }, + { + "id": "CAP-08", + "title": "Deliver customer-verifiable output at scale", + "setup": "Run the external workload using a customer-controlled verifier and independently operated workers.", + "steps": [ + "Verify every delivered proof against the contracted program and input commitment.", + "Reject wrong-format, stale and partial deliveries; test customer retry and delivery failure.", + "Reconcile delivery, acceptance, payment and refund records without exposing private inputs publicly." + ], + "accept": "P07 delivery performance and exact validity hold. Payment depends on the contracted correct result; a valid proof for the wrong job is not a successful delivery.", + "evidence": "Customer verification log; proof-format contract; settlement reconciliation.", + "priority": "BLOCKER", + "profile": "P01; P07; P14", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 17, + 18, + 24, + 25 + ], + "gate": "Technical readiness / commercial track", + "owner": "Proving lead + independent operators", + "manual_page": 44 + } + ] + }, + { + "code": "INC", + "title": "Rewards, incentives and selfish operators", + "source": [ + 13, + 16, + 17, + 18, + 24, + 26 + ], + "gate": "G4 / G5", + "owner": "Protocol economics + proving leads", + "fixtures": "F0 fee/reward rules; F4 adversarial operators; F7 incentive models", + "summary": "Assume operators optimise their own returns. Do not depend on the official client choosing a less profitable task.", + "tests": [ + { + "id": "INC-01", + "title": "Reconcile issuance, fees, burns and recipients", + "setup": "Use a deterministic short chain containing all reward types, fee paths and rounding cases.", + "steps": [ + "Calculate balances, total supply changes, burns and distributions independently.", + "Execute identical blocks natively and through the proving path.", + "Test zero, minimum, maximum and transition-boundary values plus malformed producer accounting." + ], + "accept": "Conservation and recipient rules match F0 exactly; no inflation, rounding leakage or duplicate reward. Fee-table and prose discrepancies are resolved before the run, not guessed by the tester.", + "evidence": "Independent accounting ledger; balance/supply diffs; boundary vectors.", + "priority": "BLOCKER", + "profile": "P01; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 13, + 16, + 17, + 18, + 24, + 26 + ], + "gate": "G4 / G5", + "owner": "Protocol economics + proving leads", + "manual_page": 45 + }, + { + "id": "INC-02", + "title": "Keep revenue streams and claims separate", + "setup": "Prepare jobs and blocks producing mining income, internal proof rewards and external payments.", + "steps": [ + "Trace money from source to operator, protocol, developer and any burn.", + "Compare node records, settlement records and Ember displays.", + "Attempt to classify testnet rewards, reimbursed purchases or token appreciation as external customer revenue." + ], + "accept": "Every stream reconciles and is labelled correctly. No double-counted revenue or fabricated protocol demand; mining subsidy and external service income remain distinct in dashboards and ECO.", + "evidence": "Money-flow register; UI reconciliation; rejected classifications.", + "priority": "BLOCKER", + "profile": "P01; P12; P14", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 13, + 16, + 17, + 18, + 24, + 26 + ], + "gate": "G4 / G5", + "owner": "Protocol economics + proving leads", + "manual_page": 45 + }, + { + "id": "INC-03", + "title": "Let a modified client choose the most profitable task", + "setup": "Permit independent schedulers to mine, prove internally, prove externally or switch off.", + "steps": [ + "Publish common costs and vary relative task rewards, memory pressure and switching costs.", + "Run clients that ignore the official scheduling recommendation.", + "Measure realised operator margin, internal capacity and network progress." + ], + "accept": "Required P12 sustainable worlds maintain paid essential capacity without compelled altruism. Profitability and availability are based on realised outcomes, including switching and wasted work.", + "evidence": "Scheduler source/policies; switching traces; capacity and margin series.", + "priority": "GATE", + "profile": "P07; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 13, + 16, + 17, + 18, + 24, + 26 + ], + "gate": "G4 / G5", + "owner": "Protocol economics + proving leads", + "manual_page": 45 + }, + { + "id": "INC-04", + "title": "Survive external-demand spikes and token declines", + "setup": "Use F7 scenarios with 10x external job offers and token-denominated mining-income shocks.", + "steps": [ + "Allow miners/provers to switch freely under the declared reward and difficulty rules.", + "Observe hash participation, proof backlog, fees and recovery without an administrator.", + "Repeat with external demand dropping to zero and with a dominant operator withdrawn." + ], + "accept": "Mandatory viable worlds meet P07/P12; stressed nonviable worlds fail or pause safely with truthful status. No emergency rule, fabricated demand or unofficial subsidy is inserted to force a pass.", + "evidence": "Shock timeline; fee/hash/capacity paths; failure-region report.", + "priority": "GATE", + "profile": "P07; P08; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 13, + 16, + 17, + 18, + 24, + 26 + ], + "gate": "G4 / G5", + "owner": "Protocol economics + proving leads", + "manual_page": 46 + }, + { + "id": "INC-05", + "title": "Contain job reservation and identity-splitting abuse", + "setup": "Freeze the actual assignment/payment mechanism; do not assume unimplemented collateral or identity controls.", + "steps": [ + "Create many worker identities, reserve jobs, withhold proofs and submit late results.", + "Attempt free option-taking, duplicate work rewards and displacement of honest assignments.", + "Price attacker costs and observe honest completion under the approved abuse load." + ], + "accept": "F0 rules and P07 service limits hold under the declared adversary. Identity splitting does not create unauthorised rewards or control; any unmitigated starvation path blocks the permissionless-service claim.", + "evidence": "Attack clients; assignment trace; cost-to-disrupt analysis; honest-user outcomes.", + "priority": "BLOCKER", + "profile": "P01; P07; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 13, + 16, + 17, + 18, + 24, + 26 + ], + "gate": "G4 / G5", + "owner": "Protocol economics + proving leads", + "manual_page": 46 + }, + { + "id": "INC-06", + "title": "Test difficulty and timestamp manipulation", + "setup": "Use the actual adjustment algorithm and consensus timestamp rule with independent miners.", + "steps": [ + "Inject large hashrate arrivals/departures, periodic selective mining and boundary-timed bursts.", + "Try allowed and invalid timestamp skew, withheld blocks and replayed work.", + "Observe block intervals, reward allocation and recovery after hashrate stabilises." + ], + "accept": "Invalid inputs are rejected; valid adversarial strategies remain within F0/P08 bounds and are priced in ECO. No unexplained reward amplification, permanent stall or conflicting accepted work.", + "evidence": "Difficulty trace; timestamp corpus; revenue analysis; independent rule review.", + "priority": "BLOCKER", + "profile": "P01; P08; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 13, + 16, + 17, + 18, + 24, + 26 + ], + "gate": "G4 / G5", + "owner": "Protocol economics + proving leads", + "manual_page": 46 + }, + { + "id": "INC-07", + "title": "Resist self-dealing fees and fake proving demand", + "setup": "Use self-funded operators and related customer identities in the isolated economic model/network.", + "steps": [ + "Cycle funds through jobs, tips, developer shares and rebates to seek net reward extraction.", + "Attempt to inflate external-demand metrics without genuine unrelated customer expenditure.", + "Reconcile all counterparties and net cash contribution rather than gross transaction volume." + ], + "accept": "No unauthorised subsidy extraction or metric inflation passes. Related-party volume is disclosed/excluded from P14; net external cash and legitimate protocol incentives are reported separately.", + "evidence": "Circular-flow tests; ownership/conflict review; net-cash reconciliation.", + "priority": "BLOCKER", + "profile": "P01; P12; P14", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 13, + 16, + 17, + 18, + 24, + 26 + ], + "gate": "G4 / G5", + "owner": "Protocol economics + proving leads", + "manual_page": 47 + }, + { + "id": "INC-08", + "title": "Quantify provider and supplier failure concentration", + "setup": "Model control of hashing, signing, proving, aggregation and hardware supply separately.", + "steps": [ + "Remove each largest operational dependency and combine correlated failures.", + "Measure replacement cost/time and whether essential roles share hidden ownership.", + "Compare results with the approved fault model and no-rescue exercise." + ], + "accept": "No hidden single dependency defeats the claimed independence; within-tolerance withdrawals recover under P08/P11. Hardware supply concentration is disclosed without equating vendor sales to operator voting control.", + "evidence": "Role/ownership map; dependency removals; recovery and concentration report.", + "priority": "GATE", + "profile": "P08; P11; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 13, + 16, + 17, + 18, + 24, + 26 + ], + "gate": "G4 / G5", + "owner": "Protocol economics + proving leads", + "manual_page": 47 + } + ] + }, + { + "code": "FIN", + "title": "Consensus safety and recovery", + "source": [ + 19, + 21, + 24, + 25 + ], + "gate": "G5 / technical readiness", + "owner": "Consensus lead + independent formal/security review", + "fixtures": "F0 exact fault model; F4 real-node partitions; F5 certificates and historical failures", + "summary": "Test safety under the stated fault bounds. Demand liveness only when synchrony and participation assumptions actually hold.", + "tests": [ + { + "id": "FIN-01", + "title": "Agree on ordering, work and executed state", + "setup": "Use real fork-choice/DAG handling and independent miners, not only a simplified simulator.", + "steps": [ + "Generate concurrent branches, delayed blocks, duplicates and invalid work with deterministic seeds.", + "Compare selected ordering, accumulated work, transaction execution and state roots after delivery converges.", + "Replay from independent checkpoints and from genesis where practical." + ], + "accept": "Honest nodes converge under F0 assumptions with exact roots and rewards. No duplicated work accounting or undocumented ordering dependence; simulator-only success cannot substitute.", + "evidence": "Block/ordering corpus; root/work diffs; real-node replay logs.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 19, + 21, + 24, + 25 + ], + "gate": "G5 / technical readiness", + "owner": "Consensus lead + independent formal/security review", + "manual_page": 48 + }, + { + "id": "FIN-02", + "title": "Attack finality with split honest populations", + "setup": "Use the source-discussed 40/40/20 weight split, plus threshold-boundary splits under F0.", + "steps": [ + "Let the 20% adversarial group sign conflicting histories while honest groups are partitioned.", + "Delay messages and eligibility updates independently; keep total historical weights auditable.", + "Try to form two certificates and reconnect nodes to observe accepted final history." + ], + "accept": "No conflicting final certificates are accepted within the declared fault bound. A safe pause is valid when quorum is unavailable; making progress on both sides is not required.", + "evidence": "Signed votes; certificate attempts; voter-table snapshots; safety checker output.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 19, + 21, + 24, + 25 + ], + "gate": "G5 / technical readiness", + "owner": "Consensus lead + independent formal/security review", + "manual_page": 48 + }, + { + "id": "FIN-03", + "title": "Cross authority expiry in a long partition", + "setup": "Recover historical expiry failures where available; use the actual current authority-transition rules.", + "steps": [ + "Partition for 31, 35, 60 and 90 logical days and around every retention/expiry boundary.", + "Attempt independently renewed authority sets and conflicting checkpoint locks.", + "Repeat selected boundary cases on real nodes with accelerated timers explicitly labelled." + ], + "accept": "Authority continuity remains authenticated and no conflicting final history appears within F0 assumptions. A timeout is not accepted as proof absent voters ceased to exist. Compressed time is not multi-month field evidence.", + "evidence": "Expiry timeline; table/certificate history; historical regression tests.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 19, + 21, + 24, + 25 + ], + "gate": "G5 / technical readiness", + "owner": "Consensus lead + independent formal/security review", + "manual_page": 48 + }, + { + "id": "FIN-04", + "title": "Stop signing while mining continues", + "setup": "Remove enough signing participation to invalidate the liveness assumption without forging votes.", + "steps": [ + "Continue mining and execution, cross seed boundaries and monitor proof queues.", + "Check which user-visible states advance and which remain unfinalised.", + "Restore eligible weight and bounded message delay, then verify recovery." + ], + "accept": "No false finality or fabricated authority. Behaviour matches F0 during the pause and P08 after assumptions return; unfinished transactions are not displayed as irreversible.", + "evidence": "Signing/mining trace; UI/RPC states; recovery roots and timing.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 19, + 21, + 24, + 25 + ], + "gate": "G5 / technical readiness", + "owner": "Consensus lead + independent formal/security review", + "manual_page": 49 + }, + { + "id": "FIN-05", + "title": "Authenticate voter-set changes and pooled keys", + "setup": "Use normal transitions, pool members retaining keys and malicious substitution attempts.", + "steps": [ + "Alter voter weights, membership proofs, miner/pool identity bindings and prior-certificate links.", + "Race updates across boundaries and replay old signed changes.", + "Have a new node verify the authority chain from its declared trust anchor." + ], + "accept": "Only correctly authenticated changes are accepted; weights cannot be double-counted or redirected by a pool. All honest nodes agree on the active authority set for each certified point.", + "evidence": "Authority-chain fixtures; substitution attacks; new-node verification log.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 19, + 21, + 24, + 25 + ], + "gate": "G5 / technical readiness", + "owner": "Consensus lead + independent formal/security review", + "manual_page": 49 + }, + { + "id": "FIN-06", + "title": "Analyse old-key compromise and long-range histories", + "setup": "Freeze assumptions about key erasure, retained weights, trust anchors and offline recovery.", + "steps": [ + "Use previously eligible keys to build alternative histories after their operators disappear.", + "Present these histories to recently offline and newly joining clients.", + "Test replayed certificates, stale anchors and compromised signer subsets." + ], + "accept": "Acceptance matches the explicit security model with no hidden trusted recovery step. Any reliance on a recent trusted anchor is disclosed and tested; hashpower assumptions cannot replace old-key analysis.", + "evidence": "Long-range corpus; trust-anchor policy; key-compromise review; client results.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 19, + 21, + 24, + 25 + ], + "gate": "G5 / technical readiness", + "owner": "Consensus lead + independent formal/security review", + "manual_page": 49 + }, + { + "id": "FIN-07", + "title": "Recover deterministically after reconnection and crash", + "setup": "Combine partitions with node crash, partial writes, restarts and proof backlog.", + "steps": [ + "Reconnect networks under bounded latency and restore required honest participation.", + "Verify fork choice, unfinalised reorganisation, finality, reward rollback and proof reassignments.", + "Compare all honest nodes and customer-visible receipts after recovery." + ], + "accept": "P08 recovery holds without reversing a previously valid final guarantee. Only permitted unfinalised state is reorganised; no duplicate rewards or inconsistent receipt statuses survive.", + "evidence": "Recovery timelines; roots/certificates; payout rollback; customer-state reconciliation.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 19, + 21, + 24, + 25 + ], + "gate": "G5 / technical readiness", + "owner": "Consensus lead + independent formal/security review", + "manual_page": 50 + }, + { + "id": "FIN-08", + "title": "Combine boundaries, faults and adversarial scheduling", + "setup": "Use an independent model checker/scheduler and production-node scenarios from F4.", + "steps": [ + "Combine epoch changes, authority transitions, mining churn, data delays and prover/aggregator loss.", + "Explore bounded adversarial message schedules and minimise any counterexample.", + "Replay model findings on real code and have an independent reviewer assess uncovered states." + ], + "accept": "No unresolved safety failure; liveness claims hold only within declared assumptions and P08. Model bounds and untested schedules are published, not described as proof over every possible execution.", + "evidence": "Model/spec artifacts; schedule corpus; replay evidence; independent assessment.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Model checking + real-node testing", + "status": "NOT RUN", + "source": [ + 19, + 21, + 24, + 25 + ], + "gate": "G5 / technical readiness", + "owner": "Consensus lead + independent formal/security review", + "manual_page": 50 + } + ] + }, + { + "code": "VER", + "title": "Wallets, receipts and data availability", + "source": [ + 20, + 25, + 35, + 37 + ], + "gate": "Technical readiness / claimed options", + "owner": "Wallet + light-client lead; independent security review", + "fixtures": "F0 trust/availability model; F5 malformed roots, receipts and authority chains", + "summary": "Verify the exact property shown to the user. An inclusion proof, execution proof and finality certificate are not interchangeable.", + "tests": [ + { + "id": "VER-01", + "title": "Authenticate light-client bootstrap", + "setup": "Give a clean client malicious RPC responses, fabricated voter tables and valid-looking signatures.", + "steps": [ + "Start from the approved trust anchor and verify every required link to the advertised state.", + "Substitute otherwise well-formed but unauthorised keys, weights and checkpoints.", + "Remove the bootstrap service and use another independently operated source." + ], + "accept": "The client rejects unauthorised authority and discloses any trust anchor. Signatures over a node-supplied table do not by themselves pass; missing authentication never silently degrades to trusted RPC.", + "evidence": "Bootstrap corpus; trust-chain trace; fail-closed tests.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 20, + 25, + 35, + 37 + ], + "gate": "Technical readiness / claimed options", + "owner": "Wallet + light-client lead; independent security review", + "manual_page": 51 + }, + { + "id": "VER-02", + "title": "Verify evolving authority and execution statements", + "setup": "Use valid state proofs paired with wrong execution statements or stale authority histories.", + "steps": [ + "Cross voter and verifier changes with offline clients returning after long intervals.", + "Alter roots, aggregate identity and proof/public-input bindings independently.", + "Check local verification rather than merely a server-reported verified flag." + ], + "accept": "All advertised proof checks occur locally or the remaining trust is explicitly disclosed. Wrong roots and unauthenticated authority are rejected; unsupported verification paths are not claimed.", + "evidence": "Client verification trace; corrupted inputs; offline/upgrade results.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 20, + 25, + 35, + 37 + ], + "gate": "Technical readiness / claimed options", + "owner": "Wallet + light-client lead; independent security review", + "manual_page": 51 + }, + { + "id": "VER-03", + "title": "Prove successful payment rather than inclusion", + "setup": "Create successful, reverted, wrong-asset, wrong-recipient and wrong-amount transfers.", + "steps": [ + "Generate receipts for included transactions, including failures and replaced/unfinalised transactions.", + "Verify execution status plus asset, recipient, amount and canonical-state/receipt commitment.", + "Replay the receipt on another chain and after an allowed unfinalised reorganisation." + ], + "accept": "Only the actual successful, correctly bound transfer is labelled payment proof. Inclusion-only receipts are labelled as such; no node-reported success flag substitutes for authenticated outcome.", + "evidence": "Payment fixture corpus; receipt verification; merchant-facing status checks.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 20, + 25, + 35, + 37 + ], + "gate": "Technical readiness / claimed options", + "owner": "Wallet + light-client lead; independent security review", + "manual_page": 51 + }, + { + "id": "VER-04", + "title": "Bound cross-chain oracle trust and replay", + "setup": "For a claimed oracle, freeze destination verifier, authority updates, accepted proof types and replay policy.", + "steps": [ + "Try deployer-substituted keys, stale certificates, unchecked signatures and wrong source/destination identities.", + "Exercise legitimate authority updates and source reorganisations under the approved model.", + "Measure gas/cost with realistic header sets and test disabled/unavailable verification." + ], + "accept": "The oracle enforces its declared trust model and fails closed. Deployer privileges and unavailable guarantees are explicit; no trustless-bridge claim exceeds the checks performed. Excluded oracle scope earns no pass credit.", + "evidence": "Oracle code/parameters; attack cases; cost report; privilege disclosure.", + "priority": "BLOCKER", + "profile": "P00; P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Claimed-option verification", + "status": "NOT RUN", + "source": [ + 20, + 25, + 35, + 37 + ], + "gate": "Technical readiness / claimed options", + "owner": "Wallet + light-client lead; independent security review", + "manual_page": 52 + }, + { + "id": "VER-05", + "title": "Reconstruct required state without founder storage", + "setup": "Remove founder archival/input services and start an independent operator from the documented entry point.", + "steps": [ + "Fetch authenticated blocks, state/proof inputs and any required witnesses from permitted peers.", + "Rebuild the expected state and continue validation/proving.", + "Measure bandwidth, disk, time and retention requirements against advertised operator budgets." + ], + "accept": "Required data can be obtained and verified within the declared availability model. Hidden archives or unpublished files block independence. A valid execution proof alone does not satisfy this test.", + "evidence": "Download/reconstruction logs; data hashes; resource costs; dependency inventory.", + "priority": "BLOCKER", + "profile": "P01; P08; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 20, + 25, + 35, + 37 + ], + "gate": "Technical readiness / claimed options", + "owner": "Wallet + light-client lead; independent security review", + "manual_page": 52 + }, + { + "id": "VER-06", + "title": "Detect withholding, corruption and stale data", + "setup": "Serve valid commitments with missing data, corrupted chunks, stale witnesses and conflicting peer replies.", + "steps": [ + "Attempt to make a validator or light client accept an unavailable or incorrect state under F0.", + "Test retrieval from independent peers and expiry/retry policy.", + "Restore data and check that recovery cannot alter an already verified commitment." + ], + "accept": "No unjustified available/verified status; safety and admission rules match F0. Recovery is bounded where assumptions permit, and unavailable-data states remain visible instead of hidden behind proofs.", + "evidence": "Withholding corpus; peer retrieval traces; availability/status checks.", + "priority": "BLOCKER", + "profile": "P01; P08; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 20, + 25, + 35, + 37 + ], + "gate": "Technical readiness / claimed options", + "owner": "Wallet + light-client lead; independent security review", + "manual_page": 52 + }, + { + "id": "VER-07", + "title": "Protect wallet keys, signing and recovery", + "setup": "Use test-only keys, encrypted backups and clean replacement devices; no real user funds.", + "steps": [ + "Attempt secret access from proving jobs, logs, crash dumps, clipboard and telemetry paths.", + "Verify transaction destination/amount before signing; test backup/restore and wrong-password handling.", + "Upgrade and recover without silently changing signing authority or exposing seed material." + ], + "accept": "No unintended secret disclosure or unauthorised signature. Supported recovery restores the correct keys and accounts; users receive explicit risk/backup information. Logs are sanitised without hiding security evidence.", + "evidence": "Security review; canary-secret tests; signing fixtures; restore journey.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 20, + 25, + 35, + 37 + ], + "gate": "Technical readiness / claimed options", + "owner": "Wallet + light-client lead; independent security review", + "manual_page": 53 + }, + { + "id": "VER-08", + "title": "Keep every user-facing state truthful", + "setup": "Create included-only, executed, proven, finalised, reverted, stale and paused examples.", + "steps": [ + "Compare explorer, wallet, receipt, RPC and customer API labels against authenticated evidence.", + "Interrupt finality and proof services and observe refresh/reconnect behaviour.", + "Check statements about privacy, Ethereum security and device support." + ], + "accept": "No stronger state is implied than verified; stale data is marked and failures are actionable. EVM compatibility is not labelled Ethereum security, and ZK technology is not automatically labelled transaction privacy.", + "evidence": "Cross-surface screenshots/logs; state mapping; claim review.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 20, + 25, + 35, + 37 + ], + "gate": "Technical readiness / claimed options", + "owner": "Wallet + light-client lead; independent security review", + "manual_page": 53 + } + ] + }, + { + "code": "OPS", + "title": "Independent operation and release security", + "source": [ + 21, + 24, + 25, + 26 + ], + "gate": "G5", + "owner": "Operations + release leads; independent operators", + "fixtures": "F4 isolated multi-operator network; F0 signed releases; F9 telemetry", + "summary": "A permissionless specification must remain operational without privileged infrastructure or unsafe automatic updates.", + "tests": [ + { + "id": "OPS-01", + "title": "Run the complete no-founder exercise", + "setup": "Use the P11 independent network, adequate honest participation and enough non-founder capacity for W.", + "steps": [ + "Remove founder miners, provers, aggregators, RPC, DNS/bootstrap dependencies and private support access.", + "Run the full P11 period while crossing real and separately labelled accelerated boundaries.", + "Introduce scheduled faults and have independent operators recover using published instructions." + ], + "accept": "No founder action, secret file, privileged key or emergency anti-chip rule is needed. P07/P08 outcomes hold within assumptions; any intervention is recorded as a failed no-rescue run, not erased.", + "evidence": "Operator roster/conflict checks; dependency removals; full activity/intervention log.", + "priority": "BLOCKER", + "profile": "P07; P08; P11", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 21, + 24, + 25, + 26 + ], + "gate": "G5", + "owner": "Operations + release leads; independent operators", + "manual_page": 54 + }, + { + "id": "OPS-02", + "title": "Diversify bootstrap and resist peer isolation", + "setup": "Start nodes without the default bootstrap host and give others adversarial peer lists.", + "steps": [ + "Attempt eclipse through peer concentration, stale discovery, poisoned DNS and repeated identities in an isolated lab.", + "Use independent documented discovery paths and validate returned chain data.", + "Measure synchronisation, peer diversity and recovery after benign connectivity returns." + ], + "accept": "No unauthenticated history is trusted; bootstrap has no hidden single-provider requirement. Isolation is detected/contained according to F0 and recovery meets P08 when assumptions return.", + "evidence": "Peer/discovery traces; eclipse scenarios; startup and recovery evidence.", + "priority": "BLOCKER", + "profile": "P01; P08; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 21, + 24, + 25, + 26 + ], + "gate": "G5", + "owner": "Operations + release leads; independent operators", + "manual_page": 54 + }, + { + "id": "OPS-03", + "title": "Separate update distribution from consensus authority", + "setup": "Use test signing keys and clean desktop/node installations with valid, stale and malicious packages.", + "steps": [ + "Offer signed updates with unexpected consensus rules, downgraded binaries and corrupted payloads.", + "Test explicit operator acceptance and the published signing-key incident procedure.", + "Confirm that distribution-key possession cannot independently activate new consensus rules." + ], + "accept": "Tampering/unauthorised rollback is rejected; updates do not silently transfer authority. Approved acceptance and activation are separate. No test touches production signing material.", + "evidence": "Package corpus; approval/activation traces; compromised-key rehearsal.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 21, + 24, + 25, + 26 + ], + "gate": "G5", + "owner": "Operations + release leads; independent operators", + "manual_page": 54 + }, + { + "id": "OPS-04", + "title": "Recover nodes from crash and storage damage", + "setup": "Use production database/snapshot paths with controlled interrupted writes and corrupted test storage.", + "steps": [ + "Crash during import, proof acceptance, reward application and snapshot generation.", + "Restore from independently verified snapshots or re-sync through documented procedures.", + "Compare roots, certificates, balances and processed-job IDs with an unaffected node." + ], + "accept": "No corrupt snapshot is trusted, no duplicate payout and no loss of authenticated final state. Recovery meets P08 where data is available; ambiguous corruption fails closed and is actionable.", + "evidence": "Crash schedule; snapshot hashes; root/balance diffs; recovery timing.", + "priority": "BLOCKER", + "profile": "P01; P08", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 21, + 24, + 25, + 26 + ], + "gate": "G5", + "owner": "Operations + release leads; independent operators", + "manual_page": 55 + }, + { + "id": "OPS-05", + "title": "Isolate untrusted proving workloads", + "setup": "Run hostile test jobs with secret canaries and restrictive worker permissions.", + "steps": [ + "Attempt filesystem escape, process spawning, resource exhaustion, network access and key-store reads.", + "Crash workers and inspect host, wallet and node availability plus dump/log contents.", + "Retry on every supported isolation backend and check dependency vulnerability handling." + ], + "accept": "No secret leakage or unauthorised host action; P09 resource containment holds. Worker failure does not compromise validator/wallet authority; unsupported isolation is not marketed as safe execution.", + "evidence": "Sandbox penetration report; canary logs; resource limits; host-integrity checks.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 21, + 24, + 25, + 26 + ], + "gate": "G5", + "owner": "Operations + release leads; independent operators", + "manual_page": 55 + }, + { + "id": "OPS-06", + "title": "Contain malicious network and API traffic", + "setup": "Use an authorised isolated load environment with declared resource and request-rate budgets.", + "steps": [ + "Send malformed headers, proofs, oversized messages, floods and invalid peer sequences.", + "Measure legitimate traffic, memory/disk growth and validator CPU use.", + "Test limit resets, peer reconnect and graceful degradation without disabling validation." + ], + "accept": "P09 abuse budgets hold; no unbounded allocation, persistent crash or invalid acceptance. Backpressure is visible and honest users retain the specified service at admitted load.", + "evidence": "Load/corpus manifests; resource series; valid-traffic metrics; incident traces.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 21, + 24, + 25, + 26 + ], + "gate": "G5", + "owner": "Operations + release leads; independent operators", + "manual_page": 55 + }, + { + "id": "OPS-07", + "title": "Detect failures with usable evidence and runbooks", + "setup": "Define alerts for invalid acceptance, conflicting finality, backlog, data loss, payout mismatch and stale status.", + "steps": [ + "Inject one instance of each monitored failure in the lab.", + "Have an unaffiliated operator diagnose it using only emitted evidence and published instructions.", + "Test redaction, metric freshness and duplicate-alert suppression without suppressing serious failures." + ], + "accept": "P10 alert/detection limits hold; every blocker produces actionable evidence. Monitoring does not leak secrets or mislabel intentional safe pauses as successful finality.", + "evidence": "Alert matrix; detection timelines; independent runbook exercise.", + "priority": "GATE", + "profile": "P09; P10", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 21, + 24, + 25, + 26 + ], + "gate": "G5", + "owner": "Operations + release leads; independent operators", + "manual_page": 56 + }, + { + "id": "OPS-08", + "title": "Repeat independent operation across releases", + "setup": "Use a clean previous supported version and the final candidate with independent operators.", + "steps": [ + "Perform documented rolling upgrade, rollback of non-consensus software where allowed and resynchronisation.", + "Cross activation with mixed versions and unavailable founder distribution hosts.", + "Re-run affected gates after changes and preserve prior failures and incident lessons." + ], + "accept": "No undocumented privileged migration or automatic consensus rewrite. All affected evidence is refreshed; P11 no-rescue results remain tied to the final release, not an earlier build.", + "evidence": "Upgrade/replay logs; invalidation map; repeated gate signatures.", + "priority": "BLOCKER", + "profile": "P00; P08; P11", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 21, + 24, + 25, + 26 + ], + "gate": "G5", + "owner": "Operations + release leads; independent operators", + "manual_page": 56 + } + ] + }, + { + "code": "UX", + "title": "Ember, payouts and operator control", + "source": [ + 14, + 21, + 25, + 26 + ], + "gate": "Operator readiness / G5", + "owner": "Desktop product + pool leads; independent usability study", + "fixtures": "F2 supported desktops; F8 user study; F4 honest/malicious pools", + "summary": "Successful participation must be practical for ordinary owners without hidden custody or loss of consensus authority.", + "tests": [ + { + "id": "UX-01", + "title": "Onboard ordinary owners on native desktop apps", + "setup": "Recruit the P10 first-time user cohort across Windows and macOS using supported physical hardware.", + "steps": [ + "Observe install, hardware detection, safety explanation and first accepted work without staff intervention.", + "Record download/data preparation separately as well as complete end-to-end time.", + "Test unsupported hardware and insufficient memory messaging rather than forcing a failed start." + ], + "accept": "P10 completion/time targets hold with no unsafe default or concealed prerequisite. The product is tested as the actual desktop app, not only a browser preview.", + "evidence": "Consent-based study records; task timings; failure reasons; compatibility outcomes.", + "priority": "GATE", + "profile": "P10", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent observed user study", + "status": "NOT RUN", + "source": [ + 14, + 21, + 25, + 26 + ], + "gate": "Operator readiness / G5", + "owner": "Desktop product + pool leads; independent usability study", + "manual_page": 57 + }, + { + "id": "UX-02", + "title": "Make pause, stop and safe tuning reliable", + "setup": "Run mining/proving on active desktops under contention and safe thermal stress.", + "steps": [ + "Use pause, stop, power limit, task selection and emergency local shutdown controls.", + "Crash or restart the UI while workers run and verify ownership of background processes.", + "Restore the original hardware settings and test power-saving/low-battery behaviour where supported." + ], + "accept": "P10 control latency and safe-state requirements hold. Stopping does not strand an uncontrolled process; tuning never depends on unsafe settings or silent privilege escalation.", + "evidence": "Control timings; process/settings audit; restart and safety traces.", + "priority": "BLOCKER", + "profile": "P01; P10", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 14, + 21, + 25, + 26 + ], + "gate": "Operator readiness / G5", + "owner": "Desktop product + pool leads; independent usability study", + "manual_page": 57 + }, + { + "id": "UX-03", + "title": "Show net earnings and compatibility honestly", + "setup": "Use known rewards, fees, energy readings, retries and operator-entered tariffs.", + "steps": [ + "Compare mining, internal proof and external proof income with authoritative ledgers.", + "Show gross/net estimates, measurement boundaries, tariff assumptions and payout status.", + "Test stale data, losses, negative margins and mining-only versus proving-compatible devices." + ], + "accept": "P10 reconciliation limits hold and uncertainty is visible. No guaranteed profits, fabricated fiat price or inferred proving support; provisional earnings are not shown as settled payments.", + "evidence": "UI/ledger comparisons; tariff fixtures; stale/negative examples.", + "priority": "BLOCKER", + "profile": "P01; P10; P12", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 14, + 21, + 25, + 26 + ], + "gate": "Operator readiness / G5", + "owner": "Desktop product + pool leads; independent usability study", + "manual_page": 57 + }, + { + "id": "UX-04", + "title": "Pay small operators without hidden custody", + "setup": "Use ordinary single-card balances and the actual pooling/payment path.", + "steps": [ + "Earn, request/receive payment, disconnect and reconnect; include low balances, fees and a pool outage.", + "Attempt redirection, delayed accounting and withdrawal of another user's entitlement.", + "Reconcile displayed balances with canonical entitlement and actual settlement." + ], + "accept": "P10 payout limits hold for the declared small-operator case. No unauthorised custody, redirection or unexplained loss; thresholds and fees are disclosed rather than masked by larger test balances.", + "evidence": "Single-card payout ledger; pool failure record; custody/authorisation review.", + "priority": "BLOCKER", + "profile": "P01; P10", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 14, + 21, + 25, + 26 + ], + "gate": "Operator readiness / G5", + "owner": "Desktop product + pool leads; independent usability study", + "manual_page": 58 + }, + { + "id": "UX-05", + "title": "Keep voting keys with the miner through pooling", + "setup": "Use an honest pool and a modified pool that replaces worker identity or voting credentials.", + "steps": [ + "Verify the consensus binding from performed work to the miner's retained key.", + "Attempt substitution, replay and reassignment without the miner's authorisation.", + "Leave the pool and verify retained voting/finality rights under F0." + ], + "accept": "No silent transfer of governance/finality authority. If the protocol cannot establish retained keys, this requirement fails; a pool-protocol name or user-interface promise does not pass.", + "evidence": "Work/key binding vectors; malicious-pool attempts; leave-pool authority check.", + "priority": "BLOCKER", + "profile": "P01; P09", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 14, + 21, + 25, + 26 + ], + "gate": "Operator readiness / G5", + "owner": "Desktop product + pool leads; independent usability study", + "manual_page": 58 + }, + { + "id": "UX-06", + "title": "Verify actual miner-selected work templates", + "setup": "Provide a pool interface with declared job-declaration support and independent miner templates.", + "steps": [ + "Submit miner-selected valid transaction templates and verify what is actually hashed and accepted.", + "Have a pool substitute or censor templates and test local verification/fallback.", + "Measure payout and acceptance consequences without moving authority to the pool." + ], + "accept": "The advertised selection control exists in accepted work, not only configuration. Undisclosed substitution is detected; supported independent operation remains practical under P10.", + "evidence": "Template commitments; accepted-block evidence; malicious-pool/fallback report.", + "priority": "BLOCKER", + "profile": "P01; P10", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 14, + 21, + 25, + 26 + ], + "gate": "Operator readiness / G5", + "owner": "Desktop product + pool leads; independent usability study", + "manual_page": 58 + }, + { + "id": "UX-07", + "title": "Expose actionable failures and safe updates", + "setup": "Create failed proofs, memory pressure, expired jobs, missing payouts and available software updates.", + "steps": [ + "Ask independent users to identify the issue, stop safely and follow the recommended action.", + "Test explicit update approval, version visibility and a failed/corrupt update.", + "Confirm diagnostic exports remove keys and private inputs while retaining useful evidence." + ], + "accept": "P10 task-success requirements hold; no silent update or false success state. Recovery instructions work on supported desktops and secret canaries never enter exported logs.", + "evidence": "Observed tasks; update traces; sanitised export tests.", + "priority": "BLOCKER", + "profile": "P09; P10", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 14, + 21, + 25, + 26 + ], + "gate": "Operator readiness / G5", + "owner": "Desktop product + pool leads; independent usability study", + "manual_page": 59 + }, + { + "id": "UX-08", + "title": "Publish competitive accessible software", + "setup": "Provide open documented builds, tuning parameters and known fee conditions for all supported platforms.", + "steps": [ + "Compare Ember against independently optimised permissible implementations on identical work.", + "Measure efficiency, fees, false rejection, installation and update transparency.", + "Scan for hidden developer fees, hardware whitelists, per-address privilege or undisclosed remote controls." + ], + "accept": "P10 relative-efficiency limits hold and all fees/privileges are explicit. No self-reported device tier earns consensus advantage. A superior external implementation triggers investigation, not selective exclusion.", + "evidence": "Matched software comparison; code/config review; fee/privilege inventory.", + "priority": "GATE", + "profile": "P02; P10", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 14, + 21, + 25, + 26 + ], + "gate": "Operator readiness / G5", + "owner": "Desktop product + pool leads; independent usability study", + "manual_page": 59 + } + ] + }, + { + "code": "COM", + "title": "Paid demand and sustainable delivery", + "source": [ + 4, + 17, + 18, + 24, + 26, + 27, + 31, + 32, + 33 + ], + "gate": "Commercial evidence", + "owner": "Commercial lead + independent financial/customer reviewer", + "fixtures": "F8 real consenting customers; F7 full service costs; private identity proofs", + "summary": "Devnet payouts and subsidised pilots demonstrate mechanics, not independent willingness to pay.", + "tests": [ + { + "id": "COM-01", + "title": "Deliver a genuine contracted proof pilot", + "setup": "Select one real external customer with a meaningful fixed workload and no required migration to Igneum.", + "steps": [ + "Agree program, inputs, proof format, deadline, price, failure/refund policy and verification method.", + "Run paid jobs through ordinary independently operated infrastructure.", + "Have the customer verify usefulness, correctness and its reason for choosing the service." + ], + "accept": "The pilot satisfies its actual contract and settles genuine external payment. Trial subsidies are disclosed and cannot satisfy the repeat-demand gate; no invented customer or testimonial.", + "evidence": "Redacted contract; verified jobs; settlement proof; consented customer confirmation.", + "priority": "GATE", + "profile": "P07; P14", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 17, + 18, + 24, + 26, + 27, + 31, + 32, + 33 + ], + "gate": "Commercial evidence", + "owner": "Commercial lead + independent financial/customer reviewer", + "manual_page": 60 + }, + { + "id": "COM-02", + "title": "Establish independent repeat purchasing", + "setup": "Use the P14 multi-customer observation period and ownership/conflict checks.", + "steps": [ + "Track paid purchases on distinct occasions, including refunds and stopped customers.", + "Audit related parties, project reimbursements, token grants and circular funding.", + "Reconcile external cash received with correctly delivered meaningful work." + ], + "accept": "P14 buyer, duration and volume minima are met without reimbursement or related-party substitution. Repeat orders are separate buying decisions, not a single payment split into many jobs.", + "evidence": "Anonymised buyer ledger; repeat-order dates; conflict review; net receipts.", + "priority": "GATE", + "profile": "P14", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 17, + 18, + 24, + 26, + 27, + 31, + 32, + 33 + ], + "gate": "Commercial evidence", + "owner": "Commercial lead + independent financial/customer reviewer", + "manual_page": 60 + }, + { + "id": "COM-03", + "title": "Demonstrate service and operator margins", + "setup": "Allocate all delivery costs, including aggregation, retries, hardware, power, host, network and support.", + "steps": [ + "Calculate gross contribution and fully loaded unit costs for each contracted workload.", + "Reconcile a representative operator's realised earnings against metered costs and opportunity cost.", + "Repeat under the declared demand and price sensitivities." + ], + "accept": "P14 contribution targets hold and at least the required operator cohort has positive realised contribution. Excluded overhead is visible; token appreciation or unpriced founder labour cannot silently create profitability.", + "evidence": "Unit-economics ledger; metered operator sample; allocation rules; sensitivity report.", + "priority": "GATE", + "profile": "P12; P14", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 17, + 18, + 24, + 26, + 27, + 31, + 32, + 33 + ], + "gate": "Commercial evidence", + "owner": "Commercial lead + independent financial/customer reviewer", + "manual_page": 60 + }, + { + "id": "COM-04", + "title": "Meet the customer service guarantee", + "setup": "Observe actual delivery deadlines, validity, failure handling and support over the contracted period.", + "steps": [ + "Count all accepted jobs, including failed, retried and abandoned cases.", + "Have the customer independently verify results and invoke one authorised refund/failure exercise.", + "Compare offered capacity and quoted price with what was actually delivered." + ], + "accept": "P07 and contracted obligations hold; validity has zero accepted exceptions. Failure terms are honoured, and demand beyond capacity is explicitly refused rather than quietly omitted from metrics.", + "evidence": "Customer-verifier records; SLO report; refunds; promised-versus-delivered comparison.", + "priority": "BLOCKER", + "profile": "P01; P07; P14", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 17, + 18, + 24, + 26, + 27, + 31, + 32, + 33 + ], + "gate": "Commercial evidence", + "owner": "Commercial lead + independent financial/customer reviewer", + "manual_page": 61 + }, + { + "id": "COM-05", + "title": "Compare against the buyer's real alternative", + "setup": "Identify a credible alternative supplier or in-house option for the same workload, proof format and security.", + "steps": [ + "Obtain comparable quotes or consented measured trials at the evaluation date.", + "Include integration, verification, deadlines and all operational costs, not only proof-generation time.", + "Document the customer's actual trade-off without inventing unavailable comparator evidence." + ], + "accept": "P15 commercial comparison is satisfied with like-for-like scope and a evidenced purchase reason. Missing alternative data remains MISSING; it is not scored as an Igneum win.", + "evidence": "Dated comparison; workload/security match; customer decision record.", + "priority": "GATE", + "profile": "P14; P15", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 17, + 18, + 24, + 26, + 27, + 31, + 32, + 33 + ], + "gate": "Commercial evidence", + "owner": "Commercial lead + independent financial/customer reviewer", + "manual_page": 61 + }, + { + "id": "COM-06", + "title": "Retain buyers after the pilot and subsidy period", + "setup": "Follow all recruited customers through the P14 observation period, including churn.", + "steps": [ + "Remove disclosed trial incentives before measuring repeat demand.", + "Track renewal, expansion, cancellation reasons, unresolved incidents and buyer concentration.", + "Review whether one affiliated or subsidised buyer dominates the apparent market." + ], + "accept": "P14 repeat/concentration conditions hold with honest denominator and churn reporting. Paying demand survives beyond a demonstration; unsatisfied or departed buyers are not removed retrospectively.", + "evidence": "Cohort/renewal ledger; churn notes; concentration and incentive report.", + "priority": "GATE", + "profile": "P14", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 17, + 18, + 24, + 26, + 27, + 31, + 32, + 33 + ], + "gate": "Commercial evidence", + "owner": "Commercial lead + independent financial/customer reviewer", + "manual_page": 61 + }, + { + "id": "COM-07", + "title": "Fund maintenance without assumed appreciation", + "setup": "Prepare a costed plan for development, review, infrastructure, support and incident response.", + "steps": [ + "Separate committed resources from revenue dependent on adoption or token price.", + "Stress lower income and an unexpected security/operations expense.", + "Verify responsible owners and continuity arrangements without changing fair-launch promises." + ], + "accept": "P13 committed-runway requirement holds and downside responses are documented. No uncommitted financing, rising token price or burn accounting is presented as available maintenance funding.", + "evidence": "Budget and commitment evidence; downside plan; owner/continuity roster.", + "priority": "GATE", + "profile": "P13", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 17, + 18, + 24, + 26, + 27, + 31, + 32, + 33 + ], + "gate": "Commercial evidence", + "owner": "Commercial lead + independent financial/customer reviewer", + "manual_page": 62 + }, + { + "id": "COM-08", + "title": "Let independent developers build useful integrations", + "setup": "Recruit unaffiliated developers unfamiliar with unpublished implementation details.", + "steps": [ + "Use public docs to deploy a supported application or integrate an external proof request and verification flow.", + "Record time, undocumented dependencies, workarounds and correctness issues.", + "Retest after documentation fixes without founder-written hidden integration code." + ], + "accept": "P14 developer-task minimum passes on the final release; all required public instructions exist. Successful bytecode deployment alone does not count as a working application or service integration.", + "evidence": "Consented developer logs; public examples; issue closure; verified end-to-end journeys.", + "priority": "GATE", + "profile": "P09; P14", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent integration study", + "status": "NOT RUN", + "source": [ + 4, + 17, + 18, + 24, + 26, + 27, + 31, + 32, + 33 + ], + "gate": "Commercial evidence", + "owner": "Commercial lead + independent financial/customer reviewer", + "manual_page": 62 + } + ] + }, + { + "code": "LEAD", + "title": "Comparative leadership evidence", + "source": [ + 4, + 22, + 25, + 27, + 31, + 32, + 33 + ], + "gate": "Leadership-contender decision", + "owner": "Independent assessment panel + product/economics reviewers", + "fixtures": "F8 peer/customer studies; full signed technical evidence; 90-day observation", + "summary": "A serious contention claim requires comparative outcomes and real adoption evidence, not just an internally green test dashboard.", + "tests": [ + { + "id": "LEAD-01", + "title": "Register a fair contemporary comparison", + "setup": "Choose at least the P15 peer coverage and an evaluation date before collecting confirmatory results.", + "steps": [ + "Include the plan's Ravencoin, Ergo and Firo reference set where comparable, then check for other relevant current options.", + "Freeze versions, supported hardware, methods, noninferiority margins and commercial alternatives.", + "Publish exclusions and prohibit cross-algorithm raw-hashrate comparisons." + ], + "accept": "The protocol covers material alternatives fairly and is signed independently. A missing or non-comparable feature is not scored zero; no arbitrary universal rank is inferred from selected metrics.", + "evidence": "Timestamped peer protocol; source/version records; comparison/exclusion rationale.", + "priority": "GATE", + "profile": "P15", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Pre-registered comparative study", + "status": "NOT RUN", + "source": [ + 4, + 22, + 25, + 27, + 31, + 32, + 33 + ], + "gate": "Leadership-contender decision", + "owner": "Independent assessment panel + product/economics reviewers", + "manual_page": 63 + }, + { + "id": "LEAD-02", + "title": "Demonstrate comparable operator advantages", + "setup": "Use matched user tasks and operating conditions on the selected GPU-first networks.", + "steps": [ + "Measure install-to-first-accepted-work, software overhead versus each network's tuned baseline, payout friction and retained control.", + "Measure rejection/availability under the same network conditions; report fees separately.", + "Use blinded analysis where possible and independent runs for decisive differences." + ], + "accept": "P15 noninferiority and superiority requirements hold on meaningful comparable dimensions. No raw hashes from different algorithms are compared, and transient token price is not labelled engineering superiority.", + "evidence": "Matched task data; uncertainty/effect sizes; independent comparison report.", + "priority": "GATE", + "profile": "P02; P10; P15", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 22, + 25, + 27, + 31, + 32, + 33 + ], + "gate": "Leadership-contender decision", + "owner": "Independent assessment panel + product/economics reviewers", + "manual_page": 63 + }, + { + "id": "LEAD-03", + "title": "Substantiate the specialist-coexistence claim", + "setup": "Assemble G1-G4 plus frozen rules and all surviving-adversary assumptions.", + "steps": [ + "Have independent reviewers trace each public competitiveness statement to its narrowest evidence.", + "Separate measured GPUs, modelled silicon and economic scenarios in all summaries.", + "Evaluate residual uncertainty, excluded technologies and the no-new-rules counterfactual." + ], + "accept": "All claimed envelopes meet P04/P12 without unsupported universal bounds. Reviewers agree the evidence supports scoped commodity competitiveness even when chips remain compatible; an exact chip-arrival probability is not inferred.", + "evidence": "Claim-to-evidence map; signed envelope review; limitations statement.", + "priority": "GATE", + "profile": "P04; P12; P15", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 22, + 25, + 27, + 31, + 32, + 33 + ], + "gate": "Leadership-contender decision", + "owner": "Independent assessment panel + product/economics reviewers", + "manual_page": 63 + }, + { + "id": "LEAD-04", + "title": "Observe ordinary-operator retention and margins", + "setup": "Recruit the P16 independent cohort before observing results; use privacy-preserving evidence.", + "steps": [ + "Follow participation, realised margin, hardware changes, failures and reasons for leaving for 90 days.", + "Report trial incentives separately and include every initial participant in retention denominators.", + "Compare behaviour with matched alternatives where feasible; disclose absence of an actual downturn." + ], + "accept": "P16 retention/margin minima hold with verified independence and no removal of churned users. Simulated downturns cannot be called observed bear-market retention; historical claims stay limited to the period measured.", + "evidence": "Pseudonymous cohort ledger; margin/retention calculations; departure reasons.", + "priority": "GATE", + "profile": "P12; P16", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 22, + 25, + 27, + 31, + 32, + 33 + ], + "gate": "Leadership-contender decision", + "owner": "Independent assessment panel + product/economics reviewers", + "manual_page": 64 + }, + { + "id": "LEAD-05", + "title": "Measure control and dependency concentration", + "setup": "Audit operational control of mining, voting, proving, aggregation, hosting and software distribution separately.", + "steps": [ + "Use opt-in attestations, observed dependencies and independent corroboration; disclose uncertain common ownership.", + "Compare concentration and provider-removal outcomes to the approved security and availability assumptions.", + "Check that pooled payments do not hide authority concentration and hardware vendors are not equated with operators." + ], + "accept": "P11/P16 concentration requirements hold within disclosed uncertainty; unidentified control cannot be counted as independent. No single removable dependency is falsely marketed as decentralised operation.", + "evidence": "Control/failure-domain map; uncertainty notes; concentration/removal results.", + "priority": "GATE", + "profile": "P11; P16", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 22, + 25, + 27, + 31, + 32, + 33 + ], + "gate": "Leadership-contender decision", + "owner": "Independent assessment panel + product/economics reviewers", + "manual_page": 64 + }, + { + "id": "LEAD-06", + "title": "Complete the reliability observation window", + "setup": "Observe the final candidate and approved compatible updates for the full P16 real-time period.", + "steps": [ + "Measure promised service availability, invalid acceptance, finality safety, payouts and incident impact.", + "Reconcile external probes, customer records and operator logs, including maintenance and exclusions.", + "Repeat affected critical tests after every material change; reset observation where comparability breaks." + ], + "accept": "P16 availability and safety criteria hold on live observation; no hidden downtime or compressed-time substitution. This supports the recorded window only, not multi-year operational maturity.", + "evidence": "90-day SLO ledger; independent probes; incident reports; change/retest history.", + "priority": "BLOCKER", + "profile": "P01; P16", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 22, + 25, + 27, + 31, + 32, + 33 + ], + "gate": "Leadership-contender decision", + "owner": "Independent assessment panel + product/economics reviewers", + "manual_page": 64 + }, + { + "id": "LEAD-07", + "title": "Issue an independent contender assessment", + "setup": "Provide the full evidence packet, commercial results, comparative study and unresolved-limit register to the panel.", + "steps": [ + "Check every mandatory and claimed-option test, source requirement and approved threshold.", + "Require separate signoffs for hardware/economics, security/operations and customer/operator evidence.", + "Document dissent and challenge any inference that passing an internal checklist proves number-one rank." + ], + "accept": "Every required gate is PASS with no unresolved material challenge, critical/high defect or missing comparator/customer evidence. The panel supports a credible leadership-contender conclusion within scope, not a guaranteed rank.", + "evidence": "Signed assessment; full status index; dissent/limitations; approved claim wording.", + "priority": "GATE", + "profile": "P00; P15; P16", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Independent final assessment", + "status": "NOT RUN", + "source": [ + 4, + 22, + 25, + 27, + 31, + 32, + 33 + ], + "gate": "Leadership-contender decision", + "owner": "Independent assessment panel + product/economics reviewers", + "manual_page": 65 + }, + { + "id": "LEAD-08", + "title": "Keep leadership claims valid after release", + "setup": "Define material-change triggers and scheduled reviews before publishing the assessment.", + "steps": [ + "Refresh competitor, hardware-cost, demand and security evidence at the P16 cadence.", + "Test a newly credible specialist, lost customer, major outage and verifier change against invalidation rules.", + "Withdraw or narrow stale claims promptly while publishing the new evidence status." + ], + "accept": "Claims remain dated, scoped and revisable; material contrary evidence reopens the appropriate gate. The network may remain usable while a leadership claim is suspended. No permanent self-awarded certification.", + "evidence": "Review calendar; invalidation drills; versioned public claim register.", + "priority": "GATE", + "profile": "P00; P16", + "cadence": "Release candidate; repeat after relevant changes", + "method": "Automated + independent review", + "status": "NOT RUN", + "source": [ + 4, + 22, + 25, + 27, + 31, + 32, + 33 + ], + "gate": "Leadership-contender decision", + "owner": "Independent assessment panel + product/economics reviewers", + "manual_page": 65 + } + ] + } + ], + "profiles": { + "P00": { + "title": "Frozen scope and approval", + "requirements": [ + "Approve the release manifest, supported roles, numerical profiles, mandatory scenarios, trust/fault model, workload W, adapters and claims before confirmatory tests. Unknown values are BLOCKED, not defaults.", + "Core safety and authentication invariants admit no waiver. Proposed performance or commercial targets may be replaced only before the confirmatory run, with an independent rationale and a versioned public scope.", + "After a failure, weakening a target creates a different claim and requires a new assessment. Preserve all failed runs; do not average a blocker away." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P01": { + "title": "Correctness and negative-test depth", + "requirements": [ + "Zero observed invalid acceptance, unauthorised signature, conflicting finality within assumptions, duplicated reward or unexplained cross-backend state/hash disagreement.", + "Minimum proposed campaign: 1,000,000 full-hash vectors per supported backend across all families, plus at least 10,000 malformed/boundary cases per relevant parser or binding class. Include exhaustive small-domain cases and historical regressions.", + "All prescribed critical mutants must be detected. This sampling target is not a bound on cryptographic failure probability and does not replace independent reasoning about soundness or safety." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P02": { + "title": "Hardware coverage and reproducibility", + "requirements": [ + "At least 12 physical retail configurations: at least 3 NVIDIA, 3 AMD and 2 Apple configurations, at least two discrete-GPU generations, an advertised 8 GB mining tier and 12 GB proving tiers where claimed. Record usable, not nominal, memory.", + "Declare a competitive core of at least 6 configurations spanning every advertised vendor and at least two discrete generations before optimisation. The wider cohort remains mandatory for access and economic tests; it cannot be silently dropped.", + "Use 5 paired 30-minute steady-state runs per primary cell after at least 15 minutes of warm-up and a stable temperature trend. Calibrated wall meter uncertainty must be at most 2%. Run a 7-day soak on representative low/mid/high tiers.", + "Three unaffiliated operators participate; every competitive-core cell is reproduced by at least two. Identical-SKU energy/accepted-work results must agree within 5% after declared environment corrections; unexplained variance blocks the headline." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P03": { + "title": "Candidate improvement and honest-card budget", + "requirements": [ + "For production candidate changes, per mandatory GPU cell: no more than 5% increase in joules per accepted work and no more than 2% decrease in accepted throughput versus the paired tuned baseline. Absolute safety limits always apply.", + "G2 requires at least a 10% reduction in the strongest evaluated specialist advantage after redesign, outside the declared measurement/model uncertainty, while meeting those budgets. A failed experiment is not a successful upgrade.", + "Existing clock-lock savings belong in the baseline. Long programs cannot pass by adding enough equally costly work to both devices to improve a ratio while materially worsening honest operation." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P04": { + "title": "Scoped specialist-competition target", + "requirements": [ + "Define R_E as GPU wall joules per accepted work divided by the lowest credible complete-system specialist joules for that same work. The proposed target is R_E at most 1.5 for every competitive-core cell at the same node and one node ahead.", + "Evaluate at least three materially distinct specialist architectures, with one programmable multi-family design, and a second independent reviewer. Include shared/reduced memory, hybrid execution, selective participation and realistic power/host costs.", + "Publish two-node-ahead and modular/reused-IP stress cases; they must satisfy the predeclared P12 economic envelope. No universal ceiling for unknown future hardware is claimed. Report model bounds separately from statistical confidence.", + "A lower-bound specialist estimate, not a convenient average or a deliberately constrained reference architecture, drives the conservative comparison. Undefined or unbounded decision-critical assumptions make the result BLOCKED." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P05": { + "title": "Measurement and inference protocol", + "requirements": [ + "Pre-register primary metrics, cohorts, holdout seeds, run order, exclusions and analysis before confirmation. Keep tuning/training runs separate from holdout runs.", + "Use independent runs/operators as measurement units. Report point estimates, two-sided 95% measurement intervals and absolute sample counts; handle time-series dependence with a declared block or run-level method.", + "Apply conservative uncertainty to pass decisions. A confidence interval around measured GPU energy does not capture unknown ASIC architectures; model parameter ranges and expert judgement must be reported as such.", + "Never compare raw hashes per second across different algorithms. Do not transform a five-year scenario sweep into a probability of chip arrival or a guarantee of future profitability." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P06": { + "title": "Memory and support policy", + "requirements": [ + "All advertised role/configuration combinations must finish without OOM, corruption or unsafe fallback. Publish a component memory budget, including display/OS, driver, miner, prover, aggregation and epoch construction.", + "Proposed support horizon: at least 24 months of known schedule compatibility for the advertised entry tier, unless a narrower horizon is prominently approved before sale or launch. Removal changes the claim and must pass ECO-07.", + "Treat 5.5 / 8.5 / 11.5 GiB as source candidates, not imposed final rules. Simultaneous operation, eviction and time-sharing are distinct advertised modes with separately measured cost." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P07": { + "title": "Proof service capacity and fairness", + "requirements": [ + "Freeze W as a meaningful workload mix, input sizes, proof format, fleet and requests/hour. Primary proposed target: 72 hours at W, plus 24 hours at 1.2W; at least 99.5% accepted jobs delivered valid within the contracted deadline.", + "Default delivery targets for the declared internal reference workload: p95 at most 60 seconds and p99 at most 120 seconds from input-ready assignment through verified delivery. Also publish request-to-delivery including input wait; no claim may omit that delay.", + "Request-to-delivery p99 must meet the separately approved customer deadline. Payment p99 must be at most 10 minutes after verified payable eligibility, with chain finality time reported separately. These defaults do not override a stricter contract.", + "No statistically supported positive backlog drift at steady load, no silent drops; after 2W for 15 minutes, drain excess backlog within 30 minutes of return to W. Report rejected demand and accepted-job success separately.", + "Proposed advertised-tier fairness: at least 90% timely valid assigned completions are paid under the approved rules; avoidable duplicate/retry work is at most 10% of total work. Reassignment policy must bound abandonment without promising every assignment a reward." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P08": { + "title": "Fault assumptions and recovery", + "requirements": [ + "F0 must state the exact safety threshold, quorum and authority-transition rule; the synchrony/participation assumptions for liveness; trusted inputs; and clock/expiry semantics. This manual supplies no substitute consensus rule.", + "Exercise threshold-minus/at/plus cases, the 40/40/20 partition fixture, signing outages and 31/35/60/90 logical-day expiry cases. Preserve safety when liveness assumptions fail; do not demand finality from an unavailable quorum.", + "After assumptions and input availability are restored: service replacement within 10 minutes and deterministic network convergence within 30 minutes on the reference topology. Different certified bounds must be approved beforehand.", + "Accelerated-time simulation and real elapsed operation are separate evidence classes. Recovery may not reverse a guarantee previously represented as final." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P09": { + "title": "Security and bounded resource requirements", + "requirements": [ + "Zero unresolved critical or high-severity security findings on the claimed release. Independent scopes must cover consensus, proof soundness/parameters, implementation bypasses, wallet/isolation and relevant operational controls.", + "Review the intended proof-system security level and assumptions explicitly; do not infer a security-bit claim from random rejection tests. Version every verifier, program and parameter set.", + "Freeze maximum valid/invalid verification time, memory, disk and admission rates for ordinary validator hardware. At rated valid load plus the approved hostile load, no unbounded growth, invalid acceptance or unrecoverable process failure.", + "For supported wallet fee-estimation cases, proposed absolute error at most 5% versus the specified charge when inputs are unchanged; deterministic fee-cap handling and explicit uncertainty otherwise. Customer contracts remain separately binding." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P10": { + "title": "Ordinary-operator product targets", + "requirements": [ + "At least 30 unaffiliated first-time study participants across supported Windows/macOS combinations. At least 90% install, configure safely and submit accepted work without staff help; p90 active setup at most 15 minutes. Publish complete download/dataset time separately.", + "Pause/stop acknowledgement within 2 seconds, safe worker stop within 5 seconds where no documented atomic operation prevents it, and reliable restoration of original tuning settings. No hidden custody or silent update.", + "Net-energy/fee displays reconcile within 5% under the declared measurement boundary. Incremental rejected-work loss on the normal home-link profile is at most 2 percentage points over the matched datacentre profile.", + "Open miner efficiency is within 5% of the best independently tuned permitted implementation on identical work. For the declared single-card payout case, p95 payable-to-payment at most 24 hours and total payout friction at most 2% of earned value.", + "Critical alerts are emitted within 60 seconds of detectable evidence. At least 90% of study users can identify the injected failure and follow the published safe action. No control target excuses a security failure." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P11": { + "title": "No-founder exercise and independence", + "requirements": [ + "At least 10 verified unaffiliated operators, three independently administered network/hosting domains and sufficient honest weight/capacity to satisfy F0 and W after founders are removed.", + "Run at least 30 real elapsed days without founder mining, proving, aggregation, bootstrap, required RPC, private files or privileged interventions. Cross all known logical transitions separately without calling accelerated time real history.", + "Document control by role and common dependencies; uncertain identities are not counted as independent. Within-assumption withdrawals must satisfy P08; losing more than the assumed quorum may cause a visible safe pause." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P12": { + "title": "Five-year coexistence envelope", + "requirements": [ + "Freeze a sourced revenue reference R and mandatory worlds before results. Sweep 0.25R, R, 4R and 10R; electricity at $0.03/$0.10/$0.25/$0.40 per kWh; 1/3/5-year productive life; zero/$20M/$75M development; private mining and hardware sales; no/normal/spiking external demand.", + "Those values are proposed stress inputs, not current prices or forecasts. Declare which worlds have enough funded demand for rational ongoing service before running; retain collapse worlds as explicit safety/exit tests, not profitable successes.", + "Proposed matched-tariff new-entry target in every mandatory sustainable world: median GPU/specialist total cost per accepted work at most 1.5, 90th percentile at most 1.75, and no advertised competitive-core cell above 2.0. Publish every cell, including heterogeneous tariffs.", + "At least three purchasable GPU configurations across at least two advertised vendors must have positive modelled new-entry economics; at least 75% of the entry cohort must have positive marginal operating economics in those worlds. Report model uncertainty and failure regions.", + "Do not impose GPU market share, specialist production limits, token appreciation, full research-cost recovery or automatic chip death to force the result. Any such condition must become an explicit limitation rather than a hidden assumption." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P13": { + "title": "Maintenance continuity", + "requirements": [ + "Before a readiness claim, document at least 12 months of committed maintenance resources at the approved operating scope. Include engineering, security review, infrastructure, support and incident response.", + "Use independently reviewable commitments and downside budgets. Uncommitted future sales, rising token prices, burned fees or assumed fundraising are not available resources.", + "This is a proposed governance test, not a directive to change the supply cap, issuance allocation or fair-launch design." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P14": { + "title": "Genuine commercial and developer proof", + "requirements": [ + "At least three unrelated paying buyer organisations, each making at least three separate purchase decisions across at least 30 days; at least 1,000 meaningful verified external jobs in aggregate. Split invoices do not create independent demand.", + "No project reimbursement, circular funding or undisclosed related party counts. Report customer concentration and churn; proposed maximum largest-buyer share is 70% of qualifying revenue.", + "At least 20% aggregate contribution margin after directly attributable delivery costs, retries, refunds and support; publish fully loaded economics separately. At least 75% of sampled eligible operators have positive realised contribution on the declared workload.", + "At least five unaffiliated developers complete a useful supported application or proof-service integration using public documentation. Customer confirmation and raw commercial evidence may remain confidential to the reviewer." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P15": { + "title": "Comparative contention threshold", + "requirements": [ + "Pre-register at least three relevant operating GPU-first peers, plus a real proving alternative for customer comparisons. Verify current versions at execution time. The source reference set is a starting point, not a claim about current rankings.", + "Require at least three meaningful comparable dimensions with no material inferiority beyond a pre-agreed 10% margin against the best valid comparator, and at least two independently evidenced advantages against at least two peers.", + "Advantages must be either a greater-than-10% measured improvement outside uncertainty or a directly tested control/capability difference with demonstrated user value. Non-comparable or missing data is not a win.", + "A panel with hardware/economics, security/operations and customer/operator expertise must support the scoped contender conclusion. Passing these judgement-based thresholds does not certify a universal number-one ranking." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + }, + "P16": { + "title": "Observed durability and claim freshness", + "requirements": [ + "At least 90 real elapsed days on the final compatible release family, at least 30 independently verified operators, and transparent eligibility/churn denominators. Material uncomparable changes reset affected observations.", + "Proposed outcomes: at least 60% day-90 operator retention and at least 75% of eligible observed operators with positive measured marginal operation over the period. Report incentives and electricity assumptions; do not claim a downturn was observed if it was not.", + "At least 99.9% availability for the declared customer service during eligible operating conditions, with all-in availability also reported; zero accepted invalid proofs or conflicting finality within F0 assumptions. Do not remove real incidents as maintenance to force a pass.", + "Run fault injection on isolated infrastructure, not unsuspecting customers. Publish planned test windows separately. Reassess claims at least quarterly and immediately after material hardware, protocol, economics or security changes." + ], + "status": "PROPOSED - REQUIRES APPROVAL" + } + }, + "fixtures": [ + { + "id": "F0", + "title": "Release and assurance manifest", + "contents": "Exact commits, binaries, genesis/network ID, mining class, dataset schedule, EVM fork/deviations, program/verifier IDs, fees, supply, quorum/fault rules, trust anchors, activation and supported roles." + }, + { + "id": "F1", + "title": "Clean build environments", + "contents": "Pinned toolchains, dependency locks, clean OS images and documented signing/notarisation boundaries. No production secrets or private founder files." + }, + { + "id": "F2", + "title": "Hardware and measurement lab", + "contents": "Approved physical GPU cohort, calibrated wall meters, stable thermal conditions, driver/OS images and realistic home/datacentre link conditions." + }, + { + "id": "F3", + "title": "Workload and oracle catalogue", + "contents": "Fixed full-hash and EVM/proving jobs, independent reference implementations, real customer-sized payloads, held-out seeds and complete expected results." + }, + { + "id": "F4", + "title": "Authorised fault network", + "contents": "Independent nodes/operators; controllable latency, loss, clocks, partitions, storage faults and role withdrawals. Actual consensus paths plus separately labelled simulators." + }, + { + "id": "F5", + "title": "Negative and regression corpus", + "contents": "Malformed transactions/proofs, wrong roots/IDs, duplicate payments, bad authority tables, historical failures and deliberately faulty code mutants." + }, + { + "id": "F6", + "title": "Specialist implementation pack", + "contents": "Functionally checked architectures, RTL/physical estimates where feasible, memory and board assumptions, cost inputs, adaptation paths and uncertainty ranges." + }, + { + "id": "F7", + "title": "Economic and incentive models", + "contents": "Independently reproducible costs, entry/exit/difficulty policies, scenario grid, operator opportunity costs and money-flow conservation fixtures." + }, + { + "id": "F8", + "title": "User/customer/peer studies", + "contents": "Consenting unaffiliated users, contracted meaningful workloads, private ownership checks, dated competitor methods and independent analysis." + }, + { + "id": "F9", + "title": "Evidence and status vault", + "contents": "Immutable run IDs, raw logs, hashes, analysis code, exclusions, defects, reviewers, signatures, privacy controls and public redacted summaries." + } + ], + "source_sha256": "418b3b9f68f96a413872fecb16f8508a40063891c70054c65e92e6e5f5fb70b6", + "scope_note": "Test design, not executed evidence. All numeric additions are proposed, not source-approved protocol rules. Optional claimed features require their tests; excluded features earn no pass credit.", + "all_pass_note": "Independent passage of all mandatory and claimed-option gates, including commercial and comparative observation, can support a scoped leadership-contender assessment. It does not prove a universal rank or eliminate unknown future hardware risks.", + "manual_page_count": 73 +} \ No newline at end of file diff --git a/docs/plans/igneum-2.0-test-standard.txt b/docs/plans/igneum-2.0-test-standard.txt new file mode 100644 index 000000000..4bd594968 --- /dev/null +++ b/docs/plans/igneum-2.0-test-standard.txt @@ -0,0 +1,4315 @@ + 08 OCTOBER 2026 + + ASSURANCE EDITION / 1.0 + + + + +THE 2.0 VALIDATION PROGRAMME + + + + +2.0 +Test & acceptance +standard. +The evidence required to become a credible +contender for GPU-network leadership. + + + + +128 16 G1-G5 +TEST CASES TEST SUITES DELIVERY GATES + + + + + STATUS / PROPOSED. NOT EXECUTED. + + + Independent hardware, security, economic, customer and comparative evidence. No guaranteed + rank. No assumed chip death. No emergency anti-chip rescue in the baseline case. + + + + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 1 / 73 + TEST STANDARD / 1.0 + + + + +DOCUMENT MAP + + + +The complete test programme. +A navigable specification for engineering teams, independent reviewers and the release decision. +READ FIRST THE TEST CATALOGUE + + +Assurance contract 3 GOV / Release identity and evidence 18 + +Execution rules 4 GPU / Whole-system GPU measurements 21 + +Source traceability 5 POW / Proof-of-work correctness and coupling 24 + +Gate dependencies 6 ADV / Programmable specialist adversaries 27 + +Approval register 7 ROT / Epochs, seeds and memory transitions 30 + +Shared fixtures 8 ECO / Five-year coexistence economics 33 + +Hardware thresholds 9 EVM / Execution and developer compatibility 36 + +Correctness and support 10 ZKP / Consensus-enforced proof validity 39 + +Capacity and independence 11 CAP / Sustained proving and delivery 42 + +Security and Ember 12 INC / Rewards, incentives and selfish operators 45 + +Economics and funding 13 FIN / Consensus safety and recovery 48 + +Commercial and field evidence 14 VER / Wallets, receipts and data availability 51 + +Execution sequence 15 OPS / Independent operation and release security 54 + +Measurement controls 16 UX / Ember, payouts and operator control 57 + +Suite ownership map 17 COM / Paid demand and sustainable delivery 60 +APPENDICES + LEAD / Comparative leadership evidence 63 + +Evidence record template 66 + +Defects and retesting 67 + +Gate sign-off sheet 68 + +Sources and public wording 69 + +Full test index 70 + + + + +Read the numbers as proposals. P00-P16 require approval. Source-page references preserve the original 2.0 plan. Case and +index links open the exact procedure. + + + + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 2 / 73 + TEST STANDARD / 1.0 + + + + +01 / ASSURANCE CONTRACT + + + +What a full pass earns. +The objective is a defensible leadership-contender case. A green checklist is not a universal ranking +certificate. + + + THE GOVERNING OBJECTIVE + + + Someone can build one, but ordinary GPU owners remain competitive, the supplier cannot obtain a + lasting overwhelming advantage, and the network does not depend on emergency intervention to + survive. + + + +This manual turns the supplied 37-page plan into 128 test cases across 16 suites, with procedures, pass +criteria, evidence, owners, review roles and source traceability. It is a test specification, not a completed +audit, deployed change or runnable test harness. + + DECISION EVIDENCE REQUIRED + + + All applicable baseline, correctness, security, capacity and operator-control tests + Engineering-ready + pass on the pinned release. + + G1-G4 and the frozen-rule test pass, including an adaptable specialist with + Coexistence-supported + already-funded development. + + Engineering and coexistence gates plus real paid demand, independent peer + Leadership contender + comparisons and the 90-day observation all pass. + + Not established by this manual. Ranking requires a defined external metric, + Number one + current competitors and sustained market evidence. + + +The interpretation of all pass +Every mandatory and claimed-option test must pass with evidence and independent review. Optional +excluded capabilities receive EXCLUDED, never PASS or a performance credit. Core requirements cannot be +removed to create a green dashboard. Finite tests support only the stated hardware, economic, threat-model +and observation scope. + + INITIAL STATUS + + + All 128 tests are NOT RUN. All new numerical thresholds are PROPOSED and require pre-run + approval. No new claim of implementation, current deployment or independent verification is made. + + + + +Basis: 2.0 plan pp. 3-5, 23-27 and 31-33. New test design is explicitly proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 3 / 73 + TEST STANDARD / 1.0 + + + + +02 / EXECUTION RULES + + + +No greenwashing the result. +Separate experimental outcomes from implementation status, economic claims and ranking judgements. + + + STATE EXACT MEANING + + + No valid execution packet exists for the candidate release. This is the initial state of every + NOT RUN + case. + + A required input, approved threshold, adapter, environment or independent reviewer is + BLOCKED + missing. + + An invariant, threshold or required outcome is violated. Retrying does not erase this + FAIL + result. + + All pre-registered conditions pass and the prescribed reviewer accepts the complete + PASS + evidence. + + Uncertainty, conflicting observations or inadequate coverage prevent a supported + INCONCLUSIVE + decision. + + A predeclared optional capability is absent and unclaimed. It is not a pass and cannot hide + EXCLUDED + a failed core feature. + + +Stop rules +Immediately stop and isolate any test that reveals unauthorised signing, accepted invalid proofs, conflicting +finality within assumptions, unsafe hardware settings or real-data leakage. Preserve evidence; do not +continue merely to improve the pass percentage. + +No averaging away security +A severe safety failure is a blocker even if every performance test passes. A hardware energy ratio does not +substitute for total-cost competitiveness. Paid testnet rewards do not substitute for external revenue. A +modelled ASIC is not a manufactured-chip measurement. + +An experiment can finish and still fail +G2 requires an improved production candidate under the approved cost limits. Negative research is useful +but does not satisfy that outcome. Replacing an unsuccessful hypothesis is legitimate; changing the target +after observing results requires a new frozen protocol and reassessment. + + DO NOT TEST UNSUSPECTING USERS + + + Fault injection, hostile records, key-compromise drills and overload runs belong on authorised + isolated infrastructure with test funds and keys. Customer trials require explicit agreement and + data-handling controls. + + + + +Basis: 2.0 plan pp. 5, 23-27. Assurance rules and workflow are proposed here. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 4 / 73 + TEST STANDARD / 1.0 + + + + +03 / REQUIREMENT TRACEABILITY + + + +Every plan theme has a test. +S-page references below refer to the supplied IGNEUM_2.0_Plan.pdf, not to this manual. + + + SOURCE REQUIREMENT S-PAGES TEST SUITES + + + Objective, evidence and defensible claims 3-5, 27 GOV; LEAD + + Reported v6 baseline and pending measurements 6 GPU + + Keep/change/remove decision register 7 POW; ROT; GOV + + Accepted-work cost and commodity access 8 GPU; ECO; UX + + Resource coupling and optional FP32 9 POW; ADV + + Memory sharing, shortcuts and program selection 10 POW; ADV + + Rotation, seed pipeline and dataset policy 11 ROT; GPU; FIN + + Programmable and physically credible opponent 12 ADV + + Five-year and sunk-development economics 13 ECO; INC + + Ember, pooling, keys and accessible payouts 14 UX; OPS; FIN + + EVM, zkVM and sovereign architecture 15, 34-37 EVM; ZKP; VER + + Consensus proof enforcement and rewards 16 ZKP; INC + + Full proving pipeline and paying customers 17 CAP; COM + + Mining/proving coexistence and incentives 18 GPU; CAP; INC; ECO + + Finality, authority, expiry and recovery 19 FIN; ROT + + Wallets, receipts, oracles and availability 20 VER + + Independent operation and release controls 21 GOV; OPS + + Future hardware and fair peer comparisons 22 ADV; LEAD + + G1-G5, acceptance, risks and ownership 23-26 All suites; gate sign-off + + Leadership/adoption assessment in full source 31-33 COM; LEAD + + Architecture conditions in full source 34-37 EVM; ZKP; CAP; VER + + +S-pages 1-2 and 28-30 are title/navigation/provenance/reference material. They are preserved through this source map and +the source hash, not represented as additional protocol requirements. + + + +Source: full 2.0 plan, pp. 3-37. Test allocation is a proposed extension. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 5 / 73 + TEST STANDARD / 1.0 + + + + +04 / GATE DEPENDENCIES + + + +Pass outcomes, not features. +G1-G5 retain the source plan names. G0, technical readiness and the contender decision are proposed +execution controls. + + + GATE PRIMARY EVIDENCE RELEASE CONSEQUENCE + + + No formal run or public pass before + G0 / Freeze GOV; approved P-profiles; F0; test adapters + approval. + + No validated hardware claim without + G1 / Baseline GPU; build reproducibility; exact correctness + reproduction. + + No improvement claim from a + G2 / Experiments POW; candidate GPU costs; redesigned ADV + negative hypothesis. + + No broad resistance claim from one + G3 / Adversary ADV; physical/whole-system envelope + weak design. + + No durability claim based on assumed + G4 / Coexistence ECO; INC; adaptation and sunk costs + chip expiry. + + No no-rescue claim from a + G5 / No rescue ROT; FIN; OPS; independent real nodes + founder-supported demo. + + No mainnet-ready claim with missing + Technical readiness EVM; ZKP; CAP; VER; UX; critical OPS + enforcement or safety. + + Commercial evidence COM; actual external verification/payment Devnet activity is insufficient. + + Supports a scoped contention + Contender decision All preceding gates plus LEAD + assessment, not guaranteed rank. + + +Independent approval paths +Hardware/economics reviewers approve G1-G4. Cryptography/consensus/operations reviewers approve +technical readiness and G5. Customer/operator/comparative reviewers approve commercial and LEAD +evidence. The implementation author cannot be the sole approver of their own result. + + NO COMPENSATING SCORE + + + Do not weight the gates into a single average. A strong UI cannot compensate for invalid-proof + acceptance; customer revenue cannot compensate for broken finality; a good model cannot replace + independent operation. + + + + +Basis: 2.0 plan pp. 23-27. No gate is complete in this edition. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 6 / 73 + TEST STANDARD / 1.0 + + + + +05 / P00 APPROVAL REGISTER + + + +Freeze what the plan leaves open. +The source plan deliberately left numerical tolerances and implementation details for approval. Do not +invent them during a test. + + + FIELD TO APPROVE REQUIRED VALUE OR RECORD + + + Source and binary hashes, genesis/chain identity, protocol versions, exact + Candidate identity + dependency locks. + + Work/order rule, quorum/fault bounds, authority transitions, liveness + Consensus specification + assumptions, expiry and recovery. + + Generator/semantics, families, seed/VDF mechanism, activation and dataset + Mining and seeds + schedule. + + EVM fork and deviations; permitted program, verifier and parameter hashes; + Execution and proof identity + authenticated reward inputs. + + Supply, fee allocation, burns, payouts, assignment windows, duplicate policies and + Economic rules + derived security budget. + + Supported device/OS/role cells; light-client anchors; claimed receipt/oracle + Product and trust scope + guarantees; excluded features. + + Hardware cohort, workload W and contract deadlines, scenario reference R, + Test inputs + validator budgets, link profiles. + + Actual build/test commands, submission interfaces, metric names and assertion + Implementation adapters + hooks. Bind to source; do not invent endpoint names. + + Independence and Owners, reviewers, conflicts, resources, authorisations, evidence storage and + operations incident responsibilities. + + Approved P00-P16 version, required economic worlds, peers, exclusions, public + Claims and thresholds + claim envelope. + + + + APPROVAL RULE + + + A blank or contradictory field blocks dependent tests. This manual does not silently choose a new + consensus threshold, verifier security level, final dataset size or customer contract. + + + +The supplied plan remains the source of requirements. New measurements, sample sizes and commercial thresholds below +are this manual's proposed acceptance design. Their presence in a branded PDF does not make them approved or achieved. + + + + +Basis: 2.0 plan pp. 21, 23-25. This register and default thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 7 / 73 + TEST STANDARD / 1.0 + + + + +06 / SHARED FIXTURES + + + +Prepare the test environments. +Every case inherits the relevant fixture controls and the signed release manifest. No production secrets +are needed. + + + ID / FIXTURE REQUIRED CONTENT + + + Exact commits, binaries, genesis/network ID, mining class, dataset schedule, + F0 / Release and assurance + EVM fork/deviations, program/verifier IDs, fees, supply, quorum/fault rules, + manifest + trust anchors, activation and supported roles. + + Pinned toolchains, dependency locks, clean OS images and documented + F1 / Clean build environments + signing/notarisation boundaries. No production secrets or private founder files. + + F2 / Hardware and Approved physical GPU cohort, calibrated wall meters, stable thermal + measurement lab conditions, driver/OS images and realistic home/datacentre link conditions. + + F3 / Workload and oracle Fixed full-hash and EVM/proving jobs, independent reference implementations, + catalogue real customer-sized payloads, held-out seeds and complete expected results. + + Independent nodes/operators; controllable latency, loss, clocks, partitions, + F4 / Authorised fault network storage faults and role withdrawals. Actual consensus paths plus separately + labelled simulators. + + F5 / Negative and regression Malformed transactions/proofs, wrong roots/IDs, duplicate payments, bad + corpus authority tables, historical failures and deliberately faulty code mutants. + + Functionally checked architectures, RTL/physical estimates where feasible, + F6 / Specialist implementation + memory and board assumptions, cost inputs, adaptation paths and uncertainty + pack + ranges. + + F7 / Economic and incentive Independently reproducible costs, entry/exit/difficulty policies, scenario grid, + models operator opportunity costs and money-flow conservation fixtures. + + F8 / User/customer/peer Consenting unaffiliated users, contracted meaningful workloads, private + studies ownership checks, dated competitor methods and independent analysis. + + Immutable run IDs, raw logs, hashes, analysis code, exclusions, defects, + F9 / Evidence and status vault + reviewers, signatures, privacy controls and public redacted summaries. + + + + BUILD THE HARNESS AGAINST REAL CODE + + + The catalogue specifies procedures and assertions. Implement command/API adapters against the + actual repository in GOV-01. No endpoint, executable command or fabricated test output in this PDF + should be mistaken for a working harness. + + + + +Fixture design is proposed from the requirements in 2.0 plan pp. 5-26. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 8 / 73 + TEST STANDARD / 1.0 + + + + +07 / NUMERICAL PROFILES + + + +The proposed hardware bar. +P02-P04 are deliberate research targets. They are not reported achievements or universal ASIC bounds. + +P02 / Hardware coverage and reproducibility +At least 12 physical retail configurations: at least 3 NVIDIA, 3 AMD and 2 Apple configurations, at least two +discrete-GPU generations, an advertised 8 GB mining tier and 12 GB proving tiers where claimed. Record usable, not +nominal, memory. +Declare a competitive core of at least 6 configurations spanning every advertised vendor and at least two discrete +generations before optimisation. The wider cohort remains mandatory for access and economic tests; it cannot be +silently dropped. +Use 5 paired 30-minute steady-state runs per primary cell after at least 15 minutes of warm-up and a stable +temperature trend. Calibrated wall meter uncertainty must be at most 2%. Run a 7-day soak on representative +low/mid/high tiers. +Three unaffiliated operators participate; every competitive-core cell is reproduced by at least two. Identical-SKU +energy/accepted-work results must agree within 5% after declared environment corrections; unexplained variance +blocks the headline. + + +P03 / Candidate improvement and honest-card budget +For production candidate changes, per mandatory GPU cell: no more than 5% increase in joules per accepted work +and no more than 2% decrease in accepted throughput versus the paired tuned baseline. Absolute safety limits +always apply. +G2 requires at least a 10% reduction in the strongest evaluated specialist advantage after redesign, outside the +declared measurement/model uncertainty, while meeting those budgets. A failed experiment is not a successful +upgrade. +Existing clock-lock savings belong in the baseline. Long programs cannot pass by adding enough equally costly work +to both devices to improve a ratio while materially worsening honest operation. + + +P04 / Scoped specialist-competition target +Define R_E as GPU wall joules per accepted work divided by the lowest credible complete-system specialist joules +for that same work. The proposed target is R_E at most 1.5 for every competitive-core cell at the same node and one +node ahead. +Evaluate at least three materially distinct specialist architectures, with one programmable multi-family design, and a +second independent reviewer. Include shared/reduced memory, hybrid execution, selective participation and +realistic power/host costs. +Publish two-node-ahead and modular/reused-IP stress cases; they must satisfy the predeclared P12 economic +envelope. No universal ceiling for unknown future hardware is claimed. Report model bounds separately from +statistical confidence. +A lower-bound specialist estimate, not a convenient average or a deliberately constrained reference architecture, +drives the conservative comparison. Undefined or unbounded decision-critical assumptions make the result +BLOCKED. + + + + +Source requirements: 2.0 plan pp. 6-12 and 23. All limits below are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 9 / 73 + TEST STANDARD / 1.0 + + + + +08 / NUMERICAL PROFILES + + + +Correctness before confidence. +P01, P05 and P06 prevent favourable sampling, hidden uncertainty and unsupported hardware claims. + +P01 / Correctness and negative-test depth +Zero observed invalid acceptance, unauthorised signature, conflicting finality within assumptions, duplicated reward +or unexplained cross-backend state/hash disagreement. +Minimum proposed campaign: 1,000,000 full-hash vectors per supported backend across all families, plus at least +10,000 malformed/boundary cases per relevant parser or binding class. Include exhaustive small-domain cases and +historical regressions. +All prescribed critical mutants must be detected. This sampling target is not a bound on cryptographic failure +probability and does not replace independent reasoning about soundness or safety. + + +P05 / Measurement and inference protocol +Pre-register primary metrics, cohorts, holdout seeds, run order, exclusions and analysis before confirmation. Keep +tuning/training runs separate from holdout runs. +Use independent runs/operators as measurement units. Report point estimates, two-sided 95% measurement +intervals and absolute sample counts; handle time-series dependence with a declared block or run-level method. +Apply conservative uncertainty to pass decisions. A confidence interval around measured GPU energy does not +capture unknown ASIC architectures; model parameter ranges and expert judgement must be reported as such. +Never compare raw hashes per second across different algorithms. Do not transform a five-year scenario sweep into +a probability of chip arrival or a guarantee of future profitability. + + +P06 / Memory and support policy +All advertised role/configuration combinations must finish without OOM, corruption or unsafe fallback. Publish a +component memory budget, including display/OS, driver, miner, prover, aggregation and epoch construction. +Proposed support horizon: at least 24 months of known schedule compatibility for the advertised entry tier, unless a +narrower horizon is prominently approved before sale or launch. Removal changes the claim and must pass ECO-07. +Treat 5.5 / 8.5 / 11.5 GiB as source candidates, not imposed final rules. Simultaneous operation, eviction and +time-sharing are distinct advertised modes with separately measured cost. + + + + +Source requirements: 2.0 plan pp. 5-12 and 25. All new numeric limits are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 10 / 73 + TEST STANDARD / 1.0 + + + + +09 / NUMERICAL PROFILES + + + +Capacity, faults and +independence. +Keep the proof-delivery promise separate from finality, payment eligibility and periods when liveness +assumptions fail. + +P07 / Proof service capacity and fairness +Freeze W as a meaningful workload mix, input sizes, proof format, fleet and requests/hour. Primary proposed target: +72 hours at W, plus 24 hours at 1.2W; at least 99.5% accepted jobs delivered valid within the contracted deadline. +Default delivery targets for the declared internal reference workload: p95 at most 60 seconds and p99 at most 120 +seconds from input-ready assignment through verified delivery. Also publish request-to-delivery including input wait; +no claim may omit that delay. +Request-to-delivery p99 must meet the separately approved customer deadline. Payment p99 must be at most 10 +minutes after verified payable eligibility, with chain finality time reported separately. These defaults do not override a +stricter contract. +No statistically supported positive backlog drift at steady load, no silent drops; after 2W for 15 minutes, drain excess +backlog within 30 minutes of return to W. Report rejected demand and accepted-job success separately. +Proposed advertised-tier fairness: at least 90% timely valid assigned completions are paid under the approved rules; +avoidable duplicate/retry work is at most 10% of total work. Reassignment policy must bound abandonment without +promising every assignment a reward. + + +P08 / Fault assumptions and recovery +F0 must state the exact safety threshold, quorum and authority-transition rule; the synchrony/participation +assumptions for liveness; trusted inputs; and clock/expiry semantics. This manual supplies no substitute consensus +rule. +Exercise threshold-minus/at/plus cases, the 40/40/20 partition fixture, signing outages and 31/35/60/90 logical-day +expiry cases. Preserve safety when liveness assumptions fail; do not demand finality from an unavailable quorum. +After assumptions and input availability are restored: service replacement within 10 minutes and deterministic +network convergence within 30 minutes on the reference topology. Different certified bounds must be approved +beforehand. +Accelerated-time simulation and real elapsed operation are separate evidence classes. Recovery may not reverse a +guarantee previously represented as final. + + +P11 / No-founder exercise and independence +At least 10 verified unaffiliated operators, three independently administered network/hosting domains and sufficient +honest weight/capacity to satisfy F0 and W after founders are removed. +Run at least 30 real elapsed days without founder mining, proving, aggregation, bootstrap, required RPC, private files +or privileged interventions. Cross all known logical transitions separately without calling accelerated time real history. +Document control by role and common dependencies; uncertain identities are not counted as independent. +Within-assumption withdrawals must satisfy P08; losing more than the assumed quorum may cause a visible safe +pause. + + + + +Source requirements: 2.0 plan pp. 17-21 and 24-25. All new numeric limits are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 11 / 73 + TEST STANDARD / 1.0 + + + + +10 / NUMERICAL PROFILES + + + +Safe and practical operation. +A supported operator should not need privileged help, opaque software or unsafe tuning to participate. + +P09 / Security and bounded resource requirements +Zero unresolved critical or high-severity security findings on the claimed release. Independent scopes must cover +consensus, proof soundness/parameters, implementation bypasses, wallet/isolation and relevant operational +controls. +Review the intended proof-system security level and assumptions explicitly; do not infer a security-bit claim from +random rejection tests. Version every verifier, program and parameter set. +Freeze maximum valid/invalid verification time, memory, disk and admission rates for ordinary validator hardware. At +rated valid load plus the approved hostile load, no unbounded growth, invalid acceptance or unrecoverable process +failure. +For supported wallet fee-estimation cases, proposed absolute error at most 5% versus the specified charge when +inputs are unchanged; deterministic fee-cap handling and explicit uncertainty otherwise. Customer contracts remain +separately binding. + + +P10 / Ordinary-operator product targets +At least 30 unaffiliated first-time study participants across supported Windows/macOS combinations. At least 90% +install, configure safely and submit accepted work without staff help; p90 active setup at most 15 minutes. Publish +complete download/dataset time separately. +Pause/stop acknowledgement within 2 seconds, safe worker stop within 5 seconds where no documented atomic +operation prevents it, and reliable restoration of original tuning settings. No hidden custody or silent update. +Net-energy/fee displays reconcile within 5% under the declared measurement boundary. Incremental rejected-work +loss on the normal home-link profile is at most 2 percentage points over the matched datacentre profile. +Open miner efficiency is within 5% of the best independently tuned permitted implementation on identical work. For +the declared single-card payout case, p95 payable-to-payment at most 24 hours and total payout friction at most 2% +of earned value. +Critical alerts are emitted within 60 seconds of detectable evidence. At least 90% of study users can identify the +injected failure and follow the published safe action. No control target excuses a security failure. + + + REQUIRED SOFTWARE EVIDENCE + + + Manual and automated security review, correct negative-test oracles, secret-isolation tests and + reproducible release inputs are separate obligations. A large pass count does not replace them. + + + + +Source requirements: 2.0 plan pp. 14-16 and 20-26. All new numeric limits are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 12 / 73 + TEST STANDARD / 1.0 + + + + +11 / NUMERICAL PROFILES + + + +Test the world after chips arrive. +The economics must survive a funded programmable competitor. They must also disclose where +commodity participation fails. + +P12 / Five-year coexistence envelope +Freeze a sourced revenue reference R and mandatory worlds before results. Sweep 0.25R, R, 4R and 10R; electricity +at $0.03/$0.10/$0.25/$0.40 per kWh; 1/3/5-year productive life; zero/$20M/$75M development; private mining and +hardware sales; no/normal/spiking external demand. +Those values are proposed stress inputs, not current prices or forecasts. Declare which worlds have enough funded +demand for rational ongoing service before running; retain collapse worlds as explicit safety/exit tests, not profitable +successes. +Proposed matched-tariff new-entry target in every mandatory sustainable world: median GPU/specialist total cost +per accepted work at most 1.5, 90th percentile at most 1.75, and no advertised competitive-core cell above 2.0. +Publish every cell, including heterogeneous tariffs. +At least three purchasable GPU configurations across at least two advertised vendors must have positive modelled +new-entry economics; at least 75% of the entry cohort must have positive marginal operating economics in those +worlds. Report model uncertainty and failure regions. +Do not impose GPU market share, specialist production limits, token appreciation, full research-cost recovery or +automatic chip death to force the result. Any such condition must become an explicit limitation rather than a hidden +assumption. + + +P13 / Maintenance continuity +Before a readiness claim, document at least 12 months of committed maintenance resources at the approved +operating scope. Include engineering, security review, infrastructure, support and incident response. +Use independently reviewable commitments and downside budgets. Uncommitted future sales, rising token prices, +burned fees or assumed fundraising are not available resources. +This is a proposed governance test, not a directive to change the supply cap, issuance allocation or fair-launch +design. + + + WHAT THIS DOES NOT PROMISE + + + No hash guarantees profit at every tariff or with zero demand. The mandatory sustainable worlds and + collapse cases must be chosen before results. A failure cannot be moved outside scope afterwards to + rescue the headline. + + + + +Source requirements: 2.0 plan pp. 8, 13, 18 and 24-26. Stress inputs and limits are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 13 / 73 + TEST STANDARD / 1.0 + + + + +12 / NUMERICAL PROFILES + + + +The bar beyond engineering. +Passing a private technical test set alone is insufficient for the leadership-contender assessment. + +P14 / Genuine commercial and developer proof +At least three unrelated paying buyer organisations, each making at least three separate purchase decisions across at +least 30 days; at least 1,000 meaningful verified external jobs in aggregate. Split invoices do not create independent +demand. +No project reimbursement, circular funding or undisclosed related party counts. Report customer concentration and +churn; proposed maximum largest-buyer share is 70% of qualifying revenue. +At least 20% aggregate contribution margin after directly attributable delivery costs, retries, refunds and support; +publish fully loaded economics separately. At least 75% of sampled eligible operators have positive realised +contribution on the declared workload. +At least five unaffiliated developers complete a useful supported application or proof-service integration using public +documentation. Customer confirmation and raw commercial evidence may remain confidential to the reviewer. + + +P15 / Comparative contention threshold +Pre-register at least three relevant operating GPU-first peers, plus a real proving alternative for customer +comparisons. Verify current versions at execution time. The source reference set is a starting point, not a claim about +current rankings. +Require at least three meaningful comparable dimensions with no material inferiority beyond a pre-agreed 10% +margin against the best valid comparator, and at least two independently evidenced advantages against at least two +peers. +Advantages must be either a greater-than-10% measured improvement outside uncertainty or a directly tested +control/capability difference with demonstrated user value. Non-comparable or missing data is not a win. +A panel with hardware/economics, security/operations and customer/operator expertise must support the scoped +contender conclusion. Passing these judgement-based thresholds does not certify a universal number-one ranking. + + +P16 / Observed durability and claim freshness +At least 90 real elapsed days on the final compatible release family, at least 30 independently verified operators, and +transparent eligibility/churn denominators. Material uncomparable changes reset affected observations. +Proposed outcomes: at least 60% day-90 operator retention and at least 75% of eligible observed operators with +positive measured marginal operation over the period. Report incentives and electricity assumptions; do not claim a +downturn was observed if it was not. +At least 99.9% availability for the declared customer service during eligible operating conditions, with all-in +availability also reported; zero accepted invalid proofs or conflicting finality within F0 assumptions. Do not remove +real incidents as maintenance to force a pass. +Run fault injection on isolated infrastructure, not unsuspecting customers. Publish planned test windows separately. +Reassess claims at least quarterly and immediately after material hardware, protocol, economics or security +changes. + + + + +Source requirements: 2.0 plan pp. 4, 17, 24-27 and 31-33. New thresholds are proposed judgements. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 14 / 73 + TEST STANDARD / 1.0 + + + + +13 / EXECUTION SEQUENCE + + + +Run in the right order. +Observation periods are minimum test durations, not delivery promises. Staffing and budgets still need +approval. + + + PHASE DO THE WORK EXIT + + + GOV and all + Approve F0/P00-P16; build adapters, clean images, + A / Freeze preconditions + independent oracles and mutation controls. + accepted. + + No blocking safety + Close proof enforcement, authenticated authority, + B / Safety first failure; safe to run + replay/payout correctness and wallet isolation. + broader trials. + + G1-G4 with scoped + Reproduce v6; evaluate coupling and memory attacks; uncertainty and + C / Hardware research + independent programmable design and economics. rejected designs + retained. + + D / Integrated Run sustained W, overload, concurrency, actual node Technical readiness + operation partitions and no-founder exercise. and G5. + + COM and P16 evidence; + Run consenting user/developer studies, genuine paid jobs and + E / Field evidence no simulated customer + 90-day operation/retention. + demand. + + Dated contender + assessment or a + F / Compare and Complete current peer/customer comparisons and + documented + decide independent gate review. + failed/blocked + decision. + + +Cadence by risk +Every code change runs affected deterministic and negative regressions. Nightly campaigns extend fuzzing +and soak coverage. Every release candidate reruns relevant integration and hardware cases. Protocol, +verifier, fee or dataset changes invalidate all dependent model and field evidence. Commercial/peer claims +refresh at least quarterly. + +Real time cannot be compressed away +The 30-day independent exercise can be a properly scoped part of the 90-day field period. Long-expiry +simulations remain separate. Hardware design/review and customer acquisition may take longer than any +test run; this manual makes no staffing or elapsed-delivery guarantee. + + + + +Basis: 2.0 plan pp. 23-26. Sequencing is this manual's proposed implementation approach. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 15 / 73 + TEST STANDARD / 1.0 + + + + +14 / MEASUREMENT CONTROLS + + + +Make the evidence difficult to +game. +Apply P05 globally, not only to hardware charts. Every exclusion and missing result remains visible. + +Define the denominator +Accepted-work energy = complete measured energy divided by accepted work. Delivery success = correct, +on-time jobs divided by all accepted jobs. Publish admission rejection separately. Retention uses the original +eligible cohort, including departures. Revenue excludes refunds, reimbursements and circular funding. + +Separate four kinds of evidence + + CLASS CAN SUPPORT CANNOT SUBSTITUTE FOR + + + Actual device, job or operating result with Unknown architectures or years not + Measured + uncertainty. observed. + + A result conditional on explicit cost, Manufactured-silicon performance or + Modelled + hardware and behaviour assumptions. observed profits. + + A property under a stated model and Correct implementation and complete + Formally analysed + bounded or proven assumptions. environmental assumptions. + + Independently A scoped qualified assessment and A guarantee that no future flaw or + reviewed reproduced evidence. competitor exists. + + +Use adversarial controls +Publish positive controls, historical failures, deliberate mutants and holdout seeds. Compare different +algorithms only through meaningful common tasks or normalised overhead. Do not award a win when peer +data is absent or incomparable. + + GENERAL PASS RULE + + + PASS requires the pre-registered condition, full raw evidence, no unresolved contradictory result and + the assigned review. Missing data, borderline uncertainty or a changed workload means BLOCKED, + INCONCLUSIVE or FAIL. It is not rounded into success. + + + + +Basis: 2.0 plan pp. 5, 8, 12, 17, 23-25. Experimental methods are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 16 / 73 + TEST STANDARD / 1.0 + + + + +15 / TEST EXECUTION MAP + + + +The 16-suite catalogue. +Every test starts NOT RUN. BLOCKER and GATE identify the consequence of failure, not a waiver option. + + + SUITE ACCOUNTABLE LEAD CASES + + + GOV / Release identity and evidence Release lead + independent assurance 8 + + GPU / Whole-system GPU measurements GPU lead + three independent operators 8 + + POW / Proof-of-work correctness and coupling Cryptography + GPU lead 8 + + ADV / Programmable specialist adversaries Independent hardware team 8 + + ROT / Epochs, seeds and memory transitions Consensus + GPU leads 8 + + ECO / Five-year coexistence economics Economics lead + independent reviewer 8 + + EVM / Execution and developer compatibility Execution lead + independent implementer 8 + + Proving + protocol leads; independent + ZKP / Consensus-enforced proof validity 8 + cryptography review + + CAP / Sustained proving and delivery Proving lead + independent operators 8 + + INC / Rewards, incentives and selfish operators Protocol economics + proving leads 8 + + Consensus lead + independent formal/security + FIN / Consensus safety and recovery 8 + review + + Wallet + light-client lead; independent security + VER / Wallets, receipts and data availability 8 + review + + Operations + release leads; independent + OPS / Independent operation and release security 8 + operators + + Desktop product + pool leads; independent + UX / Ember, payouts and operator control 8 + usability study + + Commercial lead + independent + COM / Paid demand and sustainable delivery 8 + financial/customer reviewer + + Independent assessment panel + + LEAD / Comparative leadership evidence 8 + product/economics reviewers + + +Inherited preconditions: approved F0/P-profile versions, controlled test keys/data, positive and negative controls, +calibrated collection and the stated independent reviewer. Retest: every release candidate and any relevant source, +parameter, hardware, economic or scope change. + + + + +Source requirements: 2.0 plan pp. 3-27. Full traceability is on the source map and each suite page. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 17 / 73 + TEST STANDARD / 1.0 + + + + +GOV / GOV-01 TO GOV-03 + + + +Release identity and evidence +Prevent a favourable result from being attached to the wrong code, assumptions or public claim. + +Lead: Release lead + independent assurance +Fixtures: F0 manifest; F1 source/build archives; F9 evidence vault +GOV-01 BLOCKER / P00 / NOT RUN + + +Freeze the release and its claims +Setup. Candidate source, binaries, public documentation and the 2.0 plan are available; no run is yet +accepted. +1. Record exact commits, binary hashes, dependencies, genesis/network identity, mining class, datasets, +execution fork, verifier IDs and fee rules in F0. 2. Map every promised capability and plan requirement to a +test ID; distinguish supported mining, proving and wallet combinations. 3. Sign the manifest with protocol, +product and independent review owners before confirmatory runs. +Pass. Every material rule and claim has an unambiguous version and test. Conflicts or unknown activation +rules produce BLOCKED, not an inferred default. Changes create a new manifest and invalidate affected +results. +Evidence. Signed F0; source-to-test map; claim inventory; unresolved-field register. + +GOV-02 BLOCKER / P00 / NOT RUN + +Approve thresholds before results +Setup. This manual supplies proposed test thresholds, not source-approved protocol parameters. +1. Approve or replace every P-profile before confirmatory testing; give each change a rationale and +independent approver. 2. Register hardware cohorts, mandatory economic worlds, customer workloads, +peer dimensions and exclusion rules. 3. Lock the profile hash and hold out seeds/workloads from the +developers doing optimisation. +Pass. No decision-critical field is TBD. Numeric limits are frozen, commercially meaningful and not chosen +from observed results. A weakened limit after failure requires a new protocol, full affected rerun and explicit +claim downgrade review. +Evidence. Approved profile register; timestamped holdout commitments; change log. + +GOV-03 BLOCKER / P00; P02 / NOT RUN + +Reproduce builds outside the founding team +Setup. Provide public source and documented build instructions to three unaffiliated operators. +1. Build on clean declared environments without private files, tokens or founder assistance. 2. Compare +reproducible payload hashes; isolate signatures, notarisation and permitted non-deterministic wrappers. 3. +Run reference vectors and restart a node using only documented artifacts. +Pass. All independent builds reproduce the same consensus payload or an independently explained, +pre-approved wrapper difference; reference outputs match exactly. Missing private prerequisites block +release. +Evidence. Build logs; dependency lockfiles; binary comparison; operator attestations. + + + + +Source: 2.0 plan pp. 5, 21, 23, 25, 26, 27. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 18 / 73 + TEST STANDARD / 1.0 + + + + +GOV / GOV-04 TO GOV-06 + + + +Release identity and evidence +Prevent a favourable result from being attached to the wrong code, assumptions or public claim. + +Lead: Release lead + independent assurance +Fixtures: F0 manifest; F1 source/build archives; F9 evidence vault +GOV-04 BLOCKER / P00 / NOT RUN + + +Preserve raw and negative evidence +Setup. Enable append-only storage for run outputs and a separate analysis workspace. +1. Capture failed, aborted and successful runs with timestamps, seeds and environment hashes. 2. +Recompute one published figure from raw records on a clean machine. 3. Modify a retained artifact +deliberately and test integrity verification. +Pass. Every headline can be regenerated; tampering is detected; exclusions have pre-registered reasons. +Failed or missing runs remain visible and are never replaced silently by a successful retry. +Evidence. Artifact manifest; hashes; reproduction script; exclusion ledger; negative-run archive. + +GOV-05 BLOCKER / P01 / NOT RUN + +Prove the test oracle detects broken behaviour +Setup. Create controlled defective variants on an isolated network only. +1. Disable proof verification, change one reward, accept an expired authority set and alter one hash output +in separate mutants. 2. Run the corresponding ZKP, INC, FIN and POW tests without telling the runner which +mutant is active. 3. Confirm the baseline still accepts authorised valid cases. +Pass. Every deliberately introduced fault is caught by its mapped test; valid controls pass. Any undetected +critical mutant blocks acceptance of that test family until the oracle is repaired. +Evidence. Mutation catalogue; blinded run results; baseline controls; oracle review. + +GOV-06 BLOCKER / P00 / NOT RUN + + +Enforce scope and optional-feature discipline +Setup. Inventory FP32 experiments, receipts/oracles and all retained or excluded mining levers. +1. Mark each capability CORE, CLAIMED-OPTIONAL or EXCLUDED before release testing. 2. For excluded +code, check binaries, protocol activation and product copy for accidental enablement or implied availability. +3. For each claimed option, require the complete associated test set rather than a demonstration. +Pass. Every core and claimed-option obligation passes. Excluded items are shown as EXCLUDED, never +PASS and never counted as achievements. Removing a failed core requirement prevents an all-2.0-pass +claim. +Evidence. Scope manifest; activation scan; product-copy comparison; exclusions register. + + + + +Source: 2.0 plan pp. 5, 21, 23, 25, 26, 27. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 19 / 73 + TEST STANDARD / 1.0 + + + + +GOV / GOV-07 TO GOV-08 + + + +Release identity and evidence +Prevent a favourable result from being attached to the wrong code, assumptions or public claim. + +Lead: Release lead + independent assurance +Fixtures: F0 manifest; F1 source/build archives; F9 evidence vault +GOV-07 BLOCKER / P09 / NOT RUN + + +Independent review and finding closure +Setup. Nominate reviewers with declared conflicts and scopes covering cryptography, consensus and +hardware. +1. Provide pinned code, raw data, adversarial models and prior failures, including negative results. 2. Track +each finding to remediation and an independent retest; do not use the author as sole approver. 3. Have +reviewers state unreviewed surfaces and model limitations in their signed conclusions. +Pass. No unresolved critical or high-severity finding affects the claimed release. A finite review is described +by scope, not as proof of universal security. Independent reproduction and review are both evidenced. +Evidence. Signed scoped reports; conflict declarations; finding/retest ledger. + +GOV-08 BLOCKER / P00 / NOT RUN + +Invalidate stale evidence and control public status +Setup. Create a simulated post-test change to a verifier, mining class, dataset and fee rule. +1. Calculate affected test dependencies and invalidate their former PASS statuses. 2. Regenerate public +status pages from F0 and the evidence register. 3. Attempt to publish a rank-one, guaranteed-profit or +automatic-chip-death claim without the required evidence. +Pass. Affected gates return to NOT RUN or BLOCKED. Public claims retain version, limits and date; +unsupported claims are withheld. No stale result remains attached to a different release. +Evidence. Dependency impact report; regenerated status page; rejected claim examples. + + + + SUITE CLOSE / GOV + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 5, 21, 23, 25, 26, 27. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 20 / 73 + TEST STANDARD / 1.0 + + + + +GPU / GPU-01 TO GPU-03 + + + +Whole-system GPU measurements +Close the pending measurements and evaluate the actual configuration, including costs hidden by +kernel-only results. + +Lead: GPU lead + three independent operators +Fixtures: F2 retail-hardware cohort; F3 paired benchmark workloads; F9 calibrated evidence +GPU-01 GATE / P02 / NOT RUN + + +Cover the declared commodity population +Setup. Freeze the P02 cohort, supported role matrix and the final v6 configuration. +1. Inventory physical SKU, usable memory, driver, operating system, firmware, cooling and acquisition +channel. 2. Run mining on every supported cohort cell and proving on every separately advertised prover +cell. 3. Include lower-memory, used-generation and all advertised vendor cases; retain unsupported results +separately. +Pass. All declared cells are tested, with no after-the-fact removal of weak cards. At least the P02 minimum +coverage is met. Mining-only support is never reported as proof-generation support. +Evidence. Cohort manifest; compatibility matrix; raw results by SKU and role. + +GPU-02 GATE / P02; P03 / NOT RUN + +Reproduce Ember clock-lock savings +Setup. Use paired stock and tuned runs on the same board, host, workload and ambient conditions. +1. Warm to stability; randomise stock/tuned order and run P02 repeated sessions. 2. Measure accepted +work, calibrated wall energy, device telemetry and rejected work. 3. Calculate paired energy and rate +changes with run-level uncertainty, retaining failed tuning attempts. +Pass. Tuning preserves correctness and meets approved P03 operating limits. The historical 34-41% saving +and under-2% rate-loss statement is reproduced only for qualifying configurations; otherwise that claim is +corrected. Existing savings are not counted twice. +Evidence. Raw power/time series; paired analysis; tuning settings; claim-by-SKU table. + +GPU-03 GATE / P02; P03 / NOT RUN + +Measure the real 64-register GPU cost +Setup. Build the baseline and window variant with identical dataset, reads and semantic workload. +1. Inspect compiled register allocation, spills, occupancy and memory traffic on each supported backend. 2. +Measure paired complete-system energy and accepted throughput, including host work. 3. Repeat during +proving coexistence and expose any memory or scheduling cliff. +Pass. Any production window meets P03 budgets for every mandatory SKU; no hidden spills or correctness +changes. Zero GPU cost is claimed only where measurement supports it within uncertainty. Results feed the +redesigned adversary, not an old core estimate. +Evidence. Compiler reports; allocation traces; paired energy/rate data; coexistence runs. + + + + +Source: 2.0 plan pp. 6, 7, 8, 14, 18, 23. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 21 / 73 + TEST STANDARD / 1.0 + + + + +GPU / GPU-04 TO GPU-06 + + + +Whole-system GPU measurements +Close the pending measurements and evaluate the actual configuration, including costs hidden by +kernel-only results. + +Lead: GPU lead + three independent operators +Fixtures: F2 retail-hardware cohort; F3 paired benchmark workloads; F9 calibrated evidence +GPU-04 BLOCKER / P01; P02 / NOT RUN + + +Find the memory-clock operating ladder +Setup. Use safe vendor-supported settings only; record operator permission and original settings. +1. Sweep approved core and memory operating points while holding workload constant. 2. Measure error +rate, accepted throughput, wall energy and thermal equilibrium. 3. Repeat the selected knee after reboot +and restore defaults after a failed or interrupted tuning session. +Pass. Selected profiles are stable, reproducible and not dependent on unsafe clocks. Every accepted hash +remains correct; saved settings restore predictably. Tuning failure leaves a working safe configuration. +Evidence. Clock ladder; safe bounds; thermal/error logs; reboot and rollback record. + +GPU-05 BLOCKER / P01; P02; P06 / NOT RUN + +Test dataset fit and support-horizon costs +Setup. Test 5.5, 8.5 and 11.5 GiB only as source-proposed candidates; F0 determines activated sizes. +1. Measure allocation plus driver, display, prover and OS headroom on the 8 GB and other cohort tiers. 2. +Run near-full-memory, fragmentation, restart and next-epoch construction scenarios. 3. Compare +time-sharing/eviction with concurrent mining/proving, including reload cost. +Pass. Every advertised combination completes without OOM or silent corruption. Unsupported future sizes +are identified before activation. GPU exclusions and lost proving capacity appear in ECO evaluation; +retirement of a tier is not a success metric. +Evidence. Memory budget per SKU; OOM traces; support horizon; concurrency cost table. + +GPU-06 GATE / P02; P10 / NOT RUN + +Measure accepted work under ordinary connectivity +Setup. Use the same hardware against clean, delayed, lossy and intermittent links in F4. +1. Measure kernel rate and accepted work separately under home and datacentre link profiles. 2. Include +reconnects, template changes, expired submissions and pool failover. 3. Attribute loss to network, local +software, validation and protocol causes. +Pass. Results use accepted work, never kernel rate alone. Ordinary-link incremental rejection stays within +P10; all losses remain priced in ECO. Unreachable links may pause but must not claim paid work. +Evidence. Per-submission ledger; network trace; rejection reasons; accepted-work comparison. + + + + +Source: 2.0 plan pp. 6, 7, 8, 14, 18, 23. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 22 / 73 + TEST STANDARD / 1.0 + + + + +GPU / GPU-07 TO GPU-08 + + + +Whole-system GPU measurements +Close the pending measurements and evaluate the actual configuration, including costs hidden by +kernel-only results. + +Lead: GPU lead + three independent operators +Fixtures: F2 retail-hardware cohort; F3 paired benchmark workloads; F9 calibrated evidence +GPU-07 BLOCKER / P01; P02; P10 / NOT RUN + + +Survive sustained thermal and power operation +Setup. Run the selected profile on actual reference machines for the P02 soak period. +1. Track wall power, temperatures, clocks, memory and accepted work continuously. 2. Inject safe power +interruptions, process restarts and normal competing desktop load. 3. Check restored settings and compare +late-run efficiency with the first stable period. +Pass. No invalid work or unsafe persistent settings; P02/P10 stability limits hold. Thermal throttling, +crashes and recovery time remain in throughput and energy denominators. A crash-free short benchmark +cannot substitute for the soak. +Evidence. Seven-day time series; crash reports; settings-restoration checks; drift analysis. + +GPU-08 GATE / P02 / NOT RUN + +Reproduce the full baseline independently +Setup. Three unaffiliated operators receive F0, F2 and F3, including the final miner/prover build. +1. Repeat identical-SKU paired runs with documented meter calibration and environment differences. 2. +Recompute joules and total cost per accepted work from the shared raw schema. 3. Investigate divergence +before accepting a pooled headline or uncertainty band. +Pass. Reproductions meet P02 tolerance and exact correctness. No unexplained divergence or selectively +missing low-end cell remains. Report manufactured GPU measurements separately from modelled +specialist estimates. +Evidence. Three signed reproduction packs; reconciliation report; final baseline table. + + + + SUITE CLOSE / GPU + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 6, 7, 8, 14, 18, 23. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 23 / 73 + TEST STANDARD / 1.0 + + + + +POW / POW-01 TO POW-03 + + + +Proof-of-work correctness and +coupling +Find semantic disagreements and structural shortcuts before treating a harder-looking program as a +stronger defence. + +Lead: Cryptography + GPU lead +Fixtures: F0 rule set; F3 independent CPU/GPU oracles; F5 mutation corpus +POW-01 BLOCKER / P01 / NOT RUN + + +Match independent execution across every backend +Setup. Implement an independently written reference evaluator, not a wrapper around the production GPU +path. +1. Execute the P01 corpus across every family, boundary seed and supported backend. 2. Exercise zero, +maximum, sign, shift, rotate, overflow and unaligned-address cases allowed by the spec. 3. Minimise every +mismatch and rerun it on clean builds. +Pass. Bit-for-bit agreement for all valid cases and identical rejection for invalid cases. One unexplained +mismatch is a blocker. Large sample counts are evidence of testing, not proof that unseen disagreements +cannot exist. +Evidence. Reference implementation review; seeds/vectors; backend matrix; mismatch archive. + +POW-02 BLOCKER / P01 / NOT RUN + +Validate generated programs and index folding +Setup. Use the frozen grammar, opcode semantics and index-fold rule; include boundary and malformed +programs. +1. Enumerate small constrained programs and fuzz the full generator at P01 depth. 2. Check bounds, valid +dependencies, address distribution and forbidden encodings. 3. Compare source-level operations with +optimised compiled code for removed or altered work. +Pass. No accepted program violates semantics, termination or memory bounds. Distribution claims have +predeclared tests and effect-size limits; passing randomness checks is not treated as a cryptographic proof. +Evidence. Generator/fuzzer logs; reduced counterexamples; disassembly comparison; index tests. + +POW-03 GATE / P03; P04 / NOT RUN + +Test whether live state is unavoidable +Setup. Take the 64-register candidate and the cheapest independently proposed storage organisations. +1. Trace value liveness across dependent reads and final output, distinguishing distinct information from +duplicated values. 2. Try banking, compression, recomputation, fewer ports and time-multiplexed contexts. +3. Quantify the best complete-system cost/throughput trade-off rather than the reference register count. +Pass. Production selection is supported by measured or physically modelled penalties after these +alternatives. G2 requires the P03 improvement; an attractive source-level register count alone does not +pass. +Evidence. Liveness traces; alternative implementations; Pareto table; reviewer analysis. + + + + +Source: 2.0 plan pp. 7, 9, 10, 23. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 24 / 73 + TEST STANDARD / 1.0 + + + + +POW / POW-04 TO POW-06 + + + +Proof-of-work correctness and +coupling +Find semantic disagreements and structural shortcuts before treating a harder-looking program as a +stronger defence. + +Lead: Cryptography + GPU lead +Fixtures: F0 rule set; F3 independent CPU/GPU oracles; F5 mutation corpus +POW-04 GATE / P03; P04 / NOT RUN + + +Evaluate connected-resource restructuring +Setup. Use a candidate initially matched to baseline instruction count, read count and dataset size. +1. Connect state, addresses, arithmetic and lane communication according to the written hypothesis. 2. +Measure GPU cost and allow the specialist reviewer to redesign the entire core. 3. Repeat on held-out +program seeds and compare the worst supported adversary, not only the original design. +Pass. The selected upgrade meets P03 and improves the adversarial result outside declared uncertainty. A +negative experiment remains a negative outcome; adopting a different design requires a new frozen +comparison. +Evidence. Matched workloads; GPU runs; redesigned core estimates; held-out results. + +POW-05 BLOCKER / P01; P04 / NOT RUN + +Prevent amortised cheap winning attempts +Setup. Prepare valid templates, nonces, intermediate-state captures and independent acceptance checks. +1. Vary nonce, payout identity, transactions, roots and other committed fields after expensive work. 2. Try +replay, precomputation, shared prefixes, partial evaluation and many cheap suffix candidates. 3. Price any +valid strategy against fresh evaluation; independently review all bindings. +Pass. Invalid modifications are rejected. Any valid cost-saving strategy is incorporated into ADV and must +still meet P04/ECO gates. No unresolved shortcut is hidden behind passing reference vectors. +Evidence. Attack implementations; valid/invalid controls; work-cost analysis; binding review. + +POW-06 BLOCKER / P01; P09 / NOT RUN + +Bound verifier work and malformed-input cost +Setup. Use ordinary CPU validators with a manifest-defined resource budget and untrusted submissions. +1. Submit shortest/longest programs, malformed encodings and adversarial memory references. 2. Measure +verification time, peak memory and work amplification across valid and invalid inputs. 3. Sustain the +approved hostile request rate while ordinary valid traffic continues. +Pass. All semantics remain correct and P09 resource budgets hold. Invalid traffic cannot cause unbounded +allocation, crashes or disproportionate free work. Rate limits must not replace consensus validation. +Evidence. CPU profiles; adversarial corpus; allocation traces; valid-traffic latency. + + + + +Source: 2.0 plan pp. 7, 9, 10, 23. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 25 / 73 + TEST STANDARD / 1.0 + + + + +POW / POW-07 TO POW-08 + + + +Proof-of-work correctness and +coupling +Find semantic disagreements and structural shortcuts before treating a harder-looking program as a +stronger defence. + +Lead: Cryptography + GPU lead +Fixtures: F0 rule set; F3 independent CPU/GPU oracles; F5 mutation corpus +POW-07 BLOCKER / P00; P01; P03 / NOT RUN + + +Constrain any mixed-resource or FP32 branch +Setup. If this branch is excluded, verify that it is unreachable and not claimed; if included, use a separate +frozen candidate. +1. Specify exact rounding, fusion, special values and backend behaviour before compiling. 2. Differentially +test all supported architectures and allow numerical-domain simplification in the specialist model. 3. +Include verifier cost and candidate energy in P03/P04, not just arithmetic-unit area. +Pass. Included branches achieve exact agreed semantics and all hardware budgets. An excluded branch +earns no performance credit. No approximate operation or unspecified compiler choice enters consensus. +Evidence. Scope decision; semantic specification; vectors; simplified datapath model. + +POW-08 GATE / P00; P03 / NOT RUN + +Keep rejected mechanisms out of the shipped claim +Setup. Inventory long programs, select trees, SM gating, wider reads, sealed classes, random epoch +lengths, per-tier scoring and VRF draws. +1. Retain their historic negative tests and realistic SRAM instruction-memory control. 2. Inspect the release +for reintroduction through renamed settings or hidden paths. 3. Require a new written hypothesis and +complete adversarial retest for any proposed return. +Pass. Excluded levers remain excluded unless separately approved and retested. Flip-flop +instruction-memory area is never presented as the cost of a realistic SRAM implementation. +Evidence. Decision register; binary/config scan; negative-control results. + + + + SUITE CLOSE / POW + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 7, 9, 10, 23. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 26 / 73 + TEST STANDARD / 1.0 + + + + +ADV / ADV-01 TO ADV-03 + + + +Programmable specialist +adversaries +Give the opponent permission to adapt, share resources and remain operational; test cost rather than +imagined chip death. + +Lead: Independent hardware team +Fixtures: F2 reference GPUs; F6 RTL/physical models; all published families +ADV-01 GATE / P01; P04 / NOT RUN + + +Build a multi-family programmable opponent +Setup. Provide the complete published family bank and future known parameter schedule to the reviewer. +1. Design one programmable architecture that supports all retained families, including firmware and +emulation paths. 2. Optimise clocks, lanes, ports and pipelines without requiring a graphics-card layout. 3. +Verify its outputs against POW vectors before measuring any advantage. +Pass. At least the P04 design diversity is evaluated; every estimated competitive design is functionally +validated. Inability of one narrow design to adapt is not evidence that all chips expire. +Evidence. Architecture reports; functional simulations; adaptation matrix; reviewer signature. + +ADV-02 GATE / P04 / NOT RUN + +Price shared, reduced and reconstructed memory +Setup. Allow multiple engines to share a dataset and to store selected fractions rather than a complete +per-engine copy. +1. Sweep sharing factors, memory fractions, caches and recomputation depth across many simultaneous +hashes. 2. Include construction/update amortisation, bandwidth contention and retained state. 3. Take the +most favourable feasible point for the specialist into the complete-board model. +Pass. No omitted feasible trade-off materially lowers the accepted cost estimate. Any winning alternative is +included in P04 and ECO; capacity alone is not accepted as an energy bound. +Evidence. Sweep definitions; energy/bandwidth data; best-feasible envelope; excluded-design reasons. + +ADV-03 GATE / P04 / NOT RUN + +Attack with data-local and hybrid execution +Setup. Permit distributed memories, state migration and companion CPU/GPU/FPGA components. +1. Compare moving computation, intermediate state or fetched data to each read location. 2. Test +specialised mining alongside outsourced proof generation rather than assuming one physical GPU does +both. 3. Include interconnect, host, synchronisation, idle and conversion costs. +Pass. The cheapest feasible combined system is included in the adversarial envelope and economic model. +A worker identity or account is never treated as proof of a single physical device. +Evidence. Hybrid architecture diagrams; traffic traces; system cost and energy ledger. + + + + +Source: 2.0 plan pp. 8, 10, 12, 22, 23. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 27 / 73 + TEST STANDARD / 1.0 + + + + +ADV / ADV-04 TO ADV-06 + + + +Programmable specialist +adversaries +Give the opponent permission to adapt, share resources and remain operational; test cost rather than +imagined chip death. + +Lead: Independent hardware team +Fixtures: F2 reference GPUs; F6 RTL/physical models; all published families +ADV-04 GATE / P04; P12 / NOT RUN + + +Measure profitable selective participation +Setup. Use all declared families plus held-out generated programs and the protocol difficulty rule. +1. Identify favourable execution paths and add cheap fallbacks for other periods. 2. Simulate entry/exit +around profitable periods, including idle time, compilation and re-entry costs. 3. Evaluate revenue and costs +across the full schedule, not just average program energy. +Pass. Intermittent specialists meet P04/ECO limits when evaluated on full-period economics. A weak tail +cannot be concealed by a favourable mean; known valid shortcuts must be priced. +Evidence. Per-program advantage distribution; policy simulator; full-period returns. + +ADV-05 GATE / P04 / NOT RUN + +Validate physical and complete-board costs +Setup. Use feasible process/library assumptions and documented component boundaries; no fabricated +foundry access. +1. Model SRAM macros, ports, wiring, clocking, memory PHYs, external memory, host and power +conversion. 2. Run place-and-route where available; mark unmodelled items as uncertainty rather than +zero. 3. Compare against a calibrated existing hardware block or equivalent validation case. +Pass. No decision-critical cost is omitted. Physically unvalidated or proprietary estimates are labelled and +independently bounded; synthesis alone cannot earn a manufactured-chip claim. +Evidence. Netlist/physical reports; macro assumptions; bill of materials; model calibration. + +ADV-06 GATE / P04; P12 / NOT RUN + +Separate process advantage from specialisation +Setup. Evaluate same-node, one-node-ahead and two-node-ahead scenarios with explicit technology +definitions. +1. Use independently justified process factors, voltages, memory and packaging assumptions for each +design. 2. Allow reusable IP and modular revisions; credit GPU improvement consistently. 3. Evaluate +measurement confidence and model-parameter sensitivity separately. +Pass. P04 primary limits hold for all competitive-reference cells; two-node futures are reported and pass +the predeclared economic stress envelope. A model range is never labelled a statistical confidence interval +without justification. +Evidence. Node-specific reports; factor provenance; uncertainty and sensitivity tables. + + + + +Source: 2.0 plan pp. 8, 10, 12, 22, 23. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 28 / 73 + TEST STANDARD / 1.0 + + + + +ADV / ADV-07 TO ADV-08 + + + +Programmable specialist +adversaries +Give the opponent permission to adapt, share resources and remain operational; test cost rather than +imagined chip death. + +Lead: Independent hardware team +Fixtures: F2 reference GPUs; F6 RTL/physical models; all published families +ADV-07 GATE / P04; P12 / NOT RUN + + +Evaluate lifetime without forced obsolescence +Setup. Assume multi-year productive survival and known schedule support before testing optional +retirement penalties. +1. Price firmware, emulation, memory expansion, companion hardware and incremental redesign. 2. Include +1-, 3- and 5-year productive lifetimes plus idle/resale possibilities. 3. Grant a retirement credit only if all +feasible cheaper adaptations lose competitiveness. +Pass. The primary case does not require chip death or a fresh full development bill per family. Every +retirement credit has a documented adaptation comparison; incompatible and unprofitable are reported +separately. +Evidence. Lifetime/adaptation ledger; revision costs; feasible-alternative analysis. + +ADV-08 GATE / P04 / NOT RUN + +Independently challenge the best-cost envelope +Setup. Publish the non-sensitive model and negative results; commission an unaffiliated second hardware +reviewer. +1. Reward cheaper valid designs and reproduced shortcuts, not confirmation of the preferred number. 2. +Re-run P04 with the strongest submitted feasible design, including a low-cost funded-development case. 3. +Record unresolved modelling disagreements and future technology exclusions. +Pass. Both reviews accept the scoped envelope or all material disagreements are resolved transparently. +Passing supports only evaluated designs and conditions, never a universal bound on all future silicon. +Evidence. Two review reports; challenge log; final envelope; unresolved-limit statement. + + + + SUITE CLOSE / ADV + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 8, 10, 12, 22, 23. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 29 / 73 + TEST STANDARD / 1.0 + + + + +ROT / ROT-01 TO ROT-03 + + + +Epochs, seeds and memory +transitions +Transitions must agree across nodes and remain usable during failures; crossing a boundary is not a +chip-retirement test. + +Lead: Consensus + GPU leads +Fixtures: F0 activation rules; F4 fault network; F5 historical and boundary vectors +ROT-01 BLOCKER / P01; P08 / NOT RUN + + +Agree across every hourly boundary +Setup. Use real nodes, CPU/GPU miners and independent clocks around successive program boundaries. +1. Submit valid work immediately before, at and after the activation boundary under clock skew and delayed +delivery. 2. Restart nodes from both sides and replay the same headers. 3. Compare selected seed, +program, validity, rewards and local wall-clock dependence. +Pass. All honest nodes derive identical consensus outcomes from the frozen rule. Late work is handled +exactly as specified; no wall-clock ambiguity or cross-backend split occurs. +Evidence. Boundary vectors; node/miner traces; acceptance and reward matrix. + +ROT-02 BLOCKER / P01; P03; P08 / NOT RUN + +Cross weekly and family boundaries together +Setup. Use the retained schedule in F0, including coincident program, parameter and family changes. +1. Run every known family transition and all coincident-boundary combinations on production code. 2. +Interrupt downloads, compilation and restart during activation; include mixed old/new clients. 3. Repeat +selected cases under real elapsed time and the remainder under disclosed accelerated time. +Pass. Deterministic activation, documented old-client behaviour and no unsafe fallback. Compilation/setup +costs satisfy P03; accelerated runs are not reported as years of operating history. +Evidence. Transition matrix; code-path evidence; compile timing; old-client logs. + +ROT-03 BLOCKER / P00; P01; P08 / NOT RUN + +Test miner-voted bring-forward governance +Setup. Freeze eligibility, threshold, windows and activation semantics before testing; do not invent a +no-veto rule. +1. Attempt threshold-minus-one, threshold, conflicting proposals, duplicate votes and coalition withholding. +2. Partition voters, restore them and test vote-key substitution through pools. 3. Verify adoption and refusal +behaviour of already running nodes. +Pass. The actual mechanism enforces F0, with authenticated voting and no conflicting activation. Any +coalition capable of blocking or manipulating changes is disclosed; labels such as no veto do not override +arithmetic. +Evidence. Executable governance model; signed-vote corpus; coalition/partition results. + + + + +Source: 2.0 plan pp. 7, 11, 19, 21. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 30 / 73 + TEST STANDARD / 1.0 + + + + +ROT / ROT-04 TO ROT-06 + + + +Epochs, seeds and memory +transitions +Transitions must agree across nodes and remain usable during failures; crossing a boundary is not a +chip-retirement test. + +Lead: Consensus + GPU leads +Fixtures: F0 activation rules; F4 fault network; F5 historical and boundary vectors +ROT-04 BLOCKER / P00; P01; P08 / NOT RUN + + +Resist seed selection and faster evaluators +Setup. Provide the specified seed pipeline and delay proof implementation plus independently +parameterised fast-adversary models. +1. Try withholding candidate seeds, grinding alternatives, replaying delay proofs and biased checkpoint +selection. 2. Vary adversarial speed advantage and outage duration; trace influence on program choice. 3. +Validate inputs, parameters and proofs against independent vectors. +Pass. No invalid seed or proof is accepted; selection advantage stays within the approved threat-model +bound. Missing bounds block this gate. A delay mechanism is not credited as generic ASIC resistance. +Evidence. Seed/grinding simulations; speed sensitivity; proof vectors; threat-model signoff. + +ROT-05 BLOCKER / P01; P08 / NOT RUN + +Continue or pause correctly when finality stops +Setup. Stop checkpoint signing while mining continues, then cross seed and family boundaries. +1. Remove the required signing weight and observe the documented fallback or safe pause. 2. Prevent +access to any founder seed service; restart from persisted state. 3. Restore the stated fault assumptions +and verify deterministic recovery. +Pass. Mining/seed behaviour matches F0 without manufacturing certificates or reinterpreting finality. Safety +holds during the outage; liveness is required only after its stated assumptions return. +Evidence. Fault timeline; seed/certificate history; node-state comparison; recovery log. + +ROT-06 BLOCKER / P01; P06 / NOT RUN + +Activate datasets without hidden exclusions +Setup. Freeze memory sizes, support horizon and sync/update procedure; test all advertised roles. +1. Construct the next dataset while current work remains active; test slow disks, low free memory and +interruption. 2. Try stale-state/dataset submissions and maliciously expensive state growth where coupling +exists. 3. Measure data transfer, restart and excluded-card costs before approving progression. +Pass. No invalid stale work is accepted, no supported card silently fails, and P06 is met. Hardware +retirement and sync burden are included in the economic decision, not treated as automatic chip protection. +Evidence. Dataset hashes; memory/update traces; stale-work tests; exclusion decision. + + + + +Source: 2.0 plan pp. 7, 11, 19, 21. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 31 / 73 + TEST STANDARD / 1.0 + + + + +ROT / ROT-07 TO ROT-08 + + + +Epochs, seeds and memory +transitions +Transitions must agree across nodes and remain usable during failures; crossing a boundary is not a +chip-retirement test. + +Lead: Consensus + GPU leads +Fixtures: F0 activation rules; F4 fault network; F5 historical and boundary vectors +ROT-07 GATE / P03; P04 / NOT RUN + + +Ablate redundant rotation layers +Setup. Use matched baseline and ablated variants in the lab; do not change a running public network. +1. Remove each weekly/family component independently and measure adversarial cost, GPU setup and +verifier complexity. 2. Include favourable-period specialists and all retained known families. 3. Keep a layer +only with a distinct, independently supported benefit or a documented non-resistance purpose. +Pass. Every retained layer has explicit justification and full boundary coverage. Redundant complexity is +removed or its rationale recorded; the security model does not double-count the same versatility cost. +Evidence. Ablation report; decision log; complexity/cost comparison. + +ROT-08 GATE / P04; P12 / NOT RUN + +Pass the no-new-rules counterfactual +Setup. Freeze the complete published rule bank and known schedule for the five-year evaluation. +1. Allow a programmable adversary to know and survive all planned changes. 2. Remove assumed future +emergency instructions and manual retirement actions from the model. 3. Run the required ECO scenarios +and link them to independent network-transition tests. +Pass. Competitiveness survives the approved envelope without future rescue assumptions. Any result that +needs unannounced changes fails this claim; ordinary bug maintenance is distinguished from anti-chip +intervention. +Evidence. Frozen-rule model; scenario results; excluded-rescue audit; G5 evidence. + + + + SUITE CLOSE / ROT + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 7, 11, 19, 21. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 32 / 73 + TEST STANDARD / 1.0 + + + + +ECO / ECO-01 TO ECO-03 + + + +Five-year coexistence economics +Test the world after specialised hardware exists, including new entrants and an already-funded +competitor. + +Lead: Economics lead + independent reviewer +Fixtures: F6 adversarial costs; F7 scenario model; F2 operator costs +ECO-01 GATE / P12 / NOT RUN + + +Reconcile complete cost per accepted work +Setup. Use benchmark outputs, current-source cost inputs recorded at execution time and separate +reference scenarios. +1. Calculate hardware annualisation, electricity, host, cooling/hosting, failures, fees, downtime and residual +value. 2. Use actual accepted work and independently verify units and period conversions. 3. Cross-check +formulas using hand-worked fixtures, edge cases and a second implementation. +Pass. All material costs and rejected-work effects appear once; model totals reconcile to raw inputs. No +GPU upgrade is free, development cost is not double-counted, and burn is not mislabelled operator income. +Evidence. Versioned model; unit fixtures; independent reconciliation; input sources. + +ECO-02 GATE / P12 / NOT RUN + +Separate existing-owner and new-entrant viability +Setup. Use both installed hardware and purchasable replacement hardware in every mandatory cohort. +1. Evaluate marginal operation separately from recovery of a new purchase. 2. Stress resale at zero, +hardware failures, financing and replacement cycles. 3. Report break-even power price and total cost +relative to the strongest feasible specialist. +Pass. P12 competitiveness conditions hold for the predeclared cohorts in required sustainable worlds. +Existing-owner profitability cannot substitute for viable new entry; cards outside the envelope remain +visible. +Evidence. Owner/entrant curves; price-date records; break-even tables; cohort outcomes. + +ECO-03 GATE / P12 / NOT RUN + +Let the specialist keep its sunk development +Setup. Use three development cases: fully funded elsewhere, source-range low and source-range high. +1. Evaluate private mining, public hardware sales and a hybrid business model. 2. Allow shared IP, +incremental revisions, multi-year survival and resale where justified. 3. Re-evaluate GPU entry after the +specialist fleet is already installed. +Pass. The coexistence claim does not depend on recovering the original chip research bill. Required P12 +cases meet the approved envelope even at zero incremental development cost; failures cannot be hidden by +the $23M/$340M source thresholds. +Evidence. Business-model variants; sunk-cost case; full cash-flow and adaptation records. + + + + +Source: 2.0 plan pp. 8, 13, 18, 24, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 33 / 73 + TEST STANDARD / 1.0 + + + + +ECO / ECO-04 TO ECO-06 + + + +Five-year coexistence economics +Test the world after specialised hardware exists, including new entrants and an already-funded +competitor. + +Lead: Economics lead + independent reviewer +Fixtures: F6 adversarial costs; F7 scenario model; F2 operator costs +ECO-04 GATE / P12 / NOT RUN + + +Model entry, exit and difficulty response +Setup. Use independently reviewed dynamic operator policies, not fixed market shares. +1. Let agents buy, sell, switch off, re-enter and choose tasks based on declared costs and expected income. +2. Apply the actual difficulty/reward rules and test optimistic and adversarial liquidity/capital availability. 3. +Compare equilibrium and transient outcomes across independent starting conditions. +Pass. Mandatory worlds satisfy P12 without an imposed GPU share or artificial specialist capacity limit. +Concentration, oscillations and excluded regions are reported; model behaviour matches unit and +conservation checks. +Evidence. Agent policies; sensitivity seeds; market-share paths; independent model review. + +ECO-05 GATE / P12 / NOT RUN + +Stress success, contraction and cheap electricity +Setup. Freeze mandatory scenarios before results: revenue bands, tariff range, lifetimes and demand states. +1. Run the P12 factorial grid plus adversarial combinations selected by the independent reviewer. 2. Test a +large successful network as well as weak-revenue and heterogeneous-tariff cases. 3. Distinguish feasible +sustained-entry worlds from collapse scenarios with no rational profitable operator. +Pass. No small-network or token-appreciation assumption props up the primary claim. Required viable +worlds pass the envelope; collapse worlds show honest contraction and safety, not fabricated profits. +Failure regions are explicit. +Evidence. Scenario register; full result cube; boundary plots; failed-world explanations. + +ECO-06 GATE / P12 / NOT RUN + +Fund security and proving as issuance falls +Setup. Use the frozen supply, halving, fee, burn and reward rules rather than source prose assumptions. +1. Reconcile revenue reaching miners, internal provers, developers and burns over the full horizon. 2. Test +flat/declining fees and no external proving income; separately introduce external demand. 3. Calculate +capacity and security-provider coverage after each reward transition. +Pass. Recurring compensation is explicit and internally consistent; mandatory sustainable scenarios meet +P12. Burned amounts are never counted as payments, and external operator income is not assumed to fund +internal work automatically. +Evidence. Issuance/fee ledger; scenario cash flows; funding-shortfall report. + + + + +Source: 2.0 plan pp. 8, 13, 18, 24, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 34 / 73 + TEST STANDARD / 1.0 + + + + +ECO / ECO-07 TO ECO-08 + + + +Five-year coexistence economics +Test the world after specialised hardware exists, including new entrants and an already-funded +competitor. + +Lead: Economics lead + independent reviewer +Fixtures: F6 adversarial costs; F7 scenario model; F2 operator costs +ECO-07 GATE / P06; P12 / NOT RUN + + +Price memory growth and honest-card displacement +Setup. Use GPU-05 and ROT-06 costs with the cheapest specialist adaptation. +1. For each dataset increment, compare specialist cost increases with excluded cards and lost proving +capacity. 2. Include ordinary-owner replacement, resale and reloading expenses. 3. Run alternate bounded +schedules without assigning automatic chip death. +Pass. The retained schedule meets P06/P12 and has an evidence-backed net competitiveness benefit. A +schedule that mainly harms accessible GPUs fails; excluded tiers and mitigations are documented before +activation. +Evidence. Per-step cost/retention table; alternative schedules; approval record. + +ECO-08 GATE / P12 / NOT RUN + +Reproduce and adversarially audit the model +Setup. Give an independent economist or qualified analyst the code, inputs and frozen success criteria. +1. Recalculate required worlds and perturb favourable assumptions against the team. 2. Check dependence +on discounts, utilisation, capital limits, artificial prices and future upgrades. 3. Publish the sensitivity range +and state which conclusions are conditional. +Pass. Material results reproduce, required scenarios pass and no unacknowledged assumption dominates +the claim. The model supports a bounded coexistence conclusion, not a percentage probability that no chip +will appear. +Evidence. Independent report; rerun outputs; model limitations; approved claim envelope. + + + + SUITE CLOSE / ECO + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 8, 13, 18, 24, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 35 / 73 + TEST STANDARD / 1.0 + + + + +EVM / EVM-01 TO EVM-03 + + + +Execution and developer +compatibility +Keep familiar applications while making every difference and metering rule explicit and reproducible. + +Lead: Execution lead + independent implementer +Fixtures: F0 execution-fork semantics; F5 transactions/contracts; F4 multi-node network +EVM-01 BLOCKER / P01; P09 / NOT RUN + + +Match the selected EVM semantics +Setup. Pin the intended execution fork, revm version and all Igneum deviations in F0. +1. Run the applicable upstream execution/state fixtures plus independently written deviation tests. 2. +Execute identical blocks on multiple nodes and compare roots, receipts, logs, gas and failure outcomes. 3. +Minimise mismatches and distinguish intended differences from implementation defects. +Pass. All applicable vectors match; every deviation has a documented test and developer consequence. No +claim of universal Ethereum equivalence or Ethereum settlement security is inferred. +Evidence. Fixture/version inventory; root/receipt diffs; deviation matrix. + +EVM-02 BLOCKER / P01 / NOT RUN + +Preserve transaction binding and replay protection +Setup. Use signed transfers, contract calls and deployment transactions with boundary field values. +1. Alter chain identity, nonce, signature, fee caps and recipient after signing. 2. Replay across nodes, forks +and distinct test networks; resubmit around reorganisation. 3. Check mempool admission and final +consensus execution independently. +Pass. Unauthorised, wrong-network or duplicate spends are rejected according to F0. Valid replacements +follow the declared rule; mempool filtering alone is not evidence of consensus enforcement. +Evidence. Signed corpus; admission/execution outcomes; account-state reconciliation. + +EVM-03 BLOCKER / P01; P09 / NOT RUN + +Test two-dimensional fees and proving limits +Setup. Freeze fee dimensions, estimator rules, abort behaviour and refund policy. +1. Run workloads near and beyond execution and proving budgets, including state-heavy pathological cases. +2. Compare estimated fees with charged fees and validate rollback/receipt status on abort. 3. Mutate a +block producer to omit or undercharge expensive work. +Pass. Deterministic metering, charged amounts and aborted state agree across nodes and proofs. Resource +bounds hold; fee estimates meet P09 for accepted supported cases. Undercharged invalid blocks cannot +bypass consensus. +Evidence. Metering traces; fee fixtures; estimator errors; invalid-block rejection. + + + + +Source: 2.0 plan pp. 15, 25, 34, 35, 36, 37. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 36 / 73 + TEST STANDARD / 1.0 + + + + +EVM / EVM-04 TO EVM-06 + + + +Execution and developer +compatibility +Keep familiar applications while making every difference and metering rule explicit and reproducible. + +Lead: Execution lead + independent implementer +Fixtures: F0 execution-fork semantics; F5 transactions/contracts; F4 multi-node network +EVM-04 BLOCKER / P01; P09 / NOT RUN + + +Exercise block context and randomness assumptions +Setup. Use contracts sensitive to timestamp, height/context, randomness and ordering. +1. Compare the declared Igneum semantics with developers' documented expectations. 2. Test boundary +transitions, miner-influenced inputs and adversarial ordering in the isolated network. 3. Run dependency +reviews for applications using these values for economic decisions. +Pass. Semantics match F0 and differences are surfaced in compatibility documentation. No source of miner +influence is marketed as unbiased randomness; incompatible applications are not included in the +compatibility claim. +Evidence. Context-contract results; threat notes; compatibility exclusions. + +EVM-05 BLOCKER / P01; P09 / NOT RUN + +Run representative contract integration journeys +Setup. Use versioned transfer/token, NFT, multisignature, exchange and upgrade-pattern fixtures where +supported. +1. Deploy, initialise, transact, revert and upgrade each contract using ordinary tooling. 2. Exercise events, +logs, balances, storage and call traces across node restart/reorganisation. 3. Compare expected application +invariants with native execution and proved results. +Pass. Supported journeys preserve their stated invariants; all deviations are documented. Example +deployment success alone cannot stand in for application-level correctness or financial audit. +Evidence. Contract fixture hashes; transaction journeys; invariant and state comparisons. + +EVM-06 BLOCKER / P01; P09 / NOT RUN + +Validate wallets, RPC and indexers +Setup. Pin supported RPC methods and response semantics; use normal developer clients and an +independent indexer. +1. Test fee estimation, pending/final states, subscriptions, pagination and reconnects. 2. Reindex from +genesis or the documented trust anchor after pruning and restart. 3. Compare logs, receipts and balances +with independently validated chain state. +Pass. No missing/duplicate canonical records; unsupported methods are explicit. UI states distinguish +included, executed, proven and finalised. Malformed RPC input cannot crash validators or leak secrets. +Evidence. RPC conformance report; reindex comparison; reconnect/edge-case logs. + + + + +Source: 2.0 plan pp. 15, 25, 34, 35, 36, 37. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 37 / 73 + TEST STANDARD / 1.0 + + + + +EVM / EVM-07 TO EVM-08 + + + +Execution and developer +compatibility +Keep familiar applications while making every difference and metering rule explicit and reproducible. + +Lead: Execution lead + independent implementer +Fixtures: F0 execution-fork semantics; F5 transactions/contracts; F4 multi-node network +EVM-07 BLOCKER / P01; P09 / NOT RUN + + +Handle execution denial-of-service workloads +Setup. Create bounded pathological bytecode, calls, state growth, storage and precompile inputs. +1. Measure CPU, memory, disk and proving cost against charged budgets. 2. Saturate admission with +invalid/expensive requests while valid workloads continue. 3. Restart mid-execution and verify atomic state +recovery. +Pass. P09 limits hold with no unbounded free work or divergent rollback. State remains consistent after +crash; availability under overload follows the declared admission policy, not silent dropping of accepted +transactions. +Evidence. Resource profiles; adversarial corpus; state recovery comparisons. + +EVM-08 BLOCKER / P01; P08; P09 / NOT RUN + +Verify controlled execution and verifier upgrades +Setup. Prepare two authorised versions and malicious, stale or unknown versions. +1. Cross activation with mixed clients, queued transactions and proofs from both versions. 2. Bind each +accepted proof to the correct execution semantics and program identity. 3. Exercise a failed software +distribution without altering consensus activation. +Pass. No unknown or wrong-version execution is accepted. Pre/post-boundary handling is deterministic and +documented; software delivery cannot silently redefine transaction semantics or proof acceptance. +Evidence. Upgrade vectors; mixed-version traces; manifest/version bindings. + + + + SUITE CLOSE / EVM + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 15, 25, 34, 35, 36, 37. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 38 / 73 + TEST STANDARD / 1.0 + + + + +ZKP / ZKP-01 TO ZKP-03 + + + +Consensus-enforced proof validity +The validator, not merely the official producer, must reject unauthorised or invalid proof records and +rewards. + +Lead: Proving + protocol leads; independent cryptography review +Fixtures: F0 pinned programs/verifiers; F5 valid and hostile proof corpus; unmodified validators +ZKP-01 BLOCKER / P01; P09 / NOT RUN + + +Reject missing and invalid proofs +Setup. Start from a native-correct statement and an independently verified valid proof. +1. Submit the statement with no proof, truncated bytes, random bytes and targeted proof mutations using a +modified producer. 2. Submit the genuine proof as a positive control through ordinary network paths. 3. +Inspect block acceptance and resulting reward/state on unmodified validators. +Pass. Every invalid proof record is rejected and earns no reward; valid controls succeed. A producer-side +filter is not sufficient. Record rejection semantics exactly as defined by F0. +Evidence. Hostile record corpus; validator decisions; before/after balances; positive controls. + +ZKP-02 BLOCKER / P01; P09 / NOT RUN + +Bind program, verifier and security parameters +Setup. Use valid proofs from authorised and unauthorised programs and parameter sets. +1. Swap program digest, verifier version, security settings and verification key where applicable. 2. Attempt +downgrade through configuration, serialized metadata or an old node path. 3. Test authorised boundary +transitions and unsupported future identities. +Pass. Only explicitly authorised combinations are accepted in the correct epoch. No implicit trust in +producer-supplied metadata or lower-security fallback; all accepted settings have scoped soundness +review. +Evidence. Identity/parameter matrix; rejection traces; cryptographic review. + +ZKP-03 BLOCKER / P01 / NOT RUN + +Bind network, epoch, job and state roots +Setup. Prepare valid proofs for distinct chains, epochs, jobs and initial/final states. +1. Replay each proof under another network, job, epoch, shard range or state commitment. 2. Alter public +inputs while retaining the proof and test valid-but-wrong-context statements. 3. Check duplicated and +reordered records across forks and replayed sync data. +Pass. Every misbound proof is rejected; valid authorised replays follow only explicitly allowed semantics +and never create extra rewards. Native reexecution cannot conceal missing proof-context binding. +Evidence. Binding matrix; public-input hashes; replay traces; reward reconciliation. + + + + +Source: 2.0 plan pp. 16, 20, 24, 25, 36, 37. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 39 / 73 + TEST STANDARD / 1.0 + + + + +ZKP / ZKP-04 TO ZKP-06 + + + +Consensus-enforced proof validity +The validator, not merely the official producer, must reject unauthorised or invalid proof records and +rewards. + +Lead: Proving + protocol leads; independent cryptography review +Fixtures: F0 pinned programs/verifiers; F5 valid and hostile proof corpus; unmodified validators +ZKP-04 BLOCKER / P01 / NOT RUN + + +Prevent reward and payout substitution +Setup. Use proofs that commit to authorisation and all reward-relevant fields required by F0. +1. Alter payout key, amount, beneficiary, source work or fee allocation independently. 2. Supply correct +execution over malicious producer-provided consensus/reward inputs. 3. Compare consensus-derived +rewards with the proved/publicly authenticated derivation. +Pass. Unauthorised payout changes and incorrect consensus inputs are rejected; no statement accepted +merely because execution over supplied inputs is internally correct. Legitimate authorisations are +preserved. +Evidence. Mutation cases; reward derivation trace; signature/proof binding review. + +ZKP-05 BLOCKER / P01 / NOT RUN + +Make proof payment idempotent across races +Setup. Use competing provers submitting valid results for the same work and simulate +retries/reorganisations. +1. Submit simultaneous duplicates, reordered receipts and repeated messages after disconnects. 2. Crash +validators between validation and reward application, then recover. 3. Reconcile canonical payouts against +the exact F0 duplicate policy. +Pass. Only the authorised total payment is made; no double payout, lost accepted entitlement or +fork-retained balance. Transactions and payout records recover atomically. +Evidence. Concurrency schedule; canonical payment ledger; crash/recovery evidence. + +ZKP-06 BLOCKER / P01; P09 / NOT RUN + +Verify aggregation coverage and completeness +Setup. Build valid multi-shard workloads plus omitted, duplicated, overlapping and misordered shard sets. +1. Attempt an aggregate with a correct outer proof but wrong coverage/public-input construction. 2. Alter +shard ranges, roots and aggregation-program identity. 3. Verify native execution, aggregate validity and +coverage commitments independently. +Pass. Only complete, correctly ordered authorised coverage is accepted. No valid proof of the wrong +computation becomes an accepted chain result; aggregation failures do not fabricate successful delivery. +Evidence. Coverage corpus; aggregate/public-input verification; rejection ledger. + + + + +Source: 2.0 plan pp. 16, 20, 24, 25, 36, 37. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 40 / 73 + TEST STANDARD / 1.0 + + + + +ZKP / ZKP-07 TO ZKP-08 + + + +Consensus-enforced proof validity +The validator, not merely the official producer, must reject unauthorised or invalid proof records and +rewards. + +Lead: Proving + protocol leads; independent cryptography review +Fixtures: F0 pinned programs/verifiers; F5 valid and hostile proof corpus; unmodified validators +ZKP-07 BLOCKER / P01; P09 / NOT RUN + + +Review soundness and verifier resource limits +Setup. Provide proof-system code, parameters, patches and the pinned verification path to an independent +specialist. +1. Review soundness assumptions, parameter margins and consequences of performance patches. 2. Fuzz +deserialization and adversarial proofs; measure verification CPU and memory under load. 3. Cross-check an +independent verifier or reference path and test crash containment. +Pass. P09 review and resource requirements pass with no unresolved critical/high finding. Random proof +rejection counts are not described as evidence of a particular cryptographic security level. +Evidence. Scoped soundness review; parameter sheet; fuzzer corpus; verifier profiles. + +ZKP-08 BLOCKER / P01; P07; P08 / NOT RUN + +Preserve authority and audit all acceptance paths +Setup. Inspect block import, sync, RPC, light verification, database restoration and fast paths. +1. Try bypassing validation via each path with a proof rejected by the normal path. 2. Remove the dominant +prover/aggregator and have independent replacements process available inputs. 3. Attempt to use +proof-production status as ordering, voting or finality authority. +Pass. No bypass accepts invalid work; proofs alone confer no unauthorised consensus control. Replacement +and pause behaviour meet F0/P07/P08 without privileged keys or a trusted aggregator shortcut. +Evidence. Path coverage report; bypass corpus; replacement run; authority checks. + + + + SUITE CLOSE / ZKP + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 16, 20, 24, 25, 36, 37. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 41 / 73 + TEST STANDARD / 1.0 + + + + +CAP / CAP-01 TO CAP-03 + + + +Sustained proving and delivery +A correct fast shard is only one stage; capacity, latency, payment and retries must work together. + +Lead: Proving lead + independent operators +Fixtures: F3 meaningful workload catalogue; F4 network; F8 external job harness +CAP-01 GATE / P02; P07 / NOT RUN + + +Reproduce the historical consumer-shard result +Setup. Recover the exact source-era workload/build if available; keep it separate from the +release-candidate workload. +1. Attempt independent reproduction of the 4,717,439-cycle workload and reported 3060/4060/4070 +results. 2. Record proof format, memory, energy, host and whether aggregation/compression are included. +3. Repeat on the final release and label all configuration changes. +Pass. Historical figures are either reproduced within P02 tolerance or corrected/labelled non-reproduced. +Release acceptance uses the current complete workload, never an unmatched historical time or a smaller +substituted shard. +Evidence. Historical/current manifests; proof verification; timing and memory records. + +CAP-02 BLOCKER / P01; P06; P07 / NOT RUN + +Prove on the actual mining configuration +Setup. Use final dataset sizes, registers, clocks, drivers and proof pipeline on every advertised proving tier. +1. Run mining alone, proving alone, concurrent execution and supported time-sharing. 2. Measure wall +energy, memory headroom, reloads, proof latency and forgone accepted mining work. 3. Induce memory +pressure and GPU task failure without losing wallet control. +Pass. Every advertised mode completes correctly and meets P06/P07. Net output includes opportunity +cost; unsupported concurrency is not claimed. Mining-only vendor support remains separately labelled. +Evidence. Four-mode results; OOM/failure logs; memory and opportunity-cost ledger. + +CAP-03 GATE / P07 / NOT RUN + +Measure the entire request-to-payment path +Setup. Assign a unique job ID and immutable timestamps to every stage of F3/F8 jobs. +1. Record request, input availability, assignment, execution, shard proof, aggregation, verification, delivery +and payment. 2. Compare monotonic elapsed time with any protocol/DAA clock and document their +relationship. 3. Reconcile failed, censored, retried and abandoned jobs with the original request +denominator. +Pass. No hidden stage or missing job; latency distributions and cost cover the complete path. Delivery, +finality and payment are reported separately; protocol seconds are not silently relabelled wall-clock +seconds. +Evidence. Stage event ledger; clock calibration; end-to-end latency/cost report. + + + + +Source: 2.0 plan pp. 17, 18, 24, 25. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 42 / 73 + TEST STANDARD / 1.0 + + + + +CAP / CAP-04 TO CAP-06 + + + +Sustained proving and delivery +A correct fast shard is only one stage; capacity, latency, payment and retries must work together. + +Lead: Proving lead + independent operators +Fixtures: F3 meaningful workload catalogue; F4 network; F8 external job harness +CAP-04 GATE / P07 / NOT RUN + + +Sustain meaningful load without queue growth +Setup. Freeze W: payload mix, input sizes, execution work and per-hour demand; prohibit tiny-workload +substitution. +1. Run 72 hours at W and a separate 24 hours at 1.2W on the declared fleet. 2. Measure arrival/completion +counts, backlog trend, oldest-job age, deadlines and all retries. 3. Use held-out workloads and an +independent observer to detect discarded or delayed requests. +Pass. P07 completion, tail-latency and bounded-backlog criteria hold. Capacity is stated for the tested +W/fleet, not as universal TPS. A queue that grows indefinitely or shrinks through silent loss fails. +Evidence. Request/completion reconciliation; backlog series; held-out results; observer report. + +CAP-05 BLOCKER / P01; P07 / NOT RUN + +Overload and recover without false acceptance +Setup. Start at W and inject 2W for 15 minutes with valid and invalid jobs, then return to W. +1. Observe admission, explicit backpressure, reservations and deadline estimates. 2. Track accepted jobs to +valid completion or the pre-agreed failure/refund outcome. 3. Measure recovery time and ensure ordinary +users are not silently starved. +Pass. P07 overload policy and recovery limits hold; no accepted job vanishes or earns an invalid reward. +Rejected demand is reported separately from delivery success, preventing denominator manipulation. +Evidence. Overload timeline; admission/refund logs; backlog-drain proof. + +CAP-06 GATE / P07; P12 / NOT RUN + +Calibrate assignment windows to paid completion +Setup. Use a heterogeneous proving fleet, including the slowest advertised consumer tier. +1. Measure actual completion distributions with network delay, competing load and failed attempts. 2. Test +the chosen exclusive window, open claiming and faster challengers after expiry. 3. Compare assignment +frequency, paid completions and wasted work by tier. +Pass. P07 fairness and wasted-work limits hold for advertised tiers. A provisional 10-DAA-second window is +not treated as approved. Fair assignment counts alone cannot pass; payment outcomes and operator +margins matter. +Evidence. Window sweep; paid-completion distribution; wasted-work and margin report. + + + + +Source: 2.0 plan pp. 17, 18, 24, 25. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 43 / 73 + TEST STANDARD / 1.0 + + + + +CAP / CAP-07 TO CAP-08 + + + +Sustained proving and delivery +A correct fast shard is only one stage; capacity, latency, payment and retries must work together. + +Lead: Proving lead + independent operators +Fixtures: F3 meaningful workload catalogue; F4 network; F8 external job harness +CAP-07 BLOCKER / P01; P07; P08 / NOT RUN + + +Reassign work when inputs or providers disappear +Setup. Remove input providers, assigned provers and the dominant aggregator independently and together. +1. Have replacement operators retrieve authenticated inputs without founder files. 2. Retry expired +assignments while preserving idempotent reward and customer outcomes. 3. Restore providers and test +late submissions racing with replacements. +Pass. P07/P08 replacement deadlines hold when availability assumptions permit. Otherwise a truthful +bounded pause/refund occurs; no fake proof, double payment or hidden privileged input source is used. +Evidence. Failure schedule; input hashes; reassignment and payout ledger; recovery trace. + +CAP-08 BLOCKER / P01; P07; P14 / NOT RUN + +Deliver customer-verifiable output at scale +Setup. Run the external workload using a customer-controlled verifier and independently operated workers. +1. Verify every delivered proof against the contracted program and input commitment. 2. Reject +wrong-format, stale and partial deliveries; test customer retry and delivery failure. 3. Reconcile delivery, +acceptance, payment and refund records without exposing private inputs publicly. +Pass. P07 delivery performance and exact validity hold. Payment depends on the contracted correct result; +a valid proof for the wrong job is not a successful delivery. +Evidence. Customer verification log; proof-format contract; settlement reconciliation. + + + + SUITE CLOSE / CAP + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 17, 18, 24, 25. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 44 / 73 + TEST STANDARD / 1.0 + + + + +INC / INC-01 TO INC-03 + + + +Rewards, incentives and selfish +operators +Assume operators optimise their own returns. Do not depend on the official client choosing a less +profitable task. + +Lead: Protocol economics + proving leads +Fixtures: F0 fee/reward rules; F4 adversarial operators; F7 incentive models +INC-01 BLOCKER / P01; P12 / NOT RUN + + +Reconcile issuance, fees, burns and recipients +Setup. Use a deterministic short chain containing all reward types, fee paths and rounding cases. +1. Calculate balances, total supply changes, burns and distributions independently. 2. Execute identical +blocks natively and through the proving path. 3. Test zero, minimum, maximum and transition-boundary +values plus malformed producer accounting. +Pass. Conservation and recipient rules match F0 exactly; no inflation, rounding leakage or duplicate reward. +Fee-table and prose discrepancies are resolved before the run, not guessed by the tester. +Evidence. Independent accounting ledger; balance/supply diffs; boundary vectors. + +INC-02 BLOCKER / P01; P12; P14 / NOT RUN + +Keep revenue streams and claims separate +Setup. Prepare jobs and blocks producing mining income, internal proof rewards and external payments. +1. Trace money from source to operator, protocol, developer and any burn. 2. Compare node records, +settlement records and Ember displays. 3. Attempt to classify testnet rewards, reimbursed purchases or +token appreciation as external customer revenue. +Pass. Every stream reconciles and is labelled correctly. No double-counted revenue or fabricated protocol +demand; mining subsidy and external service income remain distinct in dashboards and ECO. +Evidence. Money-flow register; UI reconciliation; rejected classifications. + +INC-03 GATE / P07; P12 / NOT RUN + +Let a modified client choose the most profitable task +Setup. Permit independent schedulers to mine, prove internally, prove externally or switch off. +1. Publish common costs and vary relative task rewards, memory pressure and switching costs. 2. Run +clients that ignore the official scheduling recommendation. 3. Measure realised operator margin, internal +capacity and network progress. +Pass. Required P12 sustainable worlds maintain paid essential capacity without compelled altruism. +Profitability and availability are based on realised outcomes, including switching and wasted work. +Evidence. Scheduler source/policies; switching traces; capacity and margin series. + + + + +Source: 2.0 plan pp. 13, 16, 17, 18, 24, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 45 / 73 + TEST STANDARD / 1.0 + + + + +INC / INC-04 TO INC-06 + + + +Rewards, incentives and selfish +operators +Assume operators optimise their own returns. Do not depend on the official client choosing a less +profitable task. + +Lead: Protocol economics + proving leads +Fixtures: F0 fee/reward rules; F4 adversarial operators; F7 incentive models +INC-04 GATE / P07; P08; P12 / NOT RUN + + +Survive external-demand spikes and token declines +Setup. Use F7 scenarios with 10x external job offers and token-denominated mining-income shocks. +1. Allow miners/provers to switch freely under the declared reward and difficulty rules. 2. Observe hash +participation, proof backlog, fees and recovery without an administrator. 3. Repeat with external demand +dropping to zero and with a dominant operator withdrawn. +Pass. Mandatory viable worlds meet P07/P12; stressed nonviable worlds fail or pause safely with truthful +status. No emergency rule, fabricated demand or unofficial subsidy is inserted to force a pass. +Evidence. Shock timeline; fee/hash/capacity paths; failure-region report. + +INC-05 BLOCKER / P01; P07; P09 / NOT RUN + +Contain job reservation and identity-splitting abuse +Setup. Freeze the actual assignment/payment mechanism; do not assume unimplemented collateral or +identity controls. +1. Create many worker identities, reserve jobs, withhold proofs and submit late results. 2. Attempt free +option-taking, duplicate work rewards and displacement of honest assignments. 3. Price attacker costs and +observe honest completion under the approved abuse load. +Pass. F0 rules and P07 service limits hold under the declared adversary. Identity splitting does not create +unauthorised rewards or control; any unmitigated starvation path blocks the permissionless-service claim. +Evidence. Attack clients; assignment trace; cost-to-disrupt analysis; honest-user outcomes. + +INC-06 BLOCKER / P01; P08; P12 / NOT RUN + +Test difficulty and timestamp manipulation +Setup. Use the actual adjustment algorithm and consensus timestamp rule with independent miners. +1. Inject large hashrate arrivals/departures, periodic selective mining and boundary-timed bursts. 2. Try +allowed and invalid timestamp skew, withheld blocks and replayed work. 3. Observe block intervals, reward +allocation and recovery after hashrate stabilises. +Pass. Invalid inputs are rejected; valid adversarial strategies remain within F0/P08 bounds and are priced in +ECO. No unexplained reward amplification, permanent stall or conflicting accepted work. +Evidence. Difficulty trace; timestamp corpus; revenue analysis; independent rule review. + + + + +Source: 2.0 plan pp. 13, 16, 17, 18, 24, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 46 / 73 + TEST STANDARD / 1.0 + + + + +INC / INC-07 TO INC-08 + + + +Rewards, incentives and selfish +operators +Assume operators optimise their own returns. Do not depend on the official client choosing a less +profitable task. + +Lead: Protocol economics + proving leads +Fixtures: F0 fee/reward rules; F4 adversarial operators; F7 incentive models +INC-07 BLOCKER / P01; P12; P14 / NOT RUN + + +Resist self-dealing fees and fake proving demand +Setup. Use self-funded operators and related customer identities in the isolated economic model/network. +1. Cycle funds through jobs, tips, developer shares and rebates to seek net reward extraction. 2. Attempt to +inflate external-demand metrics without genuine unrelated customer expenditure. 3. Reconcile all +counterparties and net cash contribution rather than gross transaction volume. +Pass. No unauthorised subsidy extraction or metric inflation passes. Related-party volume is +disclosed/excluded from P14; net external cash and legitimate protocol incentives are reported separately. +Evidence. Circular-flow tests; ownership/conflict review; net-cash reconciliation. + +INC-08 GATE / P08; P11; P12 / NOT RUN + +Quantify provider and supplier failure concentration +Setup. Model control of hashing, signing, proving, aggregation and hardware supply separately. +1. Remove each largest operational dependency and combine correlated failures. 2. Measure replacement +cost/time and whether essential roles share hidden ownership. 3. Compare results with the approved fault +model and no-rescue exercise. +Pass. No hidden single dependency defeats the claimed independence; within-tolerance withdrawals +recover under P08/P11. Hardware supply concentration is disclosed without equating vendor sales to +operator voting control. +Evidence. Role/ownership map; dependency removals; recovery and concentration report. + + + + SUITE CLOSE / INC + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 13, 16, 17, 18, 24, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 47 / 73 + TEST STANDARD / 1.0 + + + + +FIN / FIN-01 TO FIN-03 + + + +Consensus safety and recovery +Test safety under the stated fault bounds. Demand liveness only when synchrony and participation +assumptions actually hold. + +Lead: Consensus lead + independent formal/security review +Fixtures: F0 exact fault model; F4 real-node partitions; F5 certificates and historical failures +FIN-01 BLOCKER / P01; P08 / NOT RUN + + +Agree on ordering, work and executed state +Setup. Use real fork-choice/DAG handling and independent miners, not only a simplified simulator. +1. Generate concurrent branches, delayed blocks, duplicates and invalid work with deterministic seeds. 2. +Compare selected ordering, accumulated work, transaction execution and state roots after delivery +converges. 3. Replay from independent checkpoints and from genesis where practical. +Pass. Honest nodes converge under F0 assumptions with exact roots and rewards. No duplicated work +accounting or undocumented ordering dependence; simulator-only success cannot substitute. +Evidence. Block/ordering corpus; root/work diffs; real-node replay logs. + +FIN-02 BLOCKER / P01; P08 / NOT RUN + +Attack finality with split honest populations +Setup. Use the source-discussed 40/40/20 weight split, plus threshold-boundary splits under F0. +1. Let the 20% adversarial group sign conflicting histories while honest groups are partitioned. 2. Delay +messages and eligibility updates independently; keep total historical weights auditable. 3. Try to form two +certificates and reconnect nodes to observe accepted final history. +Pass. No conflicting final certificates are accepted within the declared fault bound. A safe pause is valid +when quorum is unavailable; making progress on both sides is not required. +Evidence. Signed votes; certificate attempts; voter-table snapshots; safety checker output. + +FIN-03 BLOCKER / P01; P08 / NOT RUN + +Cross authority expiry in a long partition +Setup. Recover historical expiry failures where available; use the actual current authority-transition rules. +1. Partition for 31, 35, 60 and 90 logical days and around every retention/expiry boundary. 2. Attempt +independently renewed authority sets and conflicting checkpoint locks. 3. Repeat selected boundary cases +on real nodes with accelerated timers explicitly labelled. +Pass. Authority continuity remains authenticated and no conflicting final history appears within F0 +assumptions. A timeout is not accepted as proof absent voters ceased to exist. Compressed time is not +multi-month field evidence. +Evidence. Expiry timeline; table/certificate history; historical regression tests. + + + + +Source: 2.0 plan pp. 19, 21, 24, 25. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 48 / 73 + TEST STANDARD / 1.0 + + + + +FIN / FIN-04 TO FIN-06 + + + +Consensus safety and recovery +Test safety under the stated fault bounds. Demand liveness only when synchrony and participation +assumptions actually hold. + +Lead: Consensus lead + independent formal/security review +Fixtures: F0 exact fault model; F4 real-node partitions; F5 certificates and historical failures +FIN-04 BLOCKER / P01; P08 / NOT RUN + + +Stop signing while mining continues +Setup. Remove enough signing participation to invalidate the liveness assumption without forging votes. +1. Continue mining and execution, cross seed boundaries and monitor proof queues. 2. Check which +user-visible states advance and which remain unfinalised. 3. Restore eligible weight and bounded message +delay, then verify recovery. +Pass. No false finality or fabricated authority. Behaviour matches F0 during the pause and P08 after +assumptions return; unfinished transactions are not displayed as irreversible. +Evidence. Signing/mining trace; UI/RPC states; recovery roots and timing. + +FIN-05 BLOCKER / P01; P08 / NOT RUN + +Authenticate voter-set changes and pooled keys +Setup. Use normal transitions, pool members retaining keys and malicious substitution attempts. +1. Alter voter weights, membership proofs, miner/pool identity bindings and prior-certificate links. 2. Race +updates across boundaries and replay old signed changes. 3. Have a new node verify the authority chain +from its declared trust anchor. +Pass. Only correctly authenticated changes are accepted; weights cannot be double-counted or redirected +by a pool. All honest nodes agree on the active authority set for each certified point. +Evidence. Authority-chain fixtures; substitution attacks; new-node verification log. + +FIN-06 BLOCKER / P01; P08 / NOT RUN + +Analyse old-key compromise and long-range histories +Setup. Freeze assumptions about key erasure, retained weights, trust anchors and offline recovery. +1. Use previously eligible keys to build alternative histories after their operators disappear. 2. Present these +histories to recently offline and newly joining clients. 3. Test replayed certificates, stale anchors and +compromised signer subsets. +Pass. Acceptance matches the explicit security model with no hidden trusted recovery step. Any reliance on +a recent trusted anchor is disclosed and tested; hashpower assumptions cannot replace old-key analysis. +Evidence. Long-range corpus; trust-anchor policy; key-compromise review; client results. + + + + +Source: 2.0 plan pp. 19, 21, 24, 25. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 49 / 73 + TEST STANDARD / 1.0 + + + + +FIN / FIN-07 TO FIN-08 + + + +Consensus safety and recovery +Test safety under the stated fault bounds. Demand liveness only when synchrony and participation +assumptions actually hold. + +Lead: Consensus lead + independent formal/security review +Fixtures: F0 exact fault model; F4 real-node partitions; F5 certificates and historical failures +FIN-07 BLOCKER / P01; P08 / NOT RUN + + +Recover deterministically after reconnection and crash +Setup. Combine partitions with node crash, partial writes, restarts and proof backlog. +1. Reconnect networks under bounded latency and restore required honest participation. 2. Verify fork +choice, unfinalised reorganisation, finality, reward rollback and proof reassignments. 3. Compare all honest +nodes and customer-visible receipts after recovery. +Pass. P08 recovery holds without reversing a previously valid final guarantee. Only permitted unfinalised +state is reorganised; no duplicate rewards or inconsistent receipt statuses survive. +Evidence. Recovery timelines; roots/certificates; payout rollback; customer-state reconciliation. + +FIN-08 BLOCKER / P01; P08 / NOT RUN + +Combine boundaries, faults and adversarial scheduling +Setup. Use an independent model checker/scheduler and production-node scenarios from F4. +1. Combine epoch changes, authority transitions, mining churn, data delays and prover/aggregator loss. 2. +Explore bounded adversarial message schedules and minimise any counterexample. 3. Replay model +findings on real code and have an independent reviewer assess uncovered states. +Pass. No unresolved safety failure; liveness claims hold only within declared assumptions and P08. Model +bounds and untested schedules are published, not described as proof over every possible execution. +Evidence. Model/spec artifacts; schedule corpus; replay evidence; independent assessment. + + + + SUITE CLOSE / FIN + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 19, 21, 24, 25. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 50 / 73 + TEST STANDARD / 1.0 + + + + +VER / VER-01 TO VER-03 + + + +Wallets, receipts and data +availability +Verify the exact property shown to the user. An inclusion proof, execution proof and finality certificate are +not interchangeable. + +Lead: Wallet + light-client lead; independent security review +Fixtures: F0 trust/availability model; F5 malformed roots, receipts and authority chains +VER-01 BLOCKER / P01; P09 / NOT RUN + + +Authenticate light-client bootstrap +Setup. Give a clean client malicious RPC responses, fabricated voter tables and valid-looking signatures. +1. Start from the approved trust anchor and verify every required link to the advertised state. 2. Substitute +otherwise well-formed but unauthorised keys, weights and checkpoints. 3. Remove the bootstrap service +and use another independently operated source. +Pass. The client rejects unauthorised authority and discloses any trust anchor. Signatures over a +node-supplied table do not by themselves pass; missing authentication never silently degrades to trusted +RPC. +Evidence. Bootstrap corpus; trust-chain trace; fail-closed tests. + +VER-02 BLOCKER / P01; P09 / NOT RUN + +Verify evolving authority and execution statements +Setup. Use valid state proofs paired with wrong execution statements or stale authority histories. +1. Cross voter and verifier changes with offline clients returning after long intervals. 2. Alter roots, aggregate +identity and proof/public-input bindings independently. 3. Check local verification rather than merely a +server-reported verified flag. +Pass. All advertised proof checks occur locally or the remaining trust is explicitly disclosed. Wrong roots and +unauthenticated authority are rejected; unsupported verification paths are not claimed. +Evidence. Client verification trace; corrupted inputs; offline/upgrade results. + +VER-03 BLOCKER / P01; P09 / NOT RUN + +Prove successful payment rather than inclusion +Setup. Create successful, reverted, wrong-asset, wrong-recipient and wrong-amount transfers. +1. Generate receipts for included transactions, including failures and replaced/unfinalised transactions. 2. +Verify execution status plus asset, recipient, amount and canonical-state/receipt commitment. 3. Replay +the receipt on another chain and after an allowed unfinalised reorganisation. +Pass. Only the actual successful, correctly bound transfer is labelled payment proof. Inclusion-only receipts +are labelled as such; no node-reported success flag substitutes for authenticated outcome. +Evidence. Payment fixture corpus; receipt verification; merchant-facing status checks. + + + + +Source: 2.0 plan pp. 20, 25, 35, 37. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 51 / 73 + TEST STANDARD / 1.0 + + + + +VER / VER-04 TO VER-06 + + + +Wallets, receipts and data +availability +Verify the exact property shown to the user. An inclusion proof, execution proof and finality certificate are +not interchangeable. + +Lead: Wallet + light-client lead; independent security review +Fixtures: F0 trust/availability model; F5 malformed roots, receipts and authority chains +VER-04 BLOCKER / P00; P01; P09 / NOT RUN + + +Bound cross-chain oracle trust and replay +Setup. For a claimed oracle, freeze destination verifier, authority updates, accepted proof types and replay +policy. +1. Try deployer-substituted keys, stale certificates, unchecked signatures and wrong source/destination +identities. 2. Exercise legitimate authority updates and source reorganisations under the approved model. 3. +Measure gas/cost with realistic header sets and test disabled/unavailable verification. +Pass. The oracle enforces its declared trust model and fails closed. Deployer privileges and unavailable +guarantees are explicit; no trustless-bridge claim exceeds the checks performed. Excluded oracle scope +earns no pass credit. +Evidence. Oracle code/parameters; attack cases; cost report; privilege disclosure. + +VER-05 BLOCKER / P01; P08; P09 / NOT RUN + +Reconstruct required state without founder storage +Setup. Remove founder archival/input services and start an independent operator from the documented +entry point. +1. Fetch authenticated blocks, state/proof inputs and any required witnesses from permitted peers. 2. +Rebuild the expected state and continue validation/proving. 3. Measure bandwidth, disk, time and retention +requirements against advertised operator budgets. +Pass. Required data can be obtained and verified within the declared availability model. Hidden archives or +unpublished files block independence. A valid execution proof alone does not satisfy this test. +Evidence. Download/reconstruction logs; data hashes; resource costs; dependency inventory. + +VER-06 BLOCKER / P01; P08; P09 / NOT RUN + +Detect withholding, corruption and stale data +Setup. Serve valid commitments with missing data, corrupted chunks, stale witnesses and conflicting peer +replies. +1. Attempt to make a validator or light client accept an unavailable or incorrect state under F0. 2. Test +retrieval from independent peers and expiry/retry policy. 3. Restore data and check that recovery cannot +alter an already verified commitment. +Pass. No unjustified available/verified status; safety and admission rules match F0. Recovery is bounded +where assumptions permit, and unavailable-data states remain visible instead of hidden behind proofs. +Evidence. Withholding corpus; peer retrieval traces; availability/status checks. + + + + +Source: 2.0 plan pp. 20, 25, 35, 37. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 52 / 73 + TEST STANDARD / 1.0 + + + + +VER / VER-07 TO VER-08 + + + +Wallets, receipts and data +availability +Verify the exact property shown to the user. An inclusion proof, execution proof and finality certificate are +not interchangeable. + +Lead: Wallet + light-client lead; independent security review +Fixtures: F0 trust/availability model; F5 malformed roots, receipts and authority chains +VER-07 BLOCKER / P01; P09 / NOT RUN + + +Protect wallet keys, signing and recovery +Setup. Use test-only keys, encrypted backups and clean replacement devices; no real user funds. +1. Attempt secret access from proving jobs, logs, crash dumps, clipboard and telemetry paths. 2. Verify +transaction destination/amount before signing; test backup/restore and wrong-password handling. 3. +Upgrade and recover without silently changing signing authority or exposing seed material. +Pass. No unintended secret disclosure or unauthorised signature. Supported recovery restores the correct +keys and accounts; users receive explicit risk/backup information. Logs are sanitised without hiding security +evidence. +Evidence. Security review; canary-secret tests; signing fixtures; restore journey. + +VER-08 BLOCKER / P01; P09 / NOT RUN + +Keep every user-facing state truthful +Setup. Create included-only, executed, proven, finalised, reverted, stale and paused examples. +1. Compare explorer, wallet, receipt, RPC and customer API labels against authenticated evidence. 2. +Interrupt finality and proof services and observe refresh/reconnect behaviour. 3. Check statements about +privacy, Ethereum security and device support. +Pass. No stronger state is implied than verified; stale data is marked and failures are actionable. EVM +compatibility is not labelled Ethereum security, and ZK technology is not automatically labelled transaction +privacy. +Evidence. Cross-surface screenshots/logs; state mapping; claim review. + + + + SUITE CLOSE / VER + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 20, 25, 35, 37. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 53 / 73 + TEST STANDARD / 1.0 + + + + +OPS / OPS-01 TO OPS-03 + + + +Independent operation and release +security +A permissionless specification must remain operational without privileged infrastructure or unsafe +automatic updates. + +Lead: Operations + release leads; independent operators +Fixtures: F4 isolated multi-operator network; F0 signed releases; F9 telemetry +OPS-01 BLOCKER / P07; P08; P11 / NOT RUN + + +Run the complete no-founder exercise +Setup. Use the P11 independent network, adequate honest participation and enough non-founder capacity +for W. +1. Remove founder miners, provers, aggregators, RPC, DNS/bootstrap dependencies and private support +access. 2. Run the full P11 period while crossing real and separately labelled accelerated boundaries. 3. +Introduce scheduled faults and have independent operators recover using published instructions. +Pass. No founder action, secret file, privileged key or emergency anti-chip rule is needed. P07/P08 +outcomes hold within assumptions; any intervention is recorded as a failed no-rescue run, not erased. +Evidence. Operator roster/conflict checks; dependency removals; full activity/intervention log. + +OPS-02 BLOCKER / P01; P08; P09 / NOT RUN + +Diversify bootstrap and resist peer isolation +Setup. Start nodes without the default bootstrap host and give others adversarial peer lists. +1. Attempt eclipse through peer concentration, stale discovery, poisoned DNS and repeated identities in an +isolated lab. 2. Use independent documented discovery paths and validate returned chain data. 3. Measure +synchronisation, peer diversity and recovery after benign connectivity returns. +Pass. No unauthenticated history is trusted; bootstrap has no hidden single-provider requirement. Isolation +is detected/contained according to F0 and recovery meets P08 when assumptions return. +Evidence. Peer/discovery traces; eclipse scenarios; startup and recovery evidence. + +OPS-03 BLOCKER / P01; P09 / NOT RUN + +Separate update distribution from consensus authority +Setup. Use test signing keys and clean desktop/node installations with valid, stale and malicious packages. +1. Offer signed updates with unexpected consensus rules, downgraded binaries and corrupted payloads. 2. +Test explicit operator acceptance and the published signing-key incident procedure. 3. Confirm that +distribution-key possession cannot independently activate new consensus rules. +Pass. Tampering/unauthorised rollback is rejected; updates do not silently transfer authority. Approved +acceptance and activation are separate. No test touches production signing material. +Evidence. Package corpus; approval/activation traces; compromised-key rehearsal. + + + + +Source: 2.0 plan pp. 21, 24, 25, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 54 / 73 + TEST STANDARD / 1.0 + + + + +OPS / OPS-04 TO OPS-06 + + + +Independent operation and release +security +A permissionless specification must remain operational without privileged infrastructure or unsafe +automatic updates. + +Lead: Operations + release leads; independent operators +Fixtures: F4 isolated multi-operator network; F0 signed releases; F9 telemetry +OPS-04 BLOCKER / P01; P08 / NOT RUN + + +Recover nodes from crash and storage damage +Setup. Use production database/snapshot paths with controlled interrupted writes and corrupted test +storage. +1. Crash during import, proof acceptance, reward application and snapshot generation. 2. Restore from +independently verified snapshots or re-sync through documented procedures. 3. Compare roots, +certificates, balances and processed-job IDs with an unaffected node. +Pass. No corrupt snapshot is trusted, no duplicate payout and no loss of authenticated final state. Recovery +meets P08 where data is available; ambiguous corruption fails closed and is actionable. +Evidence. Crash schedule; snapshot hashes; root/balance diffs; recovery timing. + +OPS-05 BLOCKER / P01; P09 / NOT RUN + +Isolate untrusted proving workloads +Setup. Run hostile test jobs with secret canaries and restrictive worker permissions. +1. Attempt filesystem escape, process spawning, resource exhaustion, network access and key-store reads. +2. Crash workers and inspect host, wallet and node availability plus dump/log contents. 3. Retry on every +supported isolation backend and check dependency vulnerability handling. +Pass. No secret leakage or unauthorised host action; P09 resource containment holds. Worker failure does +not compromise validator/wallet authority; unsupported isolation is not marketed as safe execution. +Evidence. Sandbox penetration report; canary logs; resource limits; host-integrity checks. + +OPS-06 BLOCKER / P01; P09 / NOT RUN + +Contain malicious network and API traffic +Setup. Use an authorised isolated load environment with declared resource and request-rate budgets. +1. Send malformed headers, proofs, oversized messages, floods and invalid peer sequences. 2. Measure +legitimate traffic, memory/disk growth and validator CPU use. 3. Test limit resets, peer reconnect and +graceful degradation without disabling validation. +Pass. P09 abuse budgets hold; no unbounded allocation, persistent crash or invalid acceptance. +Backpressure is visible and honest users retain the specified service at admitted load. +Evidence. Load/corpus manifests; resource series; valid-traffic metrics; incident traces. + + + + +Source: 2.0 plan pp. 21, 24, 25, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 55 / 73 + TEST STANDARD / 1.0 + + + + +OPS / OPS-07 TO OPS-08 + + + +Independent operation and release +security +A permissionless specification must remain operational without privileged infrastructure or unsafe +automatic updates. + +Lead: Operations + release leads; independent operators +Fixtures: F4 isolated multi-operator network; F0 signed releases; F9 telemetry +OPS-07 GATE / P09; P10 / NOT RUN + + +Detect failures with usable evidence and runbooks +Setup. Define alerts for invalid acceptance, conflicting finality, backlog, data loss, payout mismatch and +stale status. +1. Inject one instance of each monitored failure in the lab. 2. Have an unaffiliated operator diagnose it using +only emitted evidence and published instructions. 3. Test redaction, metric freshness and duplicate-alert +suppression without suppressing serious failures. +Pass. P10 alert/detection limits hold; every blocker produces actionable evidence. Monitoring does not leak +secrets or mislabel intentional safe pauses as successful finality. +Evidence. Alert matrix; detection timelines; independent runbook exercise. + +OPS-08 BLOCKER / P00; P08; P11 / NOT RUN + +Repeat independent operation across releases +Setup. Use a clean previous supported version and the final candidate with independent operators. +1. Perform documented rolling upgrade, rollback of non-consensus software where allowed and +resynchronisation. 2. Cross activation with mixed versions and unavailable founder distribution hosts. 3. +Re-run affected gates after changes and preserve prior failures and incident lessons. +Pass. No undocumented privileged migration or automatic consensus rewrite. All affected evidence is +refreshed; P11 no-rescue results remain tied to the final release, not an earlier build. +Evidence. Upgrade/replay logs; invalidation map; repeated gate signatures. + + + + SUITE CLOSE / OPS + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 21, 24, 25, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 56 / 73 + TEST STANDARD / 1.0 + + + + +UX / UX-01 TO UX-03 + + + +Ember, payouts and operator +control +Successful participation must be practical for ordinary owners without hidden custody or loss of +consensus authority. + +Lead: Desktop product + pool leads; independent usability study +Fixtures: F2 supported desktops; F8 user study; F4 honest/malicious pools +UX-01 GATE / P10 / NOT RUN + + +Onboard ordinary owners on native desktop apps +Setup. Recruit the P10 first-time user cohort across Windows and macOS using supported physical +hardware. +1. Observe install, hardware detection, safety explanation and first accepted work without staff intervention. +2. Record download/data preparation separately as well as complete end-to-end time. 3. Test unsupported +hardware and insufficient memory messaging rather than forcing a failed start. +Pass. P10 completion/time targets hold with no unsafe default or concealed prerequisite. The product is +tested as the actual desktop app, not only a browser preview. +Evidence. Consent-based study records; task timings; failure reasons; compatibility outcomes. + +UX-02 BLOCKER / P01; P10 / NOT RUN + +Make pause, stop and safe tuning reliable +Setup. Run mining/proving on active desktops under contention and safe thermal stress. +1. Use pause, stop, power limit, task selection and emergency local shutdown controls. 2. Crash or restart +the UI while workers run and verify ownership of background processes. 3. Restore the original hardware +settings and test power-saving/low-battery behaviour where supported. +Pass. P10 control latency and safe-state requirements hold. Stopping does not strand an uncontrolled +process; tuning never depends on unsafe settings or silent privilege escalation. +Evidence. Control timings; process/settings audit; restart and safety traces. + +UX-03 BLOCKER / P01; P10; P12 / NOT RUN + +Show net earnings and compatibility honestly +Setup. Use known rewards, fees, energy readings, retries and operator-entered tariffs. +1. Compare mining, internal proof and external proof income with authoritative ledgers. 2. Show gross/net +estimates, measurement boundaries, tariff assumptions and payout status. 3. Test stale data, losses, +negative margins and mining-only versus proving-compatible devices. +Pass. P10 reconciliation limits hold and uncertainty is visible. No guaranteed profits, fabricated fiat price or +inferred proving support; provisional earnings are not shown as settled payments. +Evidence. UI/ledger comparisons; tariff fixtures; stale/negative examples. + + + + +Source: 2.0 plan pp. 14, 21, 25, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 57 / 73 + TEST STANDARD / 1.0 + + + + +UX / UX-04 TO UX-06 + + + +Ember, payouts and operator +control +Successful participation must be practical for ordinary owners without hidden custody or loss of +consensus authority. + +Lead: Desktop product + pool leads; independent usability study +Fixtures: F2 supported desktops; F8 user study; F4 honest/malicious pools +UX-04 BLOCKER / P01; P10 / NOT RUN + + +Pay small operators without hidden custody +Setup. Use ordinary single-card balances and the actual pooling/payment path. +1. Earn, request/receive payment, disconnect and reconnect; include low balances, fees and a pool outage. +2. Attempt redirection, delayed accounting and withdrawal of another user's entitlement. 3. Reconcile +displayed balances with canonical entitlement and actual settlement. +Pass. P10 payout limits hold for the declared small-operator case. No unauthorised custody, redirection or +unexplained loss; thresholds and fees are disclosed rather than masked by larger test balances. +Evidence. Single-card payout ledger; pool failure record; custody/authorisation review. + +UX-05 BLOCKER / P01; P09 / NOT RUN + +Keep voting keys with the miner through pooling +Setup. Use an honest pool and a modified pool that replaces worker identity or voting credentials. +1. Verify the consensus binding from performed work to the miner's retained key. 2. Attempt substitution, +replay and reassignment without the miner's authorisation. 3. Leave the pool and verify retained +voting/finality rights under F0. +Pass. No silent transfer of governance/finality authority. If the protocol cannot establish retained keys, this +requirement fails; a pool-protocol name or user-interface promise does not pass. +Evidence. Work/key binding vectors; malicious-pool attempts; leave-pool authority check. + +UX-06 BLOCKER / P01; P10 / NOT RUN + +Verify actual miner-selected work templates +Setup. Provide a pool interface with declared job-declaration support and independent miner templates. +1. Submit miner-selected valid transaction templates and verify what is actually hashed and accepted. 2. +Have a pool substitute or censor templates and test local verification/fallback. 3. Measure payout and +acceptance consequences without moving authority to the pool. +Pass. The advertised selection control exists in accepted work, not only configuration. Undisclosed +substitution is detected; supported independent operation remains practical under P10. +Evidence. Template commitments; accepted-block evidence; malicious-pool/fallback report. + + + + +Source: 2.0 plan pp. 14, 21, 25, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 58 / 73 + TEST STANDARD / 1.0 + + + + +UX / UX-07 TO UX-08 + + + +Ember, payouts and operator +control +Successful participation must be practical for ordinary owners without hidden custody or loss of +consensus authority. + +Lead: Desktop product + pool leads; independent usability study +Fixtures: F2 supported desktops; F8 user study; F4 honest/malicious pools +UX-07 BLOCKER / P09; P10 / NOT RUN + + +Expose actionable failures and safe updates +Setup. Create failed proofs, memory pressure, expired jobs, missing payouts and available software +updates. +1. Ask independent users to identify the issue, stop safely and follow the recommended action. 2. Test +explicit update approval, version visibility and a failed/corrupt update. 3. Confirm diagnostic exports remove +keys and private inputs while retaining useful evidence. +Pass. P10 task-success requirements hold; no silent update or false success state. Recovery instructions +work on supported desktops and secret canaries never enter exported logs. +Evidence. Observed tasks; update traces; sanitised export tests. + +UX-08 GATE / P02; P10 / NOT RUN + +Publish competitive accessible software +Setup. Provide open documented builds, tuning parameters and known fee conditions for all supported +platforms. +1. Compare Ember against independently optimised permissible implementations on identical work. 2. +Measure efficiency, fees, false rejection, installation and update transparency. 3. Scan for hidden developer +fees, hardware whitelists, per-address privilege or undisclosed remote controls. +Pass. P10 relative-efficiency limits hold and all fees/privileges are explicit. No self-reported device tier +earns consensus advantage. A superior external implementation triggers investigation, not selective +exclusion. +Evidence. Matched software comparison; code/config review; fee/privilege inventory. + + + + SUITE CLOSE / UX + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 14, 21, 25, 26. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 59 / 73 + TEST STANDARD / 1.0 + + + + +COM / COM-01 TO COM-03 + + + +Paid demand and sustainable +delivery +Devnet payouts and subsidised pilots demonstrate mechanics, not independent willingness to pay. + +Lead: Commercial lead + independent financial/customer reviewer +Fixtures: F8 real consenting customers; F7 full service costs; private identity proofs +COM-01 GATE / P07; P14 / NOT RUN + + +Deliver a genuine contracted proof pilot +Setup. Select one real external customer with a meaningful fixed workload and no required migration to +Igneum. +1. Agree program, inputs, proof format, deadline, price, failure/refund policy and verification method. 2. Run +paid jobs through ordinary independently operated infrastructure. 3. Have the customer verify usefulness, +correctness and its reason for choosing the service. +Pass. The pilot satisfies its actual contract and settles genuine external payment. Trial subsidies are +disclosed and cannot satisfy the repeat-demand gate; no invented customer or testimonial. +Evidence. Redacted contract; verified jobs; settlement proof; consented customer confirmation. + +COM-02 GATE / P14 / NOT RUN + +Establish independent repeat purchasing +Setup. Use the P14 multi-customer observation period and ownership/conflict checks. +1. Track paid purchases on distinct occasions, including refunds and stopped customers. 2. Audit related +parties, project reimbursements, token grants and circular funding. 3. Reconcile external cash received with +correctly delivered meaningful work. +Pass. P14 buyer, duration and volume minima are met without reimbursement or related-party substitution. +Repeat orders are separate buying decisions, not a single payment split into many jobs. +Evidence. Anonymised buyer ledger; repeat-order dates; conflict review; net receipts. + +COM-03 GATE / P12; P14 / NOT RUN + +Demonstrate service and operator margins +Setup. Allocate all delivery costs, including aggregation, retries, hardware, power, host, network and +support. +1. Calculate gross contribution and fully loaded unit costs for each contracted workload. 2. Reconcile a +representative operator's realised earnings against metered costs and opportunity cost. 3. Repeat under the +declared demand and price sensitivities. +Pass. P14 contribution targets hold and at least the required operator cohort has positive realised +contribution. Excluded overhead is visible; token appreciation or unpriced founder labour cannot silently +create profitability. +Evidence. Unit-economics ledger; metered operator sample; allocation rules; sensitivity report. + + + + +Source: 2.0 plan pp. 4, 17, 18, 24, 26, 27, 31, 32, 33. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 60 / 73 + TEST STANDARD / 1.0 + + + + +COM / COM-04 TO COM-06 + + + +Paid demand and sustainable +delivery +Devnet payouts and subsidised pilots demonstrate mechanics, not independent willingness to pay. + +Lead: Commercial lead + independent financial/customer reviewer +Fixtures: F8 real consenting customers; F7 full service costs; private identity proofs +COM-04 BLOCKER / P01; P07; P14 / NOT RUN + + +Meet the customer service guarantee +Setup. Observe actual delivery deadlines, validity, failure handling and support over the contracted period. +1. Count all accepted jobs, including failed, retried and abandoned cases. 2. Have the customer +independently verify results and invoke one authorised refund/failure exercise. 3. Compare offered capacity +and quoted price with what was actually delivered. +Pass. P07 and contracted obligations hold; validity has zero accepted exceptions. Failure terms are +honoured, and demand beyond capacity is explicitly refused rather than quietly omitted from metrics. +Evidence. Customer-verifier records; SLO report; refunds; promised-versus-delivered comparison. + +COM-05 GATE / P14; P15 / NOT RUN + +Compare against the buyer's real alternative +Setup. Identify a credible alternative supplier or in-house option for the same workload, proof format and +security. +1. Obtain comparable quotes or consented measured trials at the evaluation date. 2. Include integration, +verification, deadlines and all operational costs, not only proof-generation time. 3. Document the customer's +actual trade-off without inventing unavailable comparator evidence. +Pass. P15 commercial comparison is satisfied with like-for-like scope and a evidenced purchase reason. +Missing alternative data remains MISSING; it is not scored as an Igneum win. +Evidence. Dated comparison; workload/security match; customer decision record. + +COM-06 GATE / P14 / NOT RUN + +Retain buyers after the pilot and subsidy period +Setup. Follow all recruited customers through the P14 observation period, including churn. +1. Remove disclosed trial incentives before measuring repeat demand. 2. Track renewal, expansion, +cancellation reasons, unresolved incidents and buyer concentration. 3. Review whether one affiliated or +subsidised buyer dominates the apparent market. +Pass. P14 repeat/concentration conditions hold with honest denominator and churn reporting. Paying +demand survives beyond a demonstration; unsatisfied or departed buyers are not removed retrospectively. +Evidence. Cohort/renewal ledger; churn notes; concentration and incentive report. + + + + +Source: 2.0 plan pp. 4, 17, 18, 24, 26, 27, 31, 32, 33. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 61 / 73 + TEST STANDARD / 1.0 + + + + +COM / COM-07 TO COM-08 + + + +Paid demand and sustainable +delivery +Devnet payouts and subsidised pilots demonstrate mechanics, not independent willingness to pay. + +Lead: Commercial lead + independent financial/customer reviewer +Fixtures: F8 real consenting customers; F7 full service costs; private identity proofs +COM-07 GATE / P13 / NOT RUN + + +Fund maintenance without assumed appreciation +Setup. Prepare a costed plan for development, review, infrastructure, support and incident response. +1. Separate committed resources from revenue dependent on adoption or token price. 2. Stress lower +income and an unexpected security/operations expense. 3. Verify responsible owners and continuity +arrangements without changing fair-launch promises. +Pass. P13 committed-runway requirement holds and downside responses are documented. No +uncommitted financing, rising token price or burn accounting is presented as available maintenance funding. +Evidence. Budget and commitment evidence; downside plan; owner/continuity roster. + +COM-08 GATE / P09; P14 / NOT RUN + +Let independent developers build useful integrations +Setup. Recruit unaffiliated developers unfamiliar with unpublished implementation details. +1. Use public docs to deploy a supported application or integrate an external proof request and verification +flow. 2. Record time, undocumented dependencies, workarounds and correctness issues. 3. Retest after +documentation fixes without founder-written hidden integration code. +Pass. P14 developer-task minimum passes on the final release; all required public instructions exist. +Successful bytecode deployment alone does not count as a working application or service integration. +Evidence. Consented developer logs; public examples; issue closure; verified end-to-end journeys. + + + + SUITE CLOSE / COM + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 4, 17, 18, 24, 26, 27, 31, 32, 33. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 62 / 73 + TEST STANDARD / 1.0 + + + + +LEAD / LEAD-01 TO LEAD-03 + + + +Comparative leadership evidence +A serious contention claim requires comparative outcomes and real adoption evidence, not just an +internally green test dashboard. + +Lead: Independent assessment panel + product/economics reviewers +Fixtures: F8 peer/customer studies; full signed technical evidence; 90-day observation +LEAD-01 GATE / P15 / NOT RUN + + +Register a fair contemporary comparison +Setup. Choose at least the P15 peer coverage and an evaluation date before collecting confirmatory results. +1. Include the plan's Ravencoin, Ergo and Firo reference set where comparable, then check for other +relevant current options. 2. Freeze versions, supported hardware, methods, noninferiority margins and +commercial alternatives. 3. Publish exclusions and prohibit cross-algorithm raw-hashrate comparisons. +Pass. The protocol covers material alternatives fairly and is signed independently. A missing or +non-comparable feature is not scored zero; no arbitrary universal rank is inferred from selected metrics. +Evidence. Timestamped peer protocol; source/version records; comparison/exclusion rationale. + +LEAD-02 GATE / P02; P10; P15 / NOT RUN + +Demonstrate comparable operator advantages +Setup. Use matched user tasks and operating conditions on the selected GPU-first networks. +1. Measure install-to-first-accepted-work, software overhead versus each network's tuned baseline, payout +friction and retained control. 2. Measure rejection/availability under the same network conditions; report +fees separately. 3. Use blinded analysis where possible and independent runs for decisive differences. +Pass. P15 noninferiority and superiority requirements hold on meaningful comparable dimensions. No raw +hashes from different algorithms are compared, and transient token price is not labelled engineering +superiority. +Evidence. Matched task data; uncertainty/effect sizes; independent comparison report. + +LEAD-03 GATE / P04; P12; P15 / NOT RUN + +Substantiate the specialist-coexistence claim +Setup. Assemble G1-G4 plus frozen rules and all surviving-adversary assumptions. +1. Have independent reviewers trace each public competitiveness statement to its narrowest evidence. 2. +Separate measured GPUs, modelled silicon and economic scenarios in all summaries. 3. Evaluate residual +uncertainty, excluded technologies and the no-new-rules counterfactual. +Pass. All claimed envelopes meet P04/P12 without unsupported universal bounds. Reviewers agree the +evidence supports scoped commodity competitiveness even when chips remain compatible; an exact +chip-arrival probability is not inferred. +Evidence. Claim-to-evidence map; signed envelope review; limitations statement. + + + + +Source: 2.0 plan pp. 4, 22, 25, 27, 31, 32, 33. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 63 / 73 + TEST STANDARD / 1.0 + + + + +LEAD / LEAD-04 TO LEAD-06 + + + +Comparative leadership evidence +A serious contention claim requires comparative outcomes and real adoption evidence, not just an +internally green test dashboard. + +Lead: Independent assessment panel + product/economics reviewers +Fixtures: F8 peer/customer studies; full signed technical evidence; 90-day observation +LEAD-04 GATE / P12; P16 / NOT RUN + + +Observe ordinary-operator retention and margins +Setup. Recruit the P16 independent cohort before observing results; use privacy-preserving evidence. +1. Follow participation, realised margin, hardware changes, failures and reasons for leaving for 90 days. 2. +Report trial incentives separately and include every initial participant in retention denominators. 3. Compare +behaviour with matched alternatives where feasible; disclose absence of an actual downturn. +Pass. P16 retention/margin minima hold with verified independence and no removal of churned users. +Simulated downturns cannot be called observed bear-market retention; historical claims stay limited to the +period measured. +Evidence. Pseudonymous cohort ledger; margin/retention calculations; departure reasons. + +LEAD-05 GATE / P11; P16 / NOT RUN + +Measure control and dependency concentration +Setup. Audit operational control of mining, voting, proving, aggregation, hosting and software distribution +separately. +1. Use opt-in attestations, observed dependencies and independent corroboration; disclose uncertain +common ownership. 2. Compare concentration and provider-removal outcomes to the approved security +and availability assumptions. 3. Check that pooled payments do not hide authority concentration and +hardware vendors are not equated with operators. +Pass. P11/P16 concentration requirements hold within disclosed uncertainty; unidentified control cannot +be counted as independent. No single removable dependency is falsely marketed as decentralised +operation. +Evidence. Control/failure-domain map; uncertainty notes; concentration/removal results. + +LEAD-06 BLOCKER / P01; P16 / NOT RUN + +Complete the reliability observation window +Setup. Observe the final candidate and approved compatible updates for the full P16 real-time period. +1. Measure promised service availability, invalid acceptance, finality safety, payouts and incident impact. 2. +Reconcile external probes, customer records and operator logs, including maintenance and exclusions. 3. +Repeat affected critical tests after every material change; reset observation where comparability breaks. +Pass. P16 availability and safety criteria hold on live observation; no hidden downtime or compressed-time +substitution. This supports the recorded window only, not multi-year operational maturity. +Evidence. 90-day SLO ledger; independent probes; incident reports; change/retest history. + + + + +Source: 2.0 plan pp. 4, 22, 25, 27, 31, 32, 33. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 64 / 73 + TEST STANDARD / 1.0 + + + + +LEAD / LEAD-07 TO LEAD-08 + + + +Comparative leadership evidence +A serious contention claim requires comparative outcomes and real adoption evidence, not just an +internally green test dashboard. + +Lead: Independent assessment panel + product/economics reviewers +Fixtures: F8 peer/customer studies; full signed technical evidence; 90-day observation +LEAD-07 GATE / P00; P15; P16 / NOT RUN + + +Issue an independent contender assessment +Setup. Provide the full evidence packet, commercial results, comparative study and unresolved-limit +register to the panel. +1. Check every mandatory and claimed-option test, source requirement and approved threshold. 2. Require +separate signoffs for hardware/economics, security/operations and customer/operator evidence. 3. +Document dissent and challenge any inference that passing an internal checklist proves number-one rank. +Pass. Every required gate is PASS with no unresolved material challenge, critical/high defect or missing +comparator/customer evidence. The panel supports a credible leadership-contender conclusion within +scope, not a guaranteed rank. +Evidence. Signed assessment; full status index; dissent/limitations; approved claim wording. + +LEAD-08 GATE / P00; P16 / NOT RUN + +Keep leadership claims valid after release +Setup. Define material-change triggers and scheduled reviews before publishing the assessment. +1. Refresh competitor, hardware-cost, demand and security evidence at the P16 cadence. 2. Test a newly +credible specialist, lost customer, major outage and verifier change against invalidation rules. 3. Withdraw or +narrow stale claims promptly while publishing the new evidence status. +Pass. Claims remain dated, scoped and revisable; material contrary evidence reopens the appropriate gate. +The network may remain usable while a leadership claim is suspended. No permanent self-awarded +certification. +Evidence. Review calendar; invalidation drills; versioned public claim register. + + + + SUITE CLOSE / LEAD + + + Confirm the frozen release and P-profiles, all positive/negative controls, complete raw artifacts and + independent review. A missing result is not a pass. Re-run affected cases after relevant changes. + + + +Execution owner: ____________________ Review: ____________________ +Evidence root: _______________________ Decision: NOT RUN + + + + +Source: 2.0 plan pp. 4, 22, 25, 27, 31, 32, 33. Procedures and P-profile thresholds are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 65 / 73 + TEST STANDARD / 1.0 + + + + +APPENDIX A / EVIDENCE CONTRACT + + + +One record for every result. +Use a machine-readable record in addition to the human report. The example below is a schema template, +not a test result. + + + FIELD GROUP REQUIRED CONTENT + + + test_id, run_id, release_manifest_hash, profile_hash, source_commit, binary_hashes, + Identity + time window. + + fixture/workload IDs, seed set, supported hardware/OS/roles, network topology, + Scope + security assumptions. + + Exact adapter/command, operator, environment, steps completed, exclusions, crashes + Execution + and interventions. + + Raw artifacts, units, numerator/denominator, point/interval values, model assumptions + Measures + and failed controls. + + Expected result, observed result, PASS/FAIL/BLOCKED/INCONCLUSIVE/EXCLUDED, + Decision + defects and review scope. + + Independent reviewer identity/conflicts, signature, approved evidence hashes and + Approval + expiry/invalidation triggers. + + +Example record +{ + "test_id": "ZKP-01", + "run_id": null, + "release_manifest_hash": null, + "profile_hash": null, + "status": "NOT RUN", + "observed": null, + "artifacts": [], + "defects": [], + "independent_review": null +} + + + PUBLISH SAFELY + + + Public summaries should carry hashes, methods and redacted outcomes. Keep customer contracts, + personal identities, secret keys and private inputs out of public artifacts. Qualified reviewers can + inspect protected originals with consent. + + + + +Basis: 2.0 plan pp. 5 and 25. Record fields and schema are proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 66 / 73 + TEST STANDARD / 1.0 + + + + +APPENDIX B / DEFECT AND RETEST POLICY + + + +Failure must change the decision. +No waiver converts a violated core safety or competitiveness criterion into a pass. + + + CLASS RESPONSE CLOSURE + + + Stop/isolate. Protect keys/funds, preserve Independent root-cause review, fix and + Critical + artifacts, suspend affected claims. complete affected gate rerun. + + Block release/claim. Assign accountable owner Independent retest plus regression + High + and containment. case and dependency review. + + Track with owner and deadline. Do not ignore Documented remediation or scoped + Medium/low + violations of a named pass criterion. non-blocking risk acceptance. + + New hypothesis or source-plan + Keep raw negative result. Do not call a + Research failure revision, re-freeze and confirmatory + completed experiment an improved candidate. + retest. + + BLOCKED or INCONCLUSIVE. No silent zero or Obtain required evidence and reviewer; + Missing evidence + favourable replacement. repeat the affected procedure. + + +Retest dependencies +A generator/dataset change reopens GPU, POW, ADV, ROT, ECO, CAP and relevant commercial cost claims. A +verifier/EVM change reopens EVM, ZKP, CAP, VER, OPS and customer-delivery evidence. A quorum/authority +change reopens FIN, ROT, VER, OPS and the no-rescue assessment. Fee or supply changes reopen INC, ECO, +COM and earnings claims. + +Withdrawal, not retrospective rewriting +If the final claim no longer holds, date the original evidence, publish its limitation and suspend the affected +wording. Do not edit a failed historical run into a success. The network remaining usable and a leadership +claim remaining justified are separate questions. + + NO RANK FROM PASS PERCENTAGE + + + 127 of 128 tests passing can still mean not ready. A full scoped pass supports an assessment only + when the difficult hardware, security, economic, commercial and comparative outcomes all hold. + + + + +Basis: 2.0 plan pp. 23-27. Defect workflow is proposed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 67 / 73 + TEST STANDARD / 1.0 + + + + +APPENDIX C / INDEPENDENT SIGN-OFF + + + +The release decision sheet. +Complete this sheet only after the applicable evidence packets exist. The blank state is deliberate. + + + DECISION ITEM INITIAL STATUS REVIEW / EVIDENCE + + + G0 / source and thresholds NOT RUN Manifest and approval hashes required + + G1 / independent baseline NOT RUN GPU/build packets required + + Matched experiments and negative controls + G2 / improved candidate NOT RUN + required + + Physical/cost envelope and independent + G3 / surviving specialist NOT RUN + challenge required + + Required-world results and failure regions + G4 / five-year coexistence NOT RUN + required + + G5 / no-rescue network NOT RUN Independent real-node exercise required + + Security, proving, EVM, wallet and + Technical readiness NOT RUN + operator-control packets + + Unrelated repeat customers, settlement and unit + Commercial evidence NOT RUN + costs + + Comparative/90-day evidence NOT RUN Peer study, independent retention and reliability + + All above plus scoped independent panel + Contender assessment NOT RUN + conclusion + + +Named approvals to collect +Release/accountable owner: __________________________ +Hardware and economics reviewer: ____________________ +Security and operations reviewer: _____________________ +Customer and operator reviewer: ______________________ +Manifest / evidence root / decision date: ________________ + + PERMITTED CONCLUSION AFTER A FULL PASS + + + The evaluated release supports a credible leadership-contender assessment within the published + hardware, economic, security and observation scope. This is not a guarantee of number-one market + rank or resistance to every future design. + + + + +Basis: 2.0 plan pp. 23-27. All gates remain NOT RUN in this document. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 68 / 73 + TEST STANDARD / 1.0 + + + + +APPENDIX D / PROVENANCE AND PUBLIC WORDING + + + +Scope the claim. Keep the sources. +The source plan is a strategy snapshot. This manual expands it into proposed tests without silently +changing its factual status. + +Source basis +S1. IGNEUM_2.0_Plan.pdf. 37 pages. Strategy edition dated 8 October 2026. All source-page references in +this manual refer to this file. +S2. IGNEUM 2.0.rtf, retained in S1 appendices A/B. Leadership assessment and EVM/zkVM strategy. +B1. Original Igneum brand kit dated 7 October 2026. Logo, obsidian/ember palette, Unbounded and IBM Plex +typography. + +Source PDF SHA-256: +418b3b9f68f96a413872fecb16f8508a40063891c70054c65e92e6e5f5fb70b6 + + +Editorial additions +The 128-case catalogue, P00-P16 profiles, sample sizes, proposed tolerances, evidence schema, gate +workflow and contender-assessment criteria are new acceptance-design proposals. They are not +represented as already approved requirements, current performance, independent audit findings or +externally standardised certification. + +Wording before and after validation + + BEFORE + + + Igneum is designed to keep accessible GPUs competitive even when specialised mining hardware + exists, without depending on emergency anti-chip changes. + + + + AFTER THE SCOPED EVIDENCE PASSES + + + Independent evaluation supports Igneum's commodity-GPU competitiveness against the assessed + adaptable specialist designs, under the published conditions. Technical, commercial and + comparative evidence makes the evaluated release a credible leadership contender. + + + +Leave out guaranteed chip death, a universal silicon-efficiency ceiling, chip-arrival percentages without a calibrated model, +guaranteed profits, automatic privacy, inherited Ethereum security and an unsupported number-one rank. Reassess +whenever material contrary evidence appears. + + + + +Primary basis: supplied 2.0 plan and original source document. No fresh deployment or market audit was performed. + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 69 / 73 + TEST STANDARD / 1.0 + + + + +TEST INDEX / 1 OF 4 + + + +Find a test. +Test IDs are stable. Every entry links to the complete procedure and its acceptance criteria. + +GOV / Release identity and evidence +GOV-01 Freeze the release and its claims 18 +GOV-02 Approve thresholds before results 18 +GOV-03 Reproduce builds outside the founding team 18 +GOV-04 Preserve raw and negative evidence 19 +GOV-05 Prove the test oracle detects broken behaviour 19 +GOV-06 Enforce scope and optional-feature discipline 19 +GOV-07 Independent review and finding closure 20 +GOV-08 Invalidate stale evidence and control public status 20 + + +GPU / Whole-system GPU measurements +GPU-01 Cover the declared commodity population 21 +GPU-02 Reproduce Ember clock-lock savings 21 +GPU-03 Measure the real 64-register GPU cost 21 +GPU-04 Find the memory-clock operating ladder 22 +GPU-05 Test dataset fit and support-horizon costs 22 +GPU-06 Measure accepted work under ordinary connectivity 22 +GPU-07 Survive sustained thermal and power operation 23 +GPU-08 Reproduce the full baseline independently 23 + + +POW / Proof-of-work correctness and coupling +POW-01 Match independent execution across every backend 24 +POW-02 Validate generated programs and index folding 24 +POW-03 Test whether live state is unavoidable 24 +POW-04 Evaluate connected-resource restructuring 25 +POW-05 Prevent amortised cheap winning attempts 25 +POW-06 Bound verifier work and malformed-input cost 25 +POW-07 Constrain any mixed-resource or FP32 branch 26 +POW-08 Keep rejected mechanisms out of the shipped claim 26 + + +ADV / Programmable specialist adversaries +ADV-01 Build a multi-family programmable opponent 27 +ADV-02 Price shared, reduced and reconstructed memory 27 +ADV-03 Attack with data-local and hybrid execution 27 +ADV-04 Measure profitable selective participation 28 +ADV-05 Validate physical and complete-board costs 28 +ADV-06 Separate process advantage from specialisation 28 +ADV-07 Evaluate lifetime without forced obsolescence 29 +ADV-08 Independently challenge the best-cost envelope 29 + + + + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 70 / 73 + TEST STANDARD / 1.0 + + + + +TEST INDEX / 2 OF 4 + + + +Find a test. +Test IDs are stable. Every entry links to the complete procedure and its acceptance criteria. + +ROT / Epochs, seeds and memory transitions +ROT-01 Agree across every hourly boundary 30 +ROT-02 Cross weekly and family boundaries together 30 +ROT-03 Test miner-voted bring-forward governance 30 +ROT-04 Resist seed selection and faster evaluators 31 +ROT-05 Continue or pause correctly when finality stops 31 +ROT-06 Activate datasets without hidden exclusions 31 +ROT-07 Ablate redundant rotation layers 32 +ROT-08 Pass the no-new-rules counterfactual 32 + + +ECO / Five-year coexistence economics +ECO-01 Reconcile complete cost per accepted work 33 +ECO-02 Separate existing-owner and new-entrant viability 33 +ECO-03 Let the specialist keep its sunk development 33 +ECO-04 Model entry, exit and difficulty response 34 +ECO-05 Stress success, contraction and cheap electricity 34 +ECO-06 Fund security and proving as issuance falls 34 +ECO-07 Price memory growth and honest-card displacement 35 +ECO-08 Reproduce and adversarially audit the model 35 + + +EVM / Execution and developer compatibility +EVM-01 Match the selected EVM semantics 36 +EVM-02 Preserve transaction binding and replay protection 36 +EVM-03 Test two-dimensional fees and proving limits 36 +EVM-04 Exercise block context and randomness assumptions 37 +EVM-05 Run representative contract integration journeys 37 +EVM-06 Validate wallets, RPC and indexers 37 +EVM-07 Handle execution denial-of-service workloads 38 +EVM-08 Verify controlled execution and verifier upgrades 38 + + +ZKP / Consensus-enforced proof validity +ZKP-01 Reject missing and invalid proofs 39 +ZKP-02 Bind program, verifier and security parameters 39 +ZKP-03 Bind network, epoch, job and state roots 39 +ZKP-04 Prevent reward and payout substitution 40 +ZKP-05 Make proof payment idempotent across races 40 +ZKP-06 Verify aggregation coverage and completeness 40 +ZKP-07 Review soundness and verifier resource limits 41 +ZKP-08 Preserve authority and audit all acceptance paths 41 + + + + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 71 / 73 + TEST STANDARD / 1.0 + + + + +TEST INDEX / 3 OF 4 + + + +Find a test. +Test IDs are stable. Every entry links to the complete procedure and its acceptance criteria. + +CAP / Sustained proving and delivery +CAP-01 Reproduce the historical consumer-shard result 42 +CAP-02 Prove on the actual mining configuration 42 +CAP-03 Measure the entire request-to-payment path 42 +CAP-04 Sustain meaningful load without queue growth 43 +CAP-05 Overload and recover without false acceptance 43 +CAP-06 Calibrate assignment windows to paid completion 43 +CAP-07 Reassign work when inputs or providers disappear 44 +CAP-08 Deliver customer-verifiable output at scale 44 + + +INC / Rewards, incentives and selfish operators +INC-01 Reconcile issuance, fees, burns and recipients 45 +INC-02 Keep revenue streams and claims separate 45 +INC-03 Let a modified client choose the most profitable task 45 +INC-04 Survive external-demand spikes and token declines 46 +INC-05 Contain job reservation and identity-splitting abuse 46 +INC-06 Test difficulty and timestamp manipulation 46 +INC-07 Resist self-dealing fees and fake proving demand 47 +INC-08 Quantify provider and supplier failure concentration 47 + + +FIN / Consensus safety and recovery +FIN-01 Agree on ordering, work and executed state 48 +FIN-02 Attack finality with split honest populations 48 +FIN-03 Cross authority expiry in a long partition 48 +FIN-04 Stop signing while mining continues 49 +FIN-05 Authenticate voter-set changes and pooled keys 49 +FIN-06 Analyse old-key compromise and long-range histories 49 +FIN-07 Recover deterministically after reconnection and crash 50 +FIN-08 Combine boundaries, faults and adversarial scheduling 50 + + +VER / Wallets, receipts and data availability +VER-01 Authenticate light-client bootstrap 51 +VER-02 Verify evolving authority and execution statements 51 +VER-03 Prove successful payment rather than inclusion 51 +VER-04 Bound cross-chain oracle trust and replay 52 +VER-05 Reconstruct required state without founder storage 52 +VER-06 Detect withholding, corruption and stale data 52 +VER-07 Protect wallet keys, signing and recovery 53 +VER-08 Keep every user-facing state truthful 53 + + + + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 72 / 73 + TEST STANDARD / 1.0 + + + + +TEST INDEX / 4 OF 4 + + + +Find a test. +Test IDs are stable. Every entry links to the complete procedure and its acceptance criteria. + +OPS / Independent operation and release security +OPS-01 Run the complete no-founder exercise 54 +OPS-02 Diversify bootstrap and resist peer isolation 54 +OPS-03 Separate update distribution from consensus authority 54 +OPS-04 Recover nodes from crash and storage damage 55 +OPS-05 Isolate untrusted proving workloads 55 +OPS-06 Contain malicious network and API traffic 55 +OPS-07 Detect failures with usable evidence and runbooks 56 +OPS-08 Repeat independent operation across releases 56 + + +UX / Ember, payouts and operator control +UX-01 Onboard ordinary owners on native desktop apps 57 +UX-02 Make pause, stop and safe tuning reliable 57 +UX-03 Show net earnings and compatibility honestly 57 +UX-04 Pay small operators without hidden custody 58 +UX-05 Keep voting keys with the miner through pooling 58 +UX-06 Verify actual miner-selected work templates 58 +UX-07 Expose actionable failures and safe updates 59 +UX-08 Publish competitive accessible software 59 + + +COM / Paid demand and sustainable delivery +COM-01 Deliver a genuine contracted proof pilot 60 +COM-02 Establish independent repeat purchasing 60 +COM-03 Demonstrate service and operator margins 60 +COM-04 Meet the customer service guarantee 61 +COM-05 Compare against the buyer's real alternative 61 +COM-06 Retain buyers after the pilot and subsidy period 61 +COM-07 Fund maintenance without assumed appreciation 62 +COM-08 Let independent developers build useful integrations 62 + + +LEAD / Comparative leadership evidence +LEAD-01 Register a fair contemporary comparison 63 +LEAD-02 Demonstrate comparable operator advantages 63 +LEAD-03 Substantiate the specialist-coexistence claim 63 +LEAD-04 Observe ordinary-operator retention and margins 64 +LEAD-05 Measure control and dependency concentration 64 +LEAD-06 Complete the reliability observation window 64 +LEAD-07 Issue an independent contender assessment 65 +LEAD-08 Keep leadership claims valid after release 65 + + + + +IGNEUM 2.0 / PROPOSED / NOT EXECUTED 73 / 73 + \ No newline at end of file diff --git a/site/404.html b/site/404.html index 5889e123c..59c8afca0 100644 --- a/site/404.html +++ b/site/404.html @@ -117,7 +117,7 @@ main{flex:1}
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -157,7 +157,7 @@ main{flex:1}
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/acceptance.html b/site/acceptance.html new file mode 100644 index 000000000..64e062b23 --- /dev/null +++ b/site/acceptance.html @@ -0,0 +1,821 @@ + + + + + +Igneum Test and Acceptance Standard: every case, shown as it passes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
Igneum 2.0 acceptance

Test and Acceptance Standard 1.0

Every case of the standard, shown as it is run, in the standard’s own words. A checklist, never a completion score: a gate passes only when every case it depends on has passed.

Basis IGNEUM_2.0_Plan.pdf, 37 pages, 8 October 2026. The standard runs to 73 pages. Registry dated 8 October 2026.

APPROVED AS PROPOSED 8 OCTOBER 2026P13 DEFERREDNOT EXECUTED

Test and Acceptance Standard 1.0: APPROVED AS PROPOSED by the founder, 8 October 2026; P13 (maintenance continuity) DEFERRED; 128 cases: 0 passed under the standard, 0 running with team evidence, 128 not run, 0 deferred

  • 0 pass
  • 0 fail
  • 0 blocked
  • 0 running
  • 128 not run
  • 0 deferred
The gates

Five gates, and the freeze before them.

A gate reads NOT RUN until every case it depends on has run, RUNNING while any is running, BLOCKED if any is blocked, FAIL if any fails, and PASS only when every case passes. No gate is weighted into an average.

G0NOT RUN

Freeze

Release identity

No formal run or public pass before approval.

8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred

  • GOV8 casesNOT RUN
G1NOT RUN

Baseline

D1

No validated hardware claim without reproduction.

16 cases: 0 passed under the standard, 0 running with team evidence, 16 not run, 0 deferred

  • GOV8 casesNOT RUN
  • GPU8 casesNOT RUN
G2NOT RUN

Experiments

D2

No improvement claim from a negative hypothesis.

32 cases: 0 passed under the standard, 0 running with team evidence, 32 not run, 0 deferred

  • GOV8 casesNOT RUN
  • GPU8 casesNOT RUN
  • POW8 casesNOT RUN
  • ROT8 casesNOT RUN
G3NOT RUN

Adversary

D3

No broad resistance claim from one weak design.

16 cases: 0 passed under the standard, 0 running with team evidence, 16 not run, 0 deferred

  • GOV8 casesNOT RUN
  • ADV8 casesNOT RUN
G4NOT RUN

Coexistence

D4

No durability claim based on assumed chip expiry.

24 cases: 0 passed under the standard, 0 running with team evidence, 24 not run, 0 deferred

  • GOV8 casesNOT RUN
  • ECO8 casesNOT RUN
  • INC8 casesNOT RUN
G5NOT RUN

No rescue

D5

No no-rescue claim from a founder-supported demo.

56 cases: 0 passed under the standard, 0 running with team evidence, 56 not run, 0 deferred

  • GOV8 casesNOT RUN
  • ROT8 casesNOT RUN
  • ZKP8 casesNOT RUN
  • INC8 casesNOT RUN
  • FIN8 casesNOT RUN
  • OPS8 casesNOT RUN
  • UX8 casesNOT RUN

The three named gates

NOT RUN

Technical readiness

Execution control

No mainnet-ready claim with missing enforcement or safety.

64 cases: 0 passed under the standard, 0 running with team evidence, 64 not run, 0 deferred

  • GOV8 casesNOT RUN
  • POW8 casesNOT RUN
  • EVM8 casesNOT RUN
  • ZKP8 casesNOT RUN
  • CAP8 casesNOT RUN
  • FIN8 casesNOT RUN
  • VER8 casesNOT RUN
  • UX8 casesNOT RUN
NOT RUN

Commercial evidence

Execution control

Devnet activity is insufficient.

24 cases: 0 passed under the standard, 0 running with team evidence, 24 not run, 0 deferred

  • GOV8 casesNOT RUN
  • CAP8 casesNOT RUN
  • COM8 casesNOT RUN
NOT RUN

Leadership-contender decision

Execution control

Supports a scoped contention assessment, not a guaranteed rank.

128 cases: 0 passed under the standard, 0 running with team evidence, 128 not run, 0 deferred

  • GOV8 casesNOT RUN
  • GPU8 casesNOT RUN
  • POW8 casesNOT RUN
  • ADV8 casesNOT RUN
  • ROT8 casesNOT RUN
  • ECO8 casesNOT RUN
  • EVM8 casesNOT RUN
  • ZKP8 casesNOT RUN
  • CAP8 casesNOT RUN
  • INC8 casesNOT RUN
  • FIN8 casesNOT RUN
  • VER8 casesNOT RUN
  • OPS8 casesNOT RUN
  • UX8 casesNOT RUN
  • COM8 casesNOT RUN
  • LEAD8 casesNOT RUN
01GOV

Release identity and evidence

Prevent a favourable result from being attached to the wrong code, assumptions or public claim.

NOT RUN
Owner
Release lead + independent assurance
Gate
G0 / all gates G0 G1 G2 G3 G4 G5
Fixtures
F0 manifest; F1 source/build archives; F9 evidence vault
Plan pages
5, 21, 23, 25, 26, 27
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
GOV-01Freeze the release and its claimsPriority BLOCKERProfile P00NOT RUNEvidence none yetLast run none yet

Setup

Candidate source, binaries, public documentation and the 2.0 plan are available; no run is yet accepted.

Steps

  1. Record exact commits, binary hashes, dependencies, genesis/network identity, mining class, datasets, execution fork, verifier IDs and fee rules in F0.
  2. Map every promised capability and plan requirement to a test ID; distinguish supported mining, proving and wallet combinations.
  3. Sign the manifest with protocol, product and independent review owners before confirmatory runs.

Accept

Every material rule and claim has an unambiguous version and test. Conflicts or unknown activation rules produce BLOCKED, not an inferred default. Changes create a new manifest and invalidate affected results.

Evidence the case requires

Signed F0; source-to-test map; claim inventory; unresolved-field register.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Release lead + independent assurance
Standard page
18
Plan pages
5, 21, 23, 25, 26, 27
GOV-02Approve thresholds before resultsPriority BLOCKERProfile P00NOT RUNEvidence none yetLast run none yet

Setup

This manual supplies proposed test thresholds, not source-approved protocol parameters.

Steps

  1. Approve or replace every P-profile before confirmatory testing; give each change a rationale and independent approver.
  2. Register hardware cohorts, mandatory economic worlds, customer workloads, peer dimensions and exclusion rules.
  3. Lock the profile hash and hold out seeds/workloads from the developers doing optimisation.

Accept

No decision-critical field is TBD. Numeric limits are frozen, commercially meaningful and not chosen from observed results. A weakened limit after failure requires a new protocol, full affected rerun and explicit claim downgrade review.

Evidence the case requires

Approved profile register; timestamped holdout commitments; change log.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Release lead + independent assurance
Standard page
18
Plan pages
5, 21, 23, 25, 26, 27
GOV-03Reproduce builds outside the founding teamPriority BLOCKERProfile P00, P02NOT RUNEvidence none yetLast run none yet

Setup

Provide public source and documented build instructions to three unaffiliated operators.

Steps

  1. Build on clean declared environments without private files, tokens or founder assistance.
  2. Compare reproducible payload hashes; isolate signatures, notarisation and permitted non-deterministic wrappers.
  3. Run reference vectors and restart a node using only documented artifacts.

Accept

All independent builds reproduce the same consensus payload or an independently explained, pre-approved wrapper difference; reference outputs match exactly. Missing private prerequisites block release.

Evidence the case requires

Build logs; dependency lockfiles; binary comparison; operator attestations.

Method
Independent reproduction
Cadence
Release candidate; repeat after relevant changes
Owner
Release lead + independent assurance
Standard page
18
Plan pages
5, 21, 23, 25, 26, 27
GOV-04Preserve raw and negative evidencePriority BLOCKERProfile P00NOT RUNEvidence none yetLast run none yet

Setup

Enable append-only storage for run outputs and a separate analysis workspace.

Steps

  1. Capture failed, aborted and successful runs with timestamps, seeds and environment hashes.
  2. Recompute one published figure from raw records on a clean machine.
  3. Modify a retained artifact deliberately and test integrity verification.

Accept

Every headline can be regenerated; tampering is detected; exclusions have pre-registered reasons. Failed or missing runs remain visible and are never replaced silently by a successful retry.

Evidence the case requires

Artifact manifest; hashes; reproduction script; exclusion ledger; negative-run archive.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Release lead + independent assurance
Standard page
19
Plan pages
5, 21, 23, 25, 26, 27
GOV-05Prove the test oracle detects broken behaviourPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run none yet

Setup

Create controlled defective variants on an isolated network only.

Steps

  1. Disable proof verification, change one reward, accept an expired authority set and alter one hash output in separate mutants.
  2. Run the corresponding ZKP, INC, FIN and POW tests without telling the runner which mutant is active.
  3. Confirm the baseline still accepts authorised valid cases.

Accept

Every deliberately introduced fault is caught by its mapped test; valid controls pass. Any undetected critical mutant blocks acceptance of that test family until the oracle is repaired.

Evidence the case requires

Mutation catalogue; blinded run results; baseline controls; oracle review.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Release lead + independent assurance
Standard page
19
Plan pages
5, 21, 23, 25, 26, 27
GOV-06Enforce scope and optional-feature disciplinePriority BLOCKERProfile P00NOT RUNEvidence none yetLast run none yet

Setup

Inventory FP32 experiments, receipts/oracles and all retained or excluded mining levers.

Steps

  1. Mark each capability CORE, CLAIMED-OPTIONAL or EXCLUDED before release testing.
  2. For excluded code, check binaries, protocol activation and product copy for accidental enablement or implied availability.
  3. For each claimed option, require the complete associated test set rather than a demonstration.

Accept

Every core and claimed-option obligation passes. Excluded items are shown as EXCLUDED, never PASS and never counted as achievements. Removing a failed core requirement prevents an all-2.0-pass claim.

Evidence the case requires

Scope manifest; activation scan; product-copy comparison; exclusions register.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Release lead + independent assurance
Standard page
19
Plan pages
5, 21, 23, 25, 26, 27
GOV-07Independent review and finding closurePriority BLOCKERProfile P09NOT RUNEvidence none yetLast run none yet

Setup

Nominate reviewers with declared conflicts and scopes covering cryptography, consensus and hardware.

Steps

  1. Provide pinned code, raw data, adversarial models and prior failures, including negative results.
  2. Track each finding to remediation and an independent retest; do not use the author as sole approver.
  3. Have reviewers state unreviewed surfaces and model limitations in their signed conclusions.

Accept

No unresolved critical or high-severity finding affects the claimed release. A finite review is described by scope, not as proof of universal security. Independent reproduction and review are both evidenced.

Evidence the case requires

Signed scoped reports; conflict declarations; finding/retest ledger.

Method
Independent specialist review
Cadence
Release candidate; repeat after relevant changes
Owner
Release lead + independent assurance
Standard page
20
Plan pages
5, 21, 23, 25, 26, 27
GOV-08Invalidate stale evidence and control public statusPriority BLOCKERProfile P00NOT RUNEvidence none yetLast run none yet

Setup

Create a simulated post-test change to a verifier, mining class, dataset and fee rule.

Steps

  1. Calculate affected test dependencies and invalidate their former PASS statuses.
  2. Regenerate public status pages from F0 and the evidence register.
  3. Attempt to publish a rank-one, guaranteed-profit or automatic-chip-death claim without the required evidence.

Accept

Affected gates return to NOT RUN or BLOCKED. Public claims retain version, limits and date; unsupported claims are withheld. No stale result remains attached to a different release.

Evidence the case requires

Dependency impact report; regenerated status page; rejected claim examples.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Release lead + independent assurance
Standard page
20
Plan pages
5, 21, 23, 25, 26, 27
02GPU

Whole-system GPU measurements

Close the pending measurements and evaluate the actual configuration, including costs hidden by kernel-only results.

NOT RUN
Owner
GPU lead + three independent operators
Gate
G1 / G2 G1 G2
Fixtures
F2 retail-hardware cohort; F3 paired benchmark workloads; F9 calibrated evidence
Plan pages
6, 7, 8, 14, 18, 23
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
GPU-01Cover the declared commodity populationPriority GATEProfile P02NOT RUNEvidence none yetLast run none yet

Setup

Freeze the P02 cohort, supported role matrix and the final v6 configuration.

Steps

  1. Inventory physical SKU, usable memory, driver, operating system, firmware, cooling and acquisition channel.
  2. Run mining on every supported cohort cell and proving on every separately advertised prover cell.
  3. Include lower-memory, used-generation and all advertised vendor cases; retain unsupported results separately.

Accept

All declared cells are tested, with no after-the-fact removal of weak cards. At least the P02 minimum coverage is met. Mining-only support is never reported as proof-generation support.

Evidence the case requires

Cohort manifest; compatibility matrix; raw results by SKU and role.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
GPU lead + three independent operators
Standard page
21
Plan pages
6, 7, 8, 14, 18, 23
GPU-02Reproduce Ember clock-lock savingsPriority GATEProfile P02, P03NOT RUNEvidence none yetLast run none yet

Setup

Use paired stock and tuned runs on the same board, host, workload and ambient conditions.

Steps

  1. Warm to stability; randomise stock/tuned order and run P02 repeated sessions.
  2. Measure accepted work, calibrated wall energy, device telemetry and rejected work.
  3. Calculate paired energy and rate changes with run-level uncertainty, retaining failed tuning attempts.

Accept

Tuning preserves correctness and meets approved P03 operating limits. The historical 34-41% saving and under-2% rate-loss statement is reproduced only for qualifying configurations; otherwise that claim is corrected. Existing savings are not counted twice.

Evidence the case requires

Raw power/time series; paired analysis; tuning settings; claim-by-SKU table.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
GPU lead + three independent operators
Standard page
21
Plan pages
6, 7, 8, 14, 18, 23
GPU-03Measure the real 64-register GPU costPriority GATEProfile P02, P03NOT RUNEvidence none yetLast run none yet

Setup

Build the baseline and window variant with identical dataset, reads and semantic workload.

Steps

  1. Inspect compiled register allocation, spills, occupancy and memory traffic on each supported backend.
  2. Measure paired complete-system energy and accepted throughput, including host work.
  3. Repeat during proving coexistence and expose any memory or scheduling cliff.

Accept

Any production window meets P03 budgets for every mandatory SKU; no hidden spills or correctness changes. Zero GPU cost is claimed only where measurement supports it within uncertainty. Results feed the redesigned adversary, not an old core estimate.

Evidence the case requires

Compiler reports; allocation traces; paired energy/rate data; coexistence runs.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
GPU lead + three independent operators
Standard page
21
Plan pages
6, 7, 8, 14, 18, 23
GPU-04Find the memory-clock operating ladderPriority BLOCKERProfile P01, P02NOT RUNEvidence none yetLast run none yet

Setup

Use safe vendor-supported settings only; record operator permission and original settings.

Steps

  1. Sweep approved core and memory operating points while holding workload constant.
  2. Measure error rate, accepted throughput, wall energy and thermal equilibrium.
  3. Repeat the selected knee after reboot and restore defaults after a failed or interrupted tuning session.

Accept

Selected profiles are stable, reproducible and not dependent on unsafe clocks. Every accepted hash remains correct; saved settings restore predictably. Tuning failure leaves a working safe configuration.

Evidence the case requires

Clock ladder; safe bounds; thermal/error logs; reboot and rollback record.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
GPU lead + three independent operators
Standard page
22
Plan pages
6, 7, 8, 14, 18, 23
GPU-05Test dataset fit and support-horizon costsPriority BLOCKERProfile P01, P02, P06NOT RUNEvidence none yetLast run none yet

Setup

Test 5.5, 8.5 and 11.5 GiB only as source-proposed candidates; F0 determines activated sizes.

Steps

  1. Measure allocation plus driver, display, prover and OS headroom on the 8 GB and other cohort tiers.
  2. Run near-full-memory, fragmentation, restart and next-epoch construction scenarios.
  3. Compare time-sharing/eviction with concurrent mining/proving, including reload cost.

Accept

Every advertised combination completes without OOM or silent corruption. Unsupported future sizes are identified before activation. GPU exclusions and lost proving capacity appear in ECO evaluation; retirement of a tier is not a success metric.

Evidence the case requires

Memory budget per SKU; OOM traces; support horizon; concurrency cost table.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
GPU lead + three independent operators
Standard page
22
Plan pages
6, 7, 8, 14, 18, 23
GPU-06Measure accepted work under ordinary connectivityPriority GATEProfile P02, P10NOT RUNEvidence none yetLast run none yet

Setup

Use the same hardware against clean, delayed, lossy and intermittent links in F4.

Steps

  1. Measure kernel rate and accepted work separately under home and datacentre link profiles.
  2. Include reconnects, template changes, expired submissions and pool failover.
  3. Attribute loss to network, local software, validation and protocol causes.

Accept

Results use accepted work, never kernel rate alone. Ordinary-link incremental rejection stays within P10; all losses remain priced in ECO. Unreachable links may pause but must not claim paid work.

Evidence the case requires

Per-submission ledger; network trace; rejection reasons; accepted-work comparison.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
GPU lead + three independent operators
Standard page
22
Plan pages
6, 7, 8, 14, 18, 23
GPU-07Survive sustained thermal and power operationPriority BLOCKERProfile P01, P02, P10NOT RUNEvidence none yetLast run none yet

Setup

Run the selected profile on actual reference machines for the P02 soak period.

Steps

  1. Track wall power, temperatures, clocks, memory and accepted work continuously.
  2. Inject safe power interruptions, process restarts and normal competing desktop load.
  3. Check restored settings and compare late-run efficiency with the first stable period.

Accept

No invalid work or unsafe persistent settings; P02/P10 stability limits hold. Thermal throttling, crashes and recovery time remain in throughput and energy denominators. A crash-free short benchmark cannot substitute for the soak.

Evidence the case requires

Seven-day time series; crash reports; settings-restoration checks; drift analysis.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
GPU lead + three independent operators
Standard page
23
Plan pages
6, 7, 8, 14, 18, 23
GPU-08Reproduce the full baseline independentlyPriority GATEProfile P02NOT RUNEvidence none yetLast run none yet

Setup

Three unaffiliated operators receive F0, F2 and F3, including the final miner/prover build.

Steps

  1. Repeat identical-SKU paired runs with documented meter calibration and environment differences.
  2. Recompute joules and total cost per accepted work from the shared raw schema.
  3. Investigate divergence before accepting a pooled headline or uncertainty band.

Accept

Reproductions meet P02 tolerance and exact correctness. No unexplained divergence or selectively missing low-end cell remains. Report manufactured GPU measurements separately from modelled specialist estimates.

Evidence the case requires

Three signed reproduction packs; reconciliation report; final baseline table.

Method
Independent reproduction
Cadence
Release candidate; repeat after relevant changes
Owner
GPU lead + three independent operators
Standard page
23
Plan pages
6, 7, 8, 14, 18, 23
03POW

Proof-of-work correctness and coupling

Find semantic disagreements and structural shortcuts before treating a harder-looking program as a stronger defence.

NOT RUN
Owner
Cryptography + GPU lead
Gate
G2 / technical readiness G2
Fixtures
F0 rule set; F3 independent CPU/GPU oracles; F5 mutation corpus
Plan pages
7, 9, 10, 23
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
POW-01Match independent execution across every backendPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run none yet

Setup

Implement an independently written reference evaluator, not a wrapper around the production GPU path.

Steps

  1. Execute the P01 corpus across every family, boundary seed and supported backend.
  2. Exercise zero, maximum, sign, shift, rotate, overflow and unaligned-address cases allowed by the spec.
  3. Minimise every mismatch and rerun it on clean builds.

Accept

Bit-for-bit agreement for all valid cases and identical rejection for invalid cases. One unexplained mismatch is a blocker. Large sample counts are evidence of testing, not proof that unseen disagreements cannot exist.

Evidence the case requires

Reference implementation review; seeds/vectors; backend matrix; mismatch archive.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Cryptography + GPU lead
Standard page
24
Plan pages
7, 9, 10, 23
POW-02Validate generated programs and index foldingPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run none yet

Setup

Use the frozen grammar, opcode semantics and index-fold rule; include boundary and malformed programs.

Steps

  1. Enumerate small constrained programs and fuzz the full generator at P01 depth.
  2. Check bounds, valid dependencies, address distribution and forbidden encodings.
  3. Compare source-level operations with optimised compiled code for removed or altered work.

Accept

No accepted program violates semantics, termination or memory bounds. Distribution claims have predeclared tests and effect-size limits; passing randomness checks is not treated as a cryptographic proof.

Evidence the case requires

Generator/fuzzer logs; reduced counterexamples; disassembly comparison; index tests.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Cryptography + GPU lead
Standard page
24
Plan pages
7, 9, 10, 23
POW-03Test whether live state is unavoidablePriority GATEProfile P03, P04NOT RUNEvidence none yetLast run none yet

Setup

Take the 64-register candidate and the cheapest independently proposed storage organisations.

Steps

  1. Trace value liveness across dependent reads and final output, distinguishing distinct information from duplicated values.
  2. Try banking, compression, recomputation, fewer ports and time-multiplexed contexts.
  3. Quantify the best complete-system cost/throughput trade-off rather than the reference register count.

Accept

Production selection is supported by measured or physically modelled penalties after these alternatives. G2 requires the P03 improvement; an attractive source-level register count alone does not pass.

Evidence the case requires

Liveness traces; alternative implementations; Pareto table; reviewer analysis.

Method
Experiment + independent hardware review
Cadence
Release candidate; repeat after relevant changes
Owner
Cryptography + GPU lead
Standard page
24
Plan pages
7, 9, 10, 23
POW-04Evaluate connected-resource restructuringPriority GATEProfile P03, P04NOT RUNEvidence none yetLast run none yet

Setup

Use a candidate initially matched to baseline instruction count, read count and dataset size.

Steps

  1. Connect state, addresses, arithmetic and lane communication according to the written hypothesis.
  2. Measure GPU cost and allow the specialist reviewer to redesign the entire core.
  3. Repeat on held-out program seeds and compare the worst supported adversary, not only the original design.

Accept

The selected upgrade meets P03 and improves the adversarial result outside declared uncertainty. A negative experiment remains a negative outcome; adopting a different design requires a new frozen comparison.

Evidence the case requires

Matched workloads; GPU runs; redesigned core estimates; held-out results.

Method
Controlled experiment
Cadence
Release candidate; repeat after relevant changes
Owner
Cryptography + GPU lead
Standard page
25
Plan pages
7, 9, 10, 23
POW-05Prevent amortised cheap winning attemptsPriority BLOCKERProfile P01, P04NOT RUNEvidence none yetLast run none yet

Setup

Prepare valid templates, nonces, intermediate-state captures and independent acceptance checks.

Steps

  1. Vary nonce, payout identity, transactions, roots and other committed fields after expensive work.
  2. Try replay, precomputation, shared prefixes, partial evaluation and many cheap suffix candidates.
  3. Price any valid strategy against fresh evaluation; independently review all bindings.

Accept

Invalid modifications are rejected. Any valid cost-saving strategy is incorporated into ADV and must still meet P04/ECO gates. No unresolved shortcut is hidden behind passing reference vectors.

Evidence the case requires

Attack implementations; valid/invalid controls; work-cost analysis; binding review.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Cryptography + GPU lead
Standard page
25
Plan pages
7, 9, 10, 23
POW-06Bound verifier work and malformed-input costPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Use ordinary CPU validators with a manifest-defined resource budget and untrusted submissions.

Steps

  1. Submit shortest/longest programs, malformed encodings and adversarial memory references.
  2. Measure verification time, peak memory and work amplification across valid and invalid inputs.
  3. Sustain the approved hostile request rate while ordinary valid traffic continues.

Accept

All semantics remain correct and P09 resource budgets hold. Invalid traffic cannot cause unbounded allocation, crashes or disproportionate free work. Rate limits must not replace consensus validation.

Evidence the case requires

CPU profiles; adversarial corpus; allocation traces; valid-traffic latency.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Cryptography + GPU lead
Standard page
25
Plan pages
7, 9, 10, 23
POW-07Constrain any mixed-resource or FP32 branchPriority BLOCKERProfile P00, P01, P03NOT RUNEvidence none yetLast run none yet

Setup

If this branch is excluded, verify that it is unreachable and not claimed; if included, use a separate frozen candidate.

Steps

  1. Specify exact rounding, fusion, special values and backend behaviour before compiling.
  2. Differentially test all supported architectures and allow numerical-domain simplification in the specialist model.
  3. Include verifier cost and candidate energy in P03/P04, not just arithmetic-unit area.

Accept

Included branches achieve exact agreed semantics and all hardware budgets. An excluded branch earns no performance credit. No approximate operation or unspecified compiler choice enters consensus.

Evidence the case requires

Scope decision; semantic specification; vectors; simplified datapath model.

Method
Conditional implementation test
Cadence
Release candidate; repeat after relevant changes
Owner
Cryptography + GPU lead
Standard page
26
Plan pages
7, 9, 10, 23
POW-08Keep rejected mechanisms out of the shipped claimPriority GATEProfile P00, P03NOT RUNEvidence none yetLast run none yet

Setup

Inventory long programs, select trees, SM gating, wider reads, sealed classes, random epoch lengths, per-tier scoring and VRF draws.

Steps

  1. Retain their historic negative tests and realistic SRAM instruction-memory control.
  2. Inspect the release for reintroduction through renamed settings or hidden paths.
  3. Require a new written hypothesis and complete adversarial retest for any proposed return.

Accept

Excluded levers remain excluded unless separately approved and retested. Flip-flop instruction-memory area is never presented as the cost of a realistic SRAM implementation.

Evidence the case requires

Decision register; binary/config scan; negative-control results.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Cryptography + GPU lead
Standard page
26
Plan pages
7, 9, 10, 23
04ADV

Programmable specialist adversaries

Give the opponent permission to adapt, share resources and remain operational; test cost rather than imagined chip death.

NOT RUN
Owner
Independent hardware team
Gate
G3 G3
Fixtures
F2 reference GPUs; F6 RTL/physical models; all published families
Plan pages
8, 10, 12, 22, 23
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
ADV-01Build a multi-family programmable opponentPriority GATEProfile P01, P04NOT RUNEvidence none yetLast run none yet

Setup

Provide the complete published family bank and future known parameter schedule to the reviewer.

Steps

  1. Design one programmable architecture that supports all retained families, including firmware and emulation paths.
  2. Optimise clocks, lanes, ports and pipelines without requiring a graphics-card layout.
  3. Verify its outputs against POW vectors before measuring any advantage.

Accept

At least the P04 design diversity is evaluated; every estimated competitive design is functionally validated. Inability of one narrow design to adapt is not evidence that all chips expire.

Evidence the case requires

Architecture reports; functional simulations; adaptation matrix; reviewer signature.

Method
Independent hardware study
Cadence
Release candidate; repeat after relevant changes
Owner
Independent hardware team
Standard page
27
Plan pages
8, 10, 12, 22, 23
ADV-02Price shared, reduced and reconstructed memoryPriority GATEProfile P04NOT RUNEvidence none yetLast run none yet

Setup

Allow multiple engines to share a dataset and to store selected fractions rather than a complete per-engine copy.

Steps

  1. Sweep sharing factors, memory fractions, caches and recomputation depth across many simultaneous hashes.
  2. Include construction/update amortisation, bandwidth contention and retained state.
  3. Take the most favourable feasible point for the specialist into the complete-board model.

Accept

No omitted feasible trade-off materially lowers the accepted cost estimate. Any winning alternative is included in P04 and ECO; capacity alone is not accepted as an energy bound.

Evidence the case requires

Sweep definitions; energy/bandwidth data; best-feasible envelope; excluded-design reasons.

Method
Model + adversarial implementation
Cadence
Release candidate; repeat after relevant changes
Owner
Independent hardware team
Standard page
27
Plan pages
8, 10, 12, 22, 23
ADV-03Attack with data-local and hybrid executionPriority GATEProfile P04NOT RUNEvidence none yetLast run none yet

Setup

Permit distributed memories, state migration and companion CPU/GPU/FPGA components.

Steps

  1. Compare moving computation, intermediate state or fetched data to each read location.
  2. Test specialised mining alongside outsourced proof generation rather than assuming one physical GPU does both.
  3. Include interconnect, host, synchronisation, idle and conversion costs.

Accept

The cheapest feasible combined system is included in the adversarial envelope and economic model. A worker identity or account is never treated as proof of a single physical device.

Evidence the case requires

Hybrid architecture diagrams; traffic traces; system cost and energy ledger.

Method
Independent system modelling
Cadence
Release candidate; repeat after relevant changes
Owner
Independent hardware team
Standard page
27
Plan pages
8, 10, 12, 22, 23
ADV-04Measure profitable selective participationPriority GATEProfile P04, P12NOT RUNEvidence none yetLast run none yet

Setup

Use all declared families plus held-out generated programs and the protocol difficulty rule.

Steps

  1. Identify favourable execution paths and add cheap fallbacks for other periods.
  2. Simulate entry/exit around profitable periods, including idle time, compilation and re-entry costs.
  3. Evaluate revenue and costs across the full schedule, not just average program energy.

Accept

Intermittent specialists meet P04/ECO limits when evaluated on full-period economics. A weak tail cannot be concealed by a favourable mean; known valid shortcuts must be priced.

Evidence the case requires

Per-program advantage distribution; policy simulator; full-period returns.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent hardware team
Standard page
28
Plan pages
8, 10, 12, 22, 23
ADV-05Validate physical and complete-board costsPriority GATEProfile P04NOT RUNEvidence none yetLast run none yet

Setup

Use feasible process/library assumptions and documented component boundaries; no fabricated foundry access.

Steps

  1. Model SRAM macros, ports, wiring, clocking, memory PHYs, external memory, host and power conversion.
  2. Run place-and-route where available; mark unmodelled items as uncertainty rather than zero.
  3. Compare against a calibrated existing hardware block or equivalent validation case.

Accept

No decision-critical cost is omitted. Physically unvalidated or proprietary estimates are labelled and independently bounded; synthesis alone cannot earn a manufactured-chip claim.

Evidence the case requires

Netlist/physical reports; macro assumptions; bill of materials; model calibration.

Method
Independent physical-design review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent hardware team
Standard page
28
Plan pages
8, 10, 12, 22, 23
ADV-06Separate process advantage from specialisationPriority GATEProfile P04, P12NOT RUNEvidence none yetLast run none yet

Setup

Evaluate same-node, one-node-ahead and two-node-ahead scenarios with explicit technology definitions.

Steps

  1. Use independently justified process factors, voltages, memory and packaging assumptions for each design.
  2. Allow reusable IP and modular revisions; credit GPU improvement consistently.
  3. Evaluate measurement confidence and model-parameter sensitivity separately.

Accept

P04 primary limits hold for all competitive-reference cells; two-node futures are reported and pass the predeclared economic stress envelope. A model range is never labelled a statistical confidence interval without justification.

Evidence the case requires

Node-specific reports; factor provenance; uncertainty and sensitivity tables.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent hardware team
Standard page
28
Plan pages
8, 10, 12, 22, 23
ADV-07Evaluate lifetime without forced obsolescencePriority GATEProfile P04, P12NOT RUNEvidence none yetLast run none yet

Setup

Assume multi-year productive survival and known schedule support before testing optional retirement penalties.

Steps

  1. Price firmware, emulation, memory expansion, companion hardware and incremental redesign.
  2. Include 1-, 3- and 5-year productive lifetimes plus idle/resale possibilities.
  3. Grant a retirement credit only if all feasible cheaper adaptations lose competitiveness.

Accept

The primary case does not require chip death or a fresh full development bill per family. Every retirement credit has a documented adaptation comparison; incompatible and unprofitable are reported separately.

Evidence the case requires

Lifetime/adaptation ledger; revision costs; feasible-alternative analysis.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent hardware team
Standard page
29
Plan pages
8, 10, 12, 22, 23
ADV-08Independently challenge the best-cost envelopePriority GATEProfile P04NOT RUNEvidence none yetLast run none yet

Setup

Publish the non-sensitive model and negative results; commission an unaffiliated second hardware reviewer.

Steps

  1. Reward cheaper valid designs and reproduced shortcuts, not confirmation of the preferred number.
  2. Re-run P04 with the strongest submitted feasible design, including a low-cost funded-development case.
  3. Record unresolved modelling disagreements and future technology exclusions.

Accept

Both reviews accept the scoped envelope or all material disagreements are resolved transparently. Passing supports only evaluated designs and conditions, never a universal bound on all future silicon.

Evidence the case requires

Two review reports; challenge log; final envelope; unresolved-limit statement.

Method
Independent challenge/review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent hardware team
Standard page
29
Plan pages
8, 10, 12, 22, 23
05ROT

Epochs, seeds and memory transitions

Transitions must agree across nodes and remain usable during failures; crossing a boundary is not a chip-retirement test.

NOT RUN
Owner
Consensus + GPU leads
Gate
G5 / G2 G5 G2
Fixtures
F0 activation rules; F4 fault network; F5 historical and boundary vectors
Plan pages
7, 11, 19, 21
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
ROT-01Agree across every hourly boundaryPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Use real nodes, CPU/GPU miners and independent clocks around successive program boundaries.

Steps

  1. Submit valid work immediately before, at and after the activation boundary under clock skew and delayed delivery.
  2. Restart nodes from both sides and replay the same headers.
  3. Compare selected seed, program, validity, rewards and local wall-clock dependence.

Accept

All honest nodes derive identical consensus outcomes from the frozen rule. Late work is handled exactly as specified; no wall-clock ambiguity or cross-backend split occurs.

Evidence the case requires

Boundary vectors; node/miner traces; acceptance and reward matrix.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus + GPU leads
Standard page
30
Plan pages
7, 11, 19, 21
ROT-02Cross weekly and family boundaries togetherPriority BLOCKERProfile P01, P03, P08NOT RUNEvidence none yetLast run none yet

Setup

Use the retained schedule in F0, including coincident program, parameter and family changes.

Steps

  1. Run every known family transition and all coincident-boundary combinations on production code.
  2. Interrupt downloads, compilation and restart during activation; include mixed old/new clients.
  3. Repeat selected cases under real elapsed time and the remainder under disclosed accelerated time.

Accept

Deterministic activation, documented old-client behaviour and no unsafe fallback. Compilation/setup costs satisfy P03; accelerated runs are not reported as years of operating history.

Evidence the case requires

Transition matrix; code-path evidence; compile timing; old-client logs.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus + GPU leads
Standard page
30
Plan pages
7, 11, 19, 21
ROT-03Test miner-voted bring-forward governancePriority BLOCKERProfile P00, P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Freeze eligibility, threshold, windows and activation semantics before testing; do not invent a no-veto rule.

Steps

  1. Attempt threshold-minus-one, threshold, conflicting proposals, duplicate votes and coalition withholding.
  2. Partition voters, restore them and test vote-key substitution through pools.
  3. Verify adoption and refusal behaviour of already running nodes.

Accept

The actual mechanism enforces F0, with authenticated voting and no conflicting activation. Any coalition capable of blocking or manipulating changes is disclosed; labels such as no veto do not override arithmetic.

Evidence the case requires

Executable governance model; signed-vote corpus; coalition/partition results.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus + GPU leads
Standard page
30
Plan pages
7, 11, 19, 21
ROT-04Resist seed selection and faster evaluatorsPriority BLOCKERProfile P00, P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Provide the specified seed pipeline and delay proof implementation plus independently parameterised fast-adversary models.

Steps

  1. Try withholding candidate seeds, grinding alternatives, replaying delay proofs and biased checkpoint selection.
  2. Vary adversarial speed advantage and outage duration; trace influence on program choice.
  3. Validate inputs, parameters and proofs against independent vectors.

Accept

No invalid seed or proof is accepted; selection advantage stays within the approved threat-model bound. Missing bounds block this gate. A delay mechanism is not credited as generic ASIC resistance.

Evidence the case requires

Seed/grinding simulations; speed sensitivity; proof vectors; threat-model signoff.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus + GPU leads
Standard page
31
Plan pages
7, 11, 19, 21
ROT-05Continue or pause correctly when finality stopsPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Stop checkpoint signing while mining continues, then cross seed and family boundaries.

Steps

  1. Remove the required signing weight and observe the documented fallback or safe pause.
  2. Prevent access to any founder seed service; restart from persisted state.
  3. Restore the stated fault assumptions and verify deterministic recovery.

Accept

Mining/seed behaviour matches F0 without manufacturing certificates or reinterpreting finality. Safety holds during the outage; liveness is required only after its stated assumptions return.

Evidence the case requires

Fault timeline; seed/certificate history; node-state comparison; recovery log.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus + GPU leads
Standard page
31
Plan pages
7, 11, 19, 21
ROT-06Activate datasets without hidden exclusionsPriority BLOCKERProfile P01, P06NOT RUNEvidence none yetLast run none yet

Setup

Freeze memory sizes, support horizon and sync/update procedure; test all advertised roles.

Steps

  1. Construct the next dataset while current work remains active; test slow disks, low free memory and interruption.
  2. Try stale-state/dataset submissions and maliciously expensive state growth where coupling exists.
  3. Measure data transfer, restart and excluded-card costs before approving progression.

Accept

No invalid stale work is accepted, no supported card silently fails, and P06 is met. Hardware retirement and sync burden are included in the economic decision, not treated as automatic chip protection.

Evidence the case requires

Dataset hashes; memory/update traces; stale-work tests; exclusion decision.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus + GPU leads
Standard page
31
Plan pages
7, 11, 19, 21
ROT-07Ablate redundant rotation layersPriority GATEProfile P03, P04NOT RUNEvidence none yetLast run none yet

Setup

Use matched baseline and ablated variants in the lab; do not change a running public network.

Steps

  1. Remove each weekly/family component independently and measure adversarial cost, GPU setup and verifier complexity.
  2. Include favourable-period specialists and all retained known families.
  3. Keep a layer only with a distinct, independently supported benefit or a documented non-resistance purpose.

Accept

Every retained layer has explicit justification and full boundary coverage. Redundant complexity is removed or its rationale recorded; the security model does not double-count the same versatility cost.

Evidence the case requires

Ablation report; decision log; complexity/cost comparison.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus + GPU leads
Standard page
32
Plan pages
7, 11, 19, 21
ROT-08Pass the no-new-rules counterfactualPriority GATEProfile P04, P12NOT RUNEvidence none yetLast run none yet

Setup

Freeze the complete published rule bank and known schedule for the five-year evaluation.

Steps

  1. Allow a programmable adversary to know and survive all planned changes.
  2. Remove assumed future emergency instructions and manual retirement actions from the model.
  3. Run the required ECO scenarios and link them to independent network-transition tests.

Accept

Competitiveness survives the approved envelope without future rescue assumptions. Any result that needs unannounced changes fails this claim; ordinary bug maintenance is distinguished from anti-chip intervention.

Evidence the case requires

Frozen-rule model; scenario results; excluded-rescue audit; G5 evidence.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus + GPU leads
Standard page
32
Plan pages
7, 11, 19, 21
06ECO

Five-year coexistence economics

Test the world after specialised hardware exists, including new entrants and an already-funded competitor.

NOT RUN
Owner
Economics lead + independent reviewer
Gate
G4 G4
Fixtures
F6 adversarial costs; F7 scenario model; F2 operator costs
Plan pages
8, 13, 18, 24, 26
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
ECO-01Reconcile complete cost per accepted workPriority GATEProfile P12NOT RUNEvidence none yetLast run none yet

Setup

Use benchmark outputs, current-source cost inputs recorded at execution time and separate reference scenarios.

Steps

  1. Calculate hardware annualisation, electricity, host, cooling/hosting, failures, fees, downtime and residual value.
  2. Use actual accepted work and independently verify units and period conversions.
  3. Cross-check formulas using hand-worked fixtures, edge cases and a second implementation.

Accept

All material costs and rejected-work effects appear once; model totals reconcile to raw inputs. No GPU upgrade is free, development cost is not double-counted, and burn is not mislabelled operator income.

Evidence the case requires

Versioned model; unit fixtures; independent reconciliation; input sources.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Economics lead + independent reviewer
Standard page
33
Plan pages
8, 13, 18, 24, 26
ECO-02Separate existing-owner and new-entrant viabilityPriority GATEProfile P12NOT RUNEvidence none yetLast run none yet

Setup

Use both installed hardware and purchasable replacement hardware in every mandatory cohort.

Steps

  1. Evaluate marginal operation separately from recovery of a new purchase.
  2. Stress resale at zero, hardware failures, financing and replacement cycles.
  3. Report break-even power price and total cost relative to the strongest feasible specialist.

Accept

P12 competitiveness conditions hold for the predeclared cohorts in required sustainable worlds. Existing-owner profitability cannot substitute for viable new entry; cards outside the envelope remain visible.

Evidence the case requires

Owner/entrant curves; price-date records; break-even tables; cohort outcomes.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Economics lead + independent reviewer
Standard page
33
Plan pages
8, 13, 18, 24, 26
ECO-03Let the specialist keep its sunk developmentPriority GATEProfile P12NOT RUNEvidence none yetLast run none yet

Setup

Use three development cases: fully funded elsewhere, source-range low and source-range high.

Steps

  1. Evaluate private mining, public hardware sales and a hybrid business model.
  2. Allow shared IP, incremental revisions, multi-year survival and resale where justified.
  3. Re-evaluate GPU entry after the specialist fleet is already installed.

Accept

The coexistence claim does not depend on recovering the original chip research bill. Required P12 cases meet the approved envelope even at zero incremental development cost; failures cannot be hidden by the $23M/$340M source thresholds.

Evidence the case requires

Business-model variants; sunk-cost case; full cash-flow and adaptation records.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Economics lead + independent reviewer
Standard page
33
Plan pages
8, 13, 18, 24, 26
ECO-04Model entry, exit and difficulty responsePriority GATEProfile P12NOT RUNEvidence none yetLast run none yet

Setup

Use independently reviewed dynamic operator policies, not fixed market shares.

Steps

  1. Let agents buy, sell, switch off, re-enter and choose tasks based on declared costs and expected income.
  2. Apply the actual difficulty/reward rules and test optimistic and adversarial liquidity/capital availability.
  3. Compare equilibrium and transient outcomes across independent starting conditions.

Accept

Mandatory worlds satisfy P12 without an imposed GPU share or artificial specialist capacity limit. Concentration, oscillations and excluded regions are reported; model behaviour matches unit and conservation checks.

Evidence the case requires

Agent policies; sensitivity seeds; market-share paths; independent model review.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Economics lead + independent reviewer
Standard page
34
Plan pages
8, 13, 18, 24, 26
ECO-05Stress success, contraction and cheap electricityPriority GATEProfile P12NOT RUNEvidence none yetLast run none yet

Setup

Freeze mandatory scenarios before results: revenue bands, tariff range, lifetimes and demand states.

Steps

  1. Run the P12 factorial grid plus adversarial combinations selected by the independent reviewer.
  2. Test a large successful network as well as weak-revenue and heterogeneous-tariff cases.
  3. Distinguish feasible sustained-entry worlds from collapse scenarios with no rational profitable operator.

Accept

No small-network or token-appreciation assumption props up the primary claim. Required viable worlds pass the envelope; collapse worlds show honest contraction and safety, not fabricated profits. Failure regions are explicit.

Evidence the case requires

Scenario register; full result cube; boundary plots; failed-world explanations.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Economics lead + independent reviewer
Standard page
34
Plan pages
8, 13, 18, 24, 26
ECO-06Fund security and proving as issuance fallsPriority GATEProfile P12NOT RUNEvidence none yetLast run none yet

Setup

Use the frozen supply, halving, fee, burn and reward rules rather than source prose assumptions.

Steps

  1. Reconcile revenue reaching miners, internal provers, developers and burns over the full horizon.
  2. Test flat/declining fees and no external proving income; separately introduce external demand.
  3. Calculate capacity and security-provider coverage after each reward transition.

Accept

Recurring compensation is explicit and internally consistent; mandatory sustainable scenarios meet P12. Burned amounts are never counted as payments, and external operator income is not assumed to fund internal work automatically.

Evidence the case requires

Issuance/fee ledger; scenario cash flows; funding-shortfall report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Economics lead + independent reviewer
Standard page
34
Plan pages
8, 13, 18, 24, 26
ECO-07Price memory growth and honest-card displacementPriority GATEProfile P06, P12NOT RUNEvidence none yetLast run none yet

Setup

Use GPU-05 and ROT-06 costs with the cheapest specialist adaptation.

Steps

  1. For each dataset increment, compare specialist cost increases with excluded cards and lost proving capacity.
  2. Include ordinary-owner replacement, resale and reloading expenses.
  3. Run alternate bounded schedules without assigning automatic chip death.

Accept

The retained schedule meets P06/P12 and has an evidence-backed net competitiveness benefit. A schedule that mainly harms accessible GPUs fails; excluded tiers and mitigations are documented before activation.

Evidence the case requires

Per-step cost/retention table; alternative schedules; approval record.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Economics lead + independent reviewer
Standard page
35
Plan pages
8, 13, 18, 24, 26
ECO-08Reproduce and adversarially audit the modelPriority GATEProfile P12NOT RUNEvidence none yetLast run none yet

Setup

Give an independent economist or qualified analyst the code, inputs and frozen success criteria.

Steps

  1. Recalculate required worlds and perturb favourable assumptions against the team.
  2. Check dependence on discounts, utilisation, capital limits, artificial prices and future upgrades.
  3. Publish the sensitivity range and state which conclusions are conditional.

Accept

Material results reproduce, required scenarios pass and no unacknowledged assumption dominates the claim. The model supports a bounded coexistence conclusion, not a percentage probability that no chip will appear.

Evidence the case requires

Independent report; rerun outputs; model limitations; approved claim envelope.

Method
Independent economic review
Cadence
Release candidate; repeat after relevant changes
Owner
Economics lead + independent reviewer
Standard page
35
Plan pages
8, 13, 18, 24, 26
07EVM

Execution and developer compatibility

Keep familiar applications while making every difference and metering rule explicit and reproducible.

NOT RUN
Owner
Execution lead + independent implementer
Gate
Technical readiness
Fixtures
F0 execution-fork semantics; F5 transactions/contracts; F4 multi-node network
Plan pages
15, 25, 34, 35, 36, 37
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
EVM-01Match the selected EVM semanticsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Pin the intended execution fork, revm version and all Igneum deviations in F0.

Steps

  1. Run the applicable upstream execution/state fixtures plus independently written deviation tests.
  2. Execute identical blocks on multiple nodes and compare roots, receipts, logs, gas and failure outcomes.
  3. Minimise mismatches and distinguish intended differences from implementation defects.

Accept

All applicable vectors match; every deviation has a documented test and developer consequence. No claim of universal Ethereum equivalence or Ethereum settlement security is inferred.

Evidence the case requires

Fixture/version inventory; root/receipt diffs; deviation matrix.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Execution lead + independent implementer
Standard page
36
Plan pages
15, 25, 34, 35, 36, 37
EVM-02Preserve transaction binding and replay protectionPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run none yet

Setup

Use signed transfers, contract calls and deployment transactions with boundary field values.

Steps

  1. Alter chain identity, nonce, signature, fee caps and recipient after signing.
  2. Replay across nodes, forks and distinct test networks; resubmit around reorganisation.
  3. Check mempool admission and final consensus execution independently.

Accept

Unauthorised, wrong-network or duplicate spends are rejected according to F0. Valid replacements follow the declared rule; mempool filtering alone is not evidence of consensus enforcement.

Evidence the case requires

Signed corpus; admission/execution outcomes; account-state reconciliation.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Execution lead + independent implementer
Standard page
36
Plan pages
15, 25, 34, 35, 36, 37
EVM-03Test two-dimensional fees and proving limitsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Freeze fee dimensions, estimator rules, abort behaviour and refund policy.

Steps

  1. Run workloads near and beyond execution and proving budgets, including state-heavy pathological cases.
  2. Compare estimated fees with charged fees and validate rollback/receipt status on abort.
  3. Mutate a block producer to omit or undercharge expensive work.

Accept

Deterministic metering, charged amounts and aborted state agree across nodes and proofs. Resource bounds hold; fee estimates meet P09 for accepted supported cases. Undercharged invalid blocks cannot bypass consensus.

Evidence the case requires

Metering traces; fee fixtures; estimator errors; invalid-block rejection.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Execution lead + independent implementer
Standard page
36
Plan pages
15, 25, 34, 35, 36, 37
EVM-04Exercise block context and randomness assumptionsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Use contracts sensitive to timestamp, height/context, randomness and ordering.

Steps

  1. Compare the declared Igneum semantics with developers' documented expectations.
  2. Test boundary transitions, miner-influenced inputs and adversarial ordering in the isolated network.
  3. Run dependency reviews for applications using these values for economic decisions.

Accept

Semantics match F0 and differences are surfaced in compatibility documentation. No source of miner influence is marketed as unbiased randomness; incompatible applications are not included in the compatibility claim.

Evidence the case requires

Context-contract results; threat notes; compatibility exclusions.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Execution lead + independent implementer
Standard page
37
Plan pages
15, 25, 34, 35, 36, 37
EVM-05Run representative contract integration journeysPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Use versioned transfer/token, NFT, multisignature, exchange and upgrade-pattern fixtures where supported.

Steps

  1. Deploy, initialise, transact, revert and upgrade each contract using ordinary tooling.
  2. Exercise events, logs, balances, storage and call traces across node restart/reorganisation.
  3. Compare expected application invariants with native execution and proved results.

Accept

Supported journeys preserve their stated invariants; all deviations are documented. Example deployment success alone cannot stand in for application-level correctness or financial audit.

Evidence the case requires

Contract fixture hashes; transaction journeys; invariant and state comparisons.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Execution lead + independent implementer
Standard page
37
Plan pages
15, 25, 34, 35, 36, 37
EVM-06Validate wallets, RPC and indexersPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Pin supported RPC methods and response semantics; use normal developer clients and an independent indexer.

Steps

  1. Test fee estimation, pending/final states, subscriptions, pagination and reconnects.
  2. Reindex from genesis or the documented trust anchor after pruning and restart.
  3. Compare logs, receipts and balances with independently validated chain state.

Accept

No missing/duplicate canonical records; unsupported methods are explicit. UI states distinguish included, executed, proven and finalised. Malformed RPC input cannot crash validators or leak secrets.

Evidence the case requires

RPC conformance report; reindex comparison; reconnect/edge-case logs.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Execution lead + independent implementer
Standard page
37
Plan pages
15, 25, 34, 35, 36, 37
EVM-07Handle execution denial-of-service workloadsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Create bounded pathological bytecode, calls, state growth, storage and precompile inputs.

Steps

  1. Measure CPU, memory, disk and proving cost against charged budgets.
  2. Saturate admission with invalid/expensive requests while valid workloads continue.
  3. Restart mid-execution and verify atomic state recovery.

Accept

P09 limits hold with no unbounded free work or divergent rollback. State remains consistent after crash; availability under overload follows the declared admission policy, not silent dropping of accepted transactions.

Evidence the case requires

Resource profiles; adversarial corpus; state recovery comparisons.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Execution lead + independent implementer
Standard page
38
Plan pages
15, 25, 34, 35, 36, 37
EVM-08Verify controlled execution and verifier upgradesPriority BLOCKERProfile P01, P08, P09NOT RUNEvidence none yetLast run none yet

Setup

Prepare two authorised versions and malicious, stale or unknown versions.

Steps

  1. Cross activation with mixed clients, queued transactions and proofs from both versions.
  2. Bind each accepted proof to the correct execution semantics and program identity.
  3. Exercise a failed software distribution without altering consensus activation.

Accept

No unknown or wrong-version execution is accepted. Pre/post-boundary handling is deterministic and documented; software delivery cannot silently redefine transaction semantics or proof acceptance.

Evidence the case requires

Upgrade vectors; mixed-version traces; manifest/version bindings.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Execution lead + independent implementer
Standard page
38
Plan pages
15, 25, 34, 35, 36, 37
08ZKP

Consensus-enforced proof validity

The validator, not merely the official producer, must reject unauthorised or invalid proof records and rewards.

NOT RUN
Owner
Proving + protocol leads; independent cryptography review
Gate
Technical readiness / G5 G5
Fixtures
F0 pinned programs/verifiers; F5 valid and hostile proof corpus; unmodified validators
Plan pages
16, 20, 24, 25, 36, 37
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
ZKP-01Reject missing and invalid proofsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Start from a native-correct statement and an independently verified valid proof.

Steps

  1. Submit the statement with no proof, truncated bytes, random bytes and targeted proof mutations using a modified producer.
  2. Submit the genuine proof as a positive control through ordinary network paths.
  3. Inspect block acceptance and resulting reward/state on unmodified validators.

Accept

Every invalid proof record is rejected and earns no reward; valid controls succeed. A producer-side filter is not sufficient. Record rejection semantics exactly as defined by F0.

Evidence the case requires

Hostile record corpus; validator decisions; before/after balances; positive controls.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving + protocol leads; independent cryptography review
Standard page
39
Plan pages
16, 20, 24, 25, 36, 37
ZKP-02Bind program, verifier and security parametersPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Use valid proofs from authorised and unauthorised programs and parameter sets.

Steps

  1. Swap program digest, verifier version, security settings and verification key where applicable.
  2. Attempt downgrade through configuration, serialized metadata or an old node path.
  3. Test authorised boundary transitions and unsupported future identities.

Accept

Only explicitly authorised combinations are accepted in the correct epoch. No implicit trust in producer-supplied metadata or lower-security fallback; all accepted settings have scoped soundness review.

Evidence the case requires

Identity/parameter matrix; rejection traces; cryptographic review.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving + protocol leads; independent cryptography review
Standard page
39
Plan pages
16, 20, 24, 25, 36, 37
ZKP-03Bind network, epoch, job and state rootsPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run none yet

Setup

Prepare valid proofs for distinct chains, epochs, jobs and initial/final states.

Steps

  1. Replay each proof under another network, job, epoch, shard range or state commitment.
  2. Alter public inputs while retaining the proof and test valid-but-wrong-context statements.
  3. Check duplicated and reordered records across forks and replayed sync data.

Accept

Every misbound proof is rejected; valid authorised replays follow only explicitly allowed semantics and never create extra rewards. Native reexecution cannot conceal missing proof-context binding.

Evidence the case requires

Binding matrix; public-input hashes; replay traces; reward reconciliation.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving + protocol leads; independent cryptography review
Standard page
39
Plan pages
16, 20, 24, 25, 36, 37
ZKP-04Prevent reward and payout substitutionPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run none yet

Setup

Use proofs that commit to authorisation and all reward-relevant fields required by F0.

Steps

  1. Alter payout key, amount, beneficiary, source work or fee allocation independently.
  2. Supply correct execution over malicious producer-provided consensus/reward inputs.
  3. Compare consensus-derived rewards with the proved/publicly authenticated derivation.

Accept

Unauthorised payout changes and incorrect consensus inputs are rejected; no statement accepted merely because execution over supplied inputs is internally correct. Legitimate authorisations are preserved.

Evidence the case requires

Mutation cases; reward derivation trace; signature/proof binding review.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving + protocol leads; independent cryptography review
Standard page
40
Plan pages
16, 20, 24, 25, 36, 37
ZKP-05Make proof payment idempotent across racesPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run none yet

Setup

Use competing provers submitting valid results for the same work and simulate retries/reorganisations.

Steps

  1. Submit simultaneous duplicates, reordered receipts and repeated messages after disconnects.
  2. Crash validators between validation and reward application, then recover.
  3. Reconcile canonical payouts against the exact F0 duplicate policy.

Accept

Only the authorised total payment is made; no double payout, lost accepted entitlement or fork-retained balance. Transactions and payout records recover atomically.

Evidence the case requires

Concurrency schedule; canonical payment ledger; crash/recovery evidence.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving + protocol leads; independent cryptography review
Standard page
40
Plan pages
16, 20, 24, 25, 36, 37
ZKP-06Verify aggregation coverage and completenessPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Build valid multi-shard workloads plus omitted, duplicated, overlapping and misordered shard sets.

Steps

  1. Attempt an aggregate with a correct outer proof but wrong coverage/public-input construction.
  2. Alter shard ranges, roots and aggregation-program identity.
  3. Verify native execution, aggregate validity and coverage commitments independently.

Accept

Only complete, correctly ordered authorised coverage is accepted. No valid proof of the wrong computation becomes an accepted chain result; aggregation failures do not fabricate successful delivery.

Evidence the case requires

Coverage corpus; aggregate/public-input verification; rejection ledger.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving + protocol leads; independent cryptography review
Standard page
40
Plan pages
16, 20, 24, 25, 36, 37
ZKP-07Review soundness and verifier resource limitsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Provide proof-system code, parameters, patches and the pinned verification path to an independent specialist.

Steps

  1. Review soundness assumptions, parameter margins and consequences of performance patches.
  2. Fuzz deserialization and adversarial proofs; measure verification CPU and memory under load.
  3. Cross-check an independent verifier or reference path and test crash containment.

Accept

P09 review and resource requirements pass with no unresolved critical/high finding. Random proof rejection counts are not described as evidence of a particular cryptographic security level.

Evidence the case requires

Scoped soundness review; parameter sheet; fuzzer corpus; verifier profiles.

Method
Independent cryptographic review + testing
Cadence
Release candidate; repeat after relevant changes
Owner
Proving + protocol leads; independent cryptography review
Standard page
41
Plan pages
16, 20, 24, 25, 36, 37
ZKP-08Preserve authority and audit all acceptance pathsPriority BLOCKERProfile P01, P07, P08NOT RUNEvidence none yetLast run none yet

Setup

Inspect block import, sync, RPC, light verification, database restoration and fast paths.

Steps

  1. Try bypassing validation via each path with a proof rejected by the normal path.
  2. Remove the dominant prover/aggregator and have independent replacements process available inputs.
  3. Attempt to use proof-production status as ordering, voting or finality authority.

Accept

No bypass accepts invalid work; proofs alone confer no unauthorised consensus control. Replacement and pause behaviour meet F0/P07/P08 without privileged keys or a trusted aggregator shortcut.

Evidence the case requires

Path coverage report; bypass corpus; replacement run; authority checks.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving + protocol leads; independent cryptography review
Standard page
41
Plan pages
16, 20, 24, 25, 36, 37
09CAP

Sustained proving and delivery

A correct fast shard is only one stage; capacity, latency, payment and retries must work together.

NOT RUN
Owner
Proving lead + independent operators
Gate
Technical readiness / commercial track
Fixtures
F3 meaningful workload catalogue; F4 network; F8 external job harness
Plan pages
17, 18, 24, 25
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
CAP-01Reproduce the historical consumer-shard resultPriority GATEProfile P02, P07NOT RUNEvidence none yetLast run none yet

Setup

Recover the exact source-era workload/build if available; keep it separate from the release-candidate workload.

Steps

  1. Attempt independent reproduction of the 4,717,439-cycle workload and reported 3060/4060/4070 results.
  2. Record proof format, memory, energy, host and whether aggregation/compression are included.
  3. Repeat on the final release and label all configuration changes.

Accept

Historical figures are either reproduced within P02 tolerance or corrected/labelled non-reproduced. Release acceptance uses the current complete workload, never an unmatched historical time or a smaller substituted shard.

Evidence the case requires

Historical/current manifests; proof verification; timing and memory records.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving lead + independent operators
Standard page
42
Plan pages
17, 18, 24, 25
CAP-02Prove on the actual mining configurationPriority BLOCKERProfile P01, P06, P07NOT RUNEvidence none yetLast run none yet

Setup

Use final dataset sizes, registers, clocks, drivers and proof pipeline on every advertised proving tier.

Steps

  1. Run mining alone, proving alone, concurrent execution and supported time-sharing.
  2. Measure wall energy, memory headroom, reloads, proof latency and forgone accepted mining work.
  3. Induce memory pressure and GPU task failure without losing wallet control.

Accept

Every advertised mode completes correctly and meets P06/P07. Net output includes opportunity cost; unsupported concurrency is not claimed. Mining-only vendor support remains separately labelled.

Evidence the case requires

Four-mode results; OOM/failure logs; memory and opportunity-cost ledger.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving lead + independent operators
Standard page
42
Plan pages
17, 18, 24, 25
CAP-03Measure the entire request-to-payment pathPriority GATEProfile P07NOT RUNEvidence none yetLast run none yet

Setup

Assign a unique job ID and immutable timestamps to every stage of F3/F8 jobs.

Steps

  1. Record request, input availability, assignment, execution, shard proof, aggregation, verification, delivery and payment.
  2. Compare monotonic elapsed time with any protocol/DAA clock and document their relationship.
  3. Reconcile failed, censored, retried and abandoned jobs with the original request denominator.

Accept

No hidden stage or missing job; latency distributions and cost cover the complete path. Delivery, finality and payment are reported separately; protocol seconds are not silently relabelled wall-clock seconds.

Evidence the case requires

Stage event ledger; clock calibration; end-to-end latency/cost report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving lead + independent operators
Standard page
42
Plan pages
17, 18, 24, 25
CAP-04Sustain meaningful load without queue growthPriority GATEProfile P07NOT RUNEvidence none yetLast run none yet

Setup

Freeze W: payload mix, input sizes, execution work and per-hour demand; prohibit tiny-workload substitution.

Steps

  1. Run 72 hours at W and a separate 24 hours at 1.2W on the declared fleet.
  2. Measure arrival/completion counts, backlog trend, oldest-job age, deadlines and all retries.
  3. Use held-out workloads and an independent observer to detect discarded or delayed requests.

Accept

P07 completion, tail-latency and bounded-backlog criteria hold. Capacity is stated for the tested W/fleet, not as universal TPS. A queue that grows indefinitely or shrinks through silent loss fails.

Evidence the case requires

Request/completion reconciliation; backlog series; held-out results; observer report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving lead + independent operators
Standard page
43
Plan pages
17, 18, 24, 25
CAP-05Overload and recover without false acceptancePriority BLOCKERProfile P01, P07NOT RUNEvidence none yetLast run none yet

Setup

Start at W and inject 2W for 15 minutes with valid and invalid jobs, then return to W.

Steps

  1. Observe admission, explicit backpressure, reservations and deadline estimates.
  2. Track accepted jobs to valid completion or the pre-agreed failure/refund outcome.
  3. Measure recovery time and ensure ordinary users are not silently starved.

Accept

P07 overload policy and recovery limits hold; no accepted job vanishes or earns an invalid reward. Rejected demand is reported separately from delivery success, preventing denominator manipulation.

Evidence the case requires

Overload timeline; admission/refund logs; backlog-drain proof.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving lead + independent operators
Standard page
43
Plan pages
17, 18, 24, 25
CAP-06Calibrate assignment windows to paid completionPriority GATEProfile P07, P12NOT RUNEvidence none yetLast run none yet

Setup

Use a heterogeneous proving fleet, including the slowest advertised consumer tier.

Steps

  1. Measure actual completion distributions with network delay, competing load and failed attempts.
  2. Test the chosen exclusive window, open claiming and faster challengers after expiry.
  3. Compare assignment frequency, paid completions and wasted work by tier.

Accept

P07 fairness and wasted-work limits hold for advertised tiers. A provisional 10-DAA-second window is not treated as approved. Fair assignment counts alone cannot pass; payment outcomes and operator margins matter.

Evidence the case requires

Window sweep; paid-completion distribution; wasted-work and margin report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving lead + independent operators
Standard page
43
Plan pages
17, 18, 24, 25
CAP-07Reassign work when inputs or providers disappearPriority BLOCKERProfile P01, P07, P08NOT RUNEvidence none yetLast run none yet

Setup

Remove input providers, assigned provers and the dominant aggregator independently and together.

Steps

  1. Have replacement operators retrieve authenticated inputs without founder files.
  2. Retry expired assignments while preserving idempotent reward and customer outcomes.
  3. Restore providers and test late submissions racing with replacements.

Accept

P07/P08 replacement deadlines hold when availability assumptions permit. Otherwise a truthful bounded pause/refund occurs; no fake proof, double payment or hidden privileged input source is used.

Evidence the case requires

Failure schedule; input hashes; reassignment and payout ledger; recovery trace.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving lead + independent operators
Standard page
44
Plan pages
17, 18, 24, 25
CAP-08Deliver customer-verifiable output at scalePriority BLOCKERProfile P01, P07, P14NOT RUNEvidence none yetLast run none yet

Setup

Run the external workload using a customer-controlled verifier and independently operated workers.

Steps

  1. Verify every delivered proof against the contracted program and input commitment.
  2. Reject wrong-format, stale and partial deliveries; test customer retry and delivery failure.
  3. Reconcile delivery, acceptance, payment and refund records without exposing private inputs publicly.

Accept

P07 delivery performance and exact validity hold. Payment depends on the contracted correct result; a valid proof for the wrong job is not a successful delivery.

Evidence the case requires

Customer verification log; proof-format contract; settlement reconciliation.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Proving lead + independent operators
Standard page
44
Plan pages
17, 18, 24, 25
10INC

Rewards, incentives and selfish operators

Assume operators optimise their own returns. Do not depend on the official client choosing a less profitable task.

NOT RUN
Owner
Protocol economics + proving leads
Gate
G4 / G5 G4 G5
Fixtures
F0 fee/reward rules; F4 adversarial operators; F7 incentive models
Plan pages
13, 16, 17, 18, 24, 26
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
INC-01Reconcile issuance, fees, burns and recipientsPriority BLOCKERProfile P01, P12NOT RUNEvidence none yetLast run none yet

Setup

Use a deterministic short chain containing all reward types, fee paths and rounding cases.

Steps

  1. Calculate balances, total supply changes, burns and distributions independently.
  2. Execute identical blocks natively and through the proving path.
  3. Test zero, minimum, maximum and transition-boundary values plus malformed producer accounting.

Accept

Conservation and recipient rules match F0 exactly; no inflation, rounding leakage or duplicate reward. Fee-table and prose discrepancies are resolved before the run, not guessed by the tester.

Evidence the case requires

Independent accounting ledger; balance/supply diffs; boundary vectors.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Protocol economics + proving leads
Standard page
45
Plan pages
13, 16, 17, 18, 24, 26
INC-02Keep revenue streams and claims separatePriority BLOCKERProfile P01, P12, P14NOT RUNEvidence none yetLast run none yet

Setup

Prepare jobs and blocks producing mining income, internal proof rewards and external payments.

Steps

  1. Trace money from source to operator, protocol, developer and any burn.
  2. Compare node records, settlement records and Ember displays.
  3. Attempt to classify testnet rewards, reimbursed purchases or token appreciation as external customer revenue.

Accept

Every stream reconciles and is labelled correctly. No double-counted revenue or fabricated protocol demand; mining subsidy and external service income remain distinct in dashboards and ECO.

Evidence the case requires

Money-flow register; UI reconciliation; rejected classifications.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Protocol economics + proving leads
Standard page
45
Plan pages
13, 16, 17, 18, 24, 26
INC-03Let a modified client choose the most profitable taskPriority GATEProfile P07, P12NOT RUNEvidence none yetLast run none yet

Setup

Permit independent schedulers to mine, prove internally, prove externally or switch off.

Steps

  1. Publish common costs and vary relative task rewards, memory pressure and switching costs.
  2. Run clients that ignore the official scheduling recommendation.
  3. Measure realised operator margin, internal capacity and network progress.

Accept

Required P12 sustainable worlds maintain paid essential capacity without compelled altruism. Profitability and availability are based on realised outcomes, including switching and wasted work.

Evidence the case requires

Scheduler source/policies; switching traces; capacity and margin series.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Protocol economics + proving leads
Standard page
45
Plan pages
13, 16, 17, 18, 24, 26
INC-04Survive external-demand spikes and token declinesPriority GATEProfile P07, P08, P12NOT RUNEvidence none yetLast run none yet

Setup

Use F7 scenarios with 10x external job offers and token-denominated mining-income shocks.

Steps

  1. Allow miners/provers to switch freely under the declared reward and difficulty rules.
  2. Observe hash participation, proof backlog, fees and recovery without an administrator.
  3. Repeat with external demand dropping to zero and with a dominant operator withdrawn.

Accept

Mandatory viable worlds meet P07/P12; stressed nonviable worlds fail or pause safely with truthful status. No emergency rule, fabricated demand or unofficial subsidy is inserted to force a pass.

Evidence the case requires

Shock timeline; fee/hash/capacity paths; failure-region report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Protocol economics + proving leads
Standard page
46
Plan pages
13, 16, 17, 18, 24, 26
INC-05Contain job reservation and identity-splitting abusePriority BLOCKERProfile P01, P07, P09NOT RUNEvidence none yetLast run none yet

Setup

Freeze the actual assignment/payment mechanism; do not assume unimplemented collateral or identity controls.

Steps

  1. Create many worker identities, reserve jobs, withhold proofs and submit late results.
  2. Attempt free option-taking, duplicate work rewards and displacement of honest assignments.
  3. Price attacker costs and observe honest completion under the approved abuse load.

Accept

F0 rules and P07 service limits hold under the declared adversary. Identity splitting does not create unauthorised rewards or control; any unmitigated starvation path blocks the permissionless-service claim.

Evidence the case requires

Attack clients; assignment trace; cost-to-disrupt analysis; honest-user outcomes.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Protocol economics + proving leads
Standard page
46
Plan pages
13, 16, 17, 18, 24, 26
INC-06Test difficulty and timestamp manipulationPriority BLOCKERProfile P01, P08, P12NOT RUNEvidence none yetLast run none yet

Setup

Use the actual adjustment algorithm and consensus timestamp rule with independent miners.

Steps

  1. Inject large hashrate arrivals/departures, periodic selective mining and boundary-timed bursts.
  2. Try allowed and invalid timestamp skew, withheld blocks and replayed work.
  3. Observe block intervals, reward allocation and recovery after hashrate stabilises.

Accept

Invalid inputs are rejected; valid adversarial strategies remain within F0/P08 bounds and are priced in ECO. No unexplained reward amplification, permanent stall or conflicting accepted work.

Evidence the case requires

Difficulty trace; timestamp corpus; revenue analysis; independent rule review.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Protocol economics + proving leads
Standard page
46
Plan pages
13, 16, 17, 18, 24, 26
INC-07Resist self-dealing fees and fake proving demandPriority BLOCKERProfile P01, P12, P14NOT RUNEvidence none yetLast run none yet

Setup

Use self-funded operators and related customer identities in the isolated economic model/network.

Steps

  1. Cycle funds through jobs, tips, developer shares and rebates to seek net reward extraction.
  2. Attempt to inflate external-demand metrics without genuine unrelated customer expenditure.
  3. Reconcile all counterparties and net cash contribution rather than gross transaction volume.

Accept

No unauthorised subsidy extraction or metric inflation passes. Related-party volume is disclosed/excluded from P14; net external cash and legitimate protocol incentives are reported separately.

Evidence the case requires

Circular-flow tests; ownership/conflict review; net-cash reconciliation.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Protocol economics + proving leads
Standard page
47
Plan pages
13, 16, 17, 18, 24, 26
INC-08Quantify provider and supplier failure concentrationPriority GATEProfile P08, P11, P12NOT RUNEvidence none yetLast run none yet

Setup

Model control of hashing, signing, proving, aggregation and hardware supply separately.

Steps

  1. Remove each largest operational dependency and combine correlated failures.
  2. Measure replacement cost/time and whether essential roles share hidden ownership.
  3. Compare results with the approved fault model and no-rescue exercise.

Accept

No hidden single dependency defeats the claimed independence; within-tolerance withdrawals recover under P08/P11. Hardware supply concentration is disclosed without equating vendor sales to operator voting control.

Evidence the case requires

Role/ownership map; dependency removals; recovery and concentration report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Protocol economics + proving leads
Standard page
47
Plan pages
13, 16, 17, 18, 24, 26
11FIN

Consensus safety and recovery

Test safety under the stated fault bounds. Demand liveness only when synchrony and participation assumptions actually hold.

NOT RUN
Owner
Consensus lead + independent formal/security review
Gate
G5 / technical readiness G5
Fixtures
F0 exact fault model; F4 real-node partitions; F5 certificates and historical failures
Plan pages
19, 21, 24, 25
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
FIN-01Agree on ordering, work and executed statePriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Use real fork-choice/DAG handling and independent miners, not only a simplified simulator.

Steps

  1. Generate concurrent branches, delayed blocks, duplicates and invalid work with deterministic seeds.
  2. Compare selected ordering, accumulated work, transaction execution and state roots after delivery converges.
  3. Replay from independent checkpoints and from genesis where practical.

Accept

Honest nodes converge under F0 assumptions with exact roots and rewards. No duplicated work accounting or undocumented ordering dependence; simulator-only success cannot substitute.

Evidence the case requires

Block/ordering corpus; root/work diffs; real-node replay logs.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus lead + independent formal/security review
Standard page
48
Plan pages
19, 21, 24, 25
FIN-02Attack finality with split honest populationsPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Use the source-discussed 40/40/20 weight split, plus threshold-boundary splits under F0.

Steps

  1. Let the 20% adversarial group sign conflicting histories while honest groups are partitioned.
  2. Delay messages and eligibility updates independently; keep total historical weights auditable.
  3. Try to form two certificates and reconnect nodes to observe accepted final history.

Accept

No conflicting final certificates are accepted within the declared fault bound. A safe pause is valid when quorum is unavailable; making progress on both sides is not required.

Evidence the case requires

Signed votes; certificate attempts; voter-table snapshots; safety checker output.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus lead + independent formal/security review
Standard page
48
Plan pages
19, 21, 24, 25
FIN-03Cross authority expiry in a long partitionPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Recover historical expiry failures where available; use the actual current authority-transition rules.

Steps

  1. Partition for 31, 35, 60 and 90 logical days and around every retention/expiry boundary.
  2. Attempt independently renewed authority sets and conflicting checkpoint locks.
  3. Repeat selected boundary cases on real nodes with accelerated timers explicitly labelled.

Accept

Authority continuity remains authenticated and no conflicting final history appears within F0 assumptions. A timeout is not accepted as proof absent voters ceased to exist. Compressed time is not multi-month field evidence.

Evidence the case requires

Expiry timeline; table/certificate history; historical regression tests.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus lead + independent formal/security review
Standard page
48
Plan pages
19, 21, 24, 25
FIN-04Stop signing while mining continuesPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Remove enough signing participation to invalidate the liveness assumption without forging votes.

Steps

  1. Continue mining and execution, cross seed boundaries and monitor proof queues.
  2. Check which user-visible states advance and which remain unfinalised.
  3. Restore eligible weight and bounded message delay, then verify recovery.

Accept

No false finality or fabricated authority. Behaviour matches F0 during the pause and P08 after assumptions return; unfinished transactions are not displayed as irreversible.

Evidence the case requires

Signing/mining trace; UI/RPC states; recovery roots and timing.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus lead + independent formal/security review
Standard page
49
Plan pages
19, 21, 24, 25
FIN-05Authenticate voter-set changes and pooled keysPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Use normal transitions, pool members retaining keys and malicious substitution attempts.

Steps

  1. Alter voter weights, membership proofs, miner/pool identity bindings and prior-certificate links.
  2. Race updates across boundaries and replay old signed changes.
  3. Have a new node verify the authority chain from its declared trust anchor.

Accept

Only correctly authenticated changes are accepted; weights cannot be double-counted or redirected by a pool. All honest nodes agree on the active authority set for each certified point.

Evidence the case requires

Authority-chain fixtures; substitution attacks; new-node verification log.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus lead + independent formal/security review
Standard page
49
Plan pages
19, 21, 24, 25
FIN-06Analyse old-key compromise and long-range historiesPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Freeze assumptions about key erasure, retained weights, trust anchors and offline recovery.

Steps

  1. Use previously eligible keys to build alternative histories after their operators disappear.
  2. Present these histories to recently offline and newly joining clients.
  3. Test replayed certificates, stale anchors and compromised signer subsets.

Accept

Acceptance matches the explicit security model with no hidden trusted recovery step. Any reliance on a recent trusted anchor is disclosed and tested; hashpower assumptions cannot replace old-key analysis.

Evidence the case requires

Long-range corpus; trust-anchor policy; key-compromise review; client results.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus lead + independent formal/security review
Standard page
49
Plan pages
19, 21, 24, 25
FIN-07Recover deterministically after reconnection and crashPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Combine partitions with node crash, partial writes, restarts and proof backlog.

Steps

  1. Reconnect networks under bounded latency and restore required honest participation.
  2. Verify fork choice, unfinalised reorganisation, finality, reward rollback and proof reassignments.
  3. Compare all honest nodes and customer-visible receipts after recovery.

Accept

P08 recovery holds without reversing a previously valid final guarantee. Only permitted unfinalised state is reorganised; no duplicate rewards or inconsistent receipt statuses survive.

Evidence the case requires

Recovery timelines; roots/certificates; payout rollback; customer-state reconciliation.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus lead + independent formal/security review
Standard page
50
Plan pages
19, 21, 24, 25
FIN-08Combine boundaries, faults and adversarial schedulingPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Use an independent model checker/scheduler and production-node scenarios from F4.

Steps

  1. Combine epoch changes, authority transitions, mining churn, data delays and prover/aggregator loss.
  2. Explore bounded adversarial message schedules and minimise any counterexample.
  3. Replay model findings on real code and have an independent reviewer assess uncovered states.

Accept

No unresolved safety failure; liveness claims hold only within declared assumptions and P08. Model bounds and untested schedules are published, not described as proof over every possible execution.

Evidence the case requires

Model/spec artifacts; schedule corpus; replay evidence; independent assessment.

Method
Model checking + real-node testing
Cadence
Release candidate; repeat after relevant changes
Owner
Consensus lead + independent formal/security review
Standard page
50
Plan pages
19, 21, 24, 25
12VER

Wallets, receipts and data availability

Verify the exact property shown to the user. An inclusion proof, execution proof and finality certificate are not interchangeable.

NOT RUN
Owner
Wallet + light-client lead; independent security review
Gate
Technical readiness / claimed options
Fixtures
F0 trust/availability model; F5 malformed roots, receipts and authority chains
Plan pages
20, 25, 35, 37
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
VER-01Authenticate light-client bootstrapPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Give a clean client malicious RPC responses, fabricated voter tables and valid-looking signatures.

Steps

  1. Start from the approved trust anchor and verify every required link to the advertised state.
  2. Substitute otherwise well-formed but unauthorised keys, weights and checkpoints.
  3. Remove the bootstrap service and use another independently operated source.

Accept

The client rejects unauthorised authority and discloses any trust anchor. Signatures over a node-supplied table do not by themselves pass; missing authentication never silently degrades to trusted RPC.

Evidence the case requires

Bootstrap corpus; trust-chain trace; fail-closed tests.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Wallet + light-client lead; independent security review
Standard page
51
Plan pages
20, 25, 35, 37
VER-02Verify evolving authority and execution statementsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Use valid state proofs paired with wrong execution statements or stale authority histories.

Steps

  1. Cross voter and verifier changes with offline clients returning after long intervals.
  2. Alter roots, aggregate identity and proof/public-input bindings independently.
  3. Check local verification rather than merely a server-reported verified flag.

Accept

All advertised proof checks occur locally or the remaining trust is explicitly disclosed. Wrong roots and unauthenticated authority are rejected; unsupported verification paths are not claimed.

Evidence the case requires

Client verification trace; corrupted inputs; offline/upgrade results.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Wallet + light-client lead; independent security review
Standard page
51
Plan pages
20, 25, 35, 37
VER-03Prove successful payment rather than inclusionPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Create successful, reverted, wrong-asset, wrong-recipient and wrong-amount transfers.

Steps

  1. Generate receipts for included transactions, including failures and replaced/unfinalised transactions.
  2. Verify execution status plus asset, recipient, amount and canonical-state/receipt commitment.
  3. Replay the receipt on another chain and after an allowed unfinalised reorganisation.

Accept

Only the actual successful, correctly bound transfer is labelled payment proof. Inclusion-only receipts are labelled as such; no node-reported success flag substitutes for authenticated outcome.

Evidence the case requires

Payment fixture corpus; receipt verification; merchant-facing status checks.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Wallet + light-client lead; independent security review
Standard page
51
Plan pages
20, 25, 35, 37
VER-04Bound cross-chain oracle trust and replayPriority BLOCKERProfile P00, P01, P09NOT RUNEvidence none yetLast run none yet

Setup

For a claimed oracle, freeze destination verifier, authority updates, accepted proof types and replay policy.

Steps

  1. Try deployer-substituted keys, stale certificates, unchecked signatures and wrong source/destination identities.
  2. Exercise legitimate authority updates and source reorganisations under the approved model.
  3. Measure gas/cost with realistic header sets and test disabled/unavailable verification.

Accept

The oracle enforces its declared trust model and fails closed. Deployer privileges and unavailable guarantees are explicit; no trustless-bridge claim exceeds the checks performed. Excluded oracle scope earns no pass credit.

Evidence the case requires

Oracle code/parameters; attack cases; cost report; privilege disclosure.

Method
Claimed-option verification
Cadence
Release candidate; repeat after relevant changes
Owner
Wallet + light-client lead; independent security review
Standard page
52
Plan pages
20, 25, 35, 37
VER-05Reconstruct required state without founder storagePriority BLOCKERProfile P01, P08, P09NOT RUNEvidence none yetLast run none yet

Setup

Remove founder archival/input services and start an independent operator from the documented entry point.

Steps

  1. Fetch authenticated blocks, state/proof inputs and any required witnesses from permitted peers.
  2. Rebuild the expected state and continue validation/proving.
  3. Measure bandwidth, disk, time and retention requirements against advertised operator budgets.

Accept

Required data can be obtained and verified within the declared availability model. Hidden archives or unpublished files block independence. A valid execution proof alone does not satisfy this test.

Evidence the case requires

Download/reconstruction logs; data hashes; resource costs; dependency inventory.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Wallet + light-client lead; independent security review
Standard page
52
Plan pages
20, 25, 35, 37
VER-06Detect withholding, corruption and stale dataPriority BLOCKERProfile P01, P08, P09NOT RUNEvidence none yetLast run none yet

Setup

Serve valid commitments with missing data, corrupted chunks, stale witnesses and conflicting peer replies.

Steps

  1. Attempt to make a validator or light client accept an unavailable or incorrect state under F0.
  2. Test retrieval from independent peers and expiry/retry policy.
  3. Restore data and check that recovery cannot alter an already verified commitment.

Accept

No unjustified available/verified status; safety and admission rules match F0. Recovery is bounded where assumptions permit, and unavailable-data states remain visible instead of hidden behind proofs.

Evidence the case requires

Withholding corpus; peer retrieval traces; availability/status checks.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Wallet + light-client lead; independent security review
Standard page
52
Plan pages
20, 25, 35, 37
VER-07Protect wallet keys, signing and recoveryPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Use test-only keys, encrypted backups and clean replacement devices; no real user funds.

Steps

  1. Attempt secret access from proving jobs, logs, crash dumps, clipboard and telemetry paths.
  2. Verify transaction destination/amount before signing; test backup/restore and wrong-password handling.
  3. Upgrade and recover without silently changing signing authority or exposing seed material.

Accept

No unintended secret disclosure or unauthorised signature. Supported recovery restores the correct keys and accounts; users receive explicit risk/backup information. Logs are sanitised without hiding security evidence.

Evidence the case requires

Security review; canary-secret tests; signing fixtures; restore journey.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Wallet + light-client lead; independent security review
Standard page
53
Plan pages
20, 25, 35, 37
VER-08Keep every user-facing state truthfulPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Create included-only, executed, proven, finalised, reverted, stale and paused examples.

Steps

  1. Compare explorer, wallet, receipt, RPC and customer API labels against authenticated evidence.
  2. Interrupt finality and proof services and observe refresh/reconnect behaviour.
  3. Check statements about privacy, Ethereum security and device support.

Accept

No stronger state is implied than verified; stale data is marked and failures are actionable. EVM compatibility is not labelled Ethereum security, and ZK technology is not automatically labelled transaction privacy.

Evidence the case requires

Cross-surface screenshots/logs; state mapping; claim review.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Wallet + light-client lead; independent security review
Standard page
53
Plan pages
20, 25, 35, 37
13OPS

Independent operation and release security

A permissionless specification must remain operational without privileged infrastructure or unsafe automatic updates.

NOT RUN
Owner
Operations + release leads; independent operators
Gate
G5 G5
Fixtures
F4 isolated multi-operator network; F0 signed releases; F9 telemetry
Plan pages
21, 24, 25, 26
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
OPS-01Run the complete no-founder exercisePriority BLOCKERProfile P07, P08, P11NOT RUNEvidence none yetLast run none yet

Setup

Use the P11 independent network, adequate honest participation and enough non-founder capacity for W.

Steps

  1. Remove founder miners, provers, aggregators, RPC, DNS/bootstrap dependencies and private support access.
  2. Run the full P11 period while crossing real and separately labelled accelerated boundaries.
  3. Introduce scheduled faults and have independent operators recover using published instructions.

Accept

No founder action, secret file, privileged key or emergency anti-chip rule is needed. P07/P08 outcomes hold within assumptions; any intervention is recorded as a failed no-rescue run, not erased.

Evidence the case requires

Operator roster/conflict checks; dependency removals; full activity/intervention log.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Operations + release leads; independent operators
Standard page
54
Plan pages
21, 24, 25, 26
OPS-02Diversify bootstrap and resist peer isolationPriority BLOCKERProfile P01, P08, P09NOT RUNEvidence none yetLast run none yet

Setup

Start nodes without the default bootstrap host and give others adversarial peer lists.

Steps

  1. Attempt eclipse through peer concentration, stale discovery, poisoned DNS and repeated identities in an isolated lab.
  2. Use independent documented discovery paths and validate returned chain data.
  3. Measure synchronisation, peer diversity and recovery after benign connectivity returns.

Accept

No unauthenticated history is trusted; bootstrap has no hidden single-provider requirement. Isolation is detected/contained according to F0 and recovery meets P08 when assumptions return.

Evidence the case requires

Peer/discovery traces; eclipse scenarios; startup and recovery evidence.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Operations + release leads; independent operators
Standard page
54
Plan pages
21, 24, 25, 26
OPS-03Separate update distribution from consensus authorityPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Use test signing keys and clean desktop/node installations with valid, stale and malicious packages.

Steps

  1. Offer signed updates with unexpected consensus rules, downgraded binaries and corrupted payloads.
  2. Test explicit operator acceptance and the published signing-key incident procedure.
  3. Confirm that distribution-key possession cannot independently activate new consensus rules.

Accept

Tampering/unauthorised rollback is rejected; updates do not silently transfer authority. Approved acceptance and activation are separate. No test touches production signing material.

Evidence the case requires

Package corpus; approval/activation traces; compromised-key rehearsal.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Operations + release leads; independent operators
Standard page
54
Plan pages
21, 24, 25, 26
OPS-04Recover nodes from crash and storage damagePriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run none yet

Setup

Use production database/snapshot paths with controlled interrupted writes and corrupted test storage.

Steps

  1. Crash during import, proof acceptance, reward application and snapshot generation.
  2. Restore from independently verified snapshots or re-sync through documented procedures.
  3. Compare roots, certificates, balances and processed-job IDs with an unaffected node.

Accept

No corrupt snapshot is trusted, no duplicate payout and no loss of authenticated final state. Recovery meets P08 where data is available; ambiguous corruption fails closed and is actionable.

Evidence the case requires

Crash schedule; snapshot hashes; root/balance diffs; recovery timing.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Operations + release leads; independent operators
Standard page
55
Plan pages
21, 24, 25, 26
OPS-05Isolate untrusted proving workloadsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Run hostile test jobs with secret canaries and restrictive worker permissions.

Steps

  1. Attempt filesystem escape, process spawning, resource exhaustion, network access and key-store reads.
  2. Crash workers and inspect host, wallet and node availability plus dump/log contents.
  3. Retry on every supported isolation backend and check dependency vulnerability handling.

Accept

No secret leakage or unauthorised host action; P09 resource containment holds. Worker failure does not compromise validator/wallet authority; unsupported isolation is not marketed as safe execution.

Evidence the case requires

Sandbox penetration report; canary logs; resource limits; host-integrity checks.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Operations + release leads; independent operators
Standard page
55
Plan pages
21, 24, 25, 26
OPS-06Contain malicious network and API trafficPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Use an authorised isolated load environment with declared resource and request-rate budgets.

Steps

  1. Send malformed headers, proofs, oversized messages, floods and invalid peer sequences.
  2. Measure legitimate traffic, memory/disk growth and validator CPU use.
  3. Test limit resets, peer reconnect and graceful degradation without disabling validation.

Accept

P09 abuse budgets hold; no unbounded allocation, persistent crash or invalid acceptance. Backpressure is visible and honest users retain the specified service at admitted load.

Evidence the case requires

Load/corpus manifests; resource series; valid-traffic metrics; incident traces.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Operations + release leads; independent operators
Standard page
55
Plan pages
21, 24, 25, 26
OPS-07Detect failures with usable evidence and runbooksPriority GATEProfile P09, P10NOT RUNEvidence none yetLast run none yet

Setup

Define alerts for invalid acceptance, conflicting finality, backlog, data loss, payout mismatch and stale status.

Steps

  1. Inject one instance of each monitored failure in the lab.
  2. Have an unaffiliated operator diagnose it using only emitted evidence and published instructions.
  3. Test redaction, metric freshness and duplicate-alert suppression without suppressing serious failures.

Accept

P10 alert/detection limits hold; every blocker produces actionable evidence. Monitoring does not leak secrets or mislabel intentional safe pauses as successful finality.

Evidence the case requires

Alert matrix; detection timelines; independent runbook exercise.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Operations + release leads; independent operators
Standard page
56
Plan pages
21, 24, 25, 26
OPS-08Repeat independent operation across releasesPriority BLOCKERProfile P00, P08, P11NOT RUNEvidence none yetLast run none yet

Setup

Use a clean previous supported version and the final candidate with independent operators.

Steps

  1. Perform documented rolling upgrade, rollback of non-consensus software where allowed and resynchronisation.
  2. Cross activation with mixed versions and unavailable founder distribution hosts.
  3. Re-run affected gates after changes and preserve prior failures and incident lessons.

Accept

No undocumented privileged migration or automatic consensus rewrite. All affected evidence is refreshed; P11 no-rescue results remain tied to the final release, not an earlier build.

Evidence the case requires

Upgrade/replay logs; invalidation map; repeated gate signatures.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Operations + release leads; independent operators
Standard page
56
Plan pages
21, 24, 25, 26
14UX

Ember, payouts and operator control

Successful participation must be practical for ordinary owners without hidden custody or loss of consensus authority.

NOT RUN
Owner
Desktop product + pool leads; independent usability study
Gate
Operator readiness / G5 G5
Fixtures
F2 supported desktops; F8 user study; F4 honest/malicious pools
Plan pages
14, 21, 25, 26
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
UX-01Onboard ordinary owners on native desktop appsPriority GATEProfile P10NOT RUNEvidence none yetLast run none yet

Setup

Recruit the P10 first-time user cohort across Windows and macOS using supported physical hardware.

Steps

  1. Observe install, hardware detection, safety explanation and first accepted work without staff intervention.
  2. Record download/data preparation separately as well as complete end-to-end time.
  3. Test unsupported hardware and insufficient memory messaging rather than forcing a failed start.

Accept

P10 completion/time targets hold with no unsafe default or concealed prerequisite. The product is tested as the actual desktop app, not only a browser preview.

Evidence the case requires

Consent-based study records; task timings; failure reasons; compatibility outcomes.

Method
Independent observed user study
Cadence
Release candidate; repeat after relevant changes
Owner
Desktop product + pool leads; independent usability study
Standard page
57
Plan pages
14, 21, 25, 26
UX-02Make pause, stop and safe tuning reliablePriority BLOCKERProfile P01, P10NOT RUNEvidence none yetLast run none yet

Setup

Run mining/proving on active desktops under contention and safe thermal stress.

Steps

  1. Use pause, stop, power limit, task selection and emergency local shutdown controls.
  2. Crash or restart the UI while workers run and verify ownership of background processes.
  3. Restore the original hardware settings and test power-saving/low-battery behaviour where supported.

Accept

P10 control latency and safe-state requirements hold. Stopping does not strand an uncontrolled process; tuning never depends on unsafe settings or silent privilege escalation.

Evidence the case requires

Control timings; process/settings audit; restart and safety traces.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Desktop product + pool leads; independent usability study
Standard page
57
Plan pages
14, 21, 25, 26
UX-03Show net earnings and compatibility honestlyPriority BLOCKERProfile P01, P10, P12NOT RUNEvidence none yetLast run none yet

Setup

Use known rewards, fees, energy readings, retries and operator-entered tariffs.

Steps

  1. Compare mining, internal proof and external proof income with authoritative ledgers.
  2. Show gross/net estimates, measurement boundaries, tariff assumptions and payout status.
  3. Test stale data, losses, negative margins and mining-only versus proving-compatible devices.

Accept

P10 reconciliation limits hold and uncertainty is visible. No guaranteed profits, fabricated fiat price or inferred proving support; provisional earnings are not shown as settled payments.

Evidence the case requires

UI/ledger comparisons; tariff fixtures; stale/negative examples.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Desktop product + pool leads; independent usability study
Standard page
57
Plan pages
14, 21, 25, 26
UX-04Pay small operators without hidden custodyPriority BLOCKERProfile P01, P10NOT RUNEvidence none yetLast run none yet

Setup

Use ordinary single-card balances and the actual pooling/payment path.

Steps

  1. Earn, request/receive payment, disconnect and reconnect; include low balances, fees and a pool outage.
  2. Attempt redirection, delayed accounting and withdrawal of another user's entitlement.
  3. Reconcile displayed balances with canonical entitlement and actual settlement.

Accept

P10 payout limits hold for the declared small-operator case. No unauthorised custody, redirection or unexplained loss; thresholds and fees are disclosed rather than masked by larger test balances.

Evidence the case requires

Single-card payout ledger; pool failure record; custody/authorisation review.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Desktop product + pool leads; independent usability study
Standard page
58
Plan pages
14, 21, 25, 26
UX-05Keep voting keys with the miner through poolingPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run none yet

Setup

Use an honest pool and a modified pool that replaces worker identity or voting credentials.

Steps

  1. Verify the consensus binding from performed work to the miner's retained key.
  2. Attempt substitution, replay and reassignment without the miner's authorisation.
  3. Leave the pool and verify retained voting/finality rights under F0.

Accept

No silent transfer of governance/finality authority. If the protocol cannot establish retained keys, this requirement fails; a pool-protocol name or user-interface promise does not pass.

Evidence the case requires

Work/key binding vectors; malicious-pool attempts; leave-pool authority check.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Desktop product + pool leads; independent usability study
Standard page
58
Plan pages
14, 21, 25, 26
UX-06Verify actual miner-selected work templatesPriority BLOCKERProfile P01, P10NOT RUNEvidence none yetLast run none yet

Setup

Provide a pool interface with declared job-declaration support and independent miner templates.

Steps

  1. Submit miner-selected valid transaction templates and verify what is actually hashed and accepted.
  2. Have a pool substitute or censor templates and test local verification/fallback.
  3. Measure payout and acceptance consequences without moving authority to the pool.

Accept

The advertised selection control exists in accepted work, not only configuration. Undisclosed substitution is detected; supported independent operation remains practical under P10.

Evidence the case requires

Template commitments; accepted-block evidence; malicious-pool/fallback report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Desktop product + pool leads; independent usability study
Standard page
58
Plan pages
14, 21, 25, 26
UX-07Expose actionable failures and safe updatesPriority BLOCKERProfile P09, P10NOT RUNEvidence none yetLast run none yet

Setup

Create failed proofs, memory pressure, expired jobs, missing payouts and available software updates.

Steps

  1. Ask independent users to identify the issue, stop safely and follow the recommended action.
  2. Test explicit update approval, version visibility and a failed/corrupt update.
  3. Confirm diagnostic exports remove keys and private inputs while retaining useful evidence.

Accept

P10 task-success requirements hold; no silent update or false success state. Recovery instructions work on supported desktops and secret canaries never enter exported logs.

Evidence the case requires

Observed tasks; update traces; sanitised export tests.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Desktop product + pool leads; independent usability study
Standard page
59
Plan pages
14, 21, 25, 26
UX-08Publish competitive accessible softwarePriority GATEProfile P02, P10NOT RUNEvidence none yetLast run none yet

Setup

Provide open documented builds, tuning parameters and known fee conditions for all supported platforms.

Steps

  1. Compare Ember against independently optimised permissible implementations on identical work.
  2. Measure efficiency, fees, false rejection, installation and update transparency.
  3. Scan for hidden developer fees, hardware whitelists, per-address privilege or undisclosed remote controls.

Accept

P10 relative-efficiency limits hold and all fees/privileges are explicit. No self-reported device tier earns consensus advantage. A superior external implementation triggers investigation, not selective exclusion.

Evidence the case requires

Matched software comparison; code/config review; fee/privilege inventory.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Desktop product + pool leads; independent usability study
Standard page
59
Plan pages
14, 21, 25, 26
15COM

Paid demand and sustainable delivery

Devnet payouts and subsidised pilots demonstrate mechanics, not independent willingness to pay.

NOT RUN
Owner
Commercial lead + independent financial/customer reviewer
Gate
Commercial evidence
Fixtures
F8 real consenting customers; F7 full service costs; private identity proofs
Plan pages
4, 17, 18, 24, 26, 27, 31, 32, 33
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
COM-01Deliver a genuine contracted proof pilotPriority GATEProfile P07, P14NOT RUNEvidence none yetLast run none yet

Setup

Select one real external customer with a meaningful fixed workload and no required migration to Igneum.

Steps

  1. Agree program, inputs, proof format, deadline, price, failure/refund policy and verification method.
  2. Run paid jobs through ordinary independently operated infrastructure.
  3. Have the customer verify usefulness, correctness and its reason for choosing the service.

Accept

The pilot satisfies its actual contract and settles genuine external payment. Trial subsidies are disclosed and cannot satisfy the repeat-demand gate; no invented customer or testimonial.

Evidence the case requires

Redacted contract; verified jobs; settlement proof; consented customer confirmation.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Commercial lead + independent financial/customer reviewer
Standard page
60
Plan pages
4, 17, 18, 24, 26, 27, 31, 32, 33
COM-02Establish independent repeat purchasingPriority GATEProfile P14NOT RUNEvidence none yetLast run none yet

Setup

Use the P14 multi-customer observation period and ownership/conflict checks.

Steps

  1. Track paid purchases on distinct occasions, including refunds and stopped customers.
  2. Audit related parties, project reimbursements, token grants and circular funding.
  3. Reconcile external cash received with correctly delivered meaningful work.

Accept

P14 buyer, duration and volume minima are met without reimbursement or related-party substitution. Repeat orders are separate buying decisions, not a single payment split into many jobs.

Evidence the case requires

Anonymised buyer ledger; repeat-order dates; conflict review; net receipts.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Commercial lead + independent financial/customer reviewer
Standard page
60
Plan pages
4, 17, 18, 24, 26, 27, 31, 32, 33
COM-03Demonstrate service and operator marginsPriority GATEProfile P12, P14NOT RUNEvidence none yetLast run none yet

Setup

Allocate all delivery costs, including aggregation, retries, hardware, power, host, network and support.

Steps

  1. Calculate gross contribution and fully loaded unit costs for each contracted workload.
  2. Reconcile a representative operator's realised earnings against metered costs and opportunity cost.
  3. Repeat under the declared demand and price sensitivities.

Accept

P14 contribution targets hold and at least the required operator cohort has positive realised contribution. Excluded overhead is visible; token appreciation or unpriced founder labour cannot silently create profitability.

Evidence the case requires

Unit-economics ledger; metered operator sample; allocation rules; sensitivity report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Commercial lead + independent financial/customer reviewer
Standard page
60
Plan pages
4, 17, 18, 24, 26, 27, 31, 32, 33
COM-04Meet the customer service guaranteePriority BLOCKERProfile P01, P07, P14NOT RUNEvidence none yetLast run none yet

Setup

Observe actual delivery deadlines, validity, failure handling and support over the contracted period.

Steps

  1. Count all accepted jobs, including failed, retried and abandoned cases.
  2. Have the customer independently verify results and invoke one authorised refund/failure exercise.
  3. Compare offered capacity and quoted price with what was actually delivered.

Accept

P07 and contracted obligations hold; validity has zero accepted exceptions. Failure terms are honoured, and demand beyond capacity is explicitly refused rather than quietly omitted from metrics.

Evidence the case requires

Customer-verifier records; SLO report; refunds; promised-versus-delivered comparison.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Commercial lead + independent financial/customer reviewer
Standard page
61
Plan pages
4, 17, 18, 24, 26, 27, 31, 32, 33
COM-05Compare against the buyer's real alternativePriority GATEProfile P14, P15NOT RUNEvidence none yetLast run none yet

Setup

Identify a credible alternative supplier or in-house option for the same workload, proof format and security.

Steps

  1. Obtain comparable quotes or consented measured trials at the evaluation date.
  2. Include integration, verification, deadlines and all operational costs, not only proof-generation time.
  3. Document the customer's actual trade-off without inventing unavailable comparator evidence.

Accept

P15 commercial comparison is satisfied with like-for-like scope and a evidenced purchase reason. Missing alternative data remains MISSING; it is not scored as an Igneum win.

Evidence the case requires

Dated comparison; workload/security match; customer decision record.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Commercial lead + independent financial/customer reviewer
Standard page
61
Plan pages
4, 17, 18, 24, 26, 27, 31, 32, 33
COM-06Retain buyers after the pilot and subsidy periodPriority GATEProfile P14NOT RUNEvidence none yetLast run none yet

Setup

Follow all recruited customers through the P14 observation period, including churn.

Steps

  1. Remove disclosed trial incentives before measuring repeat demand.
  2. Track renewal, expansion, cancellation reasons, unresolved incidents and buyer concentration.
  3. Review whether one affiliated or subsidised buyer dominates the apparent market.

Accept

P14 repeat/concentration conditions hold with honest denominator and churn reporting. Paying demand survives beyond a demonstration; unsatisfied or departed buyers are not removed retrospectively.

Evidence the case requires

Cohort/renewal ledger; churn notes; concentration and incentive report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Commercial lead + independent financial/customer reviewer
Standard page
61
Plan pages
4, 17, 18, 24, 26, 27, 31, 32, 33
COM-07Fund maintenance without assumed appreciationPriority GATEProfile P13NOT RUNEvidence none yetLast run none yet

Setup

Prepare a costed plan for development, review, infrastructure, support and incident response.

Steps

  1. Separate committed resources from revenue dependent on adoption or token price.
  2. Stress lower income and an unexpected security/operations expense.
  3. Verify responsible owners and continuity arrangements without changing fair-launch promises.

Accept

P13 committed-runway requirement holds and downside responses are documented. No uncommitted financing, rising token price or burn accounting is presented as available maintenance funding.

Evidence the case requires

Budget and commitment evidence; downside plan; owner/continuity roster.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Commercial lead + independent financial/customer reviewer
Standard page
62
Plan pages
4, 17, 18, 24, 26, 27, 31, 32, 33
COM-08Let independent developers build useful integrationsPriority GATEProfile P09, P14NOT RUNEvidence none yetLast run none yet

Setup

Recruit unaffiliated developers unfamiliar with unpublished implementation details.

Steps

  1. Use public docs to deploy a supported application or integrate an external proof request and verification flow.
  2. Record time, undocumented dependencies, workarounds and correctness issues.
  3. Retest after documentation fixes without founder-written hidden integration code.

Accept

P14 developer-task minimum passes on the final release; all required public instructions exist. Successful bytecode deployment alone does not count as a working application or service integration.

Evidence the case requires

Consented developer logs; public examples; issue closure; verified end-to-end journeys.

Method
Independent integration study
Cadence
Release candidate; repeat after relevant changes
Owner
Commercial lead + independent financial/customer reviewer
Standard page
62
Plan pages
4, 17, 18, 24, 26, 27, 31, 32, 33
16LEAD

Comparative leadership evidence

A serious contention claim requires comparative outcomes and real adoption evidence, not just an internally green test dashboard.

NOT RUN
Owner
Independent assessment panel + product/economics reviewers
Gate
Leadership-contender decision
Fixtures
F8 peer/customer studies; full signed technical evidence; 90-day observation
Plan pages
4, 22, 25, 27, 31, 32, 33
8 cases: 0 passed under the standard, 0 running with team evidence, 8 not run, 0 deferred
LEAD-01Register a fair contemporary comparisonPriority GATEProfile P15NOT RUNEvidence none yetLast run none yet

Setup

Choose at least the P15 peer coverage and an evaluation date before collecting confirmatory results.

Steps

  1. Include the plan's Ravencoin, Ergo and Firo reference set where comparable, then check for other relevant current options.
  2. Freeze versions, supported hardware, methods, noninferiority margins and commercial alternatives.
  3. Publish exclusions and prohibit cross-algorithm raw-hashrate comparisons.

Accept

The protocol covers material alternatives fairly and is signed independently. A missing or non-comparable feature is not scored zero; no arbitrary universal rank is inferred from selected metrics.

Evidence the case requires

Timestamped peer protocol; source/version records; comparison/exclusion rationale.

Method
Pre-registered comparative study
Cadence
Release candidate; repeat after relevant changes
Owner
Independent assessment panel + product/economics reviewers
Standard page
63
Plan pages
4, 22, 25, 27, 31, 32, 33
LEAD-02Demonstrate comparable operator advantagesPriority GATEProfile P02, P10, P15NOT RUNEvidence none yetLast run none yet

Setup

Use matched user tasks and operating conditions on the selected GPU-first networks.

Steps

  1. Measure install-to-first-accepted-work, software overhead versus each network's tuned baseline, payout friction and retained control.
  2. Measure rejection/availability under the same network conditions; report fees separately.
  3. Use blinded analysis where possible and independent runs for decisive differences.

Accept

P15 noninferiority and superiority requirements hold on meaningful comparable dimensions. No raw hashes from different algorithms are compared, and transient token price is not labelled engineering superiority.

Evidence the case requires

Matched task data; uncertainty/effect sizes; independent comparison report.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent assessment panel + product/economics reviewers
Standard page
63
Plan pages
4, 22, 25, 27, 31, 32, 33
LEAD-03Substantiate the specialist-coexistence claimPriority GATEProfile P04, P12, P15NOT RUNEvidence none yetLast run none yet

Setup

Assemble G1-G4 plus frozen rules and all surviving-adversary assumptions.

Steps

  1. Have independent reviewers trace each public competitiveness statement to its narrowest evidence.
  2. Separate measured GPUs, modelled silicon and economic scenarios in all summaries.
  3. Evaluate residual uncertainty, excluded technologies and the no-new-rules counterfactual.

Accept

All claimed envelopes meet P04/P12 without unsupported universal bounds. Reviewers agree the evidence supports scoped commodity competitiveness even when chips remain compatible; an exact chip-arrival probability is not inferred.

Evidence the case requires

Claim-to-evidence map; signed envelope review; limitations statement.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent assessment panel + product/economics reviewers
Standard page
63
Plan pages
4, 22, 25, 27, 31, 32, 33
LEAD-04Observe ordinary-operator retention and marginsPriority GATEProfile P12, P16NOT RUNEvidence none yetLast run none yet

Setup

Recruit the P16 independent cohort before observing results; use privacy-preserving evidence.

Steps

  1. Follow participation, realised margin, hardware changes, failures and reasons for leaving for 90 days.
  2. Report trial incentives separately and include every initial participant in retention denominators.
  3. Compare behaviour with matched alternatives where feasible; disclose absence of an actual downturn.

Accept

P16 retention/margin minima hold with verified independence and no removal of churned users. Simulated downturns cannot be called observed bear-market retention; historical claims stay limited to the period measured.

Evidence the case requires

Pseudonymous cohort ledger; margin/retention calculations; departure reasons.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent assessment panel + product/economics reviewers
Standard page
64
Plan pages
4, 22, 25, 27, 31, 32, 33
LEAD-05Measure control and dependency concentrationPriority GATEProfile P11, P16NOT RUNEvidence none yetLast run none yet

Setup

Audit operational control of mining, voting, proving, aggregation, hosting and software distribution separately.

Steps

  1. Use opt-in attestations, observed dependencies and independent corroboration; disclose uncertain common ownership.
  2. Compare concentration and provider-removal outcomes to the approved security and availability assumptions.
  3. Check that pooled payments do not hide authority concentration and hardware vendors are not equated with operators.

Accept

P11/P16 concentration requirements hold within disclosed uncertainty; unidentified control cannot be counted as independent. No single removable dependency is falsely marketed as decentralised operation.

Evidence the case requires

Control/failure-domain map; uncertainty notes; concentration/removal results.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent assessment panel + product/economics reviewers
Standard page
64
Plan pages
4, 22, 25, 27, 31, 32, 33
LEAD-06Complete the reliability observation windowPriority BLOCKERProfile P01, P16NOT RUNEvidence none yetLast run none yet

Setup

Observe the final candidate and approved compatible updates for the full P16 real-time period.

Steps

  1. Measure promised service availability, invalid acceptance, finality safety, payouts and incident impact.
  2. Reconcile external probes, customer records and operator logs, including maintenance and exclusions.
  3. Repeat affected critical tests after every material change; reset observation where comparability breaks.

Accept

P16 availability and safety criteria hold on live observation; no hidden downtime or compressed-time substitution. This supports the recorded window only, not multi-year operational maturity.

Evidence the case requires

90-day SLO ledger; independent probes; incident reports; change/retest history.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent assessment panel + product/economics reviewers
Standard page
64
Plan pages
4, 22, 25, 27, 31, 32, 33
LEAD-07Issue an independent contender assessmentPriority GATEProfile P00, P15, P16NOT RUNEvidence none yetLast run none yet

Setup

Provide the full evidence packet, commercial results, comparative study and unresolved-limit register to the panel.

Steps

  1. Check every mandatory and claimed-option test, source requirement and approved threshold.
  2. Require separate signoffs for hardware/economics, security/operations and customer/operator evidence.
  3. Document dissent and challenge any inference that passing an internal checklist proves number-one rank.

Accept

Every required gate is PASS with no unresolved material challenge, critical/high defect or missing comparator/customer evidence. The panel supports a credible leadership-contender conclusion within scope, not a guaranteed rank.

Evidence the case requires

Signed assessment; full status index; dissent/limitations; approved claim wording.

Method
Independent final assessment
Cadence
Release candidate; repeat after relevant changes
Owner
Independent assessment panel + product/economics reviewers
Standard page
65
Plan pages
4, 22, 25, 27, 31, 32, 33
LEAD-08Keep leadership claims valid after releasePriority GATEProfile P00, P16NOT RUNEvidence none yetLast run none yet

Setup

Define material-change triggers and scheduled reviews before publishing the assessment.

Steps

  1. Refresh competitor, hardware-cost, demand and security evidence at the P16 cadence.
  2. Test a newly credible specialist, lost customer, major outage and verifier change against invalidation rules.
  3. Withdraw or narrow stale claims promptly while publishing the new evidence status.

Accept

Claims remain dated, scoped and revisable; material contrary evidence reopens the appropriate gate. The network may remain usable while a leadership claim is suspended. No permanent self-awarded certification.

Evidence the case requires

Review calendar; invalidation drills; versioned public claim register.

Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
Independent assessment panel + product/economics reviewers
Standard page
65
Plan pages
4, 22, 25, 27, 31, 32, 33
Profiles

The numbers each case is held to.

17 profiles, P00 to P16. A profile is frozen before the confirmatory run; weakening a target after a failure creates a different claim.

P00Approved as proposed

Frozen scope and approval

  1. Approve the release manifest, supported roles, numerical profiles, mandatory scenarios, trust/fault model, workload W, adapters and claims before confirmatory tests. Unknown values are BLOCKED, not defaults.
  2. Core safety and authentication invariants admit no waiver. Proposed performance or commercial targets may be replaced only before the confirmatory run, with an independent rationale and a versioned public scope.
  3. After a failure, weakening a target creates a different claim and requires a new assessment. Preserve all failed runs; do not average a blocker away.

Cited by 14 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P01Approved as proposed

Correctness and negative-test depth

  1. Zero observed invalid acceptance, unauthorised signature, conflicting finality within assumptions, duplicated reward or unexplained cross-backend state/hash disagreement.
  2. Minimum proposed campaign: 1,000,000 full-hash vectors per supported backend across all families, plus at least 10,000 malformed/boundary cases per relevant parser or binding class. Include exhaustive small-domain cases and historical regressions.
  3. All prescribed critical mutants must be detected. This sampling target is not a bound on cryptographic failure probability and does not replace independent reasoning about soundness or safety.

Cited by 69 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P02Approved as proposed

Hardware coverage and reproducibility

  1. At least 12 physical retail configurations: at least 3 NVIDIA, 3 AMD and 2 Apple configurations, at least two discrete-GPU generations, an advertised 8 GB mining tier and 12 GB proving tiers where claimed. Record usable, not nominal, memory.
  2. Declare a competitive core of at least 6 configurations spanning every advertised vendor and at least two discrete generations before optimisation. The wider cohort remains mandatory for access and economic tests; it cannot be silently dropped.
  3. Use 5 paired 30-minute steady-state runs per primary cell after at least 15 minutes of warm-up and a stable temperature trend. Calibrated wall meter uncertainty must be at most 2%. Run a 7-day soak on representative low/mid/high tiers.
  4. Three unaffiliated operators participate; every competitive-core cell is reproduced by at least two. Identical-SKU energy/accepted-work results must agree within 5% after declared environment corrections; unexplained variance blocks the headline.

Cited by 12 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P03Approved as proposed

Candidate improvement and honest-card budget

  1. For production candidate changes, per mandatory GPU cell: no more than 5% increase in joules per accepted work and no more than 2% decrease in accepted throughput versus the paired tuned baseline. Absolute safety limits always apply.
  2. G2 requires at least a 10% reduction in the strongest evaluated specialist advantage after redesign, outside the declared measurement/model uncertainty, while meeting those budgets. A failed experiment is not a successful upgrade.
  3. Existing clock-lock savings belong in the baseline. Long programs cannot pass by adding enough equally costly work to both devices to improve a ratio while materially worsening honest operation.

Cited by 8 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P04Approved as proposed

Scoped specialist-competition target

  1. Define R_E as GPU wall joules per accepted work divided by the lowest credible complete-system specialist joules for that same work. The proposed target is R_E at most 1.5 for every competitive-core cell at the same node and one node ahead.
  2. Evaluate at least three materially distinct specialist architectures, with one programmable multi-family design, and a second independent reviewer. Include shared/reduced memory, hybrid execution, selective participation and realistic power/host costs.
  3. Publish two-node-ahead and modular/reused-IP stress cases; they must satisfy the predeclared P12 economic envelope. No universal ceiling for unknown future hardware is claimed. Report model bounds separately from statistical confidence.
  4. A lower-bound specialist estimate, not a convenient average or a deliberately constrained reference architecture, drives the conservative comparison. Undefined or unbounded decision-critical assumptions make the result BLOCKED.

FAIL R_E target at most 1.5 at the same node and one node ahead; today's placed bracket 1.5x to 2.1x: FAIL

Cited by 14 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P05Approved as proposed

Measurement and inference protocol

  1. Pre-register primary metrics, cohorts, holdout seeds, run order, exclusions and analysis before confirmation. Keep tuning/training runs separate from holdout runs.
  2. Use independent runs/operators as measurement units. Report point estimates, two-sided 95% measurement intervals and absolute sample counts; handle time-series dependence with a declared block or run-level method.
  3. Apply conservative uncertainty to pass decisions. A confidence interval around measured GPU energy does not capture unknown ASIC architectures; model parameter ranges and expert judgement must be reported as such.
  4. Never compare raw hashes per second across different algorithms. Do not transform a five-year scenario sweep into a probability of chip arrival or a guarantee of future profitability.

Cited by 0 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P06Approved as proposed

Memory and support policy

  1. All advertised role/configuration combinations must finish without OOM, corruption or unsafe fallback. Publish a component memory budget, including display/OS, driver, miner, prover, aggregation and epoch construction.
  2. Proposed support horizon: at least 24 months of known schedule compatibility for the advertised entry tier, unless a narrower horizon is prominently approved before sale or launch. Removal changes the claim and must pass ECO-07.
  3. Treat 5.5 / 8.5 / 11.5 GiB as source candidates, not imposed final rules. Simultaneous operation, eviction and time-sharing are distinct advertised modes with separately measured cost.

Cited by 4 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P07Approved as proposed

Proof service capacity and fairness

  1. Freeze W as a meaningful workload mix, input sizes, proof format, fleet and requests/hour. Primary proposed target: 72 hours at W, plus 24 hours at 1.2W; at least 99.5% accepted jobs delivered valid within the contracted deadline.
  2. Default delivery targets for the declared internal reference workload: p95 at most 60 seconds and p99 at most 120 seconds from input-ready assignment through verified delivery. Also publish request-to-delivery including input wait; no claim may omit that delay.
  3. Request-to-delivery p99 must meet the separately approved customer deadline. Payment p99 must be at most 10 minutes after verified payable eligibility, with chain finality time reported separately. These defaults do not override a stricter contract.
  4. No statistically supported positive backlog drift at steady load, no silent drops; after 2W for 15 minutes, drain excess backlog within 30 minutes of return to W. Report rejected demand and accepted-job success separately.
  5. Proposed advertised-tier fairness: at least 90% timely valid assigned completions are paid under the approved rules; avoidable duplicate/retry work is at most 10% of total work. Reassignment policy must bound abandonment without promising every assignment a reward.

Cited by 15 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P08Approved as proposed

Fault assumptions and recovery

  1. F0 must state the exact safety threshold, quorum and authority-transition rule; the synchrony/participation assumptions for liveness; trusted inputs; and clock/expiry semantics. This manual supplies no substitute consensus rule.
  2. Exercise threshold-minus/at/plus cases, the 40/40/20 partition fixture, signing outages and 31/35/60/90 logical-day expiry cases. Preserve safety when liveness assumptions fail; do not demand finality from an unavailable quorum.
  3. After assumptions and input availability are restored: service replacement within 10 minutes and deterministic network convergence within 30 minutes on the reference topology. Different certified bounds must be approved beforehand.
  4. Accelerated-time simulation and real elapsed operation are separate evidence classes. Recovery may not reverse a guarantee previously represented as final.

Cited by 25 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P09Approved as proposed

Security and bounded resource requirements

  1. Zero unresolved critical or high-severity security findings on the claimed release. Independent scopes must cover consensus, proof soundness/parameters, implementation bypasses, wallet/isolation and relevant operational controls.
  2. Review the intended proof-system security level and assumptions explicitly; do not infer a security-bit claim from random rejection tests. Version every verifier, program and parameter set.
  3. Freeze maximum valid/invalid verification time, memory, disk and admission rates for ordinary validator hardware. At rated valid load plus the approved hostile load, no unbounded growth, invalid acceptance or unrecoverable process failure.
  4. For supported wallet fee-estimation cases, proposed absolute error at most 5% versus the specified charge when inputs are unchanged; deterministic fee-cap handling and explicit uncertainty otherwise. Customer contracts remain separately binding.

Cited by 30 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P10Approved as proposed

Ordinary-operator product targets

  1. At least 30 unaffiliated first-time study participants across supported Windows/macOS combinations. At least 90% install, configure safely and submit accepted work without staff help; p90 active setup at most 15 minutes. Publish complete download/dataset time separately.
  2. Pause/stop acknowledgement within 2 seconds, safe worker stop within 5 seconds where no documented atomic operation prevents it, and reliable restoration of original tuning settings. No hidden custody or silent update.
  3. Net-energy/fee displays reconcile within 5% under the declared measurement boundary. Incremental rejected-work loss on the normal home-link profile is at most 2 percentage points over the matched datacentre profile.
  4. Open miner efficiency is within 5% of the best independently tuned permitted implementation on identical work. For the declared single-card payout case, p95 payable-to-payment at most 24 hours and total payout friction at most 2% of earned value.
  5. Critical alerts are emitted within 60 seconds of detectable evidence. At least 90% of study users can identify the injected failure and follow the published safe action. No control target excuses a security failure.

Cited by 11 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P11Approved as proposed

No-founder exercise and independence

  1. At least 10 verified unaffiliated operators, three independently administered network/hosting domains and sufficient honest weight/capacity to satisfy F0 and W after founders are removed.
  2. Run at least 30 real elapsed days without founder mining, proving, aggregation, bootstrap, required RPC, private files or privileged interventions. Cross all known logical transitions separately without calling accelerated time real history.
  3. Document control by role and common dependencies; uncertain identities are not counted as independent. Within-assumption withdrawals must satisfy P08; losing more than the assumed quorum may cause a visible safe pause.

Cited by 4 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P12Approved as proposed

Five-year coexistence envelope

  1. Freeze a sourced revenue reference R and mandatory worlds before results. Sweep 0.25R, R, 4R and 10R; electricity at $0.03/$0.10/$0.25/$0.40 per kWh; 1/3/5-year productive life; zero/$20M/$75M development; private mining and hardware sales; no/normal/spiking external demand.
  2. Those values are proposed stress inputs, not current prices or forecasts. Declare which worlds have enough funded demand for rational ongoing service before running; retain collapse worlds as explicit safety/exit tests, not profitable successes.
  3. Proposed matched-tariff new-entry target in every mandatory sustainable world: median GPU/specialist total cost per accepted work at most 1.5, 90th percentile at most 1.75, and no advertised competitive-core cell above 2.0. Publish every cell, including heterogeneous tariffs.
  4. At least three purchasable GPU configurations across at least two advertised vendors must have positive modelled new-entry economics; at least 75% of the entry cohort must have positive marginal operating economics in those worlds. Report model uncertainty and failure regions.
  5. Do not impose GPU market share, specialist production limits, token appreciation, full research-cost recovery or automatic chip death to force the result. Any such condition must become an explicit limitation rather than a hidden assumption.

Cited by 24 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P13Deferred by the founder

Maintenance continuity

  1. Before a readiness claim, document at least 12 months of committed maintenance resources at the approved operating scope. Include engineering, security review, infrastructure, support and incident response.
  2. Use independently reviewable commitments and downside budgets. Uncommitted future sales, rising token prices, burned fees or assumed fundraising are not available resources.
  3. This is a proposed governance test, not a directive to change the supply cap, issuance allocation or fair-launch design.

Cited by 1 case. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P14Approved as proposed

Genuine commercial and developer proof

  1. At least three unrelated paying buyer organisations, each making at least three separate purchase decisions across at least 30 days; at least 1,000 meaningful verified external jobs in aggregate. Split invoices do not create independent demand.
  2. No project reimbursement, circular funding or undisclosed related party counts. Report customer concentration and churn; proposed maximum largest-buyer share is 70% of qualifying revenue.
  3. At least 20% aggregate contribution margin after directly attributable delivery costs, retries, refunds and support; publish fully loaded economics separately. At least 75% of sampled eligible operators have positive realised contribution on the declared workload.
  4. At least five unaffiliated developers complete a useful supported application or proof-service integration using public documentation. Customer confirmation and raw commercial evidence may remain confidential to the reviewer.

Cited by 10 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P15Approved as proposed

Comparative contention threshold

  1. Pre-register at least three relevant operating GPU-first peers, plus a real proving alternative for customer comparisons. Verify current versions at execution time. The source reference set is a starting point, not a claim about current rankings.
  2. Require at least three meaningful comparable dimensions with no material inferiority beyond a pre-agreed 10% margin against the best valid comparator, and at least two independently evidenced advantages against at least two peers.
  3. Advantages must be either a greater-than-10% measured improvement outside uncertainty or a directly tested control/capability difference with demonstrated user value. Non-comparable or missing data is not a win.
  4. A panel with hardware/economics, security/operations and customer/operator expertise must support the scoped contender conclusion. Passing these judgement-based thresholds does not certify a universal number-one ranking.

Cited by 5 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

P16Approved as proposed

Observed durability and claim freshness

  1. At least 90 real elapsed days on the final compatible release family, at least 30 independently verified operators, and transparent eligibility/churn denominators. Material uncomparable changes reset affected observations.
  2. Proposed outcomes: at least 60% day-90 operator retention and at least 75% of eligible observed operators with positive measured marginal operation over the period. Report incentives and electricity assumptions; do not claim a downturn was observed if it was not.
  3. At least 99.9% availability for the declared customer service during eligible operating conditions, with all-in availability also reported; zero accepted invalid proofs or conflicting finality within F0 assumptions. Do not remove real incidents as maintenance to force a pass.
  4. Run fault injection on isolated infrastructure, not unsuspecting customers. Publish planned test windows separately. Reassess claims at least quarterly and immediately after material hardware, protocol, economics or security changes.

Cited by 5 cases. The profile’s own line in the registry: PROPOSED, REQUIRES APPROVAL.

Fixtures

What every run is built on.

F0

Release and assurance manifest

Exact commits, binaries, genesis/network ID, mining class, dataset schedule, EVM fork/deviations, program/verifier IDs, fees, supply, quorum/fault rules, trust anchors, activation and supported roles.

F1

Clean build environments

Pinned toolchains, dependency locks, clean OS images and documented signing/notarisation boundaries. No production secrets or private founder files.

F2

Hardware and measurement lab

Approved physical GPU cohort, calibrated wall meters, stable thermal conditions, driver/OS images and realistic home/datacentre link conditions.

F3

Workload and oracle catalogue

Fixed full-hash and EVM/proving jobs, independent reference implementations, real customer-sized payloads, held-out seeds and complete expected results.

F4

Authorised fault network

Independent nodes/operators; controllable latency, loss, clocks, partitions, storage faults and role withdrawals. Actual consensus paths plus separately labelled simulators.

F5

Negative and regression corpus

Malformed transactions/proofs, wrong roots/IDs, duplicate payments, bad authority tables, historical failures and deliberately faulty code mutants.

F6

Specialist implementation pack

Functionally checked architectures, RTL/physical estimates where feasible, memory and board assumptions, cost inputs, adaptation paths and uncertainty ranges.

F7

Economic and incentive models

Independently reproducible costs, entry/exit/difficulty policies, scenario grid, operator opportunity costs and money-flow conservation fixtures.

F8

User/customer/peer studies

Consenting unaffiliated users, contracted meaningful workloads, private ownership checks, dated competitor methods and independent analysis.

F9

Evidence and status vault

Immutable run IDs, raw logs, hashes, analysis code, exclusions, defects, reviewers, signatures, privacy controls and public redacted summaries.

What a full pass means

Independent passage of all mandatory and claimed-option gates, including commercial and comparative observation, can support a scoped leadership-contender assessment. It does not prove a universal rank or eliminate unknown future hardware risks.

Test design, not executed evidence. All numeric additions are proposed, not source-approved protocol rules. Optional claimed features require their tests; excluded features earn no pass credit.

Never served: guaranteed chip death, a universal ASIC-efficiency ceiling, chip-arrival probabilities, guaranteed profits, Ethereum security by compatibility, privacy from ZK, a numerical rank.

Source: docs/plans/igneum-2.0-test-registry.json, version 1.0, dated 8 October 2026, plan sha256 418b3b9f68f96a41. This copy was written when the page was built; the page checks the registry on the public git host every 60 seconds.

+ + + +
+ + + + + + + diff --git a/site/address.html b/site/address.html index bc1922448..75ab67bb6 100644 --- a/site/address.html +++ b/site/address.html @@ -157,7 +157,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -197,7 +197,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/api/acceptance.mjs b/site/api/acceptance.mjs new file mode 100644 index 000000000..24e4477b3 --- /dev/null +++ b/site/api/acceptance.mjs @@ -0,0 +1,45 @@ +// The acceptance registry, live. GET /api/acceptance: docs/plans/igneum-2.0-test-registry.json as it stands on master on the +// public git host (git.igneum.network), so /acceptance shows each case as it passes without a redeploy. The page renders its +// build-time copy first and polls this every 60 seconds; it re-renders only when a case state or the registry's source_sha256 +// moves. Cached 60 s in this function instance and at the edge. On any failure the reply is { ok: false, reason } with +// status 200, and the page keeps the copy it has. +export const SOURCE_URL = 'https://git.igneum.network/api/v1/repos/igneum-network/igneum/contents/docs/plans/igneum-2.0-test-registry.json?ref=master'; +export const SOURCE = 'git.igneum.network master'; +export const TTL_MS = 60_000; + +// the git host's contents reply: JSON with a base64 `content` field; the registry must carry its suites +export function decode(reply) { + if (!reply || typeof reply.content !== 'string') throw new Error('the git host reply has no content field'); + const b64 = reply.encoding === 'base64' || !reply.encoding; + const text = b64 ? Buffer.from(reply.content.replace(/\s+/g, ''), 'base64').toString('utf8') : reply.content; + const registry = JSON.parse(text); + if (!registry || !Array.isArray(registry.suites)) throw new Error('the registry has no suites'); + return registry; +} + +export function createHandler({ fetchImpl = globalThis.fetch, now = () => Date.now() } = {}) { + let cache = null; // { at, body }: one per function instance + return async function handler(req, res) { + res.setHeader('Cache-Control', 'public, max-age=30, s-maxage=60, stale-while-revalidate=60'); + res.setHeader('Access-Control-Allow-Origin', '*'); + if (req.method !== 'GET') { res.setHeader('Allow', 'GET'); return res.status(405).json({ ok: false, reason: 'method not allowed' }); } + const t = now(); + if (cache && t - cache.at < TTL_MS) return res.status(200).json(cache.body); + try { + const ctl = typeof AbortController !== 'undefined' ? new AbortController() : null; + const timer = ctl ? setTimeout(() => ctl.abort(), 8000) : null; + let r; + try { r = await fetchImpl(SOURCE_URL, { headers: { accept: 'application/json' }, signal: ctl ? ctl.signal : undefined }); } + finally { if (timer) clearTimeout(timer); } + if (!r.ok) throw new Error(`the git host answered ${r.status}`); + const registry = decode(await r.json()); + const body = { ok: true, fetched_at: new Date(t).toISOString(), source: SOURCE, registry }; + cache = { at: t, body }; + return res.status(200).json(body); + } catch (e) { + res.setHeader('Cache-Control', 'no-store'); + return res.status(200).json({ ok: false, reason: String(e && e.message || e) }); + } + }; +} +export default createHandler(); diff --git a/site/app.html b/site/app.html index 7aba9a632..1f8e683a9 100644 --- a/site/app.html +++ b/site/app.html @@ -125,7 +125,7 @@
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -165,7 +165,7 @@
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/audit.html b/site/audit.html index 76602ec6f..3ee6b2c8f 100644 --- a/site/audit.html +++ b/site/audit.html @@ -130,7 +130,7 @@ table{min-width:560px}
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -170,7 +170,7 @@ table{min-width:560px}
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/block.html b/site/block.html index 6f99a7e83..d96e7565f 100644 --- a/site/block.html +++ b/site/block.html @@ -157,7 +157,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -197,7 +197,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/build.html b/site/build.html index 56c98eaa7..bfc77222a 100644 --- a/site/build.html +++ b/site/build.html @@ -130,7 +130,7 @@ table{min-width:560px}
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -170,7 +170,7 @@ table{min-width:560px}
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/build.mjs b/site/build.mjs index dce1bfbe5..2d0ff5825 100644 --- a/site/build.mjs +++ b/site/build.mjs @@ -7,6 +7,7 @@ import { scrubBench } from './scrub.mjs'; import { MARKS, VENDORS, tokensCss, markHtml } from './lib/marks.mjs'; import { osHtml } from './lib/os-marks.mjs'; import { shareHtml, checkShare } from './og/pages.mjs'; // the share cards and metas, one source for every page (8 October 2026) +import { renderAcceptance } from './lib/acceptance-render.mjs'; // /acceptance, rendered from docs/plans/igneum-2.0-test-registry.json (8 October 2026) import { join, dirname } from 'node:path'; import { fileURLToPath } from 'node:url'; @@ -363,7 +364,7 @@ function injectShare(html, file) { return html.replace('', () => block + '\n'); } -const PAGES = [['index.html', ''], ['download.html', 'download'], ['income.html', 'income'], ['economics.html', 'economics'], ['scorecard.html', 'scorecard'], ['litepaper.html', 'litepaper'], ['live.html', 'live'], ['evidence.html', 'evidence'], ['miner.html', 'miner'], ['app.html', 'app'], ['wallet.html', 'wallet'], ['ledger.html', 'ledger'], ['metamask.html', 'metamask'], ['faucet.html', 'faucet'], ['swap.html', 'swap'], ['404.html', ''], +const PAGES = [['index.html', ''], ['download.html', 'download'], ['income.html', 'income'], ['economics.html', 'economics'], ['scorecard.html', 'scorecard'], ['acceptance.html', 'acceptance'], ['litepaper.html', 'litepaper'], ['live.html', 'live'], ['evidence.html', 'evidence'], ['miner.html', 'miner'], ['app.html', 'app'], ['wallet.html', 'wallet'], ['ledger.html', 'ledger'], ['metamask.html', 'metamask'], ['faucet.html', 'faucet'], ['swap.html', 'swap'], ['404.html', ''], // the Devnet 3 explorer (5 Oct 2026, extended 8 Oct 2026): /explorer, /block/, /address/, /tx/ (vercel.json rewrites // the three) and /proving; the Explorer entry of the Network panel is the current one on all five ['explorer.html', 'explorer'], ['block.html', 'explorer'], ['address.html', 'explorer'], ['tx.html', 'explorer'], ['proving.html', 'explorer'], @@ -419,6 +420,13 @@ for (const [file, active] of PAGES) { .sort((a, b) => b.mh_s - a.mh_s); html = inject(html, 'income-data', ``, file); } + // /acceptance (8 October 2026): the Test and Acceptance Standard, case by case, rendered from the registry by + // site/lib/acceptance-render.mjs (the same functions the page prints into its runtime script, which re-reads the registry on + // the public git host through /api/acceptance every 60 seconds); the gate builds a copy of site/ alone: the committed page stands + if (file === 'acceptance.html' && html.includes('')) { + const rp = join(docs, 'plans', 'igneum-2.0-test-registry.json'); + if (existsSync(rp)) html = inject(html, 'acceptance', renderAcceptance(JSON.parse(readFileSync(rp, 'utf8'))), file); + } writeFileSync(p, html); built.push(file); } diff --git a/site/claims.html b/site/claims.html index a6f97858d..5c7afdcae 100644 --- a/site/claims.html +++ b/site/claims.html @@ -129,7 +129,7 @@
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -169,7 +169,7 @@
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/compatibility.html b/site/compatibility.html index dbb8c0848..d54f4abb8 100644 --- a/site/compatibility.html +++ b/site/compatibility.html @@ -130,7 +130,7 @@ table{min-width:560px}
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -170,7 +170,7 @@ table{min-width:560px}
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/dev-fee.html b/site/dev-fee.html index 31fe2d5fb..33688aa35 100644 --- a/site/dev-fee.html +++ b/site/dev-fee.html @@ -129,7 +129,7 @@
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -169,7 +169,7 @@
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/download.html b/site/download.html index 7bcd1e9ce..2e3a73f43 100644 --- a/site/download.html +++ b/site/download.html @@ -119,7 +119,7 @@
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -159,7 +159,7 @@
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/economics.html b/site/economics.html index b9e192443..6f38c05f9 100644 --- a/site/economics.html +++ b/site/economics.html @@ -103,7 +103,7 @@
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -143,7 +143,7 @@
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/evidence.html b/site/evidence.html index 94596a3e9..8de68c06d 100644 --- a/site/evidence.html +++ b/site/evidence.html @@ -140,7 +140,7 @@ td.mono{font-family:var(--f-mono);font-size:12.5px;min-width:180px}td.iv{color:v
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -180,7 +180,7 @@ td.mono{font-family:var(--f-mono);font-size:12.5px;min-width:180px}td.iv{color:v
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -267,13 +267,13 @@ td.mono{font-family:var(--f-mono);font-size:12.5px;min-width:180px}td.iv{color:v
- - - - - - - + + + + + + +
#ClaimStatusVersion or commitReproducible testResult, date, machineIndependent verification
1The Igneum 2.0 devnet (igneum-devnet-4): genesis 7c36b833 stamped 8 October 2026, chain id 4465 (eth_chainId 0x1171), 18 decimals, every upgrade on from block zero (class v5, the era VDF, finality v3, calibrated fees, enforced proving); the release manifest (/release.json) carries its commits and is regenerated at its first block
This page; the live page; /build
TEAM-REPORTED; activated: the first block f3dc319c at DAA 0, mined at 17:14 UK on 8 October 2026 and accepted on the seed at 17:17the release manifest (/release.json): node 4cdcc488 on release-2.0.0-node, igneum-pow 1c420786, digest be5f4068the node's own start line and its first block (the node lane's read of build-1's seed)8 October 2026, 17:14 UK: the first block f3dc319c at DAA 0 on node 4cdcc488; an earlier object of the same genesis minted at the wrong decimals and is deadnone yet. Packet: parameters the manifest's network block (genesis 7c36b833, digest be5f4068, 18 decimals); procedure the node's start line and eth_getBalance over the public RPC; raw result the first block f3dc319c and the miner's balance 2,535,047,024,800,000,000 wei after it; reproduction none yet; review scope none; unresolved an earlier object of the same genesis is dead and its chain is not served
2Proof verification is enforced in consensus on the Igneum 2.0 devnet from block zero (Deliverable 5's prerequisite): the node's start line reads "consensus proof verification from DAA score 0 (verifier_in_consensus set)" and names the shard program id and the aggregator id; a block carrying a statement without a valid proof is refused
docs/plans/igneum-2.0.md D5; this page; the litepaper (Proving)
TEAM-REPORTED; activated: on from block zero, the chain running since 17:14 UK on 8 October 2026node 4cdcc488 on release-2.0.0-node (the manifest); the program ids are the ELF manifest's (proving/igneum-prove/elf/manifest.json)the node's own start line; the no-rescue exercise itself (D5) is Open8 October 2026: on from block zero in the 2.0 devnet's object, the chain running since 17:14 UK; the earlier devnet ran with the rule off; no block yet refused for a false proof on the recordnone yet. Packet: parameters verifier_in_consensus set from DAA 0, the shard program id 0x2b1a81cb and the aggregator id 0x474678f3 (the ELF manifest); procedure the node's start line; raw result the line itself; reproduction none yet; review scope none; unresolved no hostile submission has yet been refused on the record (D5's exercise)
3The 64-register window per lane costs a GPU under 1 percent of rate at stock, and at most 5 percent per load with the liveness chain
The litepaper (class v6); docs/plans/igneum-2.0.md D1 (the placed 64-register rows)
TEAM-REPORTED; tested by the teamdocs/analysis/class-v6/connected-state.md section 4; docs/design/class-v6-rotating-family.md section 10.0eThe class v5 nvcc harness and the kit worker, both packs on the same card minutes apart, 250 batches of 2^24, nvidia-smi at 1 Hz, vectors PASS on every row (connected-state.md section 4); the per-load rows of the full chain against the base (class-v6-rotating-family.md 10.0e)8 October 2026, rented RTX 5090 (575 W cap) and RTX 4090 (450 W cap) at stock: energy per hash +0.6 percent on the RTX 5090 and -0.9 percent on the RTX 4090, inside the run-to-run noise; under 1 percent of rate; 80 to 87 registers per thread, no spill (all measured). Per load: RTX 5090 16.7 nJ base, 17.6 nJ full chain; RTX 4090 26.0 nJ, 27.0 nJ (measured). The lock row on the project's own rigs is owednone yet. Packet: parameters a rented RTX 5090 and RTX 4090 at stock, the liveness chain, class v4; procedure the hash lane's harness rows in connected-state.md section 4; raw result energy per hash +0.6 percent and -0.9 percent, at most 5 percent per load; reproduction none yet; review scope none; unresolved two cards, one day, no AMD or Apple row
4Reorganising the same work around live state (the connected-state variant, experiment D2(a)) does not reduce a specialised chip's edge: KILL as a class
docs/plans/igneum-2.0.md D2(a); this page
TEAM-REPORTED; tested by the team (a published failure)docs/analysis/class-v6/connected-state.md (the verdict, section 6)The census, liveness and GPU rows in connected-state.md sections 2 to 4; the chip side priced on the drawn program by synthesis (a model, never a lower bound)8 October 2026, verdict 17:25 UK: the window is necessary (63 of 64 registers live at every address, measured) but only its width reaches the chip, +1.2 pJ per lane-op at N5 (synthesised); the window moves the chip's edge 1.10x node for node against a 1.25x gate (modelled); the GPU side +0.6 percent energy per hash on the RTX 5090, -0.9 percent on the RTX 4090 at stock (measured). Rearranging the dependency graph of the same operations moves neither sidenone yet. Packet: parameters the connected-state generator variant behind a flag, the census TSVs; procedure connected-state.md; raw result +1.2 pJ per lane-op at N5 on the chip side, the GPU side unmoved; reproduction none yet; review scope none; unresolved the chip side is modelled, not measured
5"A GPU-secured network for Ethereum-compatible applications and verifiable computation." served on every page
Every page
PROPOSED; designed (served)docs/plans/igneum-2.0.md (the objective: the positioning line)node tools/ci/ledger-text-check.mjs: the sentence pinned (R0) on the home page, the litepaper and this page8 October 2026: on this page; the home page and the litepaper carry it as their 2.0 text lands (designed)none yet. Packet: parameters none (a served sentence); procedure the ledger-text check pins it on every page; raw result the check's count; reproduction not applicable; review scope the three external reviews the founder accepted; unresolved none
6The chip claim as served: "Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes." Under it the three statements, separate: energy ("Current modelling estimates a 1.5x to 3.1x energy-efficiency advantage for the specialised designs assessed as complete machines against the GPU tier, from a board on commodity DRAM at 1.5x to an SRAM-store die at 3.1x (1.5x to 2.3x on the GPU's own node)." Per machine on the same node and a node ahead: the DRAM board 1.5x to 1.6x and 1.8x, the hybrid 1.9x to 2.1x and 2.4x to 2.6x, the die 2.3x and 3.1x; across the adversary's lane-count choice the same-node bracket is 1.5x to 2.1x and a node ahead 1.8x to 2.6x; 3x to 6x per dollar of hardware at list price. MODELLED: the GPU side measured, the chip's core placed and routed, the rest of the machine modelled, no chip measured, hardware cost approximate within 2x), economic and response capability, rotation an optional improvement. Class v5 derives the dataset from chain state; whether that excludes a specialised design is under evaluation (Deliverable 3), since a design that tracks state is not excluded by staleness. The dataset policy (PROPOSED; the genesis size is the founder's decision, pending; no size served as decided): "The dataset’s size is a one-off hardware ticket on specialised designs and a running energy tax on commodity cards: at 4 to 5.5 GiB a locked Blackwell card pays 12 to 14 percent more energy per hash than at 1 GiB (an 8 GB AMD card under 3 percent of rate), while the board on commodity DRAM pays nothing and the SRAM designs pay a hardware cost that does not change their outcome. So the genesis size is the founder’s decision on that scoring, pending (this lane’s recommendation 4 GiB, the largest size that keeps every entry card and a 12 GB card’s mining and proving together), and every later step is scored at 5 percent against it and taken only when the chain’s own state outgrows the dataset, not on a calendar." (PROPOSED; the energy-against-size curve on the litepaper: 1, 2, 4 and 5.5 GiB at stock and at the lock measured on an RTX 5090 against its own 1 GiB control, +0.7 and +4.3 percent at stock, +11.7 and +13.4 at the lock for 4 and 5.5 GiB, the 2 GiB knee cell a paired read in flight; the exclusions by memory; the SRAM tickets modelled). The energy ratio is not the pass criterion: the coexistence model ([docs/analysis/class-v6/coexistence-model.md](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/coexistence-model.md)) is, and its first run's result is served with its conditions: A specialised supplier may earn a normal return; ordinary GPUs remain sufficiently close in total cost, widely obtainable and useful outside mining that new operators can still compete. On today's modelled rows that holds for the chip anyone can build, a stored-dataset board on commodity DRAM, at a productive life of one to three years: its cost per accepted unit of work sits within the range of the best GPU owner and entrant, it passes six of the seven conditions (a third of the network in boards now costs less than a year's revenue at the final hardware price), and a fleet of it holds a minority of the network with GPU entrants still setting the price. For the SRAM-store die the outcome turns on its hardware cost per unit of work, not its energy advantage: at the reconciled machine cost, set by the power train and the shadow core rather than the die, it fails the cost, hardware, fleet and margin conditions at every point of the band, a modest fleet holds about two fifths of a growing network and three fifths of a flat one on arrival and takes every flat or shrinking network within five years, and the only coexistence-shaped outcome is private supply in a growing network; what holds it is the investment decision, since its economics are project economics. A third design, a DRAM board with the hottest half of the dataset in on-board SRAM, sits between the two: it coexists only in a growing network at cheap GPU electricity and fails the cost conditions in a flat or shrinking one, and the dataset's size floor is a real lever on it where it was none on the SRAM die. What holds the die is the investment decision, not the hash; every chip figure here is modelled, not measured, and the chip's hardware cost per unit of work is approximate within 2x.
The litepaper (the chip model)
MODELLED; designed (the bracket modelled; the GPU side tested by the team)docs/design/class-v6-rotating-family.md section 10 (10.0h to 10.0n, 8 October 2026); docs/plans/igneum-2.0.md D3 and D4the scoring rule in the close (the minimum over workloads of the maximum over free adversarial designs of the GPU's joules per hash over the adversary's, under the 10 percent GPU-cost budget at the lock, the verifier limit, cross-vendor correctness and hardware accessibility); the placed rows are D3'sthe GPU side measured: the RTX 5080 at its 1,100 MHz lock 2.06 microjoules per hash and the RTX 5090 at its 1,300 MHz lock 2.33 (8 October 2026, the project's own rigs and rented pods); the chip side synthesised and claimed, its placed gated row pendingnone yet. Packet: parameters the placed full 18-family core on ASAP7, claimed node scaling, the GDDR7 board, the RTX 5090 at its 1,300 MHz lock on class v4; procedure class-v6-rotating-family.md section 10 and coexistence-model.md; raw result the energies and verdicts as served; reproduction none yet; review scope three external reviews of the close, findings taken; unresolved no chip measured, hardware cost approximate within 2x, the k lane's 32-lane placed row pending
7Mining and proving together on one card needs a 16 GB card at the proposed 5.5 GiB dataset (the genesis size is pending the founder’s decision; at a smaller dataset the miner holds less and the rule is not yet measured): the miner holds about 6.1 GiB and a compressed shard proof peaks at about 7.5 GiB, so 8 GB and 12 GB cards time-share (the app pauses the miner for the proof). NVIDIA proves; AMD and Apple mine
The litepaper (Proving, vs RandomX); the miner page
TEAM-REPORTED; tested by the teamdocs/analysis/class-v6/coexist-rows.md (the 5.5 GiB ds55 miner beside igneum-prove-host-0317, compressed at threshold 2^26, the served sm_86 and sm_89 floors)the RESULT rows in that file, verbatim from the runsrented RTX 3060 12 GB: 26.82 MH/s at 117.4 W with 6,129 MiB resident; the compressed shard 13.2 s, peak 7,525 MiB (6,129 + 7,525 = 13,654 MiB against 12,288); rented RTX 4060 8 GB: 18.84 MH/s, 6,116 MiB resident; the shard 8.2 s, peak 7,532 MiB; 8 October 2026none yet. Packet: parameters the 5.5 GiB ds55 miner, igneum-prove-host-0317 compressed at threshold 2^26, sm_86 and sm_89; procedure coexist-rows.md; raw result the RESULT rows verbatim; reproduction none yet; review scope none; unresolved two cards on one day, the 6 October rows stand as 1 GiB-dataset rows
1The Igneum 2.0 devnet (igneum-devnet-4): genesis 7c36b833 stamped 8 October 2026, chain id 4465 (eth_chainId 0x1171), 18 decimals, every upgrade on from block zero (class v5, the era VDF, finality v3, calibrated fees, enforced proving); the release manifest (/release.json) carries its commits and is regenerated at its first block
This page; the live page; /build
TEAM-REPORTED; activated: the first block f3dc319c at DAA 0, mined at 17:14 UK on 8 October 2026 and accepted on the seed at 17:17the release manifest (/release.json): node 4cdcc488 on release-2.0.0-node, igneum-pow 1c420786, digest be5f4068the node's own start line and its first block (the node lane's read of build-1's seed)8 October 2026, 17:14 UK: the first block f3dc319c at DAA 0 on node 4cdcc488; an earlier object of the same genesis minted at the wrong decimals and is dead Case: GOV-01none yet. Packet: parameters the manifest's network block (genesis 7c36b833, digest be5f4068, 18 decimals); procedure the node's start line and eth_getBalance over the public RPC; raw result the first block f3dc319c and the miner's balance 2,535,047,024,800,000,000 wei after it; reproduction none yet; review scope none; unresolved an earlier object of the same genesis is dead and its chain is not served
2Proof verification is enforced in consensus on the Igneum 2.0 devnet from block zero (Deliverable 5's prerequisite): the node's start line reads "consensus proof verification from DAA score 0 (verifier_in_consensus set)" and names the shard program id and the aggregator id; a block carrying a statement without a valid proof is refused
docs/plans/igneum-2.0.md D5; this page; the litepaper (Proving)
TEAM-REPORTED; activated: on from block zero, the chain running since 17:14 UK on 8 October 2026node 4cdcc488 on release-2.0.0-node (the manifest); the program ids are the ELF manifest's (proving/igneum-prove/elf/manifest.json)the node's own start line; the no-rescue exercise itself (D5) is Open8 October 2026: on from block zero in the 2.0 devnet's object, the chain running since 17:14 UK; the earlier devnet ran with the rule off; no block yet refused for a false proof on the record Case: ZKP-01none yet. Packet: parameters verifier_in_consensus set from DAA 0, the shard program id 0x2b1a81cb and the aggregator id 0x474678f3 (the ELF manifest); procedure the node's start line; raw result the line itself; reproduction none yet; review scope none; unresolved no hostile submission has yet been refused on the record (D5's exercise)
3The 64-register window per lane costs a GPU under 1 percent of rate at stock, and at most 5 percent per load with the liveness chain
The litepaper (class v6); docs/plans/igneum-2.0.md D1 (the placed 64-register rows)
TEAM-REPORTED; tested by the teamdocs/analysis/class-v6/connected-state.md section 4; docs/design/class-v6-rotating-family.md section 10.0eThe class v5 nvcc harness and the kit worker, both packs on the same card minutes apart, 250 batches of 2^24, nvidia-smi at 1 Hz, vectors PASS on every row (connected-state.md section 4); the per-load rows of the full chain against the base (class-v6-rotating-family.md 10.0e)8 October 2026, rented RTX 5090 (575 W cap) and RTX 4090 (450 W cap) at stock: energy per hash +0.6 percent on the RTX 5090 and -0.9 percent on the RTX 4090, inside the run-to-run noise; under 1 percent of rate; 80 to 87 registers per thread, no spill (all measured). Per load: RTX 5090 16.7 nJ base, 17.6 nJ full chain; RTX 4090 26.0 nJ, 27.0 nJ (measured). The lock row on the project's own rigs is owed Case: GPU-03none yet. Packet: parameters a rented RTX 5090 and RTX 4090 at stock, the liveness chain, class v4; procedure the hash lane's harness rows in connected-state.md section 4; raw result energy per hash +0.6 percent and -0.9 percent, at most 5 percent per load; reproduction none yet; review scope none; unresolved two cards, one day, no AMD or Apple row
4Reorganising the same work around live state (the connected-state variant, experiment D2(a)) does not reduce a specialised chip's edge: KILL as a class
docs/plans/igneum-2.0.md D2(a); this page
TEAM-REPORTED; tested by the team (a published failure)docs/analysis/class-v6/connected-state.md (the verdict, section 6)The census, liveness and GPU rows in connected-state.md sections 2 to 4; the chip side priced on the drawn program by synthesis (a model, never a lower bound)8 October 2026, verdict 17:25 UK: the window is necessary (63 of 64 registers live at every address, measured) but only its width reaches the chip, +1.2 pJ per lane-op at N5 (synthesised); the window moves the chip's edge 1.10x node for node against a 1.25x gate (modelled); the GPU side +0.6 percent energy per hash on the RTX 5090, -0.9 percent on the RTX 4090 at stock (measured). Rearranging the dependency graph of the same operations moves neither side Case: POW-04none yet. Packet: parameters the connected-state generator variant behind a flag, the census TSVs; procedure connected-state.md; raw result +1.2 pJ per lane-op at N5 on the chip side, the GPU side unmoved; reproduction none yet; review scope none; unresolved the chip side is modelled, not measured
5"A GPU-secured network for Ethereum-compatible applications and verifiable computation." served on every page
Every page
PROPOSED; designed (served)docs/plans/igneum-2.0.md (the objective: the positioning line)node tools/ci/ledger-text-check.mjs: the sentence pinned (R0) on the home page, the litepaper and this page8 October 2026: on this page; the home page and the litepaper carry it as their 2.0 text lands (designed) Case: GOV-08none yet. Packet: parameters none (a served sentence); procedure the ledger-text check pins it on every page; raw result the check's count; reproduction not applicable; review scope the three external reviews the founder accepted; unresolved none
6The chip claim as served: "Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes." Under it the three statements, separate: energy ("Current modelling estimates a 1.5x to 3.1x energy-efficiency advantage for the specialised designs assessed as complete machines against the GPU tier, from a board on commodity DRAM at 1.5x to an SRAM-store die at 3.1x (1.5x to 2.3x on the GPU's own node)." Per machine on the same node and a node ahead: the DRAM board 1.5x to 1.6x and 1.8x, the hybrid 1.9x to 2.1x and 2.4x to 2.6x, the die 2.3x and 3.1x; across the adversary's lane-count choice the same-node bracket is 1.5x to 2.1x and a node ahead 1.8x to 2.6x; 3x to 6x per dollar of hardware at list price. MODELLED: the GPU side measured, the chip's core placed and routed, the rest of the machine modelled, no chip measured, hardware cost approximate within 2x), economic and response capability, rotation an optional improvement. Class v5 derives the dataset from chain state; whether that excludes a specialised design is under evaluation (Deliverable 3), since a design that tracks state is not excluded by staleness. The dataset policy (PROPOSED; the genesis size is the founder's decision, pending; no size served as decided): "The dataset’s size is a one-off hardware ticket on specialised designs and a running energy tax on commodity cards: at 4 to 5.5 GiB a locked Blackwell card pays 12 to 14 percent more energy per hash than at 1 GiB (an 8 GB AMD card under 3 percent of rate), while the board on commodity DRAM pays nothing and the SRAM designs pay a hardware cost that does not change their outcome. So the genesis size is the founder’s decision on that scoring, pending (this lane’s recommendation 4 GiB, the largest size that keeps every entry card and a 12 GB card’s mining and proving together), and every later step is scored at 5 percent against it and taken only when the chain’s own state outgrows the dataset, not on a calendar." (PROPOSED; the energy-against-size curve on the litepaper: 1, 2, 4 and 5.5 GiB at stock and at the lock measured on an RTX 5090 against its own 1 GiB control, +0.7 and +4.3 percent at stock, +11.7 and +13.4 at the lock for 4 and 5.5 GiB, the 2 GiB knee cell a paired read in flight; the exclusions by memory; the SRAM tickets modelled). The energy ratio is not the pass criterion: the coexistence model ([docs/analysis/class-v6/coexistence-model.md](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/coexistence-model.md)) is, and its first run's result is served with its conditions: A specialised supplier may earn a normal return; ordinary GPUs remain sufficiently close in total cost, widely obtainable and useful outside mining that new operators can still compete. On today's modelled rows that holds for the chip anyone can build, a stored-dataset board on commodity DRAM, at a productive life of one to three years: its cost per accepted unit of work sits within the range of the best GPU owner and entrant, it passes six of the seven conditions (a third of the network in boards now costs less than a year's revenue at the final hardware price), and a fleet of it holds a minority of the network with GPU entrants still setting the price. For the SRAM-store die the outcome turns on its hardware cost per unit of work, not its energy advantage: at the reconciled machine cost, set by the power train and the shadow core rather than the die, it fails the cost, hardware, fleet and margin conditions at every point of the band, a modest fleet holds about two fifths of a growing network and three fifths of a flat one on arrival and takes every flat or shrinking network within five years, and the only coexistence-shaped outcome is private supply in a growing network; what holds it is the investment decision, since its economics are project economics. A third design, a DRAM board with the hottest half of the dataset in on-board SRAM, sits between the two: it coexists only in a growing network at cheap GPU electricity and fails the cost conditions in a flat or shrinking one, and the dataset's size floor is a real lever on it where it was none on the SRAM die. What holds the die is the investment decision, not the hash; every chip figure here is modelled, not measured, and the chip's hardware cost per unit of work is approximate within 2x.
The litepaper (the chip model)
MODELLED; designed (the bracket modelled; the GPU side tested by the team)docs/design/class-v6-rotating-family.md section 10 (10.0h to 10.0n, 8 October 2026); docs/plans/igneum-2.0.md D3 and D4the scoring rule in the close (the minimum over workloads of the maximum over free adversarial designs of the GPU's joules per hash over the adversary's, under the 10 percent GPU-cost budget at the lock, the verifier limit, cross-vendor correctness and hardware accessibility); the placed rows are D3'sthe GPU side measured: the RTX 5080 at its 1,100 MHz lock 2.06 microjoules per hash and the RTX 5090 at its 1,300 MHz lock 2.33 (8 October 2026, the project's own rigs and rented pods); the chip side synthesised and claimed, its placed gated row pending Case: ADV-01none yet. Packet: parameters the placed full 18-family core on ASAP7, claimed node scaling, the GDDR7 board, the RTX 5090 at its 1,300 MHz lock on class v4; procedure class-v6-rotating-family.md section 10 and coexistence-model.md; raw result the energies and verdicts as served; reproduction none yet; review scope three external reviews of the close, findings taken; unresolved no chip measured, hardware cost approximate within 2x, the k lane's 32-lane placed row pending
7Mining and proving together on one card needs a 16 GB card at the proposed 5.5 GiB dataset (the genesis size is pending the founder’s decision; at a smaller dataset the miner holds less and the rule is not yet measured): the miner holds about 6.1 GiB and a compressed shard proof peaks at about 7.5 GiB, so 8 GB and 12 GB cards time-share (the app pauses the miner for the proof). NVIDIA proves; AMD and Apple mine
The litepaper (Proving, vs RandomX); the miner page
TEAM-REPORTED; tested by the teamdocs/analysis/class-v6/coexist-rows.md (the 5.5 GiB ds55 miner beside igneum-prove-host-0317, compressed at threshold 2^26, the served sm_86 and sm_89 floors)the RESULT rows in that file, verbatim from the runsrented RTX 3060 12 GB: 26.82 MH/s at 117.4 W with 6,129 MiB resident; the compressed shard 13.2 s, peak 7,525 MiB (6,129 + 7,525 = 13,654 MiB against 12,288); rented RTX 4060 8 GB: 18.84 MH/s, 6,116 MiB resident; the shard 8.2 s, peak 7,532 MiB; 8 October 2026 Case: GPU-05none yet. Packet: parameters the 5.5 GiB ds55 miner, igneum-prove-host-0317 compressed at threshold 2^26, sm_86 and sm_89; procedure coexist-rows.md; raw result the RESULT rows verbatim; reproduction none yet; review scope none; unresolved two cards on one day, the 6 October rows stand as 1 GiB-dataset rows

Click a column heading to sort; click again to reverse. Versions: the Igneum 2.0 devnet (igneum-devnet-4) runs since its first block at 17:14 UK on 8 October 2026; the release manifest, machine-readable, is regenerated at its first block and fills these at build time. As last read it names node 4cdcc488 on release-2.0.0-node, igneum-pow 1c420786, chain id 4465, read 8 October 2026, 17:2x UK. The labels stay distinct: a claim never moves up a label without the artefact the next table names. The public reference repository exists (the specifications, the pow crate, the simulators and the test material, at git.igneum.network); the full node, the miner and the proving code open later, so a row that cites them is tested by the team at most until they do. Node fork commits are the node fork’s; a document path is the repository’s. The source of this page is docs/evidence.md in the repository.

What would move a row

diff --git a/site/explorer.html b/site/explorer.html index 6bb755033..460d30a1b 100644 --- a/site/explorer.html +++ b/site/explorer.html @@ -156,7 +156,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -196,7 +196,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/faucet.html b/site/faucet.html index 0ec0229c9..91e5e09c9 100644 --- a/site/faucet.html +++ b/site/faucet.html @@ -133,7 +133,7 @@ dt{color:var(--ash)}dd{margin:0;font-family:var(--f-mono);font-size:14px;overflo
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -173,7 +173,7 @@ dt{color:var(--ash)}dd{margin:0;font-family:var(--f-mono);font-size:14px;overflo
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/grants.html b/site/grants.html index 54fd682b2..9ce0a40b0 100644 --- a/site/grants.html +++ b/site/grants.html @@ -130,7 +130,7 @@ table{min-width:560px}
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -170,7 +170,7 @@ table{min-width:560px}
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/income.html b/site/income.html index c41983a0f..2e1e32e79 100644 --- a/site/income.html +++ b/site/income.html @@ -103,7 +103,7 @@
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -143,7 +143,7 @@
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/index.html b/site/index.html index 3997b7458..5c44e641f 100644 --- a/site/index.html +++ b/site/index.html @@ -121,7 +121,7 @@
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -161,7 +161,7 @@
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/ledger.html b/site/ledger.html index a95060e7d..b8b708544 100644 --- a/site/ledger.html +++ b/site/ledger.html @@ -134,7 +134,7 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -174,7 +174,7 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
Learn
LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/lib/acceptance-render.mjs b/site/lib/acceptance-render.mjs new file mode 100644 index 000000000..631ce5e71 --- /dev/null +++ b/site/lib/acceptance-render.mjs @@ -0,0 +1,471 @@ +// The /acceptance page (8 October 2026): the Test and Acceptance Standard 1.0, case by case, rendered from ONE file, +// docs/plans/igneum-2.0-test-registry.json (128 cases in 16 suites, the profiles P00 onward, the fixtures F0 onward). +// +// One source of truth for both renders. Every function below is a plain, self-contained function declaration: site/build.mjs +// imports them to write the page at build time, and runtimeSource() prints the same functions (Function.prototype.toString) +// into the page's inline classic script, which polls /api/acceptance every 60 seconds and re-renders the page from the +// registry on the public git host when a case status or the registry's source_sha256 moves. Nothing here may reference a +// module-level binding: each function carries its own constants, so the printed copy runs unchanged in the browser. +// +// The states are the standard's words (section 02, execution rules): NOT RUN, BLOCKED, FAIL, PASS, plus RUNNING while a +// packet is being produced, and EXCLUDED for an excluded optional feature (never PASS, never counted as an achievement). +// A gate reads FAIL if any case it depends on is FAIL, else BLOCKED if any is BLOCKED, else RUNNING if any is RUNNING, else +// PASS only when every case is PASS, else NOT RUN. The page is a checklist, never a completion dashboard: no percentage. + +// the build-time constants the founder's approval of 8 October 2026 sets, used only where the registry does not carry the +// approval block yet (reg.approval {by, at, word, profiles {P00..P16}, rules_in_force}); the approver is always printed as +// "the founder", never a name. The P04 line is the coordinator's verbatim wording and is never softened. +function overrides() { + return { + approval: { word: 'APPROVED AS PROPOSED', date: '2026-10-08' }, + profiles: { all: 'APPROVED AS PROPOSED', P13: 'DEFERRED' }, + notes: { P04: 'R_E target at most 1.5 at the same node and one node ahead; today\'s placed bracket 1.5x to 2.1x: FAIL' }, + }; +} + +// a profile's approval word: the registry's approval block, else the profile's own status when it carries a decision, else +// the build-time constant +function profileWord(reg, id) { + var a = reg && reg.approval && reg.approval.profiles; + if (a && a[id]) return String(a[id]).toUpperCase(); + var raw = String(reg && reg.profiles && reg.profiles[id] && reg.profiles[id].status || ''); + if (/DEFERRED/i.test(raw)) return 'DEFERRED'; + if (/APPROVED/i.test(raw) && !/REQUIRES APPROVAL/i.test(raw)) return raw.toUpperCase(); + var o = overrides().profiles; + return o[id] || o.all; +} + +// an anchor's opening, without its closing bracket: the target escaped; the attribute name is split so the site's link +// check (which reads every href in a page, scripts included) does not take this concatenation for a literal target +function linkOpen(u) { + return '/g, '>').replace(/"/g, '"'); +} + +// registry text as served: no em dash (a comma), no spaced hyphen as a dash (a comma), escaped +function clean(s) { + return esc(String(s == null ? '' : s).replace(/\s*\u2014\s*/g, ', ').replace(/\s+-\s+/g, ', ').replace(/,\s*,/g, ',')); +} + +function fmtDate(iso) { + var m = /^(\d{4})-(\d{2})-(\d{2})/.exec(String(iso || '')); + if (!m) return clean(iso); + var MON = ['January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December']; + return Number(m[3]) + ' ' + MON[Number(m[2]) - 1] + ' ' + m[1]; +} + +// a time as UK wall time (the site's rule: times read in UK time); a value that is not a time is shown as written +function fmtWhen(v) { + if (!v) return ''; + var d = new Date(v); + if (isNaN(d.getTime()) || !/\d{4}-\d{2}-\d{2}T/.test(String(v))) return clean(v); + try { + return esc(d.toLocaleString('en-GB', { timeZone: 'Europe/London', day: 'numeric', month: 'short', year: 'numeric', hour: '2-digit', minute: '2-digit', hour12: false })) + ' UK'; + } catch (e) { return esc(d.toISOString().slice(0, 16).replace('T', ' ')) + ' UTC'; } +} + +// a case's state in the standard's words; an unknown word is BLOCKED (P00: unknown values are BLOCKED, not defaults) +function normStatus(s) { + var t = String(s == null ? '' : s).trim().toUpperCase().replace(/[_-]+/g, ' '); + if (t === '' || t === 'NOT RUN' || t === 'NOTRUN') return 'NOT RUN'; + if (t === 'PASS' || t === 'PASSED') return 'PASS'; + if (t === 'FAIL' || t === 'FAILED') return 'FAIL'; + if (t === 'BLOCKED') return 'BLOCKED'; + if (t === 'RUNNING' || t === 'IN PROGRESS') return 'RUNNING'; + if (t === 'EXCLUDED') return 'EXCLUDED'; + if (t === 'DEFERRED') return 'DEFERRED'; + return 'BLOCKED'; +} + +// the run state: run_status, else the design status (the registry before the run fields existed), else result.status +function caseStatus(t) { + if (!t) return 'NOT RUN'; + if (t.run_status != null) return normStatus(t.run_status); + return normStatus(t.status != null ? t.status : (t.result && t.result.status)); +} + +// the evidence link a case carries once it has run: evidence_path (a repository path, linked on the public git host), else +// evidence_url, evidence_link or result.evidence(_url); https or site-relative only +function caseEvidenceUrl(t) { + if (!t) return null; + var p = t.evidence_path; + if (typeof p === 'string' && /^[A-Za-z0-9._\/-]+$/.test(p) && p.indexOf('..') < 0) return 'https://git.igneum.network/igneum-network/igneum/src/branch/master/' + p.replace(/^\/+/, ''); + var r = t.result || {}; + var cands = [t.evidence_url, t.evidence_link, r.evidence_url, r.evidence_link, r.evidence]; + for (var i = 0; i < cands.length; i++) { + var u = cands[i]; + if (typeof u === 'string' && (/^https:\/\/[^\s"'<>]+$/.test(u) || /^\/[^\s"'<>]*$/.test(u))) return u; + } + return null; +} + +function caseLastRun(t) { + var r = (t && t.result) || {}; + return (t && (t.updated || t.last_run || t.last_run_at || t.run_at)) || r.at || r.run_at || r.date || null; +} + +function profilesOf(t) { + return String(t && t.profile || '').split(/;\s*/).map(function (x) { return x.trim(); }).filter(Boolean); +} + +function allCases(reg) { + var out = []; + (reg && reg.suites || []).forEach(function (s) { (s.tests || []).forEach(function (t) { out.push(t); }); }); + return out; +} + +function tally(cases) { + var c = { total: 0, PASS: 0, FAIL: 0, BLOCKED: 0, RUNNING: 0, 'NOT RUN': 0, DEFERRED: 0, EXCLUDED: 0 }; + cases.forEach(function (t) { c.total++; c[caseStatus(t)]++; }); + return c; +} + +// the counts, in the standard's words; deferred and excluded cases are counted apart and never as passes +function countStatuses(reg) { + return tally(allCases(reg)); +} + +// a gate or suite state: FAIL, else BLOCKED, else RUNNING, else PASS when every case (excluded ones aside) passed, else NOT RUN; +// a deferred case is not a pass, so it holds its gate at NOT RUN +function stateOf(cases) { + var st = cases.map(caseStatus).filter(function (s) { return s !== 'EXCLUDED'; }); + if (!st.length) return 'NOT RUN'; + if (st.indexOf('FAIL') >= 0) return 'FAIL'; + if (st.indexOf('BLOCKED') >= 0) return 'BLOCKED'; + if (st.indexOf('RUNNING') >= 0) return 'RUNNING'; + if (st.every(function (s) { return s === 'PASS'; })) return 'PASS'; + return 'NOT RUN'; +} + +// the standard's section 04: G1 to G5 keep the plan's names (the deliverables D1 to D5 by number); G0, technical readiness, +// commercial evidence and the contender decision are its proposed execution controls +function gateDefs() { + return [ + { id: 'G0', name: 'Freeze', d: 'Release identity', consequence: 'No formal run or public pass before approval.' }, + { id: 'G1', name: 'Baseline', d: 'D1', consequence: 'No validated hardware claim without reproduction.' }, + { id: 'G2', name: 'Experiments', d: 'D2', consequence: 'No improvement claim from a negative hypothesis.' }, + { id: 'G3', name: 'Adversary', d: 'D3', consequence: 'No broad resistance claim from one weak design.' }, + { id: 'G4', name: 'Coexistence', d: 'D4', consequence: 'No durability claim based on assumed chip expiry.' }, + { id: 'G5', name: 'No rescue', d: 'D5', consequence: 'No no-rescue claim from a founder-supported demo.' }, + { id: 'TR', name: 'Technical readiness', d: 'Execution control', consequence: 'No mainnet-ready claim with missing enforcement or safety.' }, + { id: 'CE', name: 'Commercial evidence', d: 'Execution control', consequence: 'Devnet activity is insufficient.' }, + { id: 'CD', name: 'Leadership-contender decision', d: 'Execution control', consequence: 'Supports a scoped contention assessment, not a guaranteed rank.' }, + ]; +} + +// a suite's "gate" string to the gates it names: "G0 / all gates" names G0 and every gate; "G2 / G3" names both; the +// readiness, commercial and leadership words name the execution controls; the contender decision rests on all of them +function gatesOf(gate) { + var g = String(gate || ''), out = []; + var re = /\bG([0-5])\b/g, m; + while ((m = re.exec(g))) if (out.indexOf('G' + m[1]) < 0) out.push('G' + m[1]); + if (/all gates/i.test(g)) ['G0', 'G1', 'G2', 'G3', 'G4', 'G5', 'TR', 'CE'].forEach(function (x) { if (out.indexOf(x) < 0) out.push(x); }); + if (/technical readiness|operator readiness/i.test(g) && out.indexOf('TR') < 0) out.push('TR'); + if (/commercial/i.test(g) && out.indexOf('CE') < 0) out.push('CE'); + if (out.indexOf('CD') < 0) out.push('CD'); + return out; +} + +function stateClass(s) { + return { 'PASS': 'pass', 'FAIL': 'fail', 'BLOCKED': 'blocked', 'RUNNING': 'running', 'NOT RUN': 'notrun', 'DEFERRED': 'deferred', 'EXCLUDED': 'excluded' }[s] || 'notrun'; +} + +function chipHtml(state) { + var s = normStatus(state); + return '' + s + ''; +} + +// the thin segmented bar: one segment per state, its width the count of cases in that state; the numbers sit beside it +function barHtml(c, label) { + var order = ['PASS', 'FAIL', 'BLOCKED', 'RUNNING', 'NOT RUN', 'DEFERRED', 'EXCLUDED']; + var segs = order.filter(function (o) { return c[o] > 0; }).map(function (o) { + return ''; + }).join(''); + return ''; +} + +// the counts as one line, in the coordinator's words: passed under the standard, running with team evidence, failed and blocked +// when non-zero, not run, deferred +function tallyText(c) { + var parts = [c.PASS + ' passed under the standard', c.RUNNING + ' running with team evidence']; + if (c.FAIL) parts.push(c.FAIL + ' failed'); + if (c.BLOCKED) parts.push(c.BLOCKED + ' blocked'); + parts.push(c['NOT RUN'] + ' not run'); + parts.push(c.DEFERRED + ' deferred'); + if (c.EXCLUDED) parts.push(c.EXCLUDED + ' excluded'); + return c.total + ' cases: ' + parts.join(', '); +} + +function tallyHtml(c) { + var rows = [['PASS', 'pass'], ['FAIL', 'fail'], ['BLOCKED', 'blocked'], ['RUNNING', 'running'], ['NOT RUN', 'not run'], ['DEFERRED', 'deferred']]; + if (c.EXCLUDED) rows.push(['EXCLUDED', 'excluded']); + return '
    ' + rows.map(function (r) { + return '
  • ' + c[r[0]] + ' ' + r[1] + '
    • '; + }).join('') + '
'; +} + +// the header's status words: the approval (the registry's approval block, else its status string when it says APPROVED, else the +// build-time constant), the deferred profiles, and NOT EXECUTED while no case has run +function statusWords(reg) { + var raw = String(reg && reg.status || ''), a = (reg && reg.approval) || {}, o = overrides(); + var c = countStatuses(reg); + var fileApproved = !!a.word || (/APPROVED/i.test(raw) && !/REQUIRES APPROVAL/i.test(raw)); + var word = a.word ? String(a.word).toUpperCase() : o.approval.word; + var dm = /(\d{4}-\d{2}-\d{2})/.exec(String(a.at || '')) || (fileApproved ? /(\d{4}-\d{2}-\d{2})/.exec(String(reg.approved_date || reg.date || '')) : null); + var date = dm ? dm[1] : o.approval.date; + var deferred = Object.keys(reg && reg.profiles || {}).filter(function (id) { return /DEFERRED/.test(profileWord(reg, id)); }); + var ran = c.PASS + c.FAIL + c.BLOCKED + c.RUNNING; + return { raw: raw, word: word, date: date, fromFile: fileApproved, deferred: deferred, execution: ran ? null : 'NOT EXECUTED' }; +} + +// the header line, verbatim in the coordinator's words with the counts read from the file +function headLine(reg) { + var w = statusWords(reg), c = countStatuses(reg); + var title = String(reg.title || 'Test and Acceptance Standard').replace(/^IGNEUM 2\.0\s*-\s*/i, ''); + var defs = w.deferred.map(function (id) { + var t = reg.profiles[id] && reg.profiles[id].title ? String(reg.profiles[id].title).toLowerCase() : ''; + return id + (t ? ' (' + t + ')' : '') + ' DEFERRED'; + }); + return title + ' ' + (reg.version || '') + ': ' + w.word + ' by the founder, ' + fmtDate(w.date).replace(/&/g, '&') + '; ' + (defs.length ? defs.join('; ') + '; ' : '') + tallyText(c); +} + +function headHtml(reg) { + var title = String(reg.title || 'Test and Acceptance Standard').replace(/^IGNEUM 2\.0\s*-\s*/i, ''); + var w = statusWords(reg), c = countStatuses(reg); + return '
' + + '
Igneum 2.0 acceptance
' + + '

' + clean(title) + ' ' + clean(reg.version) + '

' + + '

Every case of the standard, shown as it is run, in the standard’s own words. A checklist, never a completion score: a gate passes only when every case it depends on has passed.

' + + '

Basis ' + clean(reg.basis) + '. ' + (reg.manual_page_count ? 'The standard runs to ' + esc(reg.manual_page_count) + ' pages. ' : '') + 'Registry dated ' + fmtDate(reg.date) + '.

' + + '
' + + '
' + esc(w.word) + ' ' + esc(fmtDate(w.date).toUpperCase()) + '' + + w.deferred.map(function (id) { return '' + esc(id) + ' DEFERRED'; }).join('') + + (w.execution ? '' + esc(w.execution) + '' : '') + '
' + + '

' + clean(headLine(reg)) + '

' + + barHtml(c, tallyText(c)) + tallyHtml(c) + + '
' + + '
'; +} + +function gateCardHtml(def, reg, small) { + var suites = (reg.suites || []).filter(function (s) { return gatesOf(s.gate).indexOf(def.id) >= 0; }); + var cases = []; + suites.forEach(function (s) { (s.tests || []).forEach(function (t) { cases.push(t); }); }); + var st = stateOf(cases), c = tally(cases); + var list = suites.map(function (s) { + return '
  • ' + linkOpen('#suite-' + s.code) + '>' + esc(s.code) + '' + (s.tests || []).length + ' cases' + chipHtml(stateOf(s.tests || [])) + '
    • '; + }).join(''); + return '
    ' + + '
    ' + (/^G[0-5]$/.test(def.id) ? def.id : '') + '' + chipHtml(st) + '
    ' + + '

    ' + esc(def.name) + '

    ' + + '

    ' + esc(def.d) + '

    ' + + '

    ' + esc(def.consequence) + '

    ' + + barHtml(c, def.name + ': ' + tallyText(c)) + + '

    ' + esc(tallyText(c)) + '

    ' + + (list ? '
      ' + list + '
    ' : '

    No suite names this gate.

    ') + + '
    '; +} + +function gatesHtml(reg) { + var d = gateDefs(); + var g0 = d.filter(function (x) { return x.id === 'G0'; })[0]; + var five = d.filter(function (x) { return /^G[1-5]$/.test(x.id); }); + var tracks = d.filter(function (x) { return /^(TR|CE|CD)$/.test(x.id); }); + return '
    ' + + '
    The gates
    ' + + '

    Five gates, and the freeze before them.

    ' + + '

    A gate reads NOT RUN until every case it depends on has run, RUNNING while any is running, BLOCKED if any is blocked, FAIL if any fails, and PASS only when every case passes. No gate is weighted into an average.

    ' + + '
    ' + gateCardHtml(g0, reg, true) + '
    ' + + '
    ' + five.map(function (x) { return gateCardHtml(x, reg, false); }).join('') + '
    ' + + '

    The three named gates

    ' + + '
    ' + tracks.map(function (x) { return gateCardHtml(x, reg, true); }).join('') + '
    ' + + '
    '; +} + +function caseHtml(t) { + var st = caseStatus(t), ev = caseEvidenceUrl(t), run = caseLastRun(t), er = t.evidence_record; + var steps = (t.steps || []).map(function (s) { return '
  • ' + clean(s) + '
    • '; }).join(''); + var meta = []; + if (t.method) meta.push('
    Method
    ' + clean(t.method) + '
    '); + if (t.cadence) meta.push('
    Cadence
    ' + clean(t.cadence) + '
    '); + if (t.owner || t.owner_lane) meta.push('
    Owner
    ' + clean(t.owner_lane || t.owner) + '
    '); + if (t.run_id) meta.push('
    Run
    ' + clean(t.run_id) + '
    '); + if (t.run_status != null && t.status) meta.push('
    Design status
    ' + clean(t.status) + '
    '); + if (t.manual_page) meta.push('
    Standard page
    ' + esc(t.manual_page) + '
    '); + if (t.source && t.source.length) meta.push('
    Plan pages
    ' + esc([].concat(t.source).join(', ')) + '
    '); + var rec = ''; + if (er && typeof er === 'object') { + var F = [['what_was_run', 'What was run'], ['run_by', 'Run by'], ['under_the_standard', 'Under the standard'], ['pass_or_fail_today', 'Pass or fail today']]; + var rows = F.filter(function (f) { return er[f[0]] != null && er[f[0]] !== ''; }).map(function (f) { return '
    ' + f[1] + '
    ' + clean(er[f[0]]) + '
    '; }); + if (rows.length) rec = '

    Evidence record of the run

    ' + rows.join('') + '
    '; + } + return '
    ' + + '' + + '' + esc(t.id) + '' + + '' + clean(t.title) + '' + + 'Priority ' + clean(t.priority) + '' + + 'Profile ' + (profilesOf(t).map(function (p) { return esc(p); }).join(', ') || 'none') + '' + + '' + chipHtml(st) + '' + + 'Evidence ' + (ev ? linkOpen(ev) + (/^https:/.test(ev) ? ' rel="noopener"' : '') + '>record' : 'none yet') + '' + + 'Last run ' + (run ? fmtWhen(run) : 'none yet') + '' + + '' + + '' + + '
    ' + + '

    Setup

    ' + clean(t.setup) + '

    ' + + '

    Steps

      ' + steps + '
    ' + + '

    Accept

    ' + clean(t.accept) + '

    ' + + '

    Evidence the case requires

    ' + clean(t.evidence || 'not stated') + '

    ' + + '
    ' + + rec + + (meta.length ? '
    ' + meta.join('') + '
    ' : '') + + '
    ' + + '
    '; +} + +function suiteHtml(s, i) { + var cases = s.tests || [], c = tally(cases); + var gates = gatesOf(s.gate).filter(function (g) { return /^G[0-5]$/.test(g); }); + return '
    ' + + '
    ' + + '
    ' + (i + 1 < 10 ? '0' : '') + (i + 1) + '' + esc(s.code) + '
    ' + + '

    ' + clean(s.title) + '

    ' + (s.summary ? '

    ' + clean(s.summary) + '

    ' : '') + '
    ' + + '
    ' + chipHtml(stateOf(cases)) + '
    ' + + '
    ' + + '
    ' + + '
    Owner
    ' + clean(s.owner || 'not named') + '
    ' + + '
    Gate
    ' + clean(s.gate) + (gates.length ? ' ' + gates.map(function (g) { return linkOpen('#gate-' + g) + '>' + g + ''; }).join(' ') + '' : '') + '
    ' + + (s.fixtures ? '
    Fixtures
    ' + clean(s.fixtures) + '
    ' : '') + + (s.source && s.source.length ? '
    Plan pages
    ' + esc([].concat(s.source).join(', ')) + '
    ' : '') + + '
    ' + + '
    ' + barHtml(c, s.code + ': ' + tallyText(c)) + '' + esc(tallyText(c)) + '
    ' + + '
    ' + + '' + + cases.map(caseHtml).join('') + + '
    ' + + '
    '; +} + +function profileHtml(id, p, reg) { + var o = overrides(), raw = String(p.status || ''), word = profileWord(reg, id); + var used = allCases(reg).filter(function (t) { return profilesOf(t).indexOf(id) >= 0; }).length; + var deferred = /DEFERRED/.test(word), cls = deferred ? 'deferred' : (/APPROVED/.test(word) ? 'approved' : 'proposed'); + var text = deferred ? 'Deferred by the founder' : (/APPROVED AS PROPOSED/.test(word) ? 'Approved as proposed' : (/APPROVED/.test(word) ? 'Approved' : clean(word))); + var note = o.notes[id]; + return '
    ' + + '
    ' + esc(id) + '' + text + '
    ' + + '

    ' + clean(p.title) + '

    ' + + '
      ' + (p.requirements || []).map(function (r) { return '
    1. ' + clean(r) + '
      2. '; }).join('') + '
    ' + + (note ? '

    ' + chipHtml('FAIL') + ' ' + esc(note) + '

    ' : '') + + '

    Cited by ' + used + ' case' + (used === 1 ? '' : 's') + '. ' + (raw ? 'The profile’s own line in the registry: ' + clean(raw) + '.' : '') + '

    ' + + '
    '; +} + +function profilesHtml(reg) { + var ps = reg.profiles || {}; + var ids = Object.keys(ps); + return '
    ' + + '
    Profiles
    ' + + '

    The numbers each case is held to.

    ' + + '

    ' + ids.length + ' profiles, P00 to P' + (ids.length - 1 < 10 ? '0' : '') + (ids.length - 1) + '. A profile is frozen before the confirmatory run; weakening a target after a failure creates a different claim.

    ' + + '
    ' + ids.map(function (id) { return profileHtml(id, ps[id], reg); }).join('') + '
    ' + + '
    '; +} + +function fixturesHtml(reg) { + var fs = reg.fixtures || []; + if (!fs.length) return ''; + return '
    ' + + '
    Fixtures
    ' + + '

    What every run is built on.

    ' + + '
    ' + fs.map(function (f) { + return '
    ' + esc(f.id) + '

    ' + clean(f.title) + '

    ' + clean(f.contents) + '

    '; + }).join('') + '
    ' + + '
    '; +} + +function footHtml(reg) { + var rules = reg.approval && reg.approval.rules_in_force; + var rulesHtml = ''; + if (Array.isArray(rules) && rules.length) rulesHtml = '

    Rules in force

      ' + rules.map(function (r) { return '
    • ' + clean(typeof r === 'string' ? r : JSON.stringify(r)) + '
      • '; }).join('') + '
    '; + else if (typeof rules === 'string' && rules) rulesHtml = '

    Rules in force

    ' + clean(rules) + '

    '; + return '
    ' + + '
    What a full pass means
    ' + + (reg.all_pass_note ? '

    ' + clean(reg.all_pass_note) + '

    ' : '') + + (reg.scope_note ? '

    ' + clean(reg.scope_note) + '

    ' : '') + + rulesHtml + + '

    Never served: guaranteed chip death, a universal ASIC-efficiency ceiling, chip-arrival probabilities, guaranteed profits, Ethereum security by compatibility, privacy from ZK, a numerical rank.

    ' + + '

    Source: docs/plans/igneum-2.0-test-registry.json, version ' + clean(reg.version) + ', dated ' + fmtDate(reg.date) + (reg.source_sha256 ? ', plan sha256 ' + esc(String(reg.source_sha256).slice(0, 16)) + '' : '') + '. This copy was written when the page was built; the page checks the registry on the public git host every 60 seconds.

    ' + + '
    '; +} + +function suiteNavHtml(reg) { + return ''; +} + +// the page body inside #acc-root (the same at build and at runtime) +function renderBody(reg) { + return headHtml(reg) + suiteNavHtml(reg) + gatesHtml(reg) + + (reg.suites || []).map(function (s, i) { return suiteHtml(s, i); }).join('') + + profilesHtml(reg) + fixturesHtml(reg) + footHtml(reg); +} + +// a key that moves when any case's state, evidence or run time moves +function statusKey(reg) { + return String(reg && reg.source_sha256 || '') + '|' + String(reg && reg.status || '') + '|' + allCases(reg).map(function (t) { + return t.id + ':' + caseStatus(t) + ':' + (caseEvidenceUrl(t) || '') + ':' + (caseLastRun(t) || ''); + }).join(','); +} + +// the runtime: read the build-time copy, poll /api/acceptance every 60 seconds, re-render in place when the key moves, +// keeping the open cases open and the focus where it was +function boot() { + var root = document.getElementById('acc-root'), data = document.getElementById('acceptance-data'); + if (!root || !data) return; + var cur; try { cur = JSON.parse(data.textContent); } catch (e) { return; } + var key = statusKey(cur); + function live(text) { var l = document.getElementById('acc-live'); if (l) l.textContent = text; } + function apply(reg) { + var open = [].map.call(root.querySelectorAll('details[open]'), function (d) { return d.id; }); + var f = document.activeElement, fid = f && f.closest && f.closest('details') ? f.closest('details').id : null; + root.innerHTML = renderBody(reg); + open.forEach(function (id) { var d = document.getElementById(id); if (d) d.open = true; }); + if (fid) { var s = document.querySelector('#' + fid + ' > summary'); if (s) s.focus({ preventScroll: true }); } + } + function poll() { + if (document.hidden) return; + fetch('/api/acceptance', { cache: 'no-store' }).then(function (r) { return r.json(); }).then(function (d) { + if (!d || !d.ok || !d.registry || !d.registry.suites) return; + var k = statusKey(d.registry); + if (k !== key) { cur = d.registry; key = k; apply(cur); } + live('Checked against ' + (d.source || 'the git host') + ' at ' + fmtWhen(d.fetched_at).replace(/&/g, '&') + '; the page re-reads it every 60 seconds.'); + }).catch(function () { /* the build-time copy stands */ }); + } + setTimeout(poll, 4000); + setInterval(poll, 60000); + document.addEventListener('visibilitychange', function () { if (!document.hidden) poll(); }); +} + +// the page's
    content: the rendered body in #acc-root, the registry as data, the runtime script +function renderAcceptance(reg) { + return '
    ' + renderBody(reg) + '
    \n' + + '\n' + + ''; +} + +// the inline classic script: the same functions, printed, then boot() +function runtimeSource() { + var fns = [overrides, profileWord, linkOpen, esc, clean, fmtDate, fmtWhen, normStatus, caseStatus, caseEvidenceUrl, caseLastRun, profilesOf, allCases, tally, countStatuses, stateOf, gateDefs, gatesOf, + stateClass, chipHtml, barHtml, tallyText, tallyHtml, statusWords, headLine, headHtml, gateCardHtml, gatesHtml, caseHtml, suiteHtml, profileHtml, profilesHtml, fixturesHtml, + footHtml, suiteNavHtml, renderBody, statusKey, boot]; + return '/* /acceptance runtime: printed at build from site/lib/acceptance-render.mjs (one source for both renders) */\n(function(){\n' + + fns.map(function (f) { return String(f); }).join('\n') + '\nif (document.readyState === "loading") document.addEventListener("DOMContentLoaded", boot); else boot();\n})();'; +} + +export { overrides, profileWord, linkOpen, profilesOf, tally, stateClass, headLine, esc, clean, fmtDate, fmtWhen, normStatus, caseStatus, caseEvidenceUrl, caseLastRun, allCases, countStatuses, stateOf, gateDefs, gatesOf, + chipHtml, barHtml, tallyText, statusWords, gateCardHtml, gatesHtml, caseHtml, suiteHtml, profilesHtml, fixturesHtml, footHtml, renderBody, statusKey, + renderAcceptance, runtimeSource }; diff --git a/site/lib/acceptance-render.test.mjs b/site/lib/acceptance-render.test.mjs new file mode 100644 index 000000000..73e23684a --- /dev/null +++ b/site/lib/acceptance-render.test.mjs @@ -0,0 +1,89 @@ +// node --test site/lib/acceptance-render.test.mjs: the /acceptance renderer (8 October 2026). Known-failed first: a registry +// with one FAIL case must render a molten FAIL chip and read FAIL on the gate that case belongs to; then a clean fixture of +// 128 cases counts 128 NOT RUN, the runtime copy printed into the page renders the same bytes as the build, and the API +// decodes the git host's base64 reply and answers ok:false (status 200) when the host fails. +import test from 'node:test'; +import assert from 'node:assert/strict'; +import * as R from './acceptance-render.mjs'; +import { createHandler, decode } from '../api/acceptance.mjs'; + +// a clean fixture in the registry's shape: 16 suites of 8 cases, every case NOT RUN +function fixture() { + const gates = ['G0 / all gates', 'G1 / G2', 'G2 / technical readiness', 'G3', 'G5 / G2', 'G4', 'Technical readiness', 'Technical readiness / G5', + 'Technical readiness / commercial track', 'G4 / G5', 'G5 / technical readiness', 'Technical readiness / claimed options', 'G5', 'Operator readiness / G5', + 'Commercial evidence', 'Leadership-contender decision']; + const codes = ['GOV', 'GPU', 'POW', 'ADV', 'ROT', 'ECO', 'EVM', 'ZKP', 'CAP', 'INC', 'FIN', 'VER', 'OPS', 'UX', 'COM', 'LEAD']; + return { + title: 'IGNEUM 2.0 - Test and Acceptance Standard', version: '1.0', date: '2026-10-08', status: 'PROPOSED - NOT EXECUTED', basis: 'the plan', + suites: codes.map((code, i) => ({ code, title: code + ' suite', gate: gates[i], owner: 'a lead', fixtures: 'F0', summary: 'One line.', + tests: Array.from({ length: 8 }, (_, j) => ({ id: `${code}-0${j + 1}`, title: 'A case', setup: 's', steps: ['a', 'b'], accept: 'x', evidence: 'e', priority: 'GATE', profile: 'P01; P04', status: 'NOT RUN' })) })), + profiles: { P04: { title: 'Scoped specialist-competition target', requirements: ['R_E at most 1.5.'], status: 'PROPOSED - REQUIRES APPROVAL' }, P13: { title: 'Maintenance continuity', requirements: ['r'], status: 'PROPOSED - REQUIRES APPROVAL' } }, + fixtures: [{ id: 'F0', title: 'Manifest', contents: 'c' }], + source_sha256: 'ab', scope_note: 'Scope.', all_pass_note: 'All pass.', + }; +} + +test('known-failed: one FAIL case renders a molten FAIL chip and a FAIL gate', () => { + const reg = fixture(); + reg.suites[3].tests[2].run_status = 'FAIL'; // ADV-03, suite gate "G3" + const html = R.renderBody(reg); + assert.match(html, /
    [\s\S]*?FAIL<\/span>/); + assert.match(html, /
    /); + assert.match(html, /
    /); + assert.equal(R.countStatuses(reg).FAIL, 1); + assert.match(R.headLine(reg), /1 failed/); +}); + +test('a clean fixture counts 128 NOT RUN and every gate reads NOT RUN', () => { + const reg = fixture(); + const c = R.countStatuses(reg); + assert.equal(c.total, 128); assert.equal(c['NOT RUN'], 128); assert.equal(c.PASS + c.FAIL + c.BLOCKED + c.RUNNING + c.DEFERRED, 0); + const html = R.renderBody(reg); + for (const g of ['G0', 'G1', 'G2', 'G3', 'G4', 'G5']) assert.match(html, new RegExp(`id="gate-${g}" data-gate-state="NOT RUN"`)); + assert.match(R.headLine(reg), /^Test and Acceptance Standard 1\.0: APPROVED AS PROPOSED by the founder, 8 October 2026; P13 \(maintenance continuity\) DEFERRED; 128 cases: 0 passed under the standard, 0 running with team evidence, 128 not run, 0 deferred$/); + assert.match(html, /NOT EXECUTED/); + assert.doesNotMatch(html, /percent|%/); +}); + +test('the gate rule: FAIL over BLOCKED over RUNNING; PASS only when every case passes', () => { + const t = (s) => ({ run_status: s }); + assert.equal(R.stateOf([t('PASS'), t('PASS')]), 'PASS'); + assert.equal(R.stateOf([t('PASS'), t('NOT RUN')]), 'NOT RUN'); + assert.equal(R.stateOf([t('PASS'), t('RUNNING')]), 'RUNNING'); + assert.equal(R.stateOf([t('RUNNING'), t('BLOCKED')]), 'BLOCKED'); + assert.equal(R.stateOf([t('BLOCKED'), t('FAIL')]), 'FAIL'); + assert.equal(R.stateOf([t('PASS'), t('DEFERRED')]), 'NOT RUN'); + assert.equal(R.normStatus('something new'), 'BLOCKED'); + assert.deepEqual(R.gatesOf('G0 / all gates').slice(0, 6), ['G0', 'G1', 'G2', 'G3', 'G4', 'G5']); + assert.deepEqual(R.gatesOf('G2 / G3'), ['G2', 'G3', 'CD']); +}); + +test('run fields: run_status over status, evidence_path linked on the git host, updated as the last run, no em dash served', () => { + const reg = fixture(); + Object.assign(reg.suites[1].tests[0], { run_status: 'PASS', evidence_path: 'docs/runs/gpu-01.md', updated: '2026-10-08T18:05:00Z', title: 'A case \u2014 with a dash' }); + const html = R.renderBody(reg); + assert.match(html, /href="https:\/\/git\.igneum\.network\/igneum-network\/igneum\/src\/branch\/master\/docs\/runs\/gpu-01\.md"/); + assert.match(html, /8 Oct 2026, 19:05 UK/); + assert.doesNotMatch(R.renderAcceptance(reg), /\u2014/); + assert.match(html, /id="profile-P04"[\s\S]*?R_E target at most 1\.5 at the same node and one node ahead; today's placed bracket 1\.5x to 2\.1x: FAIL/); + assert.match(html, /id="profile-P13"[\s\S]*?Deferred by the founder/); +}); + +test('the runtime copy printed into the page renders the same body as the build', () => { + const reg = fixture(); reg.suites[0].tests[0].run_status = 'RUNNING'; + const src = R.runtimeSource().replace('(function(){', 'return (function(){').replace(/if \(document\.readyState[^\n]*\n\}\)\(\);$/, 'return renderBody;\n})();'); + const renderBody = new Function(src)(); + assert.equal(renderBody(reg), R.renderBody(reg)); +}); + +test('the API decodes the git host reply and keeps ok:false on failure', async () => { + const reg = fixture(); + assert.equal(decode({ content: Buffer.from(JSON.stringify(reg)).toString('base64'), encoding: 'base64' }).suites.length, 16); + const res = () => { const r = { headers: {}, code: 0, body: null }; r.setHeader = (k, v) => { r.headers[k] = v; }; r.status = (c) => { r.code = c; return r; }; r.json = (b) => { r.body = b; return r; }; return r; }; + const ok = createHandler({ fetchImpl: async () => ({ ok: true, json: async () => ({ content: Buffer.from(JSON.stringify(reg)).toString('base64'), encoding: 'base64' }) }) }); + const a = res(); await ok({ method: 'GET' }, a); + assert.equal(a.code, 200); assert.equal(a.body.ok, true); assert.equal(a.body.source, 'git.igneum.network master'); assert.equal(a.body.registry.suites.length, 16); + const bad = createHandler({ fetchImpl: async () => ({ ok: false, status: 502 }) }); + const b = res(); await bad({ method: 'GET' }, b); + assert.equal(b.code, 200); assert.equal(b.body.ok, false); assert.match(b.body.reason, /502/); +}); diff --git a/site/light.html b/site/light.html index 3d55edc0b..a83c8dfba 100644 --- a/site/light.html +++ b/site/light.html @@ -137,7 +137,7 @@
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -177,7 +177,7 @@
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/litepaper.html b/site/litepaper.html index 71959b960..067d74a1c 100644 --- a/site/litepaper.html +++ b/site/litepaper.html @@ -186,7 +186,7 @@ body.all .pager{display:none}
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -226,7 +226,7 @@ body.all .pager{display:none}
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/live.html b/site/live.html index 5eda4311e..1831ba417 100644 --- a/site/live.html +++ b/site/live.html @@ -270,7 +270,7 @@ details.tablebar summary{display:flex;align-items:center}
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -310,7 +310,7 @@ details.tablebar summary{display:flex;align-items:center}
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/metamask.html b/site/metamask.html index cca2cdc14..819b2c2c9 100644 --- a/site/metamask.html +++ b/site/metamask.html @@ -131,7 +131,7 @@ ol{margin:0 0 14px;padding-left:22px}li{margin-bottom:6px}
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -171,7 +171,7 @@ ol{margin:0 0 14px;padding-left:22px}li{margin-bottom:6px}
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/miner.html b/site/miner.html index 5fafa3238..4f775713f 100644 --- a/site/miner.html +++ b/site/miner.html @@ -126,7 +126,7 @@ pre b{color:var(--molten-text);font-weight:500}
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -166,7 +166,7 @@ pre b{color:var(--molten-text);font-weight:500}
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/miners.html b/site/miners.html index b4df366b9..2af2821f0 100644 --- a/site/miners.html +++ b/site/miners.html @@ -130,7 +130,7 @@ table{min-width:560px}
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -170,7 +170,7 @@ table{min-width:560px}
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/og/pages.mjs b/site/og/pages.mjs index 62cd6b440..93780166a 100644 --- a/site/og/pages.mjs +++ b/site/og/pages.mjs @@ -31,6 +31,7 @@ export const CARDS = { economics: { kicker: 'Economics', title: 'The economics, as the node encodes them.', sub: 'The emission, the split, the fees, each with its file and line.', route: 'igneum.network/economics' }, scorecard: { kicker: 'Scorecard', title: 'Evidence for every gate.', sub: 'Twelve acceptance gates, the evidence each needs, what never stands in for it.', route: 'igneum.network/scorecard' }, audit: { kicker: 'Site audit', title: 'Every page, audited.', sub: 'What the reset changed, what was rewritten, what is open.', route: 'igneum.network/audit' }, + acceptance: { kicker: 'Acceptance', title: 'Shown as they pass.', sub: 'The Test and Acceptance Standard, 128 cases in 16 suites, case by case.', route: 'igneum.network/acceptance' }, litepaper: { kicker: 'Litepaper', title: 'Mined by GPUs. Proven by fire.', sub: 'The hourly GPU lottery, blocks proven by miners, miner-only finality.', route: 'igneum.network/litepaper' }, light: { kicker: 'Light wallet', title: 'A balance your browser proves.', sub: 'Certificate, headers and account proof, recomputed in the tab.', route: 'igneum.network/light' }, receipt: { kicker: 'Inclusion receipt', title: 'A receipt any third party re-verifies.', sub: 'Proven against the finality certificate. Checked offline with one file.', route: 'igneum.network/receipt' }, diff --git a/site/oracle.html b/site/oracle.html index febf32012..1c0921478 100644 --- a/site/oracle.html +++ b/site/oracle.html @@ -137,7 +137,7 @@
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -177,7 +177,7 @@
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/partials/nav.html b/site/partials/nav.html index 6974dd7da..b65997c23 100644 --- a/site/partials/nav.html +++ b/site/partials/nav.html @@ -45,7 +45,7 @@
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -85,7 +85,7 @@
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/provenance.html b/site/provenance.html index a0af4992b..7155751b0 100644 --- a/site/provenance.html +++ b/site/provenance.html @@ -130,7 +130,7 @@ table{min-width:560px}
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -170,7 +170,7 @@ table{min-width:560px}
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/proving.html b/site/proving.html index c912d2b1a..0c981d701 100644 --- a/site/proving.html +++ b/site/proving.html @@ -156,7 +156,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -196,7 +196,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/randomx.html b/site/randomx.html index f9b371f7f..0fc2b6340 100644 --- a/site/randomx.html +++ b/site/randomx.html @@ -129,7 +129,7 @@
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -169,7 +169,7 @@
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/receipt.html b/site/receipt.html index b6017ffe8..4faa24f9f 100644 --- a/site/receipt.html +++ b/site/receipt.html @@ -135,7 +135,7 @@
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -175,7 +175,7 @@
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/scenes.html b/site/scenes.html index fde3350bf..1f349f784 100644 --- a/site/scenes.html +++ b/site/scenes.html @@ -121,7 +121,7 @@
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -161,7 +161,7 @@
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/scorecard.html b/site/scorecard.html index 98b49c06f..e2471030a 100644 --- a/site/scorecard.html +++ b/site/scorecard.html @@ -103,7 +103,7 @@
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -143,7 +143,7 @@
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/sitemap.xml b/site/sitemap.xml index de3c80d33..435ae98eb 100644 --- a/site/sitemap.xml +++ b/site/sitemap.xml @@ -2,6 +2,7 @@ https://igneum.network/2026-10-07weekly1.0 https://igneum.network/litepaperhttps://igneum.network/economics2026-10-07monthly0.9https://igneum.network/scorecard2026-10-08monthly0.9https://igneum.network/audit2026-10-08monthly0.9 + https://igneum.network/litepaperhttps://igneum.network/economics2026-10-07monthly0.9https://igneum.network/scorecard2026-10-08monthly0.9https://igneum.network/acceptance2026-10-08monthly0.9 https://igneum.network/miner2026-10-07weekly0.8 https://igneum.network/app2026-10-07weekly0.8 https://igneum.network/wallet2026-10-07monthly0.6 diff --git a/site/swap.html b/site/swap.html index 2232843b9..6f8a7eb17 100644 --- a/site/swap.html +++ b/site/swap.html @@ -140,7 +140,7 @@ dt{color:var(--ash)}dd{margin:0;font-family:var(--f-mono);font-size:13px;overflo
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -180,7 +180,7 @@ dt{color:var(--ash)}dd{margin:0;font-family:var(--f-mono);font-size:13px;overflo
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/tx.html b/site/tx.html index b43ac8d61..a392b67b3 100644 --- a/site/tx.html +++ b/site/tx.html @@ -157,7 +157,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -197,7 +197,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/site/wallet.html b/site/wallet.html index f0d27afa3..9323cfede 100644 --- a/site/wallet.html +++ b/site/wallet.html @@ -139,7 +139,7 @@
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. @@ -179,7 +179,7 @@
    Learn
    LitepaperThe design, as published. IncomeWhat your card would mine, from the live network. - EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.Site auditEvery page, what the reset changed and what is open. + EconomicsThe emission, the split and the fees, each with its line in the node.ScorecardThe twelve acceptance gates, their evidence and where each stands.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open. LedgerEvery criticism, answered or conceded. What Igneum does not claimThe limits, stated first. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. diff --git a/tools/ci/checks.txt b/tools/ci/checks.txt index 103c2641a..37f353b8d 100644 --- a/tools/ci/checks.txt +++ b/tools/ci/checks.txt @@ -58,6 +58,7 @@ chain scene: the live feed contract (the recorded reply validates; a rewritten m chain scene parity: one recorded feed through the home fold, /live and the app's Inspect view on build-2, three frames each pixel-equal apart from the app's own-key overlay (a changed token fails first; skipped with no box and no Playwright; one retry) no text overlaps: every served page at 390 to 1600 px, light and dark, the hero at each step (self-test first; IGNEUM_OVERLAP_APPS=1 adds the miner and wallet UIs) explorer, emission, income calculator and public stats unit tests +the /acceptance renderer and its API unit tests ship tool self-test relay unit tests miner app notice strip and update card tests diff --git a/tools/ci/never-served-check.mjs b/tools/ci/never-served-check.mjs index 594fa56e1..1f49a0fc6 100644 --- a/tools/ci/never-served-check.mjs +++ b/tools/ci/never-served-check.mjs @@ -17,14 +17,18 @@ const RULES = [ ['a workbook threshold served as a boundary', /USD 340 ?M\b|USD 23 ?M\b|USD 20 to 75 ?M\b/], ]; // a quoted challenge on the ledger page (
    , the entry title) and a limits item that negates the claim ("X. No.") are not the -// project's claims: they are stripped before the scan, so the pages may refute a line they never make -const text = (html) => html.replace(/||
    [\s\S]*?<\/blockquote>|

    [^<]*<\/h3>|[^<]*<\/strong>\s*No\.|[^<]*<\/span>/g, ' ').replace(/<[^>]+>/g, ' ').replace(/&[a-z]+;|&#\d+;/g, ' '); +// project's claims: they are stripped before the scan, so the pages may refute a line they never make; so is the plan's own list of what +// is never served, printed once on /acceptance in

    Never served: ...

    (8 October 2026) +const text = (html) => html.replace(/||
    [\s\S]*?<\/blockquote>|

    Never served:[^<]*<\/p>|

    [^<]*<\/h3>|[^<]*<\/strong>\s*No\.|[^<]*<\/span>/g, ' ').replace(/<[^>]+>/g, ' ').replace(/&[a-z]+;|&#\d+;/g, ' '); const scan = (name, html) => { const t = text(html); const hits = []; for (const [what, re] of RULES) { const m = re.exec(t); if (m) hits.push(`${name}: ${what} ("${t.slice(Math.max(0, m.index - 40), m.index + m[0].length + 40).replace(/\s+/g, ' ').trim()}")`); } return hits; }; // self-test: a known-failed fixture per rule, then a clean one const fixtures = ['every chip dies within a year', 'a universal ASIC-efficiency ceiling of 2x', 'a 30 percent chance of a chip by 2027', 'guaranteed profits for miners', 'the chain inherits Ethereum security', 'ZK makes transactions private', 'the number one GPU chain', 'the capex wall at USD 340 M']; let bad = 0; fixtures.forEach((f, i) => { if (!RULES[i][1].test(f)) { console.error(`self-test: rule ${i} missed "${f}"`); bad++; } }); if (scan('clean', '

    A GPU-secured network for Ethereum-compatible applications and verifiable computation. ZK is not privacy. EVM compatibility is not Ethereum security.

    ').length) { console.error('self-test: the clean fixture was flagged'); bad++; } +const NEVER = 'Never served: guaranteed chip death, a universal ASIC-efficiency ceiling, chip-arrival probabilities, guaranteed profits, Ethereum security by compatibility, privacy from ZK, a numerical rank.'; +if (scan('list', `

    ${NEVER}

    `).length) { console.error('self-test: the never-served list in its marked element was flagged'); bad++; } +if (!scan('list', `

    ${NEVER}

    `).length) { console.error('self-test: the same list outside its marked element was not flagged'); bad++; } if (bad) process.exit(1); const hits = []; for (const f of readdirSync(site).filter(f => f.endsWith('.html'))) hits.push(...scan(f, readFileSync(join(site, f), 'utf8'))); diff --git a/tools/ci/pre-push.sh b/tools/ci/pre-push.sh index 78813046a..088c5754c 100755 --- a/tools/ci/pre-push.sh +++ b/tools/ci/pre-push.sh @@ -157,6 +157,7 @@ tree_checks() { run "chain scene parity: one recorded feed through the home fold, /live and the app's Inspect view on build-2, three frames each pixel-equal apart from the app's own-key overlay (a changed token fails first; skipped with no box and no Playwright; one retry)" bash tools/ci/retry-once.sh scene-parity bash tools/scene/parity-remote.sh run "no text overlaps: every served page at 390 to 1600 px, light and dark, the hero at each step (self-test first; IGNEUM_OVERLAP_APPS=1 adds the miner and wallet UIs)" overlap_sweep run "explorer, emission, income calculator and public stats unit tests" node --test site/lib/explorer.test.mjs site/lib/emission.test.mjs site/lib/income-calc.test.mjs site/lib/money.test.mjs site/lib/leaderboard.test.mjs site/api/public-stats.test.mjs site/lib/proving-health.test.mjs + run "the /acceptance renderer and its API unit tests" node --test site/lib/acceptance-render.test.mjs run "ship tool self-test" node tools/ship-app.mjs --self-test run "relay unit tests" node --test relay/test/parse.test.mjs relay/test/auth.test.mjs relay/test/wake.test.mjs relay/test/ember.test.mjs run "miner app notice strip and update card tests" node --test app/igneum-app/ui/notices.test.mjs app/igneum-app/ui/update-card.test.mjs app/igneum-app/ui/view.test.mjs app/igneum-app/ui/tune-line.test.mjs diff --git a/tools/ci/site-nav-check.mjs b/tools/ci/site-nav-check.mjs index 167254ec7..2d4a085ac 100644 --- a/tools/ci/site-nav-check.mjs +++ b/tools/ci/site-nav-check.mjs @@ -15,7 +15,7 @@ const here = dirname(fileURLToPath(import.meta.url)); const GROUPS = { mine: ['/miner', '/download', '/app', '/wallet', '/miners', '/dev-fee', '/metamask'], network: ['/live', '/explorer', '/evidence', '/light', '/receipt', '/oracle'], - learn: ['/litepaper', '/income', '/economics', '/scorecard', '/audit', '/ledger', '/claims', '/randomx', '/provenance'], + learn: ['/litepaper', '/income', '/economics', '/scorecard', '/audit', '/ledger', '/claims', '/randomx', '/provenance', '/acceptance'], build: ['/build', '/faucet', '/swap', '/grants', '/compatibility'], // the builder programme (8 October 2026): the developer entry page, the Devnet 3 faucet, the swap, the grants }; const ROUTES = Object.values(GROUPS).flat(); diff --git a/tools/site/capture.sh b/tools/site/capture.sh index 78bc1c618..a662b4408 100755 --- a/tools/site/capture.sh +++ b/tools/site/capture.sh @@ -20,7 +20,7 @@ SRV=$! trap 'kill "$SRV" 2>/dev/null || true' EXIT for i in $(seq 1 40); do curl -fsS "http://127.0.0.1:$PORT/" > /dev/null 2>&1 && break; sleep 0.25; done curl -fsS "http://127.0.0.1:$PORT/" > /dev/null || { echo "the site did not answer on $PORT" >&2; cat "$OUT/serve.log" >&2; exit 3; } -ROUTES="${ROUTES:-/ /download /miner /app /wallet /live /explorer /evidence /litepaper /income /economics /scorecard /audit /ledger /claims /randomx /provenance /miners /dev-fee /faucet /metamask /404}" +ROUTES="${ROUTES:-/ /download /miner /app /wallet /live /explorer /evidence /litepaper /income /economics /scorecard /audit /ledger /claims /randomx /provenance /miners /dev-fee /faucet /metamask /404 /acceptance}" WIDTHS="${WIDTHS:-390 1440}"; THEMES="${THEMES:-dark light}" shot() { # local route="$1" width="$2" theme="$3" name height