igneum/docs/evidence.md

Igneum facts: every Igneum 2.0 claim, with its status

8 October 2026. The facts page restarts at Igneum 2.0: one row per claim, each traceable to a landed document in this repository, the path in the row. Every number carries its label (measured, modelled, synthesised, designed); nothing is restated from memory.

The six labels

Label	Meaning
designed	A decision in the design document, the plan or the specification. No code carries it, or the code is a stub
implemented	Code exists with test vectors, and the vectors pass. Not run as a measurement of the claim
activated	The code is live on a named chain by its activation height, and a node's own line says so. Not yet a measurement of the claim
tested by the team	The claim was measured or exercised by the project's own people and agents on a named machine, and the result is in a landed document
reproduced externally	Somebody outside the project ran the published command on their own hardware and got the published result
reviewed independently	Somebody outside the project, paid or not, read the code or the rule and published their finding

Five rules for reading the table:

1. Nothing on this chain has been reproduced externally or reviewed independently. Every row's last column says "none yet". Nobody outside the project has run a published command or published a reading of the code yet, so the first four labels are the ceiling today.
2. A status applies to the exact version or document in the row. An audit of one version never covers a newer one; when the version changes, the status falls back until the new version is tested, reproduced or reviewed again.
3. "Tested by the team" on one machine is one machine. The rows say which. Cards the project rents are the project's own measurement, as are the project's own rigs; neither is a reproduction.
4. The labels stay distinct and a claim never moves up a label without the artefact that label names (the table "What would move a row"). The public reference repository exists (the specifications, the igneum-pow crate, the simulators and the test material, at git.igneum.network); the full node, the miner and the proving code open later, so a row that cites them is tested by the team at most until they do.
5. A failure is a fact. An experiment that did not work is a row like any other, labelled by how it was measured, with the document that records it.

Versions in the table: "the release manifest" is site/release-manifest.json, served at /release.json and regenerated at the Igneum 2.0 devnet's first block; "node fork" commits are the node fork's, which is not in this repository's history until the node opens; a document path is this repository's.

The table

