igneum/docs/analysis/horizon/frontier.md

Horizon lane 7: frontier. Predictions to 2030, what no proof-of-work chain has shipped, and what Igneum can

6 October 2026, evening UK. Lane 7 of the Horizon programme. Worktree /Users/joshm/Projects/igneum-wt-horizon (branch horizon, at origin/master 3f4f719). The founder's words: "research anything else that we can research too, predictions, forward thinking, what we can actually do that has not been done or applied, think outside the box", and "be revolutionary". Main's bar: not features, but ideas that change what a proof-of-work chain is or what a GPU owner is to the world, each with its evidence, cost, gate, and the attack a Monero or Kaspa core developer would mount. I argue each attack as the project's own four personas would hear it (.claude/agents/cryptographer.md, consensus-engineer.md, execution-engineer.md, miner-community-lead.md).

Nothing in this file is a prediction of the coin's price, an offer to sell anything, or a change to any consensus parameter. Every chip figure is arithmetic on cited memory and logic figures; every GPU figure names its bench entry; a figure from memory says approximate. No em dashes.

Read for grounding: docs/spec/00-overview.md, 05-fees-and-economics.md, 07-execution.md, 09-pool-protocol.md, 10-light-client.md; site/litepaper.html (whole page, including "What Igneum does not claim"); docs/fud-ledger.md sections 3 (P1 to P10 present in the file; P11 to P23 are cross-referenced from the spec and round-3 entries), 4 (E1 to E8), 6 (C1 to C12), 9 (D1 to D6); docs/commercial/prover-customer-brief.md; docs/design/payment-routes.md, developer-adoption.md, execution-layer.md; docs/analysis/chip-model-v3.md sections 5 to 6; docs/plans/counter-asic-3-status.md section 4; docs/analysis/prover-tiers-real-cards.md (eleven rented cards, 6 October); docs/analysis/economy-2026-10-04.md; docs/analysis/security-budget.md; docs/bench-log.md line 2582 (rental cost of hash, measured 6 October); vendor/rusty-kaspa/consensus/core/src/config/params.rs (main checkout). block-rate-devnet2.md was still a template at 22:00 UK (RUN_A and RUN_B empty); nothing here depends on it.

Model: sim/horizon/frontier/frontier_model.py (pure Python, no numpy, about 50 ms; python3 sim/horizon/frontier/frontier_model.py > sim/horizon/frontier/out.md). Every table below marked "model" is printed by it; its INPUTS block labels each input measured, cited, designed or approximate with the source. Not run under the lock: it is arithmetic, not a measurement.

---

0. Everything ranked by payoff over difficulty

Payoff 1 to 5 is what the idea does for the chain's security, the coin's utility or the GPU owner's position in the world, if it works. Difficulty is Claude-side hours to a measurable prototype (the founder's rule: hours, never weeks). Verdicts: do now, prototype, watch, never. The "never" rows carry a sharp reason so the rest are not fantasy.

Rank	Idea	Payoff	Hours	Verdict	One line why
1	3.3 The weight table carried inside the recursive segment proof: a consensus proof at mergeset cost, so a browser verifies finality from one proof and asks no node for the voter set	5	60	do now (design and guest prototype)	Phase two's hardest item becomes incremental: each segment proof updates W2 by its own blue blocks; the cost is one BLS aggregate verify per 30 s inside the zkVM, which SP1 has precompiles for (approximate)
2	3.2 Work-stake: vote weight as the external-job bond	5	24	prototype	A bond nobody can buy: 30 days of blocks. The at-risk pool income is thousands of IGN against a 0.0015 IGN coin bond (model section 3); the design stays "no stake" because weight is work, not coins
3	3.7 Reproducible-build attestations in a registry contract; Ember refuses a release under N of M attestations	4	12	do now	Bitcoin's guix.sigs with the chain as the sigs repo; closes the devnet's "release key acts as operator" sentence (litepaper, Governance)
4	3.4 A WebAssembly verifier of the wrapped block proof in the tab	4	16	do now	Three working precedents (a16z Helios WASM, ProjectZKM ziren-wasm-verifier, xycloo wasm-groth16-verifier); the certificate half already runs at 58 to 155 ms (bench-log)
5	3.8 Ember as node, wallet and light client for everyone: node count equals miner count	4	20	do now	1,000 testnet miners become 1,000 verifying nodes; Monero shows about 5,000 peers in 72 h (monero.fail), Ethereum 8,136 execution nodes (ethernodes); Sybil counts are irrelevant here because nothing counts nodes
6	3.15 A 30-s randomness beacon from the checkpoint VDF	4	24	prototype	The pipeline exists (10-min VDF, 4.47 ms verify); a drand-class beacon with no league and 120x drand's latency; honest limit is the class-group ASIC (Chia timelords)
7	3.1 The reward rule that prices rented hash out (pay per block falls when hash arrives faster than the 30-day weight)	4	40	prototype	Doubles the renter's break-even price (model section 2) and routes the cut to the proving pool, not to incumbents; the cost is a 30-day income ramp for honest newcomers, which the vote already imposes
8	3.5 Continuous miner-voted parameters, bounded per block like Ethereum's gas limit, for B_p, the floors and the window	3	30	prototype	Replaces two-week 60 percent proposals with a drift anyone can read on the chain; Kaspa's Crescendo was a fixed DAA score (params.rs:648), Bitcoin's BIP9 a 95 percent tally; neither moves a number continuously
9	3.16 The hourly program swap as a research dataset and the fleet library as a product	3	10	do now	8,760 random kernels a year, compiled on three vendors with per-variant timings; compiler and GPU-architecture researchers have no such corpus; income small, standing large
10	3.13 Igneum as the settlement layer for GPU rental	3	40	prototype (escrow plus sampled verification)	The chain's fee is 3 to 5 orders under a 7 to 15 percent platform take (model section 5), but it can settle only what it can verify; the verifiable subsets are named
11	3.6 Treasury-less audit funding: burn-redirect bounties by 60 percent signal, review escrow on upgrade proposals	3	20	watch	The money exists only when the chain is used (USD 1,600 to 16,000 per 30 days at launch traffic, model section 4), and it is the switch spec 5.5 removed, with a veto
12	3.14 Proofs sold to AI labs for verifiable inference	2	40	watch	zkLLM: 803 s of proving per forward pass on LLaMA-2-13B (arXiv 2609.27367 citing 2404.16109); the competitor is a USD 0 TEE attestation on H100-class cards the fleet does not own
13	3.9 Hardware wallets that verify proofs	2	12	never on the secure element; do the companion verify	A bn254 pairing on a Cortex-M-class secure element is seconds to minutes (approximate); Ledger and Trezor do their heavy work in the companion app, and Igneum Wallet already verifies certificates with the node's code
14	3.12 The fleet as a public compute market (rendering, inference) priced in IGN	2	60	never for unverifiable work; do for the verifiable subsets	An escrow without a verifier is a trust-me payment with lower fees; Render uses result quorums, Akash reputation, io.net attestations (secondary), none of which a chain can check
15	3.11 Miners paid for proving others' chains as the main income, the lottery a tiebreaker	1	0	never by 2030; watch	All of Ethereum L1's proving at the Sep 2026 tracker cost is USD 36 a day; Igneum's year-1 emission is USD 13,700 a day at 0.005 (model section 7); demand must grow 1,000x against a cost curve falling 3x to 30x a year
16	3.10 Proof-of-useful-work: the lottery hash partly a proof	1	0	never	Every coupling of leader election to proving re-opens Aleo (fastest prover wins); Ball et al. 2017 and Ofelimos 2022 show the sampleability conditions, and zkVM proving meets none of them

Predictions (section 2) are not ranked; they are inputs. The three ideas a Monero or Kaspa core developer would not have thought of are 3.2, 3.3 and 4.3 (the hourly program as a hardware census), argued in section 4.

---

1. Method

Three kinds of work:

1. Trend lines with arithmetic. Each 2030 prediction has a cited anchor (a product page, a tracker, a standards body, a secondary analysis labelled as such) and a formula in the model script. Where the trend is from memory (consumer VRAM generations) the row says approximate.
2. Idea arithmetic. For the five ideas whose value depends on numbers (the rental tax, work-stake, the burn bounty, rental settlement, the proving-income ceiling) the script prints the table and the document reads it. The attack costs use the measured rental entry (docs/bench-log.md line 2582: 1,748 MH/s for USD 20.44 an hour, USD 0.0117 per MH/s-hour, about USD 11.69 per GH/s-hour) and are given per GH/s and evaluated at 1, 10, 100 GH/s and 1 TH/s, as the brief asks.
3. Prior art. WebSearch on 6 October 2026 for every idea; the paper or repository that tried it is cited, or the idea is marked "new" when none was found. Claims about other chains cite the repository file when a clone exists in the main checkout (vendor/rusty-kaspa) and are marked "not cloned, approximate" otherwise.

No simulator in sim/ was re-run and no node harness was started: every idea here is a design question whose first gate is a measurement named in its section, and tonight the fleet, PC 1, PC 2 and the devnet were in use for the class v4 rehearsal and the Devnet 2 block-rate runs. What I could not run is listed in section 6.

---

2. Predictions to 2030

Each row: the trend, its anchor, the arithmetic, and what it does to the chip model and the proving tiers. Tables marked model are frontier_model.py section 1.

2.1 GPU memory per card

Year	Flagship consumer card	GB	Label
2016	GTX 1080	8	approximate (from memory)
2018	RTX 2080 Ti	11	approximate
2020	RTX 3090	24	approximate
2022	RTX 4090	24	approximate
2025	RTX 5090	32	cited (chip-model-v3.md 5.1: 16 x 2 GB GDDR7 on 512 bits)

Compound growth 1.167 a year (4x in 9 years). Extrapolated: 51 GB in 2028, 69 GB in 2030 (model). The module arithmetic is sharper than the curve: a 512-bit board is 16 devices; Micron has ended 2 GB GDDR7 (TrendForce, 24 September 2026, via chip-model-v3.md 5.1) and 3 GB devices are USD 60 to 70, so the next flagship is 48 GB (16 x 3 GB) and 64 GB is the 2030 shape. The RTX 60 series on Rubin (GR20x) is reported for 2028 after two slips (kopite7kimi via videocardz.com and thepcenthusiast.com; rumour, not a product). Datacentre: HBM4 at 36 GB per 12-high stack, 288 GB per GPU on Rubin NVL72 (Wikipedia HBM page, Micron March 2026 production).

What it does to the chip model: nothing for the stored-dataset chip (f = 1), whose memory is already 24 to 32 GB against a dataset of 2 GiB growing to 4 GiB at year 4 (chip-model-v3.md 5.7: dataset size is "not a lever against this chip"). What it does for miners: the dataset schedule (2 GiB, doubling at years 4, 12, 28; litepaper) stays under every card from 8 GB for twelve years, and the proving side, not the mining side, is what wants VRAM (section 2.6).

2.2 Memory dollars per GB

