From 5295e961467dbe549d5057db34d6a298ce32794e Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Fri, 9 Oct 2026 11:59:09 +0000 Subject: [PATCH 01/10] Site: the chip claim in the approved wording (/resistance), the public-test page (/public-test), the 2.0.3 download note and the staged announcement The claims page serves the laboratory's approved wording verbatim (lab/README.md 8c.9) and nothing stronger: the measured 4 GiB card rows on rented pods, the same-node DRAM board at the 5090 knee and at the worst cohort cell, both conventions with the ProgPoW 0.9.4 and FishHash controls pending, the coexistence table with the cost ratio at all three tested tariffs and the meeting tariff, the new-buyer and used-card columns, phase A and phase B with phase B NOT LIVE, the SRAM die as the residual with its break-even fleet; every figure linked to its row. The litepaper, the miner page and evidence row 6 carry the same wording in place of the 8 October 1.5x bracket. The public-test page: Devnet 4, 2.0.3, not value-bearing, the 30-day independent-operator clock, join per platform, what to report and where, the five gates with their state. The download page: the 2.0.3 note with the five-target dial list and the Windows under-32 GB refusal. docs/public-test/announcement.md staged for the founder's go, not posted. The deploy script carries the served-identity guard in its export (a site-only export built unguarded) and checks the explorer by its title. Co-Authored-By: Claude Fable 5.1 --- docs/claims/resistance.md | 135 +++++++++++++++++++++++++++++++ docs/evidence.md | 2 +- docs/public-test/README.md | 65 +++++++++++++++ docs/public-test/announcement.md | 15 ++++ site/build.mjs | 2 + site/download.html | 1 + site/litepaper.html | 6 +- site/miner.html | 2 +- site/partials/footer.html | 4 +- site/partials/nav.html | 8 +- site/sitemap.xml | 2 + tools/ci/site-nav-check.mjs | 4 +- tools/site-deploy-from-mirror.sh | 8 +- 13 files changed, 237 insertions(+), 17 deletions(-) create mode 100644 docs/claims/resistance.md create mode 100644 docs/public-test/README.md create mode 100644 docs/public-test/announcement.md diff --git a/docs/claims/resistance.md b/docs/claims/resistance.md new file mode 100644 index 000000000..b0c838d63 --- /dev/null +++ b/docs/claims/resistance.md @@ -0,0 +1,135 @@ +# Chip resistance, as measured + +This page serves the chip claim in the words the record supports and nothing stronger. Every figure below names its adversary, its column (energy, capital, cost ratio), its clock state (knee or stock), the card, the adversarial set version and the file it comes from. The GPU side is measured. Every chip figure is a WITNESS: a design that was priced and found to cost at least that much less, never a ceiling on what a better design could do. Nothing here is a pass against a target. Where a row has not run it says so. + +The record lives in the repository under `docs/analysis/class-v6/1p5x/` (the laboratory interface `lab/README.md`, the scoreboard `lab/table.md`, the adversary lane's rows under `lab/adv/`). The paths on this page name the files on the repository's master at commit 688a89706 (9 October 2026, 12:5x UK); rows still on the adversary lane's branch are named with their branch and commit. The public git host serves a path once its copy of master carries it. + +## 1. The claim + +**The current model finds that existing GPU electricity costs are below the assessed DRAM-board specialist's all-in costs at the tested tariffs and stated lifetime assumptions. This supports a conditional entry-deterrence result. It does not yet establish post-deployment competitiveness, viable GPU replacement or new entry, or coexistence against the modelled SRAM fleet at sufficient scale. Those outcomes remain separately assessed.** + +That is the approved wording ([lab/README.md section 8c, item 9](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/1p5x/lab/README.md)). The sentence the rows support today, in plain words: a DRAM-board chip can be built, and it does not undercut a card its owner already has at the three tested electricity tariffs; the chip that stores the whole dataset on its die is the residual, held by its project cost and the growth schedule, and it is examined below with its break-even fleet. The position line of the Token Value volume stands beside it: Igneum is designed to compete for leadership among GPU-first networks; what has been demonstrated is named on this page, nothing more. + +Labels used on this page: MEASURED (a card on a pod or rig, board power read from the driver), WITNESS (a chip design priced as a complete machine; at least this advantage exists), BOUND (a limit no design of the class can beat), MODELLED (an assumption, with its source), PROXY (a stand-in row until the pinned control is measured), PENDING, NOT RUN, BLOCKED and NOT LIVE. + +## 2. The measured card rows + +The object is the frozen class v6 signing program at 2^30 dataset words, 4 GiB (the dataset word 1,073,741,823 on every self-test), the public Linux CUDA worker, board power from the driver, stock clocks (every rented container refused a clock lock), the median of three timed runs, the fingerprint equal on every cell. The rows are summarised on the scoreboard's ctl-v6 row ([lab/table.md](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/1p5x/lab/table.md), the cohort cell); the raw rows with their checksums sit on the build host under the lab's artefact tree, named by pod. + +| Card | Pod | Rate | Board power | Energy per hash | State | Note | +|---|---|---|---|---|---|---| +| RTX 5090 | rented pod 55006481 | 68.66 MH/s | 384 W | 5,597 nJ | stock, 4 GiB | the host's 500 W cap not reached; memory share f 0.81 | +| RTX 5090 | rented pod 55006478 | 68.64 MH/s | 400 W | 5,828 nJ | stock, 4 GiB | power-capped host (400 of 600 W) | +| RTX 5090, the project's own card | the record | | | 4,011 nJ | at its 1,300 MHz knee | the one knee row, from the X0 reconciliation ([x0/README.md section 5b](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/1p5x/x0/README.md)) | +| RTX 5080 | rented pod 55006521 | 35.03 MH/s | 189 W | 5,410 nJ | stock, 4 GiB | clean (189 of a 330 W cap); f 0.81 | +| RTX 4090 | rented pod 55006526 | 30.69 MH/s | 269 W | 8,751 nJ | stock, 4 GiB | uncapped; f 0.86; the worst cohort cell | +| RTX 3090 | rented pod 55006505 | 30.80 MH/s | 260 W | 8,429 nJ | stock, 4 GiB | power-capped host (260 of 350 W): reads "at least 8,429" | +| RTX 3090 | rented pod 55006552 | 30.90 MH/s | 220 W | 7,109 nJ | stock, 4 GiB | power-capped host (220 of 420 W) | + +What the rows mean for an owner: at stock a 5090 spends about 5.6 microjoules on every hash, a 4090 about 8.8; the card's memory path takes 81 to 86 percent of that energy on the uncapped cells (the read-only twin kernel at the same rate; [x7/README.md](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/1p5x/x7/README.md)), which is why no rewrite of the arithmetic moves the ratio much. + +Not measured, said plainly: AMD (RX 7600 to 9070) and Intel Arc tiers NOT RUN (no rented card on either provider on 9 October; the project's own rigs unreachable by software that day; retried hourly). Wall power BLOCKED on every rented pod (no meter): board power only, the idle watts beside each row. Clock locks refused by every rented container, so the only knee row is the project's own 5090. + +## 3. The same-node DRAM board, under our convention + +Our convention: the cheapest programmable core a specialist would build, priced as a complete machine (its own GDDR7 board, controller, host share, power train and cooling), on the same process node as the card and one node ahead, with every instruction counted the way the chip executes it (the instruction convention; a counted-op row is never served alone). Adversarial set v2, the adversary lane's routed fused-ARX lanes on ASAP7 ([lab/adv/README.md, branch class-v6-adversary at commit 545f3f8a0](https://git.igneum.network/igneum-network/igneum/src/branch/class-v6-adversary/docs/analysis/class-v6/1p5x/lab/adv/README.md)); the figures as summarised on the scoreboard's ctl-v6 adversary cell. + +| Comparison | Card row | Ratio, chip energy edge | Band | Label | +|---|---|---|---|---| +| The same-node DRAM board at the 5090 knee | 4,011 nJ (the record) | 2.60x | 2.06x to 3.02x | WITNESS, set v2 | +| The node-ahead DRAM board at the 5090 knee | 4,011 nJ | 2.70x | | WITNESS, set v2 | +| The same-node DRAM board at the worst cohort cell: RTX 4090 at stock, pod 55006526 | 8,751 nJ | 5.67x | 4.49x to 6.59x | WITNESS, set v2 | +| The node-ahead board at that cell | 8,751 nJ | 5.89x | | WITNESS, set v2 | +| The same-node board at the RTX 3090 at stock, pod 55006505 | at least 8,429 nJ | 5.46x | 4.33x to 6.35x | WITNESS, set v2; the card capped | +| The same-node board at the RTX 5090 at stock, pod 55006481 | 5,597 nJ | 3.63x | | WITNESS, set v2 | +| The same-node board at the RTX 5080 at stock, pod 55006521 | 5,410 nJ | 3.51x | | WITNESS, set v2 | + +The board's energy at the knee, split: the chip 527 nJ memory, 167 nJ arithmetic, 849 nJ fixed-function tax (1,543 nJ in all, band 1,328 to 1,947) against the card's 3,642 memory, 369 arithmetic, no tax. The tax ladder states what the chip's own overhead is worth: 2.60x with the record's static tax, 3.28x at half of it, 4.43x at none (the BOUND for this design). + +## 4. Both conventions, side by side + +Two conventions exist for the same question and give different numbers. Ours is above: the cheapest programmable core, complete machine. ProgPoW's premise is that a chip must keep a GPU-class datapath to run the work, so its edge is what it saves by leaving out the parts of a GPU it does not need; the published ProgPoW estimate under that premise is 1.1x to 1.2x. Every served ratio carries both. + +| Object | Under our convention (same node, complete machine) | Under ProgPoW's premise | Card row | State | +|---|---|---|---|---| +| Frozen class v6 (this network's work) | the DRAM board 2.60x at the 5090 knee (2.06x to 3.02x); 5.67x at the worst cohort cell | 1.01x to 1.02x (the card's memory share f 0.908 on that row) | MEASURED (section 2) | WITNESS, set v2; [lab/adv/README.md section 2](https://git.igneum.network/igneum-network/igneum/src/branch/class-v6-adversary/docs/analysis/class-v6/1p5x/lab/adv/README.md) | +| KAWPOW and FiroPoW (ProgPoW 0.9.x) | the DRAM board 4.24x on set v2 (4.29x, 3.50x to 5.22x, on set v1) against the 4090 at stock; the cheapest design for this object is near-memory compute in HBM base dies, 13.2x | 1.10x to 1.20x (the published estimate; f unmeasured) | the comparative lane's rented 4090 at stock, 6,920 nJ per hash, the KAWPOW census as the op-count proxy | PROXY; the pinned ProgPoW 0.9.4 control is PENDING (its pin staged on the build host, no cohort row measured yet) | +| FishHash | adversary rows only: the DRAM board 1,044 nJ per hash (872 to 1,251), three N2 dies 162 nJ; no card row, so no ratio is served | 1.10x to 1.20x (the ProgPoW-family premise) | NOT RUN | PENDING; the pinned control's cohort row is owed | + +The two conventions do not disagree about the hardware; they disagree about what the specialist is allowed to build. Under ProgPoW's premise this network's work reads about 1.0x because the card is already spending nearly all of its energy on memory it cannot avoid; under ours the same card loses 2.6x at its knee to a chip with its own memory board, because a GPU's random-read path costs 4x to 13x what a chip's does per read ([x7/README.md](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/1p5x/x7/README.md)). The ProgPoW 0.9.4 and FishHash rows change from PROXY and PENDING to measured when the laboratory posts the pinned controls' cohort rows. + +## 5. The coexistence table + +Energy alone does not say who mines. The coexistence table prices the chip as a machine against a GPU owner who already has the card (its capital sunk), at the three tested tariffs. Source: the adversary lane's coexistence rows and price sheet ([lab/adv/README.md sections 6 and 7, commit 545f3f8a0](https://git.igneum.network/igneum-network/igneum/src/branch/class-v6-adversary/docs/analysis/class-v6/1p5x/lab/adv/README.md)), as summarised on the scoreboard's ctl-v6 coexistence cell. Assumptions, all MODELLED and stated on the rows: a 100,000-machine fleet, a 24-month straight-line life, a design cost of USD 35 M for the board chip and USD 300 M for the reticle die (both claimed brackets taken at a point), the card sunk at USD 30.6 per MH/s on class v6 at the knee, GDDR7 at USD 20 per 2 GB device (September 2026), the core at USD 0.36 per mm2 of N5, the three tested tariffs USD 0.05, 0.10 and 0.15 per kWh. + +The last column is the cost ratio: the chip's all-in cost per terahash over the GPU owner's electricity-only cost per terahash. Above 1.0 the owner's card keeps mining beside the chip; below 1.0 the owner's electricity alone exceeds the chip's whole bill. + +| Adversary (frozen class v6, the 5090 knee) | Energy edge | Chip capital, USD per MH/s | Cost ratio at USD 0.05 / 0.10 / 0.15 per kWh | The two curves meet at | Break-even fleet at USD 0.10 | +|---|---|---|---|---|---| +| The same-node DRAM board | 2.60x | 14.04 (die 0.34, memory 5.42, board 3.15, design 5.13) | 4.4x / 2.4x / 1.7x | about USD 0.32 per kWh | none: the GPU's electricity-only cost is USD 0.056 / 0.111 / 0.167 per TH against the chip's all-in 0.244 / 0.265 / 0.287; memory and board capital alone exceed the GPU's electricity at any fleet in the record, and the device price would have to fall to about USD 7.5 with a 1,000,000-board fleet before the first break-even | +| The stored-half hybrid (the hottest half of the dataset in SRAM beside the board) | 3.80x | 9.17 | 2.9x / 1.6x / 1.1x | about USD 0.16 per kWh | none stated on the row; holds at all three tested tariffs | +| The N2 SRAM die (the whole dataset on reticles) | 11.9x | 1.59 | 0.5x / 0.3x / 0.2x | about USD 0.02 per kWh | 14,300 dies: above that fleet the GPU owner's electricity exceeds the die's all-in at every tested tariff; 16,700 under the default growth schedule (4 GiB doubling every 24 months), 25,000 doubling every 12 | +| The node-ahead DRAM board | 2.70x | | 4.4x / 2.4x / 1.7x | about USD 0.32 per kWh | none | + +The itemised phase B bill for the board at ten cents, per terahash: electricity 0.043, capital 0.141, design share 0.081, hosting 0.009, maintenance 0.014; in all USD 0.288 against the GPU owner's 0.111, cost ratio 2.58. The die's bill 0.037, cost ratio 0.34 ([lab/adv/README.md section 11](https://git.igneum.network/igneum-network/igneum/src/branch/class-v6-adversary/docs/analysis/class-v6/1p5x/lab/adv/README.md)). + +What this table does not say: it compares the chip with a card already owned. It is a conditional entry-deterrence result, nothing more; the phases below say what happens once a chip exists. + +## 6. The new buyer and the used card + +A new buyer compares the chip's all-in with a new card's all-in (street price over the same 24 months plus electricity). On the record the new buyer picks the chip on every row and every tier at ten cents: the same-node board costs 0.34x a new 5090 at the knee (street USD 42.7 per MH/s), 0.31x a 5090 at stock, 0.24x a 4090, 0.43x a 5080; the hybrid 0.22x; the die 0.04x. The card price at which a new buyer is indifferent: USD 9.7 per MH/s on the 5090 at the knee, 10.5 on the 5080, 5.4 on the 5090 at stock, 2.6 on the 4090. The one hold is the maker's project share: below about 13,500 boards sold the USD 35 M design cost keeps a new buyer on a new 5090; above it the chip ([lab/adv/README.md section 8](https://git.igneum.network/igneum-network/igneum/src/branch/class-v6-adversary/docs/analysis/class-v6/1p5x/lab/adv/README.md)). + +The used card does not close that gap: a used 4090 at USD 1,200 or a used 3090 at USD 700 (claimed, October 2026) with 40 percent of the price kept as resale at 24 months, against a chip whose resale is zero after a program-draw change, still loses to the board at ten cents (the 3090: the chip at 0.45x; indifferent at USD 2.0 per MH/s); the fleet at which the maker's design share stops holding the used-card buyer is about 20,000 machines for the 3090 and 16,000 for the 5080. Memory growth closes the new-buyer gap only at about 227 GB of dataset, outside every schedule to month 72. + +So the honest reading of this section: the installed base holds at the three tested tariffs; a new buyer is held only while the chip maker's fleet is under about 13,500 boards (14,300 dies). + +## 7. The two phases + +The fifth review ruled that the coexistence table proves conditional entry deterrence only, and ordered the question split into two phases per adversary ([lab/README.md section 8c, items 5 and 11](https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/analysis/class-v6/1p5x/lab/README.md)). Rows: [lab/adv/README.md section 12, branch class-v6-adversary at commit 36d17b15c](https://git.igneum.network/igneum-network/igneum/src/branch/class-v6-adversary/docs/analysis/class-v6/1p5x/lab/adv/README.md), every row WITNESS. Sources on the rows: the 80/20 split of each block's subsidy (80 to the producer, 20 to the proving escrow) from the Token Value volume's D02 record (`docs/plans/igneum-2.0-master/token-value/phase0/d02/README.md`, sha256 e4292764…) and the node's `PROVING_POOL_SHARE_PERCENT`; the year-1 subsidy 963,038,999.99 IGN from TV-04; three price paths with their hashrates from the coexistence model (growing: doubling from USD 0.10 at 20 TH/s; flat: USD 0.10 at 6.9 TH/s; falling: halving from USD 0.30 at 1.7 TH/s). + +**Phase A, before investment: can the maker recover its spend?** The fleet is added to the chain's hash and earns the mining share of the emission at the path's mean price over 24 months, electricity at ten cents; the spend is the fleet's capital plus the design cost. + +| Adversary | Growing path | Flat path | Falling path | +|---|---|---|---| +| The same-node DRAM board | recovers on no fleet from 100 to 100 M machines (at 100,000 boards, 25 percent of the hash: net USD -55 M on USD 59 M of revenue) | recovers on no fleet (net -38 M on 77 M at 100,000) | recovers at 3,200 to 355,000 boards (10,000 boards take 29 percent of the hash, net +56 M) | +| The stored-half hybrid | no fleet | no fleet | recovers at 1,300 to 178,000 machines | +| The N2 SRAM die | no fleet at any size (net -200 M to -650 M at 10,000 to 100,000 dies) | no fleet | no fleet (net -19 M at 10,000 dies) | + +In words: a maker's spend comes back only where the chain is small and the price high enough for a few thousand boards to take a third of it; on the growing and flat paths of record no maker recovers. This is the row behind "conditional entry deterrence". + +**Phase B, the spend sunk: who exits first?** Once the chip exists its maker ignores the sunk capital and compares operating cost alone. On operating cost the board chip beats the GPU owner (its electricity, hosting and maintenance about USD 0.066 per TH against the owner's 0.111), so on hash income alone GPUs exit first as revenue falls or difficulty rises. The sixth review adopted the hardware split as the answer: a GPU earns the mining share plus the proving share of each block, a hash chip the mining share only, since a chip that proves is a GPU. + +| Phase B row (flat path, 6.9 TH/s at USD 0.10; the chip at 10 percent of the hash; all proving on the GPU cohort in proportion to its hash) | Value | Label | +|---|---|---| +| Mining revenue, per TH | USD 0.354 | WITNESS | +| The GPU's proving income at the ratified 20 percent share, per TH | USD 0.098 | WITNESS; NOT LIVE | +| The board chip's operating advantage over the GPU owner, per TH | USD 0.046 | WITNESS | +| The hybrid's operating advantage | USD 0.065 | WITNESS | +| The die's operating advantage | USD 0.099 | WITNESS | +| The proving share at which the board chip's advantage disappears | 9 percent (the ratified share is 20) | WITNESS; NOT LIVE | +| The share at which the hybrid's disappears | 13 percent | WITNESS; NOT LIVE | +| The share at which the die's disappears | 20 percent (the ratified share exactly) | WITNESS; NOT LIVE | + +**NOT LIVE.** The proving rows are modelled on a proving income that the shipped packages do not yet pay out across the cohort. Today the Mac and Windows apps carry the prover, on by default only on an NVIDIA card of 24 GB or more (a 16 GB card holds no shard); the HiveOS package mines only, its prover entry in cut. The label changes to LIVE only on the proving lane's evidence that a shipped package proves beside mining on the cohort and is paid for it; until then phase B is a model of what the rules pay, not a measurement of what cards earn. The stated assumption on every phase B row: all proving stays on the GPU cohort; a chip maker who fields GPUs to prove is a GPU miner with a sidecar. + +## 8. The residual: the die + +The chip that stores the whole 4 GiB dataset on N2 reticles is the strongest design the record prices: 11.9x the 5090's energy at the knee (25x at the 3090 cell), USD 1.59 of capital per MH/s, a cost ratio of 0.3x at ten cents. It is not held by energy and it is not held by the dataset's size: no growth schedule stops a 100,000-die fleet paying, and the break-even fleet rises only from 14,300 dies to 16,700 or 25,000 under the schedules ([lab/adv/README.md section 9](https://git.igneum.network/igneum-network/igneum/src/branch/class-v6-adversary/docs/analysis/class-v6/1p5x/lab/adv/README.md)). What holds it is a project: USD 300 M of design and masks (claimed bracket USD 100 M to 500 M) against a chain whose whole mining emission over 24 months is USD 231 M at the growing path's mean price, so in phase A it recovers on no path at any fleet, and in phase B the ratified 20 percent proving share is exactly the share at which its operating advantage disappears. The die stays a live opponent in both phases on every row; where a row calls it implausible, the row names the assumption that fails (the project cost against the emission). + +## 9. What is still open + +| Row | State | Owner | +|---|---|---| +| The pinned ProgPoW 0.9.4 control: its own optimised GPU implementation, test vectors, a cohort row | PENDING (the pin staged; no cohort row) | the controls and cohort lanes | +| The FishHash control: the same | PENDING | the controls and cohort lanes | +| AMD and Intel cohort cells | NOT RUN (no rented card; the project's rigs unreachable by software on the day) | the cohort lane, hourly retry | +| Wall power on the cohort | BLOCKED (board power only on rented pods) | the cohort lane | +| The card's random-read headroom against its memory-timing bound and the chip's 148 MH/s on the same memory (the one lever on phase B that costs the chip nothing) | open | the cohort and controls lanes | +| The 4 GiB proving cap defined precisely (which of the mining state, the proof allocation, the verifier requirement or the advertised profile it limits) | NOT RUN | the controls and adversary lanes | +| A comparative review of what other GPU networks publish on chip resistance | NOT RUN | unassigned; no comparative sentence is served until it runs | +| A shipped package that proves beside the miner on the cohort (the phase B label) | NOT LIVE | the release and proving lanes | +| The adversary lane's rows landing on master (today on branch class-v6-adversary) | in flight | the adversary lane | + +## 10. How to read a figure here, and how to reproduce one + +A card figure is board power from the driver over the worker's accepted rate, the median of three timed runs on one pod, the fingerprint checked against the CPU reference; the raw rows carry the pod id, the driver, the power cap state and the dataset words. A chip figure is a placed-and-routed core on a predictive 7 nm-class library scaled on claimed node factors, its memory and machine terms from the price sheet, every assumption on its row; it is a witness of at least that advantage. A ratio is one card figure over one chip figure, named by both. The laboratory's rule, printed here as it is there: nothing on this page claims impossibility, and nothing on it claims inevitability. The reproduction kit for the frozen control (the 4 GiB packs, the read-only twin, the worker and the fixtures) is the lab's founder bundle, available on request through the Discord's #devnet channel until the public git host carries the record. diff --git a/docs/evidence.md b/docs/evidence.md index 09bcf7fad..1a2e38056 100644 --- a/docs/evidence.md +++ b/docs/evidence.md @@ -38,7 +38,7 @@ Every row carries its release evidence packet at the end of its Result cell: par | 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). For the board on commodity DRAM the two independent chip models agree after placement: 1.5x to 2.1x as a complete machine and 2.0x to 2.9x for the board alone on the GPU's own node; a node ahead 1.8x to 2.4x and 2.45x to 3.3x (placed and routed on ASAP7, both lanes, the node scaling claimed, the machine terms modelled; the 2.9x end is the resizer-downsized floor of the placed 32-lane comparator, not a point, until the placed core32 lands). The standard's P04 target reads FAIL at both ends, served as such. The standard's P04 target as approved: R_E at most 1.5 on the same node and one node ahead; today's placed bracket reads against it as a FAIL to work against." 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 (decided 8 October 2026, 20:05 UK: the genesis size is 4 GiB, the lane's recommendation taken; 2 GiB and 5.5 GiB the costed alternatives beside it; later steps at 5 percent): "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 dataset starts at 4 GiB, the largest size that keeps every entry card and a 12 GB card’s mining and proving together, decided at genesis, 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." (decided; 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). A failure, reported as found: "ECO-05, the standard's coexistence sweep, was run on a register frozen before any result against a sourced revenue reference of USD 31.65 million a year of miner revenue (Ethereum Classic's trailing year at its current era 6 reward) and FAILS the envelope as the chain stands. Of sixteen revenue and tariff worlds (a quarter, one, four and ten times the reference; electricity at 3, 10, 25 and 40 cents per kilowatt-hour) one sustains new entry across two vendors on the measured cards, ten times the reference at 3 cents (about USD 316 million a year), and a second, ten times the reference at 10 cents, on the RX 7600's modelled efficiency point, which the metered row due in the morning keeps at or below 5.4 microjoules per hash and takes away above about 5.6; the cause is that on this hash the measured AMD and Intel cards cost four to six times a Blackwell card per joule and never earn a new entrant's purchase back at list price below those worlds; the verdict is FAIL either way; in those worlds no specialised design sits inside the envelope against the whole cohort (the board on commodity DRAM is within the envelope only against the best Blackwell card, the die and the hybrid against no card of today's), and the quarter-reference worlds at 25 and 40 cents are collapse worlds with no rational profitable operator. What moves the result is the specialist's hardware cost per unit of work, the honest cards' own efficiency on this hash, above all the AMD and Intel cards' energy, and the dataset's size floor; not a smaller network, a higher token price or any chip's death. Reported as found; the register, the full result cube and the model are published for independent reproduction." (Labels: the register frozen at 18:37 UK on 8 October 2026, the reference corrected by a second public read and the run repeated with the verdict unchanged, the cube MODELLED on measured card rows, two cohort rows BLOCKED, the RX 7600's knee and the Arc's watts, their measurement running tonight; the registry row ECO-05 on /acceptance; the results file docs/analysis/class-v6/eco-05-results.md.) 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 | +| 6 | The chip claim as served since 9 October 2026: "The current model finds that existing GPU electricity costs are below the assessed DRAM-board specialist's all-in costs at the tested tariffs and stated lifetime assumptions. This supports a conditional entry-deterrence result. It does not yet establish post-deployment competitiveness, viable GPU replacement or new entry, or coexistence against the modelled SRAM fleet at sufficient scale. Those outcomes remain separately assessed." (the approved wording of the laboratory interface, docs/analysis/class-v6/1p5x/lab/README.md section 8c item 9; every figure on /resistance: the same-node DRAM board 2.60x at the 5090 knee and 5.67x at the worst cohort cell, the stored-half hybrid 3.80x, the SRAM die 11.9x, every chip figure a WITNESS, the cards MEASURED at 4 GiB on rented pods; both conventions served; phase B NOT LIVE until a shipped package proves). The claim as served before 9 October, kept for the record: "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). For the board on commodity DRAM the two independent chip models agree after placement: 1.5x to 2.1x as a complete machine and 2.0x to 2.9x for the board alone on the GPU's own node; a node ahead 1.8x to 2.4x and 2.45x to 3.3x (placed and routed on ASAP7, both lanes, the node scaling claimed, the machine terms modelled; the 2.9x end is the resizer-downsized floor of the placed 32-lane comparator, not a point, until the placed core32 lands). The standard's P04 target reads FAIL at both ends, served as such. The standard's P04 target as approved: R_E at most 1.5 on the same node and one node ahead; today's placed bracket reads against it as a FAIL to work against." 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 (decided 8 October 2026, 20:05 UK: the genesis size is 4 GiB, the lane's recommendation taken; 2 GiB and 5.5 GiB the costed alternatives beside it; later steps at 5 percent): "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 dataset starts at 4 GiB, the largest size that keeps every entry card and a 12 GB card’s mining and proving together, decided at genesis, 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." (decided; 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). A failure, reported as found: "ECO-05, the standard's coexistence sweep, was run on a register frozen before any result against a sourced revenue reference of USD 31.65 million a year of miner revenue (Ethereum Classic's trailing year at its current era 6 reward) and FAILS the envelope as the chain stands. Of sixteen revenue and tariff worlds (a quarter, one, four and ten times the reference; electricity at 3, 10, 25 and 40 cents per kilowatt-hour) one sustains new entry across two vendors on the measured cards, ten times the reference at 3 cents (about USD 316 million a year), and a second, ten times the reference at 10 cents, on the RX 7600's modelled efficiency point, which the metered row due in the morning keeps at or below 5.4 microjoules per hash and takes away above about 5.6; the cause is that on this hash the measured AMD and Intel cards cost four to six times a Blackwell card per joule and never earn a new entrant's purchase back at list price below those worlds; the verdict is FAIL either way; in those worlds no specialised design sits inside the envelope against the whole cohort (the board on commodity DRAM is within the envelope only against the best Blackwell card, the die and the hybrid against no card of today's), and the quarter-reference worlds at 25 and 40 cents are collapse worlds with no rational profitable operator. What moves the result is the specialist's hardware cost per unit of work, the honest cards' own efficiency on this hash, above all the AMD and Intel cards' energy, and the dataset's size floor; not a smaller network, a higher token price or any chip's death. Reported as found; the register, the full result cube and the model are published for independent reproduction." (Labels: the register frozen at 18:37 UK on 8 October 2026, the reference corrected by a second public read and the run repeated with the verdict unchanged, the cube MODELLED on measured card rows, two cohort rows BLOCKED, the RX 7600's knee and the Arc's watts, their measurement running tonight; the registry row ECO-05 on /acceptance; the results file docs/analysis/class-v6/eco-05-results.md.) 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 4 GiB, decided 8 October 2026; at 4 GiB the miner holds less and the rule is not yet measured there): 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 | | 8 | Finality is active on the Igneum 2.0 devnet from checkpoint 241, 115 minutes after block one, with 78 percent of active weight signing | The live page's strip; the explorer; this page | TEAM-REPORTED; activated: the first lock at 19:08:25 UK on 8 October 2026 (checkpoint 241, DAA 7,247, 77.8 percent of active weight; checkpoint 242 at 19:08:48) | the node's checkpoint state through the observer (/api/live finality.active, latest_locked_index); node 4cdcc488 on release-2.0.0-node | the observer's finality fields read at the edge (supported true, active true, latest_locked_index 244 at 19:10 UK). Case: FIN-01 | 8 October 2026, 19:08 UK: the first lock 115 minutes after the first block at 17:14; the weight window filled at DAA 7,200. Packet: parameters rule v3 from checkpoint DAA 0, the 7,200 DAA presence window, two thirds of active and of total weight; procedure the observer's checkpoint table; raw result checkpoint 241 locked at DAA 7,247 with 77.8 percent of active weight; reproduction none yet; review scope none; unresolved a pause has not yet been observed on this chain | none yet | | 9 | The reference population and the cost per accepted unit of work: The reference population is the discrete-GPU classes the network protects, from the RTX 5090 to the RX 7600 8 GB and the Arc B580, with Apple reported beside them; for each the table gives the cost per accepted unit of work for an existing owner (power, wear, fees, over accepted work) and for a new entrant (purchase at list and street price, two years of operation, resale), at three electricity prices, with every figure labelled measured or modelled. On today's rows the cheapest honest owner is a 16 GB Blackwell card at its efficiency point and the cheapest entrant the same card at list price; the specialised board on commodity DRAM costs more per accepted unit than any owner and sits between the entrant's list and street figures. | The litepaper (the chip model); /scorecard | MODELLED; designed (the card rows measured, the chip rows modelled with hardware cost approximate within 2x) | `docs/analysis/class-v6/reference-population.md` (floor lane 3 for the research lane, on master at 10aa76d7, 8 October 2026) | the table's own cells, each labelled measured or modelled; the two tests per class as the plan's D1 names them. Case: GPU-02 | 8 October 2026: the cheapest honest owner a 16 GB Blackwell card at its efficiency point, the cheapest entrant the same card at list price, the DRAM board above every owner and between the entrant's list and street figures. Packet: parameters the reference cohort (RTX 5090 to RX 7600 8 GB and Arc B580, Apple beside), three electricity prices, two years of operation; procedure the table's method section; raw result the table; reproduction none yet; review scope none; unresolved the Arc's watts and the RX 7600's knee rows are BLOCKED | none yet | diff --git a/docs/public-test/README.md b/docs/public-test/README.md new file mode 100644 index 000000000..0cdaefd03 --- /dev/null +++ b/docs/public-test/README.md @@ -0,0 +1,65 @@ +# The public test + +## 1. What this is + +Igneum 2.0 runs on Devnet 4 (network id `igneum-devnet-4`, chain id 4465), software version 2.0.3. The public test is an open invitation to run that software on your own card, on your own machine, and report what happens. It is a test. Coins on this network have no value, cannot be bought or sold, and the chain may be reset; nothing here is a launch, a sale or an offer. + +The test opens when the five gates in section 5 read green. From that morning a 30-day clock runs on one question: how many operators the project does not control keep a node and a miner on this chain, and what breaks for them. The project's own fleet is counted separately and is never mixed into that number. The monetary gates of the Token Value volume, counsel's review and the 90-day observation period are not part of this test and are not shortened by it. + +What the test proves, if it passes: that a stranger can install the software on Windows, macOS, Linux or HiveOS, sync, mine, prove where the card allows it, and ride through the hourly program changes and the weekly epoch cuts without a hand from the project. What it does not prove: that the token has value, that the chain is final in the sense a mainnet needs, or any claim about chips beyond what [the resistance page](/resistance) states in its own words. + +## 2. Join, per platform + +Every download comes from this domain only ([/download](/download)); check the sha256 the page shows. One install carries the node, the miner and, where the card allows it, the prover. + +| Platform | What to install | What you need | Notes | +|---|---|---|---| +| Windows 10 or 11 | the installer from [/download#windows](/download#windows) | an NVIDIA, AMD or Intel card with 4 GB or more; 32 GB of memory for a fresh sync this cut | SmartScreen shows "Windows protected your PC" on an unsigned build: More info, Run anyway. The installer's one administrator prompt turns on the Windows Subsystem for Linux for the proof verifier; the app installs the rest itself. On a machine under 32 GB the app does not start a fresh sync and says so; the snapshot sync of 2.0.3.1 is that machine's route. | +| macOS, Apple silicon | the disk image from [/download#mac](/download#mac) | an M-series Mac; 16 GB works | On first open macOS says it cannot verify the app: System Settings, Privacy and Security, Open Anyway. A 16 GB Mac completes a fresh sync in about an hour on swap and feels slow until the node reads synced; this holds until 2.0.3.1. | +| Linux | the tarball from [/download#linux](/download#linux) | an NVIDIA or AMD card; 64 GB of memory for a fresh sync from genesis today | The flight sheet on the download page. The number falls when snapshot sync ships. | +| HiveOS | the package from [/download#hive](/download#hive) | a rig with NVIDIA cards | The package waits for the node to sync before it mines. HiveOS mines only in 2.0.3; its prover entry is being cut. | + +The memory note, plainly: a fresh sync from genesis needs 64 GB of memory on Linux and Windows today, because the node holds the chain's execution state in memory as it replays it; a 16 GB Mac syncs on swap; the snapshot sync of 2.0.3.1 brings a 16 GB machine in without the replay, and this page says so when it ships. A 2.0.3 install dials five targets by default: the three hubs and the two public nodes on the build host; a node that cannot reach any of them says so in its log. + +What your card does once it is in: any 4 GB card mines; an NVIDIA card of 24 GB or more proves the shard beside its miner by default; a 16 GB card holds no shard. The rates the project measured per card are on [/miner#card](/miner#card) and the bench table on [/miners](/miners); your own rows are welcome (section 3). + +## 3. What to report, and where + +The Discord is the one place: [discord.gg/igneum](https://discord.gg/igneum). Read #start-here and #rules first (three rules). Then: + +| What happened | Where | What to include | +|---|---|---| +| The install or the app will not start, sync or mine on Windows | #support-windows | the app version (the window's About), the card and driver, the Windows version, the line the app shows, the log the Logs button opens | +| The same on a Mac | #support-mac | the app version, the Mac model, the macOS version, the line the app shows, the log | +| The same on Linux or HiveOS | #support-linux-hiveos | the package version, the card and driver, the flight sheet or command, the last 50 lines of the log | +| Your card's rate and watts | #benchmarks | one row: card, driver, OS, app version, MH/s, W, the command or the app's setting; the bench table is built from rows like these | +| Your first block | #first-block | the bot posts it; reply under it with your card if you like | +| Mining talk, settings, what your card is doing | #mining | say the card, the OS and the app version | +| A node you run without mining | #node-runners | the version, how it dials, what it sees | +| Proving on a 24 GB card | #proving | the card, what the app shows under proven, the shard times | +| Something that looks like a chain fault: a fork, a stall, a reset you did not expect | #devnet | the time (UTC), your node's height and tip, the lines around it; the project's incident posts are in #incidents | +| A criticism of the design or a claim on this site | #ledger | the claim as served, what you think is wrong, your source; it gets a ledger id and a dated answer on [/ledger](/ledger) | + +The hourly numbers from the public API post to #network-feed (height, hash rate, keys, the last lock). An incident is posted in #incidents when it opens and when it resolves, with the cause and the fix. Nothing you report is private; say nothing you would not say in public. + +## 4. The rules of the test + +- The software updates itself when you let it at install; a test on an old version is still a report, say the version. +- Every machine mines solo on its own keys; there is no pool during the test. Outside pools are listed on #pools only with a signed statement. +- The project's fleet, the hubs and the build host's nodes are the project's and are counted apart from independent operators. +- A fault with a software fix is fixed and shipped; it is not held for a word. The incident post names the fix and its version. +- The project does not touch your machine. There is no remote execution in the public build. + +## 5. The five gates, with their state + +The test opens the morning after all five read green. The state column is read from the project's record by the site lane; the time it was read is on the row. + +| Gate | What green means | State at 13:3x UK, 9 October 2026 | +|---|---|---| +| 1. 2.0.3 on the hubs and the fleet | the three hubs and the project's fleet run node 27f54124 on one chain | in progress: the hub canary passed its sync; the hubs move one at a time on its pass; the fleet rolls after | +| 2. A 16 GB machine joins by snapshot sync | a fresh install on a 16 GB machine reaches the tip without the full replay | not yet: the snapshot-sync branch (2.0.3.1) is green on six test suites; the first served snapshot and the 16 GB canary are due this afternoon | +| 3. Mac, Windows and HiveOS 2.0.3 entries on their canaries | each package installs, syncs, mines and updates itself on a machine the project does not hand-hold | Mac: canary passed (the reboot leg not run, held by the founder); HiveOS: canary in its last blocks; Windows: being cut; the entries publish on the hubs' line | +| 4. One tip held through two epoch cuts after the roll | every public node on one chain across two weekly cuts with no restart by hand | not yet: counted after gate 1 | +| 5. The served claims in the approved wording, both conventions | [/resistance](/resistance) serves the approved wording verbatim, the measured card rows, both conventions, the coexistence table and the two phases with their labels | green at this landing | + +When all five read green the state column changes here, the announcement goes to #announcements and the 30-day clock starts; the start date is written on this row when it happens. diff --git a/docs/public-test/announcement.md b/docs/public-test/announcement.md new file mode 100644 index 000000000..5b287878d --- /dev/null +++ b/docs/public-test/announcement.md @@ -0,0 +1,15 @@ +# The public-test announcement (staged, not posted) + +Staged 9 October 2026 by the site and claims lane for #announcements on the Discord. It is posted by main on the founder's go, after the five gates on [/public-test](/public-test) read green, and not before. Under 1,200 characters, no name, no superlative; the chip claim in the approved wording of `docs/analysis/class-v6/1p5x/lab/README.md` section 8c item 9, verbatim. Edit the links only if the pages move. + +``` +Igneum 2.0 public test: open on Devnet 4, software 2.0.3. + +This is a test, not a launch. Coins have no value and the chain may be reset. For 30 days we count the operators we do not control who keep a node and a miner on the chain, and what breaks for them. + +Join: https://igneum.network/download (Windows, macOS, Linux, HiveOS; only from that domain). A fresh sync needs 64 GB of memory on Linux and Windows until snapshot sync ships; a 16 GB Mac syncs on swap in about an hour. How to join and what to report: https://igneum.network/public-test + +The chip claim, in the record's words: "The current model finds that existing GPU electricity costs are below the assessed DRAM-board specialist's all-in costs at the tested tariffs and stated lifetime assumptions. This supports a conditional entry-deterrence result. It does not yet establish post-deployment competitiveness, viable GPU replacement or new entry, or coexistence against the modelled SRAM fleet at sufficient scale. Those outcomes remain separately assessed." Every figure and its record: https://igneum.network/resistance + +Report in the support channel for your OS; rates in #benchmarks; criticism in #ledger. +``` diff --git a/site/build.mjs b/site/build.mjs index a3fc86eaf..870f56bb9 100644 --- a/site/build.mjs +++ b/site/build.mjs @@ -233,6 +233,8 @@ for (const [src, file, title, desc, heading, lead, eyebrow] of [ ['build/compatibility.md', 'compatibility.html', 'Igneum compatibility, measured: every row a test run against the devnet', 'Compatibility as a product deliverable: representative contracts, wallet fee estimation, indexing, failed transactions, receipts, application assumptions and the measured differences (block context, randomness, two-dimensional fees), each a test with its evidence. Devnet, no value.', 'Compatibility, measured', 'Every row is a test that ran against the devnet, with its evidence; a row that could not run says why.', 'Build · compatibility'], ['site/audit-2.0.md', 'audit.html', 'Igneum site audit, 2.0', 'Every served page of igneum.network read against the Igneum 2.0 reset: what changed, what was rewritten, what still carries pre-2.0 copy, the label of each claim and what is open.', 'Site audit', 'Every served page, what the reset changed, what was rewritten, what still carries pre-2.0 copy, the label of each claim, and what is open. Main reads it against the live site.', 'Learn · audit'], ['build/tuning.md', 'tuning.html', 'Igneum tuning: how Ember reaches a good operating point', 'The knee rule with its measured rows, the ladders and priors, the safe defaults per class, the worker flags and their costs, the compiler settings and the fingerprint check: the published optimisation work.', 'Tuning', 'How Ember reaches a good operating point without third-party software, every figure a dated measured row or marked approximate.', 'Learn · audit'], + ['claims/resistance.md', 'resistance.html', 'Chip resistance, as measured: the claim, the card rows, both conventions, the coexistence table', 'The chip claim in the record’s approved words and nothing stronger: the measured card rows at 4 GiB, the same-node DRAM board under both conventions, the coexistence table at the three tested tariffs, the new-buyer column, the two phases with phase B not live, and the SRAM die as the residual with its break-even fleet. Every figure labelled and named to its row.', 'Chip resistance, as measured', 'The claim in the record’s words and nothing stronger. Every figure names its adversary, its column, its clock state, its card, its set and its file.', 'Learn · the claim'], + ['public-test/README.md', 'public-test.html', 'The Igneum 2.0 public test: what it is, how to join, what to report, the five gates', 'The public test of Igneum 2.0 on Devnet 4: a test, not a launch; how to join on Windows, macOS, Linux and HiveOS; what to report and where on the Discord; the five gates with their state and the 30-day independent-operator clock.', 'The public test', 'A test, not a launch. Devnet 4, version 2.0.3, coins with no value. Join on your own card, report what breaks, and watch the five gates.', 'Network · public test'], ]) { const mdp = join(docs, src); if (!existsSync(mdp)) continue; // the gate builds a copy of site/ alone: the committed page stands diff --git a/site/download.html b/site/download.html index b309d5987..4a54fc48c 100644 --- a/site/download.html +++ b/site/download.html @@ -283,6 +283,7 @@

Your card: pending

Before you install: a fresh sync from genesis needs 64 GB of memory today. 48 GB is the floor at this hour, and the number grows with the chain until the snapshot path ships (a fresh node reads about 30 GB of memory by DAA 44,000 and 35 to 40 GB at today’s tip, a gigabyte more every 17 minutes at one block a second; a 16 GB machine reaches DAA 7,000 to 8,000 about four minutes in and then swaps or is killed, a 32 GB machine about DAA 20,000). On a 16 GB Mac a fresh sync still completes: it takes about an hour and runs on swap (macOS pages the node’s memory to disk rather than ending it), so expect the machine to feel slow until the node reads synced; this holds until 2.0.3.1. A smaller machine waits for the snapshot path, 2.0.3.1: its design is due by 12:30 today and the first served snapshot by 15:00; this note changes when it ships. The devnet was reset this morning, 9 October; a fresh install syncs from the reset chain.

+

2.0.3 (9 October): cut and on its canaries; the buttons above serve it the moment the three hubs run it. Until then they serve 2.0.2 on macOS and 2.0.1 on Windows and HiveOS. What changes in 2.0.3: a fresh install joins the chain through a peer’s sink and rides through the epoch cuts; the Mac worker keeps mining across an epoch cut (the watchdog waits for the new epoch’s dataset instead of ending the worker); the updater proves the new engine answers before it keeps it; the dial list is five targets by default, the three hubs and the two public nodes on the build host; the HiveOS package waits for the node to sync before it mines and raises its open-files limit; on Windows a machine under 32 GB of memory does not start a fresh sync and says so (the snapshot sync of 2.0.3.1 is that machine’s route; a datadir that already holds the chain syncs on; macOS is not held); 2.0.2 becomes the lowest supported version. Mac disk image Igneum-Miner-2.0.3-27f54124-034cdad1.dmg, sha256 8f2a3c4fc1fb81338fc49dbd7d15ce15511be8e4109eae4e48c123c201b1f2ed, 47,453,555 bytes; HiveOS igneum-hive-2.0.3-27f54124.tar.gz, sha256 74e49fa72233bf5aad04450feccc5fca25bbc07da11ebaddeb79541f8b496587, 52,929,092 bytes; Windows being cut, its line written here when it publishes. The public test: how to join and what to report.

What changed in 2.0.2 (Mac, 9 October). The public miner ships without remote execution; the fleet runs Igneum Miner Lab under its own signing root. Automatic updates are a choice at install and honoured. The recovery lock is named as recovery. A fresh install syncs through the epoch cuts and the node serves its proof records to every joiner. Windows and HiveOS stay on 2.0.1 until their builds are cut; 2.0.1 is the lowest supported version. DMG Igneum-Miner-2.0.2-5d53a591-1176efb9.dmg, sha256 66137cd8303356dacc2a0abc24088a88263ef81f3a85b16ba4b950cc6bcb806f, 46,002,244 bytes.

What changed in 2.0.1. An update never leaves mining off. The Cards tab is back as its own page. The first-block card shows once per address. The window names included, executed, proven and finalised. The node serves its manifest and the genesis state stream to every miner. The Mac build is unsigned tonight.

2.0.0 is withdrawn: its miner could not read this network’s block templates; every 2.0.0 install updates itself to 2.0.1.

diff --git a/site/litepaper.html b/site/litepaper.html index 6e2822a3a..294638dc7 100644 --- a/site/litepaper.html +++ b/site/litepaper.html @@ -466,8 +466,8 @@ body.all .pager{display:none}

What carries the chip resistance is the scoring rule's result on the placed adversary rows, plus the economics, reported separately in the chip model below. Three properties feed it. Rotation is an option, not the defence. A new program every hour, drawn from the chain, its memory pattern with it, and rules that change on a schedule fixed at launch. These schedule changes defeat a chip wired for one datapath and need no human fork, but against a programmable chip that stores the dataset every drawn parameter is firmware, so the security argument does not rest on them. What meets that chip is the price per joule (the chip and economy analysis of 6 October 2026, section 5.4; ledger D3). It waits on memory, not maths. Every hash is a chain of random reads into a table too big for a chip to carry. Measured (8 October 2026; lane D’s family harness at the acceptance rule’s own 2^20 sample over 4,900 drawn eras, and the chained-cache pass’s reading of the night before): every hash executes 256 dependent 4-byte reads of the dataset under the class v6 object (the drawn program’s 16 load sites, run on both halves of the 64-register window, over 8 iterations; 128 on the classes before it), and each read lands anywhere in the 1 GiB dataset at genesis (every load site reads the whole dataset, a half or a quarter at a drawn offset), so the card pays a full memory latency per read; the reads land across the whole dataset and the distinct-index floor holds at 0.995 on every accepted program; about half of epochs carry one load site whose address bit at the era’s stride rotation is biased, which prices about 1.6 percent of a hash’s reads to a chip storing half the dataset and nothing to a chip storing all of it; the next class folds the product’s low bits before the rotation, so no era lands a biased bit on an address bit. The wait is the same physics for everyone. Miners hold the switch. Spare defences are written into the rules, switched off. A miner signal turns one on, at the class-change threshold: miners signal three things at three thresholds, 60 percent of blue blocks over two weeks for a parameter genesis leaves open, 90 percent for an upgrade (new code), and 95 percent with a floor height for a class change. No fork.

The work that waits can grow. Class v4 adds a block of latency-shadow arithmetic to every hash, about 100,000 integer operations that run while the memory reads are in flight, so a chip that stores the whole dataset still has to pay for a core. That size sits on a ladder fixed at genesis, six rungs from about 100,000 to about 1,000,000 operations, and it moves one rung at a time only when 90 percent of blue blocks in each of seven consecutive days ask for it; it can never move two rungs inside a week and never past a rung the reference verifier cannot check under 10 ms with its sibling thread busy (measured on the build server, 6 October 2026: the first three rungs pass at 8.8, 8.9 and 9.2 ms, the fourth misses by 0.08 ms on a loaded box and stays out until a quiet re-measurement, the two doublings are out at 12.4 and 15.0 ms). What it buys against a chip is scored under the rule in the chip model below. What it costs, per rung, is measured too: the Apple tier gives up 3 points of rate at the first step and 6 more at the second, the RTX 5090 nothing until the second; so the miners who pay for a step are the ones who take it.

The chip model

-

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. Class v6 adopts the 64-register window and retains it across every rotation. 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). For the board on commodity DRAM the two independent chip models agree after placement: 1.5x to 2.1x as a complete machine and 2.0x to 2.9x for the board alone on the GPU’s own node; a node ahead 1.8x to 2.4x and 2.45x to 3.3x (placed and routed on ASAP7, both lanes, the node scaling claimed, the machine terms modelled; the 2.9x end is the resizer-downsized floor of the placed 32-lane comparator, not a point, until the placed core32 lands). The standard’s P04 target reads FAIL at both ends, served as such. The standard’s P04 target as approved: R_E at most 1.5 on the same node and one node ahead; today’s placed bracket reads against it as a FAIL to work against. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment.

-

The labels. MODELLED. The GPU side is measured (the RTX 5090 at its 1,300 MHz lock on class v4, 8 October 2026). The chip’s core is placed and routed on ASAP7 with SRAM macros and scaled on claimed node factors; the chip’s memory and the rest of the machine (controller, host share, PSU, VRM, cooling) are modelled; no chip is measured, and the chip’s hardware cost is approximate within 2x. Beside it the coexistence verdict at these energies: the DRAM board passes six of the model’s seven conditions, the hybrid coexists only in a growing chain at cheap GPU electricity, the SRAM die fails the cost, hardware, fleet and margin conditions at its reconciled machine cost, and only private supply in a growing network coexists. The k lane’s own placed row amends the figures if it differs. The GPU side is measured: an RTX 5080 at its 1,100 MHz core lock, 2.06 microjoules per hash, and an RTX 5090 at its 1,300 MHz lock, 2.33 microjoules per hash, both under class v4, on the project’s own rigs and rented pods, 8 October 2026; the card’s cost of the window is measured too (a rented RTX 5090 and RTX 4090 at stock, 8 October 2026: within 5 percent per load with the liveness chain, no register spill). The chip side is synthesised and claimed: the clock-gated sequencer core with the 64-register window on ASAP7, scaled to N3 on the foundry’s headline factors (k about 0.37 at N3 and 0.51 node for node for the base core, the gated window adding about 0.13 of k against an adversary with a flop register file; the window’s liveness measured at 61 of 64 values necessary, its cost to the card measured under 5 percent); the window’s k is synthesis-derived and not a lower bound, and the multi-family adversary lane’s first core (its state in a macro) reads the window’s defence as close to nothing, a disagreement between two models that the placed rows settle. The chip’s memory is modelled: the GDDR7 board of the chip model. The placed gated figure is expected near 2.6x to 3.1x a node ahead and 2.3x to 2.7x node for node (approximate) and is served when its row lands.

+

The current model finds that existing GPU electricity costs are below the assessed DRAM-board specialist's all-in costs at the tested tariffs and stated lifetime assumptions. This supports a conditional entry-deterrence result. It does not yet establish post-deployment competitiveness, viable GPU replacement or new entry, or coexistence against the modelled SRAM fleet at sufficient scale. Those outcomes remain separately assessed. That is the approved wording of 9 October 2026 and the only chip claim this site makes; the resistance page carries every figure behind it with its label, adversary, clock state, card, set and file. The figures below this line are the 8 October 2026 modelling as it stood (a class v4 GPU numerator against a placed core, since corrected by the frozen class v6 object’s own measured energy and the chip’s instruction counts): on 9 October the same-node DRAM board reads 2.60x at the 5090 knee (2.06x to 3.02x, adversarial set v2) and 5.67x at the worst cohort cell, the stored-half hybrid 3.80x, the SRAM die 11.9x, every chip figure a WITNESS and no chip measured. The 1.5x target of P04 is not met by any measured design and is not claimed. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment.

+

The labels of the 8 October modelling, kept for the record (superseded on 9 October; see above and the resistance page). MODELLED. The GPU side is measured (the RTX 5090 at its 1,300 MHz lock on class v4, 8 October 2026). The chip’s core is placed and routed on ASAP7 with SRAM macros and scaled on claimed node factors; the chip’s memory and the rest of the machine (controller, host share, PSU, VRM, cooling) are modelled; no chip is measured, and the chip’s hardware cost is approximate within 2x. Beside it the coexistence verdict at these energies: the DRAM board passes six of the model’s seven conditions, the hybrid coexists only in a growing chain at cheap GPU electricity, the SRAM die fails the cost, hardware, fleet and margin conditions at its reconciled machine cost, and only private supply in a growing network coexists. The k lane’s own placed row amends the figures if it differs. The GPU side is measured: an RTX 5080 at its 1,100 MHz core lock, 2.06 microjoules per hash, and an RTX 5090 at its 1,300 MHz lock, 2.33 microjoules per hash, both under class v4, on the project’s own rigs and rented pods, 8 October 2026; the card’s cost of the window is measured too (a rented RTX 5090 and RTX 4090 at stock, 8 October 2026: within 5 percent per load with the liveness chain, no register spill). The chip side is synthesised and claimed: the clock-gated sequencer core with the 64-register window on ASAP7, scaled to N3 on the foundry’s headline factors (k about 0.37 at N3 and 0.51 node for node for the base core, the gated window adding about 0.13 of k against an adversary with a flop register file; the window’s liveness measured at 61 of 64 values necessary, its cost to the card measured under 5 percent); the window’s k is synthesis-derived and not a lower bound, and the multi-family adversary lane’s first core (its state in a macro) reads the window’s defence as close to nothing, a disagreement between two models that the placed rows settle. The chip’s memory is modelled: the GDDR7 board of the chip model. The placed gated figure is expected near 2.6x to 3.1x a node ahead and 2.3x to 2.7x node for node (approximate) and is served when its row lands.

The dataset policy (decided 8 October 2026: the genesis size is 4 GiB). The founder’s word at 20:05 UK took the lane’s recommendation: 4 GiB at genesis (class_v6_dataset_steps [(0, 4096 MiB)] in every D1 candidate’s literal), the largest size that keeps every entry card and a 12 GB card’s mining and proving together; 2 GiB (an 8 GB card holds it with room, about 4 percent at the lock) and 5.5 GiB (the 12 GB tier loses mine-and-prove co-residence) are the costed alternatives beside it; every later step is scored at 5 percent against it and taken only when the chain’s own state outgrows the dataset. The reasoning: 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 dataset starts at 4 GiB, the largest size that keeps every entry card and a 12 GB card’s mining and proving together, decided at genesis, 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. (the card rows measured: an RTX 5090 at its 1,300 MHz lock on the project’s own rig, one paired mapping job, 8 October 2026, the cost the size’s and not the mapping’s; the chip tickets modelled and approximate; later steps’ costs expected, not measured.)

@@ -479,7 +479,7 @@ body.all .pager{display:none}

Three statements, kept separate. The baseline is the hash as it stands under the scoring rule; rotation is an optional improvement to that baseline, not the mechanism the claim rests on.

DatasetEnergy per hash against 1 GiB, at stockAt the 1,300 MHz lockCards excluded by memorySRAM ticket on the hybrid boardSRAM ticket on the dieLabels
1 GiB (class v4 today)the controlthe controlnoneUSD 125one reticle, USD 500measured; modelled
- +
StatementWhat it saysLabel and date
Energy resistancePer machine against a locked RTX 5090, node for node and a node ahead: the DRAM board 1.5x (1.3x to 1.7x) and 1.8x; the board with SRAM holding the hottest half of the dataset 1.9x to 2.1x and 2.4x to 2.6x; the SRAM-store 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, so about 2x on the same node stands at the bracket’s top; per dollar of hardware at list price 3x to 6x (modelled on the placed full 18-family core, routed 8 October 2026, and the 32-lane core’s synthesis). The honest tier moves to the next node with every GPU generation; a chip must tape out again. Whole machine per tier (synthesis with the SRAM band and node factors, claimed; placed rows to follow): the complete GDDR7 machine about 1.8x the RTX 5090 at its lock per joule node for node and 2.1x a node ahead; 1.6x and 1.9x the RTX 5080; 2.8x and 3.3x the Ada, Ampere and RX 9070 XT cohort; about 1.5x the Apple tier, reported, never headlined.MODELLED: placed and routed core energies against the measured RTX 5090 lock row, 8 October 2026, no chip measured
Energy resistanceSuperseded on 9 October 2026 by the laboratory’s rows on the resistance page: per complete machine against the project’s RTX 5090 at its 1,300 MHz knee on the frozen class v6 object at 4 GiB, the same-node DRAM board 2.60x (2.06x to 3.02x) and 2.70x a node ahead; at the worst cohort cell (an RTX 4090 at stock) 5.67x; the stored-half hybrid 3.80x; the SRAM-store die 11.9x; chip capital USD 14.04 per MH/s for the board against the card’s 30.6 (the adversary lane’s routed lanes, set v2, every chip figure a WITNESS). The 8 October bracket (1.5x to 2.1x on the same node) paired a class v4 numerator with the chip and double-counted the chip’s micro-ops; it is withdrawn.MEASURED cards, 9 October 2026; WITNESS chips, no chip measured
Economic resistanceWhether a chip gets built depends on development cost, deployment economics and productive hardware lifetime. The first cut of the profitability surface: the price at which a project pays scales as the project cost over its share of the chain times its discounted life, and moves by under 5 percent with the per-joule edge; a fixed-lane chip under rotation needs 4x the price a programmable one needs. No threshold is the headline: the five-year coexistence model (Deliverable 4; its first run is docs/analysis/class-v6/coexistence-model.md, every row modelled) replaces any capex wall: the DRAM board passes six of its seven success conditions at a one to three year life; the SRAM die fails four conditions at its reconciled machine cost; the larger half of a chip's edge is capital cost per accepted hash, not joules. The result, as the model words it: 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 model holds under every market structure for the DRAM board (private supply, hardware sales, multiple suppliers, with no single supplier above a quarter of the network), and the SRAM die under none but private supply in a growing network; the thresholds live in the model's sensitivity workbook (docs/analysis/class-v6/coexistence-workbook.md), never on a page. A failure, reported as found: ECO-05, the standard’s coexistence sweep, was run on a register frozen before any result against a sourced revenue reference of USD 31.65 million a year of miner revenue (Ethereum Classic’s trailing year at its current era 6 reward) and FAILS the envelope as the chain stands. Of sixteen revenue and tariff worlds (a quarter, one, four and ten times the reference; electricity at 3, 10, 25 and 40 cents per kilowatt-hour) one sustains new entry across two vendors on the measured cards, ten times the reference at 3 cents (about USD 316 million a year), and a second, ten times the reference at 10 cents, on the RX 7600’s modelled efficiency point, which the metered row due in the morning keeps at or below 5.4 microjoules per hash and takes away above about 5.6; the cause is that on this hash the measured AMD and Intel cards cost four to six times a Blackwell card per joule and never earn a new entrant’s purchase back at list price below those worlds; the verdict is FAIL either way; in those worlds no specialised design sits inside the envelope against the whole cohort (the board on commodity DRAM is within the envelope only against the best Blackwell card, the die and the hybrid against no card of today’s), and the quarter-reference worlds at 25 and 40 cents are collapse worlds with no rational profitable operator. What moves the result is the specialist’s hardware cost per unit of work, the honest cards’ own efficiency on this hash, above all the AMD and Intel cards’ energy, and the dataset’s size floor; not a smaller network, a higher token price or any chip’s death. Reported as found; the register, the full result cube and the model are published for independent reproduction. (Labels: the register frozen at 18:37 UK on 8 October 2026, the reference corrected by a second public read and the run repeated with the verdict unchanged, the cube MODELLED on measured card rows, two cohort rows BLOCKED, the RX 7600’s knee and the Arc’s watts, their measurement running tonight; the registry row ECO-05 on /acceptance; the results file docs/analysis/class-v6/eco-05-results.md.)MODELLED, the coexistence model's first run, 8 October 2026
Response capabilityRotation is an optional improvement, not the mechanism. A passed rotation boundary proves the rotation works, not that hardware dies. The schedule: a new program every hour, a parameter era every week, a family epoch every 180 days, an emergency vote when miners call one. Rotation costs a chip versatility, not life: the family bank is firmware plus about 43 percent of core cells, and no transition carries an obsolescence credit (modelled).measured per boundary, 8 October 2026; the family-bank cost modelled, 8 October 2026
diff --git a/site/miner.html b/site/miner.html index 15e9ce154..a7a27f94f 100644 --- a/site/miner.html +++ b/site/miner.html @@ -336,7 +336,7 @@ pre b{color:var(--molten-text);font-weight:500}

Graphics cards only. A new mining program every hour, so no chip is built for it. 80% of every block to the card that finds it, 20% to the cards that prove it. No premine, no stake, no fee to any team. Every number above has a row in the bench table.

-

Your card against the strongest chip we can price. 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. Class v6 adopts the 64-register window and retains it across every rotation. 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). For the board on commodity DRAM the two independent chip models agree after placement: 1.5x to 2.1x as a complete machine and 2.0x to 2.9x for the board alone on the GPU’s own node; a node ahead 1.8x to 2.4x and 2.45x to 3.3x (placed and routed on ASAP7, both lanes, the node scaling claimed, the machine terms modelled; the 2.9x end is the resizer-downsized floor of the placed 32-lane comparator, not a point, until the placed core32 lands). The standard’s P04 target reads FAIL at both ends, served as such. The standard’s P04 target as approved: R_E at most 1.5 on the same node and one node ahead; today’s placed bracket reads against it as a FAIL to work against. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment. The GPU side is measured: the RTX 5090 at its 1,300 MHz lock, 2.33 microjoules per hash on class v4, the window’s cost within 5 percent per load (8 October 2026); the chip’s core is placed and routed on ASAP7 with SRAM macros and scaled on claimed node factors; its memory and the rest of the machine (controller, host share, PSU, VRM, cooling) are modelled; no chip is measured and the chip’s hardware cost is approximate within 2x (MODELLED). Under class v5 the chip is wrong on every item because the dataset is the chain’s own state (designed). Every number with its label, the harness and the scoring rules.

+

Your card against the strongest chip we can price. The current model finds that existing GPU electricity costs are below the assessed DRAM-board specialist's all-in costs at the tested tariffs and stated lifetime assumptions. This supports a conditional entry-deterrence result. It does not yet establish post-deployment competitiveness, viable GPU replacement or new entry, or coexistence against the modelled SRAM fleet at sufficient scale. Those outcomes remain separately assessed. Measured on 9 October 2026: a same-node DRAM-board chip reads 2.60x the project’s RTX 5090 at its knee and 5.67x an RTX 4090 at stock per joule (every chip figure a modelled witness, no chip measured); the chip’s capital per unit of work keeps the card you already own mining beside it at the three tested electricity tariffs; a new buyer is held only while the chip maker’s fleet is small. Every figure with its label, adversary, card and file.

diff --git a/site/partials/footer.html b/site/partials/footer.html index 4c0a93353..a107d6615 100644 --- a/site/partials/footer.html +++ b/site/partials/footer.html @@ -26,9 +26,9 @@ diff --git a/site/partials/nav.html b/site/partials/nav.html index afbe2ad07..e8586fb50 100644 --- a/site/partials/nav.html +++ b/site/partials/nav.html @@ -35,7 +35,7 @@
Live devnetThe chain as it grows, one lane per miner. ExplorerLook a block or an address up. - EvidenceEvery claim and how far it is tested. + EvidenceEvery claim and how far it is tested.Public testA test, not a launch: join, report, the five gates. Light walletA balance your browser proves, trusting no node. Payment receiptA receipt any third party re-verifies offline. State oracle on SepoliaBalances on the devnet, read from another chain. @@ -47,7 +47,7 @@ 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.PrizeA better adversary or a reproduced shortcut, never a confirmation: the terms.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open.DocumentsThe plan, the standard, the specifications and the evidence files, by path. LedgerEvery criticism, answered or conceded. - What Igneum does not claimThe limits, stated first. + What Igneum does not claimThe limits, stated first.Chip resistanceThe claim in the record’s words, every figure labelled. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. Built on the shouldersEvery borrowed part, credited.
@@ -77,7 +77,7 @@
Network
Live devnetThe chain as it grows, one lane per miner. ExplorerLook a block or an address up. - EvidenceEvery claim and how far it is tested. + EvidenceEvery claim and how far it is tested.Public testA test, not a launch: join, report, the five gates. Light walletA balance your browser proves, trusting no node. Payment receiptA receipt any third party re-verifies offline. State oracle on SepoliaBalances on the devnet, read from another chain. @@ -87,7 +87,7 @@ 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.PrizeA better adversary or a reproduced shortcut, never a confirmation: the terms.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open.DocumentsThe plan, the standard, the specifications and the evidence files, by path. LedgerEvery criticism, answered or conceded. - What Igneum does not claimThe limits, stated first. + What Igneum does not claimThe limits, stated first.Chip resistanceThe claim in the record’s words, every figure labelled. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. Built on the shouldersEvery borrowed part, credited.
diff --git a/site/sitemap.xml b/site/sitemap.xml index d136c7bb9..23b9c69f3 100644 --- a/site/sitemap.xml +++ b/site/sitemap.xml @@ -25,4 +25,6 @@ https://igneum.network/swap2026-10-08weekly0.5 https://igneum.network/grants2026-10-08monthly0.6 https://igneum.network/compatibility2026-10-08weekly0.6 + https://igneum.network/resistance2026-10-09daily0.8 + https://igneum.network/public-test2026-10-09daily0.8 diff --git a/tools/ci/site-nav-check.mjs b/tools/ci/site-nav-check.mjs index 77d17ea98..6175d0806 100644 --- a/tools/ci/site-nav-check.mjs +++ b/tools/ci/site-nav-check.mjs @@ -14,8 +14,8 @@ import { fileURLToPath } from 'node:url'; const here = dirname(fileURLToPath(import.meta.url)); const GROUPS = { mine: ['/miner', '/download', '/app', '/wallet', '/miners', '/tuning', '/dev-fee', '/metamask'], - network: ['/live', '/explorer', '/evidence', '/light', '/receipt', '/oracle'], - learn: ['/litepaper', '/income', '/economics', '/scorecard', '/prize', '/audit', '/docs', '/ledger', '/claims', '/randomx', '/provenance', '/acceptance'], + network: ['/live', '/explorer', '/evidence', '/public-test', '/light', '/receipt', '/oracle'], + learn: ['/litepaper', '/income', '/economics', '/scorecard', '/prize', '/audit', '/docs', '/ledger', '/claims', '/resistance', '/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-deploy-from-mirror.sh b/tools/site-deploy-from-mirror.sh index fc1b90db0..ed56640f7 100755 --- a/tools/site-deploy-from-mirror.sh +++ b/tools/site-deploy-from-mirror.sh @@ -18,7 +18,7 @@ LIVE_NETWORK="${LIVE_NETWORK:-igneum-devnet-4}" INDEX_STRINGS=("A GPU-secured network for Ethereum-compatible applications and verifiable computation" "git.igneum.network/igneum-network/") # the home-page rewrite hero (41cfd94a, 18:23 BST 8 Oct 2026) LEGAL_PAGE="${LEGAL_PAGE:-/litepaper}"; LEGAL_STRING="Not legal advice" # the legal line lives on the litepaper in master's tree (22:16 UK: no commit put it on the index) MINERS_MIN_ROWS="${MINERS_MIN_ROWS:-20}" # the current-class table alone (the datacentre rows sit in their own table since 8 Oct 2026) -SERVED_PAGES=(swap "faucet|Igneum 2.0 devnet faucet" "build|Built to prove every block" "build|igneum-devnet-4" "grants|Not legal advice." proving tx/0x0 "light|" "receipt|<title>" "oracle|<title>" "lc/test|<title>" "explorer|Source since 12:25 UTC" lc/app.js lc/core.js lc/verify-receipt.js "economics|Not legal advice." "income|The calculator" "income|/income-calc.js" "income|id=\"income-data\"" income-calc.js) # clean URLs every deploy must answer 200 (8 Oct 2026: the DEX lane's /swap, the builder lane's /faucet; /light /receipt /oracle /build /grants join as they land) +SERVED_PAGES=(swap "faucet|Igneum 2.0 devnet faucet" "build|Built to prove every block" "build|igneum-devnet-4" "grants|Not legal advice." proving tx/0x0 "light|<title>" "receipt|<title>" "oracle|<title>" "lc/test|<title>" "explorer|Igneum 2.0 devnet explorer" lc/app.js lc/core.js lc/verify-receipt.js "economics|Not legal advice." "income|The calculator" "income|/income-calc.js" "income|id=\"income-data\"" income-calc.js "resistance|conditional entry-deterrence result" "public-test|The five gates, with their state") # clean URLs every deploy must answer 200 (8 Oct 2026: the DEX lane's /swap, the builder lane's /faucet; /light /receipt /oracle /build /grants join as they land) SITE="${SITE_URL:-https://igneum.network}" # the /miners row count: the rows of the current-class table (table#bench-current, the regrouped bench of 8 Oct 2026; the datacentre # and earlier tables sit under their own ids); known-failed: an empty table reads 0 @@ -92,7 +92,7 @@ SHA=$(git rev-parse "$REF"); SHORT=${SHA:0:8} # metadata, so the check does not apply). The deploy directory must hold no .git; the check below refuses otherwise. W=$(mktemp -d "${TMPDIR:-/tmp}/site-deploy.XXXXXX") trap 'rm -rf "$W"' EXIT -git archive --format=tar "$SHA" site | tar -x -C "$W" +git archive --format=tar "$SHA" site tools/ci/served-identity-guard.sh tools/ci/forbidden-strings.txt | tar -x -C "$W" # the guard rides with the export (9 October 2026, 13:xx UK: a site-only export built unguarded) [ -e "$W/.git" ] || [ -e "$W/site/.git" ] && { echo "the deploy directory carries a .git; refusing (the author check would block it)" >&2; exit 1; } LINK="$HOME/Projects/igneum/site/.vercel/project.json"; [ -f "$LINK" ] || { echo "no site project link at $LINK" >&2; exit 1; } # the Vercel project's Root Directory is "site": the deploy runs from the export's root with site/ inside it @@ -104,6 +104,6 @@ OUT=$( cd "$W" && npx --yes vercel@latest --global-config "$HOME/.config/igneum/ URL=$(echo "$OUT" | grep -oE 'https://[a-z0-9.-]*vercel\.app' | tail -1) # the post-deploy checks, retried while the edge still serves the previous deployment (up to 90 s) verdict=""; for i in $(seq 1 30); do verdict=$(post_checks 2>&1) && break; sleep 5; done # up to 150 s: the edge serves the previous deployment per path for a while (22:27 BST: the litepaper lagged the API by over 90 s) -case "$verdict" in ok:*) echo "post-deploy checks $verdict" ;; *) echo "DEPLOY RED $verdict (commit $SHORT at the edge $URL, $(TZ=Europe/London date +%H:%M) BST)" >&2; exit 1 ;; esac -echo "SITE DEPLOYED commit $SHORT at $(TZ=UTC date +%H:%M:%SZ) UTC ($(TZ=Europe/London date +%H:%M) BST): $URL -> https://igneum.network" +case "$verdict" in ok:*) echo "post-deploy checks $verdict" ;; *) echo "DEPLOY RED $verdict (commit $SHORT at the edge $URL, $(TZ=Europe/London date +%H:%M) UK)" >&2; exit 1 ;; esac +echo "SITE DEPLOYED commit $SHORT at $(TZ=UTC date +%H:%M:%SZ) UTC ($(TZ=Europe/London date +%H:%M) UK): $URL -> https://igneum.network" echo "$OUT" | grep -iE "Production:|Aliased|error" | head -3 From 3bdbc6f7115a644c06704cb5fc41ab288d168214 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Fri, 9 Oct 2026 12:01:57 +0000 Subject: [PATCH 02/10] Claims page: the phase B row names what runs on chain today (the fleet's prover stack, paid on the devnet) and keeps NOT LIVE until a shipped package proves Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --- docs/claims/resistance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/claims/resistance.md b/docs/claims/resistance.md index b0c838d63..5b6c31278 100644 --- a/docs/claims/resistance.md +++ b/docs/claims/resistance.md @@ -110,7 +110,7 @@ In words: a maker's spend comes back only where the chain is small and the price | The share at which the hybrid's disappears | 13 percent | WITNESS; NOT LIVE | | The share at which the die's disappears | 20 percent (the ratified share exactly) | WITNESS; NOT LIVE | -**NOT LIVE.** The proving rows are modelled on a proving income that the shipped packages do not yet pay out across the cohort. Today the Mac and Windows apps carry the prover, on by default only on an NVIDIA card of 24 GB or more (a 16 GB card holds no shard); the HiveOS package mines only, its prover entry in cut. The label changes to LIVE only on the proving lane's evidence that a shipped package proves beside mining on the cohort and is paid for it; until then phase B is a model of what the rules pay, not a measurement of what cards earn. The stated assumption on every phase B row: all proving stays on the GPU cohort; a chip maker who fields GPUs to prove is a GPU miner with a sidecar. +**NOT LIVE.** The proving rows are modelled on a proving income that the shipped packages do not yet pay out across the cohort. Today the Mac and Windows apps carry the prover, on by default only on an NVIDIA card of 24 GB or more (a 16 GB card holds no shard); the HiveOS package mines only, its prover entry in cut. What exists today is the project's own fleet: its prover stack (the same binaries the HiveOS prover package wraps) proves shards beside its miners on rented 24 GB cards and is paid the proving share by the pool (663 paid segment records to 30 prover keys from genesis to chain block 31,719, read at 11:50 UTC on 9 October 2026 from the node's proving-status and segment-record calls), so the mechanism runs on chain, but in the fleet's stack, not in a shipped package. The label changes to LIVE only on the proving lane's evidence that a shipped package proves beside mining on the cohort and is paid for it, with the record's path and sha on this row; until then phase B is a model of what the rules pay, not a measurement of what an operator's card earns. The stated assumption on every phase B row: all proving stays on the GPU cohort; a chip maker who fields GPUs to prove is a GPU miner with a sidecar. ## 8. The residual: the die From d8cefefa84df0e3ac0dcd160a56dcee3a3881bd9 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Fri, 9 Oct 2026 12:03:19 +0000 Subject: [PATCH 03/10] Site: the rendered pages for /resistance and /public-test and the nav with the two new routes (built on the box) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --- site/404.html | 12 +- site/acceptance.html | 22 +-- site/address.html | 12 +- site/app.html | 12 +- site/audit.html | 12 +- site/block.html | 12 +- site/build.html | 12 +- site/claims.html | 12 +- site/compatibility.html | 12 +- site/dev-fee.html | 12 +- site/docs.html | 12 +- site/download.html | 12 +- site/economics.html | 12 +- site/evidence.html | 14 +- site/explorer.html | 12 +- site/faucet.html | 12 +- site/grants.html | 12 +- site/income.html | 12 +- site/index.html | 12 +- site/ledger.html | 12 +- site/light.html | 12 +- site/litepaper.html | 12 +- site/live.html | 12 +- site/metamask.html | 12 +- site/miner.html | 12 +- site/miners.html | 12 +- site/oracle.html | 12 +- site/prize.html | 12 +- site/provenance.html | 12 +- site/proving.html | 12 +- site/public-test.html | 353 +++++++++++++++++++++++++++++++++++++ site/randomx.html | 12 +- site/receipt.html | 12 +- site/resistance.html | 382 ++++++++++++++++++++++++++++++++++++++++ site/scenes.html | 12 +- site/scorecard.html | 12 +- site/swap.html | 12 +- site/tuning.html | 12 +- site/tx.html | 12 +- site/wallet.html | 12 +- 40 files changed, 969 insertions(+), 234 deletions(-) create mode 100644 site/public-test.html create mode 100644 site/resistance.html diff --git a/site/404.html b/site/404.html index 71c3126ff..9857baf1e 100644 --- a/site/404.html +++ b/site/404.html @@ -107,7 +107,7 @@ main{flex:1} <div class="panel-list"> <a href="/live" data-nav="live"><b>Live devnet</b><span>The chain as it grows, one lane per miner.</span></a> <a href="/explorer" data-nav="explorer"><b>Explorer</b><span>Look a block or an address up.</span></a> - <a href="/evidence" data-nav="evidence"><b>Evidence</b><span>Every claim and how far it is tested.</span></a> + <a href="/evidence" data-nav="evidence"><b>Evidence</b><span>Every claim and how far it is tested.</span></a><a href="/public-test" data-nav="public-test"><b>Public test</b><span>A test, not a launch: join, report, the five gates.</span></a> <a href="/light" data-nav="light"><b>Light wallet</b><span>A balance your browser proves, trusting no node.</span></a> <a href="/receipt" data-nav="receipt"><b>Payment receipt</b><span>A receipt any third party re-verifies offline.</span></a> <a href="/oracle" data-nav="oracle"><b>State oracle on Sepolia</b><span>Balances on the devnet, read from another chain.</span></a> @@ -119,7 +119,7 @@ main{flex:1} <a href="/income" data-nav="income"><b>Income</b><span>What your card would mine, from the live network.</span></a> <a href="/economics" data-nav="economics"><b>Economics</b><span>The emission, the split and the fees, each with its line in the node.</span></a><a href="/scorecard" data-nav="scorecard"><b>Scorecard</b><span>The twelve acceptance gates, their evidence and where each stands.</span></a><a href="/prize" data-nav="prize"><b>Prize</b><span>A better adversary or a reproduced shortcut, never a confirmation: the terms.</span></a><a href="/acceptance" data-nav="acceptance"><b>Acceptance</b><span>The Test and Acceptance Standard, case by case, as each one passes.</span></a><a href="/audit" data-nav="audit"><b>Site audit</b><span>Every page, what the reset changed and what is open.</span></a><a href="/docs" data-nav="docs"><b>Documents</b><span>The plan, the standard, the specifications and the evidence files, by path.</span></a> <a href="/ledger" data-nav="ledger"><b>Ledger</b><span>Every criticism, answered or conceded.</span></a> - <a href="/claims" data-nav="claims"><b>What Igneum does not claim</b><span>The limits, stated first.</span></a> + <a href="/claims" data-nav="claims"><b>What Igneum does not claim</b><span>The limits, stated first.</span></a><a href="/resistance" data-nav="resistance"><b>Chip resistance</b><span>The claim in the record’s words, every figure labelled.</span></a> <a href="/randomx" data-nav="randomx"><b>Igneum vs RandomX</b><span>What was kept and what was rebuilt for GPUs.</span></a> <a href="/provenance" data-nav="provenance"><b>Built on the shoulders</b><span>Every borrowed part, credited.</span></a> </div> @@ -149,7 +149,7 @@ main{flex:1} <div class="sheet-group"><div class="sheet-head">Network</div> <a href="/live" data-nav="live"><b>Live devnet</b><span>The chain as it grows, one lane per miner.</span></a> <a href="/explorer" data-nav="explorer"><b>Explorer</b><span>Look a block or an address up.</span></a> - <a href="/evidence" data-nav="evidence"><b>Evidence</b><span>Every claim and how far it is tested.</span></a> + <a href="/evidence" data-nav="evidence"><b>Evidence</b><span>Every claim and how far it is tested.</span></a><a href="/public-test" data-nav="public-test"><b>Public test</b><span>A test, not a launch: join, report, the five gates.</span></a> <a href="/light" data-nav="light"><b>Light wallet</b><span>A balance your browser proves, trusting no node.</span></a> <a href="/receipt" data-nav="receipt"><b>Payment receipt</b><span>A receipt any third party re-verifies offline.</span></a> <a href="/oracle" data-nav="oracle"><b>State oracle on Sepolia</b><span>Balances on the devnet, read from another chain.</span></a> @@ -159,7 +159,7 @@ main{flex:1} <a href="/income" data-nav="income"><b>Income</b><span>What your card would mine, from the live network.</span></a> <a href="/economics" data-nav="economics"><b>Economics</b><span>The emission, the split and the fees, each with its line in the node.</span></a><a href="/scorecard" data-nav="scorecard"><b>Scorecard</b><span>The twelve acceptance gates, their evidence and where each stands.</span></a><a href="/prize" data-nav="prize"><b>Prize</b><span>A better adversary or a reproduced shortcut, never a confirmation: the terms.</span></a><a href="/acceptance" data-nav="acceptance"><b>Acceptance</b><span>The Test and Acceptance Standard, case by case, as each one passes.</span></a><a href="/audit" data-nav="audit"><b>Site audit</b><span>Every page, what the reset changed and what is open.</span></a><a href="/docs" data-nav="docs"><b>Documents</b><span>The plan, the standard, the specifications and the evidence files, by path.</span></a> <a href="/ledger" data-nav="ledger"><b>Ledger</b><span>Every criticism, answered or conceded.</span></a> - <a href="/claims" data-nav="claims"><b>What Igneum does not claim</b><span>The limits, stated first.</span></a> + <a href="/claims" data-nav="claims"><b>What Igneum does not claim</b><span>The limits, stated first.</span></a><a href="/resistance" data-nav="resistance"><b>Chip resistance</b><span>The claim in the record’s words, every figure labelled.</span></a> <a href="/randomx" data-nav="randomx"><b>Igneum vs RandomX</b><span>What was kept and what was rebuilt for GPUs.</span></a> <a href="/provenance" data-nav="provenance"><b>Built on the shoulders</b><span>Every borrowed part, credited.</span></a> </div> @@ -265,9 +265,9 @@ main{flex:1} </div></div> <div class="footer-column"><h4>Read</h4><div> <a href="/litepaper">Litepaper</a> - <a href="/evidence">Evidence</a> + <a href="/evidence">Evidence</a><a href="/public-test">Public test</a> <a href="/ledger">Ledger: every criticism</a> - <a href="/claims">What Igneum does not claim</a> + <a href="/claims">What Igneum does not claim</a><a href="/resistance">Chip resistance</a> <a href="/randomx">Igneum vs RandomX</a> <a href="/provenance">Built on the shoulders</a> </div></div> diff --git a/site/acceptance.html b/site/acceptance.html index b103fb51e..e9632c43e 100644 --- a/site/acceptance.html +++ b/site/acceptance.html @@ -4,13 +4,13 @@ <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover"> <title>Igneum Test and Acceptance Standard: every case, shown as it passes - + - + @@ -24,7 +24,7 @@ - + @@ -250,7 +250,7 @@
Live devnetThe chain as it grows, one lane per miner. ExplorerLook a block or an address up. - EvidenceEvery claim and how far it is tested. + EvidenceEvery claim and how far it is tested.Public testA test, not a launch: join, report, the five gates. Light walletA balance your browser proves, trusting no node. Payment receiptA receipt any third party re-verifies offline. State oracle on SepoliaBalances on the devnet, read from another chain. @@ -262,7 +262,7 @@ 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.PrizeA better adversary or a reproduced shortcut, never a confirmation: the terms.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open.DocumentsThe plan, the standard, the specifications and the evidence files, by path. LedgerEvery criticism, answered or conceded. - What Igneum does not claimThe limits, stated first. + What Igneum does not claimThe limits, stated first.Chip resistanceThe claim in the record’s words, every figure labelled. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. Built on the shouldersEvery borrowed part, credited.
@@ -292,7 +292,7 @@
Network
Live devnetThe chain as it grows, one lane per miner. ExplorerLook a block or an address up. - EvidenceEvery claim and how far it is tested. + EvidenceEvery claim and how far it is tested.Public testA test, not a launch: join, report, the five gates. Light walletA balance your browser proves, trusting no node. Payment receiptA receipt any third party re-verifies offline. State oracle on SepoliaBalances on the devnet, read from another chain. @@ -302,7 +302,7 @@ 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.PrizeA better adversary or a reproduced shortcut, never a confirmation: the terms.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open.DocumentsThe plan, the standard, the specifications and the evidence files, by path. LedgerEvery criticism, answered or conceded. - What Igneum does not claimThe limits, stated first. + What Igneum does not claimThe limits, stated first.Chip resistanceThe claim in the record’s words, every figure labelled. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. Built on the shouldersEvery borrowed part, credited.
@@ -368,8 +368,8 @@
-
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 DEFERRED

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

  • 8 pass
  • 7 fail
  • 0 blocked
  • 0 running
  • 247 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: 1 passed under the standard, 0 running with team evidence, 15 not run, 0 deferred

  • GOV8 casesNOT RUN
  • GPU8 casesNOT RUN
G2FAIL

Experiments

D2

No improvement claim from a negative hypothesis.

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

  • GOV8 casesNOT RUN
  • GPU8 casesNOT RUN
  • POW8 casesFAIL
  • 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
G4FAIL

Coexistence

D4

No durability claim based on assumed chip expiry.

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

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

No rescue

D5

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

56 cases: 5 passed under the standard, 0 running with team evidence, 51 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

FAIL

Technical readiness

Execution control

No mainnet-ready claim with missing enforcement or safety.

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

  • GOV8 casesNOT RUN
  • POW8 casesFAIL
  • EVM8 casesNOT RUN
  • ZKP8 casesNOT RUN
  • CAP8 casesNOT RUN
  • FIN8 casesNOT RUN
  • VER8 casesFAIL
  • 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
FAIL

Leadership-contender decision

Execution control

Supports a scoped contention assessment, not a guaranteed rank.

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

  • GOV8 casesNOT RUN
  • GPU8 casesNOT RUN
  • POW8 casesFAIL
  • ADV8 casesNOT RUN
  • ROT8 casesNOT RUN
  • ECO8 casesFAIL
  • EVM8 casesNOT RUN
  • ZKP8 casesNOT RUN
  • CAP8 casesNOT RUN
  • INC8 casesNOT RUN
  • FIN8 casesNOT RUN
  • VER8 casesFAIL
  • OPS8 casesNOT RUN
  • UX8 casesNOT RUN
  • COM8 casesNOT RUN
  • LEAD8 casesNOT RUN
  • REV44 casesNOT RUN
  • INT18 casesFAIL
  • VR40 casesNOT RUN
  • TV32 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 9 Oct 2026, 08:43 UK

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
node lane (a283f5f0d364ceef0)
Run
f0-signing-20261008-2330
Design status
NOT RUN
Standard page
18
Plan pages
5, 21, 23, 25, 26, 27
GOV-02Approve thresholds before resultsPriority BLOCKERProfile P00NOT RUNEvidence recordLast run 8 Oct 2026, 21:10 UK

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
CI steward (a2ecfa95d3206016c)
Run
team-2026-10-08
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
Standard page
18
Plan pages
5, 21, 23, 25, 26, 27
GOV-04Preserve raw and negative evidencePriority BLOCKERProfile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
CI steward (a2ecfa95d3206016c)
Design status
NOT RUN
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 8 Oct 2026, 19:28 UK

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
fast-time lane (a8be71a0db962911c)
Run
200-417c4a57-b2
Design status
NOT RUN
Standard page
19
Plan pages
5, 21, 23, 25, 26, 27
GOV-06Enforce scope and optional-feature disciplinePriority BLOCKERProfile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 08:36 UK

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
CI steward (a2ecfa95d3206016c)
Run
site-gate-20261009-01
Design status
NOT RUN
Standard page
19
Plan pages
5, 21, 23, 25, 26, 27
GOV-07Independent review and finding closurePriority BLOCKERProfile P09NOT RUNEvidence none yetLast run 2026-10-08 18:3x UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
CI steward (a2ecfa95d3206016c)
Design status
NOT RUN
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: 1 passed under the standard, 0 running with team evidence, 7 not run, 0 deferred
GPU-01Cover the declared commodity populationPriority GATEProfile P02NOT RUNEvidence none yetLast run 8 Oct 2026, 22:49 UK

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
research lane (ad6a2bd47d4a46105)
Run
p02-fleet-pods-20261008-01
Design status
NOT RUN
Standard page
21
Plan pages
6, 7, 8, 14, 18, 23
GPU-02Reproduce Ember clock-lock savingsPriority GATEProfile P02, P03PASSEvidence recordLast run 9 Oct 2026, 04:58 UK

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
hash lane (a690540514aa453d7)
Run
hash-lane-20261009-batch4
Design status
NOT RUN
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 9 Oct 2026, 04:58 UK

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
hash lane (a690540514aa453d7)
Run
hash-lane-20261009-batch4
Design status
NOT RUN
Standard page
21
Plan pages
6, 7, 8, 14, 18, 23
GPU-04Find the memory-clock operating ladderPriority BLOCKERProfile P01, P02NOT RUNEvidence recordLast run 8 Oct 2026, 22:00 UK

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
hash lane (a690540514aa453d7)
Run
team-2026-10-08
Design status
NOT RUN
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 9 Oct 2026, 04:58 UK

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
hash lane (a690540514aa453d7)
Run
hash-lane-20261009-batch4
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
22
Plan pages
6, 7, 8, 14, 18, 23
GPU-07Survive sustained thermal and power operationPriority BLOCKERProfile P01, P02, P10NOT RUNEvidence recordLast run 8 Oct 2026, 22:00 UK

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
hash lane (a690540514aa453d7)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
23
Plan pages
6, 7, 8, 14, 18, 23
GPU-08Reproduce the full baseline independentlyPriority GATEProfile P02NOT RUNEvidence none yetLast run 2026-10-08 18:3x UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
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.

FAIL
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, 2 failed, 6 not run, 0 deferred
POW-01Match independent execution across every backendPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run 9 Oct 2026, 06:16 UK

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
hash lane (a690540514aa453d7)
Run
same-work-20261008-01
Design status
NOT RUN
Standard page
24
Plan pages
7, 9, 10, 23
POW-02Validate generated programs and index foldingPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
hash lane (a690540514aa453d7)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
24
Plan pages
7, 9, 10, 23
POW-03Test whether live state is unavoidablePriority GATEProfile P03, P04FAILEvidence none yetLast run 9 Oct 2026, 08:32 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
24
Plan pages
7, 9, 10, 23
POW-04Evaluate connected-resource restructuringPriority GATEProfile P03, P04NOT RUNEvidence none yetLast run 9 Oct 2026, 08:32 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
25
Plan pages
7, 9, 10, 23
POW-05Prevent amortised cheap winning attemptsPriority BLOCKERProfile P01, P04NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

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
pool design seat (a3832b1c3b274b310)
Run
binding-review-2026-10-08-a05
Design status
NOT RUN
Standard page
25
Plan pages
7, 9, 10, 23
POW-06Bound verifier work and malformed-input costPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 8 Oct 2026, 19:28 UK

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
hash lane (a690540514aa453d7)
Run
p01-partb-20261008-01
Design status
NOT RUN
Standard page
25
Plan pages
7, 9, 10, 23
POW-07Constrain any mixed-resource or FP32 branchPriority BLOCKERProfile P00, P01, P03FAILEvidence none yetLast run 8 Oct 2026, 22:00 UK

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
hash lane (a690540514aa453d7)
Run
kills-20261008
Design status
NOT RUN
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 9 Oct 2026, 04:58 UK

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
hash lane (a690540514aa453d7)
Run
hash-lane-20261009-batch4
Design status
NOT RUN
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 recordLast run 9 Oct 2026, 08:32 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
27
Plan pages
8, 10, 12, 22, 23
ADV-02Price shared, reduced and reconstructed memoryPriority GATEProfile P04NOT RUNEvidence recordLast run 8 Oct 2026, 21:41 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261008-placed-8lane
Design status
NOT RUN
Standard page
27
Plan pages
8, 10, 12, 22, 23
ADV-03Attack with data-local and hybrid executionPriority GATEProfile P04NOT RUNEvidence recordLast run 9 Oct 2026, 08:32 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
27
Plan pages
8, 10, 12, 22, 23
ADV-04Measure profitable selective participationPriority GATEProfile P04, P12NOT RUNEvidence recordLast run 8 Oct 2026, 21:41 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261008-placed-8lane
Design status
NOT RUN
Standard page
28
Plan pages
8, 10, 12, 22, 23
ADV-05Validate physical and complete-board costsPriority GATEProfile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 08:32 UK

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
k lane (a3c9601a6d4686fe1)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
28
Plan pages
8, 10, 12, 22, 23
ADV-06Separate process advantage from specialisationPriority GATEProfile P04, P12NOT RUNEvidence recordLast run 8 Oct 2026, 22:09 UK

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
k lane (a3c9601a6d4686fe1)
Run
floor-k-20261008-rows-repeat
Design status
NOT RUN
Standard page
28
Plan pages
8, 10, 12, 22, 23
ADV-07Evaluate lifetime without forced obsolescencePriority GATEProfile P04, P12NOT RUNEvidence none yetLast run 9 Oct 2026, 08:32 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
29
Plan pages
8, 10, 12, 22, 23
ADV-08Independently challenge the best-cost envelopePriority GATEProfile P04NOT RUNEvidence recordLast run 9 Oct 2026, 08:32 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
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 recordLast run 8 Oct 2026, 21:07 UK

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
fast-time lane (a8be71a0db962911c)
Run
f10-worker-20261008
Design status
NOT RUN
Standard page
30
Plan pages
7, 11, 19, 21
ROT-02Cross weekly and family boundaries togetherPriority BLOCKERProfile P01, P03, P08NOT RUNEvidence none yetLast run 2026-10-08 18:3x UK

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.

Evidence record of the run

What was run
the class v6 object crossing at its floor on 617cb441
Run by
fast-time lane (a8be71a0db962911c)
Under the standard
no: team-run before the standard's procedure; the status is RUNNING until the case is re-run under its steps with the profile's numbers and an independent run where the profile asks one
Pass or fail today
not judged under the standard yet
Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
fast-time lane (a8be71a0db962911c)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
30
Plan pages
7, 11, 19, 21
ROT-03Test miner-voted bring-forward governancePriority BLOCKERProfile P00, P01, P08NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

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
node lane (a283f5f0d364ceef0)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
30
Plan pages
7, 11, 19, 21
ROT-04Resist seed selection and faster evaluatorsPriority BLOCKERProfile P00, P01, P08NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
node lane (a283f5f0d364ceef0)
Design status
NOT RUN
Standard page
31
Plan pages
7, 11, 19, 21
ROT-05Continue or pause correctly when finality stopsPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
finality lane (aca0f5ed924a2a99b)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
31
Plan pages
7, 11, 19, 21
ROT-06Activate datasets without hidden exclusionsPriority BLOCKERProfile P01, P06NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
hash lane (a690540514aa453d7)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
31
Plan pages
7, 11, 19, 21
ROT-07Ablate redundant rotation layersPriority GATEProfile P03, P04NOT RUNEvidence recordLast run 8 Oct 2026, 22:49 UK

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
lane D family gate (a07a99a3788566af2)
Run
family-gate-20261008c
Design status
NOT RUN
Standard page
32
Plan pages
7, 11, 19, 21
ROT-08Pass the no-new-rules counterfactualPriority GATEProfile P04, P12NOT RUNEvidence recordLast run 8 Oct 2026, 22:49 UK

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
node lane (a283f5f0d364ceef0)
Run
family-gate-20261008c
Design status
NOT RUN
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.

FAIL
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, 1 failed, 7 not run, 0 deferred
ECO-01Reconcile complete cost per accepted workPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 21:07 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco05-20261008-02
Design status
NOT RUN
Standard page
33
Plan pages
8, 13, 18, 24, 26
ECO-02Separate existing-owner and new-entrant viabilityPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
33
Plan pages
8, 13, 18, 24, 26
ECO-03Let the specialist keep its sunk developmentPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
33
Plan pages
8, 13, 18, 24, 26
ECO-04Model entry, exit and difficulty responsePriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
34
Plan pages
8, 13, 18, 24, 26
ECO-05Stress success, contraction and cheap electricityPriority GATEProfile P12FAILEvidence recordLast run 8 Oct 2026, 21:07 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco05-20261008-02
Design status
NOT RUN
Standard page
34
Plan pages
8, 13, 18, 24, 26
ECO-06Fund security and proving as issuance fallsPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
34
Plan pages
8, 13, 18, 24, 26
ECO-07Price memory growth and honest-card displacementPriority GATEProfile P06, P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
35
Plan pages
8, 13, 18, 24, 26
ECO-08Reproduce and adversarially audit the modelPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 21:07 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco05-20261008-02
Design status
NOT RUN
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: 1 passed under the standard, 0 running with team evidence, 7 not run, 0 deferred
EVM-01Match the selected EVM semanticsPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 21:10 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
36
Plan pages
15, 25, 34, 35, 36, 37
EVM-02Preserve transaction binding and replay protectionPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
36
Plan pages
15, 25, 34, 35, 36, 37
EVM-03Test two-dimensional fees and proving limitsPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:13 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1744-evm
Design status
NOT RUN
Standard page
36
Plan pages
15, 25, 34, 35, 36, 37
EVM-04Exercise block context and randomness assumptionsPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:13 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1744-evm
Design status
NOT RUN
Standard page
37
Plan pages
15, 25, 34, 35, 36, 37
EVM-05Run representative contract integration journeysPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:13 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1744-evm
Design status
NOT RUN
Standard page
37
Plan pages
15, 25, 34, 35, 36, 37
EVM-06Validate wallets, RPC and indexersPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:13 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1744-evm
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
reference-apps lane (a2060899d2a27d31c)
Design status
NOT RUN
Standard page
38
Plan pages
15, 25, 34, 35, 36, 37
EVM-08Verify controlled execution and verifier upgradesPriority BLOCKERProfile P01, P08, P09PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
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: 4 passed under the standard, 0 running with team evidence, 4 not run, 0 deferred
ZKP-01Reject missing and invalid proofsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
39
Plan pages
16, 20, 24, 25, 36, 37
ZKP-02Bind program, verifier and security parametersPriority BLOCKERProfile P01, P09PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
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 9 Oct 2026, 01:33 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
39
Plan pages
16, 20, 24, 25, 36, 37
ZKP-04Prevent reward and payout substitutionPriority BLOCKERProfile P01PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
Standard page
40
Plan pages
16, 20, 24, 25, 36, 37
ZKP-05Make proof payment idempotent across racesPriority BLOCKERProfile P01PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
Standard page
40
Plan pages
16, 20, 24, 25, 36, 37
ZKP-06Verify aggregation coverage and completenessPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
enforced-proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Standard page
41
Plan pages
16, 20, 24, 25, 36, 37
ZKP-08Preserve authority and audit all acceptance pathsPriority BLOCKERProfile P01, P07, P08PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
42
Plan pages
17, 18, 24, 25
CAP-02Prove on the actual mining configurationPriority BLOCKERProfile P01, P06, P07NOT RUNEvidence recordLast run 8 Oct 2026, 23:22 UK

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
fleet lane (ac055d60427caab99)
Run
v607-floor-memory-20261008T2059Z
Design status
NOT RUN
Standard page
42
Plan pages
17, 18, 24, 25
CAP-03Measure the entire request-to-payment pathPriority GATEProfile P07NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
42
Plan pages
17, 18, 24, 25
CAP-04Sustain meaningful load without queue growthPriority GATEProfile P07NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
43
Plan pages
17, 18, 24, 25
CAP-05Overload and recover without false acceptancePriority BLOCKERProfile P01, P07NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
43
Plan pages
17, 18, 24, 25
CAP-06Calibrate assignment windows to paid completionPriority GATEProfile P07, P12NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
44
Plan pages
17, 18, 24, 25
CAP-08Deliver customer-verifiable output at scalePriority BLOCKERProfile P01, P07, P14NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
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 9 Oct 2026, 01:33 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
45
Plan pages
13, 16, 17, 18, 24, 26
INC-02Keep revenue streams and claims separatePriority BLOCKERProfile P01, P12, P14NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
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 recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
45
Plan pages
13, 16, 17, 18, 24, 26
INC-04Survive external-demand spikes and token declinesPriority GATEProfile P07, P08, P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
enforced-proving lane (a6e8f84588b809d62)
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
research lane (ad6a2bd47d4a46105)
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
enforced-proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Standard page
47
Plan pages
13, 16, 17, 18, 24, 26
INC-08Quantify provider and supplier failure concentrationPriority GATEProfile P08, P11, P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
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: 1 passed under the standard, 0 running with team evidence, 7 not run, 0 deferred
FIN-01Agree on ordering, work and executed statePriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
fast-time lane (a8be71a0db962911c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
48
Plan pages
19, 21, 24, 25
FIN-02Attack finality with split honest populationsPriority BLOCKERProfile P01, P08PASSEvidence recordLast run 9 Oct 2026, 02:02 UK

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
finality lane (aca0f5ed924a2a99b)
Run
fin-203-20261009T0127Z
Design status
NOT RUN
Standard page
48
Plan pages
19, 21, 24, 25
FIN-03Cross authority expiry in a long partitionPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
finality lane (aca0f5ed924a2a99b)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
48
Plan pages
19, 21, 24, 25
FIN-04Stop signing while mining continuesPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
finality lane (aca0f5ed924a2a99b)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
49
Plan pages
19, 21, 24, 25
FIN-05Authenticate voter-set changes and pooled keysPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
finality lane (aca0f5ed924a2a99b)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
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 8 Oct 2026, 21:10 UK

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
finality lane (aca0f5ed924a2a99b)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
49
Plan pages
19, 21, 24, 25
FIN-07Recover deterministically after reconnection and crashPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 02:02 UK

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
finality lane (aca0f5ed924a2a99b)
Run
fin-203-20261009T0127Z
Design status
NOT RUN
Standard page
50
Plan pages
19, 21, 24, 25
FIN-08Combine boundaries, faults and adversarial schedulingPriority BLOCKERProfile P01, P08NOT RUNEvidence recordLast run 9 Oct 2026, 02:02 UK

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
fast-time lane (a8be71a0db962911c)
Run
fin-203-20261009T0127Z
Design status
NOT RUN
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.

FAIL
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, 3 failed, 5 not run, 0 deferred
VER-01Authenticate light-client bootstrapPriority BLOCKERProfile P01, P09FAILEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
51
Plan pages
20, 25, 35, 37
VER-02Verify evolving authority and execution statementsPriority BLOCKERProfile P01, P09FAILEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
51
Plan pages
20, 25, 35, 37
VER-03Prove successful payment rather than inclusionPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
51
Plan pages
20, 25, 35, 37
VER-04Bound cross-chain oracle trust and replayPriority BLOCKERProfile P00, P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
52
Plan pages
20, 25, 35, 37
VER-05Reconstruct required state without founder storagePriority BLOCKERProfile P01, P08, P09FAILEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
52
Plan pages
20, 25, 35, 37
VER-06Detect withholding, corruption and stale dataPriority BLOCKERProfile P01, P08, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
52
Plan pages
20, 25, 35, 37
VER-07Protect wallet keys, signing and recoveryPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
shipper (ae892a8b0f78fe31c)
Design status
NOT RUN
Standard page
53
Plan pages
20, 25, 35, 37
VER-08Keep every user-facing state truthfulPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
node lane (a283f5f0d364ceef0)
Design status
NOT RUN
Standard page
54
Plan pages
21, 24, 25, 26
OPS-02Diversify bootstrap and resist peer isolationPriority BLOCKERProfile P01, P08, P09NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
Standard page
54
Plan pages
21, 24, 25, 26
OPS-03Separate update distribution from consensus authorityPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

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
shipper (ae892a8b0f78fe31c)
Run
site-manifest-20261009-02
Design status
NOT RUN
Standard page
54
Plan pages
21, 24, 25, 26
OPS-04Recover nodes from crash and storage damagePriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
node lane (a283f5f0d364ceef0)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
55
Plan pages
21, 24, 25, 26
OPS-05Isolate untrusted proving workloadsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
Standard page
55
Plan pages
21, 24, 25, 26
OPS-06Contain malicious network and API trafficPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
build-server lane (a352e49ff4613df86)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
55
Plan pages
21, 24, 25, 26
OPS-07Detect failures with usable evidence and runbooksPriority GATEProfile P09, P10NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
Standard page
56
Plan pages
21, 24, 25, 26
OPS-08Repeat independent operation across releasesPriority BLOCKERProfile P00, P08, P11NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
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 recordLast run 8 Oct 2026, 21:42 UK

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
update-return lane (a22d765a2e0355a9f)
Run
ux-01-20261008-win-2.0.0
Design status
NOT RUN
Standard page
57
Plan pages
14, 21, 25, 26
UX-02Make pause, stop and safe tuning reliablePriority BLOCKERProfile P01, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
shipper (ae892a8b0f78fe31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
57
Plan pages
14, 21, 25, 26
UX-03Show net earnings and compatibility honestlyPriority BLOCKERProfile P01, P10, P12NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
shipper (ae892a8b0f78fe31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
57
Plan pages
14, 21, 25, 26
UX-04Pay small operators without hidden custodyPriority BLOCKERProfile P01, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
pool design seat (a3832b1c3b274b310)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
58
Plan pages
14, 21, 25, 26
UX-05Keep voting keys with the miner through poolingPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 21:48 UK

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
pool design seat (a3832b1c3b274b310)
Run
pool-2.0-20261008-03
Design status
NOT RUN
Standard page
58
Plan pages
14, 21, 25, 26
UX-06Verify actual miner-selected work templatesPriority BLOCKERProfile P01, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
shipper (ae892a8b0f78fe31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
58
Plan pages
14, 21, 25, 26
UX-07Expose actionable failures and safe updatesPriority BLOCKERProfile P09, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
shipper (ae892a8b0f78fe31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
59
Plan pages
14, 21, 25, 26
UX-08Publish competitive accessible softwarePriority GATEProfile P02, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 08:36 UK

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
hash lane (a690540514aa453d7)
Run
site-gate-20261009-01
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 21:10 UK

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
main / the founder
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
main / the founder
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
site lane (a846fd66b5403e35a)
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
Standard page
65
Plan pages
4, 22, 25, 27, 31, 32, 33
17REV

REV: the external review's required regressions

44 regressions from 14 findings; each reads NOT RUN until its owner lane records a run

NOT RUN
Owner
the owner lanes per the dispatch table
Gate
Review findings closed
Fixtures
F0,F5
Plan pages
docs/analysis/review-2026-10-08-b/findings.json and docs/analysis/review-2026-10-08-b/dispatch.md; ids from the master traceability register
44 cases: 1 passed under the standard, 0 running with team evidence, 43 not run, 0 deferred
R2-F01-R01Valid proof A, warm cache, carried statement B: refuse exactly as a cold node does.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F01 requires (review R2 finding F01: Proof-verdict cache omits the statement being verified).

Steps

  1. Valid proof A, warm cache, carried statement B: refuse exactly as a cold node does.

Accept

Valid proof A, warm cache, carried statement B: refuse exactly as a cold node does.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, node lane
Design status
NOT RUN
Plan pages
R2-F01
R2-F01-R02Run valid/invalid contexts in both orders, concurrently and across cache eviction/restart.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F01 requires (review R2 finding F01: Proof-verdict cache omits the statement being verified).

Steps

  1. Run valid/invalid contexts in both orders, concurrently and across cache eviction/restart.

Accept

Run valid/invalid contexts in both orders, concurrently and across cache eviction/restart.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, node lane
Design status
NOT RUN
Plan pages
R2-F01
R2-F01-R03Change payout, network, kind, program ID and activation context; no accepted misbinding.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F01 requires (review R2 finding F01: Proof-verdict cache omits the statement being verified).

Steps

  1. Change payout, network, kind, program ID and activation context; no accepted misbinding.

Accept

Change payout, network, kind, program ID and activation context; no accepted misbinding.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, node lane
Design status
NOT RUN
Plan pages
R2-F01
R2-F01-R04A native two-node test must agree on block validity and payouts despite different cache histories.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F01 requires (review R2 finding F01: Proof-verdict cache omits the statement being verified).

Steps

  1. A native two-node test must agree on block validity and payouts despite different cache histories.

Accept

A native two-node test must agree on block validity and payouts despite different cache histories.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, node lane
Design status
NOT RUN
Plan pages
R2-F01
R2-F02-R01Release build cannot activate test bypass.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F02 requires (review R2 finding F02: Proof-rule infrastructure can fail open).

Steps

  1. Release build cannot activate test bypass.

Accept

Release build cannot activate test bypass.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, CI steward
Design status
NOT RUN
Plan pages
R2-F02
R2-F02-R02Missing oracle or pinned keys prevents service readiness after enforcement activation.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F02 requires (review R2 finding F02: Proof-rule infrastructure can fail open).

Steps

  1. Missing oracle or pinned keys prevents service readiness after enforcement activation.

Accept

Missing oracle or pinned keys prevents service readiness after enforcement activation.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, CI steward
Design status
NOT RUN
Plan pages
R2-F02
R2-F02-R03Missing proof bytes retry without incorrectly marking a valid block permanently invalid.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F02 requires (review R2 finding F02: Proof-rule infrastructure can fail open).

Steps

  1. Missing proof bytes retry without incorrectly marking a valid block permanently invalid.

Accept

Missing proof bytes retry without incorrectly marking a valid block permanently invalid.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, CI steward
Design status
NOT RUN
Plan pages
R2-F02
R2-F03-R01Clean build from one manifest, including the pool and workers, with no unpublished vendor tree.Priority P0Profile P00PASSEvidence none yetLast run 8 Oct 2026, 22:11 UK

Setup

The regression R2-F03 requires (review R2 finding F03: The bundle contains a v6 candidate, not a demonstrated integrated v6 release).

Steps

  1. Clean build from one manifest, including the pool and workers, with no unpublished vendor tree.

Accept

Clean build from one manifest, including the pool and workers, with no unpublished vendor tree.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward, hash lane (ProgramClass::V6 on freeze), pool lane
Run
f03-manifest-20261008-01
Design status
NOT RUN
Plan pages
R2-F03
R2-F03-R02Same job context produces identical accepted work in node, CPU reference, CUDA, Metal, OpenCL and pool.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 06:08 UK

Setup

The regression R2-F03 requires (review R2 finding F03: The bundle contains a v6 candidate, not a demonstrated integrated v6 release).

Steps

  1. Same job context produces identical accepted work in node, CPU reference, CUDA, Metal, OpenCL and pool.

Accept

Same job context produces identical accepted work in node, CPU reference, CUDA, Metal, OpenCL and pool.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward, hash lane (ProgramClass::V6 on freeze), pool lane
Run
same-work-20261008-03
Design status
NOT RUN
Plan pages
R2-F03
R2-F03-R03Cross every scheduled transition with old/new client behavior documented and identical rule identities.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 06:08 UK

Setup

The regression R2-F03 requires (review R2 finding F03: The bundle contains a v6 candidate, not a demonstrated integrated v6 release).

Steps

  1. Cross every scheduled transition with old/new client behavior documented and identical rule identities.

Accept

Cross every scheduled transition with old/new client behavior documented and identical rule identities.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward, hash lane (ProgramClass::V6 on freeze), pool lane
Run
same-work-20261008-03
Design status
NOT RUN
Plan pages
R2-F03
R2-F04-R01Native multi-node 40/40/20 partition, equivocation and dust-valid mining on both sides past the window.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F04 requires (review R2 finding F04: Finality v4 recovery deliberately has a weaker safety boundary).

Steps

  1. Native multi-node 40/40/20 partition, equivocation and dust-valid mining on both sides past the window.

Accept

Native multi-node 40/40/20 partition, equivocation and dust-valid mining on both sides past the window.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane, reference apps, site (explorer)
Design status
NOT RUN
Plan pages
R2-F04
R2-F04-R02Proof that the chosen recovery guarantee matches the public finality claim; two valid contradictory certificates are a hard failure for strong finality.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F04 requires (review R2 finding F04: Finality v4 recovery deliberately has a weaker safety boundary).

Steps

  1. Proof that the chosen recovery guarantee matches the public finality claim; two valid contradictory certificates are a hard failure for strong finality.

Accept

Proof that the chosen recovery guarantee matches the public finality claim; two valid contradictory certificates are a hard failure for strong finality.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane, reference apps, site (explorer)
Design status
NOT RUN
Plan pages
R2-F04
R2-F04-R03Pause-only resume with historical backfill, missing historical data and all old keys returning.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F04 requires (review R2 finding F04: Finality v4 recovery deliberately has a weaker safety boundary).

Steps

  1. Pause-only resume with historical backfill, missing historical data and all old keys returning.

Accept

Pause-only resume with historical backfill, missing historical data and all old keys returning.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane, reference apps, site (explorer)
Design status
NOT RUN
Plan pages
R2-F04
R2-F04-R04Wallet, receipt and oracle consumers distinguish any weaker recovery state.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F04 requires (review R2 finding F04: Finality v4 recovery deliberately has a weaker safety boundary).

Steps

  1. Wallet, receipt and oracle consumers distinguish any weaker recovery state.

Accept

Wallet, receipt and oracle consumers distinguish any weaker recovery state.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane, reference apps, site (explorer)
Design status
NOT RUN
Plan pages
R2-F04
R2-F05-R01Native reference-vs-incremental expression equivalence across all source registers and real instruction updates.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F05 requires (review R2 finding F05: reg64 address coupling has an exact incremental alternative).

Steps

  1. Native reference-vs-incremental expression equivalence across all source registers and real instruction updates.

Accept

Native reference-vs-incremental expression equivalence across all source registers and real instruction updates.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, adversary lane, floor lane 3
Design status
NOT RUN
Plan pages
R2-F05
R2-F05-R02Full-kernel output equivalence, registers, spills, wall power and accepted throughput across target GPUs.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F05 requires (review R2 finding F05: reg64 address coupling has an exact incremental alternative).

Steps

  1. Full-kernel output equivalence, registers, spills, wall power and accepted throughput across target GPUs.

Accept

Full-kernel output equivalence, registers, spills, wall power and accepted throughput across target GPUs.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, adversary lane, floor lane 3
Design status
NOT RUN
Plan pages
R2-F05
R2-F05-R03Adversary physical design includes prefix caching/recomputation cost; no assumed full 63-read cost on every load.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F05 requires (review R2 finding F05: reg64 address coupling has an exact incremental alternative).

Steps

  1. Adversary physical design includes prefix caching/recomputation cost; no assumed full 63-read cost on every load.

Accept

Adversary physical design includes prefix caching/recomputation cost; no assumed full 63-read cost on every load.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, adversary lane, floor lane 3
Design status
NOT RUN
Plan pages
R2-F05
R2-F06-R01Acceptance/reference/emitter evaluate the same activated schedule.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F06 requires (review R2 finding F06: The v6 acceptance and census gates are not complete for the final execution).

Steps

  1. Acceptance/reference/emitter evaluate the same activated schedule.

Accept

Acceptance/reference/emitter evaluate the same activated schedule.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, research lane D
Design status
NOT RUN
Plan pages
R2-F06
R2-F06-R02Full live-dataset census on unseen seeds and the complete v6 pack.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F06 requires (review R2 finding F06: The v6 acceptance and census gates are not complete for the final execution).

Steps

  1. Full live-dataset census on unseen seeds and the complete v6 pack.

Accept

Full live-dataset census on unseen seeds and the complete v6 pack.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, research lane D
Design status
NOT RUN
Plan pages
R2-F06
R2-F06-R03A failed experimental rule does not silently exhaust generation or bypass the intended resource requirement.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F06 requires (review R2 finding F06: The v6 acceptance and census gates are not complete for the final execution).

Steps

  1. A failed experimental rule does not silently exhaust generation or bypass the intended resource requirement.

Accept

A failed experimental rule does not silently exhaust generation or bypass the intended resource requirement.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, research lane D
Design status
NOT RUN
Plan pages
R2-F06
R2-F07-R01Same final v6 configuration: mine -> evict -> prove -> aggregate -> submit -> rebuild -> resume; no leaked reservations.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F07 requires (review R2 finding F07: VRAM admission and proving deadlines need one operator-level scheduler).

Steps

  1. Same final v6 configuration: mine -> evict -> prove -> aggregate -> submit -> rebuild -> resume; no leaked reservations.

Accept

Same final v6 configuration: mine -> evict -> prove -> aggregate -> submit -> rebuild -> resume; no leaked reservations.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, fleet lane
Design status
NOT RUN
Plan pages
R2-F07
R2-F07-R02OOM, process crash and stale work recover without losing wallet state or silently consuming power.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F07 requires (review R2 finding F07: VRAM admission and proving deadlines need one operator-level scheduler).

Steps

  1. OOM, process crash and stale work recover without losing wallet state or silently consuming power.

Accept

OOM, process crash and stale work recover without losing wallet state or silently consuming power.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, fleet lane
Design status
NOT RUN
Plan pages
R2-F07
R2-F07-R0316 GB+ simultaneous mode only after measured peak plus next-epoch headroom; smaller-card modes labelled separately.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F07 requires (review R2 finding F07: VRAM admission and proving deadlines need one operator-level scheduler).

Steps

  1. 16 GB+ simultaneous mode only after measured peak plus next-epoch headroom; smaller-card modes labelled separately.

Accept

16 GB+ simultaneous mode only after measured peak plus next-epoch headroom; smaller-card modes labelled separately.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, fleet lane
Design status
NOT RUN
Plan pages
R2-F07
R2-F08-R01Report every eligible job outcome, including expired work; a bounded list cannot hide losses.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F08 requires (review R2 finding F08: The proving pipeline reports waste and deadline censoring, not sustained capacity).

Steps

  1. Report every eligible job outcome, including expired work; a bounded list cannot hide losses.

Accept

Report every eligible job outcome, including expired work; a bounded list cannot hide losses.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, fleet lane, site (ops page)
Design status
NOT RUN
Plan pages
R2-F08
R2-F08-R02Consumer tiers complete and receive payment for declared jobs before claims about income.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F08 requires (review R2 finding F08: The proving pipeline reports waste and deadline censoring, not sustained capacity).

Steps

  1. Consumer tiers complete and receive payment for declared jobs before claims about income.

Accept

Consumer tiers complete and receive payment for declared jobs before claims about income.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, fleet lane, site (ops page)
Design status
NOT RUN
Plan pages
R2-F08
R2-F08-R03Sustained real workload across class transitions, with restart/retry and no publisher intervention.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F08 requires (review R2 finding F08: The proving pipeline reports waste and deadline censoring, not sustained capacity).

Steps

  1. Sustained real workload across class transitions, with restart/retry and no publisher intervention.

Accept

Sustained real workload across class transitions, with restart/retry and no publisher intervention.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, fleet lane, site (ops page)
Design status
NOT RUN
Plan pages
R2-F08
R2-F09-R01Generate all pass/fail cells directly from the declared inequalities and inputs.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F09 requires (review R2 finding F09: The economic model explicitly retains a failed specialist case).

Steps

  1. Generate all pass/fail cells directly from the declared inequalities and inputs.

Accept

Generate all pass/fail cells directly from the declared inequalities and inputs.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
research lane, floor lane 3, coordinator
Design status
NOT RUN
Plan pages
R2-F09
R2-F09-R02Independent feasibility and cost evaluation of the strongest modeled SRAM/hybrid opponent.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F09 requires (review R2 finding F09: The economic model explicitly retains a failed specialist case).

Steps

  1. Independent feasibility and cost evaluation of the strongest modeled SRAM/hybrid opponent.

Accept

Independent feasibility and cost evaluation of the strongest modeled SRAM/hybrid opponent.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
research lane, floor lane 3, coordinator
Design status
NOT RUN
Plan pages
R2-F09
R2-F09-R03GPU owners and entrants remain viable under the approved scenario envelope without assuming chip absence or death.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F09 requires (review R2 finding F09: The economic model explicitly retains a failed specialist case).

Steps

  1. GPU owners and entrants remain viable under the approved scenario envelope without assuming chip absence or death.

Accept

GPU owners and entrants remain viable under the approved scenario envelope without assuming chip absence or death.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
research lane, floor lane 3, coordinator
Design status
NOT RUN
Plan pages
R2-F09
R2-F10-R01Compare exact found nonce/hash sets with full-read mode, including all-hit overflow and zero-hit cases.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F10 requires (review R2 finding F10: CUDA production readback has an existing OpenCL optimization to borrow).

Steps

  1. Compare exact found nonce/hash sets with full-read mode, including all-hit overflow and zero-hit cases.

Accept

Compare exact found nonce/hash sets with full-read mode, including all-hit overflow and zero-hit cases.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
worker lane (new)
Design status
NOT RUN
Plan pages
R2-F10
R2-F10-R02Test stale jobs, high-32 rollover, tail batches and asynchronous buffer reuse.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F10 requires (review R2 finding F10: CUDA production readback has an existing OpenCL optimization to borrow).

Steps

  1. Test stale jobs, high-32 rollover, tail batches and asynchronous buffer reuse.

Accept

Test stale jobs, high-32 rollover, tail batches and asynchronous buffer reuse.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
worker lane (new)
Design status
NOT RUN
Plan pages
R2-F10
R2-F10-R03Compare production throughput and wall energy, not only the isolated kernel timer.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F10 requires (review R2 finding F10: CUDA production readback has an existing OpenCL optimization to borrow).

Steps

  1. Compare production throughput and wall energy, not only the isolated kernel timer.

Accept

Compare production throughput and wall energy, not only the isolated kernel timer.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
worker lane (new)
Design status
NOT RUN
Plan pages
R2-F10
R2-F11-R01Goal switch from an efficiency prior can explore higher core/power when policy allows.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F11 requires (review R2 finding F11: Ember needs workload-aware identity and objective-aware search).

Steps

  1. Goal switch from an efficiency prior can explore higher core/power when policy allows.

Accept

Goal switch from an efficiency prior can explore higher core/power when policy allows.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (new)
Design status
NOT RUN
Plan pages
R2-F11
R2-F11-R02Driver, workload, dataset, compiler and device changes invalidate certification while retaining optional hints.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F11 requires (review R2 finding F11: Ember needs workload-aware identity and objective-aware search).

Steps

  1. Driver, workload, dataset, compiler and device changes invalidate certification while retaining optional hints.

Accept

Driver, workload, dataset, compiler and device changes invalidate certification while retaining optional hints.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (new)
Design status
NOT RUN
Plan pages
R2-F11
R2-F11-R03Thermal/error/late-share events revert safely, including process or machine crash.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F11 requires (review R2 finding F11: Ember needs workload-aware identity and objective-aware search).

Steps

  1. Thermal/error/late-share events revert safely, including process or machine crash.

Accept

Thermal/error/late-share events revert safely, including process or machine crash.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (new)
Design status
NOT RUN
Plan pages
R2-F11
R2-F12-R01Crash before/after broadcast, response timeout, restart before snapshot: no duplicate payment or silent debt loss.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F12 requires (review R2 finding F12: Pool payouts have a broadcast-before-durable-intent window).

Steps

  1. Crash before/after broadcast, response timeout, restart before snapshot: no duplicate payment or silent debt loss.

Accept

Crash before/after broadcast, response timeout, restart before snapshot: no duplicate payment or silent debt loss.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F12
R2-F12-R02Same signed transaction retried, fee replacement reconciled by intent, not a new payment.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F12 requires (review R2 finding F12: Pool payouts have a broadcast-before-durable-intent window).

Steps

  1. Same signed transaction retried, fee replacement reconciled by intent, not a new payment.

Accept

Same signed transaction retried, fee replacement reconciled by intent, not a new payment.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F12
R2-F12-R03Receipt reorg and finality pause leave correct pending obligations.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F12 requires (review R2 finding F12: Pool payouts have a broadcast-before-durable-intent window).

Steps

  1. Receipt reorg and finality pause leave correct pending obligations.

Accept

Receipt reorg and finality pause leave correct pending obligations.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F12
R2-F13-R01Repeated authorization rejected or atomically replaces and cleans prior state.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F13 requires (review R2 finding F13: Pool admission and membership need bounded resources).

Steps

  1. Repeated authorization rejected or atomically replaces and cleans prior state.

Accept

Repeated authorization rejected or atomically replaces and cleans prior state.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F13
R2-F13-R02Oversized unterminated frame rejected within fixed memory/time budget.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F13 requires (review R2 finding F13: Pool admission and membership need bounded resources).

Steps

  1. Oversized unterminated frame rejected within fixed memory/time budget.

Accept

Oversized unterminated frame rejected within fixed memory/time budget.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F13
R2-F13-R03Slow clients and invalid share floods cannot grow unbounded member, nonce or outgoing state.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F13 requires (review R2 finding F13: Pool admission and membership need bounded resources).

Steps

  1. Slow clients and invalid share floods cannot grow unbounded member, nonce or outgoing state.

Accept

Slow clients and invalid share floods cannot grow unbounded member, nonce or outgoing state.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F13
R2-F14-R01Public build has no default arbitrary remote execution and a documented least-privilege boundary.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F14 requires (review R2 finding F14: Developer fleet control must not silently become the public client trust model).

Steps

  1. Public build has no default arbitrary remote execution and a documented least-privilege boundary.

Accept

Public build has no default arbitrary remote execution and a documented least-privilege boundary.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, relay lane
Design status
NOT RUN
Plan pages
R2-F14
R2-F14-R02Automatic updates off remains off for urgent manifests until explicit action.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F14 requires (review R2 finding F14: Developer fleet control must not silently become the public client trust model).

Steps

  1. Automatic updates off remains off for urgent manifests until explicit action.

Accept

Automatic updates off remains off for urgent manifests until explicit action.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, relay lane
Design status
NOT RUN
Plan pages
R2-F14
R2-F14-R03A compromised fleet/update signing key cannot silently acquire wallet access or activate a consensus change.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F14 requires (review R2 finding F14: Developer fleet control must not silently become the public client trust model).

Steps

  1. A compromised fleet/update signing key cannot silently acquire wallet access or activate a consensus change.

Accept

A compromised fleet/update signing key cannot silently acquire wallet access or activate a consensus change.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, relay lane
Design status
NOT RUN
Plan pages
R2-F14
18INT

INT: the master edition's integration gates (R1, the full-system review)

18 integration gates; each reads NOT RUN until its owner lane records a run

FAIL
Owner
the owner lanes per the coordinator's crosswalk
Gate
Integration gates closed
Fixtures
F0,F5
Plan pages
docs/plans/igneum-2.0-master/traceability.json integration_gates
18 cases: 0 passed under the standard, 0 running with team evidence, 1 failed, 17 not run, 0 deferred
INT-01Real proof H cannot authenticate a different statement under a warm cache.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-01 of the master edition (R1 / Additional regression gates).

Steps

  1. Real proof H cannot authenticate a different statement under a warm cache.

Accept

Real proof H cannot authenticate a different statement under a warm cache.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Plan pages
R1
INT-02Warm/cold/relay/restart/concurrent cache order does not change block or payout decisions; negative cache isolated.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-02 of the master edition (R1 / Additional regression gates).

Steps

  1. Warm/cold/relay/restart/concurrent cache order does not change block or payout decisions; negative cache isolated.

Accept

Warm/cold/relay/restart/concurrent cache order does not change block or payout decisions; negative cache isolated.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Plan pages
R1
INT-03Durable payout outbox survives every crash/RPC boundary without duplicate or lost liabilities.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 00:47 UK

Setup

Integration gate INT-03 of the master edition (R1 / Additional regression gates).

Steps

  1. Durable payout outbox survives every crash/RPC boundary without duplicate or lost liabilities.

Accept

Durable payout outbox survives every crash/RPC boundary without duplicate or lost liabilities.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (a1c484c48a62948c2)
Run
pool-int-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-04Corrupt existing pool state, disk-full and reorg cause safe recovery, not silent empty balances.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 00:47 UK

Setup

Integration gate INT-04 of the master edition (R1 / Additional regression gates).

Steps

  1. Corrupt existing pool state, disk-full and reorg cause safe recovery, not silent empty balances.

Accept

Corrupt existing pool state, disk-full and reorg cause safe recovery, not silent empty balances.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (a1c484c48a62948c2)
Run
pool-int-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-05The supplied finality implementation matches the approved anchor rule after >window healing.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-05 of the master edition (R1 / Additional regression gates).

Steps

  1. The supplied finality implementation matches the approved anchor rule after >window healing.

Accept

The supplied finality implementation matches the approved anchor rule after >window healing.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane (a283f5f0d364ceef0)
Design status
NOT RUN
Plan pages
R1
INT-06Recovery tests state and preserve their weaker fault bound; interfaces never label it as a stronger guarantee.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-06 of the master edition (R1 / Additional regression gates).

Steps

  1. Recovery tests state and preserve their weaker fault bound; interfaces never label it as a stronger guarantee.

Accept

Recovery tests state and preserve their weaker fault bound; interfaces never label it as a stronger guarantee.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane (a283f5f0d364ceef0)
Design status
NOT RUN
Plan pages
R1
INT-07One v6 object agrees in node, pool, CPU verifier and each supported GPU host across activation.Priority P0Profile P00FAILEvidence none yetLast run 9 Oct 2026, 08:43 UK

Setup

Integration gate INT-07 of the master edition (R1 / Additional regression gates).

Steps

  1. One v6 object agrees in node, pool, CPU verifier and each supported GPU host across activation.

Accept

One v6 object agrees in node, pool, CPU verifier and each supported GPU host across activation.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward with the hash lane (a690540514aa453d7) and the worker lane (a9e87343f008e0edd)
Run
canary-202-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-08Census, production acceptance, schedule counters and live-dataset tests use the identical frozen contract.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-08 of the master edition (R1 / Additional regression gates).

Steps

  1. Census, production acceptance, schedule counters and live-dataset tests use the identical frozen contract.

Accept

Census, production acceptance, schedule counters and live-dataset tests use the identical frozen contract.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward with the hash lane (a690540514aa453d7) and the worker lane (a9e87343f008e0edd)
Design status
NOT RUN
Plan pages
R1
INT-09Eight- and twelve-GiB epoch transitions recover deliberately without relying on repeated OOM/watchdog cycles.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-09 of the master edition (R1 / Additional regression gates).

Steps

  1. Eight- and twelve-GiB epoch transitions recover deliberately without relying on repeated OOM/watchdog cycles.

Accept

Eight- and twelve-GiB epoch transitions recover deliberately without relying on repeated OOM/watchdog cycles.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane
Design status
NOT RUN
Plan pages
R1
INT-10Metal/CUDA/OpenCL exact dataset geometry agrees; unsupported packs reject before launch.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-10 of the master edition (R1 / Additional regression gates).

Steps

  1. Metal/CUDA/OpenCL exact dataset geometry agrees; unsupported packs reject before launch.

Accept

Metal/CUDA/OpenCL exact dataset geometry agrees; unsupported packs reject before launch.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward with the hash lane (a690540514aa453d7) and the worker lane (a9e87343f008e0edd)
Design status
NOT RUN
Plan pages
R1
INT-11Only a memory-reserved proving job launches; mining buffers really release when required.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-11 of the master edition (R1 / Additional regression gates).

Steps

  1. Only a memory-reserved proving job launches; mining buffers really release when required.

Accept

Only a memory-reserved proving job launches; mining buffers really release when required.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane
Design status
NOT RUN
Plan pages
R1
INT-12Transient shard errors can retry safely; expiration, loss and paid work remain distinct durable outcomes.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-12 of the master edition (R1 / Additional regression gates).

Steps

  1. Transient shard errors can retry safely; expiration, loss and paid work remain distinct durable outcomes.

Accept

Transient shard errors can retry safely; expiration, loss and paid work remain distinct durable outcomes.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane (a6e8f84588b809d62) and fleet lane (ac055d60427caab99)
Design status
NOT RUN
Plan pages
R1
INT-13Ember cannot retain a rate-ineligible prior; material workload changes invalidate incompatible profiles.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-13 of the master edition (R1 / Additional regression gates).

Steps

  1. Ember cannot retain a rate-ineligible prior; material workload changes invalidate incompatible profiles.

Accept

Ember cannot retain a rate-ineligible prior; material workload changes invalidate incompatible profiles.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (a04fe3451877e2ff0) with the app lane
Design status
NOT RUN
Plan pages
R1
INT-14Protected helper and per-device leases restore owned settings on normal/abnormal exit; real ACL/security tests.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-14 of the master edition (R1 / Additional regression gates).

Steps

  1. Protected helper and per-device leases restore owned settings on normal/abnormal exit; real ACL/security tests.

Accept

Protected helper and per-device leases restore owned settings on normal/abnormal exit; real ACL/security tests.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (a04fe3451877e2ff0) with the app lane
Design status
NOT RUN
Plan pages
R1
INT-15Public PoP replay is not session authorization; payout/server/network binding enforced.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 00:47 UK

Setup

Integration gate INT-15 of the master edition (R1 / Additional regression gates).

Steps

  1. Public PoP replay is not session authorization; payout/server/network binding enforced.

Accept

Public PoP replay is not session authorization; payout/server/network binding enforced.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (a1c484c48a62948c2)
Run
pool-int-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-16Pool parsing/queues/connection and crypto budgets remain bounded under controlled adversarial traffic.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 00:47 UK

Setup

Integration gate INT-16 of the master edition (R1 / Additional regression gates).

Steps

  1. Pool parsing/queues/connection and crypto budgets remain bounded under controlled adversarial traffic.

Accept

Pool parsing/queues/connection and crypto budgets remain bounded under controlled adversarial traffic.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (a1c484c48a62948c2)
Run
pool-int-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-17Missing oracle/keys/mandatory real-proof fixture blocks the applicable production acceptance gate.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-17 of the master edition (R1 / Additional regression gates).

Steps

  1. Missing oracle/keys/mandatory real-proof fixture blocks the applicable production acceptance gate.

Accept

Missing oracle/keys/mandatory real-proof fixture blocks the applicable production acceptance gate.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Plan pages
R1
INT-18Whole-system economics pass the strongest feasible adversary, including sunk development and multi-epoch survival.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-18 of the master edition (R1 / Additional regression gates).

Steps

  1. Whole-system economics pass the strongest feasible adversary, including sunk development and multi-epoch survival.

Accept

Whole-system economics pass the strongest feasible adversary, including sunk development and multi-epoch survival.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
research lane (ad6a2bd47d4a46105)
Design status
NOT RUN
Plan pages
R1
19VR

VR: the token value and network leadership rules (normative, proposed, requiring ratification)

40 normative rules from Igneum 2.0, Token Value & Network Leadership 1.0-proposed (snapshot 2026-10-08); Supplement to original master and 128-case test standard; not a price/rank guarantee

NOT RUN
Owner
founder (ratification); the owner role per rule
Gate
Ratification by the founder and each rule's owner role
Fixtures
F0
Plan pages
docs/plans/igneum-2.0-master/token-value/rules-and-gates.json rules
40 cases: 0 passed under the standard, 0 running with team evidence, 40 not run, 0 deferred
VR-01One monetary contractPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Ratify one maximum-supply, subsidy and change-policy contract. No unexplained tail escape, automatic emergency mint or price-triggered issuance.

Accept

Ratify one maximum-supply, subsidy and change-policy contract. No unexplained tail escape, automatic emergency mint or price-triggered issuance.

Evidence the case requires

D01 decision, normative spec, executable supply tests and consistent public text.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + governance
Plan pages
TV
VR-02Independent supply accountingPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Make circulating, issued, burned, locked and maximum supply independently reproducible. Count bridges and wrappers without creating fictitious native supply.

Accept

Make circulating, issued, burned, locked and maximum supply independently reproducible. Count bridges and wrappers without creating fictitious native supply.

Evidence the case requires

Two independent supply calculations with exact integer reconciliation.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + measurement
Plan pages
TV
VR-03Equal opportunity at launchPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. No premine or privileged devnet conversion under the stated fair-launch policy. Publish efficient software and launch conditions before activation.

Accept

No premine or privileged devnet conversion under the stated fair-launch policy. Publish efficient software and launch conditions before activation.

Evidence the case requires

Genesis audit, launch rehearsal, insider disclosures and public release history.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Release + ecosystem
Plan pages
TV
VR-04No artificial return promisePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Do not advertise guaranteed appreciation, passive returns without necessary work, a redemption floor or electricity-backed value.

Accept

Do not advertise guaranteed appreciation, passive returns without necessary work, a redemption floor or electricity-backed value.

Evidence the case requires

Product terms, source of rewards and public-claim review.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Governance + counsel
Plan pages
TV
VR-05Fund necessary securityPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Model miners, internal provers, minimum validators and maintenance separately through declining issuance. No assumption that an external sale automatically funds all roles.

Accept

Model miners, internal provers, minimum validators and maintenance separately through declining issuance. No assumption that an external sale automatically funds all roles.

Evidence the case requires

Role-by-role cash flow, adverse scenarios and committed initial resources.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Economics + protocol
Plan pages
TV
VR-06Honest rule changePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Publish rationale, impact, adoption path and compatibility limits before a material monetary change. Do not pretend software can prevent all future voluntary forks.

Accept

Publish rationale, impact, adoption path and compatibility limits before a material monetary change. Do not pretend software can prevent all future voluntary forks.

Evidence the case requires

Versioned proposals, reviewer comments, adoption and dissent documentation.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + governance
Plan pages
TV
VR-07Transparent fee routingPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Every fee, burn, operator payment and optional Labs charge has an explicit source and recipient. No new team tax hidden in a commercial label.

Accept

Every fee, burn, operator payment and optional Labs charge has an explicit source and recipient. No new team tax hidden in a commercial label.

Evidence the case requires

Executable fee tests and reconciliation to invoices/receipts.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Economics + protocol
Plan pages
TV
VR-08Separate value and money flowsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Distinguish job turnover, fees, operator income, Labs income, token holdings and market value. Do not count the same payment or saving twice.

Accept

Distinguish job turnover, fees, operator income, Labs income, token holdings and market value. Do not count the same payment or saving twice.

Evidence the case requires

Reconciled flow diagram and reproducible metric definitions.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Economics + measurement
Plan pages
TV
VR-09Accessible hardware economicsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Fix the reference cohort and scenarios in advance. Allow the strongest feasible programmable multi-epoch specialist, including sunk development and alternative memory.

Accept

Fix the reference cohort and scenarios in advance. Allow the strongest feasible programmable multi-epoch specialist, including sunk development and alternative memory.

Evidence the case requires

Approved original GPU/ADV/ROT/ECO profiles and independent review.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
GPU + hardware reviewer
Plan pages
TV
VR-10Mandatory correct proofsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. All activated proof decisions must bind their actual statement, kind and verifier independent of cache history. Missing trusted infrastructure must not disable enforcement.

Accept

All activated proof decisions must bind their actual statement, kind and verifier independent of cache history. Missing trusted infrastructure must not disable enforcement.

Evidence the case requires

Native warm/cold/order/restart tests and positive/negative proof fixtures.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + proving
Plan pages
TV
VR-11Literal finalityPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Define fault assumptions, authority continuity and recovery. Never present a weaker recovery certificate as the stronger irreversible guarantee.

Accept

Define fault assumptions, authority continuity and recovery. Never present a weaker recovery certificate as the stronger irreversible guarantee.

Evidence the case requires

Native multi-node boundary tests and consumer label checks.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Consensus + security
Plan pages
TV
VR-12Retained operator authorityPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Pooling variance or buying a service does not silently transfer keys, transaction selection or finality/governance control.

Accept

Pooling variance or buying a service does not silently transfer keys, transaction selection or finality/governance control.

Evidence the case requires

Key/template substitution tests and explicit delegation contracts.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + pool
Plan pages
TV
VR-13Safe custody and consentPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Private keys, spending limits, signing displays and recovery choices remain under explicit user authority. Defaults must not conceal broad powers.

Accept

Private keys, spending limits, signing displays and recovery choices remain under explicit user authority. Defaults must not conceal broad powers.

Evidence the case requires

Wallet security review and independent user/recovery exercises.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Wallet + security
Plan pages
TV
VR-14Portable verificationPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Balances and receipts authenticate their roots, successful outcome and trust anchors. Necessary reconstruction data has a documented availability path.

Accept

Balances and receipts authenticate their roots, successful outcome and trust anchors. Necessary reconstruction data has a documented availability path.

Evidence the case requires

Independent receipt/client verification with hostile inputs.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Wallet + protocol
Plan pages
TV
VR-15Price real resourcesPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Bound execution, verification and storage costs. Sponsored transactions have limits. No deliberate congestion solely to increase a token metric.

Accept

Bound execution, verification and storage costs. Sponsored transactions have limits. No deliberate congestion solely to increase a token metric.

Evidence the case requires

Minimum-node tests and fee/sponsor-abuse scenarios.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + economics
Plan pages
TV
VR-16No fragile stable-value promisePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Any stable-value product has explicit issuer, reserve/redemption rights, permissions and risks. No native-backed peg used merely to manufacture demand.

Accept

Any stable-value product has explicit issuer, reserve/redemption rights, permissions and risks. No native-backed peg used merely to manufacture demand.

Evidence the case requires

Independent diligence, risk limits and legal assessment before release.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Application + counsel
Plan pages
TV
VR-17Optional bounded bridgesPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Bridge exposure is separate from core security. No bridge is mandatory for genesis or allowed to redefine base-chain finality after a loss.

Accept

Bridge exposure is separate from core security. No bridge is mandatory for genesis or allowed to redefine base-chain finality after a loss.

Evidence the case requires

External security review, loss limits and failure/isolation tests.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Application + security
Plan pages
TV
VR-18Open work settlementPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Jobs bind program, inputs, result, verifier, deadline and payment. Gateways are replaceable and Labs approval is not required for ordinary work.

Accept

Jobs bind program, inputs, result, verifier, deadline and payment. Gateways are replaceable and Labs approval is not required for ordinary work.

Evidence the case requires

Independent request-to-paid-result test and state reconciliation.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + ecosystem
Plan pages
TV
VR-19Obligation-based service bondsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Deposits secure a specific obligation, not consensus influence. Size and failure conditions must preserve small-operator paths and handle collateral decline.

Accept

Deposits secure a specific obligation, not consensus influence. Size and failure conditions must preserve small-operator paths and handle collateral decline.

Evidence the case requires

Economic and adversarial reservation/default tests.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Economics + application
Plan pages
TV
VR-20Independent developer accessPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Publish complete standards, fixtures and tooling. Grants reward useful maintained deliverables rather than deployments or price effects.

Accept

Publish complete standards, fixtures and tooling. Grants reward useful maintained deliverables rather than deployments or price effects.

Evidence the case requires

Unaffiliated integration and maintenance evidence.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Ecosystem
Plan pages
TV
VR-21Committed maintenancePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Essential maintenance and audits need a funded runway with stress accounting, distinct from hoped-for appreciation or fundraising.

Accept

Essential maintenance and audits need a funded runway with stress accounting, distinct from hoped-for appreciation or fundraising.

Evidence the case requires

At least approved P13 runway, commitments and role costs.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Maintainers + finance
Plan pages
TV
VR-22Founder independencePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Routine block, job, payment and recovery paths must not require a founder credential or undocumented manual action.

Accept

Routine block, job, payment and recovery paths must not require a founder credential or undocumented manual action.

Evidence the case requires

Real founder-absence exercises and intervention ledger.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Operations + independent reviewer
Plan pages
TV
VR-23Measure effective controlPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Report operator, pool, hosting, service and client dependencies with attribution limits. Keys and addresses are not people.

Accept

Report operator, pool, hosting, service and client dependencies with attribution limits. Keys and addresses are not people.

Evidence the case requires

Dependency/control map with uncertainty and removal experiments.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Measurement + operations
Plan pages
TV
VR-24Reproducible secure releasePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Pin source, binaries, rules, guests/keys and activation. Provenance is necessary but not sufficient for correctness.

Accept

Pin source, binaries, rules, guests/keys and activation. Provenance is necessary but not sufficient for correctness.

Evidence the case requires

Independent builds, artifact verification and scoped review.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Release + security
Plan pages
TV
VR-25Consent-preserving incident responsePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Separate public/developer authority. Urgency must not silently override installation or grant arbitrary execution. Disclose material incidents and retest.

Accept

Separate public/developer authority. Urgency must not silently override installation or grant arbitrary execution. Disclose material incidents and retest.

Evidence the case requires

Compromised-key, unsafe-update and recovery drills.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Release + operations
Plan pages
TV
VR-26Honest access and liquidityPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Use functional deposits/withdrawals and executable depth, not ticker count or fabricated volume. Never restrict exit to simulate value.

Accept

Use functional deposits/withdrawals and executable depth, not ticker count or fabricated volume. Never restrict exit to simulate value.

Evidence the case requires

Independent access-route and two-sided liquidity observations.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Ecosystem + measurement
Plan pages
TV
VR-27Transparent treasury relationshipsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Disclose material grants, insider holdings, inventory and market-making mandates. No wash trades or hidden price-support promises.

Accept

Disclose material grants, insider holdings, inventory and market-making mandates. No wash trades or hidden price-support promises.

Evidence the case requires

Mandate register, reconciled accounts and conflict policy.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Treasury + counsel
Plan pages
TV
VR-28Auditable metricsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Publish definitions, raw/adjusted views, sampling, attribution uncertainty and missing data. No subsidy-hidden demand or censored failed jobs.

Accept

Publish definitions, raw/adjusted views, sampling, attribution uncertainty and missing data. No subsidy-hidden demand or censored failed jobs.

Evidence the case requires

Data lineage, conservation checks and independent replay.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Measurement
Plan pages
TV
VR-29Fair comparison universePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Define eligible peers and exclusions before observing rankings. Include qualifying new entrants and preserve unknown values.

Accept

Define eligible peers and exclusions before observing rankings. Include qualifying new entrants and preserve unknown values.

Evidence the case requires

Independent peer census and versioned comparison protocol.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Measurement + external panel
Plan pages
TV
VR-30Scoped claims onlyPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Every leadership claim names its metric, universe, period and limits. A measured price rank does not certify overall safety or future leadership.

Accept

Every leadership claim names its metric, universe, period and limits. A measured price rank does not certify overall safety or future leadership.

Evidence the case requires

Claim register with evidence, expiry and legal signoff.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Governance + counsel
Plan pages
TV
VR-31Evidence before passPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Pre-register thresholds; missing inputs block gates; corrections preserve failed results. No aggregate score can waive core safety or economic failure.

Accept

Pre-register thresholds; missing inputs block gates; corrections preserve failed results. No aggregate score can waive core safety or economic failure.

Evidence the case requires

Frozen test charter and versioned evidence packets.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Independent acceptance panel
Plan pages
TV
VR-32Real adoptionPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Measure unaffiliated retained users and useful repeat activity with incentives identified. Do not require buying IGN to participate in a study.

Accept

Measure unaffiliated retained users and useful repeat activity with incentives identified. Do not require buying IGN to participate in a study.

Evidence the case requires

Cohort definitions, attrition, usage and subsidy audit.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Product + ecosystem
Plan pages
TV
VR-33AI earns admissionPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. AI is an optional workload category, not a guaranteed-margin network identity. Price full costs and adverse demand before expansion.

Accept

AI is an optional workload category, not a guaranteed-margin network identity. Price full costs and adverse demand before expansion.

Evidence the case requires

Workload-specific benchmark, repeat demand and verification policy.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Compute + economics
Plan pages
TV
VR-34Bound agent spendingPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Automated buyers have scoped budgets, permissions, expiry, revocation and logs. Untrusted prompts never alter base permissions.

Accept

Automated buyers have scoped budgets, permissions, expiry, revocation and logs. Untrusted prompts never alter base permissions.

Evidence the case requires

Prompt/input adversarial tests and payment-loss caps.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Application + security
Plan pages
TV
VR-35Cryptographic migration readinessPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Maintain a full algorithm inventory and reviewed transition plan. No quantum-proof claim from one component or speculative attack date.

Accept

Maintain a full algorithm inventory and reviewed transition plan. No quantum-proof claim from one component or speculative attack date.

Evidence the case requires

Expert review, downgrade/migration tests and annual refresh.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Cryptography + protocol
Plan pages
TV
VR-36Separate proof, truth and privacyPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Execution validity does not establish real-world input truth, AI answer quality or confidentiality. State trust and data exposure for each service.

Accept

Execution validity does not establish real-world input truth, AI answer quality or confidentiality. State trust and data exposure for each service.

Evidence the case requires

Threat model and user-facing guarantee audit.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Security + product
Plan pages
TV
VR-37Scale within verification budgetsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Throughput, data and state growth must preserve the declared minimum-node and reconstruction capabilities. Reprice security after fee compression.

Accept

Throughput, data and state growth must preserve the declared minimum-node and reconstruction capabilities. Reprice security after fee compression.

Evidence the case requires

Cold-path capacity, bootstrap, pruning and provider-removal tests.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + operations
Plan pages
TV
VR-38Honest energy accountingPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Report complete-system energy and role allocation. Avoid double-counting joint work or making unsupported carbon/marginal-transaction claims.

Accept

Report complete-system energy and role allocation. Avoid double-counting joint work or making unsupported carbon/marginal-transaction claims.

Evidence the case requires

Calibrated wall tests and documented environmental methodology.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
GPU + measurement
Plan pages
TV
VR-39Activity-specific legal approvalPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Obtain counsel review for actual audiences and activities. No-presale, fair-launch or decentralised labels are not blanket legal exemptions.

Accept

Obtain counsel review for actual audiences and activities. No-presale, fair-launch or decentralised labels are not blanket legal exemptions.

Evidence the case requires

Jurisdiction/activity matrix and approved external communications.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Counsel
Plan pages
TV
VR-40No indispensable administratorPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. A useful company, token holder, pool, AI agent or funding body receives no hidden power over balances, issuance or canonical history.

Accept

A useful company, token holder, pool, AI agent or funding body receives no hidden power over balances, issuance or canonical history.

Evidence the case requires

Authority inventory, isolation tests and independent operation.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + governance
Plan pages
TV
20TV

TV: the token value and network leadership gates (proposed; no gate executed)

32 gates from Igneum 2.0, Token Value & Network Leadership 1.0-proposed (snapshot 2026-10-08); scope CORE, CAPABILITY IF ENABLED or LEADERSHIP CLAIM as the file gives it; Supplement to original master and 128-case test standard; not a price/rank guarantee

NOT RUN
Owner
the owner role per gate
Gate
Token value gates closed
Fixtures
F0
Plan pages
docs/plans/igneum-2.0-master/token-value/rules-and-gates.json gates
32 cases: 0 passed under the standard, 0 running with team evidence, 32 not run, 0 deferred
TV-01Resolve and freeze the monetary contractPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Supply, tail, fee and recovery documents plus exact proposed release.

Steps

  1. Reconcile D01-D06 with protocol/economic/counsel review. Freeze thresholds and all interfaces before confirmatory tests.

Accept

No conflicting normative policy; every material choice has a signed rationale, version, adoption path and tests. Unresolved core choice is BLOCKED.

Evidence the case requires

Decision log, signed specification, release manifest, test charter.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + independent panel
Plan pages
TV
TV-02Reproduce complete supply accountingPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Two independent implementations; genesis and representative boundary/reorg fixtures.

Steps

  1. Recompute issued, paid, burned, locked and outstanding amounts through subsidy transitions, rollback/replay and duplicate records.

Accept

Exact integer agreement; no unaccounted creation, duplicate supply or cap breach under the ratified policy. Restricted wrappers are not extra native supply.

Evidence the case requires

Machine-readable ledgers, vectors, independent signoff.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + measurement
Plan pages
TV
TV-03Fair launch and early distributionPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Public binaries, source, mining modes, launch notice and insider inventory.

Steps

  1. Rehearse from clean outsider machines; audit genesis allocations and devnet balances; simulate arrival times under alternative emission schedules.

Accept

Zero undisclosed allocation or privileged conversion; approved notice/support window and cohort pass; distribution analysis includes delayed entrants without guaranteeing equal ownership.

Evidence the case requires

Genesis report, dated releases, disclosure register, simulation inputs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Release + ecosystem
Plan pages
TV
TV-04Security budget without price rescuePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Ratified reward/fee rules; role costs; horizons 1, 5, 10 and 20 years.

Steps

  1. Model falling issuance, fee volatility and .25x/1x/4x/10x revenue, zero external jobs and -90% price. Separate role receipts and funding.

Accept

Approved viable scenarios fund minimum required roles without hidden issuance or assumed appreciation; failure regions stated. Collapse scenarios need safe behaviour, not universal profit.

Evidence the case requires

Reproducible cash-flow model, assumptions, independent review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Economics + protocol
Plan pages
TV
TV-05Strongest surviving specialistPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Pinned candidate/cohort; cheapest supported physical designs including SRAM/hybrid.

Steps

  1. Apply original ADV/GPU/ECO profiles with multi-epoch survival and development sunk. Reprice alternative state and memory implementations.

Accept

All approved core energy and total-cost bounds pass with uncertainty; no unresolved feasible dominating design. Unknown feasibility blocks the broad claim.

Evidence the case requires

Design files, wall results, sensitivity model, two independent hardware opinions.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Hardware reviewer + economics
Plan pages
TV
TV-06Every fee and payment reconcilesPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Native rules, payer contract and optional Labs/service invoices.

Steps

  1. Execute gas, proof, developer, pool, burn, sponsor and refund paths, including rounding, abort, retry and zero-demand cases.

Accept

No unexplained recipient or double count; statements/invoices match exact contract outcomes. Network turnover never labelled Labs revenue or permanent holding demand.

Evidence the case requires

Flow ledger, fixtures, invoice examples, reviewed public fee table.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Economics + application
Plan pages
TV
TV-07Ownership-critical engineering closurePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Original master findings mapped to current release with genuine proof fixtures.

Steps

  1. Run native cache-order, fail-closed activation, payout crash and finality tests; reproduce fixed cases in independent environments.

Accept

No unresolved critical/high finding or counterexample within the approved guarantee; all applicable original safety gates pass. Reproducing a defect is not closure.

Evidence the case requires

Native outputs, manifests, scoped audit, issue-by-issue closure.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + independent security
Plan pages
TV
TV-08Custody and recovery usabilityPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Declared wallet/hardware combinations; 30 new participants, at least 15 non-miners.

Steps

  1. Perform receive, preview/sign, limit, recovery and revocation tasks with valueless funds; inject wrong network/address and malicious prompts.

Accept

Zero unauthorised transfer or secret disclosure; at least 90% complete the approved safe task without private help. Report confidence limitations and all failures.

Evidence the case requires

Task protocol, anonymised results, security review, recovery vectors.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Wallet + independent users
Plan pages
TV
TV-09Independently verifiable settlementPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Proof/receipt client without Labs RPC; normal and recovery certificates.

Steps

  1. Verify successful/failed transfers, wrong asset/amount, stale roots, fake voter lists, invalid proofs and withheld data.

Accept

All invalid claims refused; valid ordinary transfers verify within approved resource limits; weaker recovery and unavailable data never shown as stronger finality.

Evidence the case requires

Offline fixtures, consumer traces and independent implementation.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Wallet + consensus
Plan pages
TV
TV-10Minimum-node and sponsored-use limitsPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Approved minimum validator and sponsor budgets under final workload.

Steps

  1. Run cold proof verification, expensive invalid inputs, state growth, paymaster drain attempts and overloaded bursts.

Accept

Original capacity/security profiles pass; budgets remain bounded; no proof skipped to catch up and no sponsor can spend outside authorised scope.

Evidence the case requires

Cold-path profiles, stress traces, sponsor negative tests.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + application
Plan pages
TV
TV-11Pooled payments without authority lossPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Independent pool/member clients and durable payment state.

Steps

  1. Inject key/template substitution, reauthorisation, crash/RPC ambiguity, receipt reorg and hostile bounded inputs.

Accept

No duplicate/lost liability or unauthorised authority change; member can verify delegated powers and change pools. Session resource limits hold.

Evidence the case requires

Ledger replay, signed work fixtures and pool removal test.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Pool + independent operators
Plan pages
TV
TV-12Reproducible and consented softwarePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Release manifest, build dependencies, update keys and public installer.

Steps

  1. Two independent parties build/verify; simulate compromised key, stale package, rollback, urgency and missing fixtures.

Accept

No hidden consensus variation or arbitrary default remote control; update-off remains respected; mandatory unavailable fixtures block acceptance.

Evidence the case requires

Attestations, independent hashes, key drill, installer/ACL review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Release + independent security
Plan pages
TV
TV-13Committed maintenance coveragePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Costed roles, commitments and monthly cash dates.

Steps

  1. Audit at least 12 months of approved maintenance coverage; stress IGN-denominated resources and provider withdrawal.

Accept

Original P13 satisfied without counting future appreciation or unsigned pledges; essential functions have funded substitutes and explicit shortfall response.

Evidence the case requires

Contracts/grants or funding proof, stress cash flow, responsibility register.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Maintainers + independent finance
Plan pages
TV
TV-14Founder-absent operating exercisePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Independent builds/operators; founder services, keys and manual help removed.

Steps

  1. Run 30 real days, then satisfy the original 90-day observation programme; cross boundaries, remove major providers and record all interventions.

Accept

Approved original independence/reliability gates pass; no unpublished founder action or privileged override. Simulated long partitions are labelled separately.

Evidence the case requires

Dependency map, availability logs, intervention and payer ledger.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Independent operations panel
Plan pages
TV
TV-15Governance and authority boundariesPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Every control/activation threshold, treasury power and application admin interface.

Steps

  1. Exercise hostile coalitions, absent voters, old clients and compromised non-consensus keys; test refusal and recovery.

Accept

No actor gains undeclared issuance/balance/history authority. Every activation follows the ratified safe procedure; ambiguous threshold or recovery remains BLOCKED.

Evidence the case requires

Authority model, scenarios, native outcomes and independent review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + governance
Plan pages
TV
TV-16Two functional independent access routesPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

At least two unaffiliated custody/exchange/payment routes with disclosed shared infrastructure.

Steps

  1. Complete small controlled deposits, withdrawals, outage and reconciliation tests; identify actual custody and settlement dependencies.

Accept

Both settle correctly; neither is merely a front end to the same indispensable provider. Gaps and jurisdiction limits visible; no listing assumed from a logo.

Evidence the case requires

Settlement records, dependency map and third-party confirmation.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ecosystem + independent reviewer
Plan pages
TV
TV-17Supply-price-liquidity measurementPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Frozen sources, price filters, circulating/free-float definitions and order-size bands.

Steps

  1. Collect 90 real days; independently replay supply and prices; measure both buy/sell execution costs and withdrawal availability.

Accept

At least 95% daily coverage; exact supply reconciliation; no fabricated missing data. Sparse liquidity invalidates broad liquidity claims, not automatically the arithmetic cap.

Evidence the case requires

Raw snapshots, methodology/code, gap ledger, audit.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Measurement steward
Plan pages
TV
TV-18Real versus incentivised demandPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Customer/job/transaction definitions with privacy-respecting attribution and subsidy data.

Steps

  1. Reconcile raw/adjusted activity, self-dealing controls and incentives; test whether circular activity earns more than its irrecoverable cost.

Accept

All subsidies and known related activity separated; useful demand not inferred from gross volume alone; abusive incentive loop closed before scaling rewards.

Evidence the case requires

Accounting model, filter logic, sensitivity and independent replay.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Economics + measurement
Plan pages
TV
TV-19Independent developer adoptionPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Public kit and at least five unaffiliated developers with declared tasks.

Steps

  1. Build useful integrations without private dependencies; have two independent maintainers update the kit; record obstacles and adoption reason.

Accept

All declared core integration paths work; at least five usable integrations and two maintainer reproductions. Empty subsidised deployments do not qualify.

Evidence the case requires

Repos, task traces, user evidence and maintenance records.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ecosystem + external developers
Plan pages
TV
TV-20Programmable payment acceptancePriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Versioned library, independent application, user/sponsor limits and receipt path.

Steps

  1. Execute simple/conditional/recurring payments, revocations, expiry, failed outcome and duplicate invoice cases.

Accept

No unauthorised spend or double settlement; successful transfer independently evidenced; subjective conditions disclose adjudicator/trust.

Evidence the case requires

Contracts, negative vectors, user task record, security review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Application + wallet
Plan pages
TV
TV-21Useful paid proof demandPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Exact workload and final hardware path; three unrelated buyers and approved COM profile.

Steps

  1. Observe repeat purchases under original P14/P16 conditions, full job outcomes and operator/service costs.

Accept

All applicable COM targets met without hidden reimbursement. Queue expiry not counted as success. A monetary-only scope cannot claim this gate passed by exclusion.

Evidence the case requires

Buyer evidence, cost ledger, all-job traces and independent review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Proving + independent customers
Plan pages
TV
TV-22Replaceable work-market gatewayPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Two independent gateway implementations and job/settlement specification.

Steps

  1. Create jobs, switch providers/gateways, fail one service and deliver the same objective result using public inputs.

Accept

Correct payment/result without Labs approval; no concealed central dispatcher or irreversible dependency. External-chain receipts labelled separately.

Evidence the case requires

Gateway traces, escrow reconciliation, dependency-removal run.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Application + independent operators
Plan pages
TV
TV-23Obligation-based depositsPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Proposed bond/default contract and volatile-collateral scenarios.

Steps

  1. Test reservation abandonment, invalid inputs, network pause, -90% collateral value and malicious claims.

Accept

No consensus influence bought; default reason objective; compensation limits explicit; viable small-operator participation and approved risk bounds.

Evidence the case requires

Adversarial model, state tests, risk/legal review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Economics + security
Plan pages
TV
TV-24AI earns a separate commercial casePriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

One bounded model/job, provider hardware, verification tier and licences.

Steps

  1. Benchmark full delivery vs actual alternatives; test 90% lower unit prices, demand collapse, private-data exposure and substituted models.

Accept

Approved service economics and buyer gates pass; correctness/truth/privacy distinguished. No native price or perpetual yield assumption.

Evidence the case requires

End-to-end costs, repeat demand, licence/threat review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Compute + independent reviewer
Plan pages
TV
TV-25Bounded machine purchasingPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Approved account/paymaster permissions and chosen x402/agent interfaces.

Steps

  1. Inject hostile outputs/prompts, replayed requests, recursive spending, revoked permissions and gateway failure.

Accept

Spend never exceeds authorised destination/time/amount scope; no instruction changes authority. Draft standard support is described accurately.

Evidence the case requires

Property tests, loss-cap proof, revocation/audit logs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Application + security
Plan pages
TV
TV-26Cryptographic migration readinessPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Complete key/proof/transport/update inventory and external cryptographic review.

Steps

  1. Rehearse versioned signature/proof migration, downgrade/replay, mixed clients, inactive owners and minimum-node overhead.

Accept

No unreviewed assumption or automatic confiscation; migration can be explained and tested. No absolute quantum-proof claim or attack date inferred.

Evidence the case requires

Inventory, expert report, migration vectors, annual schedule.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Cryptography + protocol
Plan pages
TV
TV-27Private data and oracle assurancePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Per-product claims, input trust sources, data-retention and execution model.

Steps

  1. Use forged data, hostile providers, telemetry leakage, unsupported attestation and false-but-correctly-executed AI outputs.

Accept

No claim exceeds tested guarantee; secrets/data protected to stated model; unauthenticated inputs not represented as objective truth.

Evidence the case requires

Threat model, exposure tests, labelled user flows.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Security + product
Plan pages
TV
TV-28Stable assets and bridge isolationPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Only if enabled: issuer/bridge design, redemption rights, trust anchors and approved value caps.

Steps

  1. Test reserve/redemption failure, stale oracle, invalid/recovery certificates, contract compromise and emergency shutdown.

Accept

No hidden base-chain guarantee or forced reversal of final history; independent audit, conservative exposure and counsel approval.

Evidence the case requires

Risk dossier, scenarios, disclosure, independent tests.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Application + security + counsel
Plan pages
TV
TV-29Growth without inaccessible verificationPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Declared minimum node, projected data growth and alternative scaling design.

Steps

  1. Run cold/worst-case validation, state/pruning/bootstrap, censorship and aggregation withdrawal; model 10x/100x growth and fee compression.

Accept

Original minimum-node/security bounds hold; required data remains obtainable; security funding restated for changed fee routes.

Evidence the case requires

Capacity/availability results and revised economics.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + operations
Plan pages
TV
TV-30Energy and claims disciplinePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Calibrated whole-system metering and workload allocation protocol.

Steps

  1. Measure mining, proving, mixed/time-shared operation, setup/recovery and unsuccessful work; review environmental text.

Accept

No double-counted savings; original meter tolerances satisfied; no marginal-energy/carbon claim beyond method.

Evidence the case requires

Raw meter traces, job ledger, method and external review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
GPU + measurement
Plan pages
TV
TV-31Public-claim and activity reviewPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Actual jurisdiction, audience, service, token-distribution and promotion plans.

Steps

  1. Counsel assesses applicable routes and reviews each value/rank/return/security assertion against evidence.

Accept

Written activity-specific clearance and approved wording; no future-value assertion in a covered MiCA white paper; no blanket exemption inferred from mining.

Evidence the case requires

Legal decision matrix, claim register, review dates.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Qualified counsel
Plan pages
TV
TV-32Observed leadership, not a roadmap certificatePriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:39 UK

Setup

Approved peer universe; all applicable mandatory gates; stable release and 90-day observation.

Steps

  1. Run original P15/P16 comparisons and independently replay scoped rank data. Test changing peer/exclusion assumptions and missing data.

Accept

Contender requires original criteria; market-cap first requires highest 90-day median, 95% coverage; sustained daily-first convention also needs 80% of covered days. Never certify overall best from price alone.

Evidence the case requires

Independent panel report, full methods/data, scope and expiry of claim.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Independent acceptance panel
Plan pages
TV
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 148 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.

Rules in force

  • P03: a candidate change pays at most 5 percent of joules per accepted work and loses at most 2 percent of accepted throughput against the paired tuned baseline (replaces the 10 percent budget from 18:2x UK)
  • P04: R_E at most 1.5 for every competitive-core cell at the same node and one node ahead against the lowest credible complete-system specialist; today's placed bracket (1.5x to 2.1x same-node) is a FAIL to work against and is served as such
  • P12: the matched-tariff median at most 1.5, p90 at most 1.75, no core cell above 2.0
  • P02: twelve retail configurations, three unaffiliated operators, the seven-day soak define D1's reproduction

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.

- +
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 DEFERRED

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

  • 10 pass
  • 7 fail
  • 0 blocked
  • 0 running
  • 255 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: 2 passed under the standard, 0 running with team evidence, 14 not run, 0 deferred

  • GOV8 casesNOT RUN
  • GPU8 casesNOT RUN
G2FAIL

Experiments

D2

No improvement claim from a negative hypothesis.

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

  • GOV8 casesNOT RUN
  • GPU8 casesNOT RUN
  • POW8 casesFAIL
  • 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
G4FAIL

Coexistence

D4

No durability claim based on assumed chip expiry.

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

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

No rescue

D5

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

56 cases: 5 passed under the standard, 0 running with team evidence, 51 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

FAIL

Technical readiness

Execution control

No mainnet-ready claim with missing enforcement or safety.

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

  • GOV8 casesNOT RUN
  • POW8 casesFAIL
  • EVM8 casesNOT RUN
  • ZKP8 casesNOT RUN
  • CAP8 casesNOT RUN
  • FIN8 casesNOT RUN
  • VER8 casesFAIL
  • 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
FAIL

Leadership-contender decision

Execution control

Supports a scoped contention assessment, not a guaranteed rank.

272 cases: 10 passed under the standard, 0 running with team evidence, 7 failed, 255 not run, 0 deferred

  • GOV8 casesNOT RUN
  • GPU8 casesNOT RUN
  • POW8 casesFAIL
  • ADV8 casesNOT RUN
  • ROT8 casesNOT RUN
  • ECO8 casesFAIL
  • EVM8 casesNOT RUN
  • ZKP8 casesNOT RUN
  • CAP8 casesNOT RUN
  • INC8 casesNOT RUN
  • FIN8 casesNOT RUN
  • VER8 casesFAIL
  • OPS8 casesNOT RUN
  • UX8 casesNOT RUN
  • COM8 casesNOT RUN
  • LEAD8 casesNOT RUN
  • REV44 casesNOT RUN
  • INT18 casesFAIL
  • VR40 casesNOT RUN
  • TV32 casesNOT RUN
  • R1510 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 9 Oct 2026, 08:43 UK

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
node lane (a283f5f0d364ceef0)
Run
f0-signing-20261008-2330
Design status
NOT RUN
Standard page
18
Plan pages
5, 21, 23, 25, 26, 27
GOV-02Approve thresholds before resultsPriority BLOCKERProfile P00NOT RUNEvidence recordLast run 8 Oct 2026, 21:10 UK

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
CI steward (a2ecfa95d3206016c)
Run
team-2026-10-08
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
Standard page
18
Plan pages
5, 21, 23, 25, 26, 27
GOV-04Preserve raw and negative evidencePriority BLOCKERProfile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
CI steward (a2ecfa95d3206016c)
Design status
NOT RUN
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 8 Oct 2026, 19:28 UK

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
fast-time lane (a8be71a0db962911c)
Run
200-417c4a57-b2
Design status
NOT RUN
Standard page
19
Plan pages
5, 21, 23, 25, 26, 27
GOV-06Enforce scope and optional-feature disciplinePriority BLOCKERProfile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 08:36 UK

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
CI steward (a2ecfa95d3206016c)
Run
site-gate-20261009-01
Design status
NOT RUN
Standard page
19
Plan pages
5, 21, 23, 25, 26, 27
GOV-07Independent review and finding closurePriority BLOCKERProfile P09NOT RUNEvidence none yetLast run 2026-10-08 18:3x UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
CI steward (a2ecfa95d3206016c)
Design status
NOT RUN
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: 2 passed under the standard, 0 running with team evidence, 6 not run, 0 deferred
GPU-01Cover the declared commodity populationPriority GATEProfile P02PASSEvidence none yetLast run 9 Oct 2026, 10:08 UK

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
research lane (ad6a2bd47d4a46105)
Run
hash-lane-20261009-batch5
Design status
NOT RUN
Standard page
21
Plan pages
6, 7, 8, 14, 18, 23
GPU-02Reproduce Ember clock-lock savingsPriority GATEProfile P02, P03PASSEvidence recordLast run 9 Oct 2026, 04:58 UK

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
hash lane (a690540514aa453d7)
Run
hash-lane-20261009-batch4
Design status
NOT RUN
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 9 Oct 2026, 10:08 UK

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
hash lane (a690540514aa453d7)
Run
hash-lane-20261009-batch5
Design status
NOT RUN
Standard page
21
Plan pages
6, 7, 8, 14, 18, 23
GPU-04Find the memory-clock operating ladderPriority BLOCKERProfile P01, P02NOT RUNEvidence recordLast run 8 Oct 2026, 22:00 UK

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
hash lane (a690540514aa453d7)
Run
team-2026-10-08
Design status
NOT RUN
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 9 Oct 2026, 04:58 UK

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
hash lane (a690540514aa453d7)
Run
hash-lane-20261009-batch4
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
22
Plan pages
6, 7, 8, 14, 18, 23
GPU-07Survive sustained thermal and power operationPriority BLOCKERProfile P01, P02, P10NOT RUNEvidence recordLast run 8 Oct 2026, 22:00 UK

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
hash lane (a690540514aa453d7)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
23
Plan pages
6, 7, 8, 14, 18, 23
GPU-08Reproduce the full baseline independentlyPriority GATEProfile P02NOT RUNEvidence none yetLast run 2026-10-08 18:3x UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
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.

FAIL
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, 2 failed, 6 not run, 0 deferred
POW-01Match independent execution across every backendPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run 9 Oct 2026, 11:15 UK

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
hash lane (a690540514aa453d7)
Run
mhpow-b3-20261009-01
Design status
NOT RUN
Standard page
24
Plan pages
7, 9, 10, 23
POW-02Validate generated programs and index foldingPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run 9 Oct 2026, 11:20 UK

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
hash lane (a690540514aa453d7)
Run
1p5x-int8-20261009-01
Design status
NOT RUN
Standard page
24
Plan pages
7, 9, 10, 23
POW-03Test whether live state is unavoidablePriority GATEProfile P03, P04FAILEvidence none yetLast run 9 Oct 2026, 10:25 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
24
Plan pages
7, 9, 10, 23
POW-04Evaluate connected-resource restructuringPriority GATEProfile P03, P04NOT RUNEvidence none yetLast run 9 Oct 2026, 10:43 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
1p5x-x1-20261009-01
Design status
NOT RUN
Standard page
25
Plan pages
7, 9, 10, 23
POW-05Prevent amortised cheap winning attemptsPriority BLOCKERProfile P01, P04NOT RUNEvidence none yetLast run 9 Oct 2026, 11:10 UK

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
pool design seat (a3832b1c3b274b310)
Run
mhpow-b2-20261009-01
Design status
NOT RUN
Standard page
25
Plan pages
7, 9, 10, 23
POW-06Bound verifier work and malformed-input costPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 11:15 UK

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
hash lane (a690540514aa453d7)
Run
mhpow-b3-20261009-01
Design status
NOT RUN
Standard page
25
Plan pages
7, 9, 10, 23
POW-07Constrain any mixed-resource or FP32 branchPriority BLOCKERProfile P00, P01, P03FAILEvidence none yetLast run 8 Oct 2026, 22:00 UK

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
hash lane (a690540514aa453d7)
Run
kills-20261008
Design status
NOT RUN
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 9 Oct 2026, 10:08 UK

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
hash lane (a690540514aa453d7)
Run
hash-lane-20261009-batch5
Design status
NOT RUN
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 recordLast run 9 Oct 2026, 10:25 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
27
Plan pages
8, 10, 12, 22, 23
ADV-02Price shared, reduced and reconstructed memoryPriority GATEProfile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 10:44 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-x7
Design status
NOT RUN
Standard page
27
Plan pages
8, 10, 12, 22, 23
ADV-03Attack with data-local and hybrid executionPriority GATEProfile P04NOT RUNEvidence recordLast run 9 Oct 2026, 10:25 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
27
Plan pages
8, 10, 12, 22, 23
ADV-04Measure profitable selective participationPriority GATEProfile P04, P12NOT RUNEvidence recordLast run 8 Oct 2026, 21:41 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261008-placed-8lane
Design status
NOT RUN
Standard page
28
Plan pages
8, 10, 12, 22, 23
ADV-05Validate physical and complete-board costsPriority GATEProfile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 10:44 UK

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
k lane (a3c9601a6d4686fe1)
Run
adversary-20261009-x7
Design status
NOT RUN
Standard page
28
Plan pages
8, 10, 12, 22, 23
ADV-06Separate process advantage from specialisationPriority GATEProfile P04, P12NOT RUNEvidence recordLast run 8 Oct 2026, 22:09 UK

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
k lane (a3c9601a6d4686fe1)
Run
floor-k-20261008-rows-repeat
Design status
NOT RUN
Standard page
28
Plan pages
8, 10, 12, 22, 23
ADV-07Evaluate lifetime without forced obsolescencePriority GATEProfile P04, P12NOT RUNEvidence none yetLast run 9 Oct 2026, 10:25 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-placed-32lane
Design status
NOT RUN
Standard page
29
Plan pages
8, 10, 12, 22, 23
ADV-08Independently challenge the best-cost envelopePriority GATEProfile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 10:44 UK

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
adversary lane (a1a9876a88f5a72fc)
Run
adversary-20261009-x7
Design status
NOT RUN
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 recordLast run 8 Oct 2026, 21:07 UK

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
fast-time lane (a8be71a0db962911c)
Run
f10-worker-20261008
Design status
NOT RUN
Standard page
30
Plan pages
7, 11, 19, 21
ROT-02Cross weekly and family boundaries togetherPriority BLOCKERProfile P01, P03, P08NOT RUNEvidence none yetLast run 2026-10-08 18:3x UK

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.

Evidence record of the run

What was run
the class v6 object crossing at its floor on 617cb441
Run by
fast-time lane (a8be71a0db962911c)
Under the standard
no: team-run before the standard's procedure; the status is RUNNING until the case is re-run under its steps with the profile's numbers and an independent run where the profile asks one
Pass or fail today
not judged under the standard yet
Method
Automated + independent review
Cadence
Release candidate; repeat after relevant changes
Owner
fast-time lane (a8be71a0db962911c)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
30
Plan pages
7, 11, 19, 21
ROT-03Test miner-voted bring-forward governancePriority BLOCKERProfile P00, P01, P08NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

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
node lane (a283f5f0d364ceef0)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
30
Plan pages
7, 11, 19, 21
ROT-04Resist seed selection and faster evaluatorsPriority BLOCKERProfile P00, P01, P08NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
node lane (a283f5f0d364ceef0)
Design status
NOT RUN
Standard page
31
Plan pages
7, 11, 19, 21
ROT-05Continue or pause correctly when finality stopsPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
finality lane (aca0f5ed924a2a99b)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
31
Plan pages
7, 11, 19, 21
ROT-06Activate datasets without hidden exclusionsPriority BLOCKERProfile P01, P06NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
hash lane (a690540514aa453d7)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
31
Plan pages
7, 11, 19, 21
ROT-07Ablate redundant rotation layersPriority GATEProfile P03, P04NOT RUNEvidence recordLast run 8 Oct 2026, 22:49 UK

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
lane D family gate (a07a99a3788566af2)
Run
family-gate-20261008c
Design status
NOT RUN
Standard page
32
Plan pages
7, 11, 19, 21
ROT-08Pass the no-new-rules counterfactualPriority GATEProfile P04, P12NOT RUNEvidence recordLast run 8 Oct 2026, 22:49 UK

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
node lane (a283f5f0d364ceef0)
Run
family-gate-20261008c
Design status
NOT RUN
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.

FAIL
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, 1 failed, 7 not run, 0 deferred
ECO-01Reconcile complete cost per accepted workPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 21:07 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco05-20261008-02
Design status
NOT RUN
Standard page
33
Plan pages
8, 13, 18, 24, 26
ECO-02Separate existing-owner and new-entrant viabilityPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
33
Plan pages
8, 13, 18, 24, 26
ECO-03Let the specialist keep its sunk developmentPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
33
Plan pages
8, 13, 18, 24, 26
ECO-04Model entry, exit and difficulty responsePriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
34
Plan pages
8, 13, 18, 24, 26
ECO-05Stress success, contraction and cheap electricityPriority GATEProfile P12FAILEvidence recordLast run 8 Oct 2026, 21:07 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco05-20261008-02
Design status
NOT RUN
Standard page
34
Plan pages
8, 13, 18, 24, 26
ECO-06Fund security and proving as issuance fallsPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
34
Plan pages
8, 13, 18, 24, 26
ECO-07Price memory growth and honest-card displacementPriority GATEProfile P06, P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
35
Plan pages
8, 13, 18, 24, 26
ECO-08Reproduce and adversarially audit the modelPriority GATEProfile P12NOT RUNEvidence recordLast run 8 Oct 2026, 21:07 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco05-20261008-02
Design status
NOT RUN
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: 1 passed under the standard, 0 running with team evidence, 7 not run, 0 deferred
EVM-01Match the selected EVM semanticsPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 21:10 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
36
Plan pages
15, 25, 34, 35, 36, 37
EVM-02Preserve transaction binding and replay protectionPriority BLOCKERProfile P01NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
36
Plan pages
15, 25, 34, 35, 36, 37
EVM-03Test two-dimensional fees and proving limitsPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:13 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1744-evm
Design status
NOT RUN
Standard page
36
Plan pages
15, 25, 34, 35, 36, 37
EVM-04Exercise block context and randomness assumptionsPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:13 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1744-evm
Design status
NOT RUN
Standard page
37
Plan pages
15, 25, 34, 35, 36, 37
EVM-05Run representative contract integration journeysPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:13 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1744-evm
Design status
NOT RUN
Standard page
37
Plan pages
15, 25, 34, 35, 36, 37
EVM-06Validate wallets, RPC and indexersPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:13 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1744-evm
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
reference-apps lane (a2060899d2a27d31c)
Design status
NOT RUN
Standard page
38
Plan pages
15, 25, 34, 35, 36, 37
EVM-08Verify controlled execution and verifier upgradesPriority BLOCKERProfile P01, P08, P09PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
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: 4 passed under the standard, 0 running with team evidence, 4 not run, 0 deferred
ZKP-01Reject missing and invalid proofsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
39
Plan pages
16, 20, 24, 25, 36, 37
ZKP-02Bind program, verifier and security parametersPriority BLOCKERProfile P01, P09PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
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 9 Oct 2026, 01:33 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
39
Plan pages
16, 20, 24, 25, 36, 37
ZKP-04Prevent reward and payout substitutionPriority BLOCKERProfile P01PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
Standard page
40
Plan pages
16, 20, 24, 25, 36, 37
ZKP-05Make proof payment idempotent across racesPriority BLOCKERProfile P01PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
Standard page
40
Plan pages
16, 20, 24, 25, 36, 37
ZKP-06Verify aggregation coverage and completenessPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
enforced-proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Standard page
41
Plan pages
16, 20, 24, 25, 36, 37
ZKP-08Preserve authority and audit all acceptance pathsPriority BLOCKERProfile P01, P07, P08PASSEvidence recordLast run 8 Oct 2026, 23:24 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
enforced-proving-20261008-03
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
42
Plan pages
17, 18, 24, 25
CAP-02Prove on the actual mining configurationPriority BLOCKERProfile P01, P06, P07NOT RUNEvidence recordLast run 8 Oct 2026, 23:22 UK

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
fleet lane (ac055d60427caab99)
Run
v607-floor-memory-20261008T2059Z
Design status
NOT RUN
Standard page
42
Plan pages
17, 18, 24, 25
CAP-03Measure the entire request-to-payment pathPriority GATEProfile P07NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
42
Plan pages
17, 18, 24, 25
CAP-04Sustain meaningful load without queue growthPriority GATEProfile P07NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
43
Plan pages
17, 18, 24, 25
CAP-05Overload and recover without false acceptancePriority BLOCKERProfile P01, P07NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
43
Plan pages
17, 18, 24, 25
CAP-06Calibrate assignment windows to paid completionPriority GATEProfile P07, P12NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
Standard page
44
Plan pages
17, 18, 24, 25
CAP-08Deliver customer-verifiable output at scalePriority BLOCKERProfile P01, P07, P14NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
fleet lane (ac055d60427caab99)
Design status
NOT RUN
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 9 Oct 2026, 01:33 UK

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
enforced-proving lane (a6e8f84588b809d62)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
45
Plan pages
13, 16, 17, 18, 24, 26
INC-02Keep revenue streams and claims separatePriority BLOCKERProfile P01, P12, P14NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
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 recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
Standard page
45
Plan pages
13, 16, 17, 18, 24, 26
INC-04Survive external-demand spikes and token declinesPriority GATEProfile P07, P08, P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
enforced-proving lane (a6e8f84588b809d62)
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
research lane (ad6a2bd47d4a46105)
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
enforced-proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Standard page
47
Plan pages
13, 16, 17, 18, 24, 26
INC-08Quantify provider and supplier failure concentrationPriority GATEProfile P08, P11, P12NOT RUNEvidence recordLast run 8 Oct 2026, 20:55 UK

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
research lane (ad6a2bd47d4a46105)
Run
eco-d4-20261008-01
Design status
NOT RUN
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: 1 passed under the standard, 0 running with team evidence, 7 not run, 0 deferred
FIN-01Agree on ordering, work and executed statePriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
fast-time lane (a8be71a0db962911c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
48
Plan pages
19, 21, 24, 25
FIN-02Attack finality with split honest populationsPriority BLOCKERProfile P01, P08PASSEvidence recordLast run 9 Oct 2026, 02:02 UK

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
finality lane (aca0f5ed924a2a99b)
Run
fin-203-20261009T0127Z
Design status
NOT RUN
Standard page
48
Plan pages
19, 21, 24, 25
FIN-03Cross authority expiry in a long partitionPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
finality lane (aca0f5ed924a2a99b)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
48
Plan pages
19, 21, 24, 25
FIN-04Stop signing while mining continuesPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
finality lane (aca0f5ed924a2a99b)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
49
Plan pages
19, 21, 24, 25
FIN-05Authenticate voter-set changes and pooled keysPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
finality lane (aca0f5ed924a2a99b)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
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 8 Oct 2026, 21:10 UK

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
finality lane (aca0f5ed924a2a99b)
Run
team-2026-10-08
Design status
NOT RUN
Standard page
49
Plan pages
19, 21, 24, 25
FIN-07Recover deterministically after reconnection and crashPriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 02:02 UK

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
finality lane (aca0f5ed924a2a99b)
Run
fin-203-20261009T0127Z
Design status
NOT RUN
Standard page
50
Plan pages
19, 21, 24, 25
FIN-08Combine boundaries, faults and adversarial schedulingPriority BLOCKERProfile P01, P08NOT RUNEvidence recordLast run 9 Oct 2026, 02:02 UK

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
fast-time lane (a8be71a0db962911c)
Run
fin-203-20261009T0127Z
Design status
NOT RUN
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.

FAIL
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, 3 failed, 5 not run, 0 deferred
VER-01Authenticate light-client bootstrapPriority BLOCKERProfile P01, P09FAILEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
51
Plan pages
20, 25, 35, 37
VER-02Verify evolving authority and execution statementsPriority BLOCKERProfile P01, P09FAILEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
51
Plan pages
20, 25, 35, 37
VER-03Prove successful payment rather than inclusionPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
51
Plan pages
20, 25, 35, 37
VER-04Bound cross-chain oracle trust and replayPriority BLOCKERProfile P00, P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
52
Plan pages
20, 25, 35, 37
VER-05Reconstruct required state without founder storagePriority BLOCKERProfile P01, P08, P09FAILEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
52
Plan pages
20, 25, 35, 37
VER-06Detect withholding, corruption and stale dataPriority BLOCKERProfile P01, P08, P09NOT RUNEvidence recordLast run 8 Oct 2026, 20:46 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
ra-20261008T1915-ver
Design status
NOT RUN
Standard page
52
Plan pages
20, 25, 35, 37
VER-07Protect wallet keys, signing and recoveryPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
shipper (ae892a8b0f78fe31c)
Design status
NOT RUN
Standard page
53
Plan pages
20, 25, 35, 37
VER-08Keep every user-facing state truthfulPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
reference-apps lane (a2060899d2a27d31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
node lane (a283f5f0d364ceef0)
Design status
NOT RUN
Standard page
54
Plan pages
21, 24, 25, 26
OPS-02Diversify bootstrap and resist peer isolationPriority BLOCKERProfile P01, P08, P09NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
Standard page
54
Plan pages
21, 24, 25, 26
OPS-03Separate update distribution from consensus authorityPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 11:17 UK

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
shipper (ae892a8b0f78fe31c)
Run
site-manifest-20261009-02
Design status
NOT RUN
Standard page
54
Plan pages
21, 24, 25, 26
OPS-04Recover nodes from crash and storage damagePriority BLOCKERProfile P01, P08NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
node lane (a283f5f0d364ceef0)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
55
Plan pages
21, 24, 25, 26
OPS-05Isolate untrusted proving workloadsPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
Standard page
55
Plan pages
21, 24, 25, 26
OPS-06Contain malicious network and API trafficPriority BLOCKERProfile P01, P09NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
build-server lane (a352e49ff4613df86)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
55
Plan pages
21, 24, 25, 26
OPS-07Detect failures with usable evidence and runbooksPriority GATEProfile P09, P10NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
Standard page
56
Plan pages
21, 24, 25, 26
OPS-08Repeat independent operation across releasesPriority BLOCKERProfile P00, P08, P11NOT RUNEvidence none yetLast run 8 Oct 2026, 20:22 UK

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
build-server lane (a352e49ff4613df86)
Design status
NOT RUN
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 recordLast run 8 Oct 2026, 21:42 UK

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
update-return lane (a22d765a2e0355a9f)
Run
ux-01-20261008-win-2.0.0
Design status
NOT RUN
Standard page
57
Plan pages
14, 21, 25, 26
UX-02Make pause, stop and safe tuning reliablePriority BLOCKERProfile P01, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
shipper (ae892a8b0f78fe31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
57
Plan pages
14, 21, 25, 26
UX-03Show net earnings and compatibility honestlyPriority BLOCKERProfile P01, P10, P12NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
shipper (ae892a8b0f78fe31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
57
Plan pages
14, 21, 25, 26
UX-04Pay small operators without hidden custodyPriority BLOCKERProfile P01, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
pool design seat (a3832b1c3b274b310)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
58
Plan pages
14, 21, 25, 26
UX-05Keep voting keys with the miner through poolingPriority BLOCKERProfile P01, P09NOT RUNEvidence recordLast run 8 Oct 2026, 21:48 UK

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
pool design seat (a3832b1c3b274b310)
Run
pool-2.0-20261008-03
Design status
NOT RUN
Standard page
58
Plan pages
14, 21, 25, 26
UX-06Verify actual miner-selected work templatesPriority BLOCKERProfile P01, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
shipper (ae892a8b0f78fe31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
58
Plan pages
14, 21, 25, 26
UX-07Expose actionable failures and safe updatesPriority BLOCKERProfile P09, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 01:33 UK

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
shipper (ae892a8b0f78fe31c)
Run
202-5d53a591-1176efb9
Design status
NOT RUN
Standard page
59
Plan pages
14, 21, 25, 26
UX-08Publish competitive accessible softwarePriority GATEProfile P02, P10NOT RUNEvidence none yetLast run 9 Oct 2026, 08:36 UK

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
hash lane (a690540514aa453d7)
Run
site-gate-20261009-01
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 21:10 UK

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
main / the founder
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
main / the founder
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
site lane (a846fd66b5403e35a)
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
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 2026-10-08 18:3x UK

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
main / the founder
Design status
NOT RUN
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 8 Oct 2026, 20:22 UK

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
main / the founder
Design status
NOT RUN
Standard page
65
Plan pages
4, 22, 25, 27, 31, 32, 33
17REV

REV: the external review's required regressions

44 regressions from 14 findings; each reads NOT RUN until its owner lane records a run

NOT RUN
Owner
the owner lanes per the dispatch table
Gate
Review findings closed
Fixtures
F0,F5
Plan pages
docs/analysis/review-2026-10-08-b/findings.json and docs/analysis/review-2026-10-08-b/dispatch.md; ids from the master traceability register
44 cases: 2 passed under the standard, 0 running with team evidence, 42 not run, 0 deferred
R2-F01-R01Valid proof A, warm cache, carried statement B: refuse exactly as a cold node does.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F01 requires (review R2 finding F01: Proof-verdict cache omits the statement being verified).

Steps

  1. Valid proof A, warm cache, carried statement B: refuse exactly as a cold node does.

Accept

Valid proof A, warm cache, carried statement B: refuse exactly as a cold node does.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, node lane
Design status
NOT RUN
Plan pages
R2-F01
R2-F01-R02Run valid/invalid contexts in both orders, concurrently and across cache eviction/restart.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F01 requires (review R2 finding F01: Proof-verdict cache omits the statement being verified).

Steps

  1. Run valid/invalid contexts in both orders, concurrently and across cache eviction/restart.

Accept

Run valid/invalid contexts in both orders, concurrently and across cache eviction/restart.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, node lane
Design status
NOT RUN
Plan pages
R2-F01
R2-F01-R03Change payout, network, kind, program ID and activation context; no accepted misbinding.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F01 requires (review R2 finding F01: Proof-verdict cache omits the statement being verified).

Steps

  1. Change payout, network, kind, program ID and activation context; no accepted misbinding.

Accept

Change payout, network, kind, program ID and activation context; no accepted misbinding.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, node lane
Design status
NOT RUN
Plan pages
R2-F01
R2-F01-R04A native two-node test must agree on block validity and payouts despite different cache histories.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F01 requires (review R2 finding F01: Proof-verdict cache omits the statement being verified).

Steps

  1. A native two-node test must agree on block validity and payouts despite different cache histories.

Accept

A native two-node test must agree on block validity and payouts despite different cache histories.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, node lane
Design status
NOT RUN
Plan pages
R2-F01
R2-F02-R01Release build cannot activate test bypass.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F02 requires (review R2 finding F02: Proof-rule infrastructure can fail open).

Steps

  1. Release build cannot activate test bypass.

Accept

Release build cannot activate test bypass.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, CI steward
Design status
NOT RUN
Plan pages
R2-F02
R2-F02-R02Missing oracle or pinned keys prevents service readiness after enforcement activation.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F02 requires (review R2 finding F02: Proof-rule infrastructure can fail open).

Steps

  1. Missing oracle or pinned keys prevents service readiness after enforcement activation.

Accept

Missing oracle or pinned keys prevents service readiness after enforcement activation.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, CI steward
Design status
NOT RUN
Plan pages
R2-F02
R2-F02-R03Missing proof bytes retry without incorrectly marking a valid block permanently invalid.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F02 requires (review R2 finding F02: Proof-rule infrastructure can fail open).

Steps

  1. Missing proof bytes retry without incorrectly marking a valid block permanently invalid.

Accept

Missing proof bytes retry without incorrectly marking a valid block permanently invalid.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, CI steward
Design status
NOT RUN
Plan pages
R2-F02
R2-F03-R01Clean build from one manifest, including the pool and workers, with no unpublished vendor tree.Priority P0Profile P00PASSEvidence none yetLast run 8 Oct 2026, 22:11 UK

Setup

The regression R2-F03 requires (review R2 finding F03: The bundle contains a v6 candidate, not a demonstrated integrated v6 release).

Steps

  1. Clean build from one manifest, including the pool and workers, with no unpublished vendor tree.

Accept

Clean build from one manifest, including the pool and workers, with no unpublished vendor tree.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward, hash lane (ProgramClass::V6 on freeze), pool lane
Run
f03-manifest-20261008-01
Design status
NOT RUN
Plan pages
R2-F03
R2-F03-R02Same job context produces identical accepted work in node, CPU reference, CUDA, Metal, OpenCL and pool.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:57 UK

Setup

The regression R2-F03 requires (review R2 finding F03: The bundle contains a v6 candidate, not a demonstrated integrated v6 release).

Steps

  1. Same job context produces identical accepted work in node, CPU reference, CUDA, Metal, OpenCL and pool.

Accept

Same job context produces identical accepted work in node, CPU reference, CUDA, Metal, OpenCL and pool.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward, hash lane (ProgramClass::V6 on freeze), pool lane
Run
same-work-20261008-03
Design status
NOT RUN
Plan pages
R2-F03
R2-F03-R03Cross every scheduled transition with old/new client behavior documented and identical rule identities.Priority P0Profile P00PASSEvidence none yetLast run 9 Oct 2026, 09:57 UK

Setup

The regression R2-F03 requires (review R2 finding F03: The bundle contains a v6 candidate, not a demonstrated integrated v6 release).

Steps

  1. Cross every scheduled transition with old/new client behavior documented and identical rule identities.

Accept

Cross every scheduled transition with old/new client behavior documented and identical rule identities.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward, hash lane (ProgramClass::V6 on freeze), pool lane
Run
same-work-20261008-03
Design status
NOT RUN
Plan pages
R2-F03
R2-F04-R01Native multi-node 40/40/20 partition, equivocation and dust-valid mining on both sides past the window.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F04 requires (review R2 finding F04: Finality v4 recovery deliberately has a weaker safety boundary).

Steps

  1. Native multi-node 40/40/20 partition, equivocation and dust-valid mining on both sides past the window.

Accept

Native multi-node 40/40/20 partition, equivocation and dust-valid mining on both sides past the window.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane, reference apps, site (explorer)
Design status
NOT RUN
Plan pages
R2-F04
R2-F04-R02Proof that the chosen recovery guarantee matches the public finality claim; two valid contradictory certificates are a hard failure for strong finality.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F04 requires (review R2 finding F04: Finality v4 recovery deliberately has a weaker safety boundary).

Steps

  1. Proof that the chosen recovery guarantee matches the public finality claim; two valid contradictory certificates are a hard failure for strong finality.

Accept

Proof that the chosen recovery guarantee matches the public finality claim; two valid contradictory certificates are a hard failure for strong finality.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane, reference apps, site (explorer)
Design status
NOT RUN
Plan pages
R2-F04
R2-F04-R03Pause-only resume with historical backfill, missing historical data and all old keys returning.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F04 requires (review R2 finding F04: Finality v4 recovery deliberately has a weaker safety boundary).

Steps

  1. Pause-only resume with historical backfill, missing historical data and all old keys returning.

Accept

Pause-only resume with historical backfill, missing historical data and all old keys returning.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane, reference apps, site (explorer)
Design status
NOT RUN
Plan pages
R2-F04
R2-F04-R04Wallet, receipt and oracle consumers distinguish any weaker recovery state.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F04 requires (review R2 finding F04: Finality v4 recovery deliberately has a weaker safety boundary).

Steps

  1. Wallet, receipt and oracle consumers distinguish any weaker recovery state.

Accept

Wallet, receipt and oracle consumers distinguish any weaker recovery state.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane, reference apps, site (explorer)
Design status
NOT RUN
Plan pages
R2-F04
R2-F05-R01Native reference-vs-incremental expression equivalence across all source registers and real instruction updates.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F05 requires (review R2 finding F05: reg64 address coupling has an exact incremental alternative).

Steps

  1. Native reference-vs-incremental expression equivalence across all source registers and real instruction updates.

Accept

Native reference-vs-incremental expression equivalence across all source registers and real instruction updates.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, adversary lane, floor lane 3
Design status
NOT RUN
Plan pages
R2-F05
R2-F05-R02Full-kernel output equivalence, registers, spills, wall power and accepted throughput across target GPUs.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F05 requires (review R2 finding F05: reg64 address coupling has an exact incremental alternative).

Steps

  1. Full-kernel output equivalence, registers, spills, wall power and accepted throughput across target GPUs.

Accept

Full-kernel output equivalence, registers, spills, wall power and accepted throughput across target GPUs.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, adversary lane, floor lane 3
Design status
NOT RUN
Plan pages
R2-F05
R2-F05-R03Adversary physical design includes prefix caching/recomputation cost; no assumed full 63-read cost on every load.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F05 requires (review R2 finding F05: reg64 address coupling has an exact incremental alternative).

Steps

  1. Adversary physical design includes prefix caching/recomputation cost; no assumed full 63-read cost on every load.

Accept

Adversary physical design includes prefix caching/recomputation cost; no assumed full 63-read cost on every load.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, adversary lane, floor lane 3
Design status
NOT RUN
Plan pages
R2-F05
R2-F06-R01Acceptance/reference/emitter evaluate the same activated schedule.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F06 requires (review R2 finding F06: The v6 acceptance and census gates are not complete for the final execution).

Steps

  1. Acceptance/reference/emitter evaluate the same activated schedule.

Accept

Acceptance/reference/emitter evaluate the same activated schedule.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, research lane D
Design status
NOT RUN
Plan pages
R2-F06
R2-F06-R02Full live-dataset census on unseen seeds and the complete v6 pack.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F06 requires (review R2 finding F06: The v6 acceptance and census gates are not complete for the final execution).

Steps

  1. Full live-dataset census on unseen seeds and the complete v6 pack.

Accept

Full live-dataset census on unseen seeds and the complete v6 pack.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, research lane D
Design status
NOT RUN
Plan pages
R2-F06
R2-F06-R03A failed experimental rule does not silently exhaust generation or bypass the intended resource requirement.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F06 requires (review R2 finding F06: The v6 acceptance and census gates are not complete for the final execution).

Steps

  1. A failed experimental rule does not silently exhaust generation or bypass the intended resource requirement.

Accept

A failed experimental rule does not silently exhaust generation or bypass the intended resource requirement.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
hash lane, research lane D
Design status
NOT RUN
Plan pages
R2-F06
R2-F07-R01Same final v6 configuration: mine -> evict -> prove -> aggregate -> submit -> rebuild -> resume; no leaked reservations.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F07 requires (review R2 finding F07: VRAM admission and proving deadlines need one operator-level scheduler).

Steps

  1. Same final v6 configuration: mine -> evict -> prove -> aggregate -> submit -> rebuild -> resume; no leaked reservations.

Accept

Same final v6 configuration: mine -> evict -> prove -> aggregate -> submit -> rebuild -> resume; no leaked reservations.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, fleet lane
Design status
NOT RUN
Plan pages
R2-F07
R2-F07-R02OOM, process crash and stale work recover without losing wallet state or silently consuming power.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F07 requires (review R2 finding F07: VRAM admission and proving deadlines need one operator-level scheduler).

Steps

  1. OOM, process crash and stale work recover without losing wallet state or silently consuming power.

Accept

OOM, process crash and stale work recover without losing wallet state or silently consuming power.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, fleet lane
Design status
NOT RUN
Plan pages
R2-F07
R2-F07-R0316 GB+ simultaneous mode only after measured peak plus next-epoch headroom; smaller-card modes labelled separately.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F07 requires (review R2 finding F07: VRAM admission and proving deadlines need one operator-level scheduler).

Steps

  1. 16 GB+ simultaneous mode only after measured peak plus next-epoch headroom; smaller-card modes labelled separately.

Accept

16 GB+ simultaneous mode only after measured peak plus next-epoch headroom; smaller-card modes labelled separately.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, fleet lane
Design status
NOT RUN
Plan pages
R2-F07
R2-F08-R01Report every eligible job outcome, including expired work; a bounded list cannot hide losses.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F08 requires (review R2 finding F08: The proving pipeline reports waste and deadline censoring, not sustained capacity).

Steps

  1. Report every eligible job outcome, including expired work; a bounded list cannot hide losses.

Accept

Report every eligible job outcome, including expired work; a bounded list cannot hide losses.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, fleet lane, site (ops page)
Design status
NOT RUN
Plan pages
R2-F08
R2-F08-R02Consumer tiers complete and receive payment for declared jobs before claims about income.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F08 requires (review R2 finding F08: The proving pipeline reports waste and deadline censoring, not sustained capacity).

Steps

  1. Consumer tiers complete and receive payment for declared jobs before claims about income.

Accept

Consumer tiers complete and receive payment for declared jobs before claims about income.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, fleet lane, site (ops page)
Design status
NOT RUN
Plan pages
R2-F08
R2-F08-R03Sustained real workload across class transitions, with restart/retry and no publisher intervention.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F08 requires (review R2 finding F08: The proving pipeline reports waste and deadline censoring, not sustained capacity).

Steps

  1. Sustained real workload across class transitions, with restart/retry and no publisher intervention.

Accept

Sustained real workload across class transitions, with restart/retry and no publisher intervention.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane, fleet lane, site (ops page)
Design status
NOT RUN
Plan pages
R2-F08
R2-F09-R01Generate all pass/fail cells directly from the declared inequalities and inputs.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F09 requires (review R2 finding F09: The economic model explicitly retains a failed specialist case).

Steps

  1. Generate all pass/fail cells directly from the declared inequalities and inputs.

Accept

Generate all pass/fail cells directly from the declared inequalities and inputs.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
research lane, floor lane 3, coordinator
Design status
NOT RUN
Plan pages
R2-F09
R2-F09-R02Independent feasibility and cost evaluation of the strongest modeled SRAM/hybrid opponent.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F09 requires (review R2 finding F09: The economic model explicitly retains a failed specialist case).

Steps

  1. Independent feasibility and cost evaluation of the strongest modeled SRAM/hybrid opponent.

Accept

Independent feasibility and cost evaluation of the strongest modeled SRAM/hybrid opponent.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
research lane, floor lane 3, coordinator
Design status
NOT RUN
Plan pages
R2-F09
R2-F09-R03GPU owners and entrants remain viable under the approved scenario envelope without assuming chip absence or death.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F09 requires (review R2 finding F09: The economic model explicitly retains a failed specialist case).

Steps

  1. GPU owners and entrants remain viable under the approved scenario envelope without assuming chip absence or death.

Accept

GPU owners and entrants remain viable under the approved scenario envelope without assuming chip absence or death.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
research lane, floor lane 3, coordinator
Design status
NOT RUN
Plan pages
R2-F09
R2-F10-R01Compare exact found nonce/hash sets with full-read mode, including all-hit overflow and zero-hit cases.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F10 requires (review R2 finding F10: CUDA production readback has an existing OpenCL optimization to borrow).

Steps

  1. Compare exact found nonce/hash sets with full-read mode, including all-hit overflow and zero-hit cases.

Accept

Compare exact found nonce/hash sets with full-read mode, including all-hit overflow and zero-hit cases.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
worker lane (new)
Design status
NOT RUN
Plan pages
R2-F10
R2-F10-R02Test stale jobs, high-32 rollover, tail batches and asynchronous buffer reuse.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F10 requires (review R2 finding F10: CUDA production readback has an existing OpenCL optimization to borrow).

Steps

  1. Test stale jobs, high-32 rollover, tail batches and asynchronous buffer reuse.

Accept

Test stale jobs, high-32 rollover, tail batches and asynchronous buffer reuse.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
worker lane (new)
Design status
NOT RUN
Plan pages
R2-F10
R2-F10-R03Compare production throughput and wall energy, not only the isolated kernel timer.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F10 requires (review R2 finding F10: CUDA production readback has an existing OpenCL optimization to borrow).

Steps

  1. Compare production throughput and wall energy, not only the isolated kernel timer.

Accept

Compare production throughput and wall energy, not only the isolated kernel timer.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
worker lane (new)
Design status
NOT RUN
Plan pages
R2-F10
R2-F11-R01Goal switch from an efficiency prior can explore higher core/power when policy allows.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F11 requires (review R2 finding F11: Ember needs workload-aware identity and objective-aware search).

Steps

  1. Goal switch from an efficiency prior can explore higher core/power when policy allows.

Accept

Goal switch from an efficiency prior can explore higher core/power when policy allows.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (new)
Design status
NOT RUN
Plan pages
R2-F11
R2-F11-R02Driver, workload, dataset, compiler and device changes invalidate certification while retaining optional hints.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F11 requires (review R2 finding F11: Ember needs workload-aware identity and objective-aware search).

Steps

  1. Driver, workload, dataset, compiler and device changes invalidate certification while retaining optional hints.

Accept

Driver, workload, dataset, compiler and device changes invalidate certification while retaining optional hints.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (new)
Design status
NOT RUN
Plan pages
R2-F11
R2-F11-R03Thermal/error/late-share events revert safely, including process or machine crash.Priority P2Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F11 requires (review R2 finding F11: Ember needs workload-aware identity and objective-aware search).

Steps

  1. Thermal/error/late-share events revert safely, including process or machine crash.

Accept

Thermal/error/late-share events revert safely, including process or machine crash.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (new)
Design status
NOT RUN
Plan pages
R2-F11
R2-F12-R01Crash before/after broadcast, response timeout, restart before snapshot: no duplicate payment or silent debt loss.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F12 requires (review R2 finding F12: Pool payouts have a broadcast-before-durable-intent window).

Steps

  1. Crash before/after broadcast, response timeout, restart before snapshot: no duplicate payment or silent debt loss.

Accept

Crash before/after broadcast, response timeout, restart before snapshot: no duplicate payment or silent debt loss.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F12
R2-F12-R02Same signed transaction retried, fee replacement reconciled by intent, not a new payment.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F12 requires (review R2 finding F12: Pool payouts have a broadcast-before-durable-intent window).

Steps

  1. Same signed transaction retried, fee replacement reconciled by intent, not a new payment.

Accept

Same signed transaction retried, fee replacement reconciled by intent, not a new payment.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F12
R2-F12-R03Receipt reorg and finality pause leave correct pending obligations.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F12 requires (review R2 finding F12: Pool payouts have a broadcast-before-durable-intent window).

Steps

  1. Receipt reorg and finality pause leave correct pending obligations.

Accept

Receipt reorg and finality pause leave correct pending obligations.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F12
R2-F13-R01Repeated authorization rejected or atomically replaces and cleans prior state.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F13 requires (review R2 finding F13: Pool admission and membership need bounded resources).

Steps

  1. Repeated authorization rejected or atomically replaces and cleans prior state.

Accept

Repeated authorization rejected or atomically replaces and cleans prior state.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F13
R2-F13-R02Oversized unterminated frame rejected within fixed memory/time budget.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F13 requires (review R2 finding F13: Pool admission and membership need bounded resources).

Steps

  1. Oversized unterminated frame rejected within fixed memory/time budget.

Accept

Oversized unterminated frame rejected within fixed memory/time budget.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F13
R2-F13-R03Slow clients and invalid share floods cannot grow unbounded member, nonce or outgoing state.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F13 requires (review R2 finding F13: Pool admission and membership need bounded resources).

Steps

  1. Slow clients and invalid share floods cannot grow unbounded member, nonce or outgoing state.

Accept

Slow clients and invalid share floods cannot grow unbounded member, nonce or outgoing state.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (new)
Design status
NOT RUN
Plan pages
R2-F13
R2-F14-R01Public build has no default arbitrary remote execution and a documented least-privilege boundary.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F14 requires (review R2 finding F14: Developer fleet control must not silently become the public client trust model).

Steps

  1. Public build has no default arbitrary remote execution and a documented least-privilege boundary.

Accept

Public build has no default arbitrary remote execution and a documented least-privilege boundary.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, relay lane
Design status
NOT RUN
Plan pages
R2-F14
R2-F14-R02Automatic updates off remains off for urgent manifests until explicit action.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F14 requires (review R2 finding F14: Developer fleet control must not silently become the public client trust model).

Steps

  1. Automatic updates off remains off for urgent manifests until explicit action.

Accept

Automatic updates off remains off for urgent manifests until explicit action.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, relay lane
Design status
NOT RUN
Plan pages
R2-F14
R2-F14-R03A compromised fleet/update signing key cannot silently acquire wallet access or activate a consensus change.Priority P1Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

The regression R2-F14 requires (review R2 finding F14: Developer fleet control must not silently become the public client trust model).

Steps

  1. A compromised fleet/update signing key cannot silently acquire wallet access or activate a consensus change.

Accept

A compromised fleet/update signing key cannot silently acquire wallet access or activate a consensus change.

Evidence the case requires

The run record of the regression as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane, relay lane
Design status
NOT RUN
Plan pages
R2-F14
18INT

INT: the master edition's integration gates (R1, the full-system review)

18 integration gates; each reads NOT RUN until its owner lane records a run

FAIL
Owner
the owner lanes per the coordinator's crosswalk
Gate
Integration gates closed
Fixtures
F0,F5
Plan pages
docs/plans/igneum-2.0-master/traceability.json integration_gates
18 cases: 0 passed under the standard, 0 running with team evidence, 1 failed, 17 not run, 0 deferred
INT-01Real proof H cannot authenticate a different statement under a warm cache.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-01 of the master edition (R1 / Additional regression gates).

Steps

  1. Real proof H cannot authenticate a different statement under a warm cache.

Accept

Real proof H cannot authenticate a different statement under a warm cache.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Plan pages
R1
INT-02Warm/cold/relay/restart/concurrent cache order does not change block or payout decisions; negative cache isolated.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-02 of the master edition (R1 / Additional regression gates).

Steps

  1. Warm/cold/relay/restart/concurrent cache order does not change block or payout decisions; negative cache isolated.

Accept

Warm/cold/relay/restart/concurrent cache order does not change block or payout decisions; negative cache isolated.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Plan pages
R1
INT-03Durable payout outbox survives every crash/RPC boundary without duplicate or lost liabilities.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 00:47 UK

Setup

Integration gate INT-03 of the master edition (R1 / Additional regression gates).

Steps

  1. Durable payout outbox survives every crash/RPC boundary without duplicate or lost liabilities.

Accept

Durable payout outbox survives every crash/RPC boundary without duplicate or lost liabilities.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (a1c484c48a62948c2)
Run
pool-int-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-04Corrupt existing pool state, disk-full and reorg cause safe recovery, not silent empty balances.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 00:47 UK

Setup

Integration gate INT-04 of the master edition (R1 / Additional regression gates).

Steps

  1. Corrupt existing pool state, disk-full and reorg cause safe recovery, not silent empty balances.

Accept

Corrupt existing pool state, disk-full and reorg cause safe recovery, not silent empty balances.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (a1c484c48a62948c2)
Run
pool-int-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-05The supplied finality implementation matches the approved anchor rule after >window healing.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-05 of the master edition (R1 / Additional regression gates).

Steps

  1. The supplied finality implementation matches the approved anchor rule after >window healing.

Accept

The supplied finality implementation matches the approved anchor rule after >window healing.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane (a283f5f0d364ceef0)
Design status
NOT RUN
Plan pages
R1
INT-06Recovery tests state and preserve their weaker fault bound; interfaces never label it as a stronger guarantee.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-06 of the master edition (R1 / Additional regression gates).

Steps

  1. Recovery tests state and preserve their weaker fault bound; interfaces never label it as a stronger guarantee.

Accept

Recovery tests state and preserve their weaker fault bound; interfaces never label it as a stronger guarantee.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
node lane (a283f5f0d364ceef0)
Design status
NOT RUN
Plan pages
R1
INT-07One v6 object agrees in node, pool, CPU verifier and each supported GPU host across activation.Priority P0Profile P00FAILEvidence none yetLast run 9 Oct 2026, 09:59 UK

Setup

Integration gate INT-07 of the master edition (R1 / Additional regression gates).

Steps

  1. One v6 object agrees in node, pool, CPU verifier and each supported GPU host across activation.

Accept

One v6 object agrees in node, pool, CPU verifier and each supported GPU host across activation.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward with the hash lane (a690540514aa453d7) and the worker lane (a9e87343f008e0edd)
Run
canary-202-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-08Census, production acceptance, schedule counters and live-dataset tests use the identical frozen contract.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-08 of the master edition (R1 / Additional regression gates).

Steps

  1. Census, production acceptance, schedule counters and live-dataset tests use the identical frozen contract.

Accept

Census, production acceptance, schedule counters and live-dataset tests use the identical frozen contract.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward with the hash lane (a690540514aa453d7) and the worker lane (a9e87343f008e0edd)
Design status
NOT RUN
Plan pages
R1
INT-09Eight- and twelve-GiB epoch transitions recover deliberately without relying on repeated OOM/watchdog cycles.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-09 of the master edition (R1 / Additional regression gates).

Steps

  1. Eight- and twelve-GiB epoch transitions recover deliberately without relying on repeated OOM/watchdog cycles.

Accept

Eight- and twelve-GiB epoch transitions recover deliberately without relying on repeated OOM/watchdog cycles.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane
Design status
NOT RUN
Plan pages
R1
INT-10Metal/CUDA/OpenCL exact dataset geometry agrees; unsupported packs reject before launch.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-10 of the master edition (R1 / Additional regression gates).

Steps

  1. Metal/CUDA/OpenCL exact dataset geometry agrees; unsupported packs reject before launch.

Accept

Metal/CUDA/OpenCL exact dataset geometry agrees; unsupported packs reject before launch.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
CI steward with the hash lane (a690540514aa453d7) and the worker lane (a9e87343f008e0edd)
Design status
NOT RUN
Plan pages
R1
INT-11Only a memory-reserved proving job launches; mining buffers really release when required.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-11 of the master edition (R1 / Additional regression gates).

Steps

  1. Only a memory-reserved proving job launches; mining buffers really release when required.

Accept

Only a memory-reserved proving job launches; mining buffers really release when required.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
app lane
Design status
NOT RUN
Plan pages
R1
INT-12Transient shard errors can retry safely; expiration, loss and paid work remain distinct durable outcomes.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-12 of the master edition (R1 / Additional regression gates).

Steps

  1. Transient shard errors can retry safely; expiration, loss and paid work remain distinct durable outcomes.

Accept

Transient shard errors can retry safely; expiration, loss and paid work remain distinct durable outcomes.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane (a6e8f84588b809d62) and fleet lane (ac055d60427caab99)
Design status
NOT RUN
Plan pages
R1
INT-13Ember cannot retain a rate-ineligible prior; material workload changes invalidate incompatible profiles.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-13 of the master edition (R1 / Additional regression gates).

Steps

  1. Ember cannot retain a rate-ineligible prior; material workload changes invalidate incompatible profiles.

Accept

Ember cannot retain a rate-ineligible prior; material workload changes invalidate incompatible profiles.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (a04fe3451877e2ff0) with the app lane
Design status
NOT RUN
Plan pages
R1
INT-14Protected helper and per-device leases restore owned settings on normal/abnormal exit; real ACL/security tests.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-14 of the master edition (R1 / Additional regression gates).

Steps

  1. Protected helper and per-device leases restore owned settings on normal/abnormal exit; real ACL/security tests.

Accept

Protected helper and per-device leases restore owned settings on normal/abnormal exit; real ACL/security tests.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ember lane (a04fe3451877e2ff0) with the app lane
Design status
NOT RUN
Plan pages
R1
INT-15Public PoP replay is not session authorization; payout/server/network binding enforced.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 00:47 UK

Setup

Integration gate INT-15 of the master edition (R1 / Additional regression gates).

Steps

  1. Public PoP replay is not session authorization; payout/server/network binding enforced.

Accept

Public PoP replay is not session authorization; payout/server/network binding enforced.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (a1c484c48a62948c2)
Run
pool-int-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-16Pool parsing/queues/connection and crypto budgets remain bounded under controlled adversarial traffic.Priority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 00:47 UK

Setup

Integration gate INT-16 of the master edition (R1 / Additional regression gates).

Steps

  1. Pool parsing/queues/connection and crypto budgets remain bounded under controlled adversarial traffic.

Accept

Pool parsing/queues/connection and crypto budgets remain bounded under controlled adversarial traffic.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
pool lane (a1c484c48a62948c2)
Run
pool-int-20261009-01
Design status
NOT RUN
Plan pages
R1
INT-17Missing oracle/keys/mandatory real-proof fixture blocks the applicable production acceptance gate.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-17 of the master edition (R1 / Additional regression gates).

Steps

  1. Missing oracle/keys/mandatory real-proof fixture blocks the applicable production acceptance gate.

Accept

Missing oracle/keys/mandatory real-proof fixture blocks the applicable production acceptance gate.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
proving lane (a6e8f84588b809d62)
Design status
NOT RUN
Plan pages
R1
INT-18Whole-system economics pass the strongest feasible adversary, including sunk development and multi-epoch survival.Priority P0Profile P00NOT RUNEvidence none yetLast run 8 Oct 2026, 21:10 UK

Setup

Integration gate INT-18 of the master edition (R1 / Additional regression gates).

Steps

  1. Whole-system economics pass the strongest feasible adversary, including sunk development and multi-epoch survival.

Accept

Whole-system economics pass the strongest feasible adversary, including sunk development and multi-epoch survival.

Evidence the case requires

The run record of the gate as its owner lane records it through tools/ci/test-record.mjs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
research lane (ad6a2bd47d4a46105)
Design status
NOT RUN
Plan pages
R1
19VR

VR: the token value and network leadership rules (normative, proposed, requiring ratification)

40 normative rules from Igneum 2.0, Token Value & Network Leadership 1.0-proposed (snapshot 2026-10-08); Supplement to original master and 128-case test standard; not a price/rank guarantee

NOT RUN
Owner
founder (ratification); the owner role per rule
Gate
Ratification by the founder and each rule's owner role
Fixtures
F0
Plan pages
docs/plans/igneum-2.0-master/token-value/rules-and-gates.json rules
40 cases: 0 passed under the standard, 0 running with team evidence, 40 not run, 0 deferred
VR-01One monetary contractPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Ratify one maximum-supply, subsidy and change-policy contract. No unexplained tail escape, automatic emergency mint or price-triggered issuance.

Accept

Ratify one maximum-supply, subsidy and change-policy contract. No unexplained tail escape, automatic emergency mint or price-triggered issuance.

Evidence the case requires

D01 decision, normative spec, executable supply tests and consistent public text.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + governance
Plan pages
TV
VR-02Independent supply accountingPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Make circulating, issued, burned, locked and maximum supply independently reproducible. Count bridges and wrappers without creating fictitious native supply.

Accept

Make circulating, issued, burned, locked and maximum supply independently reproducible. Count bridges and wrappers without creating fictitious native supply.

Evidence the case requires

Two independent supply calculations with exact integer reconciliation.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + measurement
Plan pages
TV
VR-03Equal opportunity at launchPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. No premine or privileged devnet conversion under the stated fair-launch policy. Publish efficient software and launch conditions before activation.

Accept

No premine or privileged devnet conversion under the stated fair-launch policy. Publish efficient software and launch conditions before activation.

Evidence the case requires

Genesis audit, launch rehearsal, insider disclosures and public release history.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Release + ecosystem
Plan pages
TV
VR-04No artificial return promisePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Do not advertise guaranteed appreciation, passive returns without necessary work, a redemption floor or electricity-backed value.

Accept

Do not advertise guaranteed appreciation, passive returns without necessary work, a redemption floor or electricity-backed value.

Evidence the case requires

Product terms, source of rewards and public-claim review.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Governance + counsel
Plan pages
TV
VR-05Fund necessary securityPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Model miners, internal provers, minimum validators and maintenance separately through declining issuance. No assumption that an external sale automatically funds all roles.

Accept

Model miners, internal provers, minimum validators and maintenance separately through declining issuance. No assumption that an external sale automatically funds all roles.

Evidence the case requires

Role-by-role cash flow, adverse scenarios and committed initial resources.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Economics + protocol
Plan pages
TV
VR-06Honest rule changePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Publish rationale, impact, adoption path and compatibility limits before a material monetary change. Do not pretend software can prevent all future voluntary forks.

Accept

Publish rationale, impact, adoption path and compatibility limits before a material monetary change. Do not pretend software can prevent all future voluntary forks.

Evidence the case requires

Versioned proposals, reviewer comments, adoption and dissent documentation.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + governance
Plan pages
TV
VR-07Transparent fee routingPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Every fee, burn, operator payment and optional Labs charge has an explicit source and recipient. No new team tax hidden in a commercial label.

Accept

Every fee, burn, operator payment and optional Labs charge has an explicit source and recipient. No new team tax hidden in a commercial label.

Evidence the case requires

Executable fee tests and reconciliation to invoices/receipts.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Economics + protocol
Plan pages
TV
VR-08Separate value and money flowsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Distinguish job turnover, fees, operator income, Labs income, token holdings and market value. Do not count the same payment or saving twice.

Accept

Distinguish job turnover, fees, operator income, Labs income, token holdings and market value. Do not count the same payment or saving twice.

Evidence the case requires

Reconciled flow diagram and reproducible metric definitions.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Economics + measurement
Plan pages
TV
VR-09Accessible hardware economicsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Fix the reference cohort and scenarios in advance. Allow the strongest feasible programmable multi-epoch specialist, including sunk development and alternative memory.

Accept

Fix the reference cohort and scenarios in advance. Allow the strongest feasible programmable multi-epoch specialist, including sunk development and alternative memory.

Evidence the case requires

Approved original GPU/ADV/ROT/ECO profiles and independent review.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
GPU + hardware reviewer
Plan pages
TV
VR-10Mandatory correct proofsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. All activated proof decisions must bind their actual statement, kind and verifier independent of cache history. Missing trusted infrastructure must not disable enforcement.

Accept

All activated proof decisions must bind their actual statement, kind and verifier independent of cache history. Missing trusted infrastructure must not disable enforcement.

Evidence the case requires

Native warm/cold/order/restart tests and positive/negative proof fixtures.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + proving
Plan pages
TV
VR-11Literal finalityPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Define fault assumptions, authority continuity and recovery. Never present a weaker recovery certificate as the stronger irreversible guarantee.

Accept

Define fault assumptions, authority continuity and recovery. Never present a weaker recovery certificate as the stronger irreversible guarantee.

Evidence the case requires

Native multi-node boundary tests and consumer label checks.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Consensus + security
Plan pages
TV
VR-12Retained operator authorityPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Pooling variance or buying a service does not silently transfer keys, transaction selection or finality/governance control.

Accept

Pooling variance or buying a service does not silently transfer keys, transaction selection or finality/governance control.

Evidence the case requires

Key/template substitution tests and explicit delegation contracts.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + pool
Plan pages
TV
VR-13Safe custody and consentPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Private keys, spending limits, signing displays and recovery choices remain under explicit user authority. Defaults must not conceal broad powers.

Accept

Private keys, spending limits, signing displays and recovery choices remain under explicit user authority. Defaults must not conceal broad powers.

Evidence the case requires

Wallet security review and independent user/recovery exercises.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Wallet + security
Plan pages
TV
VR-14Portable verificationPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Balances and receipts authenticate their roots, successful outcome and trust anchors. Necessary reconstruction data has a documented availability path.

Accept

Balances and receipts authenticate their roots, successful outcome and trust anchors. Necessary reconstruction data has a documented availability path.

Evidence the case requires

Independent receipt/client verification with hostile inputs.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Wallet + protocol
Plan pages
TV
VR-15Price real resourcesPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Bound execution, verification and storage costs. Sponsored transactions have limits. No deliberate congestion solely to increase a token metric.

Accept

Bound execution, verification and storage costs. Sponsored transactions have limits. No deliberate congestion solely to increase a token metric.

Evidence the case requires

Minimum-node tests and fee/sponsor-abuse scenarios.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + economics
Plan pages
TV
VR-16No fragile stable-value promisePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Any stable-value product has explicit issuer, reserve/redemption rights, permissions and risks. No native-backed peg used merely to manufacture demand.

Accept

Any stable-value product has explicit issuer, reserve/redemption rights, permissions and risks. No native-backed peg used merely to manufacture demand.

Evidence the case requires

Independent diligence, risk limits and legal assessment before release.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Application + counsel
Plan pages
TV
VR-17Optional bounded bridgesPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Bridge exposure is separate from core security. No bridge is mandatory for genesis or allowed to redefine base-chain finality after a loss.

Accept

Bridge exposure is separate from core security. No bridge is mandatory for genesis or allowed to redefine base-chain finality after a loss.

Evidence the case requires

External security review, loss limits and failure/isolation tests.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Application + security
Plan pages
TV
VR-18Open work settlementPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Jobs bind program, inputs, result, verifier, deadline and payment. Gateways are replaceable and Labs approval is not required for ordinary work.

Accept

Jobs bind program, inputs, result, verifier, deadline and payment. Gateways are replaceable and Labs approval is not required for ordinary work.

Evidence the case requires

Independent request-to-paid-result test and state reconciliation.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + ecosystem
Plan pages
TV
VR-19Obligation-based service bondsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Deposits secure a specific obligation, not consensus influence. Size and failure conditions must preserve small-operator paths and handle collateral decline.

Accept

Deposits secure a specific obligation, not consensus influence. Size and failure conditions must preserve small-operator paths and handle collateral decline.

Evidence the case requires

Economic and adversarial reservation/default tests.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Economics + application
Plan pages
TV
VR-20Independent developer accessPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Publish complete standards, fixtures and tooling. Grants reward useful maintained deliverables rather than deployments or price effects.

Accept

Publish complete standards, fixtures and tooling. Grants reward useful maintained deliverables rather than deployments or price effects.

Evidence the case requires

Unaffiliated integration and maintenance evidence.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Ecosystem
Plan pages
TV
VR-21Committed maintenancePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Essential maintenance and audits need a funded runway with stress accounting, distinct from hoped-for appreciation or fundraising.

Accept

Essential maintenance and audits need a funded runway with stress accounting, distinct from hoped-for appreciation or fundraising.

Evidence the case requires

At least approved P13 runway, commitments and role costs.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Maintainers + finance
Plan pages
TV
VR-22Founder independencePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Routine block, job, payment and recovery paths must not require a founder credential or undocumented manual action.

Accept

Routine block, job, payment and recovery paths must not require a founder credential or undocumented manual action.

Evidence the case requires

Real founder-absence exercises and intervention ledger.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Operations + independent reviewer
Plan pages
TV
VR-23Measure effective controlPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Report operator, pool, hosting, service and client dependencies with attribution limits. Keys and addresses are not people.

Accept

Report operator, pool, hosting, service and client dependencies with attribution limits. Keys and addresses are not people.

Evidence the case requires

Dependency/control map with uncertainty and removal experiments.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Measurement + operations
Plan pages
TV
VR-24Reproducible secure releasePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Pin source, binaries, rules, guests/keys and activation. Provenance is necessary but not sufficient for correctness.

Accept

Pin source, binaries, rules, guests/keys and activation. Provenance is necessary but not sufficient for correctness.

Evidence the case requires

Independent builds, artifact verification and scoped review.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Release + security
Plan pages
TV
VR-25Consent-preserving incident responsePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Separate public/developer authority. Urgency must not silently override installation or grant arbitrary execution. Disclose material incidents and retest.

Accept

Separate public/developer authority. Urgency must not silently override installation or grant arbitrary execution. Disclose material incidents and retest.

Evidence the case requires

Compromised-key, unsafe-update and recovery drills.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Release + operations
Plan pages
TV
VR-26Honest access and liquidityPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Use functional deposits/withdrawals and executable depth, not ticker count or fabricated volume. Never restrict exit to simulate value.

Accept

Use functional deposits/withdrawals and executable depth, not ticker count or fabricated volume. Never restrict exit to simulate value.

Evidence the case requires

Independent access-route and two-sided liquidity observations.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Ecosystem + measurement
Plan pages
TV
VR-27Transparent treasury relationshipsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Disclose material grants, insider holdings, inventory and market-making mandates. No wash trades or hidden price-support promises.

Accept

Disclose material grants, insider holdings, inventory and market-making mandates. No wash trades or hidden price-support promises.

Evidence the case requires

Mandate register, reconciled accounts and conflict policy.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Treasury + counsel
Plan pages
TV
VR-28Auditable metricsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Publish definitions, raw/adjusted views, sampling, attribution uncertainty and missing data. No subsidy-hidden demand or censored failed jobs.

Accept

Publish definitions, raw/adjusted views, sampling, attribution uncertainty and missing data. No subsidy-hidden demand or censored failed jobs.

Evidence the case requires

Data lineage, conservation checks and independent replay.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Measurement
Plan pages
TV
VR-29Fair comparison universePriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Define eligible peers and exclusions before observing rankings. Include qualifying new entrants and preserve unknown values.

Accept

Define eligible peers and exclusions before observing rankings. Include qualifying new entrants and preserve unknown values.

Evidence the case requires

Independent peer census and versioned comparison protocol.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Measurement + external panel
Plan pages
TV
VR-30Scoped claims onlyPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Every leadership claim names its metric, universe, period and limits. A measured price rank does not certify overall safety or future leadership.

Accept

Every leadership claim names its metric, universe, period and limits. A measured price rank does not certify overall safety or future leadership.

Evidence the case requires

Claim register with evidence, expiry and legal signoff.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Governance + counsel
Plan pages
TV
VR-31Evidence before passPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Pre-register thresholds; missing inputs block gates; corrections preserve failed results. No aggregate score can waive core safety or economic failure.

Accept

Pre-register thresholds; missing inputs block gates; corrections preserve failed results. No aggregate score can waive core safety or economic failure.

Evidence the case requires

Frozen test charter and versioned evidence packets.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Independent acceptance panel
Plan pages
TV
VR-32Real adoptionPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Measure unaffiliated retained users and useful repeat activity with incentives identified. Do not require buying IGN to participate in a study.

Accept

Measure unaffiliated retained users and useful repeat activity with incentives identified. Do not require buying IGN to participate in a study.

Evidence the case requires

Cohort definitions, attrition, usage and subsidy audit.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Product + ecosystem
Plan pages
TV
VR-33AI earns admissionPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. AI is an optional workload category, not a guaranteed-margin network identity. Price full costs and adverse demand before expansion.

Accept

AI is an optional workload category, not a guaranteed-margin network identity. Price full costs and adverse demand before expansion.

Evidence the case requires

Workload-specific benchmark, repeat demand and verification policy.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Compute + economics
Plan pages
TV
VR-34Bound agent spendingPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Automated buyers have scoped budgets, permissions, expiry, revocation and logs. Untrusted prompts never alter base permissions.

Accept

Automated buyers have scoped budgets, permissions, expiry, revocation and logs. Untrusted prompts never alter base permissions.

Evidence the case requires

Prompt/input adversarial tests and payment-loss caps.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Application + security
Plan pages
TV
VR-35Cryptographic migration readinessPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Maintain a full algorithm inventory and reviewed transition plan. No quantum-proof claim from one component or speculative attack date.

Accept

Maintain a full algorithm inventory and reviewed transition plan. No quantum-proof claim from one component or speculative attack date.

Evidence the case requires

Expert review, downgrade/migration tests and annual refresh.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Cryptography + protocol
Plan pages
TV
VR-36Separate proof, truth and privacyPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Execution validity does not establish real-world input truth, AI answer quality or confidentiality. State trust and data exposure for each service.

Accept

Execution validity does not establish real-world input truth, AI answer quality or confidentiality. State trust and data exposure for each service.

Evidence the case requires

Threat model and user-facing guarantee audit.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Security + product
Plan pages
TV
VR-37Scale within verification budgetsPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Throughput, data and state growth must preserve the declared minimum-node and reconstruction capabilities. Reprice security after fee compression.

Accept

Throughput, data and state growth must preserve the declared minimum-node and reconstruction capabilities. Reprice security after fee compression.

Evidence the case requires

Cold-path capacity, bootstrap, pruning and provider-removal tests.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + operations
Plan pages
TV
VR-38Honest energy accountingPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Report complete-system energy and role allocation. Avoid double-counting joint work or making unsupported carbon/marginal-transaction claims.

Accept

Report complete-system energy and role allocation. Avoid double-counting joint work or making unsupported carbon/marginal-transaction claims.

Evidence the case requires

Calibrated wall tests and documented environmental methodology.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
GPU + measurement
Plan pages
TV
VR-39Activity-specific legal approvalPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. Obtain counsel review for actual audiences and activities. No-presale, fair-launch or decentralised labels are not blanket legal exemptions.

Accept

Obtain counsel review for actual audiences and activities. No-presale, fair-launch or decentralised labels are not blanket legal exemptions.

Evidence the case requires

Jurisdiction/activity matrix and approved external communications.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Counsel
Plan pages
TV
VR-40No indispensable administratorPriority P0Profile P00NOT RUNEvidence none yetLast run none yet

Setup

Steps

  1. A useful company, token holder, pool, AI agent or funding body receives no hidden power over balances, issuance or canonical history.

Accept

A useful company, token holder, pool, AI agent or funding body receives no hidden power over balances, issuance or canonical history.

Evidence the case requires

Authority inventory, isolation tests and independent operation.

Method
Ratification
Cadence
Once, at ratification; again on any change of the rule
Owner
Protocol + governance
Plan pages
TV
20TV

TV: the token value and network leadership gates (proposed; no gate executed)

32 gates from Igneum 2.0, Token Value & Network Leadership 1.0-proposed (snapshot 2026-10-08); scope CORE, CAPABILITY IF ENABLED or LEADERSHIP CLAIM as the file gives it; Supplement to original master and 128-case test standard; not a price/rank guarantee

NOT RUN
Owner
the owner role per gate
Gate
Token value gates closed
Fixtures
F0
Plan pages
docs/plans/igneum-2.0-master/token-value/rules-and-gates.json gates
32 cases: 0 passed under the standard, 0 running with team evidence, 32 not run, 0 deferred
TV-01Resolve and freeze the monetary contractPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 10:54 UK

Setup

Supply, tail, fee and recovery documents plus exact proposed release.

Steps

  1. Reconcile D01-D06 with protocol/economic/counsel review. Freeze thresholds and all interfaces before confirmatory tests.

Accept

No conflicting normative policy; every material choice has a signed rationale, version, adoption path and tests. Unresolved core choice is BLOCKED.

Evidence the case requires

Decision log, signed specification, release manifest, test charter.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + independent panel
Run
tv-d02-20261009-03
Plan pages
TV
TV-02Reproduce complete supply accountingPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 10:51 UK

Setup

Two independent implementations; genesis and representative boundary/reorg fixtures.

Steps

  1. Recompute issued, paid, burned, locked and outstanding amounts through subsidy transitions, rollback/replay and duplicate records.

Accept

Exact integer agreement; no unaccounted creation, duplicate supply or cap breach under the ratified policy. Restricted wrappers are not extra native supply.

Evidence the case requires

Machine-readable ledgers, vectors, independent signoff.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + measurement
Run
tv-02-20261009-01
Plan pages
TV
TV-03Fair launch and early distributionPriority P0Profile P00NOT RUNEvidence recordLast run 9 Oct 2026, 10:54 UK

Setup

Public binaries, source, mining modes, launch notice and insider inventory.

Steps

  1. Rehearse from clean outsider machines; audit genesis allocations and devnet balances; simulate arrival times under alternative emission schedules.

Accept

Zero undisclosed allocation or privileged conversion; approved notice/support window and cohort pass; distribution analysis includes delayed entrants without guaranteeing equal ownership.

Evidence the case requires

Genesis report, dated releases, disclosure register, simulation inputs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Release + ecosystem
Run
tv-d02-20261009-03
Plan pages
TV
TV-04Security budget without price rescuePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 10:54 UK

Setup

Ratified reward/fee rules; role costs; horizons 1, 5, 10 and 20 years.

Steps

  1. Model falling issuance, fee volatility and .25x/1x/4x/10x revenue, zero external jobs and -90% price. Separate role receipts and funding.

Accept

Approved viable scenarios fund minimum required roles without hidden issuance or assumed appreciation; failure regions stated. Collapse scenarios need safe behaviour, not universal profit.

Evidence the case requires

Reproducible cash-flow model, assumptions, independent review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Economics + protocol
Run
tv-d02-20261009-03
Plan pages
TV
TV-05Strongest surviving specialistPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Pinned candidate/cohort; cheapest supported physical designs including SRAM/hybrid.

Steps

  1. Apply original ADV/GPU/ECO profiles with multi-epoch survival and development sunk. Reprice alternative state and memory implementations.

Accept

All approved core energy and total-cost bounds pass with uncertainty; no unresolved feasible dominating design. Unknown feasibility blocks the broad claim.

Evidence the case requires

Design files, wall results, sensitivity model, two independent hardware opinions.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Hardware reviewer + economics
Plan pages
TV
TV-06Every fee and payment reconcilesPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Native rules, payer contract and optional Labs/service invoices.

Steps

  1. Execute gas, proof, developer, pool, burn, sponsor and refund paths, including rounding, abort, retry and zero-demand cases.

Accept

No unexplained recipient or double count; statements/invoices match exact contract outcomes. Network turnover never labelled Labs revenue or permanent holding demand.

Evidence the case requires

Flow ledger, fixtures, invoice examples, reviewed public fee table.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Economics + application
Plan pages
TV
TV-07Ownership-critical engineering closurePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Original master findings mapped to current release with genuine proof fixtures.

Steps

  1. Run native cache-order, fail-closed activation, payout crash and finality tests; reproduce fixed cases in independent environments.

Accept

No unresolved critical/high finding or counterexample within the approved guarantee; all applicable original safety gates pass. Reproducing a defect is not closure.

Evidence the case requires

Native outputs, manifests, scoped audit, issue-by-issue closure.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + independent security
Plan pages
TV
TV-08Custody and recovery usabilityPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Declared wallet/hardware combinations; 30 new participants, at least 15 non-miners.

Steps

  1. Perform receive, preview/sign, limit, recovery and revocation tasks with valueless funds; inject wrong network/address and malicious prompts.

Accept

Zero unauthorised transfer or secret disclosure; at least 90% complete the approved safe task without private help. Report confidence limitations and all failures.

Evidence the case requires

Task protocol, anonymised results, security review, recovery vectors.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Wallet + independent users
Plan pages
TV
TV-09Independently verifiable settlementPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Proof/receipt client without Labs RPC; normal and recovery certificates.

Steps

  1. Verify successful/failed transfers, wrong asset/amount, stale roots, fake voter lists, invalid proofs and withheld data.

Accept

All invalid claims refused; valid ordinary transfers verify within approved resource limits; weaker recovery and unavailable data never shown as stronger finality.

Evidence the case requires

Offline fixtures, consumer traces and independent implementation.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Wallet + consensus
Plan pages
TV
TV-10Minimum-node and sponsored-use limitsPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Approved minimum validator and sponsor budgets under final workload.

Steps

  1. Run cold proof verification, expensive invalid inputs, state growth, paymaster drain attempts and overloaded bursts.

Accept

Original capacity/security profiles pass; budgets remain bounded; no proof skipped to catch up and no sponsor can spend outside authorised scope.

Evidence the case requires

Cold-path profiles, stress traces, sponsor negative tests.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + application
Plan pages
TV
TV-11Pooled payments without authority lossPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Independent pool/member clients and durable payment state.

Steps

  1. Inject key/template substitution, reauthorisation, crash/RPC ambiguity, receipt reorg and hostile bounded inputs.

Accept

No duplicate/lost liability or unauthorised authority change; member can verify delegated powers and change pools. Session resource limits hold.

Evidence the case requires

Ledger replay, signed work fixtures and pool removal test.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Pool + independent operators
Plan pages
TV
TV-12Reproducible and consented softwarePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Release manifest, build dependencies, update keys and public installer.

Steps

  1. Two independent parties build/verify; simulate compromised key, stale package, rollback, urgency and missing fixtures.

Accept

No hidden consensus variation or arbitrary default remote control; update-off remains respected; mandatory unavailable fixtures block acceptance.

Evidence the case requires

Attestations, independent hashes, key drill, installer/ACL review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Release + independent security
Plan pages
TV
TV-13Committed maintenance coveragePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Costed roles, commitments and monthly cash dates.

Steps

  1. Audit at least 12 months of approved maintenance coverage; stress IGN-denominated resources and provider withdrawal.

Accept

Original P13 satisfied without counting future appreciation or unsigned pledges; essential functions have funded substitutes and explicit shortfall response.

Evidence the case requires

Contracts/grants or funding proof, stress cash flow, responsibility register.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Maintainers + independent finance
Plan pages
TV
TV-14Founder-absent operating exercisePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Independent builds/operators; founder services, keys and manual help removed.

Steps

  1. Run 30 real days, then satisfy the original 90-day observation programme; cross boundaries, remove major providers and record all interventions.

Accept

Approved original independence/reliability gates pass; no unpublished founder action or privileged override. Simulated long partitions are labelled separately.

Evidence the case requires

Dependency map, availability logs, intervention and payer ledger.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Independent operations panel
Plan pages
TV
TV-15Governance and authority boundariesPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Every control/activation threshold, treasury power and application admin interface.

Steps

  1. Exercise hostile coalitions, absent voters, old clients and compromised non-consensus keys; test refusal and recovery.

Accept

No actor gains undeclared issuance/balance/history authority. Every activation follows the ratified safe procedure; ambiguous threshold or recovery remains BLOCKED.

Evidence the case requires

Authority model, scenarios, native outcomes and independent review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + governance
Plan pages
TV
TV-16Two functional independent access routesPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

At least two unaffiliated custody/exchange/payment routes with disclosed shared infrastructure.

Steps

  1. Complete small controlled deposits, withdrawals, outage and reconciliation tests; identify actual custody and settlement dependencies.

Accept

Both settle correctly; neither is merely a front end to the same indispensable provider. Gaps and jurisdiction limits visible; no listing assumed from a logo.

Evidence the case requires

Settlement records, dependency map and third-party confirmation.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ecosystem + independent reviewer
Plan pages
TV
TV-17Supply-price-liquidity measurementPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Frozen sources, price filters, circulating/free-float definitions and order-size bands.

Steps

  1. Collect 90 real days; independently replay supply and prices; measure both buy/sell execution costs and withdrawal availability.

Accept

At least 95% daily coverage; exact supply reconciliation; no fabricated missing data. Sparse liquidity invalidates broad liquidity claims, not automatically the arithmetic cap.

Evidence the case requires

Raw snapshots, methodology/code, gap ledger, audit.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Measurement steward
Plan pages
TV
TV-18Real versus incentivised demandPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Customer/job/transaction definitions with privacy-respecting attribution and subsidy data.

Steps

  1. Reconcile raw/adjusted activity, self-dealing controls and incentives; test whether circular activity earns more than its irrecoverable cost.

Accept

All subsidies and known related activity separated; useful demand not inferred from gross volume alone; abusive incentive loop closed before scaling rewards.

Evidence the case requires

Accounting model, filter logic, sensitivity and independent replay.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Economics + measurement
Plan pages
TV
TV-19Independent developer adoptionPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Public kit and at least five unaffiliated developers with declared tasks.

Steps

  1. Build useful integrations without private dependencies; have two independent maintainers update the kit; record obstacles and adoption reason.

Accept

All declared core integration paths work; at least five usable integrations and two maintainer reproductions. Empty subsidised deployments do not qualify.

Evidence the case requires

Repos, task traces, user evidence and maintenance records.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Ecosystem + external developers
Plan pages
TV
TV-20Programmable payment acceptancePriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Versioned library, independent application, user/sponsor limits and receipt path.

Steps

  1. Execute simple/conditional/recurring payments, revocations, expiry, failed outcome and duplicate invoice cases.

Accept

No unauthorised spend or double settlement; successful transfer independently evidenced; subjective conditions disclose adjudicator/trust.

Evidence the case requires

Contracts, negative vectors, user task record, security review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Application + wallet
Plan pages
TV
TV-21Useful paid proof demandPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Exact workload and final hardware path; three unrelated buyers and approved COM profile.

Steps

  1. Observe repeat purchases under original P14/P16 conditions, full job outcomes and operator/service costs.

Accept

All applicable COM targets met without hidden reimbursement. Queue expiry not counted as success. A monetary-only scope cannot claim this gate passed by exclusion.

Evidence the case requires

Buyer evidence, cost ledger, all-job traces and independent review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Proving + independent customers
Plan pages
TV
TV-22Replaceable work-market gatewayPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Two independent gateway implementations and job/settlement specification.

Steps

  1. Create jobs, switch providers/gateways, fail one service and deliver the same objective result using public inputs.

Accept

Correct payment/result without Labs approval; no concealed central dispatcher or irreversible dependency. External-chain receipts labelled separately.

Evidence the case requires

Gateway traces, escrow reconciliation, dependency-removal run.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Application + independent operators
Plan pages
TV
TV-23Obligation-based depositsPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Proposed bond/default contract and volatile-collateral scenarios.

Steps

  1. Test reservation abandonment, invalid inputs, network pause, -90% collateral value and malicious claims.

Accept

No consensus influence bought; default reason objective; compensation limits explicit; viable small-operator participation and approved risk bounds.

Evidence the case requires

Adversarial model, state tests, risk/legal review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Economics + security
Plan pages
TV
TV-24AI earns a separate commercial casePriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

One bounded model/job, provider hardware, verification tier and licences.

Steps

  1. Benchmark full delivery vs actual alternatives; test 90% lower unit prices, demand collapse, private-data exposure and substituted models.

Accept

Approved service economics and buyer gates pass; correctness/truth/privacy distinguished. No native price or perpetual yield assumption.

Evidence the case requires

End-to-end costs, repeat demand, licence/threat review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Compute + independent reviewer
Plan pages
TV
TV-25Bounded machine purchasingPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Approved account/paymaster permissions and chosen x402/agent interfaces.

Steps

  1. Inject hostile outputs/prompts, replayed requests, recursive spending, revoked permissions and gateway failure.

Accept

Spend never exceeds authorised destination/time/amount scope; no instruction changes authority. Draft standard support is described accurately.

Evidence the case requires

Property tests, loss-cap proof, revocation/audit logs.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Application + security
Plan pages
TV
TV-26Cryptographic migration readinessPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Complete key/proof/transport/update inventory and external cryptographic review.

Steps

  1. Rehearse versioned signature/proof migration, downgrade/replay, mixed clients, inactive owners and minimum-node overhead.

Accept

No unreviewed assumption or automatic confiscation; migration can be explained and tested. No absolute quantum-proof claim or attack date inferred.

Evidence the case requires

Inventory, expert report, migration vectors, annual schedule.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Cryptography + protocol
Plan pages
TV
TV-27Private data and oracle assurancePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Per-product claims, input trust sources, data-retention and execution model.

Steps

  1. Use forged data, hostile providers, telemetry leakage, unsupported attestation and false-but-correctly-executed AI outputs.

Accept

No claim exceeds tested guarantee; secrets/data protected to stated model; unauthenticated inputs not represented as objective truth.

Evidence the case requires

Threat model, exposure tests, labelled user flows.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Security + product
Plan pages
TV
TV-28Stable assets and bridge isolationPriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Only if enabled: issuer/bridge design, redemption rights, trust anchors and approved value caps.

Steps

  1. Test reserve/redemption failure, stale oracle, invalid/recovery certificates, contract compromise and emergency shutdown.

Accept

No hidden base-chain guarantee or forced reversal of final history; independent audit, conservative exposure and counsel approval.

Evidence the case requires

Risk dossier, scenarios, disclosure, independent tests.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Application + security + counsel
Plan pages
TV
TV-29Growth without inaccessible verificationPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Declared minimum node, projected data growth and alternative scaling design.

Steps

  1. Run cold/worst-case validation, state/pruning/bootstrap, censorship and aggregation withdrawal; model 10x/100x growth and fee compression.

Accept

Original minimum-node/security bounds hold; required data remains obtainable; security funding restated for changed fee routes.

Evidence the case requires

Capacity/availability results and revised economics.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Protocol + operations
Plan pages
TV
TV-30Energy and claims disciplinePriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Calibrated whole-system metering and workload allocation protocol.

Steps

  1. Measure mining, proving, mixed/time-shared operation, setup/recovery and unsuccessful work; review environmental text.

Accept

No double-counted savings; original meter tolerances satisfied; no marginal-energy/carbon claim beyond method.

Evidence the case requires

Raw meter traces, job ledger, method and external review.

Method
Automated + independent review
Cadence
Every release candidate
Owner
GPU + measurement
Plan pages
TV
TV-31Public-claim and activity reviewPriority P0Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Actual jurisdiction, audience, service, token-distribution and promotion plans.

Steps

  1. Counsel assesses applicable routes and reviews each value/rank/return/security assertion against evidence.

Accept

Written activity-specific clearance and approved wording; no future-value assertion in a covered MiCA white paper; no blanket exemption inferred from mining.

Evidence the case requires

Legal decision matrix, claim register, review dates.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Qualified counsel
Plan pages
TV
TV-32Observed leadership, not a roadmap certificatePriority P1Profile P00NOT RUNEvidence none yetLast run 9 Oct 2026, 09:45 UK

Setup

Approved peer universe; all applicable mandatory gates; stable release and 90-day observation.

Steps

  1. Run original P15/P16 comparisons and independently replay scoped rank data. Test changing peer/exclusion assumptions and missing data.

Accept

Contender requires original criteria; market-cap first requires highest 90-day median, 95% coverage; sustained daily-first convention also needs 80% of covered days. Never certify overall best from price alone.

Evidence the case requires

Independent panel report, full methods/data, scope and expiry of claim.

Method
Automated + independent review
Cadence
Every release candidate
Owner
Independent acceptance panel
Plan pages
TV
21R15

R15: the 1.5x Research Programme packages (proposed; every package NOT RUN; the plan claims no pass)

10 packages from IGNEUM, The 1.5x Research Programme (9 October 2026); PROPOSED; every package NOT RUN; the plan claims no pass; the X and B cross-references on each package are the research-landing hand's reading of the plan against the brief's matrix and track B, for the coordinator to confirm; the lanes block names the owner lanes as the coordinator named them on 9 October

NOT RUN
Owner
the X and B lanes per package; the coordinator confirms the cross-references
Gate
1.5x programme packages closed
Fixtures
F0
Plan pages
docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json (igneum-1p5x-research-plan.md, section 10 'Proposed execution packages' (the table whose rows begin '| R15-'))
10 cases: 0 passed under the standard, 0 running with team evidence, 10 not run, 0 deferred
R15-01R15-01: Release + measurementPriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 12:45 UK

Setup

Package R15-01 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Latest exact pack, physical assumptions, source manifest, current ratio reconciliation

Steps

  1. The lane(s) X0 produce the required artefact; the package's gate is read against it by the independent review.

Accept

No cross-version mixed baseline

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
X0
Run
lab-20261009-01
Plan pages
R15
R15-02R15-02: GPU + hardwarePriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 11:06 UK

Setup

Package R15-02 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Component power/traffic model and sensitivity analysis

Steps

  1. The lane(s) X0, X5 produce the required artefact; the package's gate is read against it by the independent review.

Accept

No device/whole-machine boundary mismatch

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
X0, X5
Run
r15-02-x7-20261009-01
Plan pages
R15
R15-03R15-03: GPU + memory analysisPriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 11:06 UK

Setup

Package R15-03 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Layer-8-off control and held-out cache curves

Steps

  1. The lane(s) X1 produce the required artefact; the package's gate is read against it by the independent review.

Accept

Distinct benefit after best cache adaptation

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
X1
Run
r15-int8-20261009-01
Plan pages
R15
R15-04R15-04: GPU systemsPriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 11:23 UK

Setup

Package R15-04 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Compaction, exact-fold alternatives and tuning results

Steps

  1. The lane(s) X2, X3, X4 produce the required artefact; the package's gate is read against it by the independent review.

Accept

Byte agreement, real accepted-work savings

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
X2, X3, X4
Run
1p5x-x4-20261009
Plan pages
R15
R15-05R15-05: CryptographyPriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 11:06 UK

Setup

Package R15-05 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Exact published MHPoW control, theorem audit, malicious fixtures

Steps

  1. The lane(s) B1 produce the required artefact; the package's gate is read against it by the independent review.

Accept

No improvised sampled-memory soundness

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
B1
Run
r15-track-b-20261009-02
Plan pages
R15
R15-06R15-06: GPU + cryptographyPriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 10:19 UK

Setup

Package R15-06 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Theorem-preserving layout/parallelisation feasibility

Steps

  1. The lane(s) B3 produce the required artefact; the package's gate is read against it by the independent review.

Accept

GPU competitiveness and cheap-enough verification

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
B3
Plan pages
R15
R15-07R15-07: Cryptography + hardwarePriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 11:28 UK

Setup

Package R15-07 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Joint accepted-proof resource frontier with concrete constants

Steps

  1. The lane(s) B2, B4 produce the required artefact; the package's gate is read against it by the independent review.

Accept

No invalid theorem composition

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
B2, B4
Run
mhpow-b4-20261009-02
Plan pages
R15
R15-08R15-08: Independent ASIC teamPriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 12:45 UK

Setup

Package R15-08 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Re-optimised SRAM/DRAM/hybrid/recompute/PIM scenarios

Steps

  1. The lane(s) X5, B5 produce the required artefact; the package's gate is read against it by the independent review.

Accept

Full-storage adversary not excluded by price

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
X5, B5
Run
lab-20261009-01
Plan pages
R15
R15-09R15-09: Measurement + economicsPriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 12:45 UK

Setup

Package R15-09 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Blind cohort confirmation and separate P12 outcomes

Steps

  1. The lane(s) X6 produce the required artefact; the package's gate is read against it by the independent review.

Accept

Strongest credible ratio, not average

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
X6
Run
lab-20261009-01
Plan pages
R15
R15-10R15-10: Protocol/securityPriority P0Profile P04NOT RUNEvidence none yetLast run 9 Oct 2026, 10:19 UK

Setup

Package R15-10 of the 1.5x Research Programme (docs/plans/igneum-2.0-master/1p5x/research-plan/packages.json); the required artefact: Network and pool integration, no-rescue exercise, public evidence

Steps

  1. The lane(s) B6 produce the required artefact; the package's gate is read against it by the independent review.

Accept

Correctness and safe operation remain intact

Evidence the case requires

The run record of the package's lane(s) as recorded through tools/ci/test-record.mjs; every chip figure labelled WITNESS or BOUND; no raw hashes-per-second comparison without an approved equivalence.

Method
Automated + independent review
Cadence
Once per programme round
Owner
B6
Plan pages
R15
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 148 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 24 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.

Rules in force

  • P03: a candidate change pays at most 5 percent of joules per accepted work and loses at most 2 percent of accepted throughput against the paired tuned baseline (replaces the 10 percent budget from 18:2x UK)
  • P04: R_E at most 1.5 for every competitive-core cell at the same node and one node ahead against the lowest credible complete-system specialist; today's placed bracket (1.5x to 2.1x same-node) is a FAIL to work against and is served as such
  • P12: the matched-tariff median at most 1.5, p90 at most 1.75, no core cell above 2.0
  • P02: twelve retail configurations, three unaffiliated operators, the seven-day soak define D1's reproduction

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.

+ + + + + + + + + + +
+
+
+ +
Network · public test
+

The public test

+

A test, not a launch. Devnet 4, version 2.0.3, coins with no value. Join on your own card, report what breaks, and watch the five gates.

+
+
+
+ +
+ +

The public test

+
+

1. What this is

+

Igneum 2.0 runs on Devnet 4 (network id igneum-devnet-4, chain id 4465), software version 2.0.3. The public test is an open invitation to run that software on your own card, on your own machine, and report what happens. It is a test. Coins on this network have no value, cannot be bought or sold, and the chain may be reset; nothing here is a launch, a sale or an offer.

+

The test opens when the five gates in section 5 read green. From that morning a 30-day clock runs on one question: how many operators the project does not control keep a node and a miner on this chain, and what breaks for them. The project's own fleet is counted separately and is never mixed into that number. The monetary gates of the Token Value volume, counsel's review and the 90-day observation period are not part of this test and are not shortened by it.

+

What the test proves, if it passes: that a stranger can install the software on Windows, macOS, Linux or HiveOS, sync, mine, prove where the card allows it, and ride through the hourly program changes and the weekly epoch cuts without a hand from the project. What it does not prove: that the token has value, that the chain is final in the sense a mainnet needs, or any claim about chips beyond what the resistance page states in its own words.

+
+

2. Join, per platform

+

Every download comes from this domain only (/download); check the sha256 the page shows. One install carries the node, the miner and, where the card allows it, the prover.

+
PlatformWhat to installWhat you needNotes
Windows 10 or 11the installer from /download#windowsan NVIDIA, AMD or Intel card with 4 GB or more; 32 GB of memory for a fresh sync this cutSmartScreen shows "Windows protected your PC" on an unsigned build: More info, Run anyway. The installer's one administrator prompt turns on the Windows Subsystem for Linux for the proof verifier; the app installs the rest itself. On a machine under 32 GB the app does not start a fresh sync and says so; the snapshot sync of 2.0.3.1 is that machine's route.
macOS, Apple siliconthe disk image from /download#macan M-series Mac; 16 GB worksOn first open macOS says it cannot verify the app: System Settings, Privacy and Security, Open Anyway. A 16 GB Mac completes a fresh sync in about an hour on swap and feels slow until the node reads synced; this holds until 2.0.3.1.
Linuxthe tarball from /download#linuxan NVIDIA or AMD card; 64 GB of memory for a fresh sync from genesis todayThe flight sheet on the download page. The number falls when snapshot sync ships.
HiveOSthe package from /download#hivea rig with NVIDIA cardsThe package waits for the node to sync before it mines. HiveOS mines only in 2.0.3; its prover entry is being cut.
+

The memory note, plainly: a fresh sync from genesis needs 64 GB of memory on Linux and Windows today, because the node holds the chain's execution state in memory as it replays it; a 16 GB Mac syncs on swap; the snapshot sync of 2.0.3.1 brings a 16 GB machine in without the replay, and this page says so when it ships. A 2.0.3 install dials five targets by default: the three hubs and the two public nodes on the build host; a node that cannot reach any of them says so in its log.

+

What your card does once it is in: any 4 GB card mines; an NVIDIA card of 24 GB or more proves the shard beside its miner by default; a 16 GB card holds no shard. The rates the project measured per card are on /miner#card and the bench table on /miners; your own rows are welcome (section 3).

+
+

3. What to report, and where

+

The Discord is the one place: discord.gg/igneum. Read #start-here and #rules first (three rules). Then:

+
What happenedWhereWhat to include
The install or the app will not start, sync or mine on Windows#support-windowsthe app version (the window's About), the card and driver, the Windows version, the line the app shows, the log the Logs button opens
The same on a Mac#support-macthe app version, the Mac model, the macOS version, the line the app shows, the log
The same on Linux or HiveOS#support-linux-hiveosthe package version, the card and driver, the flight sheet or command, the last 50 lines of the log
Your card's rate and watts#benchmarksone row: card, driver, OS, app version, MH/s, W, the command or the app's setting; the bench table is built from rows like these
Your first block#first-blockthe bot posts it; reply under it with your card if you like
Mining talk, settings, what your card is doing#miningsay the card, the OS and the app version
A node you run without mining#node-runnersthe version, how it dials, what it sees
Proving on a 24 GB card#provingthe card, what the app shows under proven, the shard times
Something that looks like a chain fault: a fork, a stall, a reset you did not expect#devnetthe time (UTC), your node's height and tip, the lines around it; the project's incident posts are in #incidents
A criticism of the design or a claim on this site#ledgerthe claim as served, what you think is wrong, your source; it gets a ledger id and a dated answer on /ledger
+

The hourly numbers from the public API post to #network-feed (height, hash rate, keys, the last lock). An incident is posted in #incidents when it opens and when it resolves, with the cause and the fix. Nothing you report is private; say nothing you would not say in public.

+
+

4. The rules of the test

+
  • The software updates itself when you let it at install; a test on an old version is still a report, say the version.
  • Every machine mines solo on its own keys; there is no pool during the test. Outside pools are listed on #pools only with a signed statement.
  • The project's fleet, the hubs and the build host's nodes are the project's and are counted apart from independent operators.
  • A fault with a software fix is fixed and shipped; it is not held for a word. The incident post names the fix and its version.
  • The project does not touch your machine. There is no remote execution in the public build.
+
+

5. The five gates, with their state

+

The test opens the morning after all five read green. The state column is read from the project's record by the site lane; the time it was read is on the row.

+
GateWhat green meansState at 13:3x UK, 9 October 2026
1. 2.0.3 on the hubs and the fleetthe three hubs and the project's fleet run node 27f54124 on one chainin progress: the hub canary passed its sync; the hubs move one at a time on its pass; the fleet rolls after
2. A 16 GB machine joins by snapshot synca fresh install on a 16 GB machine reaches the tip without the full replaynot yet: the snapshot-sync branch (2.0.3.1) is green on six test suites; the first served snapshot and the 16 GB canary are due this afternoon
3. Mac, Windows and HiveOS 2.0.3 entries on their canarieseach package installs, syncs, mines and updates itself on a machine the project does not hand-holdMac: canary passed (the reboot leg not run, held by the founder); HiveOS: canary in its last blocks; Windows: being cut; the entries publish on the hubs' line
4. One tip held through two epoch cuts after the rollevery public node on one chain across two weekly cuts with no restart by handnot yet: counted after gate 1
5. The served claims in the approved wording, both conventions/resistance serves the approved wording verbatim, the measured card rows, both conventions, the coexistence table and the two phases with their labelsgreen at this landing
+

When all five read green the state column changes here, the announcement goes to #announcements and the 30-day clock starts; the start date is written on this row when it happens.

+
+

Generated from docs/public-test/README.md in the repository at build time. Times are UTC.

+
+
+ + + + + + + + \ No newline at end of file diff --git a/site/randomx.html b/site/randomx.html index c3302c682..456b81cb6 100644 --- a/site/randomx.html +++ b/site/randomx.html @@ -119,7 +119,7 @@ @@ -161,7 +161,7 @@ @@ -294,9 +294,9 @@ diff --git a/site/receipt.html b/site/receipt.html index f7c965d2c..4a65a9c33 100644 --- a/site/receipt.html +++ b/site/receipt.html @@ -125,7 +125,7 @@ @@ -167,7 +167,7 @@ @@ -329,9 +329,9 @@ diff --git a/site/resistance.html b/site/resistance.html new file mode 100644 index 000000000..47b613899 --- /dev/null +++ b/site/resistance.html @@ -0,0 +1,382 @@ + + + + + +Chip resistance, as measured: the claim, the card rows, both conventions, the coexistence table + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ +
Learn · the claim
+

Chip resistance, as measured

+

The claim in the record’s words and nothing stronger. Every figure names its adversary, its column, its clock state, its card, its set and its file.

+
+
+
+ +
+ +

Chip resistance, as measured

+

This page serves the chip claim in the words the record supports and nothing stronger. Every figure below names its adversary, its column (energy, capital, cost ratio), its clock state (knee or stock), the card, the adversarial set version and the file it comes from. The GPU side is measured. Every chip figure is a WITNESS: a design that was priced and found to cost at least that much less, never a ceiling on what a better design could do. Nothing here is a pass against a target. Where a row has not run it says so.

+

The record lives in the repository under docs/analysis/class-v6/1p5x/ (the laboratory interface lab/README.md, the scoreboard lab/table.md, the adversary lane's rows under lab/adv/). The paths on this page name the files on the repository's master at commit 688a89706 (9 October 2026, 12:5x UK); rows still on the adversary lane's branch are named with their branch and commit. The public git host serves a path once its copy of master carries it.

+
+

1. The claim

+

The current model finds that existing GPU electricity costs are below the assessed DRAM-board specialist's all-in costs at the tested tariffs and stated lifetime assumptions. This supports a conditional entry-deterrence result. It does not yet establish post-deployment competitiveness, viable GPU replacement or new entry, or coexistence against the modelled SRAM fleet at sufficient scale. Those outcomes remain separately assessed.

+

That is the approved wording (lab/README.md section 8c, item 9). The sentence the rows support today, in plain words: a DRAM-board chip can be built, and it does not undercut a card its owner already has at the three tested electricity tariffs; the chip that stores the whole dataset on its die is the residual, held by its project cost and the growth schedule, and it is examined below with its break-even fleet. The position line of the Token Value volume stands beside it: Igneum is designed to compete for leadership among GPU-first networks; what has been demonstrated is named on this page, nothing more.

+

Labels used on this page: MEASURED (a card on a pod or rig, board power read from the driver), WITNESS (a chip design priced as a complete machine; at least this advantage exists), BOUND (a limit no design of the class can beat), MODELLED (an assumption, with its source), PROXY (a stand-in row until the pinned control is measured), PENDING, NOT RUN, BLOCKED and NOT LIVE.

+
+

2. The measured card rows

+

The object is the frozen class v6 signing program at 2^30 dataset words, 4 GiB (the dataset word 1,073,741,823 on every self-test), the public Linux CUDA worker, board power from the driver, stock clocks (every rented container refused a clock lock), the median of three timed runs, the fingerprint equal on every cell. The rows are summarised on the scoreboard's ctl-v6 row (lab/table.md, the cohort cell); the raw rows with their checksums sit on the build host under the lab's artefact tree, named by pod.

+
CardPodRateBoard powerEnergy per hashStateNote
RTX 5090rented pod 5500648168.66 MH/s384 W5,597 nJstock, 4 GiBthe host's 500 W cap not reached; memory share f 0.81
RTX 5090rented pod 5500647868.64 MH/s400 W5,828 nJstock, 4 GiBpower-capped host (400 of 600 W)
RTX 5090, the project's own cardthe record4,011 nJat its 1,300 MHz kneethe one knee row, from the X0 reconciliation (x0/README.md section 5b)
RTX 5080rented pod 5500652135.03 MH/s189 W5,410 nJstock, 4 GiBclean (189 of a 330 W cap); f 0.81
RTX 4090rented pod 5500652630.69 MH/s269 W8,751 nJstock, 4 GiBuncapped; f 0.86; the worst cohort cell
RTX 3090rented pod 5500650530.80 MH/s260 W8,429 nJstock, 4 GiBpower-capped host (260 of 350 W): reads "at least 8,429"
RTX 3090rented pod 5500655230.90 MH/s220 W7,109 nJstock, 4 GiBpower-capped host (220 of 420 W)
+

What the rows mean for an owner: at stock a 5090 spends about 5.6 microjoules on every hash, a 4090 about 8.8; the card's memory path takes 81 to 86 percent of that energy on the uncapped cells (the read-only twin kernel at the same rate; x7/README.md), which is why no rewrite of the arithmetic moves the ratio much.

+

Not measured, said plainly: AMD (RX 7600 to 9070) and Intel Arc tiers NOT RUN (no rented card on either provider on 9 October; the project's own rigs unreachable by software that day; retried hourly). Wall power BLOCKED on every rented pod (no meter): board power only, the idle watts beside each row. Clock locks refused by every rented container, so the only knee row is the project's own 5090.

+
+

3. The same-node DRAM board, under our convention

+

Our convention: the cheapest programmable core a specialist would build, priced as a complete machine (its own GDDR7 board, controller, host share, power train and cooling), on the same process node as the card and one node ahead, with every instruction counted the way the chip executes it (the instruction convention; a counted-op row is never served alone). Adversarial set v2, the adversary lane's routed fused-ARX lanes on ASAP7 (lab/adv/README.md, branch class-v6-adversary at commit 545f3f8a0); the figures as summarised on the scoreboard's ctl-v6 adversary cell.

+
ComparisonCard rowRatio, chip energy edgeBandLabel
The same-node DRAM board at the 5090 knee4,011 nJ (the record)2.60x2.06x to 3.02xWITNESS, set v2
The node-ahead DRAM board at the 5090 knee4,011 nJ2.70xWITNESS, set v2
The same-node DRAM board at the worst cohort cell: RTX 4090 at stock, pod 550065268,751 nJ5.67x4.49x to 6.59xWITNESS, set v2
The node-ahead board at that cell8,751 nJ5.89xWITNESS, set v2
The same-node board at the RTX 3090 at stock, pod 55006505at least 8,429 nJ5.46x4.33x to 6.35xWITNESS, set v2; the card capped
The same-node board at the RTX 5090 at stock, pod 550064815,597 nJ3.63xWITNESS, set v2
The same-node board at the RTX 5080 at stock, pod 550065215,410 nJ3.51xWITNESS, set v2
+

The board's energy at the knee, split: the chip 527 nJ memory, 167 nJ arithmetic, 849 nJ fixed-function tax (1,543 nJ in all, band 1,328 to 1,947) against the card's 3,642 memory, 369 arithmetic, no tax. The tax ladder states what the chip's own overhead is worth: 2.60x with the record's static tax, 3.28x at half of it, 4.43x at none (the BOUND for this design).

+
+

4. Both conventions, side by side

+

Two conventions exist for the same question and give different numbers. Ours is above: the cheapest programmable core, complete machine. ProgPoW's premise is that a chip must keep a GPU-class datapath to run the work, so its edge is what it saves by leaving out the parts of a GPU it does not need; the published ProgPoW estimate under that premise is 1.1x to 1.2x. Every served ratio carries both.

+
ObjectUnder our convention (same node, complete machine)Under ProgPoW's premiseCard rowState
Frozen class v6 (this network's work)the DRAM board 2.60x at the 5090 knee (2.06x to 3.02x); 5.67x at the worst cohort cell1.01x to 1.02x (the card's memory share f 0.908 on that row)MEASURED (section 2)WITNESS, set v2; lab/adv/README.md section 2
KAWPOW and FiroPoW (ProgPoW 0.9.x)the DRAM board 4.24x on set v2 (4.29x, 3.50x to 5.22x, on set v1) against the 4090 at stock; the cheapest design for this object is near-memory compute in HBM base dies, 13.2x1.10x to 1.20x (the published estimate; f unmeasured)the comparative lane's rented 4090 at stock, 6,920 nJ per hash, the KAWPOW census as the op-count proxyPROXY; the pinned ProgPoW 0.9.4 control is PENDING (its pin staged on the build host, no cohort row measured yet)
FishHashadversary rows only: the DRAM board 1,044 nJ per hash (872 to 1,251), three N2 dies 162 nJ; no card row, so no ratio is served1.10x to 1.20x (the ProgPoW-family premise)NOT RUNPENDING; the pinned control's cohort row is owed
+

The two conventions do not disagree about the hardware; they disagree about what the specialist is allowed to build. Under ProgPoW's premise this network's work reads about 1.0x because the card is already spending nearly all of its energy on memory it cannot avoid; under ours the same card loses 2.6x at its knee to a chip with its own memory board, because a GPU's random-read path costs 4x to 13x what a chip's does per read (x7/README.md). The ProgPoW 0.9.4 and FishHash rows change from PROXY and PENDING to measured when the laboratory posts the pinned controls' cohort rows.

+
+

5. The coexistence table

+

Energy alone does not say who mines. The coexistence table prices the chip as a machine against a GPU owner who already has the card (its capital sunk), at the three tested tariffs. Source: the adversary lane's coexistence rows and price sheet (lab/adv/README.md sections 6 and 7, commit 545f3f8a0), as summarised on the scoreboard's ctl-v6 coexistence cell. Assumptions, all MODELLED and stated on the rows: a 100,000-machine fleet, a 24-month straight-line life, a design cost of USD 35 M for the board chip and USD 300 M for the reticle die (both claimed brackets taken at a point), the card sunk at USD 30.6 per MH/s on class v6 at the knee, GDDR7 at USD 20 per 2 GB device (September 2026), the core at USD 0.36 per mm2 of N5, the three tested tariffs USD 0.05, 0.10 and 0.15 per kWh.

+

The last column is the cost ratio: the chip's all-in cost per terahash over the GPU owner's electricity-only cost per terahash. Above 1.0 the owner's card keeps mining beside the chip; below 1.0 the owner's electricity alone exceeds the chip's whole bill.

+
Adversary (frozen class v6, the 5090 knee)Energy edgeChip capital, USD per MH/sCost ratio at USD 0.05 / 0.10 / 0.15 per kWhThe two curves meet atBreak-even fleet at USD 0.10
The same-node DRAM board2.60x14.04 (die 0.34, memory 5.42, board 3.15, design 5.13)4.4x / 2.4x / 1.7xabout USD 0.32 per kWhnone: the GPU's electricity-only cost is USD 0.056 / 0.111 / 0.167 per TH against the chip's all-in 0.244 / 0.265 / 0.287; memory and board capital alone exceed the GPU's electricity at any fleet in the record, and the device price would have to fall to about USD 7.5 with a 1,000,000-board fleet before the first break-even
The stored-half hybrid (the hottest half of the dataset in SRAM beside the board)3.80x9.172.9x / 1.6x / 1.1xabout USD 0.16 per kWhnone stated on the row; holds at all three tested tariffs
The N2 SRAM die (the whole dataset on reticles)11.9x1.590.5x / 0.3x / 0.2xabout USD 0.02 per kWh14,300 dies: above that fleet the GPU owner's electricity exceeds the die's all-in at every tested tariff; 16,700 under the default growth schedule (4 GiB doubling every 24 months), 25,000 doubling every 12
The node-ahead DRAM board2.70x4.4x / 2.4x / 1.7xabout USD 0.32 per kWhnone
+

The itemised phase B bill for the board at ten cents, per terahash: electricity 0.043, capital 0.141, design share 0.081, hosting 0.009, maintenance 0.014; in all USD 0.288 against the GPU owner's 0.111, cost ratio 2.58. The die's bill 0.037, cost ratio 0.34 (lab/adv/README.md section 11).

+

What this table does not say: it compares the chip with a card already owned. It is a conditional entry-deterrence result, nothing more; the phases below say what happens once a chip exists.

+
+

6. The new buyer and the used card

+

A new buyer compares the chip's all-in with a new card's all-in (street price over the same 24 months plus electricity). On the record the new buyer picks the chip on every row and every tier at ten cents: the same-node board costs 0.34x a new 5090 at the knee (street USD 42.7 per MH/s), 0.31x a 5090 at stock, 0.24x a 4090, 0.43x a 5080; the hybrid 0.22x; the die 0.04x. The card price at which a new buyer is indifferent: USD 9.7 per MH/s on the 5090 at the knee, 10.5 on the 5080, 5.4 on the 5090 at stock, 2.6 on the 4090. The one hold is the maker's project share: below about 13,500 boards sold the USD 35 M design cost keeps a new buyer on a new 5090; above it the chip (lab/adv/README.md section 8).

+

The used card does not close that gap: a used 4090 at USD 1,200 or a used 3090 at USD 700 (claimed, October 2026) with 40 percent of the price kept as resale at 24 months, against a chip whose resale is zero after a program-draw change, still loses to the board at ten cents (the 3090: the chip at 0.45x; indifferent at USD 2.0 per MH/s); the fleet at which the maker's design share stops holding the used-card buyer is about 20,000 machines for the 3090 and 16,000 for the 5080. Memory growth closes the new-buyer gap only at about 227 GB of dataset, outside every schedule to month 72.

+

So the honest reading of this section: the installed base holds at the three tested tariffs; a new buyer is held only while the chip maker's fleet is under about 13,500 boards (14,300 dies).

+
+

7. The two phases

+

The fifth review ruled that the coexistence table proves conditional entry deterrence only, and ordered the question split into two phases per adversary (lab/README.md section 8c, items 5 and 11). Rows: lab/adv/README.md section 12, branch class-v6-adversary at commit 36d17b15c, every row WITNESS. Sources on the rows: the 80/20 split of each block's subsidy (80 to the producer, 20 to the proving escrow) from the Token Value volume's D02 record (docs/plans/igneum-2.0-master/token-value/phase0/d02/README.md, sha256 e4292764…) and the node's PROVING_POOL_SHARE_PERCENT; the year-1 subsidy 963,038,999.99 IGN from TV-04; three price paths with their hashrates from the coexistence model (growing: doubling from USD 0.10 at 20 TH/s; flat: USD 0.10 at 6.9 TH/s; falling: halving from USD 0.30 at 1.7 TH/s).

+

Phase A, before investment: can the maker recover its spend? The fleet is added to the chain's hash and earns the mining share of the emission at the path's mean price over 24 months, electricity at ten cents; the spend is the fleet's capital plus the design cost.

+
AdversaryGrowing pathFlat pathFalling path
The same-node DRAM boardrecovers on no fleet from 100 to 100 M machines (at 100,000 boards, 25 percent of the hash: net USD -55 M on USD 59 M of revenue)recovers on no fleet (net -38 M on 77 M at 100,000)recovers at 3,200 to 355,000 boards (10,000 boards take 29 percent of the hash, net +56 M)
The stored-half hybridno fleetno fleetrecovers at 1,300 to 178,000 machines
The N2 SRAM dieno fleet at any size (net -200 M to -650 M at 10,000 to 100,000 dies)no fleetno fleet (net -19 M at 10,000 dies)
+

In words: a maker's spend comes back only where the chain is small and the price high enough for a few thousand boards to take a third of it; on the growing and flat paths of record no maker recovers. This is the row behind "conditional entry deterrence".

+

Phase B, the spend sunk: who exits first? Once the chip exists its maker ignores the sunk capital and compares operating cost alone. On operating cost the board chip beats the GPU owner (its electricity, hosting and maintenance about USD 0.066 per TH against the owner's 0.111), so on hash income alone GPUs exit first as revenue falls or difficulty rises. The sixth review adopted the hardware split as the answer: a GPU earns the mining share plus the proving share of each block, a hash chip the mining share only, since a chip that proves is a GPU.

+
Phase B row (flat path, 6.9 TH/s at USD 0.10; the chip at 10 percent of the hash; all proving on the GPU cohort in proportion to its hash)ValueLabel
Mining revenue, per THUSD 0.354WITNESS
The GPU's proving income at the ratified 20 percent share, per THUSD 0.098WITNESS; NOT LIVE
The board chip's operating advantage over the GPU owner, per THUSD 0.046WITNESS
The hybrid's operating advantageUSD 0.065WITNESS
The die's operating advantageUSD 0.099WITNESS
The proving share at which the board chip's advantage disappears9 percent (the ratified share is 20)WITNESS; NOT LIVE
The share at which the hybrid's disappears13 percentWITNESS; NOT LIVE
The share at which the die's disappears20 percent (the ratified share exactly)WITNESS; NOT LIVE
+

NOT LIVE. The proving rows are modelled on a proving income that the shipped packages do not yet pay out across the cohort. Today the Mac and Windows apps carry the prover, on by default only on an NVIDIA card of 24 GB or more (a 16 GB card holds no shard); the HiveOS package mines only, its prover entry in cut. What exists today is the project's own fleet: its prover stack (the same binaries the HiveOS prover package wraps) proves shards beside its miners on rented 24 GB cards and is paid the proving share by the pool (663 paid segment records to 30 prover keys from genesis to chain block 31,719, read at 11:50 UTC on 9 October 2026 from the node's proving-status and segment-record calls), so the mechanism runs on chain, but in the fleet's stack, not in a shipped package. The label changes to LIVE only on the proving lane's evidence that a shipped package proves beside mining on the cohort and is paid for it, with the record's path and sha on this row; until then phase B is a model of what the rules pay, not a measurement of what an operator's card earns. The stated assumption on every phase B row: all proving stays on the GPU cohort; a chip maker who fields GPUs to prove is a GPU miner with a sidecar.

+
+

8. The residual: the die

+

The chip that stores the whole 4 GiB dataset on N2 reticles is the strongest design the record prices: 11.9x the 5090's energy at the knee (25x at the 3090 cell), USD 1.59 of capital per MH/s, a cost ratio of 0.3x at ten cents. It is not held by energy and it is not held by the dataset's size: no growth schedule stops a 100,000-die fleet paying, and the break-even fleet rises only from 14,300 dies to 16,700 or 25,000 under the schedules (lab/adv/README.md section 9). What holds it is a project: USD 300 M of design and masks (claimed bracket USD 100 M to 500 M) against a chain whose whole mining emission over 24 months is USD 231 M at the growing path's mean price, so in phase A it recovers on no path at any fleet, and in phase B the ratified 20 percent proving share is exactly the share at which its operating advantage disappears. The die stays a live opponent in both phases on every row; where a row calls it implausible, the row names the assumption that fails (the project cost against the emission).

+
+

9. What is still open

+
RowStateOwner
The pinned ProgPoW 0.9.4 control: its own optimised GPU implementation, test vectors, a cohort rowPENDING (the pin staged; no cohort row)the controls and cohort lanes
The FishHash control: the samePENDINGthe controls and cohort lanes
AMD and Intel cohort cells
NOT RUN (no rented card; the project's rigs unreachable by software on the day)the cohort lane, hourly retry
Wall power on the cohortBLOCKED (board power only on rented pods)the cohort lane
The card's random-read headroom against its memory-timing bound and the chip's 148 MH/s on the same memory (the one lever on phase B that costs the chip nothing)openthe cohort and controls lanes
The 4 GiB proving cap defined precisely (which of the mining state, the proof allocation, the verifier requirement or the advertised profile it limits)NOT RUNthe controls and adversary lanes
A comparative review of what other GPU networks publish on chip resistanceNOT RUNunassigned; no comparative sentence is served until it runs
A shipped package that proves beside the miner on the cohort (the phase B label)NOT LIVEthe release and proving lanes
The adversary lane's rows landing on master (today on branch class-v6-adversary)in flightthe adversary lane
+
+

10. How to read a figure here, and how to reproduce one

+

A card figure is board power from the driver over the worker's accepted rate, the median of three timed runs on one pod, the fingerprint checked against the CPU reference; the raw rows carry the pod id, the driver, the power cap state and the dataset words. A chip figure is a placed-and-routed core on a predictive 7 nm-class library scaled on claimed node factors, its memory and machine terms from the price sheet, every assumption on its row; it is a witness of at least that advantage. A ratio is one card figure over one chip figure, named by both. The laboratory's rule, printed here as it is there: nothing on this page claims impossibility, and nothing on it claims inevitability. The reproduction kit for the frozen control (the 4 GiB packs, the read-only twin, the worker and the fixtures) is the lab's founder bundle, available on request through the Discord's #devnet channel until the public git host carries the record.

+
+

Generated from docs/claims/resistance.md in the repository at build time. Times are UTC.

+
+
+ + + + + + + + \ No newline at end of file diff --git a/site/scenes.html b/site/scenes.html index 7fcdaad07..3ff9bcddb 100644 --- a/site/scenes.html +++ b/site/scenes.html @@ -111,7 +111,7 @@ @@ -153,7 +153,7 @@ @@ -296,9 +296,9 @@ diff --git a/site/scorecard.html b/site/scorecard.html index f3403598f..14f11df3c 100644 --- a/site/scorecard.html +++ b/site/scorecard.html @@ -93,7 +93,7 @@ @@ -135,7 +135,7 @@ @@ -271,9 +271,9 @@ diff --git a/site/swap.html b/site/swap.html index 422f8e1a3..dd6f220f4 100644 --- a/site/swap.html +++ b/site/swap.html @@ -130,7 +130,7 @@ dt{color:var(--ash)}dd{margin:0;font-family:var(--f-mono);font-size:13px;overflo @@ -172,7 +172,7 @@ dt{color:var(--ash)}dd{margin:0;font-family:var(--f-mono);font-size:13px;overflo @@ -354,9 +354,9 @@ dt{color:var(--ash)}dd{margin:0;font-family:var(--f-mono);font-size:13px;overflo diff --git a/site/tuning.html b/site/tuning.html index 93f2f4d87..2f2561174 100644 --- a/site/tuning.html +++ b/site/tuning.html @@ -120,7 +120,7 @@ table{min-width:560px} @@ -162,7 +162,7 @@ table{min-width:560px} @@ -314,9 +314,9 @@ table{min-width:560px} diff --git a/site/tx.html b/site/tx.html index 7e5e9d643..c0fb799cd 100644 --- a/site/tx.html +++ b/site/tx.html @@ -147,7 +147,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin @@ -189,7 +189,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin @@ -310,9 +310,9 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin diff --git a/site/wallet.html b/site/wallet.html index 1d800b116..3d67abae6 100644 --- a/site/wallet.html +++ b/site/wallet.html @@ -129,7 +129,7 @@ @@ -171,7 +171,7 @@ @@ -428,9 +428,9 @@ From 25e56c1b9554ba249a144d0470b560faed32c83a Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Fri, 9 Oct 2026 12:17:04 +0000 Subject: [PATCH 04/10] 1.5x lab: the 4090 decider closed, Autolykos2 on set v3, the no-emergency-intervention row (8g) with the finality rule v3 pause as measured behaviour, the lab on watch until the ledger page Documents only; nothing on the devnet touched. Co-Authored-By: Claude Fable 5.1 --- docs/analysis/class-v6/1p5x/lab/README.md | 13 ++++++++++ docs/analysis/class-v6/1p5x/lab/table.md | 19 ++++++++++++++ docs/plans/igneum-2.0-test-registry.json | 30 +++++++++++------------ tools/ci/batches/lab-20261009-01.json | 2 +- 4 files changed, 48 insertions(+), 16 deletions(-) diff --git a/docs/analysis/class-v6/1p5x/lab/README.md b/docs/analysis/class-v6/1p5x/lab/README.md index 2dbf2f707..19da5e2f5 100644 --- a/docs/analysis/class-v6/1p5x/lab/README.md +++ b/docs/analysis/class-v6/1p5x/lab/README.md @@ -396,6 +396,19 @@ README.md at the box master's sha at 15:00, the conventions on the ctl-v6 and ct 32 GB prototype-shard clause is Devnet 1's; on Devnet 4 (fees_v1_activation_daa 0) a 24 GB NVIDIA card proves the v1 shard and aggregates beside its miner now; the 16 GB tier holds no shard. +## 8g. The "no emergency intervention" row (main, 13:1x UK; measured behaviour of record) + +The statement's third clause ("the network does not depend on emergency intervention to survive") is carried on the scoreboard as +a measured row, never an argument: Devnet 4 runs finality rule v3 (the frozen table expiring at lock DAA + 7,200); finality has +been paused since lock 1980; the roll restores signing weight; the first new lock is expected 15:30 to 17:00 UK; through the pause +the chain ran on PoW, nothing certified reversed, and proving was unaffected once the finality gate on provers was lifted. The vote +key is label-derived (no key file; a fresh datadir keeps it). The row flips from "paused, chain on PoW" to "locked" on the hub's +first new lock line; the ledger page cites it with the DAA and the UK time. + +The LAB stays on watch until the ledger page lands (17:30 UK): the scoreboard and table current as COHORT's five-chain session, +ADVERSARY's ledger rows, the proving epoch record (16:00) and the comparative review (15:30) land; make-bundle.sh re-run for the +14:00 edition and at 17:30 with the ledger rows, each edition's path and sha to main. + ## 9. The lane briefs, one line each - CONTROLS: the four controls as rows of the table: `ctl-v6` from the record and re-measured on the cohort; `ctl-progpow-094` diff --git a/docs/analysis/class-v6/1p5x/lab/table.md b/docs/analysis/class-v6/1p5x/lab/table.md index d2c5be04c..4894865f3 100644 --- a/docs/analysis/class-v6/1p5x/lab/table.md +++ b/docs/analysis/class-v6/1p5x/lab/table.md @@ -192,6 +192,25 @@ on Windows and Mac where a 32 GB NVIDIA card is present, NOT LIVE on the 24 GB t - The boxes (the build steward, 13:1x): the lab's ended box runs' pid files removed as stale after each pid's command line was read dead; the steward's defaults on build-4, build-5 and build-6 stand until a lane claims with a live pid file. +- THE 4090 DECIDER (COHORT 13:10, uncapped pod 55012546, 450 W default, driver 570.172.08, worker f5f3846c, 250 x 2^24, three + runs each, one session; build-1:/srv/artefacts/lab/ctl-v6-decider/vast-55012546/): the 4 GiB signing object 31.52 MH/s at + 275.1 W = 8,728.3 nJ per hash, twin 7,398.0, f 0.848, spread 1.06 percent, fp PASS; the same id at 2^28 32.14 MH/s = 8,600.1 + nJ; the research pack 32.15 = 8,448.2; occupancy identical (88 registers, 20 blocks per SM). CLOSED on both denominator cards: + the 4 GiB set costs 2.0 (4090) and 2.9 (5090) percent of rate and 1.5 to 1.8 percent of joules; reads 8.07 G per second at 4 GiB + against 8.23 at 1 GiB; the batch-shape question closed by CONTROLS' own pair (20 x 2^22 and 50 x 2^24 equal to four figures), so + no fix pair exists to measure. The uncapped 4090 ctl-v6 cells: 8,369 / 8,692 / 8,728 / 8,751 nJ over four pods (host spread 4.5 + percent, drivers 570 to 595): the scoreboard's 4090 figure is the median 8,710 with the spread, the worst cell 8,751 = 5.67x. +- Autolykos2 priced on set v3 (ADVERSARY 13:1x, README section 15): the same-node board 198 nJ (172 to 249) = 5.8x on the 4090 at + stock from CONTROLS' 216.2 MH/s at 250 W claimed (MODELLED-from-rate until COHORT's session row); the die on four reticles 46 + nJ (25x); premise 1.01x; phase A no recovery on any path (Ergo's 24-month mining emission about USD 0.6 M); phase B mining only, + the chip's advantage USD 0.024 per TH standing in full. +- SEARCH handed build-9 back (batches 1 and 2 done and exported); its measurements continue on the rented 4090 (x10b 64-load, + alu-520k, the v6x2 pair, batch 2's self-tests); row folders at build-1:/srv/artefacts/lab/rows/lab-search-4090-pod/ with SUMS; + the lane record docs/analysis/class-v6/1p5x/lab/search/README.md on branch lab-search. +- The "no emergency intervention" row (8g): Devnet 4 on finality rule v3, paused since lock 1980, the chain on PoW through the + pause, nothing certified reversed, proving unaffected once the finality gate on provers was lifted; the first new lock expected + 15:30 to 17:00 UK; the vote key label-derived (no key file). + ## Open rows (NOT RUN) | row | owner | clock | diff --git a/docs/plans/igneum-2.0-test-registry.json b/docs/plans/igneum-2.0-test-registry.json index c5c2cf27b..8703bef01 100644 --- a/docs/plans/igneum-2.0-test-registry.json +++ b/docs/plans/igneum-2.0-test-registry.json @@ -20434,7 +20434,7 @@ "plan_status": "NOT RUN", "run_id": "lab-20261009-01", "evidence_path": "docs/analysis/class-v6/1p5x/lab/README.md; docs/analysis/class-v6/1p5x/lab/table.md", - "updated": "2026-10-09T12:15:20.071Z", + "updated": "2026-10-09T12:17:04.434Z", "evidence_record": { "requirement_id": "R15-01", "decision": "NOT RUN", @@ -20455,8 +20455,8 @@ }, "claim_impact": "none", "reviewer": "", - "at": "2026-10-09T12:15:20.071Z", - "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." + "at": "2026-10-09T12:17:04.434Z", + "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. 13:2x UK: the decider closed on the 4090 too (2.0 percent of rate at 4 GiB); Autolykos2 priced on set v3; the finality row (8g: Devnet 4 on rule v3, paused since lock 1980, the chain on PoW, nothing reversed) as the measured behaviour for the statement's third clause. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." }, "evidence_records": { "lab:candidate": { @@ -20479,8 +20479,8 @@ }, "claim_impact": "none", "reviewer": "", - "at": "2026-10-09T12:15:20.071Z", - "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." + "at": "2026-10-09T12:17:04.434Z", + "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. 13:2x UK: the decider closed on the 4090 too (2.0 percent of rate at 4 GiB); Autolykos2 priced on set v3; the finality row (8g: Devnet 4 on rule v3, paused since lock 1980, the chain on PoW, nothing reversed) as the measured behaviour for the statement's third clause. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." } }, "in_progress_since": "2026-10-09T10:48:54.646Z", @@ -21144,7 +21144,7 @@ "plan_status": "NOT RUN", "run_id": "lab-20261009-01", "evidence_path": "docs/analysis/class-v6/1p5x/lab/README.md; docs/analysis/class-v6/1p5x/lab/table.md", - "updated": "2026-10-09T12:15:20.071Z", + "updated": "2026-10-09T12:17:04.434Z", "evidence_record": { "requirement_id": "R15-08", "decision": "NOT RUN", @@ -21165,8 +21165,8 @@ }, "claim_impact": "none", "reviewer": "", - "at": "2026-10-09T12:15:20.071Z", - "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." + "at": "2026-10-09T12:17:04.434Z", + "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. 13:2x UK: the decider closed on the 4090 too (2.0 percent of rate at 4 GiB); Autolykos2 priced on set v3; the finality row (8g: Devnet 4 on rule v3, paused since lock 1980, the chain on PoW, nothing reversed) as the measured behaviour for the statement's third clause. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." }, "evidence_records": { "lab:candidate": { @@ -21189,8 +21189,8 @@ }, "claim_impact": "none", "reviewer": "", - "at": "2026-10-09T12:15:20.071Z", - "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." + "at": "2026-10-09T12:17:04.434Z", + "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. 13:2x UK: the decider closed on the 4090 too (2.0 percent of rate at 4 GiB); Autolykos2 priced on set v3; the finality row (8g: Devnet 4 on rule v3, paused since lock 1980, the chain on PoW, nothing reversed) as the measured behaviour for the statement's third clause. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." } }, "in_progress_since": "2026-10-09T10:48:54.646Z", @@ -21234,7 +21234,7 @@ "plan_status": "NOT RUN", "run_id": "lab-20261009-01", "evidence_path": "docs/analysis/class-v6/1p5x/lab/README.md; docs/analysis/class-v6/1p5x/lab/table.md", - "updated": "2026-10-09T12:15:20.071Z", + "updated": "2026-10-09T12:17:04.434Z", "evidence_record": { "requirement_id": "R15-09", "decision": "NOT RUN", @@ -21255,8 +21255,8 @@ }, "claim_impact": "none", "reviewer": "", - "at": "2026-10-09T12:15:20.071Z", - "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." + "at": "2026-10-09T12:17:04.434Z", + "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. 13:2x UK: the decider closed on the 4090 too (2.0 percent of rate at 4 GiB); Autolykos2 priced on set v3; the finality row (8g: Devnet 4 on rule v3, paused since lock 1980, the chain on PoW, nothing reversed) as the measured behaviour for the statement's third clause. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." }, "evidence_records": { "lab:candidate": { @@ -21279,8 +21279,8 @@ }, "claim_impact": "none", "reviewer": "", - "at": "2026-10-09T12:15:20.071Z", - "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." + "at": "2026-10-09T12:17:04.434Z", + "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. 13:2x UK: the decider closed on the 4090 too (2.0 percent of rate at 4 GiB); Autolykos2 priced on set v3; the finality row (8g: Devnet 4 on rule v3, paused since lock 1980, the chain on PoW, nothing reversed) as the measured behaviour for the statement's third clause. Every row still NOT RUN until read. | The 1.5x adversarial comparison laboratory (the founder's order, 9 October 2026, 11:4x UK): one evaluation for every control and candidate (the measurement recipe with the read-only twin for the memory share, the adversary interface returning the lowest credible specialist energy per design as a complete machine with WITNESS or BOUND labels, the score as the worst comparison over the required cohort same node and one node ahead, the rejection filters F1 to F6, the regression set REG-01 to REG-08 from the 8 and 9 October failures). Every row NOT RUN until the panel reads it; the first measured score (the frozen v6 control on the cohort against adversarial set v1) lands as a later batch under this cell. Amended 11:5x UK: X10, the full-sector fold candidate of the founder's third review, added as cand-x10 with the scoped same-node board claim (the die and node-ahead chips as coexistence rows); the AMD and Intel tiers NOT RUN on every candidate (no rented card; the house rigs unreachable by software) until a card is found." } }, "in_progress_since": "2026-10-09T10:48:54.646Z", diff --git a/tools/ci/batches/lab-20261009-01.json b/tools/ci/batches/lab-20261009-01.json index 75f2f0a59..3ad0e01f0 100644 --- a/tools/ci/batches/lab-20261009-01.json +++ b/tools/ci/batches/lab-20261009-01.json @@ -26,7 +26,7 @@ "in_progress": true, "method": "model", "evidence": "docs/analysis/class-v6/1p5x/lab/README.md; docs/analysis/class-v6/1p5x/lab/table.md", - "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read.", + "note": "The lab's interface and the candidate table at the fan-out: the frozen v6 control carried from the record (the house 5090 at its knee 4,011 nJ per hash, board power; the X0 amendment 5b rows: the DRAM board 2.35x same node WITNESS, the N2 die 7.8x the worst credible), the cohort rows for the 3090, the 5080 and the AMD and Intel tiers NOT RUN, adversarial set v1 pending; the three other controls (ProgPoW 0.9.4 reference, FishHash, the cooperative ARX candidate) NOT RUN with their clocks. No score is the lab's until the cohort and the adversary rows are in; R15-01, R15-08 and R15-09 stay NOT RUN until read. X10 (cand-x10) joins the table NOT RUN with its per-lane assignments and clocks; COHORT's ctl-v6 denominator set is in flight on eight rented pods. 12:1x UK: adversarial set v1 on the table (the frozen v6's same-node board 2.57x, 2.04 to 3.00, the fused tail CLAIMED until the routed lanes land; the die 11.4x as a coexistence row); the coexistence table (interface section 8b) added as the scoreboard's headline; SEARCH's first screen recorded as SCREEN rejections. Still NOT RUN: no cohort score until COHORT's eight rows are read back. 12:2x UK: set v2 (the routed fused-ARX lanes) makes the v6 board 2.60x a WITNESS; the ctl-v6 coexistence table (the board holds at every price; the N2 die pushes the GPU owner out above 14,300 dies at USD 0.10) is the headline; X10 SCREEN with the card modelled (the board 3.00x at 118 loads). Still NOT RUN: the cohort rows in their timed runs. 12:3x UK: the first cohort cells (ctl-v6 at stock on rented 5090, 5080 and 3090 pods: the worst cell the 3090 at 8,429 nJ = 5.46x on set v2's same-node board, PARTIAL, the dataset size under decision after CONTROLS measured the live 4 GiB object at 2.4x the 1 GiB research pack's rate); X10's first measured cell (cand-x10b on the 4090 at stock 3,653 nJ per lane-work = 5.8x on the board; the fold buys nothing); set v3 (routed 64-register and multiply-xor lanes); the fourth to sixth review rulings (8c); the 4 GiB rule (8e). Every row still NOT RUN until read. 12:4x UK: ctl-v6's first full score over the NVIDIA cohort at stock (the worst cell the RTX 4090 uncapped 8,751 nJ = 5.67x on set v2's same-node board; every cell at 4 GiB, the earlier 2.4x reading an instrument artefact, corrected once); the two-phase rows (ADVERSARY 545f3f8a0, 36d17b15c): phase B NOT LIVE until a shipped package proves, the shipping row open; SEARCH's twenty candidates on set v3 none under 1.5x on any cell (SCREEN). Every row still NOT RUN until read. 13:0x UK: the decider closed on both cards (the 4 GiB object costs 2.0 to 2.9 percent of rate against its 1 GiB export; the 2.4x reading withdrawn as a contention fault); the read-headroom row answered (both cards at their activation limit); the uncapped 5090 cell 5,980 nJ = 3.88x on the board; the shipping row's facts by file and line with the Devnet 4 correction (a 24 GB card proves the v1 shard now; the proving row NOT LIVE until the epoch record by 16:00); the 4 GiB cap defined as the mining dataset floor only; the founder's ledger order (8f) applied. Every row still NOT RUN until read. 13:1x UK: CONTROLS' done line (the four controls, Etchash and Autolykos2 staged bit-exact with SUMS); ADVERSARY's cross-chain phase A and B (no chain's emission recovers a board chip; the proving share the one term) and the E9 Pro calibration (1.28x pessimistic); the first founder bundle 985afee6. Every row still NOT RUN until read. 13:2x UK: the decider closed on the 4090 too (2.0 percent of rate at 4 GiB); Autolykos2 priced on set v3; the finality row (8g: Devnet 4 on rule v3, paused since lock 1980, the chain on PoW, nothing reversed) as the measured behaviour for the statement's third clause. Every row still NOT RUN until read.", "claim_impact": "none" } ], From 992ff44f3fcda01bf84f39031b28ef38cf10e361 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Fri, 9 Oct 2026 12:17:31 +0000 Subject: [PATCH 05/10] rule 33: the 27f54124 node canary record, the lp-4090-11 fleet block as it reads (sync to within ten, mining, quit, version PASS; the shard line none: the fleet's provers hold every whole segment in the 900 s window; verdict FAIL by the rule, main's 13:1x ruling rolls the hubs on the node lines), lines under build-1:/srv/canary/27f54124/lp-4090-11/ --- tools/ci/canary/27f54124.json | 104 ++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 tools/ci/canary/27f54124.json diff --git a/tools/ci/canary/27f54124.json b/tools/ci/canary/27f54124.json new file mode 100644 index 000000000..1013b739d --- /dev/null +++ b/tools/ci/canary/27f54124.json @@ -0,0 +1,104 @@ +{ + "sha": "27f54124", + "artefacts": [ + { + "kind": "fleet", + "sha": "27f54124", + "node_sha": "27f54124", + "artefact": { + "url": "build-1:/srv/workers/fleet/27f54124-node-lane.tgz", + "sha256": "19f7950b36310e4633cb70d0c74598328eb3386118abd4fefd2863ce1ff10ce5", + "kind": "fleet", + "note": "the 2.0.3 node kit (igneumd 027bb12aedf1bb9f, igneum-miner 727606c025ffb0d3), the cross-build kit at the x86-64-v3 baseline" + }, + "box": { + "host": "lp-4090-11 (RTX 4090, Ubuntu 24.04, EPYC)", + "isa_line": "cpu flags: no avx512 (avx512f_count=0)" + }, + "datadir": { + "path": "/root/fleet/dn4 (igneum-devnet-4)", + "empty_at_start": true, + "read_back": "build-1:/srv/canary/27f54124/lp-4090-11/01-datadir.txt" + }, + "sync": { + "genesis_height": 0, + "tip_height": 31684, + "dag_blocks": 62670, + "seconds": 1742, + "feed": { + "height": 31677, + "age_s": 11, + "blocks_per_min": 43.0 + }, + "within_ten_of_reference": true, + "read_back": "build-1:/srv/canary/27f54124/lp-4090-11/02-sync.txt" + }, + "mining": { + "minutes": 5, + "refusals": 0, + "accepted_blocks": 79, + "read_back": "build-1:/srv/canary/27f54124/lp-4090-11/03-mining.txt" + }, + "shard": { + "claimed": false, + "proved": false, + "paid_or_queued": "none", + "read_back": "build-1:/srv/canary/27f54124/lp-4090-11/04-shard.txt" + }, + "quit": { + "bounded": true, + "seconds": 6, + "read_back": "build-1:/srv/canary/27f54124/lp-4090-11/05-quit.txt" + }, + "lines_read_back": [ + { + "line": "install", + "evidence": "build-1:/srv/canary/27f54124/lp-4090-11/00-install.txt" + }, + { + "line": "box", + "evidence": "build-1:/srv/canary/27f54124/lp-4090-11/00-box.txt" + }, + { + "line": "datadir", + "evidence": "build-1:/srv/canary/27f54124/lp-4090-11/01-datadir.txt" + }, + { + "line": "sync", + "evidence": "build-1:/srv/canary/27f54124/lp-4090-11/02-sync.txt" + }, + { + "line": "mining", + "evidence": "build-1:/srv/canary/27f54124/lp-4090-11/03-mining.txt" + }, + { + "line": "shard", + "evidence": "build-1:/srv/canary/27f54124/lp-4090-11/04-shard.txt" + }, + { + "line": "quit", + "evidence": "build-1:/srv/canary/27f54124/lp-4090-11/05-quit.txt" + }, + { + "line": "version", + "evidence": "build-1:/srv/canary/27f54124/lp-4090-11/00-version.txt" + }, + { + "line": "tip", + "evidence": "build-1:/srv/canary/27f54124/lp-4090-11/09-tip.txt" + } + ], + "tip": { + "line": "box last accepted line: 2026-10-09 12:09:02.508+00:00 [INFO ] Accepted 3 blocks ...596642ccb12e42f4d7c079030fe8ce7cd0b5a88e1141d8443e9d20cd0d927 | feed height=32110 hash=0x1b018bf93b88f54b age_s=19 blocks_per_min=0.0 | sync line's within_te", + "read_back": "build-1:/srv/canary/27f54124/lp-4090-11/09-tip.txt" + }, + "verdict": "FAIL", + "recorded_at": "2026-10-09T12:17:29Z", + "recorded_by": "windows 2.0.3 lane (fleet canary on the rented GPU fleet)" + } + ], + "verdict": "FAIL", + "recorded_at": "2026-10-09T12:17:31Z", + "recorded_by": "windows 2.0.3 lane", + "note": "the 2.0.3 node line 27f54124: the fleet block from lp-4090-11 (EPYC, no AVX-512, fresh datadir from 10:43:34Z): sync (EVM height 31,684 within ten of the hubs' feed; 62,670 DAG blocks), mining, quit, version PASS; the shard line reads none: no claim in the 900 s window ('no whole segment inside the margin, worklist 598': the fleet's standing provers take every whole segment within seconds; the same reading on the hive canary's run 1; main's 13:1x ruling: the hubs roll on the node lines, the shard mechanics read on lp-4090-43's hive canary), the box's floor-prover links were dangling (preflight_failed, relinked to the served 71bc2438 pair at 11:56Z), and the one claim the box's standing prover made during IBD (11:45:55Z, segment 30488..30495) failed on a cut mismatch, an export taken mid-sync. The node restarted once on the kept datadir at 11:17:54Z to add build-1's two hands as peers (the three hubs gave it one peer); the harness's sync seconds count from that restart; 1 h 25 min wall from the fresh start. Node RSS peaked 6.0 GB against the container's 31 GB cgroup limit (guard idle). The hub evidence (lp-05) is the network watch's line." +} From 3ff1b021141ad03df430517165917263cf9fc2a2 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Fri, 9 Oct 2026 12:18:48 +0000 Subject: [PATCH 06/10] The comparative review of what other GPU chains publish on chip resistance (the 8c.9 row), linked from the claims page Ravencoin, ProgPoW, Iron Fish, Ethereum Classic, Ergo and Firo: each statement verbatim under 15 words with its URL and date read, each chain's convention, and whether a priced or measured attacker row exists in its record (none found on the pages read, with where we looked). It licenses no ranking sentence. Co-Authored-By: Claude Fable 5.1 --- .../1p5x/ledger/comparative-review.md | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 docs/analysis/class-v6/1p5x/ledger/comparative-review.md diff --git a/docs/analysis/class-v6/1p5x/ledger/comparative-review.md b/docs/analysis/class-v6/1p5x/ledger/comparative-review.md new file mode 100644 index 000000000..a74a41585 --- /dev/null +++ b/docs/analysis/class-v6/1p5x/ledger/comparative-review.md @@ -0,0 +1,26 @@ +# Comparative review: what other live GPU chains publish about their own chip resistance (9 October 2026) + +The row the laboratory interface names in section 8c item 9 ("a comparative review of what other chains publish: a row of the table, NOT RUN until done"). Method: the chain's own pages were read on 9 October 2026 (the date-read column); every quotation is verbatim and under 15 words, with its URL; nothing was downloaded or run; a paraphrase is never inside quotation marks. The last column answers one question per chain: does the chain's own record carry a measured or priced attacker row (a chip designed, modelled or measured against the chain's work), and where we looked. This file states what others publish; it serves no ranking sentence. The site's own claim stays the approved wording of the interface, verbatim, and nothing stronger. + +## 1. The rows + +| Chain, algorithm | Their statement, verbatim | Where it sits (URL), date read | Their convention | A measured or priced attacker row in their record | +|---|---|---|---|---| +| Ravencoin, KAWPOW | "ASIC resistant – Uses the KAWPOW hashing algorithm to discourage the development of ASIC hardware" | https://ravencoin.org/about/ (the project page, no date shown), read 9 October 2026 | ProgPoW's premise, inherited: "The KAWPOW algorithm was derived from ProgPOW and ethhash, with modifications" (same page) | None found. Looked at ravencoin.org/about, the Ravencoin repository README (github.com/RavenProject/Ravencoin, no ASIC text) and EIP-1057. A "1.5x" figure for KAWPOW was not found on any Ravencoin page; the number quoted to the project in review is a reviewer's, not Ravencoin's. | +| Ravencoin, KAWPOW (the second sentence) | "limited potential for ASIC efficiency gains compared to consumer grade hardware" | https://ravencoin.org/about/, read 9 October 2026 | as above | as above | +| ProgPoW (the algorithm KAWPOW and FiroPoW derive from; EIP-1057) | "These would result in minimal, roughly 1.1-1.2x, efficiency gains." | https://eips.ethereum.org/EIPS/eip-1057 (section "ProgPoW Algorithm Walkthrough"), read 9 October 2026 | Its premise, in its own words: "can have a customized ASIC created for it with slightly less functionality" (section "Rationale for PoW on Commodity Hardware"); the goal: "have the algorithm's requirements match what is available on commodity GPUs" | None found on the EIP page or the reference README (github.com/ifdefelse/ProgPOW): the 1.1x to 1.2x is a design-walkthrough estimate of what a chip saves by leaving GPU parts out, not a priced design. Version 0.9.4's stated purpose: "patch the condition modifying the input state of the last keccak pass" (the README). | +| Iron Fish, FishHash (FIP-3, 20 December 2023) | "levels the playing field between different mining hardware (ASICS, FPGAs and GPUs)" | https://fips.ironfish.network/fips/fip-3-memory-hard-mining-algorithm (Abstract), read 9 October 2026 | Memory-bound by design: "difference between specialized and widely available hardware is as small as possible" (Specification); the dataset "equals 4608 MBytes" | None found. FIP-3's analysis is static (memory and compute demand); its one ratio is about Ethash's shipped chips: "much more efficient (2-10x) in terms of power consumption" (Rationale). The Trail of Bits audit (https://ironfish.network/learn/blog/2024-05-14-fish-hash-audit, read 9 October 2026) is cryptanalytic: "no practical exploitations were discovered around the memory-hardness requirement"; it prices no chip. | +| Ethereum Classic, ETChash | "there is no such thing as ASIC resistance" | https://ethereumclassic.org/faqs/miners/ (the question "Is Ethereum Classic's mining algorithm ASIC resistant?"), read 9 October 2026 | A shipped-chip observation, not a model: "mine ETCHash 2x to 6x more energy efficiently than GPUs" (same answer) | The only chain of the six with real chips on its work; the 2x to 6x is stated without a source on the page, and the hardware guide names no model: "A range of ASIC miners Ethereum Classic are available" (https://ethereumclassic.org/mining/hardware/, read 9 October 2026). No designed-attacker row; none claimed. | +| Ergo, Autolykos v2 | "fairly launched efficient ASIC-resistant Proof of Work algorithm" | https://docs.ergoplatform.com/mining/autolykos/, read 9 October 2026 | A stored table: "a single table of ~2 GB (initially)"; "designed to be efficient for miners who store the table" | None found on the Autolykos documentation page: no ratio, no priced or measured design. (The project's own comparative lane found no open GPU miner that passes its verifier on today's table, so Ergo is a non-comparable peer under the open-miner rule; recorded, not scored.) | +| Firo, FiroPoW (release post, 1 October 2021) | "designed to be both FPGA and ASIC resistant to even the playing field" | https://firo.org/2021/10/01/firopow-and-instantsend-release.html, read 9 October 2026 | ProgPoW's premise, inherited: "FiroPoW follows ProgPoW's 0.9.4 spec with a small change" (same post) | None found in the release post: no ratio, no priced or measured design; the post states the DAG start ("slightly over 4GB") and the per-block change. | + +## 2. What the rows say together + +- Four of the six (Ravencoin, FishHash, Ergo, Firo) publish a qualitative sentence (resistant, levels the playing field) and no number; two publish a number: ProgPoW's 1.1x to 1.2x (a design estimate under its own premise, inherited by Ravencoin and Firo) and Ethereum Classic's 2x to 6x (shipped chips, no source on the page). +- None of the six carries, on the pages read, a priced or measured attacker design against its own work (a chip designed, placed and costed, or a chip measured). "None found" on every row means: not on the pages named in the row; a page we did not read may exist. +- Two conventions are in play across the field: ProgPoW's premise (a chip keeps a GPU-class datapath; its edge is what it leaves out) and the whole-machine premise (the cheapest programmable core the specialist would build, as a complete machine). Ethereum Classic's figure is neither: it is what shipped chips do. +- This project's own rows, for the record beside them (docs/analysis/class-v6/1p5x/lab/table.md on master; the adversary lane's rows on branch class-v6-adversary): under ProgPoW's premise the frozen class v6 object reads 1.01x to 1.02x; under the whole-machine premise the same-node DRAM board reads 2.60x at the 5090 knee (2.06x to 3.02x, set v2, WITNESS) and 5.67x at the worst cohort cell; KAWPOW and FiroPoW under the whole-machine premise read 4.24x on set v2 against a rented 4090 at stock (the KAWPOW census as the op-count proxy, PROXY until the pinned 0.9.4 control is measured). No chip is measured on any side. + +## 3. What this review does not license + +The fifth review withdrew the sentence that no other GPU chain has such a record written down; this file is the row that was NOT RUN. It establishes only what the named pages say on the date read. It does not establish that no other chain holds a priced attacker row somewhere else, and it does not rank any chain; a ranking sentence needs the laboratory's ruling on this row, not this file. From f0e99a7c1a0df3bf7428ca6e3d7d3947584ac6c2 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Fri, 9 Oct 2026 12:20:45 +0000 Subject: [PATCH 07/10] Site: the rendered pages after the merge of master 2216068a (built on the box) Co-Authored-By: Claude Fable 5.1 --- site/404.html | 12 ++++++------ site/acceptance.html | 16 ++++++++-------- site/address.html | 12 ++++++------ site/app.html | 12 ++++++------ site/audit.html | 12 ++++++------ site/block.html | 12 ++++++------ site/build.html | 12 ++++++------ site/claims.html | 12 ++++++------ site/compatibility.html | 12 ++++++------ site/dev-fee.html | 12 ++++++------ site/docs.html | 12 ++++++------ site/download.html | 3 +++ site/economics.html | 12 ++++++------ site/evidence.html | 14 +++++++------- site/explorer.html | 12 ++++++------ site/faucet.html | 12 ++++++------ site/gpu-ledger.html | 12 ++++++------ site/grants.html | 12 ++++++------ site/income.html | 12 ++++++------ site/index.html | 12 ++++++------ site/ledger.html | 12 ++++++------ site/light.html | 12 ++++++------ site/litepaper.html | 3 +++ site/live.html | 12 ++++++------ site/metamask.html | 12 ++++++------ site/miner.html | 3 +++ site/miners.html | 12 ++++++------ site/oracle.html | 12 ++++++------ site/prize.html | 12 ++++++------ site/provenance.html | 12 ++++++------ site/proving.html | 12 ++++++------ site/public-test.html | 3 +++ site/randomx.html | 12 ++++++------ site/receipt.html | 12 ++++++------ site/resistance.html | 12 +++++++++--- site/scenes.html | 12 ++++++------ site/scorecard.html | 12 ++++++------ site/swap.html | 12 ++++++------ site/tuning.html | 12 ++++++------ site/tx.html | 12 ++++++------ site/wallet.html | 12 ++++++------ 41 files changed, 240 insertions(+), 222 deletions(-) diff --git a/site/404.html b/site/404.html index 898162924..effff435d 100644 --- a/site/404.html +++ b/site/404.html @@ -107,7 +107,7 @@ main{flex:1}
Live devnetThe chain as it grows, one lane per miner. ExplorerLook a block or an address up. - EvidenceEvery claim and how far it is tested. + EvidenceEvery claim and how far it is tested.Public testA test, not a launch: join, report, the five gates. Light walletA balance your browser proves, trusting no node. Payment receiptA receipt any third party re-verifies offline. State oracle on SepoliaBalances on the devnet, read from another chain. @@ -119,7 +119,7 @@ main{flex:1} 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.PrizeA better adversary or a reproduced shortcut, never a confirmation: the terms.AcceptanceThe Test and Acceptance Standard, case by case, as each one passes.Site auditEvery page, what the reset changed and what is open.DocumentsThe plan, the standard, the specifications and the evidence files, by path. LedgerEvery criticism, answered or conceded. - What Igneum does not claimThe limits, stated first. + What Igneum does not claimThe limits, stated first.Chip resistanceThe claim in the record’s words, every figure labelled. GPU network ledgerEvery GPU-mined chain, measured the same way. Igneum vs RandomXWhat was kept and what was rebuilt for GPUs. Built on the shouldersEvery borrowed part, credited. @@ -150,7 +150,7 @@ main{flex:1}