#	Claim	Where it is made	Status	Version or commit	Reproducible test	Result, date, machine	Independent verification
1	The Igneum 2.0 devnet (igneum-devnet-4): started fresh on 8 October 2026 from the release cut; chain id 4464; the release manifest (/release.json) carries its commits and is regenerated at its first block	This page; the live page	designed (starting)	the release manifest (/release.json)	docs/plans/igneum-2.0.md (the 2.0 reset: the network restarts as the 2.0 devnet); the row moves to activated when a node's own line shows the first block and the manifest is regenerated from it	8 October 2026: no first block yet (designed); chain id 4464 (designed)	none yet
2	Proof verification is enforced in consensus before the no-rescue exercise (D5's prerequisite). Today the rule is off: every producer verifies proofs off the consensus path, and a block carrying a matching statement without a valid proof is not refused by consensus	docs/plans/igneum-2.0.md D5; this page	implemented (switched off on the devnet)	node fork f8da7515: the switch is proving_consensus_verify_daa in consensus/core/src/config/params.rs (the plan names it verifier_in_consensus and proof_rule_active_from), the rule check_carried_proofs in consensus/src/pipeline/body_processor/body_validation_in_context.rs, the gate proof_rule_applies in consensus/core/src/proving.rs	Read the devnet parameters at that commit: proving_consensus_verify_daa: u64::MAX (never) in the devnet's parameters, which the 2.0 devnet inherits; the pass condition is the switch set to an activation height on the exercise network and a node's line naming it	8 October 2026: read from the node source, not measured; the switch reads never on the devnet (implemented, not activated)	none yet
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)	tested by the team	docs/analysis/class-v6/connected-state.md section 4; docs/design/class-v6-rotating-family.md section 10.0e	The class v5 nvcc harness and the kit worker, both packs on the same card minutes apart, 250 batches of 2^24, nvidia-smi at 1 Hz, vectors PASS on every row (connected-state.md section 4); the per-load rows of the full chain against the base (class-v6-rotating-family.md 10.0e)	8 October 2026, rented RTX 5090 (575 W cap) and RTX 4090 (450 W cap) at stock: energy per hash +0.6 percent on the RTX 5090 and -0.9 percent on the RTX 4090, inside the run-to-run noise; under 1 percent of rate; 80 to 87 registers per thread, no spill (all measured). Per load: RTX 5090 16.7 nJ base, 17.6 nJ full chain; RTX 4090 26.0 nJ, 27.0 nJ (measured). The lock row on the project's own rigs is owed	none yet
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	tested by the team (a published failure)	docs/analysis/class-v6/connected-state.md (the verdict, section 6)	The census, liveness and GPU rows in connected-state.md sections 2 to 4; the chip side priced on the drawn program by synthesis (a model, never a lower bound)	8 October 2026, verdict 17:25 UK: the window is necessary (63 of 64 registers live at every address, measured) but only its width reaches the chip, +1.2 pJ per lane-op at N5 (synthesised); the window moves the chip's edge 1.10x node for node against a 1.25x gate (modelled); the GPU side +0.6 percent energy per hash on the RTX 5090, -0.9 percent on the RTX 4090 at stock (measured). Rearranging the dependency graph of the same operations moves neither side	none yet
5	"A GPU-secured network for Ethereum-compatible applications and verifiable computation." served on every page	Every page	designed (served)	docs/plans/igneum-2.0.md (the objective: the positioning line)	node tools/ci/ledger-text-check.mjs: the sentence pinned (R0) on the home page, the litepaper and this page	8 October 2026: on this page; the home page and the litepaper carry it as their 2.0 text lands (designed)	none yet
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 (the modelled bracket about 2.3x to 3.3x a node ahead and 2.0x to 2.9x node for node, approximate and provisional until the placed gated core rows land), 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 energy ratio is not the pass criterion: the coexistence model (docs/analysis/class-v6/coexistence-model.md) is, and its first run's result is served with its conditions	The litepaper (the chip model)	designed (the bracket modelled; the GPU side tested by the team)	docs/design/class-v6-rotating-family.md section 10 (10.0h to 10.0n, 8 October 2026); docs/plans/igneum-2.0.md D3 and D4	the scoring rule in the close (the minimum over workloads of the maximum over free adversarial designs of the GPU's joules per hash over the adversary's, under the 10 percent GPU-cost budget at the lock, the verifier limit, cross-vendor correctness and hardware accessibility); the placed rows are D3's	the GPU side measured: the RTX 5080 at its 1,100 MHz lock 2.06 microjoules per hash and the RTX 5090 at its 1,300 MHz lock 2.33 (8 October 2026, the project's own rigs and rented pods); the chip side synthesised and claimed, its placed gated row pending	none yet

Count by status

Status	Rows
designed	3 (rows 1, 5, 6)
implemented	1 (row 2)
activated	0
tested by the team	2 (rows 3, 4)
reproduced externally	0
reviewed independently	0

6 rows. The rendered page is site/evidence.html (served at /evidence), generated from this file by site/build.mjs; the text is judgement, so this file is edited by hand and the page follows.

What would move a row

From	To	What it takes
designed	implemented	Code with test vectors that pass
implemented	activated	A node's own start line on a named chain naming the rule and its activation height
implemented	tested by the team	A landed document with the machine, the date, the command and the number
tested by the team	reproduced externally	The code the row names public in the reference repository (the specifications, the pow crate, the simulators and the test material are; the full node, the miner and the proving code open later), the command published, and a third party's run with the same result, linked from the row
reproduced externally	reviewed independently	A named reviewer's published finding on that version. Funding for review is docs/plans/funding.md
any	the row's status falls back	A new version of the code or rule the row names