Point	USD per GB	Source
2023, GDDR6	3.38	Tom's Hardware, "GDDR6 VRAM prices plummet", USD 27 per 8 GB
2025, GDDR6	2.50	TechSpot, "AI is eating all the DRAM" (2026)
2026, GDDR6	3.30	TechSpot, same
Sep 2026, GDDR7 2 GB device	10.00	TrendForce via chip-model-v3.md 5.1
Sep 2026, GDDR7 3 GB device	21.67	TrendForce (USD 60 to 70 per device)
Oct 2026, HBM3E 36 GB stack	about 8.3	siliconanalysts.com/data/hbm-pricing (factory gate; contract about 2x), approximate
Oct 2026, HBM4 36 GB stack	about 15.3	siliconanalysts.com (USD 550 per stack); Samsung quoting USD 4.50 to 4.90 per Gb for HBM4 against 1.50 for HBM3E (BigGo Finance), approximate

GB per dollar fell in 2026 for the first time in a decade and DRAM supply is forecast tight through 2027 with new fabs in 2028 (SoftwareSeni "HBM4 delays and GDDR7 shortages"). Memory is reported at 70 to 80 percent of the bill of materials of high-VRAM consumer cards by late 2025 (BuySellRam, secondary).

What it does to the chip model: the f = 1 chip and the GPU buy the same devices, so the ratio of their memory bills is fixed; what moves is the share of each bill that is memory. The chip's bill is about 70 percent memory (USD 320 of USD 470, chip-model-v3.md 5.4) and the 5090's about 16 percent at MSRP (USD 320 of USD 1,999) or 9 percent at the 2026 street price of USD 3,695 (localaimaster.com). A doubling of device prices raises the chip's cost 1.7x and the card's 1.1x to 1.2x: the stored-dataset chip gets dearer relative to the GPU through 2027, and the dollars-per-MH/s row (USD 2.8 against 14.7 at MSRP, 5.4 against 27 at street prices) narrows a little and no more. The per-joule row does not move at all, and per joule is where the chip wins (section 2.3).

2.3 Random-read bandwidth: GDDR7, HBM3E, HBM4

The lottery is latency-bound: one hash advances one dependent 4-byte read per memory latency, so the number that matters is random reads per second per watt, not GB/s (chip-model-v3.md 5.3 and 5.5). That ceiling is set by bank count and activate windows (tRC, tFAW), not by pin speed, so 48 Gbps GDDR7 is 28 Gbps GDDR7 here, and HBM3E is HBM3.

Memory system	Reads/s ceiling	Why	Label
GDDR7, 16 devices, 512-bit (the 5090 board)	21.3 G	4 activates per 12 ns per channel x 64 channels	approximate (chip-model-v3.md 5.3)
RTX 5090 measured	17.5 G	82 percent of the ceiling	measured (bench-log Counter ASIC 2.0)
HBM3 or HBM3E, one stack	10.7 G	16 channels	approximate
HBM4, one stack	21.4 G	JEDEC JESD270-4 raises channels per stack from 16 to 32, each with two pseudo-channels (allaboutcircuits.com, EDN), which doubles activate parallelism if tFAW per channel holds	approximate, derived (model 1.3)
A 48 GB GDDR7 board	21.3 G	capacity does not add channels	approximate

The f = 1 chip in 2028 on HBM4 (model 1.4; every figure arithmetic, approximate):

Chip	MH/s per chip	W bare / with a 150 W shadow core at k = 1	uJ per hash bare / shadow	Gain per joule vs the 5090 bare (2.40 uJ)	Gain under the class v4 shadow (card 2.95 uJ at N = 100,000)
GDDR7 f = 1 (today's row)	166	78 / 228	0.47 / 1.37	5.1x	2.2x
HBM3 one stack	84	27 / 177	0.32 / 2.12	7.5x	1.4x
HBM4 one stack (2028)	167	36 / 186	0.22 / 1.11	11.0x	2.6x

Prediction: HBM4 doubles the stored-dataset chip's rate per stack at about the same watts, so its bare per-joule edge rises from about 7x to about 11x, and under the class v4 shadow from about 2.3x to about 2.7x. The lever that answers it is N, the program work in the latency shadow: at N = 200,000 the HBM4 chip reads 1.74x at k = 1, at N = 330,000 (the 5090's full ALU budget) 1.33x (model 1.4). The verifier cost is N x 32 ops per warp: about 1 ms at N = 100,000 on one M5 Max core (measured class, counter-asic-3-status item 8), about 3 ms at 330,000, inside the 10 ms gate; the 2019-class core is unmeasured (O-1.14).

Consequence and proposal (for the coordinator, not a change tonight): write the schedule for N into the era draw at genesis, the way the dataset size already is: a candidate is a doubling of N per era until the verifier gate binds (about 1,000,000 ops, 10x of headroom on the M5 Max). The memory generation it answers arrives every two to three years and the chain must not need a human release to answer it. Per tier: no hash-rate cost while cards stay latency-bound (the M5 Max binds at about 290,000, the 9070 XT at about 650,000, approximate), watts up toward TGP (a 5090 from 326 toward 575 W, which the Ember power cap already manages), a verifier cost nodes and pools pay in milliseconds.

2.4 Price per card

Card	Launch MSRP	2026 street	Source
RTX 5090	USD 1,999	USD 3,695 to over 5,000	chip-model-v3.md 5.1; localaimaster.com; tech-insider.org ("RTX 5090 tops USD 5,000"), secondary
RTX 4090	USD 1,599 (approximate)	rental USD 0.28 to 0.60 an hour (gpus.io median)	rental cited, MSRP from memory

Prediction: consumer card prices track memory prices through 2027 and ease in 2028 when fab capacity lands. For Igneum the price per card matters twice: the honest fleet's capital cost (not in the security budget, which is power only, security-budget.md section 6) and the renter's hourly price, which fell to USD 0.21 to 0.44 per 5090-hour on Vast.ai (getdeploying.com, 6 October 2026) even as purchase prices rose, because rented supply is sunk capital. The rental market, not the purchase market, prices the 51 percent attack, and the measured entry is USD 11.69 per GH/s-hour at RunPod list prices with the market unable to supply 20 more pods when asked (bench-log line 2582). At a TH/s: USD 11,700 an hour, and no supply.

2.5 The chip-fab cost curve

Node	Mask set	Source	Igneum reading
28 nm	USD 1 to 3 M	TubeTime (3 M); VBsemi (over 1 M)	The f = 1 memory-controller chip: no mixer on the die, a USD 5 to 30 M project (asic-resistance-history.md 2.5)
7 nm	USD 10 to 15 M	VBsemi; Hacker News thread	The f = 0 recompute chip with 256 MiB on die: USD 50 to 75 M
5 nm	USD 6.5 M (2026 data) to 30 M (2023 estimate)	siliconanalysts; HN	The shadow core (30 mm^2 at N5 for N = 100,000) drags the f = 1 chip toward this node, or to a reticle-class 28 nm die
3 nm	USD 15 to 22 M (Q4 2025), up to 40 M (older)	siliconanalysts; semianalysis	Not relevant to a chip whose cost is memory

Prediction: mask cost at a fixed node falls (5 nm quoted at 30 M in 2023, 6.5 M in 2026) while the leading node rises. So the shadow lever's fab-bill teeth weaken about 4x over three years; what holds in 2030 is the rate and joule arithmetic of 2.3, not the bill. The stored-dataset chip gets cheaper to design and dearer to populate through 2027, and the net is roughly flat against the GPU on dollars; per joule it gains with each memory generation unless N grows with it.

2.6 zkVM proving speed per dollar

Point	USD per Ethereum L1 block proof	Hardware	Source
Jan 2025	1.69	about 160 RTX 4090s for 90 percent real-time, USD 300 to 400 K cluster	HackMD "Ethproofs 2025 review" (willcorcoran); Succinct SP1 Hypercube blog (May 2025), secondary
Dec 2025	under 0.04	16 x RTX 5090 (SP1 Hypercube: 99.7 percent of blocks under 12 s; cluster under USD 100 K); Pico Prism 16 GPUs (Brevis blog, Feb 2026)	same, secondary
Apr 2026		Cysic Venus 7.4 s on 24 GPUs	bex.co, secondary
Aug 2026		ZisK p99 9.62 s on 4 x RTX 5090	GitHub comparative analysis (Ricosworks1), secondary
Sep 2026	about 0.005	"sub-half-cent" fields on ethproofs	same, secondary

The 20-month ratio is 338x, about 33x a year (model 1.6). That cannot continue: it is software catching up with hardware. The table below uses 1.5x, 3x and 10x a year from the shard times measured on eleven rented cards on 6 October (prover-tiers-real-cards.md, the v1 shard, 4.7 M cycles).

Card	Beside the miner today, s	Alone today, s	2028 at 1.5x a year (beside / alone)	2028 at 3x	2028 at 10x	Under 10 s beside the miner in 2028?
RTX 3060 12 GB	37.5	14.4	16.7 / 6.4	4.2 / 1.6	0.4 / 0.1	at 3x or more
RTX 4060 8 GB (core-only beside)	22.1	18.4	9.8 / 8.2	2.5 / 2.0	0.2 / 0.2	even at 1.5x
RTX 4070 12 GB	27.3	12.1	12.1 / 5.4	3.0 / 1.3	0.3 / 0.1	at 3x or more
RTX 4060 Ti 16 GB	34.6	11.6	15.4 / 5.2	3.8 / 1.3	0.3 / 0.1	at 3x or more
RTX 3080 10 GB	25.6	7.1	11.4 / 3.2	2.8 / 0.8	0.3 / 0.1	at 3x or more
RTX 3090 24 GB	19.9	14.9	8.8 / 6.6	2.2 / 1.7	0.2 / 0.1	even at 1.5x
RTX 4090 24 GB	26.1	6.3	11.6 / 2.8	2.9 / 0.7	0.3 / 0.1	at 3x or more
RTX 5070 12 GB	37.2	4.8	16.5 / 2.1	4.1 / 0.5	0.4 / 0.0	at 3x or more
RTX 5090 32 GB	10.7	6.3	4.8 / 2.8	1.2 / 0.7	0.1 / 0.1	even at 1.5x

Prediction: at the floor rate (1.5x a year, which is the GPU hardware cadence alone) only the 24 GB and 32 GB cards mine and prove inside 10 s in 2028; at 3x a year (half the historical software rate) every card from the 3060 up does, and an 8 GB card alone proves in 2 s. The block-proof target ("under 10 s as provers improve", CLAUDE.md) should be written as a function of the measured fleet median shard time, re-read each era, not as a date. Per tier: a 12 GB desktop card is the swing tier; under 1.5x it proves alone in under 7 s but not beside its miner, so the hand-off profile (prover-tiers-real-cards.md) is the thing to ship, not a bigger card.

What the cost curve does to the economics: the dollars per proof on the open market fall as fast as the volume rises, which is the arithmetic behind the "never by 2030" of 3.11.

---

3. The ideas, one section each

Each section: the idea in a paragraph; why nobody shipped it (cited, or "new"); what Igneum already has; the model; hours; the gate; the per-tier consequence; the Monero attack; the Kaspa attack; the verdict.

3.1 The reward rule that prices rented hash out

