22 KiB
Igneum 2.0 criticism ledger
Written fresh on 8 October 2026 against the Igneum 2.0 brief (docs/plans/igneum-2.0.md). One entry per pin group: the challenge an outsider would raise, in the critic's words where a review supplied them; the status today; the answer; the evidence as a landed document; and the pin the entry answers. A pin closes only with a landed document and its pass condition met, so anything not yet delivered is Open with the pass condition named. The earlier ledger stays in the repository as history and is neither served nor linked.
Entry format (read by tools/ledger-page.mjs and tools/ledger/export-public.mjs): ### <ID>. <title>, a quoted challenge line, Status: <word> (<date>): ... where the word is one of the six statuses' words, Answer:, Evidence:, Pin:. A status that changes gets a new Status paragraph below the old one; the last one is current.
The objective and the four properties
R0. "Another zkEVM"
"This is another zkEVM chain with a mining story attached."
Status: Decided (8 October 2026): the positioning line is served on every page, and "zkEVM" appears only under the architecture explanation.
Answer: The line is "A GPU-secured network for Ethereum-compatible applications and verifiable computation." Igneum is a sovereign GPU-mined network that runs Ethereum-compatible applications and proves their execution; the proof architecture is explained beneath that line, with its three boundaries (B1 to B3), and never leads.
Evidence: docs/plans/igneum-2.0.md (the objective: the positioning line; the site reset: every page carries it). The facts page row 5 (docs/evidence.md).
Pin: Architecture and product, sixth box (every served page carries the positioning line and the three boundaries); Site reset, fourth box.
R1. A specialised miner will remove most of the cost
"GPU-friendly hashes always fall to chips. A specialist strips everything a GPU carries that the hash does not need."
Status: Open (8 October 2026): pass when the best supported cost and energy advantage of a re-optimised, programmable adversary sits inside the chosen competitiveness envelope, with its uncertainty published (D3).
Answer: The target is contestable mining, not chip destruction: a manufacturer with a profitable product is not the failure; an exclusive, durable advantage large enough to displace the accessible GPU fleet is. Two measured results already bound the design. The connected-state reorganisation was killed as a class because rearranging the same operations moves neither side (D2). The mixed FP32 branch was killed because deterministic FP32 costs the cards 15 to 26 percent energy per hash against a 10 percent budget and widens the chip's edge to 3.0x to 3.2x (measured cards, modelled chip). Both stay as regression controls.
Evidence: docs/plans/igneum-2.0.md (the objective, property 1; D1, the mixed FP32 kill; D2(a)); docs/analysis/class-v6/connected-state.md.
Pin: The objective, property 1; D3 pass condition.
R2. Ordinary operators will be priced out
"Competitive hardware ends up in a few warehouses. A home miner with a used card has no chance."
Status: Open (8 October 2026): pass when the reference GPU population is published with both tests per class (existing owner and new entrant) and the cost per accepted unit of work is served for each class.
Answer: The cohort is the discrete-GPU population, used cards included. Each class gets two tests: the existing owner (power, wear, fees, alternative use) and the new entrant (purchase, operating cost, resale). The central measure is cost per accepted unit of work: annualised hardware, power, hosting, failures and fees over annual accepted work. Nothing here is measured yet as a population.
Evidence: docs/plans/igneum-2.0.md (D1: the reference GPU population, the two tests, the central measure; the standing rule on the cohort).
Pin: The objective, property 2; D1, sixth to eighth boxes.
R3. Mining and proving will not pay once issuance falls
"The subsidy carries everyone at launch. When issuance falls the miners and provers leave."
Status: Open (8 October 2026): pass when the five-year coexistence model names credible conditions for sustained commodity participation and names where it fails; a result needing a small network, token appreciation or scheduled chip death has not passed.
Answer: The model replaces the capex wall. It covers growing and shrinking networks, reduced issuance, cheap and dear electricity, replacement and resale on both sides, changing proving demand and miners who react. Its mandatory stress case assumes the opponent's development is already paid for.
Evidence: docs/plans/igneum-2.0.md (D4).
Pin: The objective, property 3; D4 pass condition.
R4. The defence is a rescue fork waiting to happen
"When a chip arrives you will change the algorithm in an emergency, like everyone else."
Status: Decided (8 October 2026): no property assumes a future emergency algorithm change; rotation is optional to the security argument, and seed delay is evaluated only as seed-selection protection.
Answer: The four properties must hold with no rescue upgrade assumed. The no-rescue network exercise (D5) is the test: epoch boundaries crossed, signing interrupted, the network partitioned, major operators removed, hostile proof submissions, independently written clients, with specified behaviour and no emergency algorithm change or privileged intervention. That exercise is Open.
Evidence: docs/plans/igneum-2.0.md (the objective, property 4; the standing rules; D5).
Pin: The objective, property 4; D5 pass condition.
The five deliverables
D1. The numbers cannot be reproduced
"Your measurements come from your own machines and your own scripts. Nobody can check them."
Status: Open (8 October 2026): pass when an independent operator reproduces the baseline within declared tolerances from the served kit alone.
Answer: One exact generator, verifier, dataset policy, compiler configuration and measurement harness, pinned by digest and served. Mining and proving are measured together on the final configuration, with wall power beside device telemetry, accepted and rejected work, compile time, memory use and sustained thermals. Nobody outside the project has reproduced anything yet.
Evidence: docs/plans/igneum-2.0.md (D1); docs/evidence.md (rule 1: nothing reproduced externally or reviewed independently).
Pin: D1 pass condition.
D2. Reorganising the work will not stop a specialist
"A specialist separates storage, arithmetic and memory scheduling. Rearranging the same work does not change what an operation costs."
Status: Conceded (8 October 2026): the connected-state variant, D2(a), is a KILL as a class; the memory-sharing attack, D2(b), is Open.
Answer: The critic is right for D2(a). With the same operations reorganised so that live state feeds every load address, the 64-register window is necessary (63 of 64 registers live at every address, measured), but a chip answers with a clock-gated register file that pays per write, so only the window's width reaches it: +1.2 pJ per lane-op at N5 (synthesised), moving the chip's edge 1.10x node for node against a 1.25x gate (modelled). The generator variant and the liveness tool stay behind a flag. D2(b) prices memory sharing, recomputation and data-local execution against class v6; pass when a candidate improves against re-optimised adversaries across the declared population within the preset cost and verification limits, otherwise class v6 stands and the experiment is published as a failure.
Evidence: docs/analysis/class-v6/connected-state.md (the verdict); the facts page row 4 (docs/evidence.md).
Pin: D2, first box (a) and second box (b).
D3. Chips do not expire on schedule
"Your economics assume every chip dies at the next family epoch. A programmable chip survives every family you publish."
Status: Conceded (8 October 2026): "every chip dies within a family epoch" is out of the baseline economic model, and chip-arrival percentages are not published.
Answer: The adversary is allowed to survive: whole-system cost minimised across every published family, free to change lane count, register implementation, instruction storage, memory technology, scheduling and support hardware, placed rather than synthesised, with a three-year stress life. Next-generation opponents are in the matrix. Pass when its best supported cost and energy advantage sits inside the chosen competitiveness envelope with uncertainty published; 1.5x energy is a research goal, not the pass criterion. That is Open.
Evidence: docs/plans/igneum-2.0.md (the standing rules; D3).
Pin: D3, first to fourth boxes and the pass condition.
D4. The capex wall is a fiction
"Your wall assumes the attacker pays for development. Somebody already has."
Status: Open (8 October 2026): pass when the five-year coexistence model, whose mandatory stress case has development already paid for, names credible conditions for commodity participation and where they fail.
Answer: The capex wall is replaced. Tariff advantage is shown apart from hardware advantage, and the economics page resolves the tip-share discrepancy with an explicit user-funded proving payment and congestion pricing, burn treated separately, the hard cap and no development tax kept. A profit-maximising operator simulation (mine, prove internally, prove externally, switch off) must show pricing and capacity rules restoring service without an administrator.
Evidence: docs/plans/igneum-2.0.md (D4).
Pin: D4, first, fifth to seventh boxes and the pass condition.
D5. Proofs are not a protocol guarantee yet
"Proof verification sits off the consensus path. A modified producer can include a matching statement without the valid proof and collect a payout it did not earn."
Status: Fixed in the node, awaiting the live read (8 October 2026, 17:4x UK): a valid SP1 proof is a condition of payment in consensus behind the named switch verifier_in_consensus (docs/spec/proving-enforcement.md): the body rule refuses a block whose carried proof is not held, does not verify or names another program id, and the executor pays a record only with a verified proof. The switch is false on every compiled object, so Devnet 3's digest never moved; the igneum-devnet-4 object of node 2.0.0 is cut with it on from block zero (the shipper's line, release-2.0.0-node). Team-tested: the seven refusals and the plan's six negative tests as named tests (rows 1 to 5 covered; row 6 team-tested for the native veto and PENDING for the proof side), suites green on build-2 at 16:15 UK, the fast-time crossing PASS at 17:22 UK (the forged record paid below the floor, refused and unpaid at it). Pass when the rule is read live on the exercise network: the daemon's start line with verifier_in_consensus set and a refused forged record in the journal. Was: Conceded (8 October 2026): consensus does not enforce proofs today; the switch is in the node and reads never on the devnet.
Status: Fixed (8 October 2026, 17:0x UK): the Igneum 2.0 devnet's node enforces proof verification in consensus from block zero (verifier_in_consensus set, node 2.0.0 4cdcc488 on release-2.0.0-node, the node's own start line); the no-rescue exercise itself stays Open and is the pass condition. Was: Conceded, the rule off on the earlier devnet.
Answer: Every producer verifies proofs off the consensus path today, so the network demonstrates proving activity rather than enforcing a permissionless proving economy. The rule and its activation switch exist in the node fork and are off on the devnet. Enforcement in consensus is the prerequisite of the no-rescue exercise, and node 2.0.0 follows it.
Evidence: the facts page row 2 (docs/evidence.md); docs/plans/igneum-2.0.md (D5, first box; Versioning).
Pin: D5, first box (the prerequisite).
Pools, software and participation
P1. A pool controls its miners' votes
"Whoever runs the pool votes with everyone's work. Finality by pool operator."
Status: Open (8 October 2026): pass when the member's retained voting key is committed into its work at protocol level, payment aggregation is separate and verifiable, and pool identity substitution is resisted.
Answer: Vote keys stay with the miner at protocol level; the pool aggregates payment, not votes. Not built yet.
Evidence: docs/plans/igneum-2.0.md (Pools, software and participation).
Pin: Pools, first box.
P2. Pools take custody and home miners lose to latency
"Pools hold the coins, minimum payouts strand small miners, and a home connection loses accepted work to a datacentre."
Status: Open (8 October 2026): pass on non-custodial payouts with practical minimums, local work verification and low-bandwidth participation, and on a published measurement of the accepted-work penalty for home internet against datacentre connections.
Answer: P2Pool is the precedent, not the code. Neither the payout design nor the latency measurement exists yet.
Evidence: docs/plans/igneum-2.0.md (Pools, second and third boxes).
Pin: Pools, second and third boxes.
P3. Firo's miner is the bar
"Firo's reference miner supports NVIDIA and AMD, charges no developer fee, and reports performance within about 1 percent of closed miners. Ember has to meet that."
Status: Open (8 October 2026): pass when Ember reaches good operating points without third-party software and its optimisation work, compiler settings and safe tuning logic are published beside a comparison.
Answer: Agreed that this is the bar. The within-1-percent figure is Firo's own report (claimed, not measured here). Ember is measured against it, not against whitepapers.
Evidence: docs/plans/igneum-2.0.md (Pools, fourth box; Leadership tests, first box).
Pin: Pools, fourth box; Leadership tests, first box (Firo).
Architecture and proving
A1. Why not an Ethereum L2
"If you run EVM contracts and ZK proofs, settle on Ethereum like everyone else."
Status: Decided (8 October 2026): three separate decisions: EVM-compatible execution for developers (revm), SP1 as the one well-tested proving backend behind a versioned interface, and sovereign GPU-mined consensus. Not an Ethereum L2.
Answer: An L2 would suit a project whose objective is Ethereum settlement. Igneum's objective is an independent network secured by accessible hardware. Sovereignty has a cost: the network must establish its own consensus security, data availability and credible cross-chain verification, and execution proofs do not remove those duties.
Evidence: docs/plans/igneum-2.0.md (Architecture and product, first box).
Pin: Architecture and product, first box.
A2. Proof-system flexibility becomes arbitrary acceptance
"A replaceable proof system means the chain accepts whatever prover is fashionable."
Status: Decided (8 October 2026): program identities, verifier versions and security parameters are pinned in the protocol; one backend first, a second only where justified, never interchangeable immature backends.
Answer: The interface stays replaceable; what the chain accepts does not. Pinning in the protocol is designed and not yet shown on the devnet.
Evidence: docs/plans/igneum-2.0.md (Architecture and product, second box).
Pin: Architecture and product, second box.
A3. Rotation is not the defence
"Your resistance is the rotation: when a chip shows up you will identify it and fork it out."
Status: Decided (8 October 2026): no chip detection in consensus, no hardware whitelists, attestation, per-address quotas or self-reported GPU bonuses; rotation is optional to the security argument.
Answer: Igneum's mining design accepts that specialised hardware may be built; 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. The window costs a GPU under 1 percent of rate at stock (measured on rented RTX 5090 and RTX 4090 cards, 8 October 2026). The long-program and select-tree proposals stay out as regression controls.
Evidence: the facts page row 3 (docs/evidence.md); docs/analysis/class-v6/connected-state.md; docs/plans/igneum-2.0.md (the standing rules).
Pin: Standing rules (no detection, rotation optional); D3 (the adversary that survives rotation).
A4. A concentrated prover can stall the chain
"Separate roles on paper. In practice one big prover withholds proofs and useful operation stops."
Status: Open (8 October 2026): pass when a withholding concentrated prover is exercised on the no-rescue network with replacement operators, usable inputs, reassignment and explicit behaviour during proof delays, and the network behaves as specified with no privileged intervention.
Answer: Winning the mining lottery and producing proofs stay separate, and they must remain separable during a failure, not only on paper.
Evidence: docs/plans/igneum-2.0.md (D5, fourth box).
Pin: D5, fourth box.
A5. Your miner promise covers hardware your prover does not
"The miner runs on AMD and Apple, but the proving income needs NVIDIA."
Status: Conceded (8 October 2026): proving runs on NVIDIA; AMD and Apple mine. The product language states it plainly.
Answer: The proving stack is judged on the full pipeline: inputs, proving, aggregation, verification, payment, memory footprint and mining income forgone. A fast shard result is not enough when aggregation or memory pressure makes ordinary operators uncompetitive.
Evidence: docs/plans/igneum-2.0.md (Architecture and product, fourth box).
Pin: Architecture and product, fourth box.
A6. "Everything runs unchanged" is a claim, not a test
"EVM-compatible until the block context, the randomness or the fees differ."
Status: Open (8 October 2026): pass when compatibility ships as a product deliverable: representative contracts, wallet fee estimation, indexing, failed transactions, receipts and application assumptions tested, with the documented set of differences (block context, randomness, two-dimensional fees).
Answer: The differences are known and are listed; the test suite that makes compatibility a deliverable does not exist yet.
Evidence: docs/plans/igneum-2.0.md (Architecture and product, third box).
Pin: Architecture and product, third box.
A7. The proving market is revenue you do not have
"Internal payouts on a valueless devnet show a mechanism, not demand."
Status: Conceded (8 October 2026): the external proving market is not built and stays out of revenue assumptions until it is.
Answer: The ladder: prove Igneum's own execution; then one external customer's exact workload with repeat paid jobs; then further workloads only where the fleet has a demonstrated edge. Pilots and announcements do not count; customers repeatedly paying for proofs at prices that carry reliable service and an operator margin do.
Evidence: docs/plans/igneum-2.0.md (Architecture and product, fifth box; Leadership tests, third box).
Pin: Architecture and product, fifth box; Leadership tests, third box.
The three boundaries
B1. Proven execution means the block is final
"The block is proven, so it is final."
Status: Decided (8 October 2026): the boundary is stated wherever the proof architecture is explained.
Answer: Proven execution is not automatically finality. A proof shows a block's execution was computed correctly; finality is a property of the chain's own consensus and checkpoints.
Evidence: docs/plans/igneum-2.0.md (the objective: the three boundaries).
Pin: The objective, the three boundaries; Architecture and product, sixth box.
B2. EVM-compatible means Ethereum's security
"It runs Ethereum contracts, so it inherits Ethereum's security."
Status: Decided (8 October 2026): the boundary is stated wherever the proof architecture is explained.
Answer: EVM compatibility is not Ethereum security. Igneum is a sovereign network: its security is its own GPU-mined consensus, not Ethereum's validators.
Evidence: docs/plans/igneum-2.0.md (the objective: the three boundaries).
Pin: The objective, the three boundaries; Architecture and product, sixth box.
B3. ZK means private
"Zero knowledge, so my transactions are private."
Status: Decided (8 October 2026): the boundary is stated wherever the proof architecture is explained.
Answer: ZK technology does not automatically make transactions private. The proofs here verify execution; transaction data is public, and privacy would need additional application or protocol design.
Evidence: docs/plans/igneum-2.0.md (the objective: the three boundaries).
Pin: The objective, the three boundaries; Architecture and product, sixth box.
Comparisons and leadership
C1. Ravencoin already does this
"KAWPOW already keeps consumer GPUs competitive, allows for future chips and does not plan forks as the normal defence."
Status: Open (8 October 2026): pass when benchmarks against Ravencoin's KAWPOW, an operating system with the same stated objective, are published and show a stronger result or a more valuable overall offering.
Answer: Restating the goal is not enough. Igneum is measured against the operating system, not its whitepaper.
Evidence: docs/plans/igneum-2.0.md (Leadership tests, first box).
Pin: Leadership tests, first box (Ravencoin).
C2. Ergo is an operating benchmark
"Ergo already runs a GPU memory-hard design with live pooling, emission and difficulty changes."
Status: Open (8 October 2026): pass when the comparison with Ergo, on its live behaviour rather than its papers, is published.
Answer: Ergo is a reference point, not a whitepaper competitor; the comparison is owed.
Evidence: docs/plans/igneum-2.0.md (Leadership tests, first box).
Pin: Leadership tests, first box (Ergo).
C3. Number one is unsupported
"You claim to be the best GPU network before anyone outside has checked anything."
Status: Conceded (8 October 2026): no "number one" claim before comparative results and adoption exist.
Answer: No present-tense rank is served. Published claims name the evaluated release, evidence and boundary conditions. An independently substantiated pass of the acceptance standard would support a serious case that Igneum is in contention for leadership among GPU-first networks and would not award a numerical rank; it would not guarantee adoption, perpetual GPU profitability, defeat of all future chips or a numerical number-one ranking. The tests that would earn it are miners staying through hard conditions, customers repeatedly paying for proofs, and the network running without the founding team (D5); none is met yet.
Evidence: docs/plans/igneum-2.0.md (Leadership tests, second to fifth boxes).
Pin: Leadership tests, fifth box (served ranking language); second to fourth boxes.