The idea. The pulse attack M14 (a renter arrives, mines for an hour, leaves) is recorded in the ledger and the finality rule already denies rented hash a vote. The reward side is untouched: a renter is paid per block like anyone. The rule: the block subsidy paid to a producer is multiplied by m = clamp(W30 / H_now, 0.25, 1), where W30 is the 30-day work-weighted hash the finality window already computes (blue blocks per DAA second over the W2 window) and H_now the DAA-window estimate. The remainder (1 - m) of the subsidy goes to that block's proving-pool escrow, not to incumbents and not to a burn. Fees are untouched. Hash that arrives faster than the 30-day weight can follow is paid less per block until the weight catches up.

Why nobody shipped it. Bitcoin Cash's EDA and every emergency rule since adjusted difficulty, never pay (approximate; the consensus engineer's list). Kaspa's DAA retargets per block over a sampled window (vendor/rusty-kaspa/consensus/src/processes/difficulty.rs, main checkout) and pays per block. Monero's RandomX changes what hash is, not what it is paid. Ethash coins and Ergo pay per block. No chain ties the subsidy to the ratio of fresh to sustained hash, because no chain had a sustained-hash number in consensus; Igneum has it in W2. Prior art searched: none found. New.

What Igneum already has. W2 (blue blocks per key over 30 days) and the DAA estimate are both in the node; the proving-pool escrow exists in execution state (spec 7.7 item 6); the emission split is a state transition by rule (design 1.1).

The model (frontier_model.py section 2, the measured rental entry USD 11.69 per GH/s-hour):

Network hash	Attacker adds	H_now / W30	m	Attacker IGN per hour, no rule	With rule	Rent USD per hour	Break-even IGN price, no rule	With rule
1 GH/s	1 GH/s	2.0	0.50	57,038	28,519	12	0.00020	0.00041
10 GH/s	10 GH/s	2.0	0.50	57,038	28,519	117	0.00205	0.00410
100 GH/s	100 GH/s	2.0	0.50	57,038	28,519	1,169	0.02049	0.04099
1 TH/s	1 TH/s	2.0	0.50	57,038	28,519	11,690	0.20495	0.40990
10 GH/s	50 GH/s	6.0	0.25	95,064	23,766	584	0.00615	0.02459

A renter who doubles the network needs twice the coin price to break even; one who sextuples it needs four times. The diverted subsidy (57,000 to 85,000 IGN an hour in these rows) reaches the provers of the same blocks, who are the sustained population by sortition weight (spec 7.2). The honest-growth cost: a listing that doubles honest hash overnight cuts every miner's subsidy per block in half on top of the halving difficulty already imposes, until W30 catches up (the 30-day ramp of ledger C7, 0.9x by day 28 to 31). The floor 0.25 bounds the worst case at 4x.

Hours. 40: the rule in the coinbase state transition (8), W30 as a consensus value from the window the finality module keeps (8), the economy simulator scenario f with and without the rule (8), the fast-time harness timestamp test (8), spec text and tests (8).

The gate. (a) sim/economy/sim.py scenario f (a pool with the network's own hash arriving on day 10): incumbents' income under the rule above the no-rule row for all 30 days, newcomers' below. (b) The fast-time harness with headers back-dated inside Kaspa's 132-s tolerance: m moves under 2 percent. (c) Scenario d (a 20 percent operator vanishes): m stays at 1 (hash fell, so H_now < W30 and nobody is cut).

Per tier.

Tier	Consequence
Home miner, 8 to 32 GB	In a doubling month, 25 percent of the pre-event subsidy instead of 50; unchanged in a steady month; a newcomer earns half-rate for its first month, as it votes nothing for its first month already
Rig	The same per block; a rig that joins during a listing spike earns half for a month
Pool user	The same through PPLNS; the pool's dashboard should show m
Prover	Gains: the diverted share lands in the pool escrow and is paid by sortition weight
Holder	Emission schedule unchanged in total; a larger share of it reaches sustained keys during spikes
Rollup customer	Nothing
Node operator	One more consensus value (W30) and one multiplier in the coinbase rule

The Monero core developer's attack. "You have built an incumbents' cartel. Every rule that pays old miners more than new miners entrenches whoever was there first; RandomX exists so that a newcomer with a laptop earns exactly what a veteran earns per hash. Your 'to the pool, not incumbents' is cosmetic: sortition is by weight, and weight is the incumbents. And your W30 is your own finality window, so a 30-day-old farm that goes dark and returns is 'sustained' while a thousand honest newcomers after a listing are taxed for a month. Qubic reached 23 to 34 percent of our hash for weeks in August 2025 (arXiv 2512.01437) by renting and by paying miners in its own token; your rule would have taxed the honest miners who moved to P2Pool to fight it, because they were new keys." Answer: the tax is per block not per key, so moving pools under the same key costs nothing (spec 9.6), and a returning farm's W30 is its own blocks, which it did not make while dark. The entrenchment point stands and is the cost the gate measures.

The Kaspa core developer's attack. "H_now is your DAA estimate and the DAA is manipulable by timestamps inside the tolerance; a producer can lower H_now for its own block by back-dating within 132 s and raise its own m. Second, W30 is a function of the DAG past and differs between two honest tips every second; a reward that depends on it makes two honest nodes disagree about the coinbase amount of the same block unless W30 is read at a fixed ancestor (the checkpoint), and then it lags. Third, you have made emission depend on a window of 2.6 million blocks: your pruning point must now keep that window's per-second counts, which Kaspa prunes." Answer: read both numbers at the block's selected parent's last certified checkpoint (deterministic, in every node's past), accept the 30-s lag, and the timestamp test is gate (b). The pruning point already keeps the W2 window for finality (spec 3), so no new retention.

Verdict: prototype. Doubles the renter's break-even and costs honest newcomers a month of half subsidy, which is the same month the vote already costs them; gate (a) decides whether miners will wear it.

3.2 Work-stake: vote weight as the external-job bond

The idea. The external job market needs a bond because a customer waits (spec 5.4, O-5.6: maxPgas x f_p x 1.5 in IGN, slashed on a late or bad proof). Replace the coin bond with the key's 30-day vote weight: a key that claims an external job and delivers late or wrong loses a share s of its weight for 30 days, the way equivocation strips 100 percent (spec 3.6). Weight is blue blocks. It cannot be bought, borrowed or bridged; it can only be mined, in public, over 30 days. The job market then needs no IGN escrow from the prover, which removes the capital barrier that keeps home cards out of Boundless (ZKC collateral) and Succinct (PROVE staking, docs.succinct.xyz/docs/provers) while keeping a bond larger than either.

Why nobody shipped it. Every proving network bonds in its own token (Boundless: stake scales with aggregate proving work per epoch, docs.boundless.network/zkc/mining/overview; Succinct: stake required to bid, more stake more concurrent auctions). No proof-of-work chain had a non-transferable, slowly earned weight per key until Igneum's finality rule. Decred's tickets are bought with coins; Ethereum's slashing is coins. New.

What Igneum already has. W2 per key, the 30-day strip for equivocation, the sortition that already draws assignees by weight (spec 7.2), the job record format (design 6).

The model (frontier_model.py section 3):

Key's hash share	Blocks per 30 days at 1 bps	30-day pool income at risk, IGN	Lost at s = 25 percent	Lost at s = 100 percent	The coin bond for one 1 B-cycle job at the floor
0.01 percent	259	1,643	411	1,643	0.0015 IGN
0.1 percent	2,592	16,427	4,107	16,427	0.0015 IGN
1 percent	25,920	164,271	41,068	164,271	0.0015 IGN
10 percent	259,200	1,642,706	410,676	1,642,706	0.0015 IGN

The at-risk amount is five to nine orders of magnitude above the designed coin bond, before counting the lost vote. A late proof must be defined in DAA time against the claim (the P9 decision's 120-s claim timeout is the starting value), with one strike of grace per 30 days so a partition does not strip an honest key on its first miss.

Hours. 24: the strip rule in the finality module keyed by a job-fault record (8), the fault record in the job contract (design 6) with the evidence a node checks (8), tests and a devnet injection script (8).

The gate. Phase 4 devnet: 1,000 jobs with a 10 percent injected late or wrong rate: every injected fault stripped; zero honest keys stripped across a 60-s partition; a customer's job never waits more than the claim timeout plus one open window.

Per tier.

Tier	Consequence
8 GB solo miner below dust (under 100 blocks in 30 days)	No weight, so no external jobs under this rule; shards (no bond) unchanged; the pool protocol gives it a route (the pool's key, the pool's weight)
12 to 32 GB home miner above dust	Takes external jobs with no IGN locked; one bad job costs a quarter of a month's sortition income and a quarter of its vote for 30 days
Rig	The same, at the rig's weight; the rig operator's whole weight backs each job, so a rig claims only jobs it can finish
Pool user	The pool's weight is the bond; the member's share of pool income carries the pool's record
Prover	A reputation nobody can buy, visible on chain per key
Holder	No IGN is locked in bonds, so no bond capital sits idle
Rollup customer	A bond measured in 30 days of public mining instead of a token balance; the customer brief's "your chain's own bond and slashing apply" becomes "Igneum's weight is at stake" once jobs settle on Igneum
Node operator	One more strip condition in a module that already strips

The Monero core developer's attack. "CLAUDE.md says no stake anywhere in consensus. You have just made the vote weight a stake: it is at risk for an execution-layer fault. Whatever you call it, a prover now rationally hedges by splitting its mining across two keys, one that votes and never proves, one that proves and holds dust weight, which your F17 says buys nothing for the vote but buys everything here: the proving key has nothing to lose. So the bond is only real for operators too small to split, which is backwards." Answer: the sortition draws assignees in proportion to weight (spec 7.2 step 2), so a dust key is drawn with probability near zero and the proving key must carry weight to be assigned at all; the hedge costs the prover its assignments. The attack is right that this is a stake of work; the design's "no stake" means no coin balance in consensus, and that still holds. The spec wording needs the distinction.

The Kaspa core developer's attack. "'Late' is not a fact on a DAG. A proof included in a block at DAA score D is late relative to the claim at D minus T only along a chain; a reorg moves D. You will strip a key on one chain and not on another, and the strip is a consensus input to finality. Also, the fault evidence rides in blocks, so a producer who dislikes a prover can withhold its proof for T seconds and then carry the fault record. That is a griefing vector you did not have when nothing waited on a prover (ledger P9)." Answer: the evidence rule must be relative to the carrying block's own chain (as proof records are, spec 7.2 item 5), the deadline must be long relative to merge depth, and the withholding vector is real: a proof gossips to every producer, so withholding needs a majority of producers for T seconds, and a strip is only applied if no block in the carrier's past carried the proof. The griefing cost is one window of a majority, the same bound the finality rule already lives with.

Verdict: prototype. The bond nobody can buy; the two attacks name the wording (work-stake is not coin-stake) and the rule (evidence relative to the carrier's chain) that the prototype must carry.

3.3 The weight table carried inside the recursive segment proof: finality attested by provers, a consensus proof at mergeset cost

The idea. Phase two's consensus proof is scoped as "a zkVM program over the 30-day header window and the vote certificates" (design 7; O-10.8), which is 2.6 million headers per proof and the reason it is phase two. But the segment proof already recurses: segment N verifies segment N minus 1 (spec 7.8 item 1, measured on the 5090). Carry the W2 weight table as a public commitment inside that recursion. Each segment's guest takes the previous segment's committed weight table, adds the blue blocks of its own mergeset per vote key hash (the segment is exactly the mergeset of its chain block, spec 7 terms), ages out the blocks that left the 30-day window, and commits the new table. Every 30 s, when a certificate exists for a checkpoint inside the segment, the guest verifies the BLS aggregate against the table it holds and emits "checkpoint i certified under rule v2 with x percent of total weight". The segment proof then attests both execution and finality, and a light client verifying one wrapped proof learns the certified checkpoint and the state root with no voter set fetched from any node. The provers are the attesters of finality, by construction, with no new role.

Why nobody shipped it. Ethereum's sync-committee light clients (Helios, a16zcrypto.com "Building Helios") trust a committee and fetch it; Succinct's eth-proof-of-consensus (github.com/succinctlabs/eth-proof-of-consensus) proves sync-committee signatures in a SNARK but over a fixed committee, not a weight table that moves with every block. No proof-of-work chain has a weight table to carry. Mina carries a recursive proof of the whole chain but its consensus is stake (approximate, not cloned). The incremental-weight-in-recursion form: new.

What Igneum already has. The aggregator guest with chain_len and prev (spec 7.8 item 1), the 340-byte BlockOutput, the canonical voter list and bitmap (spec 3.10 C3), SP1 with BLS12-381 precompiles (approximate: SP1's precompile set includes bls12-381 field operations; the pairing cost inside the guest is unmeasured), O-10.2 which already asks for a header commitment to the weight table.

The model. Cost per segment: the segment adds at most 180 blocks per chain block at 1 BPS (mergeset limit, spec 7.1) times N = 8 chain blocks, so about 1,440 table updates (a hash-map add and an age-out) per segment, which is negligible beside the execution; plus one BLS aggregate verification per certificate, at most one per 30 s. The BLS verify is the cost: G1 aggregation of up to V keys and one pairing. In SP1 with the bls12-381 precompiles a pairing is of the order of tens of millions of cycles (approximate, from memory of the precompile benchmarks; unmeasured here), so at 1 pgas = 1,000 cycles it is tens of thousands of pgas, about one shard's budget (S_p 30,000 pgas) per 30 s. That is a real cost: about one extra shard per 30 blocks, 3 percent of proving capacity at launch traffic. The table commitment is 32 bytes in the public values; the voter list for a 10,000-key table is 10,000 x 60 bytes = 600 KB of witness per segment, which gossips with the shard witnesses (design 5.1: witnesses are not consensus data).

Hours. 60: the guest's table update and commitment (16), the BLS verify inside the guest and its cycle count on the 5090 (16, needs PC 2 or a fleet box), the light-client path that reads the certified index from the public values (8), the spec text for 7.8 and 10 (8), a fast-time run where a partition's two certificates are both presented to the guest and it accepts one (12).

The gate. (a) Cycle count of one certificate verification inside the guest under 50 M cycles on the pinned SP1 (so under two shards). (b) The browser card (spec 10.8) shows "voter set: verified" with no node asked for the set. (c) The fast-time C4 scenario (a certificate over a chain the node is not on, docs/fud-ledger.md C4 sweep): the proof refuses a certificate whose signers' weight at that block is under 2/3 of the table it carries.

Per tier.

Tier	Consequence
Home miner, any card	Nothing changes in mining; a 12 GB prover's shard gets the certificate verification about once in 30 shards
Rig, prover	About 3 percent more proving work at launch traffic, paid from the same pool; the aggregator's record grows by 32 bytes
Pool user	Nothing
Holder, wallet user	A phone or tab verifies "locked" from one proof and trusts no node for the voter set; the spec 10.1 row "voter list from nodes" is deleted
Rollup customer	The bridge on Ethereum verifies one wrapped proof and needs no relayer or committee: this is the proof bridge of spec 7.3, delivered earlier
Node operator	The witness gossip carries the voter list per segment (600 KB at 10,000 keys)

The Monero core developer's attack. "You have moved finality's safety from a BLS signature every node checks to a SNARK every node trusts. A soundness bug in SP1 (ledger P7) now forges not only a state root, which full nodes veto by native execution, but a certificate, which full nodes cannot veto because they verify the real BLS certificate separately and will disagree with the proof. Which do you believe? And your 2/3 test inside the proof is against a table the proof itself computed; a bug in the table update is a bug in finality, and it ships in a guest program, not in node code anyone reads." Answer: full nodes keep verifying the BLS certificate natively and the native-execution veto extends to the public values (a record whose certified index or table commitment differs from the node's own is invalid, spec 7.2 item 5 as written), so a forged certificate is, as for state, a light-client problem and never a chain split. The table update is a second implementation of W2 and must be differential-tested against the node's (gate c).

The Kaspa core developer's attack. "The weight table is defined over the block's DAG past (W2 counts blue blocks in the past of the chain block); your segment is the mergeset of chain block C in GHOSTDAG order, so the incremental update is only correct if every block in the window is in exactly one segment's mergeset, which holds for blue and red blocks of the selected chain's mergesets, but a reorg of the selected chain re-cuts the segments and the table must be re-derived from the fork point. Your proof chain breaks at every reorg deeper than one segment, and at 10 BPS with k = 124 a reorg of 8 chain blocks is ordinary." Answer: correct, and the recursion already restarts at an unproven segment (spec 7.8 item 7, the unproven rule); a reorg deeper than a segment invalidates the records of the abandoned chain as it does today. The table commitment must therefore be part of the statement per chain block, re-proven on the new chain, which is what re-proving the segment already does. The cost at 10 BPS is the open question for the gate.

Verdict: do now (design and guest prototype). It turns phase two's hardest item into an incremental one on code that exists, and it is the only road to "your browser verifies Igneum" with no node in the trust row.

3.4 A WebAssembly verifier of the wrapped block proof in the browser

The idea. The homepage card verifies a BLS certificate in JavaScript today (58 to 68 ms warm, 139 to 155 ms cold, bench-log round 6, P3). Ship the other half: the Groth16 or Plonk wrapper of the segment proof verified in WebAssembly in the tab, with the measured millisecond count shown.

Why nobody shipped it on a proof-of-work chain. Because no proof-of-work chain proves its blocks. The working precedents are rollup-side: ProjectZKM's ziren-wasm-verifier (github.com/ProjectZKM/ziren-wasm-verifier: "Verify STARK, Groth16 and Plonk proofs in browser", one Rust codebase to native and WASM), xycloo's wasm-groth16-verifier (github.com/Xycloo/wasm-groth16-verifier, with a live demo), a16z's Helios shipped as @a16z/helios on npm with WASM bindings (github.com/a16z/helios issue 76 and the npm package).

What Igneum already has. site/verify/core.js (BLAKE2b header hashes, canonical voter list, BLS aggregate over @noble/curves), the SP1 light verifier as a 58 MB native binary (bench-log, "the program id split"), the wrap step in the ProofSystem trait (design 5.6) unbuilt.

The model. A Groth16 proof over bn254 is three group elements, about 128 bytes compressed (spec 10.5, approximate); verification is one multi-pairing. In WASM a bn254 pairing is of the order of 10 to 50 ms on a laptop core (approximate, from the ziren and xycloo demos' order of magnitude; unmeasured here). Bytes per day in phase two on-demand mode: 800 bytes per open (spec 10.5).

Hours. 16: wrap the pinned aggregator proof to Groth16 with SP1's wrapper on a 24 GB fleet card (8, the P3 phase 2 benchmark brought forward), compile the verifier to WASM and wire it to the card (8). The wrapper's own cost on consumer hardware is the open measurement R4.

The gate. The card shows the wrapped proof verified in the tab, with bytes and milliseconds, on a phone-sized viewport, against the live devnet; the number lands in the bench-log with the browser and the device.

Per tier. A home miner's Ember node serves the proof to the tab; a holder with no node verifies state in the tab (the state root still rests on a certificate the client is given until 3.3 lands); a rollup customer sees the verifier it will run on its own chain; node operators serve one more 128-byte object.

The Monero core developer's attack. "A verifier in a tab served by your domain verifies whatever your domain says the verifying key is. Your 'no middleman' is your web server. Monero's answer to this class is: run a node." Answer: correct, which is why spec 10.8 already removed "no node, no trust, no middleman" and why the phone app with a pinned seed list is the client that meets 10.6; the tab is a demonstration with its trust row stated on the card.

The Kaspa core developer's attack. "Fine, it verifies a proof. Of which chain? The proof commits to a chain block hash; the tab needs to know that block is on the selected chain at or below a certified checkpoint, which it asks a node for (spec 10.4 item 4). You verified the arithmetic and trusted the topology." Answer: correct until 3.3 folds the certified index into the same proof.

Verdict: do now. Cheap, precedented, and the phase 2 wrapper measurement has to happen anyway.

3.5 Continuous miner-voted parameters, bounded per block, in place of two-week proposals

The idea. Spec 5.8 sets a parameter the genesis rules leave to miners by a registered proposal passing 60 percent of blue blocks over two weeks. For the handful of parameters that are dials rather than switches (B_p, S_p, the base-fee floors, the exclusive window, the external claim timeout) use Ethereum's gas-limit mechanism instead: each block carries the producer's vote for each dial, the value in force at a block is the median of the window's votes, and the median may move at most 1/1,024 of its value per block, within a hard range fixed at genesis. No proposal, no bit, no two-week window, no human. Switches (a new instruction family, a proof-system version) keep the 90 percent signal.

Why nobody shipped it this way. Ethereum moves its gas limit by producer vote, bounded to 1/1,024 of the parent's limit per block (geth core/block_validator.go, VerifyGaslimit; approximate, not cloned). Bitcoin's BIP9 is a 95 percent tally over 2,016 blocks with LOCKED_IN and one more retarget before activation (bips.dev/9); BIP 135 generalised the thresholds. Kaspa's Crescendo was a fixed DAA score: crescendo_activation: ForkActivation::new(110_165_000) for mainnet and 88_657_000 for testnet (vendor/rusty-kaspa/consensus/core/src/config/params.rs lines 648 and 704; the struct at line 28), with nodes connecting only to protocol version 7 peers from 24 hours before (docs/crescendo-guide.md at v1.0.0). Monero's upgrades are scheduled hard forks, formerly every six months, now every 9 to 12 months (getmonero.org). Igneum's own 6 October incident was a fixed-height activation crossing a half-updated fleet (CLAUDE.md, Devnet 2 rules). Nobody applied Ethereum's dial to a proof-of-work chain's economic parameters. The combination is new; the mechanism is Ethereum's.

What Igneum already has. The header's version bits (O-5.3 candidate), the 60 percent rule, the fee parameters as Params.fees per network (spec 5.11), the DAA window every node computes.

The model. At 1/1,024 per block and 1 BPS a dial can move 2.3x in a day (1.001^86,400) if every producer votes the same way, 1.07x if 51 percent do and 49 percent vote the other way (the median moves only when a majority agrees, and then one step per block). A hostile 51 percent can therefore walk a dial to the genesis bound in days; the bound is the defence, as it is on Ethereum (the gas limit has a hard floor and no cap besides the vote).

Hours. 30: the vote field and median rule (10), the clamp and bounds in Params (6), tests including the 51 percent walk (8), spec 5.8 text (6).

The gate. On the fast-time harness, 100 producers at 60/40 split: the dial moves toward the 60 side at the predicted rate and stops at the bound; with a 50/50 split it does not move; a producer that votes outside the range is invalid.

Per tier. Miners set the dials with their blocks (Ember shows the vote and defaults to "hold"); a pool votes for its members in mode A and B templates and the member sees it (spec 9.4); provers watch B_p and S_p move with the fleet's measured shard time instead of waiting for a human; holders and rollup customers see fee floors that track usage; node operators gain one field per header.

The Monero core developer's attack. "You have handed the fee floor to whoever has 51 percent of blocks, with no social veto. On Monero the dynamic block size has a penalty curve exactly so that a majority cannot cheaply walk it; your 1/1,024 is a speed limit, not a cost. A pool with 51 percent lowers f_p to its floor, bloats blocks with wash gas it no longer pays for, and the provers eat the backlog." Answer: the base fee is burned in full, so wash gas is never free (ledger E3), and the backlog rule halves B_p regardless of the vote (design 4.3); the range bound caps the walk. The point stands that a dial needs a cost curve, not only a speed limit: the prototype should add Monero's shape (a vote away from the median costs the producer a fraction of its subsidy).

The Kaspa core developer's attack. "A per-block vote on a DAG: which blocks vote? Blue blocks of the selected chain's mergesets, in order, and the median over a window is a function of the block's past, fine. But a parameter in force 'at a block' must be the same for every node validating that block: use the value at the block's selected parent's checkpoint, or two honest nodes meter the same transaction at two prices. You have the same determinism bug the proof-record rule had before P11." Answer: correct; the value in force is read at the last certified checkpoint in the block's past, as 3.1's W30 is.

Verdict: prototype. The chain's economic dials follow the fleet without a human; the two attacks give it the two rules (a cost curve, a checkpoint-anchored read) it needs.

3.6 Treasury-less audit funding: bounties from the burn, a review escrow on upgrades

The idea. the founder removed the dev fund (spec 5.5) and the project pays audits from the Ember dev fee and founders' mined coins (litepaper). The question: money for audits that comes from users paying for something, with no standing address. Two mechanisms. (a) Burn redirect. The base fee burns to nobody. A reproducible break submitted under spec 0.5 and accepted by 60 percent of blue blocks over a window redirects the base-fee burn of the next 7 (execution) or 30 (consensus) days to the submitter's address, once, then returns to burning. No address exists between events. (b) Review escrow. An upgrade proposal under 5.7 must escrow IGN in a contract that pays reviewers named in the proposal on a 60 percent "review complete" signal, or refunds on failure; the proposer pays, which is a user paying for a thing (the right to propose code).

Why nobody shipped it. Zcash funds development from the block subsidy (NU6: 8 percent to Zcash Community Grants, 12 percent to a protocol lockbox, ZIP 1015); Decred from a 10 percent treasury spent by stakeholder vote, capped at 4 percent of balance a month since January 2026 (DCP-0013); Monero from the CCS, donations off-chain; Optimism from an 850 M OP reserve for retro funding. Bug bounties pay 10 percent of funds at risk (Immunefi's standard) from the protocol's own treasury; Code4rena runs contests at zero platform fee since 2025. Nobody funds audits from a burn redirect, because a burn redirect is a subsidy to a payee by rule, and the chains that wanted that built a treasury. New in form; a dev fund in substance (see the Monero attack).

What Igneum already has. The base-fee burn in both dimensions, the 60 percent signalling, the ledger's break-submission rule (spec 0.5), the proposal registration transaction (spec 5.8).

The model (frontier_model.py section 4):

Chain traffic (fraction of full blocks)	Base fee burned per day, IGN	30-day redirect, IGN	USD at 0.02	USD at 0.10
0.01	2,592	77,760	1,555	7,776
0.10	25,920	777,600	15,552	77,760
0.50	129,600	3,888,000	77,760	388,800
1.00	259,200	7,776,000	155,520	777,600

At launch traffic a 30-day redirect is under one audit contest; at half-full blocks it is a serious bounty. The money exists only once the chain is used.

Hours. 20 for the escrow contract and the redirect rule as a proposal kind; 0 for the honest alternative, which already exists.

The gate. None that a simulator settles; the gate is the founder's: does a per-event, miner-approved payee with no standing address pass the test that removed the dev fund?

Per tier. Miners vote on each payout with their blocks and can refuse all of them; holders see supply that would have burned paid to a named person; a prover, rig, pool user and rollup customer see nothing unless a break affects them; the node operator gains a proposal kind.

The Monero core developer's attack. "This is a dev fund with extra steps. You removed a 5 percent fund because 'a switch that routes money to an address somebody controls is the first thing a critic points at'; you have now written a switch that routes money to an address somebody controls, gated by the same miners who gate everything else, and you have made the miners the judge of which cryptographer gets paid. Our CCS works because it is off-chain and voluntary and no consensus rule touches it. Keep the burn a burn." The attack is right. Answer: there is no counter besides the honest one: the alternative is the one the litepaper already states (client fee, founders' mined coins, grants off-chain), and the ledger should carry this entry as considered and rejected on the same ground as E4.

The Kaspa core developer's attack. "Also a soft target: a miner cartel with 60 percent invents a break, 'accepts' it, and un-burns 30 days of fees to itself. Your spec 0.5 reproducibility rule is a human judgement; consensus cannot check it." Correct.

Verdict: watch. Design it, do not ship it; record it in the ledger beside E4 as the honest answer to "where do audits come from with no fund": from the company's dev fee and from the people who care, in the open.

3.7 Reproducible-build attestations in a registry contract; Ember refuses a release under N of M attestations

The idea. Bitcoin Core builds with Guix and independent builders publish signed attestations of the output hashes to the guix.sigs repository (bitcoin/bitcoin PR 21462 added guix-attest and guix-verify; bitcoinops.org reproducible builds). Put the attestation registry on Igneum: a contract where a builder set posts (release tag, artefact hash, signature); the Ember updater refuses to install a release whose artefact hash has fewer than N attestations from M builders listed in the release key's policy, and shows the attesters. Windows exes are already reproducible here (-Wl,--no-insert-timestamp, CLAUDE.md), so the hash is well defined.

Why nobody shipped it on chain. Bitcoin keeps its sigs in a Git repository because Bitcoin has no contract state; Ethereum clients attest off-chain. Igneum has an EVM and a signed updater that already checks a manifest hash. The on-chain registry read by the updater: new in placement, not in idea.

What Igneum already has. Reproducible builds on the box (tools/build-remote.sh, cross-remote.sh), the signed manifest and updater in Ember (litepaper, Ember table), the commit-string check (tools/ci/commit-string-check.sh), the release key in genesis (spec 8).

The model. Trust goes from one key (the release key, which on the devnet "acts as the operator", litepaper Governance) to N of M builders, with M growing as outside builders arrive. The failure the rule catches: a release signed by a stolen key whose hash no independent builder reproduced. Cost per release: one transaction per builder.

Hours. 12: the registry contract (4), the updater's N-of-M check and the display (6), the CI step that posts the box's attestation (2).

The gate. A release whose binary is altered after signing is refused by Ember on three machines; a correct release with N attestations installs; the registry shows both.

Per tier. Every miner's updater refuses an unattested binary and names who attested; a pool operator and a node operator get a chain-readable answer to "is this the binary everyone runs"; holders and rollup customers see that the "release key as operator" sentence has a closing mechanism.

The Monero core developer's attack. "Who are the M builders at launch? The founder, under three names. Reproducible builds are only as good as the independence of the builders, and a pseudonymous one-founder project has one builder. Gitian and Guix were worth something because dozens of people with names attested. You are moving a sigs repo on chain; you are not adding a builder." Answer: correct, and the registry is what lets a second builder exist with a public record; the gate should be the first attestation from a machine the project does not own.

The Kaspa core developer's attack. "A node that reads a contract to decide whether to update is a node whose update path depends on the chain being live and unforked; during the 6 October two-sided chain you would have had two registries." Answer: the updater installs nothing while finality is paused, which is a rule worth adding anyway.

Verdict: do now. Twelve hours, and it closes a sentence the litepaper has to carry today.

3.8 Ember as node, wallet and light client for everyone

The idea. Ember already runs a node, mines, proves and keeps a key; Igneum Wallet reads Ember's node when present. Make the one app the client for everyone: a holder who does not mine runs Ember in "verify" mode (the light client of spec 10 inside the same binary, the node card to pin a seed), a miner runs it in full mode. Every miner is a node; every holder is at least a light client; nobody runs a browser wallet against someone else's RPC by default. The node count becomes the miner count plus the holders who chose full mode.

Why nobody shipped it. Bitcoin Core is a node and a wallet but not a miner; miners run separate software (approximate). Monero's GUI runs a node and a wallet and can mine on the CPU (approximate; the litepaper's reason for no CPU lane is botnets). Kaspa's miners run kaspad plus a separate miner. Igneum's Ember already supervises node, miner, prover and key (litepaper, Ember table), so the step is small. Not new; the combination with the light client and the vote key in one binary is Igneum's.

What it does to node counts and Sybil counts. Bitcoin: 24,682 reachable nodes (bitnodes.io, 5 October 2026); Ethereum: 8,136 execution clients on ethernodes.org, 11,781 on Etherscan the same day; Monero: about 5,000 peers seen in 72 hours by one tracker (monero.fail), all secondary. Igneum's gate 4 is 1,000 independent miners; with Ember as the node those are 1,000 full nodes on day one of the public testnet, each with a vote key. Sybil counts are irrelevant on Igneum by design: nothing in consensus counts nodes or keys (spec 3.1 W6, ledger F17), so a Sybil inflates a node map and nothing else. The one place a count matters, "no verifier, no vote" (spec 9.7 item 2), is served better: every member has a verifier because the signer is the verifier.

Hours. 20: the light-client engine inside Ember's process with a mode switch (12), the wallet reading it (4), the node card pinning (4).

The gate. A machine with no GPU runs Ember in verify mode, shows "locked" from a certificate it verified, and sends a transaction; a miner's Ember shows one key in the header of its blocks and the same key signing votes.

Per tier. A home miner runs one program; a holder with a laptop runs a verifier instead of trusting an RPC; a pool user's member process is Ember (spec 9.1); a rig runs one signer and many workers (spec 9.6); the node operator is now everyone.

The Monero core developer's attack. "A node that is also a hot wallet with a vote key and a miner is one process with every secret in it; one bug in the dashboard's local HTTP server (you serve it behind a per-launch token) and the key, the vote and the coins go together. Monero separates the daemon from the wallet for this reason." Answer: the separation stays at the process level (signer, workers, node, wallet are separate processes under one supervisor), and the vote key and the payout key are different keys; the attack names the test (the dashboard token's threat model) that gate 4 must include.

The Kaspa core developer's attack. "Node count is a vanity metric; what matters is who produces blocks and who the honest majority peers with. A thousand Ember nodes behind home NAT accept no inbound connections, so your reachable count is your seed list plus the rigs, and an eclipse of the seed list eclipses the fleet." Answer: correct; spec 10.6's pinned seed list with identity keys and the local peer set is the defence, and the eclipse test O-3.7 with Ember nodes is the gate.

Verdict: do now. Twenty hours; the testnet gate then measures nodes, not only miners.

3.9 Hardware wallets that verify proofs

The idea. A Ledger or Trezor that verifies the wrapped block proof (or the certificate) before signing, so "final" is checked on the device, not in the companion app.

Why nobody shipped it. Ledger's secure element is EAL6+ certified and Trezor's Safe 3 and 5 use an Infineon OPTIGA Trust M (trezor.io; ledger.com), both small, slow, memory-poor chips. The cryptographic work hardware wallets do is signing; the heavy lifting (sync, proofs, history) is in the companion. A bn254 pairing on a Cortex-M-class secure element is seconds to minutes (approximate, from memory; the Bulletproofs-on-Trezor paper, eprint 2020/281, shows what Micropython on a Trezor costs for range proofs, and it is slow). Igneum Wallet already verifies the finality certificate with the node's own code (litepaper, Wallet table), which is the companion doing it.

The model. Certificate verify: G1 aggregation of up to 10,000 keys plus one BLS12-381 pairing; on a laptop in JavaScript 58 to 155 ms (bench-log). A secure element is 100x to 1,000x slower on scalar arithmetic than a laptop core (approximate), so 6 to 150 s per certificate, every 30 s. Not shippable.

Hours. 12 for a companion-side integration (the wallet already does it); the on-device path is not worth hours.

Per tier. Holders get "final means final" in the companion today; nobody gets it on the secure element.

The Monero core developer's attack. "Monero's Ledger app exists and does nothing but sign; it took years and a custom protocol (eprint 2020/281). You will not get a proof verifier onto a secure element and you should not pretend to." Correct.

The Kaspa core developer's attack. "A device that verifies a proof still needs to know which chain tip the proof is of; it will take that from the companion, which is the thing you did not trust." Correct.

Verdict: never on the secure element; do the companion verify (already done in Igneum Wallet 0.1.1; the Ledger and Trezor apps when they exist should display the companion's verified state and sign).

3.10 Proof-of-useful-work: the lottery hash partly a proof

The idea as asked. Make the leader election depend in part on proving work, so the energy that picks the block maker is useful.

Why every attempt failed, cited. Primecoin (2013) found Cunningham and bi-twin prime chains that nobody uses (Bitcoin Magazine, July 2013). Gridcoin pays for BOINC work and stops if BOINC stops (gridcoin.us; the 2022 "Challenges of PoUW" survey, arXiv 2209.03865). Ball, Rosen, Sabin and Vasudevan (eprint 2017/203) gave proofs of useful work from fine-grained problems (Orthogonal Vectors, 3SUM, APSP) and state the conditions: the problem must be sampleable at a tunable hardness with instances the miner cannot choose, and the verifier must be cheaper than the work. Ofelimos (Fitzi, Kiayias, Panagiotakos, Russell, CRYPTO 2022, eprint 2021/1379) got a provably secure protocol by making the work a doubly efficient local search whose usefulness is a side effect and small. The 2026 "Economics of Proof-of-Useful-Work" (arXiv 2606.06700) and the empirical study of Pearl's cuPOW (arXiv 2606.04819, "The Usefulness Gap") find the same gap between the work paid for and the work anyone wanted. I found no Coinbase paper on the subject (searched 6 October 2026); if the founder has one in mind, its title is needed. Aleo ran proving as the consensus work and the fastest prover won (CLAUDE.md: the Aleo lesson; litepaper precedents table, approximate). Boundless's PoVW (docs.boundless.network/zkc/mining/overview) pays ZKC pro rata to cycles proven per epoch with a stake that scales with the work, which is a reward for proving, not a leader election, and it is on a proof-of-stake chain.

The sampleability problem, plainly. A lottery needs a puzzle whose instances are drawn at random from a distribution the miner cannot steer, whose hardness is tunable by a target, and whose solution is verifiable in milliseconds. zkVM proving has none of these: the instances (segments, jobs) are chosen by users and producers, the hardness is whatever the program is, and the verifier is tens of milliseconds to seconds. Any blend ("a miner's lottery target eases in proportion to its proven cycles last hour") gives the fastest prover more blocks, which is Aleo with a cap, and a cap small enough to be safe is a reward too small to be useful.

What Igneum already has instead. The separation (litepaper: "the lottery and the proving are kept separate on purpose"), the 20 percent pool paid by sortition by weight, PoVW-like cycle metering through pgas.

Hours. 0.

Per tier. Nothing changes; the 12 GB card still earns from proving through the pool.

The Monero core developer's attack. "RandomX's whole point is that the work has no second use, because any second use is a subsidy to whoever does the second thing best, and that is a specialist. The moment your hash is 'partly a proof', the best prover is the best miner, and the best prover is a datacentre. You know this; it is in your own CLAUDE.md."

The Kaspa core developer's attack. "Leader election on a DAG must be a memoryless Poisson process so that GHOSTDAG's k and the orphan analysis hold; a target that depends on the miner's past hour of proving is not memoryless and your blue-set bounds no longer apply."

Verdict: never. Both attacks are correct and the second is fatal to the DAG analysis. The honest version of "useful work" is the one Igneum has: the same card, two jobs, two payments, no coupling. Lane 8 may take one adjacent idea by name: the shadow-useful puzzle, in which the program work placed in the latency shadow (class v4, 100,000 ops per hash that cost the card nothing) is itself a small verifiable sub-computation drawn from chain state (a hash-based commitment to a sampled Merkle path of the segment's state witness), so the shadow ops have a second use that does not change who wins. It changes nothing about leader election because the shadow is free; whether a useful shadow program is as chip-hostile as a random one is lane 8's question.

3.11 Miners paid for proving others' chains as the main income, the lottery as the tiebreaker

The idea as asked. Invert the design: proving is the income, the lottery only orders.

The arithmetic (frontier_model.py section 7):

Income line	USD per day	Basis
Proving every Ethereum L1 block at the Sep 2026 tracker cost	36	USD 0.005 x 7,200 blocks; a buyer pays above cost, call it 10x: 360
The same at the Dec 2025 cost	288	under USD 0.04 per block
All rollup proving spend (customer brief)	8,200 to 27,400	"low millions a year", approximate
Boundless, trailing day in the explorer, 4 Oct 2026	2	8.4 T cycles at USD 0.21 per billion, developer-adoption.md 2b, approximate
Igneum year-1 emission at USD 0.005 per IGN	13,700	31.688 IGN per block x 86,400
At USD 0.02	54,800
At USD 0.10	273,800

The whole public proving market is three to four orders of magnitude under year-1 emission at any price input. The cost curve (section 2.6) falls 3x to 30x a year, so dollars per proof fall as fast as volume rises; for proving to be the main income by 2030, paid demand must grow about 1,000x in dollars. The design's own claim is the defensible one: a second income that keeps cards on after the subsidy fades (spec 5.10.2).

Why nobody shipped it. Succinct and Boundless are exactly this (proving as the income) and have a token for the lottery's role; their provers are datacentre operators (ledger C10). Nobody has made it a GPU home-miner's main income because the market is this size.

Hours. 0.

Per tier. The 12 GB home card earns pool emission today and job income later; the number that matters to it is the pool share, not the market.

The Monero core developer's attack. "Your 'paid, useful, verifiable work' line implies the work pays. It does not and will not; say so in the litepaper's income table." Answer: the litepaper already says "small market today", "upside, not a promise" (ledger P6); the arithmetic above should join it.

The Kaspa core developer's attack. "If proving were the income, the lottery would be a cost centre miners minimise, hash would fall to the floor, and your 51 percent cost would be the cost of a few 5090s. Keep the lottery paid." Correct.

Verdict: never by 2030 as the main income; watch the market yearly.

3.12 The GPU fleet as a public compute market beyond proofs, priced in IGN

The idea. Rendering, inference, transcoding, simulation sold by Igneum miners for IGN, through the same client that switches between hashing and proving.

The honest problem. General compute is unverifiable: a renter cannot tell a rendered frame from a cheaper one, an inference from a smaller model's, without redoing the work. The existing markets answer with trust substitutes: Render uses result quorums for graphics, Akash provider auctions plus reputation, io.net proof-of-work-style attestations (all secondary, io.net's own comparison page and a 2026 DePIN survey). None of those is checkable by a chain.

The verifiable subsets, named.

Work	How it is verified	Status for Igneum
ZK proving jobs	The proof	The precompile (design 6), Designed
Deterministic recompute with sampling	Commit to every intermediate, a verifier re-runs a random fraction (Statistical Proof of Execution, arXiv 2503.18899; sampled layerwise proofs for inference, arXiv 2609.27367)	Feasible as an app on the precompile: the sampled chunk is the job; the rest is a commitment
Rendering with result quorum	Two or three miners render the same frame; the chain pays on agreement (Render's approach, approximate)	An app; the chain pays per agreement, cannot judge quality
TEE-attested inference	NVIDIA confidential computing attestation on H100 and H200 (phala.com GPU TEE)	The fleet's cards have no TEE; not Igneum's
Bitwise-reproducible training	Verde-style proofs of learning on a rollup (secondary, io.net comparison page)	Research

Hours. 60 for a sampled-recompute job type on top of the precompile; 0 for the general market.

Per tier. A 24 GB card could sell sampled-recompute work; an 8 GB card cannot hold most inference models; the rollup customer is unaffected; a holder sees IGN demand only for the verifiable subset.

The Monero core developer's attack. "You would be Golem, Render and Akash with a worse token story and a settlement layer nobody asked for. The honest answer to 'GPU owners should be paid for useful work' is a market with reputation, and reputation is not a consensus rule." Correct for the general case.

The Kaspa core developer's attack. "Every second a card spends on a render is a second off the lottery; the design's own economy model shows hash falling 14 percent when external pay rises 10x (scenario b). A compute market large enough to matter would empty the lottery." Correct, and it is the reason 3.11 is never.

Verdict: never for unverifiable work; do the verifiable subsets as apps on the precompile (the sampled-recompute job type is the one worth 60 hours).

3.13 Igneum as the settlement layer for GPU rental itself

The idea. Vast.ai and RunPod match renters and hosts and take a platform cut; the escrow, the metering and the payout could run on Igneum, where every miner is already a host with a funded wallet and a card that is on.

The fee arithmetic (frontier_model.py section 5):

Card	Vast.ai on-demand USD/h	Platform take modelled	Host loses USD per card-year	Igneum settlement per rental (2 transfers at the floor)	At USD 0.02 / 0.10 per IGN
RTX 5090	0.44 (getdeploying.com, 6 Oct 2026)	Vast about 15 percent (secondary)	579	0.0102 IGN	0.0002 / 0.0010
RTX 5090	0.44	RunPod about 7 percent (secondary: hosts keep 93)	270	0.0102 IGN
RTX 4090	0.31	Vast about 15 percent	408	0.0102 IGN
RTX 4090	0.31	RunPod about 7 percent	190	0.0102 IGN

Caveat on the takes: secondary comparisons put Vast at about 15 percent and RunPod at about 7 percent; Vast's own June 2024 product update says the host fee was removed and replaced by a surcharge it does not publish, so the 15 percent is a market estimate, not a fee page. The chain's fee is three to five orders of magnitude under either. The platform's take pays for matching, images, dispute, trust and the verification of delivered work, and the last is what the chain cannot do (3.12).

What Igneum already has. Funded miner wallets, the pool protocol's TLS transport and member identity (spec 9), the job escrow shape (design 6), the sampled-recompute path above.

Hours. 40: a rental escrow contract with hourly streaming and a sampled attestation of liveness (the host signs a challenge per minute with the vote key; proves possession of the card by running one lottery warp on it, which the CPU verifier checks in 0.44 ms) (24), a client-side matching list (16). It settles payment and liveness; it does not verify the renter's workload.

The gate. Ten rentals between fleet boxes with one host that goes dark: the escrow pays to the minute of the last valid challenge; the renter's refund is exact; the chain fee per rental under 0.02 IGN.

Per tier. A home miner rents out idle hours with no platform cut and a 30-day public record as a host; a rig lists eight cards; a pool user is unaffected; the prover role and the host role compete for the same seconds; a holder sees IGN demand per rental; a rollup customer is unaffected.

The Monero core developer's attack. "Escrow is 1 percent of a marketplace. The 15 percent is the other 99: the people who answer when a pod dies. You will have a cheaper escrow and no renters, and every renter you do get will be running the thing Vast bans. Also: a card that is rented is a card that is not mining, so you are paying people to leave your lottery." The last point is 3.12's and stands.

The Kaspa core developer's attack. "Streaming payments per minute at 1 BPS are 1,440 transactions a day per rental, each burning a base fee; at a thousand rentals that is your whole block budget. Use a channel, settle twice." Correct, and the model's two transfers assume exactly that.

Verdict: prototype the escrow with the liveness challenge, because it reuses the vote key and the CPU verifier in a way no other chain can, and because miners are hosts already; do not call it a marketplace.

3.14 Proofs sold to AI labs for verifiable inference

The state of the art, cited. zkLLM (arXiv 2404.16109, CCS 2024) proves a 13 B-parameter LLM's inference in under 15 minutes with proofs under 200 kB, verified in 1 to 3 s; the 2026 sampled-layerwise paper (arXiv 2609.27367) measures 803 s of proving per forward pass on LLaMA-2-13B and extrapolates about 18 days per 2,000-token generation under full ZK. EZKL's median proof time on small workloads is about 8.2 s and a 100 M-parameter model is about 10,000 s per proof at today's throughput (proofoftech.org, secondary). Modulus Labs' Remainder prover was benchmarked at USD 0.085 per proof to verify on Base; the team joined Tools for Humanity in late 2024 and no longer sells (proofoftech.org). The competitor is a TEE: NVIDIA confidential computing on H100 and H200 with remote attestation, sold today at near-zero overhead (phala.com; arXiv 2607.19353 benchmarks), and sampling schemes (SPEX, arXiv 2503.18899) that are statistical, not cryptographic.

Cost per token, approximate. 803 s of one GPU per forward pass on a 13 B model at a USD 0.44 5090-hour is about USD 0.10 per token proven. An unverified 13 B token is of the order of USD 0.0000002 (secondary inference pricing pages, 2026). The gap is five to six orders of magnitude.

What Igneum could sell by 2030. Not inference proofs for frontier models. Proofs that a committed small model (under 100 M parameters) produced an output from a committed input, batched; proofs of aggregation over many small inferences; proofs of a sampled layer (the hybrid in arXiv 2609.27367) as a job type. developer-adoption.md 2b already draws the line at "verifiable compute, not verifiable AI".

Hours. 40 for a sampled-layer job type once the precompile exists; 0 today.

Per tier. A 24 GB card could prove a small model's inference as a job; nothing for smaller cards; a rollup customer is unaffected.

The Monero core developer's attack. "A lab that wants verifiable inference buys an H100 with a TEE and gets an attestation for free. Your 100,000x-slower proof is for people who do not trust NVIDIA's attestation key, and those people are not buying GPU time from strangers." Fair for 2026 to 2028.

The Kaspa core developer's attack. "Nothing here touches consensus; it is an app on the precompile. Stop listing apps as protocol ideas." Fair.

Verdict: watch the cost curve yearly; the crossing where ZK beats a TEE on cost per token is not in sight by 2030 on the cited numbers.

3.15 The Igneum program pipeline as a verifiable randomness beacon

The idea. The chain already derives an unbiasable seed once an hour: a certified checkpoint, through a 10-minute class-group VDF (spec 04; 516-byte proof, 4.47 ms verify). Run the same VDF on every certified checkpoint hash at a 30-s delay and publish the output: a public randomness beacon at 30-s cadence with no league, no threshold key and no trusted set.

What drand is, cited. The League of Entropy runs drand: threshold BLS over H(round) in unchained mode, a 2/3 threshold of a fixed set of organisations (the threshold must exceed 50 percent), quicknet at 3-s rounds since October 2023, timelock encryption built on it (docs.drand.love quicknet post and cryptography page). Its trust assumption is that under a third of a named set collude.

The model (frontier_model.py section 6):

Beacon	Period	Latency	Unbiasability	Trust
drand quicknet	3 s	about 3 s	threshold BLS, under 1/3 of about 20 organisations collude	a league
Igneum epoch seed today	3,600 s	600 s	certified checkpoint plus a VDF the last producer cannot evaluate in time	nobody
Proposed per-checkpoint beacon	30 s	30 to 60 s	the checkpoint is locked by 2/3 of 30-day weight before the VDF starts; a last-block grind costs a block's subsidy per try and buys a bit only if the attacker evaluates the VDF faster than the chain	nobody; the honest limit is the class-group ASIC (Chia's timelords are software or ASIC, docs.chia.net)

Chia's hardware timelords are the precedent for "the fastest squarer learns the value first" (Boneh, Bonneau, Bünz, Fisch, eprint 2018/601 for the VDF; Chia's class-group VDF competition repository for the implementation lineage). That is a front-running edge measured in seconds, not a bias.

What Igneum already has. The VDF prototype (proto-vdf/), seed_source in headers, PREVRANDAO already defined from the epoch VDF (spec 7.1), the certificate every 30 s.

Hours. 24: a 30-s VDF parameter set and the proof relay per checkpoint (12), an RPC and a wss feed (6), a contract exposing the latest value and a verify function (6).

The gate. 2,880 values a day on the devnet for a week; every value verified by an independent client in under 5 ms; no value published before its checkpoint locked; a deliberate withholding of the last block before a checkpoint measured for its effect on the output (none, because the checkpoint is what is locked).

Per tier. A node operator evaluates one 30-s VDF per checkpoint (one core); a miner does nothing new; an app developer gets a 30-s beacon and timelock encryption; a holder sees a product that drand's users (lotteries, raffles on Sui, approximate) might pay gas for; a rollup customer could read it through the proof bridge.

The Monero core developer's attack. "Your beacon is only as unbiasable as your finality, and your finality pauses whenever under 2/3 of weight is connected (spec 03). A beacon that stops when the chain is partitioned is not a beacon; drand ran through every outage its members had because it needs a threshold, not a supermajority of all." Answer: correct; the beacon publishes nothing during a pause and must say so, which is still a stronger statement than a league's liveness.

The Kaspa core developer's attack. "A 30-s VDF on a 1-BPS chain is fine; at 10 BPS your checkpoints are still 30 s of DAA time, fine; but the VDF input must be the checkpoint hash as every node agrees it, and your C4 finding showed two honest nodes can hold two certified checkpoints at one index for a window. Two beacons." Answer: the beacon for index i is published only when a single certificate for i is in the past of the next certified checkpoint, which is the F24 re-determination path; one window of delay in the worst case.

Verdict: prototype. Twenty-four hours on code that exists, and a product no proof-of-work chain offers.

3.16 The hourly program swap as a research dataset; the fleet library as a product

The idea. Igneum generates 8,760 random GPU kernels a year, compiles each on Metal, CUDA and OpenCL, races up to 17 variants per card (lever 1, measured +17 to +21 percent on the M5 Max), and logs per-card per-variant timings to the fleet log (lever 2). That corpus does not exist anywhere: a continuous stream of random, bit-exact-across-vendors integer kernels with measured performance on every consumer GPU, under a fixed memory footprint. Publish it (the generator is public with the spec; the timings are the product) and the fleet library (the per-card best-variant table) as a dataset.

Who would pay, what for. Compiler teams (LLVM's NVPTX and AMDGPU backends, Apple's Metal compiler) for a regression corpus with ground truth across vendors; GPU microarchitecture researchers for a latency-bound random-read benchmark across generations (the dependent-read ceilings of chip-model-v3.md 5.3 are exactly what such a corpus measures); the project's own cryptanalysts (the weak-program census, weak-program-census-2026-10-03.md) for the distribution of program properties. Money: small (research datasets are grants and goodwill, not revenue); standing: large, and it is the public benchmark the litepaper promises for January 2027 made continuous.

Why nobody shipped it. RandomX programs are per hash, interpreted, and never logged; ProgPoW's period changes were never published as a corpus (approximate). New as a dataset.

Hours. 10: a daily export of the fleet log and the generator seed list to a public bucket with a schema (6), a README with the citation form (4).

The gate. One outside group cites it.

Per tier. Every miner's timings are in it (anonymised to card model); a 9070 XT owner sees why their card is 7x worse per joule than a 5090 on dependent reads (chip-model-v3.md 5.8); nothing else changes.

The Monero core developer's attack. "A public corpus of your programs with timings is the chip designer's training set." Answer: the generator is public already (github.com/igneum-network/spec) and a chip must run next hour's program, not last year's; what the corpus gives a chip designer is the distribution, which the spec gives too.

The Kaspa core developer's attack. "Not a consensus matter." Correct.

Verdict: do now. Ten hours and it makes the benchmark promise continuous.

---

4. What would make a Monero or Kaspa core developer say "I had not thought of that"

Three, with the exact reasoning each would use to attack it. The first two are 3.2 and 3.3 restated as the thing that is new; the third is new in this file.

4.1 Work as the only stake, and it is slashable

Monero's and Kaspa's shared premise: in proof of work nothing is at stake except the block you are mining, so misbehaviour by a miner outside block production (a bad job, a withheld proof) cannot be punished, only priced. Igneum's finality weight is a quantity that is at stake, is earned by work alone over 30 days, cannot be transferred, and is already stripped for equivocation. Extending the strip to execution-layer faults (3.2) gives proof of work a slashable bond with no coin and no stake class.

The Monero developer's attack, verbatim form. "Then it is stake. You have a class of participants with something to lose that others do not, and a rule that takes it from them for a judgement call. Every argument you make against proof of stake (capture, cartels, nothing-at-stake inverted into everything-at-stake) applies to a stake made of blocks. Worse, your stake depreciates on its own in 30 days, so the rational prover front-loads bad behaviour in the last days of its weight." Answer: the weight is not transferable and not purchasable, which removes capture by capital; the last-days attack is bounded by the 30-day re-earn, and the sortition is proportional to current weight, so a depreciating key is drawn less. The concession: the spec must stop saying "no stake" and say "no coin stake; the only thing at stake is 30 days of public work".

The Kaspa developer's attack. "Any slashing condition needs an objective, deterministic fault; on a DAG 'late' needs a clock, and your clock is DAA score along the carrier's chain, which is deterministic. Fine. But you now have a second use for the weight table that the finality module computes, and the two uses must read the same table at the same block or two honest nodes strip differently. Your proof-record rule needed P11 for this; write the same sentence now." Accepted.

4.2 Finality carried forward inside the execution proof

The Kaspa premise: finality on a DAG is a fork-choice property computed by every node from the DAG it holds; it cannot be a proof. The Monero premise: a light client trusts whatever gave it the checkpoint. Igneum's segment proof already recurses from genesis; carrying the weight table in it (3.3) makes "certified under rule v2" a public output of the same proof that attests the state root, with the update costing one mergeset per segment, not a 30-day window per proof.

The Kaspa developer's attack. "The proof attests a chain; finality is about the DAG. Your W2 counts blue blocks in the chain block's past, and 'blue' is GHOSTDAG's judgement, which the proof does not recompute (it would have to run GHOSTDAG over k = 18 or 124 anticone sets inside a zkVM). So the proof takes blueness as a witness from the node, and a node that lies about which blocks are blue gives the proof a wrong table. You have proven the arithmetic and trusted the colouring." This is the sharp one. Answer: the colouring is committed by the header (the mergeset and blue set are determined by the parents, which the header commits to), so the witness is checkable against headers the proof also carries; but checking it means running GHOSTDAG's blue-set rule for each merged block inside the guest, which is bounded (anticone size at most k) and unmeasured. The gate for 3.3 must add: cycle count of the GHOSTDAG colouring check per mergeset inside the guest, and if it is too heavy, the colouring stays a witness and the light client's trust row says "blue set from nodes" until it is not.

The Monero developer's attack. "You have made finality depend on your proof system's soundness in the light client. Say so on the card." Already in spec 10.1 for the proof system row; the row must now name finality too.

4.3 The hourly program as an 8,760-question hardware census

The idea. Every hour the chain hands every card a new random program and every card races 17 compiled variants of it and reports which won and how fast (lever 1, measured; lever 2, shipped). A chip built for the lottery cannot look like a GPU on 8,760 different programs a year: its best variant, its timing distribution across programs, its sensitivity to instruction mix are a fingerprint. Make the fingerprint part of the share protocol: a pool records, per member and per epoch, the variant that won and the share-rate ratio between consecutive programs; the chain's observer publishes the distribution per card model from the fleet library; a key whose ratio pattern sits outside every known card's envelope for N epochs is flagged publicly (the share-pattern detector of Counter ASIC item 4, which found Monero's chips by nonce patterns, now with a per-program timing axis a chip must fake 24 times a day).

Why it is new. RandomX programs are per hash and no pool sees their timing; Monero's chip detection used nonce distributions (MoneroCrusher, approximate); ProgPoW audits priced the chip but had no running census. Igneum's hourly swap with per-card racing produces the census as a by-product. New.

The Monero developer's attack. "Timing is self-reported. A chip reports whatever a 4090 would report; it has the 4090's published envelope from your own dataset (3.16). And MoneroCrusher found us the chips not by timing but by nonce patterns, which a chip emulates trivially once it knows you look. Detection that depends on the attacker's cooperation is theatre." Answer: the share rate per epoch is not self-reported; it is the pool's count of verified shares, and a chip that throttles itself to a 4090's per-program envelope on every program forfeits its edge on the programs where it is strong, which is a cost measured in hash. The detector cannot prove a chip; it can price the chip's camouflage. That is the honest claim.

The Kaspa developer's attack. "We welcomed chips, so nothing here is for us. But as engineering: your per-epoch ratio depends on the pool's vardiff and on network luck; the envelope for one card model will be wide, and a 2x chip sits inside it. Your detector finds a 10x chip and misses the 2x one your model says is the threat." Fair: the detector's resolution is the gate (one epoch's share-rate variance per member at one share per 10 s is about 5 percent over an hour; a 2x step is 40 standard deviations, a 1.2x step 4; so it resolves 1.2x in a day and 1.05x in a month, approximate).

Hours. 16: the per-epoch ratio in the pool protocol's stats (spec 9.5) and the observer's envelope per card model (12), the public page (4).

The gate. The observer flags a deliberately throttled fleet box (a 5090 capped to a 4070's rate) within 24 epochs, and flags no honest card over a week.

Per tier. Every miner's card model gets an envelope; a home miner on an unusual card (Apple, Intel) must be in the library or will be flagged; pools carry one more statistic; nothing in consensus.

Verdict: watch, then do once the pool protocol exists: it is the cheapest instrument the chain has for the question the chip model cannot answer from a spreadsheet.

---

5. The incremental list

Smaller than the sections above; each with hours and a gate.

#	Item	Hours	Gate	Why now
I1	Expose per-key 30-day weight and blue-block count in IgneumInfo so hashrate forwards and hardware-finance contracts settle from chain state (developer-adoption.md 2c)	6	A forward contract settles on the devnet against getFinalityWeights with no oracle	The data is already maintained for finality
I2	Write the N schedule (latency-shadow program length) into the era draw at genesis, a doubling per era until the verifier gate binds (section 2.3)	8 (spec text and the draw)	Verifier under 10 ms on a 2019-class core at the year-6 N	HBM4 arrives in 2027 to 2028 and the chain must answer it without a release
I3	Define the block-proof target as a function of the fleet's measured median shard time, published per era, not as "under 10 s" (section 2.6)	4	The site reads it from the bench table	Honesty about the 12 GB tier
I4	A second zkVM implementation of the ProofSystem trait (RISC Zero or OpenVM) running on one fleet box as a shadow verifier, so a soundness bug in one system is detected by disagreement before it reaches a light client	24	1,000 segments agree across both; one injected bad proof disagrees	Ledger P7, D6: the veto protects full nodes, nothing protects light clients today
I5	The Ember updater installs nothing while finality is paused (3.7's Kaspa attack)	2	A paused devnet, a published release, no install	Free
I6	A finality-pause page on the site that shows the connected weight fraction live, so the "node reports the pause" sentence has a public face	4	Shows tonight's 18:42Z pause from the observer's data	Tonight's incident
I7	Equivocation-evidence bounty paid in sortition slots: the key that first carries valid evidence inherits the stripped key's shard assignments for 30 days (no coins move; weight is reassigned, not created)	12	Two signers under one key on the fast-time harness; the evidence carrier wins the stripped key's draws	Makes watching for equivocation pay without a treasury
I8	Mandatory proofs activation height set from a measured coverage share (spec 7.8 item 10)	4	Coverage above 99 percent for 7 days on the devnet	The rule is written and off
I9	The exclusive window at 25 s and the claim timeout at 120 s on the phase 4 devnet (decided by the founder, P9) with the economy simulator re-run at the measured shard times from prover-tiers-real-cards.md instead of the 20-s target	6	The 3060 class's shard share within 5 points of its weight share	The inputs changed today
I10	eth_getProof, debug_traceTransaction, eth_subscribe (D5 step 2) before any outside team	24	Foundry's debugger and the Blockscout fork run against a devnet node	The light client and every tool depend on eth_getProof
I11	Register chain ids 4461 to 4463 on ethereum-lists/chains before the public testnet (spec 7.1)	1	The PR merged	Wallets
I12	Publish the 2028 tier table (section 2.6) on the miner page with its three rates, so no card owner buys on a promise	2	Live	the founder's consequences rule
I13	A spec sentence in 03 and 05: "no coin stake; the only thing at stake is 30 days of public work" (4.1)	1	Text	Before 3.2 is prototyped
I14	The litepaper's income table gains the proving-market arithmetic of 3.11 in one line	1	Text	Ledger P6 asked for honesty; the number makes it concrete
I15	A ledger entry beside E4 recording 3.6 as considered and rejected on E4's ground	1	Text	So the question is not re-asked

---

6. Open questions and what I could not run

• The BLS verification cycle count inside the SP1 guest (3.3's gate a) needs a 24 GB card; PC 2 and the fleet were on the class v4 rehearsal and the Devnet 2 block-rate runs tonight. Without it, the 3 percent proving-capacity cost is an estimate.
• The GHOSTDAG colouring check inside the guest (4.2's Kaspa attack) is unmeasured and may be the real cost of 3.3; it is added to that gate.
• The wrapper (3.4) does not exist in the repository (ledger P3, R4); the 16 hours include building it on a fleet card.
• HBM4 energy per random read (section 2.3) is an unsourced estimate (1.0 nJ); JEDEC timing is behind the paywall; the 2x channel count is cited, the tFAW-per-channel assumption is mine.
• The rental-tax rule's determinism (3.1) depends on reading W30 and H_now at a checkpoint in the block's past; the lag's effect on the renter's first 30 s is unmodelled.
• Vast.ai's actual take is unpublished; the 15 percent is secondary.
• No Coinbase paper on useful work was found; if one exists its title is needed to cite it.
• block-rate-devnet2.md was a template at writing time; the 10 BPS question matters for 3.3 (segments re-cut at reorgs) and 3.5 (votes per block), and should be re-read when RUN_A lands.
• Lane 8 holds the shadow-useful puzzle (3.10's handover) and anything about new puzzle shapes; nothing here designs a puzzle.

---

7. Summary for the coordinator

Lane 7 read the spec, the litepaper, the ledger sections asked, the design files, the chip model and the fleet's eleven-card table, searched prior art for sixteen ideas, and wrote one arithmetic model (sim/horizon/frontier/frontier_model.py) behind every number. Three findings:

1. HBM4 raises the stored-dataset chip's per-joule edge from about 7x to about 11x bare and from about 2.3x to about 2.7x under the class v4 latency shadow at N = 100,000 (model 1.4, every chip figure arithmetic), because JEDEC doubled channels per stack (16 to 32); N = 200,000 brings it to 1.7x and N = 330,000 to 1.3x at k = 1. The N schedule belongs in the era draw at genesis (I2), with 10x of verifier headroom.
2. Vote weight is a slashable, non-purchasable bond (3.2): a key with 0.1 percent of hash has 16,427 IGN of 30-day pool income and its vote at risk against a designed coin bond of 0.0015 IGN per job (model section 3). The design's "no stake" must become "no coin stake".
3. The consensus proof can be incremental (3.3): carry the W2 table inside the recursive segment proof and update it by one mergeset per segment, with one BLS verify per 30 s (about one shard's budget, approximate, unmeasured). It is the only road to a browser that trusts no node for the voter set, and its real cost is the GHOSTDAG colouring check inside the guest (4.2), which is the first measurement to run.

Two honest nevers with arithmetic: proving others' chains cannot be the main income by 2030 (all of Ethereum L1's proving is USD 36 a day at the Sep 2026 tracker cost against USD 13,700 a day of year-1 emission at USD 0.005; 3.11), and the lottery hash cannot be partly a proof without re-opening Aleo and breaking the DAG's memoryless election (3.10). One rule for main: the litepaper's "proving: a second income" line should carry the 3.11 arithmetic (I14), and the spec should carry the "no coin stake" sentence (I13) before any work-stake prototype starts.