diff --git a/docs/analysis/income-tiers.md b/docs/analysis/income-tiers.md new file mode 100644 index 00000000..a854d9b0 --- /dev/null +++ b/docs/analysis/income-tiers.md @@ -0,0 +1,94 @@ +# Mining income per tier on igneum-testnet-1 + +Generated by `tools/launch/income-tiers.mjs` from `tools/launch/income-tiers.json` (mission item 10, the consequences rule). Do not edit by hand: `node tools/launch/income-tiers.mjs` rewrites it and `--check` fails CI when the two disagree. Every rate and watt figure is a measurement with its source in the first table; nothing is estimated. Testnet coins have no value and the figures below say nothing about any price: the dollar columns are electricity, a cost the reader computes from a measured watt figure and a tariff they choose. + +## The schedule the figures use + +`EmissionSchedule::TESTNET_1` (the testnet genesis, decided 7 October 2026): 100 IGN a block at one block a second, a 90-day ramp from 10 percent, a monthly glide with a two-year half-life (each month pays 2^(-1/24) of the month before), then 1 percent of supply a year from about year 11.4. Of each block, 80 percent goes to the miner who found it and 20 percent to the proving pool. A miner whose key signs its checkpoints keeps the full 80 percent; an unsigned key gives a tenth of it to the proving pool. + +| Moment | IGN a block to the miner | Of the launch figure | +|---|---|---| +| day 1 | 8.00 | 10.0% | +| day 30 | 32.00 | 40.0% | +| day 90 (ramp over) | 75.51 | 94.4% | +| month 12 | 58.23 | 72.8% | +| year 2 | 41.17 | 51.5% | + +A solo card's expected income is its share of network hash times 86,400 blocks a day times the figure above. The tables use day 90, when the ramp is over. Before that, multiply by the ramp row; after that, by the glide row. A pool user gets the same expected amount minus the pool's fee (pool-0: 1 percent) with the variance taken out; the reference pool holds no balance and pays from the coinbase split. + +## The cards, measured + +6 October 2026, rented single-card Linux boxes (docs/analysis/prover-tiers-real-cards.md, bench log 'Prover tiers on real cards: the rented fleet, 6 October 2026'): the 0.3.12 miner on the ten-field override, the miner alone on the card, nvidia-smi power at the same second. The RX 9070 XT row is the telemetry run of 5 October 2026 on a Windows rig (bench log 'Power, heat, fans and clocks, measured'); the Apple row is the Metal bench of 4 October 2026 (site/miner-bench.json, class v4). The class v4 rates on the live devnet run lower than the ten-field rates on the same card (RTX 5090: 124.2 MH/s class v4 against 98.5 on the rented box under a different driver and container, docs/bench-log.md); the table is re-generated at the testnet cut from that class. + +| Tier | Card | MH/s | W | MH/W | Source | +|---|---|---|---|---|---| +| 8 GB | NVIDIA RTX 4060 Ti 8 GB | 19.07 | 72.6 | 0.263 | docs/analysis/prover-tiers-real-cards.md, RTX 4060 Ti 8 GB row | +| 8 GB | NVIDIA RTX 4060 | 17.07 | owed | owed | docs/analysis/prover-tiers-real-cards.md, RTX 4060 row (the sampler read 0.0 W on that host: power OWED) | +| 12 GB | NVIDIA RTX 3060 | 23.78 | 103.7 | 0.229 | docs/analysis/prover-tiers-real-cards.md, RTX 3060 row | +| 12 GB | NVIDIA RTX 4070 | 24.99 | 91.1 | 0.274 | docs/analysis/prover-tiers-real-cards.md, RTX 4070 row | +| 12 GB | NVIDIA RTX 5070 | 41.89 | 137.0 | 0.306 | docs/analysis/prover-tiers-real-cards.md, RTX 5070 row | +| 16 GB | NVIDIA RTX 4060 Ti 16 GB | 17.58 | 72.3 | 0.243 | docs/analysis/prover-tiers-real-cards.md, RTX 4060 Ti 16 GB row | +| 16 GB | AMD RX 9070 XT | 18.60 | 199.0 | 0.093 | docs/bench-log.md, 'Power, heat, fans and clocks, measured' (5 October 2026): 18.6 to 19.2 MH/s, 199 W read by the ADLX helper at 100 percent busy | +| 24 GB | NVIDIA RTX 3090 | 37.79 | 228.8 | 0.165 | docs/analysis/prover-tiers-real-cards.md, RTX 3090 row | +| 24 GB | NVIDIA RTX 4090 | 52.25 | 183.1 | 0.285 | docs/analysis/prover-tiers-real-cards.md, RTX 4090 row | +| 32 GB | NVIDIA RTX 5090 | 98.48 | 258.2 | 0.381 | docs/analysis/prover-tiers-real-cards.md, RTX 5090 row (the rented box; 124.2 MH/s class v4 on a desktop, site/miner-bench.json) | +| Apple | Apple M5 Max (40 GPU cores) | 26.70 | owed | owed | site/miner-bench.json, Apple M5 Max class v4 row, 4 October 2026 (no power reading: OWED) | + +## IGN a day per card, solo, after the ramp (day 90) + +Three network sizes, because income is a share of the network and nobody knows the network before it exists. 1 GH/s, 10 GH/s, 100 GH/s are reference sizes, not forecasts. The live network's estimate is on /live; divide by it. + +| Tier | Card | at 1 GH/s | at 10 GH/s | at 100 GH/s | +|---|---|---|---|---| +| 8 GB | NVIDIA RTX 4060 Ti 8 GB | 124,414 | 12,441 | 1,244.1 | +| 8 GB | NVIDIA RTX 4060 | 111,366 | 11,137 | 1,113.7 | +| 12 GB | NVIDIA RTX 3060 | 155,142 | 15,514 | 1,551.4 | +| 12 GB | NVIDIA RTX 4070 | 163,036 | 16,304 | 1,630.4 | +| 12 GB | NVIDIA RTX 5070 | 273,293 | 27,329 | 2,732.9 | +| 16 GB | NVIDIA RTX 4060 Ti 16 GB | 114,693 | 11,469 | 1,146.9 | +| 16 GB | AMD RX 9070 XT | 121,348 | 12,135 | 1,213.5 | +| 24 GB | NVIDIA RTX 3090 | 246,544 | 24,654 | 2,465.4 | +| 24 GB | NVIDIA RTX 4090 | 340,882 | 34,088 | 3,408.8 | +| 32 GB | NVIDIA RTX 5090 | 642,489 | 64,249 | 6,424.9 | +| Apple | Apple M5 Max (40 GPU cores) | 174,192 | 17,419 | 1,741.9 | +| Rig | 6 x NVIDIA RTX 4070 | 978,217 | 97,822 | 9,782.2 | + +## Electricity a day, and the electricity cost of one mined IGN + +Electricity a day = measured watts x 24 h x the tariff. The cost of one IGN divides that by the day-90 figure at 10 GH/s; at another network size it scales with the network (ten times the network, ten times the cost per coin). The three tariffs: USD 0.05 a kWh is cheap industrial power, USD 0.10 is a US retail rate, USD 0.25 is a UK retail rate at today's level (each approximate; tariffs move, the watt figures do not). + +| Tier | Card | USD/day at 0.05/kWh | USD/day at 0.1/kWh | USD/day at 0.25/kWh | USD per IGN at 0.05/kWh | USD per IGN at 0.1/kWh | USD per IGN at 0.25/kWh | +|---|---|---|---|---|---|---|---| +| 8 GB | NVIDIA RTX 4060 Ti 8 GB | 0.087 | 0.174 | 0.436 | 0.000007 | 0.000014 | 0.000035 | +| 8 GB | NVIDIA RTX 4060 | owed | owed | owed | owed | owed | owed | +| 12 GB | NVIDIA RTX 3060 | 0.124 | 0.249 | 0.622 | 0.00000802 | 0.000016 | 0.0000401 | +| 12 GB | NVIDIA RTX 4070 | 0.109 | 0.219 | 0.547 | 0.00000671 | 0.0000134 | 0.0000335 | +| 12 GB | NVIDIA RTX 5070 | 0.164 | 0.329 | 0.822 | 0.00000602 | 0.000012 | 0.0000301 | +| 16 GB | NVIDIA RTX 4060 Ti 16 GB | 0.087 | 0.174 | 0.434 | 0.00000756 | 0.0000151 | 0.0000378 | +| 16 GB | AMD RX 9070 XT | 0.239 | 0.478 | 1.19 | 0.0000197 | 0.0000394 | 0.0000984 | +| 24 GB | NVIDIA RTX 3090 | 0.275 | 0.549 | 1.37 | 0.0000111 | 0.0000223 | 0.0000557 | +| 24 GB | NVIDIA RTX 4090 | 0.220 | 0.439 | 1.10 | 0.00000645 | 0.0000129 | 0.0000322 | +| 32 GB | NVIDIA RTX 5090 | 0.310 | 0.620 | 1.55 | 0.00000482 | 0.00000964 | 0.0000241 | +| Apple | Apple M5 Max (40 GPU cores) | owed | owed | owed | owed | owed | owed | +| Rig | 6 x NVIDIA RTX 4070 (a six-card rig of the 12 GB card, the rig's own power is six times the card's plus the host (the host is not measured here)) | 0.656 | 1.31 | 3.28 | 0.00000671 | 0.0000134 | 0.0000335 | + +## What it means per tier, and what is being done + +- **One 8 GB card.** NVIDIA RTX 4060 Ti 8 GB: 19.1 MH/s at 73 W, 12,441 IGN a day at 10 GH/s after the ramp, electricity 0.174 a day at USD 0.10 a kWh. Mines; proves only core-only shards (docs/analysis/prover-tiers-real-cards.md). The record says this tier is first under power in every exit (docs/analysis/mission/past.md section 3): the glide never halves it overnight, and the card games when the income goes. Being done: the Cards screen shows the expected MH/s, W and blocks a day before the first share (mission item 6). +- **One 12 GB card.** NVIDIA RTX 5070: 41.9 MH/s at 137 W, 27,329 IGN a day at 10 GH/s after the ramp, electricity 0.329 a day at USD 0.10 a kWh. Mines and proves beside the miner on the patched server. Being done: the same Cards line; the proving tier sentence names the shard size the card takes. +- **One 16 GB card.** NVIDIA RTX 4060 Ti 16 GB: 17.6 MH/s at 72 W, 11,469 IGN a day at 10 GH/s after the ramp, electricity 0.174 a day at USD 0.10 a kWh. Mines and proves; the AMD row is the measured 9070 XT, 199 W for 18.6 MH/s, so per watt it is about a fifth of the NVIDIA cards of its tier and the electricity cost per coin is the highest in the table. Being done: the AMD read-width experiment (docs/plans/read-width.md); until it lands the AMD tier is told its per-watt figure before it buys. +- **One 24 or 32 GB card.** NVIDIA RTX 5090: 98.5 MH/s at 258 W, 64,249 IGN a day at 10 GH/s after the ramp, electricity 0.620 a day at USD 0.10 a kWh. The last GPU standing in every exit on record, and the only tier that proves the full shard beside the miner. Being done: the proving pool is the second income for this tier and the Earnings screen shows shards and IGN beside blocks. +- **A rig.** 6 x NVIDIA RTX 4070: cards times the card figure; the host's own draw is not measured and is owed. Rigs followed income across chains inside days on every chain in the record; Igneum expects no loyalty and pays staying keys a vote (30 days of blocks). +- **A pool user.** The same expected IGN minus the pool's fee, variance removed; pool-0 holds no balance and the member's own key is in every block it finds, so a pool's vote is the member's weight. Being done: the pool finished (mission item 11). +- **Windows, Linux, macOS.** The rates above are Linux containers (NVIDIA) and Windows (AMD); the Mac row is Metal on Apple silicon with no power reading. The same card on another operating system is within the driver's margin, not measured here: owed per platform at the testnet cut. + +## Owed + +- Intel discrete (Arc): no measurement; the tier is listed with no number until one exists +- RTX 4060 and Apple M5 Max wall power: the rows carry the rate and no electricity column +- every row at class v4 on the testnet cut: the rates above are the ten-field class of 6 October 2026 on rented boxes +- a rig host's own draw: a rig row is cards times the card figure, host excluded + +## Check + +`node tools/launch/income-tiers.mjs --check` (in `tools/ci/pre-push.sh`): the file equals the generator's output. `node --test tools/launch/income-tiers.test.mjs`: the schedule arithmetic against the fork's constants (100 MH/s on 100 GH/s after the ramp = 6,912 IGN a day, the figure in docs/analysis/horizon-2026-10.md; day 1 pays 10 percent; one month step pays 97.153 percent of the one before). diff --git a/docs/analysis/mission/future.md b/docs/analysis/mission/future.md new file mode 100644 index 00000000..5bc8cc13 --- /dev/null +++ b/docs/analysis/mission/future.md @@ -0,0 +1,566 @@ +# The last mission, lane 3: the far future, 2030 to 2036 + +Written 7 October 2026 by the future lane. Scope: the ten-year axes Horizon lane 7 did not cover, and the years 2030 to 2036 on the axes it did. Lane 7's rows to 2030 (`docs/analysis/horizon/frontier.md` 2.1 to 2.6) are taken as given and not repeated; where this lane disagrees, the row is named and the reason sourced. Every figure from memory is labelled approximate. Every figure from a source names it, with a URL in the sources list and the access date (all accessed 7 October 2026 unless stated). Times are UK. The arithmetic behind sections 2, 3, 4, 6 and 7 is `model.py` in this lane's scratch directory (`scratchpad/mission-future/`), reproduced in the tables. + +The design this lane tests (horizon-2026-10.md section 1): an hourly random GPU program, a 256 MiB cache over a daily multi-GB dataset (2 GiB at genesis, doubling at years 4, 12, 28), latency-shadow work in a six-rung N ladder stepped by 90 percent miner signal, class v5 (dataset from chain state) as a candidate, miner-only finality with BLS vote keys weighted by 30 days of blocks, SP1 zkEVM proving by miners (the 20 percent pool), 100 IGN a block gliding to a 1 percent tail, no stake, no dev fund, no other chain in consensus. + +## 0. Progress + +| Time (UK) | State | +|---|---| +| 08:2x | Brief read: CLAUDE.md, frontier.md 2 and 6, algorithm.md 5, chip-model-v3.md 5, horizon-2026-10.md 1, finality-in-proof.md 4, 51-percent.md, bench-log rental entry | +| 08:3x to 08:5x | 50 web searches (the session's search budget ran out at 50; the rest went by direct fetch), 27 primary fetches | +| 08:5x | Model run (`model.py`): emission by year, chip thresholds, rental curve, heat credit, PQ bytes, wallet battery | +| 08:5x to 09:00 | Sections 1 to 11 written, 566 lines, copy-law check clean (no em or en dashes, ASCII only) | +| 09:00 | DONE. File handed to the coordinator. Nothing committed; nothing on the devnet touched; no build or measurement run | + +The tiers, used in every row: home miner with one 8, 12, 16, 24 or 32 GB card; a rig; a pool user; on Windows, Linux, macOS; NVIDIA, AMD, Apple. + +## 1. GPU and memory roadmaps, 2027 to 2036 + +### 1.1 The roadmap, sourced + +| Item | What is announced or reported | Source | Label | +|---|---|---|---| +| HBM4 | Mass production at Samsung and SK hynix from February 2026; 2,048-bit interface, 8 Gbps a pin, about 2 TB/s a stack; 12-high 36 GB; SK hynix 16-high 48 GB from Q3 2026; Micron samples over 11 Gbps, 2.8 TB/s | TrendForce 9 Jan 2026; EE Times CES 2026; Astute Group | cited | +| HBM4 price | About USD 550 a 36 GB stack, USD 15.3 per GB (factory gate) | siliconanalysts.com/tools/hbm-analysis | approximate (the site cites no primary) | +| HBM4E | Late 2027 to 2028; 14 to 16 Gbps a pin, 3.6 to 4.0 TB/s a stack; 16-high; custom base dies on TSMC N3 (the GUC and TSMC "C-HBM4E" line, 12.8 GT/s by 2027); Samsung HBM4E samples May 2026 at 3.6 TB/s | TrendForce 23 Dec 2024; Tom's Hardware (TSMC/GUC); TechTimes 30 May 2026 | cited | +| HBM on a consumer card | None announced. The Feynman datacentre architecture (2028) "supports HBM"; no consumer HBM part from NVIDIA, AMD or Intel on any roadmap found | Wikipedia Feynman page; the 2027 to 2028 rumour set | cited (absence) | +| GDDR8 | No JEDEC standard. SK hynix's roadmap to 2031 lists "GDDR7-Next" for 2029 to 2031 | Tom's Hardware (SK hynix roadmap); TechSpot | cited | +| GDDR7 devices | 2 GB ended at Micron (Sep 2026); 3 GB shipping at USD 60 to 70; 4 GB and 6 GB devices reported for 2027 to 2028 | chip-model-v3 5.1; wccftech; club386 | 3 GB cited, 4 and 6 GB rumour | +| RTX 60 (Rubin GR20x) | Late 2027 slipped to 2028; GDDR7; the 6090 reported at 512-bit with 32 GB or 48 GB | TweakTown; wccftech; BigGo | rumour | +| AMD RDNA 5 / UDNA | Mid-2027 to 2028; GDDR7 at 36 Gbps; flagship "AT0" 154 CUs, 36 GB on 384-bit, 1.7 TB/s, 380 W; shares a chiplet design with the next Xbox; GDDR7 support landed in the Linux driver | TweakTown; TechPowerUp; Tom's Hardware driver note | rumour, driver patch cited | +| NVIDIA consumer chiplets | Nothing reported; Rubin consumer parts described as monolithic | the same rumour set | approximate | +| Strix Halo class | Strix Halo: 256-bit LPDDR5X-8000, 256 GB/s. Medusa Halo (2027 to 2028): LPDDR6 on 256-bit (461 GB/s) or 384-bit (691 GB/s) | VideoCardz; hardware-corner.net | rumour | +| Apple | M5 Max: up to 128 GB unified, 614 GB/s (40-core GPU), 460 GB/s (32-core); M5 Ultra Mac Studio August 2026 | Apple newsroom 3 Mar 2026 and Aug 2026 | cited | +| LPDDR6 | JESD209-6 published July 2025; 2 sub-channels a die, 12 DQ each, 4 CA each; activate timings not public | JEDEC press release | cited; timings unknown | +| DDR5 | 32 banks in 8 groups of 4 (x4/x8); JESD79-5D Nov 2025; tFAW a four-activate window | JEDEC; DDR5 core datasheet | cited | +| The latency floor | "The latencies of three fundamental DRAM operations have not improved significantly in the past 18 years"; improvements "relatively stagnant for the last two decades" | Lee et al. (arXiv 1604.08041); Chang et al. (arXiv 1805.03154) | cited | + +### 1.2 What it means for the memory-latency-bound hash + +The hash advances one dependent 4-byte read per memory latency; the rate is activates per tFAW window times channels, and energy is per activate (chip-model-v3 5.3). Pin speed does not move it. So the ten-year question is only: do channels per watt per dollar move, and does tRC or tFAW move. The sources say tRC has been flat for about twenty years, and no DRAM roadmap to 2031 (SK hynix) names a row-cycle improvement. HBM4 doubles channels per stack (lane 7, 2.3). HBM4E adds pin speed and a custom base die, not channels. GDDR7-Next is 2029 to 2031 and unspecified. Consumer HBM does not exist on any roadmap to 2028. + +| Year | Flagship consumer memory (projected) | Random reads per second, flagship (approximate) | Mid-tier card (12 to 16 GB) | Tier that wins or loses against 2026 | +|---|---|---|---|---| +| 2026 | 32 GB GDDR7, 512-bit, 16 devices | 17.5 G measured (5090) | 12 GB, 192-bit, 6 devices: about 6.5 G | baseline | +| 2028 | 36 to 48 GB GDDR7, 384 to 512-bit (RDNA 5 rumour, RTX 60 rumour) | 16 to 21 G: the same, capacity adds no channels | 16 to 18 GB on the same channel count (3 GB devices): the same rate | nobody: a 2026 card keeps its rate against a 2028 card | +| 2031 | 48 to 64 GB GDDR7-Next (SK hynix window) | unknown; if channels per device rise to 8 (approximate guess), 1.5 to 2x | 24 GB mid-tier on the same count | the 2026 owner falls to 0.5 to 0.7x of the new card, the normal GPU cadence | +| 2036 | 64 to 96 GB (extrapolation of lane 7's 1.167 a year); HBM on a halo consumer part possible but unannounced | 2 to 4x of 2026 if a consumer HBM4-class part ships; otherwise 1.5 to 2x | 32 GB mid-tier | the 8 and 12 GB tiers are gone from the installed base (Steam trend, algorithm.md 5.6), not from the hash | + +Apple and APUs: the M5 Max's 614 GB/s is a 512-bit LPDDR5X bus (approximate); LPDDR activates are the same DRAM physics, so the Apple tier stays "0.78 uJ per hash, 21 W" class (algorithm.md 5.3a), the best per joule and the worst per dollar (USD 129 per MH/s). Medusa Halo on 384-bit LPDDR6 would be a 24 to 36 channel part (approximate: 2 sub-channels a die): a mid-tier card's read rate at laptop watts. Consequence per tier: Apple and APU miners stay the per-joule leaders and never the per-dollar ones; nothing in the hash changes that in ten years. + +### 1.3 The cache, the dataset schedule and the ladder, re-read against the roadmap + +| Design item | Roadmap fact | Verdict | Recommendation | +|---|---|---|---| +| 256 MiB cache "above every GPU's on-die cache" (the spec's rule) | 5090 L2 96 MB, GB202 128 MB; MI300X carries 256 MB Infinity Cache (datacentre, approximate from memory); RDNA 3's 7900 XTX 96 MB; no consumer part at 256 MB announced | Safe to 2028. At risk from 2029 to 2031 if a consumer part ships a 256 MB last-level cache, which the datacentre already does | Add a cache-size rung to the era-draw ladder beside N (256 to 512 MiB), stepped by the same 90 percent signal, in place of the fixed year-4 doubling alone; the trigger is a shipped consumer part with LLC at or over the cache size | +| Dataset 2 GiB, doubling at years 4, 12, 28 | Card memory 32 GB now, 48 to 64 GB by 2030 (lane 7); one HBM3 stack holds 24 GB | Right. The dataset is not a lever against the stored-dataset chip (chip-model-v3 5.7) and never binds a tier before year 12 (algorithm.md 5.6) | Hold the schedule; the public card-lifetime sentence should carry the prover footprint, not the dataset (algorithm.md 5.6's one change) | +| N ladder rungs measured on 2026 cards | The honest card's bind point moves with each generation: a 2028 card with the same read rate and 1.5x the ALUs binds at a higher N; HBM4 doubles the chip's rate per stack | Rungs are a 2026 measurement. They are the right shape and the wrong numbers for 2029 | Re-measure the rungs per card generation (the Steam top-10 cards each era) and publish the bind points; the signal mechanism already lets miners refuse a rung their cards cannot hold, so no genesis change, only a measurement duty written into the era-draw docs | +| C-HBM4E custom base die (2027 to 2028) | The base die under the stack becomes a logic die on N3 that a customer designs (TSMC and GUC) | This is the f = 1 chip's controller moved under the memory: the chip-model's "controller and PHY die beside it, 10 W, USD 50, plus a USD 200 one-stack interposer" row (5.3) collapses into the base die. Lane 7's 2.3 did not price it | Disagreement with lane 7 row 2.3 "HBM4 one stack (2028)": the controller and interposer lines fall toward zero, so the HBM4 chip's dollars per MH/s fall below the USD 2.8 GDDR7 figure by 2028, approximate. The answer is unchanged in kind (N, the price per joule) and larger in degree; section 2 carries it | + +Per tier, section 1 in one line each: 8 GB (mines to year 12, never proves beside its miner); 12 GB (mines to year 28, loses mine-and-prove at year 4); 16 GB (mines and proves to year 12); 24 and 32 GB (unconstrained to 2036 on every roadmap found); rig (the rate per card is flat through 2028, so a 2026 rig is a 2028 rig); pool user (the pool's share tracks the installed base, which loses the 8 GB tier by 2030); Windows and Linux (no change); macOS (per-joule best, per-dollar worst, both for ten years); NVIDIA (channel count flat to 2028); AMD (RDNA 5 brings GDDR7, a 36 GB flagship: AMD's first competitive random-read part since the 9070 XT's 2.4 to 2.7 G); Apple (as macOS). + +## 2. The ASIC maker's economics, 2026 to 2036 + +### 2.1 Inputs + +| Input | Value | Source | +|---|---|---| +| Mask set, total NRE: TSMC 28 nm | USD 1 M, 1.8 M | siliconanalysts.com/data/wafer-pricing (Sep 2026) | +| 16 nm | 1.8 M, 3.2 M | same | +| 7 nm | 3.5 M, 5.5 M | same | +| 5 nm | 6.5 M, 10 M | same | +| 3 nm | 15 M, 22 M; design cost of a 3 nm chip USD 400 to 600 M all-in | same; siliconanalysts tsmc-3nm-cost | +| 2 nm | masks USD 15 to 30 M; design cost quoted at USD 724 M | semiwiki thread; siliconanalysts | approximate | +| A16, A14 | no mask quote found; "capex per 1,000 wafers at A14 higher than N2" | semiwiki A14 thread | approximate | +| Wafer, 300 mm | 28 nm 3,000; 16 nm 5,500; 7 nm 9,500; 5 nm 20,000; 3 nm 20,000 (range to 27,000) | siliconanalysts wafer-pricing | cited | +| Leading-edge tapeout, all-in | USD 30 M to 100 M+ at 3 to 5 nm; 5 to 30 M at 7 to 28 nm | siliconanalysts tapeout guide, 1 Mar 2026 | cited | +| The f = 1 chip | 166 MH/s, 78 W bare, 228 W with a 150 W shadow core at k = 1; USD 470 of memory, controller and board; USD 2.8 per MH/s | chip-model-v3 5.4, lane 7 2.3 | model | +| The honest card | 5090 at class v4: 3.27 uJ, 431 W cap, 132 MH/s; USD 1,999 MSRP | algorithm.md 5.3a | measured | +| Emission (model) | 100 IGN a block, 90-day ramp from 10 percent, monthly glide at 2.9 percent, tail 1 percent a year from year 11.4 | tail-emission.md | model | +| Rental equilibrium | hash joins until rent equals subsidy: 39, 156, 780 GH/s at USD 0.005, 0.02, 0.10 per IGN | security-budget.md via 51-percent.md | model | + +Emission by year from the model (IGN, approximate): year 1 2.32 B, year 2 1.87 B, year 3 1.31 B, year 4 0.92 B, year 5 0.65 B, year 6 0.46 B, year 7 0.32 B, year 8 0.23 B, year 9 0.16 B, year 10 0.11 B; supply 4.18 B at the end of year 2, 7.07 B at year 5, 8.33 B at year 10. + +### 2.2 The decision tree, written out + +The maker chooses a target share s of the hash and a node. Revenue over the chip's two-year life is s x E2 x p, where E2 is the two-year emission and p the IGN price. The fleet needed is s/(1 - s) x H(p), and at the rental equilibrium H(p) = 7.8 M MH/s per USD of price, so the fleet's cost is also linear in p: 0.43 x 7.8 M x USD 4.64 per MH/s (the chip's two-year cost per MH/s with power at USD 0.05 per kWh, model) against two-year revenue per MH/s of 0.0117 x 17,520 = USD 205. The fleet term is 2 percent of revenue and drops out. The project pays when p is over p* = C_proj / (s x E2), and the market cap at which it pays is p* x supply. At s = 0.30 (an economic miner just under the veto third): + +| Node (project all-in) | Years 1 to 2 (E2 = 4.18 B) | Years 3 to 4 (2.24 B) | Years 5 to 6 (1.10 B) | Years 7 to 8 (0.55 B) | Years 9 to 10 (0.27 B) | +|---|---|---|---|---|---| +| 28 nm controller only, no shadow core (USD 5 M) | p* 0.0040, cap USD 17 M | 0.0075, 48 M | 0.0151, 114 M | 0.0306, 247 M | 0.0620, 517 M | +| 28 nm controller + N5 shadow core (USD 30 M) | 0.0239, 100 M | 0.0447, 287 M | 0.0906, 682 M | 0.1836, 1,481 M | 0.3718, 3,099 M | +| N3 single die, controller + shadow + lanes (USD 60 M) | 0.0478, 200 M | 0.0895, 574 M | 0.1813, 1,363 M | 0.3672, 2,961 M | 0.7437, 6,198 M | +| N2 (USD 150 M, 2026 quotes) | 0.1195, 500 M | 0.2237, 1,436 M | 0.4532, 3,408 M | 0.9179, 7,403 M | 1.8592, 15,495 M | +| A16 / A14 (USD 250 M, extrapolated) | 0.1992, 833 M | 0.3729, 2,393 M | 0.7553, 5,680 M | 1.5298, 12,339 M | 3.0987, 25,825 M | + +Reading. The stored-dataset chip without a shadow core pays at a USD 17 M market cap in the first two years, because its project is a 28 nm controller (chip-model-v3 5.6) and the chip's hour costs 56x less than rented hash. The class v4 shadow core forces an N5-class die (30 mm^2 at N = 100,000, lane 7) and lifts the bar 6x to USD 100 M. The glide lifts every bar about 2.3x per two years, so by years 9 to 10 the same N5 chip needs a USD 3.1 B cap. Nothing here needs N2 or A16: the chip is memory, and a leading node buys it nothing. So the "ASIC maker's economics at every node" collapses to two nodes, 28 nm and N5, and the N ladder is what moves between them. + +Minimum volume to break even against buying cards (saving USD 2,131 a chip over two years against 5090s at the same hash, model): 28 nm bare 2,346 chips (0.39 TH/s); 28 nm + N5 shadow 14,077 chips (2.34 TH/s); N3 28,155 (4.67 TH/s); N2 70,387 (11.7 TH/s); A14 117,312 (19.5 TH/s). Against the rental-equilibrium hash (39 to 780 GH/s at today's three price inputs) the 2.34 TH/s break-even fleet is 3x to 60x the whole network: the chip only pays once the price is high enough for the network to be a few TH/s, which is the p* column above said another way. + +### 2.3 The memory-controller chip against HBM4, per joule and per dollar, 2026 to 2036 + +| Year | Memory the chip buys | Chip uJ per hash at N = 100,000, k = 1 (approximate) | Honest 5090-class uJ | Edge per joule | Chip USD per MH/s | What moves it | +|---|---|---|---|---|---|---| +| 2026 | GDDR7, 16 x 2 GB | 1.37 | 3.27 | 2.4x | 2.8 | the measured row (algorithm.md 5.3a: 2.1x at the 5090's 431 W cap) | +| 2028 | HBM4, one stack 36 GB, C-HBM4E base die as the controller | 1.33 (algorithm lane's correction of lane 7's 1.11) | 3.3 (a 2028 card at the same read rate) | 2.5x | 2.0 to 2.5 (the interposer and controller rows fall into the base die; approximate) | HBM4 price USD 550 a stack falls as HBM4E takes the premium (approximate) | +| 2031 | HBM4E or HBM5 (SK hynix lists HBM5 on the 2029 to 2031 window) | 1.2 to 1.3 at the same N; 0.9 at N = 100,000 if activates per channel double again | 3.0 to 3.3 | 2.5x to 3.5x | 1.5 to 2.0 | activate parallelism per stack; unsourced beyond HBM4 | +| 2036 | the same class | the per-joule edge is bounded below by N x 11 pJ x k, so at N = 330,000 and k = 1 the chip pays 3.6 uJ of program work whatever its memory | 5.0 at 330,000 (the 5090 is compute-bound there) | 1.3x | 1.5 | N and k only | + +Does the chip get cheaper or dearer per joule as HBM prices fall: dearer in dollars relative to the GPU through 2027 (lane 7 2.2, memory is 70 percent of its bill), cheaper from 2028 when the base die absorbs the controller, and flat per joule, because per joule is set by activates and by N. Per tier: the home 5090 owner stays inside 2.1x to 2.5x of the chip at N = 100,000 through 2031 and inside 1.3x at N = 330,000; the 4070-class 12 GB owner the same within 10 percent; the AMD 9070 XT owner sits at 5x to 8x behind the chip at every rung (its measured 10.6 uJ) and is the first tier a chip displaces; the Apple tier sits under the chip's per-joule line at every rung. The rig owner is a 5090 owner times eight. The pool user inherits the pool's card mix. + +### 2.4 The FPGA route + +AWS F2 (f2.6xlarge, VU47P, 16 GB HBM2, USD 1.98 an hour on demand, USD 0.66 spot) is the measurement the algorithm lane planned (algorithm.md 5.1); nothing has run. The tightened range stands: 2.3 to 2.9 G reads a second a card, 0.30x to 0.47x of the 5090 per watt, at USD 4,000 to 5,000 a card (approximate). Versal HBM and Agilex 7 M-series carry HBM2e (faster pins, the same tFAW), so they sit in the same row. An HBM4-based FPGA (none announced) would carry HBM4's channel count and the 0.3x to 0.5x row would become 0.6x to 1.0x (approximate, derived). Verdict: no FPGA displaces any tier to 2031; the F2 hour should still run, because the per-stack activate rate it measures is the input every row above rests on. + +Recommendation for section 2: (1) the N ladder at genesis, as lane 2 and lane 7 said, with the bind-point re-measurement duty of 1.3; (2) write the p* table into the public threat model with the sentence "a stored-dataset chip pays at about USD 100 M of market cap in year 1 and about USD 700 M in year 5 (model, approximate)"; (3) no genesis parameter changes for N2 or A16, because the chip never needs them. + +## 3. AI compute demand and the GPU supply + +### 3.1 The numbers + +| Row | Value | Source | Label | +|---|---|---|---| +| Datacentre GPUs shipped 2023 | 3.85 M units (NVIDIA 3.76 M, AMD 0.5 M, Intel 0.4 M) | TechInsights via HPCwire, 10 Jun 2024 | cited | +| Datacentre GPUs 2024, 2025 | USD 123 B of GPUs and accelerators in 2024, USD 207 B in 2025 (Omdia); NVIDIA estimated 5.2 M Blackwell GPUs in 2025; GB200 cabinet forecasts cut to 25,000 to 35,000 (2.5 M GPUs) | Omdia Aug 2025; Tom's Hardware | cited, unit counts secondary | +| Installed datacentre fleet by end-2026 | 15 to 20 M Hopper and Blackwell class units (sum of the rows above) | arithmetic | approximate | +| Consumer AIB shipments | Q2 2026 12.5 M units, +10 percent QoQ, +6.6 percent YoY; H1 2026 24.3 M; NVIDIA about 90 percent | Jon Peddie Research Q2 2026 | cited | +| Used H100 | USD 18,000 to 22,000 in 2026; residual 40 to 75 percent at 36 months, 25 to 35 percent at 60+ months; A100 80 GB USD 12,000 to 18,000 | mercatus-ai.com (verified 23 Jun 2026); intuitionlabs | cited, secondary | +| H100 rental | USD 1.49 (Vast.ai hosts) to 6.98 an hour; was over USD 7 in early 2024; spot about USD 1.00 | cloudzero; spheron; shattered.io (2026) | cited | +| Consumer card rental | 5090 USD 0.21 to 0.44 an hour (Vast.ai, 6 Oct 2026); 4090 0.28 to 0.60 | lane 7 2.4 | cited | +| Igneum hash rental | USD 0.0117 per MH/s-hour (RunPod community pods, 38 pods, 1,748 MH/s for USD 20.44 an hour); 8x 4090 rig USD 0.0129; a 5090 pod 98 to 128 MH/s for USD 0.41 to 0.74 | bench-log, 6 Oct 2026 | measured | + +### 3.2 The used-GPU flood, 2027 to 2030 + +Hopper fleets bought in 2023 to 2024 reach the 36-month residual cliff in 2026 to 2027 and the 60-month floor in 2028 to 2029. Can they mine Igneum: the hash is memory-latency-bound, so an H100 is its five HBM3 stacks (80 GB) and an A100 its five HBM2e stacks. At chip-model-v3's unmeasured HBM3 ceiling (10.7 G reads a second a stack) an H100 reads 53 G, 3x a 5090; at the JEDEC tFAW ceiling (2.3 G a stack) 11.5 G, 0.65x. Nobody has measured it; the fleet measured A4000, A5000, L4, 3090 and 4090 (prover-tiers-real-cards.md), not an HBM part. The honest statement: an H100 mines Igneum at 0.65x to 3x of a 5090 at 700 W, which is 0.3x to 1.4x per watt (approximate, both ends unmeasured). + +| Scenario | Hash it adds | Against the rental equilibrium (39 to 780 GH/s) | What the ladder does | +|---|---|---|---| +| 1 percent of a 1 M retired H100 fleet (10,000 cards) at 1x a 5090 | 1.3 TH/s | 2x to 35x the whole network | nothing: the shadow binds compute, and an H100 has 4x a 5090's ALUs per read; it holds every rung | +| 10 percent | 13 TH/s | 17x to 330x | the same | +| Rental at USD 1.49 an hour for 0.65x to 3x of a 5090 | USD 0.0045 to 0.021 per MH/s-hour | at or above today's 0.0117: no cheaper than consumer pods at list price | n/a | +| Idle-time rental (the owner's marginal cost is power) | USD 0.00016 to 0.0007 per MH/s-hour at USD 0.05 per kWh | 17x to 70x under today's rent | n/a | + +The ladder is a joule argument against a fixed-datapath chip; against a GPU with more ALUs it is silent. The used-fleet question is a price question only. + +### 3.3 The ten-year rental curve and the 51 percent table + +The H100 rate fell about 45 percent a year from early 2024 to 2026 (USD 7+ to about 2); consumer-card rent fell as purchase prices rose (lane 7 2.4). Three curves for USD per MH/s-hour from today's 0.0117 (model): + +| Year | At -20 percent a year | At -30 percent a year | At -45 percent a year | +|---|---|---|---| +| 2028 | 0.0075 | 0.0057 | 0.0035 | +| 2031 | 0.0038 | 0.0020 | 0.0006 | +| 2036 | 0.0013 | 0.0003 | 0.00003 | + +What it does to `51-percent.md`: nothing to the dollar cost of any attack, because every row there is priced at the rental equilibrium, where rent equals subsidy. A cheaper rent means more hash joins until rent equals subsidy again: at 2036's -30 percent curve the equilibrium hash is 35x today's at the same IGN price, and the attack costs the same twelve days of emission. What the curve changes is the home card's share of the subsidy, which falls 35x with the hash, and the supply ceiling of the rental market, which stays the real limit (the market gave zero pods when asked for twenty, bench-log). Update the 51-percent price basis each year from a measured rental, not from a curve. + +### 3.4 Per tier: does a home card stay competitive against an idle datacentre card + +Cost per MH/s-hour, electricity only, a 5090-class card at 3.27 uJ (model): + +| Owner and power price | USD per MH/s-hour | Margin under today's 0.0117 rent | Margin if idle datacentre hash sets the rent (0.00016) | +|---|---|---|---| +| UK home, 26.32 p (Ofgem cap, Q4 2026) | 0.00114 | 10x | loses 7x | +| Germany home, EUR 0.387 | 0.00137 | 9x | loses 9x | +| US home, 17.7 c (EIA, H2 2025) | 0.00058 | 20x | loses 4x | +| Texas industrial, 5 c (approximate) | 0.00016 | 72x | break-even | +| Paraguay, 4.4 to 6 c (ANDE crypto tariff, Decree 7824/2022, contracts end 31 Dec 2027) | 0.00016 | 72x | break-even | +| Iran, licensed, about 1 c | 0.00003 | 358x | wins | + +The home card is competitive while the marginal supplier of hash is a rented consumer pod at list price (today). It is not competitive the day the marginal supplier is an idle datacentre card on industrial power, and the used-fleet flood of 3.2 makes that day a price event, not a technology event. Per tier: 8 and 12 GB home cards lose first (their uJ is 1.3 to 1.7x worse than the 5090's); 24 and 32 GB cards last; a rig is a home card eight times, on the same power price; a pool user's payout tracks the pool's share, which falls with the home share; Windows and Linux are the same; macOS at 0.78 uJ (M5 Max) holds a 4x power edge over the 5090 and loses last of all the home tiers; NVIDIA and AMD as their uJ rows (algorithm.md 5.3a); Apple as macOS. + +What Igneum should do: the reward rule that prices rented hash out (lane 7's 3.1, weight-aged keys paid more) is the only lever in the protocol; the earnings page should show the miner's own cost per MH/s-hour against the network's implied rent, so a UK miner sees the day the line crosses; and the H100 and A100 random-read rate should be measured on one rented card this month (two hours, under the measure lock), because every row of 3.2 rests on it. + +## 4. Energy, heat and the home + +### 4.1 Prices and forecasts + +| Region | Household price 2026 | Ten-year direction | Source | +|---|---|---|---| +| UK | 26.11 p per kWh (Jul to Sep 2026 cap), 26.32 p (Oct to Dec 2026) | Cornwall Insight's wholesale path falls to GBP 83 per MWh by 2029 ("over GBP 40 above historic"); retail scenarios 22 to 42 p by 2030 | Ofgem; Cornwall Insight (Jan 2024); solarpanelsforfactories (secondary) | +| EU | EUR 28.96 per 100 kWh average H2 2025; Ireland 40.42, Germany 38.69, Belgium 34.99; Hungary 10.82, Malta 12.82, Bulgaria 13.55 | The Commission's Electrification Action Plan (17 Jul 2026) targets electricity at most 2.5x gas for households by 2030 | Eurostat 5 May 2026; Commission | +| US | 17.7 c average H2 2025; "continue steady increase" | AEO2025 reference: 13 c (2024, a different basis) to over 20 c by 2050 | EIA | +| Cheapest mining regions | Iran about 1 c (licensed); Ethiopia 2 to 5.3 c; Paraguay 4.4 to 6 c; Kazakhstan about 4 c; Nigeria 4.8 c hosted | spark.money; oneminers; hashrateindex Paraguay (4 May 2026) | secondary | + +### 4.2 Home mining as heating + +| Product or trial | Facts | Source | +|---|---|---| +| Heatbit Trio, Maxi, Maxi Pro | USD 849 (10 TH/s, 400 W mining + 1,100 W resistive) to USD 1,499 (60 TH/s, 1,500 W); seasonal BTC USD 300 to 420 (Heatbit's own figure); Wired's review: mining covers 30 to 40 percent of electricity at 12 to 15 c per kWh | miningboard.com; techbuzz (5 Apr 2026) | +| 21energy, MintGreen, HotMine | convector radiators 250 to 2,700 W; hydronic boilers for radiators and hot water | miningboard.com | +| Qarnot "radiateur numerique" | 100 RIVP social-housing flats in Paris 15e heated by compute radiators from 2013; Qarnot moved to boilers; the model is "the building pays the capital, heat is free" | fr.wikipedia Qarnot; maisonapart | + +The economics per kWh (model): a 5090 at the 431 W cap is a 0.43 kW heater. Credit the heat at the gas price delivered through a 90 percent boiler, or at a heat pump's electricity (COP 3): + +| Region | Electricity | Heat credit, gas | Heat credit, heat pump | Effective price in the heating season | +|---|---|---|---|---| +| UK | 26.3 p | 7.0 p (27 percent) | 8.8 p (33 percent) | 17.5 to 19.3 p | +| Germany | 38.7 c | 13.3 c (34 percent) | 12.9 c (33 percent) | 25.4 to 25.8 c | +| US | 17.7 c | 5.6 c (31 percent) | 5.9 c (33 percent) | 11.8 to 12.1 c | + +A third off the power bill for the 1,500 to 2,000 heating hours a year (approximate), everywhere. It moves a UK home miner from 7x to 5x the Texas industrial price, not to parity. Consequence per tier: it matters most to the tiers with the worst uJ (8 and 12 GB, AMD) and least to Apple (21 W is not a heater). Recommendation: a heat mode in Ember (run the miner only while a room thermostat or schedule calls, power cap set to the room's load, the hourly program unchanged), which costs nothing in protocol and is the one feature home-mining heaters ship. + +### 4.3 Grid balancing + +ERCOT paid Riot USD 31.7 M in August 2023 (24.2 M curtailment credits plus 7.4 M demand response) and Riot booked USD 30.6 M of power-curtailment credits in Q3 2025, up 147 percent on the year (ABC13; Riot releases). The programmes name "large flexible customers"; a home GPU is not one. Home aggregators exist (the UK's supplier demand-flexibility sessions, US utility programmes; approximate, from memory) and pay per kWh shed against a baseline. A fleet of Ember miners is a shed-able load only if a signal reaches it. Recommendation: a curtailment input in Ember (a webhook, a schedule, a price threshold from a public spot feed) that pauses the miner and resumes it; the protocol sees a key that stops voting for an hour, which the LEAVE item of 0.3.16 already prices as nothing (vote-or-burn.md: no burn). Per tier: a pool user's pool must pass the signal down; a rig is the only home tier big enough to enrol directly. + +### 4.4 The rules by region + +| Region | Rule | Source | What it means for an Igneum home miner | What Igneum builds | +|---|---|---|---|---| +| EU, MiCA | White papers must state the consensus mechanism's climate impacts; CASPs must publish the sustainability indicators per asset (Delegated Regulation (EU) 2025/422; mandatory kWh a year, more above 500,000 kWh); Article 142 report on environmental impact and "minimum sustainability standards"; the 2022 Parliament vote dropped a PoW ban; the 2026 MiCA review consultation (reply by 31 Aug 2026) asks only how appropriate the disclosure regime is (Q53) and nothing on PoW | MiCA; 2025/422; the consultation PDF (fetched) | nothing on the miner; the exchanges that list IGN need the kWh figure | publish Igneum's own 2025/422-format indicators from the hash-rate and the measured uJ, updated each era | +| Norway | ban on new PoW mining data centres from autumn 2025; data-centre registry; existing sites run | CoinDesk 23 Jun 2025 | home mining untouched; no new hosting | nothing | +| Sweden | data-centre electricity tax relief removed July 2023 (SEK 0.006 to 0.36 per kWh); SEK 500 M of back-tax on nine firms 2024 to 2026 | CoinDesk 14 Apr 2023; crypto.news | home miners already paid full tax; hosting is dead | nothing | +| Russia | mining banned in 10 regions 1 Jan 2025 to 15 Mar 2031; Moscow region from 15 Aug 2026 to 2032; seasonal bans in Irkutsk, Buryatia, Zabaikalsky; no new regions in 2026 | TASS; Cryptopolitan | a region check at install; the 2024 law's 6,000 kWh a month household allowance (approximate, from memory) covers one card | a region prompt in Ember with the banned list | +| Kazakhstan | mining legal outside the AIFC (Nov 2025 law); "strategic mining" rules from 1 Aug 2026 with a share to the national reserve | Caspian News; KuCoin | licensed industrial; a home card is below any threshold found | nothing | +| Paraguay | ANDE crypto tariff USD 44.33 per MWh (Decree 7824/2022), lifted toward 5.1 to 6 c; every crypto contract ends 31 Dec 2027 | hashrateindex 4 May 2026 | the cheapest hydro region closes to new load in 2028 | nothing | +| Iran | licensed mining at a mining tariff; seasonal shutdowns in power shortages (approximate) | ainfp.org; MEXC | the cheapest power on earth and the least reliable | nothing | +| China | illegal; joint Notice 6 Feb 2026 reaffirmed; one report of Sichuan, Inner Mongolia, Xinjiang reopening from 1 Jan 2026 is uncorroborated | lightspark; egw.news (single source) | a Chinese home miner runs at legal risk | the region prompt | +| US, federal | SEC staff statement 20 Mar 2025: PoW mining, solo and pooled, is not a securities offering; DAME 30 percent excise proposed 2023, 2024, 2025 budgets, never enacted; EIA's emergency survey (Jan 2024) blocked in court (Mar 2024); CLARITY failed cloture 49 to 50 on 15 Sep 2026; GENIUS Act (stablecoins) 2025 | Dechert; Blockworks; Fortune; Orrick 2 Oct 2026 | nothing on the miner | nothing | +| US, states | Texas, Kentucky, Wyoming pro; New York's fossil-PoW moratorium (2022, approximate); California's DFAL licensing from 1 Jul 2026 reaches crypto businesses, not a home card | sazmining; crypto.news | a home miner is not a licensee anywhere found | the region prompt | + +Per-region electricity-price prompt: the earnings page should default the price per kWh from a public table by country (the Eurostat, Ofgem and EIA rows above), let the miner edit it, and show the miner's own break-even hash share, because the number that ends a home miner is the bill, not the regulation. + +## 5. Zero-knowledge proving cost, 2026 to 2036 + +### 5.1 The numbers today + +| Row | Value | Source | Label | +|---|---|---|---| +| EF real-time proving target (10 Jul 2025) | P99 under 10 s, capex under USD 100 K, under 10 kW, open source, 128 bits (100 accepted at first), proof under 300 KiB, no trusted setup; written for solo stakers "from home" on a 10 kW supply | blog.ethereum.org | cited | +| Ethproofs 2025 review (6 Dec 2025) | USD 1.69 to under a penny a proof in nine months; 7 zkVMs, 15 provers, about 200,000 blocks; four teams at sub-10 s P99; single-GPU proving from 16 min to under 60 s; 2026 target sub-8 s P99 and kWh a proof as the metric | hackmd willcorcoran | cited | +| SP1 Hypercube | 99.7 percent of blocks under 12 s on 16 x RTX 5090, cluster under USD 100 K; about USD 0.02 a block single-node | Succinct blog; The Block | cited | +| Pico Prism | 99.9 percent under 12 s on 64 x 5090 | Brevis | cited | +| Cysic Venus | 7.4 s a block on 24 GPUs (type unstated); ZK ASIC claims (1.33 M Keccak a second, 50x energy) with no shipping date | bex.co 17 Apr 2026 | cited, ASIC unverified | +| ZisK | p99 9.62 s on 4 x 5090 | GitHub comparative analysis, Sep 2026 | secondary | +| Airbender | 51 s average on one RTX 4090, under a cent | bex.co Jan 2026 | secondary | +| RISC Zero | R0VM 2.0: 35 min to 44 s a block (Dec 2025) | wavect; RISC Zero blog | secondary | +| Jolt | Lattice Jolt (9 Sep 2026): 2 to 3x faster, 65 to 80 KB proofs, 2 M cycles a second CPU, over 10 M with a GPU, post-quantum | cryptobriefing | cited | +| Cost a block on the tracker | about USD 0.005 (Sep 2026) | lane 7 2.6 | secondary | +| Hardware provers | Cysic (C1, ZK-Air, ZK-Pro), Fabric (VPU), Ingonyama (ICICLE; Accseal Leo ASIC in ICICLE v3), Irreducible (FPGA clusters, Binius), Supranational; "10 to 100x on MSM and NTT" claims | h33.ai survey; Ingonyama; Cysic docs | claims, no shipped benchmark on a zkVM block | +| Igneum's own | 11 rented cards: shard beside the miner 10.7 s (5090) to 37.5 s (3060); alone 4.8 to 18.4 s; SP1 compressed verify 0.032 s on a Mac core | prover-tiers-real-cards.md; bench-log 5 Oct | measured | + +### 5.2 The trend line to 2036 and the 20 percent pool + +Lane 7's 33x a year is software catching hardware and cannot hold. Hardware alone is 1.5x a year. The EF's own 2026 metric is kWh a proof, which is the right axis for a miner-prover: a shard that costs a joule of GPU time is paid from the pool and competes with the same joule in the lottery. + +| Year | Block proof cost on the open market (USD, approximate) | Hardware that proves an Ethereum block in real time | What proves an Igneum shard (4.7 M cycles) under 10 s | Does a home 12 GB card have a place | +|---|---|---|---|---| +| 2026 | 0.005 to 0.02 | 16 x 5090 (SP1), 4 x 5090 (ZisK) | 5090 beside its miner (10.7 s), every card alone | yes, alone or hand-off (prover-tiers-real-cards.md) | +| 2028 | 0.001 to 0.005 | 1 to 4 consumer cards; first ASIC or VPU boards if any ship (none has) | every card from the 3060 at 3x a year (lane 7's table); 12 GB beside the miner at 3x, not at 1.5x | yes alone; beside the miner only under 3x | +| 2031 | 0.0003 to 0.001 | one consumer card, or a prover ASIC at 10 to 50x per joule if the claims land | a 12 GB card in 1 to 3 s | yes, but a prover ASIC would take the external job market first (dollar-priced jobs go to the cheapest joule), and the pool second only if shards are open to anyone | +| 2036 | under 0.0001 | commodity | any card | the pool's economics are the lottery's: whoever holds vote weight is drawn (sortition by weight), so the home card keeps its share of the pool whatever an ASIC does to the open market | + +The design's defence is already in place: the pool is drawn by vote weight (sortition), and vote weight is 30 days of blocks, which a prover ASIC does not have. A prover ASIC centralises the external job market, not the pool. What it would do to the pool is set the shard deadline: if the chain tightens the deadline toward ASIC times, home cards miss it. So the shard deadline must be a function of the measured fleet median (lane 7's rule), re-read each era, and the shard size must stay at a size a 12 GB card proves alone inside it (today 4.8 to 14.4 s). "Verified proving as the reward" (horizon-2026-10 item 1: the proof verified in consensus) is the piece that makes the pool unforgeable, and its activation is the decision owed. + +Per tier: 8 GB (proves alone, never beside its miner; keeps its pool share by weight); 12 GB (the swing tier; the hand-off profile is the product); 16 GB and up (unconstrained); rig (proves beside mining on every card from 2028 at 1.5x); pool user (the pool operator's prover does it); Windows, Linux (the same); macOS (an M5 Max proves a shard, unmeasured against the rented table; Metal lane open); NVIDIA (every measurement is NVIDIA); AMD (no measured shard time; the 9070 XT has no SP1 GPU backend measured here, so the AMD tier proves on CPU or not at all until it is measured, which is the first owed number); Apple (as macOS). + +### 5.3 Proof-system risk and the swap interface + +| Event | Date | What a malicious prover could do | Source | +|---|---|---|---| +| SP1 v3.4.0 (LambdaClass, 3MI, Aligned) | disclosed 26 Jan 2025 | "generate valid SP1 proofs of incorrect execution of an arbitrary program": universal forgery, from two bugs plus a Plonky3 evaluation gap | LambdaClass blog; Blockworks | +| RISC Zero zkVM 2.0.0 to 2.0.2 | 15 May 2025 | a missing constraint in the rv32im circuit let any 3-register instruction be proven wrong; on-chain verifiers stopped by estop | HackenProof | +| SP1 Hypercube JALR | 20 May 2026 | a completeness bug (prover crash), not soundness; the EF's audit found only 51 of 62 opcodes fully proven, four load instructions proven against wrong specifications | zkevm.ethereum.foundation | + +Three soundness-class events in 18 months across the two leading zkVMs. On Igneum today a soundness bug is a light-client problem (spec 10.1; finality-in-proof.md 4.4): every full node executes natively and vetoes a record whose statement differs. It becomes a chain failure the day any of three things is true: (1) proof verification in consensus pays a shard on the proof alone (the 0.3.16 switch) and a forged proof carries a correct statement, which earns the pool and nothing else; (2) finality is carried inside the proof (lane 7's 3.3) and a forged proof carries a forged weight table, which a full node still vetoes, so the failure is confined to proof-only clients; (3) the chain ever lets a proof replace execution for full nodes, which the design forbids. So the chain-failure case is (3), and the rule is: never. The swap interface needs: a pinned verifier key per proof system with a version in the record; two independent zkVMs accepted in parallel (the EF's own "multiple provers" lesson), with a record valid only if its system is on the active list; a 95 percent class-change signal to retire a system, and a stop switch (RISC Zero's estop pattern) that any 1/3 of weight can flip to "execution only" inside an hour. Per tier: nothing a miner does; a pool's prover must build for two systems; the cost is two guest builds and two verifier keys. + +## 6. Light clients on phones, 2026 to 2036 + +### 6.1 The state of the art + +| Client | What it verifies | Bytes and time | Source | +|---|---|---|---| +| Ethereum sync-committee clients (Helios, Kevlar) | 512-validator sync committee signatures; syncs in about 2 s, no storage; "lightweight enough to run on mobile" | about 25 KB per two days (24,576 bytes of keys plus the signature, header and branch) | a16z Helios; annotated spec | +| Mina | a recursive SNARK of the whole chain | a 22 KB chain; "a few milliseconds of processing" | Mina docs via gate.com, iq.wiki | +| Celestia Lumina | data-availability sampling in a browser or phone (Wasm, Rust) | random shares a block; bandwidth not published for 2026 (approximate: tens of MB a day) | celestiaorg/lumina; Eiger | +| Bitcoin BIP-157/158 (Neutrino: Breez, Blixt) | compact block filters served by full nodes | headers and filters in under 5 minutes | Blixt; Lightning Labs | +| StarkWare's Bitcoin header proof | every header since genesis in one STARK | 1 MB, under 100 ms on a phone | cryptotimes 11 Sep 2025 | +| Zcash (Zashi/Zodl SDKs, lightwalletd; Tachyon-Lite) | shielded sync through servers | server-dependent (the anti-pattern) | Zcash forum, GitHub | +| Kaspa wallets (Kaspium, kaspa-core) | none: wallets talk to public nodes over wRPC | n/a (approximate) | coincodex; Zelcore | +| Phone verify times | Groth16 about 5 ms; a Keccak circuit's verify 0.12 s on an iPhone 15 Pro (Mopro); a 45 KB STARK in 16 ms (laptop, approximate); Groth16 proving 2.9 to 3.1 s on a Galaxy S25 and iPhone 17 Pro | Mopro benchmarks; provebench; shattered.io | cited, mixed devices | +| WebGPU | in Chrome 113, Edge 113, Safari 18, Firefox 141 | n/a | Wikipedia WebGPU | + +### 6.2 What Igneum's finality-in-proof needs from the phone + +The client holds one proof and fetches the newest segment proof from any node (finality-in-proof.md 4.2); SP1's compressed verify is 0.032 s on a Mac core (bench-log 5 Oct), a Groth16 or Plonk wrapper is unmeasured. Model (a wallet updating every 10 minutes, 144 times a day, a phone big core at 3 W, LTE at about 1.5 J a MB, an 18 Wh battery): + +| Form the wallet verifies | Bytes a day | CPU | Radio | Battery a day | +|---|---|---|---|---| +| Groth16 or Plonk wrapper (about 1 KB with public values) at about 10 ms on a phone (approximate, 3x the Mac core) | 0.14 MB | 4 J | under 1 J | 0.007 percent | +| Compressed STARK at the EF's 300 KiB ceiling, about 100 ms on a phone | 42 MB | 43 J | 63 J | 0.16 percent | + +Either is nothing. The choice is the EF's: no trusted setup and under 300 KiB, which is the STARK row, and by 2030 a WASM-SIMD or WebGPU verifier on a phone should put the STARK verify under 30 ms (approximate projection from the 294x STARK-verifier speedup reported in 2026 and the WebGPU adoption row). The 2026 answer is the Plonk wrapper (no trusted setup, small) for the phone and the compressed STARK for nodes. Bytes a day are set by update frequency, and a wallet that updates on open rather than on a timer is under 1 MB a day in either form. + +"Every miner is also a light-client server" has prior art: Bitcoin full nodes serving BIP-157 filters under the NODE_COMPACT_FILTERS service bit (every full node that opts in serves every light client), and Ethereum's Portal Network (every node serves a slice; "without having to trust or put extra strain on full nodes"). The anti-pattern is Zcash's lightwalletd, a few servers everyone trusts. Recommendation: the node serves `igneum_getSegmentProofBytes` over p2p and a rate-limited HTTP path, on by default in Ember, so the serving set is the miner set; the phone client dials three miners and takes the longest valid chain of proofs. Per tier: no cost a miner notices (one proof of a few hundred KB served on request); the pool node serves for its members; Windows, Linux, macOS, every vendor the same. + +## 7. Post-quantum signatures and a proof-of-work chain + +### 7.1 The standards and sizes + +| Scheme | Standard | Public key | Signature | Status | Source | +|---|---|---|---|---|---| +| ML-DSA-44 | FIPS 204 | 1,312 B | 2,420 B | final (Aug 2024) | Cloudflare 9 Jul 2026; FIPS 204 | +| ML-DSA-65 | FIPS 204 | 1,952 B | 3,309 B | final | encryptionconsulting | +| ML-DSA-87 | FIPS 204 | 2,592 B | 4,627 B | final | same | +| SLH-DSA-SHA2-128s / 128f | FIPS 205 | 32 B | 7,856 B / 17,088 B | final | Cloudflare | +| FN-DSA-512 (Falcon) | FIPS 206 | 897 B | 666 B | draft; final expected late 2026 to early 2027; floating-point signing is "difficult to implement securely" | encryptionconsulting; Cloudflare | +| ML-KEM | FIPS 203 | n/a | n/a | final | NIST | +| BLS12-381 (today) | n/a | 48 B | 48 B aggregate for 8,192 voters | quantum-broken by Shor on the curve's discrete log | ethereum.org PQ page | + +Timelines: NIST IR 8547 deprecates ECDSA, EdDSA, RSA and EC Diffie-Hellman after 2030 and disallows them after 2035 (final version confirmed). The Global Risk Institute's 2025 survey (26 experts, report page dated 9 Mar 2026): a cryptographically relevant quantum computer "quite possible (28 to 49 percent)" within 10 years and "likely (51 to 70 percent)" within 15. Resource estimates: ECC-256 at 1,200 to 1,450 logical qubits and 70 to 90 M Toffoli (Google, 2026), about 500,000 physical qubits against about 1 M for RSA-2048 (Gidney, May 2025); 835 logical qubits with 2^30.6 Toffoli (Luo et al., arXiv 2607.13816, Jul 2026). Bitcoin: BIP-360 merged into the BIPs repository 11 Feb 2026 as a draft (P2MR, formerly P2QRH), a companion BIP for ML-DSA and SLH-DSA, a testnet implementation March 2026, no activation. Ethereum: a PQ team formed January 2026; BLS to be replaced by leanXMSS (hash-based) with leanVM aggregating "3,000 bytes" of signature against BLS's 96 by "250x"; core PQ infrastructure targeted "by approximately 2029"; EIP-8141 account abstraction for user migration. + +### 7.2 What quantum does to Igneum + +| Component | Break | Consequence | Size of the fix | +|---|---|---|---| +| BLS vote keys (in every header) | Shor on BLS12-381's G1 discrete log (a 255-bit subgroup over a 381-bit field; wider than secp256k1, so a later break by a year or two, approximate) | every vote key is public; a CRQC forges two thirds of weight and certifies any chain. Catastrophic | the migration below | +| Hash-to-curve | none; it is a hash | nothing | nothing | +| ECDSA accounts in the EVM | as Ethereum: exposed public keys after a first spend | user funds; the same exposure as Ethereum's "0.1 percent dormant" row, smaller | account abstraction with an ML-DSA verify precompile from genesis | +| The VRF (aggregator pick) | if EC-based, forgeable; aggregation is not safety (every voter signs) | liveness nuisance | the same key succession | +| The class-group VDF (epoch seed, era draw) | Shor computes the class-group order, which removes the sequentiality assumption of a Wesolowski-style VDF (approximate; from memory of the class-group VDF literature) | an attacker with a CRQC grinds the hourly program seed | a hash-chain fallback behind the same version byte; flagged, not sized | +| SP1 (STARK core, Groth16/Plonk wrapper) | the STARK is hash-based and stands; the pairing wrapper falls | the on-chain and phone verifier moves to the compressed STARK | the wrapper choice of section 6 | + +### 7.3 The cost in bytes, 8,192 voters, every voter signing every 30-second checkpoint (model) + +| Scheme | Per checkpoint | Per day (2,880 checkpoints) | Averaged per block at 1 block/s | Key in the header | +|---|---|---|---|---| +| BLS aggregate (today) | 1.0 KB (48 B + a 1,024 B bitmap) | 2.9 MB | 34 B | 48 B | +| ML-DSA-44 | 19,361 KB | 57.1 GB | 645 KB | 1,312 B | +| ML-DSA-65 | 26,473 KB | 78.1 GB | 882 KB | 1,952 B | +| FN-DSA-512 | 5,329 KB | 15.7 GB | 178 KB | 897 B | +| SLH-DSA-128s | 62,849 KB | 185 GB | 2,095 KB | 32 B | +| SLH-DSA-128f | 136,705 KB | 403 GB | 4,557 KB | 32 B | +| ML-DSA-44 aggregated by a SNARK at the EF's 250x | 77 KB | 223 MB | 2.6 KB | 1,312 B, or a 32 B hash of it | + +A naive ML-DSA swap costs 57 GB a day of votes against a block stream of about 100 MB a day (approximate), 500x. It is not shippable without aggregation. The aggregator already exists in the design (VRF picks 8 aggregators a checkpoint): the migration is "aggregators carry a STARK of N verified PQ signatures", which is Ethereum's leanVM shape, and the per-checkpoint cost falls to the order of 100 KB. + +### 7.4 The plan to pre-commit at genesis + +1. A `sig_scheme` version byte in the vote item and in the vote-key registration; genesis value 0 = BLS12-381. +2. Key succession at registration: every vote key registers with a 32-byte hash of a successor public key (any scheme). A `succeed` item signed by the old key and the new key moves the 30-day weight to the successor without a reset. Miners generate the successor at first run; Ember stores it offline. +3. A PQ verify precompile (ML-DSA-44 first, FN-DSA when FIPS 206 is final) in the EVM from genesis, so account abstraction can migrate users before 2030. +4. The flip is a class change: 95 percent signal with a floor height, as the P2 mechanism; the aggregated-vote format ships first, the scheme flip second. +5. The VDF carries the same version byte with a hash-chain fallback. +6. The public sentence: "Igneum's vote keys and accounts can move to NIST post-quantum signatures by miner signal; the key succession is in every key from genesis." + +Per tier at migration: a home miner on any card runs the updater and signs one `succeed` item from Ember; ML-DSA-44 signing is well under a millisecond on any CPU (approximate), every 30 s; the bandwidth cost is the aggregated form's, about 100 KB a checkpoint, which an 8 GB card's host handles; a rig's one key succeeds once; a pool's key is the operator's, and pool members do nothing; Windows, Linux, macOS, NVIDIA, AMD, Apple: nothing hardware-specific, since the signature runs on the CPU. + +## 8. Regulation of mining and of coins with no issuer, 2026 to 2036 + +### 8.1 The texts + +| Regime | What it says | Source | +|---|---|---| +| MiCA Article 4(3) | Title II (offers and white papers) does not apply where the crypto-asset is "automatically created as a reward for the maintenance of the distributed ledger or the validation of transactions" (point (b)); where there is no identifiable issuer "the obligation to produce a white paper does not apply to an issuer, as none exists"; a CASP that plays an active or promotional role may have to draw up one (Article 5 and the trading-platform duty under Title V) | Osborne Clarke (4 Oct 2023); Conventus Law; Squire Patton Boggs | +| MiCA sustainability | Article 66 and Delegated Regulation 2025/422: CASPs publish the consensus mechanism's energy (kWh a year mandatory; more above 500,000 kWh); the Commission's Article 142 report may propose "minimum sustainability standards"; the 2026 review consultation (reply by 31 Aug 2026) asks only how appropriate the regime is (Q53) | the consultation PDF; carbon-ratings; Latham tracker | +| MiCA transition | over on 1 Jul 2026; unlicensed service to EU clients is a breach | ESMA statement Apr 2026 | +| UK | The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026: regulated activities from 25 Oct 2027 (issuing qualifying stablecoins, safeguarding, operating a qualifying cryptoasset trading platform, dealing, arranging, arranging staking); gateway and savings window 30 Sep 2026 to 28 Feb 2027; a "qualifying cryptoasset" is the FCA perimeter term (the formal definition sits in the Regulations and was not retrievable here); mining and validating are not in the activity list found; the 2023 financial-promotions regime already covers promotions of qualifying cryptoassets to UK consumers | FCA policy statements page; Lewis Silkin 30 Sep 2026; Skadden Jul 2026 | +| US | SEC Corporation Finance staff statement 20 Mar 2025: PoW mining, solo or pooled, is not an offer of securities (non-binding, facts and circumstances); CLARITY (CFTC over digital commodities) failed cloture 49 to 50 on 15 Sep 2026, a motion to reconsider preserved; GENIUS Act 2025 covers payment stablecoins; DAME 30 percent excise proposed three times, never enacted | Dechert; Orrick 2 Oct 2026; Cointelegraph | +| FATF | Recommendation 16 revised June 2025; implementation by end-2030; unhosted wallets still treated differently by country | FATF best practices Jun 2025; Sumsub | +| DIFC (Igneum Labs LTD's seat) | DFSA crypto-token regime amended 12 Jan 2026: firm-led suitability, no more Recognised Crypto Tokens list, controller approval at 30 and 50 percent; applies to firms providing financial services in crypto tokens; nothing on mining or software | Dechert 13 Jan 2026; Arabian Business | +| Dubai outside DIFC | VARA rulebook v2.1 (2026): exchange services, disclosures, token issuance; a federal licensing decision Feb 2026 | TradingView/Coinpedia; Dechert | + +### 8.2 What it means for each actor + +| Actor | EU | UK | US | DIFC | FATF | +|---|---|---|---|---|---| +| A pool operator paying members | not a CASP for mining; a CASP if it holds members' coins or exchanges them (custody, exchange); the energy figure is the CASPs' duty, not the pool's | not an activity listed, unless it safeguards or deals; from 25 Oct 2027 a pool that holds balances looks like safeguarding | SEC: pooled mining not a security; FinCEN money-transmitter guidance on pools is the open point (approximate) | not a financial service unless it custodies | a pool that holds and sends on behalf of members is a VASP-shaped entity by end-2030 | +| A home miner selling coins | a seller, not an offeror; taxed as income then gains (country rules) | the same; promotions rules do not reach a private sale | income at receipt (IRS), then gains | n/a | the exchange it sells on carries the travel rule | +| The entity publishing the software (Igneum Labs LTD) | no issuer under 4(3); the white paper is nobody's duty; publishing the 2025/422 indicators voluntarily lets CASPs list | not an activity; public text must not be a financial promotion of a qualifying cryptoasset to UK consumers (the 2023 regime), which rules out "buy", "invest" and price talk | the SEC statement covers mining, not the publisher; CLARITY's "mature blockchain" test is the thing to watch if it passes | a software company in the DIFC with no financial service and no token sale sits outside the DFSA token regime on its face | n/a | +| The testnet with no value | nothing; no asset | nothing | nothing | nothing | nothing | +| The external proving market paid in dollars | a job is a service; settlement in IGN on-chain with no operator custody is not a CASP activity; an operator that converts dollars to IGN is an exchange | the same; dealing or arranging if an operator sits between | money transmission if an operator holds funds | a dollar-settled service is a financial service only if the entity holds or exchanges | the same | + +### 8.3 What Igneum writes into its genesis and public text now (not legal advice; counsel is engaged) + +1. No issuer, no offeror, no sale: every coin is created as a block reward (MiCA Article 4(3)(b) language, verbatim in the litepaper). +2. The 2025/422 sustainability indicators (kWh a year from hash rate and measured uJ, intensity per transaction, mix by region when known) published by the project each era, so an EU CASP can list without asking. +3. No financial promotion: no price, no "buy", no "invest", no return language anywhere the UK can read it; the earnings page shows hash and IGN, not sterling. +4. The pool reference implementation never holds a member's balance: payouts are direct from the coinbase split (the pool is a coordinator, not a custodian), which keeps pools out of CASP, safeguarding and VASP shapes in every regime above. +5. The job market is peer-to-peer settled on-chain; no operator account, no dollar leg in the protocol; the dollar price is a quote, the settlement is IGN. +6. The software is published under an open licence by a company that holds no coins by right (no dev fund, already decided) and runs no service the chain depends on. +7. The region prompt and the banned-region list in Ember (Russia's ten regions and Moscow from 15 Aug 2026, China) with the sentence "mining may be restricted where you are; you are responsible for checking". +8. A genesis "no privileged key" statement: no key can mint, pause or upgrade (true by design; say it because the regulators' tests turn on it). + +## 9. Ten-year scenario table + +| Year | Scenario A: GPUs stay general and cheap | Scenario B: HBM-only high end, APU-only low end | Scenario C: proving ASICs win | +|---|---|---|---| +| 2028 | 48 GB flagship on GDDR7 (lane 7); used H100s at USD 7,500 to 10,500 flood rentals; hash at the rental equilibrium, home share falling with the rent curve. Igneum: the N ladder's first rung by signal; home miners inside 2.5x of the chip per joule; the chip pays at USD 100 M of cap. Alive. The parameter: N stepped by signal | HBM4 only on datacentre parts; consumer GDDR7 unchanged; APUs (Medusa Halo, M6) take the laptop tier. Igneum: nothing changes for the hash; the Apple and APU tiers grow. Alive. The parameter: the cache rung, in case an APU's LLC reaches 256 MB | First VPU or C1 boards ship at 10 to 50x per joule on MSM and NTT; the external job market goes to them within a year. Igneum: the 20 percent pool is sortition by weight, so home cards keep it; the dollar market is lost to ASICs. Alive, with the external income line (already "never the main income" by 2030, lane 7 3.11) gone sooner. The switch: the shard deadline as a function of the fleet median | +| 2031 | GDDR7-Next; 64 GB flagship; rental at 0.002 to 0.004 per MH/s-hour; hash 3 to 6x today's at the same price. The chip bar is USD 1.4 B at N5. Home miners on retail power are marginal unless the heat mode and the price prompt keep the UK and EU tiers on in winter. Alive; the home share is 10 to 20 percent (approximate). The parameter: the weight-aged reward rule (lane 7 3.1) | A consumer HBM4-class halo card appears (unannounced today): 2 to 4x the read rate of a 2026 card; the home 2026 cards fall to 0.25 to 0.5x of a new card, the GPU cadence twice over. The chip's stack-level edge is the same as the card's, so the per-joule gap closes to about 1.5x. Alive; the installed base shifts to the new card. The parameter: the N bind-point re-measurement per generation | Prover ASICs at 100x; the EF's L1 zkEVM runs on them; SP1-class software moves to ASIC backends. Igneum: proving in consensus verified, home cards prove shards inside the deadline because the deadline is the fleet's; the pool's 20 percent stays with weight. Alive. The risk: if a soundness bug in the ASIC's backend lands, the stop switch of 5.3 is the defence | +| 2036 | 96 GB cards; rent at 0.0003 to 0.0013; hash 10 to 35x; the emission at the 1 percent tail (86 M IGN a year). Security is 1 percent of market cap a year (tail-emission.md). Igneum lives if the cap is over about USD 50 M (a 24-hour attack at 0.032 percent of cap is USD 16,000 against a rental market that can supply it); dies below that only in the sense every PoW chain does: cheap to attack, nothing to steal. The parameter: the tail | HBM everywhere above the laptop; the f = 1 chip and the halo card are the same memory; the ASIC question is closed by parity and the ladder's N is the remaining difference. Alive. The parameter: N at the verifier's 10 ms ceiling | Every proof is an ASIC proof; the pool pays miners for shards an ASIC proves 100x cheaper; miners buy ASIC prover boards the way they buy cards (USD 500 to 2,000 boards, approximate guess). Igneum: proving is a second card, not a second income. Alive. The parameter: the shard deadline rule | + +Where Igneum dies, honestly: + +| Death | Scenario | What would be needed to survive it | +|---|---|---| +| The stored-dataset chip at N5 is built at a USD 100 M cap in year 1 and holds over a third of hash by year 2 | A, 2028, if the N ladder is not at genesis or the signal never steps it | the N ladder at genesis with its first rung live; the weight-aged reward; the honest sentence that the chip's bar is USD 100 M, so the cap passes it fast or not at all | +| Idle datacentre hash sets the rent and the home tier leaves; weight concentrates in three hosting firms; a hosting failure is a 30-day finality pause | A, 2031 | the LEAVE item (shipped), the reward rule that pays aged keys, the heat mode and price prompt that keep winter home miners on, and a public "weight by hosting provider" chart so the concentration is seen | +| A CRQC in 2033 to 2036 (28 to 49 percent inside ten years, GRI) before the key succession has flipped | any, 2033+ | the genesis key succession and the aggregated-vote format shipped by 2030, the flip signalled the year NIST deprecates (2030), not the year a machine appears | +| A soundness bug in the one proof system while the pool pays on the proof alone | C, any year | two zkVMs on the active list and the 1/3-weight stop switch | +| The cap never passes USD 20 M: the tail's 1 percent is USD 200,000 a year of security, a day's rental | all, any year | nothing in the protocol; it is the market's verdict, and the design should say so rather than promise a floor | + +## 10. Verdict table + +| Axis | Finding | Source | Per-tier consequence | Recommendation | +|---|---|---|---|---| +| Memory roadmap | tRC flat for about 20 years; HBM4 doubles channels a stack (2026); HBM4E adds pins and a custom base die (2027 to 2028); no consumer HBM, no GDDR8 before 2029 to 2031 | JEDEC, SK hynix roadmap, Lee et al. | a 2026 card keeps its read rate against a 2028 card; 8 and 12 GB leave the installed base by 2030, not the hash | nothing at genesis; re-measure the N rungs per generation (text, a measurement duty) | +| The cache | consumer LLC 96 to 128 MB; datacentre 256 MB today | chip-model-v3, MI300X (approximate) | an LLC at the cache size gives that card's owners a 2 to 3x shortcut | a cache-size rung on the signal ladder (genesis parameter) | +| The dataset | 2 GiB to 16 GiB over 28 years is under every card and never binds before year 12 | algorithm.md 5.6 | the prover footprint binds first | nothing; fix the public card-lifetime sentence (text) | +| The chip's bar | pays at USD 17 M of cap bare, USD 100 M with the N5 shadow core in years 1 to 2, 2.3x higher every two years with the glide; never needs N2 or A16 | model, siliconanalysts mask costs | the 9070 XT tier is displaced first, Apple never per joule, the 5090 inside 2.5x | the N ladder at genesis (parameter); the p* sentence in the threat model (text) | +| C-HBM4E | the memory controller moves under the stack from 2027 to 2028 | TSMC/GUC via Tom's | the chip's dollars per MH/s fall under USD 2.8 by 2028 (approximate) | disagreement with lane 7 row 2.3 recorded; no new parameter, N covers it | +| Used-GPU flood | 15 to 20 M datacentre GPUs installed by end-2026; residual 25 to 35 percent at 60 months; an H100 mines at 0.65x to 3x a 5090, unmeasured | TechInsights, Omdia, mercatus | 1 percent of a retired fleet is 2 to 35x the equilibrium hash | measure an H100 and an A100 this month (measurement); the reward rule (parameter, lane 7 3.1) | +| Rental curve | 0.0117 to 0.0003 to 0.0013 per MH/s-hour by 2036 | model on cloudzero's H100 history | attack dollars unchanged at equilibrium; home share falls 10 to 35x | re-price 51-percent.md from a measured rental yearly (text); the cost-vs-rent line on the earnings page (software) | +| Energy | UK 26.3 p, EU 29 c average, US 17.7 c; heat credit is a third off in the heating season; ERCOT pays industrial curtailment, not homes | Ofgem, Eurostat, EIA, ABC13 | retail-power tiers (UK, DE) are 5 to 9x the industrial price even with heat credited | heat mode, curtailment input, per-region price prompt (software); 2025/422 indicators published (text) | +| Mining rules | Norway (new sites), Sweden (tax), Russia (regions and Moscow), China (illegal), Kazakhstan and Paraguay (licensed, tariffed); US SEC: mining is not a securities offer | the table in 4.4 | a home miner's risk is regional | the region prompt and banned list in Ember (software) | +| Proving cost | USD 1.69 to about 0.005 a block in 20 months; four teams at sub-10 s; EF's 2026 metric is kWh a proof; no prover ASIC has shipped a block benchmark | ethproofs, EF, Cysic | a 12 GB card proves alone under 10 s at every rate; beside its miner only at 3x a year | the shard deadline as a function of the measured fleet median (parameter); two zkVMs and the 1/3 stop switch (switch) | +| Proof-system risk | three soundness-class events in 18 months across SP1 and RISC Zero | LambdaClass, HackenProof, EF | none for miners today; a chain failure only if a proof ever replaces execution for full nodes | never let it (text in spec 10.1); the active-list and stop switch (switch) | +| Light clients | 25 KB per two days (Ethereum), 22 KB (Mina), a 1 MB STARK in under 100 ms on a phone (StarkWare); a verifying Igneum wallet costs under 0.2 percent of a day's battery | a16z, Mina, cryptotimes, model | nothing a miner notices; every miner serves proofs | serve the segment proof from every node by default (software); the Plonk wrapper for phones, the STARK for nodes (parameter) | +| Post-quantum | ML-DSA-44 2,420 B signatures; 57 GB a day of naive votes at 8,192 voters, 223 MB with 250x aggregation; CRQC 28 to 49 percent within ten years; NIST deprecates 2030 | FIPS 204, Cloudflare, GRI, NIST IR 8547, model | a miner signs one succession item at migration; nothing hardware-specific | the sig_scheme byte, the key succession, the PQ precompile, the VDF fallback at genesis (parameters); the aggregated-vote format by 2030 (switch) | +| Regulation of a no-issuer coin | MiCA 4(3)(b) exempts block-reward assets; UK regulates platforms, dealing, custody, staking from 25 Oct 2027, not mining; SEC mining statement; CLARITY stalled; FATF by 2030 | the texts in 8.1 | a pool must not custody; a miner selling is a seller; the publisher is nobody's issuer | the eight-item list of 8.3 (text); the non-custodial pool reference (software) | +| Scenarios | alive in every 2028 and 2031 cell with one parameter each; dies on an unstepped N ladder, on concentration after the home tier leaves, on a late PQ flip, on a single proof system, or on a cap under about USD 20 M | section 9 | the home tiers are the ones each death removes first | the five "needed to survive" rows of section 9 | + +## 11. Three headline findings for the coordinator + +1. A stored-dataset chip with the class v4 shadow core pays for itself at about USD 100 M of market cap in Igneum's first two years and about USD 700 M in years 5 to 6 (30 percent share, USD 30 M project, model), and it never needs a node below 28 nm plus N5, so the N ladder at genesis is the only lever and C-HBM4E (2027 to 2028) moves the chip's controller under the memory and cuts its dollar cost further. +2. Ten years of rental deflation (USD 0.0117 to 0.0003 to 0.0013 per MH/s-hour by 2036) leaves every 51-percent dollar figure unchanged at the equilibrium and cuts the home card's share of the subsidy 10 to 35x; the day an idle datacentre card on 5 c power sets the rent, a UK home miner at 26.3 p loses 7x on electricity, and the heat mode buys back a third, not the gap. +3. A post-quantum vote at 8,192 voters costs 57 GB a day in naive ML-DSA-44 (19.4 MB a checkpoint) and about 223 MB a day with 250x SNARK aggregation, against a 28 to 49 percent chance of a cryptographically relevant quantum computer inside ten years (GRI 2025) and NIST deprecation after 2030, so the key-succession item, the scheme byte and the aggregated-vote format belong at genesis and the flip belongs in 2030. + +File: `/Users/joshm/Projects/igneum-wt-mission/docs/analysis/mission/future.md`. + +## Sources (accessed 7 October 2026 unless dated otherwise) + +Lane and repository inputs: `docs/analysis/horizon/frontier.md` (lane 7), `docs/analysis/horizon/algorithm.md` (lane 2), `docs/analysis/chip-model-v3.md`, `docs/analysis/51-percent.md`, `docs/bench-log.md` ("Rental cost of hash, 6 October 2026"), `horizon-2026-10.md`, `finality-in-proof.md`, `tail-emission.md`, `vote-or-burn.md`, `prover-tiers-real-cards.md`. + +Memory and GPUs: +- TrendForce, NVIDIA fuels HBM4 race, 9 Jan 2026: https://www.trendforce.com/news/2026/01/09/news-nvidia-demand-fuels-hbm4-race-12-layer-ramps-16-layer-push-by-sk-hynix-samsung-and-micron/ +- EE Times, The state of HBM4 at CES 2026: https://www.eetimes.com/the-state-of-hbm4-chronicled-at-ces-2026/ +- Astute Group, SK hynix 62 percent of HBM: https://www.astutegroup.com/news/general/sk-hynix-holds-62-of-hbm-micron-overtakes-samsung-2026-battle-pivots-to-hbm4/ +- siliconanalysts HBM pricing: https://siliconanalysts.com/tools/hbm-analysis +- TrendForce, Micron HBM4E 2027 to 2028, 23 Dec 2024: https://www.trendforce.com/news/2024/12/23/news-micron-plans-hbm4-mass-production-in-2026-customized-hbm4e-to-launch-in-2027-2028/ +- Tom's Hardware, TSMC and GUC HBM4E and C-HBM4E: https://www.tomshardware.com/pc-components/dram/hbm-undergoes-major-architectural-shakeup-as-tsmc-and-guc-detail-hbm4-hbm4e-and-c-hbm4e-3nm-base-dies-to-enable-2-5x-performance-boost-with-speeds-of-up-to-12-8gt-s-by-2027 +- TechTimes, Samsung HBM4E samples, 30 May 2026: https://www.techtimes.com/articles/317400/20260530/samsung-ships-industry-first-hbm4e-samples-36-tb-s-bandwidth-beats-sk-hynix-six-months.htm +- Tom's Hardware, SK hynix roadmap to 2031: https://www.tomshardware.com/pc-components/dram/sk-hynix-reveals-dram-development-roadmap-through-2031-ddr6-gddr8-lpddr6-and-3d-dram-incoming +- TechSpot, GDDR7 successor after 2028: https://www.techspot.com/news/110151-sk-hynix-expects-launch-ddr6-gddr7-successor-after.html +- TweakTown, RTX 60 Rubin GR20x: https://www.tweaktown.com/news/109619/next-gen-geforce-rtx-60-gpus-rumored-to-use-rubin-gr20x-family-gearing-up-for-2027-release/index.html +- wccftech, RTX 60 2028 launch rumour: https://wccftech.com/nvidia-rtx-60-2028-launch-rumor/ +- wccftech, 4 GB and 6 GB GDDR7: https://wccftech.com/4-gb-and-6-gb-gddr7-memory-chips-will-be-rolled-out-in-the-next-two-years/ +- TechPowerUp, UDNA 96 CUs: https://www.techpowerup.com/339101/amds-upcoming-udna-rdna-5-gpu-could-feature-96-cus-and-384-bit-memory-bus +- TweakTown, RDNA 5 mid-2027: https://www.tweaktown.com/news/112289/amds-rdna-5-radeon-gpus-will-launch-in-mid-2027-per-new-leak/index.html +- Tom's Hardware, AMD GDDR7 driver support: https://www.tomshardware.com/pc-components/gpus/amd-begins-to-add-gddr7-support-to-its-linux-gpu-drivers-changes-could-herald-use-of-advanced-memory-standard-with-next-gen-radeon-gpus +- VideoCardz, Medusa Halo LPDDR6: https://videocardz.com/newz/amd-ryzen-max-500-medusa-halo-rumored-to-support-lpddr6-memory +- Apple, M5 Pro and M5 Max, 3 Mar 2026: https://www.apple.com/newsroom/2026/03/apple-debuts-m5-pro-and-m5-max-to-supercharge-the-most-demanding-pro-workflows/ +- Apple, Mac Studio M5 Max and M5 Ultra, Aug 2026: https://www.apple.com/newsroom/2026/08/apple-introduces-new-mac-studio-with-m5-max-and-m5-ultra/ +- JEDEC LPDDR6 press release: https://www.jedec.org/news/pressreleases/jedec%C2%AE-releases-new-lpddr6-standard-enhance-mobile-and-ai-memory-performance +- JEDEC DDR5 JESD79-5D: https://www.jedec.org/standards-documents/docs/jesd79-5d +- Lee et al., Reducing DRAM latency at low cost (latency stagnation): https://arxiv.org/pdf/1604.08041 +- Chang et al., Flexible-latency DRAM: https://arxiv.org/pdf/1805.03154 +- Wikipedia, Feynman microarchitecture: https://en.wikipedia.org/wiki/Feynman_(microarchitecture) + +Chip costs: +- siliconanalysts wafer and mask pricing (Sep 2026): https://siliconanalysts.com/data/wafer-pricing +- siliconanalysts tapeout cost guide, 1 Mar 2026: https://siliconanalysts.com/analysis/fabless-startup-tapeout-cost-guide +- siliconanalysts TSMC 3 nm cost: https://siliconanalysts.com/guide/tsmc-3nm-cost +- SemiWiki, TSMC A14: https://semiwiki.com/forum/threads/tsmc-a14-at-2026-dec-iedm.25920/ + +GPU supply and rental: +- HPCwire, TechInsights 3.76 M datacentre GPUs 2023, 10 Jun 2024: https://www.hpcwire.com/2024/06/10/nvidia-shipped-3-76-million-data-center-gpus-in-2023-according-to-study/ +- Omdia, AI data centre chip market, Aug 2025: https://omdia.tech.informa.com/pr/2025/aug/ai-data-center-chip-market-to-hit-286bn-growth-likely-peaking-as-custom-asics-gain-ground +- Tom's Hardware, Blackwell cabinet forecasts halved: https://www.tomshardware.com/tech-industry/artificial-intelligence/analysts-halve-nvidia-gb200-blackwell-shipment-forecasts-for-2025-prediction-contrasts-ai-boom +- Jon Peddie Research, Q2 2026 AIB shipments: https://www.jonpeddie.com/news/q226-pc-graphics-aib-shipments-increased-10-from-last-quarter-to-12-million-units/ +- mercatus-ai, H100 resale value (23 Jun 2026): https://www.mercatus-ai.com/blog/h100-resale-value +- intuitionlabs, used AI GPU prices 2026: https://intuitionlabs.ai/articles/used-ai-gpu-prices-resale-trends +- cloudzero, H100 price 2026: https://www.cloudzero.com/blog/h100-gpu-cost/ +- spheron, GPU cloud pricing 2026: https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/ + +Energy, heat, mining rules: +- Ofgem price cap: https://www.ofgem.gov.uk/your-energy-supply/your-energy-bill/energy-price-cap-unit-rates-and-standing-charges +- Eurostat, household electricity prices H2 2025, 5 May 2026: https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20260505-1 +- EIA, US electricity prices: https://www.eia.gov/todayinenergy/detail.php?id=65284 +- EIA AEO2025 via The Energy Coop: https://theenergy.coop/blog/unpacking-2025-aeo/ +- Cornwall Insight via Solar Power Portal, 10 Jan 2024: https://www.solarpowerportal.co.uk/energy-policy/cornwall-insight-forecasts-lower-gb-power-prices-on-the-long-road-to-truly-affordable-energy- +- spark.money, mining profitability by country: https://www.spark.money/tools/bitcoin-mining-profitability-by-country +- Hashrate Index, Paraguay 2026 (4 May 2026): https://hashrateindex.com/blog/the-state-of-bitcoin-mining-in-paraguay-2026-2/ +- miningboard, bitcoin heaters 2026: https://miningboard.com/guides/bitcoin-heaters +- techbuzz on Wired's Heatbit review, 5 Apr 2026: https://www.techbuzz.ai/articles/heatbit-s-bitcoin-mining-heater-fails-the-math-test +- Qarnot (French Wikipedia): https://fr.wikipedia.org/wiki/Qarnot +- ABC13, ERCOT paid Riot USD 31.7 M: https://abc13.com/post/ercot-texas-power-grid-riot-bitcoin-miners/13753300/ +- Riot June 2025 update: https://www.globenewswire.com/news-release/2025/07/03/3109856/0/en/Riot-Announces-June-2025-Production-and-Operations-Updates.html +- CoinDesk, Norway ban, 23 Jun 2025: https://www.coindesk.com/tech/2025/06/23/norway-plans-ban-on-new-crypto-mining-data-centers-to-preserve-power +- CoinDesk, Sweden tax, 14 Apr 2023: https://www.coindesk.com/policy/2023/04/14/sweden-drives-final-nail-into-its-bitcoin-mining-industry-with-tax-hike +- crypto.news, Sweden back-tax: https://crypto.news/sweden-orders-six-crypto-firms-to-pay-56m-in-additional-taxes/ +- TASS, Moscow mining ban: https://tass.com/politics/2152151 +- Cryptopolitan, Russia regions: https://www.cryptopolitan.com/russia-regional-crypto-mining-ban-2025/ +- Caspian News, Kazakhstan lifts restrictions, 17 Nov 2025: https://caspiannews.com/news-detail/kazakhstan-lifts-restrictions-on-cryptocurrency-mining-trading-2025-11-17-36/ +- KuCoin, Kazakhstan strategic mining from 1 Aug 2026: https://www.kucoin.com/news/flash/kazakhstan-to-enforce-strategic-crypto-mining-rules-from-august-1 +- Lightspark, China 2026: https://www.lightspark.com/knowledge/is-crypto-legal-in-china +- egw.news, China provinces (uncorroborated): https://egw.news/crypto/news/30440/china-officially-brings-back-mining-sichuan-inner--NnyU95QrT +- ainfp, Iran mining 2026: https://ainfp.org/mining-crypto-in-iran-legal-status-restrictions-risks +- Dechert, SEC PoW mining statement, Mar 2025: https://www.dechert.com/knowledge/onpoint/2025/3/sec-staff-issues-statement-on-proof-of-work-crypto-mining-activi.html +- Fortune, EIA survey backlash, 1 Mar 2024: https://fortune.com/crypto/2024/03/01/department-energy-survey-bitcoin-miners-legal-backlash/ +- Cointelegraph, DAME tax revived: https://cointelegraph.com/news/crypto-mining-tax-united-states-budget +- sazmining, US state mining laws 2026: https://www.sazmining.com/blog/us-crypto-mining-rules-review + +Proving: +- EF, Realtime proving, 10 Jul 2025: https://blog.ethereum.org/2025/07/10/realtime-proving +- Ethproofs 2025 review, 6 Dec 2025: https://hackmd.io/@willcorcoran/S1A840ZMZg +- Succinct, SP1 Hypercube on mainnet: https://blog.succinct.xyz/sp1-hypercube-is-now-live-on-mainnet/ +- bex.co, Cysic Venus, 17 Apr 2026: https://bex.co/blog/2026/04/17/cysic-venus-multi-gpu-zk-proving-real-time-verification-bottleneck +- bex.co, Airbender, 30 Jan 2026: https://bex.co/blog/2026/01/30/zksync-airbender-fastest-risc-v-zkvm-ethereum-proving +- GitHub comparative analysis, Sep 2026: https://github.com/Ricosworks1/blockchain-payment-flow-analysis/releases/tag/comparative-analysis-ethereum-zk-proving-race-sept-2026 +- cryptobriefing, Lattice Jolt, 9 Sep 2026: https://cryptobriefing.com/lattice-jolt-post-quantum-zkvm/ +- RISC Zero, R0VM 2.0: https://risczero.com/blog/introducing-R0VM-2.0 +- h33.ai, ZK proof companies 2026: https://h33.ai/blog/zk-companies/ +- Cysic ZK ASIC docs: https://docs.cysic.xyz/hardware-products/zk-asic-products/ +- Ingonyama and Accseal: https://www.ingonyama.com/oldblogs/partnership-announcement-accseal-x-ingonyama +- LambdaClass, SP1 exploit disclosure, 26 Jan 2025: https://blog.lambdaclass.com/responsible-disclosure-of-an-exploit-in-succincts-sp1-zkvm-found-in-partnership-with-3mi-labs-and-aligned-which-arises-from-the-interaction-of-two-distinct-security-vulnerabilities/ +- Blockworks, SP1 bug: https://blockworks.co/news/succinct-sp1-bug +- HackenProof, RISC Zero missing constraint, May 2025: https://hackenproof.com/blog/for-hackers/risc-zero-zkvm-missing-constraint-vulnerability +- EF, On formal verification and a bug in SP1 Hypercube, 20 May 2026: https://zkevm.ethereum.foundation/blog/sp1-fv + +Light clients: +- a16z Helios: https://github.com/a16z/helios and https://a16zcrypto.com/posts/article/building-helios-ethereum-light-client/ +- Ethereum annotated spec, sync protocol: https://github.com/ethereum/annotated-spec/blob/master/altair/sync-protocol.md +- Portal Network: https://ethportal.net/overview +- Mina 22 KB: https://www.gate.com/learn/articles/what-is-mina-protocol/4814 +- Celestia Lumina: https://github.com/celestiaorg/lumina +- Lightning Labs Neutrino: https://github.com/lightninglabs/neutrino +- Blixt features: https://blixtwallet.github.io/features +- StarkWare 1 MB Bitcoin verifier, 11 Sep 2025: https://www.cryptotimes.io/2025/09/11/starkware-unveils-1mb-bitcoin-verifier-for-mobile-devices/ +- Mopro benchmarks: https://zkmopro.org/docs/0.2/performance/ and https://hackmd.io/@vivi432/mopro-benchmark +- provebench: https://github.com/agnij-dutta/provebench +- shattered.io, STARK 45 KB verify: https://shattered.io/bulletproofs-vs-zk-starks-2026/ +- Wikipedia WebGPU: https://en.wikipedia.org/wiki/WebGPU +- Zcash Tachyon-Lite grant: https://forum.zcashcommunity.com/t/grant-proposal-tachyon-lite-light-client-sdk-and-sync-proof-server-for-zcash/55671 + +Post-quantum: +- Cloudflare, ML-DSA will have to do, 9 Jul 2026: https://blog.cloudflare.com/ml-dsa-will-have-to-do/ +- encryptionconsulting, FN-DSA FIPS 206: https://www.encryptionconsulting.com/education-center/fn-dsa-fips-206/ +- encryptionconsulting, NIST IR 8547 deadlines: https://www.encryptionconsulting.com/nist-ir-8547-2030-2035-action-plan/ +- NIST PQC standardisation: https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization +- Global Risk Institute, Quantum Threat Timeline Report 2025: https://globalriskinstitute.org/publication/quantum-threat-timeline-report-2025b/ +- postquantum.com, Google ECDLP resources: https://postquantum.com/security-pqc/google-quantum-bitcoin-ecdlp/ +- postquantum.com, 835 logical qubits (arXiv 2607.13816): https://postquantum.com/security-pqc/ecc-secp256k1-835-logical-qubits/ +- arXiv, Brace for impact (ECDLP challenges): https://arxiv.org/pdf/2508.14011 +- ethereum.org, post-quantum cryptography: https://ethereum.org/roadmap/security/quantum-resistance/ +- The Quantum Insider, EF PQ team, 26 Jan 2026: https://thequantuminsider.com/2026/01/26/ethereum-foundation-elevates-post-quantum-security-to-top-strategic-priority/ +- The Quantum Insider, BIP-360 testnet, 20 Mar 2026: https://thequantuminsider.com/2026/03/20/btq-technologies-implements-bip-360-quantum-resistant-bitcoin-transactions-testnet/ +- qsha256, BIP-360 and BIP-361: https://qsha256.com/blog/bitcoin-pq-migration + +Regulation: +- Osborne Clarke, MiCAR white papers and Bitcoin, 4 Oct 2023: https://www.osborneclarke.com/insights/what-are-eus-white-paper-requirements-micar-and-do-they-apply-bitcoin +- Conventus Law, crypto-assets without an identifiable issuer: https://conventuslaw.com/report/crypto-assets-without-an-identifiable-issuer-regulatory-reality-two-years-post-micar-application-date/ +- Latham, MiCA white paper and sustainability disclosures: https://www.lw.com/en/markets-in-crypto-assets-regulation-tracker/mica-white-paper-sustainability-disclosures +- carbon-ratings, MiCA sustainability indicator methods: https://carbon-ratings.com/dl/whitepaper-mica-methods-2024 +- European Commission, 2026 MiCA review targeted consultation (reply by 31 Aug 2026): https://finance.ec.europa.eu/document/download/62be7015-f066-4fac-b74e-71bacdbcc9f5_en?filename=2026-mica-review-targeted-consultation-document_en.pdf +- ESMA, end of MiCA transitional periods, Apr 2026: https://www.esma.europa.eu/sites/default/files/2026-04/ESMA75-113276571-1679_Statement_on_the_end_of_transitional_periods_under_MiCA.pdf +- FCA, cryptoasset regime policy statements: https://www.fca.org.uk/publications/policy-statements/cryptoasset-regime +- Lewis Silkin, UK draft Regulations and perimeter guidance, 30 Sep 2026: https://www.lewissilkin.com/insights/2026/09/30/uk-cryptoasset-regime-draft-regulations-and-fca-perimeter-guidance-provide-furth-102o3vf +- Skadden, FCA finalises core rules, Jul 2026: https://www.skadden.com/insights/publications/2026/07/fca-finalises-core-rules-for-the-uk-cryptoasset-regime +- Orrick, CLARITY stalls, 2 Oct 2026: https://www.orrick.com/en/Insights/2026/10/The-CLARITY-Act-Stalls-in-the-Senate-Whats-Next-for-Digital-Asset-Regulation +- FATF, travel rule supervision best practices, Jun 2025: https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/Best-Practices-Travel-Rule-Supervision.pdf +- Sumsub, FATF Recommendation 16 revision: https://sumsub.com/media/spotlight/same-rule-same-problems-will-fatf-travel-rule-fix-the-divide/ +- Dechert, DFSA crypto token regime, 13 Jan 2026: https://www.dechert.com/knowledge/onpoint/2026/1/dubai-updates-crypto-token-regulatory-framework.html +- TradingView/Coinpedia, UAE and VARA 2026: https://www.tradingview.com/news/coinpedia:681009ff8094b:0-crypto-regulations-in-uae-dubai-in-2026/ diff --git a/docs/analysis/mission/invent.md b/docs/analysis/mission/invent.md new file mode 100644 index 00000000..108cd387 --- /dev/null +++ b/docs/analysis/mission/invent.md @@ -0,0 +1,528 @@ +# The last mission, lane 4: what can be invented, judged hard + +7 October 2026, morning UK. Lane 4 of the final research programme ("the last mission"), worktree `igneum-wt-mission`. The question: given everything Igneum already has (the horizon one page, the frontier lane's sixteen ideas, the new-PoW lane's three schemes, class v5, finality in the proof, work-stake, the tail, vote-or-burn, the ladder, the pool design, the light client, the phone app), what is the NEXT genuinely new thing a GPU chain could do that none has. Every candidate here was checked against prior art by name and year, run through its own game theory with a model this lane ran (`invent_model.py`, section 0), reviewed in the Monero or Kaspa developer's voice, priced in agent hours with a first gate, and given its per-tier consequence and four persona verdicts. Nothing here touches the devnet. No em dashes. Figures from memory say approximate; figures from a source name it. + +the project lead's rulings are applied as a filter before any idea is scored: miners are the security always; no stake and no coin bond; no holder penalised; no device bounty; no fixed-height activations; no calendar dates; no reliance on another chain; no dev fund; no privacy; nothing that becomes a token sale; the lottery and the proving stay separate; emission carries security with no end date. An idea that needs one of these is marked dead in one line. + +## 0. Progress, method and the four voices + +| Time (UK) | State | +|---|---| +| 08:05 | Lane started; read CLAUDE.md, the horizon one page (sections 1 to 3), frontier.md (sections 0 and 3, all sixteen), new-pow.md (3, 4, 6, 7), class-v5-stored-state.md, finality-in-proof.md, work-stake.md, tail-emission.md (one page), vote-or-burn.md, latency-ladder.md, 51-percent.md, pool.md, spec 09, spec 10, phone-app.md, the four persona files, bench-log (rental cost, warp verify, aggregation, 5090 rows) | +| 08:35 | Prior art checked by WebFetch on primary pages (the session's WebSearch budget was already spent; every page that answered is in the sources list; four pages 404'd and those items are labelled approximate) | +| 08:51 | `invent_model.py` written and run in the lane's scratch (`mission-invent/out.md`); every table below marked "model" is printed by it | +| 08:59 | This file written (528 lines, 0 em dashes, not staged); final message to the coordinator | + +**Method.** Three passes per candidate. (1) Prior art: the paper, project or repository that did it, with the year, and the one sentence of what differs. (2) Game theory: who gains from cheating, the attack, its cost, the bound; a short numeric model actually run. (3) The hostile review in the Monero or Kaspa developer's voice, then the prototype cost in agent hours, the first measurable gate, the per-tier consequence (home miner 8 / 12 / 16 / 24 to 32 GB, rig, pool user; Windows, Linux, macOS; NVIDIA, AMD, Apple) and four persona verdicts: do now, prototype, watch, never. + +**The four voices.** The cryptographer, the consensus engineer and the miner (the miner-community lead) are the persona files in `.claude/agents/`. The fourth, the economist, is defined here from the economy lane's method (`docs/analysis/horizon/economy-and-utility.md`, `tail-emission.md`): every number is priced in rented hash at the measured USD 0.0117 per MH/s-hour (bench-log, "Rental cost of hash", 6 October 2026); an IGN price is an input never a prediction, shown at USD 0.005, 0.02 and 0.10; fees are never assumed to be the security budget; a mechanism that moves income is judged by who pays, who is paid, and whether the payer would rather leave; the per-tier consequence is stated before anyone asks. + +**Price basis used throughout.** Subsidy 100 IGN a block at one block a second (the tail-emission recommendation; today's code pays 31.688). Rented hash USD 11.7 per GH/s-hour. CPU verify of one 32-lane unit: 0.441 ms class v3 steady (bench-log line 170), 5.06 ms class v4 cold on the box's core (horizon L2), 1.35 ms per pool share check in isolation (pool.md section 5); the gate is 10 ms. Header 400 B working figure (spec 10.9). Snapshot 114.8 MB (horizon rank 22). Groth16 proof 260 B (SP1 docs), public values with the finality extension 494 B (finality-in-proof section 1). + +**What the measurement budget did not allow.** Nothing in this lane needed the box or a GPU pod to reach a verdict; where a first gate needs one, the gate names the command and the expected number and the final message lists it for the coordinator. + +--- + +## 1. Hashing useful to the chain itself, without reopening the useful-work trap + +The trap, restated from new-pow section 3.1 and frontier 3.10: a lottery needs a sampleable puzzle with a cheap verifier; any coupling of the puzzle to a scarce skill hands the lottery to the best at that skill (Aleo). The four variants below avoid the trap by keeping the hash kernel byte for byte as shipped and changing only what a miner must HOLD or must have DONE to build the dataset or to be paid. That is class v5's shape (new-pow scheme C: hash rate 63.083 against 63.088 MH/s on the 4090, build +1.4 ms, verifier +0.11 to 0.21 ms per unit), so the question for each is only: what does it add to class v5 that is measurable, and does the addition survive its own game. + +### 1.1 What class v5 already delivers, so nothing below re-invents it + +| Property | Delivered by class v5 | Where | +|---|---|---| +| Every mining operation holds the day's execution state | yes, by construction: `leaf(t) = D[t mod n]` keys every item; a stateless hasher is wrong on every item (the known-failed case) | class-v5 section 3, 4 | +| Every block names 128 random state leaves per lane any full node can open against `R_d` | yes; the opening RPC is new-pow rank 6 (4 hours, not built) | new-pow 3.3, 7 | +| The miner must know the chain to within the epoch lead | yes, already since class v3: the program is the 10-minute VDF of a certified checkpoint 20 minutes before the epoch (spec 04 4.3); a miner without the last hour of chain has the wrong program and every hash is wrong | spec 04 | +| The f = 0 recompute chip must hold the state | yes | new-pow 6 | +| The pool caveat | stated: a pool ships `D` once a day (6 KB today, 1 to 2 GiB on a used chain) | class-v5 section 3 | + +### 1.2 (a) Proof of following: the day's leaves include the last N blocks + +**The idea.** Widen class v5 so that the dataset derives from the state AND from the chain's recent blocks: the day's leaf array gains the hashes or receipts of the last N chain blocks before the cut, so a miner proves it relayed or held recent blocks, not only the state. + +**Prior art.** Verthash (Vertcoin, January 2021, approximate: the vertcoin.org page 404'd this morning): a 1.2 GB dataset built from the chain's own block headers, random reads per hash. Ethash (2015): dataset from the epoch seed. Class v5 (this project, 7 October 2026): dataset from the execution state. Permacoin (Miller, Juels, Shi, Parno, Katz, IEEE S&P 2014): proof of retrievability of a dealer's file. The combination "state plus recent headers" is new in form; Verthash is the nearest in substance. + +**Mechanism.** + +| Item | Rule | +|---|---| +| Extra leaves | after the state records, one record per chain block in `(daa(C_d) - N, daa(C_d)]`: `0x04 ‖ block_hash ‖ state_root ‖ receipts_root` | +| Keyed by | `R_d` as every other leaf; the day's cut `C_d` is one hour before the day (class-v5 section 2) | +| What it forces | a builder must hold the last N headers and receipt roots before the cut | +| What class v5 forces already | the whole state after `C_d`, which commits to every one of those blocks through `R_d` | + +**Game theory.** Nobody gains from cheating because there is nothing to cheat: the state root already commits to the chain. The only question is what a miner must HOLD. Under class v5 a miner holds `D` (the state sample); under 1.2 it also holds N header records it can fetch from any peer in one round trip. Model (section A of `invent_model.py`, the outsourcing row): a key with nothing answers a fetch in about 108 ms over a 100 ms link. The addition forces no holding that a pool's daily delivery does not already satisfy, and the "following" it proves is the following the epoch seed proves every hour at zero cost. + +**What is measurable.** Nothing new per block. The receipts are a function of the state transition every executing node already computed; the day's cut already requires the chain to within an hour; the epoch seed requires it to within 80 minutes. The one measurable thing would be a per-block dataset change, and a per-block build is 32 ms on a 4090 (class-v5 section 2) against a 1,000 ms block: a 3.2 percent hash loss on every card every second for a property the program swap gives every hour for free. + +**Hostile review (Kaspa voice).** "You have a dataset keyed by a state root that is itself a function of every block in the chain's past. Adding the last N block hashes as leaves adds information the root already carries. If you want 'following', the program swap is your following: a miner that is an hour behind has the wrong kernel. Do not add bytes to a build that already proves the thing." + +**Cost and gate.** 0 hours: not built. If someone insists: the gate is the fast-time harness showing a stateful miner with stale headers is refused, which the state root already does. + +**Per tier.** No change for any card, rig or pool user; the verifier's RAM unchanged. + +**Verdicts.** Cryptographer: never (the root commits to the chain; redundant). Consensus engineer: never (bytes for nothing). The miner: never (nothing to see). Economist: never (no income moves). Verdict: never, with the sentence "proof of following is the epoch seed plus class v5" written into class-v5's litepaper paragraph. + +### 1.3 (b) Proof of serving: a reward component for serving headers, snapshots and proofs + +**The idea.** A slice of the producer's 80 points is paid only to keys that served data to peers in the window, verified by challenge-response sampled into blocks. + +**Prior art.** Filecoin WindowPoSt (2020; spec.filecoin.io: 48 deadlines of 30 minutes a day, randomness from a beacon 20 epochs before the deadline, fee debt on a missed proof); Arweave SPoRA (version 2.4, February 2021, approximate: the docs page 404'd; mining reward requires random access to stored chunks); Sia storage proofs (2015, approximate) and Storj audits (2018, approximate); Celestia data availability sampling (2023, approximate); EigenDA (2024, approximate); Ethereum PeerDAS (EIP-7594, 2024: custody by node id, cell KZG proofs, and the EIP states no reward or penalty for serving); Kaspa archival nodes (a flag on kaspad, unrewarded; the README fetched this morning does not document it, approximate). What differs here: the data served is the chain's own state, the challenger is the next block producer and the randomness is the chain's, and the reward is a slice of the block subsidy to a miner key, not a storage market. + +**Mechanism.** + +| Item | Rule | +|---|---| +| Challenge | block B's producer draws `c` keys from the weight table at the last certified checkpoint in B's past, by weight, seeded by B's prehash; for each, 8 leaf indices of the day's `D` | +| Answer | the challenged key signs `(B, leaves, openings against R_d)` and any producer carries it within `T` blocks | +| Failure | no answer carried in `T` blocks after B | +| Reward | x of the 80 producer points conditional: a key with an unanswered challenge in the window is paid 80 - x on its next blocks until it answers one | +| Bytes | 8 leaves x (64 + 25 x 32) + 96 B signature = 6.8 KB per answer; 1 challenge per block = 0.61 GB a day on every node (model, table A2) | + +**Game theory (model, section A).** + +| Attack | Cost | Bound | +|---|---|---| +| Serve yourself from your own nodes | zero; the challenged key answers its own challenge from the state it already holds to mine under class v5 | the proof reduces to "I hold what class v5 already makes me hold" | +| Outsource the answer to a peer that holds the state | one fetch, about 108 ms on a 100 ms link; any deadline over one block (1,000 ms) admits it | the proof becomes "someone with the state answered"; Filecoin's answer is sealing (replicas slower to fetch than to read), which costs hours of CPU per sector and does not fit a daily dataset | +| Producer griefing: refuse to carry answers | an answer gossips to every producer; withholding for T blocks needs a majority of producers for T seconds | the same bound finality lives with | +| Sybil the draw | the draw is by weight; a dust key is never drawn; splitting a key splits its draws and its loss | nothing to gain | +| Loss to a key that never serves at x = 8 | 0.1 percent key: 691 IGN a day (USD 3.5 at 0.005); 10 percent key: 69,120 IGN a day | the price of not running a node, which a miner under class v5 must run anyway | + +**Load per key.** At 10,000 keys and one challenge per block a key's share of challenges is its weight share: 8.64 a day for a mean key, 0.06 MB of upload a day, 0.006 kbit/s. At 128 leaves per challenge and 8 per block, 7.6 MB a day. Every home connection carries it (table A1). The cost is on the chain, not the key: 0.61 to 76.5 GB a day of answers on every node depending on the two parameters. + +**Hostile review (Monero voice).** "You pay a miner for proving it holds the thing your own lottery forces it to hold. The challenge adds 0.6 GB a day to every node to learn nothing, and the fetch bound makes it 'someone served', which is what gossip already guarantees. Filecoin pays for storage because storage is the product; your product is blocks. The one honest version is unpaid: a light-client spot check of availability, which is your rank 6 RPC." + +**Cost and gate.** 0 hours as a reward; 4 hours as new-pow rank 6 (the opening RPC, unpaid), whose gate is 128 openings verifying against `R_d` on the fast-time network. + +**Per tier.** As a reward: every tier pays bytes (0.61 GB a day of chain) to prove what class v5 proves. As the unpaid RPC: a node serves 102 KB per request on demand; a light client gains a daily availability spot check; no card changes. + +**Verdicts.** Cryptographer: never as a reward, do the RPC (the outsourcing bound makes the proof vacuous). Consensus engineer: never (0.61 to 76 GB a day for no new property). The miner: never (a line item nobody understands). Economist: never (it moves x points for a service already compelled). Verdict: never as protocol; new-pow rank 6 stands. + +### 1.4 (c) Proof of propagation: signed receipts from peers in the next block + +**The idea.** A block carries receipts, signed by peers' vote keys, that they received the previous block within t seconds; the producer is paid a slice for fast propagation. + +**Prior art.** Bitcoin's Relay Network and FIBRE (Matt Corallo, 2016; bitcoinfibre.org: UDP, forward error correction, compact blocks; no protocol payment to relays). Kaspa's relay is the ordinary p2p flow with no receipts (approximate). "Proof of relay" papers: this lane found none that shipped; the arXiv search for "proof of latency" returned five unrelated papers (section 7.11). GHOSTDAG itself: a slow block is red and its subsidy goes to its merger (spec 02 2.5), which is the propagation reward the DAG already pays. + +**Mechanism and why it dies.** + +| Item | Problem | +|---|---| +| The time field | no consensus clock finer than Kaspa's timestamp window (a header at most 10 s ahead of the clock, spec 02; the DAG tolerance 132 s in frontier 3.1); a receipt's "within t seconds" is the signer's word | +| Sybil receipts | peers are keys; weight-drawn receipts cost the attacker nothing because its own keys sign its own receipts | +| Bytes | 8 receipts x 136 B = 1,088 B per block, 94 MB a day; 32 receipts 376 MB a day (model, section H) | +| What the DAG already does | at 1 block/s on Devnet 2 run B the red rate was under 2 percent from minute six (bench-log, "Block rate on Devnet 2"); a block that propagates slowly is red and its subsidy moves to its merger: the propagation reward exists and is measured in blue blocks, which are also the vote weight | + +**Hostile review (Kaspa voice).** "GHOSTDAG is a proof of propagation. Blue means it arrived in time; red means it did not; the k parameter is the clock. Receipts signed by the people who benefit from them prove nothing and cost 94 MB a day." + +**Verdicts.** All four: never. Cost 0. + +### 1.5 (d) Proof of state availability with block-derived challenges and the producer's own next block + +**The idea.** As 1.3 but the challenge is issued by the producer's own next block (so no trusted party), answered on demand, and the reward slice is paid only to keys that answered. + +This is 1.3 with the challenger named. The trap the brief names ("who issues challenges without a trusted party") is answered correctly by block-derived randomness and the producer's next block, and the answer does not rescue the idea: the outsourcing bound (a fetch in 108 ms) and the self-serving bound (the key answers from the state class v5 makes it hold) are unchanged. The one new element, "the producer's own next block" as the carrier, makes the producer the judge of its own challenge and needs a second producer to carry the answer for fairness, which is 1.3's `T` blocks. + +**Verdicts.** All four: never as a reward; the unpaid availability spot check (new-pow rank 6) is the whole of what survives. Cost 4 hours for the RPC. + +### 1.6 Section 1 in one table + +| Variant | Prior art | New? | Survives its game? | Cost | Verdict | +|---|---|---|---|---|---| +| (a) proof of following | Verthash 2021; class v5 2026 | in form only | yes, because it does nothing | 0 | never: the epoch seed and the state root already prove following | +| (b) proof of serving | Filecoin PoSt 2020; Arweave SPoRA 2021; PeerDAS 2024 (unrewarded) | the reward to a miner key is new | no: outsourced in 108 ms; self-answered under class v5 | 0 (4 for the unpaid RPC) | never as a reward | +| (c) proof of propagation | FIBRE 2016 (unpaid); GHOSTDAG's reds | no | no: time is unverifiable; receipts are Sybil-free | 0 | never | +| (d) state availability by the producer's next block | same as (b) | the challenger rule is new | no, same bounds as (b) | 4 (RPC) | never as a reward | + +--- + +## 2. A block reward that pays for availability of the chain's state + +**The exact split proposal, as asked.** Of the 80 producer points, x are conditional on the key having served state in the window, verified as in 1.5; the rest unconditional. The candidate x: 2, 4 or 8 (8 would mirror the signing bonus of vote-or-burn, which pays 8 of the 80 for signing). + +**The attack: serve yourself.** The challenged key answers from the state it holds; the challenge is drawn by weight, so the key's own weight is the only thing that decides how often it is asked. A key that runs a node (every class v5 miner) passes every challenge at zero marginal cost. A key that runs no node and proxies to a pool passes every challenge at one fetch. Nobody fails except a key whose node is down, which is the signing bonus's case already (vote-or-burn section 1: the honest-silence classes), so the conditional slice is a second liveness bonus on the same event. + +**The Sybil bound.** Vote-key weight as the challenge draw: a dust key is never drawn, a split key is drawn in proportion, so splitting gains nothing. Correct, and it also means the mechanism measures the keys that already mine, who already hold the state. + +**Per-tier cost (model, table A1).** At 10,000 keys, one challenge per block, 8 leaves: a mean key uploads 0.06 MB a day; at 8 per block and 128 leaves, 7.6 MB a day, 0.7 kbit/s. Any home connection on any OS carries it. The chain pays 0.61 to 76.5 GB a day of answer bytes on every node for the two parameter corners. + +**What it costs a key that never serves (model, table A3).** At x = 8: 0.01 percent key 69 IGN a day, 0.1 percent 691, 1 percent 6,912, 10 percent 69,120 (USD 0.3 to 346 at 0.005). The same shape as the signing bonus and for the same population. + +**Hostile review (Monero voice).** "Two liveness bonuses on one event is one bonus with worse accounting. Your signing bonus already pays 8 points for 'my node is up and following'; this pays x more for 'my node is up and holds the state', which under class v5 is the same node. Merge them or drop this." + +**The economist.** No payer wants it: the slice comes from the same producer share, so it is a transfer from keys whose nodes are down to keys whose nodes are up, which the signing bonus already does; the chain pays gigabytes a day for the second accounting. + +**Verdicts.** Cryptographer: never (vacuous under the outsourcing bound). Consensus engineer: never (bytes). The miner: never (a second deduction line is read as a second fine; vote-or-burn's 93 to 97 percent respect for one bonus at genesis would not survive two). Economist: never. Cost 0. + +--- + +## 3. Mining that is also a light-client service + +**The idea.** Every miner's node serves finality-in-proof public values (494 B) and certificate bitmaps to phones; a reward slice or a fee market pays for it. + +**Prior art.** Ethereum Portal Network (2021 to 2026; ethportal.net: history, state and beacon networks; clients Trin, Nimbus Portal (Fluffy), Ultralight, Shisui; the site states no reward for nodes). Helios (a16z, 2022, approximate for the year; github: weak-subjectivity checkpoints as the root of trust, sync-committee verification). Mina's snarkers (2021, approximate): a fee market for SNARK work inside the protocol. Celestia light nodes and bridges (2023, approximate). What Igneum has that none of these had: the serving node is a miner with a funded key, and the object served (494 B of public values plus a 260 B Groth16 proof, once the wrapper lands) is tiny and self-certifying. + +**Whether it is a protocol item.** No. The object is public values a node already holds; serving it is one HTTP or wss endpoint (spec 10.7's read-only table); the phone app already reads nodes it pins (phone-app section 5). A fee market for 786 bytes is a transaction per fetch at 0.0051 IGN (frontier 3.13's transfer floor), which no phone will pay per refresh and no node needs. A reward slice is 1.3's reward with a different payload and the same vacuity. + +**What it is: an Ember feature.** Ember in verify mode is frontier 3.8 (do now, 20 hours). The light-client serving side is a line in the node's RPC: `igneum_getLatestWrappedProof`, served to any client, rate-limited per IP, with the phone app pinning the user's own node by its card (phone-app section 5) or the seed list. Bytes per day per phone: 786 B per refresh, 2,880 refreshes a day if it polls every checkpoint = 2.3 MB (spec 10.5's phase-two figure, 2.30 MB, matches). + +**Game theory.** A node that lies serves a proof that does not verify, which the phone refuses; a node that withholds is replaced by the next pinned node. No payment, so no cheating for pay. The one attack is topology: a phone pinned to one node is eclipsed by that node, which spec 10.6's N of M seed agreement bounds. + +**Hostile review (Kaspa voice).** "Serving 786 bytes is not a service you price. It is a feature of a node. Put it in the app." + +**Cost and gate.** 4 hours (the RPC and the rate limit) on top of frontier 3.8's 20; gate: a phone on cellular shows "locked, voter set verified in the proof" from a miner's Ember node with no other node asked, bytes counted on the Verify screen. + +**Per tier.** Every miner's Ember serves phones by default behind a per-IP limit (a home upload of 786 B per request is nothing); a holder's phone gets its proof from any miner; a pool user's member process is the same Ember; no card or OS difference. + +**Verdicts.** Cryptographer: do now (as the Ember line). Consensus engineer: do now, not a protocol item. The miner: do now ("my node serves my phone" is a sentence miners like). Economist: do now, unpaid; a fee market here would price a service below its transaction cost. + +--- + +## 4. A decentralised pool in the protocol + +### 4.1 The design, as asked + +| Item | Rule | +|---|---| +| A share | a block header at a low difficulty, signed by the miner's own payout key, referencing the round `r` | +| The round | the window of blocks between two chain-block boundaries, e.g. 600 chain blocks (the record window of spec 7.8) | +| Carriage | any block carries shares it has seen; a share is valid if its header's PoW passes the share target and its parents are in the carrier's past | +| Payout | a coinbase rule every node computes: the producer share of blocks in round r is split by share weight (`2^-s`) over the shares carried in round r's blocks, PPLNS style, minus nothing (no operator, no fee) | +| Variance reduction | a miner is paid by its shares whether or not it found a block | + +### 4.2 Prior art + +| Name | Year | What it did | What differs | +|---|---|---|---| +| P2Pool (Bitcoin) | 2011 (Forrest Voight, approximate) | a sidechain of shares at a 10-s target; payouts in the coinbase of found blocks; no operator | the shares were off the main chain; nodes did not verify them | +| FruitChains | Pass and Shi, 2016 (eprint 2016/916) | "fruits" as low-difficulty PoW objects carried in blocks, rewarded fairly: any honest set with phi of the hash gets at least (1 - delta) phi of the reward | the exact in-protocol shape asked for here, published nine years ago; never shipped on a major chain | +| SmartPool | Luu, Velner, Teutsch, Saxena, 2017 (eprint 2017/019) | shares committed by Merkle root to an Ethereum contract, verified by sampling; miners paid 0.6 percent of block rewards in transaction fees | a contract, not a coinbase rule; the operator is the contract | +| Monero P2Pool | SChernykh, 2021 (github SChernykh/p2pool) | a 10-s share sidechain merge-mined with Monero, PPLNS over 2,160 shares (6 hours), no operator, payouts as coinbase outputs | off the main chain; Monero nodes do not verify shares | +| Stratum V2 job negotiation | Braiins, 2019 onward (approximate) | the miner builds its own template; the pool must pay shares on it | an operator remains; the vote and template are the miner's (spec 09 already takes this) | +| Ocean (Bitcoin) | 2023 (approximate) | an operator pool with on-chain payouts per block (TIDES) | an operator remains | +| Braidpool | 2021 onward (github braidpool/braidpool: in development, not production) | a DAG ("braid") of shares; miners build their own blocks; constant-size payouts | not shipped | +| Kaspa "SPECTRE shares" | none found | | Kaspa pools are Stratum bridges with operators (approximate) | + +So the in-protocol pool is FruitChains (2016) with Igneum's payout key and round. It is not new. + +### 4.3 The bytes and the verifier (model, section B) + +| Miners | Share interval | Shares per block | Bytes per block (compact 169 B) | Per day on every node | Verifier cores at 1.35 / 5.06 / 10 ms per share | +|---|---|---|---|---|---| +| 1,000 | 10 s | 100 | 16.5 KB | 1.5 GB | 0.14 / 0.51 / 1.0 | +| 10,000 | 10 s | 1,000 | 165 KB | 14.6 GB | 1.35 / 5.06 / 10.0 | +| 100,000 | 10 s | 10,000 | 1,650 KB | 146 GB | 13.5 / 50.6 / 100 | +| 100,000 | 100 s | 1,000 | 165 KB | 14.6 GB | 1.35 / 5.06 / 10.0 | +| 100,000 | 1,000 s | 100 | 16.5 KB | 1.5 GB | 0.14 / 0.51 / 1.0 | + +The full-header form (496 B) is 2.9x the bytes. The verifier at the class v4 cold figure (5.06 ms) needs 50 cores per node at 100,000 miners and a 10-s share interval, which no home node has; at a 1,000-s interval it fits one core and 1.5 GB a day, but then the variance reduction is the thing being bought and it has gone: + +| Income source | Paying events per day | CV of a day's income | CV of a month | +|---|---|---|---| +| solo 17 MH/s at 1 TH/s | 1.5 | 82.5 percent | 15.1 percent | +| shares at 1 per 1,000 s | 86 | 10.8 percent | 2.0 percent | +| shares at 1 per 100 s | 864 | 3.4 percent | 0.6 percent | +| shares at 1 per 10 s | 8,640 | 1.1 percent | 0.2 percent | + +At 100,000 miners the chain can afford one share per 1,000 s per miner (1.5 GB a day, one core), which gives a small card a 10.8 percent daily CV: a real improvement on 82.5 percent, at the cost of 1.5 GB a day on every node including every phone-class light client that would want to verify the coinbase. At 10,000 miners and 100 s the same bytes buy 3.4 percent. + +### 4.4 Does the vote key and sortition machinery give a round for free? + +Yes for the ROUND, no for the SHARES. W2 already counts blue blocks per key over 30 days, and the shard sortition already draws by that count (spec 7.2). A "round" and a per-key tally exist in every node. What does not exist is a sub-block unit of work, and that is the whole cost: every share is a PoW object every node verifies. The free version is to pay by BLOCKS over a window, which the protocol already does (every block pays its producer), so the free "pool" is the chain itself, and its variance is the solo row above. + +### 4.5 The attacks + +| Attack | Effect | Bound | +|---|---|---| +| Share withholding (find a block, publish only shares) | in an operator pool the withholder is paid shares and the pool loses the block; here the round's payout IS the blocks found, so a withheld block shrinks everyone's payout including the withholder's own share of it: the withholder loses `(1 - its share) x 80` points and gains nothing | self-defeating; FruitChains' fairness bound is the formal version | +| Share stuffing | every share is PoW at the share target, so a fake share costs its hash; stuffing is mining | none needed | +| Share grinding on the round boundary | a share's round is fixed by its parents; a share straddling a boundary is a DAG event nodes already order | none needed | +| A majority refusing to carry others' shares | it earns the majority a larger split of the round; this is red-flooding by another name, 26 to 28 percent of honest income at 51 percent (51-percent.md section 1) | the same bound as today's reds | +| Verifier DoS | a flood of invalid shares costs a node 5 ms each before rejection | the per-peer rate limits of the p2p layer; the ban score | + +### 4.6 The honest verdict against docs/plans/pool.md + +The shipped pool v0 (5 October 2026, rebased 6 October) already removes the two things an in-protocol pool is for: the operator holds no key and no vote (members sign their own votes through their own verifiers, spec 9.7), and the share rule is fixed by spec 9.8 so the member keeps its own ledger. The measured operator cost is 1.35 ms per share check (4,800 to 22,700 members per core) and 1 percent fee by default. What the operator still controls: transaction choice for mode A members who do not check (mode C fixes it), and the payout ledger's honesty (the member's own ledger plus the chain's blocks under its key bound it). + +The finished form is therefore the pool design plus one addition the brief names: **a verifiable payout contract**, which is SmartPool (2017) on Igneum's EVM: the operator posts the round's share Merkle root and the payout list; any member can prove under-payment with its own share log against the root; the contract pays from the pool address. Cost 16 hours (contract 6, operator posting 4, member proof and the Ember line 6). Gate: a member whose share is dropped from the root proves it on the fast-time network and is paid; an honest round costs the operator one transaction. Bytes on chain: 32 B per round per pool. Verifier cost on nodes: nothing per share. + +**Hostile review (Monero voice).** "P2Pool exists because we did not want shares on the main chain; your numbers say why: 14.6 to 146 GB a day. Our P2Pool is a sidechain nobody but miners runs. Build that if you want no operator; it costs your chain nothing." Answer: a Monero-style P2Pool sidechain for Igneum is an app a pool operator could ship (the share chain's only chain-side object is the coinbase payout list), and it is the same code as the pool v0 member minus the server; the lane recommends the contract first because it keeps every existing pool (HiveOS, WhatToMine listings) and makes them verifiable. + +**Per tier.** Home miner on any card: nothing changes in the worker; under the contract a member can prove under-payment from its own log. Rig: one key per rig as today. Pool user: the pool's round is public. Node operator: 32 B per round per pool instead of 1.5 to 146 GB a day. Light clients: unchanged. + +**Verdicts.** Cryptographer: never in protocol (FruitChains is the prior art and the bytes are the reason it never shipped); prototype the contract. Consensus engineer: never in protocol (50 cores per node at 100,000 miners on a 10-s share); the contract 16 hours. The miner: never in protocol (a chain that grows 14.6 GB a day from shares is the first thing a reviewer attacks); the contract is what listings want. Economist: the operator's 1 percent is already below SmartPool's 0.6 percent plus gas (approximate); the contract makes the 1 percent honest. Verdict: never in protocol; prototype the verifiable payout contract, 16 hours. + +--- + +## 5. Heat as product + +**The idea.** Ember's "heat mode" targets a room temperature or a schedule: the card mines when the room wants heat and idles when it does not; the chain does nothing. + +**Prior art.** Heatbit (2022 launch, approximate; heatbit.com this morning lists Bitair at 25 W, 1.2 TH/s, USD 179 to 249, and names earlier Maxi and Trio models), 21energy (Austria; Ofen 3 heaters EUR 1,658 to 3,325, "7 to 10 kW" central-heating models coming, 21energy.com), Qarnot (France, founded 2010, approximate, the Wikipedia page 404'd; QRad computing heater 2013, approximate; sells HPC and heats buildings), MintGreen in North Vancouver (2021, approximate), the Finnish and French district-heat trials (approximate; no page fetched). Every one is an ASIC or HPC box sold as a heater. None is a GPU chain's own client with a thermostat. Ember's version is new as a client feature and nothing else. + +**Numbers (model, section C).** A 300 W card delivers 300 W of heat at the card's electricity price. The competition is a gas boiler at 90 percent or a heat pump at COP 3. + +| Region | Card per hour | Gas boiler, same 300 W | Heat pump COP 3 | Resistive electric | Card must earn per hour to match boiler / heat pump | +|---|---|---|---|---|---| +| UK (Ofgem, 1 Oct to 31 Dec 2026: 26.32 p electricity, 7.97 p gas) | 7.90 p | 2.66 p | 2.63 p | 7.90 p | 5.24 p / 5.26 p | +| EU (Eurostat H2 2025: EUR 0.2896; gas EUR 0.11 approximate) | 8.69 c | 3.67 c | 2.90 c | 8.69 c | 5.02 c / 5.79 c | +| US (EIA July 2026: 18.31 c; gas 5 c approximate) | 5.49 c | 1.67 c | 1.83 c | 5.49 c | 3.83 c / 3.66 c | + +Against a resistive heater (a bedroom panel, a US baseboard) the mining heat is free and every IGN earned is profit. Against a boiler or a heat pump the card must earn about 5.3 p an hour in the UK. + +| Network hash | IGN per hour, 100 MH/s card at 100 IGN a block | at USD 0.005 | at 0.02 | at 0.10 | +|---|---|---|---|---| +| 100 GH/s | 360 | USD 1.80 | 7.20 | 36.00 | +| 1 TH/s | 36 | 0.18 | 0.72 | 3.60 | +| 10 TH/s | 3.6 | 0.018 | 0.072 | 0.36 | + +So at 1 TH/s and USD 0.02 a 5090-class card earns 72 US cents (about 55 p) an hour and heats for 7.9 p: a heater that pays. At 10 TH/s and USD 0.005 it earns 1.8 cents and the heat costs 5.3 p more than gas: a heater that costs 3.9 p an hour net, which is still under the resistive panel it replaces in a room without a radiator. The honest sentence for the app: "In heat mode your card is an electric heater that also earns; whether it beats your boiler depends on the network and the price, shown live." + +**Game theory.** None on the chain: a heat-mode miner is a miner with a schedule. One effect to name: seasonal hash. If heat mode becomes a large share of hash, winter hash rises and summer hash falls in the northern hemisphere; the DAA absorbs it, and the 30-day weight window means a summer departure of heat miners is a slow slide, not a departure event (the 10 percent per hour rule is not touched by a thermostat that ramps over weeks). + +**Hostile review (Monero voice).** "A thermostat in a miner is a feature every miner GUI has had since 2014 (approximate: temperature targets in miner software). Call it heat mode if it sells; it changes nothing about the chain." Correct. + +**Cost and gate.** App feature, 6 hours: a target-temperature input, the schedule, a sensor source (the OS's, or the card's own temperature as a proxy with a stated error), the live "earns X, heats Y, your boiler would cost Z" line from the tariff the user enters (phone-app 4.1 already has the tariff field). Gate: a room sensor loop on PC 1 holds a set temperature within 1 degree over four hours while the hash rate follows the duty cycle, logged. + +**Per tier.** An 8 GB card at 150 W is a 150 W heater (the small-room case); a 5090 at 326 to 575 W (the ladder page's TGP range) is a large-room heater; a rig is a space heater that should not be in a bedroom; a pool user's duty cycle shows as a share-rate pattern the pool sees; macOS: the M5 Max at low watts is a poor heater; Windows and Linux alike. + +**Verdicts.** Cryptographer: do now (no protocol content). Consensus engineer: do now, 6 hours. The miner: do now (the one feature a home miner in a cold flat asks for first; the number line must show when it loses to gas). Economist: do now, with the tariff line mandatory so nobody reads "free heat". + +--- + +## 6. Phone-verifiable everything + +**What remains after finality-in-proof and the WASM verifier (horizon rank 19).** Finality-in-proof gives 494 B of public values that say "locked at checkpoint i by x of y weight" under one proof; rank 19 gives the Groth16 or Plonk wrapper verified in a tab. What is left is the last mile: carrying that object with no network, and a "verify this block" link on the explorer. + +**Prior art.** Mina (2021, approximate): a constant-size recursive proof of the whole chain, verified on a phone, with proof-of-stake under it. zkSync's block proofs on Ethereum (2023, approximate): verified by a contract, not a phone. Helios (a16z, 2022): a light client in WASM, trust rooted in a weak-subjectivity checkpoint. No proof-of-work chain has a phone-verifiable finality object; after finality-in-proof Igneum does, and the QR is only packaging. + +**The object (model, section D).** Groth16 proof 260 B (SP1 docs) + public values 494 B + verifying-key id 32 B = 786 B. A version 40 QR at level L holds 2,953 B; a version 25 at level M about 1,000 B (approximate). So one QR carries the proof with room for a block hash and a receipt path of up to about 2 KB, and a phone with the pinned verifying key verifies it with no network: one bn254 multi-pairing, of the order of 2 to 5 ms native on a phone (approximate; Helios and the xycloo WASM demos are the order-of-magnitude anchors, 10 to 50 ms in WASM, frontier 3.4). The URL form is the same bytes base64 in a fragment, 1,048 characters, under every browser's limit. + +**What the phone learns with no network.** That some chain with this chain id, under this aggregator program, had checkpoint i locked by x of y weight, with state root R and history root H, and (with the receipt path) that transaction T is in a block at or below the lock. What it cannot learn offline: that this is the LATEST lock (staleness: the `lock_daa` field lets it show the age against its own clock, labelled "age by your clock"). + +**The wrapper's cost on a 5090.** SP1's docs give PLONK as about 1 min 30 s longer than a compressed proof and Groth16 as the recommended on-chain form at 260 B; the wrap runs on the CPU in gnark whatever the GPU (approximate, from memory of SP1's wrapper architecture). So the wrap is not per segment (8 s): one wrapper machine wraps one proof per 90 s, and the chain's "latest wrapped proof" is 38 segments behind the tip at a 300-s cadence or 8 behind at 60 s with two wrapper machines (model, table D). The measurement the design needs is the one frontier 3.4 names (R4): wrap the pinned aggregator proof on a 24 GB fleet card and the box's CPU, record seconds and RAM. Expected, approximate: 60 to 180 s and 16 to 32 GB of RAM. + +**The explorer link.** "Verify this block" on the explorer renders the QR and the URL for the newest wrapped proof whose history covers the block, plus the block's MMR path; the tab verifies it with rank 19's WASM verifier and shows the milliseconds. 4 hours once rank 19 lands. + +**Game theory.** A forged QR fails verification; a stale QR shows its age; a QR from another chain id is refused. A soundness bug in SP1 forges a lock on the phone and not on the chain (full nodes verify the BLS certificate natively, finality-in-proof 5.1), which is the stated light-client row. + +**Hostile review (Kaspa voice).** "A QR that says 'locked' with no network says 'locked as of when the QR was made'. Say the age in big letters or you will have people paying against last week's lock." Correct; the age line is in the design. + +**Cost and gate.** 8 hours (QR and URL packing 2, the phone verify call on the shared `igneum-light` engine 4, the explorer link 2) plus rank 19's 16. Gate: a phone in airplane mode scans a QR printed from the explorer and shows "locked at checkpoint i, x percent of weight, age 4 minutes by your clock, verified in N ms"; a QR with one byte changed is refused. + +**Per tier.** Holders: a proof in their pocket. Miners: their node serves the wrapped proof (section 3). Rollup customers: the same 786 B is what their bridge verifies. Node operators: one wrapper machine per network at a 300-s cadence (a box, not a card). + +**Verdicts.** Cryptographer: do now after rank 19 (the first offline-verifiable PoW finality). Consensus engineer: do now (nothing in consensus). The miner: prototype (nice, not what miners ask for). Economist: do now (the cheapest public proof of the phase-two claim; the wrapper machine is one box). + +--- + +## 7. More candidates, generated and judged + +Twelve more. The first four are this lane's own (7.1 to 7.4); the rest are the brief's list, judged. + +### 7.1 A weight-backed peer directory in the coinbase (this lane's candidate) + +**The idea.** A block producer may opt in to carry its node's reachable address (IPv6 plus port, 18 B) in its coinbase extra data, signed by the vote key the header already names. The chain becomes its own seed list: a fresh client draws its outbound peers from the last 30 days of carried addresses, weighted by the carrying keys' W2 weight. No DNS seed, no shipped seed list beyond genesis peers, no operator. + +**Prior art.** Bitcoin's DNS seeds and `addr` gossip (2011 onward, approximate); Ethereum's ENR and discv5 (2019, approximate); Kaspa's dnsseeder (approximate); the eclipse attack paper (Heilman, Kendler, Zohar, Goldberg, USENIX Security 2015) and its address-bucket fixes. No chain this lane knows writes reachable addresses into blocks under the producer's key with weight-weighted draws. New in form; the pieces (addr gossip, weighted sampling) are old. + +**Mechanism.** + +| Item | Rule | +|---|---| +| Object | `IGNA`-style section: `0x05 ‖ ip16 ‖ port2`, opt-in, at most one per block, signed by the header's vote key (the key reveal already proves possession) | +| Directory | every node keeps the last window's entries keyed by vote key hash (one address per key, newest wins) | +| Draw | a client picks outbound peers by the key's W2 weight; keys under dust are not drawn | +| Bytes | 18 B per block = 1.56 MB a day on every node (model, section E); 30 days at most 2.6 M entries, far fewer after de-duplication by key | + +**Game theory (model, table E).** An attacker with share a of the 30-day weight lists share a of the directory. With 8 outbound peers drawn by weight, the probability every peer is the attacker's is a^8: 2.6e-6 at 20 percent, 1.8e-4 at 34 percent, 4.6e-3 at 51 percent; with 16 peers 6.6e-12, 3.2e-8, 2.1e-5. Against this, a DNS seed is one operator and a shipped list is one release key. The attack that remains: listing honeypot addresses under honest-looking keys costs the attacker 30 days of mining per key, the same bound as every other weight-backed thing on this chain. Griefing: a producer lists a victim's address to draw traffic to it; bounded by one address per key per block and the signed key, so the lister is named on chain. + +**Hostile review (Kaspa voice).** "Your reachable miners are the rigs and the seeds; home miners are behind NAT and will list nothing or list a dead address. The directory is a list of rigs weighted by rigs, which is the thing you said you wanted to avoid (frontier 3.8's Kaspa attack). Also a 30-day-old address is a dead address." Answer: the client draws from the newest entries first with the weight as the tie-break, a liveness probe before use is the ordinary `version` handshake, and the rigs-weighted list is still a list of parties that mined 30 days of public blocks rather than one DNS operator. The NAT point stands and is the measurement. + +**Cost and gate.** 10 hours: the coinbase section and signature check (3), the directory and the weighted draw in the node (4), the client's use in Ember verify mode and the phone (3). Gate: a fresh node with no seed list and genesis peers only reaches 8 outbound peers from the directory on the fast-time network; an eclipse harness with a 34 percent attacker listing 34 percent of addresses eclipses the fresh node in under 0.1 percent of 1,000 starts (expected 1.8e-4 at 8 peers). + +**Per tier.** Home miner: opt-in, off by default (NAT); a rig and a seed node opt in; a pool node opts in; the phone and Ember verify mode gain a seed list with no DNS; no card, OS or vendor difference; node operators store 1.56 MB a day. + +**Verdicts.** Cryptographer: prototype (a weight-backed seed list is the right shape; measure the NAT fraction). Consensus engineer: prototype (10 hours, nothing in fork choice). The miner: watch (home miners will not opt in; rigs will; fine). Economist: prototype (removes one operator from the trust row for 1.56 MB a day). + +### 7.2 Sign-in with Igneum: 30 days of public work as a login (this lane's candidate) + +**The idea.** A vote key signs a challenge to prove its W2 weight to a third party: a rental marketplace, a forum, a faucet, an airdrop-free allowlist. The verifier reads the weight from any node or the finality-in-proof public values. Sybil cost is 30 days of mining per identity. + +**Prior art.** Hashcash (Back, 1997): proof of work as an anti-spam stamp. Sign-In with Ethereum (EIP-4361, 2021): a signed message as a login. Proof-of-humanity and Gitcoin Passport (2021 onward, approximate): social Sybil resistance. No chain has a non-transferable, work-earned weight per key to sign with; Igneum does. + +**Game theory.** A key's weight is worth its 30 days of pool income (work-stake section 5: 2,793 IGN for an 8 GB card at 100 GH/s), so lending it to a login is lending a reputation that cannot be split without halving each half. A marketplace that gates on weight gets a Sybil cost it cannot buy elsewhere. The attack: a key used as a login is a key whose secret is on a machine that talks to websites; the pool spec's one-signer rule (9.6 item 3) and the equivocation strip mean a stolen key is burned by its thief in one double vote. The login must therefore be a delegated session key signed once by the vote key, never the vote key online. + +**Hostile review (Monero voice).** "You are building an identity out of a mining key. Miners do not want identities; that is why they mine." Answer: opt-in, delegated, and the first customer is the rental escrow of frontier 3.13, which already needs the key. + +**Cost and gate.** 6 hours (the delegation message, the verifier library in `igneum-light`, an Ember button). Gate: a web page verifies a delegated signature against a node's weight for one key and refuses a key under dust. + +**Per tier.** Any key above dust (100 blocks a window; 3.86 MH/s at 100 GH/s) can sign in; an 8 GB card qualifies at every network size up to about 440 GH/s (where 17 MH/s falls under dust, arithmetic on work-stake section 5); below that, nothing. + +**Verdicts.** Cryptographer: watch (the delegation design is the whole risk). Consensus engineer: watch (not consensus). The miner: watch. Economist: prototype only with the rental escrow as the first user. + +### 7.3 Public timestamping on the proof chain (this lane's candidate) + +**The idea.** Any hash posted in an Igneum transaction is, 60 to 93 s later, inside a certified checkpoint and, after the segment proof, inside a 786 B offline-verifiable object (section 6). OpenTimestamps (Todd, 2016, approximate) does this on Bitcoin with hours of latency and a Merkle aggregator; Igneum does it with the lock latency and a proof a phone verifies. + +**Game theory.** None: a transaction with a hash. The base fee burns; the priority fee pays. The product is the receipt path in the QR. + +**Cost and gate.** 4 hours (a contract that emits the hash in a log, the receipt path in the explorer link of section 6). Gate: a timestamp verified offline on a phone from a QR. + +**Verdicts.** All four: do now once section 6 lands; it is section 6's first use. The economist: a product with a fee a user pays, which is the kind the utility lane wants. + +### 7.4 Hash-rate futures as an app (this lane's candidate, judged against ruling) + +**The idea.** Braidpool's stated purpose: a miner sells its future shares forward for cash now. On Igneum a miner could sell its next window's pool income (the work-stake bond) forward. + +**Why it dies.** A forward needs a counterparty and collateral; the collateral is a coin balance posted by the seller or buyer, which is a coin bond, which is refused by ruling for anything the protocol touches. As an app between consenting parties with their own escrow it is allowed and the chain is indifferent. Prior art: Braidpool (in development), NiceHash (2014, an operator market). Verdict: never in protocol; watch as a third-party app. 0 hours. + +### 7.5 Finality as a service for other PoW chains + +**The idea.** Another PoW chain posts its block hashes into Igneum and treats the Igneum lock as a checkpoint; its clients refuse reorgs below the last anchored, locked hash. Igneum relies on nothing; others relying on Igneum is allowed by ruling. + +**Prior art.** Komodo dPoW (2018, approximate; the academy page 404'd): notary nodes write a chain's block hash into Bitcoin every 10 minutes (approximate) and protected chains refuse reorgs below it; VeriBlock Proof-of-Proof (2019, approximate; veriblock.org: "securing 1 chain", market cap USD 9 M); Babylon (Tas, Tse, Gai, Kannan, Maddah-Ali, Yu, 2022, IEEE S&P 2023: PoS chains checkpoint to Bitcoin; stake withdrawal from weeks to under 5 hours). Igneum's difference: the anchored chain gets a 90-s lock instead of Bitcoin's hour, and an offline-verifiable proof instead of an SPV path. + +**Game theory.** For Igneum: none; an anchor is a transaction. For the anchored chain: its safety becomes Igneum's finality, which pauses whenever under two thirds of weight signs (spec 03 3.7); an anchored chain must fall back to its own PoW during a pause and say so, which Babylon's design also requires of its consumers. A hostile Igneum majority cannot forge an anchor (it would need two thirds of weight to lock a false chain) but a third of weight can pause anchoring. Market (model, section G): at Komodo's cadence (144 anchors a day) the fee is 0.73 IGN a day, under one cent at any listed price. Revenue to Igneum: nothing material; standing: a product no PoW chain offers with proof-carrying finality. + +**Hostile review (Kaspa voice).** "Who are the customers? Komodo's dPoW protected a handful of Komodo-family chains and VeriBlock secures one chain worth USD 9 M. Small PoW chains that fear 51 percent (ETC, BTG, VTC in 2018 to 2020) chose checkpoints from their own developers over paying anyone." Correct; the demand is the gate. + +**Cost and gate.** 16 hours: an anchor contract (4), a client library that reads the lock and the proof for an anchored hash (8), a reference patch for one open-source PoW node (4). Gate: one outside chain's testnet runs the patch for a week and refuses a staged deep reorg below an anchored lock. + +**Per tier.** Nothing changes for any Igneum miner or holder; an anchored chain's miners get a 90-s checkpoint they did not vote for, which their community must accept (the Komodo precedent: accepted by chains that chose it). + +**Verdicts.** Cryptographer: prototype (sound, and the first external use of the lock). Consensus engineer: watch (demand first). The miner: watch (no miner cares). Economist: watch (USD 0.004 a day per customer at the floor is standing, not income). + +### 7.6 The hourly program as a standing public hardware benchmark with a leaderboard + +Frontier 3.16 (do now, 10 hours) publishes the corpus; the leaderboard is the product on top: per card model, per vendor, per driver, the median rate and joules per hash across the hour's variants, from the fleet library and opt-in Ember submissions, with the bit-exact fingerprint per entry. Prior art: Geekbench (2007, approximate), hashrate.no and WhatToMine (2018 onward, approximate) as operator tables; none continuous on a random kernel stream. New as a continuous random-kernel benchmark. Game theory: a submitter lies about its rate; the fingerprint proves bit-exactness not speed, so self-reported rates are labelled and the fleet's measured rows are the reference tier. Cost 8 hours on top of 3.16. Gate: a public page with the eleven measured cards (prover-tiers-real-cards.md) as the reference tier and opt-in rows beneath. Verdicts: do now (all four; the miner: "a leaderboard is the first thing a mining YouTuber screenshots"). + +### 7.7 Proof of unique card: count machines, not keys + +Dead, and the reason is the design's own: nothing in consensus counts nodes, keys or cards (spec 3.1 W6, ledger F17), so a count of machines would be a Sybil surface the design removed on purpose; and a chip emulates any fingerprint it has been shown (frontier 4.3's Monero attack). What the design does count is blocks, and a card's blocks are its weight. Verdict: never. 0 hours. + +### 7.8 Shard proving as the on-ramp: a proving-only key earning pool income without a card + +Dead by the sortition rule: shard assignees are drawn by W2 weight (spec 7.2 step 2); a key with no blocks has no weight and is never drawn. What a proving-only key can do today: claim shards after the exclusive window (spec 7.2 item 4) and prove external jobs under the pool protocol's bonded key route (work-stake section 5, the prover row). That is the on-ramp and it exists. Verdict: never as a rule change; the two existing routes stand. 0 hours. + +### 7.9 Miner-signed release: 95 percent of weight signs the release hash + +Compare horizon rank 13 (reproducible-build attestations, N of M builders, 12 hours). A weight signature says "we RUN this hash", not "we BUILT it", and running is what the 95 percent class signal already measures (the object byte in the header version). So the idea is the P2 signal applied to a binary hash instead of a class byte: a header bit per release. Prior art: BIP9's version bits (2015) for rules, not binaries; no chain signals binary hashes (approximate). What it adds: a chain-readable "share of weight on release X" that Ember can show beside rank 13's "N builders reproduced X". Cost 4 hours (a release-hash field in the coinbase, tallied by the explorer, no consensus effect). Game theory: lying costs nothing and buys nothing; it is a statistic. Verdict: watch, fold into rank 13's display. Cryptographer: watch. Consensus engineer: do as a coinbase field, 4 hours. The miner: watch. Economist: watch. + +### 7.10 An energy-price oracle from miners' own signals + +**The idea.** Each producer carries its electricity price in its coinbase; the window's weighted median is the chain's energy price, free of any oracle operator. + +**Prior art.** Chainlink and the oracle networks (2017 onward, approximate); frontier 3.5's miner-voted dials (Ethereum's gas-limit vote, geth `VerifyGaslimit`); no PoW chain carries a price field (approximate). + +**Game theory.** A field nobody is paid for and nobody is punished for lying in is noise; a field that feeds a price (the job reserve of horizon rank 7, "measured proving electricity per pgas at the published settlement rate") is a field miners overstate, bounded only by the customer's bid, which rank 7 already makes the price. So the oracle is either noise or a lever on the job price that the bid neutralises. The honest use is statistical: the miner community lead's hardware-economics model wants real tariffs, and Ember's opt-in telemetry (the tariff field of phone-app 4.1) gives them off-chain with no consensus bytes. + +**Verdict.** Never in consensus; an opt-in Ember statistic. 2 hours for the telemetry line. All four personas: never in protocol. + +### 7.11 A first-block bonus per new key, Sybil-bounded by dust + +**The idea.** A key's first block above dust pays a bonus B, to welcome newcomers; the signing bonus of vote-or-burn exists, so this would be the second bonus. + +**Game theory (model, section F).** Dust is 100 blocks a window. A 10 percent miner makes 259,200 blocks a window and can keep 2,592 keys above dust, each collecting B once: at B = 100 IGN that is 259,200 IGN a window, 1 percent of its subsidy, for free (weight and sortition are per block, so the split costs it nothing but its own vote's convenience; the pool spec's one-key rule is a client default, not a consensus rule). A bonus large enough to matter to a newcomer (10 blocks, 1,000 IGN) is a 10 percent raise for every miner willing to run 2,592 keys. The dust bound makes the Sybil expensive in KEYS and free in HASH, and keys are free. Verdict: never. 0 hours. The miner: "an instamine with extra steps". + +### 7.12 A cross-vendor parity bounty + +Dead by ruling (no device bounty): a payment conditioned on a card model is a device bounty whatever it is called. What the design does instead is measure (the eleven rented cards, the ladder's per-rung 5 percent rule) and publish. Verdict: never. 0 hours. + +### 7.13 In-protocol insurance against reorgs for exchanges + +**The idea.** An exchange that credited a deposit later reversed by a reorg is made whole from a protocol pool. + +**Prior art.** None shipped in any protocol (this lane found no primary page; approximate). Off-chain: exchange confirmation policies; Nexus Mutual-style cover for contracts (2019, approximate), not for reorgs. + +**Why it dies.** Who pays? A protocol pool is either emission (a transfer from miners to exchanges, which the miner persona rejects on the Decred and Ethereum precedents in vote-or-burn section 2) or the proving pool (a transfer from provers, who did nothing wrong). The design's own answer is stronger than insurance: a certified checkpoint cannot be reversed (51-percent.md section 2), the four-state rule credits on "finalised" (ledger P17), and the exchange guidance says confirm at the lock or at 12 hours during a pause (horizon rank 16). Insurance is only wanted where finality is paused, and during a pause the only reorg-capable party is a hash majority with no slashable bond, by ruling. Verdict: never; the guidance is the product. 0 hours. + +### 7.14 Pause insurance from the proving pool + +Dead: it pays the wrong people or nobody. During a pause the silent third earns its subsidy (51-percent.md: "free to hold while silent"); redirecting pool income to the signing keys is the signing bonus's job (8 of 80 points) and to holders is impossible (no mechanism pays holders). Vote-or-burn priced the pause at 3,103 to 6,206 IGN an hour at 34 percent silent and found a deposit worth attacking covers either; LEAVE and weight-gated fork choice close the line. Verdict: never. 0 hours. + +### 7.15 Proof of latency: rewarding low-latency relays + +The arXiv search for "proof of latency" this morning returned five unrelated papers and none on relay rewards; FIBRE (2016) relays unpaid. Timing is unverifiable in consensus (section 1.4) and the DAG already pays for latency in blue blocks (under 2 percent red at 1 block/s, run B). A relay reward would need a clock and a Sybil-proof receipt, and it has neither. Verdict: never. 0 hours. + +--- + +## 8. Verdict table + +Ranked. At most three "do now" and three "prototype"; the rest "watch" or "never" with the line that killed them. Persona order: cryptographer / consensus engineer / the miner / economist. + +| Rank | Candidate | Prior art (name, year) | New? | Survives its game (bound) | Hostile review verdict | Hours | First gate | Four verdicts | Recommendation | +|---|---|---|---|---|---|---|---|---|---| +| 1 | 6 Phone-verifiable proof in a QR or URL, offline, plus the explorer link | Mina 2021 (approx.), Helios 2022, zkSync block proofs 2023 (approx.) | the offline PoW finality object is new | yes (a forged QR fails; staleness shown by `lock_daa`) | "show the age in big letters": accepted | 8 (+16 rank 19) | phone in airplane mode verifies a printed QR, refuses a one-byte change | do now / do now / prototype / do now | **do now** | +| 2 | 5 Heat mode in Ember | Heatbit 2022, 21energy (Austria), Qarnot 2010 (approx.) | new only as a chain client feature | yes (a schedule is a schedule; seasonal hash absorbed by the DAA and the 30-day window) | "every miner GUI has a thermostat": accepted | 6 | set temperature held within 1 degree for 4 h on PC 1 while hash follows the duty cycle | do now x4 | **do now** (UK break-even 5.3 p an hour against gas or a heat pump; free against a resistive panel) | +| 3 | 3 Miners' nodes serve the 786 B proof to phones (Ember line, unpaid) | Portal Network 2021 to 2026 (unrewarded), Helios 2022, Mina snarkers 2021 (approx.) | no | yes (a lie fails verification; eclipse bounded by N of M pins) | "not a service you price": accepted | 4 (+20 frontier 3.8) | a phone on cellular shows "locked, voter set verified" from a miner's node | do now x4 | **do now** | +| 4 | 7.1 Weight-backed peer directory in the coinbase | DNS seeds 2011, discv5 2019, Heilman 2015 (approx.) | new in form | yes: eclipse at 34 percent of weight 1.8e-4 with 8 peers, 3.2e-8 with 16 (model E) | "a list of rigs weighted by rigs; NAT": partly accepted, the NAT fraction is the measurement | 10 | fresh node with genesis peers only reaches 8 outbound from the directory; 34 percent attacker eclipses under 0.1 percent of 1,000 starts | prototype / prototype / watch / prototype | **prototype** | +| 5 | 4 Verifiable payout contract for existing pools (SmartPool shape) | SmartPool 2017; Ocean 2023 (approx.) | no | yes (a dropped share is provable from the member's log) | "P2Pool sidechain if you want no operator": accepted as the alternative | 16 | a member proves a dropped share on the fast-time network and is paid; 32 B per round on chain | prototype x4 | **prototype** | +| 6 | 7.5 Finality as a service for other PoW chains | Komodo dPoW 2018 (approx.), VeriBlock PoP 2019 (approx.), Babylon 2022 | the 90-s proof-carrying anchor is new | yes for Igneum (an anchor is a transaction); the anchored chain inherits Igneum's pauses | "who are the customers": demand is the gate | 16 | one outside testnet refuses a staged deep reorg below an anchored lock for a week | prototype / watch / watch / watch | **prototype** (demand-gated) | +| 7 | 7.6 Hardware leaderboard on the program corpus | Geekbench 2007, WhatToMine 2018 (approx.); frontier 3.16 | new as a continuous random-kernel benchmark | yes (self-reported rates labelled; the fleet's rows are the reference tier) | none | 8 (+10) | public page with the eleven measured cards as the reference tier | do now x4 | watch (frontier 3.16 is already "do now"; this is its page; the cap of three "do now" is spent) | +| 8 | 7.3 Public timestamping on the proof chain | OpenTimestamps 2016 (approx.) | the offline-verifiable receipt is new | yes | none | 4 | a timestamp verified offline from a QR | do now x4 | watch until rank 1 lands, then 4 hours | +| 9 | 7.2 Sign-in with Igneum (delegated weight as a login) | Hashcash 1997, EIP-4361 2021 | new (work-earned, non-transferable weight) | yes if delegated (a vote key online is a key a thief burns) | "miners do not want identities": opt-in | 6 | a page verifies a delegated signature against a node's weight; dust refused | watch / watch / watch / prototype | watch (first user: the rental escrow) | +| 10 | 7.9 Miner-signed release hash in the coinbase | BIP9 2015; horizon rank 13 | no | yes (a statistic) | fold into rank 13 | 4 | the explorer shows share of weight per release hash | watch / do / watch / watch | watch | +| 11 | 1.3 and 1.5 Proof of serving or state availability as a reward slice | Filecoin PoSt 2020, Arweave SPoRA 2021 (approx.), PeerDAS 2024 | the miner-key reward is new | no: outsourced in 108 ms; self-answered under class v5 | "pays for what the lottery compels" | 0 (4 for the unpaid RPC) | | never x4 | never: the unpaid RPC (new-pow rank 6) is all that survives | +| 12 | 2 x of 80 points conditional on serving | as 11 | no | no (same bounds; a second liveness bonus on the signing bonus's event) | "merge or drop" | 0 | | never x4 | never | +| 13 | 4 In-protocol pool (shares in blocks) | FruitChains 2016, P2Pool 2011, Monero P2Pool 2021, Braidpool (in development) | no | yes on incentives (withholding self-defeating), no on cost: 14.6 to 146 GB a day and 5 to 50 cores per node at 10,000 to 100,000 miners on a 10-s share | "we built a sidechain for this reason" | 0 | | never x4 | never in protocol | +| 14 | 1.2 Proof of following | Verthash 2021 (approx.), class v5 2026 | in form only | yes, by doing nothing new | "the root already commits to the chain" | 0 | | never x4 | never: the epoch seed plus class v5 is proof of following | +| 15 | 1.4 Proof of propagation receipts | FIBRE 2016 (unpaid) | no | no (time unverifiable; receipts Sybil-free; 94 to 376 MB a day) | "GHOSTDAG is a proof of propagation" | 0 | | never x4 | never | +| 16 | 7.10 Energy-price oracle from miners | Chainlink 2017, frontier 3.5 | no | no (noise, or a lever the bid neutralises) | | 2 (Ember telemetry) | | never x4 (in protocol) | never; opt-in statistic | +| 17 | 7.11 First-block bonus per key | the signing bonus (vote-or-burn) | no | no: a 10 percent miner collects it 2,592 times a window (model F) | "an instamine with extra steps" | 0 | | never x4 | never | +| 18 | 7.13 Reorg insurance for exchanges | none shipped (approx.) | yes | no (no slashable payer by ruling; the lock is the product) | | 0 | | never x4 | never | +| 19 | 7.14 Pause insurance from the proving pool | vote-or-burn's pricing | no | no (pays the wrong people) | | 0 | | never x4 | never | +| 20 | 7.15 Proof of latency | none found (arXiv, 7 Oct 2026) | yes | no (no consensus clock) | | 0 | | never x4 | never | +| 21 | 7.7 Proof of unique card | frontier 4.3 | no | no (nothing counts cards by design; a chip emulates a fingerprint) | | 0 | | never x4 | never | +| 22 | 7.8 Proving-only key earning pool income | spec 7.2 | no | dead by the sortition rule; open claims and the pool route exist | | 0 | | never x4 | never | +| 23 | 7.12 Cross-vendor parity bounty | | | dead by ruling (device bounty) | | 0 | | never x4 | never | +| 24 | 7.4 Hash-rate futures | Braidpool, NiceHash 2014 (approx.) | no | needs a coin bond: dead in protocol | | 0 | | never (protocol) x4 | never in protocol; a third-party app is the chain's indifference | + +Three "do now": ranks 1, 2, 3 (34 hours in all, plus the 36 of rank 19 and frontier 3.8 they sit on). Three "prototype": ranks 4, 5, 6 (42 hours). Everything the brief hoped was a protocol invention in sections 1, 2 and 4 is dead on a number this lane ran: 108 ms (the outsourcing fetch), 0.61 to 76.5 GB a day (challenge answers), 14.6 to 146 GB a day and 5 to 50 cores (in-protocol shares). + +--- + +## 9. The honest answer + +Igneum's revolution is the combination already built, not any one new item. The pieces that exist in code or on a branch today and that no shipped proof-of-work chain has together: a random-program GPU hash whose dataset is the chain's own state (class v5, hash rate unchanged at 63.08 MH/s, verifier +0.11 to 0.21 ms), miner-only finality by 30 days of blue blocks with no stake (a lock 63 to 93 s after a checkpoint; 51 percent never reaches two thirds while honest miners mine), that finality carried inside the execution proof as 494 bytes a phone verifies (finality-in-proof), a bond for proving jobs made of 30 days of public work and no coin (work-stake: 2,793 IGN at risk for an 8 GB card at 100 GH/s against a 0.0015 IGN coin bond), a tail that keeps a 24-hour attack at about twelve days of emission in every year, and a pool protocol in which the operator holds no key and no vote. + +This lane tested fourteen candidates for the next thing and found two small ones worth building now (the offline proof in a QR, 8 hours, and heat mode, 6 hours), one Ember line (miners' nodes serve the proof, 4 hours), and three prototypes (a weight-backed peer directory that bounds an eclipse at 1.8e-4 for a 34 percent attacker, a verifiable payout contract for pools, and finality as a service for other chains). Every candidate that would have changed consensus died on a measured number: proof of serving on a 108 ms fetch, in-protocol shares on 14.6 GB a day, propagation receipts on the absence of a clock. The next genuinely new thing is the first offline-verifiable proof-of-work finality object in a user's pocket, and it is packaging on what is already built. + +--- + +## 10. Three headline findings for the coordinator + +1. Every "hashing useful to the chain" variant beyond class v5 is dead on one number: a key with no state answers an availability challenge in about 108 ms over a 100 ms link, so any deadline over one block makes the proof "someone served", and the reward slice it would gate (2 to 8 of the 80 points, 17 to 69,120 IGN a day by key size) pays for what the lottery already compels. +2. An in-protocol pool is FruitChains (2016) and it costs every node 14.6 GB a day and 5 cores at 10,000 miners on a 10-s share (146 GB and 50 cores at 100,000), so the finished form is the shipped pool v0 plus a verifiable payout contract (SmartPool 2017 shape, 16 hours, 32 B per round on chain). +3. The three things worth doing now total 18 hours and change no consensus rule: an offline-verifiable 786 B finality object in a QR (260 B Groth16 + 494 B public values + 32 B key id, under a version-40 QR's 2,953 B), Ember heat mode (a 300 W card breaks even against a UK gas boiler or COP-3 heat pump at 5.3 p an hour earned, and is free against a resistive heater), and every miner's node serving that proof to phones. + +--- + +## Sources (accessed 7 October 2026 unless stated) + +Project files: `docs/analysis/horizon-2026-10.md`; `docs/analysis/horizon/frontier.md`; `docs/analysis/horizon/new-pow.md`; `docs/analysis/class-v5-stored-state.md` (branch class-v5); `docs/analysis/finality-in-proof.md` (branch fin-proof); `docs/analysis/work-stake.md` (branch work-stake); `docs/analysis/tail-emission.md`; `docs/analysis/vote-or-burn.md`; `docs/design/latency-ladder.md`; `docs/analysis/51-percent.md`; `docs/plans/pool.md`; `docs/spec/09-pool-protocol.md`; `docs/spec/10-light-client.md`; `docs/design/phone-app.md`; `docs/bench-log.md` (lines 170, 230, 685, 873 to 877, 1934, 2582 to 2635); `.claude/agents/*.md`. Model: `/private/tmp/claude-501/-Users-joshm/cd75457f-4858-4f86-9634-7481ee056b7b/scratchpad/mission-invent/invent_model.py` and `out.md`. + +Primary pages fetched (WebFetch; the session's WebSearch budget was spent before this lane started, so every check is a direct fetch of a known primary page): + +- FruitChains: A Fair Blockchain, Pass and Shi, 2016: https://eprint.iacr.org/2016/916 +- SmartPool: Practical Decentralized Pooled Mining, Luu, Velner, Teutsch, Saxena, 2017: https://eprint.iacr.org/2017/019 +- Monero P2Pool (SChernykh): https://github.com/SChernykh/p2pool +- Braidpool: https://github.com/braidpool/braidpool +- EIP-7594 PeerDAS (2024): https://eips.ethereum.org/EIPS/eip-7594 +- Portal Network: https://ethportal.net/ +- FIBRE: https://bitcoinfibre.org/ +- Helios: https://github.com/a16z/helios +- Heatbit: https://www.heatbit.com/ +- 21energy: https://21energy.com/ +- Filecoin storage mining and WindowPoSt: https://spec.filecoin.io/systems/filecoin_mining/storage_mining/ +- SP1 proof types (Groth16 about 260 B, PLONK about 1 min 30 s longer than compressed): https://docs.succinct.xyz/docs/sp1/generating-proofs/proof-types +- Ofgem energy price cap unit rates, 1 October to 31 December 2026 (26.32 p electricity, 7.97 p gas, direct debit, national average): https://www.ofgem.gov.uk/your-energy-supply/your-energy-bill/energy-price-cap-unit-rates-and-standing-charges +- EIA, average residential electricity price, July 2026 (18.31 cents per kWh): https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a +- Eurostat, electricity price statistics, H2 2025 (EUR 0.2896 per kWh household): https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Electricity_price_statistics +- Babylon: Bitcoin-Enhanced Proof-of-Stake Security, Tas, Tse, Gai, Kannan, Maddah-Ali, Yu, 2022: https://arxiv.org/abs/2207.08392 +- VeriBlock Proof-of-Proof: https://www.veriblock.org/ +- arXiv search "proof of latency" (no relevant paper): https://arxiv.org/search/?query=%22proof+of+latency%22&searchtype=all + +Pages that returned 404 this morning, so the item is labelled approximate in the text: Arweave yellow paper and mining guide (SPoRA), vertcoin.org Verthash page, Komodo dPoW academy page, Qarnot's Wikipedia page, Ofgem's cap-levels page (the unit-rates page above answered instead). Figures from memory are labelled approximate where they appear: Heatbit's 2022 launch, Qarnot's 2010 founding and 2013 QRad, Komodo's 2018 dPoW and its 10-minute cadence, VeriBlock's 2019 launch, Verthash's January 2021 activation, Mina's 2021 phone verification, EU and US gas prices, phone-side pairing times, SP1's Groth16 wrap time and RAM, Geekbench and WhatToMine years, the Heilman 2015 eclipse paper's venue. diff --git a/docs/analysis/mission/mission.md b/docs/analysis/mission/mission.md new file mode 100644 index 00000000..b25f0329 --- /dev/null +++ b/docs/analysis/mission/mission.md @@ -0,0 +1,186 @@ +# The Igneum Mission + +Written 7 October 2026, morning UK, by the mission coordinator (branch `mission`, worktree `igneum-wt-mission`) on the project lead's order of the same morning, verbatim: "i dont want to get stuck in a loop here where we keep finding and adding features and security so im going to give you one last mission, deep deep dive into the past and look far into the future, what has been done, what hasnt been done, what has been started but not finished, what can we invent and what can we reinvent to honestly make the perfect gpu network that will be noticed as the revolution that everyone is waiting for." + +This is the last research round. Its output is the closed list in section 2. After it the project stops researching and ships. Five lanes ran in parallel and each has its own file with sources and a verdict table: `past.md` (lane 1), `unfinished.md` (lane 2), `future.md` (lane 3), `invent.md` (lane 4), `reinvent.md` (lane 5). Every number below names its lane; the lane file names the source or the model. Hours are agent hours. Nothing on the live devnet was touched and no build or hash measurement was run for this document. + +## 1. One page for the project lead + +**What has been done.** Of 31 GPU-mined chains since 2011, 8 lost the GPU lane to a chip, 7 closed it by choice, 10 died on price or a rental attack; the 6 still GPU-only pay USD 0.22 to 0.71 a day per RTX 3080 (lane 1). In 20 miner posts the wants were hardware that keeps its value, income without a cliff, a fair supply. Igneum answers the supply in full (no premine, no fund, no fee to any team), the hardware with a measured 2.1x chip bound and the N ladder, the cliff with a monthly glide and a 1 percent tail. Finality by 30 days of blocks, proving as the reward, the leave item and the signing bonus are built or approved for the testnet genesis. + +**What has not been done.** Nobody on those forums asked for finality, a DAG or proofs; they asked for a card that keeps its value, a bill that gets paid and a coin that sells. The front page leads with the hash, the earnings page shows £0.00, a fresh install opens with two operating-system warnings and ends its first hour without one number the miner came for, and no proving customer has signed, so the coin has Ergo's 2023 exposure: a thin market. These gaps are hours, not protocol. + +**Started and not finished.** Three designs sit on branches: class v5 (the dataset is the chain's own state), finality inside the segment proof, work-stake (a bond of 30 days of work, no coin). Across the industry (lane 2), every useful-work scheme that passed cheap-verify did so by making the work useless, no pool without an operator exists on any chain but Monero, and every proof-of-work finality that held was a second validator set bought with coins. Lane 4 tested whether anything new in consensus beats these; each died on a number: proof of serving on a 108 ms fetch, in-protocol pool shares on 14.6 GB a day per node at 10,000 miners, propagation receipts on the absence of a clock, proof of following because the epoch seed plus class v5 already is one. + +**What we invent.** One thing, and it is packaging on what is built: the first offline-verifiable proof-of-work finality object: 786 bytes in a QR a phone verifies in airplane mode, served by every miner's node. No PoW chain has put finality in a user's pocket. Beside it, two genesis bytes the future demands (lane 3): a signature-scheme byte with a key-succession slot, because a post-quantum vote at 8,192 voters costs 57 GB a day unaggregated and the flip must be signalled before a machine exists; and a cache-size rung on the ladder, because a 256 MB consumer cache is a 2 to 3x shortcut. + +**What we reinvent.** The miner's first month. The 30-day vote window is a level system no chain has, and it is free: first block, 100 blocks for a vote, a signature in a checkpoint, 30 of 30 days, rank by weight, a signing streak. Every rung is a chain fact from one RPC; a renter cannot top it inside 30 days; no fund pays for it. Lane 5 priced the first month at about 35 hours: the Poisson count-up before the first block (an 8 GB card at 100 GH/s waits 1.6 hours expected), the block card, earnings in IGN first, the weight leaderboard, the hardware census. In a 105-post Reddit sample the miner's own posts rise highest ("my card paid for itself" at 777 times the room median against 66 for the network's milestone), so every shareable surface carries the miner's card, rank and days, never the project's number. + +**The honest answer.** Igneum's revolution is the combination already built plus two new things: the finality object in the pocket, and the ladder shown everywhere. No shipped chain has the combination: a random-program GPU hash whose dataset is the chain, miner-only finality with no stake that 51 percent never reaches, that finality inside the execution proof, a work bond with no coin, a tail that holds a 24-hour attack at twelve days of emission in every year. Twelve items, about 290 agent hours, no new consensus rule beyond the three cut branches. + +### Decisions owed from the project lead + +The cryptanalysis entity and prize; the signing certificates (lane 5); the signed proving customer as a mainnet gate (lane 1); the H100 and A100 hash measurement on rented pods (lane 3). + +## 2. The closed list + +Twelve items, in build order. "In flight" names the lane or branch that holds it. Hours are the remaining agent hours; a gate is what must be true before the item is called done. Nothing is added to this list without removing something. + +| # | Item | State | Hours | Gate | +|---|---|---|---|---| +| 1 | The testnet genesis re-cut as approved | in flight (ship lane) | 0 new | the go checklist | +| 2 | Finality in the pocket: finality in the proof, the 786 B object, every node serves it, the browser verifier | in flight (fin-proof) plus new | 68 | a phone in airplane mode verifies a printed QR and refuses a one-byte change | +| 3 | Class v5, the dataset is the chain, and nothing wider | in flight (class-v5) | 16 | the fast-time harness across a day boundary; Devnet 2 across a real day | +| 4 | Weight-gated deep fork choice before mainnet | in flight (horizon rank 4) | 16 | a 51 percent fresh-key fork from 15 min back refused by every honest node | +| 5 | Work-stake: the job bond made of 30 days of work | in flight (work-stake) | 24 | 1,000 posted jobs, every injected miss forfeits, zero honest forfeits | +| 6 | The ladder shown everywhere: the miner's first month | new (lane 5) | 35 | a Devnet 2 key walks every rung on screen; first share within 10 minutes in 9 of 10 fresh Windows installs | +| 7 | Heat mode, the region and price prompt, the cost-against-rent line | new (lanes 3, 4) | 10 | a set temperature held within 1 degree for 4 h on PC 1 while hash follows the duty cycle | +| 8 | Genesis forward-compatibility: the scheme byte, key succession, the cache rung | new (lane 3) | 10 | the digest test; a vote item with scheme 1 refused by every node until the signal | +| 9 | A second proof system on the active list and the one-third stop switch | new (frontier I4, lane 3) | 24 | 1,000 segments agree across both systems; one injected bad proof disagrees and pays nothing | +| 10 | The launch pack: gates and text, no protocol | new (lanes 1, 3, 5) | 15 | every gate line in testnet-go.md with its check | +| 11 | The pool finished: pool-0 with member keys at 1 percent, TLS, the share sidechain with no operator | new (lanes 2, 4, 5) | 60 | 100 members on the fast-time network paid by the coinbase rule from a share chain with no operator key; the first on a DAG chain | +| 12 | The weight-backed peer directory | new (lane 4, prototype) | 10 | a 34 percent attacker eclipses under 0.1 percent of 1,000 fresh starts | + +### 2.1 The testnet genesis re-cut as approved (in flight, ship lane) + +What it is: one cut with 18 decimals, `EmissionSchedule::TESTNET_1` (100 IGN a block, a monthly glide with a two-year half-life, a 90-day ramp from 10 percent, a 1 percent tail from year 11.4), and the switches on from genesis: proof verification in consensus, the leave item, the signing bonus at 1,000 bps, finality v3, the latency ladder at rung 0. the project lead approved it on 7 October 2026, 09:3x UK (ledger-decisions.md). +Why it is right: lane 1's verdict rows 4 and 5 (the cliff and the premine) are answered by it in full; lane 3's tail row holds to year 200. +Evidence: tail-emission.md one page; vote-or-burn.md section 5; ledger-decisions.md 7 October. +Cost: 0 new hours; the ship lane's own plan. +Gate: the go checklist (`docs/plans/testnet-go.md`); nothing mines until the word. +Order: first; every later item lands on this genesis. + +### 2.2 Finality in the pocket (in flight on `fin-proof`, plus three new parts) + +What it is: the weight table carried inside the recursive segment proof (W2 updated one mergeset per segment, the BLS certificate verified in the guest, 494 B of public values), then three parts this mission adds: a Groth16-wrapped proof as a 786 B object (260 B proof, 494 B public values, 32 B key id) in a QR or URL that a phone verifies offline; every miner's node serving the latest object by default (an Ember line, unpaid); and the WebAssembly verifier in the tab (horizon rank 19). +Why it is new: no proof-of-work chain has an offline-verifiable finality object; the closest shipped forms are Mina's recursive state proof (2021) and Helios's committee light client (2022), both online and neither over proof of work. Lane 4 section 6 and 3, persona verdicts do now, do now, prototype, do now. +Evidence: finality-in-proof.md sections 1 to 5 (level 1 of the blue-set check designed, level 0 in the prototype); the certificate half verifies in 58 to 68 ms warm in a browser (bench-log round 6); SP1 light verifier 0.032 s on a Mac core; a version-40 QR holds 2,953 B. +Cost: 40 for the fin-proof remainder (level 1 of 5.2, the cycle counts of section 6.1 on the box, the 5090 prover time on a pod), 8 for the QR object, 4 for the Ember line, 16 for the WASM verifier. 68. +Gate: a phone in airplane mode verifies a printed QR and refuses a one-byte change; "locked, voter set verified" on cellular from a miner's node; a block proof verifies in the tab under 500 ms on a laptop. +Order: second; it is the one invention and it needs the genesis of item 1 for the pinned aggregator id. + +### 2.3 Class v5, the dataset is the chain, and nothing wider (in flight on `class-v5`) + +What it is: each day's dataset built from the execution state at a reference block an hour before the day; a card without the state builds every item wrong. The branch widened it to a per-window refresh (section 2a of its page). This mission's ruling: no further widening. Lane 4 tested proof of following, serving, propagation and state availability as additions and found each dead on a number: a key with no state answers an availability challenge in about 108 ms over a 100 ms link, so any deadline over one block proves only that someone served; propagation receipts need a clock the DAG does not have; the epoch seed plus the state root already commit to the chain's recent blocks, so proof of following is class v5 by another name. +Why it is right: hash rate and watts unchanged within noise (63.083 against 63.088 MH/s, 205 to 208 W on a 4090), build +1.4 ms, verifier +0.11 to 0.21 ms per unit; it removes the f = 0 recompute chip as a category and the stateless pool miner. +Evidence: class-v5-stored-state.md; new-pow.md 5.2 and 6; invent.md sections 1 and 8 rows 11 to 15. +Cost: 16 (the 4090 rows owed in section 7, the exec snapshot wire version 2, the GPU hosts' leaf buffer, the spec text). +Gate: the fast-time harness crosses a day boundary with the roots agreeing on every node and the stateless node's miner at 0 accepted blocks; Devnet 2 across a real day boundary; then the 95 percent signal with a floor. +Order: third; it rides the class-signal machinery item 1 ships. + +### 2.4 Weight-gated deep fork choice before mainnet (in flight, horizon rank 4) + +What it is: a tip whose fork point is older than D (10 min of past-median time) is a fork-choice candidate only if the keys that built it hold at least a third of the weight table at the fork point. +Why it is right: lane 1's verdict row 6: rented hash reorganised Bitcoin Gold, Vertcoin and Musicoin for USD 70 k to 18 M; Igneum's finality bounds this after day 20 and not before, and the first 20 days are when a new chain is watched. The 51 percent paper prices a 12-hour double spend during a pause at USD 146 at 1 GH/s today. +Evidence: 51-percent.md section 5 rank 2; horizon rank 4; past.md section 4 row 6. +Cost: 10 to 16. +Gate: fast-time: a 51 percent fresh-key fork from 15 min back is refused by every honest node; a one-third-weight fork is accepted; partition heal unchanged. +Order: fourth; before the public testnet opens, because the testnet is the first chain outsiders can rent against. + +### 2.5 Work-stake (in flight on `work-stake`) + +What it is: a vote key may claim an external proving job only if its next window of pool income covers the job's value; a miss, refusal or forgery forfeits that income for one window, the buyer's fee refunded first, the rest to the pool. No balance moves; no coin is posted. The spec sentence lands first: "no coin stake; the only thing at stake is 30 days of public work." +Why it is right: a bond nobody can buy (2,793 IGN at risk for an 8 GB card at 100 GH/s against a 0.0015 IGN coin bond); every attack in its section 6 fails on the window arithmetic. +Evidence: work-stake.md sections 3 to 7; frontier 3.2 and 4.1. +Cost: 24 (orders carried in blocks, the term unwound on reorg, the finality report wired to `judge_at`, the snapshot field, the deadline floor). +Gate: Devnet 2: 1,000 posted jobs with 10 percent injected misses, every injected fault forfeits, zero honest keys forfeit; a 60 s partition across 100 deadlines forfeits nothing. +Order: fifth; it needs the job market of spec 5.4, which the first customer (item 10) needs. + +### 2.6 The ladder shown everywhere: the miner's first month (new, lane 5) + +What it is: the 30-day vote window as the status ladder on every surface, and the first month's moments built around it. The rungs: first block; 100 blocks and "your key has a vote"; "your signature is in checkpoint K"; 30 of 30 days, full weight; rank by weight; the signing streak; "your card proved shard N of block M". The parts: the Poisson count-up before the first block ("a card like yours finds a block about every 1.6 hours on today's network; chance so far 31 percent"); the block card with a locally drawn PNG and the explorer link; Earnings in IGN first (6,912 IGN a day for a 100 MH/s card at 100 GH/s at the full rate) with a typed price never fetched; the weight leaderboard on `/live` (weight, never hashrate, so a renter sits at the bottom for 30 days); the public address profile behind an opt-in; the hardware census on `/miners` from the hourly program's per-card timings (frontier 4.3); #first-blocks and the Voter and Window roles granted from `getFinalityWeights`. +Why it is the right reinvention: lane 5's archive sample shows the joy posts are the first block, the first payout and the rig photo In a 105-post sample the miner's own posts rise highest: "my card paid for itself" at 777 times the room median against 66 for the network's milestone.; Helium, Chia, Ethereum 2017 and Kaspa 2022 each had a hook, a daily ritual and a status surface, and each status surface was a company number or a hashrate a renter could top. Igneum's is a consensus fact. Nobody has it. +Evidence: reinvent.md sections 1, 2, 3.2 to 3.7, 7; the solo-block expectations per tier at 100 GH/s and 1 TH/s (an 8 GB card: 1.6 h and 16 h; it never reaches the vote line at 1 TH/s, which is why the pool is item 11; the 100-block dust line means an 8 GB card never votes past about 500 GH/s, a question for the finality lane and a watch item, not a list item). +Cost: 35 (Poisson line 2, block card 4.5, earnings 6.5, ladder 6, leaderboard 3, profile 3, census 4, Discord 5, the first-hour timeline on `/miner` 2). +Gate: a Devnet 2 key walks every rung on screen in a view test; every number on the tab names its RPC field on hover; "first share within 10 minutes of download in 9 of 10 fresh Windows installs" published on `/evidence`. +Order: sixth; it is the first thing the first outside miner sees. + +### 2.7 Heat mode, the region and price prompt, the cost-against-rent line (new, lanes 3 and 4) + +What it is: Ember holds a room temperature or a schedule and the hash follows the duty cycle; a per-region electricity-price prompt with a banned-region line ("mining may be restricted where you are; you are responsible for checking"); the Earnings tab's cost line against the measured rental rate so a miner sees when rented hash undercuts their card. +Why it is right: a 300 W card as a heater breaks even against a UK gas boiler or a COP-3 heat pump at 5.3 p an hour earned and is free against a resistive panel (lane 4 section 5); the heating season credits about a third of a UK or EU miner's bill (lane 3 section 4); lane 3's 2031 row says retail-power tiers leave first when idle datacentre hash sets the rent, and the heat mode keeps winter home miners on. Prior art is Heatbit (2022), 21energy and Qarnot; new only as a chain client's feature, which is the point. +Evidence: invent.md section 5 and rank 2; future.md sections 3, 4 and 10. +Cost: 6 heat mode, 2 region prompt, 2 the rent line. 10. +Gate: a set temperature held within 1 degree for 4 h on PC 1 while hash follows the duty cycle; the prompt shows the right banned list for a Russian region; the rent line reads the bench-log rate. +Order: seventh; app only, no digest, ships in any cut. + +### 2.8 Genesis forward-compatibility: the scheme byte, key succession, the cache rung (new, lane 3) + +What it is: three genesis fields. A `sig_scheme` byte in the vote item and the key reveal (0 = BLS12-381 today), so a post-quantum scheme flips by the 95 percent signal and not by a fork. The key-succession item (W5, unimplemented on the node) so a key can hand its weight and its forfeit term to a successor once, which is the migration path. A cache-size rung on the signal ladder beside N, because a consumer last-level cache at the cache size (256 MiB) gives that card's owners a 2 to 3x shortcut (chip-model-v3; consumer LLC is 96 to 128 MB today, datacentre 256 MB). The class-group VDF's quantum fallback is flagged, not sized. +Why it is right: naive ML-DSA-44 votes at 8,192 voters cost 19.4 MB a checkpoint and 57 GB a day; with 250x SNARK aggregation about 223 MB a day; a cryptographically relevant quantum computer is "quite possible (28 to 49 percent)" within ten years (Global Risk Institute 2025) and NIST deprecates ECDSA and EdDSA after 2030. The flip is signalled the year of deprecation, not the year a machine appears; the byte costs nothing now and a fork later. +Evidence: future.md section 7 and 10; finality-in-proof.md 7 (W5 absent). +Cost: 10 (the byte and the digest test 4, the W5 item 6, the rung 1 inside the ladder code, the spec text). +Gate: the digest test; a vote item with scheme 1 refused by every node until the signal; a succession carried once and refused twice in the fast-time harness. +Order: eighth; genesis fields must land before item 1's final cut, so this is scheduled with it and listed here for its own gate. + +### 2.9 A second proof system on the active list and the one-third stop switch (new, frontier I4 and lane 3) + +What it is: a second zkVM behind the `ProofSystem` trait (RISC Zero or OpenVM) proving the same segments on one fleet box as a shadow; a disagreement between the two on any segment is a public alert and the pool stops paying on proofs until 1/3 of weight signals which system to trust. Full nodes keep the native-execution veto whatever happens. +Why it is right: three soundness-class events across SP1 and RISC Zero in 18 months (lane 3 section 5); the veto protects full nodes and nothing protects a light client or the proving pool; lane 3's death row 4 is this. +Evidence: future.md sections 5 and 9; frontier I4; ledger P7 and D6. +Cost: 24. +Gate: 1,000 segments agree across both systems; one injected bad proof disagrees, pays nothing and raises the alert. +Order: ninth; before any phone trusts item 2's object. + +### 2.10 The launch pack: gates and text, no protocol (new, lanes 1, 3 and 5) + +What it is: lines added to `docs/plans/testnet-go.md` and the litepaper, each with its check. Gates: a signed proving customer before mainnet, with the weight of the Devnet 2 gate; per-tier income published at three prices (USD 0.005, 0.02, 0.10) before the testnet, per the consequences rule; the launch-week hash-origin report (key counts, pool shares, fleet shares) from the observer, daily for the first 90 days; the first 100 keys, the first 1,000 independent keys (the X5 definition), the first pool not run by the project, the first outside-reproduced benchmark, the first block from a card the project does not own; signed and notarised installers (Developer ID, Authenticode) with the measured first-share time per release. Text: the three wants on the front page and finality on page two; "a block pays its miner whether or not anyone buys a proof that day"; the eight regulatory sentences of lane 3 section 8.3 (no issuer, no sale; the sustainability indicators per era; no price language; the pool holds no balance; no privileged key), labelled "not legal advice; counsel is engaged". +Why it is right: lane 1's shape (income halves 60 to 120 days after a peak, under USD 0.10 per kWh within 6 to 18 months, 50 to 100 percent of hash gone in 90 days) and its rows 2, 4, 7 and 9; lane 5's install findings (SmartScreen warns on any file without reputation); lane 3's regulation rows (MiCA 4(3)(b) exempts block-reward assets; the UK regime from 25 October 2027 covers platforms and custody, not mining). +Evidence: past.md sections 3 and 4; future.md section 8; reinvent.md 3.1 and 4.1. +Cost: 15, plus the project lead's certificates and the customer's signature. +Gate: every gate line in testnet-go.md with its check; the forbidden-strings check passes on the new text; the hash-origin report posts on Devnet 2 for seven days before the testnet go. +Order: tenth; text and gates can land any hour, and the customer gate is the one that takes longest. + +### 2.11 The pool finished (new, lanes 2, 4 and 5) + +What it is: pool-0 run by the project at the testnet go with the member's vote key in every header (the pool holds no weight and no vote), a 1 percent fee published beside the dev fee, PPLNS with a round every 60 s; TLS before the public testnet (spec 9.3) and the pool page rows Q69 to Q73; then the pool without an operator: a P2Pool-style share sidechain in the pool crate, shares forming a 10-second chain committed in the coinbase extra data, the window's payout computed by every node from consensus data as the 20 percent already is, no balance and no operator key, every member running the node the design already assumes. Lane 2's verdict: the finished form is Monero P2Pool's, not SmartPool's (SmartPool's on-chain claims died on gas, and at 1.35 ms per share verification a sampled contract would still need the zkEVM to re-derive a warp unit per sampled share); lane 4's in-protocol pool (shares inside blocks, every node verifying every share) stays refused at 14.6 GB a day per node. +Why it is right: no pool without an operator exists on any chain but Monero (P2Pool at 7.7 percent of hash, 3,520 miners, 0 percent fee; Ocean 2.05 percent of blocks with 85 percent through DATUM; Stratum V2 job declaration at 1 block in 52,297); Igneum already holds the three objects that make one cheap (the vote key in the header, the 20 percent paid by sortition, the coinbase extra data), and nobody has built one on a DAG chain. An 8 GB card at 1 TH/s finds a solo block every 16 hours and 23 percent of its days have none, so the first-month ladder of item 6 depends on a pool from about 1 TH/s. +Evidence: unfinished.md section 5 (5.2, 5.3) and headline 2; invent.md section 4 and rank 13; reinvent.md 3.5 and 1.4; pool.md; spec 09. +Cost: 60 (TLS 8, the pool page rows about 12, the share sidechain about 40). +Gate: 100 members on the fast-time network paid by the coinbase rule from a share chain with no operator key, a withheld share earning nothing, a member's dropped share provable from its own log; the first payout inside two minutes of the first share for an 8 GB card on Devnet 2. +Order: eleventh; pool-0 and TLS before the testnet go, the share sidechain before the network passes about 1 TH/s. + +### 2.12 The weight-backed peer directory (new, lane 4, prototype) + +What it is: a coinbase section where a key above dust may publish its node's address; a fresh node dials from that list weighted by 30-day weight, beside the DNS seeds. +Why it is right: lane 4's model E bounds an eclipse by a 34 percent attacker at 1.8e-4 with 8 outbound peers and 3.2e-8 with 16; prior art (DNS seeds 2011, discv5 2019, Heilman's eclipse paper 2015) weights nothing by work; lane 3's 2031 death row (weight concentrating in hosting firms) is first seen through such a list. +Evidence: invent.md section 7.1 and rank 4; horizon rank 9 (the peer floor it extends). +Cost: 10. +Gate: a fresh node with genesis peers only reaches 8 outbound from the directory; a 34 percent attacker eclipses under 0.1 percent of 1,000 fresh starts; the NAT fraction measured on the fleet. +Order: last; a prototype, dropped if the NAT fraction makes the list useless. + +## 3. Rejected, with the one line that killed each + +| Idea | The line | +|---|---| +| A pool inside the protocol (shares in blocks, no operator) | FruitChains (2016): 14.6 GB a day and 5 cores per node at 10,000 miners on a 10 s share; 146 GB and 50 cores at 100,000 | +| A reward slice for serving state or data | a key with no state answers in 108 ms over a 100 ms link; it pays for what the lottery already compels | +| Proof of propagation receipts | no consensus clock; 94 to 376 MB a day of receipts; GHOSTDAG already is a proof of propagation | +| Proof of following beyond class v5 | the epoch seed and the state root already commit to the recent chain | +| A first-block bonus per key | a 10 percent miner collects it 2,592 times a window: an instamine with extra steps | +| Reorg insurance for exchanges, pause insurance from the pool | no slashable payer by ruling; the lock is the product; the pool pays the wrong people | +| Proof of latency, proof of unique card, an energy-price oracle, hash-rate futures in protocol | no clock; nothing counts cards by design; a lever the bid neutralises; needs a coin bond | +| Finality as a service for other chains | kept as a demand-gated prototype only; no customer named, so not on the list | +| The weight-aged reward rule (pay per block falls when hash arrives faster than the weight) | a 30-day income ramp on every honest newcomer, which the first-month ladder cannot afford; revisit only if weight by hosting provider passes a third | +| Mining is proving; useful work in the hash | 2.9 MB of openings per block, a 32 to 40 ms verify against the 10 ms gate; Aleo's fastest-prover-wins | +| Proving others' chains as the main income | all of Ethereum L1's proving is about USD 36 a day against USD 13,700 of year-1 emission | +| Vote-or-burn | 70 to 80 percent respect against the 95 percent test; the signing bonus is on at genesis instead | +| Dormant-coin rent, any holder penalty, a device bounty, a coin stake, Bitcoin anchoring, privacy | refused by ruling | +| A hardware wallet verifying proofs on the secure element | a bn254 pairing on a Cortex-M class element is seconds to minutes; the companion verifies | +| A compute market for unverifiable work | an escrow without a verifier is a trust-me payment with lower fees | +| Merged mining, multi-algo, an auxiliary chain | A child inherits its parent's pool concentration and loses its say in rules; a second hash lane splits the weight table and the DAA (Myriad, Verge, DigiByte); the one merged-mining shape with value is the share sidechain of item 11 | +| Gamification paid from a fund, referral in coins, an airdrop for anything, NFT badges, off-chain points, a rank-by-hashrate board, a top-earners board in fiat, streaks that demote | there is no fund; nothing is for sale; the rung is a chain fact; a renter tops hashrate on day one; the burn was refused | +| Any number that needs a company server to be trusted | every number shown is reproducible from a node, or it is not shown | + +## 4. What this round did not run + +| Item | Why | Where it sits now | +|---|---|---| +| The H100 and A100 hash rate on rented pods | no pod rented for this round | item 10's measurement line; lane 3 section 3 | +| The in-guest BLS and colouring cycle counts (fin-proof 6.1) | no box slot taken for this document | item 2's cost | +| The 4090 rows for class v5 (section 7 of its page) | the pod window was the class-v5 lane's | item 3's cost | +| Reddit, bitcointalk and the Wayback Machine | refused this environment's fetches; quotes came through search snippets and project forums | past.md section 2, reinvent.md section 1, each labelled | + +## 5. The closing line + +Nothing is added to this list without removing something. Signed, the mission programme, 7 October 2026. diff --git a/docs/analysis/mission/past.md b/docs/analysis/mission/past.md new file mode 100644 index 00000000..eec69950 --- /dev/null +++ b/docs/analysis/mission/past.md @@ -0,0 +1,304 @@ +# The past, honestly: every GPU-mined chain since 2011 and what GPU miners want + +Lane 1 of the last mission. Written 7 October 2026 by the past lane for the mission coordinator. Scope: the history of every chain that mattered to GPU miners, what each promised, what each paid, when the GPU miners left, and what the record says Igneum should change. The ASIC side of this history (which hash fell to which chip and how fast) is already in `docs/analysis/asic-resistance-history.md` and is not repeated; this file cites it where a chip is the reason a chain died for GPUs. The emission and governance comparison against Kaspa, Monero, Ethereum and the rollups is in the Horizon economy lane (section 4.6) and is not repeated either. + +Every figure from a source carries a URL and the access date in section 6. Every figure from memory is labelled approximate. Reddit, bitcointalk and the Wayback Machine refuse this environment's fetches (sections 2 and 6 say which quotes came through search snippets instead). Times are UK time. + +## 0. Progress + +| Time (UK, 7 Oct 2026) | State | +|---|---| +| 08:05 | Read CLAUDE.md, asic-resistance-history.md, horizon-2026-10.md section 1, economy-and-utility.md 4.6 | +| 08:10 to 08:45 | 75 web searches and 60 fetches across project blogs, pool blogs, forums, press (search budget exhausted at 08:40) | +| 08:49 | Writing; sections 1 to 6 landed in one pass | +| 08:53 | Length check (258 lines, under the 300 floor); added 1a (the Merge week) and 1b (promised against delivered), split the grouped chain paragraphs, reconciled headline 1's counts against the table | +| 08:58 | Done. File complete, reported to the coordinator | + +## 1. One row per chain + +Income columns are USD per card per day before electricity unless stated. "Exit" is when the median GPU miner stopped earning more than electricity at USD 0.10 per kWh, or when the lane closed outright. State is October 2026. + +| Chain (hash) | Launch | What it promised GPU miners | Peak GPU income (card, date) | Exit income (card, date) | GPU miners left | What killed the GPU lane, or state today | +|---|---|---|---|---|---|---| +| Litecoin (scrypt) | 13 Oct 2011 (approximate) | Memory-hard hash mineable on CPUs and consumer GPUs; no ASIC existed (litecoin.watch) | 200 to 800 kH/s per Radeon, 2012 to 2013; USD per card approximate 1 to 5 | 2014, under power for any GPU once Zeus 28 MH/s at 800 W shipped | Mid 2014 | Scrypt ASIC (Gridseed Jan 2014, Zeus mid 2014, Antminer L3 2017). Today an ASIC chain merged with Dogecoin | +| Dogecoin (scrypt, AuxPoW) | 6 Dec 2013 | A fun scrypt coin for the same GPUs as Litecoin | Approximate USD 1 to 3 per card, Jan to Feb 2014 | Aug 2014 | Aug to Sep 2014 | Merged mining under Litecoin from block 371,337 (28 Aug 2014); hashrate +1,500 percent in a month (Binance Research). GPUs never came back | +| Ethereum (Ethash) | 30 Jul 2015 | GPU-friendly memory-hard hash with a promise to leave for proof of stake | USD 0.233 per MH per day, Jan 2018 (so USD 23 per 100 MH); USD 6.35 to 9.15 per RTX 3080, early 2021 (Minerstat via Wccftech); May 2021 approximate USD 12 to 15 per 3080 | USD 1 to 2 per 3080 on 14 Sep 2022 (approximate) | 15 Sep 2022, all at once | The Merge. About 900 TH/s and about 20 million GPUs (Tom's Hardware estimate) lost 94 percent of GPU income in one block (2Miners: USD 24 M a day to USD 1.2 M) | +| Ethereum Classic (Etchash) | Jul 2016 fork | A home for Ethash GPUs after the Merge | 70.5 to 158 TH/s in 7 hours on 15 Sep 2022 (CoinDesk), 296 to 312 TH/s inside a day | Under electricity for most GPUs within weeks; hashrate -48 percent in four days (AMBCrypto) | Sep to Dec 2022, then again as E9 Pro and Jasminer ASICs took the chain | Today 130 to 186 TH/s, ASIC-dominated; best ASIC nets USD 3.64 a day at USD 0.10 (asicminervalue) | +| Monero (CryptoNight to RandomX) | 18 Apr 2014 | CPU and GPU mining, fork away any ASIC | Vega 56 era 2017 to 2018, approximate USD 2 to 4 per card | 30 Nov 2019: GPU performance "gets a tiny boost or degrades" (MinerUpdate) | 30 Nov 2019: 75 percent of GPU miners offline (MinerUpdate) | RandomX moved it to CPU on purpose; hashrate 300 MH/s to 800 MH/s in weeks. Qubic's rented-CPU campaign claimed 51 percent on 11 Aug 2025 with a 6-block reorg (The Block); the AFT 2026 paper finds no sustained majority and no reward edge | +| Zcash (Equihash 200,9) | 28 Oct 2016 | "Universal accessibility" in mining (forum users' reading of the project) | USD 8 per GTX 1080 Ti, Jul 2017 (WhatToMine via 2Miners) | USD 2.63 per 1080 Ti, 6 May 2018 (2Miners) | Jun to Sep 2018 | Antminer Z9 mini announced 3 May 2018; the company stayed neutral; no fork. ASIC chain since; proof-of-stake migration under discussion (approximate) | +| Ravencoin (X16R, KAWPOW) | 3 Jan 2018 | GPU-only by design; three hash changes to keep it so | Approximate USD 6 to 8 per 3080, Feb to Apr 2021 (RVN peak USD 0.2857) | 3080 loses USD 0.13 to 0.31 a day, 2026 (WhatToMine) | Gradual through 2023 to 2025 | KAWPOW (6 May 2020) cut hashrate 10x as FPGAs left and held off chips for six years; the Merge doubled it (8.9 to 15.9 TH/s). On 7 Aug 2026 a header-validation flaw let blocks carry "no genuine ProgPoW work" and split the chain; RVN -19 percent (crypto.news) | +| Ergo (Autolykos v2) | 1 Jul 2019 (approximate) | Memory-hard, ASIC-resistant, GPU-only (minerstat FAQ) | Approximate USD 3 to 4 per 3080, Sep to Nov 2021 (ERG near USD 15) | USD 0.22 per 3080 before power, Oct 2026 (hashrate.no) | Late 2022 onward | The Merge pushed it from 22 to 155 TH/s in a day (Decrypt); difficulty ate the income within weeks. Still GPU, no chip, income under power | +| Kaspa (kHeavyHash) | 7 Nov 2021 | "GPU PoW", fair launch, no premine (bitcointalk ANN title) | Approximate USD 2 to 3 per 3080, Feb to Mar 2023 | 3070 at USD 1.21 a day, 14 Apr 2023 (2Miners) while a KS2 made USD 361 | Apr to Oct 2023 | IceRiver KS0/KS1/KS2 (Apr to Jul 2023), Bitmain KS3 (May 2023). KS0 earned USD 25 a day in Jul 2023. Today 347 PH/s (hashrate.no), KS7 at USD 1,899, GPUs effectively zero | +| Grin (Cuckaroo29, Cuckatoo31+) | 15 Jan 2019 | 90 percent of blocks for the GPU hash at launch, falling to zero over two years (Grin forum) | Approximate USD 1 to 2 per card, Jan 2019 | 2020 | 2019 to 2020, by schedule | The schedule itself. Today Cuckatoo32 ASIC only, GRIN at USD 0.035, USD 16 k daily volume (minerstat, approximate) | +| Beam (BeamHash III) | 3 Jan 2019 | GPU-friendly Equihash 150,5 | Approximate USD 1 to 2 per card, Jan 2019 | 2020 onward | Most by 2021 | Never an ASIC; the price went. Still GPU-mined, sixth hard fork July 2026, negligible income | +| Conflux (Octopus) | Oct 2020 (approximate) | GPU-only, no FPGA or ASIC | Approximate USD 2 to 3 per 3080, 2021 | USD 0.71 per 3080 before power, Oct 2026 (hashrate.no) | Ongoing | Still GPU at 3.9 TH/s. No chip in six years; income under power for most cards | +| Alephium (Blake3) | Nov 2021 (approximate) | GPU-mineable sharded chain | Approximate USD 1 to 2 per 3080, 2023 | 2024 | May to Oct 2024 | Goldshell AL-Box 360 GH/s at 180 W (May 2024), AL-Box III 1.25 TH/s (Oct 2024). GPUs out in five months; even the ASICs now lose USD 3.44 a day at USD 0.10 (asicminervalue) | +| Nexa (NexaPow) | 21 Jun 2022 | CPU first, then GPU, "scale to global capacity" | Top of the GPU tables Jul 2023 (2Miners) | 2024 (approximate) | 2024 (approximate) | Price. Approximate: down over 99 percent from its 2023 high; hashrate a fraction of 2023 | +| Aleo (PoSW) | 18 Sep 2024 | Proving as mining on GPUs | USD 13.50 per RTX 4090 at ALEO USD 9, Sep 2024 (PANews via AiCoin) | Under USD 5 per 4090 at USD 3.40, late 2024 (same source) | Q4 2024 to 2025 | Price and allocation: a one-year lock on early rewards, validators seeded with 270 k to 1.1 M tokens, 10 M stake to validate; f2pool holds 28.9 percent of proving (hashrate.no). "Difficulty plummeted ... as miners exited" | +| Iron Fish (Blake3, FishHash) | 20 Apr 2023 | GPU mining of a private chain | Approximate USD 1 to 2 per 3080, Apr 2023 | USD 0.48 per 3080 before power, Oct 2026 (hashrate.no) | 2023 to 2024 | Blocks of "unknown origin and hash power" within weeks (FPGA suspected); FishHash fork 2 Apr 2024 kept it GPU; the price did the rest | +| Flux (ZelHash) | 2018 as Zel | GPU-only Equihash 125,4 | USD 50 k a day across the chain, Sep 2022 (2Miners) | Late 2025 | Late 2025 | Proof of Useful Work v2 (RunOnFlux, 23 Oct 2025): FluxNodes produce all blocks; "GPUs stopped having any relevance to FLUX rewards" | +| Firo (MTP, FiroPoW) | 2016 as Zcoin | GPU-only ProgPoW variant since 26 Oct 2021 | 4x hashrate after the Merge | USD 0.56 per 3080 before power, Oct 2026 (hashrate.no) | Ongoing | No chip in five years. Still GPU, 13 to 54 GH/s, small | +| Vertcoin (Lyra2RE, Verthash) | 8 Jan 2014 | "The people's coin", fork away every ASIC | Approximate USD 1 to 2 per card, Dec 2017 | 2019 | 2018 to 2019 | Two rental 51 percent attacks (Dec 2018: 300-block reorg, about USD 100 k; 1 Dec 2019: 603 blocks replaced, NiceHash). Verthash (Jan 2021) kept GPUs; nobody came back | +| Bitcoin Gold (Equihash-BTG) | Oct 2017 | "Make Bitcoin decentralized again" on GPUs | USD 474 a coin, Dec 2017 | 2018 | 2018 to 2020 | 51 percent attacks: May 2018 (388,000 BTG, up to USD 18 M), Jan 2020 (29 blocks, USD 70 k). Delisted by Binance 1 Sep 2024 and Upbit 23 Jan 2025; "under 100 actively reachable nodes" (Decrypt) | +| EthereumPoW (Ethash) | 16 Sep 2022 | Ethereum mining continues | Above USD 140 a coin at launch | 2022 to 2023; profitability -85 percent from peak | Within months | Price: USD 1.70 by mid 2025 (99 percent down); pools left for ETC | +| Nervos CKB (Eaglesong) | 16 Nov 2019 | GPU-mineable launch | 300 GTX 1070 Ti earned USD 410 a day, 19 Nov 2019 (2Miners) | The same rig earned USD 4.46 a day, 21 Mar 2020 | Mar 2020 | Hashrate 198 TH/s to 1.99 PH/s in 16 days before any chip was sold (secret ASICs); Antminer K5 Apr 2020 at USD 22 then 11 a day | +| Radiant (SHA512/256d) | 2022 (approximate) | "GPU/ASIC mining" in the ANN title | Approximate USD 1 per 3080, 2023 | Sep 2024 | Sep 2024 | IceRiver RX0 and DragonBall A11 ASICs, Sep 2024. Designed to go to ASIC | +| Karlsen, Pyrin, Nomura (kHeavyHash forks) | Nov to Dec 2023 | "We will ensure long-term GPU-friendly mining" (Karlsen README) | Approximate USD 0.5 to 1 per 3080, Dec 2023 | 2024 | 2024 | Karlsen moved to FishHash (KarlsenHashv2, 12 Sep 2024) as kHeavyHash chips arrived; Pyrin was called "another pre-mine scam" on bitcointalk (five days of private mining before the announced start) | +| Dynex (DynexSolve) | Sep 2022 | Proof of useful work, "the most GPU mined coin" (22 percent of Hive OS, Oct 2023) | Approximate USD 2 to 4 per 3080, mid 2023 | 2024 | 2024 | Price: 99.9 percent below its USD 1.39 high (CoinGecko). The useful-work marketplace never paid the miners | +| Qubic (uPoW) | 2022 (approximate) | AI training as mining, CPU first | By 2025 about 90 percent of its compute was GPU rigs (Qubic blog) | n/a | Rotating | Pivoted to CPU incentives, then rented its idle fleet to Monero (May to Aug 2025, 27,000 blocks, USD 3.5 M), then to Dogecoin ASIC mining (1 Apr 2026). A hashrate broker, not a GPU chain | +| Clore (Kawpow) | 2022 | GPU coin paid for GPU rental | ATH USD 0.45, 17 Mar 2024 | Dec 2025 | Dec 2025 | Proof of work "ended" at block 1,584,180 (Clore changelog, Dec 2025): "miner sell pressure fully removed". A 4090 rents for USD 1.18 to 2.45 a day there | +| TurtleCoin (CryptoNight Turtle) | Dec 2017 | A friendly CPU/GPU coin | Negligible | Mar 2023 | 15 Mar 2023 | Halted at block 5,500,000; token moved to Fantom (TurtleCoin v2 FAQ). Dead as a chain | +| Musicoin (Ethash) | 2017 | Ethash side income | Negligible | 2019 | Jul 2019 | Repeated 51 percent attacks, Bittrex delisting, 2Miners delisting (31 Jul 2019: "Musicoin is dead") | +| Akroma (Ethash) | 2018 | Ethash side income with masternodes | Negligible | 2019 | Jul 2019 | Developers left; USD 92 daily volume; delisted by 2Miners | +| Callisto (Ethash) | 2018 | Ethereum Classic airdrop chain | Negligible | 2024 | 2024 | Team liquidity crisis and "civil war" in 2024 (Callisto history page). Dead | + +### 1a. The Merge week, the one migration with hour-level data + +| When (UK) | What happened | Source | +|---|---|---| +| 15 Sep 2022, 07:43 | The Merge; Ethereum's last proof-of-work block; about 900 TH/s of GPU hash loses its income | Tom's Hardware | +| 15 Sep 2022, 07:00 to 14:00 | ETC from 70.5 to 158.3 TH/s; RVN from 8.9 to 15.9 TH/s; ERG from 22 to about 70 TH/s | CoinDesk, Decrypt | +| 15 to 16 Sep 2022 | ETC peaks at 296 to 312 TH/s (about a third of Ethereum's hash); ERG peaks at 155 TH/s (7x) | AMBCrypto, crypto.news, Decrypt | +| 16 Sep 2022 | ETHW mainnet; the fork trades above USD 140 and falls for three years | KuCoin price history | +| 19 Sep 2022 | ETC hashrate down 48 percent from its peak in four days | AMBCrypto | +| Sep 2022 | Hiveon pool: 16 percent of its miners to ETC, 7 percent to RVN, the rest spread or gone | Hiveon | +| 12 Sep 2022 (before) | 2Miners' arithmetic: USD 24 M a day of GPU income, 94 percent of it Ethereum; USD 1.2 M a day left for all GPU coins after | 2Miners, The Block | + +The arithmetic is the whole story: the receiving chains had one twentieth of the income and received, for a day, one third of the hash. Difficulty did the rest. The 2Miners advice of the day was to pick ETC, RVN or ERG "at least for the first days", and the first days were all there were. + +### 1b. Promised against delivered + +| Chain | The launch text (quoted or paraphrased) | What GPU miners got | Months of GPU income | +|---|---|---|---| +| Grin | 90 percent of blocks to the GPU hash at launch, falling to zero over two years (forum, Aug 2018) | Exactly that | About 18 | +| Ravencoin | GPU-only, fork away FPGAs (KAWPOW, May 2020) | GPU-only for six years; a header bug, not a chip, split the chain in 2026 | 100 and counting, under power since about 2023 | +| Kaspa | "GPU PoW", fair launch (bitcointalk ANN title) | 17 months, then chips at 20x and more per joule | 17 | +| Karlsen | "We will ensure long-term GPU-friendly mining" (README) | A second hash in nine months to keep the promise; income under power either way | 10 | +| Iron Fish | A GPU-mined private chain | Unknown hardware inside weeks; a GPU hash a year later | 12, then under power | +| Aleo | Proving as mining on GPUs | USD 13.50 a day per 4090 for a few weeks, then price and pools | 3 | +| Flux | GPU-only, "resistance to concentrated specialized-hardware advantages" | Seven years, then block production moved to nodes | 84, then closed | +| Clore | Mine the coin that pays for GPU rental | Proof of work ended in December 2025; rental stayed | 36 | +| Nervos | GPU-mineable launch | 16 days of 10x hashrate growth from secret chips four months in | 4 | + +What the table says, chain by chain, in one short paragraph each. + +**Litecoin.** The first GPU coin and the first proof that a memory-hard hash on paper is a compute-bound hash in a fab. Scrypt with a 128 kB scratchpad fit on a chip in 27 months. GPU miners did not vote or fork; they sold the cards. Lesson for Igneum: the dataset has to be bigger than any die the chip can afford, and the lane's own history (asic-resistance-history.md rows Scrypt) already prices this. + +**Dogecoin.** The only chain on the list whose GPU exit was a decision, not a defeat. Merged mining handed security to Litecoin's ASICs and the hashrate rose 15x in a month. Lesson: a small chain that shares hardware with a big one is mined by the big one's miners whenever the big one's miners choose; Igneum's hash has no big sibling, which is a feature and a cost. + +**Ethereum.** Seven years of GPU income, three cycles, one exit that was announced for five years and still removed 94 percent of all GPU mining income in one block. The money went to ETC, RVN and ERG for days and then to the shelf. Lesson: miners follow income, not loyalty, and an exit that is scheduled is still an exit. + +**Ethereum Classic.** The refugee chain. It absorbed a quarter of Ethereum's hashrate within hours and lost half of that within four days, then went to ASICs. Lesson: a chain that receives a migration gets a difficulty shock, not a community. + +**Monero.** Four hash forks in 20 months kept chips off and cost 85 percent of hashrate each time (asic-resistance-history.md). RandomX then chose CPUs on purpose and three quarters of the GPU miners left in a day. In 2025 a rented CPU fleet (Qubic) claimed a majority and produced a 6-block reorg; the peer-reviewed analysis finds no sustained majority and no profit. Lesson: ASIC resistance by hand is a treadmill; a majority that cannot profit still frightens exchanges. + +**Zcash.** The clearest record of a project refusing to fork for its GPU miners. The forum poll ran in February 2018, the Z9 shipped in May, the company stayed neutral, the GPUs left by autumn. Income per 1080 Ti fell from USD 8 to USD 2.63 before the chip arrived, because the price fell first. Lesson: the price kills before the chip does. + +**Ravencoin.** The one chain that forked three times and kept the GPUs for six years. KAWPOW cut hashrate 10x on fork day because the FPGAs left. Then in August 2026 a validation bug (not a chip) split the chain. Lesson: random-program hashes work; the client is the next weak point, and Igneum has one client. + +**Ergo.** A GPU-only hash that never saw a chip and still pays USD 0.22 a day per 3080. The Merge gave it 7x the hashrate in a day and the difficulty took the income back in weeks. Lesson: the hash is not the income. + +**Kaspa.** The template Igneum forked. A fair launch, a compute-bound hash, 17 months of GPU income, then IceRiver and Bitmain in the same quarter. In April 2023 a 3070 made USD 1.21 a day beside a KS2 making USD 361. The GPU share went to nothing by the end of the year while the chain prospered. Lesson: the chain can win while its GPU miners lose; Igneum's whole bet is that these two must not separate. + +**Grin and Beam.** Both launched in January 2019 into a bear market. Grin scheduled its own GPU lane to die over two years and it did. Beam never had a chip and still lost its miners to the price. Lesson: a launch into a falling market with a thin order book does not get a second chance; the ramp must survive a bad first year. + +**Conflux, Firo, Iron Fish.** Three GPU-only hashes with no chip after five to six years, each paying under a dollar a day per card. Lesson: resisting the chip buys the right to be small. + +**Alephium.** A sharded chain with a plain Blake3 hash, GPU-mined for about 30 months, then Goldshell shipped a 180 W box in May 2024 and a 1.25 TH/s box five months later. The GPUs were out by autumn and by 2026 the boxes themselves lose money at USD 0.10. Lesson: a chip on a small chain eats the GPUs and then eats itself; the chain gets neither back. + +**Nervos.** The extreme case of private hardware. Hashrate rose 10x in 16 days in March 2020, four months after launch and a month before the first ASIC was on sale; a 300-card GPU farm went from USD 410 a day to USD 4.46. Lesson: the first ASIC is always private, and the launch ramp has to assume one. + +**Radiant.** Said "GPU/ASIC" in its own announcement title and went to ASIC on schedule in September 2024. Lesson: a chain that invites the chip gets the chip; honest, and not Igneum's path. + +**EthereumPoW.** The fork that promised Ethereum mining would continue. The coin traded above USD 140 for a day and under USD 2 by 2025; the pools left for Ethereum Classic within months. Lesson: a fork keeps the code and loses the market; the market is what paid the miners. + +**Karlsen, Pyrin, Nomura.** Three kHeavyHash forks launched into the gap the Kaspa chips opened. Karlsen kept its README promise by changing its hash within a year; Pyrin was called a premine scam on launch day; Nomura is a title. Lesson: "the GPU version of X" is a business model with a nine-month half-life. + +**Nexa.** Fair launch, CPU first, the top of the profitability tables for a summer, then price. Lesson: being the most profitable coin on WhatToMine for a month is a sell signal, not a community. + +**Aleo.** The one chain where mining was proving. The fastest provers took the reward, the pools took the rest, the price fell from USD 9 to USD 3.40 and the GPUs left; the record also shows what miners say when insiders hold the supply. Lesson: Igneum's separation of lottery and proving is the right answer to the first half; the allocation half is answered by having no allocation. + +**Flux, Clore, Dynex, Qubic.** Four projects that stopped paying GPUs for hashing and told miners to rent, host or train instead. Flux moved block production to nodes, Clore ended proof of work and pays for rental, Dynex's marketplace never paid, Qubic became a hashrate broker for Monero and then Dogecoin. Lesson: "useful work" projects abandon the miner the day the useful work does not pay; Igneum's proving must be priced to clear (Horizon rank 7) or it is Dynex. + +**Vertcoin, Bitcoin Gold, Musicoin.** The three small chains 51 percent attacked by rented hash, between USD 70 k and USD 18 M a time. Each was GPU-only and each was attacked because it was. Lesson: a GPU chain is rentable by definition; finality has to be something hash cannot buy. + +**EthereumPoW, TurtleCoin, Akroma, Callisto.** Dead by price, by halt, by abandonment, by a team's money running out. Lesson: a chain with no market is a chain with no miners within a year. + +## 2. What GPU miners say they want + +Twenty posts and articles read in full or in snippet, 2018 to 2026. Each quote is under 15 words. Reddit threads could not be fetched from this environment, so the miner voice here comes from project forums, pool blogs, bitcointalk snippets and press that quoted miners by name. + +| # | Date | Forum or source | Quote | URL | +|---|---|---|---|---| +| 1 | 25 Feb 2018 | Zcash forum, user vgm | "Centralized ASIC mining will destroy hobby mining along with any organic user growth potential." | forum.zcashcommunity.com/t/lets-talk-about-asic-mining/27353 | +| 2 | 25 Feb 2018 | Zcash forum, user JKDC | "Decentralization is as important as privacy." | same thread | +| 3 | 26 Feb 2018 | Zcash forum, user aoeu | "I'd rather have GPUs for general computation, not silicon trash." | same thread | +| 4 | 25 Feb 2018 | Zcash forum, user Autotunafish | "Zcash is about universal accessibility, not a select few" | same thread | +| 5 | 27 Aug 2018 | Grin forum, igno.peverell (launch text) | "A healthy and grassroot GPU mining community at launch is highly desirable." | forum.grin.mw/t/proof-of-work-update/713 | +| 6 | 30 Nov 2019 | MinerUpdate (RandomX day) | "Honest miners will be fighting an uphill battle against botnets" | minerupdate.com (section 6) | +| 7 | 21 Mar 2020 | 2Miners blog (Nervos) | "ASICs or FPGA's are to blame for a sudden increase in the hash rate." | 2miners.com/blog/nervos-ckb-network-hashrate-increased-asics-are-the-cause/ | +| 8 | 9 Apr 2020 | VoskCoinTalk, user Rocky_Bro | "Those 3000watt beasts just eat slower devices for breakfast." | voskcointalk.com/t/.../172 | +| 9 | 12 Sep 2022 | The Block, Ethan Vera (Luxor) | "You have to have sub $0.03 per kilowatt hour and new generation GPUs." | theblock.co (section 6) | +| 10 | 12 Sep 2022 | The Block, Mark D'Aria (Bitpro) | "Ethereum is 95% of the total income. Everything else will get crushed." | same article | +| 11 | 12 Sep 2022 | 2Miners blog, Confessions of a Miner 2 | "When mining makes you lose the money you stop mining." | 2miners.com/blog/confessions-of-a-miner-2-is-this-the-end-of-gpu-mining/ | +| 12 | Sep 2022 | Hiveon pool, year review | "16% moving to ETC, 7% going to RVN" | hiveon.com/news/reflection-and-forecast-... | +| 13 | 2023 (approximate) | bitcointalk, "Kaspa asics" thread (snippet) | "Specialized mining equipment optimized for corporate industry raping" | bitcointalk.org/index.php?topic=5449022.0 | +| 14 | Dec 2023 | bitcointalk, Pyrin ANN thread (snippet) | "another pre-mine scam" | bitcointalk.org/index.php?topic=5476198.0 | +| 15 | 2023 | bitcointalk thread title | "Why most premined coins (>90% of all altcoins) will eventually fail" | bitcointalk.org/index.php?topic=5457833.0 | +| 16 | 14 May 2024 | Iron Fish blog (on its own launch) | "unknown origin and hash power" | ironfish.network/learn/blog/2024-05-14-fish-hash-audit | +| 17 | 2024 | Karlsen README (launch text) | "We will ensure long-term GPU-friendly mining." | github.com/karlsen-network/karlsend | +| 18 | Sep 2024 | PANews via AiCoin, Aleo community user | "When you don't know where the liquidity comes from, you are the liquidity." | aicoin.com/en/article/419859 | +| 19 | 31 Jul 2019 | 2Miners blog (delisting) | "Musicoin is dead, Akroma is irrelevant." | 2miners.com/blog/akroma-and-musicoin-delisting/ | +| 20 | 10 Feb 2026 | Clore blog | "losing money mining with most mid-range GPUs at average electricity rates" | blog.clore.ai/gpu-mining-is-dead-... | + +### The three wants, with counts + +| Want | Posts asking for it (of 20) | Evidence rows | +|---|---|---| +| 1. Hardware that stays useful: no chip, no FPGA, a card that games or computes when the coin dies | 10 | 1, 2, 3, 4, 5, 7, 8, 13, 16, 17 | +| 2. Income above electricity that does not fall off a cliff | 6 | 9, 10, 11, 12, 19, 20 | +| 3. A fair supply: no premine, no insider allocation, a coin somebody will buy | 4 | 14, 15, 18, 19 | + +### The three hates, with counts + +| Hate | Posts (of 20) | Evidence rows | +|---|---|---| +| A. Secret hardware on the chain before anyone can buy it | 5 | 7, 8, 13, 16, and Nervos (section 1) | +| B. Premine, VC allocation, locked airdrops | 3 | 14, 15, 18 | +| C. The income cliff and the dead market (an exit, a delisting, a 99 percent drawdown) | 5 | 10, 11, 12, 19, 20 | + +### Mapped to Igneum's design (horizon-2026-10.md section 1 and the litepaper) + +| Want or hate | Status | Mechanism, and the honest gap | +|---|---|---| +| Want 1, hardware stays useful | Partly answered | Random-program hash with hourly swaps, 256 MB dataset with 8 dependent reads, era draws from chain state, no scheduled fork (CLAUDE.md design paragraph). The chip model says 2.1x per joule at class v4 and the N ladder is a decision owed (Horizon item 4 and rank 10). Kaspa's chip was 20x to 1,200x; 2.1x is a different world, but a 2.1x chip at scale still ends home mining on power price alone. The gap is the ladder decision and a public chip model per era | +| Want 2, income without a cliff | Partly answered | 100 IGN a block gliding 2.9 percent a month, no halving day, a 1 percent tail (tail-emission.md). No chain on this list ever had a cliff-free schedule, so this is new. The gap: every exit in section 1 came from price, not schedule, and no protocol sets price. What Igneum can do is publish the per-tier income at three prices before launch (the consequences rule) so nobody buys a card on a number that was never promised | +| Want 3, fair supply | Answered | No premine, no dev fund, no fee to any team, 90-day ramp from 10 percent (CLAUDE.md, tail-emission.md). Aleo and Pyrin are the counter-examples and Igneum has nothing they had | +| Hate A, secret hardware at launch | Partly answered | The ramp from 10 percent makes the first 90 days worth less to a private farm; the correlated-group detector and `security_alert` (Horizon rank 16) show it; the hourly program swap means a private FPGA bitstream has to be re-made every hour. Not answered: a private rented GPU fleet is not hardware and is allowed; Nervos's 16-day 10x rise would look the same on Igneum's charts. The gap is a published launch-week hash-origin report (pools, key counts, fleet shares) so the community sees it the day it happens | +| Hate B, premine and allocations | Answered | As Want 3 | +| Hate C, the cliff and the dead market | Not answered by protocol | The glide removes the schedule cliff and the proving market gives the coin a buyer other than an exchange (Horizon 4.1a), but a rollup customer paying in dollars is a contract not yet signed (Taiko is the first named customer). Until a customer pays, Igneum has the same exposure as Ergo in 2023: a good hash, a thin market | + +One more thing the posts do not say and the record does: nobody on these forums asked for finality, for a DAG, or for proving. They asked for a card that keeps its value, a bill that gets paid, and a coin that sells. Igneum's technical answers are to questions miners did not ask; the mission should put the three wants on the front page and the finality on page two. + +## 3. The earnings curve as a pattern + +USD per card per day before electricity. A 3080 draws about 220 W, so electricity at USD 0.10 per kWh is USD 0.53 a day; a 4090 at 400 W is USD 0.96. Where a figure is approximate it says so. + +| Chain | Launch | Peak month | Peak income (per 100 MH Ethash or per 3080 equivalent) | Month income fell under power at USD 0.10 | Hashrate that left in the next 90 days | +|---|---|---|---|---|---| +| Ethereum | Jul 2015 | Jan 2018, then May 2021 | USD 23 per 100 MH (Jan 2018, USD 0.233 per MH); approximate USD 12 to 15 per 3080 in May 2021 | Never for a 3080 before the Merge (approximate USD 1 to 2 a day in Sep 2022, over power); the lane closed 15 Sep 2022 | 100 percent of Ethereum's 900 TH/s; of the GPUs, about a quarter tried ETC and half of those left inside four days (CoinDesk, AMBCrypto); approximate 80 percent of the cards were off within 90 days | +| Kaspa | Nov 2021 | Feb to Mar 2023 (approximate) | Approximate USD 2 to 3 per 3080 | Approximate Sep to Oct 2023 (a 3070 was at USD 1.21 in Apr 2023 as the first ASICs landed) | GPU share from near 100 percent to under 10 percent by Dec 2023 (approximate); the network's total hashrate rose the whole time | +| Ergo | Jul 2019 | Sep to Nov 2021 | Approximate USD 3 to 4 per 3080 | Approximate Nov to Dec 2022 (the Merge took hashrate from 22 to 155 TH/s in a day) | Approximate 50 to 70 percent of the post-Merge peak within 90 days | +| Ravencoin | Jan 2018 | Feb to Apr 2021 | Approximate USD 6 to 8 per 3080 | Approximate Nov 2022 (the FTX month); a 3080 now loses USD 0.13 to 0.31 a day | Approximate 40 percent of the post-Merge peak (15.9 TH/s) within 90 days | +| Aleo | Sep 2024 | Sep 2024 | USD 13.50 per 4090 at USD 9 (PANews) | Approximate Q1 2025 as the price reached USD 3.40 and difficulty followed the pools | "Difficulty plummeted ... as miners exited" (PANews); approximate over 50 percent of GPU provers within 90 days of the token-economics reveal | + +What the curve means per tier (the consequences rule), using the record's ratios rather than a price nobody can promise: + +| Tier | What the record says happens to them | What Igneum should tell them before launch | +|---|---|---| +| Home miner, one 8 or 12 GB card | First under power in every exit (the 3060 lost money on Clore's 2026 table while the 4090 still cleared) | Income per card at three prices, and that the glide never halves it overnight; the card keeps gaming when the income goes | +| Home miner, one 16 to 32 GB card | Last GPU standing; still under power 6 to 18 months after a peak on every chain in the table | The proving pool is the second income for this tier only; say so, with the measured 15.6 GB profile | +| Rig (6 to 12 cards) | Followed income across chains inside days (Hiveon: 16 percent to ETC, 7 percent to RVN) and shut down inside 90 days | Rig income at three prices; no loyalty expected, none needed, the 30-day weight pays staying miners a vote | +| Pool user | Took the pool's choice of chain and the pool's fee; pools held 29 percent of Aleo proving at launch | Which pools carry the finality signer, and that a pool's vote is the user's weight (ledger G8) | + +The common shape, in numbers: income peaks inside one to six months of a price run or a migration, halves within 60 to 120 days as difficulty catches the price, and falls under power within six to eighteen months of the peak; when it does, 50 to 100 percent of the GPU hashrate leaves inside 90 days. The trigger was a chip twice (Kaspa, and ETC's second decline), a scheduled exit once (Ethereum), and the price three times (Ergo, Ravencoin, Aleo). In no case did a GPU lane recover its peak income after the exit. + +## 4. Verdict table + +| # | Lesson | Evidence (chain, year) | What Igneum does today | Gap | What the mission should add or change | +|---|---|---|---|---|---| +| 1 | A compute-bound hash goes to a chip in 16 to 37 months, and the first chip is private | Litecoin 2014, Zcash 2018, Nervos 2020, Kaspa 2023, Alephium 2024 | Random-program hash, 256 MB dataset, latency shadow, era draws; chip model 2.1x at class v4 (Horizon item 4) | Small | Decide the N ladder at genesis and publish the chip model with every era draw; nothing else | +| 2 | Secret hardware or fleets show up as an unexplained hashrate step in the first weeks | Nervos 2020 (10x in 16 days), Iron Fish 2023, Kaspa 2023 | 90-day ramp from 10 percent; correlated-group detector and `security_alert` (Horizon rank 16) | Small | A public launch-week hash-origin report (key counts, pool shares, fleet shares) from the observer, daily for the first 90 days | +| 3 | Hash forks by hand lose miners and add bugs; the client is the next failure | Monero 2018 to 2019 (85 percent gone per fork), Vertcoin 2018 to 2019, Ravencoin Aug 2026 (header flaw) | No scheduled human fork; era draws from chain state; 95 percent signalling with a floor; Devnet 2 gate | Large on the client | The second independent client is the item; until then a fuzz gate on header and PoW validation paths equal to the sync-request fuzz (Horizon rank 9) | +| 4 | Income cliffs empty a chain in days; miners follow income with no loyalty | Ethereum Sep 2022 (94 percent of income gone), ETC -48 percent in four days, Aleo Q4 2024 | Monthly glide, no halving day, 1 percent tail (tail-emission.md) | Small on schedule, large on price | Publish per-tier income at three prices (USD 0.005, 0.02, 0.10) in the litepaper before the testnet, per the consequences rule; nothing in protocol | +| 5 | Premine and insider allocation drive GPU miners out faster than any chip | Aleo 2024, Pyrin 2023 | No premine, no dev fund, no fee to any team | None | Nothing | +| 6 | A GPU chain is rentable; rented hash reorganised three of them for USD 70 k to USD 18 M | Bitcoin Gold 2018 and 2020, Vertcoin 2018 and 2019, Musicoin 2019 | Miner-only finality on 30 days of blocks; 20 days of 100 percent hash to reach 2/3 (CLAUDE.md) | Small after day 20, large before | Weight-gated deep fork choice (Horizon rank 4) covers the first 20 days; ship it before mainnet, not after | +| 7 | A coin with no market dies within a year whatever the hash does | Musicoin 2019, Akroma 2019, TurtleCoin 2023, Grin (USD 16 k daily volume), Nexa | Proving sold in dollars, settled in IGN (litepaper); Taiko named as first customer | Large until a customer pays | A signed proving customer before mainnet is a launch gate, with the same weight as the Devnet 2 gate; decouple the job price from `f_p` (Horizon rank 7) so the first job can clear | +| 8 | Useful-work projects drop the miner the day the work does not pay | Dynex 2024, Flux 2025, Clore 2025, Qubic 2025 to 2026 | The lottery pays 80 percent of every block whatever the proving market does; proving is the second income, never the only one | None by design | Write the sentence into the litepaper: "A block pays its miner whether or not anyone buys a proof that day" | +| 9 | Random-program hashes keep GPUs for five years and more, and still pay under a dollar a card | Ravencoin 2020 to 2026, Firo, Conflux, Iron Fish | The hash is Igneum's strongest answer | None on the hash | Stop presenting the hash as the reason to mine; present income, fairness and the second income (section 2's three wants) first | + +## 5. Headline findings for the coordinator + +1. Of the 31 rows (33 chains) that paid GPU miners since 2011, 8 lost the GPU lane to a chip, 7 closed it by their own choice (Dogecoin, Ethereum, Monero, Grin, Flux, Clore, Qubic), 10 died or went dormant on price, rental attacks or abandonment, and the 6 still GPU-only (Ravencoin, Ergo, Firo, Conflux, Iron Fish, Beam) pay USD 0.22 to 0.71 a day per RTX 3080 before power, so the hash keeps the miner and not the income. +2. In 20 miner posts and launch texts read, 10 asked for hardware that keeps its value, 6 for income above electricity without a cliff and 4 for a fair supply; Igneum answers the fair supply in full, the hardware in part (a 2.1x chip model with the N ladder still owed), and the income only on schedule, since every GPU exit in the record except two came from price. +3. The earnings curve has one shape across Ethereum, Kaspa, Ergo, Ravencoin and Aleo: income halves within 60 to 120 days of the peak, falls under USD 0.10 per kWh within 6 to 18 months, and 50 to 100 percent of GPU hashrate leaves inside 90 days of that, so the launch plan needs a signed proving customer and published per-tier income at three prices before the first miner buys a card. + +## 6. Sources (all accessed 7 October 2026 unless noted) + +Project and pool sources +- Zcash forum, "Let's talk about ASIC mining", Feb 2018: https://forum.zcashcommunity.com/t/lets-talk-about-asic-mining/27353 +- Grin forum, "Proof of work update", 27 Aug 2018: https://forum.grin.mw/t/proof-of-work-update/713 +- 2Miners, Nervos hashrate and ASICs, 21 Mar 2020: https://2miners.com/blog/nervos-ckb-network-hashrate-increased-asics-are-the-cause/ +- 2Miners, Akroma and Musicoin delisting, 31 Jul 2019: https://2miners.com/blog/akroma-and-musicoin-delisting/ +- 2Miners, End of Ethereum mining, 30 Aug 2022: https://2miners.com/blog/end-of-the-ethereum-mining-when-what-to-mine-next-with-gpu-transition-to-pos-explained/ +- 2Miners, Confessions of a Miner 2, 12 Sep 2022: https://2miners.com/blog/confessions-of-a-miner-2-is-this-the-end-of-gpu-mining/ +- 2Miners, How to mine Kaspa with ASIC and GPU, 14 Apr 2023: https://2miners.com/blog/how-to-mine-kaspa-with-asic-and-gpu-settings-extra-rewards-dual-mining/ +- 2Miners, July 2023 report (Nexa, Kaspa KS0 port): https://2miners.com/blog/july-2023-work-progress-report-new-coin-nexa-kaspa-geo-servers/ +- 2Miners, KawPoW fork, May 2020: https://2miners.com/blog/kawpow-new-ravencoin-mining-algorithm/ +- Hiveon, PoW to PoS notes, 24 Aug 2022: https://hiveon.com/news/the-pow-and-pos-transition-important-notes/ +- Hiveon, 2022 review (16 percent ETC, 7 percent RVN): https://hiveon.com/news/reflection-and-forecast-reviewing-the-events-of-2022-and-anticipating-the-year-ahead/ +- VoskCoinTalk, Antminer K5 impressions, 9 Apr 2020: https://voskcointalk.com/t/initial-impressions-of-the-bitmain-antminer-k5-nervos-ckb-eaglesong-asic-miner-mining-22-a-day/172 +- Iron Fish, FishHash audit and the reason for the switch, 14 May 2024: https://ironfish.network/learn/blog/2024-05-14-fish-hash-audit +- Iron Fish, hard fork 1 activation, 2 Apr 2024: https://ironfish.network/learn/blog/2024-02-26-mainnet-hardfork +- Karlsen README: https://github.com/karlsen-network/karlsend +- hashrate.no, Karlsen and Pyrin algorithm change, 13 Sep 2024: https://www.hashrate.no/c/Algorithm_change_for_Karlsen_and_Pyrin +- hashrate.no, RTX 3080 today (top coins and USD per day): https://hashrate.no/gpus/3080 +- hashrate.no, Kaspa network (347 PH/s): https://www.hashrate.no/coins/KAS +- hashrate.no, Aleo pools (f2pool 28.9 percent): https://www.hashrate.no/coins/ALEO/pools +- RunOnFlux, Proof of Useful Work v2, 23 Oct 2025: https://runonflux.com/forking-flux-proof-of-useful-work-v2/ +- Clore changelog (PoW end, Dec 2025): https://clore.ai/changelog +- Clore blog, GPU mining is dead, 10 Feb 2026: https://blog.clore.ai/gpu-mining-is-dead-gpu-hosting-is-the-future-heres-how-to-earn-500month/ +- Qubic blog, mining evolution, 30 Jun 2025: https://qubic.org/blog-detail/qubic-mining-evolution-from-cpu-roots-to-gpu-dominance-and-back-again +- Qubic blog, Dogecoin mining on Qubic: https://qubic.org/blog-detail/qubic-dogecoin-mining-how-it-works +- TurtleCoin v2 FAQ (halt at block 5,500,000, 15 Mar 2023): https://hackmd.io/@iburnmycd/rJzyWD3-_ +- Callisto history (2024 collapse): https://www.callisto-pirl.com/history +- bitcointalk, Kaspa ANN: https://bitcointalk.org/index.php?topic=5373286.0 (403 on fetch; title and snippet via search) +- bitcointalk, "Kaspa asics": https://bitcointalk.org/index.php?topic=5449022.0 (snippet only) +- bitcointalk, Pyrin ANN: https://bitcointalk.org/index.php?topic=5476198.0 (snippet only) +- bitcointalk, Karlsen ANN: https://bitcointalk.org/index.php?topic=5475216.0 (snippet only) +- bitcointalk, "Why most premined coins will eventually fail": https://bitcointalk.org/index.php?topic=5457833.0 (title only) +- asicminervalue, Antminer KS7: https://www.asicminervalue.com/miners/bitmain/antminer-ks7-40th +- asicminervalue, Goldshell E-AL1M (negative at USD 0.10): https://www.asicminervalue.com/miners/goldshell/e-al1m +- asicminervalue, Ethereum Classic: https://www.asicminervalue.com/coins/etc-ethereum-classic +- minerstat, Grin: https://minerstat.com/coin/grin_cuckatoo32 +- WhatToMine, Ravencoin on RTX 3080 LHR: https://whattomine.com/coins/234-rvn-kawpow/gpus/63-nvidia-geforce-rtx-3080-lhr +- Binance Research, merged mining case study: https://www.binance.com/en/research/analysis/merged-mining +- litecoin.watch, scrypt history: https://litecoin.watch/articles/understanding-the-scrypt-mining-algorithm + +Press and papers +- CoinDesk, ETC and RVN hashrate after the Merge, 15 Sep 2022: https://www.coindesk.com/tech/2022/09/15/ethereum-classic-and-ravencoins-hashrate-nearly-doubles-after-merge +- AMBCrypto, ETC post-Merge high wearing off, 19 Sep 2022: https://ambcrypto.com/why-ethereum-classics-etc-post-merge-high-is-wearing-off/ +- crypto.news, ETC hashrate +280 percent: https://crypto.news/ethereum-classic-hashrate-jumped-280-post-merge/ +- Decrypt, ETC, RVN and ERG hashrate soar, Sep 2022: https://decrypt.co/109803/ethereum-classic-ravencoin-ergo-hash-rate-soar-post-merge +- The Block, what is left for GPU miners, 12 Sep 2022: https://www.theblock.co/news/ecosystems/2022-09-12-whats-left-for-ethereum-gpu-miners-after-the-merge-168380 +- Tom's Hardware, GPU mining unprofitable after the Merge (900 TH/s, about 20 million GPUs): https://www.tomshardware.com/news/gpu-mining-is-now-unprofitable +- Wccftech (Minerstat figures, RTX 3080 USD 6.35 to 9.15 a day, early 2021): https://wccftech.com/rgb-lit-bitcoin-mining-rig-78-geforce-rtx-3080-graphics-cards-comes-operational/ +- FXStreet, Ethereum miners in the red (USD 0.233 per MH per day in Jan 2018), 29 Mar 2018: https://www.fxstreet.com/amp/cryptocurrencies/news/ethereum-price-analysis-eth-usd-eyes-40000-amid-cryptocurrency-sell-off-miners-are-deep-in-red-201803290719 +- MinerUpdate, CPU mining dominates Monero since RandomX, 30 Nov 2019: https://www.minerupdate.com/news/miner-insights/cpu-mining-dominates-monero-since-randomx-upgrade +- Bitcoin Magazine, Antminer Z9 mini, May 2018: https://bitcoinmagazine.com/business/bitmains-antminer-z9-mini-designed-mine-zcash-threatens-asic-resistance +- 2Miners, Zcash mining and profitability (1080 Ti at USD 8 in Jul 2017, USD 2.63 on 6 May 2018): https://2miners.com/blog/how-to-mine-zcash-zec-mining-and-profitability/ +- Medium (Blockwise), the end of GPU mining (Monero April 2018 fork halved hashrate): https://medium.com/blockwise/the-end-of-gpu-mining-a702921fc1e1 +- crypto.news, Ravencoin consensus flaw, 11 Aug 2026: https://crypto.news/ravencoin-falls-as-consensus-flaw-splits-network/ +- Decrypt, the long collapse of Bitcoin Gold: https://decrypt.co/47381/the-long-collapse-of-bitcoin-gold +- metalicjames gist, Bitcoin Gold Jan 2020 attack: https://gist.github.com/metalicjames/71321570a105940529e709651d0a9765 +- metalicjames gist, Vertcoin Dec 2018 attack: https://gist.github.com/metalicjames/f2acdb9ef448ec5298173b36c7c54133 +- news.bitcoin.com, Vertcoin second attack, Dec 2019: https://news.bitcoin.com/vertcoin-network-sabotaged-by-another-51-attack/ +- Binance Square, BTG delisting 1 Sep 2024: https://www.binance.com/en/square/post/12128321695753 +- AiCoin (PANews), Aleo mainnet, miners cry foul, Sep 2024: https://www.aicoin.com/en/article/419859 +- Aleo, mainnet announcement, 18 Sep 2024: https://aleo.org/post/announcing-aleo-mainnet/ +- The Block, Monero reorg fears after Qubic's 51 percent claim, 12 Aug 2025: https://www.theblock.co/post/366535/monero-faces-chain-reorganization-fears-after-qubic-says-it-controls-51-of-hashrate +- Lee and Kim, Inside Qubic's selfish mining campaign on Monero, arXiv 2512.01437, AFT 2026: https://arxiv.org/abs/2512.01437 +- Decrypt, Qubic mining Dogecoin, Apr 2026: https://decrypt.co/363018/qubic-the-network-that-captured-51-of-monero-is-now-mining-dogecoin-on-its-ai-compute-infrastructure-live +- CoinGecko, Dynex (99.9 percent below ATH): https://www.coingecko.com/en/coins/dynex +- Medium (crypto-blog), Dynex the most GPU mined coin, Oct 2023: https://medium.com/crypto-blog/dynex-dnx-seems-to-be-the-most-gpu-mined-coin-at-the-moment-cdf7d30c433a +- KuCoin, ETHW price history: https://www.kucoin.com/price/ETHW +- Kryptex, IceRiver KS series: https://pool.kryptex.com/articles/iceriver-ks0-ks1-ks2-ks3-ks3l-en +- Medium (VoskCoin), Was Kaspa mining worth it (KS0 USD 25 a day, Jul 2023): https://medium.com/voskcoin/was-kaspa-mining-worth-it-ca3ac9ff7566 (403 on fetch; figures via search snippet) + +Internal +- `docs/analysis/asic-resistance-history.md` (5 Oct 2026) +- `docs/analysis/horizon-2026-10.md` section 1 and ranks 4, 7, 9, 10, 16 (6 to 7 Oct 2026) +- `docs/analysis/horizon/economy-and-utility.md` section 4.6 +- `docs/analysis/tail-emission.md`, `docs/analysis/vote-or-burn.md` + +Not reachable from this environment (recorded so the coordinator can fetch by hand): reddit.com (all subreddits), bitcointalk.org thread bodies, web.archive.org, the Springer paper "The PoW Landscape in the Aftermath of The Merge" (login wall), statista's Ethereum profitability series (paywall), bitinfocharts chart values (rendered client-side). diff --git a/docs/analysis/mission/reinvent.md b/docs/analysis/mission/reinvent.md new file mode 100644 index 00000000..ca148980 --- /dev/null +++ b/docs/analysis/mission/reinvent.md @@ -0,0 +1,446 @@ +# Mission lane 5: what can be reinvented. The miner's experience + +Date: 7 October 2026, UK time. Lane 5 of the last mission. Written in the mission worktree; this file is the only output. Nothing was built, measured, posted or started; the live devnet was not touched. + +the project lead's words that this lane holds: "revolutionise the mining itself"; "dopamine for GPU miners everywhere, a structure that makes the mining commodity fall in love with the project"; "the perfect gpu network that will be noticed as the revolution that everyone is waiting for". Bounds that this lane obeys: no premine, no dev fund, no treasury, no token sale, no airdrop, no referral paid in coins; every coin is mined under the rules that exist (the 80/20 split, the signing bonus of 8 of the 80 producer points, the proving pool); no stake; no device bounty; the three signalling thresholds (60, 90, 95); miners are the security always; gates, not dates; hours are agent hours. + +## 0. Progress + +| Time (UK) | State | +|---|---| +| 08:46 | Rules read: CLAUDE.md, polish.md sections 1, 3.1, 3.2, 3.4, 3.6, 3.7, 3.10, 4.5; litepaper miner sections; vote-or-burn section 5; tail-emission one page; horizon one page; ledger decisions 3, standing, 6 and 7 October; pool.md; miner-ui-3 and its audit; testnet-go; the dev fee; the Discord kit; the Reddit kit (branch reddit-kit); journey.json | +| 09:05 | Three research sub-lanes launched: Reddit post sample, chain histories, pool and install facts. The third refused by the concurrency limit; its topics done by hand with WebFetch. The session's WebSearch budget was already spent by other lanes, so every outside fact below comes from a fetched page or is labelled approximate | +| 08:52 | Igneum maths computed (scratch `mission-reinvent/igneum-maths.txt`, `tiers.txt`): solo block expectations per tier at 100 GH/s and 1 TH/s, the vote dust line, the signing bonus per day | +| 09:04 | Sections 3 to 8 drafted; 1.1 and 2 waiting on the sub-lanes | +| 09:10 | Section 1.1 and headline 3 written from `reddit-sample.md` (105 posts, 69 with a room median) | +| 09:13 | Section 2 and the sources written from `chains.md` (seven chains, hashrates derived from explorer APIs at dated heights) | +| 09:15 | Done: 0 em dashes by grep, no placeholders, 446 lines; the three findings sent to the coordinator | + +## 1. The dopamine loop of a GPU miner, from data + +### 1.1 What the archives say + +Method (the sub-lane's file, scratch `mission-reinvent/reddit-sample.md`): 105 posts picked by hand from the top-of-all-time listings of r/EtherMining, r/gpumining, r/chia, r/ravencoin, r/MoneroMining, r/Monero, r/HeliumNetwork (2021 to 2022), r/kaspa and r/erg_miners (r/ErgoMining is an empty shell whose top post points to r/erg_miners), plus six bitcointalk "first block" posts from 2011 to 2017 through the ninjastic archive. Each post's score is the value Reddit served on 7 October 2026. The subreddit median for the post's year is estimated from three half-month samples of the Arctic Shift archive (approximate; the typical post in these rooms scores 1 to 4 points, so the ratios are large and describe how far the best joy posts rise above an ordinary post). 69 of the 105 rows have a ratio; r/MoneroMining and r/erg_miners have no archive sample. + +| Post type | Rows with a ratio | Median score | Median ratio to the room's typical post | Range | Best example (score, date, URL) | +|---|---|---|---|---|---| +| f. "My card paid for itself" (ROI, break-even) | 6 | 777 | 777x | 493x to 1,367x | solar panels paid for by mining, 1,367 points, 16 May 2021, https://www.reddit.com/r/gpumining/comments/ndduuu/ | +| g. The community meme | 11 | 710 | 739x | 81x to 2,054x | "New miners be like...", 2,054 points, 19 Apr 2021, https://www.reddit.com/r/EtherMining/comments/mu3jgh/ | +| c. The rig photo | 13 | 361 | 417x | 48x to 2,923x | "Rate my new build", 2,923 points, 3 Mar 2021, https://www.reddit.com/r/EtherMining/comments/lwpudz/ | +| d. The hashrate milestone | 7 | 324 | 409x | 95x to 672x | "What 1GH looks like", 672 points, 8 Apr 2021, https://www.reddit.com/r/EtherMining/comments/mmybn2/ | +| e. The profit screenshot, "X per day" | 7 | 234 | 234x | 48x to 593x | "I finally mined a full Ethereum today", 593 points, 21 Jul 2021, https://www.reddit.com/r/EtherMining/comments/ootl28/ | +| a. First block found solo | 8 (plus 6 bitcointalk rows with no score) | 233 | 119x | 46x to 762x | "Tried Solo Mining ETH as an Experiment, Ended up Hitting a Block", 762 points, 3 Jun 2021, https://www.reddit.com/r/EtherMining/comments/nr13be/ | +| h. "We did it", the network milestone (ATH, listing, hotspot count, halving) | 12 | 214 | 66x | 12x to 305x | Helium's first telecom deal, 305 points, 26 Oct 2021, https://www.reddit.com/r/HeliumNetwork/comments/qg9o6g/ | +| b. First payout | 5 | 173 | 56x | 43x to 478x | "I made my first bitcoin penny", 478 points, 8 Mar 2021, https://www.reddit.com/r/gpumining/comments/m0emml/ | +| all | 69 | 256 | 297x | 12x to 2,923x | | + +What the ranking says. The posts that rise highest are about the miner, not the network: the card that paid for itself (777x), the rig in a photo (417x), the personal hashrate milestone (409x). The network's own milestone, the thing a project would post, sits near the bottom (66x). The first solo block is the strongest single feeling in the quotes and a middling score (119x), because it is rare; the first payout is the lowest (56x), because on a pool it is routine. Chia's first-block posts are the exception that proves it: on a chain where the first win took weeks of plotting, "It finally happened! I never thought this day would come" scored 615 (19 May 2021, https://www.reddit.com/r/chia/comments/ngevxy/), 308x its room's median. The Monero room shows the same feeling at every size of CPU: "After 271 days and 101 Billion Hashes, I Finally Mined my First Monero" (128 points, 20 Nov 2020, https://www.reddit.com/r/MoneroMining/comments/jxxwzo/). + +Quotes (verbatim, with the sub-lane's dates and URLs; all accessed 7 October 2026): + +| Quote | Where | Date | +|---|---|---| +| "GUYZ! I DID IT! I FINALLY WON!!" | r/chia title, https://www.reddit.com/r/chia/comments/myaizh/ | 25 Apr 2021 | +| "cries in 17TiB with 0 xch" | top comment on the same post | 25 Apr 2021 | +| "380 MH/s, about 24 hours total time mining. Very, very lucky." | r/ravencoin, https://www.reddit.com/r/ravencoin/comments/pnfl4y/ | 13 Sep 2021 | +| "That's crazy. Now all of us pool miners are going to think hmm." | r/EtherMining, https://www.reddit.com/r/EtherMining/comments/nr13be/ | 3 Jun 2021 | +| "1 GH/s and disappointed parents achieved!" | r/gpumining title, https://www.reddit.com/r/gpumining/comments/okexp4/ | 14 Jul 2021 | +| "Love solo mining its the best." | r/MoneroMining, https://www.reddit.com/r/MoneroMining/comments/1uexakh/ | 25 Jun 2026 | +| "I just solo mined my first block ever! :3 Feels good." | bitcointalk, https://bitcointalk.org/index.php?topic=619210.msg6866375#msg6866375 | 22 May 2014 | +| "Mind blown." | bitcointalk, first reply to "just found my first block", https://bitcointalk.org/index.php?topic=338903.0 | 19 Nov 2013 | + +Consequence for Igneum, by surface: the shareable thing must be the miner's own object (the block card with the card's name on it, the rig's row on the census, the weight rank), never the project's milestone; the ROI post cannot exist without a price, so its stand-in at the testnet is the line "N IGN per kWh" and the days-mined ring; and the solo first block must stay reachable for the common tier, which is the reason the Poisson line and the pool switch sit on the same screen (section 3.2). + +### 1.2 Time to the first hit on each chain + +| Chain, year | First hit | Measured or estimated time from install | Source | +|---|---|---|---| +| Ethereum 2017, pool (Ethermine, Nanopool) | first share accepted, worker on the dashboard | share within seconds of the first job; worker visible in 1 to 10 minutes; first payout at 0.05 ETH took one GTX 1070 about 2 to 3 weeks in mid 2017 (approximate) | approximate, from memory of the pool pages | +| Ethereum 2017, solo | first block | a 30 MH/s card against 60 TH/s: one block in about 2 million blocks, 1 year or more; nobody did it (approximate) | approximate | +| Kaspa, launch day 8 Nov 2021, solo | first block | the network was 3.4 MH/s on 8 Nov 2021 (derived from the header bits, `chains.md`), so one 2021 card found blocks within minutes; at 2.86 TH/s six months later the same card needed a pool | https://api.kaspa.org/blocks-from-bluescore?blueScore=100000 (7 Oct 2026) | +| Kaspa 2022, pool (2miners) | first share; payout at 50 KAS every 2 hours | share in seconds; payout the same day for a 1 GH/s card in 2022 (approximate); 2miners: "Payouts are processed automatically every 2 hours", minimum 50 KAS | https://2miners.com/faq and https://kas.2miners.com/ (7 Oct 2026) | +| Monero 2019, p2pool (from 2021) | a share in the PPLNS window, paid at the next pool block | p2pool: "It can take several days to a week to find a share if your hashrate is low"; min payout 0.00027 XMR | https://p2pool.io/ (7 Oct 2026) | +| Chia 2021 | the first plot finished (the hit was the plot, not the coin) | 6 to 12 hours a plot on a consumer SSD; the expected solo win on 10 TB at 5 EiB netspace was months (approximate) | r/chia posts of May 2021 (section 1.1); approximate | +| Helium 2021 | the hotspot on the map, the first beacon, "HNT per day" in the app | hours after power-on, days to weeks of waiting for the device itself (the r/HeliumNetwork top post of 2021 is a photo of a miner six months after ordering, section 1.1) | section 1.1 | +| Ravencoin 2018, solo | first block, 5,000 RVN | on launch day any card found blocks in minutes (approximate) | approximate | +| Igneum devnet, 2026 | first accepted block, shown in the app's event feed | an Apple silicon laptop through the DMG: first block "within the first minutes", 33 accepted blocks in 7 minutes; an RTX 5090 through the Windows installer: 34 accepted blocks in the first minute once the clock was right | `docs/bench-log.md` 4 October 2026 (the first outside machine; the three-card rig) | + +### 1.3 The loop + +| Stage | What it is for a miner | Evidence | +|---|---|---| +| Trigger | a number moved: a block, a payout, a hashrate tick, a chart on the explorer, a post in the feed | the post types that score highest are all "a number moved and here is the screenshot" (section 1.1) | +| Action | open the app, the pool page, the explorer, the Discord; refresh | the daily ritual on every chain in section 2 | +| Variable reward | blocks are a Poisson draw; the payout varies; the post's upvotes vary; luck is the word every pool shows | 2miners shows "luck 441%" and "last block 2 minutes ago" on the pool's front page (https://kas.2miners.com/, 7 Oct 2026) | +| Investment | a rig built, plots made, a key aged, a reputation in the room, a name on a board | Chia's plots, Helium's named hotspot on the map, the EtherMining rig-photo post (section 1.1) | + +Igneum has one investment no other chain has: the vote key's 30-day window. A key that mined for 30 days weighs more than the same hashrate that appeared yesterday, and that weight signs finality. That is a level system written into consensus, and section 3.7 builds the ladder on it. + +### 1.4 The five moments on Igneum, and the time to each today + +Computed at 1 block a second, the producer share of 80 points, 100 IGN a block at full rate. The network size is the variable: the first 1,000 miners at the measured median card (about 25 MH/s, section 3.8) are about 25 GH/s; 100 GH/s is the litepaper's example; 1 TH/s is where the loop breaks for solo cards. Full tables per tier: section 3.8 and scratch `tiers.txt`. + +| Moment | Solo, 100 MH/s on 100 GH/s | Solo, 17 MH/s (8 GB) on 100 GH/s | Pool member, any card | Where it is shown today | Where it should be shown | +|---|---|---|---|---|---| +| 1. First share or first block | first block: expected gap 16.7 min, 97 percent within the first hour | 1.6 h expected, 46 percent within the first hour | first share: vardiff starts at one share per 10 s and the first correction is sized from the measured rate (`pool.md` section 2), so under a minute after the first job; before that the node sync and the dataset build (measured: the devnet laptop's first block "within the first minutes") | the event feed and the blocks strip (`app.js:1052-1127`) | the block card of section 3.3 | +| 2. First payout | the coinbase of the first block, credited by the execution layer when the block is blue; so the payout is the block, seconds later | the same | PPLNS credit on blue confirmation; a payout round every 60 s (`pool/src/config.rs:61`), minimum 1 IGN; an 8 GB member at 100 GH/s earns 1 IGN in about 73 s, so the first payout lands inside two minutes of the first share | Earnings reads "£0.00 earned" and never shows mined IGN (Q18) | Earnings as section 3.4 | +| 3. First proof shard paid | shards are assigned by lot to eight provers for ten seconds; 388 shards and 446.13 IGN paid on 5 October (the Discord kit's start-here text); on a 24 GB NVIDIA card today, 12 GB cards with the patched prover measured not shipped | not available on 8 GB today (core-only proving measured, `prover-tiers-real-cards.md` rows 4060) | proving income never passes through the pool (C6) | Prove tab state line "0 proven · 0 paid" | "your card proved shard N of block M" as a card, section 3.7 | +| 4. First vote (the key above dust, 100 blocks in the 30-day window) | 1.2 days | 6.8 days | the member's own blocks carry its key (`pool.md` section 2, Votes), so the same days as solo for the same card; a member without a node has no vote (spec 09 9.7) | nothing: the app never says whether the key votes | "your key has a vote" card, the ladder rung 1 | +| 5. First signature in a certified checkpoint, then the full window | the first checkpoint after the key enters the table (one checkpoint is 30 s; a young key counts as present); the full window at day 30 | the same; full window at day 30 | the same | nothing | "your signature is in checkpoint K" and "30 of 30 days" | + +The consequence of the dust line, per tier (the standing rule of 5 October): at 100 GH/s every tier reaches a vote inside a week; at 1 TH/s a single 8 GB card finds 44 blocks in 30 days and never reaches 100, so it never votes, and the pool does not help because weight follows the member's own found blocks. The 12 GB RTX 4070 reaches 65, also under. The RTX 5090 reaches 255. So past about 500 GH/s the "your key has a vote" rung is out of reach for the cards most of the first 1,000 miners own, and the X5 gate (1,000 independent keys above dust) gets harder as the network grows. This lane does not touch the constant; it hands the finality lane the question in section 8 and keeps the ladder's first rungs (first block, first payout, first shard, 30 days mined) reachable for every tier at any network size. + +## 2. The product structures that made miners fall in love + +Method (the sub-lane's file, scratch `mission-reinvent/chains.md`): hashrates derived from block difficulty at dated heights through each chain's public explorer API (Ergo, Monero, Ravencoin, Kaspa) or Etherscan's daily CSV (Ethereum); Helium and Chia from their own HIPs, blog posts and release notes; prices from CoinGecko. Every URL opened on 7 October 2026. "Approximate" marks a figure from memory. Hash units differ across forks and are not compared across them. + +### 2.1 The hook, the ritual, the proof, the ladder, the story + +| Chain | Hook | Daily ritual | Social-proof surface | Status ladder | The story a miner told | +|---|---|---|---|---|---| +| Helium 2019 to 2021 | a USD 500 box on the windowsill mines by giving radio coverage | the app or explorer.helium.com: the hotspot's 24-hour HNT, witnesses, "relayed" | the explorer hex map; every hotspot a dot with a three-word name; "the map was the product" | none formal: "first in my city" on the map, maker badges in Discord, validators from 2021 (approximate) | HIP 10's own example: a hotspot "which has earned approximately $21,000 worth of HNT by purchasing $145 worth of DC" (https://github.com/helium/HIP/blob/main/0010-usage-based-data-transfer-rewards.md) | +| Chia 2021 | farm on drives you already own; "green Bitcoin" from the BitTorrent inventor | the GUI's netspace and "estimated time to win"; plots finishing; then the pool page | the netspace chart (chiaexplorer, xchscan); the pool leaderboard | plot count and TiB; "OG plots" against portable plots (approximate beyond that) | "It finally happened! I never thought this day would come" (section 1.1); the other side: "cries in 17TiB with 0 xch" | +| Ethereum 2017 | the gaming PC prints money while you sleep | WhatToMine with your card list, the pool's unpaid balance and graph, the overclock | the pool's worker list and "estimated earnings"; YouTube rig builds; the GPU price chart | rig size (6, 8, 12 cards), hashrate, the "paid off" post (approximate) | "In Feb this subreddit told me it was too late and I'd never ROI" (893 points, 1 Aug 2021, https://www.reddit.com/r/EtherMining/comments/ovvaah/) | +| Kaspa 2022 | "No premine. No hidden allocation. Fair launch." (https://kaspa.org/) | miningpoolstats.stream, the pool dashboard, Discord #mining | the miningpoolstats hashrate chart and pool count | Discord roles for early miners and pool operators (not verified, approximate) | "I mined six figures of KAS on two GPUs at a tenth of a cent" (approximate, the room's tone) | +| Monero RandomX 2019 | any CPU, even a laptop, mines again; RandomX "optimized for CPUs" (https://www.getmonero.org/resources/moneropedia/randomx.html) | the xmrig console, the pool page, the electricity maths | the RandomX README benchmark table (i9-9900K 5,770 H/s, Ryzen 7 1700 4,100, i3-3220 510, Raspberry Pi 3 20; https://github.com/tevador/RandomX) and the pool's miner count | none formal; hashes per watt bragging | "After 271 days and 101 Billion Hashes, I Finally Mined my First Monero" (section 1.1) | +| Ravencoin 2018 | Bitcoin's fair launch replayed for GPUs; "no private, public, founder, or developer allocation" (https://ravencoin.org/assets/documents/Ravencoin.pdf) | the pool dashboard, the WhatToMine line, Discord #mining, "is that hashrate jump an FPGA?" | the pool ranking and the explorer difficulty chart | none formal | "380 MH/s, about 24 hours total time mining. Very, very lucky." (section 1.1) | +| Ergo 2019 | the ETH miners' second home: GPU-only Autolykos, a 2 GB table, "hardcoded no-premine proof" (https://github.com/ergoplatform/ergo/releases/tag/v3.0.0) | the pool dashboard, the explorer, WhatToMine, Discord #mining | the hashrate chart and the pool list | none formal | "My first payout. All mined with my humble GTX 1060 at 50MH/s." (section 1.1) | + +What the seven have in common: the daily ritual is a number read off a page the project does not control (a pool, miningpoolstats, WhatToMine); the social proof is a chart or a map; the ladder is informal everywhere. Helium is the one chain whose product was the proof surface itself (the map), and it is the one whose miners posted photos of the device six months after ordering (section 1.1). No chain had a ladder the chain itself computed. + +### 2.2 The numbers at 3, 6 and 12 months + +| Chain, launch | 3 months | 6 months | 12 months | Peak | Source | +|---|---|---|---|---|---| +| Helium, 1 Aug 2019 | about 1,500 hotspots (approximate) | about 3,000 (approximate) | about 7,500 (approximate) | "500,000+ Hotspots" (HIP 54, 2 Feb 2022); "close to 1 million" (HIP 70, 30 Aug 2022) | https://raw.githubusercontent.com/helium/HIP/main/0054-h3dex-targeting.md ; https://github.com/helium/HIP/blob/main/0070-scaling-helium.md | +| Chia, 19 Mar 2021 (transactions 3 May) | "over 30 exabytes" (7 Jul 2021) from "about 100 pebibytes" at launch | 32 EiB (3 Aug 2021) | 28 EiB (19 Mar 2022); "over 400,000 nodes" | about 35 to 40 EiB late 2021 (approximate); 17.3 EiB on 7 Oct 2026 | https://www.chia.net/2021/07/07/official-pooling-protocol-launched/ ; https://www.chia.net/2022/03/19/chia-mainnet-year-one/ ; https://alltheblocks.net/chia | +| Ethereum GPU, from 1 Jan 2017 (6.0 TH/s) | 17.3 TH/s (1 Apr 2017) | 37.2 TH/s (1 Jun 2017) | 159.4 TH/s (1 Jan 2018) | 1,126.7 TH/s (13 May 2022); 871.0 TH/s on 14 Sep 2022, zero from 16 Sep | https://etherscan.io/chart/hashrate?output=csv | +| Kaspa, 7 Nov 2021 (3.4 MH/s on 8 Nov) | about 1 TH/s (approximate; 0.3 TH/s on 19 Dec 2021) | 2.86 TH/s (28 May 2022) | 431.8 TH/s (26 Nov 2022) | 210.7 PH/s (12 Apr 2024, derived); about 344 PH/s on 7 Oct 2026 | https://api.kaspa.org/blocks-from-bluescore?blueScore=15800001&includeTransactions=false ; https://api.kaspa.org/info/hashrate?stringOnly=false | +| Monero RandomX, 30 Nov 2019 (307 MH/s CryptoNightR before, 686 MH/s RandomX on 1 Dec) | 1,338 MH/s (29 Feb 2020) | 1,372 MH/s (30 May 2020) | 1,695 MH/s (29 Nov 2020) | 7.54 GH/s (16 Jan 2026) | https://xmr-node.cakewallet.com:18081/json_rpc (get_block_header_by_height) ; https://www.coinwarz.com/mining/monero/hashrate-chart | +| Ravencoin, 3 Jan 2018 | 0.89 TH/s (19 Mar 2018) | 1.31 TH/s (17 Jun 2018) | 3.51 TH/s (7 Jan 2019) | X16R 22.5 TH/s (29 Sep 2019); KAWPOW 18.76 TH/s (20 Sep 2022); 0.61 TH/s on 7 Oct 2026 | https://blockbook.ravencoin.org/api/v2/block/130000 (and later heights) ; https://rvn.2miners.com/api/stats | +| Ergo, 1 Jul 2019 | 1.06 TH/s (1 Oct 2019) | 1.29 TH/s (31 Dec 2019) | 7.89 TH/s (30 Jun 2020) | 180.6 TH/s (17 Sep 2022); 0.47 TH/s on 7 Oct 2026 | https://api.ergoplatform.com/api/v1/blocks?limit=1&offset=66000&sortBy=height&sortDirection=asc (and other offsets) ; https://erg.2miners.com/api/stats | + +Discord member counts were not found in any source opened for any of the seven; the one community-size number in the sample is r/erg_miners passing 5,000 subscribers on 6 Jan 2022 (section 1.1, row 104). + +What the first year looked like from a card: Kaspa went from 3.4 MH/s on its first day to 2.86 TH/s at six months, a million-fold, and then 150x more in the next six (the post-Merge fleet); Chia's netspace rose about 300x in under four months, so a fixed farm's share fell 300x; Ethereum rose 26x across 2017. A miner who joined on day one of any of them watched their share fall by two or three orders of magnitude inside a year. Igneum's 30-day window gives that miner something the hashrate curve took away: weight that the newcomers cannot buy for 30 days. + +### 2.3 The failure modes + +| Chain | What broke | The number | Source | +|---|---|---|---| +| Helium, 2022 | dilution then gaming then a pivot: emission halved to 2,500,000 HNT a month (1 Aug 2021, HIP 20) while hotspots went past "close to 1 million", so under 0.1 HNT a day per hotspot against about 5 to 10 in 2020 (approximate); a denylist run by the company from about 14 Jan 2022 whose method is not published; subDAO tokens with a "50B pre-mine" of MOBILE (HIP 53); the move to Solana (April 2023); the SEC complaint of 17 Jan 2025 over claims about Lime, Nestlé and Salesforce, settled for USD 200,000 | HNT ATH USD 54.88 to ATL 0.1132; "almost 38% of all HNT is staked in Validators" (HIP 70) | https://raw.githubusercontent.com/helium/HIP/main/0020-hnt-max-supply.md ; https://github.com/helium/denylist ; https://raw.githubusercontent.com/helium/HIP/main/0053-mobile-dao.md ; https://www.sec.gov/enforcement-litigation/litigation-releases/lr-26229 ; https://www.coingecko.com/en/coins/helium | +| Chia, 2021 | the SSD burn (about 1.3 TiB of writes per plot, Chia's own figure; consumer drives killed in weeks, the press figure approximate), the pool protocol eight months after the pools promise (11 Nov 2020 to 8 Jul 2021) with "OG plots" shut out of it, a closed pool at a third of netspace, 300x dilution in four months, then consolidation and a price fall of 99.9 percent | hpool "hovering at around 33% of netspace" (15 Jun 2021); XCH ATH USD 1,645.12 to ATL 1.14 | https://www.chia.net/2021/05/24/chia-and-ssd-endurance/ ; https://www.chia.net/2021/06/15/common-misconceptions-vol-1/ ; https://github.com/Chia-Network/chia-blockchain/releases/tag/1.2.0 ; https://www.coingecko.com/en/coins/chia | +| Ethereum, 15 Sep 2022 | the Merge switched 871 TH/s off in a day; ETC absorbed at most 236.6 TH/s; Ergo rose 11x in 48 hours (16.1 to 180.6 TH/s) and Ravencoin 7x (2.70 to 18.76 TH/s), so every existing Ergo rig lost about 91 percent of its share inside a week; both fell back by Christmas (32.6 and 9.19 TH/s) | the bagpipes post: "Powering down last ETH mining rig the only proper way", 2,277 points, 15 Sep 2022, https://reddit.com/r/EtherMining/comments/xek7wq | https://etherscan.io/chart/hashrate?output=csv ; https://bitinfocharts.com/comparison/hashrate-eth-etc.html ; https://decrypt.co/109713/ethereum-classic-hashrate-soars-merge-nears-miners | +| Kaspa, 2023 | the ASIC turn: IceRiver KS0 to KS3 listed for "Sep 2023", Bitmain KS3 "Oct 2023"; network hashrate 2.67 PH/s (28 Jul 2023) to 115.7 PH/s (19 Dec 2023), 43x in under five months; one KS1 at 1 TH/s equals about 2,000 RTX 3070-class cards (approximate), so the GPU share went to a rounding error | 43x | https://www.asicminervalue.com/miners/iceriver ; https://api.kaspa.org/blocks-from-bluescore (derived) | +| Monero, 2019 onward | nothing broke on chain; two slow failures: botnet mining ("Monero's popularity among malware-based non-consensual miners", Wikipedia), and a 4x hashrate rise to the 2026 peak against the 0.6 XMR tail | 686 MH/s (1 Dec 2019) to 7.54 GH/s (16 Jan 2026) | https://en.wikipedia.org/wiki/Monero ; https://www.coinwarz.com/mining/monero/hashrate-chart | +| Ravencoin, 2019 to 2020, then 2022 | the FPGA and ASIC surge: 10.0 to 22.5 TH/s between 22 Aug and 29 Sep 2019 with no price move; two algorithm forks (X16Rv2, 1 Oct 2019, "ASIC shmasic"; KAWPOW, May 2020, hashrate 29.4 to 3.39 TH/s overnight); then the economic break after the Merge, 18.76 TH/s to 0.61 TH/s today, and a "consensus flaw in KAWPOW header validation" rescued by a pool in Aug 2026 | hashrate down 97 percent from the 2022 peak; RVN down 99.2 percent | https://github.com/RavenProject/Ravencoin/releases?page=2 ; https://github.com/RavenProject/Ravencoin/releases/tag/v4.1.0 ; https://2miners.com/blog/august-2026-work-progress-ravencoin-chain-rescue-pearl-hard-fork-and-kaspa-reward-cut/ | +| Ergo, 2022 | the overflow pipe: 16.1 TH/s (3 Sep 2022) to 180.6 (17 Sep), back to 36.8 by 3 Oct; 0.47 TH/s today, under 3 percent of the peak | 11x up and 80 percent down in a month | https://api.ergoplatform.com/api/v1/blocks (derived) ; https://erg.2miners.com/api/stats | + +What Igneum takes from each: from Helium, a proof surface the miner owns (the map) and a warning that a company-run denylist with an unpublished method ends the love (section 6, "a number a company server has to be trusted for"); from Chia, that the ritual (plotting) must not destroy the hardware, and that a pool that arrives eight months late with the early miners shut out is remembered (pool-0 is at the go, section 3.5); from Ethereum, that the shareable post is the rig and the ROI, and that a chain can end mining by decree (Igneum's miners are the security always, so there is no Merge to decree); from Kaspa, that a fair launch holds a community for two years and an ASIC takes it in five months (the hourly program and the census, 4.4); from Monero, that "anyone's CPU" is a narrative that survives seven years when the hash keeps its promise; from Ravencoin, that two algorithm forks by human release are what Igneum's automatic schedule replaces; from Ergo, that a hashrate wave arriving from a dead chain dilutes the faithful 11x in two days, which is exactly what the 30-day weight window was built to keep from the vote. + +## 3. The miner's experience on Igneum, reinvented + +### 3.1 Install: the two warnings before the first screen + +What happens today (polish.md 3.10): Windows, SmartScreen "Windows protected your PC" (More info, Run anyway), per-user install, then a UAC prompt for the firewall rule 20 to 50 s in, on top of whatever screen is up. Mac, an ad hoc signature, Gatekeeper refuses, the user must find Privacy and Security, Open Anyway; the app strips its own quarantine on start. The Windows installer cannot be rebuilt tonight (Q80, GitHub billing). + +What the comparators do: SmartScreen warns on any file that is not "well known and downloaded frequently" and on any certificate without reputation; "If a URL, a file, an app, or a certificate has an established reputation, users don't see any warnings" (https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/, page dated 23 April 2026, read 7 Oct 2026). SSL.com's code-signing page says Microsoft "moved away from automatic instant reputation", so OV and EV build reputation through use (https://www.ssl.com/code-signing/, 7 Oct 2026). Apple: USD 99 a year, notarisation included (https://developer.apple.com/programs/, 7 Oct 2026); on macOS the unidentified-developer path is System Settings, Privacy and Security, Open Anyway (https://support.apple.com/en-us/102445, 7 Oct 2026). Certum sells an open-source code-signing certificate "from €49.00" (https://shop.certum.eu/open-source-code-signing-on-simplysign.html, 7 Oct 2026; out of stock on the day). Azure Trusted Signing: Basic tier 5,000 signatures a month, one certificate profile of each type; price not shown on the page (https://azure.microsoft.com/en-us/pricing/details/trusted-signing/, 7 Oct 2026; from memory about USD 10 a month, approximate). GPU miners trip antivirus even when signed: T-Rex's README says some engines detect signatures "similar to those that real viruses protected by the same packer have" (https://github.com/trexminer/T-Rex, 7 Oct 2026). + +| Step | Today | Proposal | Hours | Gate | +|---|---|---|---|---| +| Mac signature | ad hoc, quarantine strip | Developer ID plus notarisation and stapling in `build-dmg.sh`; the quarantine strip removed | 3 plus the project lead's USD 99 | a fresh macOS 26 machine opens the DMG's app with no Privacy and Security visit | +| Windows signature | none | Authenticode through Trusted Signing or an OV certificate, signed on the box as a job step; the sha256 and the signer's name on the download page (Q50, Q82) | 3 plus the project lead's purchase | a fresh Windows 11 machine runs the installer with no SmartScreen interstitial by the 1,000-download mark (reputation is use; before that the page shows the exact interstitial text and the two clicks) | +| Firewall prompt | UAC 20 to 50 s in, unexplained | the Cards screen names it and the step runs after `setup_done` (Q14) | 1 | the prompt never appears before a screen that says it will | +| Antivirus | nothing | a "What your antivirus may say" line on `/miner#get` with the engine names and the exact action, and the submission to Microsoft's SmartScreen review on every release (the Learn page's submission route) | 1 | the line is on the page; every release's binaries are submitted the day they ship | +| Time to the first share | not measured end to end on a fresh machine | measured on a fresh Windows 11 VM and a fresh Mac for every release by the Devnet 2 gate: download to first accepted share or block, with the clock, the sync and the dataset build as three timed steps | 2 | "first share within 10 minutes of download in 9 of 10 fresh Windows installs", published on `/evidence` | + +### 3.2 First run: what the first hour should feel like + +Today's three screens (Welcome, Cards, Address, the key sheet) are rated 7 to 8 of 10 by the UI 3 audit; the audit's own finding is that the one question a home miner has, "is this worth running", is not answered until the third screen, and the Cards row does not say what the card is expected to make although `site/miner-priors.json` knows the model (`miner-ui-3-audit.md` 2.1, 2.2). + +| Screen | Add | Hours | Gate | +|---|---|---|---| +| Cards | under each known model: "about 25 MH/s at 91 W; on today's network that is about N blocks a day" from the prior and the live network rate | 1 | the row shows a number for every model in the priors file | +| Cards | the tier sentence in plain words: "8 GB: mines; proves small shards", "24 GB: mines and proves" (from `prover-tiers-real-cards.md`) | 0.5 | every memory size has a sentence | +| Address | "Start mining" starts mining; the key sheet comes before the button (the audit: "the button lies once") | 1 | view test | +| Mine, first ten minutes | a "waiting for your first block" line with the live expectation: "a card like yours finds a block about every 1.6 hours on today's network; chance so far: 31 percent" (a Poisson line from the card's own rate and `/api/stats` network rate; the pool mode shows "first share in N s" instead) | 2 | the line is on screen from the first job until the first block, then is replaced by the block card | + +The Poisson line is the piece no miner app has. 2miners shows luck for the pool; nothing shows a solo miner's own running chance. It turns the dead first hour into a count-up, and it is honest: it says 46 percent for an 8 GB card at 100 GH/s, which is why the pool switch sits one line below it. + +### 3.3 The first block: the card, the sound, the link + +Today: an event line in the feed and the blocks strip. Nothing is shareable, nothing is kept. + +Proposal, the block card (Ember, Mine page, in place, no dialog): + +``` +Block 1,284,117 is yours. 12:27:53 UK +RTX 4070 · 25.0 MH/s · 0.025% of the network +80.00 IGN to 0xdd44…86E8 (72 producer points, 8 for signing) +Hash 9f3a…c21e [Open in the explorer] [Save the card] [Copy the link] +``` + +| Element | Rule | Hours | Gate | +|---|---|---|---| +| The card | shown on the first block of every key, then on every 100th, 1,000th and 10,000th, and on the first block of every new card; stays until dismissed; the rest are feed lines | 2 | view test on the four thresholds | +| Sound | off by default; one short tone on a block when on; honours reduced motion and the OS mute (`app.css` already honours reduced motion everywhere) | 0.5 | the tone never plays when the switch is off | +| Save the card | a 1200x630 PNG drawn locally from the same data (the rig-photo post without the rig; the dark scheme, the brand mark, the card name, the hash, the explorer link as a QR) | 2 | the PNG opens; no network call is made to make it | +| The link | `/block/` (exists: parents, children, mergeset, shards, checkpoint fractions, `block.html:285-325`) | 0 | | +| What is not on it | no fiat, no price, no "worth": there is no market and the copy law forbids the aphorism | | | + +The pool user gets the same card for the first share ("Share accepted by pool-0 · 0.0012 of a block") and the first credited block ("pool-0 found block N; your share 0.41 IGN"), from the `share_result` and the PPLNS credit lines the pool already sends. + +### 3.4 The app: Earnings + +Today (`miner-ui-3.md` section 5, polish Q18): the first number on the tab is "£0.00 earned: nothing is bought or sold on devnet"; mined IGN is never shown, only proving `paid_wei`; the electricity line is real and shown as a cost. + +| Line | Today | Should read | Source of the number | Hours | +|---|---|---|---|---| +| 1 | £0.00 earned | **6,912 IGN a day** at your last hour's rate (86 blocks) | the node's own block count for the key times the subsidy at the block's DAA; the projection from the 1-h rate and `/api/stats` network rate | 2 | +| 2 | 0.0000 IGN from 0 proofs | 2,592 blocks in 30 days, 207,360 IGN; 14 shards, 16.1 IGN | the node and the execution layer (the balance is in the wallet; the app reads the coinbase credits per key) | 1 | +| 3 | none | about £N a day at a price you type (no exchange lists IGN; a typed price, remembered, never fetched) | the user's field; the engine's `price_gbp_per_ign` when a market exists, as the UI 3 plan already owes | 1 | +| 4 | none | your card is 0.100 percent of the network; weight rank 41 of 1,204 keys; 30 of 30 days | `/api/live` miners and the finality weights RPC (`getFinalityWeights`, spec 3.10) | 2 | +| 5 | £1.95 a day electricity | unchanged, and the line under it: "N IGN per kWh" | the existing watt reading | 0.5 | +| 6 | dev fee line | unchanged (1 in 100, the switch) | | 0 | + +A rule for every number on the tab: it comes from the node this machine runs, or from the public API with the field named on hover (polish 4.3, one formatter table). The typed price is the only number the user supplies and the tab says so. + +### 3.5 The pool + +Decision for the launch pool, with reasons: + +| Question | Decision | Why | +|---|---|---| +| Who runs it | the project runs pool-0 at the testnet go and at mainnet genesis, on the written systemd unit (`pool/README.md`), with the member's vote key in every header as built | nobody else can on day 1; the member-key design means the project's pool never holds vote weight, which is the thing a project pool is normally criticised for | +| Fee | 1 percent, the same as the solo dev fee, published in `welcome`, on the page and on `/miner` | a 0 percent project pool makes every outside pool unviable, and the first outside pool is a launch gate (section 4.1); 1 percent is what miners accept everywhere (2miners 1.0 percent, https://kas.2miners.com/, 7 Oct 2026; Ethermine 1 percent, approximate); fee-neutral between solo (dev fee 1 in 100) and pool, so the choice is about variance only | +| Where the fee goes | the same software address as the dev fee; it is a software fee, documented as such (`miner-dev-fee.md`), never a protocol fee | no dev fund, no treasury; the protocol carries no fee to anyone | +| Mode | PPLNS, window 2 blocks of weight, payout rounds every 60 s, minimum 1 IGN (as built) | the first payout inside two minutes of the first share for an 8 GB card at 100 GH/s (section 1.4) | +| Default in the app | solo under 500 GH/s network, the app suggests the pool above it, per card: "a card like yours finds a block about every 16 hours on today's network; pool-0 pays every minute" | the Poisson line of 3.2 decides; the user chooses | +| What the pool page shows | the connect card, the lookup, the blocks and the payments table (Q71 owed), luck in MiningPoolStats' convention (Q69, Q72), "payouts follow blue confirmation, not finality" (Q73), and the finality state | the comparator rows in polish 3.6 | +| TLS | before the public testnet (Q67, 8 hours, consensus-engineer) | spec 9.3 | + +The variance arithmetic that makes the pool required, computed: a single 8 GB card at 17 MH/s finds a solo block every 1.6 hours at 100 GH/s, every 16 hours at 1 TH/s (23 percent of days with no block), every 6.8 days at 10 TH/s (36 percent of weeks with no block), every 68 days at 100 TH/s. The pool is optional at launch size and required from about 1 TH/s. The pool's own payout latency: credit on blue confirmation (seconds), a round every 60 s, so under two minutes end to end once the member's balance passes 1 IGN. + +### 3.6 Community: the Discord, the live page, the leaderboard, the miners page, the explorer + +What exists: the Discord kit (roles Founder, Core, Prover, Miner, Bot; channels INFO, CHAIN, LEDGER, TALK; the bot posts a pulse four times a day, a daily digest, weekly numbers, releases, incidents; nothing live yet, Q7); `/live` with a Miners lane list of vote keys with a block in the last 10 minutes; `/miners` the bench table (six rows, Q51); the explorer with Miner as the payout address per block; `/address` (noindex) with balance and blocks mined. + +| Surface | Add | Rule that keeps it honest | Hours | Gate | +|---|---|---|---|---| +| Discord #first-blocks | the bot posts every first block of a new key (short key id, the block link, the card model if the miner opted in through the app's "show my card" switch) | from the public API only; the forbidden-string guard; no name, no machine id | 2 | ten first blocks posted on Devnet 2 with the right links | +| Discord roles | Voter (the key is above dust, verified by a message signed with the vote key against `getFinalityWeights`), Window (30 of 30 days), Prover (as built) | chain-side facts, anyone can check the same RPC | 3 | a role granted and revoked by the chain's numbers in a test | +| `/live` Miners | a leaderboard by 30-day weight: rank, short key id, blocks in window, days mined, signing presence, last block; a toggle to the 10-minute view that exists | weight, never hashrate; a renter who arrived today is at the bottom whatever they rent | 3 | the page shows the top 100 by weight with days-mined; a key that stops mining falls one place a day | +| `/address/` | the public profile: blocks in 30 days, weight rank, vote state, checkpoints signed, shards proven, first block date, the block cards | noindex stays until the owner opts in from the app ("make my page public") | 3 | the page renders for every key in the window | +| `/miners` | the hardware census (section 4.4): one row per card model from the hourly program's per-card timings, MH/s, W, MH/W, count of keys on that model, median first-block time | measured, scrubbed, no machine names (the bench-table rule) | 4 | eleven rows today, every model with three or more keys after the testnet go | +| Explorer block page | "found by key id N, rank 41, day 23 of 30" under Miner | from the same weights | 1 | the line on every block | + +### 3.7 Why I stay: the ladder written into consensus + +The thing no other chain has: vote weight is 30 days of blocks per key (rule v2). A level system with no points server, no badge contract and no company database: the chain computes it, the node reports it (`getFinalityWeights`), the wallet verifies the certificates it signs. + +| Rung | Name on screen | Rule | Time for a 100 MH/s card at 100 GH/s | Time for an 8 GB card at 100 GH/s | Where shown | +|---|---|---|---|---|---| +| 0 | First block | one blue block with your key | 16.7 min expected | 1.6 h | the block card; #first-blocks | +| 1 | Your key has a vote | 100 blocks in the window (the dust line) | 1.2 days | 6.8 days | Mine hero, address page, Discord Voter | +| 2 | Your signature is in checkpoint K | the first certified checkpoint carrying the key's vote | the next 30-s checkpoint after rung 1 | the same | the finality line in Mine, the block page of the lock | +| 3 | Full window | 30 of 30 days with blocks | day 30 | day 30 | the days ring in the hero; Discord Window | +| 4 | Rank | position by weight among all keys | continuous | continuous | `/live` leaderboard, Earnings line 4 | +| 5 | Signing streak | days since the key last missed the presence window (the 8 points never lost) | continuous | continuous | Earnings: "signing 8 of 80 points, 41 days unbroken" | +| P | Your card proved shard N of block M | a paid shard record | hours on a 24 GB card; not yet on 8 GB | not yet | the Prove tab card, Discord Prover | + +The exact lines, in copy law: "Your key has a vote." "Your signature is in checkpoint 184,220." "Your card proved shard 3 of block 1,284,117." "30 of 30 days. Full weight." "Rank 41 of 1,204 keys." Each line names the chain fact behind it on hover (the RPC field), the same rule as every number on the site. + +What the rungs pay, so the ladder is not decoration: rung 1 is the vote itself; rung 2 starts the 8-point signing line (the public sentence: miss two hours of signing and the next blocks pay 72 until you sign again); rung 3 is maximum weight; rung P is the proving income (20 points of every block, split by shard). Nothing is paid from a fund; the ladder only names what the rules already pay. + +### 3.8 Per tier: the first hour and the first month + +Cards at the measured untuned rates of `docs/analysis/prover-tiers-real-cards.md` (rented, 6 October 2026) and the bench table; expectations at 1 block a second; the first month at full rate (100 IGN a block) and at the 90-day ramp approved for the testnet genesis on 7 October (10 percent on day 1, so divide the IGN column by 10 on launch day; CLAUDE.md's 30-day ramp is the earlier text). + +Network 100 GH/s: + +| Tier | Gap to a solo block | Block in the first hour | Blocks a day | IGN a day (80 points) | Days to a vote | First month: blocks, and what the key is | +|---|---|---|---|---|---|---| +| 8 GB, RTX 4060 (17.07 MH/s) | 1.6 h | 46 percent | 14.7 | 1,180 | 6.8 | 442 blocks; a voter from day 7; full window day 30; proves core-only shards (`prover-tiers` row 4060) | +| 8 GB, RX 9070 XT (17.9) | 1.6 h | 48 percent | 15.5 | 1,237 | 6.5 | 464; a voter from day 7; no proving (CUDA only today) | +| 12 GB, RTX 4070 (24.99) | 1.1 h | 59 percent | 21.6 | 1,727 | 4.6 | 648; a voter from day 5; mines and proves on the patched prover when shipped | +| 12 GB, RTX 5070 (41.89) | 40 min | 78 percent | 36.2 | 2,895 | 2.8 | 1,086; a voter from day 3 | +| 16 GB, RTX 4060 Ti (17.58) | 1.6 h | 47 percent | 15.2 | 1,215 | 6.6 | 456; a voter from day 7; mines and proves | +| 24 GB, RTX 4090 (52.25) | 32 min | 85 percent | 45.1 | 3,612 | 2.2 | 1,354; a voter from day 3; mines and proves today | +| 32 GB, RTX 5090 (98.48 rented; 122 on PC 1) | 17 min | 97 percent | 85.1 | 6,807 | 1.2 | 2,553; a voter from day 2; proves beside the miner | +| Apple M5 Max, Metal (26.7) | 1.0 h | 62 percent | 23.1 | 1,846 | 4.3 | 692; a voter from day 5; proves on the CPU, slowly | +| Rig, 6 x RTX 4090 (313.5) | 5.3 min | 100 percent | 271 | 21,669 | 0.4 | 8,126 (one key per machine, the 6 October default) | +| Pool member, any of the above | first share under a minute; first credit under two minutes | 100 percent | the same blocks on average, paid every minute | the same minus 1 percent | the same days (weight follows the member's own blocks) | the same | + +Network 1 TH/s (the same cards): + +| Tier | Gap to a solo block | Block in the first hour | Blocks a day | IGN a day | Days to a vote | 30-day blocks | +|---|---|---|---|---|---|---| +| 8 GB, 17.07 MH/s | 16.3 h | 6 percent | 1.5 | 118 | 68 (never inside the window) | 44 | +| 12 GB, 24.99 | 11.1 h | 9 percent | 2.2 | 173 | 46 (never) | 65 | +| 12 GB, 41.89 | 6.6 h | 14 percent | 3.6 | 290 | 28 | 109 | +| 24 GB, 52.25 | 5.3 h | 17 percent | 4.5 | 361 | 22 | 135 | +| 32 GB, 98.48 | 2.8 h | 30 percent | 8.5 | 681 | 12 | 255 | +| Apple M5 Max | 10.4 h | 9 percent | 2.3 | 185 | 43 (never) | 69 | +| Rig, 6 x 4090 | 53 min | 68 percent | 27.1 | 2,167 | 3.7 | 813 | + +Per OS and vendor, what differs in the first hour: Windows, two prompts (section 3.1) and NVIDIA through the driver, AMD and Intel through OpenCL; macOS, one prompt, Apple silicon through Metal, no watt reading so no pounds line; Linux and HiveOS, no prompt, the Flight Sheet fields, Hive itself untested on a real rig (`/miner`). AMD cannot prove today (CUDA only). The 12 GB tier cannot mine and prove at once on the shipped build (peak 15.6 GB measured, bench log 5 October); the patched prover's 10.1 GB peak beside the miner on the 4070 is measured and not shipped. + +### 3.9 The first withdrawal, and the first "I own something" + +No exchange at the testnet, none arranged or sought at mainnet (journey phase 6). So the first ownership moment is not a withdrawal. It is: + +| Moment | Today | Proposal | Hours | +|---|---|---|---| +| The balance | in the wallet ("the balance is in the wallet", Earnings); the address page shows balance and blocks | the Earnings tab shows the balance read from this machine's node, with "verified by this node" on hover | 1 | +| The proof | the wallet verifies finality certificates with the node's own code (`finality.rs:101-121`) | the first block card carries "final under checkpoint K, certificate verified by this machine" once the lock lands, and the address page shows the latest locked checkpoint (Q37) | 1 | +| The QR | the wallet draws the `ethereum:` URI locally (`server.rs:140`) | the saved block card carries the explorer link as a QR; the address page's QR under "make my page public" | 0.5 | +| The send | EIP-1559 value transfers in the wallet | a first-transfer card in the wallet: "sent 10 IGN to 0x…, in block N, final under checkpoint K" with the state words pending, included, executed, proven, finalised (UI 3) | 0 beyond Q9 | + +"I own something" on Igneum is "a block with my key is final under a certificate my own machine verified". No other chain's miner app says that sentence. + +## 4. The exact structure for Igneum + +### 4.1 The launch sequence as gates + +The go checklist (`docs/plans/testnet-go.md`) has eleven steps, from the seeds at height 0 to the first miner's block 1. These are the community gates that follow it; none has a date. + +| Gate | Definition | How it is measured | What opens when it passes | +|---|---|---|---| +| G-C1 First 100 keys | 100 distinct vote keys with a block in the last 24 h | `/api/live` miners over a day | the #first-blocks channel goes live; the leaderboard shows ranks | +| G-C2 First block by a card the project does not own | a block whose key is not in the project's fleet list | the observer's key list against the fleet file (the Discord guard already reads it) | the "first outside block" post, with the owner's permission | +| G-C3 First outside-reproduced benchmark | a card row on `/miners` measured by someone outside the project, with driver, OS and version (Discord rule 6) | the bench-table ingest with `by: reported by a miner` | the census starts (4.4) | +| G-C4 First pool not run by the project | a pool at an address the project does not control with 10 percent of blocks for 7 days, the member key in its headers | the explorer's payout-address share | pool-0 stays at 1 percent; the app's pool list gains a second entry | +| G-C5 First 1,000 independent keys | X5 as decided on 6 October: 1,000 keys above dust over 30 days, independent in autonomous system, machine fingerprint and pool attestation, top-10 share of window weight under 50 percent; a silent key counts only if its AS is its own | the observer's AS and fingerprint columns (owed, one app-owner item) | journey phase 5 closes; mainnet genesis is the next gate | +| G-C6 First outside proving customer | one rollup's job proven and paid on its own chain | the job market's payout contract | phase 4's second half | + +### 4.2 The first 1,000 miners: where they come from + +The no-airdrop constraint shapes every row: nothing is offered for joining; the only pay is mined emission; the message is the number and the file. Costs are agent hours for the content and the answering; the expected counts are this lane's estimates and labelled so. + +| Channel | Expected keys (approximate) | Hours | The message | Rule | +|---|---|---|---|---| +| r/gpumining (the Reddit kit's day-7 post: eleven cards, MH/s, W, MH/W) | 150 to 300 | 6 (post, 48 h of answers) | the card table; "devnet coins have no value; nothing is for sale"; the ledger | rule 2.10 (no referral or promo links); the founder reads the Expanded Rules first | +| r/EtherMining (the Merge story, under rule 7's disclosure) | 100 to 200 | 4 | four years after the Merge, what runs and the command to check it | one linked post per seven days; nobody sent to Discord | +| HiveOS forum and the custom-miner listing | 100 to 250 (rigs, so more hashrate than keys) | 4 plus the first real Hive run | the HiveOS card verbatim, "Hive itself is untested so far; report what breaks" | the first reported rig run gets a bench row and the Miner flair | +| Bitcointalk ANN | 50 to 150 | 3 plus daily answers for a week | the ANN format: no premine, no sale, the dev fee, the card table | no bounty, no signature campaign | +| Miner Discords (lolMiner, BzMiner, Hive, the Kaspa and Ergo mining rooms) | 100 to 200 | 3 | two sentences, the card table, the ledger, "nothing is for sale" | one message per server in its projects channel | +| The miner-software authors (lolMiner, BzMiner, Team Red, Rigel) | 0 to 300 keys on the day one of them ships Igneum | 8 (the worker protocol document, the vectors, the dev-fee template mechanism explained so their fee works in solo mode) | "a fee template is 1 in 100 by a counter; your fee rides the same mechanism" | their fee is theirs; the protocol carries none | +| r/CryptoTechnology, r/zkproofs, r/Monero (the design rooms) | 30 to 80 | 4 | the prover, the verify command, the vs RandomX table | comments only where the rules say so | +| The hardware census itself (4.4), once G-C3 passes | 100 to 300 over the first months (people come to get their card measured on a public board) | 0 beyond the board | "your card's row, measured by the chain, not by us" | scrubbed, no machine names | +| Total | 630 to 1,780 keys, median about 1,000 | 32 | | | + +Every row is the Reddit kit's existing text or an extension of it; the only new content is the census board and the worker-protocol document for the miner authors. + +### 4.3 The pool at launch + +Decided in 3.5: project-run pool-0 at 1 percent, member keys in headers, PPLNS, 60-s rounds, the dev fee off in pool mode because the pool fee is the same 1 percent to the same software address. The outside pool is a gate (G-C4), not a hope: the pool crate is public with its README, and the app's pool field takes any host. + +### 4.4 The leaderboard and the census + +| Board | Ranks | Never ranks | Source | Why | +|---|---|---|---|---| +| Keys (`/live`, the address page, Earnings line 4) | 30-day weight (blue blocks per key in the window), with days mined and signing presence | hashrate | `getFinalityWeights` | a renter who arrives today has no weight; a laptop that mined for 30 days outranks a rented rig's first week; the board is the chain's own security table, so it cannot lie without the chain lying | +| Cards (`/miners`, the census) | efficiency per card model: MH/s, W, MH/W, and the per-program timing spread from the hourly swap (the frontier lane's "8,760-question hardware census", `frontier.md` 4.3) | people | the hourly program's per-card timings, the bench-table ingest, scrubbed | the public benchmark the litepaper promises, made continuous; a chip that does better than the GPU curve shows up on this board first | + +The census is new: RandomX programs are per hash and no pool sees their timing; Igneum's hourly program with per-card racing produces the census as a by-product (`frontier.md` 4.3). It is the one leaderboard a miner wants that no chain has, and it doubles as the chip alarm. + +### 4.5 The story each miner tells + +Written in copy law (short sentences, no antithesis, no aphorism). + +| When | The three sentences | +|---|---| +| First week | "I installed it in five minutes and the first block was mine inside the hour. Every block pays my address straight away. My 4070 is on a public board with its watts." | +| First month | "My key has a vote now. It signs finality every 30 seconds and I can see the checkpoint it is in. After 30 days my weight is full, and the rented farms that showed up last week sit under me." | +| First year | "The program has changed 8,760 times and my card still mines it. My card has proved 400 shards for a rollup I have never heard of. Nothing was sold and nothing was given away: every coin I hold was mined." | + +## 5. The surfaces to change + +| Surface | Today (polish.md) | Should show | Hours | Gate | +|---|---|---|---|---| +| Ember, Cards | card name, switch, "worker Metal, 40 GPU cores" (audit 2.2) | expected MH/s and W from the priors, "about N blocks a day on today's network", the proving tier sentence | 1.5 | every model in the priors shows a number | +| Ember, Mine (before the first block) | the blocks strip, 10 minutes (`app.js:1052-1127`) | the Poisson count-up line; the pool suggestion when the gap passes 8 h | 2 | the line shows from the first job to the first block | +| Ember, Mine (the block card) | an event line | the block card of 3.3, saved PNG, the explorer link | 4.5 | the four thresholds; the PNG with no network call | +| Ember, Earnings | "£0.00 earned", mined IGN never shown (Q18) | IGN a day, blocks and IGN in 30 days, shards and IGN, a typed price, share of network, weight rank, days, signing streak | 6.5 | every line names its RPC field on hover; a view test per line | +| Ember, Prove | state line "0 assigned · 0 proven · 0 paid" | the shard card "your card proved shard N of block M, 1.15 IGN" | 1 | a card on the first paid record on Devnet 2 | +| Ember, Settings | pool field designed, not built (`pool.md` section 7) | the pool field, the terms box from `welcome`, the dev-fee line reading "off in pool mode: the pool's 1 percent is the same fee" | 3 | a member connects from the app and shows the terms | +| Ember, first run | two prompts, one unexplained (Q3, Q14) | signed and notarised; the firewall step named on the Cards screen | 7 plus the project lead's certificates | 3.1 gates | +| Wallet | one account, no finality state on the address page (Q33, Q37) | the first-transfer card with the five state words; the address page with the latest lock | 3 (plus Q9's 6) | a devnet transfer walks the five words on screen | +| Site `/miner` | "Install. Start. The card mines and proves." plus feature lines | the first-hour timeline (download, the one prompt, first share, first block, first payout) with the measured times from the Devnet 2 gate | 2 | the times on the page equal the gate's log | +| Site `/live` | miners with a block in 10 minutes | the weight leaderboard with days mined and signing presence; the 10-minute view as a toggle | 3 | top 100 by weight; a stopped key falls one place a day | +| Site `/miners` | six rows, two models, "not measured" MH/W (Q51) | the census: one row per model, MH/s, W, MH/W, keys on that model, median first-block time | 4 | every model with three or more keys | +| Site `/address` | balance, blocks, noindex | the public profile of 3.6 behind the app's opt-in | 3 | renders for every key in the window | +| Explorer block page | Miner = payout address | "found by key id N, rank 41, day 23 of 30" | 1 | on every block | +| Pool page | stat strip, connect, lookup, blocks, no payments table (Q71) | payments, luck in the standard convention, "payouts follow blue confirmation, not finality", finality state | 3 | the comparator rows in polish 3.6 | +| Discord | nothing live (Q7); roles Miner and Prover by hand | the bot live; #first-blocks; Voter and Window roles from chain facts | 8 | ten first blocks on Devnet 2 posted; a role granted by a signed message | +| Total | | | 52.5 plus the certificates | | + +## 6. What not to build + +| Idea | The line that kills it | +|---|---| +| Gamification paid from a fund (a weekly prize, a "block of the day" bonus) | there is no fund; every coin is mined under the 80/20 rule and the signing bonus, and a prize paid by the project is a premine by another name | +| Referral in coins | no referral paid in coins from a fund: there is no fund; and r/gpumining rule 2.10 bans referral codes outright | +| An airdrop for installing, posting or reproducing a benchmark | an airdrop in exchange for anything is a sale by another name; the rule is "nothing is for sale" on every surface | +| NFT badges for the rungs | the rung is a chain fact already (weight, days, signatures); a token for it adds a contract, a market and a price to a thing that must stay a number | +| An off-chain points system | a number a company server has to be trusted for; the ladder's rule is that every number is a chain fact anyone can read from an RPC | +| A rank-by-hashrate board | a renter tops it on the first day; the only board is weight, which takes 30 days | +| A "top earners" board in fiat | there is no price; a typed price is the user's and stays on their machine | +| A Discord level bot (MEE6-style XP for messages) | a number a server owner sets; it rewards talking, not mining | +| A bounty for the first ASIC, or a device bounty | ruled out (M1, M22); a device bounty is a sale of the chip | +| Streaks that penalise a miss (lost rungs, demotion) | the signing bonus already prices a miss (72 until you sign again) and nothing is burned; a second penalty on top is the burn the owner refused | +| Any surface whose number needs a company server to be trusted | the observer, the API and the Discord bot are conveniences; every number they show must be reproducible from a node, or it is not shown | + +## 7. Verdict table + +| Proposal | Evidence (chain, year, number) | Newness | Hours | Gate | Recommend | +|---|---|---|---|---|---| +| Signed and notarised installers | SmartScreen warns on any file without reputation (Microsoft Learn, 2026); polish Q3 | everyone has it; we lack it | 7 plus certificates | no interstitial on a fresh Mac; the Windows one gone by 1,000 downloads | do now | +| The Poisson count-up before the first block | 2miners shows pool luck (kas.2miners.com, 2026); no app shows a solo miner's own running chance | nobody has it | 2 | the line shows until the first block | do now | +| The block card with a saved PNG | EtherMining's rig photo 2,528 points in 2021 (section 1.1); the Helium miner photo 860 in 2021 | nobody has it in a miner app (approximate) | 4.5 | PNG with no network call | do now | +| Earnings in IGN first, a typed price second | NiceHash shows fiat first (polish 3.1, approximate); Q18 | someone has fiat; nobody has "typed price, never fetched" | 6.5 | every line names its field | do now | +| The weight ladder: vote, signature, full window, rank, streak | rule v2 (Igneum, 2026): weight is 30 days of blocks per key | nobody has it | 6 (across Ember, address page, Discord) | a Devnet 2 key walks every rung on screen | do now | +| The weight leaderboard on `/live` | Kaspa pools rank workers by hashrate (approximate); Helium ranked hotspots by HNT (section 2) | nobody ranks by consensus weight | 3 | top 100 by weight | do now | +| The hardware census on `/miners` | frontier 4.3; the litepaper's promised benchmark | nobody has it | 4 | every model with three keys | do now | +| Pool-0 at 1 percent, member keys | 2miners 1.0 percent fee (2026); spec 09 member votes | the member-key pool is new; the fee is standard | 0 beyond Q67 to Q73 (about 20) | G-C4 | do now | +| #first-blocks and the Voter and Window roles | Discord kit roles (2026); chain-side facts | nobody grants a role from consensus weight (approximate) | 5 | roles from a signed message | do now | +| The public address profile behind an opt-in | Helium's explorer hotspot page (2021), section 2 | someone has it (Helium); ours adds the vote and the signatures | 3 | renders for every key | prototype | +| The first-hour timeline on `/miner` with measured times | the devnet laptop's 7 minutes and the 5090's first minute (bench log, 4 Oct 2026) | ethereum.org and kaspa.org have no measured install time (approximate) | 2 | the page equals the gate's log | prototype | +| The worker-protocol document for miner authors | lolMiner 0.75 percent Kaspa fee, T-Rex 1 percent (their READMEs, 2026) | standard | 8 | one outside miner ships Igneum | prototype | +| A dust line that scales with the network | section 1.4: an 8 GB card never votes past about 500 GH/s | a finality-lane question | 0 here | the finality lane's answer | watch | +| Sound on a block | every pool page has a block sound option (approximate) | standard | 0.5 | off by default | watch | +| Anything in section 6 | | | | | never | + +## 8. Three headline findings for the coordinator + +1. At the litepaper's 100 GH/s network a solo 8 GB card finds its first block in 1.6 hours expected and 46 percent of them see no block in the first hour, so the first-hour dopamine for the most common tier is the Poisson count-up line and the pool's first share under a minute, not the block; at 1 TH/s that card finds a block every 16 hours and never reaches the 100-block vote line (44 blocks in 30 days), which the finality lane must weigh against the 1,000-independent-keys gate. + +2. Igneum's 30-day vote window is a level system no other chain has, and it is free: the rungs (first block, 100 blocks for a vote, a signature in a checkpoint, 30 of 30 days, rank by weight, a signing streak) are chain facts from `getFinalityWeights`, cost about 6 agent hours to show across Ember, the address page and Discord, and cannot be topped by a renter inside 30 days. + +3. In a 105-post sample of miner joy on Reddit (69 with a room median), the posts that rise highest are the miner's own: "my card paid for itself" at 777 times the room's typical score, the rig photo at 417, the hashrate milestone at 409, against 66 for the network's own milestone and 56 for the first pool payout; so every shareable surface Igneum builds carries the miner's card, rank and days, not the project's number, and the saved block card (4.5 hours) is the first of them. + +## Sources + +Repository files (the mission worktree, read 7 October 2026): `CLAUDE.md`; `docs/analysis/horizon/polish.md` (sections 1, 3.1, 3.2, 3.4, 3.6, 3.7, 3.10, 4.5); `docs/analysis/vote-or-burn.md` section 5; `docs/analysis/tail-emission.md`; `docs/analysis/horizon-2026-10.md` section 1; `docs/plans/ledger-decisions.md` (item 3, the standing decisions, the 6 and 7 October decisions); `docs/plans/pool.md`; `pool/src/config.rs`; `docs/spec/09-pool-protocol.md`; `docs/plans/miner-ui-3.md` and `miner-ui-3-audit.md`; `docs/plans/testnet-go.md`; `docs/design/miner-dev-fee.md`; `docs/community/discord-hooks.md`; `docs/analysis/prover-tiers-real-cards.md`; `docs/analysis/horizon/frontier.md` 4.3; `docs/bench-log.md` (4 and 5 October 2026 entries); `site/journey.json`, `site/live.html`, `site/explorer.html`, `site/miner.html`, `site/miner-bench.json`; the litepaper text; the Reddit kit on branch `reddit-kit` (`docs/community/reddit/outreach.md`, `outreach-week-1.md`, `discord.md`). + +Fetched by this lane (all 7 October 2026): +- https://2miners.com/faq (payouts every 2 hours; thresholds per coin page) +- https://kas.2miners.com/ (1.0 percent fee, 50 KAS minimum, 771 miners, luck 441 percent, last block 2 minutes ago) +- https://solo-kas.2miners.com/ (SOLO fee 1.5 percent, 99 miners) +- https://p2pool.io/ (min payout 0.00027 XMR; "several days to a week to find a share") +- https://github.com/Lolliedieb/lolMiner-releases (Kaspa fee 0.75 percent, Autolykos 1.5 percent) +- https://github.com/trexminer/T-Rex (1 percent, 2 percent on Octopus and Autolykos2; the antivirus note) +- https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/ (page dated 23 April 2026) +- https://www.ssl.com/code-signing/ (reputation through use for OV and EV) +- https://support.apple.com/en-us/102445 (Open Anyway) +- https://developer.apple.com/programs/ (USD 99 a year) and https://developer.apple.com/support/compare-memberships/ (notarisation included) +- https://shop.certum.eu/open-source-code-signing-on-simplysign.html (from EUR 49, out of stock) +- https://azure.microsoft.com/en-us/pricing/details/trusted-signing/ (Basic 5,000 signatures a month; price not shown) +- https://en.wikipedia.org/wiki/Helium_Network and https://en.wikipedia.org/wiki/Chia_(cryptocurrency) +- https://api.pullpush.io/reddit/search/submission/ (r/EtherMining, r/chia, r/HeliumNetwork, r/kaspa listings used as a cross-check of the sub-lane's sample) + +Fetched by the Reddit sub-lane (scratch `mission-reinvent/reddit-sample.md`, 105 posts, every URL in its table 1 and quotes in table 3; the Arctic Shift archive for medians; the ninjastic archive for bitcointalk). The URLs cited in sections 1.1 and 2 above are from that file. + +Fetched by the chains sub-lane (scratch `mission-reinvent/chains.md`, 96 URLs in its sources list): the Helium HIPs 10, 15, 17, 20, 25, 51, 53, 54, 70 and the denylist repository; the Chia blog posts of 11 Nov 2020, 23 Feb, 17 Mar, 24 May, 13 Jun, 15 Jun, 30 Jun, 7 Jul, 3 Aug 2021 and 19 Mar 2022 and releases 1.0.0, 1.1.0, 1.2.0; Etherscan's hashrate CSV; bitinfocharts ETH and ETC; Decrypt on ETC; api.kaspa.org; the BzMiner, lolMiner and Team Red release pages; asicminervalue; the Monero node RPC, xmrchain, the RandomX repository and getmonero.org; the Ravencoin whitepapers, releases and blockbook; the Ergo releases, docs and explorer API; the 2miners stats APIs and blog; CoinGecko for every price. Pages that refused the fetch (Mashable, The Verge, Bloomberg, Forbes, CNBC, Polygon, PCMag) are cited through Wikipedia and marked so in that file. + +Figures labelled approximate come from memory and were not pinned to a page today. diff --git a/docs/analysis/mission/unfinished.md b/docs/analysis/mission/unfinished.md new file mode 100644 index 00000000..4a7d741b --- /dev/null +++ b/docs/analysis/mission/unfinished.md @@ -0,0 +1,371 @@ +# The last mission, lane 2: started and not finished, across the industry + +7 October 2026. Lane 2 of the final research programme. What the industry started and did not finish, group by group, with one verdict per row: Igneum already has the finished version, Igneum could finish it in hours, or Igneum should leave it. Every figure from a source carries its URL and access date in section 9; every figure from memory is labelled approximate. Hours are agent hours (the project lead's rule: Claude-side work takes hours, never weeks). Nothing here is a token sale. + +What this file does not repeat: the ASIC chip history (`docs/analysis/asic-resistance-history.md`), the useful-work verdict and the stored-state candidate (`new-pow.md` sections 3, 6, 7), the ranked frontier ideas (`frontier.md` section 0, 3.10, 3.11), and Igneum's own pool design (`docs/plans/pool.md`, `docs/spec/09-pool-protocol.md`). Those are cited, not restated. + +## 0. Progress (UK time) + +| Time | State | +|---|---| +| 08:1x (approximate) | Context read: CLAUDE.md, asic-resistance-history.md, new-pow.md 3, 6, 7, frontier.md 0, 3.10, 3.11, horizon-2026-10.md 1, pool.md, spec 09, polish.md 3.1, 3.6, 3.10 | +| 08:2x (approximate) | Four research lanes launched (A, B, C with D, E). Lane F was refused by the concurrency cap and was researched by this lane directly | +| 08:3x (approximate) | The session's WebSearch budget ran out (200 of 200). Every later fact came from WebFetch of a primary page or is labelled approximate | +| 08:49 | Lane F notes saved (scratch `mission-unfinished/F-notes.md`, file time) | +| 08:50 | Igneum-side pool and Ember comparison drafted (scratch `igneum-side-draft.md`) | +| 08:53 to 08:59 | Lanes A, E, B, C with D landed (scratch file times) | +| 09:09 | All notes read; assembly of this file started | +| 09:17 | File complete: 371 lines, em-dash grep at zero, nothing staged | + +Limits of this research: p2pool.observer answered 502 all morning (Monero P2Pool share taken from the miningpoolstats data file instead); Bob Rao's ProgPoW PDF would not extract (his 1.1x to 1.2x figure is cited to EIP-1057); Bitmain's own X9 page was unreachable (the X9 is reported as announced per resellers, unconfirmed shipping); NiceHash's fee and repayment pages are gone (those figures are approximate); Salad's take rate is not published anywhere fetched. + +## 1. Group A: proof of useful work + +The one question per row: can the useful work be verified cheaper than it is done, and is it sampleable (a nonce picks a random instance the miner cannot steer, with tunable hardness)? The third column the rows keep answering by themselves is whether anyone wanted the output. + +### 1.1 The rows + +| # | Programme | Attempted, by whom, when | Achieved (numbers) | Left undone | Why it stopped | Verified cheaper than done | Sampleable | +|---|---|---|---|---|---|---|---| +| 1 | Primecoin | Sunny King, 7 Jul 2013: header hash is the origin of a Cunningham or bi-twin prime chain | 13-prime 94-digit chain 10 Sep 2013; first length-15 twin chain 30 Mar 2018; height 7,038,822 today | Any use of the primes; GPU resistance (GPU miners by 2014, approximate) | Nobody needed the output; price USD 0.034, "stopped trading on all exchanges"; last release 26 Jan 2021 | Yes, but polynomial: 10 to 15 modexps to verify against millions of sieve steps (approximate) | Yes: the hash fixes the origin, chain length plus fractional remainder tunes hardness | +| 2 | Gridcoin | Rob Halford, "Proof of Research" live 11 Oct 2014 on BOINC credit | 17 whitelisted projects, 3 greylisted; release 5.5.0.0 on 3 Apr 2026 (78 PRs, 11 contributors) | A verifiable work primitive; consensus moved to pure PoS 2014 to 2015 | Scraper nodes read credit from project servers and sign a superblock; the chain never checks a work unit | Only by trust (an oracle reads a website) | No: the miner picks the project and the unit; the project sets hardness | +| 3 | Curecoin, FoldingCoin | 2014, Folding@home points paid daily (CURE) or monthly (FLDC on Counterparty) | 1 trillion F@h points by 28 Jul 2019, over 10,000 team members | Verification by anyone but Stanford's servers; Curecoin 2.0 roadmap undated; FoldingCoin asset archived, site gone | Tip jar on a centralised stats feed; token value fell under the electricity (approximate) | Only by trusting F@h | No: F@h assigns the work | +| 4 | Aleo PoSW to synthesis puzzle | Proof of Necessary Work (Kattis, Bonneau, 2020/190); testnet 3 coinbase puzzle 2023; mainnet 17 Sep 2024 on AleoBFT with the puzzle outside consensus; ARC-41 synthesis puzzle | 750 M proofs per second and over 44,000 provers on testnet 3 (Messari excerpt); 2/3 of coinbase to provers; about 16 pools took close to 90 percent of puzzle rewards; ARC-46 (31 Jul 2025) demands 100,000 ALEO staked per solution, 2,500,000 by 2027 | The original promise: energy that produces proofs of real state. The puzzle proves nothing the network uses | A BFT validator set gives finality; the puzzle survives only to pay hardware and keep a prover fleet warm; proving centralised on the same path as mining | Yes (SNARK verify in milliseconds) | Yes (epoch hash plus nonce, target tunable). Useful: no | +| 5 | Ofelimos | Fitzi, Kiayias, Panagiotakos, Russell, eprint 2021/1379, CRYPTO 2022: doubly parallel local search, every step a hashed PoW unit | A security proof in the backbone model; WalkSAT variant "competitive with vanilla WalkSAT" | Any deployment; who submits problems and pays; the search's own efficiency (FRLS follow-up 14 Nov 2025 calls DPLS "particularly wasteful") | Economics and operations, not the proof | Yes (each step is a cheap check) | Partly: the step is nonce-bound, the instance comes from a client pool, so hardness is tuned on the hash part | +| 6 | PoW from worst-case assumptions | Ball, Rosen, Sabin, Vasudevan, eprint 2017/203 and 2018/559: Orthogonal Vectors, 3SUM, APSP with a delegation verifier | The conditions: worst-case to average-case reduction, non-amortisability, fast verification | Any implementation or benchmark; a buyer for random OV instances | The instances must be drawn from a distribution no real problem has; polynomial blow-ups | Yes (near-linear verify against quadratic solve) | Yes by construction. Useful: no in practice | +| 7 | Filecoin PoRep and PoSt | Protocol Labs, mainnet Oct 2020: seal a 32 GiB sector (hours of CPU plus 20 to 30 min GPU SNARK, 128 to 256 GiB RAM), then daily WindowPoSt | Utilisation 29 percent (Q1 2025), 36 percent (Q3 2025), 1,110 PiB of real data on 3.0 EiB committed; raw byte power 3.01 EiB (29 Sep 2025) to 1.35 EiB (14 Sep 2026), down 55 percent; 99.5 percent of Q3 2025 fees were penalties | Paid demand; two thirds of proved bytes were zero-filled capacity; the chain now pivots to PDP hot storage (May 2025) that earns no consensus power | Sealing cost was paid by emission, not customers; when rewards fell providers left | Yes (one seal, then a sub-second daily proof) | Yes (random leaf challenges per deadline). The only row that held both for a real good, at hours per 32 GiB | +| 8 | Chia proof of space | Chia Network, mainnet May 2021: plots of random tables, challenge per signage point | 1.5 EiB to 15 EiB in May 2021 alone, peak 36.5 EiB Jul 2021; a k32 plot needs 1.3 TiB of SSD writes; pooling Jul 2021; compression Jan 2023; under 4 EiB effective and under 3 EiB raw in Sep 2026 (about 10 percent of peak); XCH USD 1.36 against a USD 1,934.51 peak; Chia 3.0 (27 Feb 2026) resets plots to 1 GiB k28 with a 256-day phase-out | Anything stored; the space holds nothing | Price down 99.9 percent, reward per TB collapsed, no use for the plots | Yes (a few hashes) | Yes (challenge, plot filter, k). Useful: no | +| 9 | Flux, Akash | Compute markets beside a coin: Flux (2018 as ZelCash, 7,015 nodes on 5 Oct 2026 against a 14,000 peak, no published revenue in six years, "PoUW v2" Oct 2025 = hardware benchmarking); Akash (Q1 2026 lease revenue USD 253,250, 58 providers, 84 GPUs in use of 334) | Node counts, not verified work | A chain that checks the compute; InFlux Technologies entered administration 4 Sep 2026 | Block rewards pay for idle capacity; demand is two to three orders under the subsidy | No (reputation and benchmarks) | No (customers pick the job) | +| 10 | Dynex | 2022 to 2026, "neuromorphic quantum computing cloud", DynexSolve | A WIPO patent (14 Nov 2024); market cap USD 119,386, down 99.9 percent; a "phase-out of the utility token" toward a securities structure | A checkable claim: no public code shows the chain checking that a QUBO instance was solved | The useful-work claim was never made verifiable | Unknown, treat as not verified | Not sampleable | +| 11 | Qubic | 2024 to 2025 "useful PoW" (Aigarth training); from Jun 2025 the work was Monero RandomX hashing sold for QUBIC buybacks | Under 2 percent of Monero in May 2025, over 25 percent by late Jul, 51 percent claimed 11 to 12 Aug 2025; 63 of 122 blocks (3,475,729 to 3,475,850); 6-block reorg 12 Aug (about 60 orphans); 18-block reorg 15 Sep 2025 (117 transactions, past Monero's 10-block lock) | Any verification of the AI claim; no Monero consensus change by Sep 2025; miners moved to P2Pool, exchanges raised confirmations | The "useful" work was a token buyback funded by attacking another chain | The RandomX part: yes, and useless by design. The AI part: no | The AI part: no | +| 12 | Bittensor subnets | 2023 onward, validators score miners off-chain, Yuma consensus; dTAO 13 Feb 2025 | Over 120 subnets (Mar 2026); 24 with commercial income, USD 28 M to 35 M ARR estimated (Sep 2026); validator reward correlates with stake at 0.80 to 0.95, miner reward with performance at 0.10 to 0.30 (64 subnets, 6.66 M events); weight copying fixed by commit-reveal (May 2024); Quasar (SN24) collapsed Aug 2026 on a plagiarised model | Proof of anything; usefulness is judged, not proved | By design: a stake-weighted reputation market with emission attached | No (judged) | Partly (validators pick queries, no nonce, no hardness knob) | +| 13 | Proof of inference, 2024 to 2026 | Gensyn Verde (refereed delegation, about 60 percent overhead on Llama-3.1-1B, needs one honest provider); Hyperbolic proof of sampling (re-execute a fraction, slash); Ambient proof of logits (claimed 0.1 percent overhead, testnet still pending Apr 2026); Inference Labs (self-reported 950 M proofs); zkML (hundreds of seconds per query for billion-parameter models); Boundless PoVW (pays ZKC per proved cycle, a sample proof 2 to 5 min at USD 0.04 to 0.17); Succinct (over 6 M proofs in 2025, 25 provers) | Proving networks exist and are run by a few dozen operators | A job that is both random and wanted; a verifier cheaper than a referee, a chip or a slashing game | zk proving costs 10^3 to 10^4 times the inference; the cheaper schemes trust something | zk: yes at 10^3 to 10^4 overhead. The rest: only by trust | zk: yes if nonce-bound. Nobody has made the job random and wanted | + +The 2025 to 2026 literature says the same thing from three sides. The SoK (eprint 2025/1814, over 50 constructions): "PoUW is actually not as useful as expected, since the economic and societal utility do not contribute to the security budget". Pass (arXiv 2606.06700): a majority attack still costs the block reward. Basu (arXiv 2606.04819): Pearl's 24 EH/s network of about 320,000 GPU-equivalents at about 112 MW "produces zero useful AI computation". + +### 1.2 The pattern, and what Igneum finishes + +Every programme that passed both tests (cheap verify, sampleable with tunable hardness) did so by making the work useless: Primecoin chains, Chia tables, Aleo's synthesis puzzle, Filecoin's capacity sectors, Boundless cycles. Every programme that kept the work useful gave up verification: Gridcoin, Curecoin, Bittensor, Flux, Akash, Qubic, Dynex. Filecoin alone held both for a real good and paid with hours of sealing per 32 GiB and a network two thirds filler. + +**What Igneum already finishes (two rows).** + +| Row | The unfinished promise | Igneum's finished form | Evidence in the repo | +|---|---|---|---| +| 4, Aleo PoSW and Proof of Necessary Work | Energy that produces succinct proofs of real state, paid from issuance | Every block is proven by miners in chunks and aggregated 20 to 60 s behind the tip; the provers are paid 20 percent of emission by sortition by weight; the proof is of the chain's own execution, not a synthetic circuit | CLAUDE.md design paragraph; lane 4's finding 1: the proof verified in consensus is the fix for the one line where a majority earned more than it spent (11,636 IGN an hour at 51 percent of blocks); switch `proving_consensus_verify_daa` ships off by default in 0.3.16, activation a decision owed | +| 13, Boundless PoVW and Succinct | Pay per verified unit of proving, meter the cycles, let a market set the price | pgas cycle metering through the proving share; external jobs 90/10 provers and burn, priced in dollars, settled in the token | frontier.md 3.10 "PoVW-like cycle metering through pgas"; CLAUDE.md fee lines | + +**Why the split is the finished form.** The bound from `new-pow.md` 3.1 is the reason nobody closed the loop: the useful fraction of a proving-as-lottery scheme is (proving work per segment) over (network hashes per segment), 8 percent at 1 GH/s and 0.08 percent at 100 GH/s, because gas sets one and the security budget sets the other. Aleo found the same wall and decoupled on 17 Sep 2024 ("provers do not participate in consensus or produce blocks"), then had to add a stake gate in 2025 because the puzzle centralised on the fastest prover. Igneum's split carries no stake and no coupling: the lottery is a Poisson process on a random program (the Kaspa developer's objection in frontier 3.10 stays satisfied), the proving is paid by sortition by weight, and the one line where the split was NOT yet finished (a majority prover pool earning more than it spent) is closed by verifying the proof in consensus. Until that switch is on, Igneum's split is Aleo's 2024 form; with it on, it is the form Aleo could not reach without a validator set. + +**What Igneum should leave.** Rows 1 to 3, 5, 6, 9 to 12: 0 hours. The only adjacent idea with value was taken by lane 8 as scheme C (the dataset is the keyed execution state, the class v5 candidate), which answers rows 7 and 8 by making the stored thing the chain itself, at an unchanged hash rate; it is already judged and not repeated here. + +## 2. Group B: memory-hard and ASIC-resistance programmes that stalled + +The chip history is done in `asic-resistance-history.md`. This section covers only what was started and abandoned, and ends each row with what Igneum's hourly random program, latency shadow and class ladder already encode, and what they do not. + +### 2.1 The rows + +| # | Programme | What was planned | What shipped | What was left on the table | Why it stopped | +|---|---|---|---|---|---| +| 1 | Ethash successors | EIP-969 (David Stanfill, 3 Apr 2018): five FNV primes of Hamming weight 7 to 8 against the Antminer E3, fork at block 5,550,000 with 30 days' notice; ProgPoW as "Ethash 2" | Nothing on Ethereum. ETC's Etchash (ECIP-1099, Thanos, block 11,700,000, Dec 2020) halved DAG growth to keep 3 to 6 GB cards | The FNV tweak (Stagnant), the DATASET_PARENTS increase Least Authority asked for, any epoch recalibration on mainnet | No client team adopted EIP-969 for a chip expected to be short-lived; attention moved to ProgPoW; PoW ended at the Merge 15 Sep 2022 | +| 2 | ProgPoW, EIP-1057 | Hold the chip gain to 1.1x to 1.2x by saturating the whole GPU datapath (random math, 16 KB cache, DAG loads, keccak-f800) | Two audits (Least Authority 9 Sep 2019: accurate to design, five suggestions, the light-evaluation attack named; Bob Rao: 100 MB on-die SRAM "possible", DRAM 3 pJ per bit against 0.3 on chip); KawPow (6 May 2020), FiroPoW (26 Oct 2021), Zano, Sero, Quai (29 Jan 2025) | Activation on Ethereum: tentatively accepted 4 Jan 2019, "accepted and final" 21 Feb 2020, petition EIP-2538 27 Feb, kik's 64-bit-seed exploit about 4 Mar, off the fork schedule 6 Mar 2020; authors reposted it 11 May 2020 saying "we do not recommend" deployment | Governance (a revival read as stealth), the PoS roadmap, a bug two weeks after "final", the authorship conflict (Core Scientific, Linzhi's 3x to 8x claim with no evidence) | +| 3 | RandomX v2 | A tweak after seven years: program 256 to 384 instructions, 16 AES mixes in place of XOR, dataset prefetch 2 iterations ahead; work per hash up 52.9 percent (4,456,448 to 6,815,744 ops) to re-match CPU to memory latency | Library PR 317 merged 17 Feb 2026 (SChernykh); commitments PR 265 merged 8 Sep 2023 | Activation: Monero PR 10038 (v17) open since 14 Aug 2025, pending review 19 Sep 2026, no date | The chip came first: Antminer X5 Sep 2023 (212 kH/s, 1,350 W); X9 1 MH/s at 2,472 W listed as "August 2026, delayed" per resellers, unconfirmed shipping; the Qubic episode used plain CPUs so it forced no algorithm change | +| 4 | Kaspa kHeavyHash | A hash for optical hardware (Dubrovsky, Ball, Penkovsky, arXiv 1911.05193): shift cost from OPEX to CAPEX; GPU resistance never a goal; chosen by community vote one day before launch | IceRiver KS0 (100 GH/s at 65 W, 2023), then 15 to 21 TH/s boxes; GPUs at 2.2 GH/s left | A GPU lane (never planned); optical mining (no shipping hardware, approximate) | By design. The GPU fleet forked away: Karlsen (FishHash, 4 GB DAG), Spectre (CPU), Pyrin | +| 5 | Autolykos v2 | Keep the 2 GB table, grow it 5 percent per 51,200 blocks from block 614,400, cap at block 4,198,400 (2,143,944,600 elements) | EIP-0009 at block 417,792 (Feb 2021 approximate); non-outsourceability removed because contract pools bypassed it (Chepurnoy and Saxena, eprint 2020/044) and small miners did not want it | A successor to pool resistance; an answer to HBM FPGAs ("HBM FPGA friendly", Osprey listed ERGO); the growth stops at the cap | Small prize, no chip, the table cap is a policy choice | +| 6 | Grin's two lanes | Cuckaroo29 for GPUs (90 percent of reward falling to 0 over two years, tweaked every six months), Cuckatoo31+ for chips (10 percent rising to 100) | Four hard forks on schedule; HF4 (about 15 Jan 2021) ended the GPU lane; one chip shipped (iPollo G1, 36 GPS at 2,800 W, Dec 2020) | Obelisk GRN1 cancelled 19 Jul 2019 ("lack of interest and funding", full refunds); Innosilicon G32 announced, never documented shipping; the lean-solver memory claim: Tromp's USD 10,000 linear TMTO bounty claimed 11 Apr 2025 (about half an order of magnitude, not tenfold) | The schedule forced chip makers to choose between a single-use C31 chip and a late C32 chip at a USD 2 coin; network today 3.40 KGps on GPUs | +| 7 | Equihash parameter programmes | Zcash: a parameter change "ideally deployed by late 2018"; a 2020 PoW migration (ballot 3 Jul 2018: 38 of 64 for migration by 31 Dec 2020). Beam: forks at 6 and 12 months then an "affordable ASIC" (BeamHash III, 28 Jun 2020). BTG: Zhash 144,5 after the May 2018 51 percent attack (388,000 BTG) | Zcash stayed on 200,9 with chips (2019: BCTV14 forced the choice of Sapling over ASIC work); Beam stayed on BeamHash III with GPUs only; BTG forked and was hit again in Jan 2020 | Zcash's migration; Beam's affordable chip; BTG's real problem (rented hash on a small chain) | Governance by poll chose "reduce chokepoints" over resistance; parameter forks do not fix a rentable chain | +| 8 | Octopus to Ethash | CIP-102 (Chenxing Li, 5 Aug 2022): switch to Ethash "to make it easier for Ethereum miners to switch to Conflux" | Nothing; the CIP has "TBA" for specification and rationale and never left Draft | The AMD support and DAG shrink the forum asked for instead | The community called Ethash "not ASIC resistant" and Octopus "the trademark" | +| 9 | Blake3 on Alephium | ASIC friendly by design, "just like Bitcoin" | Goldshell AL-BOX (360 GH/s, May 2024 per the aggregator), Antminer AL1 (15.6 TH/s, Jul 2024); the project's own gpu-miner and fpga-miner repos stopped mattering | Nothing, by the project's own view | By design | +| 10 | Tensor PoW | Komargodski and Weinstein, eprint 2025/685: PoUW from arbitrary matrix multiplication at 1+o(1) overhead; "this blockchain is currently under construction" | A paper (15 Apr 2025, revised 8 Dec 2025). ethresear.ch has no topic matching "tensor core proof of work" | A chain; a measurement of what tensor work costs the honest card against a chip | Nobody measured it before writing it | + +### 2.2 The FPGA question, one line per row + +| Row | Was the FPGA the first adversary | What stopped it | +|---|---|---| +| Lyra2REv2 (Vertcoin) | Yes: a Zynq UltraScale+ at 31.25 MH/s and 24.93 W, 4.3x a Titan Xp per joule (arXiv 1905.08792) | A fork to Lyra2REv3 | +| X16R (Ravencoin) | Yes: all 16 hashes on one UltraScale+, about 5x a 1080 Ti per joule at 3 to 4x the price | X16Rv2 then KawPow | +| Equihash 144,5 and 200,9 | Promised in 2018 (a vendor asked a USD 1,000,000 minimum order), no hashrate ever posted | The 2.5 GB table; HBM boards matched GPUs per dollar at best (approximate) | +| Ethash and ProgPoW | HBM boards existed in 2019; Least Authority: a 10-block period makes "building and loading a bitstream in such a short period (about 2 minutes) impractical" | DRAM latency on cheap boards, HBM cost on fast ones, bitstream churn | +| Autolykos v2 | Osprey listed ERGO on an 8 GB HBM board; no share figure published | Nothing stopped it; nothing measured it | +| kHeavyHash | Osprey E300, 14 GH/s at 250 to 500 W, USD 4,999, three VU35P with HBM2, announced 13 Dec 2022 | Overtaken within months by 100 GH/s to 1 TH/s ASICs | +| RandomX, Cuckoo | No FPGA product ever shipped | A CPU-like core with 2 MB per thread; 512 MB to 1 GB of fast memory per graph | + +### 2.3 What Igneum already encodes, and what it does not + +| Row | Encoded in Igneum (where) | Not encoded (the gap) | +|---|---|---| +| 1 Ethash successors | A dataset that grows on a genesis-fixed schedule with the cache doubling (256 MiB, 512 MiB year 4, 1 GiB year 12); the 4 GB cliff lesson lives in the tier rule ("every number carries its consequences", 8 GB to 32 GB cards); EIP-969's human tweak against a chip is replaced by automatic era draws | The DATASET_PARENTS idea is Igneum's mixer x8 (8 dependent reads per item), which has the fixed shape the chip history calls the 3x factor; the random item derivation (asic-history addition 2) is still open | +| 2 ProgPoW | The governance death is designed out: every layer is a genesis rule or a reserve, no adoption vote (asic-history lesson 7); the 64-bit-seed class: Igneum's seed is 256 bits and the program is the epoch's; the light-evaluation attack is priced (chip-model-v3, 0.31x bare, 0.92x with the 3x factor); the datapath target is the whole GPU | ProgPoW's 2-minute period was its FPGA defence; Igneum's epoch is 1 h, so a soft-overlay bitstream within the hour is the open lane (asic-history addition 5, the 10 min to 2 h epoch reserve, design on `ca2-epoch`) | +| 3 RandomX v2 | The lesson is that a tweak after seven years arrives after the chip. Igneum draws era parameters every 6 months from chain state and unlocks families by height, with no human release; the class ladder (95 percent with a floor height, P2) is the only human path and it is for new code, not for parameters | Per-hash program entropy (RandomX's 25x GPU cost, refused on purpose); the random superscalar item derivation; four external audits before launch (RandomX paid USD 141,000; Igneum's cryptanalysis spend of USD 80,000 to 160,000 is a decision owed) | +| 4 kHeavyHash | The loss of the GPU fleet is the metric: hashrate share by card model from the observer and the January 2027 benchmark (asic-history addition 4) | A published vendor-share number does not exist yet | +| 5 Autolykos v2 | Pools are wanted (spec 09), so non-outsourceability is nowhere by choice; the dataset grows by rule | Whether Igneum's growth schedule ever caps is a spec 1.13.3 question this lane did not reopen | +| 6 Grin | Scheduled change without a vote is the shared idea; Igneum's draws are automatic, Grin's were forks | The lean-solver lesson (a memory claim weakened six years later by a bounty) is the reason the mixer and chained cache need cryptanalysis (ledger M7) | +| 7 Equihash | The rented-hash problem is answered by the 30-day weight finality, not by the hash (section 4) | Nothing | +| 8, 9 Octopus, Blake3 | Nothing to take | Nothing | +| 10 Tensor PoW | Measured and retired: scheme B's mm8 shadow costs the honest card 0.056 to 0.70 pJ per multiply-add and moves the chip's edge only from 6.9x to 4.9x, so it is reserve R8 with the two-output correction (new-pow.md 6) | Nothing; Igneum did the measurement the 2025 paper has not | +| FPGA, all rows | Bitstream churn is encoded as the hourly program; the HBM board is the f = 1 stored-dataset chip in the model (5.1x on GDDR7, 7.5x to 9.2x on HBM3) | The soft-overlay FPGA miner with HBM is unmeasured (addition 5); no row in the chip model for a partial-store chip (addition 1) | + +Verdict for the group: nothing in B is a programme Igneum should restart. The three unfinished items that do matter are Igneum's own open rows (random item derivation, external cryptanalysis, the epoch-length and FPGA-overlay measurement) and they are already ranked in `asic-resistance-history.md` 4.3. + +## 3. Group C: merged mining and multi-algo + +### 3.1 The rows + +| # | Programme | When, by whom | What it bought (numbers) | The attacks and the costs | Left undone | +|---|---|---|---|---|---| +| 1 | Namecoin AuxPoW | Block 19,200, Oct 2011 (vinced; Mike Hearn's outline) | Bitcoin's hashrate for free: about 95 percent of Bitcoin on 12 Jan 2020, about 69 percent (732 EH/s) in Sep 2026; nine pools find blocks (AntPool 34.78 percent, F2Pool 19.99, ViaBTC 19.69, 14-day window to 20 Nov 2025) | One pool (F2Pool) above 50 percent of Namecoin for most of late 2014 to 2016 (approximate; Judmayer et al.: pools "operated at the edge of, and even beyond, the security guarantees" of Nakamoto consensus); the spec's nonce-clash flaw is documented and a replacement BIP never came | Independence: the child's rules are signalled by the parent's pools; Foundry, the largest Bitcoin pool, does not merge-mine it; the name market never grew | +| 2 | Dogecoin on Litecoin | Hard fork at block 371,337, Sep 2014, after Charlie Lee's Apr 2014 proposal; Dogecoin's own words: "our hashrate has been on a decline" | Hashrate up over 1,500 percent in Sep 2014; DOGE and LTC hashrates correlate at 0.95; about 90 percent of DOGE hashrate from Litecoin pools by 2019; DOGE's share of pool revenue "has long surpassed" Litecoin's (F2Pool data, 7 Apr 2026) | A pool above 50 percent of Litecoin is above 50 percent of Dogecoin by construction | A miner base of its own; any say in the parent's rules | +| 3 | Myriadcoin and Verge multi-algo | Myriad 23 Feb 2014 (five algos, per-algo floating difficulty, 20 percent of blocks each); Verge (five algos) | Hardware diversity | Verge, Apr 2018: timestamps spoofed about an hour back on the Scrypt lane, per-lane difficulty collapsed, blocks seconds apart, 250,000 to about 20 M XVG (reports conflict); 22 May 2018: Scrypt and Lyra2re both at near-zero difficulty, about 25 blocks a minute, 35 M XVG (about USD 1.8 M); the hard fork between them did not remove the bug; a 560,000-block reorg in Feb 2021 (headline only) | Five lanes made the surface five times wider; each lane is cheaper to rent than the whole | +| 4 | DigiByte MultiShield, Odocrypt | DigiShield Feb 2014 (block 67,200), MultiAlgo Sep 2014 (145,000), MultiShield Dec 2014 (400,000), Odocrypt Jul 2019 (9,112,320): per-block retarget on all five lanes from a 10-block average, clamps 16 percent down and 8 percent up; Odocrypt rewrites itself every ten days for FPGAs | DigiShield was adopted by Dogecoin (1.6, Mar 2014) and Zcash (v3 variant, approximate); the "93 percent on one algo and 51 percent on the other four" claim is a model, not a measurement | 28 Jun 2026: a dropped validation rule on the Groestl lane let about 1,356 blocks (about 351,000 DGB) be mined, no double spend | A lane with little hashrate still mints one block in five; the ten-day rewrite assumes FPGA owners re-flash and does nothing against a party with many FPGAs | +| 5 | Elastos, RSK | Elastos with Bitmain 28 Aug 2018 (AntPool, BTC.com); RSK since Jan 2018 (approximate) | Elastos "over 50 percent" of Bitcoin's work (13 Mar 2024); RSK 62.46 percent (Q1 2024), 54.58 (Q3), 56.40 (Q4 2024, AntPool 38.6, ViaBTC 24.3, F2Pool 16.9); Foundry joined | RSK's Armadillo (RSKIP110): detects forks up to about 448 blocks when the attacker has under 9 percent of Bitcoin; "cannot stop a miner creating a blockchain from a past point"; the PowPeg is a federation with HSMs | The attacker rents or bribes three pools, not hardware; Armadillo alerts, it does not finalise; usage stayed small so fees stayed small | +| 6 | The paper | Judmayer, Zamyatin, Stifter, Voyiatzis, Weippl, "Merged Mining: Curse or Cure?", eprint 2017/791 | One line: merge-mined chains concentrate in fewer pools than the parent, with single pools above 50 percent for months in Namecoin, Huntercoin and Myriad (approximate for the per-coin detail) | | | + +### 3.2 Verdict: does Igneum want any of it + +No, with four reasons. Igneum's ruling is already "no reliance on another chain"; the question left is whether an Igneum-side auxiliary chain or an "algo slot" has value, and it does not. + +| Option | What it would buy | Why not | Hours | +|---|---|---|---| +| Igneum as a merge-mined child of another chain | Borrowed hashrate | Ruled out (CLAUDE.md: no other chain in consensus); and the rows show the child inherits the parent's pool concentration and loses its say in rules | 0 | +| Igneum as a parent for other chains | Nothing for Igneum; a coinbase commitment slot for others | The hash is a new program every hour, so a child cannot verify Igneum work without Igneum's program pipeline, VDF seed and dataset; the vote key per operator would not carry to the child; the only cost is a header field nobody asked for | 0 until asked | +| An algo slot (a second hash lane) | Hardware diversity | Myriad, Verge and DigiByte show each lane is a separate difficulty controller and a separate rentable surface; Igneum's 30-day vote weight is counted in blue blocks of ONE work unit, so a second lane splits the weight table and the DAA; GHOSTDAG's k is derived from one block rate on one hash | 0 | +| A share sidechain merge-mined through the coinbase | A pool without an operator | This is the one merged-mining shape with value, and it belongs to section 5 (it is how Monero P2Pool works) | see 5.3 | + +## 4. Group D: GPU-friendly finality attempts + +The one axis asked: can a renter buy or break finality in a day? Igneum's rule for comparison (CLAUDE.md, finality rule v2): vote weight = blue blocks per vote key over a flat 30-day window, lock at 2/3 of all 30-day weight, so 10 days of 100 percent hashrate reach 1/3 of weight and 20 days reach 2/3; 51 percent never reaches 2/3 while honest miners stay. + +### 4.1 The rows + +| # | Programme | Attempted | Finished | Left undone | Renter buys finality in a day? | +|---|---|---|---|---|---| +| 1 | Decred hybrid | Feb 2016: tickets vote on every block, 3 of 5 called tickets must sign; 40,960 ticket pool, 28-day average wait | A PoS veto on every block, stakeholder-voted forks, a treasury; stake locked rose from 50 percent (Dec 2019) to 64 percent (Dec 2022) while hashrate fell about 6x; DCP-0011 (BLAKE3 and ASERT) and DCP-0012 (PoW to 1 percent of subsidy) active at block 794,368 (Aug 2023) because PoW was "used to maliciously manipulate Decred markets" | No finality gadget; PoW is a 1 percent stipend | No for reorgs (needs about half the live ticket pool, roughly 30 percent of DCR bought over 28-day cycles, approximate); yes for withholding and censorship, since the hash layer is thin | +| 2 | Horizen delayed-block penalty | After the 2 Jun 2018 51 percent attack (over USD 500,000, 36 fake blocks): a block n late owes about n(n-1)/2 extra blocks (approximate formula); shipped in ZEN 2.0.16, late 2018 | A reorg tax on hidden chains | Partition safety: the smaller honest side looks like a hidden chain; Horizen now calls itself an L3 on Base and the PoW mainchain is winding down (approximate) | Yes under 5 blocks and for public mining; a deep secret reorg costs quadratically more. A tax, not finality | +| 3 | Kaspa merge depth and finality depth | MERGE_DEPTH_DURATION 3,600 s, FINALITY_DURATION 43,200 s, PRUNING 108,000 s in rusty-kaspa constants; at 10 BPS since Crescendo (about 5 May 2025): merge depth 36,000 blocks, finality depth 432,000 | Online nodes refuse a reorg deeper than 12 hours; a block cannot merge a side chain older than an hour | Both rules are local and subjective; a node syncing later follows the heaviest DAG; DAGKnight (eprint 2022/1494) is in PRs (1104, 1124, 1132) and not on mainnet | Partly: under 12 hours yes with over 50 percent of an ASIC-only hash (thin rental supply); over 12 hours the attacker splits the network instead | +| 4 | Conflux Tree-Graph, GHAST, PoS votes | GHAST (arXiv 2006.01072): confirmation in O(d log 1/epsilon), about 3d against about 360d for six Bitcoin blocks; adaptive weight switches to a conservative mode under a liveness attack | CIP-43 (Hydra, about 28 Feb 2022): a PoS chain of staked CFX (1,000 CFX per vote) votes on pivot blocks "to protect against 51 percent attacks from PoW" | GHAST alone is probabilistic; the PoS committee is the finality | No for finalised pivot blocks; yes inside the trailing minutes | +| 5 | Ethereum Casper FFG over PoW | EIP-1011 (20 Apr 2018): 1,500 ETH minimum deposit, 50-block epochs, "never revert finalised blocks"; testnet 31 Dec 2017 | Nothing on mainnet; the Berlin Eth2 workshop (Jun 2018) discarded hybrid Casper for the beacon chain | The hybrid itself | Under the design: no for finalised checkpoints (slashing two thirds of deposits), yes inside an epoch. Dropped because "the limited bandwidth of the EVM constrained the size of the validator set", forcing whale-sized deposits | +| 6 | Bitcoin Cash Avalanche pre-consensus | Sechet, Sep 2018 (approximate) | On BCH: nothing. On eCash (XEC): post-consensus finality 14 Sep 2022, staking rewards 15 Nov 2023, pre-consensus 15 Nov 2025 at block 923,347 ("finalise transactions in under 3 seconds"); staked XEC 69.4 B to 242 B in the year to Jul 2024, 350 B+ by Jul 2026; 33 to 94 nodes; 100 M XEC minimum per stake UTXO with 2,016 confirmations | BCH never got it; no slashing (approximate); on quorum loss the chain falls back to heaviest work | No while the quorum holds; yes if the attacker knocks the about 94 Avalanche nodes offline | +| 7 | Ethereum Classic MESS | ECIP-1100, active at block 11,380,000 (Oct 2020) after three Aug 2020 reorgs (3,594, 4,446 and 7,278 blocks; 807,000 and 465,444 ETC double spent): a capped polynomial, up to 31x the local chain's difficulty for a segment older than about 7 hours | No deep reorg on ETC after Oct 2020 (approximate) | Deactivated by ECIP-1110 at block 19,250,000 (Spiral, Jan 2024) because "the costs now outweigh the risks"; Core-Geth v1.13.0 (15 Sep 2026) re-enabled it with 96 unreviewed commits, miners rolled back the same day, PR 53 (merged 6 Oct 2026) restored the deactivation | With MESS on: no for reorgs older than 7 h, yes for short ones, and an eclipse strands a victim. Off today: yes, plain PoW | +| 8 | Zcash trailing finality layer, Crosslink | ECC's TFL book (2023, Wilcox and Hopwood); Shielded Labs builds zebra-crosslink, "a proposed upgrade"; BFT PoS finalises a trailing prefix, PoW continues if BFT stalls | An incentivised feature net; milestone 4 of 5 in early 2026 (search summaries) | Mainnet: nothing by 7 Oct 2026 | Today: yes (plain Equihash, rentable, approximate). Under Crosslink: no for finalised blocks, yes inside the trailing window | +| 9 | Nervos CKB | NC-Max (eprint 2020/1101): two-step confirmation, 3.0 to 6.6 times shorter latency; Eaglesong "ASIC neutral", first chip four months after launch | NC-Max runs since launch | No finality layer; no hybrid plan | Yes in principle; ASIC-only supply is thin | +| 10 | Dash ChainLocks, Syscoin, Komodo | Dash DIP-0008 since block 1,088,640 (Jun 2019): an LLMQ of 300 to 400 masternodes signs the first block seen, 240 signatures lock it; Syscoin copied it over Bitcoin merged mining (4.2.0, block 1,004,200, 30 Apr 2021); Komodo notarises to Bitcoin then Litecoin every 10 to 25 minutes through 64 elected notaries | Finality in about one block (Dash) | A second validator set bought with coins (1,000 DASH per masternode, approximate) or elected (Komodo's 64) | No for locked blocks | + +### 4.2 The comparison on the one axis + +Every finality on a PoW chain that holds in practice is a second validator set paid in coins: Decred tickets, Dash and Syscoin masternodes, eCash stake, Conflux PoS, Komodo notaries, Casper FFG's 1,500 ETH deposits. Every rule that only reweights work (Horizen's penalty, MESS, Kaspa's 12-hour depth) is subjective and partition-sensitive, and two of the three have been switched off or are winding down. + +Igneum is the only design in the table whose second set is the miners themselves, weighted by past blocks, with no coins staked. On the one axis: + +| Attacker | Decred | Kaspa | MESS (on) | eCash | Igneum | +|---|---|---|---|---|---| +| Rents 100 percent of hashrate for one day | Withholds, cannot reorg | Reorgs up to 12 h | Reorgs up to about 7 h | Nothing while the quorum holds | Reorders inside the 90-second window (horizon 1, finding 3), nothing past a certificate; has 1/30 of a window's weight at the end of the day, needs 2/3 | +| Rents 100 percent for 20 days | Same | Splits the network | Same as above | Same | Reaches 2/3 of weight only if every honest miner has left; with honest miners staying, 51 percent never reaches 2/3 | +| Buys coins | Buys tickets over 28-day cycles | n/a | n/a | Buys stake | Nothing; weight is not for sale | + +What is unfinished in Igneum's own finality is Igneum's, not the industry's: the signed LEAVE item (0.3.16) after the 6 October pause (42.7 percent of the frozen voter table left in three minutes and the pause held a window), the 10-percent-per-hour removal rule, weight-gated deep fork choice and vote-or-burn (horizon 1, findings 2 and 3). The one lesson this group adds: every subjective reweighting rule was eventually turned off by its own chain (MESS twice), so the "no hidden-block n^2 penalty" removal in Igneum's rule v2 was the right side of the history. + +## 5. Group E: decentralised pools + +### 5.1 The rows + +| # | Programme | When, by whom | Design | What it achieved (numbers) | Why it stalled or died | Left undone | +|---|---|---|---|---|---|---| +| 1 | Bitcoin P2Pool | Forrest Voight, 2011 | A share chain with a 30-second share period; window = shares worth 3 blocks of work or 8,640 shares (72 hours), whichever is smaller; the generation transaction pays the window; 0.5 percent to the finder, no operator | 350 GH/s in Apr 2012 (about 2 to 3 percent of Bitcoin, approximate); 1.4 TH/s by Jul 2013; today 915 TH/s on 14 payout addresses (about 0.0001 percent of about 950 EH/s, my division); last commit 19 Sep 2018 | Variance for small miners (a small miner rarely lands a share in the window), dust (one output per miner per block), a 20x faster chain so stales are "common and expected", a 2012 orphan flaw, a Python 2 node on a full bitcoind | Payout aggregation, per-miner vardiff inside the chain, a maintained node (c2pool's C++ rewrite says "v37 is design-stage, do not run in production") | +| 2 | Monero P2Pool | SChernykh, Aug 2021 | A sidechain merge-mined with Monero: 10-second blocks, PPLNS up to 2,160 blocks (6 hours), uncles at 20 percent less, payouts in the Monero coinbase, 0 percent fee, about 0.00027 XMR minimum, every miner runs monerod; three chains (main, mini, nano since v4.7, 30 May 2025); Tari merge mining since the 12 Oct 2024 fork | Today: main 441 MH/s and 561 miners, mini 25.3 MH/s and 1,997, nano 4.8 MH/s and 962; 471 MH/s and 3,520 miners in all, 7.7 percent of 6.13 GH/s (my division); against SupportXMR at 2.35 GH/s (38 percent) and HashVault at 672 MH/s (11 percent); the Monero GUI bundles it | A local node is mandatory; below about 15 MH/s of pool hashrate "not all shares will result in payouts"; three chains fragment the hashrate; share has fallen from double digits (approximate) to 7.7 percent | A light mode; cross-chain vardiff; payout smoothing for mini and nano miners | +| 3 | Stratum V2 | Braiins (Moravec, Capek) with Matt Corallo, 2019, from Corallo's BetterHash draft (12 Mar 2018, never past specification) | Binary, Noise-encrypted; Mining, Job Declaration (renamed from Job Negotiation) and Template Distribution sub-protocols; the SRI translation proxy | SRI v1.0.0 tag 23 May 2023, v1.12.0 17 Sep 2025; native V2 pools: Braiins (JD "since about 2020"), DEMAND (public Nov 2025), ckpool (31 Jul 2026); firmware: Braiins OS, Bitaxe ESP-Miner v2.14.0 (Jun 2026), Auradine; stock Antminer and WhatsMiner are V1 only; the first known Job Declaration block is 955,318 on 25 Jun 2026 (DMND, GoMining's template); seven pools holding about 75 percent of hashrate joined the working group on 7 May 2026 "still in testing" | No primary number for SV2 hashrate; the two V2-native pools mined 753 and 1 of 52,297 blocks in the last year, so under 2 percent on SV2 at all and far under 0.1 percent on JD (approximate conclusion) | Stock firmware, JD at any top-five pool, Windows template building ("not yet supported"), a payout scheme that rewards miner-built templates, any measurement of adoption | +| 4 | Braiins Pool | Slush Pool, Nov 2010; the first anti-hopping score (Rosenfeld 2011, section 3.1) | FPPS "0 percent fees with Braiins OS", 2 percent otherwise; on-chain or Lightning payouts | 13.91 EH/s, 177,359 workers, 13,112 users today; 753 of 52,297 blocks (1.44 percent) in the last year | The oldest pool and the SV2 author holds 1.4 percent | SV2 adoption did not become hashrate | +| 5 | Ocean | Luke Dashjr, 28 Nov 2023, USD 6.2 M seed led by Jack Dorsey | TIDES: a share log eight times the difficulty deep, each share rewarded about eight times, 99.9665 percent chance of at least once, paid in the coinbase itself; DATUM (29 Sep 2024): the miner runs a gateway and a full node and builds its own template, 50 percent fee discount (2 percent, 1 percent with DATUM) | First block's coinbase came from a test server and paid nobody (4 Dec 2023 post-mortem); today 28.97 EH/s, 2,522 users, 1,553 blocks of which 1,316 DATUM (85 percent, my division), 1,073 of 52,297 blocks (2.05 percent) in the last year; Tether committed hashrate Apr 2025 | The template fight: Bitcoin Knots filtered inscriptions and Samourai transactions at launch; Dashjr resigned 29 Aug 2026 after the "mining divide" | A single operator still runs TIDES accounting, share verification and the generation transaction; non-DATUM miners get the pool's policy | +| 6 | DEMAND | Guru Protocol Ltd (company 15235937), Alejandro De La Torre; launched Mar 2025 on the SRI, public Nov 2025 | "The world's first Stratum V2 mining pool"; SLICE pays subsidy by hashrate and fees "by the value you built"; Rootstock merge mining | 1 block in 19 months | Scale | SLICE at size | +| 7 | Kaspa pools | Today: 334.9 PH/s; F2Pool 98.14 PH/s (29.3 percent), HumPool 92.95 (27.8), ViaBTC 37.89 (11.3), K1Pool 16.74 (5.0), WhalePool 13.67 (4.1); top two hold 57 percent | All PPLNS or PPS+ with 0.5 to 4 percent fees | No non-custodial or P2Pool-style pool; solo bridges only (K1Pool Solo, Kaspa-Pool SOLO, HeroMiners SOLO); no pool page explains which DAG blocks pay (approximate: blue blocks in the mergeset, red blocks earn nothing) | n/a | A decentralised pool on a DAG chain has never been built | +| 8 | SmartPool | Luu, Velner, Teutsch, Saxena, eprint 2017/019, USENIX Security 2017 | Shares in batches ("1 transaction can claim 1 million shares") in an augmented Merkle tree; the contract samples k random paths; a caught cheater is paid nothing | ETC first ("over 30 blocks"), Ethereum closed beta Jun 2017; 105 blocks across both, peak 30 GH/s from 2 miners (about 0.05 percent of Ethereum, approximate); cost 0.6 percent of block rewards in transaction fees | Gas prices rose about ten-fold in 2017 and the claim cost passed the fee it was meant to beat; the beta never opened; the team founded Kyber; PoS removed the target (all approximate: smartpool.io is dead) | Any successor with hashrate; the opposite approach (Autolykos v1's non-outsourceable puzzles) was bypassed with collateralised contracts (eprint 2020/044) and removed | +| 9 | Non-custodial on GPU chains, 2024 to 2026 | Ravencoin: 2Miners 292.67 GH/s with "51 percent of recent blocks", Hiveon 621 GH/s, no P2Pool; Ergo: 2Miners 303.14 of 491.76 GH/s (61.6 percent), no P2Pool; SoloPool.org sells solo mining at 1.5 to 2 percent "no pool wallet, no balances" | | Outside Monero every "non-custodial" offer is solo with a stratum bridge, not pooled variance reduction | | | + +Share verification cost, from the sources: a Scrypt proxypool spends "around 50 percent of the server's CPU time" checking shares; RandomX light mode on an i9-9900K verifies 1,160 H/s on 16 threads, so a core checks about 70 shares a second (fast mode about 700); Bitcoin SHA256d is microseconds per share (approximate, 10^5 to 10^6 per core). Igneum's pool v0 checks every share on the CPU warp verifier at 1.35 ms isolated and 2.1 ms under load, 480 to 740 per core (`pool.md` section 5), which is RandomX-fast-mode class, 1,000x a SHA256 share. + +The payout pattern: FPPS won on Bitcoin because large pools carry variance and sell certainty (Foundry about 30 percent, AntPool about 19, ViaBTC 14, F2Pool 10, d-central 2026); every non-custodial design (P2Pool, Eligius CPPSRB, TIDES, SLICE) is PPLNS-shaped because a coinbase cannot pay a debt. That is the structural reason non-custodial pools stay small, and it is the reason Igneum's pool is PPLNS. + +### 5.2 What Igneum's pool lacks against the best of these + +Igneum's pool v0 (`docs/plans/pool.md`, spec 09): newline JSON over plain TCP, mode A templates, every share CPU-verified, PPLNS over 2 blocks of weight, 1 percent fee, payouts by EIP-1559 transfer from the pool's coinbase key after blue confirmation, `state.json` every 15 s, the member's vote key in every header it hashes, the pool holds no key, the member checks seeds, class and era against its own node. + +| Axis | Best in the field | Igneum v0 | The gap | +|---|---|---|---| +| Operator trust for payout | Monero P2Pool and TIDES pay in the coinbase itself; nobody holds a balance | The operator holds the 80 percent in its coinbase address and pays by transfer at most 16 per round; a crash loses up to 15 s of shares; a dishonest operator can misaccount or withhold | The whole of the trust. Mode C (declared templates) and vote carriage are designed, not built; neither removes the operator from payout | +| Operator trust for template and vote | DATUM and SV2 Job Declaration let the miner build the template; neither touches governance | The member's vote key rides in every header (no Stratum pool does this); mode C is designed, not built | Transaction choice is the pool's in mode A; the vote is already the member's | +| Variance | P2Pool main: 6-hour window, 561 miners; Ocean: a window 8 difficulties deep | PPLNS over 2 blocks of weight at 1 block a second: a 2-second window of work. Each share is 2^-s of a block, so a 100 MH/s card at one share per 10 s is paid on every block it has a share in | The window is short because blocks are frequent; variance is a block-time question, not a pool question, and v0 has no number for the income variance of a 100 MH/s member at devnet scale | +| Share verification | Full recompute everywhere; sampling at high difficulty (spec 9.8 item 5, allowed above shift 8, not built) | 1.35 to 2.1 ms per share, one core per 480 to 740 shares a second, no sampling | One template fetch per member per second is the real limit: 1,000 members is 1,000 `getBlockTemplate` calls a second and 10 MB/s (pool.md section 3) | +| Transport | SV2 Noise encryption, binary framing | Plain TCP, `binding` sent empty, against spec 9.3's TLS 1.3 | Q67 (polish 3.6): 8 hours | +| Stats and alerts | 2miners charts, offline alerts, luck | 15-minute samples not persisted, no `/metrics`, no payout history on the page, luck defined inverted | Q68 to Q73: about 17 hours | +| Finality | No pool in the field has a finality concept | Pays on blueness, says nothing during a pause | Q73: 1 hour | + +### 5.3 "Shares as first-class protocol objects, no operator": already in Igneum, partly + +| Piece | In Igneum already | Where | What is new | +|---|---|---|---| +| Governance weight follows the hasher, not the pool | Yes: the vote key per operator in the header (spec 9.6), pool concentration is not vote concentration | spec 2.2 fork point a5, spec 9.6 | Nothing; this is further than SV2 or DATUM went | +| An operator-less payout by weight | Yes for the 20 percent: the proving share is paid by sortition by weight from consensus data, no operator | CLAUDE.md, `executor.rs` (pool.md "The 20%") | Nothing for provers | +| A share the chain can see | No: a share is a pool message, verified by the pool, paid by the pool | spec 9.8 | This is the new thing | + +The finished form is Monero P2Pool's, not SmartPool's. SmartPool's on-chain claims died on gas at Ethereum's share rate; at Igneum's 1.35 ms per share verification, a contract that samples k paths per million-share claim would still need the zkEVM to re-derive the program's warp unit per sampled share, which is the one cost the design keeps off the chain. A share sidechain merge-mined through the coinbase extra data is the shape that works: Igneum's coinbase already carries the member's key reveal and the pool's address (pool.md section 2), so the commitment slot exists. + +| Finish | What it is | Hours (agent) | Gate | +|---|---|---|---| +| A P2Pool-style share sidechain in the pool crate | Shares form a 10-second chain committed in the coinbase extra data; the window's payout is the block's own coinbase split (the execution layer already credits by rule from consensus data for the 20 percent, so the 80 percent split follows the same path); no balance, no operator key; every member runs a node (the design already assumes one, spec 9.1) | about 40 (sidechain 16, coinbase split in the executor 8, member client 8, Devnet 2 crossing 8) | a 3-node fast-time network pays a window with no operator; an operator that drops every share from one member cannot stop that member's payout | +| Mode C declared templates | The miner builds the block (DATUM, SV2 JD) | 6 (O-9.4 RPC 2, messages 4) | a declared template is paid like any other | +| TLS and the `binding` field | spec 9.3 | 8 (Q67) | a replayed `authorize` on a second connection is refused | + +The verdict for the group: finish the share sidechain, because it is the one unfinished thing in the field that Igneum's existing objects (vote key in the header, coinbase extra data, execution-layer credit by rule, a node per member) make cheap, and nobody has built one on a DAG chain. + +## 6. Group F: mining app UX and the "one click" promise + +### 6.1 The rows + +Minutes to first share are approximate unless a source is named; they count from the download to the first accepted share on a fresh machine with a driver installed. + +| # | Product | Install to first share (min, approximate) | Custody | Fee | What it did that nobody else has | What it left undone | State 2026 | +|---|---|---|---|---|---|---|---| +| 1 | NiceHash (2014; QuickMiner 2020, approximate) | 5 to 10 | NiceHash wallet, BTC only; 2.5 M users (infobox) | Seller 2 percent, buyer 3 percent (approximate); BTC deposits at or above 0.00005 BTC free, Lightning free above 0.0000001 | A hashpower marketplace: the miner never picks a coin | Custody: 6 Dec 2017 spear-phishing hack, about 4,700 BTC (USD 64 M), Lazarus indicted 17 Feb 2021; repayment completed Dec 2020 (approximate); no node, no wallet of the user's own | Alive | +| 2 | HiveOS (2017) | 20 to 40 (flash an image on a second machine or drive, make a web account) | Hiveon pool pays the user's wallet | 2 workers free (3 days of stats); USD 0.50 per card per month to USD 3.00 at 6 or more cards; ASIC USD 2 or free with Hiveon firmware; 10 to 50 percent off at 50 to 1,000 workers | Farm-scale remote management, charts over hours, Telegram and Discord alerts, per-GPU clocks | A second machine or a flash drive; a web account; no local-only mode, no wallet, no node | Alive | +| 3 | Minerstat, Awesome Miner | 15 to 30 | User's pool and wallet | minerstat free to 2 rigs, about USD 1.46 per rig per month on larger plans (approximate); Awesome Miner free to 2 miners, paid from about USD 4 per month (approximate) | Awesome Miner: "up to 200,000 ASIC and 25,000 GPU miners" from one Windows console | Management only; no node, no wallet, no pool | Alive | +| 4 | Salad (2018) | 5 | Salad Balance, redeemable for PayPal, gift cards, games | Not published | Gaming-PC "earn while idle"; 450,000+ GPUs since 2018; 16,000+ daily active GPUs in 190+ countries today | Mining itself: the site no longer mentions crypto; SaladCloud sells GPU-hours from USD 0.015; the user's take rate is not disclosed; payout in gift cards for years | Pivoted to a compute marketplace | +| 5 | Honeyminer (2018) | 3 to 5 | Honeyminer balance, paid in BTC | 8 percent for one GPU, 2.5 percent for two or more (approximate) | The first "download, sign in, earn" miner with no settings | Everything else; the site refuses connections on 7 Oct 2026 | Dead (about 2020 to 2021, approximate) | +| 6 | Cudo Miner (2017) | 5 to 10 | Cudo balance | 1.5 to 3 percent by tier (approximate) | Profit switching on Windows, macOS, Linux | The pivot to Cudo Compute (cloud GPU); docs host unresolvable on 7 Oct 2026 | Pivoted | +| 7 | Kryptex | 5 ("Download, Launch, Earn"; first payout 1 to 8 hours) | Kryptex balance; withdraw BTC, USDT, ETH, USDC, LTC, BNB, TRX, Volet, Amazon gift cards; 0.00025 BTC minimum | "A small pool fee", unstated | "153,000 GPU and ASIC miners", "10 million+ downloads"; the pool: BTC 4,945 miners at 6.63 EH/s, XMR 37,576 miners at 1.08 GH/s; PPS+ | A balance, not a wallet | Alive | +| 8 | unMineable | 5 to 10 | unMineable balance, paid in 80+ assets | 1 percent, 0.75 with a referral code (approximate) | Mine any algorithm, be paid in any coin | A balance; conversion risk; no node | Alive | +| 9 | Bitcoin Core "generate" (2009 to 2016) | 0 (one setting) | The user's own wallet, in the node | None | Node, wallet and miner in one process, the only time it has shipped at scale | Removed in 0.13 (2016) once GPUs and chips made it pointless | Dead | +| 10 | Monero GUI mining | 0 after sync (Advanced, Mining, Start mining; thread count; local node required) | The user's wallet | None | A wallet with the daemon's CPU miner, and P2Pool bundled and updated per release (nano sidechain 26 Aug 2023, P2Pool 4.18.1 on 6 Oct 2024); the nearest shipped "node plus wallet plus miner" | The GPU (RandomX is CPU work); no tuning, no alerts; the sync wait | Alive | +| 11 | Kaspa community miners, the big three | 5 to 15 (a command line, a pool, an address) | The pool's | lolMiner 0.75 percent kHeavyHash, 1.0 Karlsen, 0.7 Ethash, 1.5 Autolykos (v1.96a); BzMiner 1 percent most algorithms, 0.5 ETC, 2 on Pearl and Quantus (v100.45, Windows, Linux, macOS arm64, Docker); GMiner 1 percent kHeavyHash, 2 Ethash and KawPoW, 5 Cortex, "charged continuously"; T-Rex 1 percent (2 on Octopus and Autolykos), 730 open issues, no release date shown; NBMiner 1 to 3 percent, last release 42.3 on 2 Sep 2022 | The per-GPU accepted, rejected, invalid and fault line; kernel speed | No node, no wallet, no tuning against a goal, no signed updates; two of the big three stopped in 2022 (approximate for T-Rex) | lolMiner, BzMiner, GMiner alive; T-Rex and NBMiner stale | + +Nobody in the table ships a miner that is also a verifying node and a wallet with a GPU worker: Bitcoin Core did it for CPUs in 2009 and removed it in 2016; the Monero GUI does it for CPUs with P2Pool bundled; every GPU miner is a kernel plus a pool address, and every "one click" app is a custodial balance. + +### 6.2 Ember against the field + +Ember's state is from `polish.md` 3.1 and 3.10: a Rust engine runs `igneumd` and one GPU worker per card, serves a tokenised local dashboard, Welcome, Cards, Address, the one-time key sheet, Start mining; Ember Tune measured 37 to 41 percent more hashes per watt on PC 1; signed, hash-checked, rolled-back updates with a safe-moment rule; no dev fee in pool mode, a 1-in-100 template solo; pool mode is design only (pool.md section 7). + +| Axis | The field's best | Ember today | Past or behind | +|---|---|---|---| +| Node, wallet and miner in one process, GPU | Nobody (Monero GUI for CPU) | Yes: `igneumd`, the worker, the key and the address in one app | Past | +| Custody | Direct-to-wallet only at P2Pool and HiveOS; every one-click app holds a balance | The coinbase pays the user's own address; the vote key never leaves the machine | Past | +| Governance | Nobody | The vote key in every header the card hashes | Past | +| Updates | Unsigned zips (the kernel miners); NiceHash and HiveOS auto-update inside an account | Ed25519-signed manifests, sha256, staged, rolled back after 90 unhealthy seconds, a safe-moment rule | Past | +| Tuning | HiveOS per-GPU clocks by hand; Nanominer's watchdog | A goal with the money consequence on screen, hill climb, 37 to 41 percent per watt | Past | +| Fee | 0.5 to 3 percent dev fees; 1 to 8 percent custodial takes | 1 percent template dev fee solo, 0 in pool mode | Past | +| Install to first share | NiceHash, Honeyminer, Kryptex: about 5 minutes with one interstitial | Windows: SmartScreen interstitial, per-user install, a firewall UAC prompt 20 to 50 s in; Mac: an ad hoc signature that macOS 15 refuses without Privacy and Security, Open Anyway (Q3, Q14, Q15); the Windows installer pipeline is dead on GitHub billing (Q80) | Behind: three prompts against one, and no Windows build until Q80 | +| Earnings | NiceHash's fiat per day on the main screen | "£0.00 earned" first; mined IGN never shown (Q18) | Behind, 2 hours | +| History and alerts | HiveOS hours of charts and Telegram alerts | A 10-minute strip; no outbound alert (Q16) | Behind, 4 hours plus an alert hook | +| Per-card faults | lolMiner's status line | "N blocks" per card; `mismatched=` and `faults=` never reach the row (Q13) | Behind, 2 hours | +| Remote view | HiveOS, NiceHash Rig Manager | None for the owner (the console is the operator's) | Behind; not ranked here | +| Pool mode | Every miner | Design only | Behind; the share sidechain of 5.3 is the finish | +| Finality on the surface | Nobody | Nothing during a pause (Q2) | Behind, 3 hours, and nobody else has the concept | + +The honest line: Ember is the first app to ship the thing the table says nobody shipped (node, wallet, GPU miner, own key, signed updates, no custody), and it loses to a 2018 Honeyminer on the sixty seconds between download and first share. The first-run fixes are one Developer ID and one Authenticode certificate (Q3, a the project lead decision) plus the Q80 installer builder; the rest of the behind rows are 11 hours. + +## 7. Verdict table + +| Group | Unfinished item | Who could finish it | Igneum has it | Hours on Igneum | Recommend | +|---|---|---|---|---|---| +| A | Energy that produces proofs of real state, paid from issuance (Aleo's 2019 promise) | A chain with a prover network and no validator set | Yes once the proof is verified in consensus (`proving_consensus_verify_daa`, 0.3.16, off by default) | 0 beyond the activation decision | Already done; activate | +| A | Pay per verified unit of proving at a market price (PoVW) | Boundless, Succinct, Igneum | Yes (pgas metering, 90/10 external jobs) | 0 | Already done | +| A | Useful work verified cheaper than done AND sampleable AND wanted | Nobody in 13 years | No, and the bound says why (0.08 percent useful at 100 GH/s) | 0.5 (the ledger row beside F13, new-pow.md rank 8) | Skip | +| A | Stored data as the work (Filecoin, Chia) without filler | Lane 8's scheme C | Partly (class v5 candidate, judged) | per new-pow.md rank 1 (16) | Not this lane's call; already ranked | +| B | A tweak that lands before the chip (RandomX v2 merged, unscheduled; ProgPoW dead on governance) | A chain whose parameters move without a vote | Yes (era draws every 6 months, families by height, the class ladder) | 0 | Already done | +| B | The random item derivation and external cryptanalysis of the mixer | Igneum | No | per asic-history 4.3 additions 2 and 3; the spend (USD 80,000 to 160,000) is a decision owed | Finish, through the existing ranking | +| B | The FPGA overlay measurement and the epoch-length reserve | Igneum | Partly (reserve designed on `ca2-epoch`) | per asic-history addition 5 | Finish, through the existing ranking | +| B | Tensor-core PoW measured against a chip | Igneum did it (scheme B) | Yes, retired to reserve R8 with the two-output correction | 1 (new-pow.md rank 5) | Already done | +| C | A merged-mining BIP that replaces the 2011 spec; any child chain with a say in its parent | Namecoin, RSK | n/a (ruled out) | 0 | Skip | +| C | An algo slot or an Igneum-side auxiliary chain | Nobody should | No | 0 | Skip, with the reasons in 3.2 | +| D | Finality on PoW without a coin-bought validator set | Zcash Crosslink (not shipped), Kaspa DAGKnight (PRs) | Yes: miner-only 30-day weight, 20 days at 100 percent hashrate for 2/3 | 0 beyond Igneum's own open rows (LEAVE item, 10 percent rule, weight-gated deep fork choice, vote-or-burn: 0.3.16 and horizon 1) | Already done; finish the own rows | +| D | A subjective reweighting rule that survives its own chain (Horizen, MESS) | Nobody | Removed on purpose (no hidden-block n^2 penalty) | 0 | Skip | +| E | A pool with no operator on a DAG chain | Nobody has; Monero P2Pool is the finished form on a chain | Partly (vote key in the header, the 20 percent paid by sortition, coinbase extra data) | about 40 (section 5.3) | Finish | +| E | Miner-built templates (DATUM, SV2 JD: one block in 52,297) | Igneum's mode C | Designed, not built | 6 | Finish after the sidechain | +| E | Encrypted member transport | SV2 Noise | No (plain TCP, Q67) | 8 | Finish | +| E | A pool-as-contract with sampled share verification (SmartPool) | Nobody since 2017 | No | 0 | Skip (1.35 ms per share makes it worse than it was for Ethereum) | +| F | Node, wallet and GPU miner in one app, own key, signed updates | Nobody; Ember | Yes | 0 | Already done | +| F | Sixty seconds from download to first share | Honeyminer did it in 2018 | No (three prompts, no Windows build) | 6 plus certificates (Q3); 0 or 4 (Q80) | Finish; the certificates are the project lead's | +| F | Earnings in IGN, per-card faults, an hour of history, a finality notice | HiveOS, lolMiner | No (Q18, Q13, Q16, Q2) | 11 | Finish | +| F | Payout in something a gamer can spend (Salad's gift cards) | Salad | No, and the chain says "nothing is bought or sold on devnet" | 0 | Skip until there is a market | + +## 8. Three headline findings for the coordinator + +1. Every proof-of-useful-work programme that passed both tests (cheap verify, sampleable) did so by making the work useless, and the one exception, Filecoin, ran at 29 to 36 percent utilisation and lost 55 percent of its raw byte power in the year to 14 Sep 2026; Igneum's split already finishes Aleo's 2019 promise, and the only unfinished line (a majority prover pool earning 11,636 IGN an hour at 51 percent) closes when `proving_consensus_verify_daa` is switched on. + +2. No pool without an operator exists on any chain but Monero (P2Pool at 7.7 percent, 3,520 miners, 0 percent fee; Ocean at 2.05 percent of blocks with 85 percent of them from DATUM; Stratum V2 job declaration at 1 block in 52,297), and Igneum already holds the three objects that make one cheap (the vote key in the header, the 20 percent paid by sortition, the coinbase extra data), so a share sidechain is about 40 agent hours and would be the first on a DAG chain. + +3. Every finality on a PoW chain that held in practice is a second validator set bought with coins (Decred 64 percent of supply staked, eCash 350 B XEC, Dash 1,000 DASH per masternode), and every rule that only reweights work has been switched off by its own chain (MESS twice, Horizen winding down, Kaspa's 12-hour depth subjective); Igneum's work-weighted set needs 20 days of 100 percent hashrate to reach 2/3, so no renter buys it in a day, and the unfinished items are Igneum's own (the LEAVE item and the 10 percent rule), not the industry's. + +## 9. Sources + +All accessed 7 October 2026 unless stated. Lane notes with the full per-item citations sit in the scratchpad under `mission-unfinished/` (A-notes, B-notes, CD-notes, E-notes, F-notes). + +Group A +- https://en.wikipedia.org/wiki/Primecoin ; https://www.johndcook.com/blog/2026/01/10/primecoin-primality-test/ ; https://github.com/primecoin/primecoin/wiki/Primecoin-Reaches-13-primes-Milestone ; https://primecoin.io/ ; https://chainz.cryptoid.info/xpm/ ; https://www.coingecko.com/en/coins/primecoin ; https://bitinfocharts.com/primecoin/ +- https://github.com/gridcoin-community/Gridcoin-Wiki/wiki/zArchive~Proof-of-Research ; https://gridcoin.us/assets/docs/scraper-summary.pdf ; https://gridcoin.us/guides/whitelist.htm ; https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/5.5.0.0 +- https://curecoin.net/knowledge-base/folding-for-curecoin/how-do-i-start-folding-for-curecoin-quick/ ; https://curecoin.net/news/curecoin-team-reaches-1-trillion-ppd-on-foldinghome/ ; https://curecoin.net/curecoin-roadmap/ ; https://tokenmarket.net/blockchain/counterparty/assets/foldingcoin/ +- https://eprint.iacr.org/2020/190 ; https://aleo.org/post/aleo-mainnet-faq/ ; https://docs.aleo.org/participate/run-a-node/prover ; https://github.com/ProvableHQ/ARCs/discussions/97 ; https://provable.com/blog/introducing-arc-0046 ; https://aleo.org/post/announcing-snarkos-v4.0.0/ ; https://messari.io/report/state-of-aleo-q2-2025 (search excerpt; direct fetch 429) ; https://followin.io/en/feed/11596817 +- https://eprint.iacr.org/2021/1379 ; https://eprint.iacr.org/2025/2091 ; https://eprint.iacr.org/2017/203 ; https://eprint.iacr.org/2018/559 +- https://filecoin.io/blog/posts/a-guide-to-filecoin-storage-mining ; https://lotus.filecoin.io/storage-providers/get-started/hardware-requirements/ ; https://lotus.filecoin.io/storage-providers/operate/benchmarks/ ; https://filecointldr.io/article/key-trends-and-takeaways-from-filecoin-q1-2025 ; https://www.kucoin.com/news/flash/filecoin-q3-2025-report-capacity-drops-10-network-utilization-rises-to-36 ; https://thetradersspread.com/crypto/filecoin-rose-24-percent-ahead-of-75-percent-supply-cut ; https://github.com/filecoin-project/FIPs/discussions/1009 ; https://filecoin.io/blog/posts/introducing-proof-of-data-possession-pdp-verifiable-hot-storage-on-filecoin/ +- https://www.chia.net/2022/03/19/chia-mainnet-year-one/ ; https://www.chia.net/2021/05/24/chia-and-ssd-endurance/ ; https://www.chia.net/2021/08/03/chia-and-ssd-endurance-big-progress-less-waste/ ; https://www.chia.net/2023/01/21/plotting-chias-future/ ; https://www.chia.net/2026/02/27/changes-coming-to-3-0/ ; https://lowendbox.com/blog/the-crypto-that-ate-all-the-hard-drives-whatever-happened-to-chia/ ; https://xch.today/2026/02/09/top-10-chia-predictions-for-2026/ ; https://en.wikipedia.org/wiki/Chia_Network +- https://ownyourmind.ai/projects/flux/ ; https://runonflux.com/ ; https://messari.io/report/state-of-akash-q1-2026-final (search excerpt) ; https://akash.network/blog/akash-network-q1-2026-report/ +- https://github.com/dynexcoin/Dynex ; https://www.coingecko.com/en/coins/dynex ; https://www.coinlore.com/coin/dynex/news +- https://qubic.org/blog-detail/qubic-s-useful-proof-of-work-the-future-of-ai-compute ; https://qubic.org/blog-detail/the-next-evolution-of-useful-proof-of-work-(upow) ; https://www.halborn.com/blog/post/explained-the-monero-51-percent-attack-august-2025 ; https://www.theblock.co/post/366535/monero-faces-chain-reorganization-fears-after-qubic-says-it-controls-51-of-hashrate ; https://cointelegraph.com/news/monero-qubic-selfish-mining-51-percent-attack ; https://www.bitget.com/news/detail/12560604967511 ; https://wublock.substack.com/p/monero-hit-by-a-51-hashrate-attack +- https://arxiv.org/html/2507.02951v1 ; https://www.theblock.co/news/web3/2026-03-05-dcg-yuma-bittensor-report-392351 ; https://abittensorjourney.com/p/navigating-bittensor-september-2026 ; https://beincrypto.com/bittensor-subnets-reach-ath-in-may/ +- https://arxiv.org/abs/2502.19405 ; https://www.gensyn.ai/research/verde-verification-system-in-production ; https://arxiv.org/abs/2405.00295 ; https://blockeden.xyz/blog/2026/04/01/ambient-ai-l1-proof-of-logits-pow-blockchain-decentralized-inference/ ; https://inferencelabs.com/ ; https://arxiv.org/abs/2603.19025 ; https://arxiv.org/pdf/2512.20176 ; https://blockeden.xyz/blog/2026/01/14/boundless-risc-zero-decentralized-proof-market-zk/ ; https://blog.succinct.xyz/succinct-2025-recap/ +- https://arxiv.org/abs/2209.03865 ; https://eprint.iacr.org/2025/1814 ; https://arxiv.org/abs/2606.06700 ; https://arxiv.org/abs/2606.04819 ; https://arxiv.org/abs/2510.09729 + +Group B +- https://eips.ethereum.org/EIPS/eip-969 ; https://eips.ethereum.org/EIPS/eip-1057 ; https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining-algorithms/ethash/ ; https://github.com/eth-classic/etchash ; https://2miners.com/blog/how-to-mine-ethereum-and-ethereum-classic-on-4gb-gpus/ +- https://leastauthority.com/static/publications/LeastAuthority-ProgPow-Algorithm-Final-Audit-Report.pdf ; https://github.com/ethcatherders/progpow-audit (PDF text not extractable) ; https://github.com/kik/progpow-exploit ; https://github.com/ethereum/EIPs/issues/2640 ; https://hudsonjameson.com/posts/2020-03-02-progpow-the-ethereum-community-speaks/ ; https://cointelegraph.com/news/the-history-of-the-bitter-debate-over-ethereums-progpow ; https://www.theblock.co/linked/57061/ethereum-community-members-submit-dissenting-progpow-petition ; https://www.coindesk.com/tech/2020/03/05/ethereums-progpow-debate-is-about-much-more-than-mining ; https://www.coindesk.com/tech/2020/03/06/ethereums-progpow-call-features-frustration-but-little-progress ; https://github.com/Souptacular/linzhi ; https://linzhi.io/docs/LWP15-Posts-Against-ProgPoW-05092019.pdf ; https://cryptoslate.com/progpow-authors-steps-down-core-scientific-ethereum/ ; https://ecips.ethereumclassic.org/ECIPs/ecip-1070 ; https://2miners.com/blog/kawpow-new-ravencoin-mining-algorithm/ ; https://en.wikipedia.org/wiki/Firo_(cryptocurrency) ; https://www.qu.ai/blog/quai-network-mainnet-launching-january-29th +- https://github.com/tevador/RandomX ; https://github.com/tevador/RandomX/pull/265 ; https://github.com/tevador/RandomX/pull/317 ; https://github.com/monero-project/monero/pull/10038 ; https://github.com/monero-project/research-lab/issues/136 ; https://xmrig.com/docs/algorithms ; https://github.com/xmrig/xmrig-cuda/issues/67 ; https://www.asicminervalue.com/miners/bitmain/antminer-x5 ; https://www.asicminervalue.com/miners/bitmain/antminer-x9 ; https://millionminer.com/news/monero-mining-guide-2026-antminer-x5-x9-pinecone-r1x-randomx (reseller, unverified) ; https://www.coindesk.com/business/2025/08/12/monero-s-51-attack-problem-inside-qubic-s-controversial-network-takeover +- https://arxiv.org/abs/1911.05193 ; https://kaspa-lens.com/kaspa-wiki/kaspa-technology-and-features/kheavyhash-proof-of-work-algorithm/ ; https://kaspa-lens.com/kaspa-wiki/getting-started-with-kaspa/mining-kaspa/ ; https://www.asicminervalue.com/miners/iceriver/ks0 ; https://github.com/karlsen-network/karlsend ; https://github.com/spectre-project/rusty-spectre ; https://github.com/Pyrinpyi/pyipad +- https://docs.ergoplatform.com/mining/autolykos/ ; https://www.ergoforum.org/t/autolykos-v-2-details/480 ; https://github.com/ergoplatform/eips/blob/master/eip-0027.md ; https://eprint.iacr.org/2020/044 ; https://x.com/RedPandaMining/status/1697408861014196711 ; https://cryptoage.com/en/3019-osprey-e300-fpga-miner-for-kaspa-cryptocurrency.html +- https://github.com/mimblewimble/grin/blob/master/doc/pow/pow.md ; https://docs.grin.mw/about-grin/proof-of-work/ ; https://forum.grin.mw/t/grin-v5-0-0-network-upgrade-hard-fork-4-january-2021/7895 ; https://2miners.com/blog/grin-version-4-hard-fork-what-will-change-and-how-to-get-ready/ ; https://forum.grin.mw/t/grn1-cancellation-announcement/5624 ; https://voskcointalk.com/t/new-grin-miner-coming-out/6373 ; https://www.asicminervalue.com/miners/innosilicon/g32-500 ; https://www.asicminervalue.com/miners/ipollo/g1 ; https://2cryptocalc.com/cuckatoo32-algorithm ; https://github.com/tromp/cuckoo +- https://coinbureau.com/mining/battle-against-asics-antminer-z9-zcash ; https://github.com/ZcashFoundation/zfnd/blob/master/_posts/blog/2018-05-08-statement-on-asics.md ; https://raw.githubusercontent.com/ZcashFoundation/zfnd/master/_posts/blog/2018-06-07-asic-equihash-study.md ; https://raw.githubusercontent.com/ZcashFoundation/zfnd/master/_posts/blog/2018-07-03-governance-results.md ; https://forum.zcashcommunity.com/t/will-zcash-fork-to-be-asic-resistant/30829 ; https://crypto.news/zcash-doubles-efforts-on-investigating-asic-resistance/ ; https://github.com/BeamMW/beam/wiki/BEAM-Mining ; https://www.minerupdate.com/news/trending-news/beam-hard-fork-executes-to-deter-asic-miners ; https://u.today/privacy-coin-beam-introduces-new-proof-of-work-algorithm ; https://cryptoage.com/en/2095-beam-cryptocurrency-hard-fork-new-beamhash3-mining-algorithm.html ; https://en.wikipedia.org/wiki/Bitcoin_Gold ; https://www.tweaktown.com/news/62048/bitcoin-gold-hit-51-attack-up-18-million-gone/index.html +- https://github.com/Conflux-Chain/CIPs/blob/master/CIPs/cip-102.md ; https://forum.conflux.fun/t/cip-102-change-pow-mining-algorithm/16068 ; https://f2pool.io/mining/guides/how-to-mine-conflux/ ; https://www.asicminervalue.com/coins/conflux-cfx +- https://docs.alephium.org/frequently-asked-questions/ ; https://docs.alephium.org/mining/ ; https://www.asicminervalue.com/miners/goldshell/al-box ; https://www.asicminervalue.com/miners/bitmain/antminer-al1 +- https://eprint.iacr.org/2025/685 ; https://ethresear.ch/search.json?q=tensor%20core%20proof%20of%20work +- https://arxiv.org/abs/1905.08792 ; https://medium.com/@dave_46855/altered-silicon-x16r-mining-on-the-xilinx-fpga-dbc290c56909 (search excerpt; fetch 403) ; https://forum.zcashcommunity.com/t/equihash-mining-in-fpga/31054 ; https://cryptoage.com/en/3195-all-hashaltcoin-fpgas-get-support-for-the-kheavyhash-algorithm.html + +Group C +- https://github.com/namecoin/wiki/blob/master/Merged-Mining.mediawiki ; https://www.namecoin.org/docs/faq/ ; https://en.bitcoin.it/wiki/Merged_mining_specification ; https://metrics.namecoin.org/namecoin/period-timestamps-14-days/pool/charts/latest.txt ; https://forum.namecoin.org/viewtopic.php?f=6&t=2421 (search excerpt; fetch 500) ; https://cryptorank.io/news/feed/7620f-while-bitcoins-hashrate-remains-sky-high-merge-mined-crypto-asset-networks-benefit (search excerpt; fetch 403) ; https://eprint.iacr.org/2017/791 +- https://www.coindesk.com/markets/2014/08/04/dogecoin-to-allow-litecoin-merge-mining-in-network-security-bid ; https://www.binance.com/en/research/analysis/merged-mining (search excerpt) ; https://www.bitdeer.com/learn/dogecoin-the-logic-of-auxpow-and-stable-profits ; https://www.mexc.com/learn/article/dogecoin-mining-2025-how-doge-is-mined-merge-mining-and-miner-economics/1 +- https://myriadteam.github.io/ ; https://www.pxdojo.net/2017/04/myriadcoin-untold-story-of-invincible.html ; https://thenextweb.com/news/hackers-verge-blockchain-steal-1-7m ; https://bitcoinist.com/verge-xvg-hacked-35-million-xvg-tokens-reportedly-generated-hacker/ ; https://en.wikipedia.org/wiki/Verge_(cryptocurrency) ; https://cryptonary.com/verge-suffers-reorg-attack-200-days-of-transactions-wiped-away/ (headline only) +- https://solofury.com/blog/digibyte-dgb-explained-for-miners/ ; https://www.gemini.com/cryptopedia/digibyte-mining-digibyte-coin-dgb-coin +- https://cryptobriefing.com/elastos-bitmain-merged-mining/ ; https://blog.elastos.net/news/ela-queen-of-bitcoin/ ; https://rootstock.io/blog/merged-mining-insights-report-q1-2024/ ; https://rootstock.io/blog/rootstock-x-bitcoin-merged-mining-insights-report-q4-2024/ ; https://rootstock.io/blog/the-security-architecture-of-rootstock-and-the-principle-of-defense/ ; https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP110.md + +Group D +- https://docs.decred.org/proof-of-stake/overview/ ; https://docs.decred.org/research/hybrid-design/ ; https://github.com/decred/dcps/blob/master/dcp-0011/dcp-0011.mediawiki ; https://github.com/decred/dcps/blob/master/dcp-0012/dcp-0012.mediawiki ; https://xaur.github.io/decred-news/journal/201912 ; https://xaur.github.io/decred-news/journal/202012 ; https://xaur.github.io/decred-news/journal/202112 ; https://xaur.github.io/decred-news/journal/202212 +- https://www.coindesk.com/tech/2018/10/10/a-solution-to-cryptos-51-attack-fine-miners-before-it-happens ; https://blog.horizen.io/horizens-51-attack-solution/ (search excerpt; fetch 403) ; https://www.horizen.io/ ; https://docs.horizen.io/ +- https://raw.githubusercontent.com/kaspanet/rusty-kaspa/master/consensus/core/src/config/constants.rs ; https://raw.githubusercontent.com/kaspanet/rusty-kaspa/master/consensus/core/src/config/bps.rs ; https://raw.githubusercontent.com/kaspanet/rusty-kaspa/master/consensus/core/src/config/params.rs ; https://eprint.iacr.org/2022/1494 ; https://github.com/kaspanet/rusty-kaspa/pull/1104 (search excerpt) +- https://arxiv.org/abs/2006.01072 ; https://www.usenix.org/conference/atc20/presentation/li-chenxing ; https://doc.confluxnetwork.org/docs/general/hardforks/v2.0 ; https://doc.confluxnetwork.org/docs/general/conflux-basics/consensus-mechanisms/proof-of-stake/pos_overview +- https://arxiv.org/abs/1710.09437 ; https://eips.ethereum.org/EIPS/eip-1011 ; https://eth2book.info/latest/part2/consensus/overview/ ; https://hackmd.io/@tvanepps/Beacon-Book ; https://ethresear.ch/t/convenience-link-to-casper-sharding-chain-v2-1-spec/2332 ; https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2041.md +- https://e.cash/blog/ecash-day-2024-celebrating-three-years-of-ecash-xec ; https://e.cash/blog/eCash-day-2026 ; https://e.cash/blog/preconsensus-launch ; https://e.cash/blog/staking-guide ; https://e.cash/blog/avalanche-faq +- https://meowsbits.github.io/51-percent-docs/ ; https://ecips.ethereumclassic.org/ECIPs/ecip-1100 ; https://ecips.ethereumclassic.org/ECIPs/ecip-1110 ; https://www.kucoin.com/news/flash/etc-miners-revert-to-argos-after-core-geth-v1-13-0-controversy ; https://github.com/ethereumclassic/core-geth/issues/44 ; https://github.com/ethereumclassic/core-geth/pull/53 +- https://electric-coin-company.github.io/tfl-book/design/crosslink.html ; https://shieldedlabs.net/crosslink/ ; https://zechub.substack.com/p/arborist-call-88-r-and-d-updates +- https://eprint.iacr.org/2020/1101 ; https://www.nervos.org/mining (search excerpt; fetch 429) +- https://docs.dash.org/projects/core/en/21.0.0/docs/guide/dash-features-chainlocks.html ; https://syscoincore.org/en/releases/4.2.0/ ; https://komodoplatform.com/en/docs/start-here/core-technology-discussions/delayed-proof-of-work/ + +Group E +- https://en.bitcoin.it/wiki/P2Pool ; https://github.com/p2pool/p2pool ; https://github.com/p2pool/p2pool/commits/master ; https://github.com/treib-holdings/p2pool.org/issues/1 ; https://github.com/frstrtr/c2pool +- https://github.com/SChernykh/p2pool ; https://github.com/SChernykh/p2pool/blob/master/README.md ; https://github.com/SChernykh/p2pool/releases ; https://monero.observer/schernykh-releases-p2pool-v4.7-support-nano-sidechain/ ; https://www.getmonero.org/resources/moneropedia/p2pool.html ; https://data.miningpoolstats.stream/data/monero.js?t=1791359405 ; https://xmrchain.net/api/networkinfo ; https://supportxmr.com/api/pool/stats ; https://api.hashvault.pro/v3/monero/pool/stats ; https://p2pool.observer/ (502 on every try) +- https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki ; https://github.com/stratum-mining/sv2-spec ; https://github.com/stratum-mining/stratum/releases ; https://stratumprotocol.org/ ; https://braiins.com/stratum-v2 ; https://braiins.com/pool ; https://d-central.tech/data/stratum-protocol-matrix/ ; https://d-central.tech/bitcoin-mining-pool-comparison-2026/ ; https://www.spark.money/research/bitcoin-stratum-v2-mining-decentralization ; https://cryptobriefing.com/demand-pool-first-stratum-v2-block/ ; https://www.tftc.io/stratum-v2-job-declaration-first-block-dmnd-gomining/ ; https://www.dmnd.work/ ; https://mempool.space/api/v1/mining/pools/1w ; https://mempool.space/api/v1/mining/pools/1y +- https://ocean.xyz/docs/tides ; https://ocean.xyz/docs/datum ; https://ocean.xyz/dashboard ; https://bitcoinmagazine.com/technical/an-ocean-launch-post-mortem ; https://crypto.news/bitcoin-mining-divide-pushes-luke-dashjr-out-of-ocean/ +- https://data.miningpoolstats.stream/data/kaspa.js?t=1791359405 ; https://2miners.com/kas-mining-pool ; https://woolypooly.com/en/coin/kas ; https://f2pool.io/mining/guides/how-to-mine-kaspa/ ; https://kaspa.herominers.com/?lang=en ; https://solopool.org/ +- https://eprint.iacr.org/2017/019 ; https://blog.acolyer.org/2017/09/07/smartpool-practical-decentralized-mining/ ; https://eprint.iacr.org/2020/044 +- https://miningpoolstats.net/coins/ravencoin/ ; https://2miners.com/erg-mining-pool +- https://github.com/dogestreet/proxypool ; https://arxiv.org/pdf/1112.4980 ; https://arxiv.org/pdf/1402.1718 ; https://arxiv.org/abs/1411.7099 ; https://eprint.iacr.org/2015/155 ; https://en.bitcoin.it/wiki/Eligius + +Group F +- https://en.wikipedia.org/wiki/NiceHash ; https://www.nicehash.com/support/general-help/nicehash-service/fees-and-pricing (deposit fees only; the seller and buyer fee pages returned 404) +- https://hiveon.com/pricing/ +- https://www.awesomeminer.com/ ; https://minerstat.com/ (no pricing on either page fetched) +- https://salad.com/ ; https://support.salad.com/article/213-how-much-can-i-earn-with-salad (no take rate published) +- https://www.kryptex.com/ ; https://pool.kryptex.com/ +- https://unmineable.com/ +- https://www.getmonero.org/resources/user-guides/solo_mine_GUI.html ; https://github.com/monero-project/monero-gui/releases +- https://github.com/Lolliedieb/lolMiner-releases ; https://github.com/bzminer/bzminer ; https://github.com/develsoftware/GMinerRelease ; https://github.com/trexminer/T-Rex ; https://github.com/NebuTech/NBMiner +- Unreachable on 7 Oct 2026: honeyminer.com (connection refused), docs.cudominer.com (no DNS), cudominer.com (429), web.archive.org (blocked for this tool) + +Igneum documents cited +- `CLAUDE.md` (the design paragraph, finality rule v2, the fee lines, the 6 October 2026 rules) +- `docs/analysis/asic-resistance-history.md` (rows 3, 17 to 25, 30; lessons 5 to 9; sections 4.1 to 4.3) +- `docs/plans/pool.md` sections 2, 3, 5, 7; `docs/spec/09-pool-protocol.md` sections 9.1 to 9.8 +- Scratch inputs: `mission-inputs/horizon/new-pow.md` sections 3.1, 3.3, 6, 7; `mission-inputs/horizon/frontier.md` sections 0, 3.10, 3.11; `mission-inputs/horizon-2026-10.md` section 1; `mission-inputs/horizon/polish.md` sections 3.1, 3.6, 3.10 diff --git a/docs/community/discord-hooks.md b/docs/community/discord-hooks.md index 23a665e9..2c0bbb14 100644 --- a/docs/community/discord-hooks.md +++ b/docs/community/discord-hooks.md @@ -83,4 +83,4 @@ file yet), the install on the box. ## The server invite -The standing invite is https://discord.gg/beCy8G5ZR (created 6 October 2026, main; the vanity names discord.gg/igneum and discord.gg/igneumnetwork were free on 3 October and are not yet claimed). The home page's join line and any public text use this URL; nobody asks for it again. +The standing invite is https://discord.gg/igneum (created 6 October 2026, main; the vanity names discord.gg/igneum and discord.gg/igneumnetwork were free on 3 October and are not yet claimed). The home page's join line and any public text use this URL; nobody asks for it again. diff --git a/docs/evidence.md b/docs/evidence.md index 17248e4c..f564650f 100644 --- a/docs/evidence.md +++ b/docs/evidence.md @@ -41,7 +41,7 @@ Versions in the table: `igneum-pow` is the Rust crate at `igneum-pow/Cargo.toml` | 14 | Ethereum bytecode runs unchanged, with the documented differences of spec 7.1 | Homepage Build card; litepaper Building | tested by the team | as row 13; fixes `F-exec-A`, `F-exec-B` (spec 7.5) | `tools/evm-smoke/smoke.mjs`: deploy via viem, `increment`, `hashLoop`, `eth_estimateGas`, `eth_getLogs`; `tools/exec-attacks` scenarios 1 and 3; bench-log "execution layer attack fixes" | Deployment, calls, reverts, logs and gas estimates behave as viem expects; chain id 4463; the prototype pgas table gives 0.0095 to 0.028 pgas per gas, below the design's band before calibration, 3 October 2026. 4 October 2026: a transaction that would cross the block's proving budget is refused by the mempool and, if forced in, aborted and charged with its nonce advanced (25 of 25 checks; 30 of 30 malformed cases). Apple M5 Max. The `Prover` precompile, proof records and the shard planner are not in the node | none yet | | 15 | Every block is proven, with the proof landing within about a minute at launch | Homepage stats ("~60 s to a proof"); litepaper Proving; roadmap phase 3 gate | implemented | repo `d7e1f89` (GPU proof), `e01a3cc`, `292e800`, `eedd136` (`proving/igneum-prove`: shard cutter, MPT witnesses, shard and aggregator guests); SP1 6.8.1; spec 7.2, 7.6 | `proving/windows-wsl2` (SETUP-PROVER, PROVE-BLOCK) on the RTX 5090; `igneum-prove-host --mode block` on `proving/fixtures/`; bench-log "proving v0 on the RTX 5090" and "proving: devnet v4 shards" | First GPU proof of an Igneum block, 4 October 2026, RTX 5090 (WSL2, SP1 cuda, mining paused): fixture `block-78-increment` (2 transactions), core proof 1.4 s (7.3 MB, verify 0.221 s), compressed proof 2.7 s (1.27 MB, verify 0.038 s), post-state and receipts roots identical to the node's; 15.7x and 20.6x faster than a loaded M5 Max CPU. The same day on that CPU (load 38 to 47): a three-shard block proved shard by shard and aggregated by recursion, 19 min (1,139 s) end to end, 245 to 337 s per compressed shard proof, every proof verified. What is not there: no proof is produced, carried or checked on the chain (the devnet prover is a stub that signs claims), the proving pool pays nobody (row 21), the block proven is far below one shard, and the 60-second figure remains a design target; the pass mark is the standard in `docs/benchmarks/proving-e2e.md`. Second RTX 5090 run, 4 October 2026 evening (job run-20261004-173115): a full shard at the provisional S_p (6.75 M pgas, 60.8 M cycles) executed in 1.63 s, core proof 8.3 s (18.1 MB), compressed proof 10.9 s (1.27 MB, verify 0.040 s); a two-shard block (13.5 M pgas) proved shard by shard (11.7 s and 10.0 s) and aggregated in 2.2 s, 24 s of GPU stages end to end, every proof verified, six tampered witnesses rejected. The two host defects (an abort after the upload, an idle wait that turned out to be an unbuffered 18 MB proof save through the WSL2 file bridge, 24 minutes) are fixed (ledger P20) 5 October 2026, live devnet with real transactions (bench-log "real transactions, the first non-empty shard proven and paid"): block 72704 shard 0, 29 transfers, 5,800 pgas, proven on PC 2 in 34 s, verified on the Mac in 0.297 s and paid 1.7623 IGN, 53 s after the chain block executed; of about 1,400 blocks in the 20-minute window 36 were proven (the one prover takes the newest shard assigned to it), so "every block" is not yet true; a second content shard (72803, all copies skipped) failed the native-execution veto on the exporter's block structure, fixed with fixtures the same day, the node side pending the 0.3.9 rollout 5 October 2026, evening (bench-log "proving v1"): the aggregated segment record, the chain rule and the unproven rule are implemented behind `proving_v1_activation_daa` (branch proving-v1, not on the devnet before 0.3.11); on the RTX 5090 a chain of 8 consecutive live blocks proved and aggregated by recursion in 135.6 s with the miner on the card (17 s a block, one proof of 1,272,909 bytes attesting all 8, verified in 0.04 s); the 3-node fast-time harness paid a segment record 1.0 s after submission and refused a late one after its deadline (21 checks); the devnet itself, with one prover, carried proofs for 2.4% of blocks over 30 minutes at a block-to-record latency p50 44 s, p99 52 s. The "within about a minute" holds per proven block; "every block" needs 18 mining 5090s or 6 proving-only cards at empty blocks on the measured rates, and the mandatory rule stays off until the share is one | none yet | | 16 | A 12 GB card proves one shard in about 20 s (WITHDRAWN 5 October 2026: a 24 GB card proves a full shard at the adopted size in 4.3 s; 32 GB mines and proves) | Litepaper Proving ("The proving budget"); roadmap gate 2 | designed | spec 5.1 (Target), 7.6 (`S_p` provisional, 7,500,000 pgas = `B_p` / 4) | `PROVE-SHARD.bat` on the RTX 5090 (pending); the end-to-end standard in `docs/benchmarks/proving-e2e.md`; bench-log "proving: devnet v4 shards" | Measured on a 32 GB card, not yet on a 12 GB card. A shard at the provisional `S_p` is 60.8 M SP1 cycles on the prototype pgas table (9 cycles per pgas, 44 per EVM gas; the modexp entry about 100x its SP1 cost); on an RTX 5090 (4 October 2026 evening, job run-20261004-173115) it executed in 1.63 s and its compressed proof took 10.9 s, verified in 0.040 s, so the 32 GB card is inside the 20 s target with margin. Whether a 12 GB card proves it at all, and in what time, is the next measurement (an RTX 3060 and an RTX 5060 Ti 16 GB are on order). A per-shard time can be met by shrinking the shard, so the project does not use it as a pass mark 5 October 2026, evening (bench-log "proving v1", the S_p curve): measured on the RTX 5090 with SP1 6.8.1's GPU prover, the card to itself, 1-s nvidia-smi samples: an empty shard 13,874 MiB and 2.2 s; a full shard at the ADOPTED v1 budget (30,000 pgas, 4.7 M cycles) 20,434 MiB and 4.3 s; the full prototype shard (6.75 M pgas, 60 M cycles) 28,307 MiB and 10.8 s; beside the miner 15,670 and 30,039 MiB. No environment knob of SP1 moves the 13.9 GB floor and the GPU server has no options of its own, so on this build a 12 GB card proves nothing, a 16 GB card only empty shards, a 24 GB card the adopted full shard alone and beside the miner (22,210 MiB and 13.2 s, measured on the 32 GB card: the 5090's allocation pattern, not yet a run on a 24 GB card) and a 32 GB card the prototype shard beside the miner with 2.5 GB spare. The litepaper line now says so; the 12 GB gate returns when a prover build with a smaller floor is measured on a 12 GB card | none yet | -| 17 | The chip resistance claim: the strongest recompute chip under 1x per chip against an RTX 5090; the stored-dataset chip 1.2x per chip and 5x to 9x per joule in the model (2.1x to 4.8x by the Ethash precedent); the latency-shadow lever, measured and in its gates, brings it to about 2x | Homepage hero and litepaper abstract (draft (a) of `docs/plans/counter-asic-3-status.md` section 6, chosen 6 October 2026), litepaper "What Igneum does not claim" | tested by the team (the model), designed (the target) | program class v3 (Counter ASIC 2.0, 5 October 2026): branches ca2-v3 d233fa1 and after, ca2-mixer 1ab8b21, ca2-era 78c0ee4; `docs/analysis/chip-model-v3.md`, `docs/analysis/sram-mirror.md`, `docs/analysis/scratch-soundness.md` | The m16 recompute model re-run on the measured v3 rates and verifier times; the on-die-cache chip row | The on-die-cache recompute chip against the RTX 5090's measured 136.1 MH/s: class v2 2.4x; class v3 (mixer x8) 0.31x bare, 0.92x with a 3x fixed-function allowance (approximate), 0.76x at equal silicon; margin 8% on the allowance, 9% on the budget. 5 October 2026, M5 Max, RTX 5090, RX 9070 XT. The 2x target is a target: no chip has been built; the bounty stands (O-1.17) | none yet | +| 17 | The chip resistance claim: the strongest chip in the public model reaches 5x to 9x per joule against an RTX 5090 today (modelled); class v4 brings it to 2.1x (k = 1) to 3.9x (k about 0.33, claimed by a withdrawn product) and its second rung to about 2.8x (modelled on measured watts); class v5 makes the dataset the chain's state so a stateless or stale chip is wrong on every item (designed, +0.2 ms verifier); the hot-set cache bounded at 1.067x at the ceiling (measured census of 1,024 programs) and the weak-day FPGA at most 12 percent on 12 days a century (measured census) are bounded and routed to the next class; datacentre silicon (H100 SXM, measured 7 October) does not change the question; a stored-dataset chip pays for itself only at about USD 100 M of market cap in two years (modelled) | The home page's chip line, the litepaper's chip model section, the miner page's line (the texts of `docs/plans/counter-asic-3-public-text-2026-10-07.md`) | tested by the team (every card, the verifier, the two attack-pass censuses, the H100), the chip itself modelled, class v5 and the ladder designed, the X9 core claimed and never measured | `docs/analysis/chip-model-v3.md` 5 and 6; `docs/analysis/latency-shadow-2026-10-06.md`; `docs/plans/counter-asic-3-status.md`; `docs/analysis/attack-pass/f8-uniform.md`, `f4-weakday.md`; `docs/design/class-v5-stored-state.md`; the H100 and market-cap rows of 7 October; `docs/plans/funding.md` (the three lots) | The chip model re-run on the measured class v3 and v4 rates, watts and verifier times; the hot-set census of 1,024 programs and the weak-day census of 2^24 days on the attack-pass branch; the H100 SXM bench row | 136 MH/s at 350 W (5090, bench) and 290 W (app); 27 MH/s at 21 W (M5 Max); 249 MH/s (H100 SXM) at 98 percent of its read ceiling, 1.78x hash, 1.15x MH/W, a third per rented dollar; 2.33 ms per warp; 5.1x to 9.2x; 2.1x, 3.9x, 2.8x; 1.067x at the ceiling; 12 percent on 12 days a century; 10.85 ms at rung 3; USD 100 M; 6 and 7 October 2026 | none yet; the three cryptanalysis lots are the next test | | 18 | The chip resistance measurements: the program is latency-bound (random reads), not bandwidth-bound, on every card we own, and sits beyond a card's on-chip cache | Litepaper Mining ("waits on memory latency, not on maths or bandwidth"), vs RandomX; the numbers page | tested by the team | readwidth e752fc7 (`docs/plans/read-width.md`), ca2-era 78c0ee4, ca2-cache 2de19e5 (`docs/plans/hot-table.md`) | The dependent-read probes at 32 to 1,024 MiB and the hash rate per class on the three cards; the latency-bound share = rate over the probe ceiling per load | Latency-bound share at the 1 GiB dataset: RTX 5090 0.96 (v2) and 1.01 (v3), RX 9070 XT 0.87 and 0.95, M5 Max 1.01 and 1.06; wider reads do not close the AMD gap (the 9070 XT does 2.4 G dependent reads per second at every width; the 5090 goes bandwidth-bound at 64 B, share 0.58); a 32 to 96 MiB hot table is not kept resident by any card while the dataset streams (g 0.80 to 0.87 in the added form). 5 October 2026 | none yet | | 19 | The lottery hash is sound as a hash: uniform output, deterministic, no out-of-bounds read, fuzzed; class v3 bit-exact on the three vendors | Litepaper vs RandomX ("Every number above is measured and logged"), the numbers page | tested by the team | ca2-mixer 1ab8b21 (`tests/mixer.rs`, `tests/scratch.rs`), ca2-era 78c0ee4, ca2-soundness a465881 (`docs/analysis/scratch-soundness.md`), `igneum-pow/tests/packs.rs` | The crate suite (53 + 4 + 19 + 7), the Metal fuzz, edge, stats and determinism runs on the v3 construction, the pack vectors and 2^24 fingerprints on Metal, Apple OpenCL, the RTX 5090 and the RX 9070 XT, the 1,024-hash CPU re-check per card | Class v3 (mixer x8 + era): 200-program fuzz 200 of 200 on Metal, every tenth on Apple OpenCL; the pinned v3 packs 3/3 + 3/3 and 96 of 96 lanes on Metal and Apple OpenCL; the six era packs' fingerprints equal on the three vendors (PC 1 job run-ca2-era-pc1-20261005, 5 October 2026); the v2 exports byte-identical on the v3 crate; the final-class PC rows and the G2 re-check: job run-ca2-era-pc1b-20261005 (pending at the time of writing) | none yet | | 20 | No premine, no pre-sale, no allocation: every coin is minted by the schedule and every coin goes to the block producer (80%) and the proving pool (20%) | Homepage stats and Economics tiles; litepaper Supply, Economics | implemented | repo `6ac80a3`; fork "igneum-node devnet v0"; `consensus/core/src/igneum.rs`, `coinbase.rs` | `cargo test -p kaspa-consensus-core igneum` (8 pass: subsidy table, ramp, split, cap) and `cargo test -p kaspa-consensus coinbase` (8 pass); `igneum-miner inspect 40`; bench-log "igneum-node devnet v0" | Coinbases on the devnet: 80/20 exact on 39 of 39 single-payee blocks, the 20% to the `igneum-proving-pool-v0` output; the per-second schedule sums to under the 4,000,000,000 cap by less than 100 coins; 3,168,808,781 units per DAA second in years 0 to 2, halving at 63,115,200 DAA s. 3 October 2026, Apple M5 Max. The devnet genesis carries no allocation; the mainnet genesis does not exist yet, so the claim is about the code and the stated rule, not a launch that has happened | none yet | diff --git a/docs/fud-ledger.md b/docs/fud-ledger.md index 3a9f89e4..89a28b69 100644 --- a/docs/fud-ledger.md +++ b/docs/fud-ledger.md @@ -185,6 +185,8 @@ Evidence: `docs/analysis/horizon/algorithm.md` section 5.1 (the ceiling table: m ### M34. The shadow size N is a constant of the binary, so the one lever against the dataset-storing chip needs a fork to move "Your own Horizon lane says the reserve and the era draw buy nothing against a chip that stores the dataset, and that the only lever is the latency-shadow size N. N is 27 passes of a 256-instruction block, hard-coded in `V4_CLASS`. So when HBM4 doubles a chip's rate per stack in 2028, your answer is a hard fork, and a fork that retires the M5 Max at the first doubling. And now there is a shipping RandomX ASIC." +Status: Relabelled (7 October 2026, morning, X36): the X9 in this row and in the litepaper paragraph is the chip Bitmain announced and withdrew before launch, its core claimed and never measured; the ladder's arithmetic against that core is unchanged. + Status: Conceded, implemented (6 October 2026, night; `docs/design/latency-ladder.md`, branch `ladder`, fork branch `ladder-node`, the 0.3.17 feature tree, behind `latency_ladder_activation_daa`, never until set, 0 on the testnet when the project lead says): N is a genesis ladder of six rungs (27, 35, 53, 88, 173, 267 passes; about 102,100 to 1,001,600 counted ops) with a measured admissibility flag per rung (cold verify under 10 ms on the reference core with its SMT sibling loaded, igneum-build-1, 6 October 2026: rungs 0 to 2 pass at 8.77, 8.87 and 9.23 ms, rung 3 misses by 0.08 ms under a box load of 25 and is out until a quiet re-run, rungs 4 and 5 are out at 12.38 and 14.96), and the step is consensus state derived from two bits of the header version: up one rung when 90 percent of blue blocks in each of seven consecutive windows ask for it and the rung above is admissible, down one rung symmetrically, never two rungs inside seven windows (the oldest window must begin after the last step took effect), never unconditionally. Tests, the known-failed case first: a changed N today hashes another program under the same program id (a hard fork no pack line told apart); after, rung 0 is class v4 byte for byte, a rung above carries its pass count in the id, 8,999 bps in one window of seven does not move the step, a two-step jump is impossible, down never passes rung 0, an inadmissible rung is never entered. Stated in `site/litepaper.html`, Mining section ("The work that waits can grow"). Answer: Correct on both counts, and the second was the sharper one. The X9 (Bitmain, about 1 MH/s at 2,472 W, approximate, github.com/monero-project/monero/issues/10270) is a shipped 3x per-joule edge over a desktop CPU on the best-known latency-bound random-program design, seven years after launch; it makes the k = 0.3 column of the chip model a product class rather than an attacker's claim, and the public headline is now the range 2.1x (k = 1) to 3.9x (k = 0.33) over the RTX 5090 at class v4, with the ladder taking the X9 bracket to about 2.8x by rung 2 and the Apple tier's to about 1.1x by rung 3. The ladder does not close the gap; it is the chain's only automatic answer, it moves at the pace of the cards that pay for it, and the honest card's watts remain the lever that moves every row (algorithm lane proposal 7). What the ladder gives up by design: a chip holding over 10 percent of weight can stall it, and the status quo it stalls is a rung the cards already run. @@ -709,6 +711,8 @@ Evidence: litepaper "For miners", hardware paragraph. Wording: overclaims list, ### C2. vs Monero: "no chip in seven years" is not proof "Absence of a public RandomX ASIC is not evidence one cannot exist. Monero is also a small prize." +Status: Reopened as conceded (7 October 2026, morning, X36): the X9 never shipped, so Monero's record is again seven years without a shipped chip, and the concession stands as first written; the litepaper says so in the same sentences. + Status: Conceded, stated (7 October 2026, morning): the one-screen home page is back on the owner's word, so this row is stated on `site/litepaper.html` only; the sentence there is unchanged and the text check lists it under the litepaper. Status: Closed by the fact (6 October 2026, night): a public RandomX chip now exists, Bitmain's Antminer X9, shipping from July 2026 (1 MH/s at 2,472 W, about USD 5,600; monero-project/monero issue 10270). Every sentence that leaned on its absence was rewritten under X34; "2019 (approximate)" stays on both pages. @@ -2281,6 +2285,8 @@ Evidence: `site/litepaper.html`; `docs/plans/testnet-go.md`; X31, X32. ### X34. RandomX described as chip-free "The home page said the random program 'has kept chips off Monero since 2019', the litepaper said Monero ran on RandomX 'with no chip publicly shipped' and spoke of 'Monero's seven years without a public chip'. Bitmain's Antminer X9, a RandomX chip, ships from July 2026 (1 MH/s at 2,472 W, about USD 5,600; monero-project/monero issue 10270), and RandomX 2.0 shipped on 25 March 2026. Every sentence that said or implied RandomX is chip-free, or that Monero's approach has held, was wrong." +Status: Corrected (7 October 2026, morning, X36): the X9 never shipped. Bitmain opened pre-orders on 26 December 2025 and withdrew the product in mid-May 2026 before any unit was delivered; every sentence below that had it shipping now states that, and RandomX stands as a technique no chip has yet shipped against. The sentences in this row are the history. + Status: Fixed, stated (7 October 2026, morning): the one-screen home page carries no RandomX sentence, so the corrected wording stands on `site/litepaper.html` (four sentences and the table row); the text check lists them there. Status: Fixed, stated (6 October 2026, night, from the cryptanalysis research): four sentences corrected, each with the X9 as the stated fact and its date; every sentence that only names the technique stands. @@ -2301,6 +2307,8 @@ Evidence: `site/index.html`; `site/litepaper.html`; `tools/ci/ledger-text-check. ### X35. The class v4 chip headline stated as one number, 2.1x "The home page said the strongest chip reaches 'about 2x once the lever now in its gates ships' and the litepaper said the latency-shadow work 'brings the chip to about 2x' and that its edge 'falls from 5.6x to 2.1x ... at a chip core equal to the GPU's'. That 2.1x assumes the chip's core costs what the GPU's does per operation (k = 1). Bitmain's Antminer X9 reached about a third of its honest device's energy on a latency-bound random program, so k about 0.33 is a shipped product class, and at that k the same model gives 3.9x." +Status: Kept, relabelled (7 October 2026, morning, X36): the range stands, with k about 0.33 labelled as the X9's claimed, unmeasured core, since no unit shipped or was benchmarked. + Status: Fixed, stated (7 October 2026, 00:0x UK, from the ladder lane's recalibration against the X9): every public sentence that stated 2.1x alone now states the range with k named. The 5.7x class v3 memory-only figure has no core work in it and is unmoved; the litepaper's 5.6x is the Counter ASIC 3.0 item 8 figure and stays as cited. - `site/index.html`, chip model card. Was: "In our public model the strongest chip reaches 5x to 9x per joule against an RTX 5090 today, about 2x once the lever now in its gates ships." Now: "In our public model the strongest chip reaches 5x to 9x per joule against an RTX 5090 today. With the class v4 shadow work it is 2.1x to 3.9x, the range running from a chip core as costly per operation as the GPU's (k = 1) to one as efficient as Bitmain's RandomX chip (k about 0.33); the ladder's second rung takes that 3.9x to about 2.8x." - `site/litepaper.html`, "A chip is impossible" (both copies). Was: "it brings the chip to about 2x." Now: "it brings the chip to 2.1x to 3.9x, the range running from a chip core as costly per operation as the GPU's (k = 1) to one as efficient as Bitmain's Antminer X9 (k about 0.33); the ladder's second rung takes the X9 bracket to about 2.8x." Was: "falls from 5.6x to 2.1x on GDDR7 at a chip core equal to the GPU's, the 5090 at 0.2% less rate". Now: "falls from 5.6x to 2.1x on GDDR7 at a chip core equal to the GPU's (k = 1) and to 3.9x at the X9's core (k about 0.33), the 5090 at 0.2% less rate". @@ -2312,6 +2320,24 @@ Answer: One number was the model's k = 1 column; the X9 made the k = 0.33 column Evidence: `docs/design/latency-ladder.md` (the k column, the rung table at k = 0.33, the verifier table); M34; X34. +### X36. The X9 described as a shipping chip +"X34 and X35 said Bitmain's Antminer X9 'ships from July 2026' and called it 'the shipping RandomX chip'. It never shipped: Bitmain opened pre-orders on 26 December 2025 for July 2026 delivery, resellers told buyers in mid-May 2026 that Bitmain had discontinued it and refunded them, no unit was delivered and none was independently benchmarked." + +Status: Fixed, stated (7 October 2026, morning, from the research agent's primary sources): every public sentence that had the X9 shipping now states the pre-order, the withdrawal and the unbenchmarked core. +- `site/litepaper.html`, Mining. Was: "Monero ran on RandomX from 2019 (approximate) with no chip publicly shipped until Bitmain's Antminer X9 in July 2026 (1 MH/s at 2,472 W, about USD 5,600; monero-project/monero issue 10270). About seven years of hold and then a chip: that is the record Igneum's hourly program and its chip model are built against." Now: "Monero has run on RandomX since 2019 (approximate) with no chip shipped. Bitmain opened Antminer X9 pre-orders on 26 December 2025 for July 2026 delivery, then withdrew the product in mid-May 2026 and refunded buyers before any unit shipped; none has been independently benchmarked. A box with about a 2x per joule edge over the best CPUs, and about 3x over a desktop, was withdrawn rather than face a RandomX re-tune of 1.5x or more. That is the band Igneum's class v4 model sits in (2.1x to 3.9x over an RTX 5090), and the defence that held was a maintained algorithm with a credible upgrade path, which is what the ladder is." +- `site/litepaper.html`, vs RandomX. Was: "That hold ended: Bitmain's Antminer X9 ships from July 2026 at 1 MH/s and 2,472 W, about USD 5,600, and RandomX 2.0 shipped on 25 March 2026". Now: "The one chip announced against it, Bitmain's Antminer X9 (pre-orders from 26 December 2025 at 1 MH/s and 2,472 W, about USD 5,600), was withdrawn in mid-May 2026 before any unit shipped; RandomX 2.0 shipped on 25 March 2026". +- `site/litepaper.html`, vs RandomX table, Track record. Was: "About seven years without a public chip, then Bitmain's Antminer X9, shipping from July 2026". Now: "About seven years without a shipped chip; the one announced, Bitmain's Antminer X9, was withdrawn in May 2026 before launch". +- `site/litepaper.html`, "A chip is impossible". Was: "Monero's RandomX held for about seven years before Bitmain's Antminer X9 shipped in July 2026 (...)". Now: "Monero's RandomX has held for about seven years; the one chip announced against it, Bitmain's Antminer X9, was withdrawn in mid-May 2026 before any unit shipped, its claimed core (k about 0.33) never measured." +- `site/litepaper.html`, Precedents row: "its first chip, Bitmain's Antminer X9, ships from July 2026" is now "the one chip announced against it, Bitmain's Antminer X9, withdrawn in May 2026 before launch". The X35 range sentences (both copies) now read "the core Bitmain claimed for its withdrawn Antminer X9 (k about 0.33, never measured)" and "the X9's claimed core (k about 0.33, never measured)". The ladder paragraph (M34) reads "the one Bitmain claimed for its withdrawn Antminer X9 (about 3x per joule over a desktop CPU, never measured)". +- `site/index.html`, chip model card: "to the core Bitmain claimed for its withdrawn Antminer X9 (k about 0.33, never measured)". +Checked by `tools/ci/ledger-text-check.mjs` (rows X36 on both pages; the X34 and X35 phrases updated). + +Answer: The k about 0.33 column stays in the public range as the X9's claimed, unmeasured core: Bitmain's figures (1,000 KH/s at 2,472 W, 2.47 J/KH) were a pre-order sheet, never a benchmark, and the RandomX team's own reading (sech1, 25 January 2026) was "no, X9 is not an ASIC... Only 2x efficiency gap (hash/Joule) is not 'cracked'": a box of commodity Sophgo SG2044 server SoCs with an AES block and over sixty DRAM sticks, no tapeout, about 2x per joule over a tuned Zen 4 part and about 3x over a stock desktop CPU. It was withdrawn rather than face a RandomX re-tune of 1.5x or more. The lesson the public text now carries is that one: a maintained algorithm with a credible upgrade path held, which is what the latency ladder is for Igneum. Monero's hashrate shows no X9 fleet (about 6.1 GH/s before and after, approximate). + +Sources: bitmain.com news post dated 1 January 2026 (pre-orders opened 26 December 2025, USD 5,600, 1,000 KH/s, 2,472 W, shipments "scheduled to begin in July 2026"); shop.bitmain.com (the X9 still listed as sold out, "shipping in July 2026", 7 October 2026); pcpraha.cz, 15 May 2026 ("Antminer X9 canceled: Bitmain withdraws model from market before launch"); r/MoneroMining, 17 May 2026 ("Bitmain's X9 discontinued", the relayed reason "technical adjustments and a new strategy", a reseller's "there may be an algorithm change"); monero.forum, 16 May and 3 June 2026 (jeffro256: benchmark data "pretty hard to get since they're never going to be released publicly"). Bitmain itself published no cancellation. + +Evidence: `site/index.html`; `site/litepaper.html`; `tools/ci/ledger-text-check.mjs`; X34, X35, M34. + ## Status updates, 4 October 2026 (round 4) - **F21** (the long-partition fork). Extended: a side locks alone when its own share of its own table reaches two thirds, at `t = W (2/3 - s) / (1 - s)`: 50/50 at 2,400 DAA s on the devnet (about 40 minutes), 10 days on mainnet; the 60 side of 60/40 at 1,200 DAA s (20 minutes), 5 days; the ledger's measured `W/(3R)` = 200 s is this formula at s = 1/2. At HEAD a second certificate at an index is kept, logged and ignored (`processes/finality.rs:650-655, 661-666`) and `fork_choice_lock` (`:886-901`) pins the node. Public text: `site/litepaper.html:511` says a third of the blocks is needed to split finality in a partition; the partition alone does it. Replacement sentence in `docs/review/round-4-2026-10-04.md` section 1 (b). Review id R4.1.5. diff --git a/docs/plans/build-server.md b/docs/plans/build-server.md index 65e5320a..06d5cd8b 100644 --- a/docs/plans/build-server.md +++ b/docs/plans/build-server.md @@ -79,6 +79,7 @@ Also logged for context: the Mac's Linux cross-build with zig (`infra/cross/buil | R2 | Windows exes come from `tools/cross-remote.sh` (fork worktree: igneumd.exe, igneum-miner.exe; app/igneum-app: igneum-app.exe and the two tools). The PC `build` job stays as the second source until two releases have shipped from the box. | | R3 | The Mac keeps what only it can do: aarch64-apple-darwin binaries (the DMG, nodes that agents run locally), tests that need Metal (proto-metal, the Metal worker), and measurements. Those still use `tools/lock/with-lock.sh` and the Mac's build slots. | | R4 | A worktree builds once on the box per commit plus overlay; the next build is incremental in `/srv/builds//.../target`. Nobody deletes another worktree's target dir on the box. | +| R4a | A lane's scratch on the box mirror survives other lanes' builds (7 October 2026, after the attack rows lost `attack-f3/`, `attack-f1-venv/` and `tools/attack/*/target` to each other's builds, hazard AP-H1). The checkout's `git clean` spares `attack-*`, `scratch-*`, `target-attack-*` and `.build-remote.log` at any depth, plus every glob in the mirror-local file `/srv/builds//.igneum-scratch-spare` (one glob per line, gitignore syntax, `#` comments; the file itself is spared). **To declare a prefix**: before the first build that must leave it alone, append one line named for the lane (`bs-`, `r03xx-ship`, the scratchpad prefix rule of 7 October): `ssh -i ~/.ssh/igneum_ed25519 build@188.40.146.49 "printf 'bs-mylane-*\n' >> /srv/builds//.igneum-scratch-spare"`. Keep scratch outside the crate directories the overlay syncs (`bs_overlay_dir` rsyncs those with `--delete`, so an undeclared dir inside one goes the Mac's way regardless; a `target-attack-*` name is safe there too, rsync protects its excluded `target-*/`). `remote-run.sh --self-test` shows a declared and a fixed-prefix dir surviving and an undeclared one removed; `tools/ci/scratch-spare-check.sh` (pre-push gate) fails when the clean line loses the mechanism or gains `-x`. | | R5 | `RUST_TOOLCHAIN` in provision.sh is bumped in the same commit as the Mac's `rustup update`; build-remote.sh refuses a mismatch. Add a `rust-toolchain.toml` to the fork and the repo (none exists today) so both sides pin from one file. | | R6 | The box is never a node host for the live devnet and never holds a secret (no `~/.config/igneum` there). The Devnet 2 seed on it runs under its own unit with `--devnet --devnet-suffix=` on 26611 (ufw already open) when that work starts. | | R6a | ONE recorded exception to R6 (main's ruling, 6 October 2026, 20:0x UK): the three Discord webhook URLs live at `/srv/discord-hooks/env` (mode 600, owner build), installed by `infra/build-server/discord-hooks/install.sh` with `IGNEUM_SECRET_ON_BOX_OK=1`, because the Mac sleeps and the bot's timer must not. The reasoning: a webhook URL signs no release, moves no funds and reaches none of the devnet's hands; whoever holds it can only post as the bot, and a leaked one is deleted in Discord in one click and the file replaced. No other secret joins it; `check` prints key names, never values. | @@ -96,6 +97,7 @@ Also logged for context: the Mac's Linux cross-build with zig (`infra/cross/buil | A path dependency inside a vendor repo (the shipper's proving build, 6 Oct 2026) | proving/igneum-prove depends on vendor/igneum-node-exec/igneum/evm-types, a MEMBER of the fork's workspace (it inherits `thiserror` from the fork's root manifest); the first design synced that one directory, so cargo found no workspace root on the box ("failed to load manifest for workspace member"), and the shipper cross-built the Linux prove-host on the Mac with cargo-zigbuild meanwhile | lib.sh groups path dependencies by git top level: one under vendor/ is a whole repository, pushed to its mirror (a fork worktree such as igneum-node-exec goes to /srv/igneum-node.git, which already held its branch; a repository of its own gets /srv/.git, created on first use) and checked out whole at /srv/builds//vendor/; run-from-mac.sh wires every vendor repo the Cargo.toml files reach (today only igneum-node-exec). The detector's first version tested "under BS_TOP" before "own repository" and missed it, since vendor/ lies under the igneum top level on disk. Then `libprotobuf-dev` was missing (sp1-prover-types's build script imports google/protobuf/empty.proto); added to provision.sh. Proof: `cd proving/igneum-prove && tools/build-remote.sh -- build --release -p igneum-prove-host`: igneum-prove-host 71,943,192 B, sha256 e9213e3a6c979512d7859f6d8e848105bab53f4355e99fb0d30fb4a72c2d5714, ELF x86-64, 1 min 05 s warm (the cold run compiled 605 crates in 55 s before protoc stopped it). A Mac worktree has no vendor/ of its own, so a worktree that builds proving needs `git -C vendor/igneum-node worktree add /vendor/igneum-node-exec execution-layer` first, as the fork worktrees do | | One remote build lost its ssh session after 75 s (18:30:50 UTC, the first full proving build) | the remote bash died with it (slot line left behind, no JSONL line); no OOM, no reboot, the retry a minute later passed | the dashboard collector's one-pass unit finished within a second of the drop, so it was tested: a 90 s remote session through the same ControlMaster path survived two collector passes triggered by hand; the collector only reads (/proc, lock files, `flock -n`, `sccache --show-stats`, `kill(pid, 0)`). One event, no cause in the journal, the retry passed. A build that must survive a dropped connection would need the remote command under setsid with the Mac reconnecting to wait; not done, open if it happens again | | A stamp file at a nested path failed every checkout of /srv/builds/igneum (18:31 to 18:5x UTC, the shipper's 18:52 run) | a repo-kind crate keeps its `.build-remote-sha-` and `target/` inside the crate dir; the checkout mode's clean-tree test only excused them at the tree root | the test is depth-agnostic and uses `--untracked-files=all` (a wholly untracked directory is otherwise collapsed to `?? dir/`); the self-test carries a nested stamp, a nested target dir and a stale `.git/index.lock`, which the mode now removes when no git runs there | +| The attack rows lost scratch dirs to each other's builds (7 Oct 2026, 09:2x UK, hazard AP-H1 from the attack-pass lane) | checkout_tree's `git clean -fd` ran on the shared mirror before every build from any agent and took every untracked directory: `attack-f3/`, `attack-f1-venv/`, `tools/attack/*/target` | the clean spares the fixed prefixes and the globs in `.igneum-scratch-spare` (R4a), still without `-x` so `.git/info/exclude` applies; the clean-tree test asks `git clean -nd` with the same excludes instead of filtering the status list, so a spared dir no longer reads as "not clean"; the self-test carries a fixed-prefix dir at the root and nested, a declared dir, the spare file and an undeclared dir; `tools/ci/scratch-spare-check.sh` in the gate | | Two runs on one worktree at once (the shipper, 18:48:56Z) | the second run's checkout replaced the first's sources mid-cargo; both died | lib.sh takes a per-worktree lock on the box (`/srv/builds/_locks/wt-`, mkdir-atomic, holder line) across sync, build and fetch; a second run waits up to 2 h (a line every minute), a lock older than 3 h is taken over; released on EXIT. The build slot (`build-`) is unchanged | | The 0.3.15 prover pair for the PCs needs `--features igneum-prove-host/cuda` (the PCs run SP1_PROVER=cuda) | my first proving build named no feature | built on the box from master e1b5bc9: igneum-prove-host 73,161,528 B sha256 71bc2438856bb141f6cad3d18489f708568144fad5a06a002fbadefb9ce256f9, igneum-prove-export 3,609,360 B sha256 263bf4cef70af4a13a45b2e79b8dbab373282ea4c571f624d02ddb5791935361 (52 s warm, no CUDA needed at build time); handed to the shipper | | Let's Encrypt saw NXDOMAIN for build.igneum.network | the deSEC record was minutes old; Ubuntu's Caddy then fell back to ZeroSSL and failed with HTTP 422 for ever | issuer pinned to Let's Encrypt; the retry got the certificate | @@ -120,7 +122,16 @@ Self-test: `tools/build-remote.sh --self-test-repro [--full]` from a fork worktr | Consequence: glibc ceiling 2.38 | runs on the fleet (Ubuntu 22.04 containers are glibc 2.35: NO, 2.38 > 2.35; Ubuntu 24.04 hosts yes). The Mac's zig build (`infra/cross/build-workers-linux.sh`, glibc 2.36) is the one for Debian 12 and HiveOS; the fleet agent must check its boxes' glibc before swapping the worker. Fix if needed: zig on the box (open row in section 6) or `clang -target x86_64-linux-gnu.2.35` via zig; both a day's work, not done | | Runner fix found on the way | a command string carrying `set -e` leaked into remote-run.sh through `eval` and killed the runner before its RESULT line (reported as rc 101); the runner now evaluates the command in a subshell | -## 5c. Deploy key for the observer clone (steps for the project lead, 7 October 2026) +## 5c. Deploy key for the observer clone (DONE: the project lead added the key on 7 October 2026, morning) + +Done. the project lead added the public half as the read-only deploy key "igneum-build-1 observer (read-only)" (SHA256:51ice3W8...; the +organisation's deploy-key policy had to be switched to Enabled first). The sync's own test then still said "mirror": `ssh -T` to +GitHub exits 1 after its greeting and the script runs under pipefail, so `su ... | grep -q` reported failure although grep had +matched; fixed by capturing the output first (install-hands.sh). First pass reading "source: github (deploy key accepted)": +7 Oct 2026 07:30:54 UTC, "observer files changed (8aab05ce); restarting igneum-observer": the clone went from the mirror's 8397781 to +GitHub's master 8aab05ce in that pass, the observer restarted on it and is active; remote `github` = git@github-igneum-observer:igneum-network/igneum.git. The clone now follows origin/master every 5 minutes; the mirror stays the fallback whenever GitHub refuses. + +The steps as they were, for the record: The observer on the box runs tools/observer from a clone that follows the mirror `/srv/igneum.git`, which moves only when a Mac agent pushes. With a read-only deploy key it follows GitHub directly (every 5 minutes, `igneum-observer-sync.timer`). The key pair diff --git a/docs/plans/launch-pack.md b/docs/plans/launch-pack.md new file mode 100644 index 00000000..9e799ea3 --- /dev/null +++ b/docs/plans/launch-pack.md @@ -0,0 +1,232 @@ +# The launch pack: gates and text, no protocol (mission item 10) + +7 October 2026, 10:1x to 11:xx UK, the launch-pack lane (branch `launch-pack`, worktree `igneum-wt-launch-pack`, from master b92a5fd4). Mission item 10 of `docs/analysis/mission/mission.md` 2.10, built from `past.md` sections 3 and 4, `future.md` section 8, `reinvent.md` 3.1 and 4.1, `docs/plans/testnet-go.md` and the litepaper. This is an operations document: `docs/plans` is not on the public export list, so it may name the owner; the text handed to the site lane in section 4 may not, and `tools/ci/launch-gates-check.mjs` greps it. + +the project lead's three decisions of this morning, written in everywhere below: + +| Decision | the project lead's word (7 October 2026, 10:1x UK) | Where it lands | +|---|---|---| +| The proving customer | A signed proving customer IS a mainnet gate: one signed customer paying for proofs at a published rate, or a signed letter of intent with a volume, before mainnet, not before the testnet | `testnet-go.md` LG-11; the journey's phase 4 gate loses "one rollup signs for testnet" (section 4, item E); ledger X13 status (section 4, item F) | +| The certificates | APPROVED: Windows EV Authenticode and an Apple Developer organisation account, both under Igneum Labs LTD, executed the day the entity exists | LG-3; the runbook in section 2; the signing step in 2.4 | +| The disclosure prize | YES, USD 50,000; payer Igneum Labs LTD; staged until the entity address exists on its documents and the project lead's publish word (`docs/plans/cryptanalysis.md` 3.3, branch `cryptanalysis`, 43d9700b) | LG-13; nothing public until the word | + +## 1. The gates + +The thirteen gate rows are in `docs/plans/testnet-go.md`, section "Launch gates", each with its check, its state today and its owner. The check that keeps them honest: `node tools/ci/launch-gates-check.mjs` fails when a row has no check, when a check names a repository path that does not exist, when the handoff text in section 4 carries a served-page pattern or an em dash, or when one of the eight regulatory sentences is missing or out of order. Its `--self-test` fires on each of those. Both run in `tools/ci/pre-push.sh`. + +What this lane built, and what each gate still needs: + +| Gate | Built here | Still owed, by whom | +|---|---|---| +| LG-1 income per tier | `tools/launch/income-tiers.json` (the measured rows, each with its source), `tools/launch/income-tiers.mjs` (the generator, `--check`), `tools/launch/income-tiers.test.mjs`, `docs/analysis/income-tiers.md` (public) | re-generate at the 0.4.0 cut from class v4 rates (the shipper); the RTX 4060 and Apple wall power, an Intel row (the fleet lane) | +| LG-2, LG-6, LG-7, LG-9, LG-10, LG-12 the hash-origin report | `tools/observer/hash-origin.mjs` (the job: `--dry`, `--write`, `--post`, `--fixture`), its fixture and test; ran read-only on the live devnet tables today | the Devnet 2 observer with a table prefix (fleet lane); the fleet registry's key file (fleet lane); the systemd timer (build-server lane); the two X5 columns (the observer owner); the pool statement format (the pool lane) | +| LG-3 signed installers | the runbook (section 2) and the signing-step specification (2.4) | the project lead: the entity's documents, the two enrolments (section 5); the shipper: the step | +| LG-4 first-share time | the measurement specification (2.5) | the fleet lane: `tools/fleet/first-share-time.sh` | +| LG-5 the text | the handoff block (section 4) | the site lane: land it, rebuild, deploy | +| LG-11 the customer | the gate line and its check | the project lead: the signature; the execution engineer: the paid job | +| LG-13 the prize | the gate line pointing at the staged text | the project lead: escrow, the address, the word | + +## 2. The certificate runbook + +Two enrolments, both in the entity's name, both the day Igneum Labs LTD exists on paper. Neither names the founder publicly: an Apple Developer ID certificate reads `Developer ID Application: Igneum Labs LTD (TEAMID)` and an EV Authenticode certificate reads the entity's registered name; the person who enrols is known to Apple and to the certificate authority, not to the public. + +### 2.1 Apple: the Developer Program as an organisation + +| Item | Value | Source | +|---|---|---| +| Provider | Apple Developer Program, organisation membership | https://developer.apple.com/programs/ (read 7 October 2026 by lane 5: USD 99 a year, notarisation included) | +| Cost | USD 99 a year | the same page | +| What the entity supplies | (1) a D-U-N-S number for Igneum Labs LTD at its registered address (free from Dun and Bradstreet; Apple has its own D-U-N-S lookup and request form; a new entity's number can take days to weeks to issue, approximate); (2) the legal entity name exactly as the DIFC registrar records it; (3) a person with legal authority to bind the entity (a director) who enrols with an Apple ID on an entity mailbox (for example `developer@igneum.network`) with two-factor on; (4) a website on a domain the entity controls (igneum.network); (5) a phone number Apple can call for verification | Apple's enrolment requirements for organisations, from memory, approximate; the exact list is on the enrolment page at the time | +| What comes out | A Team ID; a `Developer ID Application` certificate (and a `Developer ID Installer` certificate if a .pkg is ever shipped); notarisation through `notarytool` with an app-specific password or an App Store Connect API key | Apple's notarisation documentation, from memory | +| Where the key lives | In the login keychain of the Mac that runs `packaging/mac/build-dmg.sh`, exported once to an encrypted .p12 kept with the entity's records; never on igneum-build-1 (CLAUDE.md: the box holds no secret that signs releases) | this lane | +| Time | Enrolment review by Apple: days, approximate; D-U-N-S first | from memory, approximate | + +### 2.2 Windows: an EV Authenticode certificate + +| Item | Value | Source | +|---|---|---| +| Provider | One of the public CAs that issue EV code-signing certificates: DigiCert, Sectigo, GlobalSign, SSL.com (the four this lane knows; from memory). The choice that matters: the CI runner must sign, so pick one whose private key lives in the CA's cloud HSM with a client for Windows (SSL.com eSigner with its CodeSignTool, DigiCert KeyLocker with `smctl`; Sectigo and GlobalSign have hardware-token and cloud options; from memory, approximate). Azure Trusted Signing was considered and set aside: its public-trust tier wants three years of verifiable organisation history (from memory, approximate), which a new DIFC entity cannot show | lane 5 (`reinvent.md` 3.1) for the SmartScreen facts; this lane for the provider notes | +| Cost | USD 300 to 700 a year for EV, approximate, from memory of list prices; cloud signing may add a monthly fee or a per-signature count | approximate | +| Why EV and not OV | Both are hardware-bound since the CA/B Forum's June 2023 rule (private keys in a FIPS 140-2 level 2 token or an HSM; from memory). EV used to grant SmartScreen reputation at once; SSL.com's page says Microsoft "moved away from automatic instant reputation" (`reinvent.md` 3.1, read 7 October 2026), so even EV may show the interstitial until the file earns reputation. the project lead chose EV; the download page states the two clicks until the 1,000-download mark either way | `reinvent.md` 3.1 | +| What the entity supplies | (1) the DIFC certificate of incorporation or commercial licence showing the registered name and address; (2) proof the address is the one on the registrar's record; (3) a telephone number the CA can verify (a public directory listing, or a letter from the entity's accountant or lawyer when there is none); (4) the government ID of the person signing the subscriber agreement and a director's letter authorising that person; (5) the D-U-N-S listing from 2.1, which shortens the CA's organisation check | the EV code-signing guidelines' identity requirements, from memory, approximate; the CA's own checklist governs | +| What comes out | A certificate in the CA's HSM (or a USB token posted to the registered address), a signing account for CI with a short-lived credential, and a timestamp URL | approximate | +| Where the key lives | In the CA's HSM; the CI credential in the repository's GitHub secrets (rotatable); a USB token, if that route is taken, stays with the Mac and signs through `osslsigncode` with a PKCS#11 module; never on igneum-build-1 | this lane | +| Time | Validation 1 to 5 business days after the documents, approximate | from memory | + +### 2.3 Mailboxes and records to create with the entity + +| Item | Why | +|---|---| +| `developer@igneum.network` (or the name the project lead picks) | The Apple ID of the organisation account and the CA's subscriber contact | +| `security@igneum.network` | The disclosure address of the prize (`cryptanalysis.md` 3.3; the project lead's call on the name) | +| The D-U-N-S number | Apple requires it; the CA uses it | +| An encrypted record of the Team ID, the certificate serials, the expiry dates and the renewal month | Renewal is a calendar item the way a domain is | + +### 2.4 The signing step in the shipper's cut (specification; the shipper ae892a8b0f78fe31c implements) + +Today `packaging/mac/build-dmg.sh` signs ad hoc (`codesign -s -`), the app strips its own quarantine on start, and the Windows exes and installer are unsigned (`.github/workflows/windows.yml`, step "installer"). The step below adds signing where each binary is built and verification where the shipper already verifies, so `tools/ship-app.mjs` keeps its step list (`preflight bump inputs commit ci fetch dmg copy mirror manifest deploy verify console`) and gains checks inside `fetch`, `dmg` and `verify` rather than a new step. + +| Where | What changes | Check | +|---|---|---| +| `.github/workflows/windows.yml`, step "installer", before ISCC | Sign `igneum-app.exe`, `igneumd.exe`, `igneum-miner.exe`, the window host and the worker exes with `signtool sign /fd SHA256 /td SHA256 /tr ` through the CA's KSP (the cloud client logs in from two GitHub secrets: the account credential and the TOTP or API key the CA gives); then the Inno script's `SignTool=` directive signs the installer and its uninstaller with the same command. The secrets are absent on a fork or a pull request: the step then builds unsigned and marks the artefact `unsigned`, and the shipper refuses it (next row) | `signtool verify /pa /v dist\*.exe` in the same job prints the signer and the timestamp; the smoke-run step reads it | +| `tools/ship-app.mjs`, `fetch` | After `packaging/windows/fetch-ci-artifacts.sh`, run `osslsigncode verify ` on the Mac (Homebrew `osslsigncode`): the signer CN must equal `Igneum Labs LTD`, the digest SHA-256, a timestamp present; an unsigned or wrongly signed installer fails the step with the line | the step's own exit | +| `packaging/mac/build-dmg.sh` | Replace `codesign -s - -f` with `codesign --force --options runtime --timestamp --sign "Developer ID Application: Igneum Labs LTD (TEAMID)"` on every binary under `Contents/Resources/bin` and `Contents/MacOS`, then the app bundle (with an entitlements file only if a binary needs one; none is known today); `xcrun notarytool submit --keychain-profile igneum-notary --wait` must print `Accepted`; `xcrun stapler staple` the app, then build the DMG, then `xcrun stapler staple` the DMG; remove the app's own quarantine strip (it exists for the ad-hoc case only) | `spctl --assess --type execute -vv ` prints `accepted` and `source=Notarized Developer ID`; `codesign --verify --deep --strict ` exits 0 | +| `packaging/ota/publish-manifest.sh` and the manifest | Two fields per platform file: `signed_by` (the signer CN as verified) and `notarized` (true or false); `publish-manifest.sh` refuses `--public` when either is missing | `tools/ship-app.mjs --check` and the manifest's signature check already run; add the field check there | +| `tools/ship-app.mjs`, `verify` | Besides size and sha256: download the live installer and run `osslsigncode verify`; mount the live DMG and run `spctl --assess`; both results must match the manifest fields | the step's own exit | +| The download page (`site/miner.html`, the site lane) and the Discord release post (`tools/community/discord-hooks.mjs release`) | Show "Signed by Igneum Labs LTD" and the sha256 only when the manifest says so; keep the "what your antivirus may say" line (`reinvent.md` 3.1) and the exact SmartScreen text and two clicks until the 1,000-download mark | `tools/ci/launch-gates-check.mjs` greps nothing here; the site's own build grep runs | +| `tools/ci/signed-release-check.sh` (new, with the implementation) | A manifest in `dl/public/` without `signed_by` on every file fails; `--self-test` with a manifest missing the field | in `tools/ci/pre-push.sh` | + +Order of work for the shipper once the certificates exist: the Mac side first (one machine, one keychain, one release), then the CI side (the cloud-signing client in the runner), then the manifest fields, then the download page. Until the certificates exist nothing in this table runs, and the 0.4.0 cut ships unsigned with the page saying so (`funding.md` section 2, the client audit row: "the one-click app ships at testnet unaudited and says so on the download page"). + +### 2.5 The first-share time, measured per release (specification; the fleet lane builds `tools/fleet/first-share-time.sh`) + +`reinvent.md` 3.1: the time from download to the first accepted share has never been measured end to end on a fresh machine. The measurement is a Devnet 2 gate step, one run per platform per release: + +| Step | What | Where | +|---|---|---| +| 1 | A fresh Windows 11 VM (Hyper-V on the RTX 5090 Windows rig, or a rented Windows box) and a fresh macOS VM (Tart or UTM on the Mac) from clean images; no Igneum files on them | the fleet lane's box library (`tools/fleet/lib/`) for the rented case; a Mac job for the macOS case | +| 2 | The script downloads the release from the public URL, runs the installer (Windows) or opens the DMG and copies the app (macOS), starts the app with the Devnet 2 network setting, and reads the app's own log for three stamps: install done, node synced, dataset built, then the first accepted share or block | the app's log lines are the clock; the script never reads a reported rate | +| 3 | One line into the gate log: `FIRST-SHARE download= sync= dataset= share= version=` | `~/Desktop/fleet/devnet2-gate-.log`, the same file `devnet2-gate.sh` writes | +| 4 | The numbers go to `/evidence` as a row per release ("download to first share, fresh Windows 11: N min M s; fresh macOS: N min M s"), with the date and the version | the site lane | +| Gate | Under 10 minutes in 9 of 10 fresh Windows installs (mission item 6), measured across releases | the /evidence rows | + +## 3. The hash-origin report: what it is and how it runs + +`tools/observer/hash-origin.mjs`. Once a day, from the observer's tables, who found the blocks. It reads `live_blocks` (24 h: vote key, payout address, colour), `live_state` (the node's hash-rate estimate), `miner_logs` (the vote keys the project's intake-reporting workers logged) and, with `--fleet-keys ` or `IGNEUM_FLEET_KEYS_FILE`, the fleet registry's key list. It writes, only with `--write`, its own two tables (`hash_origin_days`: one row per key per day for the 30-day dust and independence counts; `hash_origin_reports`: the day's report as posted) and the jsonb column `hash_origin` on `live_state` for the site. With `--post` it posts to #numbers through `tools/community/discord-hooks.mjs`'s poster (its guard refuses any post with a machine id, a path, an IP or a 32-hex token; key `hash-origin:`, so a day posts once). + +| Command | What | +|---|---| +| `node tools/observer/hash-origin.mjs --fixture tools/observer/fixtures/hash-origin-day.json` | The fabricated day; no database | +| `node tools/observer/hash-origin.mjs --dry [--go 2026-10-20]` | The live tables, read-only (ran today) | +| `node tools/observer/hash-origin.mjs --dry --prefix dn2_` | The Devnet 2 observer's tables, once that observer runs with `LIVE_TABLE_PREFIX=dn2_` | +| `node tools/observer/hash-origin.mjs --write --post --live --go ` | The daily run on the box | +| `node --test tools/observer/hash-origin.test.mjs` | The known-finished and known-failed days; in `tools/ci/pre-push.sh` | + +Today's read-only reading on the live devnet (7 October 2026, 11:xx UK), and what it means (the consequences rule): + +| Line | Reading | What it means, and what is done about it | +|---|---|---| +| Keys | 113 with a block, 95 above the dust line, ten largest 45.0 percent | The devnet runs the project's machines with several identities each (ledger-decisions.md decision 13 moves the default to one key per machine), so 113 keys is not 113 miners; the independent count is the X5 definition and its two owed columns | +| Fleet | 36 keys, 38.4 percent "fleet"; 77 keys, 61.6 percent "outside" | False: the rented boxes do not upload identity lines, so the job cannot see them as the project's. The fleet registry's key file fixes it (`IGNEUM_FLEET_KEYS_FILE`); until the fleet lane exports it, LG-7 is void and the report says so by its numbers | +| Pools | 13 shared payout addresses (68.4 percent); attested pools 0 | A shared payout is a pool or one machine with several identities; the job counts a pool only when attested (the project's own, or an operator's signed key list), so no devnet machine is mistaken for an outside pool and LG-9 cannot pass on a multi-key machine | +| Network | 0.76 GH/s, no yesterday | The step line needs two days of its own table; the first run with `--write` starts the series | + +The runbook for the box (build-server lane; `infra/build-server/hands/` holds the observer's units): + +| Item | Value | +|---|---| +| Unit | `igneum-hash-origin.service` (oneshot) and `igneum-hash-origin.timer`, `OnCalendar=*-*-* 08:30:00 UTC` (before the 09:00 UK digest), `Persistent=true` so a missed day runs at boot | +| Command | `node tools/observer/hash-origin.mjs --write --post --live --go ` from the box's checkout, as the observer user | +| Environment | `EnvironmentFile=/srv/observer/env` (DATABASE_URL) and `/srv/discord-hooks/env` (the webhooks, already on the box by the 6 October exception); `IGNEUM_PROJECT_POOLS=`; `IGNEUM_KNOWN_POOLS=` (empty until a statement exists); `IGNEUM_FLEET_KEYS_FILE=/srv/observer/fleet-keys.txt` (written by the fleet lane's export, one 64-hex key per line, mode 600) | +| Devnet 2 | The same unit with `LIVE_TABLE_PREFIX=dn2_` once the Devnet 2 observer runs; seven days of posts before step 10 is LG-2 | +| 90 days | The timer runs for ever; LG-12 counts the first 90 days from the go in `hash_origin_reports` | +| Gate | The unit is trusted after one run that posted and one run with the database string removed that failed loudly (the watcher rule) | + +## 4. The text, handed to the site lane + +Everything between the two markers is for the site lane (a4b202cabca2d95c0 deploys). It is written to the copy law and `tools/ci/launch-gates-check.mjs` greps it against `site/forbidden-strings.txt` and `tools/ci/forbidden-strings.txt`. The site lane lands it in `site/index.html`, `site/litepaper.html`, `site/journey.json`, rebuilds (`node site/build.mjs`) and pushes; the ledger owner takes item F into `docs/fud-ledger.md` (`tools/ledger-page.mjs` renders it). + + + +### A. The front page: the three wants lead (`site/index.html`, the hero and the first block under it) + +The miners' own words asked for three things (twenty posts and launch texts, 2018 to 2026, `docs/analysis/mission/past.md` section 2: hardware that keeps its value, 10 of 20; income above electricity that does not fall off a cliff, 6; a fair supply, 4). Nobody asked for finality, a DAG or proofs. The front page answers the three in order; finality moves to page two. The h1 stays as it is. Under it, three cards, each with one heading and three to four short lines: + +**1. Your card stays a card.** +The hash is a new random program every hour over a dataset the chain draws from its own state. No scheduled fork, no release a team must ship. The chip model and its number are published with every era on /evidence. When you stop, the card still games. + +**2. Income with no cliff.** +100 IGN a block, falling 2.9 percent a month. No halving day. Then 1 percent of supply a year, for ever. A block pays its miner whether or not anyone buys a proof that day. What each card mines, and what its electricity costs, is one table: the income page. + +**3. A fair supply.** +No premine. No fund, no foundation, no fee to any team. Nobody holds a coin before block one. The founders mine from genesis with disclosed addresses and the same software as everyone else. The first 90 days ramp from 10 percent, so the launch weeks are worth less to a private farm. + +Under the three cards, one line and a link: "Blocks are final by miners alone, with no stake and no other chain. How, on page two." (the link is the litepaper's "Speed and finality" section). + +The income page: render `docs/analysis/income-tiers.md` as `/income` (or link the public mirror's copy) and link it from card 2 and from `/miner`. The page is generated; the site lane does not edit its numbers. + +### B. Page two: finality (`site/litepaper.html`, "Speed and finality") + +No change to the section's text. The change is placement: the front page's hero no longer carries a finality claim; the "Igneum at a glance" block keeps its one finality line and links down to the section. The explorer and the wallet keep their finality state words. + +### C. The block sentence (`site/litepaper.html`, "Three income streams, one balance", directly under the table) + +"A block pays its miner whether or not anyone buys a proof that day. The lottery pays 80 percent of every block from emission; proving is the second income, never the only one. Every useful-work chain on record dropped its miners the day the work stopped paying; Igneum's miners are paid for the block first." + +### D. The eight sentences (`site/litepaper.html`, a new short section "What the chain is, in law" at the end of Economics, under the label "Not legal advice; counsel is engaged") + +Each sentence is `docs/analysis/mission/future.md` 8.3, verified against the file on 7 October 2026 and re-worded to the copy law where the file's own line was a note; the number in brackets is the file's. The heading sentence: "Not legal advice; counsel is engaged. These are the facts of the design that the rules of each region turn on; nothing here is a promotion of anything." + +1. No issuer, no offeror, no sale. Every coin is created automatically as a reward for the maintenance of the distributed ledger or the validation of transactions, and in no other way. (8.3 sentence 1; the quoted words are MiCA Article 4(3)(b)'s, verbatim, as the file asks) +2. The sustainability indicators of Delegated Regulation 2025/422 (energy in kWh a year from the network's hash rate and the measured microjoules per hash, intensity per transaction, the regional mix when it is known) are published by the project every era, so a service provider in the EU can list the coin without asking. (8.3 sentence 2) +3. No financial promotion. No price, no "buy", no "invest", no return language anywhere. The earnings screen shows hash and IGN, never a currency. (8.3 sentence 3; the income page shows electricity in dollars as a cost, never the coin's price, which is this sentence kept) +4. The reference pool never holds a member's balance. Payouts come straight from the coinbase split; the pool coordinates, it does not keep custody. (8.3 sentence 4) +5. The job market settles peer to peer on the chain. There is no operator account and no dollar leg in the protocol: the dollar figure is a quote, the settlement is IGN. (8.3 sentence 5) +6. The software is published under an open licence by a company that holds no coins by right and runs no service the chain's consensus depends on. There is no dev fund. (8.3 sentence 6; the file's line reads "runs no service the chain depends on"; "consensus" is added because the company does run seeds, a public RPC and a log intake, none of which consensus needs; counsel reads both) +7. Mining may be restricted where you are; you are responsible for checking. The miner asks your region at first run and refuses the regions where mining is banned (the file's list on 7 October 2026: ten regions of Russia and Moscow from 15 August 2026, and China). (8.3 sentence 7) +8. No privileged key. No key can mint, pause or upgrade the chain; the only way a rule changes is miners signalling for it, and nothing requires them to. (8.3 sentence 8) + +### E. The journey (`site/journey.json`) + +| Phase | Today | Change | +|---|---|---| +| phase-4, gate | "Finality design passes external review and one rollup signs for testnet" | "Finality design passes external review" | +| phase-5, gate | "1,000 independent miners run 30 days and rollup proofs are delivered on time" | unchanged | +| phase-6 (mainnet), when | "After the testnet has passed its gate: 1,000 independent miners for 30 days and rollup proofs on time" | "After the testnet has passed its gate (1,000 independent miners for 30 days, rollup proofs on time) and one proving customer has signed: a customer paying for proofs at a published rate, or a letter of intent with a volume" | + +### F. The ledger rows (`docs/fud-ledger.md`; ids provisional, the ledger owner renumbers on merge) + +**X13 (existing), status update.** Decided (7 October 2026, 10:1x UK, by the owner): a signed proving customer, paying for proofs at a published rate or a letter of intent with a volume, is a MAINNET gate (testnet-go.md LG-11). The phase 4 gate drops "one rollup signs for testnet". The pilot progression in the answer stands: a signature opens mainnet, repeat purchases and a second unrelated customer are the evidence after it. + +**X37. Your installer is a warning screen.** +"Windows says 'Windows protected your PC' and the Mac refuses to open it. A miner's first screen on your chain is an operating-system warning, and you call that one click." +Status: Open, certificates approved (7 October 2026): an EV Authenticode certificate and an Apple Developer organisation account, both in the entity's name, enrolled the day the entity exists; the signing step is specified for the release tool and runs from the first signed cut. Until then the download page shows the exact warning text and the two clicks. +Answer: True today. The DMG is signed ad hoc and the Windows installer is unsigned. SmartScreen warns on any file without reputation and reputation is use, so the interstitial may outlive the signature by some downloads; the page says so. The measured time from download to the first share on a fresh machine is published per release. +Evidence: testnet-go.md LG-3 and LG-4; launch-pack.md section 2. + +**X38. Nobody will know whose hash the launch is.** +"On launch week your own rented cards will be most of the hash, and the chart will look like Nervos in 2020 or Iron Fish in 2023: a step nobody can explain." +Status: Open, the report built (7 October 2026): a daily hash-origin report from the observer, posted in public for the first 90 days and on the staging chain for seven days before the go: keys with a block, keys above dust, the project's own fleet share, attested pools, the ten largest keys, and any 2x step in the estimate with the keys that carry it. +Answer: Right that the first weeks are the project's own cards plus whoever shows up, and that a chart alone cannot tell them apart. The report names the project's share every day, from the project's own key list, so the step is explained the day it happens. What it cannot do yet: count independent miners (the autonomous-system and fingerprint columns are owed), or tell a pool from a machine with several keys without the pool's own signed statement. +Evidence: testnet-go.md LG-2, LG-6, LG-7, LG-9, LG-12; tools/observer/hash-origin.mjs. + +**E23. You will show a number that makes someone buy a card.** +"Every GPU chain's launch page had an earnings number, and every one was wrong inside six months." +Status: Stated (7 October 2026): the income page shows IGN a day per measured card at three network sizes, electricity a day at three tariffs, and the electricity cost of one mined IGN; no coin price appears, every rate is a measurement with its source, and the page says what each tier should expect from the record of other chains. +Answer: Agreed, and the record is the argument: income halves within 60 to 120 days of a peak and falls under power within 6 to 18 months on every chain in the sample. The page shows the arithmetic the miner can redo with the live network figure, and nothing else. +Evidence: docs/analysis/income-tiers.md; testnet-go.md LG-1. + +**L10. The eight sentences.** +"You say 'not legal advice' and then write eight sentences of it." +Status: Open, counsel engaged (the owner, 6 October 2026); the eight sentences are the design facts the rules turn on, each cited to its regime in the research file, and they go to counsel with the litepaper before mainnet. +Answer: The sentences state what the design does (no issuer, no custody in the pool, no dollar leg, no privileged key, the region refusal) and what the project publishes (the energy indicators); they do not say what any law concludes. Counsel decides the wording for each region. +Evidence: docs/analysis/mission/future.md section 8; testnet-go.md LG-5. + + + +## 5. What needs the project lead + +| # | Item | What exactly | Blocks | +|---|---|---|---| +| 1 | The entity's documents | Igneum Labs LTD's certificate of incorporation or DIFC commercial licence, proof of the registered address, a director's government ID, a director's authorisation letter naming who enrols and signs | LG-3 (both certificates), LG-13 (the payer's address on the prize text) | +| 2 | The D-U-N-S number | Request it for Igneum Labs LTD at the registered address (free; days to weeks, approximate) | the Apple enrolment; the CA's organisation check | +| 3 | The Apple Developer Program enrolment | As an organisation, on an entity mailbox with two-factor, USD 99 a year, the project lead as the person with authority; Apple may call | LG-3 (the Mac side) | +| 4 | The EV certificate order | Pick the CA (a cloud-HSM one so the CI runner signs: SSL.com eSigner or DigiCert KeyLocker, approximate), pay (USD 300 to 700 a year, approximate), take the validation call, receive the signing account; the CI credential goes into the repository's secrets | LG-3 (the Windows side) | +| 5 | The proving customer's signature | One customer paying for proofs at a published rate, or a signed letter of intent with a volume (Taiko is the named first customer; the brief is ledger X13's) | LG-11, mainnet | +| 6 | The prize | Escrow USD 50,000 with the entity; confirm the registered address on the staged text; give the publish word; pick the disclosure mailbox name | LG-13 | +| 7 | Two mailboxes | `developer@igneum.network` (or the project lead's name for it) and `security@igneum.network` | items 3, 4 and 6 | +| 8 | The three tariffs | DECIDED (the coordinator for the project lead, 7 October 2026, 11:xx UK): electricity tariffs per kWh, never a coin price; the triple is USD 0.05 (cheap industrial), 0.10 (US retail) and 0.25 (UK retail at today's rate), and the table was regenerated on it. Nothing left here | none | +| 9 | Permission to post the first outside block | reinvent.md 4.1 G-C2: the "first outside block" post needs the owner's permission | LG-7's post, not its check | + +## 6. Not done here, and why + +| Item | Why not | Who | +|---|---|---| +| Any change to a live page or to `site/` | The site lane deploys; this lane hands text (section 4) | site lane | +| The signing step's code | A specification only (2.4); the shipper implements when the certificates exist | shipper | +| `tools/fleet/first-share-time.sh` | A specification only (2.5); it needs the fleet library and a Windows VM job | fleet lane | +| The Devnet 2 observer and the fleet key file | Fleet-side; without them LG-2 and LG-7 cannot fire | fleet lane | +| The systemd timer on the box | Box-side; the unit is specified in section 3 | build-server lane | +| The X5 observer columns | The app-owner item of ledger-decisions.md section 3 | observer owner | +| Ledger edits | Handed as rows (item F); the ledger owner merges and renumbers | ledger owner | +| The litepaper artifact (the Claude doc) | The site's `litepaper.html` is the public copy the handoff targets; the doc follows the site | site lane | diff --git a/docs/plans/ledger-decisions.md b/docs/plans/ledger-decisions.md index 1ac6842c..7639ef79 100644 --- a/docs/plans/ledger-decisions.md +++ b/docs/plans/ledger-decisions.md @@ -102,3 +102,13 @@ Still owed from the project lead after the close: the cryptanalysis spend (fundi | 7 | Testnet date | Leave open | No month anywhere; the go checklist is the date. | Standing rulings of the same hour: "We dont want to penalise holders" (dormant-coin rent and anything that takes from a balance or taxes inactivity is refused for ever); vote-or-burn is implemented only if 95 percent or more of the mining community would respect it (the weigh-up lane decides between the burn and the signing bonus). + +## Decisions (7 October 2026, 09:3x UK), the project lead's approvals + +| # | Decision | the project lead's word | What it sets | +|---|---|---|---| +| 1 | Emission schedule | Approved | The testnet genesis carries `EmissionSchedule::TESTNET_1`: 100 IGN a block at 1 bps, a monthly glide with a two-year half-life, a 90-day ramp from 10 percent, a tail of 1 percent of supply a year from the month the glide first pays under it (about year 11.4). No hard cap; the public sentence is the one in docs/analysis/tail-emission.md. Ledger E22 moves to Decided. The devnet keeps `CURRENT`. | +| 2 | Signing bonus at the testnet genesis, no burn | Approved | `signing_bonus_activation_daa` = 0 and `signing_bonus_bps` = 1,000 in the testnet genesis; the unsigned tenth to the proving pool; the vote-or-burn code leaves the tree before the testnet code is public. | +| 3 | The latency ladder | Approved | The six rungs (27, 35, 53, 88, 173, 267 passes), rungs 0 to 2 admissible, rung 3 re-measured on a quiet core before genesis, 4 and 5 inadmissible until verifiers allow; every step by 90 percent in each of seven windows, never unconditional; `latency_ladder_activation_daa` = 0 on the testnet at rung 0. | +| 4 | Cryptanalysis | Approved, "make sure they find ZERO flaws, also cut costs if possible" | The engagement runs at the low point (about USD 80,000) unless a quote forces more; an internal attack pass precedes it so the firms find nothing new; every finding is fixed before the testnet go. The contracting entity and the prize are still the project lead's to confirm. | +| 5 | Re-cut the testnet genesis | Approved | One cut with 18 decimals, `TESTNET_1`, and the switches on from genesis: proof verification, the leave item, the signing bonus, finality v3, the ladder at rung 0. Nothing live is touched; the go checklist decides the date. | diff --git a/docs/plans/site-copy-pass.md b/docs/plans/site-copy-pass.md new file mode 100644 index 00000000..77aff9d4 --- /dev/null +++ b/docs/plans/site-copy-pass.md @@ -0,0 +1,46 @@ +# Site copy pass, 7 October 2026 + +the project lead, 11:2x UK: "free reign to check the copy everywhere to make it sound as human, friendly and GPU community focused." +Done as part of the redesign integration, on every served page. The register: one miner talking to another, second +person where it fits, no corporate voice, no hype, no scare. Every fact and number is exactly as our files state it; +the ledger's stated sentences (tools/ci/ledger-text-check.mjs), the regulatory lines and "not an offer to sell +anything" are verbatim. Copy law kept: no em dashes, no two-beat antithesis, no aphorisms, short sentences, numbers in +tables, no orphan word on a line (tools/ci/site-orphan-check.mjs at 390 px). + +## The twenty biggest changes + +| # | Page | Before | After | +|---|---|---|---| +| 1 | Home, hero | A proof-of-work chain for graphics cards, whose miners prove the blocks. | Your GPU has more to give. (the package's line, kept) + You already own the card. Igneum gives it a job worth doing: mine the block, prove it, watch it lock. One click installs the node, the miner and the prover. | +| 2 | Home, principles | (none; the home page was the scene and three facts) | Graphics cards only / The miners are the provers / No premine, no stake / Every claim has a status, one line each under the hero | +| 3 | Home, live panel | (the scene with no heading) | Follow the work. See the chain grow. + "Every square is a real block, read from one node every 2 s. Nothing here is a replay." | +| 4 | Home, reasons | (none) | Three reasons to power on: A program that never holds still / Work you can see / One click, and it mines, each in plain words with the measured limit named | +| 4a | Home, reasons (7 October 2026, the launch pack) | Three reasons to power on | Three things, in order: Your card stays a card / Income with no cliff / A fair supply, the three asks of twenty miner launch posts (docs/plans/launch-pack.md section 4 A), in the same three cards; the income card carries no emission number until the genesis re-cut, and the line under the grid points at the litepaper's finality section | +| 5 | Home, economics | (on the litepaper only) | Made for the people running the hardware. Every block pays the card that found it and the cards that prove it. The protocol carves out nothing for a team, a foundation or a fund. | +| 6 | Home, CTA band | (none) | Give your GPU something to do. Download Ember, watch the devnet, and tell us what breaks. The people on the Discord run cards like yours. | +| 7 | Miner, hero | Install. Start. The card mines. (kept) | The miner built around your card. Your rate, your watts, what it costs a day at your price, and the chain drawn live with your own blocks ringed. | +| 8 | Miner, downloads | Three buttons in a list | A platform card: Windows, macOS, Linux / HiveOS, each with one sentence of what to expect ("A Mac mines on its GPU at about a fifth of a flagship card and proves on its CPU, slowly."), the signed file, its version, size and sha256 | +| 9 | Miner, steps | (none) | Check your card / Install the official build / Press Start, then tell us, with the seed-phrase warning in the second person: "Keep it to yourself. This site never asks for it." | +| 10 | Miner, FAQ | (none) | Six questions miners ask first: does the website mine on my GPU, does my card mine and prove, is the devnet paying real money, is there a fee, can I run it on a rig or in a pool, where do the numbers come from | +| 11 | Miner, Linux tab | Install on a Hive rig | For the rig people. One tarball, the miner and the node inside, the same signed manifest as the desktop apps. | +| 12 | Wallet, hero | Your coins. Final means final. (kept) | ... it checks every finality certificate itself with the node's own code. No confirmation counts, no trusting the node. (verifies -> checks) | +| 13 | Wallet, MetaMask | One click adds the Igneum network with its chain id and RPC. | + a link to the same values on this site, so a Windows or Linux miner has a path today | +| 14 | Journey (new page) | Journey linked to the litepaper's roadmap table | Six phases from the specification to a fair launch. Each closes at its gate, a measurement published whether it passes or fails, so there is no date to slip. + the log, newest first, with a filter | +| 15 | Claims (new page) | Footer link into the litepaper | What Igneum does not claim. Every limit we know of, written down here before anyone else writes it. (the body is the litepaper's section, unchanged) | +| 16 | RandomX (new page) | Footer link into the litepaper | Random-program mining is the idea Igneum borrowed. Here is what changed when it was rebuilt for graphics cards, and what RandomX's seven years say and do not say about this chain. | +| 17 | Explorer | Paste a block hash, a transaction hash, a chain block number or an address. | ... or click any row. | +| 18 | Faucet | Paste an address. The faucet sends 10 testnet IGN and shows the transaction hash. | ... and shows you the transaction hash. Once per address per day, once per connection per day. No account, no sign-in, nothing to install. | +| 19 | Live devnet | Every block has a story. Follow the connections. | Every block has a story. Follow the connections, and find your own. | +| 20 | 404 | The pages below are where most readers want to go | The pages below are where most people want to go; the miner page added as the first card | + +## What was deliberately left alone + +- The litepaper's text: every section is our text as it stood on master (the X9 relabelling, the X31 to X36 corrections, the chip model), under the package's reading layout. The reading tone is already plain; the technical sections stay precise. +- The ledger, the evidence table, the bench log and the bench table: generated from docs/, restyled only. +- The app page's feature copy (already in the register) and every screenshot caption, which names the machine, the version and the time. +- The chip-model paragraph on the home page and the miner page: the Counter ASIC lane's current text, word for word. +- The downloads notices: "Public testnet: not yet open; the devnet build is here for people who want to look." and the rest, verbatim (ledger rows X2, X31, E5). + +## Removed from the package, not served + +The package's own copy where it made claims our files do not: "Hardware becomes the network" (kept as "Your card becomes the network", an illustration caption), its sample wallet balance and sample address, its "Simulated" app window, its "Sample feed" labels, its historical benchmark examples, its "optional 1% software dev fee" phrasing where it drifted from the measured 1.146 percent and the one-flag rule, and its launch-date language. diff --git a/docs/plans/site-ui-3-shots/v5/404-1440-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/404-1440-dark-fold.jpg new file mode 100644 index 00000000..25ba041e Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/404-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/404-1440-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/404-1440-dark-full.jpg new file mode 100644 index 00000000..a81e8aef Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/404-1440-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/404-1440-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/404-1440-light-fold.jpg new file mode 100644 index 00000000..1ba39625 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/404-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/404-1440-light-full.jpg b/docs/plans/site-ui-3-shots/v5/404-1440-light-full.jpg new file mode 100644 index 00000000..369e4b5a Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/404-1440-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/404-390-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/404-390-dark-fold.jpg new file mode 100644 index 00000000..cfc34c86 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/404-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/404-390-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/404-390-dark-full.jpg new file mode 100644 index 00000000..33e45aa1 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/404-390-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/404-390-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/404-390-light-fold.jpg new file mode 100644 index 00000000..d4035ca4 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/404-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/404-390-light-full.jpg b/docs/plans/site-ui-3-shots/v5/404-390-light-full.jpg new file mode 100644 index 00000000..8259e0e8 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/404-390-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/app-1440-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/app-1440-dark-fold.jpg new file mode 100644 index 00000000..061bf676 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/app-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/app-1440-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/app-1440-dark-full.jpg new file mode 100644 index 00000000..13f62910 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/app-1440-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/app-1440-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/app-1440-light-fold.jpg new file mode 100644 index 00000000..2410ec4e Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/app-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/app-1440-light-full.jpg b/docs/plans/site-ui-3-shots/v5/app-1440-light-full.jpg new file mode 100644 index 00000000..1b0ba1ad Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/app-1440-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/app-390-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/app-390-dark-fold.jpg new file mode 100644 index 00000000..a16fa6eb Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/app-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/app-390-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/app-390-dark-full.jpg new file mode 100644 index 00000000..31ca6720 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/app-390-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/app-390-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/app-390-light-fold.jpg new file mode 100644 index 00000000..d43dbb46 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/app-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/app-390-light-full.jpg b/docs/plans/site-ui-3-shots/v5/app-390-light-full.jpg new file mode 100644 index 00000000..1d5d9d5f Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/app-390-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/bench-1440-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/bench-1440-dark-fold.jpg new file mode 100644 index 00000000..5077a11c Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/bench-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/bench-1440-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/bench-1440-light-fold.jpg new file mode 100644 index 00000000..4b7465ff Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/bench-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/bench-390-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/bench-390-dark-fold.jpg new file mode 100644 index 00000000..b240dbe3 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/bench-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/bench-390-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/bench-390-light-fold.jpg new file mode 100644 index 00000000..7511b12f Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/bench-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/home-1440-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/home-1440-dark-fold.jpg new file mode 100644 index 00000000..c3daf626 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/home-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/home-1440-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/home-1440-dark-full.jpg new file mode 100644 index 00000000..b46c6604 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/home-1440-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/home-1440-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/home-1440-light-fold.jpg new file mode 100644 index 00000000..99156244 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/home-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/home-1440-light-full.jpg b/docs/plans/site-ui-3-shots/v5/home-1440-light-full.jpg new file mode 100644 index 00000000..41ff5400 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/home-1440-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/home-390-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/home-390-dark-fold.jpg new file mode 100644 index 00000000..36f8b380 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/home-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/home-390-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/home-390-dark-full.jpg new file mode 100644 index 00000000..d607b263 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/home-390-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/home-390-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/home-390-light-fold.jpg new file mode 100644 index 00000000..495441de Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/home-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/home-390-light-full.jpg b/docs/plans/site-ui-3-shots/v5/home-390-light-full.jpg new file mode 100644 index 00000000..f2a9ec79 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/home-390-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/ledger-1440-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/ledger-1440-dark-fold.jpg new file mode 100644 index 00000000..99674662 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/ledger-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/ledger-1440-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/ledger-1440-light-fold.jpg new file mode 100644 index 00000000..2c160f15 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/ledger-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/ledger-390-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/ledger-390-dark-fold.jpg new file mode 100644 index 00000000..9be0582d Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/ledger-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/ledger-390-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/ledger-390-light-fold.jpg new file mode 100644 index 00000000..134fdcdc Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/ledger-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/litepaper-1440-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/litepaper-1440-dark-fold.jpg new file mode 100644 index 00000000..a336a6ab Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/litepaper-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/litepaper-1440-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/litepaper-1440-light-fold.jpg new file mode 100644 index 00000000..2fec621a Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/litepaper-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/litepaper-390-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/litepaper-390-dark-fold.jpg new file mode 100644 index 00000000..93d69c81 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/litepaper-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/litepaper-390-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/litepaper-390-light-fold.jpg new file mode 100644 index 00000000..fa4ab58e Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/litepaper-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/live-1440-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/live-1440-dark-fold.jpg new file mode 100644 index 00000000..d51afcf6 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/live-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/live-1440-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/live-1440-dark-full.jpg new file mode 100644 index 00000000..d1aad2d2 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/live-1440-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/live-1440-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/live-1440-light-fold.jpg new file mode 100644 index 00000000..c0dd19c6 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/live-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/live-1440-light-full.jpg b/docs/plans/site-ui-3-shots/v5/live-1440-light-full.jpg new file mode 100644 index 00000000..46eb3f8e Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/live-1440-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/live-390-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/live-390-dark-fold.jpg new file mode 100644 index 00000000..177e3a51 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/live-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/live-390-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/live-390-dark-full.jpg new file mode 100644 index 00000000..923c1f75 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/live-390-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/live-390-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/live-390-light-fold.jpg new file mode 100644 index 00000000..6ec37527 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/live-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/live-390-light-full.jpg b/docs/plans/site-ui-3-shots/v5/live-390-light-full.jpg new file mode 100644 index 00000000..5b8b7775 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/live-390-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/miner-1440-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/miner-1440-dark-fold.jpg new file mode 100644 index 00000000..552d53c9 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/miner-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/miner-1440-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/miner-1440-dark-full.jpg new file mode 100644 index 00000000..92e434d0 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/miner-1440-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/miner-1440-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/miner-1440-light-fold.jpg new file mode 100644 index 00000000..2550dac9 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/miner-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/miner-1440-light-full.jpg b/docs/plans/site-ui-3-shots/v5/miner-1440-light-full.jpg new file mode 100644 index 00000000..b43ff15d Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/miner-1440-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/miner-390-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/miner-390-dark-fold.jpg new file mode 100644 index 00000000..c4aaef04 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/miner-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/miner-390-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/miner-390-dark-full.jpg new file mode 100644 index 00000000..8748f3a4 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/miner-390-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/miner-390-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/miner-390-light-fold.jpg new file mode 100644 index 00000000..6df11d49 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/miner-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/miner-390-light-full.jpg b/docs/plans/site-ui-3-shots/v5/miner-390-light-full.jpg new file mode 100644 index 00000000..72c0bd37 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/miner-390-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/wallet-1440-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/wallet-1440-dark-fold.jpg new file mode 100644 index 00000000..0356743f Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/wallet-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/wallet-1440-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/wallet-1440-dark-full.jpg new file mode 100644 index 00000000..5c16d723 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/wallet-1440-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/wallet-1440-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/wallet-1440-light-fold.jpg new file mode 100644 index 00000000..9e1d8937 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/wallet-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/wallet-1440-light-full.jpg b/docs/plans/site-ui-3-shots/v5/wallet-1440-light-full.jpg new file mode 100644 index 00000000..87ed05df Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/wallet-1440-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/wallet-390-dark-fold.jpg b/docs/plans/site-ui-3-shots/v5/wallet-390-dark-fold.jpg new file mode 100644 index 00000000..1fd9a77c Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/wallet-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/wallet-390-dark-full.jpg b/docs/plans/site-ui-3-shots/v5/wallet-390-dark-full.jpg new file mode 100644 index 00000000..b3821d04 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/wallet-390-dark-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/wallet-390-light-fold.jpg b/docs/plans/site-ui-3-shots/v5/wallet-390-light-fold.jpg new file mode 100644 index 00000000..e99a12d9 Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/wallet-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-3-shots/v5/wallet-390-light-full.jpg b/docs/plans/site-ui-3-shots/v5/wallet-390-light-full.jpg new file mode 100644 index 00000000..b5fcc9be Binary files /dev/null and b/docs/plans/site-ui-3-shots/v5/wallet-390-light-full.jpg differ diff --git a/docs/plans/site-ui-3-shots/wallet-light/history-dark.png b/docs/plans/site-ui-3-shots/wallet-light/history-dark.png new file mode 100644 index 00000000..cc1b7d3e Binary files /dev/null and b/docs/plans/site-ui-3-shots/wallet-light/history-dark.png differ diff --git a/docs/plans/site-ui-3-shots/wallet-light/history-light.png b/docs/plans/site-ui-3-shots/wallet-light/history-light.png new file mode 100644 index 00000000..aa96ec98 Binary files /dev/null and b/docs/plans/site-ui-3-shots/wallet-light/history-light.png differ diff --git a/docs/plans/site-ui-3-shots/wallet-light/home-dark.png b/docs/plans/site-ui-3-shots/wallet-light/home-dark.png new file mode 100644 index 00000000..583155fc Binary files /dev/null and b/docs/plans/site-ui-3-shots/wallet-light/home-dark.png differ diff --git a/docs/plans/site-ui-3-shots/wallet-light/home-light.png b/docs/plans/site-ui-3-shots/wallet-light/home-light.png new file mode 100644 index 00000000..94f63601 Binary files /dev/null and b/docs/plans/site-ui-3-shots/wallet-light/home-light.png differ diff --git a/docs/plans/site-ui-3-shots/wallet-light/tx-dark.png b/docs/plans/site-ui-3-shots/wallet-light/tx-dark.png new file mode 100644 index 00000000..5e648d66 Binary files /dev/null and b/docs/plans/site-ui-3-shots/wallet-light/tx-dark.png differ diff --git a/docs/plans/site-ui-3-shots/wallet-light/tx-light.png b/docs/plans/site-ui-3-shots/wallet-light/tx-light.png new file mode 100644 index 00000000..6fe537f4 Binary files /dev/null and b/docs/plans/site-ui-3-shots/wallet-light/tx-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/cards/home-1440-dark.png b/docs/plans/site-ui-4-shots/chrome/cards/home-1440-dark.png new file mode 100644 index 00000000..86fe5db3 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/cards/home-1440-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/cards/home-1440-light.png b/docs/plans/site-ui-4-shots/chrome/cards/home-1440-light.png new file mode 100644 index 00000000..10bdabff Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/cards/home-1440-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/cards/home-390-dark.png b/docs/plans/site-ui-4-shots/chrome/cards/home-390-dark.png new file mode 100644 index 00000000..318997f9 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/cards/home-390-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/cards/home-390-light.png b/docs/plans/site-ui-4-shots/chrome/cards/home-390-light.png new file mode 100644 index 00000000..90313ed9 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/cards/home-390-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/cards/miner-1440-dark.png b/docs/plans/site-ui-4-shots/chrome/cards/miner-1440-dark.png new file mode 100644 index 00000000..50fa336b Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/cards/miner-1440-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/cards/miner-1440-light.png b/docs/plans/site-ui-4-shots/chrome/cards/miner-1440-light.png new file mode 100644 index 00000000..ed2d1ba4 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/cards/miner-1440-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/cards/miner-390-dark.png b/docs/plans/site-ui-4-shots/chrome/cards/miner-390-dark.png new file mode 100644 index 00000000..648a3a00 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/cards/miner-390-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/cards/miner-390-light.png b/docs/plans/site-ui-4-shots/chrome/cards/miner-390-light.png new file mode 100644 index 00000000..3ed1cc08 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/cards/miner-390-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/footer/home-1440-dark.png b/docs/plans/site-ui-4-shots/chrome/footer/home-1440-dark.png new file mode 100644 index 00000000..10314980 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/footer/home-1440-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/footer/home-1440-light.png b/docs/plans/site-ui-4-shots/chrome/footer/home-1440-light.png new file mode 100644 index 00000000..8388454e Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/footer/home-1440-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/footer/home-390-dark.png b/docs/plans/site-ui-4-shots/chrome/footer/home-390-dark.png new file mode 100644 index 00000000..69c1674f Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/footer/home-390-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/footer/home-390-light.png b/docs/plans/site-ui-4-shots/chrome/footer/home-390-light.png new file mode 100644 index 00000000..af616698 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/footer/home-390-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/footer/miner-1440-dark.png b/docs/plans/site-ui-4-shots/chrome/footer/miner-1440-dark.png new file mode 100644 index 00000000..61ff40ac Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/footer/miner-1440-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/footer/miner-1440-light.png b/docs/plans/site-ui-4-shots/chrome/footer/miner-1440-light.png new file mode 100644 index 00000000..bb35e027 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/footer/miner-1440-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/footer/miner-390-dark.png b/docs/plans/site-ui-4-shots/chrome/footer/miner-390-dark.png new file mode 100644 index 00000000..99d83c98 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/footer/miner-390-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/footer/miner-390-light.png b/docs/plans/site-ui-4-shots/chrome/footer/miner-390-light.png new file mode 100644 index 00000000..5a724153 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/footer/miner-390-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-1440-dark-bar.png b/docs/plans/site-ui-4-shots/chrome/header/home-1440-dark-bar.png new file mode 100644 index 00000000..d987d76c Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-1440-dark-bar.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-1440-light-bar.png b/docs/plans/site-ui-4-shots/chrome/header/home-1440-light-bar.png new file mode 100644 index 00000000..085b084b Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-1440-light-bar.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-390-dark-closed.png b/docs/plans/site-ui-4-shots/chrome/header/home-390-dark-closed.png new file mode 100644 index 00000000..196de636 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-390-dark-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-390-dark-open.png b/docs/plans/site-ui-4-shots/chrome/header/home-390-dark-open.png new file mode 100644 index 00000000..7a7e97b0 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-390-dark-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-390-light-closed.png b/docs/plans/site-ui-4-shots/chrome/header/home-390-light-closed.png new file mode 100644 index 00000000..83e795f8 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-390-light-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-390-light-open.png b/docs/plans/site-ui-4-shots/chrome/header/home-390-light-open.png new file mode 100644 index 00000000..52bf2db2 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-390-light-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-768-dark-closed.png b/docs/plans/site-ui-4-shots/chrome/header/home-768-dark-closed.png new file mode 100644 index 00000000..b8e3f893 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-768-dark-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-768-dark-open.png b/docs/plans/site-ui-4-shots/chrome/header/home-768-dark-open.png new file mode 100644 index 00000000..1f788795 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-768-dark-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-768-light-closed.png b/docs/plans/site-ui-4-shots/chrome/header/home-768-light-closed.png new file mode 100644 index 00000000..10b7975a Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-768-light-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/home-768-light-open.png b/docs/plans/site-ui-4-shots/chrome/header/home-768-light-open.png new file mode 100644 index 00000000..ed6014f9 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/home-768-light-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/ledger-1440-dark-bar.png b/docs/plans/site-ui-4-shots/chrome/header/ledger-1440-dark-bar.png new file mode 100644 index 00000000..674e90a0 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/ledger-1440-dark-bar.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/ledger-1440-light-bar.png b/docs/plans/site-ui-4-shots/chrome/header/ledger-1440-light-bar.png new file mode 100644 index 00000000..3652539f Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/ledger-1440-light-bar.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-1440-dark-bar.png b/docs/plans/site-ui-4-shots/chrome/header/live-1440-dark-bar.png new file mode 100644 index 00000000..fb38baf4 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-1440-dark-bar.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-1440-light-bar.png b/docs/plans/site-ui-4-shots/chrome/header/live-1440-light-bar.png new file mode 100644 index 00000000..ed490037 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-1440-light-bar.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-390-dark-closed.png b/docs/plans/site-ui-4-shots/chrome/header/live-390-dark-closed.png new file mode 100644 index 00000000..7e044ca2 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-390-dark-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-390-dark-open.png b/docs/plans/site-ui-4-shots/chrome/header/live-390-dark-open.png new file mode 100644 index 00000000..e58bcc3e Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-390-dark-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-390-light-closed.png b/docs/plans/site-ui-4-shots/chrome/header/live-390-light-closed.png new file mode 100644 index 00000000..5cd1421d Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-390-light-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-390-light-open.png b/docs/plans/site-ui-4-shots/chrome/header/live-390-light-open.png new file mode 100644 index 00000000..c231bebd Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-390-light-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-768-dark-closed.png b/docs/plans/site-ui-4-shots/chrome/header/live-768-dark-closed.png new file mode 100644 index 00000000..2c8ecde0 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-768-dark-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-768-dark-open.png b/docs/plans/site-ui-4-shots/chrome/header/live-768-dark-open.png new file mode 100644 index 00000000..3c38c3c5 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-768-dark-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-768-light-closed.png b/docs/plans/site-ui-4-shots/chrome/header/live-768-light-closed.png new file mode 100644 index 00000000..a57e1dff Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-768-light-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/live-768-light-open.png b/docs/plans/site-ui-4-shots/chrome/header/live-768-light-open.png new file mode 100644 index 00000000..6d56c332 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/live-768-light-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-1440-dark-bar.png b/docs/plans/site-ui-4-shots/chrome/header/miner-1440-dark-bar.png new file mode 100644 index 00000000..3be0d458 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-1440-dark-bar.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-1440-light-bar.png b/docs/plans/site-ui-4-shots/chrome/header/miner-1440-light-bar.png new file mode 100644 index 00000000..43d0bf9e Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-1440-light-bar.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-390-dark-closed.png b/docs/plans/site-ui-4-shots/chrome/header/miner-390-dark-closed.png new file mode 100644 index 00000000..ae808327 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-390-dark-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-390-dark-open.png b/docs/plans/site-ui-4-shots/chrome/header/miner-390-dark-open.png new file mode 100644 index 00000000..f363e3b8 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-390-dark-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-390-light-closed.png b/docs/plans/site-ui-4-shots/chrome/header/miner-390-light-closed.png new file mode 100644 index 00000000..3b8d6046 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-390-light-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-390-light-open.png b/docs/plans/site-ui-4-shots/chrome/header/miner-390-light-open.png new file mode 100644 index 00000000..2faf0959 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-390-light-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-768-dark-closed.png b/docs/plans/site-ui-4-shots/chrome/header/miner-768-dark-closed.png new file mode 100644 index 00000000..02fc994b Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-768-dark-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-768-dark-open.png b/docs/plans/site-ui-4-shots/chrome/header/miner-768-dark-open.png new file mode 100644 index 00000000..38f94b27 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-768-dark-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-768-light-closed.png b/docs/plans/site-ui-4-shots/chrome/header/miner-768-light-closed.png new file mode 100644 index 00000000..007dc39a Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-768-light-closed.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/header/miner-768-light-open.png b/docs/plans/site-ui-4-shots/chrome/header/miner-768-light-open.png new file mode 100644 index 00000000..fa4ff579 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/header/miner-768-light-open.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/report.json b/docs/plans/site-ui-4-shots/chrome/report.json new file mode 100644 index 00000000..7067a5d8 --- /dev/null +++ b/docs/plans/site-ui-4-shots/chrome/report.json @@ -0,0 +1,3020 @@ +{ + "header": [ + { + "page": "/", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Igneum, the GPU-mined layer 1", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/litepaper", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Igneum Litepaper: how the chain works", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Litepaper", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/miner", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Igneum Ember, the one-click GPU miner", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Miner", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/app", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Igneum Ember, the app", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "App", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/wallet", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Igneum Wallet", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Wallet", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/live", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Igneum live devnet", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Live devnet", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/ledger", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Igneum ledger: every criticism, answered", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Ledger", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 487, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/bench", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Igneum engineering log", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/evidence", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Igneum evidence", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/no-such-page", + "width": 390, + "scheme": "dark", + "closed": { + "status": "Page not found. Igneum", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Igneum, the GPU-mined layer 1", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/litepaper", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Igneum Litepaper: how the chain works", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Litepaper", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/miner", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Igneum Ember, the one-click GPU miner", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Miner", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/app", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Igneum Ember, the app", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "App", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/wallet", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Igneum Wallet", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Wallet", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/live", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Igneum live devnet", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Live devnet", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/ledger", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Igneum ledger: every criticism, answered", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Ledger", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 487, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/bench", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Igneum engineering log", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/evidence", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Igneum evidence", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/no-such-page", + "width": 768, + "scheme": "dark", + "closed": { + "status": "Page not found. Igneum", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/", + "width": 390, + "scheme": "light", + "closed": { + "status": "Igneum, the GPU-mined layer 1", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/litepaper", + "width": 390, + "scheme": "light", + "closed": { + "status": "Igneum Litepaper: how the chain works", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Litepaper", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/miner", + "width": 390, + "scheme": "light", + "closed": { + "status": "Igneum Ember, the one-click GPU miner", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Miner", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/app", + "width": 390, + "scheme": "light", + "closed": { + "status": "Igneum Ember, the app", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "App", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/wallet", + "width": 390, + "scheme": "light", + "closed": { + "status": "Igneum Wallet", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Wallet", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/live", + "width": 390, + "scheme": "light", + "closed": { + "status": "Igneum live devnet", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Live devnet", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/ledger", + "width": 390, + "scheme": "light", + "closed": { + "status": "Igneum ledger: every criticism, answered", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Ledger", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 487, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/bench", + "width": 390, + "scheme": "light", + "closed": { + "status": "Igneum engineering log", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/evidence", + "width": 390, + "scheme": "light", + "closed": { + "status": "Igneum evidence", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/no-such-page", + "width": 390, + "scheme": "light", + "closed": { + "status": "Page not found. Igneum", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 844 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/", + "width": 768, + "scheme": "light", + "closed": { + "status": "Igneum, the GPU-mined layer 1", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/litepaper", + "width": 768, + "scheme": "light", + "closed": { + "status": "Igneum Litepaper: how the chain works", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Litepaper", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/miner", + "width": 768, + "scheme": "light", + "closed": { + "status": "Igneum Ember, the one-click GPU miner", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Miner", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/app", + "width": 768, + "scheme": "light", + "closed": { + "status": "Igneum Ember, the app", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "App", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/wallet", + "width": 768, + "scheme": "light", + "closed": { + "status": "Igneum Wallet", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Wallet", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/live", + "width": 768, + "scheme": "light", + "closed": { + "status": "Igneum live devnet", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Live devnet", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/ledger", + "width": 768, + "scheme": "light", + "closed": { + "status": "Igneum ledger: every criticism, answered", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": "Ledger", + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 487, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/bench", + "width": 768, + "scheme": "light", + "closed": { + "status": "Igneum engineering log", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/evidence", + "width": 768, + "scheme": "light", + "closed": { + "status": "Igneum evidence", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/no-such-page", + "width": 768, + "scheme": "light", + "closed": { + "status": "Page not found. Igneum", + "hscroll": false, + "burgerVisible": true, + "burgerHit": [ + 44, + 44 + ], + "barVisible": 0, + "barItems": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "expanded": "false", + "current": null, + "word": true + }, + "open": { + "open": true, + "expanded": "true", + "label": "Close the menu", + "sheetVisible": true, + "items": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger", + "Download" + ], + "minHit": 48, + "hscroll": false, + "lastBottom": 492, + "innerH": 1024 + }, + "escClosed": true, + "after": { + "path": "/wallet", + "open": false, + "current": "Wallet" + } + }, + { + "page": "/", + "width": 1440, + "scheme": "dark", + "desktop": { + "visible": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "current": null, + "underline": null, + "cta": [ + 120, + 40 + ], + "burger": "none" + } + }, + { + "page": "/miner", + "width": 1440, + "scheme": "dark", + "desktop": { + "visible": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "current": "Miner", + "underline": "rgb(242, 84, 27)", + "cta": [ + 120, + 36 + ], + "burger": "none" + } + }, + { + "page": "/live", + "width": 1440, + "scheme": "dark", + "desktop": { + "visible": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "current": "Live devnet", + "underline": "rgb(242, 84, 27)", + "cta": [ + 120, + 36 + ], + "burger": "none" + } + }, + { + "page": "/ledger", + "width": 1440, + "scheme": "dark", + "desktop": { + "visible": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "current": "Ledger", + "underline": "rgb(242, 84, 27)", + "cta": [ + 120, + 36 + ], + "burger": "none" + } + }, + { + "page": "/", + "width": 1440, + "scheme": "light", + "desktop": { + "visible": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "current": null, + "underline": null, + "cta": [ + 120, + 40 + ], + "burger": "none" + } + }, + { + "page": "/miner", + "width": 1440, + "scheme": "light", + "desktop": { + "visible": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "current": "Miner", + "underline": "rgb(208, 66, 13)", + "cta": [ + 120, + 36 + ], + "burger": "none" + } + }, + { + "page": "/live", + "width": 1440, + "scheme": "light", + "desktop": { + "visible": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "current": "Live devnet", + "underline": "rgb(208, 66, 13)", + "cta": [ + 120, + 36 + ], + "burger": "none" + } + }, + { + "page": "/ledger", + "width": 1440, + "scheme": "light", + "desktop": { + "visible": [ + "Litepaper", + "Miner", + "App", + "Wallet", + "Live devnet", + "Ledger" + ], + "current": "Ledger", + "underline": "rgb(208, 66, 13)", + "cta": [ + 120, + 36 + ], + "burger": "none" + } + } + ], + "cards": [ + { + "page": "/", + "width": 1440, + "scheme": "dark", + "marks": [ + { + "title": "Windows", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(255, 255, 255)", + "bg": "rgb(242, 84, 27)" + }, + { + "title": "macOS", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(244, 241, 236)", + "bg": "rgb(22, 22, 26)" + }, + { + "title": "Linux · HiveOS", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(244, 241, 236)", + "bg": "rgb(22, 22, 26)" + } + ] + }, + { + "page": "/miner", + "width": 1440, + "scheme": "dark", + "marks": [ + { + "title": "Windows", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(255, 255, 255)", + "bg": "rgb(242, 84, 27)" + }, + { + "title": "macOS", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(244, 241, 236)", + "bg": "rgb(22, 22, 26)" + }, + { + "title": "Linux · HiveOS", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(244, 241, 236)", + "bg": "rgb(22, 22, 26)" + } + ] + }, + { + "page": "/", + "width": 390, + "scheme": "dark", + "marks": [ + { + "title": "Windows", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(255, 255, 255)", + "bg": "rgb(242, 84, 27)" + }, + { + "title": "macOS", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(244, 241, 236)", + "bg": "rgb(22, 22, 26)" + }, + { + "title": "Linux · HiveOS", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(244, 241, 236)", + "bg": "rgb(22, 22, 26)" + } + ] + }, + { + "page": "/miner", + "width": 390, + "scheme": "dark", + "marks": [ + { + "title": "Windows", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(255, 255, 255)", + "bg": "rgb(242, 84, 27)" + }, + { + "title": "macOS", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(244, 241, 236)", + "bg": "rgb(22, 22, 26)" + }, + { + "title": "Linux · HiveOS", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(244, 241, 236)", + "bg": "rgb(22, 22, 26)" + } + ] + }, + { + "page": "/", + "width": 1440, + "scheme": "light", + "marks": [ + { + "title": "Windows", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(255, 255, 255)", + "bg": "rgb(208, 66, 13)" + }, + { + "title": "macOS", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(22, 22, 26)", + "bg": "rgb(255, 255, 255)" + }, + { + "title": "Linux · HiveOS", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(22, 22, 26)", + "bg": "rgb(255, 255, 255)" + } + ] + }, + { + "page": "/miner", + "width": 1440, + "scheme": "light", + "marks": [ + { + "title": "Windows", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(255, 255, 255)", + "bg": "rgb(208, 66, 13)" + }, + { + "title": "macOS", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(22, 22, 26)", + "bg": "rgb(255, 255, 255)" + }, + { + "title": "Linux · HiveOS", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(22, 22, 26)", + "bg": "rgb(255, 255, 255)" + } + ] + }, + { + "page": "/", + "width": 390, + "scheme": "light", + "marks": [ + { + "title": "Windows", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(255, 255, 255)", + "bg": "rgb(208, 66, 13)" + }, + { + "title": "macOS", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(22, 22, 26)", + "bg": "rgb(255, 255, 255)" + }, + { + "title": "Linux · HiveOS", + "mark": true, + "size": [ + 28, + 28 + ], + "color": "rgb(22, 22, 26)", + "bg": "rgb(255, 255, 255)" + } + ] + }, + { + "page": "/miner", + "width": 390, + "scheme": "light", + "marks": [ + { + "title": "Windows", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(255, 255, 255)", + "bg": "rgb(208, 66, 13)" + }, + { + "title": "macOS", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(22, 22, 26)", + "bg": "rgb(255, 255, 255)" + }, + { + "title": "Linux · HiveOS", + "mark": true, + "size": [ + 26, + 26 + ], + "color": "rgb(22, 22, 26)", + "bg": "rgb(255, 255, 255)" + } + ] + } + ], + "footer": [ + { + "page": "/", + "width": 1440, + "scheme": "dark", + "eyebrowTops": [ + 504, + 504, + 504, + 504 + ], + "colLefts": [ + 490, + 686, + 881, + 1077 + ], + "social": [ + { + "label": "Igneum on GitHub: the spec, the vectors and the issues", + "href": "https://github.com/igneum-network/spec", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + }, + { + "label": "The Igneum Discord", + "href": "https://discord.gg/igneum", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + }, + { + "label": "Igneum on Reddit", + "href": "https://www.reddit.com/user/Igneum_network/", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + } + ], + "state": "devnet live", + "hscroll": false, + "gridCols": 5, + "tagline": "Mined by GPUs. Proven by fire." + }, + { + "page": "/miner", + "width": 1440, + "scheme": "dark", + "eyebrowTops": [ + 504, + 504, + 504, + 504 + ], + "colLefts": [ + 490, + 686, + 881, + 1077 + ], + "social": [ + { + "label": "Igneum on GitHub: the spec, the vectors and the issues", + "href": "https://github.com/igneum-network/spec", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + }, + { + "label": "The Igneum Discord", + "href": "https://discord.gg/igneum", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + }, + { + "label": "Igneum on Reddit", + "href": "https://www.reddit.com/user/Igneum_network/", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + } + ], + "state": "devnet live", + "hscroll": false, + "gridCols": 5, + "tagline": "Mined by GPUs. Proven by fire." + }, + { + "page": "/", + "width": 390, + "scheme": "dark", + "eyebrowTops": [ + 632, + 632, + 907, + 907 + ], + "colLefts": [ + 16, + 203, + 16, + 203 + ], + "social": [ + { + "label": "Igneum on GitHub: the spec, the vectors and the issues", + "href": "https://github.com/igneum-network/spec", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + }, + { + "label": "The Igneum Discord", + "href": "https://discord.gg/igneum", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + }, + { + "label": "Igneum on Reddit", + "href": "https://www.reddit.com/user/Igneum_network/", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + } + ], + "state": "devnet live", + "hscroll": false, + "gridCols": 2, + "tagline": "Mined by GPUs. Proven by fire." + }, + { + "page": "/miner", + "width": 390, + "scheme": "dark", + "eyebrowTops": [ + 107, + 107, + 382, + 382 + ], + "colLefts": [ + 16, + 203, + 16, + 203 + ], + "social": [ + { + "label": "Igneum on GitHub: the spec, the vectors and the issues", + "href": "https://github.com/igneum-network/spec", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + }, + { + "label": "The Igneum Discord", + "href": "https://discord.gg/igneum", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + }, + { + "label": "Igneum on Reddit", + "href": "https://www.reddit.com/user/Igneum_network/", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(244, 241, 236)" + } + ], + "state": "devnet live", + "hscroll": false, + "gridCols": 2, + "tagline": "Mined by GPUs. Proven by fire." + }, + { + "page": "/", + "width": 1440, + "scheme": "light", + "eyebrowTops": [ + 504, + 504, + 504, + 504 + ], + "colLefts": [ + 490, + 686, + 881, + 1077 + ], + "social": [ + { + "label": "Igneum on GitHub: the spec, the vectors and the issues", + "href": "https://github.com/igneum-network/spec", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + }, + { + "label": "The Igneum Discord", + "href": "https://discord.gg/igneum", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + }, + { + "label": "Igneum on Reddit", + "href": "https://www.reddit.com/user/Igneum_network/", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + } + ], + "state": "devnet live", + "hscroll": false, + "gridCols": 5, + "tagline": "Mined by GPUs. Proven by fire." + }, + { + "page": "/miner", + "width": 1440, + "scheme": "light", + "eyebrowTops": [ + 504, + 504, + 504, + 504 + ], + "colLefts": [ + 490, + 686, + 881, + 1077 + ], + "social": [ + { + "label": "Igneum on GitHub: the spec, the vectors and the issues", + "href": "https://github.com/igneum-network/spec", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + }, + { + "label": "The Igneum Discord", + "href": "https://discord.gg/igneum", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + }, + { + "label": "Igneum on Reddit", + "href": "https://www.reddit.com/user/Igneum_network/", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + } + ], + "state": "devnet live", + "hscroll": false, + "gridCols": 5, + "tagline": "Mined by GPUs. Proven by fire." + }, + { + "page": "/", + "width": 390, + "scheme": "light", + "eyebrowTops": [ + 632, + 632, + 907, + 907 + ], + "colLefts": [ + 16, + 203, + 16, + 203 + ], + "social": [ + { + "label": "Igneum on GitHub: the spec, the vectors and the issues", + "href": "https://github.com/igneum-network/spec", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + }, + { + "label": "The Igneum Discord", + "href": "https://discord.gg/igneum", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + }, + { + "label": "Igneum on Reddit", + "href": "https://www.reddit.com/user/Igneum_network/", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + } + ], + "state": "devnet live", + "hscroll": false, + "gridCols": 2, + "tagline": "Mined by GPUs. Proven by fire." + }, + { + "page": "/miner", + "width": 390, + "scheme": "light", + "eyebrowTops": [ + 107, + 107, + 382, + 382 + ], + "colLefts": [ + 16, + 203, + 16, + 203 + ], + "social": [ + { + "label": "Igneum on GitHub: the spec, the vectors and the issues", + "href": "https://github.com/igneum-network/spec", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + }, + { + "label": "The Igneum Discord", + "href": "https://discord.gg/igneum", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + }, + { + "label": "Igneum on Reddit", + "href": "https://www.reddit.com/user/Igneum_network/", + "target": "_blank", + "hit": [ + 44, + 44 + ], + "color": "rgb(22, 22, 26)" + } + ], + "state": "devnet live", + "hscroll": false, + "gridCols": 2, + "tagline": "Mined by GPUs. Proven by fire." + } + ], + "scene": [ + { + "page": "/", + "scheme": "dark", + "stats": { + "window": 30, + "narrow": true, + "lanes": 4, + "rendered": 300, + "state": "live" + }, + "canvas": [ + 358, + 300 + ], + "version": "2.0.2", + "throttled4x": { + "moduleFps": 50.1, + "rafFps": 103.9 + } + }, + { + "page": "/live", + "scheme": "dark", + "stats": { + "window": 30, + "narrow": true, + "lanes": 4, + "rendered": 300, + "state": "live" + }, + "canvas": [ + 314, + 300 + ], + "version": "2.0.2", + "throttled4x": { + "moduleFps": 41.4, + "rafFps": 80 + } + }, + { + "page": "/", + "scheme": "light", + "stats": { + "window": 30, + "narrow": true, + "lanes": 4, + "rendered": 300, + "state": "live" + }, + "canvas": [ + 358, + 300 + ], + "version": "2.0.2", + "throttled4x": null + }, + { + "page": "/live", + "scheme": "light", + "stats": { + "window": 30, + "narrow": true, + "lanes": 4, + "rendered": 300, + "state": "live" + }, + "canvas": [ + 314, + 300 + ], + "version": "2.0.2", + "throttled4x": null + } + ] +} \ No newline at end of file diff --git a/docs/plans/site-ui-4-shots/chrome/scene/home-390-10s.webm b/docs/plans/site-ui-4-shots/chrome/scene/home-390-10s.webm new file mode 100644 index 00000000..b0ef744b Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/scene/home-390-10s.webm differ diff --git a/docs/plans/site-ui-4-shots/chrome/scene/home-390-dark.png b/docs/plans/site-ui-4-shots/chrome/scene/home-390-dark.png new file mode 100644 index 00000000..f0ff73db Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/scene/home-390-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/scene/home-390-light.png b/docs/plans/site-ui-4-shots/chrome/scene/home-390-light.png new file mode 100644 index 00000000..554e9840 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/scene/home-390-light.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/scene/live-390-10s.webm b/docs/plans/site-ui-4-shots/chrome/scene/live-390-10s.webm new file mode 100644 index 00000000..c2cfe468 Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/scene/live-390-10s.webm differ diff --git a/docs/plans/site-ui-4-shots/chrome/scene/live-390-dark.png b/docs/plans/site-ui-4-shots/chrome/scene/live-390-dark.png new file mode 100644 index 00000000..d717cfba Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/scene/live-390-dark.png differ diff --git a/docs/plans/site-ui-4-shots/chrome/scene/live-390-light.png b/docs/plans/site-ui-4-shots/chrome/scene/live-390-light.png new file mode 100644 index 00000000..8ee57c0e Binary files /dev/null and b/docs/plans/site-ui-4-shots/chrome/scene/live-390-light.png differ diff --git a/docs/plans/site-ui-4-shots/dag/demo-feed-proven-1000-dark.jpg b/docs/plans/site-ui-4-shots/dag/demo-feed-proven-1000-dark.jpg new file mode 100644 index 00000000..4507088e Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/demo-feed-proven-1000-dark.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/home-1440-dark-mid.jpg b/docs/plans/site-ui-4-shots/dag/home-1440-dark-mid.jpg new file mode 100644 index 00000000..685facd6 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/home-1440-dark-mid.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/home-1440-light-mid.jpg b/docs/plans/site-ui-4-shots/dag/home-1440-light-mid.jpg new file mode 100644 index 00000000..e8fe6e63 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/home-1440-light-mid.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/home-390-dark-mid.jpg b/docs/plans/site-ui-4-shots/dag/home-390-dark-mid.jpg new file mode 100644 index 00000000..a5d1d501 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/home-390-dark-mid.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/home-390-light-mid.jpg b/docs/plans/site-ui-4-shots/dag/home-390-light-mid.jpg new file mode 100644 index 00000000..e67568d6 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/home-390-light-mid.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/igneum-chain-scene.html b/docs/plans/site-ui-4-shots/dag/igneum-chain-scene.html new file mode 100644 index 00000000..1f2eda95 --- /dev/null +++ b/docs/plans/site-ui-4-shots/dag/igneum-chain-scene.html @@ -0,0 +1,595 @@ + + +Igneum / Miner in motion + + + +
+
IGNEUM.MINER / MOTION LAB
+
+
YOUR WORK. PART OF THE NETWORK.

The chain, made visible.

Follow your blocks. Watch the proofs. See each checkpoint lock.

SIMULATED FEED

Mining-app motion preview
No connection to the devnet

+
+
Blocks in window
—last 90s
Waiting for sample data
+
Your blocks
—in this window
Key 6ad0e117
+
Proven blocks
—
Observer-reported proof status
+
Latest checkpoint
—
Waiting for sample data
+
+
+

Block DAG

Time-aligned miner lanes. Every parent connection.

Simulation running
+
6 miner keys
+
Your browser needs canvas support. The block table below provides the same records as text.
+
IncludedExcludedSelected chainYour block✓ProvenLocked checkpoint
+
Click to inspect · Drag to explore
90s
+ +
+
Try the motionThese controls change the simulation only.
+

Small footprint. Same chain.

The same renderer, scaled for an app overview card.

COMPACT / 60S
+

Motion, with meaning.

01

A block arrives.

A brief signal traces its real parent edges. Your blocks receive a molten frame.

02

The proof takes shape.

Shard tiles reflect planned, proving, verified and paid states from the feed.

03

A checkpoint locks.

A pending marker becomes a solid boundary only when the observer reports locked.

+
Explore the blocks as a table KEYBOARD-ACCESSIBLE / SAME DISPLAYED DATA
Sample blocks in the displayed time window. Select a hash to inspect its proof states.
HashMiner keyDAAInclusionProofFinality
+
Use this in the mining app EXISTING IgneumDag.mount() API RETAINED

Replace your existing live-dag.js with the supplied module. Keep the existing canvas, CSS colour tokens, API endpoint and mount call. The richer preview shell is optional; the renderer does not need it.

const dag = IgneumDag.mount(canvas, {
+  poll: false,
+  mine: yourMinerKey,
+  window: 120,
+  pauseButton,
+  tooltip,
+  onState: updateFeedStatus
+});
+
+// The same observer reply your app already receives.
+dag.push(reply);
+
+// When the screen unmounts:
+dag.destroy();

The separate proof-core.js adds the larger shard visual. This file is a standalone simulation, not a deployed change or a connection to live hardware.

+
IGNEUM / EMBER 02   Mining application motion studySimulated data. No wallet, mining-engine or production changes.
+
+ + diff --git a/docs/plans/site-ui-4-shots/dag/live-1440-dark-mid.jpg b/docs/plans/site-ui-4-shots/dag/live-1440-dark-mid.jpg new file mode 100644 index 00000000..e07c991d Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-1440-dark-mid.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/live-1440-dark-selected.jpg b/docs/plans/site-ui-4-shots/dag/live-1440-dark-selected.jpg new file mode 100644 index 00000000..fdd951e7 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-1440-dark-selected.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/live-1440-light-mid.jpg b/docs/plans/site-ui-4-shots/dag/live-1440-light-mid.jpg new file mode 100644 index 00000000..9f40157a Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-1440-light-mid.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/live-1440-light-selected.jpg b/docs/plans/site-ui-4-shots/dag/live-1440-light-selected.jpg new file mode 100644 index 00000000..7e0cc4a0 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-1440-light-selected.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/live-390-dark-mid.jpg b/docs/plans/site-ui-4-shots/dag/live-390-dark-mid.jpg new file mode 100644 index 00000000..41ba8dc1 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-390-dark-mid.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/live-390-dark-selected.jpg b/docs/plans/site-ui-4-shots/dag/live-390-dark-selected.jpg new file mode 100644 index 00000000..c0945219 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-390-dark-selected.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/live-390-light-mid.jpg b/docs/plans/site-ui-4-shots/dag/live-390-light-mid.jpg new file mode 100644 index 00000000..ac9b6343 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-390-light-mid.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/live-390-light-selected.jpg b/docs/plans/site-ui-4-shots/dag/live-390-light-selected.jpg new file mode 100644 index 00000000..b18c2d30 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-390-light-selected.jpg differ diff --git a/docs/plans/site-ui-4-shots/dag/live-scene-10s.gif b/docs/plans/site-ui-4-shots/dag/live-scene-10s.gif new file mode 100644 index 00000000..0d153e12 Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-scene-10s.gif differ diff --git a/docs/plans/site-ui-4-shots/dag/live-scene-10s.mp4 b/docs/plans/site-ui-4-shots/dag/live-scene-10s.mp4 new file mode 100644 index 00000000..39ce324a Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-scene-10s.mp4 differ diff --git a/docs/plans/site-ui-4-shots/dag/live-scene-10s.webm b/docs/plans/site-ui-4-shots/dag/live-scene-10s.webm new file mode 100644 index 00000000..877e540f Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/live-scene-10s.webm differ diff --git a/docs/plans/site-ui-4-shots/dag/pack-preview.mp4 b/docs/plans/site-ui-4-shots/dag/pack-preview.mp4 new file mode 100644 index 00000000..78b6000b Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/pack-preview.mp4 differ diff --git a/docs/plans/site-ui-4-shots/dag/side-by-side-live-vs-demo.jpg b/docs/plans/site-ui-4-shots/dag/side-by-side-live-vs-demo.jpg new file mode 100644 index 00000000..bad6744f Binary files /dev/null and b/docs/plans/site-ui-4-shots/dag/side-by-side-live-vs-demo.jpg differ diff --git a/docs/plans/site-ui-4-shots/live-1440-dark-fold.jpg b/docs/plans/site-ui-4-shots/live-1440-dark-fold.jpg new file mode 100644 index 00000000..d9d0a539 Binary files /dev/null and b/docs/plans/site-ui-4-shots/live-1440-dark-fold.jpg differ diff --git a/docs/plans/site-ui-4-shots/live-1440-dark-full.jpg b/docs/plans/site-ui-4-shots/live-1440-dark-full.jpg new file mode 100644 index 00000000..036ad61b Binary files /dev/null and b/docs/plans/site-ui-4-shots/live-1440-dark-full.jpg differ diff --git a/docs/plans/site-ui-4-shots/live-1440-dark-inspector.jpg b/docs/plans/site-ui-4-shots/live-1440-dark-inspector.jpg new file mode 100644 index 00000000..28b7afbd Binary files /dev/null and b/docs/plans/site-ui-4-shots/live-1440-dark-inspector.jpg differ diff --git a/docs/plans/site-ui-4-shots/live-1440-light-fold.jpg b/docs/plans/site-ui-4-shots/live-1440-light-fold.jpg new file mode 100644 index 00000000..8fe73fd3 Binary files /dev/null and b/docs/plans/site-ui-4-shots/live-1440-light-fold.jpg differ diff --git a/docs/plans/site-ui-4-shots/live-1440-light-full.jpg b/docs/plans/site-ui-4-shots/live-1440-light-full.jpg new file mode 100644 index 00000000..69d9e7da Binary files /dev/null and b/docs/plans/site-ui-4-shots/live-1440-light-full.jpg differ diff --git a/docs/plans/site-ui-4-shots/live-390-dark-fold.jpg b/docs/plans/site-ui-4-shots/live-390-dark-fold.jpg new file mode 100644 index 00000000..1418a735 Binary files /dev/null and b/docs/plans/site-ui-4-shots/live-390-dark-fold.jpg differ diff --git a/docs/plans/site-ui-4-shots/live-390-dark-full.jpg b/docs/plans/site-ui-4-shots/live-390-dark-full.jpg new file mode 100644 index 00000000..d4585810 Binary files /dev/null and b/docs/plans/site-ui-4-shots/live-390-dark-full.jpg differ diff --git a/docs/plans/site-ui-4-shots/live-390-light-fold.jpg b/docs/plans/site-ui-4-shots/live-390-light-fold.jpg new file mode 100644 index 00000000..6035e12f Binary files /dev/null and b/docs/plans/site-ui-4-shots/live-390-light-fold.jpg differ diff --git a/docs/plans/site-ui-4-shots/live-390-light-full.jpg b/docs/plans/site-ui-4-shots/live-390-light-full.jpg new file mode 100644 index 00000000..a5f9e433 Binary files /dev/null and b/docs/plans/site-ui-4-shots/live-390-light-full.jpg differ diff --git a/docs/plans/site-ui-4-shots/pack/results.json b/docs/plans/site-ui-4-shots/pack/results.json new file mode 100644 index 00000000..ad20bc44 --- /dev/null +++ b/docs/plans/site-ui-4-shots/pack/results.json @@ -0,0 +1,330 @@ +{ + "passed": 73, + "total": 73, + "results": [ + { + "test": "Standalone preview renders without JS errors", + "passed": true, + "evidence": [] + }, + { + "test": "Standalone preview makes no network requests", + "passed": true, + "evidence": [] + }, + { + "test": "Both renderers use the same block records", + "passed": true + }, + { + "test": "Sample contains six miner keys", + "passed": true + }, + { + "test": "Visible source label says simulated", + "passed": true + }, + { + "test": "Original mount API is exposed", + "passed": true + }, + { + "test": "Zoom-in control works", + "passed": true + }, + { + "test": "Zoom-out control works", + "passed": true + }, + { + "test": "Ordinary page scrolling is not captured", + "passed": true, + "evidence": { + "prevented": false, + "w": 90 + } + }, + { + "test": "Modified wheel zooms the graph", + "passed": true, + "evidence": { + "prevented": true, + "w": 103 + } + }, + { + "test": "Keyboard inspection updates the details", + "passed": true, + "evidence": "e231e4cf43678ba5" + }, + { + "test": "Escape clears selection", + "passed": true + }, + { + "test": "Your-block filter is active", + "passed": true + }, + { + "test": "Selected-chain filter is active", + "passed": true + }, + { + "test": "Pause button updates state and accessibility", + "passed": true + }, + { + "test": "Pause freezes displayed records while receiving data", + "passed": true + }, + { + "test": "Pause freezes the rendered pixels", + "passed": true + }, + { + "test": "Paused graph has no continuous RAF loop", + "passed": true, + "evidence": { + "before": 16, + "after": 16 + } + }, + { + "test": "Resume applies buffered block records", + "passed": true + }, + { + "test": "Sample block control selects a new own block", + "passed": true + }, + { + "test": "Sample proof control advances shard states", + "passed": true + }, + { + "test": "Sample checkpoint control produces an explicit locked record", + "passed": true + }, + { + "test": "Accessible table contains block records", + "passed": true + }, + { + "test": "Table selection opens the matching block", + "passed": true + }, + { + "test": "Light theme control works", + "passed": true + }, + { + "test": "Manual reduced motion propagates to both visuals", + "passed": true + }, + { + "test": "System reduced-motion changes stop continuous drawing", + "passed": true, + "evidence": { + "before": 70, + "after": 70 + } + }, + { + "test": "Motion resumes when the system preference changes", + "passed": true + }, + { + "test": "Offscreen main graph suspends animation", + "passed": true, + "evidence": { + "before": 78, + "after": 78 + } + }, + { + "test": "Main preview remains free of JS errors", + "passed": true, + "evidence": [] + }, + { + "test": "Responsive layout 320px has no horizontal overflow", + "passed": true + }, + { + "test": "Compact renderer draws when scrolled into view at 320px", + "passed": true + }, + { + "test": "Responsive preview 320px has no JS errors", + "passed": true, + "evidence": [] + }, + { + "test": "Responsive layout 390px has no horizontal overflow", + "passed": true + }, + { + "test": "Compact renderer draws when scrolled into view at 390px", + "passed": true + }, + { + "test": "Responsive preview 390px has no JS errors", + "passed": true, + "evidence": [] + }, + { + "test": "Responsive layout 768px has no horizontal overflow", + "passed": true + }, + { + "test": "Compact renderer draws when scrolled into view at 768px", + "passed": true + }, + { + "test": "Responsive preview 768px has no JS errors", + "passed": true, + "evidence": [] + }, + { + "test": "Responsive layout 1024px has no horizontal overflow", + "passed": true + }, + { + "test": "Compact renderer draws when scrolled into view at 1024px", + "passed": true + }, + { + "test": "Responsive preview 1024px has no JS errors", + "passed": true, + "evidence": [] + }, + { + "test": "Responsive layout 1440px has no horizontal overflow", + "passed": true + }, + { + "test": "Compact renderer draws when scrolled into view at 1440px", + "passed": true + }, + { + "test": "Responsive preview 1440px has no JS errors", + "passed": true, + "evidence": [] + }, + { + "test": "Valid observer payload is accepted", + "passed": true + }, + { + "test": "Renderer does not mutate supplied records", + "passed": true + }, + { + "test": "Age and selected-chain status do not imply proof or finality", + "passed": true + }, + { + "test": "Existing records update miner, parents and header fields", + "passed": true + }, + { + "test": "Malformed envelope is rejected without throwing", + "passed": true + }, + { + "test": "Invalid block records are rejected without throwing", + "passed": true + }, + { + "test": "Prototype-like hashes are safe map keys", + "passed": true + }, + { + "test": "Tooltip treats incoming text as text, not markup", + "passed": true + }, + { + "test": "Unknown shard state is not promoted to planned or verified", + "passed": true + }, + { + "test": "Zoom has a 30-second lower bound", + "passed": true + }, + { + "test": "Zoom has a 300-second upper bound", + "passed": true + }, + { + "test": "ResizeObserver tracks container-only resizes", + "passed": true + }, + { + "test": "Checkpoint is not snapped to a different blue score", + "passed": true + }, + { + "test": "Exact checkpoint score renders a pending marker", + "passed": true + }, + { + "test": "Weight alone does not infer checkpoint lock", + "passed": true + }, + { + "test": "Stale feed preserves records and reports stale", + "passed": true + }, + { + "test": "Stale feed does not animate as fresh activity", + "passed": true + }, + { + "test": "Mounting again destroys the previous instance", + "passed": true + }, + { + "test": "Destroy stops animation and rejects future pushes", + "passed": true + }, + { + "test": "Polling preserves existing endpoint query parameters", + "passed": true + }, + { + "test": "Polling requests fresh data with an abort signal", + "passed": true + }, + { + "test": "Overlapping polls are prevented", + "passed": true + }, + { + "test": "Queued zoom request uses latest window", + "passed": true + }, + { + "test": "Observer response reaches rendered model", + "passed": true + }, + { + "test": "Destroy aborts an in-flight observer request", + "passed": true + }, + { + "test": "New module runs inside the supplied original HTML host", + "passed": true, + "evidence": [] + }, + { + "test": "Original host pause control still works", + "passed": true + }, + { + "test": "Original host theme control remains compatible", + "passed": true, + "evidence": [] + } + ], + "scope": "Chromium headless; embedded standalone HTML; mocked read-only observer; original uploaded HTML host. Not a live devnet or native mining-engine test." +} \ No newline at end of file diff --git a/docs/plans/site-ui-4-shots/pack/verify-local.log b/docs/plans/site-ui-4-shots/pack/verify-local.log new file mode 100644 index 00000000..00219d0f --- /dev/null +++ b/docs/plans/site-ui-4-shots/pack/verify-local.log @@ -0,0 +1,74 @@ +PASS Standalone preview renders without JS errors +PASS Standalone preview makes no network requests +PASS Both renderers use the same block records +PASS Sample contains six miner keys +PASS Visible source label says simulated +PASS Original mount API is exposed +PASS Zoom-in control works +PASS Zoom-out control works +PASS Ordinary page scrolling is not captured +PASS Modified wheel zooms the graph +PASS Keyboard inspection updates the details +PASS Escape clears selection +PASS Your-block filter is active +PASS Selected-chain filter is active +PASS Pause button updates state and accessibility +PASS Pause freezes displayed records while receiving data +PASS Pause freezes the rendered pixels +PASS Paused graph has no continuous RAF loop +PASS Resume applies buffered block records +PASS Sample block control selects a new own block +PASS Sample proof control advances shard states +PASS Sample checkpoint control produces an explicit locked record +PASS Accessible table contains block records +PASS Table selection opens the matching block +PASS Light theme control works +PASS Manual reduced motion propagates to both visuals +PASS System reduced-motion changes stop continuous drawing +PASS Motion resumes when the system preference changes +PASS Offscreen main graph suspends animation +PASS Main preview remains free of JS errors +PASS Responsive layout 320px has no horizontal overflow +PASS Compact renderer draws when scrolled into view at 320px +PASS Responsive preview 320px has no JS errors +PASS Responsive layout 390px has no horizontal overflow +PASS Compact renderer draws when scrolled into view at 390px +PASS Responsive preview 390px has no JS errors +PASS Responsive layout 768px has no horizontal overflow +PASS Compact renderer draws when scrolled into view at 768px +PASS Responsive preview 768px has no JS errors +PASS Responsive layout 1024px has no horizontal overflow +PASS Compact renderer draws when scrolled into view at 1024px +PASS Responsive preview 1024px has no JS errors +PASS Responsive layout 1440px has no horizontal overflow +PASS Compact renderer draws when scrolled into view at 1440px +PASS Responsive preview 1440px has no JS errors +PASS Valid observer payload is accepted +PASS Renderer does not mutate supplied records +PASS Age and selected-chain status do not imply proof or finality +PASS Existing records update miner, parents and header fields +PASS Malformed envelope is rejected without throwing +PASS Invalid block records are rejected without throwing +PASS Prototype-like hashes are safe map keys +PASS Tooltip treats incoming text as text, not markup +PASS Unknown shard state is not promoted to planned or verified +PASS Zoom has a 30-second lower bound +PASS Zoom has a 300-second upper bound +PASS ResizeObserver tracks container-only resizes +PASS Checkpoint is not snapped to a different blue score +PASS Exact checkpoint score renders a pending marker +PASS Weight alone does not infer checkpoint lock +PASS Stale feed preserves records and reports stale +PASS Stale feed does not animate as fresh activity +PASS Mounting again destroys the previous instance +PASS Destroy stops animation and rejects future pushes +PASS Polling preserves existing endpoint query parameters +PASS Polling requests fresh data with an abort signal +PASS Overlapping polls are prevented +PASS Queued zoom request uses latest window +PASS Observer response reaches rendered model +PASS Destroy aborts an in-flight observer request +PASS New module runs inside the supplied original HTML host +PASS Original host pause control still works +PASS Original host theme control remains compatible +RESULT 73 / 73 diff --git a/docs/plans/testnet-go.md b/docs/plans/testnet-go.md index 7a70c5dd..0668d6a8 100644 --- a/docs/plans/testnet-go.md +++ b/docs/plans/testnet-go.md @@ -115,3 +115,23 @@ NET=testnet ./install-rpc-from-mac.sh seed1.testnet # the public RPC again The node binary for the seeds: `node tools/build-job.mjs run --node /Users/joshm/Projects/igneum/vendor/igneum-node-testnet-infra --target ae432dc7 --targets linux --no-tests` then `node tools/build-job.mjs fetch ` (lands in `infra/cross/out/`). + +## Launch gates (mission item 10, 7 October 2026, 10:1x UK) + +Added by the launch-pack lane (branch `launch-pack`) from `docs/analysis/mission/mission.md` 2.10, with the owner's three decisions of the same morning written in: a signed proving customer is a MAINNET gate (not a testnet gate); the code-signing certificates are approved (Windows EV Authenticode and an Apple Developer organisation account, both under Igneum Labs LTD, executed the day the entity exists); the USD 50,000 disclosure prize is YES, staged until the entity address exists and the owner gives the publish word (`docs/plans/cryptanalysis.md` 3.3 on branch `cryptanalysis`). The runbooks, the signing-step specification and the text handed to the site lane are in `docs/plans/launch-pack.md`. Every row has its check; `node tools/ci/launch-gates-check.mjs` (in `tools/ci/pre-push.sh`) fails when a row loses it or names a script that is not there. "When" says which go the gate holds: T = before the testnet go (steps 1 to 11 above), C = a community gate after the go with no date (`docs/analysis/mission/reinvent.md` 4.1), M = before the mainnet go. + +| Gate | What must be true | Check | When | State at 10:1x UK, 7 October 2026 | Who | +|---|---|---|---|---|---| +| LG-1 Per-tier income at three tariffs | `docs/analysis/income-tiers.md` is published before the testnet: one 8, 12, 16, 24 or 32 GB card, a rig and a pool user, IGN a day at three network sizes from the measured bench rows and `EmissionSchedule::TESTNET_1`, electricity a day and per mined IGN at USD 0.05, 0.10 and 0.25 a kWh (cheap industrial, US retail, UK retail; decided 7 October 2026), each tier with what it means and what is being done (the consequences rule) | `node tools/launch/income-tiers.mjs --check` (the page equals its inputs) and `node --test tools/launch/income-tiers.test.mjs` (the schedule arithmetic: 6,912 IGN a day for 100 MH/s on 100 GH/s at the launch rate, day 1 at 10 percent, one month step at 2^(-1/24)); the page is in the public export and passes `tools/ci/identity-check.sh` | T | DONE on the branch from the 6 October rented-card rows (ten-field class). OWED: re-generate at the testnet cut from class v4 rates; the RTX 4060 and Apple wall power; an Intel row | launch-pack lane, then whoever cuts 0.4.0 | +| LG-2 Hash-origin report on Devnet 2 for seven days before the go | The daily report (keys with a block, keys above dust, attested pools and shared payouts, the project fleet's share, the ten largest keys, the network step) posts from the Devnet 2 observer's tables on seven consecutive days before step 10 | `node tools/observer/hash-origin.mjs --prefix dn2_ --dry` prints a report; seven consecutive `hash-origin:` keys in the poster's state for that prefix; `node --test tools/observer/hash-origin.test.mjs` (a known-finished day and a known-failed day) | T | The job exists and ran read-only on the live devnet tables today (113 keys, 0.76 GH/s). OWED: a Devnet 2 observer writing `dn2_live_*` (fleet lane), the fleet key file from the fleet registry, the systemd timer on the box (`docs/plans/launch-pack.md` section 3) | launch-pack lane (job), fleet lane (observer, key file), build-server lane (timer) | +| LG-3 Signed and notarised installers | The 0.4.0 DMG is signed with a Developer ID certificate of Igneum Labs LTD, notarised and stapled, and opens on a fresh macOS machine with no Privacy and Security visit; the Windows installer and every exe inside it carry an EV Authenticode signature of Igneum Labs LTD with a timestamp | `spctl --assess --type execute -vv ` prints `accepted` and `source=Notarized Developer ID`; `osslsigncode verify ` (or `signtool verify /pa /v`) prints the signer `Igneum Labs LTD` and a timestamp; the shipper's `verify` step writes both into the manifest (`signed_by`, `notarized`) and the download page shows the signer and the sha256 (`docs/plans/launch-pack.md` section 2.4) | T | NOT DONE: certificates approved 7 October; the entity's documents and the two enrolments are the owner's (section 2, items for the owner); the signing step is a specification for the shipper (`docs/plans/launch-pack.md` 2.4) | the owner (enrolments), the shipper (the step) | +| LG-4 First-share time measured per release | Every release's Devnet 2 gate measures download to first accepted share on a fresh Windows 11 VM and a fresh macOS VM, as three timed steps (download and install, sync, dataset build), and the numbers are published on /evidence; the mission's bar is under 10 minutes in 9 of 10 fresh Windows installs | the gate log carries `FIRST-SHARE download= sync= dataset= share=` for both platforms (`docs/plans/launch-pack.md` 2.5 is the specification of the script that writes it, tools/fleet/first-share-time.sh, OWED: until it exists this row is OPEN); the /evidence row equals the log line | T | OWED: specification written, script not built; no fresh-machine time has been measured end to end (`docs/analysis/mission/reinvent.md` 3.1) | fleet lane with the shipper | +| LG-5 The launch text on the site | The front page leads with the three wants (hardware that stays useful, income without a cliff, a fair supply) and finality moves to page two; the litepaper carries "A block pays its miner whether or not anyone buys a proof that day"; the eight regulatory sentences of `docs/analysis/mission/future.md` 8.3 are on the litepaper under "not legal advice; counsel is engaged"; the journey's phase 4 gate no longer says a rollup signs for the testnet | `node tools/ci/launch-gates-check.mjs` (the handoff block exists, carries no served-page pattern, no em dash, the eight sentences numbered in order); after the site lane lands it: `grep -c "whether or not anyone buys a proof" site/litepaper.html` is 1 and `grep -c "automatically created as a reward" site/litepaper.html` is 1 | T | Text handed over in `docs/plans/launch-pack.md` section 4 (branch `launch-pack`); nothing on the live site changed | site lane | +| LG-6 First 100 keys | 100 distinct vote keys with a blue block in the last 24 h | the hash-origin report's `gates.first_100_keys` (`node tools/observer/hash-origin.mjs --dry --json`) | C | Devnet reading today: 113 keys with a block, most of them the project's multi-identity machines; the testnet counts from its own go | the report | +| LG-7 First block from a card the project does not own | A blue block whose vote key is in neither the intake-reporting workers' identity lines nor the fleet registry's key file | the report's `gates.first_block_outside_fleet`, valid only with `IGNEUM_FLEET_KEYS_FILE` loaded (without the file the devnet reads its own rented boxes as outside: today 77 "outside" keys, which is the missing file, not outsiders); the post needs the owner's permission (reinvent.md 4.1 G-C2) | C | Void until the fleet key file exists (OWED, fleet lane) | the report, the fleet lane | +| LG-8 First outside-reproduced benchmark | A row on /miners measured by someone outside the project, with driver, OS and version (`docs/benchmarks/repro.md`) | `grep -c '"by": "reported by a miner"' site/miner-bench.json` is at least 1 (today the rows are `measured by the team` and `reported by the fleet`) | C | No such row | the community lead (the bench-table ingest) | +| LG-9 First pool not run by the project | An attested outside pool (its operator published the signed member-key list X5 asks for) with 10 percent of blue blocks for 7 consecutive days | the report's `gates.first_outside_pool` with the pool's payout address in `IGNEUM_KNOWN_POOLS`; a shared payout address nobody attested never passes it (the test's third case) | C | No attested outside pool; the devnet's 13 shared payout addresses are multi-identity machines and the project's pool-0 | the report, the pool lane (the statement format) | +| LG-10 First 1,000 independent keys (X5) | N_ind of at least 1,000 over 30 days, independent in autonomous system, machine fingerprint and pool attestation, top-10 share of window weight under 50 percent (`docs/plans/ledger-decisions.md` section 3) | the report's `independent` block once the observer stores the autonomous system per announcing address and the fingerprint per key; until then the report prints the keys above dust as an upper bound and never passes the gate (`gates.first_1000_independent` is false by construction) | C, and the gate of mainnet genesis | The two observer columns are OWED (app-owner item, ledger-decisions.md section 3); today's upper bound on the devnet is 95 | the observer owner | +| LG-11 A signed proving customer | One customer paying for proofs at a published rate, or a signed letter of intent with a volume, before mainnet (the owner, 7 October 2026: a mainnet gate, not a testnet gate; the weight of the Devnet 2 gate: mainnet does not open without it) | the contract or the letter in the entity's records, a redacted copy linked from `docs/evidence.md`, the rate on the site; for the paying case the job market's payout contract shows a paid job for that customer; `grep -c "rollup signs for testnet" site/journey.json` is 0 after the handoff lands | M | NOT DONE: Taiko is named as the first customer and nothing is signed; the brief and the pilot progression are ledger X13 | the owner (the signature), the execution engineer (the paid job) | +| LG-12 Hash origin daily for 90 days | The report posts every day for the first 90 days from the go, with no gap | `SELECT count(*) FROM hash_origin_reports WHERE day >= ''` reaches 90 with consecutive days; the timer's journal on the box shows a run per day | C | The job and its `--go ` flag exist; the timer is OWED (section 3 of the pack) | build-server lane (timer), the report | +| LG-13 The disclosure prize | USD 50,000 for a reproduced break of the published hash class, paid in fiat by Igneum Labs LTD, announced only when escrowed and only when the entity's registered address exists on its documents and the owner gives the publish word | `docs/plans/funding.md` rule 3 (escrow before announcement); the staged text in docs/plans/cryptanalysis.md 3.3 on branch `cryptanalysis` (43d9700b, not on master yet); until the word, `grep -ci "50,000" site/*.html` is 0 | M (the announcement may come earlier, on the word) | APPROVED by the owner at 09:5x UK on 7 October 2026; STAGED; nothing public mentions it | the owner (escrow, the word), the cryptanalysis lane (the announcement) | diff --git a/infra/build-server/README.md b/infra/build-server/README.md new file mode 100644 index 00000000..49f7ba10 --- /dev/null +++ b/infra/build-server/README.md @@ -0,0 +1,37 @@ +# The build boxes (infra/build-server) + +Three Hetzner dedicated servers in Falkenstein run everything the Mac must not: builds, test suites, benchmarks, CPU proving, the +devnet hands and the observer. The Mac keeps macOS binaries, the DMG and Metal tests (CLAUDE.md, "Running agents on this Mac"). + +## No mining on any Hetzner box, ever + +the project lead's rule through main, 7 October 2026: Hetzner's policies forbid crypto mining. The boxes run nodes, builds, tests, benchmarks and +CPU proving only. The pool's fast-time network runs its miners on rented GPU pods (tools/fleet), never on a box; a box may run the +network's nodes. The capacity layer refuses a job that would start `igneum-miner mine` or a GPU worker (capacity/run.sh), and no +hands unit carries a miner. A node started with `--enable-unsynced-mining` is a node flag, not a miner; nothing feeds it blocks here. + +## The boxes and the kind map + +| Box | Host file on the Mac | Takes | Never | +|---|---|---|---| +| igneum-build-1 (188.40.146.49, AX162-1-LTD) | `~/.config/igneum/build-server` | release gates (`--priority gate`), builds and cross-builds, checks, the GPU workers' host side, the devnet hands (node 1, the observer node, the observer), the Devnet 2 seed, the CI runner, the dashboard feed | suites and benches once box 2 exists | +| igneum-build-2 (AX162-1, on order) | `~/.config/igneum/build-server-2` | suites (`cargo test`), benches (`cargo bench`), the attack rows (`--box 2`) | gates, hands | +| igneum-build-3 (AX102-1, on order) | `~/.config/igneum/build-server-3` | proving and aggregation CPU work (proving/igneum-prove builds and suites), the second prover's shadow runner, the pool's fast-time NETWORK (nodes only, `--box 3`) | miners of any kind | + +`tools/build-remote.sh` routes by class (lib.sh `bs_route`): suite and bench to box 2, the proving crate to box 3, everything else +to box 1; `--box N` overrides; a class whose box has no host file yet falls back to box 1 and says so. `--priority gate` always runs +on box 1. Each box has its own mirrors, slots, locks and JSONL log under /srv; `run-from-mac.sh --box N ` provisions a box and +writes its host file; the dashboard collector reads every box it is told about. + +## Files + +| File | What | +|---|---| +| `provision.sh` | the box itself: install mode (rescue system, Ubuntu 24.04, RAID 1, no swap) and provision mode (user build, toolchains, the pin, sccache, zig, CUDA headers, docker, Caddy, mirrors, slots, sshd, ufw) | +| `run-from-mac.sh` | ships provision.sh, writes the host file, wires the `build` remotes and pushes every branch | +| `lib.sh`, `remote-run.sh` | the Mac and box halves of a remote run: sync, checkout, slots, scheduling classes, the JSONL line | +| `hands/` | the devnet hands' units, the mover and the restart read-backs | +| `capacity/` | the capacity layer (the box-work lane's): background jobs under the build slots, never a miner | +| `repro/`, `night/`, `prover/`, `runner/`, `workers/` | other lanes' pieces that live on the boxes | + +Plan, numbers and the gotchas: docs/plans/build-server.md; the hands: docs/plans/hands-on-build-1.md. diff --git a/infra/build-server/capacity/run.sh b/infra/build-server/capacity/run.sh index d522c59b..95eb92f6 100755 --- a/infra/build-server/capacity/run.sh +++ b/infra/build-server/capacity/run.sh @@ -58,6 +58,11 @@ run_slice() { once() { for job in $SEQUENCE; do + # No mining on any Hetzner box, ever (the project lead through main, 7 October 2026; Hetzner's policies forbid it): a job that would start a + # miner or a GPU worker is refused here, whatever SEQUENCE says. Nodes, builds, tests, benchmarks and CPU proving only. + if grep -qE 'igneum-miner[[:space:]]+mine|igneum-worker-(cuda|opencl)|igneum-app.*--mine|cargo run.*-p[[:space:]]+igneum-miner' "$JOBS_DIR/$job.sh" 2>/dev/null; then + echo "capacity: REFUSED job $job: it would start a miner or a GPU worker; no mining on a Hetzner box (infra/build-server/README.md)" >&2; continue + fi [ -f "$JOBS_DIR/$job.sh" ] || { cap_say "no job $job"; continue; } # wait out a running build before starting a slice (do not even launch during a build) while cap_build_active; do diff --git a/infra/build-server/hands/install-hands.sh b/infra/build-server/hands/install-hands.sh index e991494e..885e54f8 100755 --- a/infra/build-server/hands/install-hands.sh +++ b/infra/build-server/hands/install-hands.sh @@ -90,7 +90,10 @@ set -uo pipefail cd /srv/observer/igneum || exit 1 g() { su - build -c "git -C /srv/observer/igneum $*"; } # the clone is build's; root's git refuses it (safe.directory), so every git call runs as build before=$(g rev-parse HEAD:tools/observer HEAD:site/lib 2>/dev/null | tr '\n' ' ') -if su - build -c "ssh -o BatchMode=yes -o ConnectTimeout=10 -T git@github-igneum-observer" 2>&1 | grep -q "successfully authenticated"; then +# `ssh -T` to GitHub exits 1 after its greeting, so under this script's pipefail a `su ... | grep -q` reported failure although grep +# had matched (7 Oct 2026: the pass said "mirror" while the same line by hand said authenticated); the output is captured first +probe=$(su - build -c "ssh -o BatchMode=yes -o ConnectTimeout=10 -T git@github-igneum-observer" 2>&1 || true) +if grep -q "successfully authenticated" <<<"$probe"; then su - build -c "git -C /srv/observer/igneum remote get-url github >/dev/null 2>&1 || git -C /srv/observer/igneum remote add github git@github-igneum-observer:igneum-network/igneum.git" if su - build -c "git -C /srv/observer/igneum pull -q --ff-only github master" 2>&1 | head -2; then echo "source: github (deploy key accepted)"; else echo "source: github refused the pull, mirror next"; su - build -c "git -C /srv/observer/igneum pull -q --ff-only origin master" 2>&1 | head -2; fi else diff --git a/infra/build-server/lib.sh b/infra/build-server/lib.sh index ef05dffb..bb754b79 100755 --- a/infra/build-server/lib.sh +++ b/infra/build-server/lib.sh @@ -16,7 +16,19 @@ # shellcheck disable=SC2034 # shared with the scripts that source lib.sh BS_KEY="${IGNEUM_BUILD_KEY:-$HOME/.ssh/igneum_ed25519}" -BS_HOST_FILE="${IGNEUM_BUILD_HOST_FILE:-$HOME/.config/igneum/build-server}" # one line: build@ +BS_HOST_FILE="${IGNEUM_BUILD_HOST_FILE:-$HOME/.config/igneum/build-server}" # one line: build@ (box 1; box N is build-server-N) +# Several boxes (main, 7 October 2026: igneum-build-2 and igneum-build-3 on order). One host file per box: ~/.config/igneum/build-server +# is box 1, build-server-2 is box 2, build-server-3 is box 3 (run-from-mac.sh --box N writes it). The route by class, unless the +# caller passes --box: gates, builds, checks, cross-builds, the workers, the hands and the observer stay on box 1; suites, benches and +# the attack rows go to box 2; proving and aggregation CPU work, the second prover's shadow runner and the pool's fast-time NETWORK go +# to box 3. A class whose box has no host file yet falls back to box 1, and the log line says so. No box mines, ever (README.md). +bs_box_file() { case "${1:-1}" in 1) echo "$BS_HOST_FILE" ;; *) echo "${BS_HOST_FILE}-$1" ;; esac; } +bs_route() { # -> the box number, falling back to 1 + local want=1 + case "$1" in suite|bench|attack) want=2 ;; prove|shadow|fasttime) want=3 ;; esac + if [ "$want" != 1 ] && [ ! -s "$(bs_box_file "$want")" ]; then bs_log "class $1 routes to box $want, which has no host file yet ($(bs_box_file "$want")): box 1"; want=1; fi + echo "$want" +} BS_ROOT_REMOTE=/srv/builds BS_MIRROR_REPO=/srv/igneum.git BS_MIRROR_NODE=/srv/igneum-node.git @@ -24,11 +36,13 @@ BS_MIRROR_NODE=/srv/igneum-node.git bs_log() { printf '%s %s: %s\n' "$(date -u +%H:%M:%S)" "${BS_TOOL:-build-server}" "$*" >&2; } bs_die() { bs_log "ERROR: $*"; exit 1; } -bs_host() { +bs_host() { # [box number, default BS_BOX or 1] + BS_BOX="${1:-${BS_BOX:-1}}" BS_HOST="${BUILD_HOST:-}" if [ -z "$BS_HOST" ]; then - [ -s "$BS_HOST_FILE" ] || bs_die "no build server: write build@ to $BS_HOST_FILE (infra/build-server/run-from-mac.sh does) or set BUILD_HOST" - BS_HOST="$(head -1 "$BS_HOST_FILE" | tr -d '[:space:]')" + local f; f=$(bs_box_file "$BS_BOX") + [ -s "$f" ] || bs_die "no build server for box $BS_BOX: write build@ to $f (infra/build-server/run-from-mac.sh --box $BS_BOX does) or set BUILD_HOST" + BS_HOST="$(head -1 "$f" | tr -d '[:space:]')" fi case "$BS_HOST" in *@*) ;; *) bs_die "BUILD_HOST must be user@host, got '$BS_HOST'" ;; esac [ -r "$BS_KEY" ] || bs_die "no ssh key at $BS_KEY" @@ -281,8 +295,9 @@ bs_remote_run() { BR_DIR="$dir" BR_LABEL="$label" BR_CMD="$cmd" BR_TOOL="${BS_TOOL:-build-remote}" BR_WT="$BS_WT" BR_CRATE="$BS_CRATE_REL" \ BR_BRANCH="$BS_BRANCH" BR_SHA="$BS_SHA" BR_AGENT="$agent" BR_KIND="${BR_KIND:-other}" BR_COMMAND="${BR_COMMAND:-}" \ BR_TARGET="${BR_TARGET:-}" BR_ARTEFACTS="${BR_ARTEFACTS:-}" BR_SDE="${BR_SDE:-}" BR_PAIRS_WITH="${BR_PAIRS_WITH:-}" \ + BR_NICE="${BR_NICE:-0}" BR_CORES="${BR_CORES:-0}" BR_JOBS_CAP="${BR_JOBS_CAP:-0}" BR_PRIORITY="${BR_PRIORITY:-normal}" \ bash -c ' - for v in BR_DIR BR_LABEL BR_CMD BR_TOOL BR_WT BR_CRATE BR_BRANCH BR_SHA BR_AGENT BR_KIND BR_COMMAND BR_TARGET BR_ARTEFACTS BR_SDE BR_PAIRS_WITH; do + for v in BR_DIR BR_LABEL BR_CMD BR_TOOL BR_WT BR_CRATE BR_BRANCH BR_SHA BR_AGENT BR_KIND BR_COMMAND BR_TARGET BR_ARTEFACTS BR_SDE BR_PAIRS_WITH BR_NICE BR_CORES BR_JOBS_CAP BR_PRIORITY; do printf "export %s=%q\n" "$v" "${!v}" done cat "$0"' "$(dirname "${BASH_SOURCE[0]}")/remote-run.sh" | bs_ssh 'bash -s' diff --git a/infra/build-server/remote-run.sh b/infra/build-server/remote-run.sh index 2a1cdd62..15facd9f 100755 --- a/infra/build-server/remote-run.sh +++ b/infra/build-server/remote-run.sh @@ -51,6 +51,26 @@ _slots_env="${IGNEUM_BUILD_SLOTS_DIR:-}"; _log_env="${IGNEUM_BUILD_LOG_DIR:-}" [ -f /etc/profile.d/igneum-build.sh ] && . /etc/profile.d/igneum-build.sh [ -n "$_slots_env" ] && IGNEUM_BUILD_SLOTS_DIR="$_slots_env"; [ -n "$_log_env" ] && IGNEUM_BUILD_LOG_DIR="$_log_env" +# What the clean spares beyond target dirs and stamps: a lane's scratch. The fixed prefixes, plus every glob in the mirror-local +# file `.igneum-scratch-spare` (one per line, # comments; the file itself is spared). spare_args fills SPARE_ARGS with +# the `-e ` arguments; it is never empty (the fixed list), so bash 3.2's unbound-empty-array rule cannot bite the self-test. +SPARE_FIXED=('attack-*' 'scratch-*' 'target-attack-*' '.build-remote.log' '.igneum-scratch-spare') +spare_args() { + local p + SPARE_ARGS=() + for p in "${SPARE_FIXED[@]}"; do SPARE_ARGS+=(-e "$p"); done + [ -f "$1/.igneum-scratch-spare" ] || return 0 + while IFS= read -r p || [ -n "$p" ]; do + p="${p%%#*}"; p="${p#"${p%%[![:space:]]*}"}"; p="${p%"${p##*[![:space:]]}"}" + [ -n "$p" ] && SPARE_ARGS+=(-e "$p") + done < "$1/.igneum-scratch-spare" + return 0 +} +# the untracked paths the clean would still take, up to three (empty = the tree is clean); the same excludes as the clean line +tree_left() { + git -C "$1" clean -nd -e target -e 'target-*' -e '.build-remote-sha-*' -e '.cross-remote-sha-*' -e sccache "${SPARE_ARGS[@]}" | head -3 +} + # discard the previous overlay (tracked edits and untracked files; target dirs, the sha stamps and anything ignored are kept), # fetch, then the branch at the commit. Runs in BR_CO_DIR, clones it from BR_CO_MIRROR when it has no .git. checkout_tree() { @@ -68,7 +88,12 @@ checkout_tree() { if [ "$lock_age" -gt 30 ]; then rm -f .git/index.lock; echo "checkout: removed a stale .git/index.lock (${lock_age}s old) in $dir" >&2; fi fi git checkout -q -- . 2>/dev/null || true - git clean -qfd -e target -e 'target-*' -e '.build-remote-sha-*' -e '.cross-remote-sha-*' -e sccache + # 7 October 2026: the attack rows lost their scratch dirs (attack-f3/, attack-f1-venv/, tools/attack/*/target) to each + # other's builds, because this clean ran on the shared mirror before every build from any agent and took every untracked + # directory. A lane's scratch is now spared: the fixed prefixes and the mirror-local .igneum-scratch-spare (SPARE_ARGS, + # see spare_args above). Never -x here: .git/info/exclude still applies. tools/ci/scratch-spare-check.sh guards this line. + spare_args "$dir" + git clean -qfd -e target -e 'target-*' -e '.build-remote-sha-*' -e '.cross-remote-sha-*' -e sccache "${SPARE_ARGS[@]}" git fetch -q origin '+refs/heads/*:refs/remotes/origin/*' git checkout -q -B "$branch" "$sha" git reset -q --hard "$sha" @@ -78,11 +103,28 @@ checkout_tree() { # ... at any depth: a repo-kind crate (pool/, igneum-pow/, app/igneum-app/) writes its stamp in its own directory, and the # root-anchored pattern of the first version failed the second build of every such crate (6 October 2026, 18:51 UTC, the # pool build: "tree not clean after reset: ?? pool/.build-remote-sha-target"; the self-test has the subdirectory case now) - local left; left=$(git status --porcelain --untracked-files=all | grep -vE '^\?\? (.*/)?(target|target-|sccache|\.build-remote-sha-|\.cross-remote-sha-)' | head -3 || true) + # ... and since 7 October 2026 a lane's spared scratch, so the test asks the clean itself what it would still remove + # (tree_left: `git clean -nd` with the same excludes; a spared directory is no longer "not clean") + local left; left=$(tree_left "$dir" || true) [ -z "$left" ] || { echo "checkout: tree not clean after reset at $dir: $left" >&2; return 1; } set +e } +if [ "${1:-}" = --self-test-keeper ]; then + # the keeper restores a truncated holder line within its interval, and stops at release + t=$(mktemp -d); trap 'rm -rf "$t"' EXIT + BR_PID=$$; BR_LABEL="keeper self-test"; got=0; waited=3; SLOTS_DIR="$t"; BR_KEEP_S=1 + holder_line() { printf 'pid %s since %sZ waited %s s: %s\n' "$BR_PID" "$(date -u +%H:%M:%S)" "$1" "$BR_LABEL"; } + holder_line "$waited" > "$t/build-0" + keeper_pid=""; keep_line() { local f="$1" w="$2"; ( while kill -0 "$BR_PID" 2>/dev/null; do [ -s "$f" ] || holder_line "$w" > "$f" 2>/dev/null; sleep "${BR_KEEP_S:-20}"; done ) & keeper_pid=$!; } + keep_line "$t/build-0" "$waited" + : > "$t/build-0"; sleep 2.5 + grep -q "^pid $$ since .* waited 3 s: keeper self-test$" "$t/build-0" || { echo "keeper self-test: the truncated holder line was NOT restored"; kill "$keeper_pid" 2>/dev/null; exit 1; } + kill "$keeper_pid" 2>/dev/null; wait "$keeper_pid" 2>/dev/null; : > "$t/build-0"; sleep 2.5 + [ ! -s "$t/build-0" ] || { echo "keeper self-test: the keeper kept writing after release"; exit 1; } + echo "keeper self-test: a truncated holder line comes back within the interval; nothing is written after release"; exit 0 +fi + if [ "${1:-}" = --self-test ]; then t=$(mktemp -d); trap 'rm -rf "$t"' EXIT git init -q --bare -b master "$t/mirror.git" @@ -95,6 +137,11 @@ if [ "${1:-}" = --self-test ]; then echo edited > "$t/box/a.txt"; echo new > "$t/box/b.txt"; mkdir -p "$t/box/target/release"; echo bin > "$t/box/target/release/x"; echo "$sha1" > "$t/box/.build-remote-sha-target" # a crate in a subdirectory: its stamp and target dir must survive, its untracked overlay file must not mkdir -p "$t/box/sub/target/release"; echo bin > "$t/box/sub/target/release/y"; echo "$sha1" > "$t/box/sub/.build-remote-sha-target"; echo new > "$t/box/sub/c.txt" + # a lane's scratch (7 October 2026): a fixed-prefix dir at the root and nested, a dir declared in .igneum-scratch-spare + # (comments and blank lines in the file), and an undeclared dir that the clean must still take + mkdir -p "$t/box/attack-f3" "$t/box/sub/attack-f1-venv" "$t/box/bs-lane-1" "$t/box/undeclared-1" + echo x > "$t/box/attack-f3/x"; echo x > "$t/box/sub/attack-f1-venv/x"; echo x > "$t/box/bs-lane-1/x"; echo x > "$t/box/undeclared-1/x" + printf '# the build-server lane\n\n bs-lane-* # trailing comment\n' > "$t/box/.igneum-scratch-spare" : > "$t/box/.git/index.lock" # a run killed mid-git leaves this; the checkout mode removes it once it is older than 30 s touch -t "$(date -d '-2 min' +%Y%m%d%H%M.%S 2>/dev/null || date -v-2M +%Y%m%d%H%M.%S)" "$t/box/.git/index.lock" # backdated two minutes (GNU date, then BSD date) [ $(( $(date +%s) - $(stat -c %Y "$t/box/.git/index.lock" 2>/dev/null || stat -f %m "$t/box/.git/index.lock") )) -gt 30 ] || { echo "self-test: could not backdate the fixture lock"; exit 1; } @@ -111,12 +158,21 @@ if [ "${1:-}" = --self-test ]; then [ -f "$t/box/sub/.build-remote-sha-target" ] || { echo "self-test: a subdirectory crate's sha stamp was cleaned"; exit 1; } [ -f "$t/box/sub/target/release/y" ] || { echo "self-test: a subdirectory crate's target dir was cleaned"; exit 1; } [ ! -e "$t/box/sub/c.txt" ] || { echo "self-test: a subdirectory's untracked overlay file survived"; exit 1; } + # a lane's scratch (7 October 2026): fixed prefixes at any depth and a declared glob survive, the spare file survives, an + # undeclared dir is removed + [ -f "$t/box/attack-f3/x" ] || { echo "self-test: a fixed-prefix scratch dir (attack-*) was cleaned"; exit 1; } + [ -f "$t/box/sub/attack-f1-venv/x" ] || { echo "self-test: a nested fixed-prefix scratch dir was cleaned"; exit 1; } + [ -f "$t/box/bs-lane-1/x" ] || { echo "self-test: a scratch dir declared in .igneum-scratch-spare was cleaned"; exit 1; } + [ -f "$t/box/.igneum-scratch-spare" ] || { echo "self-test: the .igneum-scratch-spare file itself was cleaned"; exit 1; } + [ ! -e "$t/box/undeclared-1" ] || { echo "self-test: an undeclared scratch dir survived the clean"; exit 1; } # the known-failed case: an untracked file the overlay left that no rule keeps must fail the check echo stray > "$t/box/sub/stray.txt" - if (cd "$t/box" && left=$(git status --porcelain --untracked-files=all | grep -vE '^\?\? (.*/)?(target|target-|sccache|\.build-remote-sha-|\.cross-remote-sha-)' | head -3); [ -n "$left" ]); then :; else echo "self-test: the clean-tree check did NOT fire on a stray untracked file"; exit 1; fi + spare_args "$t/box"; left=$(tree_left "$t/box"); [ -n "$left" ] || { echo "self-test: the clean-tree check did NOT fire on a stray untracked file"; exit 1; } rm -f "$t/box/sub/stray.txt" + # ... and a spared directory alone must NOT fire it (the check asks the clean, not the status list) + left=$(tree_left "$t/box"); [ -z "$left" ] || { echo "self-test: the clean-tree check fired on spared scratch: $left"; exit 1; } [ ! -f "$t/box/.git/index.lock" ] || { echo "self-test: the stale index.lock survived"; exit 1; } - echo "self-test: checkout mode lands on the new commit with a clean tree, target dirs and sha stamps kept at any depth, stale index.lock removed, and fires on a stray file"; exit 0 + echo "self-test: checkout mode lands on the new commit with a clean tree, target dirs and sha stamps kept at any depth, declared and fixed-prefix scratch kept, an undeclared dir removed, stale index.lock removed, and fires on a stray file"; exit 0 fi if [ "${1:-}" = --self-test-slots ]; then @@ -197,6 +253,7 @@ d = { "start": iso(e['BR_START']), "end": iso(e['BR_END']), "secs": num(e['BR_SECS']), "exit": num(e['BR_EXIT']), "compiles": num(e['BR_COMPILES']), "jobs": num(e.get('BR_JOBS')), "measure": (e.get('BR_MEASURE') == '1') or None, "source_date_epoch": num(e.get('BR_SDE')), "pairs_with": e.get('BR_PAIRS_WITH') or None, + "nice": num(e.get('BR_NICE')) or 0, "cores": (num(e.get('BR_CORES')) or 0) or os.cpu_count(), "priority": e.get('BR_PRIORITY') or "normal", "class": e.get('BR_CLASS') or None, "run_log": e.get('BR_RUN_LOG') or None, } sc = {k: num(e[v]) for k, v in (("hits", "BR_HITS"), ("misses", "BR_MISSES"), ("hits_total", "BR_HITS_T"), ("misses_total", "BR_MISSES_T"))} @@ -280,6 +337,18 @@ else flock -s -w 7200 "$mfd" || give_up "the measurement to end" rm -f "$waitfile"; trap - EXIT fi + # scheduling (main, 7 Oct 2026): a gate announces itself (gate-pending-) and takes the next free slot; a suite, bench or + # other non-gate run that has not taken a slot yet yields while any gate-pending marker younger than 15 min exists + gatefile="" + if [ "${BR_PRIORITY:-normal}" = gate ]; then gatefile="$SLOTS_DIR/gate-pending-$BR_PID"; holder_line 0 > "$gatefile"; trap 'rm -f "$gatefile"' EXIT + else + yt0=$(date +%s) + while pending=$(find "$SLOTS_DIR" -maxdepth 1 -name 'gate-pending-*' -mmin -15 2>/dev/null | head -1) && [ -n "$pending" ]; do + [ -f "$waitfile" ] || { echo "build-remote: a gate is queued ($(head -c 120 "$pending")), this ${BR_KIND:-run} yields" >&2; holder_line 0 > "$waitfile"; trap 'rm -f "$waitfile"' EXIT; } + [ $(( $(date +%s) - yt0 )) -lt 7200 ] || give_up "the queued gate" + sleep 5 + done + fi got="" for k in $(seq 0 $((slots - 1))); do exec {fd}>>"$SLOTS_DIR/build-$k" @@ -308,11 +377,24 @@ else exec {tfd}>&- done if [ "$held" -gt 1 ]; then BR_JOBS=$JOBS_SHARED; else BR_JOBS=$JOBS_ALONE; fi + # the bounded classes cap the jobs (suite and bench: 32 unless the caller passed --priority gate) + if [ "${BR_JOBS_CAP:-0}" -gt 0 ] && [ "$BR_JOBS" -gt "$BR_JOBS_CAP" ]; then BR_JOBS=$BR_JOBS_CAP; fi export CARGO_BUILD_JOBS="$BR_JOBS" BR_JOBS - echo "build-remote: holding build-$got on $BR_HOST (waited $waited s; $held of $slots slots held, CARGO_BUILD_JOBS=$BR_JOBS)" >&2 + [ -n "$gatefile" ] && { rm -f "$gatefile"; trap - EXIT; } + echo "build-remote: holding build-$got on $BR_HOST (waited $waited s; $held of $slots slots held, CARGO_BUILD_JOBS=$BR_JOBS, kind ${BR_KIND:-other}, nice ${BR_NICE:-0}, cores $( [ "${BR_CORES:-0}" = 0 ] && nproc || echo "$BR_CORES"))" >&2 fi -release_slot() { if [ "$got" = measure ]; then : > "$SLOTS_DIR/measure"; else : > "$SLOTS_DIR/build-$got"; fi; } +# The holder keeps its own line (the watcher-trust rule, 7 October 2026 10:39Z: two held slots read EMPTY while two suites ran, +# because a run from a worktree without last night's append-mode fix still opens a busy sibling's slot file with `>` on every +# probe). A keeper re-writes the holder line whenever it finds the file empty, every BR_KEEP_S seconds, until release_slot. +keeper_pid="" +keep_line() { # + local f="$1" w="$2" + ( while kill -0 "$BR_PID" 2>/dev/null; do [ -s "$f" ] || holder_line "$w" > "$f" 2>/dev/null; sleep "${BR_KEEP_S:-20}"; done ) & + keeper_pid=$! +} +if [ "$got" = measure ]; then keep_line "$SLOTS_DIR/measure" "$waited"; else keep_line "$SLOTS_DIR/build-$got" "$waited"; fi +release_slot() { [ -n "$keeper_pid" ] && { kill "$keeper_pid" 2>/dev/null; wait "$keeper_pid" 2>/dev/null; keeper_pid=""; }; if [ "$got" = measure ]; then : > "$SLOTS_DIR/measure"; else : > "$SLOTS_DIR/build-$got"; fi; } cd "$BR_DIR" || { BR_CLASS=no-dir jsonlog 2 "$got" "$waited" "" "$(date +%s)" "" "" "" "" "" ""; redlog 2 0 no-dir; release_slot; exit 2; } # PRE-FLIGHT for a cargo command (the instant-death class, 6 October 2026): the manifest parses and every -p package exists, @@ -362,8 +444,15 @@ t1=$(date +%s) # streams stay where they were for the Mac (stdout to stdout, stderr to stderr), each teed into the run log RUN_LOG_DIR="$LOG_DIR/runs"; mkdir -p "$RUN_LOG_DIR" BR_RUN_LOG="$RUN_LOG_DIR/$BR_HOST-$BR_T0-$BR_PID.log"; export BR_RUN_LOG -( eval "$BR_CMD" ) > >(tee -a "$BR_RUN_LOG") 2> >(tee -a "$BR_RUN_LOG" >&2) +# the class's nice and core set apply to the command's subshell and everything it starts (renice and taskset on the subshell's own +# pid, BASHPID; cores are the LAST N of the box's set, so gates and builds keep the first ones to themselves) +ncpu=$(nproc); cores_str="0-$((ncpu - 1))" +if [ "${BR_CORES:-0}" -gt 0 ] && [ "${BR_CORES}" -lt "$ncpu" ]; then cores_str="$((ncpu - BR_CORES))-$((ncpu - 1))"; fi +( [ "${BR_NICE:-0}" -gt 0 ] && renice -n "$BR_NICE" -p $BASHPID >/dev/null 2>&1; [ "$cores_str" != "0-$((ncpu - 1))" ] && taskset -cp "$cores_str" $BASHPID >/dev/null 2>&1; eval "$BR_CMD" ) > >(tee -a "$BR_RUN_LOG") 2> >(tee -a "$BR_RUN_LOG" >&2) rc=$? +# the keeper stops BEFORE the bare `wait` (which flushes the two tees): a bare wait also waits for the keeper, and the keeper waits +# for this script, a deadlock that held build-2's first run 15 minutes after its test had passed (7 Oct 2026, 11:04 to 11:19Z) +if [ -n "$keeper_pid" ]; then kill "$keeper_pid" 2>/dev/null; wait "$keeper_pid" 2>/dev/null; keeper_pid=""; fi wait t2=$(date +%s); secs=$(( t2 - t1 )) exec_after=$(stat_field "Compile requests executed"); hits_after=$(stat_field "Cache hits "); misses_after=$(stat_field "Cache misses ") @@ -385,8 +474,8 @@ elif [[ "$BR_CMD" == cargo\ test* ]] && { [[ "$BR_CMD" == *" -- "* ]] || grep -q echo "build-remote: REFUSED after the run: the test filter matched no test in any binary (every 'running 0 tests'); check the name" >&2 fi export BR_CLASS -printf 'build-remote: RESULT rc=%s secs=%s compiles=%s sccache_hits=%s sccache_misses=%s sccache_hits_total=%s sccache_misses_total=%s jobs=%s load=%s class=%s\n' \ - "$rc" "$secs" "$compiles" "$hits" "$misses" "${hits_after:-?}" "${misses_after:-?}" "${BR_JOBS:-measure}" "$(cut -d' ' -f1-3 /proc/loadavg)" "${BR_CLASS:-ok}" +printf 'build-remote: RESULT rc=%s secs=%s compiles=%s sccache_hits=%s sccache_misses=%s sccache_hits_total=%s sccache_misses_total=%s jobs=%s nice=%s cores=%s load=%s class=%s\n' \ + "$rc" "$secs" "$compiles" "$hits" "$misses" "${hits_after:-?}" "${misses_after:-?}" "${BR_JOBS:-measure}" "${BR_NICE:-0}" "$( [ "${BR_CORES:-0}" = 0 ] && nproc || echo "$BR_CORES")" "$(cut -d' ' -f1-3 /proc/loadavg)" "${BR_CLASS:-ok}" jsonlog "$rc" "$([ "$got" = measure ] && echo "" || echo "$got")" "$waited" "$t1" "$t2" "$secs" "$compiles" "$hits" "$misses" "${hits_after:-}" "${misses_after:-}" [ "$rc" = 0 ] || redlog "$rc" "$secs" "$BR_CLASS" release_slot diff --git a/infra/build-server/run-from-mac.sh b/infra/build-server/run-from-mac.sh index eeb94ea0..a5a275a8 100755 --- a/infra/build-server/run-from-mac.sh +++ b/infra/build-server/run-from-mac.sh @@ -20,13 +20,20 @@ BS_TOOL=run-from-mac # shellcheck source=lib.sh . "$HERE/lib.sh" +BOX=1; while [ "${1:-}" = --box ]; do BOX="$2"; shift 2; done # --box N: igneum-build-N, host file build-server-N (7 Oct 2026) IP="${1:-}"; shift || true -[ -n "$IP" ] || bs_die "usage: run-from-mac.sh [--wire-only]" +[ -n "$IP" ] || bs_die "usage: run-from-mac.sh [--box N] [--wire-only]" WIRE_ONLY=0; [ "${1:-}" = --wire-only ] && WIRE_ONLY=1 +# box N is igneum-build-N with its own dashboard feed name build-N.igneum.network (the dashboard lane's collector reads one server +# section per box; main adds the A record with the IP) +[ "$BOX" = 1 ] || { BOX_HOSTNAME="${BOX_HOSTNAME:-igneum-build-$BOX}"; WORKERS_HOST="${WORKERS_HOST:-build-$BOX.igneum.network}"; export BOX_HOSTNAME WORKERS_HOST; } +export BS_BOX="$BOX" # lib.sh's bs_host derives the host file from BS_BOX (box 1: build-server; box N: build-server-N); never set BS_HOST_FILE here (7 Oct 2026: a second suffix, build-server-2-2) +HOST_FILE=$(bs_box_file "$BOX") +REMOTE="build"; [ "$BOX" = 1 ] || REMOTE="build-$BOX" # one git remote per box in the two repositories # the toolchain pin travels from rust-toolchain.toml unless RUST_TOOLCHAIN is set by hand (one file pins every side, 7 Oct 2026) [ -n "${RUST_TOOLCHAIN:-}" ] || RUST_TOOLCHAIN=$(sed -n 's/^channel *= *"\([^"]*\)".*/\1/p' "$REPO/rust-toolchain.toml" 2>/dev/null | head -1); export RUST_TOOLCHAIN PASS="" # a string, not an array: bash 3.2 (the Mac) treats an empty array as unbound under set -u -for v in MODE RUST_TOOLCHAIN SCCACHE_GB SCCACHE_VERSION NODE_MAJOR SLOTS P2P_PORTS BOX_HOSTNAME SSH_PUBKEY; do +for v in MODE RUST_TOOLCHAIN SCCACHE_GB SCCACHE_VERSION NODE_MAJOR SLOTS P2P_PORTS BOX_HOSTNAME WORKERS_HOST SSH_PUBKEY; do [ -n "${!v:-}" ] && PASS="$PASS $v=$(printf '%q' "${!v}")" done @@ -43,19 +50,19 @@ if [ "$WIRE_ONLY" = 0 ]; then if "${ROOT_SSH[@]}" 'hostname' 2>/dev/null | grep -q '^rescue'; then bs_die "still in the rescue system after provision.sh"; fi fi -mkdir -p "$(dirname "$BS_HOST_FILE")" -printf 'build@%s\n' "$IP" > "$BS_HOST_FILE" -bs_log "wrote $BS_HOST_FILE" +mkdir -p "$(dirname "$HOST_FILE")" +printf 'build@%s\n' "$IP" > "$HOST_FILE" +bs_log "wrote $HOST_FILE" bs_host bs_ssh 'hostname; nproc' >/dev/null || bs_die "build@$IP does not answer with $BS_KEY" wire_remote() { # repo-dir mirror label local dir="$1" mirror="$2" label="$3" url="$BS_HOST:$2" cur - cur=$(git -C "$dir" remote get-url build 2>/dev/null || true) - if [ -z "$cur" ]; then git -C "$dir" remote add build "$url"; bs_log "$label: remote build = $url" - elif [ "$cur" != "$url" ]; then git -C "$dir" remote set-url build "$url"; bs_log "$label: remote build -> $url" - else bs_log "$label: remote build ok"; fi - GIT_SSH_COMMAND="$BS_SSH_CMD" git -C "$dir" push -q --force build --all && bs_log "$label: every branch pushed to $mirror ($(git -C "$dir" branch --list | wc -l | tr -d ' ') branches)" || bs_die "$label: push to $mirror failed" + cur=$(git -C "$dir" remote get-url "$REMOTE" 2>/dev/null || true) + if [ -z "$cur" ]; then git -C "$dir" remote add "$REMOTE" "$url"; bs_log "$label: remote $REMOTE = $url" + elif [ "$cur" != "$url" ]; then git -C "$dir" remote set-url "$REMOTE" "$url"; bs_log "$label: remote $REMOTE -> $url" + else bs_log "$label: remote $REMOTE ok"; fi + GIT_SSH_COMMAND="$BS_SSH_CMD" git -C "$dir" push -q --force "$REMOTE" --all && bs_log "$label: every branch pushed to $mirror ($(git -C "$dir" branch --list | wc -l | tr -d ' ') branches)" || bs_die "$label: push to $mirror failed" } wire_remote "$MAIN_REPO" "$BS_MIRROR_REPO" "igneum" wire_remote "$MAIN_REPO/vendor/igneum-node" "$BS_MIRROR_NODE" "igneum-node (the fork)" diff --git a/infra/build-server/workers/install.sh b/infra/build-server/workers/install.sh index 6842091e..91bce76d 100755 --- a/infra/build-server/workers/install.sh +++ b/infra/build-server/workers/install.sh @@ -1,11 +1,18 @@ #!/usr/bin/env bash # Install or refresh the worker dashboard collector on igneum-build-1 from this Mac. -# infra/build-server/workers/install.sh copies tools/workers/{lib,collect}.mjs and the two units, enables the timer -# Needs root over ssh (root@ with ~/.ssh/igneum_ed25519); the host ip comes from ~/.config/igneum/build-server (build@). +# infra/build-server/workers/install.sh build-1: copies tools/workers/{lib,collect}.mjs and the two units, enables the timer +# infra/build-server/workers/install.sh 2 igneum-build-2 (host line in ~/.config/igneum/build-server-2), 3 for build-3 +# infra/build-server/workers/install.sh build@ any box by its host line +# Needs root over ssh (root@ with ~/.ssh/igneum_ed25519); the host ip comes from ~/.config/igneum/build-server[-N] (build@). set -euo pipefail HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"; ROOT="$(cd "$HERE/../../.." && pwd)" KEY="${IGNEUM_BUILD_KEY:-$HOME/.ssh/igneum_ed25519}" -HOST_LINE="$(head -1 "${IGNEUM_BUILD_HOST_FILE:-$HOME/.config/igneum/build-server}" | tr -d '[:space:]')" +case "${1:-}" in + "") HOST_LINE="$(head -1 "${IGNEUM_BUILD_HOST_FILE:-$HOME/.config/igneum/build-server}" | tr -d '[:space:]')" ;; + [2-9]) HOST_LINE="$(head -1 "$HOME/.config/igneum/build-server-$1" | tr -d '[:space:]')" ;; + *@*) HOST_LINE="$1" ;; + *) echo "usage: install.sh [N | build@]" >&2; exit 2 ;; +esac IP="${HOST_LINE#*@}"; [ -n "$IP" ] || { echo "no build server in ~/.config/igneum/build-server" >&2; exit 1; } SSH=(ssh -i "$KEY" -o BatchMode=yes -o StrictHostKeyChecking=accept-new -o ConnectTimeout=10) "${SSH[@]}" "root@$IP" 'install -d -o build -g build /srv/workers /srv/workers/bin /srv/workers/sources /srv/builds/_log; chown build:build /srv/builds/_log' diff --git a/site/404.html b/site/404.html index f01382b6..012e1065 100644 --- a/site/404.html +++ b/site/404.html @@ -13,6 +13,7 @@ +
+
Explorer · address

Address

@@ -160,61 +177,68 @@ main{padding-bottom:var(--sec)}
- diff --git a/site/api/live.mjs b/site/api/live.mjs index 7b1751f5..9450c5b4 100644 --- a/site/api/live.mjs +++ b/site/api/live.mjs @@ -1,5 +1,5 @@ // Igneum live devnet feed. GET /api/live returns what tools/observer wrote to Neon: -// {now, state (incl. height = chain block number), blocks (last 90 s, or ?window=N up to 300), miners (last 10 min), events (last 30), finality (checkpoints, newest lock), +// {now, state (incl. height = chain block number), blocks (last 90 s, or ?window=N up to 1800, at most 1,800 blocks), miners (last 10 min), events (last 30), finality (checkpoints, newest lock), // proving (activation and 10-minute counts; every chain block carries shards: [{i, state, prover, lag, payout}])}. // Five queries, all on indexed columns. Cached one second at the edge. // LIVE_TABLE_PREFIX (default empty) reads a test observer's tables (fintest_live_*, provtest_live_*) instead of the devnet's. @@ -37,9 +37,13 @@ export default async function handler(req, res) { } try { const sql = neon(); - // ?window=N seconds of blocks (30 to 300, default 90): the page's diagnostic long view; the row cap keeps a busy DAG bounded + // ?window=N seconds of blocks (30 to 1800, default 90): the page's long views; the row cap of 1,800 blocks keeps a busy DAG bounded + // (7 October 2026: the cap was 300 s while proofs land two to five minutes after the block, so no window could show a proven block) const q = new URL(req.url || '/', 'http://x').searchParams; - const windowS = Math.max(30, Math.min(300, Number(q.get('window')) || 90)); + const windowS = Math.max(30, Math.min(1800, Number(q.get('window')) || 90)); + // ?summary=1: the counts of the window alone (blocks, chain blocks, proven, shards by state), for a tile that reads a long + // window every 10 s while the scene keeps its short one (7 October 2026); no block rows, no miners, no events + const summary = q.get('summary') === '1'; const [head, blockRows, minerRows, checkpointRows, proofRows] = await Promise.all([ sql(`SELECT now() AS now, (SELECT row_to_json(s) FROM ${T}live_state s WHERE s.id = 1) AS state, @@ -49,7 +53,7 @@ export default async function handler(req, res) { FROM ${T}live_blocks WHERE received_at > now() - ($1 || ' seconds')::interval ORDER BY received_at DESC - LIMIT 2000`, [String(windowS)]), + LIMIT 1800`, [String(windowS)]), sql(`SELECT vote_key_hash, count(*)::int AS blocks, max(received_at) AS last_seen, max(engine) AS engine, max(miner_address) AS address FROM ${T}live_blocks WHERE received_at > now() - interval '10 minutes' AND vote_key_hash IS NOT NULL @@ -60,11 +64,13 @@ export default async function handler(req, res) { FROM ${T}live_checkpoints ORDER BY index DESC LIMIT 40`).catch(() => []), - // Proving v0: the planned shards of the chain blocks in the window and what became of them (an older observer has no table) - sql(`SELECT block_hash, shard, shards, state, prover, lag_daa, payout_wei, pgas - FROM ${T}live_proofs - WHERE received_at > now() - ($1 || ' seconds')::interval - ORDER BY block_hash, shard`, [String(windowS + 30)]).catch(() => []), + // Proving v0: the planned shards of the blocks in the window and what became of them (an older observer has no table). + // The rows are joined by block hash, never by when the plan or the proof landed: a block in view carries its shard + // states (planned, proving, verified, paid) whatever its age, and the proof's own landing is what moves them. + sql(`SELECT p.block_hash, p.shard, p.shards, p.state, p.prover, p.lag_daa, p.payout_wei, p.pgas + FROM ${T}live_proofs p + WHERE p.block_hash IN (SELECT hash FROM ${T}live_blocks WHERE received_at > now() - ($1 || ' seconds')::interval ORDER BY received_at DESC LIMIT 1800) + ORDER BY p.block_hash, p.shard`, [String(windowS)]).catch(() => []), ]); const now = new Date(head[0].now).getTime(); @@ -170,6 +176,10 @@ export default async function handler(req, res) { // peer events never carry an address on the public API (review round 4, R4.6.2); older stored rows are redacted here too const events = (head[0].events || []).map(e => ({ ts: e.ts, kind: e.kind, text: String(e.text).replace(/\b\d{1,3}(\.\d{1,3}){3}(:\d+)?\b/g, 'a peer') })); + if (summary) { + const by = {}; for (const b of blocks) for (const x of b.shards) by[x.state] = (by[x.state] || 0) + 1; + return res.status(200).json({ ok: true, now: new Date(now).toISOString(), window: windowS, stale, blocks: blocks.length, chain: blocks.filter(b => b.chain).length, planned: blocks.filter(b => b.shards.length).length, proven: blocks.filter(b => b.proven).length, shards: by, proving }); + } return res.status(200).json({ ok: true, now: new Date(now).toISOString(), state, blocks, miners, events, finality, proving }); } catch (e) { res.setHeader('Cache-Control', 'no-store'); diff --git a/site/app.html b/site/app.html new file mode 100644 index 00000000..737960a6 --- /dev/null +++ b/site/app.html @@ -0,0 +1,462 @@ + + + + + +Igneum Ember, the app + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ +
Igneum Ember · the app
+

The app you mine with.

+

Your rate, what it costs a day, and the chain drawn live with your own blocks ringed. One window, four pages, every card one row.

+ +
WindowsmacOSLinux · HiveOSlight and dark
+
+
+
Overview
+ The Overview page of 0.3.16: an RTX 5090 at 103 MH/s and 317 W, 0.32 MH/W, 62 blocks this run and 91,521 lifetime, the Stop mining button, the chain drawn live with this rig's blocks ringed and locked checkpoints, the node synced with 5 peers, the activity log + The Overview page of 0.3.16 in light mode: an RTX 5090 at 103 MH/s and 317 W, the chain drawn live with this rig's blocks ringed +
0.3.16, rendered from the RTX 5090 Windows rig’s live state at 23:33 UK, 6 October 2026. No electricity price is set on that rig, so the pounds cell asks for one.
+
+
+
+ +
+
+
+
+
Overview · Mac
+ The Overview page on an Apple M5 Max: 18.3 MH/s, 6,789 blocks this run, the chain drawn live with this Mac's blocks in the lane marked you, locked checkpoints at 71% of weight, the node synced with 4 peers + The Overview page in light mode: 511 MH/s from one of three cards mining, 629 W, £4.23 a day of electricity, 6,784 blocks this run, the chain drawn live with this rig's blocks marked you, the node line and the activity log +
An Apple M5 Max mining at 18.3 MH/s, from the app in development.A three-card rig at 511 MH/s, from the app in development.
+
+
+
01 · Overview
+

The number, then the chain

+

One big number: your hash rate. Beside it, watts, hashes per watt, and what the electricity costs a day at your price. Then the chain itself, as it grows.

+
    +
  • Your blocks, ringedEvery block the network makes, one lane per miner, yours marked. A locked checkpoint rings the blocks it covers.
  • +
  • The node, one lineSynced, peers, blocks, read N seconds ago. Details opens the chain numbers in place.
  • +
  • ActivityBlocks found, tunes finished, updates installed, with the time of each.
  • +
+
+
+
+
+ +
+
+
+
+
Cards
+ The Cards page: Ember Tune with Efficiency, Balanced and Maximum goals and the watts it saves; one row per card with its rate, watts, hashes per watt, cost a day and temperature; the RTX 5090's details open with its power cap, goal, Retune and the tune curve of hash rate against power + The Cards page of 0.3.16 in light mode: Ember Tune, the RTX 5090 at 103 MH/s, 322 to 317 W, 68 degrees, its tune line and Retune button; the integrated AMD graphics off +
The Cards page with a card’s details open, from the app in development.0.3.16, rendered from the RTX 5090 Windows rig’s live state at 23:33 UK, 6 October 2026.
+
+
+
02 · Cards
+

Every card, tuned by Ember

+

One row per card: rate, watts, hashes per watt, pounds a day, temperature, a Tune button and a switch. Ember Tune walks each card through its power steps and keeps the point with the most hashes per watt.

+
    +
  • Three goalsEfficiency, Balanced, Maximum. Set once for every card, or per card under its chevron.
  • +
  • Under the chevronThe power cap, the goal, the last tune’s curve of rate against watts, how many miners the card runs as.
  • +
  • Power control, one approvalSetting an NVIDIA cap needs administrator rights on Windows. The app asks once; every cap after that is set with no prompt.
  • +
+
+
+
+ + + + + +
Ember Tune, measured 6 Oct 2026UntunedTunedSaved
RTX 5090311.0 W · 127.9 MH/s · 0.411 MH/W226.8 W · 127.7 MH/s · 0.563 MH/W84 W, £0.56 a day at 28p/kWh
RTX 4070106.0 W · 28.72 MH/s · 0.271 MH/W75.6 W · 28.78 MH/s · 0.381 MH/W30 W, £0.20 a day at 28p/kWh
+

Ember run 6 on the three-card Windows rig. The pounds are arithmetic from the saved watts at 28p per kWh; the app uses your price. The log.

+
+
+ +
+
+
+
03 · The chain, live
+

The chain on your screen

+

This is the live devnet, drawn by the same code the app ships. Every square is a real block; a lane per miner; a ring where a checkpoint locked. In the app, your own lane is marked.

+
+
+
+
connecting to the devnet observer
+
on screen 0last lock pendingproven pending
+
+
+
+ pending + included + selected chain + excluded + proven + locked checkpoint +
+

120 s of blocks on screen. Hover or tap a block for its hash, miner and proof state. Ctrl or cmd and scroll, a pinch, or a click into the scene zooms the window.

+
+
+
+ +
+
+
+
+
Earnings
+ The Earnings page of 0.3.16: pounds earned with the devnet reason, IGN from proofs, 23,056 blocks lifetime, electricity with no card reporting its draw, the dev fee switch, the rewards address with Copy, Change address, Show my key and Open the wallet + The Earnings page of 0.3.16 in light mode +
0.3.16 on the team’s Apple M5 Max, paused, 6 October 2026. Pounds earned reads 0.00 on devnet and says why.
+
+
+
04 · Earnings
+

Money first

+

What you made, where it goes. IGN from blocks and from proofs, the electricity at your price, and the address every block pays.

+
    +
  • The dev fee switch1 block in 100 pays the people who make this app. The network itself takes nothing. The switch turns it off.
  • +
  • An address made on this machineCopy it, change it, or show the key. Nothing leaves the machine unless you copy it.
  • +
  • Open the walletYour balance is in the wallet, which imports the miner’s key with one click.
  • +
+
+
+
+
+ +
+
+
+
+
Prove
+ The Prove page of 0.3.16: the Prove on this machine switch, one sentence per card on what it can prove, one line of counts, assigned, proven, paid and IGN, and Details + The Prove page of 0.3.16 in light mode +
0.3.16 on the team’s Apple M5 Max, 6 October 2026. Apple silicon proves on the CPU, slowly; a 24 GB NVIDIA card proves the full shard.
+
+
+
05 · Prove
+

One switch. The same card proves.

+

Every block is turned into a short proof, in pieces called shards. Your cards prove the shards the chain assigns to them and earn IGN for each one.

+
    +
  • One sentence per cardWhat it can prove and how. A 24 GB NVIDIA card proves the full shard; a 32 GB card mines and proves.
  • +
  • One line of countsAssigned, proven, paid, IGN. Details holds the verifier, the program id and the segments.
  • +
+
+
+
+
+ +
+
+
+
06 · Settings
+

Plain rows, one sentence each

+
+
+
Settings · Tuning
+ The Tuning card of Settings in 0.3.16: the goal at Balanced, the Ember Tune, Power control and Fine tuning switches, each with one sentence, and the electricity price in pence per kWh + The Tuning card of Settings in 0.3.16, light mode +
0.3.16 on the team’s Apple M5 Max, 6 October 2026.
+
+
    +
  • Electricity pricePence per kWh, set once. Every pound figure in the app uses it.
  • +
  • Start at loginOpens when you sign in and keeps mining in the background.
  • +
  • Updates by itselfSigned, downloaded in the background, installed at a quiet moment, never mid-program.
  • +
  • LogsCopy the last lines the node and the miner wrote, for a support message.
  • +
+
+
+ +
+
+
+
+
07 · Any width
+

Under 720 px, the rail becomes a tab bar

+

The same window on a narrow screen: the big button, the number, the chain, then the tabs.

+
+
+
390 px
+ The Overview page in a 390 pixel wide window: the rate, the Start mining button, the chain live, and a bottom tab bar with Overview, Cards, Earnings, Prove, Settings and Logs + The Overview page of 0.3.16 in a 390 pixel wide window, light mode: 103 MH/s, the Stop mining button, the chain live and the bottom tab bar +
0.3.16 on the team’s Apple M5 Max, paused.0.3.16, rendered from the RTX 5090 Windows rig’s live state at 23:33 UK.
+
+
+
390 px
+ The Cards page in a 390 pixel wide window: Ember Tune and the card row stacked, with the bottom tab bar + The Cards page of 0.3.16 in a 390 pixel wide window, light mode: Ember Tune, the RTX 5090 row and the bottom tab bar +
0.3.16 on the team’s Apple M5 Max, paused.0.3.16, rendered from the RTX 5090 Windows rig’s live state at 23:33 UK.
+
+
+
+
+ +
+
+
+
08 · It keeps mining
+

Built to be left alone

+

Measured against a worker that misbehaves on command, 4 October 2026: recoveries in seconds. The log.

+
+
    +
  • Hourly program, no pauseThe next program compiles in the background and swaps at the boundary: 0.01 ms on Metal, 0.00 ms on CUDA, 0 rejected blocks.
  • +
  • Watchdog per cardNo status line for 90 s, or a rate of 0 for 60 s while synced: the miner restarts once. Again inside five minutes, the card is marked faulted and the others keep mining. Measured: 91.0 s back to mining.
  • +
  • Watchdog per nodeA node silent for 120 s is restarted by the app. Measured: silent node to mining again in 160.0 s.
  • +
  • Restart in orderMiners first, then the node, on quit and on update. What crashes comes back.
  • +
  • Clock checkOver 5 s out, a warning; over 10 s, Start is blocked and a Sync clock button appears. A slow clock once kept a node silently dead for 12 minutes.
  • +
  • Signed, over the airAn Ed25519 key compiled into the app checks the manifest before the app reads it. If the new version fails to start twice, the previous one comes back by itself.
  • +
+
+
+ +
+
+
+
Downloads
+

Get the miner

+

Download only from this domain. Nobody from Igneum will ask for your seed.

+
+
+ +
+

Your card: pending

+

Public testnet: not yet open; the devnet build is here for people who want to look.

+

Devnet. Coins have no value and the chain may be reset.

+
+
+
+
+
+ +
+
+
+

The miner pays the wallet.

+

Install the miner, press Start, and the address it makes is the one the wallet imports with one click.

+
+ +
+
+ +Download the minerv0.3.19 · 62.7 MB + + + + + + + + + + + + diff --git a/site/bench.html b/site/bench.html index 0ebb5c4a..54e889ec 100644 --- a/site/bench.html +++ b/site/bench.html @@ -31,6 +31,7 @@ + -
-
-
90 entries, newest at the bottom
+
+
+
+ +
92 entries, newest at the bottom

Engineering log

-

Every measurement the project has made, newest at the bottom, written by the people and agents who ran it, with the commands and hardware. Prototype numbers are not mining numbers and say so.

+

Every measurement the project has made, newest at the bottom, written by the people and agents who ran it, with the commands and hardware. Prototype numbers are not mining numbers and say so.

-
- -

Igneum bench log

+
+
+
+
+ +

Igneum bench log

Append-only. Every number here was measured on the machine named, on the date given.

-

2026-10-03 proto-metal / igneum-bench, first run

+
+

2026-10-03 proto-metal / igneum-bench, first run

Machine: Apple M5 Max, 40 GPU cores, 64 GB unified memory, macOS Darwin 25.6.0, Swift 5.8.1, Metal 4. Build: swiftc -O -o igneum-bench main.swift -framework Metal. Source: proto-metal/main.swift. Setup: 1 GiB dataset (2^28 uint32), 64 instructions x 8 iterations, threadgroup 32 (threadExecutionWidth 32), 4 timed batches x 2^22 nonces after one warm-up batch. Verification: 3 warps per program, CPU interpreter vs GPU.

SeedLoads/hashCompile msMhash/sGB/s usefulCPU verify ms/warpVerify
igneum-genesis10449.6 (cold)45.218.80.015PASS
igneum-genesis/epoch110420.348.420.10.019PASS
igneum-second-seed10446.6 (cold)35.514.80.016PASS
igneum-second-seed/epoch114418.735.420.40.017PASS
igneum-hourly12852.0 (cold)36.618.70.021PASS
igneum-hourly/epoch112821.637.519.20.017PASS
igneum-hourly/epoch212023.736.617.60.016PASS

Dataset size sweep (seed igneum-genesis): 4 MiB 569 Mhash/s, 64 MiB 183, 256 MiB 94, 512 MiB 69, 1 GiB 44. Dataset fill 1 GiB: 2.34 ms GPU time (427 GB/s) warm, 5.57 ms on first run of a process. Result: 21 warps, 672 hashes, zero mismatches. OVERALL PASS. Reading: memory bound at 1 GiB (12.8x drop from cache-resident), limited by random access rather than bandwidth, CPU verify roughly 250x under the 10 ms gate with a cheap dataset element. Apple silicon only. Details in proto-metal/README.md.

-

2026-10-03 proto-cuda / program pack export (Apple M5 Max side only; RTX 5090 run pending)

+
+

2026-10-03 proto-cuda / program pack export (Apple M5 Max side only; RTX 5090 run pending)

Machine: the same Apple M5 Max. No CUDA toolchain exists on it, so nothing below is an NVIDIA measurement. Added --export-pack <dir> to proto-metal/main.swift. It writes, per seed, the CUDA kernel (kernel.cu), C headers (program.h, vectors.h), JSON twins, and the Metal source, into proto-cuda/packs/<seed>/. Vectors: 3 warps (base nonces 0, 4096, 1000000), 96 x 64-bit outputs from the CPU interpreter, plus dataset words 0..15 and word [MASK]. The exporter runs the Metal kernel for the same warps and refuses to write unless all 96 match.

PackLoads/hashOp mixCPU interpreter vs Metal GPU (3 warps)CUDA text in CPU emulation (clang, 32 threads/warp)
igneum-genesis104load=13 xor=13 sub=7 shfl=6 add=5 mulhi=5 mad=4 rotr=4 mul=3 rotl=3 or=1PASS 3/3PASS: dataset self-test, 3/3 warps standalone, warps 0 and 4096 in batch at 1 and 2 warps/block
igneum-hourly128load=16 add=8 xor=7 mad=5 mul=5 mulhi=5 shfl=5 rotl=4 or=3 rotr=3 sub=3PASS 3/3PASS: dataset self-test, 3/3 warps standalone, warps 0 and 4096 in batch at 1 warp/block

Sweep sizes 4, 64, 256, 512 MiB in the emulation: dataset self-test PASS at each (vectors only apply at 1 GiB). The regular Metal bench was re-run after the change: igneum-genesis 44.8 Mhash/s and igneum-hourly 36.3 Mhash/s at 1 GiB with 2 x 2^20 batches, PASS 3/3 warps each (consistent with the first-run table above, not a new figure). Harness: proto-cuda/host.cu, build.sh, build.bat, README.md, CHECKLIST.md, emu/. Pending: build and run on the project's RTX 5090 (CUDA 12.8 or newer, -arch=sm_120). No NVIDIA hash rate exists yet. Emulation rates are not recorded because they measure the Apple M5 Max's CPU, not a GPU.

-

2026-10-03 sim/finality_sim.py, sustained-mining finality vote weight (model, not hardware)

+
+

2026-10-03 sim/finality_sim.py, sustained-mining finality vote weight (model, not hardware)

Model: 1 day steps, 86,400 Poisson blocks/day, 1,000 Pareto honest keys (top key 17%), perfect retarget, every block blue, no latency, no VRF noise. Seed 7, seed 11 agrees. Rule: weight = 30-day sum of counted blocks, counted = min(actual, 2 x yesterday + f). Lock at 2/3 of total. Floors f in {1, 10, 100, 1000}. A: weight tracks hashrate at steady state (corr 1.00000); full weight from zero history on day 41 (f=1) to 32 (f=1000). B: 60% renter on one key takes 59.9% of rewards on day 1, crosses 1/3 of weight on day 20 to 26, 50% on day 27 to 34, never 2/3. 75% renter reaches 2/3 on day 29 to 34, day 27 with the cap removed. C: splitting defeats the cap. 10,000 fresh keys at f=1 move the 50% crossing from day 34 to 27 (no-cap figure 26); at f=10 they match no-cap exactly. The 30-day trickle buys 2 more days for 11.6% of the network. D: honest doubling is under-weighted 28 to 31 days; old miners lock alone for 20 to 23 days. E: 30% churn leaves 71% live, lock never lost. Threshold is 1/3: 35% stalls 1 day, 50% stalls 10 to 11 days. Active-24h total removes every stall. F: 51% patient owner holds 51.0% weight from day 45, vetoes from day 7 to 20, never locks alone. 67% owner locks alone from day 34 to 44. Recommend: f=1, cap 2x, window 30 (the window is the defence, the cap is worth 1 to 8 days), total = all keys with weight in the window. Details in sim/results.md.

-

2026-10-03 proto-metal hardening tests (correctness and soundness of the lottery hash, Metal only)

+
+

2026-10-03 proto-metal hardening tests (correctness and soundness of the lottery hash, Metal only)

Machine: the same Apple M5 Max. Added --fuzz, --edge, --stats, --determinism, --memcheck, --inline-dataset to proto-metal/main.swift. Full tables and commands in proto-metal/TESTS.md. Fuzz: 10,200 random programs (200 + 10,000, cold compiles 13.6 to 48.5 ms), 4 random full-range warps each, dataset drawn from 64 MiB / 256 MiB / 1 GiB: 40,800 warps, 1,305,600 hashes, 0 mismatches, 0 compile failures, 0 static mask failures, generator contract (rotl 1..31, mask in {1,2,4,8,16}, src != dst) held on every instruction. 196 s for the 10,000 run. Edge: 14 hand-built cases (rotr by register 0 / 32 / -32 / 31 / 63, rotl 1 and 31, mulhi max operands, shfl masks 1..16, loads at index 0 and MASK via in-range and out-of-range registers, add/sub/mul/mad wraparound, zero loads, 64 loads) with operand values proven by a traced interpreter: 14/14 PASS, 128/128 lanes each. rotl by 0 (never generated) agreed too, recorded as informational only. Stats (3 seeds, 2^20 nonces each): bit frequency max deviation 2.90 sigma over 192 bit positions; avalanche 16,000 flips mean 31.99 to 32.04 (expect 32), std 3.98 to 4.01 (expect 4), every output bit flips with probability 0.490 to 0.508; chi-square on four 16-bit windows all within 2.3 sigma; 0 duplicates. Looks uniform. Not a security proof. Determinism: 5 runs and 3 compiles (one forced cold, 30 ms) of 2^20 hashes gave fingerprint 933787e8cfefccb7 every time; dataset fill deterministic (0b1a77899ee60493 twice) and 4,096 sampled words incl. 0 and MASK match the CPU closed form. Memcheck: every dataset[ in the MSL is dataset[rN & MASK] (13/13 at 3 sizes), CUDA twin 13/13 plus one guarded fill write; 4 MiB run with nonces up to 0xffffffff completed and 4 wrapping warps matched the CPU; 416/416 load indices exceeded MASK before masking. Bench re-run after the changes: igneum-genesis 44.56 Mhash/s, epoch1 47.74 Mhash/s at 1 GiB, PASS 3/3 warps each (within 2 percent of the first-run table). --export-pack igneum-genesis re-run is byte-identical to the existing pack. SHORTCUT MEASURED: --inline-dataset replaces every load with the six-op closed form ds_elem and never reads memory: 4,888 Mhash/s wall (6,274 GPU time) vs 44.6 honest at 1 GiB, about 110x, and about 9x the cache-resident honest rate. With a closed-form dataset the hash is not memory-hard; an expensive dataset derivation is required, not optional. Not demonstrated: cryptographic strength, weak-program frequency and rejection, NVIDIA/AMD bit-exactness (CUDA run still pending), CPU verify gate with an expensive dataset element. Next three tests for the cryptographer are listed in TESTS.md section 8.

-

3 October 2026, RTX 5090 first run (an RTX 5090 on Windows, CUDA 12.8 runtime, driver 13.4, Visual Studio 2026 with the 14.30 toolset selected via vcvarsall -vcvars_ver=14.30)

+
+

3 October 2026, RTX 5090 first run (an RTX 5090 on Windows, CUDA 12.8 runtime, driver 13.4, Visual Studio 2026 with the 14.30 toolset selected via vcvarsall -vcvars_ver=14.30)

Pack igneum-genesis, dataset 1024 MiB, 5 batches x 2^24 hashes, 1 warp per block.

CardMhash/s at 1 GiBGB/s usefulrandom loads/sdataset fillvectors
NVIDIA RTX 5090 (170 SMs, 32 GB)228.194.923.7 G0.66 ms, 1638 GB/s96/96 PASS, standalone and in batch
Apple M5 Max (40 GPU cores, same program, same day)45.218.84.6 G2.34 ms, 427 GB/s96/96 PASS

Result: the same hourly program, generated on the Apple M5 Max, compiled by Apple's Metal and NVIDIA's CUDA, produced identical hashes on both vendors. Vendor independence of the lottery program is demonstrated for one program; igneum-hourly and the dataset sweep are the next runs. The ratio 5090 to M5 Max is about 5x on hashes and on random loads per second, approximate, consistent with a memory-bound program (random-access bound, not bandwidth bound: the 5090 writes the dataset at 1638 GB/s but hashes at 95 GB/s of useful 4-byte loads). Caveat unchanged: the prototype dataset is closed-form and not yet memory-hard (see TESTS.md), so these are prototype numbers, not mining numbers.

@@ -158,58 +175,78 @@ table{min-width:560px}
dataset MiBMhash/sGB/s usefulrandom loads/s (G)
41339.8557139.3
641352.7563140.7
256269.811228.1
512241.810125.2
1024228.79523.8

Second program igneum-hourly (128 loads per hash): 96/96 vectors PASS, 185.3 Mhash/s at 1 GiB, 23.7 G random loads/s.

Reading: the 5090 carries 96 MiB of L2. At 4 and 64 MiB the dataset sits inside it and the program runs about 5.8x faster than at 1 GiB. Past the L2 the rate settles at about 23.7 G random loads/s for both programs regardless of loads per hash (104 vs 128 loads gives 228 vs 185 Mhash/s, proportional), so the program is random-access bound once the dataset exceeds on-chip cache. Each 4-byte random load moves a 32-byte sector, so DRAM traffic is roughly 760 GB/s, approximate, against a quoted peak near 1.8 TB/s for this card. Design consequence: the dataset must stay well above any plausible on-chip cache, which the 2 GB genesis size and the growth schedule provide; a chip would need gigabytes of on-chip memory to escape the random-access limit. Still prototype numbers: dataset derivation remains closed-form until the 256 MB cache construction lands.

-

2026-10-03 sim/finality_v2.py, finality rule V2 with latency, partitions and eclipses (model, not hardware)

+
+

2026-10-03 sim/finality_v2.py, finality rule V2 with latency, partitions and eclipses (model, not hardware)

Model: 30-s slots, Poisson(30) blocks/slot, 1,000 Pareto honest keys in 3 regions (45/35/20), 2-s inter-region delay (0.5 and 5 swept), uptime 97% (99.5% for pools over 1%), warm 30-day start for B to G. Seed 7, seed 11 agrees on B and E. Run time 5 min. Details in sim/results_v2.md. Rule: weight = flat 30-day blue blocks, dust 100, checkpoint per 30 blocks, lock at 2/3 of ACTIVE (participation over 240 checkpoints) vs TOTAL weight. A: weight = hashrate (corr 1.00000), full weight day 30, all keys over dust by day 20, lock median 2.5 s / p99 4.6 s at 2 s delay, 14 s max at 5 s, 0 stalls in 60 days except 17 at genesis. B: share(t) = (t/30) x a/(1+a) holds to 0.04 points; 1/3 crossed at day 20.0 / 15.0 / 12.5 / 11.1 and 2/3 at never / 30.0 / 25.0 / 22.2 for a = 1 / 2 / 4 / 9; dust hands a 9x renter 1.3 extra points. C: silent set that keeps mining: active recovers in 0 / 13 / 20 / 29 / 38 min at 34 / 40 / 45 / 50 / 55%; total never (silent weight never ages out). D: churn: active 2 min (35%) and 31 min (50%); total 41 h and 10.1 days. E: active FAILS the partition test: 50/50 honest split, no attacker, both sides lock after 60 min (30 with DAA retarget), 60/40 after 121 min; first-lock time = presence x (1 - 1.5 s)/s slots, confirmed. Total: 0 conflicts in every honest partition. 34% attacker breaks every variant at 50/50 (67% per side). F: delayed eclipse of a 20% pool is harmless (participation 0 after 2 h, back in 2 h, 0 conflicts); a 34% attacker poisoning that pool finalises a private fork in 49 min under active, never under total. Floor hybrid: active denominator never below 0.85 x total (lock needs 56.7% of total) gives 0 conflicts in every partition and eclipse, recovers in 0 / 13 min at 34 / 40% silent and 2 min at 35% churn; costs 4.1 days at 50% churn and liveness ends near 42% silent. Floor 0.80 does not stop the eclipse (54% > 53.3%). Recommend: active/cert + floor 0.85, presence 240, dust 100, quorum 2/3, grace at least 3x worst delay. Not modelled: real GHOSTDAG merge and post-heal fork choice, DAA lag, VRF aggregators, certificate revocation.

-

2026-10-03 proto-metal memory-hard dataset (cache + 8 dependent reads), Metal only; CUDA pack emulated

+
+

2026-10-03 proto-metal memory-hard dataset (cache + 8 dependent reads), Metal only; CUDA pack emulated

Machine: the same Apple M5 Max (one performance core for the CPU figures). Construction, every table and the commands are in proto-metal/MEMHARD.md. Default dataset is now memory-hard; --closed-form keeps the original for comparison. Construction: 256 MiB cache = 2^22 lines of 64 B in 2^16 chains of 64 ChaCha12 blocks with feed-forward (in_j = prev ^ (sigma || K[8] || seg || j || tag)); item t = 16 words, 8 rounds of (seed-parameterised ARX-multiply mixer, read cache line s[0] & (2^22-1), xor) plus a final mixer; dataset[w] = item(w >> 4)[w & 15]. Hash kernel unchanged. Cache fill: 2.0 ms GPU (0.6 to 2.1 across runs), 185 ms one CPU core (Swift), 162 ms C++ host reference. Dataset build 1 GiB: 20.6 ms GPU (29.4 first in process), 814 M items/s, 6.5 G cache-line reads/s. GPU cache == CPU cache on all 2^26 words every run (FNV-1a 64 48c4f5bf24166b2e for day 2026-10-03). Shortcut ratio, seed igneum-genesis, 1 GiB: honest 45.2 Mhash/s in both constructions. Inline kernel (never reads the dataset): closed form 5,014 Mhash/s (111x FASTER than honest); memory-hard 9.49 Mhash/s (0.21 of honest, 4.8x SLOWER). At a 256 MiB dataset: honest 94.8, inline 9.48 (0.10). CPU verify per 32-lane warp (holds only the cache, derives every word on demand, 32 lanes interleaved): 0.649 / 0.631 / 0.701 ms for igneum-genesis, /epoch1, /epoch2 (104, 104, 112 loads; 3,328 to 3,584 items); 0.801 ms igneum-second-seed (104 loads); 1.205 ms igneum-second-seed/epoch1 (144 loads, 4,608 items). Cold single warps 1.16 to 2.11 ms. Closed form was 0.017 ms. 10 ms GATE MET, margin about 8x steady. Levers (implemented, measured, OFF by default; default generator unchanged): (a) --load-weight 17: 72 to 80 loads/hash, CPU 0.457 to 0.512 ms/warp, GPU 55.0 to 73.4 Mhash/s. (b) --wide-frac 50 (warp-coalesced 128 B loads): CPU 0.233 to 0.489 ms/warp, GPU 56.1 to 135.2 Mhash/s and useful bandwidth up to 56 GB/s, so (b) erodes the random-access bound. (a)+(b): CPU 0.223 to 0.276, GPU 106 to 139. Recommendation: no lever; (a) is the fallback if a slower verifier ever threatens the gate; (b) not recommended. Tests re-run on the new dataset: fuzz 200/200 (800 warps, 25,600 hashes, 0 mismatches, CPU interpreter 1.23 s), edge 14/14, determinism PASS (fingerprint 62a4f0eb018df273), memcheck PASS, stats PASS (3 seeds, no obvious bias). 3 warps x 3 seeds bit-exact in the bench run. CUDA: new pack proto-cuda/packs/igneum-genesis-mh (kernel.cu with cache-fill and build kernels, memhard.h shared by device and host, vectors incl. cache head/last/FNV and 64 sampled words). host.cu handles both modes; old packs unchanged (closed-form export re-run is byte-identical in kernel.cu and program.metal). clang emulation (emu/emu.sh igneum-genesis-mh): cache check PASS (all words, FNV == Mac), dataset self-test PASS at 1 GiB, 3/3 vectors standalone and 2/2 in batch at 2 warps/block. RTX 5090 and AMD runs of this pack PENDING; no NVIDIA figure for the memory-hard dataset exists. Not demonstrated: cross-vendor results for the new dataset; the shortcut ratio on a discrete GPU; time-memory trade-offs between the two measured points; cryptographic strength of the mixer and the chained cache; distinct-lines-per-hash census.

-

2026-10-03 rusty-kaspa base build and 3-node devnet on the Apple M5 Max (consensus-engineer, pre-fork proof)

+
+

2026-10-03 rusty-kaspa base build and 3-node devnet on the Apple M5 Max (consensus-engineer, pre-fork proof)

Machine: Apple M5 Max (18 CPU cores), 64 GB, macOS 26.6.2. Toolchain: Homebrew rust 1.69.0 was too old (repo needs 1.91.0), so rustup 1.29.1 was installed non-interactively and gives rustc 1.99.0 and cargo 1.99.0; protobuf 36.2 added via brew install protobuf (protoc was missing); Apple clang 14.0.3 already present. Nothing else was needed. Source: vendor/rusty-kaspa at commit 01b532e8b553523216471682649693af92f0fd16 (v2.1.0, 2026-09-22). cargo build --release --bin kaspad: 2 min 36 s cold, binary 35,405,104 bytes (34 MB), 131 compiler warnings, zero errors. Devnet: three kaspad --devnet --nodnsseed --disable-upnp --enable-unsynced-mining --yes --loglevel=info nodes, separate --appdir, P2P 16611/16621/16631, gRPC 16610/16620/16630, nodes 2 and 3 --connect to node 1 (node 3 to node 2 never came up because both started at once, so the topology was a star through node 1). Network params: 10 BPS (100 ms blocks), GHOSTDAG k 124, merge depth 36,000 blocks, finality depth 432,000, pruning depth 1,080,000, DAA window 661 samples x 40 blocks, genesis bits 0x1e21bc1c (about 248,663 hashes per block). Miner: kaspad ships none, so a 150-line CPU miner on kaspa-pow::State (real kHeavyHash, 16 threads, 300 ms template refresh) submitted to node 1 only: 27.2 MH/s sustained, 5,718 blocks in 180 s, 0 rejected. Blocks per second over the 180 s run: 31.76 on all three nodes (1,691 to 7,409 blocks each). Two phases: 56 to 62 blocks/s while difficulty sat at genesis (first 6,000 blocks, min window 150 samples), then the DAA raised difficulty to 1.12 M at block 6,018 and the rate fell to 14 to 15 blocks/s, still converging toward the 10 BPS target when the run ended. Propagation: block counts, DAA scores and sink hash were identical on all three nodes at 18 of 19 ten-second samples; the one miss was node 2 trailing by a single block for one sample. Tips stayed at 1 because a single serial miner never produced parallel blocks, so GHOSTDAG k was not exercised; a second miner is the next step for that. Earlier 30 s warm-up run: 1,690 blocks, 56.3 blocks/s on all three nodes, 28.1 MH/s. Fork points mapped with line numbers in docs/fork-map.md (hash, coinbase, DAA, header, depth constants, BPS and k). All nodes stopped at the end. Miner source kept outside the repo (scratchpad); re-create from testing/integration/src/common/utils.rs:271 if needed.

-

3 October 2026, RTX 5090, memory-hard dataset (pack igneum-genesis-mh)

+
+

3 October 2026, RTX 5090, memory-hard dataset (pack igneum-genesis-mh)

CheckResult
256 MiB cache, GPU vs host, all 67,108,864 wordsPASS, FNV-1a 48c4f5bf24166b2e matches the Apple M5 Max
Cache fill0.67 ms GPU, 223 ms one host thread
Dataset build from the cache, 1 GiB13.4 ms, 1,253 M items/s
Vectors, 3 warps, standalone and in batch96/96 PASS
Hash rate at 1 GiB228.95 Mhash/s, 95.2 GB/s useful, 23.8 G random loads/s

Reading: the memory-hard construction is now bit-exact across Apple Metal, NVIDIA CUDA and the CPU reference, cache and dataset included. Hash rate is unchanged from the closed-form dataset on both vendors, as expected, since the hash kernel only loads; what changed is that computing items on the fly is now slower than loading them (4.8x slower measured on Apple, not yet measured on NVIDIA). Still unmeasured: the inline shortcut ratio on NVIDIA, and AMD on any dataset.

-

2026-10-03 proto-vdf, Wesolowski VDF between the certified checkpoint and the program seed (epoch 10 min, era 1 h)

+
+

2026-10-03 proto-vdf, Wesolowski VDF between the certified checkpoint and the program seed (epoch 10 min, era 1 h)

Machine: Apple M5 Max (18 logical cores), rustc 1.69.0, GMP 6.3.0 via rug 1.19. Source proto-vdf/, details in proto-vdf/README.md. Single core sequential squaring unless stated. Rates: class group 1024-bit prime discriminant (production choice, chiavdf construction, NUDUPL/NUCOMP ported from vendor/chiavdf) 163,000 sq/s; class group 2048-bit 83,500 sq/s; RSA-2048 trusted-setup stand-in (public trapdoor, timing only) 1,257,000 sq/s. T for 10 min / 60 min on this core: class 1024: 98.0 M / 588 M; class 2048: 50.1 M / 301 M; RSA-2048: 754 M / 4.53 G. Full 10-min runs: RSA T=756,516,411 eval 607.1 s (1,246,000 sq/s), prove 9.0 s on 12 threads (71.2 s on 1), verify 0.88 ms, proof 512 bytes. Class 1024 T=97,126,043 eval 585.4 s (165,900 sq/s, the RSA run sharing the chip ended midway), prove 9.1 s on 12 threads (56.8 s on 1), verify 4.47 ms, proof 516 bytes. Prover costs 12 to 13 percent of eval single-threaded (12-bit digits, at most 65,536 checkpoints, 17 MB) and parallelises over residue classes; verify is two 256-bit exponentiations, 4.5 ms class 1024 (12.6 ms including deriving D from the checkpoint hash), 1.4 ms RSA. Seed pipeline: epoch_seed(checkpoint) -> (seed, proof) and verify_epoch_seed; the same checkpoint hash gave the same seed and identical proof bytes in two separate processes at T=1,000,000; wrong checkpoint, flipped seed bit and T+1 all rejected. Attacker speed: delay must only exceed the 2 s publish-or-lose window; margin is 300x at the epoch and 1,800x at the era, so a 2x (or 10x, or 100x) faster evaluator leaves grinding impossible. Requirement: the checkpoint hash must commit to full block hashes incl. nonce. Grinding model (3,600 blocks/epoch, advantage uniform 0 to 15%, keep top quartile, one block burned per withheld candidate), gain per epoch in blocks, no delay vs with delay: s=0.1 +0.40 vs 0; s=0.2 +1.66 vs 0; s=0.3 +3.62 (+0.32%, 13.5:1 on burned blocks) vs 0; s=0.4 +6.06 vs 0. Monte Carlo over 2,000,000 epochs agrees to 0.03 blocks. Correctness: NUDUPL, NUCOMP and the Lehmer partial xgcd agree with Cohen 5.4.7 / plain duplication / plain-division xgcd on 15,000 random cases; block prover equals the naive O(T) prover at T = 37, 5,000 and 100,000 in both groups; 216 associativity triples; 3 tamper cases rejected per size. Recommend: class group 1024-bit D from the checkpoint hash, epoch T = 600 x r_ref and era T = 3,600 x r_ref with r_ref the fastest honest single-core rate measured on the devnet (98 M and 588 M on this Mac), fixed at genesis, 20 min lead time for the epoch seed and 2 h for the era draw, 256-bit Fiat-Shamir prime. Open: external review of classgroup.rs against chiavdf, reference core choice, fallback rule for a node without the seed at epoch start, carry D in the proof.

-

2026-10-03 igneum-pow: Rust crate bit-exact with proto-metal (consensus-engineer)

+
+

2026-10-03 igneum-pow: Rust crate bit-exact with proto-metal (consensus-engineer)

Machine: Apple M5 Max, one performance core, rustc 1.99.0 (rustup), release build with LTO. Crate at igneum-pow/ (seed, generator, memhard, verify, emit; CLI bench, export, hash), standard library only, serde_json as a dev-dependency for the pack tests. Agreement with the Swift through proto-cuda/packs/: program.json instruction by instruction for igneum-genesis, igneum-genesis-mh and igneum-hourly (3 x 64 match); mixer rot/mul/rc match; cache head, last line and FNV-1a 64 48c4f5bf24166b2e match; dataset head, [MASK] and 64 sampled words match in all three packs; hash vectors 96/96 for igneum-genesis-mh (memory-hard) and 96/96 each for the two closed-form packs. 23 tests, all pass. Emitted sources: kernel.cu, program.metal, kernel.cl and program.h byte-identical for all three packs, memhard.h and memhard.metal byte-identical for igneum-genesis-mh; igneum-pow export then diff -r against the packs differs only in the provenance string of vectors.json/vectors.h. Found: proto-cuda/packs/igneum-genesis-mh/program.json is not valid JSON (main.swift line 1291 writes jhex(cacheLineMask) inside the "item" string). The Rust emitter writes the mask bare and the test normalises that line; fix pending in the Swift. Cache fill, 256 MiB on one core: 175 to 181 ms in Rust (5 runs) against 184.5 to 190.6 ms Swift and 161.5 ms C++ host reference. CPU verify per 32-lane warp, avg of 20, 1 GiB dataset: igneum-genesis 0.441 ms (Swift 0.649), /epoch1 0.411 (0.631), /epoch2 0.488 (0.701), igneum-second-seed 0.482 (0.801), igneum-second-seed/epoch1 at 144 loads and 4,608 items 0.579 (1.205). Cold single warps 0.41 to 0.87 ms (Swift 1.16 to 2.11). Closed form 0.002 ms (Swift 0.017). Reading: Rust is 1.4x to 2.1x faster than the Swift verifier per warp with the same algorithm (register-major lanes, 32-lane interleaved item derivation); 10 ms gate margin about 17x steady, 11x on the worst cold warp. Cache fill is within 5 percent of the Swift and 10 percent slower than clang C++. API for the fork: Epoch::memory_hard(seed, day) once per epoch (fills the cache), then epoch.hash(nonce), epoch.hash_warp(base), epoch.verify_block(nonce, target); emit::export_pack(&epoch, day, source) for miner programs. seed::seed_words_from_bytes is the boundary for the VDF output. Not done: no GPU run from Rust; the 256-bit target mapping stays in the fork; the seed is still a string.

-

3 October 2026, proto-opencl: OpenCL path built and proven without AMD silicon (Apple OpenCL 1.2, pocl, CPU emulator)

+
+

3 October 2026, proto-opencl: OpenCL path built and proven without AMD silicon (Apple OpenCL 1.2, pocl, CPU emulator)

Machine: the same Apple M5 Max. New: proto-opencl/host.c (C99, OpenCL 1.2 API), kernel.cl in every pack from --export-pack (same emitter, OpenCL C dialect; memory-hard core emitted in three dialects), WAVEFRONT.md, CPU emulator with a 32- or 64-wide sub-group. The AMD rig has not arrived; no AMD compiler or device has touched this code. Exchange rule: sub_group_shuffle_xor only when the device lists cl_khr_subgroup_shuffle, the work-group is exactly 32 and the queried sub-group size for a 32-item work-group is exactly 32; otherwise a __local memory exchange with one barrier per exchange (two alternating buffers). Wave64 hardware (GCN, CDNA, RDNA in wave64) therefore takes the local-memory path and the hash never depends on the wave width. Apple OpenCL 1.2 runtime, Apple M5 Max (40 CUs, OpenCL C 1.2, no sub-group extension, local-memory path): cache check PASS (all 2^26 words, FNV-1a 64 48c4f5bf24166b2e = Mac), dataset self-test PASS, 96/96 vectors standalone and in batch for igneum-genesis-mh; also 96/96 at --exchange local --group-warps 2 and --group-warps 4; closed-form packs igneum-genesis 96/96 and igneum-hourly 96/96. Apple OpenCL hash rate (wall time; Apple's event timestamps are unusable), pack igneum-genesis-mh, 1 GiB, 5 x 2^24: 45.03 Mhash/s, 18.73 GB/s useful (repeat run 44.58). igneum-genesis 45.17, igneum-hourly 36.33 (128 loads). Metal on the same chip: 45.2. This is Apple's deprecated OpenCL on the M5 Max, NOT an AMD number. Apple OpenCL sweep (3 batches): 4 MiB 573.7 Mhash/s, 64 MiB 178.9, 256 MiB 94.3, 512 MiB 68.8, 1024 MiB 45.0 (Metal sweep shape reproduced). pocl 7.2 CPU device (OpenCL 3.0, LLVM 23, Khronos ICD loader, brew install pocl, needs SDKROOT): --exchange auto and --exchange subgroup built with -cl-std=CL3.0 -D IGNEUM_EXCHANGE=1 and ran the real sub_group_shuffle_xor text: cache FNV = Mac, 96/96 PASS. pocl's clGetKernelSubGroupInfoKHR returns CL_INVALID_OPERATION, so the new probe kernel (igneum_probe_subgroup, reports get_sub_group_size() 32) decided; --exchange local also 96/96. CPU emulator (proto-opencl/emu, kernel.cl compiled as C++, 1 GiB dataset built on 256 host threads): 7 configurations all PASS with the identical batch fingerprint f99fb375b3abeaf5 over 2^13 outputs: exchange 0 with work-group 32/sub-group 32, 64/64, 32/64; exchange 1 (sub-group shuffles) with 32/32, 32/64, 64/64 (wave64 carrying two 32-lane units in one shuffle domain), 64/32. Cross-implementation fingerprint at --batch-log2 13, base nonce 0, igneum-genesis-mh: Apple OpenCL f99fb375b3abeaf5, pocl sub-group f99fb375b3abeaf5, pocl local f99fb375b3abeaf5, emulator f99fb375b3abeaf5 (all 7). At 2^24 Apple OpenCL prints 98af644e993239e2 (reference for the AMD run). proto-cuda emulator re-run after the header changes (program.h, vectors.h, memhard.h now C99-safe): PASS. Not demonstrated: any AMD compile or run, any AMD hash rate, the cost of the local-memory exchange on AMD, whether RDNA compiles igneum_hash as wave32 or wave64. Next: run the seven commands in proto-opencl/README.md on the AMD rig and paste the logs.

-

3 October 2026, AMD gfx1036 (Ryzen 7 9800X3D integrated RDNA 2 graphics, 1 compute unit), AMD OpenCL 2.1 driver 3652.0

+
+

3 October 2026, AMD gfx1036 (Ryzen 7 9800X3D integrated RDNA 2 graphics, 1 compute unit), AMD OpenCL 2.1 driver 3652.0

Pack igneum-genesis-mh, memory-hard dataset, 1024 MiB, exchange via local memory (the driver lists no sub-group shuffle extension), wavefront 32.

CheckResult
256 MiB cache, device vs host vs MacPASS, 17.5 ms device fill
Dataset build from the cache, 1 GiB392 ms, 42.8 M items/s
Dataset self-test, 4 checksPASS
Vectors, 3 warps, standalone and in batch96/96 PASS
Hash rate4.38 Mhash/s on one compute unit, 1.82 GB/s useful

Reading: the third GPU vendor. The same memory-hard program now produces identical hashes on Apple Metal, NVIDIA CUDA, Apple OpenCL and AMD OpenCL, cache and dataset included. The AMD number is from a two-CU integrated chip sharing system memory and is a correctness result only; the discrete AMD card is still to come. The local-memory exchange path, which wave64 cards will also use, is now proven on AMD silicon.

-

3 October 2026, RTX 5090 through NVIDIA OpenCL (fourth compiler path on the same card)

+
+

3 October 2026, RTX 5090 through NVIDIA OpenCL (fourth compiler path on the same card)

Pack igneum-genesis-mh, 1024 MiB, local-memory exchange (NVIDIA's OpenCL lists no sub-group shuffle extension).

CheckResult
Cache check and dataset self-testPASS
Vectors96/96 PASS, batch fingerprint 98af644e993239e2, identical to the AMD gfx1036 run
Hash rate219.6 Mhash/s via OpenCL against 229.0 via CUDA, about 4% apart, approximate

Reading: NVIDIA's OpenCL compiler and NVIDIA's CUDA compiler agree with each other, with AMD's OpenCL, with Apple's Metal and OpenCL, and with the CPU reference. The batch fingerprint over 16.7 million consecutive nonces is identical on the AMD integrated chip and the 5090, which is a far stronger statement than the 96 vectors alone. The local-memory exchange costs about 4% against CUDA's warp shuffle on this card, approximate.

-

3 October 2026, igneum-node devnet v0: 3-node igneum-devnet at 1 BPS with the 80/20 coinbase and vote_key_hash (consensus-engineer)

+
+

3 October 2026, igneum-node devnet v0: 3-node igneum-devnet at 1 BPS with the 80/20 coinbase and vote_key_hash (consensus-engineer)

Machine: Apple M5 Max (18 logical cores), rustc 1.99.0, fork vendor/igneum-node at commit "Build: forward the igneum-pow feature" on top of rusty-kaspa v2.1.0 01b532e8. Release build of kaspad and igneum-miner; the kHeavyHash stub engine (default feature set); cargo check -p kaspad --features igneum-pow also builds. Network: three kaspad --devnet --nodnsseed --disable-upnp --enable-unsynced-mining nodes, P2P 26611/26621/26631, gRPC 26610/26620/26630, nodes 2 and 3 --connect to node 1 and node 3 also to node 2; network name igneum-devnet, k 18, merge depth 3,600 blocks, DAA 661 samples x 4 blocks, genesis bits 0x1e020000 (2^23 expected hashes per block). Miners: three igneum-miner mine processes, 6 threads each, one per node, 960 s, each with its own vote-key label: 2.21 MH/s each (6.63 MH/s total), found 253 + 284 + 270 = 807 blocks, 0 rejected. Blocks per second: 0.84 on all three nodes over the 901.9 s watch window (755 blocks each); expected 0.79 from hash rate over genesis difficulty, then the DAA lowered difficulty from 4,194,304 to 3,444,348 after its 600-block minimum window (block 600 to 711), still converging to 1.00 when the run ended. Propagation: block count, DAA score and sink hash identical on all three nodes at 90 of 90 ten-second samples; 1.11 parents and 1.11 mergeset per block on average, tips stayed at 1 (three serial CPU miners rarely collide). vote_key_hash: igneum-miner inspect 40 read the same 40 selected-chain blocks from all three nodes over gRPC and found the header's vote_key_hash identical on every node for 40 of 40 blocks, with the three miners' distinct hashes (17 + 17 + 6 blocks) all present, so the field round-trips through the template RPC, submit, p2p relay and the header hash. Emission: 80/20 exact on 39 of 39 single-payee coinbases (the 40th merged two blues, three outputs, pool share still 0.2000); at DAA 806 the payload subsidy was 317,767,704 units (launch ramp day 0, 10.03%), split 254,213,284 to the miner and 63,553,320 to the OP_RETURN igneum-proving-pool-v0 output. Unit tests, release profile: kaspa-consensus-core igneum 8 pass (subsidy table, ramp, split, cap), params window test 1 pass, kaspa-pow 5 pass (stub) and 6 pass with --features igneum-pow (engine smoke, one 256 MiB cache, 0.39 s), kaspa-consensus coinbase 8 pass. Per-second subsidy, 8 decimals: 3,168,808,781 units (31.68808781 coins) for years 0 to 2, 1,584,404,390 for years 2 to 4, 792,202,195 for years 4 to 6, 1 unit in period 31, 0 from period 32; ramp day 0 is 316,880,878; the sum is under the 4,000,000,000-coin cap by less than 100 coins. Not done: the devnet ran on the kHeavyHash stub, not the lottery engine (the miner has no igneum-pow path yet and the lane hash does not absorb the header); no VDF seed, no finality, no prover payout; 8 versus 18 decimals open (docs/fork-divergence.md).

-

3 October 2026, first devnet blocks on the real lottery hash: CPU, then Metal GPU, three worker implementations (consensus-engineer)

+
+

3 October 2026, first devnet blocks on the real lottery hash: CPU, then Metal GPU, three worker implementations (consensus-engineer)

Machine: Apple M5 Max (18 logical cores, 40 GPU cores), rustc 1.99.0, Swift 5.8.1, fork vendor/igneum-node at "PoW: header-bound lottery engine, real-hash miner modes, genesis bits 0x1e400000" plus the overnight genesis commit; igneum-pow at "igneum-pow: header binding ...". Release builds with --features igneum-pow. Binding (spec 01 section 1.6, O-1.9, igneum-pow/src/bind.rs): I = seed_words_from_bytes("igneum-block/" || H || nonce_hi_le32), lane nonce = low 32 bits of the 64-bit header nonce, H = header hash with the nonce zeroed and the timestamp kept, pow256 = lane hash in the top 64 bits with zero low bits (pow <= target is exactly lane <= target >> 192). Interim day seed "igneum-day/" || day_le64 (day = timestamp_ms / 86,400,000); epoch seed = the 32 bytes of the epoch block hash (genesis for epoch 0). 8 bound vectors in igneum-pow/README.md; 29 crate tests pass; the 288 pack vectors and the pack files are unchanged, program_bound.metal, kernel_bound.cu and kernel_bound.cl are new pack files. CPU rate on the real hash: 0.44 ms per 32-lane warp on one core (crate bench); 0.142 MH/s with one 6-thread miner (1.35 ms per warp per thread); 0.294 MH/s with three 6-thread miners at once (2.0 ms per warp per thread, memory-latency bound), 0.37 MH/s later in the run. Genesis bits for the CPU devnet: 0x1e400000 = 2^18 expected hashes per block. CPU devnet, 3 nodes (node 1 RPC and p2p on 0.0.0.0, ports 26610/26611, 26620/26621, 26630/26631), three 6-thread igneum-miner mine --engine igneum-pow, 660 s: found 252 + 309 + 272 = 833 blocks, 0 rejected; watch window 641 s: 825 blocks on all three nodes = 1.29 blocks/s; sink identical on all nodes at 61 of 64 samples (tips 1 or 2, twice 3). DAA: 1.43 blocks/s over the first 600 blocks at difficulty 131,072, then difficulty 184,000 to 187,000 (1.41x) and 1.03 blocks/s over blocks 610 to 816. Each node logged "PoW accepted <hash> by igneum-lottery-v1-bound" 833 times, 0 rejections during the run. igneum-miner bad-nonce: Reject(BlockInvalid) and a "PoW rejected ... by igneum-lottery-v1-bound" line. inspect 30: vote_key_hash identical on all 3 nodes for 30 of 30, 80/20 exact on 19 of 19 single-payee coinbases. Epoch 0 seed = devnet genesis hash 03115da0...d86b, day 20729, program 104 loads/hash. Metal GPU worker (proto-metal/igneum-bench --serve, runtime-compiled igneum_hash_bound, init words in buffer 3, 2^22 nonces per dispatch, CPU-side scan of the 64-bit outputs) driven by igneum-miner --worker on node 1 of the same devnet, 300 s: 506 jobs of 2^24 nonces, 5,636 blocks found and accepted, 0 rejected, 0 CPU/GPU mismatches (every found nonce is re-hashed on the CPU before submit); nodes 833 -> 5,073 blocks on all three (14.57 blocks/s over the 291 s watch window), sink identical at 28 of 29 samples; difficulty 180,562 -> 7,134,312 (39x) and still rising at the end. Epoch change crossed live at DAA 3,600: new seed 76c39fcf..., 128-load program compiled by the worker in 129 ms (first program 6.5 ms), no rejected blocks across the change. Rate through the worker: 32.4 MH/s inside jobs, 28.2 MH/s wall, against 45.2 MH/s raw bench (igneum-bench 2^22 x 4 batches): the gap is the read-back and CPU scan per dispatch, one command buffer per dispatch, and the template round trip per job. Early in the run one job found about 45 sibling blocks of one template; the miner now submits one block per job. Overnight devnet (started 19:07 UTC): genesis bits 0x1d100000 = 2^28 expected hashes per block, sized for RTX 5090 229 + M5 Max 45 + gfx1036 4 = 278 MH/s (1.04 blocks/s); genesis hash edc4fa84...fb07; epoch 0 program 136 loads/hash compiled in 69.5 ms on Metal; node 1 alone (<listen address>/26611, caffeinate -dims, logs /tmp/igneum-devnet/node1.log) with the Metal worker (/tmp/igneum-devnet/metal-worker.log): 31 blocks in 273 s = 0.11 blocks/s at 31.1 MH/s, as expected for 2^28 until the RTX 5090 machine joins. Worker implementations, all bit-exact with igneum-pow hash-bound for a 96-nonce job across the 2^32 lane boundary (nonces 4294967264 to 4294967359, prehash ab x 32, devnet seeds): Metal (M5 Max GPU), OpenCL (proto-opencl/host.c --serve, Apple OpenCL 1.2 on the M5 Max, local-memory exchange, --vendor device filter added), CUDA (proto-cuda/host.cu --serve with the pack's kernel_bound.cu, through the clang emulation shim: bench PASS on the Rust-exported devnet pack, serve job bit-exact, seed-mismatch error exercised). CUDA and OpenCL are built ahead of time per pack; the Windows launcher re-exports and rebuilds at each epoch or day change (miner exit 42). igneum-miner.exe cross-compiled for x86_64-pc-windows-gnu with Homebrew mingw-w64 (9.4 MB; no rocksdb in the miner's closure). Not done: no NVIDIA or AMD run of the bound kernels yet (the Windows package igneum-mine-test.zip is the next step); NVRTC and runtime OpenCL rebuilds inside the workers; the block level for pruning proofs on a lane-only pow value; 8 vs 18 decimals; the VDF seeds and finality.

-

3 October 2026, Windows node package: igneumd cross-compiled for x86_64-pc-windows-gnu, two-peer sync test (consensus-engineer)

+
+

3 October 2026, Windows node package: igneumd cross-compiled for x86_64-pc-windows-gnu, two-peer sync test (consensus-engineer)

Machine: Apple M5 Max, load average 60 to 110 (three other agents building), rustc 1.99.0, Homebrew mingw-w64 (gcc 16.2.0), Homebrew llvm (libclang). Worktree vendor/igneum-node-win, branch windows-node at 352495f6 (the rename commit d62708a8 plus one miner change: watch prints blue= and synced= after sink=). Cross-compile: cargo build --release -j 6 -p kaspad -p igneum-miner --features igneum-pow --target x86_64-pc-windows-gnu at nice -n 19, 8 min 25 s from a clean target directory (recipe in proto-cuda/windows-node/cross-build.sh). librocksdb-sys (bindgen plus the bundled rocksdb and snappy C++) built with LIBCLANG_PATH=/opt/homebrew/opt/llvm/lib, BINDGEN_EXTRA_CLANG_ARGS_x86_64_pc_windows_gnu="--target=x86_64-w64-mingw32 --sysroot=<mingw sysroot> -I<mingw include>" and CXX_x86_64_pc_windows_gnu=x86_64-w64-mingw32-g++; zstd, lz4, bzip2, zlib, secp256k1 and mimalloc built with the mingw gcc. igneumd.exe 43,172,352 bytes, igneum-miner.exe 9,391,104 bytes. The exe imports libstdc++-6.dll: -static-libstdc++ is ignored by the gcc driver rustc links with, and -C link-arg=-static (second full build, 8 min) does not cover a library rustc passes as -Bdynamic; the package ships libstdc++-6.dll, libgcc_s_seh-1.dll and libwinpthread-1.dll next to the exe (fix for next time: empty CXXSTDLIB_x86_64_pc_windows_gnu plus -Wl,-Bstatic -lstdc++). Not run on Windows yet. Sync test (native build of the same worktree, 20:44 to 20:46 UTC, live node on 26610/26611 untouched): node A on 27000/27001 with START-NODE.bat's flags (--addpeer=<lan-ip>:26611 --listen=<listen address> --nodnsseed --disable-upnp --nologfiles) connected and started IBD within 20 ms, had 5,144 headers and 1,386 blocks at 7 s, and from 17 s on matched the live node's block count, DAA score, blue score and sink at every 10-s sample over 60 s (5,157 to 5,175 blocks, sink identical 5 of 6 samples, synced=true); every header checked by igneum-lottery-v1-bound. Live node peers 1 -> 2 -> 1. Node B on 27010/27011 dialled A's listener, synced to the same sink within 25 s and learnt the live node from A (outbound 2): a node with --addpeer plus --listen accepts inbound connections (--connect would set the inbound limit to 0, kaspad/src/daemon.rs). SIGINT stopped both cleanly. Package: igneum-node-windows.zip from proto-cuda/windows-node/make-package.sh (exe, miner exe, src.zip snapshot of the worktree HEAD plus igneum-pow/, scripts, README). Build on the RTX 5090 machine (BUILD-NODE.bat) estimated at 15 to 25 minutes on the 9800X3D, approximate, untested.

-

3 October 2026, R3.26 / M15: PoW checked after the cheap checks, cache-build cap, attack before and after (consensus-engineer)

+
+

3 October 2026, R3.26 / M15: PoW checked after the cheap checks, cache-build cap, attack before and after (consensus-engineer)

Machine: Apple M5 Max (18 logical cores), load average 60 to 110 (three other agents building at the same time), rustc 1.99.0. Worktree vendor/igneum-node-r3, branch r3-fixes at 5166ee26 on top of the rename commit d62708a8. Release builds; the real engine needs --features igneum-pow. Fix: validate_header now runs version, timestamp-not-in-future, parent, vote-key, parents-exist, GHOSTDAG, pruning, DAA-score, difficulty, blue-score, blue-work and past-median checks before the PoW engine; the engine (the one 256 MiB cache per day seed) is the last check that chooses seeds. The engine is process-wide, holds KEEP = 4 (epoch seed, day) caches, keeps the chain's current and next day resident, runs at most one build per seed pair and at most 2 at once with a queue of 4 (then PowCacheQueueFull, retryable, not a peer fault). A per-peer p2p guard counts an off-day cold build or a rejected-before-PoW header as a strike; more than IGNEUM_POW_STRIKES (default 2) in an hour disconnects the peer and bans its IP for an hour. Cache build time: one 256 MiB ChaCha12 program-plus-cache build in 222 ms on one core under this load (the engine smoke test on an idle machine earlier the same day measured about 0.2 s; proto-metal reported 273.6 ms for the CPU reference fill under the same load). The honest 20-to-60 s proving lag and the 10 ms CPU verify gate are unaffected. Attack, before and after (ignored test measure_m15_attack_before_and_after, release, --features igneum-pow, validate_and_insert_block, the path submit_block and block relay call into): an honest 10-block chain builds 1 cache (genesis epoch, genesis day). Then 50 headers with bogus timestamps (50 distinct past days) and bogus DAA scores.

  • Before (the pre-fix order, replayed by calling the engine with the header's own unvalidated day seed): 50 cold 256 MiB builds, 10,595 ms, and the honest day's entry is evicted (KEEP was 3).
  • After (the new order): 0 builds, all 50 rejected (TimeTooOld or UnexpectedHeaderDaaScore) in 14 ms total. The live day stays resident.

Tests: kaspa-pow --features igneum-pow 8 pass (engine smoke, one_build_per_seed_pair_under_contention, live_days_survive_off_day_builds, build_queue_is_bounded, index and live-day helpers, shared-engine, stub); kaspa-consensus header_processor cheap_checks_run_before_the_pow_engine pass; kaspa-p2p-flows pow_guard 2 pass; the full kaspa-consensus release suite otherwise unchanged. M16 Metal note (R3.5, cheap reconfirmation only): the Apple M5 Max --inline-dataset shortcut at the 256 MiB cache, 256 MiB dataset, under the same heavy load, ran honest 91.7 Mhash/s against inline 5.29 Mhash/s (inline about 17x slower); this is noisier and slower than the idle-machine figures already in proto-metal/MEMHARD.md (10x slower at a 256 MiB dataset, 4.8x at 1 GiB), because the inline kernel is compute-bound and the machine was loaded. The 64 MiB on-die-SRAM emulation M16 wants (inline kernel with a 64 MiB cache, cacheLog2Words = 24 in proto-metal/main.swift) is the RTX 5090 run reserved for the maintainers' PC, as R3.5 states; it is not done here and the Apple M5 Max number above does not price a die. Not done: the real-engine daemon RPC run (honest blocks need GPU-mined pow, so the measurement used the equivalent validate path with skip_proof_of_work); the 64 MiB-cache inline kernel on the 5090; the chain-derived day seed by DAA score (spec 01 section 1.12, still the timestamp-day devnet rule); the VDF epoch seed and finality.

-

3 October 2026, difficulty controller: devnet record, simulator, Igneum dual-lane rule, 3-node CPU test network (consensus-engineer)

+
+

3 October 2026, difficulty controller: devnet record, simulator, Igneum dual-lane rule, 3-node CPU test network (consensus-engineer)

Machine: the same Apple M5 Max, shared with two other build agents (load average 60 to 98 during the Rust builds). Fork worktree vendor/igneum-node-diff, branch difficulty from d62708a8. Everything in docs/analysis/difficulty-2026-10-03.md; raw outputs in sim/difficulty/results.md. Record: 3,682 headers of the overnight devnet pulled read-only through the observer node's wRPC JSON (ws://127.0.0.1:28640, getBlocks from genesis) into sim/difficulty/devnet-2026-10-03.csv. Kaspa's sampled DAA held genesis difficulty 134,217,727 through block 600 at 0.6 blocks/s (PC, 116 MH/s estimated from the blocks), then eased 4.8x at the first retarget (DAA 600, 19:56:12 UTC) and on to 15.7x (8,552,118) because the 600-block window spanned the 21-minute Metal-only period and a 13-minute idle gap; 5.44 blocks/s over the next five minutes, 355 blocks in the peak minute, 1,633 blocks above 2x, then 1.5x too hard; the DAG widened to 3,681 blocks for 1,656 chain blocks. Exact replay of the record's bits through rusty-kaspa's integer arithmetic matches 244 of 244 retargets while the devnet was a chain and diverges from DAA 845 (merged blocks a chain-only replay cannot see). Simulator sim/difficulty/sim.py (Python, one chain, exponential solve times, 1 BPS): Kaspa sampled DAA, Monero 720, LWMA 60 and 120, the Igneum rule and the brief's literal trigger, on nine synthetic profiles plus the record. Two design findings: Zawy's average-target LWMA estimator is biased while targets ramp (the fast lane stalled at 15x of a 50x step), so every Igneum lane uses work over time (Kaspa's estimateNetworkHashesPerSecond estimator); the brief's trigger (short-window rate off target) chatters once the short window is back on target while the long window is still polluted (polluted case 1,876 s against 70 s), so the trigger compares the two lanes. Tuned on the synthetic set only: short window 120, hold 8, prior 16, long lane from 600 blocks of the epoch, trigger 25%, harden 3% per block, ease 10% per block, solvetime cap 20 T. Settled seconds (121-block mean within 10% for 100 blocks), Kaspa / Monero / LWMA60 / LWMA120 / Igneum: x50 step 1,542 / 94 / 105 / 231 / 62; /50 step 12,296 / 6,433 / 578 / 1,074 / 657 (worst gap 179 / 187 / 119 / 65 / 35 s); epoch +-30% steps 1,583 / 456 / 157 / 153 / 144; 10x hopping never / 284 (6 of 12 never) / 264 / 326 / 212; polluted window 2,748 (peak 7.9x) / 124 (peak 15x) / 66 / 110 / 70; genesis 10x too hard never / 287 / 155 / 188 / 322; steady std of rate 0.012 / 0.037 / 0.131 / 0.092 / 0.038; the record's 75x step never (peak 7.6x, 2,340 blocks above 2x) / 136 / 75 / 157 / 79. With +-500 ms timestamp jitter the ordering holds (Igneum x50 169 s, /50 1,047 s, epoch 55 s, polluted 71 s). Implementation: DifficultyRule { KaspaSampled, IgneumDual } as a network parameter (IgneumDual on all four networks, "difficulty_rule": "kaspa-sampled" in the override file selects Kaspa's), OverrideParams.genesis_bits (genesis hash recomputed) for test networks, SampledDifficultyManager::igneum_difficulty_bits over a selected-chain walk plus the in-epoch samples of the existing window, pure integer core igneum_target (Uint320). cargo test -p kaspa-consensus --lib difficulty: 9 pass (hold, steady state, 3% harden, 10% ease, trigger, epoch shrinkage, max target, Kaspa's two level-work tests); cargo test -p kaspa-consensus-core --lib params: 4 pass. The miner now takes the genesis from the node (pruning point before the first pruning) so it mines an override-genesis network; before the fix it hashed the compiled devnet genesis as the epoch seed and every block was rejected. Test network (ports 26800 to 26821, appdir /tmp/igneum-diff-test, override file with difficulty_rule and genesis_bits 0x1e200000): 3 igneumd nodes, 3 CPU miners of 4 threads (A for 1,200 s; B and C from 359 s to 779 s), 1,133 blocks, 0 rejected, one sink. Delivered hash rate 0.0653 / 0.0988 / 0.0686 MH/s (the join is x1.51, not 3x: shared cores at load 50 to 90). Genesis 4x too hard. Measured first within 10% of 1 block/s (61-block mean): warm-up 132 s, join 214 s (23 s to first touch), leave 85 s; simulator on the same profile, 5 seeds: medians 263 s, 61 s, 231 s; worst gap 7.3 s. Kaspa's rule on the same genesis: no retarget inside 20 minutes in any seed (600-block dead zone). Kaspa's rule live on the same genesis, 10 minutes: 70 blocks, bits unchanged on all 70, 0.08 blocks/s, worst gap 63 s, never within 10% of target. Not done: no DAG in the simulator (red blocks' work is ignored by every lane, as by Kaspa's estimator); Monero and LWMA reproduced from memory (approximate); real-time targeting left out; the chain walk (600 reads per header early in an epoch) must be re-measured before the 4 BPS step.

-

3 October 2026, igneum-node devnet v2: sustained-mining finality rule v2 on a four-miner test network, and as a follower of the live devnet (consensus-engineer and cryptographer)

+
+

3 October 2026, igneum-node devnet v2: sustained-mining finality rule v2 on a four-miner test network, and as a follower of the live devnet (consensus-engineer and cryptographer)

Machine: Apple M5 Max, rustc 1.99.0, fork vendor/igneum-node at commits "Finality: BLS12-381 vote keys ..." through "Miner: BLS identity ..." (four commits on top of the rename). Builds in target-finality (CARGO_TARGET_DIR=target-finality cargo build --release --features igneum-pow): igneumd 36 MB (66 MB with line tables for the stall hunt), igneum-miner 7.6 MB; Windows cross-builds with Homebrew mingw-w64 in target-finality/x86_64-pc-windows-gnu/release/: igneum-miner.exe 9.7 MB and igneumd.exe 44 MB (rocksdb compiled under mingw without trouble, 8 min 13 s). Unit tests: kaspa-consensus-core 71 pass (4 new: key derivation and proof of possession, vote sign/verify/aggregate, section codec with reveal, sortition threshold), kaspa-notify 131, kaspa-rpc-core 20, 0 failures. Rule as implemented: docs/spec/03-finality.md section 3.10 and docs/fork-divergence.md "Finality v2". Crypto: blst min-pubkey BLS12-381, votes over "igneum-vote-v1/" || chain_id || 0 || index || hash, sortition VRF = SHA-256 of the sortition signature, aggregate certificates with a bitmap over the canonical voter list. Devnet parameters: checkpoint every 30 blue score, determined at +20, weight window 7,200 DAA s, dust 5 blocks, presence 20 indices, 8 aggregators, ban 7,200 DAA s, quorum 2/3 of active and 17/30 of total. Test network (--devnet --devnet-suffix=7, network id igneum-devnet-7, genesis bits 0x1e400000 through --override-params-file, finality params as devnet): three igneumd nodes on gRPC 26650/26660/26670, p2p 26651/26661/26671, wRPC JSON 28650/28660/28670 (nodes 2 and 3 --addpeer node 1, node 3 also node 2), peers at protocol version 12; four 4-thread CPU igneum-miner mine --engine igneum-pow identities m1, m2 (node 1), m3 (node 2), m4 (node 3); 20:59:48 to 21:53 UTC. Block rate 0.25 blocks/s per miner (m1: 736 blocks in 3,000 s, 0.072 MH/s, 0 rejected), 2,193 blocks at 21:35 UTC; difficulty 149,037 at DAA 2,193. Key reveal: all four keys revealed from the first block of each identity (Finality: vote key revealed), hash matches the header on all three nodes. Weights at checkpoint 4 (DAA 119): 34 + 31 + 30 + 24 blocks, total 119, 4 voters, participation 1.0 (all keys younger than the presence window). Checkpoints and locks, steady state (indices 1 to 72, all four voting until the equivocation at 43, three after): 72 of 72 determined checkpoints locked on all three nodes; lock latency from determination to lock on node 1: median 0.80 s, p90 1.08 s, max 1.55 s (the vote round trip is bounded by the miners' 1-s poll); first lock 61 s after the first block (checkpoint 1 at blue score 31). Certificates built by the first node to see quorum: node 1 built 91, node 2 92, node 3 90 of 93, 0 conflicting certificates on any node; identical checkpoint hashes, states, signed and total weights on all three nodes at every RPC sample (getFinalityCheckpoints on 28650, 28660, 28670). Checkpoint 2 and 3 locked with 3 of 4 votes (74.6% and 73.0% of total) because the per-template vote carriage and the 1-s poll leave one vote outside the aggregator's first certificate; the lock still met both tests. Sortition: with 4 voters every voter is eligible (threshold = 1 when voters <= 8); aggregators lists the keys whose proof verified, 3 to 4 per checkpoint, and the certificate names the local eligible voter of the building node. Equivocation (m4 restarted with --equivocate at 22:19:41): at index 43 m4 submitted a vote for the checkpoint and one for the hash with its last bit flipped; node 3 answered the second with accepted=false equivocation=true, every node logged EQUIVOCATION by key 56da130c... at index 43 ... weight stripped until daa 8512, and from checkpoint 44 the key is voter false, stripped_until 8931 (the ban is re-stamped at each detection, m4 kept equivocating at every index), the voter list is 3, total weight excludes its 526 blocks, and locks continued at 3 of 3 votes (checkpoint 64: 938 of 953 active, 1,400 total). Evidence items were carried in blocks (evidence carriers) and re-detected by the follower path; 21 detections on node 3 in 10 minutes. Partition test (m4 stripped throughout, so the honest set is m1, m2, m3 with 33% of weight each): phase A, m3 stopped 22:31:07 to 22:35:10 (240 s): locks continued (72 at the end, signed 1,088 of 1,105 active and 1,563 total). Phase B, m2 also stopped 22:35:19 to 22:47:48 (749 s), m1 alone voting: 0 locks in 12 checkpoints (73 to 84); at the end m1's weight was 696 of 1,759 total (39.6%) and 696 of 962 active (72.3%), so the ACTIVE test passed as the two silent keys decayed out of the presence window and the 56.7% FLOOR alone held the lock back, which is the sim's 3.3.1 scenario on a real DAG. finality_active stayed true until the lock at 72 fell out of the 20-index window. Phase C, m2 and m3 restarted at 22:47:56: the returning miners signed every open index of the presence window, checkpoints 73 to 85 locked within 30 s (determined-to-locked 749 s for 73 down to 121 s for 84, 0 s for 85), 86 to 92 locked at the steady cadence (signed 1,784 of 1,784 at 86, 1,287 of 1,921 at 92, 3 voters). No conflicting certificate and no stall on any node through the heal. Observer and site: tools/observer/observer.mjs with LIVE_TABLE_PREFIX=fintest_ against 28650 wrote fintest_live_checkpoints (49 rows, 42 locked at the first sample) and checkpoint_locked events ("checkpoint 42 locked (76.2% of weight, 96.5% of active, 3 votes of 4 voters) at block 0d1405d0"), from both the FinalityLock subscription and the 2-s poll; live_state.finality carried the weights snapshot. site/api/live.mjs adds the live_checkpoints query and locked/final flags per block; site/live.html draws the locked-checkpoint ring, the dashed "final" line at the newest lock and the locked counter. Live devnet follower (igneumd v2 on gRPC 26690, p2p 26691, JSON 28690, --connect=127.0.0.1:26611, never mining): IBD of 5,254 blocks from node 1 in under a second, kept in sync (5,418 blocks at 21:53, 0.70 blocks/s on the live chain), determined checkpoints 1 to 302 within 1 s of IBD; weights at checkpoint 296 (DAA 8,935): 16 keys, 14 above dust, total 7,146 blocks (eight RTX 5090 identities at 862 to 936 blocks, six at 4 to 10), 0 revealed keys, 0 votes, participation 0, 0 locks, finality_active false, exactly as expected while the Windows miners run the pre-v2 binary. RSS 1.1 GB. It only ever receives from node 1 (its protocol version 12 against node 1's 11 means no finality messages in either direction). Open: one stall of all three test nodes at 20:48:43 UTC in the first run (stripped binary, right after the follower, the equivocating miner and the test observer started): all three logs stop in the same second, every RPC times out, CPU 0%, node 1 of the live devnet unaffected; not reproduced in 28 minutes of the same scenario on the symbolized build (lock 40 to 93 without a pause, including the equivocation and the partition). The first run's self-deadlock (compute_weights taking the state lock its callers hold) was found and fixed before that stall, and Router::enqueue is a non-blocking try_send, so the gossip pump cannot deadlock across nodes; cause unknown. Also open: C3 validity rule and F3 pruning bound not enforced; d = 20 chosen without the reorg-depth distribution; the weight walk is O(window) per checkpoint; one certificate per index per node means a certificate often names fewer signers than the votes that exist. Not demonstrated: locks on the live devnet (its miners do not vote yet), the Windows binaries on Windows, a certificate carried into a block and verified by a cold node that missed the gossip (the follower had no votes to receive), the 2-hour presence window at full length (the run was 53 minutes).

-

3 October 2026, execution layer devnet v3: revm over the selected chain, 3-node simnet, viem smoke test (execution-engineer)

+
+

3 October 2026, execution layer devnet v3: revm over the selected chain, 3-node simnet, viem smoke test (execution-engineer)

Machine: the same Apple M5 Max (18 cores), shared with two other agents' builds (load 15 to 55). Branch execution-layer in vendor/igneum-node-exec, worktree of vendor/igneum-node from d62708a8; revm 43.0.3, alloy-primitives 1.7.3, alloy-consensus 2.5.0, alloy-trie 0.9.8, axum 0.8.9; viem 2.57.2, solc 0.8.37 (tools/evm-smoke). Release build CARGO_TARGET_DIR=target cargo build --release -p kaspad -p igneum-miner --features igneum-pow: first full build with the new crates about 20 min under nice -n 10 -j 10 on the loaded machine; incremental igneumd rebuilds 35 s to 4 min. Test network: 3 igneumd --simnet nodes (devnet block rate and depths, proof of work skipped, chain id 4463) on gRPC 26700/26710/26720, p2p 26701/26711/26721, eth RPC 26790/26791/26792, appdirs /tmp/igneum-exec-test; 3 single-thread igneum-miner --engine stub --hold-ms 2500 (exponential hold, mean 2.5 s per miner). Rate: 130 blocks in 120 s = 1.08 blocks/s; 68 chain blocks; selected-chain reorgs 22 in 120 s, depth 1 (17) and 2 (5), identical on the 3 nodes. Earlier run with a fixed 900 ms hold: 3 blocks/s in lockstep rounds and 80 to 92 reorgs in 60 s with flips 45 to 69 deep (equal-work chains kept alive by the hash tie-break); every flip was unwound correctly (state roots identical on 3 nodes at block 32 after 65-deep flips), the fix is Poisson pacing in the miner. Smoke test (node tools/evm-smoke/smoke.mjs, stock viem paths): 87 checks passed, 0 failed, 36 s wall, tip at chain block 78. eth_chainId 0x116f, net_version 4463. Miner 1 (EVM address = low 20 bytes of its vote key hash) held 91.28 IGN at chain block 53 from 80% subsidy shares of 36.59 IGN per blue block (3,168,808,781 sompi x 1e10 x 0.8, launch-ramp day 0 is not applied on simnet's genesis timestamp); proving pool escrow 92.55 IGN at the end. Funding: 3 transfers of 5 IGN, eth_estimateGas 25,380 (21,000 plus the pgas fold and the 15% margin), all status 1, balances exact. 50 transfers between 3 accounts (each sender's transactions to one node, no p2p relay of EVM transactions): all 50 executed in 16 s wall across chain blocks 58 (17), 61 (20), 62 (13); 57 executed transactions in 7 chain blocks over the run, max 20 per chain block; 19 skipped copies (the same miner re-including transactions handed out before its earlier template landed, every one skipped by the nonce rule with no fee and no receipt). Balances of the 3 accounts matched the receipt accounting to the wei (value plus gas_used x effectiveGasPrice plus burnedProvingFee). Transfer receipt: gasUsed 21,000, pgasUsed 200, effectiveGasPrice 2 gwei (base 1 gwei, tip 1 gwei), burnedProvingFee 200 gwei (200 pgas x 1 gwei), minerTip 16,800 gwei (80% of 21,000 gwei), developerShares [burned 4,200 gwei] (unregistered, 20%). Contract call increment(5): gasUsed 45,354, pgasUsed 1,288, minerTip 36,283.2 gwei (80%), developer share 9,070.8 gwei (20%) credited to the payee the constructor registered (balance delta equal). Deployment via viem deployContract: gasUsed 185,948, pgasUsed 1,438, registry creatorOf = deployer and payeeOf = constructor argument (executor CREATE rule plus register). eth_estimateGas reports the revert of increment(0); eth_call hashLoop(50) returns; eth_estimateGas hashLoop(200) = 98,900 with the fold; eth_getLogs finds the event. Measured pgas/gas: 0.0095 transfer, 0.028 storage write with event, 0.0077 deployment, 0.0099 averaged (prototype table, below the design's 0.1 to 10 band as expected before calibration). Duplicates in parallel blocks: one identical copy sent to nodes 1 and 2 was included twice (chain blocks 63 and 64, blocks c09c9329... and 3f401bd2...), executed once, the second skipped NonceTooLow { expected: 18, got: 17 }; a conflicting same-nonce pair (different values, one copy per node) executed exactly once (B1), the loser never reached a block because its node's pool dropped it once the nonce had passed (igneum_getTransactionStatus: includedIn [], executed false). Execution time per chain block (node 1, igneum.executionMicros, includes the full-recompute state root): 50, 71, 93, 57, 41, 46, 50 us for the 7 chain blocks with 3, 17, 20, 13, 2, 1, 1 transactions; 71 empty chain blocks averaged 11 us; the same chain block on the 3 nodes: 50 / 192 / 85 us (block 56) and 50 / 88 / 46 us (block 78). State roots as outputs: genesis (registry only) 7e37a9fb19b154d32daf5bf30a50d339a75029fbc9eec9ea20e95439dba5a311; chain block 56 (3 funding transfers) 68cacfd393b00ead784a69b10d57a3e2dd57858029df107b529487a49f393b50; chain block 78 5b18b3a58f6c1d21b22caad4a1dbd9ee8a6394a02db2220255e556a9d4f90878; identical hash and root on all 3 nodes at heights 0, 56, 74 and 78; the root advanced at every block with transactions. Base fees stayed at the 1 gwei floor (segments far below the 15 M gas target). Differential (igneum-exec-diff seq.json, plain revm without inspector, pgas or split, balances adjusted by the exported Igneum-only flows): segments 0 to 78, 57 executed transactions compared (status, gas used, logs), 19 skipped copies confirmed rejected by plain revm at their positions, 10 accounts compared (balance, nonce, code hash), 0 mismatches. cargo test -p igneum-evm-types: 3 passed. Not done: on-disk state and incremental trie (state rebuilt from genesis at start), header fields utxo_commitment and accepted_id_merkle_root kept (proofs_root is an RPC placeholder), body miner field and proofs section, pgas calibration, proving layer, eager virtual execution, eth_getProof/subscribe/debug, EVM transaction relay between nodes, the finality merge (plan in the design document, section 10.4). Test network stopped at the end of the run.

-

2026-10-03, consensus attack harness (consensus-engineer), catalogue run on the ordering-layer node

+
+

2026-10-03, consensus attack harness (consensus-engineer), catalogue run on the ordering-layer node

Machine: Apple M5 Max, 64 GB, load 61.19 55.26 50.53. Private test network of igneumd (release, skip_proof_of_work devnet) on 127.0.0.1 ports 27200+, data /tmp/igneum-harness; the live devnet and the RTX 5090 node were not touched. Harness: tools/harness/, node fork worktree vendor/igneum-node-harness.

ScenarioCriterion (spec)MeasuredPass
5 malformed and boundary inputs on every p2p message and RPC method the fork touchesrejected without a crash or a cache build (spec 02 2.4; fork-divergence header and RPC rows; ledger M15)63 cases (46 RPC, 17 p2p): node stayed up on every case; all malformed inputs rejected or disconnected. 5 cases (rpc:timestamp-zero, rpc:timestamp-past-3-days, rpc:daa-score-bogus, p2p:ts-past-day, p2p:daa-bogus) built a 256 MiB cache = ledger M15 reproduced on HEAD d62708a8, which the r3-fixes branch drives to 0 (bench-log M15 entry). Other unexpected cache builds: 0. Over-length vote_key_hash (vkh-33-bytes) and an unknown JSON field were normalized and accepted rather than rejected (minor, no safety impact).pass
2 timestamp boundaries (live)rejected at ts <= past median, accepted at pmt+1; accepted below now+132 s, rejected above (spec 02 section 2.3)past: pmt-1=rejected, pmt=rejected, pmt+1=accepted, pmt+2=accepted; future flip between +132.00 s and +132.01 spass
2 timestamp stretch drift (sim)controller response to a 33% miner stretching timestamps inside the rules is measured (blocks per second drift against an honest run)honest 0.9952 b/s (difficulty x1.016); ahead 131 s: 1.0222 b/s (+2.7%, x0.96); oscillate: 1.0422 b/s (+4.7%, x0.923); over 6000 virtual spass
1 withhold a=0.1 release every 5attacker blue share <= 0.1 + 2 sigma (0.014) over 1927 bluesblue share 5.4% (104 blue, 81 red of 186 made); honest reorgs depth:count 1:2 2:5 3:2 4:2 5:2 8:2, max 8pass
1 withhold a=0.1 release every 20attacker blue share <= 0.1 + 2 sigma (0.014) over 1858 bluesblue share 1.2% (23 blue, 157 red of 186 made); honest reorgs depth:count 1:1 2:1 5:1, max 5pass
1 withhold a=0.25 release every 5attacker blue share <= 0.25 + 2 sigma (0.020) over 1942 bluesblue share 22.0% (428 blue, 42 red of 474 made); honest reorgs depth:count 1:11 2:11 3:6 4:17 5:6 6:9 7:5 8:6 9:2 10:1, max 10pass
1 withhold a=0.25 release every 20attacker blue share <= 0.25 + 2 sigma (0.021) over 1693 bluesblue share 12.6% (214 blue, 266 red of 489 made); honest reorgs depth:count 1:3 3:3 4:1 5:1 6:1 7:1 8:2 11:2 13:1 14:2 16:1 25:1 30:1, max 30pass
1 withhold a=0.33 release every 5attacker blue share <= 0.33 + 2 sigma (0.021) over 2039 bluesblue share 31.5% (643 blue, 17 red of 663 made); honest reorgs depth:count 1:15 2:18 3:21 4:21 5:15 6:14 7:10 8:5 12:1 13:1, max 13pass
1 withhold a=0.33 release every 20attacker blue share <= 0.33 + 2 sigma (0.024) over 1561 bluesblue share 27.4% (428 blue, 212 red of 640 made); honest reorgs depth:count 2:2 3:1 4:1 5:1 6:1 7:1 8:2 12:1 13:1 15:1 19:1 22:1 23:3 25:2 26:1 28:2 29:1 32:2 33:1, max 33pass
1 withhold a=0.45 release every 5attacker blue share <= 0.45 + 2 sigma (0.022) over 2002 bluesblue share 44.2% (885 blue, 0 red of 886 made); honest reorgs depth:count 1:24 2:27 3:23 4:29 5:22 6:16 7:7 8:8 9:2 13:2 14:1 15:1, max 15pass
1 withhold a=0.45 release every 20attacker blue share <= 0.45 + 2 sigma (0.024) over 1657 bluesblue share 50.7% (840 blue, 40 red of 886 made); honest reorgs depth:count 3:1 8:2 9:1 11:3 12:1 13:1 15:1 16:5 17:2 18:2 19:3 20:3 21:1 22:4 23:3 25:3 26:2 28:1 29:1 31:1 32:2 36:1, max 36FAIL
3 partition 120 sone chain after the merge-depth rule; reorg depth and time to heal recordedone chain: true (blue scores within 3 at the end); healed in 10 s; losing-side reorg at heal 41 chain blocks (per node 41/41/0/2); rejects nonepass
3 partition 600 sone chain after the merge-depth rule; reorg depth and time to heal recordedone chain: true (blue scores within 4 at the end); healed in 10 s; losing-side reorg at heal 234 chain blocks (per node 0/0/233/234); rejects nonepass
3 partition 1800 sone chain after the merge-depth rule; reorg depth and time to heal recordedone chain: true (blue scores within 4 at the end); healed in 10 s; losing-side reorg at heal 920 chain blocks (per node 0/0/920/920); rejects nonepass
3 partition 3700 s (beyond merge depth)one chain after the merge-depth rule; reorg depth and time to heal recordedone chain: true (blue scores within 4 at the end); healed in 10 s; losing-side reorg at heal 2160 chain blocks (per node 0/5/2160/2159); rejects MissingParents:1; MissingParents:1; MissingParents:5; MissingParents:5pass
6 resource exhaustion (50x template, submit and mempool floods from one peer)honest template p95 < 200 ms and both nodes under baseline RSS + 512 MB, alive, one sinkhonest template p95 worst 3.7 ms across loads (baseline 33.2 ms); template 500ps 500/s, submit 50ps 50/s, mempool 500ps 500/s; RSS growth template +4MB, submit +11MB, mempool +14MB; alive true; same sink truepass
4 eclipse 600 svictim rejoins the honest chain on reconnection within the merge-depth bound; reorg depth recordedvictim rejoined 10 s after reconnection (blue-score gap to honest 3 at the end); victim reorg depth 149 chain blocks; adversary built 242 blocks that never entered the honest chainpass
4 eclipse 1800 svictim rejoins the honest chain on reconnection within the merge-depth bound; reorg depth recordedvictim rejoined 10 s after reconnection (blue-score gap to honest 0 at the end); victim reorg depth 447 chain blocks; adversary built 497 blocks that never entered the honest chainpass
7 fast-miner flood, controller trajectory (sim, Kaspa sampled DAA on HEAD)trajectory recorded for the difficulty branch (bits, blocks per second, settle times)50x joins at 600 s: peak 25.27 blocks/s, difficulty x28.4, within 25% of 1 BPS after never s; leaves at 1200 s: trough 0 blocks/s, back within 25% after never spass
7 fast-miner flood, live (50 blocks/s from one peer)node stays responsive: honest template p95 < 200 ms, both nodes alive, same sinkflood accepted 721 blocks in 60 s (12.0/s); honest template p50/p95/max 0.4/0.8/1.3 ms under flood (baseline 0.4/0.8/1.2); rss a 303->333 MB, b 305->332 MB; alive true; same sink truepass
1b withhold vs finality weight (finality branch)spec 03: a withholder gains no vote weight beyond its hash share; under the 56.7% total floor, 0 conflicting locks (the design document, ledger F18)stub: run s1 withhold against a node built with the finality-v2 branch, with miner --vote keys, and read getFinalityWeights and getFinalityCheckpoints; assert blue-weight share within noise and no conflicting lock. Needs the finality branch merged into the harness worktree.stub
3b partition vs finality lock (finality branch)spec 03.5 and ledger F16: after a partition heals, no certified lock is revoked (an exchange relies on "locked" being final); the F16 decision (Kaspa halt vs re-evaluate) is exercisedstub: run s3 partition with voting miners on both sides; record every FinalityLock notification and assert no locked checkpoint changes hash after the heal. Needs the finality branch.stub
4b eclipse vs finality presence window (finality branch)spec 03.3 F2 and ledger F2: a 2-hour presence window does not let an eclipsed victim be fed a locked side chain; the victim rejoins without accepting a revoked lockstub: run s4 eclipse with voting miners; assert the victim never reports a lock on the adversary chain that the honest chain does not also certify. Needs the finality branch.stub
2b difficulty controller under timestamp stretch (difficulty branch)docs/analysis/difficulty-2026-10-03.md: the igneum-dual rule holds the block rate under a timestamp-stretching miner better than Kaspa sampled DAA; forged timestamps move a lane by at most a few percent (spec 02 section 2.3)stub: run s2 Part B with {"difficulty_rule":"igneum-dual"} in the override file against the difficulty branch, compare the drift to the kaspa-sampled baseline this branch measured. Needs the difficulty branch (vendor/igneum-node-diff) merged into the harness worktree.stub
7b fast-miner flood on the dual-lane controller (difficulty branch)docs/analysis/difficulty-2026-10-03.md: on the igneum-dual rule the 50x step settles within about 62 s and the step-down within about 11 minutes, against Kaspa sampled DAA never settling (the record of the devnet event)stub: run s7 Part A with the difficulty branch and {"difficulty_rule":"igneum-dual"}, compare the trajectory to the kaspa-sampled baseline this harness records. Needs the difficulty branch.stub

Full JSON per scenario under /tmp/igneum-harness/results and /tmp/igneum-harness/sim. The simulator (igneum/harness-sim in the fork worktree) runs real consensus code in virtual time with PoW skipped, as rusty-kaspa simpa does; the live scenarios (5, 6, 7 Part B) drive real igneumd processes over wRPC and the fork's own p2p (igneum/p2p-probe).

Finality and difficulty-controller scenarios are stubs here: their criteria are written and they run against those branches once merged into the harness worktree (see tools/harness/scenarios/stubs.mjs).

-

3 October 2026, weak-program census: 400,000 program runs through the CPU reference, the redundant-load finding, and the rules for M5 and M6 (cryptographer)

+
+

3 October 2026, weak-program census: 400,000 program runs through the CPU reference, the redundant-load finding, and the rules for M5 and M6 (cryptographer)

Machine: Apple M5 Max, 8 threads at nice -n 15 while a devnet build and its simulations shared the box (load average 25 to 107), rustc 1.99.0, release build with LTO. New crate igneum-census/ (path dependency on igneum-pow, nothing in igneum-pow changed); the instrumented interpreter is checked against igneum_pow::hash_warp on the first warp of every program and against the igneum-genesis spec vectors at start. Commands: igneum-census run --root igneum-census-2026-10-03 --count 100000 --warps 128 --threads 8 --gen default (memory-hard, 1 GiB, day 2026-10-03; 2,797 s), the same with --gen fixed16-fresh --warps 64 (1,049 s), --gen fixed16-fresh2 --warps 64 (6,650 s, starved to under a core for most of it), and --gen default --closed-form --warps 128 (125.6 s once the machine was quiet); summarise, probe, show. Full tables and the rules in docs/analysis/weak-program-census-2026-10-03.md. Current generator, 100,000 programs x 4,096 nonces: loads per hash 24 to 256 (mean 127.9); distinct addresses per hash 24 to 200 (mean 102.4): 19.9 percent of all loads re-read an address the same hash already read, 94.8 percent of programs have at least one such load, 22.5 percent have a pair that cancels to the identity. The Mac rates of the eight bench seeds vary 1.38x by static loads/s and 1.10x by distinct loads/s (3.51 to 3.85 G/s), so the GPU is bound by the distinct count; igneum-second-seed/epoch1 (144 static, 104 distinct) hashes at the rate of igneum-second-seed (104 and 104). Weak programs, current generator: 2.43 percent have a register with no injecting write (saturates to all ones); 0.73 percent have a register with a nonce-independent bit, 0.03 percent a whole nonce-independent register, 0.03 percent a load site read at one address by all 32 lanes, 0.68 percent more than 1 percent of final registers at 0 or all ones, 6 programs an output bit past 6 sigma (0.03 expected by chance). Avalanche clean on every program (mean 31.85 to 32.15, every output bit flips 0.473 to 0.523). Mechanisms: no injecting write; zero-absorbing register sets closed under mulhi/mul; or or mul as the last write. Rules: G1 exactly 16 load slots drawn first from slots 1..63; G2 a load reads only a register written earlier in the program and not read by a load since; R-a no cyclically redundant load; R-b every register has an injecting write; R-c 64 fixed warps on the seed-keyed closed-form dataset with no constant register bit, no lane-constant site, saturation under 1 percent, no output bit past 6 sigma, more than 120 distinct addresses per hash on average. Rejection: 95.0 percent under the current generator (the redundancy alone), 38.3 percent under the first form of G2 (the iteration wrap), 5.14 percent under the proposed form (R-a or R-b 3.93 percent, R-c 2.05 percent), so 1.054 candidates per epoch on average; the accepted population does 120.05 to 128 distinct loads per hash, median 128.00. Closed-form check: with the same seeds and nonces on the closed-form dataset instead of the memory-hard one, R-c agrees on 99,961 of the 100,000 proposed-generator programs (2,054 rejected memory-hard, 2,055 closed-form; the 39 that differ sit at a threshold edge, one nearly constant bit or a bias near 6 sigma) and the per-program metrics agree to three decimals, so the acceptance test can be a pure function of the program. Hash-rate spread: today 2.7x between the 1st and 99th percentile program by distinct loads (56 to 152 per hash; 321 to 118 Mhash/s projected on the RTX 5090 at 18.0 G distinct loads/s), 8.3x min to max; under G1 + G2 every program does 128 distinct loads, projected 141 Mhash/s on the 5090 and 28 on the M5 Max, with the 1.10x program-shape residual the only spread left, approximate. One 5090 run of igneum-second-seed (predicted 173 Mhash/s if distinct-bound, 228 if static-bound) settles the reading on NVIDIA. Not done: no GPU run of the new generator; the spec text is proposed in the analysis doc, section 9, not written into docs/spec/01-lottery-hash.md; test vectors are re-cut when the generator rule is adopted.

-

3 October 2026, proving v0: first SP1 proof of an Igneum block, Apple M5 Max CPU, loaded machine (execution-engineer, proving)

+
+

3 October 2026, proving v0: first SP1 proof of an Igneum block, Apple M5 Max CPU, loaded machine (execution-engineer, proving)

Machine: Apple M5 Max (18 cores, 64 GB), macOS Darwin 25.6.0, load average 14 to 45 during the runs (the live devnet, the observer and other agents' builds were running), everything under nice -n 19. Toolchain: SP1 v6.8.1 (sp1up, cargo-prove c84ada1 of 24 Sep 2026, succinct rustc 1.96.0-dev, circuit version v6.1.0), sp1-sdk 6.8.1 CPU prover, revm 43.0.3, alloy-primitives 1.7.3 with SP1's sha3 patch and k256 patch. Code: proving/igneum-prove (guest ELF 2.69 MB, host 54 MB), fixtures cut from tools/evm-smoke/seq.json (the 3-node simnet export, execution-layer commit fb33069) by igneum-prove-export, which replayed all 79 segments from genesis through the ported executor and matched every one of the node's state roots (final root 0x5b18b3a5...). Statement: re-execute one chain block (rewards by rule, nonce-rule skip, two-dimensional gas with the prototype pgas table, fee flows with the developer split, state root over the whole in-memory state) and commit the pre-root, post-root, receipts root, gas, pgas and the executed and skipped counts; the host checks the guest's public values against its own native run before and after each proof.

FixtureTxs (executed / skipped)EVM gaspgasPre-state accountsSP1 cyclesProver gasCycles per EVM gasExecute s
block-78-increment (Counter increment(5) plus a duplicate copy skipped by the nonce rule)2 (1 / 1)45,3541,48810626,246843,343140.03
block-56-transfers (three funding transfers)3 (3 / 0)63,0006005549,469733,29790.03
block-78-increment, CPU proverProve sProof bytesVerify sVerified
Setup (pk, vk; vk hash 0x00c3a917...)6.9
Core (STARK shards)22.07,317,2170.164yes
Compressed (recursion, one shard)55.71,272,7690.033yes

Reading: at 626 k cycles the block is far below one SP1 shard, so these times are fixed overhead (proof system setup and the recursion stack), not throughput; cycles per EVM gas (9 to 14) is the first data point for the pgas table calibration (R1) and is dominated by the state-root computation over every account plus one secp256k1 recovery per transaction (through the patched k256). Nothing here is a 12 GB-card shard time (ledger P1); that is the RTX 5090 run of proving/windows-wsl2/ and then the 3060-class gate. The devnet was not touched. Not done: the Groth16 or Plonk wrapper (ledger P3), MPT witnesses, more than one shard per block, chain recursion, the prover key in the statement (P12).

-

2026-10-03 execution layer attack suite: malformed txs, nonce games, RPC fuzz, pgas exhaustion, reorgs, registry abuse (execution test engineer)

+
+

2026-10-03 execution layer attack suite: malformed txs, nonce games, RPC fuzz, pgas exhaustion, reorgs, registry abuse (execution test engineer)

Machine: Apple M5 Max (18 cores), shared with other agents' builds (load 9 to 15). Worktree vendor/igneum-node-exec-attacks on branch exec-attacks (from execution-layer fb330692); igneumd, igneum-miner and a new hostile-miner bin igneum-inject built release with CARGO_TARGET_DIR=target nice -n 19 cargo build -j 4 -p kaspad -p igneum-miner --features igneum-pow (stable-aarch64 toolchain; the default cargo on PATH is too old for edition 2024). Tools and the per-scenario commands: tools/exec-attacks/ (README, net.sh, scenario{1,2,3,4,5,6}*.mjs, igneum-inject); raw results under tools/exec-attacks/results/*.json. Network: 3 igneumd --simnet --enable-unsynced-mining --unsaferpc --disable-upnp nodes, PoW skipped, chain id 4463, eth RPC 27690/27691/27692, gRPC 27610/27620/27630, p2p 27611/27621/27631, appdir /tmp/igneum-exec-attacks; one honest stub miner for scenarios 1 to 5 and 4, three miners split into partitions for scenario 6. igneum-inject fetches a block template, replaces the EVM body with arbitrary raw EIP-2718 bytes, recomputes hash_merkle_root and resubmits, so the hostile-miner path reaches body validation and the executor directly. The live devnet (26610, 26611, 26640, 26641, 28640) and other agents' ports (up to 27599) were not touched; every process was stopped at the end.

Run in priority order 1, 2, 5, 3, 6, 4. One row per scenario: criterion (from the design), measured result, verdict.

#ScenarioCriterionResultVerdict
1Malformed and boundary txs (mempool and hostile block)State-free faults invalidate the block; state-dependent faults skip the tx with no receipt; no panic; memory bounded7 state-free faults (bad RLP, type-3 blob, wrong chain id, intrinsic gas above limit, initcode above 49,152, duplicate hash in block, non-contiguous nonces, invalid signature s=0) each made the hostile block invalid and were rejected by the mempool where decodable; 5 state-dependent faults (nonce far ahead, nonce reuse, zero fee below base, insufficient funds, max fee at 2^120) each landed in an accepted block and were skipped with no receipt; gas limit exactly at B_e executed; node kept producing blocks; node RSS 345 MiB to 348 MiB (x1.01); 0 node panics in any logPASS (30/30 checks)
2Nonce games across parallel blocksExactly one execution per nonce; deterministic; state roots identical on all nodesnonces n..n+3 spread across 3 parallel blocks with heavy duplication executed once each, account nonce advanced to n+4; a conflicting same-nonce pair in two parallel blocks executed exactly once; state roots identical on all 3 nodes at the tip in both roundsPASS (9/9)
5RPC fuzzErrors not crashes; honest latency under 200 ms31 eth_*/igneum_* methods x 9 junk param shapes plus deep nesting (5,000 levels) and broken bodies all returned a JSON-RPC envelope or a handled HTTP error, none dropped the connection or crashed; under a one-client eth_call flood of 4,184 req/s (about 200x honest) honest p95 latency 29.1 ms, max 33.5 ms, 0 flood errors; node kept advancingPASS (5/5)
3Proving-gas (pgas) exhaustionThe per-block pgas budget B_p caps inclusion and the template respects it; measure execution time per blockB_p = 30,000,000. modexp loops: 1,000 iters executed 3.45 M pgas in 1.34 ms; 3,000 -> 10.33 M pgas, 4.56 ms; 6,000 -> 20.64 M pgas, 7.54 ms; 9,000 -> would-be 30.96 M pgas, skipped with BlockProvingBudget after 10.85 ms of native execution; no executed block carried more than B_p (max 20.64 M)PASS (4/4)
6Reorgs under executionState root recomputed deterministically; displaced-tx receipts handled per design; no stuck mempoolPartition P1={node1}/P2={node2,node3} healed via igneum-inject addpeer after 1/3/5/8 s forced selected-chain reorgs of depth 3, 6, 13, 11 on the losing node; all 3 nodes converged to one sink and agreed on the state root at the common height each time; the tx executed on the pre-heal chain re-resolved to one canonical, cross-node-consistent outcome (DAG merges the losing blocks, design 1.2/1.3; it does not orphan them); a fresh tx was mined after every reorg (mempool not stuck)PASS (31/31 checks over 4 cycles)
4Developer registry abuseDesign 4.5: base fees burned, no positive-expectation loop; record the max share a self-dealer recoversregister(someone-else's-contract) and register(unrelated EOA) both revert; a factory's CREATE and CREATE2 children inherit the factory payee; a same-tx creator override sets a different payee; an EOA cannot override a factory child; an unregistered factory's child has no payee (share burns); self-dealer (sender = payee = block miner) recovered 100.0% of the tip but only 56.45% of total fees paid, because both base fees are burned; recovered < paid alwaysPASS (19/19). Max share a self-dealer recovers: 56.45% of fees paid (tip only; base fees always lost)
@@ -217,9 +254,11 @@ table{min-width:560px}

Findings (not consensus failures; filed for the ledger):

  • F-exec-A (low): the EVM mempool admits a transaction whose gas_limit exceeds the block execution limit B_e. igneum/exec/src/pool.rs EvmPool::add checks funds, nonce and fee cap but never bounds gas_limit by BLOCK_EXECUTION_GAS_LIMIT. Reproduction: fund an account, send a type-2 tx with gas=31_000_000 (B_e is 30,000,000) to any node's eth RPC; eth_sendRawTransaction returns a hash (admitted). The transaction can never be selected (EvmPool::select breaks when gas + gas_limit > B_e) nor form a valid block (check_evm_body -> SumGasLimitAboveBlockLimit), so it occupies a queue slot until evicted. Self-limited because admission still reserves gas_limit x max_fee_per_gas in the funds check. Fix: reject gas_limit > B_e in EvmPool::add, as geth rejects gas > block gas limit.
  • F-exec-B (medium, griefing): an over-pgas-budget transaction is executed natively in full before it is skipped, and because it is skipped it pays no fee. A transaction whose own pgas exceeds B_p (for example one large modexp, or the 9,000-iter loop above at 30.96 M pgas) is included, executed (10.85 ms of real work here, more for a bigger input), then dropped with BlockProvingBudget and charged nothing (igneum/exec/src/executor.rs: the skip happens after inspect_one_tx runs and before any fee is taken). Every node re-executes it on every inclusion for free, and because the nonce never advances it also head-of-line-blocks that sender's higher nonces (seen here: the 14,000 and 20,000 loops were never includable behind the stuck 9,000). The funds check at admission does not bound pgas (pgas is not known without execution), so a modestly funded account can force repeated free computation network-wide. Fix options: charge the intrinsic plus consumed pgas on a budget skip, cap single-transaction pgas at admission via eth_estimateGas-style simulation, or drop a sender's queue on a BlockProvingBudget skip rather than retrying.

Not covered here (out of scope for this pass, and because the proving layer is not implemented on this branch): proof records, the native-execution veto, sortition, and the finality lock (proven/locked are always false on devnet v3, so only executed was exercised). These need the proving layer and the finality merge (design 10.4) before they can be attacked.

-

4 October 2026, sim/economy: mining versus proving under stress, agent-based (economist; model, not hardware)

+
+

4 October 2026, sim/economy: mining versus proving under stress, agent-based (economist; model, not hardware)

Machine: Apple M5 Max, shared (load 9 to 25), single process at nice 19, about 28 minutes of compute in total. sim/economy/sim.py, Python 3.10.10, numpy 2.2.6; 1,000 operators, 30 days, 180-s ticks, 13 to 25 s per run. Inputs: RTX 5090 229 MH/s (measured, this log); every other number approximate (docs/analysis/economy-2026-10-04.md, assumptions table). Six scenarios x 5 seeds (sim/economy/results.md): no backlog, no window miss, no hash under 50% of pre-event in any run. Hash troughs: a 0.95, b (price down 70%, external x10) 0.82, c 0.97, d (20% operator leaves) 0.75, e (30% withholder) 0.98, f (2x pool arrives) 0.95 of pre-event; day 30: 1.00 / 0.87 / 1.00 / 0.80 / 1.00 / 1.92. Blocks proven within 60 s: 1.00 in every hour; within 20 s: 0.14 to 0.41. Cards in hybrid mode (mine, answer own assignments) at day 30: 42 to 54%; cards off: 1% (a, c, e) to 10% (b). Profit $ per card-day, baseline: 5090 6.37, 3090 1.66, 3060 0.78, small 0.39; shard share 5090 0.59, 3090 0.26, 3060 0.16. Proving-share 10-90 range over the last 10 days 3 to 9 points (one seed of f at 10.1). Sensitivities on b (2 seeds, sim/economy/levers.md): traffic 3 / 30 / 100 / 300 shards per block gives hash trough 0.81 / 0.82 / 0.63 / 0.06, oldest unproven age 0 / 0 / 85 / permanent, worst day within 60 s 1.000 / 1.000 / 0.994 / 0.825, hours under 50% hash 0 / 0 / 0 / 22. Observation window 20 min to 24 h: score 0.939 to 0.952, churn only. Lever study on b at 100 shards per block (2 seeds): window 5 / 10 / 20 / 30 s gives age max 565 / 325 / 0 / 0 s, hash trough 0.53 / 0.62 / 0.77 / 0.77, score 0.592 / 0.765 / 0.948 / 0.948; pool 0.1 / 0.2 / 0.3 / 0.4 gives age 168 / 325 / 16 / 0 and cards off 0.05 / 0.07 / 0.07 / 0.10; burn 0 to 0.5 and claim timeout 60 to 600 s leave the age at 325 s in every row. Proposal (not applied): window = p90 shard time plus one swap, 25 s at today's targets (O-5.1); B_p tied to the live proving fleet rather than a launch calibration. Not done: DAG and network latency, pool protocol, bonds on jobs beyond a class filter, price feedback from burns, the launch ramp; the age column of the 300-shard sensitivity row predates the age-formula fix.

-

2026-10-04 execution layer attack fixes: F-exec-A (mempool gas-limit bound) and F-exec-B (pgas abort rule, spec 7.5) (execution-engineer)

+
+

2026-10-04 execution layer attack fixes: F-exec-A (mempool gas-limit bound) and F-exec-B (pgas abort rule, spec 7.5) (execution-engineer)

Machine: Apple M5 Max (18 cores), shared with other agents' builds (load 13 to 18). Worktree vendor/igneum-node-exec, branch execution-layer (fix commit on top of fb330692); built release with CARGO_TARGET_DIR=target nice -n 19 cargo build --release -j 4 -p kaspad -p igneum-miner --features igneum-pow (stable-aarch64 toolchain), unit tests with cargo test --release -j 4 -p igneum-exec -p igneum-evm-types. Network: 3 igneumd --simnet --enable-unsynced-mining --unsaferpc --disable-upnp nodes from this worktree, one honest stub miner, eth RPC 27990/27991/27992, gRPC 27910/27920/27930, p2p 27911/27921/27931, appdir /tmp/igneum-exec-fix; hostile blocks through the attack suite's igneum-inject (vendor/igneum-node-exec-attacks/target/release, same wire protocol). The attack scripts of tools/exec-attacks ran unchanged against this network with IGNEUM_RPCS and IGNEUM_GRPC1 pointed at it, from copies outside the repository so results/*.json of the 3 October run stay as recorded; the after-fix reproduction is a separate script (session scratchpad, scenario3_after.mjs, 25 checks) written against the new rule. The live devnet and the attack suite's 276xx ports were not touched; every process was stopped at the end; 0 panics in the three node logs.

What changed (spec 7.5, design 10 note): the inspector meters pgas against the including block's remaining B_p and halts the transaction before the opcode or precompile that would cross it (a precompile over the cap is answered with a revert that spends none of the forwarded gas, and the parent halts at its next instruction); the executor charges an aborted transaction as out of gas for the gas and pgas consumed to the abort, status 0, nonce advanced, receipt pgasAborted; the proving charge never takes a sender past the signed budget. The mempool refuses gas_limit > B_e (F-exec-A) and an estimated pgas above B_p (estimate = simulation at the tip under the cap), the template packs by the estimate, eth_estimateGas and eth_call fail naming the pgas when the cap is hit, igneum_estimateGas returns both dimensions. Simulations now read the state through DatabaseRef instead of cloning it per call. igneum-exec-diff treats a pgasAborted transaction as an Igneum-only flow (plain revm would run it to its own end).

Unit tests (new, all pass): pool::gas_limit_is_bounded_by_the_block_execution_limit, pool::estimated_proving_gas_is_bounded_by_the_block_proving_limit, pool::template_never_exceeds_the_remaining_proving_budget, executor::over_budget_pgas_is_aborted_charged_and_the_nonce_advances (an SLOAD-loop bomb with a 30 M gas limit, about 54 M pgas if run out, is cut under B_p, charged exactly gas_used x price + pgas_used x f_p, nonce advanced; a second inclusion skips with NonceTooLow in under 100 ms; the next nonce executes), executor::the_cap_is_the_remaining_block_budget (two bombs in one block fill it to within 1,000 pgas of B_p; a third copy skips at its intrinsic pgas), executor::estimate_reports_the_cap. 6 of 6 in igneum-exec, 3 of 3 in igneum-evm-types.

@@ -229,18 +268,22 @@ table{min-width:560px}

Scenario 1 (malformed and boundary, unchanged script): 30 of 30; the single-gas-limit-over-block case now records mempoolAdmitted: false (the observation that filed F-exec-A is gone); the script's RSS probe looks for the attack worktree's binary path and found no process here, so that check was trivial in this run (the after-fix script measured RSS itself, above).

Differential: igneum-exec-diff over the test network's export, segments 0 to 176, 17 executed transactions compared (one pgasAborted), 6 skipped copies confirmed, 11 accounts compared, 0 mismatches.

Not changed: the pgas table magnitudes (prototype), B_p = 30 M (prototype). Open: the admission estimate runs under the RPC's state read lock, so a flood of heavy eth_sendRawTransaction calls delays the follower by up to B_p of simulation each (same shape as the eth_call flood of scenario 5, which stayed under 34 ms p95); a per-sender or per-second cap on estimates is the next step if the devnet shows it.

-

3 October 2026, per-identity hash rate "decay" on the RTX 5090: diagnosis and Metal reproduction (miner-community-lead)

+
+

3 October 2026, per-identity hash rate "decay" on the RTX 5090: diagnosis and Metal reproduction (miner-community-lead)

Machine for the reproduction: Apple M5 Max, 64 GiB, Darwin 25.6.0, load average 2 to 147 (other agents' builds and, during R1, another agent's Metal worker on the same GPU); everything at nice -n 19. Binaries: HEAD proto-metal/main.swift built with swiftc -O into the scratchpad (465,529 bytes, the same size as proto-metal/igneum-bench), vendor/igneum-node-diff/target/release/igneumd and igneum-miner (22:38 and 21:17 UTC, the difficulty worktree pair; the miner's Seeder and worker protocol are the same code as HEAD and as the Windows build 745d41ef). Private networks on 127.0.0.1 ports 27500 to 27562, appdirs under /tmp/igneum-decay-test, all stopped afterwards. Full write-up: docs/analysis/hashrate-decay-2026-10-03.md; proposed fix: docs/analysis/hashrate-decay-2026-10-03.patch (not applied; git apply --check passes against vendor/igneum-node). PC data (node tools/logs.mjs <run_id> --all, STATUS lines deduplicated by timestamp, per-interval rates from consecutive cumulative figures): segment 22:57 to 23:04 UTC, nvidia-1: 40 jobs in the first 30 s then exactly 32 per 30 s for 12 intervals at 17.5 to 18.4 MH/s wall while the printed cumulative figure fell 22.18 to 18.13; nvidia-8 (started 4.7 s later) printed a rising 16.80 to 17.71. Segment 22:23 to 22:57 UTC (epoch 2, DAA 8,474 to 10,513): per-identity gap between jobs 0.098 s to 0.330 s per 0.68 to 0.81 s job, inside-jobs rate rising 28.7 to 34.7 MH/s, wall falling 24.6 to 20.6 MH/s, card total 197 to about 165 MH/s; at the 22:57 epoch boundary the gap returned to 2% and the difficulty held (84.5M to 83.0M). Code audit: nothing allocated per job survives the job in proto-cuda/host.cu, proto-opencl/host.c or proto-metal/main.swift serve loops (tables in the analysis); the miner's only per-job growth is time in Seeder::seeds_for (memo keyed by (epoch, sink), one getBlock RPC per block from the sink to the epoch start on every miss, 1,274 to 3,313 calls on the RTX 5090 machine). cudaDeviceSynchronize at the default schedule spins one thread per worker (the maintainers' 6.2% per process); the hot-swap working tree sets cudaDeviceScheduleBlockingSync and swaps clFinish for clWaitForEvents. Metal runs (STATUS every 30 s; "gap" = 1 minus wall over inside, per interval): R1 control, epoch 0, genesis bits 0x1d100000, 308 s (cut by the 22:21:37 UTC SIGTERM of every process of this session): first interval 25.18 MH/s alone on the GPU, then 14.0 to 14.4 MH/s in every interval after another agent's worker joined at 25 s, gap 0 to 2%, worker RSS 56.8 MiB flat. R2 walk reproduction, 900 s: skip_proof_of_work node pumped to DAA 4,000 (one-second timestamps, difficulty held at 76.8M), one identity, pumped blocks at 1/s for 300 s, none for 300 s, 1/s for 300 s: inside 27.0 to 27.7 MH/s in all 29 intervals; wall 22.3 to 24.3 (gap 12 to 18%, walk 400 to 700), 25.9 to 27.3 (gap 0 to 4%), 18.0 to 21.0 (gap 25 to 35%, walk 700 to 1,000); miner CPU 0 to 1% in the quiet phase, 11 to 21% in the last. R3 one worker at difficulty 2^25 (Kaspa sampled rule, genesis bits held), 600 s: 30.51 wall / 30.72 inside, 1,091 jobs, 224 blocks, 53 to 56 jobs per 30 s throughout. R4 eight workers at 2^25: 29.38 / 29.45 summed (3.32 to 4.38 each), 1,053 jobs, 242 blocks, 7 jobs per 100 s per identity in every interval, worker CPU 0.0 to 0.6%, RSS 46 to 57 MiB. R5 one worker at 2^31: 37.01 / 37.75, 1,324 jobs, 4 blocks, flat. R6 eight workers at 2^31: 36.67 / 36.75 summed (4.29 to 5.55 each), 1,314 jobs, 5 blocks, flat. (R5 and R6 ran a different epoch-0 program from R3 and R4, 112 loads per hash, hence 37 against 30.5 MH/s.) Side findings: the difficulty worktree's node panics at consensus/src/processes/difficulty.rs:431 ("Work should not exceed 2**192") when fed 85 blocks/s with wall-clock timestamps under the Igneum dual rule (a pump artefact, logged for the consensus-engineer); skip_proof_of_work nodes still log "PoW rejected ... by igneum-lottery-v1-bound" for every block they accept. Not done: the fix applied and measured on the RTX 5090 machine (the acceptance figure is a flat gap at DAA 10,800 with eight identities); the OpenCL event wait checked on the AMD driver; a unit test of seeds_for (the client is concrete).

-

2026-10-04 finality v2 attack harness: seven hostile scenarios on a six-voter private test network (consensus test engineer, cryptographer)

+
+

2026-10-04 finality v2 attack harness: seven hostile scenarios on a six-voter private test network (consensus test engineer, cryptographer)

Machine: Apple M5 Max, rustc stable, macOS Darwin 25.6.0. Fork: worktree vendor/igneum-node-fin-attacks, branch fin-attacks on master c6d47547 to 2a00ff55 (BLS votes, certificates in coinbase extra data, p2p message 70, the finality RPCs). Build: CARGO_TARGET_DIR=target nice -n 19 cargo build --release -j 4 -p kaspad -p igneum-miner --features kaspad/igneum-pow. Tool: tools/finality-attacks (run.mjs, lib/, README with the proposed fixes). Network: igneum-devnet-800, ports 27800 and up, data /tmp/igneum-fin-attacks, skip_proof_of_work (the hostile miners never hash; each gets its block share from a Poisson clock; every other consensus rule unchanged). Devnet finality parameters: interval 30, depth 20, weight window 7,200 DAA, dust 5, presence 20 indices, 8 aggregators, ban 7,200 DAA, quorum 2/3 of active and 17/30 of total. Durations at SCALE 0.6. The live devnet (26610, 26611, 26640, 26641, 28640) was never touched. Run time 32 min of process time (the machine slept twice during the run, which pauses the monotonic clocks the harness and the miners use, so wall-clock timestamps in the log jump; no result depends on wall time).

Hostile pieces are test-only flags of igneum-miner, never honest node or consensus code: vmine (Poisson submit at a chosen hash share, decoupled 0.5-s voter), --equivocate, --sybil b:bb:a:ab (one miner mints many vote keys), --drop-votes (strips the node's finality section from its coinbase so its blocks carry no votes or certificates while it still votes over RPC), --pulse burst:on:period, and fin-rpc-attack (malformed, mis-signed, replayed, oversized and non-hex votes over submitFinalityVote). Six voters throughout; three nodes for the cross-node scenarios, two nodes over a TCP proxy for the partitions.

#Scenario (priority order)Criterion (spec 03)MeasuredVerdict
3Dishonest aggregators (6 voters, 3 nodes, every node aggregates)other aggregators' certificates still lock; a sub-quorum certificate cannot lock (Q3); block-carried votes give participation (F3); lock latency under 2 s median35 / 35 / 35 locked per node, identical lock hashes on all three, 0 conflicting certificates, median lock latency 1,018 ms (bounded by the miners' 1-s poll). Sub-quorum rejection is by code review (lock_test needs both integer tests; a certificate below either is Certified, never Locked); injecting one on the wire needs a finality-aware p2p probe (not built)PASS (wire injection not run)
2Sybil dust (one miner mints 200 keys at 4 blocks and 200 at 6, dust 5; 3 honest voters)dust keys zero weight and no voters; above-dust weight = blocks; total weight = voters' blue blocks; sortition by weight not key count (F17)200 dust keys seen, all voter false; 203 voters above dust; total weight 1,240 = sum of voter blocks 1,240; aggregator sortition is PER KEY (is_aggregator(output, voters, 8) counts keys), with 203 voters a real signer's chance to be an aggregator fell to about 8/203 and the last checkpoint named 0 aggregators (zero-aggregator certificates, "anyone MAY aggregate")weights PASS; sortition FAIL (F17)
1Equivocation at scale (2 of 6 keys sign two checkpoints at every index, 3 nodes)both keys stripped within one checkpoint on every node; no conflicting certificate; honest locks continuestripped keys 2 / 2 / 2 on the three nodes, 78 / 8 / 8 detections (node-local on the equivocators' node, block-carried evidence on the others), 0 conflicting certificates, 35 / 35 / 35 locks by the 4 honest keysPASS
6APartition 3/3 for 90 s after a 252-s shared warmup (window 1,439 DAA at the cut), then healzero locks on either side during the split; locks resume after the heal; no conflicting certificatesside 0: no new lock in 90 s; side 1: first new lock at 84 s, 8 locks before the heal; 0 conflicting certificates (side 0 never locked those indices); locks resumed on both sides after the heal. Side 1 crossed the floor because its own fresh blocks raised its share of its window: at the cut each side held 50% of 1,439 DAA of weight; the 3-miner side added about 2.6 blocks/s and by 84 s held (720 + 220) / (1,439 + 220) = 56.7%. The model is share(T) = (F/2 + R T) / (F + R T) with F the window weight at the cut and R the side's block rate, so the floor holds for T* = 2F / (13R): 74 s predicted at F = 1,439 and R = 3, 84 s measured (sibling losses lower R). The simulation used fixed weights and could not see this (spec 3.7 item 8)FAIL (floor is time-bounded)
6BPartition 4/2 for 90 s after a 252-s warmup, then healthe 4 side (66.7% of total) keeps locking; the 2 side (33%) does not; no conflicting certificates4 side locked 47 to 59 (first new lock 15 s after the cut, the active test passes at exactly 2/3); 2 side stayed at 47; 0 conflicting certificates; both resumed after the healPASS
4Vote-dropping block producer (40% of blocks carry no finality section, 2 nodes)participation and locks unaffected because other blocks carry the votes; delay measuredthe node that saw the dropper's blocks only through gossip and the other producers' blocks locked 35 checkpoints; median lock latency 1,019 ms with the dropper vs 1,019 ms control, 0 ms addedPASS
8Malformed votes over the RPC (9 cases, fresh key per case)rejected without a crash; node stays upcontrol vote accepted; replay answered "already known" (deduplicated, not double-counted); bad signature and wrong chain id rejected "invalid vote signature"; a vote for a hash the node does not hold at a known index is recorded and flagged, not certified; 8-byte, 2 MB and non-hex payloads rejected "vote must be 280 bytes" / "vote is not hex" before any processing; node answered getInfo after all 9. The message-70 half (sub-quorum and replayed certificates, oversized bitmaps) needs the p2p probe; by code review Certificate::read bounds the bitmap at 1 MB, the relay bounds a message at 1 MB and a malformed one is a ProtocolError that disconnects the peerPASS (RPC half)
5Pulsed miner (base share 1/6, 10x for 20 s of every 120 s, 5 steady voters, 216 s, Kaspa's DAA rule as master runs it)weight proportional to block share over the window (no retarget amplification, W2 and F14); cannot lock aloneweight share 35.3% vs block share 35.3%, ratio 0.999: W2 counts blocks and the retarget lag bought nothing extra. But checkpoints 1 to 10 were locked by the burster ALONE: its first 20-s burst gave one key 66.7% to 71.7% of a window that held under 300 blocks (cp 5: 98 of 147 signed by 1 of 6 voters; cp 10: 201 of 297), above both Q3 tests. From cp 11 every lock needed 3 or 4 signers as its share decayed to 35%. This is ledger F1 measured live: with no first-month gate (min_daa 0 on devnet, 3,600 DAA on mainnet, spec 3.8 not implemented) a short burst owns a young windowamplification PASS; lock-alone FAIL (F1)
7Eclipse of one voter with an adversarial side chainnot run: needs the finality-aware p2p probe to feed a private forknot measurednot run

Failures and the proposed fixes (diffs in tools/finality-attacks/README.md, for gate 3 to ratify; no rule was changed here):

  1. F17 (S2): is_aggregator draws the 8 aggregators per key. Liveness only, because any node may aggregate and a certificate must still meet Q3 by weight, which the Sybil split does not change. Proposed: draw by weight, output x total < 8 x weight x 2^64, mirroring the spec 7.2 step-2 fix.
  2. Floor time bound (S6A): the 56.7% floor protects a partition for about T* = 2F / (13R) of DAA time, with F the window weight at the cut and R the majority side's block rate. Approximate, formula only, window slide ignored: on mainnet with a full 30-day window and a 50/50 split at 1 block/s, 9.2 days; a 55/45 split, 2.1 days; 60/40 locks at once (3.3.1 already says so). Minimum fix: state the bound in spec 3.3.1 and 3.9. Rule option for gate 3: evaluate the floor against the weight table of the last locked checkpoint while no newer lock exists, so a stalled side cannot lift its own share by mining; cost: after a permanent loss of weight the floor needs a manual override instead of the 4.1 days of 3.3.1 D.
  3. F1 (S5): no certificate should form before the window holds a full window of history (spec 3.8, O-3.1). Proposed: min_daa = weight_window (2,592,000 on mainnet, 7,200 on devnet) in FinalityParams, one line each.

Not demonstrated: certificate injection on the wire (S3, S8 half), the eclipse (S7), the 2-hour presence window at mainnet length, the heal rule of 3.5 (both partitions healed without a conflicting certificate, so it was not exercised).

-

4 October 2026, difficulty rule under attack: pool hopping, pulsed rental, timestamp stretching, short-lane oscillation, epoch games, polluted window, block flood (consensus test engineer)

+
+

4 October 2026, difficulty rule under attack: pool hopping, pulsed rental, timestamp stretching, short-lane oscillation, epoch games, polluted window, block flood (consensus test engineer)

Machine: the same Apple M5 Max, shared with other agents' builds and test networks (load 15 to 30). Simulator sim/difficulty/attacks/attacks.py over sim/difficulty/sim.py (controllers unchanged): several miners with on/off strategies, block attribution by hash share at the solve, hashes per miner, timestamp forging inside the fork's rules (132 s ahead, above the 27-sample past median). Node runs on branch diff-attacks of vendor/igneum-node (worktree vendor/igneum-node-diff-attacks, from difficulty at 3ea7a3e3; adds only the attack variable IGNEUM_ATTACK_TS_OFFSET_MS in the template builder and a reproduction test), ports 27700 to 27721, appdir /tmp/igneum-diff-attacks, genesis bits 0x1f010000. Everything in sim/difficulty/attacks/README.md, raw tables in results.md, headers of the three test-network runs in testnet/. Simulator, seeds 7 to 9, Igneum / Kaspa's rule, criterion, verdict: (1) pool hopper 10 to 100% of the base, on while D is below its 6-hour mean, 24 h: hopper's blocks per hash +1.5% at most / +0.8% at most, under 5% both, Igneum 0.7 points above Kaspa's in every greedy cell (unchanged with the ease clamp at 6% or 3%: the price of a controller that moves inside the hour; a 60 s dwell turns the 50% and 100% hoppers into losers, -1.7% and -4.0%): PASS under 5%, FAIL on "no larger than Kaspa's" by the letter, no change proposed. (2) 50x burst for 10 min every hour: pulser's weight per hash 0.26 / 0.98 of the base's, blocks per hash 3.7% / 85% of the base's; once: 0.13 / 0.87: PASS (no weight amplifier under either rule; Kaspa's makes the burst cheap, Igneum's makes it 27x dearer; the hour after costs the base 37% and a 153 s worst gap under Igneum). (3) forger at 30 or 50% stamping at the latest allowed, the earliest allowed, or alternating: Igneum block rate 0.66 / 0.42 / 0.51 at 30% and 0.56 / 0.12 / 0.23 at 50%, difficulty 1.5x to 9.9x on an unchanged hash rate, worst gap 234 s; Kaspa's rule +5% to +11% easing: FAIL both, Igneum far worse. Cause: the symmetric per-step clamp turns every forged block and the honest block after it into zero measured time (spec 2.3's "the next honest block cancels it" is the bug, not the defence), so the lanes measure 1 - 2a(1 - a) of real time at share a; past-stamping also drags the past median down without bound. (4) 25% miner on and off every 120 blocks: std of the rate ratio 0.160 / 0.147 against 0.045 / 0.010 steady and a 0.143 floor from the attacker's own square wave: FAIL by the letter for both, neither oscillates (12% and 3% above the floor), no change proposed. (5) hold dodger 30%, hold flooders 10x and 30%: 0.0 / +0.7 / +0.3% against 0.0 / 0.0 / -0.1%: PASS. (6) 10x miner leaving at block 600 of an epoch, where the long lane takes over: settled 303 s (292 s with the short lane engaged at the switch), worst gap 17 s, against 334 s for a leave at block 1,200; Kaspa's 2,910 to 3,540 s: PASS. (7) side finding, blocks every 12 ms fed to the rule (another agent's pump): the target passes below 2^64 after 4,142 blocks and calc_work panics at difficulty.rs:431 (should_panic test igneum_flood_at_85_blocks_per_second_drives_the_target_below_block_work_range on diff-attacks): FAIL, floor proposed. Test network, 3 igneumd nodes, honest 4-thread miner A on node 1 for 15 min, forger F (4 threads, about 50%) honest on node 2 for 5 min then on node 3 with the offset: Igneum, earliest allowed stamp: 0.97 blocks/s at difficulty 91,000 before, 0.24 blocks/s at 275,000 during forging and 0.20 at 341,000 in the last 5 min, forger offsets -121 to -566 s, hash unchanged (A 0.078, F 0.069 MH/s). Igneum, latest allowed stamp (+134 s): 0.98 blocks/s at 89,000 before, 0.59 at 170,000 during, 0.50 at 191,000 in the last 5 min (A 0.112, F 0.110 MH/s); the simulator's 50% cases give 0.12 at 9.9x and 0.56 at 1.8x. Kaspa's rule, earliest allowed stamp: 1.73 blocks/s on a 2.5x too easy genesis to block 600 at 210 s, then 1.02 blocks/s at 83,400 through ten minutes of -180 s stamps. 517, 767 and 1,454 blocks, 0 rejected. Proposed (README.md, diffs, not applied): Part A, timestamp rules: 10 s future tolerance (FUTURE_TOLERANCE_MS, a new constant so the past-median window keeps its 27 samples) and a floor at the selected parent's timestamp minus 10 s (BACK_TOLERANCE_MS) beside the past median; Part B, the chain steps of the short and epoch lanes measured on a sanitised running clock c(b) = max(c(p) + clamp(t(b) - c(p), -20 T, +20 T), t(b) - 60 T), step = min(c(b) - c(p), 20 T), stored per header, so forgeries telescope instead of cancelling; the long lane unchanged. Measured, both parts, 3 seeds: the 50% forger drifts the rate +0.7% (past), +0.9% (future), +1.1% (alternating), worst seed +2.7%; base profiles unchanged except down50 762 s against 782 s, warm-up 327 s against 381 s, polluted peak 11.4x against 8.0x; the other attacks identical. Either part alone fails (unchanged rule under the tight rules: -36% and -83% to past-stamping; the clock under the 132 s rules: collapse at 50%, a martingale once the forgery range exceeds half the cap). Part C for the flood: clamp the output at MIN_DIFFICULTY_TARGET = 2^128 beside the existing maximum, in both rules. Not done: the candidate in the node (simulator only; the per-header clock is a store change); DAG effects of forged stamps on red and merged blocks (one chain in the simulator); a rule change for the hopper's 0.7-point excess (none found that keeps the controller fast; README.md, scenario 1); Kaspa's rule under the flood (same hole, 17x slower, not run).

-

2026-10-04 finality fixes F17 and F1: aggregators drawn by weight, first-month gate min_daa = window; attack scenarios 2 and 5 before and after (consensus-engineer)

+
+

2026-10-04 finality fixes F17 and F1: aggregators drawn by weight, first-month gate min_daa = window; attack scenarios 2 and 5 before and after (consensus-engineer)

Machine: Apple M5 Max, rustc stable, macOS Darwin 25.6.0. Branch fin-fixes (worktree vendor/igneum-node-fin-fixes, from master 2a00ff55), commit da1eb889. Build: CARGO_TARGET_DIR=target nice -n 19 cargo build --release -j 4 -p kaspad -p igneum-miner --features kaspad/igneum-pow. Tests: cargo test --release -p kaspa-consensus-core -p kaspa-consensus -- finality: 6 of 6 in consensus-core (sortition_threshold, sortition_is_by_weight_not_key_count with 200 dust keys and 6 real ones, first_month_rule_is_the_full_window, the three pre-existing), 1 of 1 in consensus (processes::finality::tests::no_certificate_while_the_window_is_filling, a 150-block TestConsensus chain at a 60-DAA window where one key holds all the weight: nothing certifies under DAA 60, a hand-built early certificate is refused, every checkpoint from DAA 60 locks). The live devnet (26610, 26611, 26640, 26641, 28640) and the other agents' nodes (26680, 27700 to 27720, 28680) were never touched.

The two diffs. (1) F17: is_aggregator(output, weight, total_weight, aggregators) is eligible when output x total < aggregators x weight x 2^64 (was output x voters < 8 x 2^64, drawn per key); ingest_vote passes the key's weight and the table total. A key split into n parts holds n thresholds that sum to the one it had; a key without weight never draws; a key at 1/8 of total or more always draws. A node that serves a drawn aggregator aggregates at once; any other node after checkpoint_depth + aggregator_fallback (15) DAA seconds, so anyone MAY aggregate stays the liveness fallback. (2) F1: min_daa = weight_window (mainnet 2,592,000, devnet 7,200); evaluate never locks and ingest_certificate refuses any certificate while the checkpoint's DAA score is below it; the node logs and reports "finality not active, window filling, N of M" (finality_reason, window_filled_daa, window_full_daa on getFinalityCheckpoints).

Re-run of scenarios 2 and 5 (tools/finality-attacks, hostile igneum-miner from the fin-attacks worktree, unchanged; it drove the fixed node without modification because the new RPC fields are additive). Six voters on one node, skip_proof_of_work, 600 s per run. The harness copy used for the runs is /tmp/igneum-fin-fixes/harness (lib/net.mjs with ports, data directory, network suffix and the finality override taken from the environment; rerun.mjs with the s2 and s5 measurements below); the repo harness was not edited, and its s2 pass test still reads "voters > 8 means per-key sortition", which is now wrong and needs the by-weight test below. Finality override for every run: interval 30, depth 20, window 1,800 DAA, dust 5, presence 20, 8 aggregators, ban 1,800; min_daa 0 for the before runs (the master default) and 1,800 for the after runs (the fixed rule, min_daa = window), fallback 15. The window was shortened from 7,200 to 1,800 so it fills inside a 10-minute run; the rule under test is the equality, not the number. Before = fin-attacks igneumd (master code, built 3 Oct 23:25) on ports 28100 and 28300, network ids igneum-devnet-801 and 803; after = fin-fixes igneumd on 28500 and 28700, ids 805 and 807. Results in /tmp/igneum-fin-fixes/{before,after}-{s2,s5}/.

@@ -249,18 +292,22 @@ table{min-width:560px}

Scenario 5, pulsed miner (five steady voters at 1/6, one burster at 1/6 pulsing 10x for 20 s of every 120 s).

Before (master)After (fin-fixes)
Burster weight share vs block share over the run30.9% vs 32.0%, ratio 0.96630.8% vs 32.1%, ratio 0.959
Checkpoints determined / locked148 / 148148 / 88
First lockcheckpoint 1 at DAA 29, built "by 1 of 1 voters, weight 22 (total 22)", the aggregator and sole voter above dust the burster's key (its first 20-s burst); checkpoints 2 and 3 locked at 3 of 3 and 4 of 4 voters as the others cleared dustcheckpoint 61 at DAA 1,829 (the first checkpoint at or above min_daa 1,800), 5 of 6 voters, 84.7% of active and of total
Locks with the checkpoint under min_daa 1,800not gated (checkpoints 1 to 60 all locked)0
Locks carried by one voter above dust1 (checkpoint 1)0
finality_reason over the runfield absent"window filling, 92 of 1800" ... "1448 of 1800" at 180 s, "paused" at 240 s (window full, first lock pending), "active" from 300 s; 59 "window filling" determination lines in the node log
Conflicting certificates00
Verdictamplification PASS, lock-alone FAIL (F1)amplification PASS, lock-alone PASS

Notes. The fallback path ("fallback: any node may aggregate") fired 0 times in both after runs: every voter on the single node is local and, with six keys of similar weight, each is drawn at every checkpoint, so every certificate named a drawn aggregator. The "paused" reading between the window filling and the first lock is the report's label for "window full, no lock yet"; it lasted one sample in s5 and five minutes in s2 (the floor against silent sybil weight, 3.3.1). The repo harness tools/finality-attacks/run.mjs keeps its pre-fix s2 and s5 criteria and should adopt the two measurements above; the fin-attacks miner prints no FINALITY line (that is the fin-fixes miner).

-

4 October 2026, difficulty rule: timestamp attack fixed (tight bounds, sanitised clock, target floor), simulator regression, 3-node forger test (consensus-engineer)

+
+

4 October 2026, difficulty rule: timestamp attack fixed (tight bounds, sanitised clock, target floor), simulator regression, 3-node forger test (consensus-engineer)

Machine: the same Apple M5 Max, shared with other agents' simulations (load 6 to 10). Worktree vendor/igneum-node-diff, branch difficulty, commit "Difficulty: timestamp rules 10 s both ways, sanitised clock per header, target floor 2^128" on 3ea7a3e3; built with CARGO_TARGET_DIR=target nice -n 19 cargo ... -j 4 on the rustup toolchain (cargo 1.99; the Homebrew cargo 1.69 in PATH cannot read the 2024 edition). Everything in docs/analysis/difficulty-2026-10-03.md section 11 and spec 2.3; ledger M23. The change, the three parts of sim/difficulty/attacks/README.md as proposed: (A) FUTURE_TOLERANCE_MS 10 s in isolation and BACK_TOLERANCE_MS 10 s behind the selected parent in context (new RuleError::TimeTooFarBehindParent), past-median rule and window unchanged, template floor matched; (B) a sanitised clock per header, c(b) = max(c(p) + clamp(t(b) - c(p), -20 T, +20 T), t(b) - 60 T), in a new store (stores::clock, prefix IgneumClock 62, written in commit_header, deleted at pruning, falling back to the parent's raw stamp when the parent has none), the short and epoch lanes walking clock steps min(c(b) - c(p), 20 T); (C) bound_target floors both rules at 2^128. sim/difficulty/sim.py class Igneum carries the same clock and floor. Unit tests: cargo test --release -p kaspa-consensus --lib difficulty 12 pass (the diff-attacks flood test with should_panic removed: every output at or above 2^128, floor reached between blocks 2,000 and 3,000, work under 2^129; both_rules_share_the_target_floor; igneum_clock_steps_pay_a_forgery_back: three blocks 10 s behind their parents then honest blocks, clock steps sum to the 8 s real span, raw clamped solvetimes to -6 s); cargo test --release -p kaspa-consensus-core --lib igneum 9 pass (sanitised_clock_telescopes_a_forged_stamp). Simulator, seeds 7 to 9 (attacks.py --scenario ts --ts-rules tight), forger at 30 / 50% stamping latest / earliest / alternating, block rate after one hour of forging: 1.008 / 1.008 / 1.004 and 1.009 / 1.007 / 1.011 of target (drift +0.4% to +1.1%, worst seed +2.7%), mean difficulty ratio 1.00, worst gap 10.1 s; the 3 October rule under Kaspa's bounds: 0.66 / 0.42 / 0.51 and 0.56 / 0.12 / 0.23, under the 10 s bounds alone 0.636 and 0.170 on the earliest cells. Flood at 85 blocks/s in the simulator: floor reached at block 2,635, no overflow. Pool hopping (--scenario hop, 24 h): unchanged to three decimals, +1.5% at most greedy, -1.7% and -4.0% with a 60 s dwell at 50 and 100%. Base-profile regression, 3-seed means, 3 October against 4 October: record 102.8 against 91.0 s settled (first within 10% 70.3 against 68.5 s); up50 154.4 against 154.4; down50 782.3 against 762.2 (worst gap 78.3 against 73.9 s); epoch30 87.6 against 87.6; hop10 239.4 against 245.1; polluted 70.1 against 74.9 (seed 9: 78.9 against 92.0), peak 8.0x against 11.4x; steady std unchanged. All means within 10%; the two profiles with an idle gap move, because a gap over 60 T is paid back as three 20 T steps instead of one clamped step. Test network (3 igneumd nodes from the fix plus the diff-attacks template hook on a scratch branch, ports 28500 to 28521, appdir /tmp/igneum-diff-fix, genesis bits 0x1f010000, honest 4-thread miner A on node 1 for 15 min, forger F 4 threads honest on node 2 for 5 min then on node 3 with the offset, two runs): earliest allowed stamp (offset -1e9 ms, floored by the rules; 986 blocks, 823 chain, 0 rejected): chain rate 0.82 blocks/s honest (60 to 300 s) at difficulty 102,226, 0.88 during forging (300 to 900 s) at 100,134, 0.83 in the last 300 s at 106,141, all-blocks rate 1.00 / 1.02 / 0.95, forger offsets -10 to -90 s (mean -23), hash A 0.110 MH/s, F 0.109. Latest allowed stamp (+9,000 ms; 1,028 blocks, 829 chain, 0 rejected): 0.78 honest at 102,382, 0.89 forging at 96,717, 0.89 last 300 s at 102,754, all-blocks 0.95 / 1.09 / 1.11, offsets +9 to +26 s, hash A 0.112, F 0.111. Flat within the CPU miners' noise; the 3 October rule on the same schedule fell to 0.24 blocks/s at 275,135 and 0.59 at 170,222 (bench-log entry above). Records in /tmp/igneum-diff-fix/ts-past-igneum/record.csv and ts-future-igneum/record.csv (not archived into the repo). Not done: the DAG effect of forged stamps on red and merged blocks (one chain in the simulator); the clock of a header whose parent arrived through a pruning proof starts from the raw stamp (one window of exposure after a sync, unmeasured); upstream's timestamp integration tests assume the 132 s bounds and were not re-run; the hopper's 0.7-point excess over Kaspa's rule stays open.

-

4 October 2026, devnet-v4 integration: nine branches merged, 3-node test network on the merged node, Windows cross-build (release engineer)

+
+

4 October 2026, devnet-v4 integration: nine branches merged, 3-node test network on the merged node, Windows cross-build (release engineer)

Machine: Apple M5 Max, shared (load 8 to 16, another agent's build and the live devnet running throughout), rustc stable, every build and test at nice 19 with 6 jobs into vendor/igneum-node/target-integration. Branch devnet-v4 of vendor/igneum-node, head dc749905; merge order, conflicts and the cut-over commands in docs/fork-divergence.md, "Integration 4 Oct 2026". The hot swap was not in master (no pow_epoch in 2a00ff55); it was captured from the uncommitted hotswap worktree as a4224689 and merged first. Build times: first release build 3 min 37 s, the execution layer's crates 6 min more, the Windows cross-build 4 min 49 s from a warm dependency cache (proto-cuda/windows-node/cross-build.sh vendor/igneum-node-v4 6). Tests: 628 passed, 0 failed, 24 ignored across the 21 touched crates (--no-fail-fast), then kaspa-p2p-flows 30 of 30 after the estimated_header_size fix (the header's voteKeyHash field was not counted since 815cd00f). Three Kaspa UTXO-body tests are ignored with the reason (the execution layer retires UTXO transactions from bodies); two p2p-lib test modules were brought to the pair-shaped BlockBody. Test network, 01:02:27 to 01:18:53 UTC: 3 igneumd on igneum-devnet-880 (gRPC 28800/28810/28820, p2p 28801/28811/28821, wRPC JSON 28802/28812/28822, eth RPC 28803/28813/28823; node 2 and 3 --addpeer node 1, node 3 also node 2), override file genesis_bits 0x1f010000 (2^16) and finality interval 30, depth 20, window 300 DAA, dust 5, presence 20, aggregators 8, ban 300, min_daa 300, fallback 15; IGNEUM_POW_EPOCH_BLOCKS=300, IGNEUM_POW_EPOCH_LEAD=60 (a short epoch so the hourly swap crosses boundaries inside the run; the devnet values are 3,600 and 600). Miners m1, m2, m3 (igneum-miner mine ... 3 960 --engine igneum-pow --payout-label mN --evm-address 0x7099...79C8), 0.078 MH/s each (3 threads on the loaded machine), 375 / 342 / 338 blocks found, 0 rejected.

MeasureValue
Blocks accepted per node (PoW accepted lines)1,055 / 1,055 / 1,055, 0 rejected, 0 invalid
Block rate95 to 1,026 blocks between the 0-s and 900-s samples: 1.03 blocks/s; 1,055 in 960 s
Sink identical on all 3 nodes31 of 31 samples; peers 2 on every node at every sample; max tips 2
Difficulty (dual-lane rule)56,268 at 20 s, 155,835 peak at 90 s, 110,533 at 900 s
Epoch boundaries (DAA 300, 600, 900)first block of the new epoch accepted 2.23 / 0.50 / 1.47 s after the last of the old; inter-accept gap over the run median 0.59 s, p90 2.21 s, max 7.27 s
Caches built per node4 (genesis day plus the three epoch seeds); miners' CPU program and cache for a new seed ready in 191 to 212 ms
Finalitywindow filling to DAA 300, paused one sample, active from 270 s (DAA 363); first lock checkpoint 11 (blue 331) by 3 of 3 voters at 100%; 24 locks to checkpoint 34, same index on all 3 nodes at every sample; checkpoint 12 locked at 2 of 3 votes (68.1% of active and of total)
Lock latency (miner, proposed to locked over RPC)median 1,011 / 1,012 / 1,010 ms, max 1,988 / 2,716 / 1,965 ms; 34 of 34 votes accepted per miner
EVM smoke (tools/evm-smoke, copy outside the repo, IGNEUM_RPCS on 28803/28813/28823)84 of 85 checks in 118 s: chain id 4463, miner balance 428.5 IGN at chain block 113 (the IGNA payout address), three accounts funded, 59 transfers executed in 10 chain blocks (max 17 per block, 33 to 91 us execution per block), deploy, call, receipts, logs, revert, developer share, state roots identical across nodes; the failing check is "duplicates landed in parallel blocks within 6 attempts" (identical copies to two nodes landed once in 2 of 6 attempts, the conflicting pair never both), which needs parallel blocks the PoW network did not produce in that 36 s (tips 1 at most samples)
igneum-exec-diff on the smoke exportsegments 0 to 198, 59 transactions compared, 8 accounts, 0 mismatches
Harness scenario 5 (ports 28900+, copy of tools/harness)63 cases (46 RPC, 17 p2p): node up on every case, 0 cache builds (RSS flat, node log 1 build = the honest day), the M15 p2p cases disconnected by the strike guard: PASS
Harness scenario 2 (copy adapted to the merged rules; the repo copy probes 132 s and pmt+1)live: floor-2 and floor-1 rejected, floor and floor+1 accepted where floor = max(pmt + 1, parent - 10 s); future flip between +10.00 and +10.02 s; sim: honest 0.908 b/s, ahead +0.2%, oscillate -0.7% over 1,200 virtual s: PASS

Binaries: target-integration/release/{igneumd 40,463,680 B, igneum-miner 7,916,096 B, igneum-exec-diff, igneum-inject, igneum-p2p-probe, igneum-harness-sim}; target-integration/x86_64-pc-windows-gnu/release/{igneumd.exe 50,169,344 B, igneum-miner.exe 10,045,440 B}; package /tmp/igneum-integration/igneum-node-windows-v4.zip (32,946,104 B). Not done: the GPU prepare hot-swap path on the merged miner (CPU miners only here), the cut-over itself, v4 builds for the Apple M5 Max seed relay and the seed node, the repo harness's scenario 2 rules and its scenario 5 summary text (stale "built a cache on HEAD" wording while the per-case data says 0 builds).

-

4 October 2026, generator version 2 adopted: exact load count, fresh-source loads, program acceptance; every vector re-cut, three workers re-checked, 20,000-program census, devnet-v4 binaries rebuilt (cryptographer)

+
+

4 October 2026, generator version 2 adopted: exact load count, fresh-source loads, program acceptance; every vector re-cut, three workers re-checked, 20,000-program census, devnet-v4 binaries rebuilt (cryptographer)

Machine: Apple M5 Max, idle at the start (load 3), rustc 1.99.0 (rustup), Swift 5.8.1, builds at nice 10. Decision (the maintainers, this morning): adopt the census's generator rule before any public vector ships. Rule as implemented (igneum-pow/src/generator.rs, src/accept.rs, spec 01 sections 1.4.2, 1.4.3 and 1.4.6; mirrored in proto-metal/main.swift as generateProgramV2 and acceptProgram because the Metal worker derives its program from the seed itself): G1 exactly 16 load slots, a uniform subset of instructions 1..63 drawn first by partial Fisher-Yates, the other 48 ops from the ten non-load weights (sum 75); G2 a load's source is drawn from the registers other than dst written by an earlier instruction and not read by a load since; R (a) no cyclically stale load source, (b) every register has an injecting write, (c) 64 units at base nonces from SplitMix64(FNV-1a-64("igneum-accept/" || seed words LE)) on the seed-keyed closed-form dataset at 2^28 words with init words = seed words: no constant register bit, no lane-constant load site in any unit, fewer than 164 saturated final values, every output bit within 136 of 1,024, distinct addresses above 245,760 over the 2,048 hashes; a rejected candidate is replaced by seed_words_from_bytes(seed || k_le32), k = 1, 2, ..., 32 consecutive rejections a consensus fault. Every pack carries generator 2, the attempt and the program id FNV-1a-64("igneum-program/" || 2_le32 || seed words LE || attempt_le32); igneum-pow is 0.2.0 and the node's engine reports igneum-lottery-v2-bound. The crate is now the pack source (igneum-pow export); the Swift exporter is the Metal cross-check. Version 1 stays as generate_v1 for the census and MEMHARD.md levers; its vectors are retired.

Packs regenerated (proto-cuda/packs/): igneum-genesis and igneum-hourly (closed form), igneum-genesis-mh (memory-hard, day 2026-10-03, cache FNV unchanged 48c4f5bf24166b2e), and new igneum-devnet-v4-epoch0 (epoch seed = devnet genesis hash edc4fa84...fb07, day bytes igneum-day/20730, cache FNV 448274a57f508cbc). igneum-genesis attempt 0, program id bcc1248b10cc90f2, op mix load=16 add=8 shfl=8 xor=6 mad=5 mul=5 mulhi=5 sub=4 rotl=3 rotr=3 or=1, lane 0 at base 0 42246ba99fc58e4f, lane 31 b08446b1f2de7793; devnet pack id 4be132dd1f2ff270, lane 0 285a83011e7ac3fc. Bound vectors re-cut (igneum-pow/README.md: H zero, nonce 0 gives 746c567b090acf6a). cargo test --release: 39 of 39 (28 unit, 11 pack).

CheckResult
Rust CPU reference (igneum-pow)the packs by construction; verify 0.631 ms per unit (avg of 20), cold 0.67 to 0.81 ms, 4,096 items per unit, cache fill 179 ms; acceptance 1.3 to 3.4 ms per candidate
Apple Metal, natively (proto-metal/igneum-bench, Swift v2 generator)--export-pack igneum-genesis memory-hard: GPU cache == CPU cache, Metal cross-check PASS 3 of 3 warps, instruction list and 96 vectors identical to the Rust pack; closed-form exports of igneum-genesis, igneum-hourly, igneum-census-2026-10-03/22, /37, /51 (the last three have attempt 0 rejected: (b) r7, (c) 119.74 distinct, (b) r4; attempt 1 accepted, ids 22ed0609d079f4cf, 947705cc4eb1df0a, 9869afcc028bf9f1): instructions, seed words and 96 vectors identical to Rust on all five; fuzz --fuzz 2000 --fuzz-seed igneum-fuzz-gen2-2026-10-04: 2,000 of 2,000 PASS, 8,000 warps, loads per hash 128 to 128, compile avg 21.8 ms, wall 91.4 s (proto-metal/TESTS.md section 9)
CUDA through the clang emulation shim (proto-cuda/emu/emu.sh, --batch-log2 13 --block-warps 2)all four packs OVERALL PASS: dataset self-test, 3 warps standalone, 2 warps per block in batch; memory-hard packs cache check 67,108,864 of 67,108,864 words, host fill 174 to 178 ms
OpenCL through the clang emulation (proto-opencl/emu/emu.sh), sub-group 32 local exchange and wave64 sub-group shuffleigneum-genesis-mh and igneum-devnet-v4-epoch0: 96 of 96 in both configurations, fingerprints f2a95d5bb84d961e and 8e22ad069cb2a8c3 at 2^13, identical across configurations
Apple OpenCL on the M5 Max (proto-opencl/host.c)all four packs: cache check PASS, 96 of 96 standalone and in batch (also --group-warps 2), fingerprint f2a95d5bb84d961e at 2^13 = the emulator's; 2^24 fingerprints 25f96e7dce90bd4e (genesis-mh), 3cc4fbf90fa6366c (devnet); rate 27.5 to 27.9 Mhash/s, 14.1 to 14.3 GB/s useful on every pack (version 1 genesis: 45.0 at 80 distinct loads; the census projected 28 at 128)
igneum-census, 20,000 programs, --gen v2 --warps 64, memory-hard day 2026-10-03, 8 threads, 254.8 srejected 5.225 percent (static 4.130, dynamic 1.095), 1.0551 candidates per epoch; accepted programs: distinct addresses per hash mean 127.887, min 120.127, p1 126.897, p50 127.999, max 128.000; static loads 128 on every program (census-v2-20k.tsv and its summary in the session scratchpad, not checked in). Against the 100,000-seed figure of 3 October: 5.14 percent
devnet-v4 node and miner (vendor/igneum-node-v4, path dependency bumped to igneum-pow 0.2.0, engine name v2)cargo build --release -p kaspad -p igneum-miner --features igneum-pow into vendor/igneum-node/target-integration (1 min 17 s warm): release/igneumd 40,480,112 B, release/igneum-miner 7,932,880 B (07:41 UTC); cargo test --release -p kaspa-pow --features igneum-pow 11 of 11; Windows cross-build (proto-cuda/windows-node/cross-build.sh vendor/igneum-node-v4 6, 4 min 53 s): target-integration/x86_64-pc-windows-gnu/release/igneumd.exe 50,179,072 B, igneum-miner.exe 10,065,920 B (libstdc++-6.dll import as before)
2-node test network on the real engine (ports 29000 to 29012, /tmp/igneum-gen2, igneum-devnet-900, IGNEUM_DEVNET_GENESIS_BITS=0x1f010000, IGNEUM_POW_EPOCH_BLOCKS=100, IGNEUM_POW_EPOCH_LEAD=20, one 3-thread CPU miner per node for 300 s)338 blocks accepted on both nodes, 0 rejected, 0 invalid, sink identical at 10 of 10 samples; four epochs crossed (DAA 0, 100, 200, 300; epoch seeds 234e08..., d3f427..., de316c..., 971384..., all attempt 0, ids 8f8806638d59850f, c015349db63beb2c, d7d52120407a0b69, 512527bb7a528476), program and cache ready in 192 to 284 ms on the miners, 4 cache builds per node; m1 158 and m2 180 blocks at 0.046 MH/s each; one WARN per node (eth JSON-RPC port 26790 held by the live devnet node, harmless)

Not done: no NVIDIA or AMD hardware has run a version 2 pack (the RTX 5090's 192 of 192 and the gfx1036 run of 3 October were version 1; the kernel text is unchanged); the edge, stats, determinism and memcheck sections of TESTS.md were not re-run (they do not depend on the generator); the live devnet (v3, version 1 programs) was not touched, so the cut-over is where version 2 goes live; proto-metal/main.swift carries the version 2 port uncommitted next to the hot-swap working-tree changes (not in this agent's file list), and the Apple M5 Max app's Metal worker must be rebuilt from it before the cut-over or Mac GPU shares will fail the CPU re-check; the v4 binaries above were built from the worktree as found, which also holds another agent's uncommitted finality floor change (2/3 of total, O-3.15); the GPU prepare hot-swap path was not exercised here (CPU miners only). The ten non-load weights and the 6-sigma bias threshold remain prototype values (spec 1.16).

-

2026-10-04 finality floor 2/3: the total-weight floor raised from 17/30 to two thirds, simulator A to L re-run, attack scenarios 6A and 6B on a three-node, six-voter network (cryptographer)

+
+

2026-10-04 finality floor 2/3: the total-weight floor raised from 17/30 to two thirds, simulator A to L re-run, attack scenarios 6A and 6B on a three-node, six-voter network (cryptographer)

Decision of 4 October 2026 (the maintainers, O-3.15): a lock needs two thirds of all 30-day weight, and finality pauses whenever less than two thirds of that weight is connected and signing; the chain continues on proof of work meanwhile and the node reports it. Spec 3.3, 3.3.1, 3.7, 3.9, 3.11 rewritten; litepaper Finality and "What Igneum does not claim" updated; ledger F2, F9, F16, F18 restated and F21 added (the window bound of attack scenario 6A).

Node. Branch devnet-v4 of vendor/igneum-node (worktree vendor/igneum-node-v4, from dc749905), commit 6457ca95, two files: consensus/core/src/finality.rs (FLOOR_NUM / FLOOR_DEN 2/3, was 17/30; the Q3 arithmetic as FinalityParams::{quorum_met, floor_met, locks}, both comparisons inclusive) and consensus/src/processes/finality.rs (lock_test calls it). Build CARGO_TARGET_DIR=target-integration nice -n 10 cargo build --release -j 6 -p kaspad --features kaspad/igneum-pow, 3 min 17 s on a machine at load 3 to 13 (another agent's igneum-pow rebuild and the live devnet running). Tests cargo test --release -j 6 -p kaspa-consensus-core -p kaspa-consensus -- finality: 7 of 7 in consensus-core including the new floor_is_two_thirds_of_total_and_inclusive (4 of 6 locks, 3 of 6 does not, 2 of 3 locks, 67 of 100 locks, 66 does not, 57 does not; the total test implies the active test at every participation; a 3/3 side never locks whatever the other side's participation decays to), 2 of 2 in consensus (no_certificate_while_the_window_is_filling unchanged). The live devnet (26610, 26611, 26640, 26641, 28640, the seed relay on 26680 and observer.mjs) was never touched.

Simulator. sim/finality_v2.py: --floor f (a lock needs f x 2/3 of total; default 1.0 since this date, --floor 0.85 reproduces the 3 October tables), the +local partition mode (a side's weight table counts only the blocks it has seen since the split, as a real node's window does; the 3 October tables kept weights global), scenario L (silent weight at 25 to 45%, churn, the poisoned eclipse, 12-day partitions with local weights), H widened to 30% and 33% attackers, I given the 34% case. A to G at --quick for seeds 7, 11, 13, 17, 19 (about 1 min a seed), H to L at full length for the same seeds (H 25 s, I 13 s, J 16 s, K 400 s, L 240 s), all at nice 10. Full tables and the 0.85 against 2/3 deltas in sim/results_v2.md, "Floor 2/3".

@@ -270,21 +317,26 @@ table{min-width:560px}

The long-heal run is the measurement the 3 October harness could not make: the old floor fell at 84 s of a young window (S6A); the two-thirds floor on a full 1,800-DAA window held for 150 s and fell at 205 s, 3.25x later as the arithmetic says (2F / (13R) against F / (2R) on a young window, 2W / (15R) against W / (3R) on a full one), and it fell on both sides within 10 s of each other because a 50/50 split crosses the bound at the same moment from both ends. On mainnet the same bound is 10 days of a 30-day window at 50/50 (spec 3.3.1, sim/results_v2.md L4). What the DAG adds to the simulation: after the heal the losing side's blocks are red in the winner's view, so the crossing is sudden rather than gradual, and once either side has certified a checkpoint of its own F1 never lets it back, so the fork is permanent until an operator sets a trusted certificate (F5, not implemented).

The inclusive comparison at exactly two thirds is pinned by the integer test 3 x signed >= 2 x total and the unit test (4 of 6, 2 of 3 lock; the 3 October S6B run had already measured the active test passing at exactly 2/3 with 4 of 6 equal voters); the devnet's 4 side sat at 67.9% rather than 66.67% because block counts are Poisson, and locked at the first checkpoint after the cut.

Notes. (1) The v4 node logged "PoW rejected ... by igneum-lottery-v1-bound" about five times a second per node (2,952 lines on n0 over 6A) although the override carries skip_proof_of_work and the six miners saw every submission accepted; the window held exactly 1,800 blocks of weight on every node and each side's DAA advanced at 3 per second as planned, so the lines did not move the measurement, but what the v4 pipeline is re-checking there is a question for the consensus engineer before the v4 cut-over (30 of a sample of 200 rejected hashes were later accepted on the same node). (2) The repo harness tools/finality-attacks/run.mjs s6 criterion text and the s5 "below the 56.7% floor" pass test are now stale and should read two thirds. (3) Not done: the two-hour presence window and a 30-day window at mainnet length; the first-month gate under the new floor is unchanged (min_daa = window). (4) The harness's 60-s heal window (6A, 6B) is shorter than the connection manager's redial backoff for a --connect peer after a cut, so a healed proxy does not mean a reconnected n0 inside it; the long-heal run used 300 s and n0 redialled at 59 s after the gate reopened. (5) Stop everything: every node, miner and proxy of the three runs was stopped by the harness at the end of each run; ports 29200 to 29299 were free afterwards (lsof 0 listeners).

-

4 October 2026, proving v0 on the RTX 5090: first GPU proof of an Igneum block (WSL2, SP1 6.8.1 cuda)

+
+

4 October 2026, proving v0 on the RTX 5090: first GPU proof of an Igneum block (WSL2, SP1 6.8.1 cuda)

Machine: the maintainers' Windows 11 PC, RTX 5090 (32,607 MiB, driver 617.14), 16 cores and 45 GB visible to WSL2 Ubuntu 24.04, mining paused. Package proving/windows-wsl2 (SETUP-PROVER then PROVE-BLOCK), host igneum-prove-host built with the cuda feature, SP1_PROVER=cuda, sp1-gpu-server 6.8.1 on device 0. Fixture block-78-increment (chain 4463, 2 transactions, 10 accounts). Run id prove-<pc>-20261004-084838.

StageRTX 5090Apple M5 Max CPU (3 October, loaded)
native re-execution0.0003 s, state root MATCHES the fixture0.0004 s, matches
setup (one per program id)23.23 s20.55 s on the RTX 5090 machine's CPU; Mac not timed separately
execute626,876 cycles, prover gas 844,704, 0.19 s, 14 cycles per EVM gas626,246 cycles, 0.15 s on the RTX 5090 machine's CPU
core proofprove 1.4 s, 7,317,217 bytes, verify 0.221 s, VERIFIEDprove 22.0 s, 7.3 MB, verify 0.16 s
compressed proofprove 2.7 s, 1,272,769 bytes, verify 0.038 s, VERIFIEDprove 55.7 s, 1.27 MB, verify 0.03 s

Reading: 15.7x on core and 20.6x on compressed against a loaded laptop CPU. The block is far below one SP1 shard, so these are the fixed per-proof overheads of the proof system on this card; the throughput number needs the larger fixtures (proving e2e standard). Post-state root and receipts root identical to the node's on every stage. Two defects, neither in the proof: the host aborted (exit 134) AFTER writing and uploading the results, in sp1-cuda's destructor outside a Tokio runtime; and the host was silent for ten minutes between the core and compressed stages with the card idle. Ledger P20. Setup on the RTX 5090 machine needed three package fixes found only by running it on Windows: protobuf-compiler in the apt list, the WSL distro check (UTF-16 output), the elevated window closing; and WSL2 itself needed bcdedit /set hypervisorlaunchtype auto on a PC whose BIOS already had SVM on.

-

4 October 2026, devnet v4 cut-over: generator v2, 2/3 floor, three nodes and a seed on a fresh chain

+
+

4 October 2026, devnet v4 cut-over: generator v2, 2/3 floor, three nodes and a seed on a fresh chain

Sequence (UTC): seed re-staged from 6457ca95 (build 55 min on the 2-vCPU VM, 08:55 to 09:54); node 1 stopped and the v3 database moved aside at 10:05:30, igneumd v4 up at 10:05:31 with the execution layer; observer peer and observer.mjs restarted on fresh appdirs at 10:06:10; seed switched with switch-v4.sh at 10:06:28 and synced at 10:07:38 (blocks=2, peers=1); Mac Metal miner (generator v2 port, prepare 1) first accepted block at 10:07:35; the RTX 5090 machine joined at 10:10:55 (protocol version 12) and its first blocks followed within the minute. Block rate went from about 1 per second (Mac alone, difficulty easing 9.1% a block from the 134M genesis value) to about 2 per second with the 5090; the live page followed from block 0 with 9 identities after five minutes. First NVIDIA card to mine a generator v2 program; CPU re-check passed on every Mac share. One launcher defect found only on Windows: "$machine:$vendorName" in igneum-common.ps1 is a drive-qualified variable to PowerShell, so the file failed to parse (fixed, braces). The first finality lock is due at DAA 7,200, two hours after the v4 genesis; the first hourly swap at DAA 3,600.

-

4 October 2026, one-click Windows workers: what the Apple M5 Max could measure (no NVIDIA GPU here)

+
+

4 October 2026, one-click Windows workers: what the Apple M5 Max could measure (no NVIDIA GPU here)

Package 0.3.0 replaces the build-on-the-PC workers with two prebuilt exes (proto-cuda/nvrtc/worker.cpp: driver API + NVRTC loaded at run time; proto-opencl/host.c --pack: OpenCL.dll loaded at run time, pack read at run time). Both cross-compile with Homebrew mingw-w64 16.2 and import only KERNEL32 and the Universal CRT (1,117,184 and 78,336 bytes stripped). The NVRTC DLLs (12.8.93) add 93 MB to the zip. Checks run on the M5 Max, same protocol script for both (proto-cuda/nvrtc/emu/serve-check.sh: jobs on pack A, a background prepare of a second pack, the swap, a job after the swap, 15 to 17 found hashes against igneum-pow hash-bound):

WorkerHow it ran hereFirst pack (cache / dataset / self-test)Prepare of pack B (reported)Verdict
igneum-worker-cuda (emulation backend: pack kernels on host threads, NVRTC stand-in)nvrtc/emu/test.sh157 / 4,758 / 1,702 ms8,413 ms (cache 132, dataset 4,759, check 1,671)PASS, 17 of 17 sampled hashes, source check PASS for 4 files
igneum-bench-cl --pack (Apple OpenCL 1.2, built against a different placeholder pack)proto-opencl/test-generic.sh53 / 289 / 1,588 ms2,083 ms (build 212, cache 25, dataset 197, check 1,387)PASS, 15 of 15 sampled hashes

The self-test times are dominated by reading the 256 MiB cache back and hashing it on one CPU thread (FNV-1a 64 over 2^26 words); the emulation's dataset build is 256 host threads over 2^24 items and says nothing about a GPU. Nothing NVIDIA was measured: the first NVRTC compile, cubin load and hash rate on the RTX 5090 are owed from the RTX 5090 machine run (proto-cuda/windows-app/TEST.md lists the lines to copy here).

-

4 October 2026, first hourly program swap on the live devnet: compile-ahead, no pause, two cards

+
+

4 October 2026, first hourly program swap on the live devnet: compile-ahead, no pause, two cards

Live devnet v4, epoch boundary at DAA 3,600 (10:05:07 UTC). The node announced the next seed once the sink was 150 DAA past the seed score (next_epoch_seed, confirm = lead/4); each miner sent prepare to its worker and the worker built the next program in the background while the current one mined.

MachinePrepare sentCompileSwap at 3,600RestartRate before / afterRejected
Mac M5 Max (Metal, prepare 1)449 DAA before the boundary82 ms0.01 ms, resident 2 programsnone26.7 / 26.7 MH/s0
RTX 5090 (CUDA, nvcc in the background)same template1,285 ms (nvcc 1,129, cache 4, dataset 23)0.00 ms, resident 2 programs 2 datasetsnone121.8 / 123.4 MH/s0
AMD Radeon integrated (OpenCL)samepreparedno restartnone2.74 / 2.74 MH/s0

Reading: the compile-ahead rule (3 October 2026 decision: never restart every miner at once) holds on real values with three vendors; the hash rate is unbroken through the boundary and the launcher's exit-42 rebuild path was not used (rebuilds 0). The next boundary is DAA 7,200, which is also the first finality lock (weight window 7,200).

-

4 October 2026, proving: devnet v4 shards on the Apple M5 Max CPU, loaded machine (execution-engineer, proving)

+
+

4 October 2026, proving: devnet v4 shards on the Apple M5 Max CPU, loaded machine (execution-engineer, proving)

Machine: Apple M5 Max (18 cores, 64 GB), macOS Darwin 25.6.0, load average 38 to 47 during the runs (the live devnet node and Metal miner, another agent's cross-builds, this agent's exports), everything under nice -n 19. Toolchain: SP1 v6.8.1 (cargo-prove c84ada1, succinct rustc 1.96.0-dev, circuit v6.1.0), sp1-sdk 6.8.1 CPU prover, revm 43.0.3, alloy-trie 0.9.8. Code: proving/igneum-prove at the "Proving fixtures: blocks of one, two and four shards" commit: two guests (shard program id 0x7b274fc9..., aggregator id 0x36e952f0...), port of igneum-exec b7fca5a0. Fixtures: proving/fixtures/block-{338,341,344} cut by igneum-prove-export from tools/prove-fixtures/seq.json (a private one-node simnet, execution-layer b7fca5a0 binaries whose exec crate is byte-identical on devnet-v4; the devnet-v4 worktree had another agent's uncommitted edits and was not built), which replayed all 346 segments from genesis and matched every node state root (final root 0xe0f269dc...); block-56-transfers-3shards is the v0 block 56 cut at a test budget of 200 pgas. S_p = 7,500,000 pgas (provisional, B_p / 4).

Statement per shard: from the carried-in position and a witness of the touched accounts, slots and trie nodes (checked against the pre-root), execute the shard's transactions and commit the post-root, the shard's receipts root, gas, pgas, the carry links and the prover's payout address; the aggregator verifies the shard proofs in order and commits the block. The host checks the native cut (shards chain and sum to the block) and rejects three tampered witnesses before any proof, on every fixture.

FixtureTxsEVM gaspgasShards (pgas each)Witness per shard: accounts / slots / leaves / hashesInput bytes per shard
block-338-shard1 (3 modexp calls of 652 iterations, 6 transfers, 2 Counter increments)111,390,7736,751,5681 (6.75 M)19 / 3 / 24 / 1321,447
block-341-shards2142,564,83813,499,3602 (6.75 M, 6.75 M)11 / 1 / 12 / 17; 16 / 3 / 22 / 1218,372; 20,335
block-344-shards4 (near B_p)204,947,16826,994,9444 (6.75 M each)11 / 1 / 12 / 17; 7 / 1 / 8 / 18; 7 / 1 / 7 / 21; 16 / 3 / 23 / 1018,371; 17,125; 17,150; 20,362
block-56-transfers-3shards (test cut at 200 pgas)363,0006003 (200 each)4 / 0 / 5 / 0; 2 / 0 / 1 / 4; 2 / 0 / 1 / 54,298; 3,671; 3,720
@@ -294,7 +346,8 @@ table{min-width:560px}
StageProve sProof bytesVerify sVerified
setup (prover client plus two key setups)39.4 to 60.6 (keys 3.3 + 3.2 of it; the rest is the client)
shard 0: core83.17,310,2570.368yes
shard 0: compressed272.31,272,8970.075yes
block mode, shard 0: compressed336.91,272,8970.068yes
block mode, shard 1: compressed305.41,272,8970.066yes
block mode, shard 2: compressed245.31,272,8970.064yes
block mode, aggregation over the 3 shard proofs (recursion, deferred proofs)244.51,272,9090.084yes, shard program id and claim checked
block mode, end to end (first shard proof to the verified block proof, 10:07:22 to 10:26:21 UTC)1,139
RTX 5090 (PROVE-SHARD.bat)shard at S_p: execute, core, compressedtwo-shard block end to endfour-shard block end to end
pending

Reading: the shard at S_p is 60 M cycles on the prototype table, 9 cycles per pgas against the unit's 1,000 (the modexp entry is about 100x its SP1 cost: R1, one number); a plain transfer shard is 1,400 to 1,600 cycles per pgas because the 200-pgas intrinsic charge carries the fixed cost of the witness check and the two root computations. The aggregator statement is 1.5 to 1.7 M cycles (bincode, an unpatched sha256 of each shard's public values, the keccaks), small next to a shard. The CPU proof times are 3.8x and 4.9x the 3 October v0 numbers on a comparable statement, on a machine three times as loaded; the GPU row stays empty until the RTX 5090 machine runs. The devnet was not touched; the simnet ran on ports 29300, 29301 and 29390 and was stopped.

-

2026-10-04, fast time (60x test profile), Linux cross-compile from the Apple M5 Max, CI on every push (consensus-engineer)

+
+

2026-10-04, fast time (60x test profile), Linux cross-compile from the Apple M5 Max, CI on every push (consensus-engineer)

Machine: Apple M5 Max, 64 GB, shared with four other agents and the live devnet (load 40 to 76 throughout), every job at nice 19 with at most 4 cargo jobs. The live devnet (26610/26611, 26640/26641, 28640), the Metal worker and the seed's <server path> were not touched.

Fast time. infra/fast-time/override-60x.json is the devnet with every clock-like consensus parameter divided by 60 and every block count unchanged (infra/fast-time/README.md lists each field and why it scales or not). The hourly program epoch and its lead are now consensus parameters carried by the override file (pow_epoch_blocks, pow_epoch_lead, plus pow_day_ms for the dataset day; devnet-v4 a5ef8b07, devnet defaults unchanged: kaspa-consensus-core 79 tests, kaspa-pow 7, igneum-pow 39 pass, and a new test reads the 60x file and checks every rule against DEVNET_PARAMS). Proof (infra/fast-time/simnet.mjs, three devnet-v4 nodes on ports 29500+, igneum-devnet-950, three vmine voters sharing 1 block/s, one real-hash CPU miner thread): next epoch seed in the template at 56.1 s (DAA 53), program swap at 65.1 s wall (DAA 60; the CPU miner's new program and cache ready 397 ms later), first finality lock at 185.5 s wall (checkpoint 5, blue score 150, DAA 149; checkpoint 4 sat one DAA under min_daa 120), sinks identical on all three nodes. The devnet reaches the same two events at DAA 3,600 and DAA 7,200 plus a checkpoint.

Harness run, same binariesDevnet profile60x profile (--fast-time)
tools/finality-attacks s3, dishonest aggregatorscatalogue 32 min at SCALE 0.6 on the 3 Oct node (above); on today's rule the window fills at DAA 7,200 = 20 min at 6 blocks/s before any lock113 s wall: 16 locks per node, 0 conflicting certificates, lock hashes agree, median lock latency 1,018 ms, PASS
tools/harness s3, partition and heal (in-process simulator of the devnet-v4 line)983 s wall, four cuts of 120 / 600 / 1,800 / 3,700 virtual s (46 / 151 / 400 / 831 s wall), all PASS43 s wall, three cuts of 10 / 30 / 62 virtual s (18 / 20 / 26 s wall), all PASS; the 62-s cut beyond the 60-s merge depth converged with a 34-block reorg
@@ -302,22 +355,28 @@ table{min-width:560px}

Linux cross-compile. infra/cross/build-linux.sh: cargo-zigbuild 0.23.4 with zig 0.17.0 (brew install zig, cargo install cargo-zigbuild, rustup target add x86_64-unknown-linux-gnu), target x86_64-unknown-linux-gnu.2.36 (Debian 12 on the servers), -p kaspad -p igneum-miner --features kaspad/igneum-pow, target dir vendor/igneum-node/target-linux. Cold build: 1,856 s (30 min 56 s) at 4 jobs, nice 19, on this loaded machine; rocksdb (librocksdb-sys C++), lz4, blst, secp256k1 and the execution layer's crates all linked through zig; no crate failed, so cross was not needed (Docker is not installed here anyway). Output: ELF x86-64 PIE, igneumd 46,883,304 B and igneum-miner 8,978,424 B, dynamically linked against libc and libm only. Verified on the seed node (Debian 12, glibc 2.36, 2 vCPU) in <server path>: igneumd --version = igneumd 2.1.0, igneum-miner --help prints its usage, and a 60-s run of the cross-compiled node on igneum-devnet-951 (the 60x profile at genesis bits 2^16, real proof of work) with the cross-compiled miner on one CPU thread: the miner adopted the node's 60-block epoch from the template, built its 256 MiB cache in 395 ms, found 7 blocks at 0.011 MH/s, all 7 accepted by the node's own PoW check, 0 rejected (the x86 build of the lottery hash agrees between miner and node; neither binary exposes a standalone vector check). Against the alternatives: the seed's own build took 55 min on its 2 vCPU (4 Oct 2026, above), the builder VM 10 to 25 min on 8 vCPU plus its creation and deletion. BIN_SOURCE=mac is wired into infra/cloud-devnet/provision.sh (no builder VM, build/bin from the cross-compile) and infra/seed-nodes/stage-v4.sh (upload to <server path>, install as before).

CI. .github/workflows/ci.yml runs on every push and pull request of the private repository: igneum-pow cargo test --release and the igneum-census build (49 s), the two simulators' --quick modes under a 120-s timeout (49 s for the job; sim/finality_v2.py --quick is now a true smoke run, 149 s at nice 19 on this loaded Mac and under 40 s on the runner, was 745 s; sim/difficulty/sim.py --quick is new, 36 s here), the site build, an internal link check of site/*.html (151 links, 0 broken) and a gh-free identity grep of the public export list after the generic scrub (tools/ci/identity-check.sh, tools/ci/forbidden-strings.txt: 157 files, 0 hits). First run green: https://github.com/igneum-network/igneum/actions/runs/37193811336, 54 s from trigger to completion. The node fork is gitignored and too big for the free runners today; the workflow says so.

Not done: igneum-harness-sim's per-block cost on the devnet-v4 line (about 70 ms here against 3 ms on the ordering-layer branch, the execution layer's follower) is what still bounds the harness, not the clocks; the fast-time presence window floors at one checkpoint; the GPU workers were not run on fast time (the CPU miner proved the swap).

-

4 October 2026, first finality lock on the live devnet: checkpoint 242 at 77.4% of all weight, two hours after genesis

+
+

4 October 2026, first finality lock on the live devnet: checkpoint 242 at 77.4% of all weight, two hours after genesis

Live devnet v4 (genesis 09:05 UTC). The weight window and min_daa are 7,200 DAA seconds, so no checkpoint could lock before DAA 7,200. The first checkpoint past it, index 242 (block 59b4a314, blue score 7,261), locked at 11:03:44 UTC with 77.4% of total weight and 77.4% of active weight signed, 12 aggregated votes from 17 vote keys (two RTX 5090 machines with 8 identities each, the Apple M5 Max's Metal miner, the integrated AMD chip's identities), floor 2/3. The certificate (23 headers) was stored and carried in block 1e2439a1; observer.mjs logged checkpoint_locked 0.7 s after the miner's own LOCK line. The floor was raised to 2/3 this morning (O-3.15); this is its first live lock. Difficulty at the moment of the lock was mid-oscillation (93M to 99M, see the oscillation finding), which did not affect voting.

-

4 October 2026, the gfx1036 worker fault and what the Apple M5 Max could and could not reproduce

+
+

4 October 2026, the gfx1036 worker fault and what the Apple M5 Max could and could not reproduce

the RTX 5090 Windows rig (RTX 5090 plus the Ryzen's integrated gfx1036), package 0.3.0 prebuilt workers. The CUDA worker compiled the pack with NVRTC (after -default-device) and mined at 124.2 MH/s, equal to the nvcc-built worker, 0 rejected, CPU re-check clean. The OpenCL worker (igneum-worker-opencl.exe --pack, path prebuilt-generic) self-tested PASS and mined correctly at 3.3 MH/s for 577 s (8 accepted blocks), then from about 600 s every job "completed" in 0.5 ms with no hash: 906 jobs became 56,384 within 30 s, the miner reported 4.3 GH/s inside jobs and the dashboard over 1 GH/s, with no error line, no exit and no restart. the three-card Windows rig's cl.exe-built worker on the same host.c serve loop ran over an hour without this.

Root cause, as far as it can be stated: the AMD runtime kept answering clEnqueueNDRangeKernel, clWaitForEvents and the blocking clEnqueueReadBuffer with CL_SUCCESS while running nothing, so the loop walked its chunks at memory speed and reported the stale output buffer as a finished job. What flipped the runtime into that state at 600 s is not visible in the logs and the job path itself leaks nothing (one event per chunk, created and released; verified below). The two plausible triggers are a device reset of the integrated GPU with the runtime swallowing it (the generic path is the only one that self-tests, which reads 256 MiB back and runs the three vector warps at start; an hourly prepare would do the same work again on a second queue while jobs run) and a runtime limit reached after about 900 jobs. Neither reproduces on Apple OpenCL:

Run on the M5 Max (Apple OpenCL 1.2, pack-a, 2^22 nonces per job)JobsJob time ms (mean, min, max)FaultsLive objects at the end
20-minute soak of the shipped generic worker3,365412 / 305 / 5910not counted (that build had no counters)
1,200-job soak of the hardened worker (events and buffers counted)1,200411 / 315 / 54900 events, 4 buffers (cache, dataset, out, init words); 1,200 events created and released
the same worker with IGNEUM_FAULT_TEST=6 (the dispatch skipped from chunk 6 on, the runtime "succeeding")6 real + 11: the output buffer is unchanged since the previous dispatch, exit 3

So the fix is defensive at three levels (commit 112acf6 and vendor devnet-v4 f9392600): the worker treats every OpenCL error in the job path as fatal, requires CL_COMPLETE on the dispatch event, refuses a chunk 20x faster per nonce than the running mean or an output buffer unchanged since the previous dispatch, prints live object counts every 200 jobs and exits 3 on any of these; the miner kills and restarts a worker whose job time per hash drops under 1/20 of the mean or whose interval rate exceeds 10x the mean before it, rolls its counters back to the last report and prints WORKER FAULT; the launcher shows worker fault and restarting for that card instead of a rate. The next gfx1036 run says which guard fires first; that line is the diagnosis the Apple M5 Max cannot give.

-

4 October 2026, a node 60 s behind the clock is silently dead (the RTX 5090 Windows rig's first app install)

+
+

4 October 2026, a node 60 s behind the clock is silently dead (the RTX 5090 Windows rig's first app install)

the RTX 5090 Windows rig came back from a power cut with its clock 60 s slow. igneumd connected, then logged HandleRelayInvsFlow flow error: the block timestamp is too far into the future: block timestamp is ... but maximum timestamp allowed is ... for every relayed block, processed 0 blocks and the app sat on "waiting for a peer" with nothing to say. The consensus rule is right (a header may not be ahead of the node's clock by more than the tolerance, check_block_timestamp_in_isolation); the reporting was not. The node prints one WARN per relayed block with two millisecond numbers and never the one line a person needs.

WhatWhereNow
The app reads that WARN, takes block timestamp - maximum allowed as a lower bound and shows "Your clock is at least N seconds behind the network; mining cannot start until it is fixed" on the node card with a Sync clock button (macOS sntp -sS time.apple.com under an administrator prompt, Windows w32tm /resync elevated, Linux chronyc makestep / timedatectl) and the manual stepsapp/igneum-app/src/engine.rs node_line, resolve_clock; platform.rs sync_clockdone
Independent of the node: once blocks arrive the engine samples the latest block's timestamp through the node's Ethereum JSON-RPC every 10 s and takes the median of local minus block time over the last 9 (behind only; a stalled chain reads as ahead); and an HTTPS Date header from the downloads host at start and every 10 min (either direction, 1 s resolution). Over 5 s: a warning. Over 10 s (the consensus bound): the Start button is blocked and running miners are heldengine.rs watch_line, update.rs latest_block_time, https_timedone
The node itself should log one clear line at WARN, once, not per block: clock skew: local time is N s behind the median peer block time (and the same for ahead, when its own templates are refused by peers). Filed for the devnet-v4 worktree owner; the app does not patch the nodedocs/plans/node-changes.mdfiled

Checked on the Apple M5 Max with a fake 60 s skew (IGNEUM_APP_FAKE_SKEW=-60): the banner, the node card, the blocked Start button and the held miner all showed; with the real clock the HTTPS source read +0.4 s and the block source agreed.

-

4 October 2026, first machine on the Igneum Miner app: the RTX 5090 Windows rig's RTX 5090 at 118 MH/s, via Setup.exe

+
+

4 October 2026, first machine on the Igneum Miner app: the RTX 5090 Windows rig's RTX 5090 at 118 MH/s, via Setup.exe

the maintainers' second PC (a clone of the first; the app's per-install machine id 1ccfe586 keeps its keys apart), installed from the runner-built Igneum-Miner-Setup-0.3.0.exe (unsigned, SmartScreen "run anyway"), the one-click package: prebuilt NVRTC worker, no toolchain on the machine. First attempt sat at "waiting for peer": the RTX 5090 machine's clock was 62 s slow after a power cut and igneumd rejected every relayed block ("the block timestamp is too far into the future"; the 10-s skew bound from the hardened timestamp rule) and processed 0 blocks for 12 minutes with no visible reason. Clock set by hand; the node caught up (46 blocks in the next 10 s at 11:27:53 UTC), the 5090 started inside the app and ran at 117 to 119 MH/s with 34 accepted blocks in the first minute, CPU re-check OK on every share, the integrated AMD chip at 3.3 MH/s beside it. Two defects from the run, both fixed in the app the same hour: no clock-skew warning (now detected from the node's warning, block timestamps and an HTTPS Date header; Start is blocked above 10 s), and the node card stayed on "syncing" after the late catch-up while the miner was already accepted (state now re-derived every poll).

-

4 October 2026, difficulty rule v2: the live oscillation, its cause, the DAG replay, the fix behind a height switch (consensus-engineer)

+
+

4 October 2026, difficulty rule v2: the live oscillation, its cause, the DAG replay, the fix behind a height switch (consensus-engineer)

Machine: Apple M5 Max shared with four other agents' builds (load average 7 at the start, 184 to 442 from 11:40 UTC on); every simulation and build at nice 19, cargo at 4 jobs; the live devnet (26610/26611, 26640/28640, observer.mjs, the Metal miner) untouched, read through the observer node's wRPC only. Worktree vendor/igneum-node-v4, branch devnet-v4, built in its own target/. Everything in docs/analysis/difficulty-2026-10-04-oscillation.md; ledger M24; spec 2.3 revised. Live finding (devnet v4, UTC): the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) (RTX 5090, 122 MH/s, 8 identities through its own node) with the Apple M5 Max (26.7 MH/s) and a Radeon (2.8) from 09:11; the RTX 5090 Windows rig (RTX 5090, 124 MH/s, 8 identities through the Apple M5 Max node) from 10:12:17, off 10:31:25 to 10:35:19; both PCs restarted at 11:00 for the machine-id package (they are clones with one computer name and had signed with the same vote keys). Difficulty (node convention): flat 56.7M to 67M within 1% per minute from 09:24 to 10:04; 70M to 144M in 90 s after the join; then 101.8M to 164.3M from 10:17 to 10:32 (5 peaks of 1.33x spaced 132 chain blocks, std of log difficulty 0.123, 54 to 81 blocks a minute) and 103M to 150M from 10:37 to 10:54 (4 peaks of 1.35x, std 0.072, a floor rising 110M to 127M) against a true 139M; after the epoch boundary at DAA 7,200 (11:01:52) 69.0M to 72.7M within 1.3% per minute. Stacked clamps in the observer's 2-s polls: "up 15.9%" = five 3% hardens, "down 24.3%" = three 10% eases. DAG: 6,741 blocks to 10:54, 38% of chain blocks merging two or more blues, every merged block blue. Records sim/difficulty/records/live-2026-10-04.csv (8,090 headers, pull_live.py) and live-2026-10-04-hashrate.csv (587 worker STATUS lines from the log intake, by run id and node). Cause: spec 2.3's reference lane is the whole epoch, so a step 7 minutes into the hour left it polluted for the hour; the short lane read 11 to 25% above it; the 25% trigger flipped on the short lane's noise; the clamps turned each flip into a ramp. The DAG's bursts widen the short lane's noise and the stacked clamps steepen each flip; neither starts it. The 3 October simulator stepped at epoch boundaries, so it never saw it. Replay: sim.py --live, a DAG model (miners on two nodes with igneum-miner's template staleness, templates stamped by the node, GHOSTDAG, the rule as igneum_difficulty_bits runs it, the sampled window per mergeset), one scale fitted to the merge fraction. Join window 10:20 to 10:31, 3 seeds: std of log difficulty 0.115 against the record's 0.134, 4.3 peaks of 1.31x against 4 of 1.37x, 110.7M to 167.2M against 101.8M to 164.3M, 56.7 to 73.7 blocks a minute against 59 to 72, 22 lane flips, the short lane ruling 38% of the time. Whole polluted window: 0.118 against 0.123, 5.3 peaks against 5. The chain-only simulator with a 1.85x step 10 minutes into an epoch: std 0.136 to 0.189 with 96 to 142 flips (v1). Candidates on the live replay (join window, 3 seeds, std of log difficulty / lane flips): v1 0.115 / 22; short lane 240 0.125 / 10; 360 0.107 / 11; ease clamp 3% 0.113 / 20; clamp once per DAA second 0.132 / 21; hysteresis leave at 10% 0.090 / 2 (short lane ruling 78%); median of three 0.124 / 15; soft trigger 0.110 / 13; reference window 1,200 0.108, 900 0.081, 720 0.055, 600 0.024 / 0, 480 0.021 / 0. Adopted: v2 = the reference lane is the epoch lane over the newest 600 DAA score of the epoch, the sampled long lane not consulted: 0.026 / 0, mean 142.6M against 139M true; rejoin window 0.031 / 0; chain-only 0.022 to 0.081. Cost (synthetic set seed 7, v1 / v2): x50 settled 61.7 / 65.5 s (standard under 90), /50 628 / 753 s (worst gap 32 / 62 s), epoch +-30% settled 144 / 143 s, hop10 211 / 200 s, polluted overshoot 0.180 / 0.089, warm-ups equal, steady std 0.038 / 0.049 with blocks-per-minute CV 0.135 / 0.130. Attacks (seeds 7 to 9, v1 / v2): greedy hopper at most +1.5% / +2.5%, with a 60 s dwell -4.0% / -1.5% at 100%; pulsed rental -96.4% / -96.3% with weight per hash 0.262 / 0.262; forger drift +0.4 to +1.1% / -0.8 to +0.5% (worst seed 2.7% / 1.5%); short-lane oscillation gain 3.75 / 3.29; epoch games 0.0 to +0.7% / 0.0 to +0.4%; polluted window settled 287 to 329 s / 288 to 331 s; base profiles 3-seed up50 154 / 150 s, down50 762 / 822 s, epoch30 88 / 88 s, hop10 245 / 233 s, polluted 75 / 76 s, steady std 0.042 / 0.053. Implementation (devnet-v4): difficulty_v2_activation_daa in Params (every network u64::MAX), OverrideParams, override_params, the daemon's file parser (prints the height), SampledDifficultyManager (new field, reference_window(daa_score, epoch_blocks, activation)), REF_WINDOW_V2 = 600, IgneumInputs.k_ref; infra/fast-time/override-60x.json carries the field as never. cargo test --release -p kaspa-consensus --lib difficulty: 15 pass (12 of 3 and 4 October plus reference_window_switches_at_the_activation_height, v2_reference_window_follows_a_step_inside_the_epoch_where_v1_eases_into_it, v1_and_v2_agree_in_a_steady_epoch); -p kaspa-consensus-core --lib params: 7 pass (override_params_carry_the_difficulty_v2_activation, the fast-time file test extended). Build 2 min incremental for igneumd and igneum-miner. Test network (sim/difficulty/testnet_v2.py, 3 nodes on 29600 to 29622, the 60x file with the devnet epoch, genesis bits 2^16, activation 900 on nodes 1 and 2, node 3 without it; CPU miners A from 0, B from minute 4, off at 19, back at 23): node 1 reached DAA 900 at 1,022 s; node 3 rejected the first v2 block ("difficulty of 520437997 is not the expected value of 520406991"), banned its peer and stayed at DAA 900 (901 headers, a prefix of node 1's 1,472); nodes 1 and 2 agreed on every header and the sink. Under v2 the leave eased 6,589 to 5,972 over 180 s (std 0.036, no peak), the rejoin hardened 6,154 to 8,312 within 60 s and held within 3%. The v1 phase is not readable: the load swung the CPU miners' delivered hash rate 2x on its own (difficulty fell 40% after B joined). Record records/testnet-v2-2026-10-04.csv. Repeat on a quiet machine, 30 minutes. Rollout: only igneumd changes (the Apple M5 Max build, infra/cross/build-linux.sh for the seed and the the cloud provider nodes, the Windows package for the three-card Windows rig's node); every node of a chain needs the same "difficulty_v2_activation_daa": N in its override file before the height or it forks off there. First the 12 the cloud provider nodes on their own chain (N = current DAA + 1,800, restart one by one, a miner joins inside an epoch, no flips after the height), then the devnet with N about two hours ahead: observer node, seed, Mac node 1, the three-card Windows rig's node, in that order, by the maintainers. A new network sets 0. Not done: a quiet-machine test-network run; the DAG model's red blocks and the Apple M5 Max's log series; v2 with +-500 ms stamp jitter.

-

4 October 2026, the observer stored nothing for 78 minutes, then 7,022 blocks in two minutes

+
+

4 October 2026, the observer stored nothing for 78 minutes, then 7,022 blocks in two minutes

Mac, load average 200 to 300 from other agents' simulations (uptime at 13:21 UTC: 83 / 224 / 206). The observer (tools/observer/observer.mjs, reading the Apple M5 Max's non-mining peer on wRPC 28640) kept writing live_state every 2 s, so the page said LIVE with age_s 0.1 while its newest stored block was 4,868 s old; the DAG panel showed "waiting for the first block" and one identity while the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) mined at 122 MH/s.

Measured from live_blocks (received_at minus the header timestamp, UTC):

WindowBlocks storedMean lag sMax lag s
11:30 to 11:55, five-minute slots150 to 451 each4 to 1112 to 61
11:57 to 13:150
13:15 slot (the restart at 13:18)7,0232,4874,911
13:20 slot1351084
@@ -325,22 +384,27 @@ table{min-width:560px}

What changed (commit "Observer: decoupled ingest, lag metric, per-minute by header time, feed self-check, restart loop"):

ChangeWhereMeasured after
Notifications only enqueue; a drain loop handles them in bounded batches; block flush, colour marking and certificate work on separate timers, none waits on anotherobserver.mjsqueue_depth 0
Mergesets taken from each notification's verbose data (bounded cache of 4,000); getBlock only on a miss, four in flightobserver.mjs0 RPC fetch failures in the first 5 min
live_state.observer_lag_s (now minus newest stored header time) and queue_depth; served by /api/live; the page shows "observer N s behind" past 30 s instead of "waiting for the first block"observer.mjs, site/api/live.mjs, site/live.htmllag 0.7 s at 13:27 UTC
blocks_per_minute and blocks_60s bucketed by the block's own timestamp, reseeded from the table on startobserver.mjs13:18 = 76, 13:19 = 63; max in the hour 110
Self-check: no blockAdded for 60 s while the node's block_count advances resubscribes; two failed attempts exit 2observer.mjsnot yet triggered
tools/observer/run.sh: restart loop, same env and log (/tmp/igneum-devnet/observer-mjs-v4.out)newrunning since 13:26 UTC

Open: the gap itself. Zero blocks for 78 minutes followed by every missed block arriving with its original header time is also what a stalled observer node delivering its own catch-up looks like; the lag metric now makes either case visible on the page within 30 s, and the self-check covers the dead-subscription case. Node logs for 11:57 to 13:18 UTC would settle which it was.

-

4 October 2026, the RTX 5090 Windows rig at the 14:20 boundary: a worker stuck on the previous epoch (root cause from the uploads)

+
+

4 October 2026, the RTX 5090 Windows rig at the 14:20 boundary: a worker stuck on the previous epoch (root cause from the uploads)

Run win-1ccfe586-20261004-132055 (the Igneum Miner app, package 0.3.0 workers). Sequence from the node and miner uploads: the app reinstalled and its node restarted at 13:20:29 UTC in IBD from DAA 17,881, inside epoch 4 (seed 57ac7663...); the app exported packs\devnet from that node's template at once, so both workers started on 57ac. The boundary at DAA 18,000 passed about a minute later. The CUDA miner's first templates still carried next_epoch_seed c23e65dd... within lead: PREPARE sent at 14:20:57, prepared 0.9 s later (NVRTC 151 ms, cache 68, dataset 113, self-test 511 ms), switched to the prepared pair at 14:21:28, then 60 MH/s with 8 identities and 101 accepted blocks in 271 s. The OpenCL worker reported ready 43 s after the CUDA one (14:21:39); by then every template was on c23e as the current pair and no next epoch was within lead, so the miner never sent a prepare, and the worker answered 514 jobs in a row with epoch seed mismatch (one every 0.5 s, the miner's error back-off) for the rest of the run. The message text "holds prepared epoch 57ac..." is host.c's wording for a pack read at run time, which is why the stuck worker looked like a wrong prediction: the RTX 5090 Windows rig's node announced the same next epoch (c23e) as the chain. No node on this PC predicted a different epoch, and the 57ac pack was simply the previous epoch's. Fixes: devnet-v4 miner 3bfe346f (prepare the current pair after a need line or three mismatches; exit 42 without prepare support; restart a ready worker with jobs queued and no job done for 60 s), workers emit need <epoch> <day> before the error. Not measured here: the swap time of the forced prepare on the RTX 5090 machine; the OpenCL run's "2 jobs in 154 s" were the two jobs before the first mismatch and are not a rate.

-

4 October 2026, shard proving on the RTX 5090: a full shard compressed in 10.9 s, a two-shard block aggregated in 2.2 s, all verified

+
+

4 October 2026, shard proving on the RTX 5090: a full shard compressed in 10.9 s, a two-shard block aggregated in 2.2 s, all verified

Machine: the maintainers' the RTX 5090 Windows rig (RTX 5090, 32,607 MiB; WSL2 Ubuntu 24.04, SP1 v6.8.1 with the cuda feature, the toolchain of the 4 October morning run in ~/igneum-prove), the Igneum Miner app (machine id 1ccfe586) stopping its miners for the run. Delivered as the signed job shard-benchmark (app/igneum-app/src/jobrun.rs, packaging/ota/publish-jobs.sh), which runs prove-shard.sh block-338-shard1 "block-341-shards2 block-344-shards4" and reports every RESULT line to the intake as job-<id>-1ccfe586 (node tools/jobs.mjs <id>). The Mac CPU column is the 4 October entry above ("proving: devnet v4 shards"); the Apple M5 Max proved only the 200-pgas test cut, so its shard rows at S_p are the executor alone. S_p = 7,500,000 pgas provisional; the fixtures carry 6.75 M pgas per shard.

StageApple M5 Max CPU (4 October, loaded)RTX 5090 (job id, UTC)
shard at S_p (block-338-shard1, 6.75 M pgas): execute60.0 M cycles, 9 per pgas, 6.9 s (block-344 shard 0, the same size)60,759,590 cycles, 9 per pgas, 44 per EVM gas, 1.63 s (run-20261004-173115, 17:40:20)
shard at S_p: core proof (prove s, bytes, verify s)not run at S_p (200-pgas shard: 83.1 s, 7,310,257 B, 0.368 s)8.3 s, 18,116,295 B, 0.564 s, VERIFIED (run-20261004-173115, 17:40:29)
shard at S_p: compressed proof (prove s, bytes, verify s)not run at S_p (200-pgas shard: 272.3 s, 1,272,897 B, 0.075 s)10.9 s, 1,272,897 B, 0.040 s, VERIFIED (run-20261004-173115, 18:04:44)
two-shard block (block-341-shards2): compressed proof per shardnot run11.7 s and 10.0 s, 1,272,897 B each, verify 0.039 and 0.038 s (run-20261004-173115, 18:06:50 and 18:07:00)
two-shard block: aggregation (prove s, bytes, verify s)not run (three 200-pgas shards: 244.5 s, 1,272,909 B, 0.084 s)2.2 s, 1,272,909 B, 0.039 s, VERIFIED, shard program id and claim checked (run-20261004-173115)
two-shard block: end to end, first shard proof to the verified block proofnot run (three 200-pgas shards: 1,139 s)24 s of GPU stages (setup 12.6 s, two compressed proofs, aggregation); 2 min 18 s wall with the proof saves (run-20261004-173115, 18:06:26 to 18:08:44)
four-shard block (block-344-shards4, near B_p): compressed proof per shardnot run10.6, 10.7, 10.5 and 10.2 s, 1,272,897 B each, verify 0.037 to 0.039 s (run-20261004-r3-shards, 19:01:49 to 19:02:21)
four-shard block: aggregation (prove s, bytes, verify s)not run (aggregator statement 1.66 M cycles)2.5 s, 1,272,909 B, 0.038 s, VERIFIED (run-20261004-r3-shards)
four-shard block: end to endnot run44.5 s of GPU stages (setup 12.5 s, four compressed proofs, aggregation); the block at 27 M pgas proves in under a minute on one card (run-20261004-r3-shards)
setup (one per program id)39.4 to 60.6 s (client plus two key setups)21.3 s first process (client 6.7, shard keys 14.6, aggregator keys 0.03); 12.6 s second process
GPU idle wait before the run, package download and extract, build (incremental)miners stopped 17:38:56; build 58 s (sources already compiled once); job 1,789 s wall, of which 25 min 46 s was saving proofs (below); mining resumed by itself at 127 MH/s

Job run-20261004-173115 (the run kind, prove only, as root inside the app's own WSL2 instance), log intake run job-run-20261004-173115-1ccfe586, exit 0 after 1,789 s. Fixtures captured from the devnet: block 338 (one shard at S_p, 11 transactions) and block 341 (two shards, 14 transactions). Every proof verified on the RTX 5090 machine; the three tampered witnesses per fixture (balance, storage or code, dropped account) were rejected before any proving.

What the numbers say. One RTX 5090 turns a full shard into the 1.27 MB compressed proof the chain carries in about 11 s, and folds a block's shards into one proof in about 2 s more. Against the launch target of 20 to 60 s behind the tip, a single card has 9 s of slack on a one-shard block; a two-shard block needs two cards or two rounds. The 44 cycles per EVM gas and 9 cycles per prover gas are the first measured constants for the prover-gas schedule (spec 7, provisional S_p).

What went wrong, measured. The job was silent for 24 min 4 s between the core proof (17:40:29 UTC) and the compressed stage (18:04:33 UTC), and 1 min 42 s after the compressed proof: SP1's save writes a proof straight into an unbuffered file, and with the results folder under /mnt/c every field element was one round trip across the WSL2 file bridge. The host now saves through a 4 MB buffer and prints a timed saved line, and the script keeps results on the Linux side and copies them once per stage (ledger P20). The four-shard fixture (block 344) was not run: the script read only its second argument, also fixed. Both fixes are in the package rebuilt at 18:10 UTC; the next job measures them.

Reading: pending the run. What it decides: the first S_p point (the shard stage time on the card against the 20 to 60 s proof lag of the litepaper), whether the P20 Drop fix holds on the GPU path (exit 0, no abort after the results), and the gap before the first compressed stage (the ten silent minutes of the v0 run).

-

4 October 2026, first outside machine on the devnet: an Apple silicon laptop through the Igneum Miner app

+
+

4 October 2026, first outside machine on the devnet: an Apple silicon laptop through the Igneum Miner app

A friend of the project installed Igneum Miner 0.3.1 from the DMG on an Apple silicon laptop (machine id 3a9bf309, no toolchain, no instructions beyond the five steps in the morning summary: drag to Applications, Open Anyway in Privacy & Security once, Get started, Make me an address, Start mining). Node synced from the seed and the LAN-less path (the seed at the public address first), the Metal worker reported ready and the first block was accepted within the first minutes; after 7 minutes: 33 accepted blocks, 0 rejected, 21.0 MH/s average (24.3 MH/s at the moment of the report), CPU re-check OK on every share. Node 1 counted 7 peers with the laptop connected. The log intake received its uploads every minute under the per-install id, so the machine is observable without any contact from its owner. Observed by the team; the machine is not ours, so this is the first row that is not "the project's own hardware".

-

2026-10-04 (afternoon) proving v0 end to end on a 3-node test network (Mac, CPU prover)

+
+

2026-10-04 (afternoon) proving v0 end to end on a 3-node test network (Mac, CPU prover)

Machine: Apple M5 Max, load 5 to 8 shared with the live devnet, other agents' builds and a Windows cross-build in the last minutes. Node: branch proving of the fork at 8c0cff15 (vendor/igneum-node-proving/target/release), 3 nodes on 127.0.0.1:29800+, network igneum-devnet-955, infra/fast-time/override-60x.json with skip_proof_of_work and proving_v0_activation_daa 60; three igneum-miner vmine producers sharing 1 block/s and voting; node 0 with IGNEUM_PROOF_VERIFIER = the SP1 host, nodes 1 and 2 in trust mode. Prover: proving/igneum-prove host built 14:58 (guest rebuilt with the payouts input), SP1_PROVER=cpu. Script: tools/proving-v0/run.mjs; report tools/proving-v0/report-2026-10-04.json. Second run; the first (14:08) failed at the carriage step because the template never carried the record section (fixed in 8c0cff15), everything before it identical.

StepMeasured
Activation DAA 60 reached62.8 s after start (DAA 65)
Transfer executed in chain block 6865.8 s
Shard plan of block 68: 1 shard, 200 pgas (one transfer, intrinsic only), 3 eligible keys of 67 window blocks, 3 assignees (every eligible key holds a slot), shard credit 633,911,390,000,000,000 weiidentical on nodes 0 and 1
igneum-prove-export on the chain export (68 segments)0.005 s; plan equals the node's (pre-root, post-root, links, receipts root, pgas)
igneum-prove-host --mode compressed, shard 0 of block 68execute 0.027 s, 293,603 cycles; compressed proof 61.3 s, 1,272,897 bytes, local verify 0.029 s; 70.3 s with setup
igneum-miner sign-record + igneum_submitProofRecord to node 1 (trust mode)accepted (native statement matched), 137.6 s after start
Record on node 0 over p2p (message 71)1.0 s after the submission
Carried by a block and paid on node 0 (chain block 150, carrier 0x8302cf39...)4.0 s after the submission
Node 0's verifier (SP1 compressed proof against the shard vk, statement compared)VERIFIED, 9.3 s in all (SP1 client and key setup; the verify itself 0.029 s)
Payout on all three nodes0x8cc1b0cf4062c00 wei on each; the payout address holds exactly the shard's credit; pool escrow 100.16 IGN after the payment
End to endPASSED in 150.6 s

Reading. The whole loop (plan, export, cut, prove, sign, submit, relay, verify, carry, pay) runs and three nodes agree on the payment. The exporter's cut equals the node's cut on the same trace, which is the condition for a prover to prove what the node pays. The 200-pgas shard is the smallest possible (one plain transfer); its 61 s compressed proof on this CPU is a correctness number, not a throughput number, and says nothing about S_p. The verifier's 9.3 s is nearly all SP1 setup per invocation (the pool runs one process per proof); a resident verifier would cut it to the 0.03 s verify. The trust-mode nodes carried the record before node 0 had verified it, which is the v0 limitation of spec 7.7 item 4 in one line: carriage and payout rest on the native statement, verification on the producer's pool policy.

-

4 October 2026, cloud devnet: 12 igneumd nodes in 5 locations, inter-region latency, two Singapore partitions, hash-rate steps (consensus-engineer)

+
+

4 October 2026, cloud devnet: 12 igneumd nodes in 5 locations, inter-region latency, two Singapore partitions, hash-rate steps (consensus-engineer)

Machines: 12 the cloud provider Cloud VMs (hel1 x3, fsn1 x3, ash x2, hil x2, sin x2; cx23 2 shared vCPU in the EU, cpx21 3 vCPU in the US, cpx22 in Singapore, nodes 08 to 11 ccx13 2 dedicated cores), Debian 12, chrony, private-network mode (one the cloud provider network per zone, four public gateways with NAT and one DNAT port per private node; infra/cloud-devnet/README.md). Node: igneumd 2.1.0 from devnet-v4 6457ca95 with igneum-pow 2ee37fa (the live devnet v4 build copied from the seed), network igneum-devnet-20, genesis bits 0x1e400000, 12 one-thread CPU miners with one BLS vote key each, sparse --addpeer ring plus chord (3 peers per node), finality interval 30, depth 20, weight window 7,200 DAA, floor 2/3 of total, dual-lane difficulty rule v1. Everything in infra/cloud-devnet/results/2026-10-04/ (summary.md, hop-series.tsv at 10 s, both partition directories, per-node logs).

Inter-region RTT (ms, median of pair averages, ping): hel1-fsn1 35, ash-hel1 118, ash-fsn1 135, hil-ash 75, hil-hel1 174, hil-fsn1 191, sin-hel1 188, sin-fsn1 205, sin-hil 238, sin-ash 289; inside a location 0.4 to 0.7.

Block propagation, 10-min window at 10:30 UTC, 644 blocks, 642 seen by at least 80% of nodes (arrival at a node minus the first arrival anywhere, across about 3 hops): p50 343 ms, p90 497 ms, p99 666 ms, max 2,313 ms. Per region p50 / p90 / p99: fsn1 239 / 470 / 491, ash 291 / 464 / 595, hel1 291 / 455 / 661, hil 357 / 632 / 698, sin 413 / 610 / 744.

@@ -351,9 +415,11 @@ table{min-width:560px}
StepNetwork hashDifficulty beforeFirst extreme (time after step)Settled whereRate while settling2-min rate within 10% of 60/min for 3 min
6 of 12 nodes to 4 threads0.159 to 0.226 MH/s, x1.4280.1k133.7k, x1.67 (6 min)134k, 90k, 129k, 95k over 20 min (±20%, 8-min period), then 95k to 122k47 to 83 blocks/min for 20 min, 50 to 70 after751 s
back to 1 threadx0.70115.0k75.7k, x0.66 (3 min)97k to 105k for the remaining 12 min (80k expected)40 to 57 blocks/min for 15 min, mean 49.5not within 900 s
hel1's 3 miners offx0.7597.1k51.2k, x0.53 (2 min)54k to 66k34/min in minute 1, then 45 to 68241 s
hel1 backx1.3254.1k86.6k, x1.60 (1 min)86k sliding to 78k over 17 min35 to 66 blocks/min, mean 55.1646 s

Reading. Latency: the real inter-region path is 0.3 to 0.7 s per block for 99% of blocks, under the 5-s bound behind GHOSTDAG k and well under spec 03 C1's 2-s inter-region assumption. Partition: the floor rule did what the design says (DECIDED 4 Oct 2026, O-3.15): the 15.8% side locked nothing, the 84.2% side locked every 30-s interval, no index was certified twice, and both sides were on one chain within 15 s of the heal with the minority's 420 to 500 blocks reorged out. The margin is thinner than the weights suggest: certificates carried 8 to 10 of 12 votes with everything connected (signed 66.7% to 89% of total at 14:00 UTC), so during the cut the majority locked at 66.8% twice; the missing votes are the open question (finality owner). Controller: with 12 small steady miners the dual-lane rule overshoots every step (x1.6 to x1.7 on x1.3 to x1.4, x0.53 on x0.75), swings ±20% for 20 min after a step up and then damps, and holds the rate 10 to 20% under target for 10 to 15 min after a step down; none of the settle times is near the simulator's 62 s for x50, and the /1.42 step had not settled in 15 min. The live devnet's two bursty GPU miners oscillate without damping; this network damps. Both regimes are now measured on real timestamps.

What failed: the first partition ran before the window had filled (no lock possible) and a second was added after the first lock, about USD 0.30; the script's sink-count heal criterion reported 539 and 768 s and is tip churn (replaced with the chain-removal heal time); its first-lock poll reported 807 s because it started after that wait (replaced with the journals); the Apple M5 Max hibernated on a flat battery from 11:56 to 13:16 UTC during the hop schedule, so the 4-thread phase ran 94 min instead of 15 (the scripts now hold the machine awake with caffeinate); the schedule's 4 threads gave x1.42, not x2.5. Another agent's difficulty-v2 rollout (infra/cloud-devnet/rollout-v2.sh, activation DAA 16,170) restarted every node one at a time between 14:14:40 and 14:18:05 UTC, the last 56 s of the second cut and its heal window: the cut-phase locks, the reorg depths and both minority heal times are unaffected (the minority reorgs at 14:15:47 and 14:15:51 came before those nodes' rollout restarts); the majority's first lock after the heal (448, 13 s) was on igneum-01 69 s after its own restart and carries that caveat. Finding for the execution owner: both minority nodes logged "[igneum-exec] reorg deeper than the snapshot ring; replaying from genesis" at both heals. Cost: USD 2.82 net by 14:34 UTC, USD 0.57 per hour while the network stays up (it was left running). Caveats: CPU hash rate only, one afternoon, 12 nodes not 1,000, clocks by chrony.

-

4 October 2026, correction: the 78-minute observer gap was the Apple M5 Max hibernating

+
+

4 October 2026, correction: the 78-minute observer gap was the Apple M5 Max hibernating

The "observer fell 45 minutes behind" entry left the cause open. The cloud-devnet agent's logs show the Apple M5 Max hibernated on a 1% battery from 11:56 to 13:16 UTC: node 1, the observer node, observer.mjs, the Apple M5 Max miner and every agent on the machine stopped; the two PCs, the seed and the cloud network carried the chain (no gap in the chain itself: every block the observer later stored carried its original header time). The lag-proofing stays (it is right on its own), the restart loop stays, and the public-face watch now runs from the same machine, so it also sleeps when the Apple M5 Max does; the fix is the charger and keep-awake, not software. The cloud scripts now re-exec under caffeinate -i.

-

2026-10-04 (afternoon) the app's prover loop end to end on the Apple M5 Max (Igneum Miner engine, packaged binaries, private test network)

+
+

2026-10-04 (afternoon) the app's prover loop end to end on the Apple M5 Max (Igneum Miner engine, packaged binaries, private test network)

Machine: Apple M5 Max, load 2 to 31 through the runs (other agents' builds and a Linux cross-build of the SP1 host ran alongside). Network: tools/proving-v0/run.mjs --network-only (3 proving nodes on 29800+, igneum-devnet-955, 60x fast time, activation 60, node 0 with the SP1 verifier, nodes 1 and 2 in trust mode, three vmine voters at 1 block/s). App: app/igneum-app engine (release, commit 77ea5b6) staged at /tmp/igneum-app-proving with bin/ = the proving node and miner (vendor/igneum-node-proving/target/release), the Metal worker, igneum-prove-host and igneum-prove-export (proving/igneum-prove/target/release), and an igneum-app.json whose node_override_params is the fast-time profile with skip_proof_of_work and the activation height; environment IGNEUM_APP_DEVNET_SUFFIX=955, RPC 29850, peers 127.0.0.1:29811 and 29801. Driven through its own API (setup with a pasted address 0x4343..., start, api/prove {on:true}); the Proving tile read every 5 s from api/state.

Run 1 (14:36 to 14:49 UTC, mining on the Metal worker at 12 to 20 MH/s): tile states as they happened:

Wall (UTC)TileNote
14:36:53idle, "no shard assigned to this machine in the last 60 blocks", 3 blocks acceptedthe key needs 5 blue blocks in the 120-DAA window (dust)
14:37:49idle, 5 blocks acceptedeligible from here
14:37:59proving block 140 shard 0 (0 txs, 0 pgas), assigned 10, "proving on the CPU (slow)"the first plan after eligibility assigned the key to 10 of the last 60 shards
14:40:02submitted (proved 1, submitted 1)compressed proof 107.0 s; the app's node accepted the record (verify Off: the app's node has no verifier, it relays)
14:40:04(node log) chain block 259 paid 634,083,030,000,000,000 wei to 0x4343...2 s after the submission; carried by a trust-mode node's block
14:43:22, 14:46:12blocks 268 and 447 proved (143.1 s, 115.3 s) and paid the same waythe tile still said paid 0
@@ -363,17 +429,21 @@ table{min-width:560px}
Wall (UTC)Tile
15:02:22(engine up, node restarting)
15:02:27proving block 1579 shard 0 (0 txs, 0 pgas, open), "proving on the CPU (slow)"
15:03:38submitted (proved 1, submitted 1), "block 1579 shard 0 submitted; paid when a block carries it"
15:03:49proving block 1650 shard 0 (open), paid 1, 637,452,090,000,000,000 wei (0.637 IGN)

Block 1579 shard 0: 233,576 cycles, execute 0.025 s, compressed 60.2 s, 1,272,897 bytes; node 0 shows the record carried by chain block 1655 and paid; the payout address's balance on node 0 was 163.15 IGN at the end (4 shard payouts of about 0.635 IGN each plus the mining rewards of run 1). The app's node, restarted twice, replayed the chain from genesis each time and re-applied the same three payouts (its log at 15:49:53 lists chain blocks 433, 618 and 756 paying blocks 268, 447 and 569), which is the determinism the rule needs.

Reading. The packaged loop works on a Mac with the CPU prover: 71 s from the tile saying proving to paid on the chain for the smallest shard. The two defects were in the tile's bookkeeping and the child's lifetime, not in the chain rules. The open-shard fallback is what makes a prover without mining weight useful; whether assignees should keep more of the pool is the O-5.1 question, untouched. Nothing here ran on Windows or on a GPU.

-

4 October 2026, difficulty v2 rollout rehearsal on the 12-node the cloud provider network, binaries for the devnet, the devnet plan (rollout engineer)

+
+

4 October 2026, difficulty v2 rollout rehearsal on the 12-node the cloud provider network, binaries for the devnet, the devnet plan (rollout engineer)

Builds (Mac M5 Max under other agents' load, nice 19, 4 cargo jobs, each into its own target directory seeded from an existing cache; the live binaries untouched), source vendor/igneum-node-v4 at 3bfe346f = a21ff239 (difficulty v2) plus a miner-only commit, so igneumd is the a21ff239 node: Mac arm64 144 s (vendor/igneum-node/target-v2/release/igneumd, sha256 8b0fbd27...), Linux x86-64 glibc 2.36 by cargo-zigbuild 173 s (infra/cross/out-v2/igneumd, 70751def...), Windows x86-64 by mingw 8 min 50 s (target-v2/x86_64-pc-windows-gnu/release/igneumd.exe, 27c2ce85...). Each carries the difficulty_v2_activation_daa parser; the Apple M5 Max binary printed Difficulty rule v2 from the override file: active from DAA score 123456 on a private suffix, the Linux one on all 12 cloud nodes. cargo test -p kaspa-consensus-core --lib params: 7 pass (the fast-time file already carries the field as never). Windows payload inputs pushed (payload-inputs.zip 66b4dc51...); no manifest published.

Rehearsal (infra/cloud-devnet/rollout-v2.sh; igneum-devnet-20, its own chain): N = DAA 14,362 + 1,800 = 16,170; staging the 47 MB binary to the four gateways from the Apple M5 Max then gateway to private node (the Apple M5 Max to Hillsboro ran at 32 KB/s; igneum-01 to igneum-04 server to server took 12 s); the 12 nodes rolled one at a time 14:14:39 to 14:18:16 UTC, 15 to 30 s each, every one rejoined within 5 to 15 s with its DAA within 2 of the reference. Watch to N + 600 (31 checks a minute apart): DAA spread 2 to 12 across nodes, difficulty within 1%, moving through N (76.7k at 16,161, 74.5k at 16,344, 86.8k at 16,740). Definitive: getVirtualChainFromBlock from a DAA-14,500 block on all 12 nodes returned the same chain block at DAA 16,062, 16,304, 16,565 and 16,797. No fork. Lesson: systemctl stop igneumd also stops the miner and the block log (Requires=); the script now starts all three (the block logs were off from the roll to 14:56 UTC).

Hash-rate step under v2 (hop.sh "half:4:600;all:1:600", 14:57 UTC) against the morning's v1 schedule, first 600 s of each step (results/2026-10-04/v2/compare.md): 2-min rate back within 10% of 60/min after 157 s (v1 161 s) on the step up and 172 s (v1 272 s) on the step down; neither rule holds the 3-min criterion inside 600 s on 12 CPU miners. After 300 s the v1 step-up difficulty swung 128k to 134k to 89k (max/min 1.51, std log D 0.169), the v2 one climbed 102k to 117k (1.15, 0.053); on the step down v2 reached the one-thread level (82k) by 600 s, v1 was at 100k after 600 s and 97k after 900 s. One run each, CPU miners, the v2 series has a bridged gap in its first two rows.

Devnet: docs/plans/difficulty-v2-rollout-devnet.md. The gap found: the app launched igneumd without an override file, so an OTA-delivered v2 node would have forked at N; fixed with node_override_params in the packaged config (igneum-app.json, one NODE_OVERRIDE_PARAMS line in packaging/mac/packaged-config.sh read by both packagers; the engine writes <app data>/app/override-params.json and passes the flag). Rule: N = DAA at the manifest publish + 10,800 at least; since N is baked at the cut, choose DAA + 14,400 when committing the line and check at publish.

-

4 October 2026, difficulty rule v2 activated on the live devnet at DAA 33,000 by height switch, no fresh chain

+
+

4 October 2026, difficulty rule v2 activated on the live devnet at DAA 33,000 by height switch, no fresh chain

Rollout: the cloud rehearsal in the morning (12 nodes, one chain through N + 600), then the devnet. Node 1, the observer node and the seed were restarted on the v2 binary with --override-params-file carrying {"difficulty_v2_activation_daa": 33000}; the three app machines received the same height through the signed update manifest (the engine writes it to the node's override file and restarts the node at a safe moment), the two PCs within two minutes of an update-now job, the Apple M5 Max on its next check; the height had first been set to 46,500 and was moved to 33,000 at 16:55 UTC by the same route. The height passed at 17:37 UTC: node 1 and the seed shared the sink (ab6bb0a7147b at block 33,291), the observer followed, both PCs' nodes processed blocks normally, difficulty kept moving (150.8M at the height, then stepping down as the RTX 5090 Windows rig's card paused for a proving job). No node forked; no restart of the chain; a consensus rule changed under a running network with miners on three platforms. The first measurement of v2 on the devnet's own regime (two large miners, bursty parallel blocks) needs the RTX 5090 Windows rig back from its job; the cloud numbers stand meanwhile (settle 157 to 272 s, no swing).

Third run (job run-20261004-r3-shards, 18:59 to 19:02 UTC, 3 min 22 s wall for the shard and both blocks): the buffered save closed the gap, the core proof finished at 19:00:38 and the compressed stage started at 19:00:39 UTC; shard timings repeated within 0.3 s of the first run (core 9.1 s, compressed 10.5 s). The second run (run-20261004-1912-shards) failed in its first second with a guest that returned 0 bytes of public values; the same sources executed the shard on the Apple M5 Max, and a forced rebuild of every source on the RTX 5090 machine cleared it (ledger P20 closed; the package build now has a gate).

-

4 October 2026, first machine in the United States: a Windows laptop on an Intel integrated GPU, synced and voting

+
+

4 October 2026, first machine in the United States: a Windows laptop on an Intel integrated GPU, synced and voting

A colleague's Windows laptop in the United States installed Igneum Miner 0.3.3 from the downloads link at about 18:52 UTC. Its node took the 38,000 headers and blocks from one peer, the seed node, in about eight minutes across the Atlantic. The only card is an Intel UHD integrated GPU: the OpenCL worker runs at 1.46 MH/s and found one block in its first four minutes; the identity's votes on checkpoints 1202 and 1203 were accepted by the network, so a laptop with no discrete card takes part in finality. Machine id 37ba0461 in the console; app log run win-37ba0461-20261004-185342.

- +
+

the maintainers, 4 October 2026 evening: "we need to fix these serious issues before making things public". Both fixes sit behind one height switch, finality_v3_activation_daa (default never on every network, set by the override file like difficulty_v2_activation_daa), on branch finality-fixes of the node (worktree vendor/igneum-node-finality, from the proving head 8c0cff15). Spec 03 Q4 (fold) and Q5 (frozen table), 3.3.1, 3.7 items 2 and 9, 3.10, 3.11; ledger F21 and F22 "Fix built, pending rollout"; the devnet plan in docs/plans/finality-v3-rollout-devnet.md. The live devnet was never touched; every network below ran on ports 29700 to 29799, suffix 970.

F22, what was wrong. The cloud logs of the healthy stretch 11:45 to 14:00 UTC (212 indices, 12 miners; tools/finality-attacks/vote-timing.py, output in infra/cloud-devnet/results/2026-10-04/f22-vote-timing.md): the node builds a certificate the instant the votes it holds meet Q3, median 1.24 s (p99 1.71 s) after the first node determined the checkpoint, with 7 to 10 of 12 signers (mean 8.27); 10.24 votes had been issued by then on average (two in flight: the miner's 1-s poll, the 250-ms gossip pump per hop, up to 289 ms RTT) and the last of the 12 was issued median 1.45 s, p90 2.36 s after the first determination. A 1-s hold after the first build would have carried all 12 votes at 192 of 212 indices; the other 20 are miners 01, 06 and 11 down together for 10 minutes (indices 377 to 396, the hop.sh restarts), an outage, not lag. There is no cut-off to lengthen: the fix is a second round. Presence needs nothing, since the block reading of Q2 credits a late vote once any block carries it.

The rule built. F22: the first certificate still forms at quorum (lock latency unchanged); once every voter has signed, or certificate_fold DAA seconds after the determination (FinalityParams::certificate_fold, 3 on devnet, 6 on mainnet, serde default 3 so every older override file parses), a node holding a certificate rebuilds it from every vote seen when heavier and gossips it; ingest_certificate replaces a held certificate with a verified heavier one over the same block; templates carry the held one; a lock is never withdrawn. F21: frozen_table finds the highest locked index below i whose block is an ancestor of C_i and takes its weight table (bans applied) while daa(C_i) < daa(C_f) + weight_window; evaluate requires the signers (and a held certificate's signers) to hold two thirds of it at its weights on top of Q3; a locked checkpoint is never downgraded; the LOCKED line carries the frozen fraction and index. Node tests (cargo test --release -p kaspa-consensus-core -p kaspa-consensus -- finality params, 20 of 20): frozen_table_holds_a_side_without_the_other_keys_for_one_window (A 60%, B 40%; B leaves; v2 locks A alone within 30 DAA of B's last block, v3 not before the last lock is one 60-DAA window old, then at once), fold_round_carries_late_votes_and_heavier_certificates_replace (4 of 6 lock, a fifth vote is folded in 2 DAA later, a lighter hand-built certificate is refused, a heavier one replaces), override_params_carry_the_finality_v3_activation, the fast-time file test extended to both fields.

@@ -382,7 +452,8 @@ table{min-width:560px}

Fast-time 3-node network (node tools/finality-attacks/v3.mjs, the target-finality build, infra/fast-time/override-60x.json merged with skip_proof_of_work and finality_v3_activation_daa 0, or the file's own "never" for the v2 control; W = 120 DAA; n1 listens, n0 and n2 dial it through TCP proxies that hold every byte 300 ms each way, the stand-in for tc/netem which macOS lacks, so n0 to n2 is 600 ms plus n1's relay; six vmine voters at 1/6 of 1 block/s in all; machine shared with other agents' builds and the live devnet). Raw tables and the v3 split's finality log lines in docs/benchmarks/finality-v3-2026-10-04/.

RunCriterionMeasuredVerdict
fold, v2 control, 480 s(baseline)12 locked indices per node; the certificate each node held at the end carried 4 or 5 of 6 votes (means 4.67 / 4.50 / 4.25 on n0 / n1 / n2), never 6; median lock latency 1,008 msthe F22 state reproduced with 300-ms links
fold, v3, 480 sthe held certificate carries at least 95% of connected keys' votes (6 of 6)11 locked indices per node; first-built certificates 4 or 5 of 6 (means 4.75 / 4.36 / 4.45, as under v2); held certificates 6 of 6 at 11 of 11 indices on every node (100%); 9 to 10 fold lines per node ("every voter signed", 0.3 to 1.4 s after the first build) and 1 to 4 replacements by a heavier gossiped certificate; 0 conflicting certificates; median lock latency 1,008 ms, unchangedPASS
split50, v2 control: 3/3 split 150 s (old bound W / (3R) = 80 s at R = 0.5 blocks/s per side), heal window 200 s(the fork of 3.7 item 9)side B (n1, n2) locked alone from 126 s after the cut, 3 locks; side A none; n0 redialled 72 s after the gate reopened; at the end 7 CONFLICTING certificate lines (4 on n0, 3 on n1) and 4 locked indices disagreeing across the three nodesthe fork, as on the morning's three-node and cloud runs
split50, v3: the same cutneither side locks during the split; heal; locking resumes on one chain; 0 conflicting certificates0 / 0 / 0 new locks during the 150 s (the v2 control locked at 126 s, so the frozen table held side B for the checkpoints of the last 24 s; the frozen table would have expired at 240 s); n0 redialled 72 s after the gate reopened; all three nodes resumed at index 7 and reached 13 inside the heal window; 0 conflicting certificates; 0 disagreeing locked indices; every post-heal LOCKED line names the frozen lock and its fraction (81 to 94% of the frozen table)PASS
split70, v3: 4/2 keys, the 4 side at 70% of weight (shares 0.175 x 4 against 0.15 x 2), 150 sthe 4 side locks during the split, the 2 side does not; 0 conflicts4 side: 4 new locks, the first 30 s after the cut; 2 side: 0; heal: all three at 17; 0 conflicting certificates; 0 disagreeing indicesPASS (6B at 70/30; exactly 4/6 is a knife edge under both rules, simulator row above)

What remains uncertain. (1) The v3 split's hold was observed over the last 24 s of a 150-s split (the control crossed at 126 s); a longer split under the 240-s expiry (say 200 s) would show more held checkpoints, and the "held by the frozen table" line is logged at debug, which the runs did not enable. (2) No cloud rehearsal: the 12-node the cloud provider network was destroyed at 15:30 UTC, so the 95% target is shown on three nodes with emulated 300-ms links and on the cloud logs' arithmetic, not on the cloud topology itself; the rollout plan names the re-creation and the partition experiment to run first. (3) The frozen reference is the node's own highest lock on the chain, not the certificate carried in C_i's past, so two honest nodes can test one checkpoint against tables 30 s apart; in a connected network those tables differ by a minute of blocks, under a partition both are pre-split, and no run showed a disagreement, but it is a property argued, not proved. (4) The price: a sudden departure of a third or more now pauses finality for a full window (30 days on mainnet) instead of 1.4 to 10 days; a gradual one costs nothing. the maintainers asked for the pause over the fork; the number is stated in spec 3.7 item 2. (5) The fold clock is in memory: a restarted node folds from daa(C_i) + depth, a few seconds late at worst. (6) Binaries, all from finality-fixes 6aa69a45, hashes and checks in the rollout plan's section 2: Mac native fe982a1d... (verified running), Linux 7c100fc2... (cargo-zigbuild, 34 min, not run on a Linux host), Windows cc1d1001... (mingw, 12 min 28 s, the v2 exe's DLL set, cannot run here); the Windows payload inputs were staged with push-inputs.sh --no-deploy into a scratch folder and NOT deployed (plan 7a).

-

4 October 2026, miner performance: variant racing (Metal worker on the M5 Max; the RTX 5090 job is ready, not run)

+
+

4 October 2026, miner performance: variant racing (Metal worker on the M5 Max; the RTX 5090 job is ready, not run)

Method (docs/design/miner-tuning.md): at every hourly prepare the worker compiles the bound kernel in several variants (unroll, load path, register budget, threads per group, combinations), checks each bit for bit against the base kernel, times each for 2 s with the job loop paused, and keeps the fastest for the hour. Base is the kernel as it has always shipped. Code: proto-metal/main.swift (raceProgram, --race-test), proto-cuda/nvrtc/worker.cpp (racePair, --race), branch miner-perf, commit 460a99a.

Machine: Apple M5 Max, Darwin 25.6.0 (macOS 26.6.2), 64 GiB. CONDITIONS: the live Igneum Miner app's own Metal worker (igneum-bench --serve, pid <n>) was mining on the same GPU throughout, and the load average was 130 at the build and 14 to 67 during the races (other agents' cargo builds). The absolute MH/s below are therefore about half of the card's (the app reported 26.7 MH/s on 4 October with the GPU to itself) and each window was contended; the numbers to read are the ratios, taken as the best of three interleaved rounds per variant so the contention hits every variant alike. A re-run with the Apple M5 Max card paused is listed under "next".

Command (under the measure lock, which holds the build lock too):

@@ -394,7 +465,8 @@ table{min-width:560px}

Serve-protocol check (the same binary, --serve --race-rounds 1, scripted stdin: two inline jobs on pair A, the deferred race on A, prepare of pair B with its race, jobs on A meanwhile, the swap to B, a job across the 32-bit nonce boundary): 44 jobs done, 0 errors, no found line missed; the inline compile of pair A 220 ms, the deferred race on A winner g256 14.207 base 11.404 gain +24.58% (compile 563 ms, 36 s of windows); prepared for B after 35,554 ms = program 58 ms, dataset 524 ms, race 34,972 ms (winner mt512-g256 12.807 base 10.346 gain +23.79%), the swap to B in 0.01 ms, the 64-nonce job across the 32-bit boundary 14.8 ms. Found by this check: the job queued during a race waited for the whole race (job 2 done after 35,946 ms; the mutex is not fair), so the race now pauses 150 ms after every window (commit 32d1c01). Re-check with the pause (--serve, a job every 3 s through both races, load average 134 to 183): every job during the deferred race on A and the prepare race on B finished in 0.17 to 2.8 s (33 jobs, none over 2,831 ms, versus 35,946 ms before), the race on B 39.8 s inside a 40.2 s prepare, winner g256 both times, swap 0.01 ms, 0 errors; the race's own windows were 2 to 3 s longer in total than without the pause, as expected.

NVIDIA side, what the Apple M5 Max could check: proto-cuda/nvrtc/emu/test.sh PASS on the race build (the race off under emulation, "variants 1 base only, no race (emulation)" logged per pair; 9 source checks PASS, the --serve protocol with prepare, swap and self-heal unchanged, 17 sampled hashes equal to igneum-pow hash-bound); mingw cross-compile of igneum-worker-cuda.exe with the race (build-windows.sh, mingw, static): 1,509,376 bytes, the same imports as the shipped worker (KERNEL32 and the Universal CRT), icon and version block verified; zipped as igneum-worker-cuda-race.zip (429,387 bytes, sha256 321a086e...c4c049) for the the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job. The race has not run on a GPU.

Next: the the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job (ready in docs/plans/miner-perf.md); the Apple M5 Max card paused for a clean absolute table; the Mac app's own worker on this build (its hourly prepare then races by itself and logs the TUNING record).

-

4 October 2026, miner fault guards and the app watchdog measured against a fake worker (miner-community-lead, app owner)

+
+

4 October 2026, miner fault guards and the app watchdog measured against a fake worker (miner-community-lead, app owner)

Machine: Apple M5 Max, load average 17 to 92 (other agents' builds and runs throughout), everything at nice 19 under tools/lock/with-lock.sh run. These are recoveries and seconds, not hash rates: nothing here is a performance number. Private test networks only: one igneumd (devnet suffix 9950, ports 29950 to 29953) for the miner scenarios and the app's own private node (suffix 9960, ports 29960 and 29961) for the app scenarios; the live devnet was not touched. Worker: tools/reliability/fake-worker.mjs, a stand-in that speaks the serve protocol and misbehaves on command (jobs done in 0.3 ms, 0 hashes, silence, wrong hashes, refused prepares); it never hashes, so no block was found and the fake rate of about 157 MH/s inside jobs is an invented number. Miner: fork branch miner-reliability (aea5ac6d, 501363e0, 945153ab), igneum-miner release with --status-secs 10. App: app/igneum-app at f39e240 plus the card-message fix, IGNEUM_APP_STATUS_SECS=10. Harness: tools/reliability/run.mjs and app-run.mjs; every scenario states what must and must not appear, and the detectors were shown to fire on the faulting scenarios and stay quiet on the healthy stretches before any number below was kept.

Miner guards (review round 4 M26, M27, X21), one fresh miner process per scenario:

ScenarioWhat the worker didResultSeconds
slow-first (M26)5 s jobs for the first 25 s, then the true rate, 47x fasterone trip, one restart, STATUS lines every 10 s throughout (8 in 85 s, max gap 10.1 s), 4 healthy intervals after it with no further trip; the old guard tripped on every interval and printed nothingslow start to trip 40.1, trip to worker restarted 2.0
fake-fast (the gfx1036 fault)jobs "done" in 0.3 ms with the full countthe job-time guard fired on the first such job; STATUS with faults=1 printed after the trip; one restarttrip 0.0 after injection, worker restarted 2.0, ready 2.5, first healthy STATUS 12.5
fake-fast-staysthe same fault persiststrips at 0.2, 3.2, 8.7 s with restart delays 2 then 4 s; the third trip in the window ends the miner with exit 43 (WORKER FAULT 3 guard trips in 10 minutes)injection to exit 8.8
badfound (X21)a wrong hash on every found3 WORKER MISMATCH lines, then WORKER FAULT cpu re-check: 3 consecutive mismatches; 3 wrong shares seen, 0 submitted; STATUS shows mismatched=3; one restartfirst mismatch 0.3, trip 0.5, first healthy STATUS after the trip 2.9
silentstops answering with jobs queuedSTATUS lines kept printing during the silence (5; the old loop printed none and never restarted); the stall guard fired at 60 s; one restartsilence to trip 60.1, trip to first healthy STATUS 12.9
prepare-flap (M27)refuses every prepare across epochs of 60 DAA (a 3-thread CPU block producer on genesis bits 0x1f100000)5 epochs turned (333 blocks in 5 min); one PREPARE sent per epoch, each answered prepare-failed, each retry held (PREPARE held ... within 30 s of the last prepare) and the epoch turned before a retry was due: 5 sends, 5 held, 0 repeats; before the limiter a refused prepare was re-sent at the next job fill, a pack write and a GPU build each timesmallest gap between sends 50.6
@@ -402,7 +474,8 @@ table{min-width:560px}

App watchdog (src/watchdog.rs), one engine run, the fake worker as the Metal worker, steps in order:

StepWhat happenedResultSeconds
own-restartthe worker reports jobs done in 0.3 msthe miner's guard restarted the worker; the card showed the fault and worker faults 1; the app did NOT restart the miner (same pid, app restarts 0)fault on the card 1.0 after injection, mining again 9.1 after the fault
zero-oncejobs complete with 0 hasheswatchdog: hash rate 0 for 60 s while the node is synced; one app restart; mining on the new miner processzero to restart 79.6 (60 s rule plus the status interval and the quit grace), restart to mining 11.3, zero to mining 91.0
zero-faultedthe same again inside five minutescard faulted: hash rate 0 for 60 s while the node is synced (restarted once already); 45 s later still faulted, no miner process, no further restart; the node kept running and the app stayed up; resume cleared it and mining resumedzero to faulted 75.4
no-statusthe miner process stopped with SIGSTOPwatchdog: no status line from the miner for 90 s; the stopped process killed; mining on a new processquiet to restart 90.4, restart to mining 11.0
node-silentthe node process stopped with SIGSTOPthe app restarted the node in-process (the remote-job restart kind), the new node synced, mining resumedquiet to restart 150.7 (120 s rule plus the 30 s terminate grace on a process that cannot answer SIGTERM), restart to synced 7.2, quiet to mining 160.0

Not measured: any real GPU. The job-time and interval guards, exit 43 and the app's faulted card have not run on an RTX 5090, the gfx1036 or a Metal card; the first real run is owed from the fleet logs. The "no status" rule has not been tried against a hung RPC (only a stopped process). Unit tests: cargo test -p igneum-miner -- guard (7) and cargo test -- watchdog in app/igneum-app (11), both replaying recorded STATUS and WORKER FAULT lines.

-

4 October 2026 (evening), the software dev fee measured on a test network: 9 fee blocks in 785, the chain and the miners' counters agree

+
+

4 October 2026 (evening), the software dev fee measured on a test network: 9 fee blocks in 785, the chain and the miners' counters agree

Decision of the evening: the Igneum Miner software takes a visible, switchable 1% dev fee (one block template in 100 requested with the dev payout address, chosen by a template counter, never at random); the protocol carries no fee. Branch dev-fee of both repositories; docs/design/miner-dev-fee.md; FUD ledger E18.

Machine: Apple M5 Max, macOS 26.6.2, load 140 to 170 (many other agents' builds and runs alongside; only counts were taken, no rates). Network: node tools/dev-fee/run.mjs --secs 600 --hold-ms 500, two devnet-v4 nodes (igneumd 3bfe346f) on 127.0.0.1 ports 29900 and 29910, network id igneum-devnet-957, the fast-time profile with proof of work skipped and genesis_bits at the floor so a CPU stub miner solves every template it holds. Three igneum-miner processes (dev-fee branch a2c7ba83, --engine stub, 1 thread, exponential hold with mean 500 ms, no voting), each paying its own test address: a and b at the default --dev-fee 1, c the control at --dev-fee 0. 600 s. Then igneum-miner payouts on both nodes: every block the node holds, counted by the IGNA payout address in its coinbase.

What the miners printed at start, verbatim:

@@ -410,7 +483,8 @@ table{min-width:560px}
Miner--dev-feeBlocks found (its summary)Rejectedfee= in its summarydev-fee block linesBlocks to its own address on the chain
a1 (default)385055380
b1400044396
c0 (control)397000397

The chain (payouts, identical on node 0, the miners' node, and node 1, its peer): 1,183 blocks; 380 + 396 + 397 to the three user addresses, 9 to the dev-fee address 0xdfaea6...0c2e (0.761% of all blocks, 1.146% of the 785 blocks of the two fee-paying miners), and 1 block with no IGNA field, the genesis block. Found per miner = own blocks + fee blocks exactly (380 + 5, 396 + 4, 397 + 0), so every fee block the miners logged is on the chain and no other block went to the dev address. The control miner paid nothing.

Reading. The expectation is 1 in 100 templates; the stub miner found a block on most but not every template once the difficulty had risen on three miners at about 2 blocks/s against the 1 block/s target (a and b held about 500 templates each, 5 and 4 of them fee templates at positions 99, 199, ..., and converted 77 to 80% of templates into blocks), so the block share lands near 1% with the sampling noise of 9 events (1.15% here). The exactness claim is on the template side and is the unit test (dev_fee_tests: 100 of 10,000 at positions 99, 199, ...; 0 at --dev-fee 0; exact at 2 to 100%); the chain test shows the fee blocks reach the chain and are counted the same by the miner and by both nodes. Not measured: worker (GPU) mode, where the fee template is one of the templates the background fetcher rotates through once a second per identity, so the share is 1 in 100 templates by time, not by job; and nothing on Windows.

-

4 October 2026 (night), ledger M30: the block and transaction floods grew the node by 256 MiB per epoch roll, fixed by sharing the PoW cache across the epochs of a day (memory engineer)

+
+

4 October 2026 (night), ledger M30: the block and transaction floods grew the node by 256 MiB per epoch roll, fixed by sharing the PoW cache across the epochs of a day (memory engineer)

Machine: Apple M5 Max, 64 GB, load averages 126 to 146 for the whole session (ten or more agents building and running at once). Every count here (blocks accepted, cache builds, RSS before and after) is valid under that load; every latency is an upper bound and is not a number. Private test network of two igneumd on 127.0.0.1 ports 29500+ (node A on 29500/29501/29502, node B on 29510/29511/29512), data under /tmp/igneum-fud-mem/{baseline,after,after2} (the second is pass 1, the third the committed build), the 60x fast-time profile (infra/fast-time/override-60x.json, skip_proof_of_work on, pow_epoch_blocks 60, pow_day_ms 1,440,000) exactly as the red team ran it. The live devnet and other agents' ports were not touched. Every run went through tools/lock/with-lock.sh run, every build and the unit tests through with-lock.sh build.

What the red team saw (docs/review/redteam-2026-10-04.md rows 5 and 8, ledger M30): on the 0.3.4 build the s6 submit flood grew RSS by +269 MB, the mempool flood by +270 MB, and the s7 block flood took both nodes from 302 to 1,082 MB. The s6 figures were cumulative from one baseline taken before all three loads (rss_peak - rss_baseline in s6-exhaustion.mjs), so the mempool flood's "+270 MB" was the submit flood's growth carried forward; its own cost was 1 MB. The red team's guess (execution-layer records, rejected transactions retained) did not hold: the mempool flood retains nothing measurable.

Cause, measured: every RSS step is one PoW cache built line in the node log (consensus/src/pipeline/header_processor/pre_ghostdag_validation.rs:136), 256 MiB each. The lottery engine (consensus/pow/src/igneum.rs, IgneumEngine::epoch_for_impl) keyed its resident entries by (epoch seed, day) and built a full igneum_pow::Epoch (program plus the 256 MiB ChaCha12 cache) per entry, keeping KEEP = 4 of them, although the cache is a function of the day seed alone (igneum_pow::Epoch::from_seed_bytes: seed_words_from_bytes(day_bytes); the epoch seed only feeds the program). On the 60x profile an epoch is 60 DAA, so the honest chain rolls an epoch every minute and the 50x block flood every 10 to 20 s; each roll cost a cache build and 256 MiB until the fourth entry, then evictions. The engine runs under skip_proof_of_work too (check_pow_and_calc_block_level always calls it and forces the pass afterwards), so the harness exercised it. The 3 October harness run (this file, "2026-10-03, consensus attack harness") was on the plain devnet profile (3,600-DAA epochs), where no roll falls inside a 60 s flood, which is why it grew 11 to 33 MB; the profile change and the build change were conflated in M30. On the live devnet the same rule means 256 MiB per hour until 1 GiB resident, and a 50x fast miner reaches that in minutes.

@@ -426,7 +500,8 @@ table{min-width:560px}

` IGNEUMD=<binary> IGNEUM_FAST_TIME=1 IGNEUM_HARNESS_BASE_PORT=<29500|29600> IGNEUM_HARNESS_TMP=/tmp/igneum-fud-mem/steady-<before|after> \ IGNEUM_STEADY_BLOCKS=1500 IGNEUM_STEADY_MAX_MIN=40 tools/lock/with-lock.sh run node tools/harness/scenarios/s8-steady.mjs `

Blocks (node A / B, both equal)Before (shipping igneumd, 29500+): RSS A / B MB, cache buildsAfter (796f758d, 29600+): RSS A / B MB, cache builds
0 (nodes up, miner not started)41 / 42, 041 / 42, 0
514 and 5101,342 / 1,342, 9319 / 317, 1
1,008 and 1,0291,355 / 1,355, 18589 / 588, 2
1,529 and 1,526 (end, 1,527 and 1,521 s)1,371 / 1,372, 27603 / 602, 2
Slope from 1,000 blocks to the end30.7 MB per 1,000 blocks30.2 MB per 1,000 blocks

Reading. Before: one cache build per epoch roll (25 rolls in 1,529 blocks, plus the two days) and the RSS steps with them up to five chunks: KEEP = 4 plus one evicted 256 MiB chunk the allocator keeps and never returns to the OS (vmmap at 500, 1,000 and 1,500 blocks: 1.3 G resident in the region vmmap labels IOAccelerator, which held exactly the cache chunks; the malloc zones hold 9 to 22 MB). It stays at five: the before node is flat at 1,34x to 1,37x from 514 blocks on. After: one cache for the first day (319 MB at 510 blocks), a second when the fast-time day rolled at 01:36 UTC (both runs; the day cache is per day by design, KEEP_DAYS = 3), 2 of 2 builds in 1,526 blocks against 27 of 27 before; on the devnet profile (24-hour day, 1-hour epochs) that is 256 MiB flat, 512 MiB around midnight UTC, 768 MiB worst case, against 256 MiB per hour up to 1.3 GB before. So per 1,000 blocks: before, 1,300 MB in the first 500 blocks (the four caches plus the kept chunk) then 31 MB; after, 30 MB, plus 256 MiB once per day. The 30 MB per 1,000 blocks is the same on both builds and is not the PoW cache: at 1,526 blocks the after node's non-cache footprint is 584.0 M physical minus 2 x 256 MiB = 72 MB against 23 MB at 0 blocks, and the malloc zones account for 22 MB of it, so most of it is in large vm_allocate regions, which on this node means the consensus database's write buffers and block cache and the consensus in-memory caches filling toward their fixed sizes (rusty-kaspa sizes them in entries for mainnet), not the execution layer (1,526 chain-block records on an empty chain are about 2 to 3 MB, approximate) and not the finality key maps (1 voter here). That is a reading, not a measurement: it needs a longer run to see the plateau (the live node's own figures fit it: 1,081 to 1,193 MB over 52 minutes with no epoch roll is 36 MB per 1,000 blocks). The live app node's 2,258 MB at 4 h 14 min is more than the before build can hold on its own (five chunks plus 30 MB per 1,000 blocks gives about 1.7 GB at 15,000 blocks); the app runs a GPU worker beside the node (Metal buffers and a kernel per epoch), which this harness does not cover, so that node wants its own vmmap -summary. Result JSON docs/benchmarks/memory-floods-2026-10-04/{before,after}-s8-steady.json, vmmap summaries under .../vmmap/.

-

4 October 2026 (night), round-4 consensus items F23, F24, G12, X18 and M31: unit tests and fast-time 3-node runs against the control (consensus engineer)

+
+

4 October 2026 (night), round-4 consensus items F23, F24, G12, X18 and M31: unit tests and fast-time 3-node runs against the control (consensus engineer)

Branches: node fork fud-consensus (worktree vendor/igneum-node-fud, from finality-fixes 6aa69a45, no remote; commits 9f738e2e the four items, ae9df8a3 pending certificates at fresh determinations, b755f43d merge of fud-memory, then M31 and the un-determination rule), main repo fud-consensus. Machine shared with the red team, the release builds and the memory runs all night (load average 100 to 146 until about 00:00 UTC, under 20 after); every number here is a count, a lock or an index, not a timing. Runner tools/finality-attacks/fud.mjs (scenarios digest, ban, reorg; fast-time 60x profile with finality_v3_activation_daa 0 merged by the BigInt-safe overrideParams, ports 29400+, suffix 940, /tmp/igneum-fin-fud, node logs kept per scenario); the control is the shipping finality-fixes build vendor/igneum-node/target-finality/release/igneumd driven by the same miner. Raw result files in docs/benchmarks/round4-consensus-2026-10-04/.

Builds. with-lock.sh build nice -n 19 cargo build --release -j 4 -p kaspad -p igneum-miner --features kaspad/igneum-pow on a target directory cloned from target-finality with cp -Rc (APFS clonefile, 1 min, no disk): 17 min 53 s the first time under load 140, 8 min 58 s the second. Unit tests in the release profile (cargo test --release -j 4 -p <crate> --lib): consensus-core config::params::tests and igneum 20 of 20 (new: consensus_digest_covers_every_consensus_field_and_nothing_else, env_pow_schedule_is_devnet_and_simnet_only), consensus processes::finality 6 of 6 (new: ban_is_decided_by_the_carrying_block_so_nodes_agree_on_every_voter_list with three TestConsensus nodes on one chain, reorg_past_an_unlocked_checkpoint_re_determines_it_and_verifies_the_pending_certificate, a_locked_checkpoint_pins_the_chain_and_a_certificate_against_it_conflicts). After M31 and the un-determination rule (fork 977db931, with the fud-memory merge): consensus-core params and igneum tests 28 of 28 then params 12 of 12 (new: largest_coinbase_fits_on_every_network), consensus processes::finality 7 of 7 (new: a_shallower_sink_un_determines_the_indices_it_cannot_reach), kaspa-pow with igneum-pow 12 of 12; the second rebuild took 15 min 18 s under load 110 to 134.

X18, the params digest (fud.mjs digest: n1 listens on the shared override, n0 dials it with finality.weight_window 121 instead of 120, then n2 dials with the shared override).

@@ -442,11 +517,13 @@ table{min-width:560px}
ScenarioBuildResult
f23: two keys equivocating at every index, four honest voters, three nodes, 105 s (the evening's 9 / 3 / 4 refusals)ae9df8a3PASS: equivocation detections 14 / 7 / 7, voter-count refusals 0 / 0 / 0, CONFLICTING 0 / 0 / 0, disagreeing locked indices 0, max locked 61 / 61 / 61
f24c: 3/3 split, 16 s cut (96 DAA at 6 blocks/s), healae9df8a3PASS: n1 determined 31..32 during the cut; after the heal 0 refusals, 0 CONFLICTING, 0 stuck indices, 0 disagreeing, max locked 61 / 61
f24b: 4/2 split, 24 s cut, healae9df8a3 and 977db931FAIL on both, outside F24: 24 s at 6 blocks/s is 144 DAA, longer than the 120-DAA window and the 60-DAA merge depth, so the chains never merge and each side locks its own chain alone ("100.0% of total, 100.0% of the table frozen at lock 39" on n1): the partition longer than a window of spec 3.7 item 9 (F21), mis-scaled by the scenario's assumption of 1 DAA a second. The 1,668 and 2,025 "PoW rejected" lines are the INFO line of pre_ghostdag_validation.rs:158 for nonce-1 blocks, which skip_proof_of_work then accepts; no block was refused for them

G12 is covered by the digest run (the environment's schedule is part of the digest, so a devnet node with IGNEUM_POW_EPOCH_BLOCKS set cannot connect to one without it) and by env_pow_schedule_is_devnet_and_simnet_only; no mainnet node was started tonight. M31 is covered by largest_coinbase_fits_on_every_network; no simnet network was started tonight (the red team's tools/exec-attacks/net.sh is the run that would show templates on simnet without an override).

Uncertain. (1) Every run is fast time (W = 120 DAA, ban 120, depth 20) on three nodes with 100-ms links; the mainnet values are 30 days, 30 days and 60 blocks. (2) The ban run shows one equivocation at one index; the red team's s1 (equivocation at every index, two keys) was re-run on the new build only through the red team's f23 above (0 refusals where the evening had 9 / 3 / 4). (3) The digest-less allowance on devnet and simnet is deliberate for the rollout and is a hole until removed. (4) The reorg run's final pass had the majority lock no index during the first 60 s of the split, so the re-determination at 8 and 9 was exercised, the pending-certificate path only at 10 and 11; the first pass exercised the opposite. (5) The un-determination rule has a unit test and one network pass (reorg-final2) in which the shallow-sink case did not recur, so the rule is exercised by the test, not by a run; the case needs a split whose difficulty drifts enough for blue work to overtake blue score, which happened once in four runs. (6) The red team's f24b is a window-length partition at 6 blocks/s, so it measures F21's stated limit, not F24; a 4/2 cut under 20 s at that rate would be the F24 case.

-

5 October 2026, live devnet: the first shards proven, verified and paid

+
+

5 October 2026, live devnet: the first shards proven, verified and paid

Proving v0 activated at DAA 84,100 (manifest consensus.override, every node restarted with the same file; a hand node restarted early with another value was refused by the digest handshake and sat isolated for 20 minutes until it was restarted with the same file). The first proof records came from the RTX 5090 Windows rig's RTX 5090 (SP1 CUDA under WSL2, app 0.3.7, node 2b6d23ef) and were verified by the Apple M5 Max node's verifier (igneum-prove-host --mode verify, the only block producer with a verifier until 0.3.7 put one on every machine) and paid at the carrying chain block.

WhatMeasured
First shard record in the pool (observer)10:51 UTC, block 94,904 on the live page, prover key e809e396, shard 0, 0 pgas (an empty shard)
Paid shards by 10:53 UTC (Mac node igneum_getProvingStatus)3 shards, 3.370437410 IGN in total, pool balance 68,601.72 IGN
Pool at that moment4 entries: 3 pending, 1 failed verification, 0 verified-and-waiting
Non-empty shardsnot yet: the exporter's post-root assertion fires on blocks with content (58,584 to 58,984 on 5 October); investigation open
The assertion, explained (12:30 UTC, branch prover-match)Not block content. Every block it fired on is empty (the RTX 5090 Windows rig's export logs: 58,752 to 58,843 hit the assertion; 58,584 to 58,740 hit the backslash path of 6d51e53), one reward plus the pool credit, no transactions, no payouts. the RTX 5090 Windows rig's exporter was a stale build: the panic names shard.rs:175, the line before commit 1251f0a moved the assert to 179, and that core's planner gave an empty segment the pre-root as its post-root while the statement applied the rewards (left = the node's root after the rewards, right = the root before them, as the log shows for 58,752). The core at master reproduces 58,927 and 59,192 with the node's roots, and the same shape (59,507: one reward to the same miner) was proven and paid after the 10:49 and 10:52 UTC rebuilds on the RTX 5090 Windows rig. Branch prover-match: fixture block-58927-empty-reward.json, export/tests/fixtures.rs (every fixture reproduces; an empty segment ends at the root after the rewards), and a source stamp on the first line of the exporter and the host so a stale binary names itself. The guest is untouched: built in one directory, master and the branch give byte-identical loadable segments for the shard program and the aggregator (shard program id 0x1ec8b941 at master in that directory). Noted on the way: the same sources built in three directories on this Mac gave two different guest ELFs (text segment c173b3de in the main checkout and in a fresh worktree, 830f7433 in the branch's worktree, shard program id 0x366e2aca there), so the program id is not yet a pure function of the sources on a native build; SP1's docker build is the reproducible path and is not in use. Open item.

Commands: curl -X POST http://127.0.0.1:26800 -d '{"jsonrpc":"2.0","id":1,"method":"igneum_getProvingStatus","params":[]}' on the Apple M5 Max; node tools/logs.mjs for the RTX 5090 Windows rig's prover lines (prover: block N shard 0 assigned to win-1ccfe586-1-1: export, cut, prove (CUDA), sign, submit).

-

5 October 2026, the program id split: why the Apple M5 Max rejected the RTX 5090 Windows rig's proofs, and the verifier at 114 s

+
+

5 October 2026, the program id split: why the Apple M5 Max rejected the RTX 5090 Windows rig's proofs, and the verifier at 114 s

Machine: Apple M5 Max under the live devnet node, the Metal miner and two other agents' builds (every number here is wall time under that load, taken through the measure lock). Code: proving/igneum-prove on branch program-id, SP1 6.8.1, circuit v6.1.0.

HostBuiltShard program idSource
Mac, shipped (Igneum Miner.app/Contents/Resources/bin/igneum-prove-host, app 0.3.7)5 Oct 10:48, release tree on the Apple M5 Max0x0559759b3d8740b26ceceb2c56054b89194878ab691b018d7dd2f8af2f2242ddits own --mode verify setup line
the RTX 5090 Windows rig, WSL2 CUDA (<server path>)4 Oct 19:00Z, package sources0x05db1aca65f8ae9d585c7bd178a832d92a67275857f21c0d484a58c06dba61a3app log run-20261004-r3-shards (node tools/logs.mjs job-collect-pc2-applog-paid-1ccfe586); confirmed by the sp1_vk_digest inside its proof of block 59507 shard 0 (below)
Mac, fresh worktree igneum-wt-programid5 Oct 12:07Z, same sources as the shipped host0x0dfade071ffc05a50be5f7e6640fb12638bac0ea63697ec252863f55658be16aigneum-prove-pin

Three builds of the same guest sources, three ids. Cause: host/build.rs compiled the guest with sp1_build::build_program on whatever machine built the host, and the guest ELF depends on where it is built. Shown by strings on the two Mac ELFs: 946 anonymous symbol names differ, and the crate hash of igneum_prove_core is Csl6o96CsXEfN_ in the main checkout against Cs5Jl7brLd39a_ in the worktree (cargo's -C metadata for a path crate includes the checkout path, and rustc's symbol names carry it); the ELFs also embed ~/.cargo/registry/... panic-location strings, which differ again on Linux. A different ELF is a different verifying key, so every verifier rejects every other machine's proof ("sp1 vk hash mismatch" inside SP1's verify_compressed), and the node log showed it as a bare NOT VERIFIED after 114 s to 138 s. Over the same window the Apple M5 Max's pool read 16 entries, 9 failed, 0 verified, 22 shards paid (included by the RTX 5090 Windows rig's own node).

@@ -454,7 +531,8 @@ table{min-width:560px}
Verify of the RTX 5090 Windows rig's proof of block 59507 shard 0 (1,272,897 bytes) on the Apple M5 MaxSetupVerifyVerdict
Before: shipped host, ProverClient::from_env + two key setups125.82 s0.383 sNOT VERIFIED, no reason given
Before, as the node saw it (blocks 59373 and 59402)138.6 s and 114.4 s in all0.409 s and 0.104 sNOT VERIFIED
After: pinned key, light verifier (program-id host, same proof)2.085 s0.002 s (refused on the program id before any field arithmetic)NOT VERIFIED, program id 0x05db1aca...61a3 IS NOT OURS 0x0dfade07...be16a; 2.35 s wall, exit 3
After, known-good case: block 56 shard 0 proven with the pinned ELF on this Mac (--mode compressed, 558,137 cycles, prove 1,066 s under load 113), verified against its real statement1.323 s0.108 sVERIFIED, program id ... (ours); 1.80 s wall, exit 0

Before: 127.0 s wall per proof on the Apple M5 Max (the node saw 114 s to 139 s). After: 1.8 s to 2.4 s wall, under the 2 s target for the verify call itself; the remaining 1.3 s to 2.1 s is SP1's light verifier construction plus paging a 58 MB binary under load, and would shrink in a long-lived verifier process. Unit tests (cargo test -p igneum-prove-host --bin igneum-prove-host): the embedded files hash to the manifest, the embedded keys derive the manifest's ids, a changed file is refused; the ignored test re-runs SP1's setup on the embedded ELFs and gets the pinned ids. tools/ci/pinned-guests-check.sh was shown failing on an empty elf/ and passing on the pinned one.

What every machine must do: the pinned shard id 0x0dfade07...be16a differs from every id now running (Mac 0x0559759b..., the RTX 5090 Windows rig 0x05db1aca...), so this is a guest change for the whole devnet, and proofs in flight at the switch are rejected by a verifier that has moved. Rollout order (proving/README.md, "Pinned guest programs"): provers off on every machine; wait until igneum_getProvingStatus shows an empty pool on every node; install the host built from this elf/ on every node (Mac DMG; PCs through igneum-prove-wsl2.zip, whose package carries elf/, so the WSL build embeds the same files); confirm igneum-prove-host --mode id prints the same shard id everywhere; provers back on. From then on a differing id is impossible without a change to the committed elf/.

-

5 October 2026 (afternoon), live devnet: real transactions, the first non-empty shard proven and paid, and the exporter's block structure fixed (execution engineer)

+
+

5 October 2026 (afternoon), live devnet: real transactions, the first non-empty shard proven and paid, and the exporter's block structure fixed (execution engineer)

Until this run the devnet had carried no transaction at all, so every one of the 349 shards paid before 15:35 UTC was empty (0 pgas). tools/txgen/run.mjs (new; viem for EIP-1559 signing, otherwise Node 22 built-ins) funds generated wallets from the devnet dev-fee key (<config path>, keys of the generated wallets in <config path>, mode 0600) and sends transfers between them at a steady rate through one node's EVM RPC; tools/txgen/proving-watch.mjs samples the proving layer during a run and builds the per-block report afterwards. Both runs went through the Apple M5 Max node (127.0.0.1:26800) under tools/lock/with-lock.sh run, with the RTX 5090 Windows rig's RTX 5090 (app 0.3.8, SP1 CUDA under WSL2) as the only prover and the Apple M5 Max node as the verifier. Chain id 4463, gas price quote 3 gwei (1 gwei execution base, 1 gwei proving base at ratio 1.0, 1 gwei tip), eth_estimateGas 25,380 for a transfer.

RunWindow (UTC)WalletsSentIncludedIncluded per sLatency p50 / p90 / max (s)Blocks with contentTransfers per content block p50 / p90 / maxFailuresFees paid (IGN)
1, master code15:37:30 to 15:57:30162,2752,161 (103 pending at the cut, all with a receipt 20 s later)1.8640.7 / 110.8 / 209598 / 92 / 22460: 49 "replacement underpriced", 10 dropped, 1 skipped (9 of the 11 executed later, see below)0.091
2, fixed code15:59:34 to 16:14:34161,6501,633 (17 pending at the cut)1.7145.7 / 128.7 / 2534810 / 99 / 2240 (0 nonce retries, 0 deferred)0.069

Funding: 16 wallets at 2 IGN each, 16 IGN from the dev-fee address, which held 891 IGN before and 997 IGN after (it receives 1 block reward in 100 from every fee-paying miner). The wallets end with 31.83 IGN; the whole spend of the afternoon is 16.16 IGN.

@@ -465,11 +543,13 @@ table{min-width:560px}

The fix, both sides ours. Fork (vendor/igneum-node-txgen, branch txgen-export, exec/src/rpc.rs): the export names the mergeset per segment ("blocks": hash, miner, blue, txCount, empty blocks included) and gives every entry "block" and "position" from the executor's boundaries (body order), skipped copies with their block's miner; records without boundaries keep the old shape. Exporter (proving/igneum-prove/export/src/main.rs blocks_of): rebuilds from those fields block for block; an old export is kept in its order and a block of skipped copies whose miner it does not name is refused instead of guessed. tools/prove-fixtures/complete-export.mjs completes an old export with the mergeset from igneum_getSegment (which names every skipped copy's block) for the fixtures. Fixtures proving/fixtures/block-72803-skipped-copies.json and block-72854-empty-block-first.json, each with <name>.node-plan.json beside it (the node's igneum_getShardPlan); export/tests/fixtures.rs check_against_node_plan asserts the cut's links, roots, gas, pgas and counts against the node's shard by shard, which the exporter-versus-core checks could not see. Known-failed shown: the old 72854 fixture under that check fails on "links (block index, block gas and pgas, tx accumulator)"; known-good: both new fixtures match the node's link_out exactly. Three unit tests on blocks_of (the 0.3.9 shape with an empty block, a skipped copy between two executed transactions and a block of skipped copies only; a count mismatch refused; the old shape kept in order and the skipped-only block refused). cargo test --release -p igneum-prove-export: 3 + 2 tests pass over 9 fixtures. The guest is untouched (no change under core/). The node side needs the 0.3.9 build and rollout; until every prover exports from a 0.3.9 node, a shard whose transaction block follows an empty block, or whose copies were all skipped, fails the veto.

Also noted: the collect job uploads the first 256 KiB of a log file, so a tail needs --command "powershell -NoProfile -Command Get-Content -Tail 500 logs\app-....log".

Commands: tools/lock/with-lock.sh run node tools/txgen/run.mjs --duration 1200 --rate 2 --wallets 16 --fund 2 --cap 40 --summary <file>; node tools/txgen/proving-watch.mjs watch --interval 30 --duration 1560 --out <jsonl>; node tools/txgen/proving-watch.mjs report --summary <summary.json> --pc2-log <collected app log>; node tools/prove-fixtures/complete-export.mjs seq.json out.json 72803,72854; igneum-prove-export out.json 72803 proving/fixtures/block-72803-skipped-copies.json.

-

5 October 2026, the prover carries both fee tables and the height switch: one pinned guest on either side of DAA 210,000

+
+

5 October 2026, the prover carries both fee tables and the height switch: one pinned guest on either side of DAA 210,000

The adopted fee table (spec 05 section 5.11) reaches the devnet by fees_v1_activation_daa (docs/plans/fee-switch-devnet.md). Until today the prover's guest carried only the prototype table (B_p 30 M, S_p 7.5 M, intrinsic 200), so every shard statement after the switch would have differed from the node's plan. Now igneum-prove-core mirrors the node's fees.rs (both tables, FeeSchedule::at), the shard input carries the schedule and the block's DAA score, and the executor raises the carried base fees to the set's floors as the node does. The 328-byte public values are unchanged: the node's native veto (it recomputes every statement) is what pins the schedule a prover claims.

CheckCommandResult
The node reads the switchcargo test --release -p igneum-exec on fork 2b6d23ef (this Mac, target vendor/igneum-node/target-036, 15:32:27Z to 15:36:30Z)11 passed, 0 failed, among them the_fee_switch_meters_by_the_block_daa_score
The digest for H = 210,00020 s scratch node, override {"difficulty_v2_activation_daa":33000,"proving_v0_activation_daa":84100,"fees_v1_activation_daa":210000}ab8847da538dead1dc10e046dfaadab3c1c35928e3748810c4e050d4a886087a
One chain across the switchprivate simnet on the 2b6d23ef binaries, override {"fees_v1_activation_daa": 200}, tools/prove-fixtures/gen.mjs before and after DAA 200, one igneum_exportSegments dump with every segment's daaScoreone chain, 358 segments, DAA 0 to 1,121: block 51 (DAA 187, prototype, 11 transactions, 7,494,392 pgas, one shard at S_p 7.5 M) before the switch; blocks 351 (DAA 1,105, 11 transactions, 36,934 pgas, two shards at S_p 30,000) and 355 (DAA 1,117, 14 transactions, 69,292 pgas, three shards) after it; igneum_getBudgets went from provingGasLimit 0x1c9c380 to 0x1d4c0 and the base fees to 100 gwei and 10,000 gwei at the switch. Found on the way: a burst signed with a 21 gwei cap just before the switch never executed after it (the floor is 100 gwei), and under v1 a modexp bomb's proving charge (pgas x 10,000 gwei) crosses the signed budget unless the gas limit covers it (design 4.1); gen.mjs now sizes both from the node's budgets
The port replays both sidesigneum-prove-export on that dump: every segment's state root equals the node's, prototype below 200 and v1 at and above itreplayed 358 segments from genesis; every state root equals the node's for each of the three cuts; fixtures fees-switch-prototype, fees-v1-shards2, fees-v1-shards3; igneum-prove-host --mode native on each: MATCHES, the three tamper cases REJECTED
The pinned guest on both sidesigneum-prove-host <fixture> --mode execute on this Mac (setup 37 s, pinned: setup matches the manifest)fees-switch-prototype shard 0: 66,043,259 cycles, 44 cycles per EVM gas, 9 cycles per prototype pgas, 2.88 s; fees-v1-shards2 shard 0: 4,717,439 cycles (213 cycles per v1 pgas, 0.38 s), shard 1: 3,485,430 cycles (236 per pgas, 0.26 s); aggregator 1.4 M cycles over 2 shards; every tamper case REJECTED. Under v1 these transfer-and-modexp shards run at about a quarter of the unit (1,000 cycles per pgas): the table over-charges them, which is the safe side of design R1's calibration
The new pinproving/igneum-prove/pin-guests.shshard program id 0x2b1a81cb413236cf063077b46ed3111628f6c41036bcf6e23ee4cbbf5679ef7a (2,832,504 bytes), aggregator 0x474678f35f7545db28055d5e5bbc308231d84a5a072202087a2a8d5b09123896, pinned 16:20:38Z; the 0.3.8 ids (0x0dfade07..., 0x135e67e7...) are what every machine runs until 0.3.9

Block rate for H: DAA 111,230 at 15:23Z, 112,227 at 15:40:13Z, 0.965 blocks/s; H = 210,000 is 24 h ahead of a publish before about 19:50Z on 5 October (the runbook moves it otherwise).

-

5 October 2026 (night), the C4 fix: certificate-driven reorg

+
+

5 October 2026 (night), the C4 fix: certificate-driven reorg

Owner: the consensus engineer and cryptographer agent, worktrees igneum-wt-c4 (branch c4-fix) and vendor/igneum-node-c4 (fork branch c4-fix on release-0.3.6 a24ab01a). Harness tools/finality-attacks/c4.mjs on the fast-time 3-node network (100-ms proxied links), node built on the Apple M5 Max in vendor/igneum-node/target-c4 from the fork worktree (an APFS clone of target-036), suites on the RTX 5090 Windows rig through tools/build-job.mjs. The Mac carried two other builds and the M20 live sync throughout; every figure is a count, an index or a second from the harness clock.

The cause, in the code. processes/finality.rs: ingest_certificate verified a certificate only when its block was the node's own determination at that index (cp.hash == cert.checkpoint); any other block went to hold_pending, and nothing ever tried the pending certificate against the table at its own block. fork_choice_lock reads state.locks, which only evaluate filled, and evaluate only ever ran over the node's own determination. So a certified checkpoint off the node's chain never became a lock and never constrained the sink search, whatever spec 3.5 says. Second cause, found tonight on the harness: protocol/flows/src/v10/blockrelay/flow.rs skips a relayed block whose blue work is under the virtual's merge-depth root ("hence we are skipping it"), and the certified chain is lighter by construction, so the node on the heavier side never received the certified chain's blocks at all: in the first runs on the fixed consensus n0 held B's certificates by gossip for the whole heal window and B's blocks never arrived (n0's log shows only its own blocks "via submit block" after the reconnect).

The fix. Fork: ingest_off_chain (verifies against voters_at of the certificate's own block, Q3 and Q5 by quorum_at from that block's past, the lock chain by off_lock_chain, then LOCKED with a FinalityLock notification and a VirtualStateProcessingMessage::Resolve nudge so the sink moves without waiting for a block); retry_pending_off_chain on every virtual change; the lock-chain guard in evaluate (a determination off the chain through the node's nearest locks never locks and never aggregates); fork_choice_lock reports a lock beyond the depth-based finality point once; wants_unknown_certified_block and the relay-flow bypass of the merge-depth skip while a pending certificate names a block the node lacks (finality_wants_blocks through ConsensusApi and the session). Not gated on finality_v3_activation_daa: rule v2 took the same pending path.

@@ -477,7 +557,8 @@ table{min-width:560px}

Harness, weight against work (B four keys and 70% of the weight, A two keys and 30%; at the cut A mines 0.6 and B 0.4 blocks/s; WINDOW = weight window, ban and min_daa at fast time). The 120-DAA window of the earlier runs turns every long split into F21's partition-longer-than-a-window shape once the p2p reconnect is added: n0 dials the proxy again on the connection manager's backoff, 84 to 114 s after the heal in every run tonight (the original sweep's 6 s was a short cut), so A's chain is 130 + 84 s = 128 DAA past the cut before any certificate can reach it, past its 120-DAA frozen table (v3) or its own two-thirds share of a sliding table (v2, 126 DAA at W 240 and s 0.3), and A locks alone first. With WINDOW=240 and WARM=320 the bound is 400 s (v3) or 210 s (v2) after the cut.

RunNodeRule, W, splitB locks during the splitn0 reconnectedn0 adopted off-chainFinal chainConflictingDisagreeingVerdict
on 90 s (the sweep's framing)c4 consensus fix, no sync hookv3, 120, 90 s0 (36 blue blocks for B, a new index needs 50)6 s0A, all three (no certificate to follow)00not the C4 shape
v2 90 ssamev2, 120, 90 s1 (index 8)6 s0apart5 / 5 / 52n0 locked 10 alone at 18:32:42, B's certificate for 8 reached it at 18:32:43: F21's bound (63 DAA of A's own chain) crossed before the heal
on 130 ssamev3, 120, 130 s1 (index 9)84 s0apart9 / 3 / 32n0 locked 12 alone at DAA 359, one window after lock 8 at 239, 6 s before the reconnect
off 150 s (control)sameno certificate, 150 s096 s0A (heavier), all three; B's nodes re-determined 2 indices00PASS, as in the sweep
on 130 s, W 240samev3, 240, 130 s2 (10, 11)114 s0 (certificates 13 and 14 pending, blocks unknown)apart00the sync gap: n0 never received a B block
v2 130 s, W 240samev2, 240, 130 s2 (10, 11)114 s0apart, n0 locked 16 alone at 293 s0 / 1 / 10the sync gap again (n0 reconnected after v2's 210-s bound)
v2 130 s, W 240c4 fix with the sync hookv2, 240, 130 s1 (index 12)84 s3 (12, 13, 14 within 2 s of the first B block; 11 re-determined)B, all three, A's split tip abandoned00PASS
on 130 s, W 240samev3, 240, 130 s0 (Poisson: 52 blue blocks, the index fell just short)84 sn1 1, n2 2 (B's nodes adopted A's post-heal certificates and moved before IBD)A, all three00the mirror case; not the C4 shape
on 140 s, W 240, addPeer at the healsamev3, 240, 140 s2 (11, 12, first at 12 s)3 s (the harness now dials through addPeer; the address goes as {ip, port})1 (12 by certificate; 11 verified on the new chain)B, all three, A's split tip abandoned00PASS

Reading. With the consensus fix and the sync hook, a node on the heavier chain that receives a certificate for a chain it has never seen fetches that chain, verifies the certificate at its own block, locks it, moves its sink to the lighter certified chain and re-determines its own records onto it (the v2 W 240 row: 0 conflicts, 0 disagreements, every node on B's chain, which is the spec's F1 and the design's Fork choice items 1 to 4). The same holds under rule v3 with the frozen table on (the last row: B certified 11 and 12 during a 140-s split, n0 reconnected 3 s after the heal once the harness dialled through addPeer, adopted 12 by certificate and ended on B's chain with the other two, 0 conflicts, 0 disagreements). The fix does not and cannot cover a partition that outlasts the bound before the certificate arrives (rows 2, 3 and 6): there the node has already locked alone and 3.11.4 keeps that lock, the late certificate is CONFLICTING for the operator. On the live devnet (W 7,200 DAA, two hours) the bound is two hours after a side's last lock, so every partition under that heals by certificate. Raw: scratchpad c4-results-*.md, node logs c4-*-n0.log.

-

5 October 2026 (evening), FUD ledger sweep round 6

+
+

5 October 2026 (evening), FUD ledger sweep round 6

Owner: the consensus engineer and cryptographer agent, worktree igneum-wt-fud-a (branch fud-a), 15:45 to 16:40 UTC. The Mac was loaded throughout (two cargo builds, a txgen run and a fee-switch simnet by other agents; load average over 100), so every figure below is a count, an index, a byte or a number from another machine; the only millisecond figures are the browser verifier's, taken as ratios and labelled. Live reads through the Apple M5 Max node's wRPC (ws://127.0.0.1:28640) and the log intake (Neon HTTP SQL, lines split server-side), never a restart.

Rolled-out fixes, the live evidence (F23, F24, G12, X18, M30, M31, F25, M20, M26, M27, X21). The 0.3.5 cut at 06:33 UTC (master 2054ae3, fork 20139145) carried fud-consensus, m20-pruning and miner-reliability; every reachable app machine was on the node line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation (docs/plans/release-0.3.6.md 8j, "live devnet: the first shards proven"). Node logs of the five app machines over the 10 hours to 15:45 UTC, one intake query (scratchpad fud-a/nodelines.mjs):

Linethe three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT)the RTX 5090 Windows rigMacSam's MacUS laptopReads on
Finality: state blob of layout 1 read and converted11111F23 (persisted state migrated, no locks lost)
certificates refused "names N voters"00000F23
CONFLICTING, EQUIVOCATION0, 00, 00, 00, 00, 0F23, F24
re-determined (checkpoints 2970 and 2971 at 09:56 UTC on three machines at once; the rest at first start)78401F24
LOCKED1,1981,2041,197683961all
Consensus params digest at startf10a4eab...f10a4eab...f10a4eab...f10a4eab...f10a4eab...X18, G12
consensus params digest mismatch (07:15 to 07:35 UTC, the hand node restarted early with another proving height)115465600X18
PoW cache built (each at a node start; none at the epoch rolls of 14:29 and 15:29 UTC)55815M30
@@ -498,7 +579,8 @@ table{min-width:560px}

C4, the overlay against GHOSTDAG, measured (tools/finality-attacks/c4.mjs, the live node line target-036 2b6d23ef, fast time, 3 nodes, 100-ms proxied links, ports 29800+; "weight against work": side B with four keys and 70% of the weight table, side A with two keys and 30%; at the cut the rates swap, A at 0.6 and B at 0.4 blocks/s for 150 s, so A builds the heavier chain while only B can certify; heal window 200 s). The first run went out with the override unapplied (the harness library reads it at import; fixed the same hour) and is kept as the rule v2 control:

RunRuleNew locks during the split A / BFirst lock A / B (s)Blue score A / B at the healSinks after the healFinal chainConflicting certificatesDisagreeing locked indices
controlv2 (the live devnet's rule), min_daa 1204 / 3133 / 9335 / 296apart (n0 on its own)none (a finality fork, F21)1 on n01
offno certificates (min_daa never)0 / 0none / none330 / 301one sink on all threeA's (the heavier)00; B's nodes re-determined 2 indices onto A's chain; n0 reconnected 36 s after the heal
on, split 150 sv3 from checkpoint DAA 00 / 2none / 39326 / 313apartnone3 on n02 (n0 reconnected 66 s after the heal, A's chain past the 120-DAA table by then)
on, split 90 sv30 / 2none / 3278 / 265apartnone3 on n02 (n0 reconnected 6 s after the heal, A's chain at about 58 DAA, inside the table)

Reading (the NEW finding, ledger C4). With the module off GHOSTDAG alone converges on the heavier chain and the losing side's records re-determine (F24 works when the chain moves). With the module on the overlay holds during the split (A, with 30% of the frozen table, locks nothing; B locks 7 and 8) and then fails at the heal in the shipped node: B's certificates for blocks off n0's chain are "kept pending until the chain decides (no lock at this index)", n0's chain never decides because GHOSTDAG keeps its heavier tip and nothing turns the certificate into a fork-choice constraint, and once n0's last lock (index 7, DAA 209) is one window old (DAA 329) the frozen table stops applying on A's chain ("no frozen table (no lock on this chain inside the window)"), A's two keys are 100% of A's own window (B's post-cut blocks are red there) and n0 locks 10, 11, 12 alone; B's certificates for 10 and 11 then log CONFLICTING on n0 (n0 log, 16:27:04 to 16:29:54 UTC). A finality fork from a 96-s honest partition, no attacker, table intact at the heal; the 150-s run and the v2 control end the same way. The spec's fork choice ("GHOSTDAG among tips through all certified checkpoints", 3.5) is therefore implemented only for certificates over blocks already on the node's chain. Fix named in the ledger entry: verify an off-chain certificate against the table at its own block and let it constrain fork choice (a certificate-driven reorg), then re-determine. Raw: scratchpad fud-a/c4-results-*.md, node logs c4-on90-tmp/, c4-v2-control-tmp/.

-

5 October 2026 (evening), the 9070 XT on the eGPU: why 17.9 MH/s, and what moved

+
+

5 October 2026 (evening), the 9070 XT on the eGPU: why 17.9 MH/s, and what moved

the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) (ae432dc7, Windows 11, Ryzen 7 9800X3D with its gfx1036, RTX 5090 on CUDA), an AMD Radeon RX 9070 XT (gfx1201, RDNA 4) in a Sonnet Breakaway Box 850T5 over USB4, Adrenalin 26.9.2 (OpenCL driver string 3683.0 (PAL,LC), platform OpenCL 2.1 AMD-APP (3683.0)). Branch opencl-rdna4. the maintainers: "the hashrate is low" (17.9 MH/s with one worker; two workers on the card earlier gave 8.9 and 9.4).

Before, from the three-card Windows rig's own app log (node tools/logs.mjs win-ae432dc7-20261005-181046, the miner's STATUS line for the card amd:1:gfx1201, 2^21-nonce jobs): hash=17.82 MH/s wall (17.83 MH/s inside jobs) ... idle=0.3%. Wall equals inside, so the host loop (template fetch, job line, read-back, scan) costs nothing measurable; the dispatch itself is slow. The worker's ready line: exchange 0 (local memory: AMD lists cl_khr_subgroups and no shuffle extension), batch 4194304, dataset-log2 28 (1 GiB), device [1] gfx1201 on the 3683.0 platform, AMD wavefront width 32. The same card was listed again as [3] gfx1201 on the older platform 3652.0 (the 32.0.21042 driver's OpenCL registration is still present after the update): that is the two-worker run.

Hypotheses, each with its number (the measurement job rdna4-bench-1, 18:39:25 to 18:41:17 UTC, the card switched off in the app through POST /api/cards for key amd:1:gfx1201 only, the 5090 untouched; worker exe sha256 53c7e8c9…5403e10 built from this branch by proto-cuda/nvrtc/build-windows.sh; read back with node tools/jobs.mjs rdna4-bench-1):

@@ -522,7 +604,8 @@ table{min-width:560px}

Probes with a fresh seed per repetition (the first probe round replayed the same addresses on repeats, so its low-lane rows were cache hits; fixed in probeLaunch, job rdna4-serve-4): 1024 MiB chase at 256 lanes 276 ns per dependent load, at 1,024 lanes 422 ns, at 4,096 lanes 1,560 ns (2.63 G/s, the cap). Random 64-byte lines (four uint4 loads per step) at 1024 MiB: 2.46 to 2.88 G lines/s = 158 to 184 GB/s in lines, the same count per second as the 4-byte chase: every random 4-byte read costs this card a 64-byte line fetch. Coalesced stream over the whole 1024 MiB: 635.2 GB/s against the vendor's 640 GB/s, so the memory clock is in its full state and the card is not parked. Inside the 64 MiB buffer the line probe reaches 8.3 to 14.0 G lines/s (533 to 894 GB/s in lines: the Infinity Cache, approximate).

A second defect found on the way: the pack export race. the three-card Windows rig's app log since its 19:02 UTC restart (node tools/logs.mjs win-ae432dc7-20261005-190232): worker error: error 0 pack packs\devnet: the epoch seed bytes do not give the pack's IGNEUM_SEEDW_INIT at 19:07:03, 19:07:19 and 19:08:07, so the 9070 XT was not mining at all in the app while this entry was written (my job rdna4-serve-1 at 18:43 hit the same folder in the same state). Cause, from app/igneum-app/src/engine.rs prepare_worker: one thread per card, each running igneum-miner export-pack into the one folder packs\devnet; across an epoch change the two exports interleave and the folder keeps one epoch's program.h with the other's seeds.txt until the next export. Fix on this branch: a process-wide mutex around both export sites (EXPORT_LOCK); the second export rewrites the same pack. Not measured in the app yet: it ships with the branch.

Answer to the maintainers. The 9070 XT does 2.5 G random 4-byte reads per second from its memory for this access pattern, and the hash needs 128 of them, so about 19 MH/s is this card's ceiling for the current program class, on any slot; it was running at 92% of that. The eGPU link cost 6% per job through the read-back, now removed (17.87 against 16.88 MH/s inside jobs standalone). The duplicate platform that halved it to 8.9 + 9.4 is folded away. The pack race that stopped it is serialised. Nothing else in the worker's control moves the number: the next step for this card is the program class itself (fewer, wider loads per hash would favour AMD's 64-byte lines), which is a consensus question, not a worker one.

-

5 October 2026 (night), Ember Tune: the two-knob efficiency tune, the fleet prior, and what the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) could measure tonight (miner-community-lead)

+
+

5 October 2026 (night), Ember Tune: the two-knob efficiency tune, the fleet prior, and what the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) could measure tonight (miner-community-lead)

Branch ember-tune (54ff1bc), docs/plans/ember-tune.md. Every card tuned for MH per watt out of the box: the power limit and the core clock cap stepped on the live kernel (memory clock never touched), the point with the best MH per watt within 1% of the top rate kept and pinned, every result uploaded as a TUNE {json} record (a hash of the install id, no address) and folded per (card model, driver major, program class) into a prior the signed manifest carries back, so a new card of a known model starts there and confirms it in two steps.

What was measured tonight (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT), machine ae432dc7, from its own uploads to the intake):

FactWhere it was readConsequence
The installed 0.3.9 app runs as <pc-hostname>\Admin with elevated=False (account line, 19:02:33 UTC)app log win-ae432dc7-20261005-190232nvidia-smi -pl and -lgc need administrator rights; the one prompt is the Power control switch (3562f26), which the app never raises by itself
Two in-app sweep attempts aborted at 20:09 UTC: the_elevated_helper_did_not_run_(the_administrator_prompt_was_cancelled)the same logno stored sweep result from today exists; the 5090's two-knob tune is owed to the morning (one click on Power control, then it runs by itself within 2 minutes of steady mining)
The RX 9070 XT left the three-card Windows rig's bus at about 20:40 UTC, was back at 21:09 and gone again at 21:22:59 UTC (the eGPU link, third drop today)the telemetry agent and the the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) schedulerthe AMD path (ADLX, no prompt) is unit-tested on the helper's captured line shapes; its end-to-end run waits for the card
@@ -538,7 +621,8 @@ table{min-width:560px}
CapLimitMH/sWMH/WGPU C
100%575 W127.38309.90.41164
90%518 W99.32313.60.31765
80%460 W123.11312.20.39465
70%403 W127.38310.90.41065
60% (floor 400 W)400 W127.38311.30.40965

Reading: the cap does not bind on this hash (310 to 314 W under every limit, as the 4 October stability line said), so the power knob is flat at 0.41 MH/W on the 5090 and the saving must come from the clocks; the 90% and 80% rows' rate dips at the same draw are stalls inside those holds (a worker restart or a template wait), not the cap. The clock ladder's first step (2,781 MHz at 575 W) was requested at 15:37:47Z and never measured: the playbook's own watchdog killed the live engine at 15:39:03Z (all three cards mining at 177 MH/s) because its idle clause sampled one log line and read "idle" from a missing match; the 4070's and the 9070 XT's plans never ran. Consequences: the 5090 is probably left with its core clock locked at 2,781 MHz (an -lgc lock persists until -rgc or a reboot) under the 575 W cap, which costs little rate; freeing it needs administrator rights; and the Power Helper was NOT registered by this run (the registration lived only in the installed app's cap path, which a --sweep engine skips). Fixed the same hour: the watchdog's idle rule (three consecutive status lines reading 0.00 MH/s and 300 s, never a missing match), the after snapshot and the engine-log dump on every exit, and an elevated tune engine registering the task itself before its first step. The decided way out: the maintainers switches Power control ON in the 0.3.13 app (its one prompt registers the task from the install folder), a job frees the clock through the task (rgc), the tune runs unelevated through the task.

Consequence for the tiers: an AMD card is tuned on its power limit alone until its stock core clock is read (a 9070 XT at -30% is the floor the driver allows, 4 steps, 5 minutes); every NVIDIA card's two-knob plan waits on the user's one click on Power control; the re-run on the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) is held until the quit's source is named (the event-log collect) and follows the 0.3.11 rollout (the update clears the jobs folder, so the engine and the helper are fetched again), with the scheduler's slot.

-

5 October 2026 (night), read width of the lottery hash: 4, 16 and 64-byte loads, a per-load mix, a written scratch; three cards (gate 1 experiment, cryptographer)

+
+

5 October 2026 (night), read width of the lottery hash: 4, 16 and 64-byte loads, a per-load mix, a written scratch; three cards (gate 1 experiment, cryptographer)

Branch readwidth (commits 019b014, b970dda, 4badcee, a9e002c, d0018cf and the entry commit); plan and recommendation in docs/plans/read-width.md. Nothing here changes consensus: every class sits behind igneum-pow --class and the default class is generator version 2 byte for byte (igneum-pow/tests/packs.rs passes on the four pinned packs after every commit). Question (the maintainers, after "the 9070 XT on the eGPU" above): would wider reads keep the latency-bound random-access property while closing the vendor gap. Additions from the coordinator: a per-load width drawn from an era-fixed mix, and a written per-warp scratch (measurement only, no soundness claim).

What a class does (igneum-pow/src/generator.rs LoadClass, verify::fold_words, the three emitters): a load of W words reads the W-word-aligned address (src AND MASK) AND NOT (W - 1) and folds every word into dst (x = dst ^ w0; x = (rotl(x, 11) * 0x9e3779b1) ^ w[j]); W = 1 is the lottery hash exactly (w4 = pack bcc1248b10cc90f2). A mix class draws W per load with one extra below(100) roll per instruction. A scratch class scr<k>k<kb> turns k of the 16 memory slots into read-modify-writes of a 16-byte slot of the lane's share of a kb KiB per-warp scratch (kernels run persistent warps, one per block or work-group; a slot reads as a seed-and-base fill until the unit writes it, behind a per-unit tag). Program ids carry the class. Dependent chain and 32-lane unit unchanged.

Correctness: 23 packs (proto-cuda/packs-readwidth/, Rust CPU reference vectors). Every pack passed its three vector units and the cache and dataset checks on Metal (M5 Max, proto-metal/packbench), Apple OpenCL (--bench-pack), the RTX 5090 (NVRTC, igneum-worker-cuda --bench) and, the 16 width and mix packs, the RX 9070 XT (igneum-worker-opencl --bench-pack); the 2^24 batch fingerprints agree across all four runtimes on every pack (for example w16 e7c890445b47af60, w64 836e56e7d496e980, mixB-2 a18ac73098c76007). The clang CUDA emulation (w16, w64, w64x4, mixA-0, mixB-0: 3 of 3 units standalone and 2 of 2 in batch at 2 warps per block) and the clang OpenCL emulation (the same five plus scr2k32 and scr8k128, sub-group 32 and, width packs, wave64 with sub-group shuffles) pass with equal fingerprints per configuration. Acceptance rule on the classes: 60 candidates per class, rejection 0 to 14 of 60 (w16 and w64 as v2; the mixes the same; the scratch classes' distinct-address bound now covers dataset loads only, since a 64-slot lane scratch repeats slots by design). CPU verifier (M5 Max, one core, avg of 50 units, igneum-pow bench --class): v2 0.604 ms, w16 0.610, w64 0.630, w64x4 0.160, mix50-35-15 0.620, mix25-50-25 0.614, scr0k32 0.600 (1.004 on a loaded re-run), scr2k32 0.657, scr4k32 0.458, scr8k32 0.317, scr2k128 0.535, scr4k128 0.458, scr8k128 0.311; per hash divide by 32. The wide reads cost the verifier nothing (a lane's words lie in one item); scratch ops replace item derivations and make it cheaper.

@@ -552,7 +636,8 @@ table{min-width:560px}

The 9070 XT rows are 2,048 persistent warps (4,096 within 1 percent), arena 64 MiB at 32 KiB and 256 MiB at 128 KiB, working set 1.4 and 1.6 GiB; its control (17.88, the persistent loop) equals its v2 rate (18.15) within 2 percent, and every RMW share costs it 18 to 33 percent: on AMD a scratch op is a dependent 16-byte read plus a write into a region the 64 MB Infinity Cache does not hold for 2,048 warps, so it is memory work there as on the 5090, not the cached op it is on Apple. Apple OpenCL on the same scratch packs (wall time, --bench-pack --warps 2048): scr0k32 27.85, scr2k32 28.58, scr4k32 32.43, scr8k32 47.93, scr2k128 25.67, scr4k128 27.24, scr8k128 32.93 MH/s, the Metal shape within 4 percent, fingerprints equal. Bytes moved per scratch op: 16 read + 16 written (the tag word included); per hash at 50 percent, 1,024 read + 1,024 written beside 256 of dataset reads. The 5090 at 4,096 launched warps (above its 4,080 resident) lost 2 to 26 percent (scr8k32 90.0 MH/s), so the rows above are the in-capacity launch.

Readings. (1) Same count, wider: the vendor gap does not move at 16 B (7.8x) because on the 9070 XT a 4-byte read already costs a 64-byte line and on the 5090 a 16-byte read costs one 32-byte sector, the same as 4 bytes: the memory systems do identical work, only the fold's input grows. At 64 B the gap closes to 4.1x, entirely by the 5090 losing half its rate (its share falls to 0.58 and its DRAM traffic reaches 589 GB/s, 37 percent of the stream: bandwidth, not latency, bounds it), while the 9070 XT and the M5 Max do not move. (2) Fewer, wider (w64x4): 3.7x, but every card runs 4x faster because the dependent chain is 32 loads long instead of 128; the 5090 sits at a 0.56 share (bandwidth), so a chip with more bandwidth per dollar than a GPU gains, which is the Ethash shape the design avoids. (3) The mix: the hour-to-hour spread is 7 to 22 percent of the median per card (the 5090 the widest, because its 64-byte loads are the expensive ones and their count per program runs 2 to 8 of 16); the programs with many 64-byte loads (mixA-3, mixA-5, mixB-2) are the slow hours on the 5090 and the fast ones nowhere. (4) The scratch: on the 5090 every RMW share costs 12 to 48 percent against the persistent control, the 32 KiB arena less than the 128 KiB one (the smaller arena, 64 MiB over 2,048 warps, sits inside the 96 MB L2); on the M5 Max the 32 KiB rows are FASTER than the control (+12 and +74 percent at 25 and 50 percent), because the arena (128 MiB over 4,096 warps) lives in the chip's caches and a scratch op is cheaper than a dataset read, so replacing dataset loads raises the rate: the scratch at these sizes is not memory work on Apple and is partly cached on NVIDIA. The chip row for these variants comes from the ca2-soundness branch; what this entry gives is the GPU cost and the share. (5) Latency-bound shares: v2 0.87 to 1.01 on the three cards, w16 0.84 to 1.03, w64 0.58 (5090) and 0.78 (9070 XT); the Apple M5 Max's shares above 1 are an Apple OpenCL probe under load against a Metal rate.

Jobs: run-readwidth-5090-20261005 and run-readwidth-9070-20261005 (probes; the packs refused for their string seeds, fixed in a9e002c), run-readwidth-5090-20261005c, run-readwidth-9070-20261005c (benches), run-readwidth-9070-scratch-20261005d (the scratch packs after the __local fix d0018cf, AMD's compiler requires the exchange buffer at the kernel's outermost scope); read back with node tools/jobs.mjs <id> --all. Mac commands and logs: docs/plans/read-width.md section 3. The worker exes for the jobs: proto-cuda/nvrtc/build-windows.sh on this branch (mingw), sha256 of the CUDA one 6f46336f...defe1.

-

5 October 2026 (night), the hot table on the M5 Max: a second table sized to GPU cache beside the 1 GiB dataset (Counter ASIC 2.0 layer 5)

+
+

5 October 2026 (night), the hot table on the M5 Max: a second table sized to GPU cache beside the 1 GiB dataset (Counter ASIC 2.0 layer 5)

Branch ca2-cache (on readwidth 1ea7a52), docs/plans/hot-table.md. Apple M5 Max, measure lock held, the Apple M5 Max's load average 14 to 27 throughout (other agents' CPU work; the lock serialises builds and measurements, not every process), so the ratios inside one session are the result and the absolute rates are not quiet numbers. Packs proto-cuda/packs-ca2-hot/hot{32,64,96}k4, hot64k2, hot64k8 from igneum-pow export --seed igneum-genesis --day 2026-10-03 --class hot<S>k<k> (the version 2 genesis program with k of its 16 loads redirected to an S MiB table H keyed by seed_words("igneum-hot/" || seed bytes), read at H[mulhi(src, words)]).

Probe (proto-opencl/igneum-bench-cl-igneum-genesis-mh --memprobe --probe-mib S, Apple OpenCL, wall time, best of 3, 256 dependent steps per lane, work-group 256; the ceiling row is 4,194,304 lanes):

MiBchase at 4,096 lanesns per dependent loadchase ceiling, G loads/sindep x8 ceilingstream
323.51 G/s1,16821.721.8138.7 GB/s
643.631,12912.813.0199.1
963.301,24212.312.7242.6
10242.221,8443.503.50521.5
@@ -572,7 +657,8 @@ table{min-width:560px}

Rates (5 dispatches of 2^24 after a warm-up; 5090 --bench --block-warps 1, 9070 XT --bench-pack --device 1 work-group 256; every row check=PASS with the Apple M5 Max's fingerprint; v2 references from the readwidth entry, same night, same workers: 136.1 and 18.15 MH/s):

Pack5090 MH/sg9070 XT MH/sgideal g
hot32k4146.61.0819.791.091.33
hot64k4140.81.0318.731.031.33
hot96k4138.51.0218.331.011.33
hot64k2137.51.0118.171.001.14
hot64k8163.61.2022.321.232.0
hot32k4a118.70.8715.270.841
hot64k4a115.40.8514.620.811
hot96k4a114.40.8414.560.801

Reading: the probe promises a full hit rate on the 5090 (every S inside the 96 MiB L2 at one ceiling, 6.4x DRAM) and the hash gets 2 to 8% at k = 4 and 20% at k = 8; the 9070 XT the same shape. The dataset's random lines evict the table from the shared cache on every card. The added form costs 13 to 20% of the rate. Recommendation in docs/plans/hot-table.md section 6.4: do not adopt layer 5 in either form on these measurements.

-

5 October 2026 (night), mixer x4 and the cache growth rule: the class v3 dataset construction, with the x8 candidate (Counter ASIC 2.0; branch ca2-mixer on ca2-v3 6c75dad; cryptographer's lane)

+
+

5 October 2026 (night), mixer x4 and the cache growth rule: the class v3 dataset construction, with the x8 candidate (Counter ASIC 2.0; branch ca2-mixer on ca2-v3 6c75dad; cryptographer's lane)

Machine: Apple M5 Max, 64 GiB, Darwin 25.6.0. Write-up docs/plans/mixer-x4.md; chip model docs/analysis/chip-model-v3.md; code igneum-pow (LoadClass mixer_mult and growth, memhard::Shape, the schedule, the three emitters), packs proto-cuda/packs-ca2-mixer/, tests igneum-pow/tests/mixer.rs and tests/packs.rs. Commits 0fc0ad1, 66eeba3, e4c04a7, 7ce8d1e, 504cae4, fe4e193 and this entry's.

What changed. Under program class v3 (V3_CLASS = LoadClass::MX4) every mixer application of the item derivation is m = 4 applications with round keys (r m + j + 1) x 0x9E3779B9, the 8 dependent cache reads per item unchanged; the cache doubles when the dataset doubles (growth_doublings(d) = floor(log2(1 + d / 1460)): 2^26 words to day 1,459, 2^27 from day 1,460, 2^28 from day 4,380). Version 2 is byte-identical: fresh exports of igneum-genesis-mh and igneum-devnet-v4-epoch0 diff -r IDENTICAL against the checked-in packs, and the crate tests regenerate every pinned file. A v3 program of a seed is the v2 program of that seed instruction for instruction (v2 loads take no width roll); only the dataset words and the hashes change.

Bit-exactness, with-lock.sh run, 22:05 and 21:45 UTC: the two pinned v3 packs (mx4-genesis, mx4-devnet-epoch0: dataset words 0..15 61ff2180 0d4c7e6c ... and afe80d67 b9fbd029 ..., word MASK 5020180e and e6a99c7a, unit at base 0 lane 0 63acd2d273f475ba and 212c6442b51e87ae) and the two x8 candidate packs on Metal (packbench, built from this branch) and Apple OpenCL (igneum-bench-cl --bench-pack): 3/3 standalone and 3/3 in batch, 96 of 96 lanes, cache FNV-1a 64 unchanged from v2 (48c4f5bf24166b2e, 448274a57f508cbc), dataset head, word MASK and 64 samples PASS, one 2^24 fingerprint per pack across both harnesses (mx4 6f48d5a2aa0dbe5f and 73caaebb28e808fe; mx8 7c28cfb06c5c65a9 and bbb183f72692f840); hash rate the v2 rate (27.5 to 27.7 MH/s GPU time, the hash kernel is unchanged). Fuzz: 200 class v3 programs (4 units each across the 32-bit range, one in the top 256 nonces) interpreted twice on the CPU, 800 of 800; the same 200 packs on Metal 200 of 200 (--batch-log2 9 --batch-base 4294967040, the wrapping unit inside the window), every tenth on Apple OpenCL 20 of 20; x8: 50 of 50 on Metal, 5 of 5 on OpenCL. Stats (8,192 outputs per seed, two seeds): v3 avalanche 49.97 to 49.99 percent, worst bit z 1.92 to 3.09, 0 duplicates (v2 beside it 49.87 to 49.98, z 2.25 to 2.30). Edges: items 0, 1, 2^28 - 1, 2^32 - 1 by hand at m = 1, 2, 4, 8; words 0, 15, 16, 17, MASK - 1, MASK through the fetch path. Determinism: two epochs, every vector and file equal and equal to the pinned pack. The scratch soundness tests of ca2-soundness (cherry-pick 0d8f745) 7 of 7 on this tree. Crate: 44 lib + 12 packs + 4 mixer + 7 scratch tests pass. A first Metal fuzz run reported 200 of 200 FAIL on an empty RESULT line (a packbench built before the --batch-base cherry-pick); it was read as a failure, the harness rebuilt, the run repeated.

@@ -581,7 +667,8 @@ table{min-width:560px}

Reading: the mixer multiplies the verifier's ALU part only (the 8 dependent misses per item are unchanged), hence 1.45x and 2.1x and not 4x and 8x; the Apple M5 Max's GPU build is latency-bound and does not move with the mixer, so the "under 1 s on every discrete card" half of the x8 rule is the RTX 5090 machine job (five packs, relay/playbooks/mixer-x4-pc1-bench.ps1, waiting for the go). Verification throughput (C19): a quiet 2026 core serves about 1,100 shares per second at x4 and 800 at x8 (1,660 at v2, re-cutting spec 09's 2,270), a 22,000-member pool at one share per 10 s needs 2 cores at x4 and 3 at x8, IBD over 108,000 headers is 1.6 min at x4 and 2.3 at x8 on that core; the 10 ms gate keeps 8.0 ms (x4) and 7.1 ms (x8) of margin on the loaded core, 6 to 7 ms on a 2019-class laptop core (approximate, unmeasured, O-1.14).

Chip model (docs/analysis/chip-model-v3.md): the on-die-cache recompute chip at 50 T op/s against the 5090's measured 136.1 MH/s: v2 334 MH/s, 2.45x bare, 7.4x with the 3x fixed-function factor; x4 83.5 MH/s, 0.61x bare, 1.84x with the factor, 1.53x with the 128 mm^2 N5 mirror deducted at equal silicon; x8 41.7 MH/s, 0.31x, 0.92x, 0.76x. The claim at x4 is "under 2x" with the margin thin on the equal-budget convention (a 3.3x factor or a 10 percent larger budget reads 2.0x); the hot table in the added form would have raised it to 2.1x to 2.2x at the 5090's g (kept as measured, not adopted). Nothing here is a measurement of a chip.

Addendum, 22:15 UTC: the verifier regression, the the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) build rows, and x8 into v3. The era agent measured the same v2 input with readwidth's binary (0.604 ms) and ca2-v3 HEAD's (1.33) in one minute; bisected under the measure lock to this branch's 0fc0ad1 (seam 6c75dad 0.610, 0fc0ad1 1.332; the "loaded box" reading above was wrong by that factor, the load was real but the 2x was the code). Cause: the item loop (derive_items) inlined into MemhardCpu::fetch; the mask hoisted, the mask constant, and the constant-mask loop inlined all stayed at 1.33, the same loop #[inline(never)] read 0.60 to 0.62. Fix: derive_items_mask, out of line, one instance per cache size with the line mask a constant. Measured the era agent's way (readwidth's binary beside the fixed one, same input, same minute, 22:07 UTC): v2 0.607 / 0.610 against 0.609 / 0.611; on the fixed binary x4 1.238 / 1.237 (2.0x), x8 2.077 / 2.058 (3.4x), worst cold 2.15 ms; the increments (+0.63, +1.46 ms per unit) equal the slow binary's. Lesson, the class: an inlined item loop costs 2.2x and nothing in the suite sees it; a verifier benchmark with a pinned bound in the crate's CI is filed for the next cut, and until then every change to the item loop is measured against the previous binary on the same input in the same minute. the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) (job run-mixer-x4-pc1-20261005, 22:00 to 22:04 UTC, the worker's cache ... dataset ... ms wall line): RTX 5090 dataset 23 to 25 ms at v2, x4 and x8; RX 9070 XT (gfx1201) 72 to 77 ms at all three; every fingerprint equal to the Apple M5 Max's; rates the v2 rate (136.5 to 137.4 and 18.0 to 18.2 MH/s). Decision under the delegated rule (coordinator, 22:05 UTC): x8 enters class v3 (V3_CLASS = MX8); pinned packs mx8-genesis (7c28cfb06c5c65a9) and mx8-devnet-epoch0 through the chain path with the era inside (90f794dd556f7a3b, Metal and Apple OpenCL, 22:12 UTC); the x4 packs kept as the candidate's record. Chip headline at x8: 41.7 MH/s, 0.31x bare, 0.92x with the 3x factor, 0.76x at equal silicon (docs/analysis/chip-model-v3.md).

-

5 October 2026 (evening), EVM transaction relay: three nodes in a chain, every transaction sent to one end included by the other two miners (execution and networking engineer)

+
+

5 October 2026 (evening), EVM transaction relay: three nodes in a chain, every transaction sent to one end included by the other two miners (execution and networking engineer)

Until this change the node did not relay EVM transactions to its peers, so a transaction sent to one node was only ever included by that node's own templates (this file, "5 October 2026 (afternoon), live devnet: real transactions": 3,794 transfers, all in the Apple M5 Max's blocks; execution-layer ledger item 9). Fork branch tx-gossip (worktree vendor/igneum-node-txgossip, from release-0.3.6 a24ab01a, commit e242acd0), main repo branch tx-gossip. Design in docs/design/execution-layer.md 1.4 "Relay"; the hand-out cooldown of its 10.2 table is gone with it (row "Mempool hold").

What was built. Three p2p messages after Kaspa's own transaction relay (protocol/flows/src/v10/txrelay/flow.rs): an inventory of admitted hashes, a request for the unknown ones, one answer with the raw bytes (protocol/p2p/proto/p2p.proto, payload numbers 72 to 74). Two flows per peer (protocol/flows/src/v10/evmrelay.rs), a pump that announces the mempool's admitted hashes every 250 ms, a sink trait the execution layer implements (kaspa_consensus_core::evm::EvmTxSink, igneum/exec/src/service.rs EvmTxRelaySink), and the mempool's side: every admitted hash queued for gossip, executed, evicted and invalid hashes remembered (65,536) so a second announcement is not requested, a 50,000-transaction cap, and the hold on block-added in place of the 4-second cooldown (the executor subscribes to consensus BlockAdded; a transaction leaves the templates when any DAG block carries it and comes back if a chain block skipped it). Limits per peer in the table.

LimitValueOver it
Hashes announced to us, or requested from us2,000 per second, burst 8,192the surplus of the message is dropped (the sender paid as much as we did)
Hashes per inventory or request message4,096disconnect
Bytes per answer / per transaction4 MiB / 128 KiBdisconnect
Transaction failing a state-free rule (malformed, signature, chain id, type 3 or 4)disconnect, hash remembered
State-dependent refusal (nonce more than 16 ahead, fee cap under the base fee, funds, 64 queued per sender, pool full)dropped quietly, hash not remembered
@@ -591,13 +678,15 @@ table{min-width:560px}
Measured, 3-node fast-time run (17:49 to 17:52 UTC)Value
Sent to A / included / pending at the end / failures240 / 240 / 0 / 0 (0 nonce retries, 0 deferred, 0 throttled)
Included per second over the send span1.98 (target 2)
Inclusion latency p50 / p90 / p99 / max1,545 / 3,058 / 5,033 / 6,017 ms (mean 1,859)
Chain blocks in the window / executed transfers / skipped copies149 / 256 (240 transfers and 16 funding) / 0
Included by miner B (one hop): blocks / with transactions / executed79 / 59 / 151
Included by miner C (two hops): blocks / with transactions / executed70 / 42 / 105
Pool depth, sampled every 5 s on A, B and Cequal on all three at 27 of 27 samples (0 to 6 pending), peak 6
Sinks agree at the endyes
First funding transfer, sent to A, included2.0 s after the send (block 37, mined by B or C)

Reading. Every transaction given to A was mined by B or C within 6 s, two thirds of them within 3 s, with no skipped copy: the hold on block-added kept B's and C's parallel blocks from carrying the same transfer. The afternoon run on the live devnet, through one node with the cooldown, had p50 40.7 s and p90 110.8 s with 50-s quiet stretches; here the 1.5 s p50 is one fast-time block plus the relay and the executor's lag. The pool depth matching on all three nodes at every sample is the convergence. Not measured here: a transaction flood above the per-peer rate (the bucket is unit-tested only), a 13 peer in the fleet (the digest check and the version gate are the evidence), and the hold's 30-s expiry on a block that never reaches the chain (not seen in 149 chain blocks).

Commands: IGNEUMD=vendor/igneum-node/target-txgossip/release/igneumd IGNEUM_MINER=vendor/igneum-node/target-txgossip/release/igneum-miner tools/lock/with-lock.sh run node tools/txgen/relay-net.mjs --rate 2 --duration 120 --wallets 16 --fund 2; the Apple M5 Max binaries from the fork worktree with CARGO_TARGET_DIR=vendor/igneum-node/target-txgossip cargo build --release -j 4 -p kaspad -p igneum-miner --features kaspad/igneum-pow under the build lock (an APFS clone of target-036, 2 min 15 s to clone, 5 min 06 s to build); the suites with node tools/build-job.mjs run --target 1ccfe586 --node vendor/igneum-node-txgossip --targets linux --node-tests "igneum-exec kaspa-p2p-flows" --no-app.

-

5 October 2026 (night), the SP1 CPU prover on the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) beside the miners, and the backend survey: no zkVM proves on AMD (amd-prove agent)

+
+

5 October 2026 (night), the SP1 CPU prover on the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) beside the miners, and the backend survey: no zkVM proves on AMD (amd-prove agent)

the maintainers, 21:50 UTC: "test proving on the amd card?" and "can we test proving on mac?". The analysis with the backend table and the tier consequences: docs/analysis/amd-proving.md. The survey (SP1 v6.8.1 and dev 318dd530 of 28 Sep 2026, RISC Zero, Jolt, OpenVM, ICICLE, sppark; every claim cites a file or page there): on 5 October 2026 no zkVM proves on an AMD GPU; Apple silicon has RISC Zero's shipped Metal prover and ICICLE's Metal backend; SP1, the prover here, is CPU-only off NVIDIA.

Machine: the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) (machine ae432dc7), Windows 11, WSL2 Ubuntu 24.04 as root, 16 cores and 46,994 MB visible to the VM, the Igneum Miner app 0.3.9 mining on the RTX 5090 and the RX 9070 XT throughout (the 5090 at 89% mean utilisation, 59 to 70% minimum, from a 1-s nvidia-smi sampler under the run: the job never touched a card). Signed run job cpu-prove-pc1-small2 (tools/amd-prove/pc1-cpu-prove.ps1), 20:49:00Z to 20:59:49Z: the hosted package igneum-prove-wsl2-pv1b.zip (sha256 df50dee5...) built WITHOUT the cuda feature (6 s warm; the first job cpu-prove-pc1-small built it cold in 126 s), --mode id the pinned pair (shard 0x2b1a81cb..., aggregator 0x474678f3..., pinned 2026-10-05T16:20:38Z), SP1_PROVER=cpu, --mode shard --shard 0 under /usr/bin/time -v. Log: node tools/jobs.mjs cpu-prove-pc1-small2 --all.

FixtureSP1 cyclesSetup sCore prove s (bytes, verify s)Compressed prove s (bytes, verify s)Wall sPeak RSSCPU
block-56-transfers-3shards shard 0 (200 pgas, one transfer)315,47922.75 (client 19.46, shard keys 1.85, aggregator keys 1.44)82.5 (7,310,257, 0.210) VERIFIED199.2 (1,272,897, 0.035) VERIFIED312.129,503,652 kB (29.5 GB)978% (9.8 of 16 cores), user 2,516 s, system 537 s, load max 11.3
block-78-increment (2 transactions, 1 executed 1 skipped)631,12721.7587.0 (7,317,857, 0.209) VERIFIED202.3 (1,272,897, 0.034) VERIFIED322.330,517,916 kB (30.5 GB)979%, user 2,616 s, system 541 s, load max 13.1
block-338-shard1 (one shard at S_p, 60.8 M cycles)not run: the the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) scheduler kept the machine for the Counter ASIC 2.0 gates (21:05Z). Approximate extrapolation: about 29 SP1 shards of 2^21 cycles at about 80 s each, 40 min of core proof, then hours of recursion; floor from the 5090's ratios (6x core, 4x compressed, block-78 to S_p): 9 min core, 13 min compressed

For comparison (this log): the Apple M5 Max CPU on 4 October, loaded, block-56 shard 0: core 83.1 s, compressed 272.3 s; on 3 October the v0 guest on block-78: core 22.0 s, compressed 55.7 s. The RTX 5090: block-78 core 1.4 s, compressed 2.7 s (4 October, mining paused); a full shard at S_p compressed 10.9 s alone and 33.0 s beside the miner; an empty live shard 7.0 to 7.7 s beside the miner (5 October). No fresh Mac run tonight: the measure lock was held from 20:31Z (a read-width packbench, three builds, a 1,500-s proving-v1 network under run) and did not free inside the 10-minute window set for it.

Reading, and the consequences (the design document, every number). Doubling the cycles added 4.5 s to the core proof and 3.1 s to the compressed proof: about 280 s of a CPU proof is fixed cost in the compressed-proof recursion, so no shard size brings a CPU proof under the launch deadline (20 to 60 s behind the tip) or near the 10-s assignment window; it fits only the v1 unproven deadline (600 s), which pays a CPU prover only when no card has proven the shard in 10 minutes. The 29.5 to 30.5 GB peak RSS means the CPU prover needs 32 GB free: a 64 GB an RTX 5090 on Windows (WSL2 takes half the host's RAM by default), a 32 GB Linux machine, a 64 GB Mac; a 16 GB machine cannot run it at all. Per tier: an AMD-only home miner (8, 12 or 16 GB, Windows or Linux) mines and does not prove, and loses the 20% proving-pool share; Apple silicon the same (the M5 Max mines at 26.7 MH/s, this log, 4 October); a mixed rig proves on its NVIDIA cards and the rig installer's prover_decision already skips every non-NVIDIA card (packaging/linux/bin/igneum-rig-lib.sh, branch rig-install), now a stated requirement; the app's provedefault.rs already keeps proving off on Apple silicon and off without an NVIDIA card. Decision asked of nobody: no CPU tier (the analysis, section 4a); the public line for the site, litepaper and Proving tile is in section 4c ("Proving needs an NVIDIA card with 16 GB or more today ... AMD and Apple cards mine. A prover for them lands when a zkVM ships one"). The first job proved nothing because an apostrophe inside a single-quoted awk program ended the quote and bash refused the loop while the job reported exit 0; the class fix is tools/amd-prove/check-job-bash.sh (bash -n on the embedded bash body before publishing) and the same bash -n inside the job before the run, both shown to refuse the bad body and pass the fixed one.

-

Counter ASIC 2.0, the numbers

+
+

Counter ASIC 2.0, the numbers

5 October 2026 (night). The chip-resistance layers measured on the three cards we own (Apple M5 Max, RTX 5090 on the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) and the RTX 5090 Windows rig, RX 9070 XT on the three-card Windows rig's eGPU), the decisions taken under the maintainers' delegated rules for the devnet, and the chip model before and after. Every number is from an entry above or from the plan documents named; approximate is marked. Levels: docs/plans/counter-asic-2-public.md.

Program class v3 (the devnet, activation by height switch program_class_v3_activation_daa) = class v2's 128 x 4-byte loads, the era draw of the table layout and the working-set windows (layers 4 and 8), the cache growth rule (layer 6, option C: the cache doubles when the dataset doubles), the mixer at x8 (M16's multiplier), reserve family R1 (integer matrix, switched off) and the epoch length as a signalled reserve parameter (layer 9, 3,600 DAA s until a 90% signal). Not adopted on the measurements: wider reads (layer 1), the per-load width mix (layer 2), the per-warp write scratch (layer 3), the hot table (layer 5).

Cardv2 MH/sv3 MH/s, six eras (spread)Bytes per hashLatency-bound shareDaily 1 GiB build, v2 / v3
Apple M5 Max, Metal27.6827.85 to 27.98 (0.5%)5121.0621 / 21 ms
RTX 5090, CUDA137.2135.90 to 137.70 (1.3%)5121.0125 / 23 ms
RX 9070 XT, OpenCL18.0918.59 to 19.18 (3.1%)5120.9574 / 75 ms
@@ -606,7 +695,8 @@ table{min-width:560px}

The chip model, before and after (docs/analysis/chip-model-v3.md, docs/analysis/sram-mirror.md): the strongest chip we can name holds the whole 256 MiB cache on-die (about 128 mm^2 and $46 of silicon at N5, approximate) and computes dataset items on the fly at 50 T integer op/s. Against the RTX 5090's measured 136.1 MH/s: class v2 333 MH/s, 2.4x; class v3 41.7 MH/s, 0.31x bare, 0.92x with a 3x fixed-function allowance (approximate), 0.76x at equal silicon. The claim is "under 2x"; the margin is thin on the allowance (3.3x reads 1.0x) and 9% on the budget. Next levers, named: the mixer at x16 (the verifier at about 4 ms per warp; a 2019-class core unmeasured), a hot table small enough to stay resident beside the streaming dataset.

The user tiers. AMD RDNA 4 sits at about a seventh of a 5090 on this hash (its dependent-read rate: 2.4 G against 17.5 G per second), 2.2x worse per pound at list prices and 4.9x worse per watt (approximate); the card's memory system, not a tuning gap. The integrated tier on the CUDA and OpenCL one-click workers mines v3 with a restart per epoch until per-day dataset reuse lands (0.3.12). Card lifetime under the step schedule: a 4 GB card to year 4, 8 GB to year 12, 12 GB to year 28 with the cache freed after the daily build.

The bounty. A bounty for any chip design beating a GPU by more than 2x on the published model, with a leaderboard by card model, follows the external review (spec O-1.17, January 2027); it is named publicly only once escrowed (docs/plans/funding.md, rule 3), which it is not yet.

-

5 October 2026 (evening), proving v1: segment records, the chain rule, the unproven rule; what was measured tonight (proving engineer)

+
+

5 October 2026 (evening), proving v1: segment records, the chain rule, the unproven rule; what was measured tonight (proving engineer)

Branches proving-v1 (main repository, worktree igneum-wt-proving-v1; fork vendor/igneum-node-pv1 from a24ab01a). Rules: spec 7.8; plan docs/plans/proving-v1.md. Every row names its command. The live devnet was in a degraded state the whole evening: from 18:35Z the RTX 5090 workers on the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) and the RTX 5090 Windows rig exited at start on a pack seed mismatch (the epoch seed bytes do not give the pack's IGNEUM_SEEDW_INIT, restart 60+ on the RTX 5090 Windows rig by 19:05Z, another agent's branch pack-loop), the Apple M5 Max app node was down from 17:45Z, so the RTX 5090 Windows rig mined 3.4 MH/s from its iGPU and the RTX 5090 Windows rig's prover was the only prover; the coordinator held every the RTX 5090 Windows rig measurement at 19:00Z until the fleet mines again.

Step 1, the prover default and its cost

WhatMeasured
The default rule (app/igneum-app/src/provedefault.rs)cargo test --release -p igneum-app provedefault on this Mac (the app crate, build lock, 19:05Z): 5 passed (a 5090 with WSL2 on Windows is on; Windows without WSL2 off with the Set up hint; Linux needs no WSL2 and the 12 GB gate holds, a 10 GB 3080 and a 16 GB AMD card stay off; Apple silicon off; the biggest qualifying card is named)
Mining alone against mining with the prover, first try (the RTX 5090 Windows rig job prover-cost-pc2-pv1, tools/proving-v1/pc2-prover-cost.ps1, published 18:40:48Z, ran 18:41:13Z)VOID: the job waited 20 min for the 5090 worker to hash and it never did (the pack fault above); "mining alone" was 0 MH/s
Mining alone against mining with the prover, the re-run after the coordinator's go (job prover-cost-pc2-pv1b, ran 19:20:36Z to 19:51:17Z; the 5090 worker restored at 19:16Z and hashing throughout; prover OFF by POST /api/prove {"on":false} 19:40:39Z, back ON 19:46:09Z, left on). The job's own /api/state samples stayed empty on the RTX 5090 Windows rig (Invoke-RestMethod returns an object PowerShell 5.1 cannot walk, cards=0, the fix is for the next run), so the hash rate is read from the miner's own STATUS lines (miner-nvidia-1ccfe586-1 uploads, now=... MH/s wall, one every 30 s, the intake table miner_logs)prover OFF, 19:41:09 to 19:46:09Z: n 10, mean 124.72 MH/s, p50 124.81, min 124.10, max 125.38. Prover ON, 19:46:39 to 19:51:13Z: n 9, mean 119.74, p50 118.87, min 118.08, max 123.42. The 15 min before the job with the prover on (19:25 to 19:40Z): n 30, mean 119.88, p50 118.79. So the prover costs the 5090 5.0 MH/s, 4.0% of its hash rate, while it proves the devnet's empty shards one after another (1.4 a minute here: the node's paidShards 559 -> 566 over the 5-min phase). A full shard at S_p keeps the card busier (the 4 October run proved one in 10.9 s); the cost at that load is the chain job's row
GPU memory during proving, first try (phase B of the first job: the prover on for 5 min, 298 one-second nvidia-smi --query-gpu=memory.used samples, the 5090 worker dead so the card held nothing else)memory.used min 1,654 MiB, max 13,816 MiB, utilisation mean 2.7%, power max 190.6 W: the prover alone on empty shards
GPU memory with the miner AND the prover on the card (the re-run's phase B, 298 one-second samples, 19:46 to 19:51Z)memory.used min 3,396 MiB (the miner's dataset and program resident), max 15,590 MiB, utilisation mean 92.9%, power max 328.6 W. So the prover's own peak is about 12.2 GB on an empty shard (15,590 minus the miner's 3,396), and the two together need 15.6 GB: a 16 GB card (5080, 9070 XT class, if it had a CUDA path) sits 0.4 GB under tonight's peak with no room for a full shard, a 24 GB 4090 has 8.4 GB of headroom, a 12 GB card cannot mine and prove at once on this build. The full-shard peak is the chain job's row
Shards per minute with the mining worker deadthe node's paidShards 510 -> 518 over the 5-min phase: 1.6 shards a minute from one 5090 through the app's loop (export, cut, prove, sign, submit)
Host RAM (Windows Win32_OperatingSystem and the vmmem working set, sampled every 15 s)host used 25,550 MB of 63,132 MB at the end; the WSL2 VM's working set 7,915 MB (2,334 MB used of 30,914 MB inside the distribution)
The SP1 GPU server's compiled targets (cuobjdump --list-elf <server path> inside the RTX 5090 Windows rig's Ubuntu-24.04, CUDA 12.8, driver 610.47)sp1-gpu-server 6.8.1 (251,306,680 bytes, sha256 c2642ad1c42e85d8525159cf0c7cd5200d8766c9be1283f452a1f9bf9fea725c, the asset sp1_gpu_server_v6.8.1_x86_64.tar.gz the SDK downloads, sp1-cuda-6.8.1/src/server.rs): one ELF each for sm_80, sm_86, sm_89, sm_90, sm_100 and sm_120; strings finds compute_120 PTX as well. So sm_89 (Ada: RTX 4090, 4080) is compiled in natively, no JIT; so are Ampere (3090, 3060), Hopper, Blackwell datacentre (sm_100) and consumer (sm_120, the 5090). Nothing for AMD (no HIP path in SP1)
@@ -634,27 +724,31 @@ table{min-width:560px}

Reading, with the miner-on pairs above (empty shard 15,670 MiB, full prototype shard 30,039 MiB). The witness is never the binding term (4.9 to 21.6 KB a shard); the GPU server's working set is: a floor of 13.9 GB for any shard, 20.4 GB at 4.7 M cycles, 28.3 GB at 60 M cycles (23.0 GB with the smallest trace threshold, at the same time). By card: a 12 GB card proves nothing on this build (the floor is 13.9 GB alone); a 16 GB card proves only empty and near-empty shards, alone (13.9 GB; 15.7 GB beside the miner leaves nothing for the display); a 24 GB card proves the adopted v1 shard alone (20.4 GB) and, at the miner's measured 1.7 GB extra, about 22.1 GB beside it (approximate: not measured on a 24 GB card), and never the prototype shard (28.3 GB); a 32 GB card proves the prototype shard beside the miner with 2.5 GB spare (30.0 of 32.6 GB). The devnet is on the prototype table until H = 210,000 (6 October, about 19:50Z) and on the adopted v1 table (S_p 30,000 pgas) after it, so from H the 24 GB tier joins the provers and the shard that binds the memory is the 4.7 M-cycle one. Shards per block at each size: 1 at the prototype S_p, 4 at B_p; at the v1 budget 1 to 4 (one a block on tonight's chain, 2 to 3 on the txgen blocks).

Step 4, the rule

WhatMeasured
Unit testscargo test --release -p kaspa-consensus-core -p igneum-exec --lib -- proving config::params::tests::override_params_carry_the_proving_v1 config::params::tests::consensus_digest on this Mac (target vendor/igneum-node/target-pv1, 19:09Z): consensus core 13 passed (the segment record round trip, signature and the three nested sections; the credit split; the params switch and the digest that moves only once the switch is set), exec 8 passed (the segment grid and the split; the record checks: alignment, block, chain length, the veto naming the field, the deadline, the window; the chain rule both ways; the unproven restart; the shard side at 90%; the pool offering the segment section). The six full node suites go to the RTX 5090 Windows rig as a build job when the fleet is back
The fast-time 3-node harness (tools/proving-v1/net.mjs, 29950+, suffix 956, every node in trust mode, three vmine voters, v0 at DAA 60, v1 at DAA 120, 4 blocks a segment, unproven after 60 DAA, a tenth to the aggregator; fork b177718e built on this Mac)run 2, 19:13:01Z to 19:16:19Z, under the run lock: PASSED, 21 checks in 197.3 s (tools/proving-v1/report-2026-10-05.json). v1 start = chain block 119 on all three nodes; the native statement identical on all three. Known-finished: segment 119..122's fresh-chain record submitted to n1 at t=131.1 s, relayed, verified (trust) and PAID on n0 1.0 s later at chain block 129, 253,611,648,000,000,000 wei = a tenth of the four credits, the same on every node, the payout address holding it. Chain rule: segment 123..126's fresh-chain record refused ("does not chain to segment 119..122 ... proven (record paid at chain block 129)"), the continuing one (chain_len 8) accepted and paid. Known-failed: segment 127..130 left without a record: a fresh-chain record for 131..134 refused while 127..130 was pending ("pending until DAA 191"); at DAA 192 the status read unproven, a late record for 127..130 refused ("unproven: carried after the deadline"), the fresh-chain record for 131..134 accepted and paid with chain_len 4; segmentsInWindow proven 3, unproven 1. The shard side: a v1 shard's shardWei = 90% of its block's credit. Run 1 (19:10Z) failed in its own tooling (the signer's argument order), fixed. Run 3 on the FINAL fork tree (ece42979 on the 0.3.10 commit 21d4c73c, protocol 15, N = 8 both in the params default and --segment 8, the fast-time file's four fields), 20:52:41Z to 20:56:45Z: PASSED, 21 checks in 244.4 s (segments of 8: 119..126 paid in 1.0 s after submission, 127..134 refused fresh and paid continuing with chain_len 16, 135..142 left unproven and skipped, 143..150 restarted the chain)
-

5 October 2026 (night), dp4a-class throughput on the M5 Max: the dot4 emulation against the ALU chain (Counter ASIC 2.0 layer 7)

+
+

5 October 2026 (night), dp4a-class throughput on the M5 Max: the dot4 emulation against the ALU chain (Counter ASIC 2.0 layer 7)

Apple M5 Max, macOS 26, branch ca2-analysis (base readwidth 4badcee). The probes are standalone (no pack, no lottery kernel): proto-metal/dot4-probe.swift (built swiftc -O -o dot4-probe dot4-probe.swift -framework Metal under with-lock.sh build), proto-opencl/dot4-probe.c (built cc -std=c99 -O2 -o dot4-probe-cl dot4-probe.c -framework OpenCL), both run under with-lock.sh measure (exclusive; nothing else built or measured on the Apple M5 Max during the runs). Shape: a dependent chain of one dot4 per step per lane, acc = dot4(x, y, acc); x = x * 0x9E3779B1 + acc; y = rotl(y, 7) ^ (acc + s), 1,048,576 lanes x 4,096 steps, work-group 256, best of 3 with a fresh seed per repetition, device time (Metal: command buffer GPU start to end; OpenCL: event profiling). Beside it the ALU chain of the 9070 XT entry (x = x * K + rotl(y, 7); y = (y ^ x) + s, 5 ops per step counted). Every kernel is checked bit for bit against a CPU reference on lanes 0 and 1,048,575 in every repetition ("ok"). Design context: docs/analysis/int8-matrix-family.md.

API, kernelWhat one step isbest msG steps/sns per dependent stepok
Metal, probe_alumul, add, rotate, xor, add4.882879.8 (about 4.4 T int ops/s at 5 per step, approximate)1,192yes
Metal, probe_dot4ssigned dot4 emulated: int4(as_type<char4>(a)) x same for b, 4 products summed into a wrapping int, plus the 3-op chain22.820188.2 G dot4/s5,571yes
Metal, probe_dot4uunsigned dot4 emulated: uint4(as_type<uchar4>(a)), same chain7.834548.2 G dot4/s1,913yes
Apple OpenCL 1.2, aluas Metal4.928871.51,203yes
Apple OpenCL 1.2, dot4esigned dot4 emulated with convert_int4(as_char4(a))22.797188.4 G dot4/s5,566yes
Apple OpenCL 1.2, dot4_khracc + dot(as_char4(x), as_char4(y)) under #pragma OPENCL EXTENSION cl_khr_integer_dot_product : enable5.076846.21,239NO: mismatched the CPU reference on every lane checked in all 3 repetitions

Reading: on this GPU a signed-byte dot4 costs 4.7 ALU-chain steps and an unsigned-byte one 1.6; Metal has no dp4a and no integer simdgroup matrix (MSL 4.1 sections 2.4 and 6.9), so these are the honest Apple costs of a per-lane dot4 family, and an unsigned definition is 3x cheaper for Apple at no cost to NVIDIA or AMD (both carry the unsigned form, PTX dp4a.u32.u32, AMD v_dot4_u32_u8). Apple's OpenCL does not list cl_khr_integer_dot_product; its dot on char4 compiled anyway and returned something other than the integer dot (the mismatch), which is why a family's conformance vectors must gate every vendor path on the feature macro, not on "it compiled". Not run here: NVIDIA and AMD. The PC job is prepared and not published (coordinator's rule): relay/playbooks/dot4-probe.ps1 with dot4-probe-cl.exe (proto-opencl/dot4-probe.c cross-compiled with mingw as x86_64-w64-mingw32-gcc -std=c99 -O2 -static -DIGNEUM_CL_DYNAMIC -DCL_TARGET_OPENCL_VERSION=120 -I proto-cuda/nvrtc/redist/include, sha256 5adaeb1aceb03dc41135baabe0b53f1ed5fac891a5b3c3849645b03efe4416f4, 161,863 bytes); it runs the scalar, KHR, AMD __builtin_amdgcn_sudot4 and NVIDIA inline-PTX dp4a variants on every OpenCL GPU of the machine with the mining cards switched off through /api/cards and restored after. The CUDA form (proto-cuda/dot4-probe.cu, __dp4a) needs nvcc on the RTX 5090 machine and is the cross-check.

the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT), 5 October 2026 20:29 UTC, the same probe on the RTX 5090 and the RX 9070 XT (machine ae432dc7, Windows 11; fetch job fetch-dot4-20261005 placed dot4-probe-cl.exe sha256 5adaeb1a…6416f4, run job run-dot4-20261005 ran relay/playbooks/dot4-probe.ps1: the app's nvidia:0 and amd:1:gfx1201 cards switched off through POST api/cards, the probe run on every OpenCL device, the cards restored with their settings (identities 8 and 2, power cap 80% and none); node tools/jobs.mjs run-dot4-20261005; 101 s wall, every kernel under 10 ms; device event time, best of 3, same lanes and steps as the Apple M5 Max rows):

Device, platformalu, G steps/s (ms)dot4e signed emulation, G dot4/s (ms)dot4 instruction, G dot4/s (ms)cl_khr_integer_dot_productok
RTX 5090, NVIDIA OpenCL 3.0 CUDA, driver 617.148,753.5 (0.491)1,239.1 (3.466), 7.1x the ALU step7,453.6 (0.576) via inline PTX dp4a.s32.s32, 1.17x the ALU stepnot listed; the dot(char4,char4) kernel does not buildyes
RX 9070 XT (gfx1201), AMD-APP 3683.0 (PAL,LC), OpenCL 2.0701.4 (6.124)480.8 (8.932), 1.46x664.3 (6.465) via __builtin_amdgcn_sudot4, 1.06xnot listed; sameyes
RX 9070 XT, the older 3652.0 platform entry (dup)696.2 (6.169)501.7 (8.561)683.6 (6.283)not listedyes
gfx1036 (integrated RDNA 2, 2 CUs), 3683.040.6 (105.9)15.8 (272.3), 2.6xsudot4 does not build: "needs target feature dot8-insts"not listedalu and dot4e yes

Reading: one dp4a on the 5090 costs about one ALU-chain step (7.45 T dot4/s, 0.85 of the chain's 8.75 T steps/s); one v_dot4_i32_iu8 on the 9070 XT the same (0.66 T, 0.95 of its chain). Emulating the signed dot4 costs 6.0x the instruction on NVIDIA (the OpenCL compiler does not fold the four sign-extended products into dp4a) and 1.38x on AMD. Vendor ratios: the 5090 is 12.5x the 9070 XT on the ALU chain and 11.2x on hardware dot4; against the M5 Max's best (unsigned emulation, 0.55 T) it is 10x on the chain and 13.6x on dot4. The hash itself is bound by DRAM reads, so these per-op numbers bound a family's cost and are not hash rates (docs/analysis/int8-matrix-family.md section 4). Adrenalin's OpenCL C accepts the clang builtin and emits the instruction on RDNA 4 (the third-party RDNA 3 report of the same route is now confirmed on this card); no PC platform lists the Khronos integer-dot extension. The 5090 SM clock read 2,505 MHz before and after (nvidia-smi; 2,850 MHz while mining in the telemetry entry), so the card was idle for the probe.

-

5 October 2026, layer 3 scratch soundness (Counter ASIC 2.0 step 4; branch ca2-soundness on readwidth b970dda; cryptographer)

+
+

5 October 2026, layer 3 scratch soundness (Counter ASIC 2.0 step 4; branch ca2-soundness on readwidth b970dda; cryptographer)

Machine: Apple M5 Max, 64 GiB, Darwin 25.6.0, other agents' builds and the readwidth measurements running beside (the Apple M5 Max measure lock was free during the GPU runs; nothing here is a hash-rate figure). Write-up docs/analysis/scratch-soundness.md; tests igneum-pow/tests/scratch.rs; harness proto-metal/packbench built from this branch (--batch-base added) into the session scratchpad with swiftc -O -target arm64-apple-macos11 -framework Metal.

CPU, with-lock.sh build nice -n 19 cargo test -j4 --test scratch -- --nocapture (3.6 s): 7 of 7 pass. Stats, 6 classes x 3 seeds x 2^11 units, every read-modify-write traced (3.1 to 12.6 million per class): written-word bias within 6 sigma (worst 3.63); re-hit rate measured against the uniform birthday rate 12.58 vs 10.91 percent (scr2k32), 21.47 vs 20.83 (scr4k32), 36.99 vs 36.50 (scr8k32), 3.84 vs 2.88 (scr2k128), 6.25 vs 5.82 (scr4k128), 11.89 vs 11.37 (scr8k128); slot histogram non-uniform (hottest slot 1.39x to 5.10x the mean: the slot is a register's low bits); deepest chain 5 to 9. Edge: 7 hand-built programs x 2 geometries x 4 bases against an independent hand model, 56 of 56, and 56 of 56 mismatches with the hand model's rewrite words swapped. Static scratch check: 42 of 42 emitted kernels of the 7 scr packs (regenerated byte for byte from program.json first), 6 deliberate breaks caught. Fuzz: 200 generated scratch programs, contract and acceptance on every instruction, 800 units; IGNEUM_SCRATCH_PACKS_OUT wrote 214 packs (57 s, three memory-hard caches). The crate's other tests: 33 of 34 lib tests pass; verify::tests::fold_and_wide_fetch fails on the readwidth tip itself (verify.rs:508, k as u32 * 0x9E37_79B1 overflows under the test profile; not touched here).

Metal, with-lock.sh run <script>, scripts gpu-a.sh and gpu-b.sh in the session scratchpad (one packbench call per line):

RunCommand shapeResult
scr4k32 standard pack, timingpackbench --pack proto-cuda/packs-readwidth/scr4k32 --batches 1 --batch-log2 24 --warps 20483/3 standalone, 3/3 in batch, fingerprint 3d1af881bd978fb9, 1.8 s wall for the run
warp-count independencesame pack, --batch-log2 12 --warps 1, 2, 128fingerprint 8c07620f4d9adefd at all three
wrap inside the launch--batch-log2 9 --batch-base 4294967040 --warps 1, 4fingerprint 8e9e233234d3a297 at both, the base-0 vector inside the window after the wrap 1/1
broken tag (tag = salt) on a copy of scr4k32, standard vectors--batch-log2 24 --warps 2048standalone 3/3, in batch 2/3 (base 1,000,000, warp 530's 16th unit, caught), overall FAIL
broken tag, 2 units on 1 warp, standard vectors--batch-log2 6 --warps 13/3, 1/1, PASS: missed, the standard vectors have no base 32
14 edge packs, run A--batch-log2 6 --warps 1 --batches 114/14 PASS, 4/4 standalone and 2/2 in batch each (bases 0 and 32 on one arena)
14 edge packs, run B--batch-log2 9 --warps 1 --batch-base 429496704014/14 PASS, 4/4 and 3/3 each (16 units on one arena, the wrap inside)
broken tag on edge-slot0 at 32 and 128 KiB--batch-log2 6 --warps 14/4 standalone, 1/2 in batch, FAIL at both (the second unit read the first's slot 0)
broken lazy fill (m_ all ones) on edge-slot0 at 32 KiBsame0/4, 0/2, FAIL
200 fuzz packs--batch-log2 9 --warps 2 --batch-base 4294967040 --batches 1 each200/200 PASS, 800/800 standalone units (25,600 hashes), 400/400 in the window; 91 s wall for the 200 runs (20:16:02 to 20:17:33 UTC)

Totals: 228 of 228 PASS where expected, 3 of 3 FAIL where built in. Reading: the one-warp CPU simulation is exact on Metal under the hosts' present tag policy; the analysis names the host contract (zero the arena at allocation and at the tag counter's wrap, tags from 1, groups a multiple of warps) that turns that into a guarantee, and finds layer 3 does not move the named chip (section 3.4 of the write-up: 2.4x at every share under the cap).

-

5 October 2026 (night), epoch length as an era parameter (Counter ASIC 2.0, layer 9): the Apple M5 Max's compile-ahead per program

+
+

5 October 2026 (night), epoch length as an era parameter (Counter ASIC 2.0, layer 9): the Apple M5 Max's compile-ahead per program

Branch ca2-epoch, worker "ca2-epoch"; design and the per-card table in docs/plans/epoch-length.md. Question (the maintainers: "what about faster program changes?"): what a card spends per epoch between receiving the next seed and swapping, which sets the floor of the epoch-length ladder (600 to 7,200 DAA s). Machine: Apple M5 Max (Darwin 25.6.0, 64 GiB), 21:18 UTC, load average 11 to 14 from other agents' builds and runs; the measure lock held for the 3-s run (tools/lock/with-lock.sh measure bash scratchpad/epoch-measure.sh). proto-metal/igneum-bench built from this branch with swiftc -O -target arm64-apple-macos11 -o igneum-bench main.swift -framework Metal under a build slot.

Ten distinct programs (seed strings igneum-devnet-v4-epoch0, /epoch1 .. /epoch9; version 2 generator, 128 loads per hash), each generated and compiled at run time (makeLibrary from source plus makeComputePipelineState), dataset 2^28 words, one 2^20 batch and one verify warp per program:

./igneum-bench --seed igneum-devnet-v4-epoch0 --hours 10 --dataset-log2 28 --batch-log2 20 --batches 1 --verify-warps 1

ProgramCompile ms (library + pipeline)Mhash/s (GPU)Verify
epoch018.8 (9.3 + 9.5)27.2PASS
epoch117.8 (8.8 + 9.1)27.9PASS
epoch217.6 (8.6 + 9.1)27.8PASS
epoch316.1 (8.0 + 8.2)27.7PASS
epoch418.6 (9.0 + 9.6)27.5PASS
epoch515.9 (7.7 + 8.2)28.4PASS
epoch617.6 (8.6 + 9.1)27.8PASS
epoch717.6 (8.7 + 9.0)30.1PASS
epoch820.4 (9.8 + 10.6)28.4PASS
epoch918.2 (8.7 + 9.5)29.3PASS
min / median / max15.9 / 17.7 / 20.410 of 10

Cache fill 1.95 ms GPU (192.4 ms one core), dataset build 20.8 ms GPU for 1 GiB. The devnet pack three times through packbench --pack ../proto-cuda/packs/igneum-devnet-v4-epoch0 --batches 1 --batch-log2 20 --group 256 (the pack's two libraries, memhard.metal and program.metal): compile 79 ms, 1 ms, 1 ms (the system shader cache answers the identical source from the second run); cache fill 0.6 to 0.7 ms GPU, dataset build 20.7 to 20.8 ms GPU.

Reading: a fresh program compiles in about 18 ms on this card with the Metal compiler service warm, 79 ms for a pack with its dataset kernels, up to 1.8 s cold (the variant-racing entry's first seed), 0 to 444 ms at the fleet's live boundaries (M11). The hot table fill of layer 5 is 0.07 to 0.22 ms (ca2-cache). So the Apple M5 Max's per-epoch compile-ahead is under 2 s without the race and about 38 s with it (M11: 34.0 / 34.9 / 37.8 s), and the race is the only item visible against the 600-s window in which the program is known (lead 1,200 s minus the 600-s VDF, fixed at every epoch length). PC cards, cited in the plan: RTX 5090 NVRTC 151 to 180 ms, prepare 0.5 to 1.0 s without the dataset (M11), race one round about 37 s; RX 9070 XT OpenCL compile NOT MEASURED at the current worker (owed: host.c times clBuildProgram only in the prepare path and no prepared line from gfx1201 is in any upload); Intel UHD build 3.0 to 6.4 s (M11). Floor by the rule (slowest compile-ahead under 10% of the epoch and inside the window, dataset excluded): 600 DAA s, carried by the race at 6.3% of 600 s; with the race off (M11 found base wins on both the 5090 and the Apple M5 Max) the slowest measured row is the Intel iGPU at 1.1%. Consequences per tier and the difficulty-settle constraint (24% of a 600-s epoch in settle at the measured 144 s) are in the plan.

-

6 October 2026, Counter ASIC 3.0 item 2: the per-day derivation

+
+

6 October 2026, Counter ASIC 3.0 item 2: the per-day derivation

Branch ca3-derive (worker "derive", from ca3-coord 50df751; commits acb96ee and after), design, spec text and the chip row in docs/plans/counter-asic-3-derivation.md and docs/analysis/chip-model-v3.md section 6. Question (the plan's item 2): replace the fixed-shape mixer (the chip model's 3x fixed-function allowance, 0.31x to 0.92x) with a random item-derivation program drawn per day from the day key stream (RandomX's SuperscalarHash idea, superscalar.cpp read at upstream 7607fb2), keep the 8 dependent cache reads per item exactly, keep the op count per item at or above x8's, and measure the verifier against the 10 ms gate, bit-exactness, the daily build and the hash rate. Machine: Apple M5 Max, 64 GiB, Darwin 25.6.0; every timing row names its lock and load average.

The construction (class dr736, igneum-pow/src/derive.rs): nine straight-line programs of 736 instructions per item (one before each cache read, one after the last), four draws per instruction from the mixer's own SplitMix64 stream after its 40 draws, twelve two-register forms (add, sub, xor, mul-lo by c|1, rotate-add, xor-rotate, add-constant, xor-constant, the M_r form (d ^ c) * odd, d * odd + c, d ^= c & b, d += c | b), every instruction reading the register the previous one wrote (the chain, s[0] first) and writing another, every form a bijection on the state; the acceptance test rejects a register never written, fewer than 8 distinct rotations, or a draw under the x8 mixer's counts from the code (72 x 128 = 9,216 chip ops, 72 x 144 = 10,368 as written, 1,152 multiplies; the coordinator's correction of the 130-per-application figure). The genesis day draws 6,624 instructions, 10,659 GPU ops, 9,992 chip ops, 1,461 multiplies per item; the verifier runs it with a word-major interpreter over the 32 items of a load, dispatching on instruction pairs, no JIT.

Verifier per 32-lane unit, one core (with-lock.sh measure, one session 07:42:20 to 07:42:33 UTC, load average 4.91 / 4.53 / 5.34 at the start, 4.46 / 4.44 / 5.30 at the end; igneum-pow bench --seed igneum-genesis --day 2026-10-03 --class <c> --warps 50, two rounds, then the devnet seeds once):

@@ -669,7 +763,8 @@ table{min-width:560px}

RTX 5090 (the RTX 5090 Windows rig, one job run-ca3-derive-pc2-20261006, relay/playbooks/ca3-derive-pc2.ps1, published 08:26:08Z after the proving agent's clear at 08:24:27Z, lock 08:25:55 to 08:29:08Z; ran 08:26:43 to 08:28:49Z, done exit 0): the installed 0.3.11 worker through NVRTC 12.8 on the self-fetched zip. The card did NOT come off: the job read the key from settings.json (nvidia:0:NVIDIA GeForce RTX 5090, with the device index) where the 5 October jobs posted the state's key without it, and one worker process stayed up through the 90 s wait, so every row is a loaded-card figure (the v2 control 62.3 MH/s against its unloaded 136 to 137) with the ratios valid.

PackNVRTCCache1 GiB buildSelf-test (64 samples, 96 lanes)Fingerprint 2^24MH/s bw1 / bw8 (loaded)
v2-genesis-mh167 ms646 msPASS25f96e7dce90bd4e = Mac62.26 / 61.34
mx8-genesis164 ms440 msPASS7c28cfb06c5c65a9 = Mac61.98 / 60.53
dr736-genesis1,266 ms542 msPASS50e3eaa779da4f1e = Metal = Apple OpenCL61.08 / 58.51
dr736-devnet-epoch01,266 ms632 msPASS9553f6d5c667205a = Metal62.15 / 61.44

Reading: bit-exact on CUDA (four compilers now agree on both packs); the build and the rate do not move beyond the loaded noise; the number that moved is the NVRTC compile, +1.1 s per pack, because memhard.h's 6,624-statement item function is inside every hash-kernel and race-variant compile (17 variants: about +19 s per epoch, approximate, against a 38 s compile-ahead budget at the 600-s epoch floor), so compiling the item function once a day into its own module is a requirement of the class. Consequences: a 5090 owner pays 1.1 s once a day after that fix and 1.1 s per variant per epoch before it; the Apple M5 Max 0.75 s once a day. Filed: the card-off key form (post both forms, confirm by the process list) before the next the RTX 5090 Windows rig round; the unloaded 5090 rows re-run then. RX 9070 XT: OWED (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT)).

-

6 October 2026, Counter ASIC 3.0 item 8: program work in the latency shadow

+
+

6 October 2026, Counter ASIC 3.0 item 8: program work in the latency shadow

Branch ca3-shadow, worker "shadow" (docs/analysis/latency-shadow-2026-10-06.md carries the design, the chip side and the consequences; this entry carries the measurements). The knob: LoadClass::shadow, class name <class>+sh<S>x<R>, a block of S ALU instructions drawn from the program stream after the 64 base instructions and run R times at the end of every iteration (no load; the base program, its attempt and the acceptance verdict are the class's without the shadow; v2 and v3 byte-identical, cargo test in igneum-pow 54 + 4 + 19 + 7 green). Packs proto-cuda/packs-ca3-shadow/* over mx8 for seed igneum-genesis; the control is the pinned class v3 pack packs-ca2-mixer/mx8-genesis. Ops per hash = shadow instructions x 1.83 (counted from the emitted statements: add 5, rotr 2, shfl 2, the rest 1, weighted over the non-load weights) + 930 (the base program's 384 ALU instructions and 128 loads).

Apple M5 Max, Metal (proto-metal/packbench --pack <dir> --batches 60 --batch-log2 24 --group 256 under with-lock.sh measure, two sessions 07:51 to 08:03 UTC, GPU time; power = the IOReport "Energy Model" GPU and DRAM channels at 2 Hz through a dlopen of libIOReport, no root, the mean over each run after its first 6 s; idle GPU 0.44 W, DRAM 0.64 W; the package is about 17 W more, Ember Tune's 38 W row, approximate; load averages 3.3 to 6.8, the GPU idle: the Apple M5 Max mines nothing):

PackShadow instrs per hashOps per hashMH/sAgainst the controlGPU WDRAM WMicrojoules per hash (GPU + DRAM)Verifier ms per warp, one core, avg of 20 (worst cold)Bit-exact, fingerprint 2^24Load at start
mx8-genesis (control; runs 1, 2, 3)093027.07, 27.07, 27.1011.2, 9.2, 12.310.2, 10.0, 10.20.782.062 (2.188)yes, 7c28cfb06c5c65a94.6, 6.8, 4.2
sh256x24,0968,40026.85-0.8%15.110.40.952.080 (2.249)yes, 33e8bbe4c35b2e544.6
sh256x714,33627,20026.74-1.3%18.010.61.072.112 (2.224)yes, 6cfb70911007520a4.2
sh256x1326,62449,70026.75-1.2%20.610.51.162.212 (2.237)yes, 59ac286fe2a5a9ef3.7
sh64x52 (64-instruction block; runs 1, 2)26,62449,70027.72, 27.79+2.5%19.8, 20.310.2, 10.31.092.137 (2.237)yes, 9dd010f79d8ca9f44.4, 4.1
sh1024x3 (1,024-instruction block)24,57645,90022.53-16.8%20.29.71.332.150 (2.274)yes, a05399c819b79aad6.0
sh256x27 (runs 1, 2)55,296102,10026.48, 26.86-1.5%26.9, 26.910.4, 10.21.402.229 (2.276)yes, 3d2e8245cc084d073.3, 5.6
sh256x4081,920150,80025.10-7.3%26.710.11.462.329 (2.396)yes, 0844b706302f1c9c5.0
sh256x53 (runs 1, 2)108,544199,60024.40, 24.09-10.4%28.8, 28.59.5, 9.71.582.427 (2.461)yes, 4f824b15cf2b124a3.9, 4.6
sh256x88180,224330,70021.39-21.0%31.78.41.882.619 (2.771)yes, 0572522e39a94d8a3.8
@@ -679,7 +774,8 @@ table{min-width:560px}

Reading: the 5090 holds to 150,800 ops (-0.3 percent) and loses 2.7 percent at 199,600, under a 431 W cap that the control never reaches (342 to 357 W) and that binds from 102,100 ops up: the SM clock falls from 3,037 to 1,834 MHz and at 330,700 ops the card is compute-bound at the capped clock (28.6 T counted op/s, the 45.2 T budget scaled by the clock). The 5 percent point at 431 W is about 210,000 ops. The marginal ALU energy at the shipping clock, read on the three rungs under the cap: 10.2 to 13.2 pJ per counted op, twice the 5.5 pJ the chip model assumed. The 64-instruction block runs 3.5 percent above the control here too. Clock rows (-lgc): OWED, nvidia-smi refused the lock without administrator rights and the job did not ask for them. Power-cap rows: the 5 October sweep's (floor 400 W, so -pl 200 and 250 cannot be set; the cap never binds at the control).

RX 9070 XT (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT), ae432dc7): OWED (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) is the maintainers' desk and not released today); the OpenCL kernels are in every pack.

Consequences per tier (the file's section 8 in short): at the recommended N = 100,000 ops per hash (sh256x27) the Apple card loses 1.5 percent of its rate and pays 16 W more (income per watt 0.56x, per pound unchanged), the 5090 holds its rate at its 431 W cap (350 W at the control: per watt 0.81x, measured), the 9070 XT holds by its budget (owed), a rig pays about 30 percent more electricity for the same hash, a pool user sees nothing, and the f = 1 chip's edge per joule falls from 1.6x to 0.9x against the M5 Max and from 5.6x to 2.1x against the 5090 at k = 1, where k is the chip core's energy per op over the 5090's measured 11 pJ: the number that decides the item. Verdict: GO as a class v4 candidate at N = 100,000 (mx8+sh256x27), subject to the 9070 XT row and the gates; NO-GO above 130,000 or with a block over 256 instructions. No card we own may lose more than 5 percent (the 2.0 rule): the M5 Max caps N at 130,000.

-

6 October 2026, Counter ASIC 3.0 item 6: the reserve families' step costs

+
+

6 October 2026, Counter ASIC 3.0 item 6: the reserve families' step costs

Branch ca3-reserve, worker "reserve" (docs/plans/counter-asic-3-reserve.md carries the proposed order and spec text; this entry carries the measurements). Method: the dot4 probe's dependent chain (docs/analysis/int8-matrix-family.md section 4), one op of the family per step per lane, 1,048,576 lanes x 4,096 steps, best of 3 dispatches per run, three runs, bit-exact against a CPU reference on two whole 32-lane warps (the shuffle rows need the whole warp). Every chain has the same glue (acc = OP(acc, x, y); x = x * K + acc; y = rotl(y, 7) ^ (acc + s)), so the "step cost" is the family's one op plus four glue ops against the add-xor-rotate chain of the 9070 XT bench-log entry (alu: x = x * K + rotl(y, 7); y = (y ^ x) + s, 5 ops per step counted, no acc). Reference rows are live families (alu; rotr = the live rotr_var text; shflx = the live shfl, lane XOR 8). Candidate rows are the seven families of spec 1.13.2 (shl, shr, bfe with the vendor's extract function and bfec the C form (y >> 7) & 0x1fff, andn, perm = bytes (b1, b3, b0, b2), popc and clz folded by add, sel on bit 5, shfla = lane + 3 mod 32). Comparison rows: dot4u and dot4s (Apple, emulated), dot4i (__dp4a) and mm8 (one mma.sync.m8n8k16 u8 per step per warp, inline PTX) on CUDA. Sources: proto-metal/family-probe.swift, proto-cuda/family-probe.cu, the the RTX 5090 Windows rig job tools/ca3-reserve/pc2-family-probe.ps1 (made by make-pc2-playbook.sh). G steps/s is the whole card's dependent-step throughput; ops per step counted = the family's op plus 4 glue (alu 5, shfla and shflx 6: shuffle plus xor, mm8 1 mma plus 4).

Apple M5 Max, Metal (swiftc -O -o family-probe family-probe.swift -framework Metal under with-lock.sh build; three runs of with-lock.sh measure ./family-probe --reps 3, 07:29:05 to 07:29:08 UTC, load average 7.64 / 7.59 / 7.14 before and after every run (the Apple M5 Max was loaded by other agents' builds the whole morning; the measure lock held, the GPU idle: the Apple M5 Max mines nothing), GPU start-to-end time):

kernelbest ms, runs 1 / 2 / 3best of the three, msG steps/s (best)ns per step (best)ops per step countedstep cost (ratio to alu, best)bit-exact, 3 runs
alu5.039 / 4.918 / 4.8734.8738811,19051.00yes
rotr (live)5.610 / 5.533 / 5.4925.4927821,34151.13yes
shflx (live)4.196 / 4.259 / 4.2234.1961,0241,02460.86yes
shl4.120 / 4.202 / 4.1194.1191,0431,00650.85yes
shr4.296 / 4.194 / 4.3194.1941,0241,02450.86yes
bfe (extract_bits)3.731 / 3.805 / 3.8163.7311,15191150.77yes
bfec (C form)3.762 / 3.818 / 3.6463.6461,17889050.75yes
andn3.680 / 3.732 / 3.6763.6761,16889850.75yes
perm5.500 / 5.548 / 5.5245.5007811,34351.13yes
popc4.261 / 4.223 / 4.2624.2231,0171,03150.87yes
clz4.918 / 4.916 / 4.9144.9148741,20051.01yes
sel3.718 / 3.831 / 3.7183.7181,15590850.76yes
shfla (lane + 3)9.337 / 9.323 / 9.2879.2874622,26761.91yes
dot4u (emulated)7.818 / 8.044 / 7.9257.8185491,90951.60yes
dot4s (emulated)23.264 / 23.254 / 23.04523.0451865,62654.73yes
@@ -690,7 +786,8 @@ table{min-width:560px}

RX 9070 XT (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT), ae432dc7), OpenCL: OWED. the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) is the maintainers' desk and not released today (the brief's rule); the OpenCL twin of the probe (__builtin_amdgcn_* paths for v_bfe_u32, v_perm_b32, v_bcnt_u32_b32, v_cndmask_b32, ds_bpermute_b32) is the next job on that card.

Consequences per tier, Mac rows (the hash is latency-bound by 128 dependent DRAM reads; a family at W_new = 4 points is about 4% of the 64 instructions, so these per-op costs bound a family's hash-rate cost and are not hash rates; the 5% rule of 1.13.2 is argued from them, not measured, until a family is live):

TierWhat the rows meanWhat is being done
Apple user (M-series laptop or desktop, the app's Metal worker)six of the seven candidates (shl, shr, bfe, andn, popc, sel) cost at most the live rotr step; clz the same as the reference; perm 1.13x (emulated); shfla 1.91x, the only candidate over the live shfl's cost by more than 2x on this card. At 4 points of 64 a 1.91x op costs under 1% of the program's ALU time, itself a small share of a latency-bound hash (approximate: argued, measured when live)the proposed order puts shfla after the plain datapath families (R6), so Apple pays it last; mm8 stays last
NVIDIA user (8 to 32 GB card)every candidate is native and costs 0.95x to 1.23x the live rotr step (andn, the shifts, perm, sel under 1.0x; popc 1.14x; shfla 1.16x; bfe 1.17x; clz 1.23x); nothing on this card is emulated above a compiler sequence; at 4 points of 64 no family moves the ALU time by over 1% (argued) on a hash bound by DRAM readsthe family-live measurement at each unlock rehearsal; nothing to change in the order for NVIDIA
AMD user (RX 9070 XT, 16 GB)owed: no row todaythe the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job when the desk is free
A rig or a pool userthe same per-card figures; no family changes the dependent-read boundnothing until a family is live
A chipevery candidate but mm8 is a 32-bit datapath structure (barrel shifter, byte crossbar, popcount tree, 32-lane shuffle crossbar: docs/plans/counter-asic-3-reserve.md section 3 names them with approximate areas); none is licensable as a block the way an int8 matrix unit isthe reserve order of that document
-

6 October 2026, Counter ASIC 3.0 gate run, the hash side

+
+

6 October 2026, Counter ASIC 3.0 gate run, the hash side

Branch ca3-v4-hash, worker "v4-hash", on ca3-coord 3213ee9. The candidate class v4 mx8+sh256x27 composed with the era as the chain composes it (mx8-era<hex>+sh256x27, generator 3), on the devnet epoch-0 and day seeds at the genesis era (v4-devnet-epoch0) and at the six test eras of 2.0 (v4-era-0 to v4-era-5), with the class v3 control mx8-devnet-epoch0 re-exported beside them (proto-cuda/packs-ca3-v4/). Gates G1, G2 and G3 of docs/plans/counter-asic-2-rollout.md section 7 and the pinned verifier benchmark; the evidence tables and one JSON per run in docs/plans/counter-asic-3-gate/ (hash-gates.md). G4, G5 and G6 are the node's and the release's.

G1, bit-exact (with-lock.sh run, 15:49:29 to 15:50:02Z, load 6.8 to 6.7). packbench --pack <dir> --batches 1 --batch-log2 24 --group 256 (Metal) and igneum-bench-cl --bench-pack --pack <dir> --batches 1 --batch-log2 24 (Apple OpenCL), both built from this branch: on all eight packs the cache FNV 448274a57f508cbc PASS, the dataset head and last PASS, vectors 3 of 3 standalone and 3 of 3 in batch (Metal), 96 of 96 lanes (Apple OpenCL), and one fingerprint per pack across both harnesses. The control reproduces 2.0's 90f794dd556f7a3b (the harness fired on a known case).

PackClassFingerprint 2^24 at base 0 (Metal = Apple OpenCL)RTX 5090 (CUDA NVRTC, the RTX 5090 Windows rig)RX 9070 XT
mx8-devnet-epoch0 (control)mx8-erad810f22d90f794dd556f7a3b90f794dd556f7a3bthe three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job 1
v4-devnet-epoch0mx8-erad810f22d+sh256x27f410c731b6bc2d31f410c731b6bc2d31the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job 1
v4-era-0mx8-erab2ed8a89+sh256x27b115c410e08be6cab115c410e08be6cathe three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job 1
v4-era-1mx8-era676a17fc+sh256x27edc2b18fc67e9d1cedc2b18fc67e9d1cthe three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job 1
v4-era-2mx8-era843155d7+sh256x27604ed87109570559604ed87109570559the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job 1
v4-era-3mx8-erad6367bfe+sh256x279541e2a41dde2ee69541e2a41dde2ee6the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job 1
v4-era-4mx8-era4488f3ed+sh256x27a9ffa2b67bd2e366a9ffa2b67bd2e366the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job 1
v4-era-5mx8-eraf897c84e+sh256x271f34e9c4659452491f34e9c465945249the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job 1
@@ -706,7 +803,8 @@ table{min-width:560px}
FigureValueSource
Paid shards, devnet, all provers663curl -s 127.0.0.1:26790 -d '{"jsonrpc":"2.0","id":1,"method":"igneum_getProvingStatus","params":[]}' at tip DAA 0x22caf
Paid wei, all provers0x2c2961a69990745400 = 814.64 IGNsame call
Average per paid shard1.23 IGN (approximate: the mean over 663)814.64 / 663
u64::MAX in IGN18.452^64 - 1 over 1e18
Paid shards per app start before the reply empties15 (approximate: at the mean payout)18.45 / 1.23

Cause: ProvingState.paid_wei: u128 and serde_json to_value (1.0.151, value/ser.rs serialize_u128: u64 range or an error); the error became json!({}). Fix: the field serialises as a decimal string; state_json logs the error once. Test a_paid_total_over_u64_max_still_serialises_the_whole_state (cargo test --offline -q paid_wei, 1 passed).

The fast-time 3-node harness (tools/proving-v1/net.mjs, 29950+, suffix 956, every node in trust mode, three vmine voters, v0 at DAA 60, v1 at DAA 120, 4 blocks a segment, unproven after 60 DAA, a tenth to the aggregator; fork b177718e built on this Mac)run 2, 19:13:01Z to 19:16:19Z, under the run lock: PASSED, 21 checks in 197.3 s (tools/proving-v1/report-2026-10-05.json). v1 start = chain block 119 on all three nodes; the native statement identical on all three. Known-finished: segment 119..122's fresh-chain record submitted to n1 at t=131.1 s, relayed, verified (trust) and PAID on n0 1.0 s later at chain block 129, 253,611,648,000,000,000 wei = a tenth of the four credits, the same on every node, the payout address holding it. Chain rule: segment 123..126's fresh-chain record refused ("does not chain to segment 119..122 ... proven (record paid at chain block 129)"), the continuing one (chain_len 8) accepted and paid. Known-failed: segment 127..130 left without a record: a fresh-chain record for 131..134 refused while 127..130 was pending ("pending until DAA 191"); at DAA 192 the status read unproven, a late record for 127..130 refused ("unproven: carried after the deadline"), the fresh-chain record for 131..134 accepted and paid with chain_len 4; segmentsInWindow proven 3, unproven 1. The shard side: a v1 shard's shardWei = 90% of its block's credit. Run 1 (19:10Z) failed in its own tooling (the signer's argument order), fixed
-

5 October 2026 (night), aggregation cost on the RTX 5090: what a per-block aggregation spends and what each lever gives (proving engineer, agg-cost)

+
+

5 October 2026 (night), aggregation cost on the RTX 5090: what a per-block aggregation spends and what each lever gives (proving engineer, agg-cost)

the maintainers, 5 October 2026: "fix everything else in the numbers tonight". The number under test: the chained segment aggregation cost 9.6 to 9.7 s a block on the RTX 5090 Windows rig's 5090 while the card mined (chain-pc2-pv1c, the entry above), 2.2 s on 4 October with the card to itself. Target: under 3 s a block, the miner's slowdown of the prover under 1.5x, the proof statement unchanged. Branch agg-cost (worktree igneum-wt-agg-cost, from proving-v1 219517f). Host changes (statement untouched, elf/ untouched): the aggregation's stdin build timed apart from the prove call, the deferred-proof count and the SP1 knobs in the RESULT lines, --mode chain --save-shards (every shard's compressed proof written next to the results, so --mode aggregate re-runs the same proofs under other settings). Jobs: agg-cost-pc2-1 (21:01:20Z to 21:25:11Z, tools/proving-v1/pc2-agg-cost.ps1, the package igneum-prove-wsl2-aggcost.zip fetched by fetch-prove-aggcost 20:55:39Z, built in WSL2 against the live target dir in 5 s, installed to <server path>, the live <server path> untouched, --mode id the pinned pair) and agg-cost-pc2-2 (21:34:00Z, the same script). The live prover was switched OFF for the runs (its sp1-gpu-server would otherwise be shared through /tmp/sp1-cuda-0.sock and carry its own environment; gpu_server_before running=0) and ON again at the end. Fixtures: four consecutive live blocks cut from the RTX 5090 Windows rig's own node (86165..86168 at tip 86195, one empty shard each, every one MATCHES natively), the same four for every phase of job 1. App 0.3.9 on the RTX 5090 Windows rig throughout.

Known-finished case of the host changes before the GPU (this Mac, CPU, run lock, 20:41Z to 20:44Z): --mode chain over fixtures/chain/block-81046.json with --save-shards (shard 38.5 s, aggregate 43.4 s, the proof file written), then --mode aggregate over that saved shard proof with SP1_WORKER_VERIFY_INTERMEDIATES=false (46.6 s, the same statement 0x3dedb8ea...), --mode verify-segment VERIFIED in 0.027 s; known-failed: a wrong statement NOT VERIFIED in 0.027 s. Unit tests: cargo test --release -p igneum-prove-core -p igneum-prove-host: core 8 passed, host 9 passed and 1 ignored (build lock, 20:53Z).

Lever 1, the profile: where a per-block aggregation goes

@@ -737,7 +835,8 @@ table{min-width:560px}

6 October 2026, 08:26Z to 08:35Z, the fast-time harness on the fresh-record rule (Mac, tools/lock/with-lock.sh run)

IGNEUM_PV1_BIN=vendor/igneum-node/target-pv1/release node tools/proving-v1/net.mjs --segment 8 --unproven 10 [--fresh-rule 0] (fork 0f0dda95, 3 nodes at 60x, ports 29950+):

CaseChecksTime
The rule as shipped (no switch): fresh refused while the previous segment is pending (known-failed), accepted after it is unproven22 passed166.2 s
--fresh-rule 0: fresh accepted while the previous segment is pending, freshAdmissible true, still refused after a proven one, the second offer a duplicate ("segment already paid")23 passed139.9 s
-

6 October 2026, 12:25 to 13:20Z, the finality route: why 26 fresh nodes lost the seed every checkpoint (fork fin-route-0313 5a339733 on 83089544; release engineer)

+
+

6 October 2026, 12:25 to 13:20Z, the finality route: why 26 fresh nodes lost the seed every checkpoint (fork fin-route-0313 5a339733 on 83089544; release engineer)

The fleet agent's finding (12:25Z): every rented node logged P2P, route error: incoming route capacity for message type IgneumFinality has been reached (peer: 188.245.5.161:26611) every 20 to 60 s and reconnected at the checkpoint cadence (every 30 s); on a Vast box the seed is the only peer, so each drop cost the node its only peer until the next dial.

The cause is an echo, not the burst. A certificate for an index below a node's window (next_index minus KEEP_CHECKPOINTS 2,000: trimmed history) finds no record, goes through the off-chain path (ingest_off_chain), is LOCKED, pushed to gossip and sent to every peer, trimmed again on the next pass, and comes back from every peer that held it. The seed's journal (igneumd-v4, 12:40 to 12:47Z):

Line shapeCount in 7 min
Finality: checkpoint N LOCKED by certificate: block <hash> ... is off this node's selected chain (not determined here yet)13,354 (index 2954: 2,811; 2956: 2,799; 2957: 2,790; 2955: 2,778; 3897: 1,234; 1464: 942; the seed's next index was 6,127)
route error: incoming route capacity for message type IgneumFinality (the seed dropping ITS peers)13
the real work (determined, received, LOCKED, folded, replaced by a heavier one)13 + 13 + 13 + 8 + 20
@@ -745,79 +844,99 @@ table{min-width:560px}

The fix (four changes, 5a339733): ingest_certificate ignores an index below keep_from (counted, debug: the echo stops at its source once the seed runs it); the router's overflow policy for IgneumFinality is Drop with a counted warn once per 10 s per peer, never a disconnect; the finality route is subscribed with 4,096 (a checkpoint's worst case is MAX_VOTES_PER_BLOCK 48 votes on each of 30 blocks plus the certificates); the relay flow skips votes while IBD runs (counted, said once per 30 s; certificates still go in and land pending). No consensus change, no digest change. Tests: the overflow-policy table (p2p 33 of 33), the flows crate (19 of 19), a certificate below the window submitted twice (ignored, no gossip, counter 2; an index inside goes the normal way) with the finality tests (12 of 12).

After, on the fixed binary against the still-unfixed seed (203ae727, same run, 13:15:31 to 13:20:31Z): 63,628 certificates received (the seed's echo had grown to 3,032 per 10 s at the peak as more fleet nodes joined), 0 route errors, 0 drops, 4 connections kept (the seed and three peers learned from it), 168 votes skipped during IBD. The receiver side of the fix holds under a storm five times the morning's; the source side (the guard) cannot show on the seed until 0.3.13 runs there, and the fresh node's own guard never fires during IBD (its window starts at genesis), which is correct. Harness s7 on the fixed binary (--quick --live-only): PASS, 192 blocks accepted in 60 s under a 50 blocks/s flood from one peer, honest template p50/p95/max 0.4/0.6/1.4 ms, rss 306 to 321 MB.

Per tier: a home miner joining today sees the warning and the peers=0 flicker every checkpoint until the seed runs 0.3.13; a rig the same once; a pool user nothing; a fleet operator gets a node that keeps its only peer, and a seed that stops amplifying old certificates to every peer (13,354 lines of work it did not need in seven minutes). Owed: the fleet agent's synced-node reading; a receiver-side limit on certificates per index per minute as a second belt once the seed is fixed; the formatter's reflow of finality.rs (taken out of the commit).

-

6 October 2026, 16:01Z: Ember run 6 on the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) (ember-tune-pc1-6, 0.3.13 + kit-6 = 564bdea, elevated, one click)

+
+

6 October 2026, 16:01Z: Ember run 6 on the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) (ember-tune-pc1-6, 0.3.13 + kit-6 = 564bdea, elevated, one click)

The helper registered inside the run but on the scratch copy (fixed: task_exe, the reregister verb; see the plan's run 6 notes). RTX 5090: chosen 1854 MHz at 100% = 127.71 MH/s at 226.8 W, 0.563 MH/W, against 127.9 at 311.0 W (0.411) untuned: 84 W saved for 0.15% of rate. Every cap step 60 to 100% read 311 to 313 W (the cap never binds). The clock ladder: 2781 MHz 298.8 W 0.428; 2472 MHz 262.0 W 0.488; 2163 MHz 239.9 W 0.533; 1854 MHz 226.8 W 0.563 (the floor, not the optimum: the next cut's ladder goes to 45%). RTX 4070: caps 100 to 60% all 106.0 W 28.71 MH/s (0.271); 50% 99.1 W 28.70 (0.290); clock 2794 MHz at 50% 99.1 W (0.290); 2484 MHz 81.1 W 28.73 (0.354); further rows and the 9070 XT ladder below once the run closes.

Run 6 closed 16:39:37Z, exit 0, 2317 s, 19 rows. RTX 4070 chosen 1863 MHz at 50% = 28.78 MH/s at 75.6 W (0.381) against 28.72 at 106.0 W (0.271): 30 W saved for no rate lost; its clock ladder at 50%: 2794 MHz 99.1 W 0.290; 2484 MHz 81.1 W 0.354; 2173 MHz 77.7 W 0.370; 1863 MHz 75.6 W 0.381 (the floor). RX 9070 XT: aborted at step 1, "card reports 0 W, acknowledged true" = the applied rule demanded watts from a card that reports offsets (fixed bd7fcf4); the draw itself was read on every tick (amd_watts_source=engine_telemetry, 363 samples). The helper registered on the scratch copy (fixed 200362a: task_exe, the reregister verb). the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) mined through the installed app again by 16:44Z: 170.6 MH/s over the three cards, 0 faults.

Re-point and proof, 16:48 to 16:53Z: the Power Helper task re-pointed by the helper itself ("1 reregister ok: the task now runs ...Programs\Igneum Miner\igneum-app.exe --power-helper"), then the installed app's caps through the task with no prompt ("-pl 460: set to 460.00 W from 575.00 W", "-pl 160: set to 160.00 W from 100.00 W"). Task Running, Highest, user Admin. Cards: 5090 221 W at 1845 MHz, 4070 75.8 W at 1860 MHz, 9070 XT 202 W, all mining through the installed app. Ember closed 16:53Z.

-

Prover tiers on real cards: the rented fleet, 6 October 2026 (branch gpu-fleet)

+
+

Prover tiers on real cards: the rented fleet, 6 October 2026 (branch gpu-fleet)

From 11:50 UTC, Vast.ai containers (nvidia/cuda:12.8.1-devel-ubuntu24.04, the host's driver), one card each, the 0.3.12 Linux node 83089544 on the ten-field override, the 0.3.12 CUDA worker, the patched SP1 server built on each box from proving/prover-floor/sp1-gpu-6.8.1-floor.patch v4 (e81cb0d0...) for the card's own arch, the cuda host with the pinned ids 0x2b1a81cb... and 0x474678f3...; the v1 shard (fees-v1-shards2.json shard 0, 4,717,439 cycles); every proof VERIFIED by the host's own SDK verifier; peak = nvidia-smi memory.used sampled once a second (a per-second loop, not -l 1, which buffers and ignores SIGTERM in a container); own = peak minus the reading before the point; beside = the card's miner running (its resident set is the base). Runner tools/fleet/box-matrix.sh, collector tools/fleet/collect.py, raw logs fleet/<instance>/, the analysis docs/analysis/prover-tiers-real-cards.md.

CardVRAM GBIdle MiBMinerStock SP1 6.8.1Patched, proves alone (own)Beside the miner (peak)Core-only beside the miner (own)Verdict
RTX 306012123.78 MH/s at 103.7 W, 1.4 GBrefused: thread 'tokio-rt-worker' (48952) panicked at sp1-gpu/crates/7.4 GB, 14.4 s (alone-comp-26-v1)8.9 GB peak, 37.5 s5.6 GB, 27.2 smines and proves
RTX 3080101140.82 MH/s at 204.9 W, 1.5 GBrefused: thread 'tokio-rt-worker' (49593) panicked at sp1-gpu/crates/8.0 GB, 7.1 s (alone-comp-26-v1)9.2 GB peak, 25.6 s5.9 GB, 19.2 smines and proves
RTX 309024137.79 MH/s at 228.8 W, 1.5 GBnot measured: the SDK's server download stalled (killed at 553 s)7.7 GB, 14.9 s (alone-comp-26-v1)9.3 GB peak, 19.9 s5.8 GB, 13.3 smines and proves
RTX 4060 Ti 16 GB16017.58 MH/s at 72.3 W, 1.4 GBrefused: thread 'tokio-rt-worker' (49293) panicked at sp1-gpu/crates/7.8 GB, 11.6 s (alone-comp-26-v1)9.0 GB peak, 34.6 s5.8 GB, 25.9 smines and proves
RTX 4060 Ti 8 GB8019.07 MH/s at 72.6 W, 1.4 GBrefused: thread 'tokio-rt-worker' (43763) panicked at sp1-gpu/crates/7.6 GB, 9.6 s (alone-comp-26-v1)no GB peak, s5.8 GB, 26.3 smines and proves core-only
RTX 40608217.07 MH/s at 0.0 W, 1.4 GBrefused: thread 'tokio-rt-worker' (48510) panicked at sp1-gpu/crates/7.4 GB, 18.4 s (alone-comp-26-v1)no GB peak, s5.6 GB, 22.1 smines and proves core-only
RTX 407012924.99 MH/s at 91.1 W, 1.4 GBrefused: thread 'tokio-rt-worker' (47475) panicked at sp1-gpu/crates/7.6 GB, 12.1 s (alone-comp-26-v1)10.1 GB peak, 27.3 s5.6 GB, 14.3 smines and proves
RTX 409024152.25 MH/s at 183.1 W, 1.7 GBproved 5.6 s at 17.4 GB7.9 GB, 6.3 s (alone-comp-26-v1)10.7 GB peak, 26.1 s6.1 GB, 10.6 smines and proves
RTX 507012241.89 MH/s at 137.0 W, 2.7 GBrefused: thread 'tokio-rt-worker' (53680) panicked at sp1-gpu/crates/7.6 GB, 4.8 s (alone-comp-26-v1)10.2 GB peak, 37.2 s5.8 GB, 19.8 smines and proves
RTX 509032298.48 MH/s at 258.2 W, 1.8 GBproved 8.4 s at 18.3 GB8.0 GB, 6.3 s (alone-comp-26-v1)9.9 GB peak, 10.7 s6.3 GB, 7.4 smines and proves
RTX A500024147.7 MH/s at 222.7 W, 1.5 GBproved 6.4 s at 17.2 GB7.7 GB, 8.3 s (alone-comp-26-v1)10.5 GB peak, 34.6 s6.0 GB, 18.2 smines and proves

Also measured: the stock SP1 6.8.1 server refuses every card under 24 GB at builder.rs:38 and proves the v1 shard on the 4090 (5.6 s, 17.4 GB), the A5000 (6.4 s, 17.2 GB) and the 5090 (8.4 s, 18.3 GB); 2^27 does not fit a 10 or 8 GB card and the v4 server hangs at the card's limit (568 and 904 s until killed) where v5 aborts in 13 s ("FLOOR abort: a device allocation failed at slop/crates/tensor/src/inner.rs:51 ... AllocError { size: 486586112 }", exit 70; the known-failed case of the prover-floor gate, on the 3080); the miner beside a prover costs 1.7x (5090) to 7.7x (5070) on the proof's time and 5 to 20% of the miner's rate; the empty-shard fixture (block-72854, a first block with a genesis witness) proves slower than the v1 shard on every card (24 to 55 s) and is not an empty live shard; Ember's two knobs are refused in the containers, so the ladders are baseline rows (docs/plans/ember-tune.md, fleet priors).

-

Rental cost of hash, 6 October 2026 (branch gpu-fleet): what a GH/s costs by the hour against the devnet

+
+

Rental cost of hash, 6 October 2026 (branch gpu-fleet): what a GH/s costs by the hour against the devnet

Measured on the rented fleet (RunPod community pods, list prices, 18:45Z): 38 wave pods (4090, A4000, L4, 3090, 3070, 4070 Ti, A5000, 4000 Ada) ran 1,748 MH/s inside jobs (median pod 28 MH/s) for USD 20.44 an hour, USD 0.0117 per MH/s-hour; the 8x 4090 rig 459 MH/s at 1,636 W for USD 5.92 an hour, USD 0.0129 per MH/s-hour; a single 5090 pod 98 to 128 MH/s for USD 0.41 to 0.74 an hour. The live devnet's difficulty read 1,156,040,186 at 1 block a second at 19:00Z, so the whole network was about 1.16 GH/s, and the rented fleet was most of it. The live litepaper's line ("2 GH/s for USD 13/h vs 280 MH/s devnet") is corrected to: 1.75 GH/s for USD 20 an hour on community pods, against a devnet of 1.16 GH/s.

BuyerWhat USD 20/h buysAgainst the devnet (1.16 GH/s)Against mainnet scale
Home miner, 8 to 12 GB card (11 to 28 MH/s)nothing: the card is owned, 0.15 to 0.2 kWone card is 1 to 2 percent of the devnetone card is noise at a TH/s
Rig, 8x 4090 (459 MH/s, USD 5.92/h rented)1.7 rigsone rig is 40 percent of the devnetone rig is 0.05 percent of a TH/s
Renter at RunPod list prices1.75 GH/s while cards exist150 percent of the devnet: overtaken for USD 15/ha TH/s costs USD 11,700 an hour and the market cannot supply it: asked for 20 pods of any of 8 card types at 18:59Z to 19:15Z, RunPod gave 0 ("no instances currently available")
-

Consequence: the devnet's hash is rentable for the price of a dinner, so nothing on it is a security result; the counter-ASIC and finality work is tested there for correctness, not for cost. The cost argument only starts at the TH/s scale, where the rental market's supply (not its price) is the limit, and that number belongs in the litepaper with this caveat.

+

Consequence: the devnet's hash is rentable for the price of a dinner, so nothing on it is a security result; the counter-ASIC and finality work is tested there for correctness, not for cost. The cost argument only starts at the TH/s scale, where the rental market's supply (not its price) is the limit, and that number belongs in the litepaper with this caveat.

+
+

Block rate on Devnet 2, 6 October 2026 (branch gpu-fleet): 10 blocks per second against 1 on 42 rented cards

+

Run A (10 blocks/s profile, star topology, 65 min): 4.87 DAG blocks/s, 1.09 blue blocks/s, 77.6 percent red, tips 250 to 660, max reorg 55, difficulty easing all hour (6,719 to 1,307), the exec follower at 0.05 blocks/s (lag 18,901 at the end). Run B (1 block/s, same boxes, 30 min): 1.41 blocks/s over the window with the join burst, 1.0 blocks/s and under 2 percent red from minute six, tips 1 to 3, difficulty settled in six minutes (453 to 482 M), the exec follower at 0.46 blocks/s. The network lane's read: run A's reds came from node throughput (61 to 345 ms CPU per accepted block at mergeset 8 to 200), not from the star. Per tier the blue rate decides the payout interval (1.09 against 1.19 blue/s: a 4070 at 10 TH/s waits about three days for a paying block either way), so the higher rate buys the solo miner nothing until the node processes a block in under 50 ms at mergeset 248. Recommendation (the lane's): 1 block/s for the testnet and the launch, 10 behind three measured gates. Full tables and sources: docs/analysis/block-rate-devnet2.md, rows in fleet/bps/{A,B}.jsonl.

+
+

The rented fleet is the devnet's finality, 6 October 2026 (branch gpu-fleet)

+

Measured at 21:57Z from the hub's last 2,000 blocks: the 38 wave pods held 77.8 percent of the voter weight (mean 2.05 percent a pod), the 14 standing boxes most of the rest, the hands and the hub the remainder; the last lock signed 93.5 percent of the active voters and 89.9 percent of the frozen table (53 of 84 voters on the first certificate). Earlier the same evening the fleet removed 13 miners' GPUs inside three minutes and finality paused for two hours five minutes (18:39:36Z to 20:44:44Z, 42.7 percent of the table gone with earlier leavers; rule v3 holds a full window). From that came the 10 percent rule (never remove more than 10 percent of the live devnet's weight in an hour, tools/fleet/lib/standing.py weight_check) and the wave's wind-down by hourly slices (tools/fleet/winddown.py: slice 1 at 21:58Z took 12 pods and the 8x rig at 8.6 percent of weight).

+

When the wave is gone the 14 standing boxes hold about 95 percent of the weight, so from then until public hash arrives the fleet alone is the devnet's finality: a home miner's lock lands only while the fleet is up. What holds it up: every standing box runs under box-standing.sh, which restarts a dead node within one of its 60-second passes (the hub's three deaths tonight: 63 s, 41 s and 56 s to the restart line), restarts the miner with the node, prunes the prover's exports and trims the node log, and runs the exec recovery recipe when the state layer reads zero; lib/standing.py loop re-rents a dead host in the same shape and reports a box behind its wanted binary.

+
TierWhat it means
Home mineryour lock depends on 14 rented cards staying up and mining; a finality pause is not your node's fault and nothing you can fix; the rule above is what keeps it from recurring on the fleet's side
Rigthe same, and a rig that leaves is itself a weight removal: at 459 MH/s on tonight's devnet it is about 20 percent of the weight, over the hour's budget by itself
Poola pool node is one voter carrying its members' whole weight; a pool restart is the largest single removal on the network and must be sliced like the fleet's
The networkfinality by miner weight is only as steady as the miners' uptime; until public hash dwarfs the fleet, the fleet's supervisor is a consensus component

Generated from the repository at build time. Times are UTC. Machine names are model names.

+
- + \ No newline at end of file diff --git a/site/block.html b/site/block.html index 262039c9..0d123503 100644 --- a/site/block.html +++ b/site/block.html @@ -29,6 +29,7 @@ +
+
Explorer · block

Block

@@ -161,61 +178,68 @@ main{padding-bottom:var(--sec)}
- diff --git a/site/build.mjs b/site/build.mjs index 83257d38..76b992e9 100644 --- a/site/build.mjs +++ b/site/build.mjs @@ -51,7 +51,8 @@ const HEAD = partial('head.html'), NAV = partial('nav.html'), FOOT = partial('fo function navFor(active) { if (!active) return NAV; const re = new RegExp(`( `; } -function page(title, desc, bodyHtml, toc, note, { path = '/bench', heading = title, active = 'bench', eyebrow } = {}) { +function sectionise(bodyHtml) { + // the markdown renderer's flat stream, cut at every h2 into
so the contents rail and the + // text filter work on sections; anything before the first h2 is its own section + const parts = bodyHtml.split(/(?=

${p}

`).join('\n'); +} +function page(title, desc, bodyHtml, toc, note, { path = '/bench', heading = title, active = 'bench', eyebrow, crumb, filter = true } = {}) { const h2s = toc.filter(t => t.lvl === 2); - const nav = h2s.map(t => `
  • ${esc(t.t)}
  • `).join(''); + const nav = h2s.map(t => `${esc(t.t)}`).join(''); + const key = path.replace(/^\//, '') || 'doc'; return ` @@ -103,53 +111,51 @@ ${meta(title, desc, path)} ${HEAD} ${navFor(active)} -
    -
    -
    ${eyebrow || `${h2s.length} entries, newest at the bottom`}
    +
    +
    +
    + +
    ${eyebrow || `${h2s.length} entries, newest at the bottom`}

    ${esc(heading)}

    -

    ${note}

    +

    ${note}

    -
    - -
    ${bodyHtml}
    +
    +
    +${filter ? `
    ` : ''} +
    + +
    ${sectionise(bodyHtml)}

    Generated from the repository at build time. Times are UTC. Machine names are model names.

    +
    ${FOOT} + `; } @@ -161,7 +167,7 @@ if (existsSync(join(docs, 'bench-log.md'))) { const { html, toc } = md(src); writeFileSync(join(here, 'bench.html'), page('Igneum engineering log', 'Every Igneum benchmark and test, with the hardware and the commands that produced it. Prototype numbers are labelled as such.', html, toc, 'Every measurement the project has made, newest at the bottom, written by the people and agents who ran it, with the commands and hardware. Prototype numbers are not mining numbers and say so.', - { path: '/bench', heading: 'Engineering log' })); + { path: '/bench', heading: 'Engineering log', crumb: 'Engineering log' })); built.push('bench.html'); // journey feed: dated headings become log entries. `short` is the homepage line (one clause, under 72 characters); // SHORT holds hand-written lines keyed by the start of the heading, the rule below covers the rest. @@ -338,12 +344,12 @@ function renderEvidence(html) { const d = new Date(); const MON = ['Jan','Feb','Mar','Apr','May','Jun','Jul','Aug','Sep','Oct','Nov','Dec']; const day = `${d.getUTCDate()} ${MON[d.getUTCMonth()]} ${d.getUTCFullYear()}`; const dayLong = `${d.getUTCDate()} ${['January','February','March','April','May','June','July','August','September','October','November','December'][d.getUTCMonth()]} ${d.getUTCFullYear()}`; - html = html.replace(/
    \d+ claims · 5 labels · [^<]*<\/div>/, `
    ${rows.length} claims · 5 labels · ${day}
    `); + html = html.replace(/
    (?:<\/span>)?\d+ claims · 5 labels · [^<]*<\/div>/, `
    ${rows.length} claims · 5 labels · ${day}
    `); html = html.replace(/

    Statuses are honest as of [^<]*<\/p>/, `

    Statuses are honest as of ${dayLong}, the day this page was generated from docs/evidence.md, and change only through that file.

    `); return html; } -const PAGES = [['index.html', ''], ['litepaper.html', 'litepaper'], ['live.html', 'live'], ['evidence.html', 'evidence'], ['miner.html', 'miner'], ['wallet.html', 'wallet'], ['metamask.html', ''], ['faucet.html', ''], ['404.html', ''], +const PAGES = [['index.html', ''], ['litepaper.html', 'litepaper'], ['live.html', 'live'], ['evidence.html', 'evidence'], ['miner.html', 'miner'], ['app.html', 'app'], ['wallet.html', 'wallet'], ['metamask.html', ''], ['faucet.html', ''], ['404.html', ''], // the DAG explorer (5 Oct 2026): /explorer, /block/ and /address/ (vercel.json rewrites the last two) ['explorer.html', 'live'], ['block.html', 'live'], ['address.html', 'live'], // the scenes lab (6 Oct 2026): three animated views of the live feed, unlinked, noindex @@ -408,7 +414,153 @@ for (const [file, active] of PAGES) { const toc = [{ lvl: 2, t: 'The table', id: 'table' }, { lvl: 2, t: 'How a row gets here', id: 'how' }, { lvl: 2, t: 'Fleet tuning priors', id: 'priors' }]; writeFileSync(join(here, 'miners.html'), page('Igneum GPU bench table', 'Measured Igneum hash rates per GPU: card, generator version, best MH/s, MH per watt where measured, miner version, date and the log entry each number came from.', body, toc, 'Measured hash rates per card on the Igneum lottery hash, with the generator version, the miner version, the date and the log entry behind each number.', - { path: '/miners', heading: 'GPU bench table', active: 'miner', eyebrow: `${rows.length} measured rows, ${prows.length} fleet tuning models` })); + { path: '/miners', heading: 'GPU bench table', active: 'miner', eyebrow: `${rows.length} measured rows, ${prows.length} fleet tuning models`, crumb: 'GPU bench table' })); built.push('miners.html (' + rows.length + ' rows)'); } + +// The secondary pages (7 Oct 2026, the redesign): each one is rendered from ONE source so no sentence is kept twice by hand. +// /claims and /randomx are the litepaper's own sections (their ledger sentences stay on the litepaper, which is what the +// ledger text check reads); /dev-fee is the miner page's fee section; /provenance is docs/provenance.md through the same +// scrub as /bench; /journey is journey.json (the phases and the log the bench entries feed). A page with no source is not written. +function shell({ title, desc, path, crumb, eyebrow, heading, lead, body, active = '', style = '', after = '' }) { + return ` + + + + +${meta(title, desc, path)} + +${HEAD} + + + + + +${navFor(active)} + +
    +
    +
    + +
    ${eyebrow}
    +

    ${heading}

    +

    ${lead}

    +
    +
    +
    +
    +${body} +${after} +
    +
    +
    + +${FOOT} + + + +`; +} +// a section of a built page, its own h2 and section head removed, its in-page anchors pointed back at the source page +function sectionOf(file, id, base) { + const html = readFileSync(join(here, file), 'utf8'); + const m = new RegExp(`
    ]*>([\\s\\S]*?)
    `).exec(html); + if (!m) throw new Error(`${file}: no
    `); + let inner = m[1]; + // the section head (eyebrow, h2, an optional lead) is removed by a balanced walk over its divs, never a lazy regex + // (7 Oct 2026: a lazy match ran on to the first
    pair inside the fee card and emptied /dev-fee) + const hs = inner.indexOf('
    '); + let lead = ''; + if (hs >= 0) { + let depth = 0, i = hs; const re = //g; re.lastIndex = hs; let m; + while ((m = re.exec(inner))) { depth += m[0] === '
    ' ? -1 : 1; if (depth === 0) { i = m.index + m[0].length; break; } } + if (depth !== 0) throw new Error(`${file}#${id}: unbalanced section head`); + const head = inner.slice(hs, i); const pm = /

    ([\s\S]*?)<\/p>\s*<\/div>\s*$/.exec(head); lead = pm ? pm[1] : ''; + inner = inner.slice(0, hs) + inner.slice(i); + } + inner = inner.replace(/^\s*

    [\s\S]*?<\/h2>/, ''); + const ids = new Set([...inner.matchAll(/\sid="([^"]+)"/g)].map(x => x[1])); + inner = inner.replace(/href="#([^"]+)"/g, (all, frag) => ids.has(frag) ? all : `href="${base}#${frag}"`); + return { html: inner.trim(), lead }; +} +function onward(links) { return `
    ${links.map(([href, label]) => `${esc(label)}`).join('')}
    `; } +{ + const lp = sectionOf('litepaper.html', 'limits', '/litepaper'); + writeFileSync(join(here, 'claims.html'), shell({ + title: 'What Igneum does not claim', desc: 'The limits of Igneum, stated first: proof times, chips, income, finality in the first month, the review it has not had yet. From the litepaper, with the ledger behind it.', + path: '/claims', crumb: 'What Igneum does not claim', eyebrow: 'The limits, stated first', heading: 'What Igneum does not claim.', + lead: 'Every limit we know of, written down here before anyone else writes it. The same text as the litepaper’s last section; the ledger carries every criticism in full.', + body: `
    ${lp.html}
    `, active: 'litepaper', + after: onward([['/ledger', 'The ledger: every criticism'], ['/evidence', 'The evidence page'], ['/litepaper#limits', 'Read it in the litepaper']]), + })); + built.push('claims.html (from litepaper#limits)'); + const rx = sectionOf('litepaper.html', 'randomx', '/litepaper'); + writeFileSync(join(here, 'randomx.html'), shell({ + title: 'Igneum and RandomX', desc: 'Monero’s random-program idea, rebuilt for graphics cards: a program per hour instead of a program per hash, a dataset that grows, and what RandomX’s record does and does not say about Igneum.', + path: '/randomx', crumb: 'Igneum vs RandomX', eyebrow: 'Monero’s idea, finished for GPUs', heading: 'RandomX, rebuilt for GPUs.', + lead: 'Random-program mining is the idea Igneum borrowed. Here is what changed when it was rebuilt for graphics cards, and what RandomX’s seven years say and do not say about this chain. The same text as the litepaper’s section.', + body: `
    ${rx.html}
    `, active: 'litepaper', + after: onward([['/litepaper#mining', 'How mining works'], ['/litepaper#chip-model', 'The chip model'], ['/provenance', 'Built on the shoulders']]), + })); + built.push('randomx.html (from litepaper#randomx)'); + const fee = sectionOf('miner.html', 'fee', '/miner'); + writeFileSync(join(here, 'dev-fee.html'), shell({ + title: 'The Ember dev fee, in full view', desc: 'The protocol carries no fee. The Ember software takes an optional 1% dev fee, the norm for GPU miners, visible in the app and off with one flag. Where it is, how it was measured, how to turn it off.', + path: '/dev-fee', crumb: 'The dev fee', eyebrow: 'The dev fee', heading: 'The fee, in full view.', + lead: fee.lead || 'The protocol carries no fee. The software fee is the miner app’s, like every other GPU miner’s, and one flag turns it off.', + body: fee.html, active: 'miner', + style: '.feecard{display:grid;grid-template-columns:1fr;gap:var(--s-4)}@media (min-width:900px){.feecard{grid-template-columns:minmax(0,1.1fr) minmax(0,.9fr);align-items:start}}pre b{color:var(--molten-text);font-weight:500}', + after: onward([['/miner#get', 'Get the miner'], ['/litepaper#economics', 'The economics'], ['/bench', 'The engineering log']]), + })); + built.push('dev-fee.html (from miner#fee)'); +} +if (existsSync(join(docs, 'provenance.md'))) { + const src = scrubBench(readFileSync(join(docs, 'provenance.md'), 'utf8')); + const { html, toc } = md(src); + writeFileSync(join(here, 'provenance.html'), page('Igneum provenance: built on the shoulders', 'Every borrowed component of Igneum credited in public: the origin and licence, what changed, why the design needed it, and how the change is measured. What is new in Igneum, and what is adopted from upstream.', html, toc, + 'Igneum credits every borrowed component in public, replaces only what its own design requires, and measures every change. This table is the record: the origin and licence, what changed, why, and the measurement behind it.', + { path: '/provenance', heading: 'Built on the shoulders', active: 'litepaper', eyebrow: 'Provenance · the decision of 3 October 2026', crumb: 'Built on the shoulders', filter: false })); + built.push('provenance.html (from docs/provenance.md)'); +} +{ + const j = JSON.parse(readFileSync(join(here, 'journey.json'), 'utf8')); + const STATUS = { active: ['current', 'Under way'], next: ['next', 'Next'], done: ['done', 'Done'] }; + const phases = (j.phases || []).map((p, i) => { const [cls, word] = STATUS[p.status] || ['', p.status]; return `
    ${esc(p.when)}
    ${word}

    ${i + 1}. ${esc(p.name)}

    ${esc(p.line)}

    ${p.gate ? `

    Gate: ${esc(p.gate)}

    ` : ''}
    `; }).join('\n'); + const MON = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']; + const day = d => { const [y, m, dd] = d.split('-'); return `${Number(dd)} ${MON[Number(m) - 1]} ${y}`; }; + const log = (j.log || []).map(e => `
    log

    ${esc(e.short || e.text)}

    ${e.short && e.short !== e.text ? `

    ${esc(e.text)}

    ` : ''}
    `).join('\n'); + writeFileSync(join(here, 'journey.html'), shell({ + title: 'The Igneum journey: six phases, four gates', desc: 'Where Igneum is: six phases from the specification to a fair launch, each closing at a published gate, and the engineering log’s latest entries. No calendar dates.', + path: '/journey', crumb: 'The journey', eyebrow: `Six phases · updated ${day(j.updated)}`, heading: 'The journey.', + lead: 'Six phases from the specification to a fair launch. Each closes at its gate, a measurement published whether it passes or fails, so there is no date to slip. Below the phases, the latest entries of the engineering log.', + body: `
    ${phases}
    +
    The log, newest first

    Lately, in the log.

    +
    ${log}
    + +

    Every entry is a dated heading of the engineering log, where the commands and the hardware are. The phases and their gates are the litepaper’s roadmap.

    `, + active: '', + after: onward([['/bench', 'The engineering log'], ['/evidence', 'Every claim and its status'], ['/live', 'The live devnet']]), + })); + built.push('journey.html (' + (j.phases || []).length + ' phases, ' + (j.log || []).length + ' entries)'); +} console.log('built: ' + built.join(', ')); +// the header rule: every served page carries the full nav (tools/ci/site-nav-check.mjs); the build fails on a shorter one +// (the gate builds a copy of site/ alone and runs the check as its own line, so a missing tools/ is not a failure here) +{ const check = join(here, '..', 'tools', 'ci', 'site-nav-check.mjs'); if (existsSync(check)) { const { spawnSync } = await import('node:child_process'); const r = spawnSync(process.execPath, [check, here], { stdio: 'inherit' }); if (r.status !== 0) process.exit(r.status || 1); } } diff --git a/site/claims.html b/site/claims.html new file mode 100644 index 00000000..e7ce19fa --- /dev/null +++ b/site/claims.html @@ -0,0 +1,232 @@ + + + + + +What Igneum does not claim + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    +
    + +
    The limits, stated first
    +

    What Igneum does not claim.

    +

    Every limit we know of, written down here before anyone else writes it. The same text as the litepaper’s last section; the ledger carries every criticism in full.

    +
    +
    +
    +
    +

    Here are the limits, stated before anyone else states them.

    +
      +
    • A proof in seconds. Not at launch. Proving a full block today needs a cluster of 100 to 200 consumer GPUs, approximate, so Igneum launches with proofs within about a minute and tightens as hardware improves. Users still see their transaction land in one second.
    • +
    • A chip is impossible. No. A chip wired for one program is a bad bet, because the program moves before it ships. A programmable chip is not stopped by the moving target: everything it needs is public at genesis and every drawn parameter is firmware to it (an address permute, a rotator, an immediate table), so the defence against it is the latency-shadow work (class v4) and the price per joule, not the schedule (the Horizon lane analysis, 6 October 2026, section 5.4; ledger M32). The published model (5 October 2026) prices the strongest chip we can name, one with the whole cache on-die computing dataset items on the fly, at 0.92x the hash rate of an RTX 5090 per unit of silicon with a 3x fixed-function allowance, approximate. The same model, drawn out to the chip that stores the dataset (6 October 2026): The strongest recompute chip we can price, holding the whole 256 MiB cache on-die, reaches under 1x per chip against an RTX 5090. A memory-controller chip that stores the whole dataset reaches 1.2x per chip and, in our model, 5x to 9x per joule; the Ethash chips of this class reached 2.1x to 4.8x. The lever against it, program work in the latency shadow, is measured and in its gates: it brings the chip to 2.1x to 3.9x, the range running from a chip core as costly per operation as the GPU’s (k = 1) to the core Bitmain claimed for its withdrawn Antminer X9 (k about 0.33, never measured); the ladder’s second rung takes that bracket to about 2.8x. Sources: the chip model analysis (6 October 2026); the Ethash rows of the ASIC history (Linzhi Phoenix 2020, Jasminer X4 2021, Antminer E9 2022); Counter ASIC 3.0 item 8 (100,000 ops per hash: the chip's per-joule edge over the RTX 5090 falls from 5.6x to 2.1x on GDDR7 at a chip core equal to the GPU's (k = 1) and to 3.9x at the X9’s claimed core (k about 0.33, never measured), the 5090 at 0.2% less rate, gates G1 to G6 in progress). No hash has stayed free of chips forever; Igneum does not claim to. Monero’s RandomX has held for about seven years; the one chip announced against it, Bitmain’s Antminer X9, was withdrawn in mid-May 2026 before any unit shipped, its claimed core (k about 0.33) never measured. That record says nothing about the price of a chip with the 256 MB cache on its die; that price is a cost model, not a measurement.
    • +
    • A guaranteed income floor. No. External proving is a small market today. Igneum's miners' electricity cost in it is close to power, but the price they must charge is the subsidy they forgo, which falls as one over network hash: an edge at scale and nothing more.
    • +
    • A memory-hard prototype on every vendor. Not yet. The 256 MB cache closed the shortcut on Apple silicon (computing items runs 4.8x slower than loading them, measured 3 October 2026). The same ratio on NVIDIA and on a discrete AMD card is Open.
    • +
    • Finality in the first month. No. No checkpoint locks until the 30-day window has 30 days of history. The first month of mainnet is proof of work with a 12-hour depth, and the text above says so wherever a day count appears.
    • +
    • A cryptography team. Not yet. One founder working with AI systems wrote the design and the code; external reviewers are named and paid before gate 3, and every security claim here is a design claim until then.
    • +
    • Finality that no amount of hardware can break. No. A miner holding a third of the last 30 days of blocks can split finality during a network partition, and two thirds can lock a bad checkpoint for a double-spend bounded by the 12-hour finality depth. Reaching a third takes at least ten days of producing every block on the chain, in public; an attacker matching the honest network needs twenty days for a third and never reaches two thirds. That is harder than attacking Bitcoin, where a majority can reorganise at once, and it is the limit of proof of work without stake or an outside chain. Igneum chose those limits on purpose. The floor is also bounded in time: an honest partition that lasts long enough for each side's own new blocks to reach two thirds of its window locks on both sides, about ten days of a 30-day window at an even split, and an operator must then resolve it (measured on a test network, 4 October 2026).
    • +
    • Finality that never pauses. No. A lock needs two thirds of all 30-day mining weight. Whenever less than two thirds of that weight is connected and signing, finality pauses until it returns or ages out of the window, up to 30 days. The chain keeps running on proof of work and the node reports the pause.
    • +
    • A finished protocol. The sustained-mining finality rule is the newest piece and the one that external review will try hardest to break. The specification, the review and the benchmarks are published as they happen.
    • +
    +

    Everything in this document is subject to the gates on the roadmap. Nothing in it is an offer to sell anything. Found an error, or a criticism this document does not answer? Email hello@igneum.network, or open an issue on the public specification repository: github.com/igneum-network/spec/issues. Post reaches Igneum Labs LTD, Unit IH-00-01-01-OF-01, Level 01, Innovation One, Dubai International Financial Centre.

    + +
    +
    +
    + + + + + + + + \ No newline at end of file diff --git a/site/dev-fee.html b/site/dev-fee.html new file mode 100644 index 00000000..f65b6c50 --- /dev/null +++ b/site/dev-fee.html @@ -0,0 +1,243 @@ + + + + + +The Ember dev fee, in full view + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    +
    + +
    The dev fee
    +

    The fee, in full view.

    +

    The protocol carries no fee: no dev fund, no fee to any team, foundation or fund. The software fee is the miner app’s, like every other GPU miner’s, and one flag turns it off.

    +
    +
    +
    +
    +
    + +
    +
    +

    The Ember software takes a visible, switchable 1% dev fee, the norm for GPU miners. One block template in 100 is requested with the dev payout address instead of yours. The fee goes to Igneum Labs LTD, the company that ships the software.

    +
    + + + + + + +
    WhereOff with
    The app, Earningsthe Dev fee switch under the money rows
    The command line--dev-fee 0
    HiveOS, extra configDEV_FEE=0
    +

    Measured on a test network, 4 Oct 2026: 9 fee blocks in the 785 blocks of two fee-paying miners (1.146%); the control miner at --dev-fee 0 paid none; the miners’ counters and both nodes agree. The log.

    +
    +
    +
    Earnings, as the app shows it
    +
    Dev fee: 1 block in 100 pays the people who make this app
    +

    The network itself takes nothing. This is the app’s fee, the same way every mining app takes one. This switch turns it off.

    +
    What the miner prints at start
    +
    dev fee 1% (1 block in 100) to 0x<address>; --dev-fee 0 turns it off
    +
    +
    +
    + +
    +
    +
    + + + + + + + + \ No newline at end of file diff --git a/site/evidence.html b/site/evidence.html index eed08d49..131b945e 100644 --- a/site/evidence.html +++ b/site/evidence.html @@ -31,6 +31,7 @@ +
    -
    devnet, last 24 hours
    -

    Explorer

    -

    Every block the devnet made in the last day, read from a node by the observer. Paste a block hash, a transaction hash, a chain block number or an address.

    + +
    devnet, last 24 hours
    +

    Explorer.

    +

    Every block the devnet made in the last day, read from a node by the observer. Paste a block hash, a transaction hash, a chain block number or an address, or click any row.

    - diff --git a/site/faucet.html b/site/faucet.html index c8e71643..e4ef11f1 100644 --- a/site/faucet.html +++ b/site/faucet.html @@ -27,6 +27,7 @@ + - - +
    - -
    -
    -

    A proof-of-work chain for graphics cards, whose miners prove the blocks.

    -
    - Download the miner - Read the litepaper +
    Built for GPU miners / devnet live

    Your GPU has
    more to give.

    You already own the card. Igneum gives it a job worth doing: mine the block, prove it, watch it lock. One click installs the node, the miner and the prover.

    Devnet build. Coins have no value. The chain may reset.
    IGNEUM / EMBERYour card becomes the network
    01 / MiningIllustration
    The card runs this hour’s program. A block comes out.Drawn, not live telemetry. The live graph is below.
    GPU > BLOCK > PROOF > LOCK
    Graphics cards onlyA new mining program every hour
    The miners are the proversSame card, two jobs, 80/20 of every block
    No premine, no stakeNo fee to any team in the protocol
    Every claim has a statusThe evidence page says how far each one is tested
    +
    See what your card joins

    Follow the work.
    See the chain grow.

    Open the observatory
    BLOCKDAG/The live devnet, one lane per miner.
    connecting
    Live now
    pending
    pending vote keys mined a block in the last ten minutes; a card runs several
    Proven and paid
    pending
    shards proven and paid on the chain so far, pending of them in the last ten minutes
    The chip model
    5x to 9x
    Built for graphics cards. In our public model the strongest chip reaches 5x to 9x per joule against an RTX 5090 today; class v4, now on the vote, brings that to 2.1x to 3.9x, and class v5 makes the dataset the chain’s own state, so a chip that stores it or recomputes it is wrong on every item. The model and every measurement are public.
    One node is read every 2 s. The chip figures are a cost model, not a measurement.Look a block up in the explorer
    +
    +
    +
    +
    What miners asked for, 2018 to 2026

    Three things, in order.

    +

    Twenty launch posts and threads, and the same three asks each time: hardware that keeps its value, income that does not fall off a cliff, a fair supply. The front page answers those three. Finality is on page two.

    -
    -
    - -
    -

    Connecting to the devnet observer.

    -
    - -
    -
    -
    -
    Live now
    pending

    pending vote keys mined a block in the last ten minutes; a card runs several.

    -
    Proven and paid
    pending

    shards proven and paid on the chain so far, pending of them in the last ten minutes.

    -
    The chip model
    5x to 9x

    per joule for the strongest chip against an RTX 5090 today in our public model. With the class v4 shadow work it is 2.1x to 3.9x, from a core as costly as the GPU’s (k = 1) to the Bitmain X9’s (k about 0.33); the ladder’s second rung takes that to about 2.8x: the numbers.

    -
    -

    One node is read every 2 s. The chip figures are a cost model, not a measurement.

    -
    -
    - -
    -
    -
    -
    Igneum Ember · one click
    -

    Install. Start. The card mines.

    -
    - -

    Devnet. Coins have no value and the chain may be reset.

    -

    Public testnet: not yet open; the devnet build is here for people who want to look. The public testnet is weeks away: three seed nodes and the public RPC are up, and it opens when the go checklist closes.

    -

    Read more about the miner. The protocol carries no fee. The one payment to the project is the Ember software's optional 1% dev fee, like other GPU miners, off with one flag. Download only from this domain. Nobody from Igneum will ask for your seed. Questions: the Discord.

    -
    -
    - -
    -
    -
    -

    Every criticism, answered or conceded, and what Igneum does not claim.

    - The ledger +
    +
    +
    01
    +

    Your card stays a card.

    +

    The hash is a new random program every hour over a dataset the chain draws from its own state. No scheduled fork, no release a team must ship. The chip model and its number are published with every era on /evidence. When you stop, the card still games.

    + How mining works +
    +
    +
    02
    +

    Income with no cliff.

    +

    No halving day. The schedule glides month by month, then holds a steady share of supply for ever. A block pays its miner whether or not anyone buys a proof that day. What each card mines, and what its electricity costs, comes as one table when the testnet schedule is cut.

    + What your card does here +
    +
    +
    03
    +

    A fair supply.

    +

    No premine. No fund, no foundation, no fee to any team. Nobody holds a coin before block one. The founders mine from genesis with disclosed addresses and the same software as everyone else. The launch weeks ramp up from a low start, so they are worth less to a private farm.

    + The economics, as published +
    +
    Blocks are final by miners alone, with no stake and no other chain.How, on page two
    +
    The economic design, as published

    Made for the people running the hardware.

    Every block pays the card that found it and the cards that prove it. The protocol carves out nothing for a team, a foundation or a fund. No premine, no stake.

    Each block, by the rule
    100%to miners and provers
    80% Miningto the card that found the block
    20% Provingto the cards that prove it
    0% Treasurynothing to any team

    The protocol rule, not an income forecast. Cap 4,000,000,000 IGN, halving every two years. Devnet coins have no value.

    +
    Find your place

    A whole network to look round.

    Keep what you earned.

    A desktop wallet that checks finality itself. Block rewards and proving payouts in one history.

    The wallet

    See what your card does here.

    Measured hash rates per card, with the watts, the date and the log entry behind each number.

    The bench table

    Understand the design.

    Mining, proving, finality, the economics and the open questions, in one readable paper.

    Read the litepaper
    +
    Igneum Ember · one click

    Install. Start. The card mines.

    Everything about the miner

    Devnet. Coins have no value and the chain may be reset.

    Public testnet: not yet open; the devnet build is here for people who want to look. The public testnet is weeks away: three seed nodes and the public RPC are up, and it opens when the go checklist closes.

    Read more about the miner. The protocol carries no fee. The one payment to the project is the Ember software’s optional 1% dev fee, like other GPU miners, off with one flag. Download only from this domain. Nobody from Igneum will ask for your seed. Questions: the Discord.

    +
    Your next block starts here

    Give your GPU
    something to do.

    Download Ember, watch the devnet, and tell us what breaks. The people on the Discord run cards like yours.

    Experimental software. No promise of earnings.

    +

    Every criticism, answered or conceded, and what Igneum does not claim.

    The ledger
    - - + - + + + diff --git a/site/journey.html b/site/journey.html new file mode 100644 index 00000000..e2896c28 --- /dev/null +++ b/site/journey.html @@ -0,0 +1,268 @@ + + + + + +The Igneum journey: six phases, four gates + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    +
    + +
    Six phases · updated 6 Oct 2026
    +

    The journey.

    +

    Six phases from the specification to a fair launch. Each closes at its gate, a measurement published whether it passes or fails, so there is no date to slip. Below the phases, the latest entries of the engineering log.

    +
    +
    +
    +
    +
    Under way; closes when the specification is out for external review
    Under way

    1. Specification

    Mining generator, shard proving, finality rules, written for external review

    +
    Under way; closes at its gate
    Under way

    2. Prove the proving

    Mining program proven on Apple, NVIDIA and AMD; shard proving benchmark on consumer cards still to run

    Gate: A fixed published workload, job received to accepted proof on a declared consumer card, sustained with no growing backlog, reproduced by three independent operators

    +
    Live since 3 October 2026; closes at its gate
    Under way

    3. Devnet

    BlockDAG node mining on the new program, GPU miners on three vendors, EVM execution in build

    Gate: 1 block a second held with proofs under 60 s behind the tip

    + + +
    +
    The log, newest first

    Lately, in the log.

    +
    log

    16:01Z: Ember run 6 on the three-card Windows rig

    +
    log

    Counter ASIC 3.0 item 2

    Counter ASIC 3.0 item 2: the per-day derivation

    +
    log

    Counter ASIC 3.0 item 8

    Counter ASIC 3.0 item 8: program work in the latency shadow

    +
    log

    Counter ASIC 3.0 item 6

    Counter ASIC 3.0 item 6: the reserve families' step costs

    +
    log

    Counter ASIC 3.0 gate run, the hash side

    +
    log

    16:01Z: Ember run 6 on the three-card Windows rig (RTX 5090, RTX 4070

    16:01Z: Ember run 6 on the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT)

    +
    log

    00:4xZ, the empty `/api/state` reply

    +
    log

    07:12Z to 07:17Z, the host's chain mode with --save-shards records…

    07:12Z to 07:17Z, the host's chain mode with --save-shards records and --prev, on the Apple M5 Max's CPU

    +
    log

    07:52Z to 08:24Z, the segment-aligned prover beside the miner on the…

    07:52Z to 08:24Z, the segment-aligned prover beside the miner on the RTX 5090 Windows rig's RTX 5090

    +
    log

    08:26Z to 08:35Z, the fast-time harness on the fresh-record rule

    +
    log

    12:25 to 13:20Z, the finality route: why 26 fresh nodes lost the…

    12:25 to 13:20Z, the finality route: why 26 fresh nodes lost the seed every checkpoint

    +
    log

    Ember Tune: the two-knob efficiency tune, the fleet prior

    Ember Tune: the two-knob efficiency tune, the fleet prior, and what the three-card Windows rig could measure tonight

    +
    log

    The SP1 CPU prover on the three-card Windows rig beside the miners,…

    The SP1 CPU prover on the three-card Windows rig beside the miners, and the backend survey: no zkVM proves on AMD

    +
    log

    The 9070 XT on the eGPU

    The 9070 XT on the eGPU: why 17.9 MH/s, and what moved

    +
    log

    Ember Tune: the two-knob efficiency tune, the fleet prior

    Ember Tune: the two-knob efficiency tune, the fleet prior, and what the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) could measure tonight

    +
    log

    Read width of the lottery hash

    Read width of the lottery hash: 4, 16 and 64-byte loads, a per-load mix, a written scratch; three cards

    +
    log

    The hot table on the M5 Max

    The hot table on the M5 Max: a second table sized to GPU cache beside the 1 GiB dataset

    +
    log

    Mixer x4 and the cache growth rule

    Mixer x4 and the cache growth rule: the class v3 dataset construction, with the x8 candidate

    +
    log

    The SP1 CPU prover on the three-card Windows rig (RTX 5090, RTX…

    The SP1 CPU prover on the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) beside the miners, and the backend survey: no zkVM proves on AMD

    +
    log

    Proving v1: segment records, the chain rule

    Proving v1: segment records, the chain rule, the unproven rule; what was measured tonight

    +
    log

    Dp4a-class throughput on the M5 Max

    Dp4a-class throughput on the M5 Max: the dot4 emulation against the ALU chain

    +
    log

    Layer 3 scratch soundness

    +
    log

    Epoch length as an era parameter

    Epoch length as an era parameter : the Apple M5 Max's compile-ahead per program

    +
    log

    Aggregation cost on the RTX 5090

    Aggregation cost on the RTX 5090: what a per-block aggregation spends and what each lever gives

    +
    log

    The C4 fix: certificate-driven reorg

    +
    log

    EVM transaction relay

    EVM transaction relay: three nodes in a chain, every transaction sent to one end included by the other two miners

    +
    log

    The prover carries both fee tables and the height switch

    The prover carries both fee tables and the height switch: one pinned guest on either side of DAA 210,000

    +
    log

    FUD ledger sweep round 6

    +
    log

    Live devnet: real transactions, the first non-empty shard proven and…

    Live devnet: real transactions, the first non-empty shard proven and paid, and the exporter's block structure fixed

    +
    log

    The program id split

    The program id split: why the Apple M5 Max rejected the RTX 5090 Windows rig's proofs, and the verifier at 114 s

    +
    log

    Live devnet: the first shards proven, verified and paid

    +
    log

    One-click Windows workers

    One-click Windows workers: what the Apple M5 Max could measure

    +
    log

    First live finality lock: 77.4% of weight, 17 voters

    First finality lock on the live devnet: checkpoint 242 at 77.4% of all weight, two hours after genesis

    +
    log

    The gfx1036 worker fault and what the Apple M5 Max could and could…

    The gfx1036 worker fault and what the Apple M5 Max could and could not reproduce

    +
    log

    A node 60 s behind the clock is silently dead

    +
    log

    First machine on the one-click app: a 5090 at 118 MH/s

    First machine on the Igneum Miner app: the RTX 5090 Windows rig's RTX 5090 at 118 MH/s, via Setup.exe

    +
    log

    Difficulty rule v2

    Difficulty rule v2: the live oscillation, its cause, the DAG replay, the fix behind a height switch

    +
    log

    The observer stored nothing for 78 minutes, then 7,022 blocks in two…

    The observer stored nothing for 78 minutes, then 7,022 blocks in two minutes

    +
    log

    The RTX 5090 Windows rig at the 14

    The RTX 5090 Windows rig at the 14:20 boundary: a worker stuck on the previous epoch

    +
    log

    Shard layer on the RTX 5090: a full shard proven in 10.9 s, a block aggregated in 2.2 s

    Shard proving on the RTX 5090: a full shard compressed in 10.9 s, a two-shard block aggregated in 2.2 s, all verified

    + +

    Every entry is a dated heading of the engineering log, where the commands and the hardware are. The phases and their gates are the litepaper’s roadmap.

    + +
    +
    +
    + + + + + + + + \ No newline at end of file diff --git a/site/journey.json b/site/journey.json index 53f3b74a..9f39477e 100644 --- a/site/journey.json +++ b/site/journey.json @@ -28,10 +28,10 @@ { "id": "phase-4", "name": "Finality and job market", - "when": "Closes when the finality design passes external review and one rollup signs for the testnet", + "when": "Closes when the finality design passes external review", "status": "next", "line": "Sustained-mining finality, external proving jobs, miner client with auto-switching", - "gate": "Finality design passes external review and one rollup signs for testnet" + "gate": "Finality design passes external review" }, { "id": "phase-5", @@ -44,7 +44,7 @@ { "id": "phase-6", "name": "Mainnet fair launch", - "when": "After the testnet has passed its gate: 1,000 independent miners for 30 days and rollup proofs on time", + "when": "After the testnet has passed its gate (1,000 independent miners for 30 days, rollup proofs on time) and one proving customer has signed: a customer paying for proofs at a published rate, or a letter of intent with a volume", "status": "next", "line": "Genesis with no premine, 30-day ramp. No listing is arranged, promised or sought by the project" } diff --git a/site/ledger.html b/site/ledger.html index bf634875..0c2155ae 100644 --- a/site/ledger.html +++ b/site/ledger.html @@ -4,13 +4,13 @@ Igneum ledger: every criticism, answered - + - + @@ -18,7 +18,7 @@ - + @@ -29,6 +29,7 @@ + -
    -
    -
    Ledger · 183 entries · regenerated from the repository
    -

    Every criticism, answered or conceded

    -

    This is every criticism the project expects, in the critic's words, with what was done about it and the date. 183 entries since 3 October 2026. Entries are never deleted; a status that changes keeps its history on the line. Where the critic was right the entry says Conceded. Where nothing has been done it says Open and names what settles it. The founder mined through the GPU years. Ethereum's move to proof of stake in September 2022 ended that income and the miners' place in that chain. This is one person building, with AI systems doing the engineering, the coin he wanted to exist for miners: GPU-mined, the miners are the provers, no founder allocation, every cost stated. Help is welcome and a team is wanted: cryptographers, node engineers, miners who will test. This ledger is the application form: pick an open row and write to hello@igneum.network with its id.

    -
    -
    +
    +
    +
    + +
    Ledger · 184 entries · regenerated from the repository
    +

    Every criticism, answered
    or conceded.

    +

    This is every criticism the project expects, in the critic's words, with what was done about it and the date. 184 entries since 3 October 2026. Entries are never deleted; a status that changes keeps its history on the line. Where the critic was right the entry says Conceded. Where nothing has been done it says Open and names what settles it. The founder mined through the GPU years. Ethereum's move to proof of stake in September 2022 ended that income and the miners' place in that chain. This is one person building, with AI systems doing the engineering, the coin he wanted to exist for miners: GPU-mined, the miners are the provers, no founder allocation, every cost stated. Help is welcome and a team is wanted: cryptographers, node engineers, miners who will test. This ledger is the application form: pick an open row and write to hello@igneum.network with its id.

    +
    +
    +
    +
    - - + + - - + +
    CountStatusMeaning
    7Nothing has settled it yet. The entry names what will
    63The critic is right. "Stated" means the public text says so; "not yet stated" means it does not yet
    59A code, spec or text change answers it, with the commit or the page named
    61The critic is right. "Stated" means the public text says so; "not yet stated" means it does not yet
    58A code, spec or text change answers it, with the commit or the page named
    27A consensus rule or a decision by the owner answers it, dated
    13A measurement or a simulation exists and is named
    13A design rule answers it; no measurement is possible yet
    1A status outside the six above, read the line
    183Every entry. The sections: Mining and chips, Finality and attacks, Proving and the zkEVM, Economics and the coin, Governance and the founders, Comparisons, Legal and regulatory, Launch and operations, Builders
    5A status outside the six above, read the line
    184Every entry. The sections: Mining and chips, Finality and attacks, Proving and the zkEVM, Economics and the coin, Governance and the founders, Comparisons, Legal and regulatory, Launch and operations, Builders

    Mining and chips

    @@ -242,10 +251,10 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Conceded, stated 6 October 2026, evening; the Horizon lane analysis a repository file section 5.1, the FPGA lane): the public FPGA line carries only the measured row, 2.4 G reads/s per card and 0.30x to 0.39x of the RTX 5090 per watt (Shuhai, FCCM 2020 Fig 7; the tFAW arithmetic from ICCAD 2021 Table I), and the 11.4 G bank-bound row and the 12.2 G ceiling are marked unmeasured until an AWS F2 hour measures them. Stated in a repository file section 5.3 (the activate-bound row marked UNMEASURED with the JEDEC figure beside it, and the FPGA paragraph after the table). The epoch-length analysis's 12.2 row is not on master yet and is corrected when it lands.
    The answer as first written

    Correct. The measured 2.4 G/s had been read on 6 October as a mapping artefact ("the paper's point is that this mapping is the wrong one for random access"); the activate window says it is the DRAM's own limit, and a bank-interleaved mapping does not lift it because tFAW is enforced per channel by the die. The measurement that settles it is one AWS F2 hour (f2.6xlarge, Virtex UltraScale+ VU47P, 16 GB HBM2 in 2 stacks, 32 pseudo-channels, USD 1.98 an hour on demand): the chase kernel of a repository file 2.2 ported to a Vitis HLS AXI master over the HBM IP at 1 GiB across all 32 pseudo-channels, 256 to 4,096 lanes in flight, board power at 1 Hz; pass line 15 to 25 M reads/s/W (0.3x to 0.5x of the 5090), alarm 27 (0.5x), over 54 (1.0x) a Counter ASIC 4.0 item. Consequence per tier: none today (no FPGA mines); on the measured row a soft-overlay FPGA mines at an RX 9070 XT's rate per watt for about 7x the price (approximate), so no home or rig tier is displaced.

    -
    -
    M34

    The shadow size N is a constant of the binary, so the one lever against the dataset-storing chip needs a fork to move

    6 October 2026
    +
    +
    M34

    The shadow size N is a constant of the binary, so the one lever against the dataset-storing chip needs a fork to move

    7 October 2026
    Your own Horizon lane says the reserve and the era draw buy nothing against a chip that stores the dataset, and that the only lever is the latency-shadow size N. N is 27 passes of a 256-instruction block, hard-coded in V4_CLASS. So when HBM4 doubles a chip's rate per stack in 2028, your answer is a hard fork, and a fork that retires the M5 Max at the first doubling. And now there is a shipping RandomX ASIC.
    -
    Conceded, implemented 6 October 2026, night; a repository file, branch ladder, fork branch ladder-node, the 0.3.17 feature tree, behind latency_ladder_activation_daa, never until set, 0 on the testnet when the owner says): N is a genesis ladder of six rungs (27, 35, 53, 88, 173, 267 passes; about 102,100 to 1,001,600 counted ops) with a measured admissibility flag per rung (cold verify under 10 ms on the reference core with its SMT sibling loaded, igneum-build-1, 6 October 2026: rungs 0 to 2 pass at 8.77, 8.87 and 9.23 ms, rung 3 misses by 0.08 ms under a box load of 25 and is out until a quiet re-run, rungs 4 and 5 are out at 12.38 and 14.96), and the step is consensus state derived from two bits of the header version: up one rung when 90 percent of blue blocks in each of seven consecutive windows ask for it and the rung above is admissible, down one rung symmetrically, never two rungs inside seven windows (the oldest window must begin after the last step took effect), never unconditionally. Tests, the known-failed case first: a changed N today hashes another program under the same program id (a hard fork no pack line told apart); after, rung 0 is class v4 byte for byte, a rung above carries its pass count in the id, 8,999 bps in one window of seven does not move the step, a two-step jump is impossible, down never passes rung 0, an inadmissible rung is never entered. Stated in a repository file, Mining section ("The work that waits can grow").
    +
    Relabelled 7 October 2026, morning, X36): the X9 in this row and in the litepaper paragraph is the chip Bitmain announced and withdrew before launch, its core claimed and never measured; the ladder's arithmetic against that core is unchanged.
    The answer as first written

    Correct on both counts, and the second was the sharper one. The X9 (Bitmain, about 1 MH/s at 2,472 W, approximate, github.com/monero-project/monero/issues/10270) is a shipped 3x per-joule edge over a desktop CPU on the best-known latency-bound random-program design, seven years after launch; it makes the k = 0.3 column of the chip model a product class rather than an attacker's claim, and the public headline is now the range 2.1x (k = 1) to 3.9x (k = 0.33) over the RTX 5090 at class v4, with the ladder taking the X9 bracket to about 2.8x by rung 2 and the Apple tier's to about 1.1x by rung 3. The ladder does not close the gap; it is the chain's only automatic answer, it moves at the pace of the cards that pay for it, and the honest card's watts remain the lever that moves every row (algorithm lane proposal 7). What the ladder gives up by design: a chip holding over 10 percent of weight can stall it, and the status quo it stalls is a rung the cards already run.

    @@ -541,10 +550,10 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Answered by design
    The answer as first written

    Monero chose the CPU for egalitarian reasons and accepted botnets as the price. Igneum chooses the GPU because the thesis is paid proving, which CPUs cannot do, and refuses a CPU lane because of botnets. It is a different trade, and the litepaper should say "Monero's technique, applied to GPUs" rather than "finished".

    -
    +
    C2

    vs Monero: "no chip in seven years" is not proof

    7 October 2026
    Absence of a public RandomX ASIC is not evidence one cannot exist. Monero is also a small prize.
    -
    Conceded, stated 7 October 2026, morning): the one-screen home page is back on the owner's word, so this row is stated on a repository file only; the sentence there is unchanged and the text check lists it under the litepaper.
    +
    Reopened as conceded 7 October 2026, morning, X36): the X9 never shipped, so Monero's record is again seven years without a shipped chip, and the concession stands as first written; the litepaper says so in the same sentences.
    The answer as first written

    True. "No chip publicly shipped, approximate" is the defensible phrasing. The argument from Monero is precedent, not proof, and the bounty exists because precedent is not proof.

    @@ -644,7 +653,7 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Answered by design
    The answer as first written

    At launch jobs are paid on the customer's chain, in the customer's asset, by the customer's contract, to the prover's address; Igneum operates no custody and takes no cut off-chain. When the market settles on Igneum the fee split is consensus, not a company. Counsel confirms before phase 4.

    -

    Launch and operations

    +

    Launch and operations

    X1

    "Reproducible from the repository" and the repository is private

    5 October 2026
    Your site links to github.com/igneum-network/igneum. It 404s. 'Every number above is measured, published, and reproducible from the repository' is false today.
    @@ -868,7 +877,7 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Rule written 5 October 2026): spec 8.3 item 2; the control is unbuilt in the app. Was: Open, minor. Sweep (5 October 2026): the app carries no signalling control today (grep -i signal a repository file: none), so nothing is signalled on first run; the rule binds when the control is built.
    The answer as first written

    Correct. Fix: first run signals nothing until the user chooses, shown in the interface.

    -

    Launch and operations

    +

    Launch and operations

    X12

    Tonight's numbers are quoted before they are logged, and the worker efficiency gap is unexplained

    5 October 2026
    The 50x step, the trough near 9 million, 5.5 blocks a second and two-thirds efficiency over eight processes are in the brief and not in the bench-log. And the chain saw 70 to 83 MH/s from a card that benches 229, which is a third, not two thirds.
    @@ -946,7 +955,7 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Decided 4 October 2026, 08:20 UTC): the specification subset is public as igneum-network/spec (a repository file), labelled; the node fork, the proving code and the harnesses stay private until the benchmark. Was: Open, decision for the owner.
    The answer as first written

    The fact is conceded in X1 (the repository is private and the site says reproducible) and the pre-publication steps are in a repository file section 5 (ledger out of the tree, the project rules file rewritten, history rewritten, licence). The reviewer asks for an earlier date than January 2027 and a narrower scope: the benchmark harnesses, the test vectors, the simulators and a repository file/, each labelled experimental, with the node fork following when the gate-2 work is in. the owner decides which components, under which licence, and when; section 5 runs first in any case. The reviewer's companion advice, one proof-request workflow and one reference application before any broader app set, is the same decision's scope: the genesis-app list (G4, O-5.4) is not a prerequisite for the benchmark or the testnet.

    -

    Launch and operations

    +

    Launch and operations

    X13

    One paying customer for a stated reason

    6 October 2026
    'One rollup signs for testnet' is a letter of intent with no money. A customer who pays once, pays again without a rebate, and then a second unrelated customer, is evidence. A signature is not.
    @@ -1060,7 +1069,7 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Conceded, contained by rule, reviewed 5 October 2026, night): a repository file. Next step: the three devnet checks of that review's section 6 (containment under a deliberately broken verifier; the version gate and the overlap; the callback boundary), on the phase 4 devnet once the precompile of design 6 exists (design 10.3 item 5). Was: Conceded, contained by rule, review scheduled. Sweep (5 October 2026): a review item (R12 with the cryptographer); nothing runnable.
    The answer as first written

    Correct. Design 6 says it in those words. The containment: a job output cannot mint IGN or touch system contracts (R12), jobs are gated behind the proof-system version with the three-month overlap and the 90% signal (design 5.6), and the emergency path for a live soundness bug is the version bump of spec 5.7. The rule for an app, the same one the customer brief gives rollups: anything that acts irreversibly on a job output keeps its own fallback. R12 is reviewed with the cryptographer before devnet v2.

    -

    Launch and operations

    +

    Launch and operations

    X23

    One shipped key is an administrator channel to the founder's PCs

    5 October 2026
    Your relay accepts either the URL token or the x-igneum-key header for everything, including queuing PowerShell that the PC agent runs as administrator. The key is the log intake key, a literal in six tracked files and inside every Windows and prover package you have handed out. And the zip with both relay secrets sits on the downloads host behind the dl token, which is in your git history and in every installed app. One token, four hops, no privilege boundary.
    @@ -1116,7 +1125,7 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Decided 6 October 2026, 17:25 UTC, by the owner; decisions item 8): the history rewrite runs the morning after the last of the close's branches merges, with every worktree removed first and both secrets rotated regardless. Was: Fixed on a branch, pending merge (5 October 2026, night), the tooling part: ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. Decision owner: the owner for the rewrite date (a repository file). Was: Open (4 October 2026); extends a repository file section 5.
    The answer as first written

    Correct, count-only. The key: a repository file, a repository file, a repository file, prove-shard.sh, a repository file, a repository file, commits 78df757 to 4c9810f. The token: a repository file, commit c47ff03. git check-ignore returns nothing for the ledger, fixes and review files. The CI identity grep covers the public export list, by design. Fix: both secrets join section 5 step 4's rewrite list (and are rotated regardless); TZ=UTC in the commit path now. Review ids R4.4.8, R4.5.3, R4.5.4.

    -

    Launch and operations

    +

    Launch and operations

    X18

    Two nodes with two override files connect, and only some mismatches fork

    5 October 2026
    Your handshake compares the network name and nothing else. A PoW or difficulty mismatch forks and bans; a finality mismatch is a WARN; rollout-v2.sh throws the finality block away when it writes the file; the app rewrites the packaged file on every start.
    @@ -1142,7 +1151,7 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Fixed rolled out 5 October 2026, 0.3.5: both harness libraries reached master with the fud-consensus merge 7abce72 of the 0.3.5 cut; the sweep of 5 October ran run.mjs s4 and s5 --fast-time, fud.mjs and tonight's c4.mjs through them, every node started). Was: Fixed in both harnesses (4 October 2026, night: a repository file kept the sentinels as BigInt through the merge since the v3 runner of the evening; a repository file got the same reviver on branch fud-memory, merged into fud-consensus); the stale timestamp criterion of scenario 2 is not touched. Was: Open (4 October 2026, red-team run). Tooling, low severity: no consensus effect, but every fast-time attack run is blind until it is fixed.
    The answer as first written

    Correct, measured. The red-team run's first scenario errored on it (a repository file, "Tooling defect"); a repository file already edits the file as text for this reason. Scenario 2 live probe: past floor pmt+1, future flip between +130.00 and +130.01 s of the probe's own offsets, every stamp from +10 s rejected; the node is right, the criterion is stale. Smallest fix: in a repository file and a repository file overrideParams, drop the two sentinel fields before stringify (absent means never) or splice the extra fields into the file text; in a repository file, probe max(pmt + 1, parent - 10 s) and the +10 s bound. Also stale: a repository file waits for an over-budget transaction to be included and skipped with BlockProvingBudget; since F-exec-B the mempool refuses it with the metered pgas, so the check should accept ProvingGasAboveBlockLimit from the pool (a repository file row 28). And a repository file scenario 5 compares the burster's share of the weight window with its share of the whole run, which only agree when the run is shorter than the window (row 17).

    -

    Launch and operations

    +

    Launch and operations

    X19

    Operational knobs and silences in the shipped node

    5 October 2026
    A slow-clock node disconnects every peer on every relayed block and never says why; the handshake's time_offset is computed and unused; IGNEUM_ATTACK_TS_OFFSET_MS and IGNEUM_POW_STRIKES are compiled into the live binary; timestamp_deviation_tolerance is dead and still accepted.
    @@ -1180,7 +1189,7 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (miner; 3d4ec451 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3) and branch ledger-fork (workers), suites the Windows machine jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Apple M5 Max), both on 815c7d64; the tip is fbb0082a. Was: Open, minor (4 October 2026). The writer is the local miner and the directory is the user's own, so no privilege boundary is crossed. Sweep (5 October 2026): no kernel hash in program.json on any branch (git grep -i 'kernel_hash|program_hash' on miner-reliability finds nothing); the tampered-pack test needs a GPU worker. Fix row in section 2.5.
    The answer as first written

    Correct. packfile.h:~262-283, 306-345; worker.cpp:414-416, 596-620; emu/test.sh:57-66. The CPU re-check (main.rs:1250-1256) stops a wrong program from earning, not from running. Fix: a hash of the emitted kernel in program.json, derived from the seed by the miner and checked by both workers; one sentence in the docs that the chain commits to the seed, not the text. Review id R4.2.4.

    -

    Launch and operations

    +

    Launch and operations

    X21

    A wrong program burns power with a green rate

    5 October 2026
    The CPU re-check counts mismatches and does nothing: no threshold, no stop. The app reads hash, now, template_age and synced from STATUS and nothing else, so mismatched= and WORKER FAULT never reach the card.
    @@ -1239,7 +1248,7 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Answered by design and with evidence 4 October 2026, evening; the owner's decision of that evening, branch dev-fee in both repositories).
    The answer as first written

    The fee exists and is disclosed; the rest is wrong in three places. (1) It is software-level, not protocol-level: no consensus rule, coinbase rule or emission rule knows of it. The chain pays whatever payout address a block template names, and the miner software names the dev address for one template in 100. A different client, or the same client with --dev-fee 0 (a switch in the app's Settings, DEV_FEE=0 on HiveOS), pays nothing and the chain treats its blocks exactly the same. That is the norm for GPU miners (lolMiner, T-Rex, approximate as to their percentages) and the litepaper says so beside the words "the protocol carries no fee". (2) It is auditable, not hidden: the choice is a template counter, not a random draw. Template n (from 0) is a fee template when floor((n + 1) p / 100) > floor(n p / 100), which at p = 1 is exactly the templates 99, 199, 299, ...; the source is one function (fee_slot, a repository file, section "Software dev fee"), the miner prints dev fee 1% (1 block in 100) to 0x<address>; --dev-fee 0 turns it off at start, logs dev-fee block <hash> for each one and counts fee=N in its status line, and igneum-miner payouts <node> reads the chain back and lists blocks per payout address with the dev address tagged. (3) It takes nothing from anyone else's security: a fee block keeps the user's vote key, so the user's finality weight is unchanged; only the execution-layer payout of that block moves.

    -

    Launch and operations

    +

    Launch and operations

    X29

    Host and file hygiene, minor

    6 October 2026
    The Mac's live node binds its gRPC to every interface. Four secrets or pointers in a config file are world-readable, one token is a filename, and the intake key rides on curl's command line. The manifest answers CORS * and the clock source is a cacheable page's Date header.
    @@ -1270,18 +1279,24 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
    Fixed, stated 6 October 2026, night, the owner's ruling): both sentences read "The public benchmark with a leaderboard ships with the public testnet." (a repository file, For miners and Questions miners ask). The gate is one the reader already knows from the roadmap's phase 5. The 5 October answers in M1, X1 and the overclaims list that name January 2027 are the history of the plan and stay as written.
    The answer as first written

    The month was the plan of 3 October 2026. The benchmark tool is part of the testnet's go checklist, so it ships with the testnet; no month is given for either.

    -
    +
    X34

    RandomX described as chip-free

    7 October 2026
    The home page said the random program 'has kept chips off Monero since 2019', the litepaper said Monero ran on RandomX 'with no chip publicly shipped' and spoke of 'Monero's seven years without a public chip'. Bitmain's Antminer X9, a RandomX chip, ships from July 2026 (1 MH/s at 2,472 W, about USD 5,600; monero-project/monero issue 10270), and RandomX 2.0 shipped on 25 March 2026. Every sentence that said or implied RandomX is chip-free, or that Monero's approach has held, was wrong.
    -
    Fixed, stated 7 October 2026, morning): the one-screen home page carries no RandomX sentence, so the corrected wording stands on a repository file (four sentences and the table row); the text check lists them there.
    +
    Corrected 7 October 2026, morning, X36): the X9 never shipped. Bitmain opened pre-orders on 26 December 2025 and withdrew the product in mid-May 2026 before any unit was delivered; every sentence below that had it shipping now states that, and RandomX stands as a technique no chip has yet shipped against. The sentences in this row are the history.
    The answer as first written

    The precedent Igneum cites is now a complete one: a fixed random program held CPU mining for about seven years and then a chip shipped. Igneum's program changes every hour from a genesis-fixed schedule, its dataset grows, and the chip model on the numbers page prices the chip that stores the dataset rather than assuming none can be built. The X9's rate and power are Bitmain's published figures, not our measurement.

    -
    +
    X35

    The class v4 chip headline stated as one number, 2.1x

    7 October 2026
    The home page said the strongest chip reaches 'about 2x once the lever now in its gates ships' and the litepaper said the latency-shadow work 'brings the chip to about 2x' and that its edge 'falls from 5.6x to 2.1x ... at a chip core equal to the GPU's'. That 2.1x assumes the chip's core costs what the GPU's does per operation (k = 1). Bitmain's Antminer X9 reached about a third of its honest device's energy on a latency-bound random program, so k about 0.33 is a shipped product class, and at that k the same model gives 3.9x.
    -
    Fixed, stated 7 October 2026, 00:0x UK, from the ladder lane's recalibration against the X9): every public sentence that stated 2.1x alone now states the range with k named. The 5.7x class v3 memory-only figure has no core work in it and is unmoved; the litepaper's 5.6x is the Counter ASIC 3.0 item 8 figure and stays as cited.
    +
    Kept, relabelled 7 October 2026, morning, X36): the range stands, with k about 0.33 labelled as the X9's claimed, unmeasured core, since no unit shipped or was benchmarked.
    The answer as first written

    One number was the model's k = 1 column; the X9 made the k = 0.33 column a product rather than a claim, so the public figure is the range. Rung 2 of the ladder (the top admissible rung on 6 October 2026) takes the X9 bracket from about 3.9x to about 2.8x and does not close it; the ladder moves at the pace of the cards that pay for it (M34).

    +
    +
    X36

    The X9 described as a shipping chip

    7 October 2026
    +
    X34 and X35 said Bitmain's Antminer X9 'ships from July 2026' and called it 'the shipping RandomX chip'. It never shipped: Bitmain opened pre-orders on 26 December 2025 for July 2026 delivery, resellers told buyers in mid-May 2026 that Bitmain had discontinued it and refunded them, no unit was delivered and none was independently benchmarked.
    +
    Fixed, stated 7 October 2026, morning, from the research agent's primary sources): every public sentence that had the X9 shipping now states the pre-order, the withdrawal and the unbenchmarked core.
    +
    The answer as first written

    The k about 0.33 column stays in the public range as the X9's claimed, unmeasured core: Bitmain's figures (1,000 KH/s at 2,472 W, 2.47 J/KH) were a pre-order sheet, never a benchmark, and the RandomX team's own reading (sech1, 25 January 2026) was "no, X9 is not an ASIC... Only 2x efficiency gap (hash/Joule) is not 'cracked'": a box of commodity Sophgo SG2044 server SoCs with an AES block and over sixty DRAM sticks, no tapeout, about 2x per joule over a tuned Zen 4 part and about 3x over a stock desktop CPU. It was withdrawn rather than face a RandomX re-tune of 1.5x or more. The lesson the public text now carries is that one: a maintained algorithm with a credible upgrade path held, which is what the latency ladder is for Igneum. Monero's hashrate shows no X9 fleet (about 6.1 GH/s before and after, approximate).

    +

    Proving and the zkEVM

    P23

    An unwound transaction leaves the node's view until its sender resends it

    6 October 2026
    @@ -1291,63 +1306,71 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co

    Source: the project's criticism ledger, a file in the repository, rendered to this page at build time; the repository is published at the public testnet. A criticism that is not here, or that shows an entry is wrong, is added with credit if wanted: hello@igneum.network or an issue on the specification repository.

    +

    - diff --git a/site/litepaper.html b/site/litepaper.html index bebdee43..c668b982 100644 --- a/site/litepaper.html +++ b/site/litepaper.html @@ -32,6 +32,7 @@ + - + -
    -
    -
    live devnet
    -

    Live devnet

    -

    A node is read every two seconds. Every block below is real: its parents, its miner, whether it sits on the selected chain, and whether it is a locked checkpoint. A checkpoint locks when the finality rule's quorum signs it. Once the proving layer is activated, every chain block's shards show as they are planned, proven and paid.

    -

    Fees: from DAA score 210,000 (the chain's block-time clock, about one step a second) the adopted fee table applies: 300 proving gas per transaction, 30,000-gas shards, floors of 100 gwei per gas and 10,000 gwei per proving gas. Before it the devnet metered with its prototype table, and the provers' program carries both.

    +
    +
    +
    + +
    Network observatory
    +

    The work becomes
    the chain.

    +

    Every block has a story. Follow the connections, and find your own.

    +
    +
    + +
    connecting to the observer
    +
    +
    + +
    +
    Blocks / second ↗
    pending
    counted over the node’s last 60 s; the target is 1
    +
    Blue score #
    pending
    the newest block’s count of blue ancestors
    +
    Network hash rate ∿
    pending
    the node’s estimate from the last 1,000 blocks’ difficulty
    +
    Active vote keys ◇
    pending
    keys with a block in 10 min; a card runs several
    +
    Connected peers ⇄
    pending
    peers of the observer’s node
    +
    Locked checkpoint ●
    pending
    signed by two thirds of all 30-day weight
    -
    -
    Status
    OFFLINE
    no observer update yet
    -
    Network
    igneum-devnet
    node
    -
    Blocks / s
    0.00
    over 60 s
    -
    Blue score
    0
    0 blocks
    -
    Difficulty
    0
    target per block
    -
    Hash rate
    0
    network estimate
    -
    Identities
    0
    vote keys active in 10 min; a card runs several
    -
    Peers
    0
    mempool 0
    -
    +
    +
    +
    Blocks in window
    0last 90 s
    waiting for the observer
    +
    Your blocks
    0in this window
    Key not set ·
    +
    Proven blocks
    0reading
    of the last 10 minutes, every shard verified or paid
    +
    Latest checkpoint
    None
    no checkpoint in the reply
    +
    +
    +
    The block graph
    + 0 blocks +
    + + + +
    +
    + keys + + + +
    +
    +
    +
    +
    connecting to the observer
    +
    +
    + Click to inspect  ·  Drag to explore + 60 s +
    +
    + +
    +
    +
    + Included + Excluded + Selected chain + Your block + Proven + Locked checkpoint +
    + blue score pending +
    +
    -
    -
    This tab · light client
    PREVIEW
    -

    Browser checks Igneum

    A checkpoint certificate, verified in this tab. Voter list from the node.

    -
    -
    Block proof
    not yet
    -
    Checkpoint
    checking
    -
    Proof system
    BLS aggregate, version 1
    -
    Verified in this tab
    checking
    +
    +

    Motion, with meaning.

    +
    +
    01

    A block arrives.

    A brief signal traces its real parent edges. Your blocks take a molten frame.

    +
    02

    The proof takes shape.

    Shard tiles follow the planned, proving, verified and paid states the observer reports.

    +
    03

    A checkpoint locks.

    A pending marker becomes a solid band only when the observer reports it locked.

    - -
    + -
    -
    -
    connecting to the devnet observer
    -
    on screen 0chain 0identities 0last lock pendingproven pending
    +
    +
    +

    Block activity

    header times / window
    +
    0blocks in this view
    +
    +
    one bar a minute, the last 30 minnow
    +

    Counted by the observer as blocks arrive.

    -
    -
    - pending - includedselected chain - excluded - proven - locked checkpoint - finality band, locked, with its weight - finality band, pending +
    +

    Mining identities

    displayed window
    +
    No blocks in the window.
    +

    Vote-key share of the displayed blocks. Several keys may belong to one GPU.

    -

    120 s of blocks on screen. One lane per miner, the busiest first; the rest share the last lane. Hover or tap a block for its hash, miner, blue score, parents and proof state. Ctrl or cmd and scroll, a pinch, or a click into the scene then scroll, changes the window; the page's ?window= fixes it.

    -
    - -
    -
    -

    Miners

    last 10 min
    -
    No blocks in the last 10 minutes.
    -

    Every vote key with a block in the last 10 minutes; a card runs several. The short id is the first 8 hex characters of the vote key hash in each header.

    -
    -
    -

    Events

    the last five
    -
    No events yet.
    -

    Checkpoint locks, miners going quiet and coming back, provers seen, as the observer records them.

    +
    +

    Event stream

    live
    +
    Waiting for the first read.
    -
    -

    Blocks per minute

    last hour
    - -

    Counted by the observer as blocks arrive.

    +
    +
    +

    Weight leaderboard

    30-day weight
    +
    + + +
    RankKeyBlocks in windowPresenceLast block
    Waiting for the first read.
    +

    Weight is blue blocks over the window, never hashrate: a card that arrived today sits at the bottom. The dust line and the window are read from the node.

    +
    +
    +

    Who is mining

    10 minutes
    +
    Waiting for the first read.
    +

    Counted from the observer’s reply. The card-by-card hardware census arrives with the app’s “Make my page public” switch; until then no card model is shown.

    +
    + +
    + Explore blocks as a table keyboard-accessible view +
    + + +
    Blue scoreHashVote keyParentsStateChain block
    Waiting for the first read.
    +
    + +
    Igneum / observatoryOne node read every 2 s. Nothing here is a replay.
    - + diff --git a/site/metamask.html b/site/metamask.html index 869506fc..2b8acf56 100644 --- a/site/metamask.html +++ b/site/metamask.html @@ -31,6 +31,7 @@ + - + +
    -
    -
    -
    -
    Igneum Ember · one click
    -

    Install. Start. The card mines and proves.

    -

    Ember finds your GPU, makes a wallet for you and runs the node, the miner and the prover as one app. Every card mines. Today's app, with the stock SP1 server: a 24 GB NVIDIA card proves the full shard and a 32 GB card mines and proves. Measured on 6 October 2026 on eleven rented cards with the patched server: every NVIDIA card from 8 GB proves, and 10 GB and up mine and prove (the log); ships when the packaging row lands. Four pages: Mine, Earnings, Prove, Settings. Every card is one row: its rate, its watts, pounds a day at your electricity price, a Tune button. Every hour it compiles the next program while the current one mines, so the card never stops.

    - -
    - WindowsmacOSLinuxHiveOSNVIDIA · AMD · Apple silicon +
    +
    + +
    +
    +
    Igneum Ember · one click
    +

    Install. Start. The card mines.

    +

    One click installs the node, the miner and the prover, and makes your wallet. Every card mines: NVIDIA, AMD and Apple silicon. A 24 GB NVIDIA card proves as well.

    +
    -
    -
    -
    Igneum Miner
    - The Mine page of Igneum Miner 0.3.14 on a three-card PC: the Stop mining button, 169 MH/s at 532 W, 84 blocks this run, and one row per card: an RTX 5090 at 122 MH/s, 222 W, 0.55 MH/W and 56 °C, an RTX 4070 at 28.7 MH/s and 76 W, an RX 9070 XT at 18.9 MH/s and 198 W, each with its tune line, Tune button and switch, and the integrated GPU off -
    Igneum Ember (the app window still says Igneum Miner) 0.3.14, Mine page, on a Windows rig with an RTX 5090, RTX 4070 and RX 9070 XT, live devnet, 6 Oct 2026, 18:16 UTC. No electricity price set, so the £ cells ask for one. The tune lines are stopped tunes from before that afternoon's Power Helper fix.
    +
    +
    + +
    +
    +
    +
    +
    Devnet buildDesktop, not browser mining
    +

    The miner built around your card.

    +

    Your rate, your watts, what it costs a day at your price, and the chain drawn live with your own blocks ringed. Every card is one row. Ember Tune finds each card’s best hashes per watt and keeps it there.

    + +

    The window on the right is the shipped app, photographed on a real rig. Nothing on this page is a mock-up.

    +
    +
    +
    Igneum Miner / live devnet
    + The Mine page of Igneum Miner 0.3.14 on a three-card rig: the Stop mining button, 169 MH/s at 532 W, 84 blocks this run, and one row per card: an RTX 5090 at 122 MH/s and 222 W, an RTX 4070 at 28.7 MH/s and 76 W, an RX 9070 XT at 18.9 MH/s, each with its tune line, Tune button and switch + The Overview page of 0.3.16 in light mode: an RTX 5090 at 103 MH/s and 317 W, 0.32 MH/W, 62 blocks this run, the chain drawn live with this rig's blocks ringed +
    The shipped app, mining on the three-card Windows rig: an RTX 5090, an RTX 4070 and an RX 9070 XT, live devnet, 6 October 2026.0.3.16, rendered from the RTX 5090 Windows rig’s live state at 23:33 UK, 6 October 2026.
    -
    + -
    -
    -
    -

    Hash, prove, get paid

    -

    One client. The card hashes the lottery, proves the shards the chain assigns to it, and every block pays one address.

    +
    +
    +
    +
    Downloads

    Get the miner.

    +

    Download only from this domain. Nobody from Igneum will ask for your seed. Every file is the one the app’s signed manifest names, with its version and size.

    -
    -
    - -
    01 · HASH
    The card hashes
    -

    A new random program every hour. 80% of each block to the card that finds it.

    +
    +
    +
    + + + +
    +
    +

    Ember for Windows

    the installer, from the signed manifest

    +

    Run the installer, press Start. NVIDIA and AMD cards both mine. Setting an NVIDIA power cap asks for administrator rights once.

    + Download for Windows v0.3.19 · 62.7 MB +
    from dl.igneum.networksha256 fb693e841bcd99dc580900b2d0b2560c8431fce29bc630561566fef08e9e0772
    +
    + +
    -
    - -
    02 · PROVE
    The same card proves
    -

    The client switches to the shards the chain assigns to its keys, posts the proof, and goes back to hashing.

    -
    -
    - -
    03 · GET PAID
    One address, in IGN
    -

    Block rewards and proving payouts land on the address the app made for you. The wallet shows them.

    +
    +
    +
    01

    Check your card.

    Any 4 GB card mines at launch. A 24 GB NVIDIA card proves the full shard as well; a 32 GB card mines and proves at once. What your card does here has the measured rates.

    +
    02

    Install the official build.

    Only from this domain. The app makes your wallet address on first start and shows you its seed phrase once. Keep it to yourself. This site never asks for it.

    +
    03

    Press Start, then tell us.

    Watch your blocks ring on the chain. Let Ember Tune pick each card’s point. When something breaks, say so on the Discord or by email.

    +
    +

    Your card: pending

    +
    Devnet, not an earnings opportunity.

    Devnet. Coins have no value and the chain may be reset.

    Public testnet: not yet open; the devnet build is here for people who want to look. The public testnet is weeks away: three seed nodes and the public RPC are up, and it opens when the go checklist closes.

    The protocol carries no fee. The one payment to the project is the Ember software’s optional 1% dev fee, like other GPU miners, off with one flag: the fee, in full view.

    +
    +

    Testnet coin for testing: the faucet sends 10 IGN per address per day. Any 4 GB card at launch. The dataset starts at 2 GB and grows on a schedule fixed at the testnet genesis (2 GB, doubling at years 4, 12 and 28), so a 4 GB card mines about four years and an 8 GB card about twelve, approximate.

    -
    -
    -
    -

    Four pages. Every card is one row.

    -

    Mine, Earnings, Prove, Settings, shipped in 0.3.14 on 6 October 2026. The screenshots are the live app: the Windows rig's three cards for Mine, Earnings and Settings; this team's Apple M5 Max, paused, for Prove, light and the phone width. Apple silicon reports no draw, so its row carries no watts and no pounds; an NVIDIA or AMD card's row does.

    +
    +
    +
    +
    Your card

    What your card does here.

    +

    Measured rates from the bench table, and how often each card finds a block at the network’s hash rate right now. One block a second is the target, so the wait is the network’s rate over yours.

    -
    - - - - - - - - - - +
    On the rowWhat it saysWhen it is not shown
    State wordmining, paused, tuning: step 7 of 9, waiting for the node, restarting in 4 s, off with the reason. A card never shows 0 MH/s without a word.Always shown.
    Rate122 MH/s, live.Blank with the state word when the card is not mining.
    Power290 W with 0.42 MH/W under it.A card that reports no draw: Apple silicon, an integrated GPU. The row says so once.
    Pounds a dayWatts × 24 ÷ 1,000 × your pence per kWh. The price is yours, set once in Settings."Set a price" until you set one; hidden with no draw.
    Temperature61 °C. Amber from 86 °C, ember from 92 °C.When the card reports none.
    Tune and the switchTune starts an Ember Tune on this card; Stop during a run. The switch turns the card on or off. Tune all queues every card, one at a time.Tune is hidden for a card with no control and no measurement.
    The tune line"Not tuned yet: starts after 2 min of steady mining", "Tuning: step 7 of 9 · about 4 min left", "Tuned 2 h ago · 1,854 MHz at 100% · next check Sunday", or "Measured 27 MH/s as it runs" where the system sets the clocks.No line for a card with no control and no measurement.
    Under the chevronThe power cap slider, identities, pin or unpin, memory temperature, clocks, device facts, the last tune's table.Closed by default.
    + + + + + + + +
    CardMeasuredWattsA block about everyMeasured on
    NVIDIA RTX 5090127.7 MH/s227 Wpending6 Oct 2026, Ember run 6, the three-card Windows rig
    NVIDIA RTX 407028.8 MH/s76 Wpending6 Oct 2026, Ember run 6, the three-card Windows rig
    Apple M5 Max26.7 MH/snot loggedpending4 Oct 2026, Metal, the first hourly swap
    AMD RX 9070 XT17.8 MH/snot loggedpending5 Oct 2026, OpenCL, on the eGPU
    NVIDIA RTX 4090not yet measuredsend yours: the app uploads its rows
    AMD RX 7900 XTXnot yet measuredsend yours: the app uploads its rows
    -

    Under the rows: the Tuning card (Efficiency, Balanced, Maximum, and about how many pounds a day at that goal), then the node as one line: synced, peers, blocks, read N s ago. Details opens the chain numbers in place.

    -
    -
    -
    -
    Earnings
    - The Earnings page on the Windows rig: pounds earned with the devnet reason, IGN from proofs, 64,778 blocks lifetime and 84 this run, 532 W of electricity waiting for a price, the dev fee switch, the rewards address with Copy, Change address and Show my key -
    Money first. £ earned reads 0.00 on devnet and says why; 532 W waits for a price. The dev fee switch lives here. Change address and Show my key ask in place, no dialogs.
    -
    -
    -
    -
    -
    Prove
    - The Prove page: the Prove on this machine switch, one sentence per card on what it can prove, one line of counts, and Details -
    One switch, one sentence per card, one line of counts: assigned, proven, paid, IGN. Details holds the verifier, the program id and the segments.
    -
    -
    -
    -
    -
    Settings
    - The Settings page on the Windows rig: Tuning with the goal at Balanced (about 560 W), Ember Tune and Power control on, Hill climb off, the electricity price, the last tune 6 h ago with the next check on 13 Oct; This machine with start at login, remote jobs running a signed job, the name and appearance -
    Plain rows, one sentence each: Tuning, This machine, one update card, Logs, Advanced. Ember Tune and Power control on; the electricity price every £ figure uses is set here.
    -
    -
    -
    -
    -
    -
    -
    Light
    - The Mine page in light mode -
    Light and dark follow the system. Settings lets you pick one.
    -
    -
    -
    -
    -
    390 px
    - The Mine page in a 390 pixel wide window: the big button, the totals, the card row stacked, a bottom tab bar with Mine, Earnings, Prove, Settings and Logs -
    Under 720 px the rail becomes a bottom tab bar.
    -
    -
    -
    +

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

    +

    Your card against the strongest chip we can price: an RTX 5090 at 136 MH/s on 350 W (measured 6 October 2026), the chip 5x to 9x per joule in the public model today, 2.1x to 3.9x under class v4 (modelled on measured watts), and under class v5 wrong on every item because the dataset is the chain’s own state (designed); the model and the measurements are public.

    -
    -
    -
    -

    Every feature, one line each

    -

    What the app does today on the live devnet, and what is built but not yet measured on a card. Each number links to its engineering log entry.

    +
    +
    +
    +
    The ladder

    Seven rungs. Every one is a fact on the chain.

    +

    The app lights a rung the moment the chain does. Every threshold is read from the node, never a constant: the devnet reads 5 blocks to a vote and 2 of 2 hours of presence; mainnet reads 100 blocks and 8 of 8.

    - -
    -
    01 · One click

    Install, press Start

    Five steps from download to the first block on a friend's laptop: drag to Applications, open, Get started, Make me an address, Start mining.

    -
    -
    The card mines; an NVIDIA card proves

    One button starts the node, waits for sync, starts one miner per card and, on an NVIDIA card, the prover. Today's app, with the stock SP1 server: a 24 GB card proves the full shard (RTX 4090 5.6 s, RTX A5000 6.4 s) and a 32 GB card mines and proves (RTX 5090, 8.4 s); the stock server refuses 16 GB and under. Measured on 6 October 2026 on eleven rented cards, RTX 3060 to RTX 5090, with the patched server: every NVIDIA card from 8 GB proves, and 10 GB and up mine and prove; ships when the packaging row lands. AMD and Apple cards mine; a prover for them lands when a zkVM ships one. Quit stops them in order.

    log · 6 Oct 2026, prover tiers on real cards (docs/analysis/prover-tiers-real-cards.md)
    -
    Finds your GPU by itself

    NVIDIA through the driver, AMD and Intel through OpenCL, Apple silicon through Metal. Real card names, one worker per card.

    -
    A wallet made for you

    A payout key made on your machine and locked to your user, with a backup step before mining starts. Or paste an address you already hold.

    -
    Earnings, money first

    Every block this machine finds pays one address in IGN. The Earnings page counts blocks this run and for life, IGN from proofs, and the electricity cost at your price. £ earned stays 0.00 on devnet and says why; a market price fills it in when one exists (coming). The wallet shows the balance.

    -
    Windows, macOS, Linux

    An installer on Windows, a disk image on macOS, a package on Linux. No toolchain, no driver work: the GPU workers are prebuilt.

    -
    HiveOS package

    A custom miner for farms: the Linux miner, node and both GPU workers with the four Hive hooks. Hive itself is untested: report what breaks.

    -
    First outside machine

    An Apple silicon laptop, no instructions beyond the five steps: 33 accepted blocks in 7 minutes, 0 rejected, 21.0 MH/s average.

    log · 4 Oct 2026
    -
    First card on the app

    An RTX 5090 on Windows from the installer: 117 to 119 MH/s, 34 accepted blocks in the first minute, CPU re-check OK on every share.

    log · 4 Oct 2026
    -
    -
    - -
    -
    02 · One client

    Hashing and proving, switched by the client

    The lottery and the proving are kept apart on purpose. The client runs both and the miner sees one balance.

    -
    -
    Hashing and proving in one client

    Proving is a switch. On, the client proves the shards the chain assigns to this machine's keys, submits the record to its own node and goes back to hashing. The Prove page shows one sentence per card on what it can prove and one line of counts: assigned, proven, paid, IGN.

    -
    Several identities per card

    Identities take turns on the card and each one votes and pays separately. 8 suits a big card, 2 a small one, 1 an integrated GPU.

    -
    Hourly program, no pause

    The node announces the next seed early. The worker compiles the next program in the background and swaps at the boundary while the current one mines.

    log · 4 Oct 2026
    -
    - The first live swap, 4 Oct 2026, three vendors -
    - - - - - - -
    CardCompile, ahead of timeSwap at the boundaryRate before / afterRejected
    Apple M5 Max, Metal82 ms0.01 ms26.7 / 26.7 MH/s0
    RTX 5090, CUDA1,285 ms0.00 ms121.8 / 123.4 MH/s0
    AMD Radeon integrated, OpenCLpreparedno restart2.74 / 2.74 MH/s0
    - log · 4 Oct 2026, live devnet v4, epoch boundary at DAA 3,600 -
    -
    -
    - -
    -
    03 · Updates

    Signed, over the air, at a safe moment

    Every app updates itself. This is also how a consensus upgrade reaches every node before its activation height.

    -
    -
    Signed over the air

    The manifest is signed with an Ed25519 key compiled into the app. The app verifies the bytes before it reads them, then checks the download's size and hash.

    -
    Installed at a safe moment

    Node synced, no hourly boundary within 3 minutes, no worker starting. Machines take turns, each in its own minute of the hour, and never while the network lost over 30% of its identities in 10 minutes.

    -
    Mining continues through an update

    The download and the staging run while the card mines. The swap itself takes seconds. If the new version fails to start twice, the previous one comes back by itself.

    -
    Urgent when it has to be

    At once when a consensus activation is within 1,800 blocks or the version is below the minimum supported, or when you click Install now.

    -
    -
    - -
    -
    04 · Faster, by measurement

    The fleet tunes itself

    Nothing here changes the hash. Every variant is the same program in a different shape for the compiler, checked bit for bit before it is timed.

    -
    -
    Variant racing every hour

    At every hourly prepare the worker compiles the program in several shapes (unroll, load path, register budget, threads per group), times each for 2 seconds and keeps the fastest for the hour. Base keeps its place unless beaten.

    log · 4 Oct 2026
    -
    Measured on Apple silicon

    On the M5 Max, 256-thread groups ran 17.3% and 21.2% faster than base on two programs, under load from other work. The NVIDIA race is built and has not yet run on a GPU.

    log · 4 Oct 2026, ratios under contention
    -
    Fleet tuning manifest

    Every race is one record in the app log. The fleet's best variant per card model goes back out inside the signed update manifest, so a card starts from the known best and keeps racing.

    -
    Ember Tune

    Tunes every card for hashes per watt: once after install, then every 7 days, and after a driver or program change. The app steps the power limit and the core clock on the live kernel, 60 seconds a step, and keeps the point with the best MH per watt within 1% of the card's top rate. The memory clock is never touched; a step with a rejected hash, a hot GPU or a dragged memory clock is reverted and marked. Every result feeds a fleet prior per card model that the next card of that model starts from. One goal for all cards: Efficiency, Balanced or Maximum, with about how many pounds a day at that goal.

    log · 6 Oct 2026, Ember run 6
    -
    Power control: one approval, then no prompts

    Setting an NVIDIA power or clock limit needs administrator rights on Windows. The app asks once, when you turn Power control on, and registers a helper task; every cap after that is set through the task with no prompt. Off, NVIDIA cards are measured only. AMD cards are set through the app's own helper with no prompt at all.

    log · 6 Oct 2026, the task re-pointed and two caps set with no prompt
    -
    - Ember Tune measured on the Windows rig, 6 Oct 2026 -
    - - - - - -
    CardUntunedTunedSaved
    RTX 5090311.0 W
    127.9 MH/s
    0.411 MH/W
    226.8 W at 1,854 MHz, cap 100%
    127.71 MH/s (0.15% less)
    0.563 MH/W
    84 W
    £0.56 a day at 28p/kWh
    RTX 4070106.0 W
    28.72 MH/s
    0.271 MH/W
    75.6 W at 1,863 MHz, cap 50%
    28.78 MH/s (none lost)
    0.381 MH/W
    30 W
    £0.20 a day at 28p/kWh
    -

    The chosen clocks are the floor of the ladder, not the optimum: the next cut's ladder goes lower. The pounds are arithmetic from the saved watts at 28p per kWh; the app uses your price. The RX 9070 XT's run aborted at step 1 on a rule that asked a card reporting offsets for watts, fixed the same hour; its row is owed.

    - log · 6 Oct 2026, Ember run 6 on the Windows rig (0.3.13 + tuning kit 6, elevated, one click) -
    -
    Latency work

    A block built on a stale tip earns less. The miner is moving from polling to a template subscription and shorter jobs, so a new tip reaches the card in milliseconds. In progress, no number published yet.

    -
    Remote signed jobs, opt in

    Our own fleet only. A switch, "Allow remote jobs from Igneum (signed)", with the key's fingerprint beside it. Off aborts the running job and stops polling. Jobs run at most once each and only on the machines they name.

    -
    -
    - -
    -
    05 · Reliability

    Watchdog, restart, clock

    Measured against a worker that misbehaves on command: these are recoveries in seconds, not hash rates.

    -
    -
    Watchdog per card

    No status line for 90 seconds, or a hash rate of 0 for 60 seconds while synced: the miner is restarted once. If it recurs, that card is marked faulted with the reason and the other cards keep mining.

    log · 4 Oct 2026
    -
    Watchdog per node

    A node that answers nothing for 120 seconds is restarted by the app, with a growing delay when it repeats. Measured: silent node to mining again in 160.0 s.

    log · 4 Oct 2026
    -
    Restart in order

    Miners first, then the node, on quit and on update. What crashes comes back. A worker that restarts itself is left alone, so nothing is restarted twice.

    -
    Clock check

    A clock 60 seconds slow kept a node silently dead for 12 minutes. Now the app reads block times and an HTTPS Date header: over 5 seconds a warning, over 10 seconds Start is blocked and a Sync clock button appears.

    log · 4 Oct 2026
    -
    - Recoveries measured, 4 Oct 2026 -
    - - - - - - - -
    What the worker didWhat the app didBack to mining
    Reported 0 hashesRestarted the miner once after the 60 s rule91.0 s
    The same again inside five minutesMarked the card faulted, no further restart; Resume cleared it75.4 s to faulted
    The miner process stoppedKilled and restarted it after the 90 s rule101.4 s
    The node process stoppedRestarted the node, which synced; mining resumed160.0 s
    - log · 4 Oct 2026, a fake worker on a private test network, no real GPU -
    -
    -
    - -
    -
    06 · Published

    The log and the bench table

    Every number on this page has a row. Prototype numbers say so.

    -
    -
    Engineering log

    Every benchmark and test the project has made, with the hardware and the commands. Newest at the bottom.

    /bench
    -
    GPU bench table

    One row per card, generator version and miner version: best MH/s, MH per watt where measured, the date and the log entry behind each number.

    /miners
    -
    Your rows, from your machine

    The app uploads its status lines once a minute under a per-install id. Rows marked "reported by the fleet" come from machines we do not own.

    -
    -
    -
    -
    - -
    -
    -
    -

    Why Igneum Ember stays ahead

    -

    Six levers, set on 4 October 2026. Each one is an idea in one line and a measured state. Nothing here claims fastest: the bench table says that, or it does not.

    -
    -
    - +
    LeverThe ideaMeasured state
    + - - - - - - + + + + + + +
    RungWhat lights itThe line in the appDevnetMainnet
    1 · Race the compiler every hourFor each new program, five to ten kernel variants are compiled, benched for two seconds each, and the winner is kept for the hour.Measured on the Mac's Metal worker: the winning variant +17.3% on the genesis seed and +21.2% on the hourly seed over the base compile, under load from other work. The RTX 5090 race is prepared and not yet run. Log, 4 Oct 2026
    2 · Auto-tune that learns from the fleetApps report the race per card and program class, and every finished Ember Tune. The best settings come back down through the signed update manifest as defaults, so the miner gets faster and more efficient for everyone as the fleet grows.Shipped. The fleet is still small, so no fleet table yet; the priors table on /miners fills as machines report.
    3 · Hash per watt, not hashEmber Tune: two knobs per card (power limit, core clock), the memory clock held, the point with the best MH per watt within 1% of the top rate kept and pinned. Miners pay for electricity; that is the number they compare.Measured on the Windows rig, 6 Oct 2026: an RTX 5090 from 311.0 W to 226.8 W for 0.15% of its rate (0.411 to 0.563 MH/W); an RTX 4070 from 106.0 W to 75.6 W for none (0.271 to 0.381 MH/W). The chosen clocks are the ladder's floor, not the optimum. AMD through the app's own helper, no prompt; Apple silicon measures only. The table above.
    4 · Template latencySolo against the local node, a new template within 50 ms of a new tip, because a late block on a BlockDAG goes red and earns nothing.Shipped in 0.3.6 (the miner-latency merge; the app is at 0.3.14). Approximate, from the 0.3.6 release plan and not yet in the engineering log: switched p50 46 to 52 ms on a three-node CPU run, 5 Oct 2026.
    5 · Never lose a secondZero-loss hourly program swaps, fault guards, automatic restart, a CPU re-check of every found hash, per-worker health.Shipped. Swap 0.01 ms on Metal and 0.00 ms on CUDA with 0 rejected blocks; recoveries in the table above. Log, 4 Oct 2026
    6 · Prove it in publicThe bench table per card, fed from the job channel. We claim fastest only when the table says so.Live at /miners, one row per card, generator version and miner version, each with its log entry.
    1 · First blockYour key finds a block“Block 1,284,117 is yours.”1 block1 block
    2 · Your key has a voteYour blocks in the 30-day window pass the dust line“61 of 100 blocks to a vote.”5 blocks100 blocks
    3 · Your signature is in a checkpointYour key signs a checkpoint that locks“Your signature is in checkpoint 184,220.”1 lock1 lock
    4 · Full windowBlocks on every day of the weight window“30 of 30 days. Full weight.”2 of 2 hours30 of 30 days
    5 · Rank by weightYour key’s place in the table, by blue blocks over the window“Rank 41 of 1,204 keys.”by weightby weight
    6 · Signing streakEvery presence point signed, no gap over the presence window“Signing 8 of 80 points, 41 days unbroken.”2 of 28 of 8
    7 · Your card proved a shardA paid shard record carries your prover key“Your card proved shard 3 of block 1,284,117.”1 shard1 shard
    -

    The dev fee is the software's 1%, visible and switchable. The protocol carries no fee. The fee, in full view.

    +

    Weight, never hashrate: a card that arrived today sits at the bottom of the table and climbs one day at a time. The live table shows every key by weight.

    -
    -
    -
    -

    The fee, in full view

    -

    The protocol carries no fee: no dev fund, no fee to any team, foundation or fund. The software fee is the miner app's, like every other GPU miner's, and one flag turns it off.

    +
    +
    +
    +
    Hash, prove, get paid

    One client. Three jobs.

    -
    -
    -

    The Ember software takes a visible, switchable 1% dev fee, the norm for GPU miners. One block template in 100 is requested with the dev payout address instead of yours. The fee goes to Igneum Labs LTD, the company that ships the software. The choice is a template counter, never a random draw, so it is exactly 1 in 100 and anyone can audit it from the source or from the chain. A fee block still adds to your finality weight; the only thing that moves is who the execution layer pays for that one block.

    +
      +
    • 01 · The card hashesA new random program every hour, compiled on your machine. 80% of each block to the card that finds it.
    • +
    • 02 · The same card provesThe client switches to the shards the chain assigns to its keys, posts the proof, and goes back to hashing.
    • +
    • 03 · One address, in IGNBlock rewards and proving payouts land on the address the app made for you. The wallet shows them.
    • +
    +
    +
    + +
    +
    +
    +
    The dev fee

    The fee, in full view.

    +

    The protocol carries no fee: no dev fund, no fee to any team, foundation or fund. The software fee is the miner app’s, like every other GPU miner’s, and one flag turns it off.

    +
    +
    +
    +

    The Ember software takes a visible, switchable 1% dev fee, the norm for GPU miners. One block template in 100 is requested with the dev payout address instead of yours. The fee goes to Igneum Labs LTD, the company that ships the software.

    @@ -456,54 +288,68 @@ pre b{color:var(--molten);font-weight:500}
    WhereOff with
    HiveOS, extra configDEV_FEE=0
    -

    Measured on a test network, 4 Oct 2026: 9 fee blocks in the 785 blocks of two fee-paying miners (1.146%); the control miner at --dev-fee 0 paid none; the miners' counters and both nodes agree. The log entry.

    +

    Measured on a test network, 4 Oct 2026: 9 fee blocks in the 785 blocks of two fee-paying miners (1.146%); the control miner at --dev-fee 0 paid none; the miners’ counters and both nodes agree. The log.

    -
    -
    -
    Earnings, as the app shows it
    -
    Dev fee: 1 block in 100 pays the miner software's author
    -

    The miner software's fee, the same way every GPU miner takes one. The protocol takes none. This switch turns it off.

    -
    -
    -
    What the miner prints at start
    +
    +
    Earnings, as the app shows it
    +
    Dev fee: 1 block in 100 pays the people who make this app
    +

    The network itself takes nothing. This is the app’s fee, the same way every mining app takes one. This switch turns it off.

    +
    What the miner prints at start
    dev fee 1% (1 block in 100) to 0x<address>; --dev-fee 0 turns it off
    -
    dev fee off (--dev-fee 0); the default is 1% (1 block in 100) to 0x<address>
    -

    Each fee block is logged as it is accepted. igneum-miner payouts lists blocks per payout address over every block the node holds, with the dev address tagged.

    -
    -
    -
    -
    -

    Get the miner

    -

    Download only from this domain. Nobody from Igneum will ask for your seed. Every file below is the one the app's signed manifest names, with its version and size.

    -

    Public testnet: not yet open; the devnet build is here for people who want to look.

    -

    Devnet: coins have no value and the chain may be reset.

    +
    +
    +
    +
    The app

    Four pages. Every card is one row.

    +

    Your rate, what it costs a day, and the chain drawn live with your own blocks ringed. Every page of the app, light and dark.

    -
    - Windows v0.3.14 · 45.4 MB - macOS v0.3.14 · 41.9 MB - Linux v0.3.14 · 24.7 MB - HiveOS v0.3.14 · 24.7 MB +
    +
    +
    OverviewEarnings
    + The Overview page of 0.3.16: an RTX 5090 at 103 MH/s and 317 W, 0.32 MH/W, 62 blocks this run and 91,521 lifetime, the Stop mining button, the chain drawn live with this rig's blocks ringed and locked checkpoints, the node synced with 5 peers + The Earnings page of 0.3.16 in light mode: pounds earned with the devnet reason, IGN from proofs, blocks lifetime, the dev fee switch and the rewards address +
    0.3.16, rendered from the RTX 5090 Windows rig’s live state at 23:33 UK, 6 October 2026.0.3.16 on the team’s Apple M5 Max, paused, 6 October 2026. Pounds earned reads 0.00 on devnet and says why.
    +
    +
    +
    Cards
    + The Cards page: Ember Tune with Efficiency, Balanced and Maximum goals; one row per card with its rate, watts, hashes per watt, cost a day and temperature; the RTX 5090's details open with its power cap, goal, Retune and the tune curve + The Cards page of 0.3.16 in light mode: Ember Tune, the RTX 5090 at 103 MH/s, 322 to 317 W, 68 degrees, its tune line and Retune button; the integrated AMD graphics off +
    The Cards page, from the app in development.0.3.16, rendered from the RTX 5090 Windows rig’s live state at 23:33 UK, 6 October 2026.
    +
    +
    +
    Overview · Mac
    + The Overview page on an Apple M5 Max: 18.3 MH/s, 6,789 blocks this run, the chain drawn live with this Mac's blocks in the lane marked you, locked checkpoints at 71% of weight, the node synced with 4 peers + The Overview page in light mode: 511 MH/s from one of three cards mining, 629 W, £4.23 a day of electricity, 6,784 blocks this run, the chain drawn live with this rig's blocks marked you, the node line and the activity log +
    An Apple M5 Max mining at 18.3 MH/s, from the app in development.A three-card rig at 511 MH/s, from the app in development.
    +
    -
    -
    HiveOS · Flight Sheet
    -

    Install on a Hive rig

    -

    Miner: Custom. Installation URL: https://dl.igneum.network/dl/public/igneum-hive-0.3.14.tar.gz. Miner name igneum, wallet and worker 0x<your 40-hex payout address>.%WORKER_NAME%, pool URL grpc://<your node>:26610 or local for the bundled node, extra config DEV_FEE=1 IDENTITIES=8 WORKER=auto VOTE=1. The Linux button above is the same archive: the Linux miner, node and both GPU workers. Hive itself is untested so far. Report what breaks.

    -

    sha256 c4699f2487580dcf06b5c22a36a2eb8383a3307b6137699c76c45eefebdd4c88

    +
    +
    + +
    +
    +
    +
    Before you start

    The questions worth asking.

    +
    +
    +
    Does this website use my GPU to mine?

    No. The pictures on the home page are drawn, not mined. Mining happens only in the app you install, and only when you press Start.

    +
    Does my card mine and prove?

    Every card mines. Proving the full shard needs a 24 GB NVIDIA card; a 32 GB card does both at once. Apple silicon proves on the CPU, slowly. The Prove page of the app says in one sentence what your card can do.

    +
    Is the devnet paying real money?

    No. Devnet coins have no value and the chain may reset. The app’s pounds row reads 0.00 on devnet and says why. The public testnet opens when the go checklist closes; mainnet comes after the testnet passes its gate.

    +
    Is there a fee?

    Not in the protocol: no dev fund, no fee to any team. The app takes an optional 1% software fee, the norm for GPU miners, and one flag turns it off. The fee, in full view.

    +
    Can I run it on a rig or in a pool?

    The Linux and HiveOS tarball is above, with the flight sheet. Pools are part of the public testnet; until then every machine mines solo on its own keys, and a card runs several.

    +
    Where do the numbers on this page come from?

    Every rate has a row in the bench table and an entry in the engineering log with the command and the hardware. Nothing here is estimated earnings.

    -

    Testnet coin for testing: the faucet sends 10 IGN per address per day. Any 4 GB card at launch. The dataset starts at 2 GB and grows (the proposed schedule, fixed at the testnet genesis: 2 GB, doubling at years 4, 12 and 28), so a 4 GB card mines for about four years, approximate. Updates arrive signed; the app installs them itself. The wallet reads this machine's node when the miner is installed.

    - Read more in the litepaper
    -
    -
    +
    +

    Every number here has a row.

    The engineering log holds the commands and the hardware behind each one. The bench table compares cards, not miners, because there is no other Igneum miner yet.

    @@ -511,69 +357,84 @@ pre b{color:var(--molten);font-weight:500}
    +Download the minerv0.3.19 · 62.7 MB + - + + + diff --git a/site/miners.html b/site/miners.html index 624aee03..1d0c9705 100644 --- a/site/miners.html +++ b/site/miners.html @@ -31,6 +31,7 @@ + -
    -
    -
    6 measured rows, 0 fleet tuning models
    +
    +
    +
    + +
    6 measured rows, 0 fleet tuning models

    GPU bench table

    -

    Measured hash rates per card on the Igneum lottery hash, with the generator version, the miner version, the date and the log entry behind each number.

    +

    Measured hash rates per card on the Igneum lottery hash, with the generator version, the miner version, the date and the log entry behind each number.

    -
    +
    +
    +
    + +

    The table

    One row per card, generator version and miner version. The rate is the best one measured. Integrated GPUs are not listed. Prototype rows are bench numbers from before the devnet and say so in the miner column.

    CardGeneratorBest MH/sMH per wattMinerDateSourceWho measured it
    Apple M5 Max (40 GPU cores, Metal)v145.2not measuredproto-metal bench (prototype, not mining)2026-10-03bench log: 3 October 2026, RTX 5090 first run (the Apple row of the same table)measured by the team. genesis program, 1 GiB dataset
    Apple M5 Max (40 GPU cores, Metal)v226.7not measuredigneum-miner devnet v4, Metal worker with prepare2026-10-04bench log: 4 October 2026, first hourly program swap on the live devnet: compile-ahead, no pause, two cardsmeasured by the team. live devnet v4, unbroken through the hour boundary
    Apple silicon laptop (model not reported)v224.3not measuredIgneum Miner 0.3.1 (DMG)2026-10-04bench log: 4 October 2026, first outside machine on the devnet: an Apple silicon laptop through the Igneum Miner appreported by the fleet. 21.0 MH/s average over 7 minutes, 24.3 MH/s at the moment of the report, 33 accepted blocks
    NVIDIA RTX 5090 (32 GB)v1229not measuredproto-cuda bench (prototype, not mining)2026-10-03bench log: 3 October 2026, RTX 5090, memory-hard dataset (pack igneum-genesis-mh)measured by the team. genesis program, 104 loads per hash, 1 GiB dataset
    NVIDIA RTX 5090 (32 GB)v1185.3not measuredproto-cuda bench (prototype, not mining)2026-10-03bench log: 3 October 2026, RTX 5090 first run, dataset sweep and second programmeasured by the team. hourly program, 128 loads per hash, 1 GiB dataset
    NVIDIA RTX 5090 (32 GB)v2124.2not measuredIgneum Miner 0.3.0 package, prebuilt NVRTC worker2026-10-04bench log: 4 October 2026, the gfx1036 worker fault and what the Apple M5 Max could and could not reproducemeasured by the team. live devnet v4, 128 loads per hash, CPU re-check clean, 0 rejected
    -

    How a row gets here

    +
    +

    How a row gets here

    Every row names the engineering log entry or the job it came from. "Measured by the team" means our own hardware and our own log. "Reported by the fleet" means a machine we do not own, read from the status lines its miner uploads.

    MH per watt needs the card's power draw during the run. The app reads it on NVIDIA cards through the driver. Rows get the figure when a run records it.

    There is no other Igneum miner to compare with yet, so this table compares cards, not miners. The app that produces these rows: the miner page.

    Rows: 6. Each row names the engineering log entry it came from.

    -

    Fleet tuning priors

    +
    +

    Fleet tuning priors

    Ember Tune runs on every card the app mines with: the power limit and the core clock are stepped on the live program and the card keeps the point with the best MH per watt within 1% of its top rate. Every finished tune is reported back without anything that identifies the owner, and the fleet's median point per card model, driver major and program class comes back down inside the signed update manifest as the starting point for the next card of that model. A model needs 5 reports before its prior is used.

    No tune reports yet. The first rows appear once five machines with the same card model have reported.

    Measured by the team

    • NVIDIA GeForce RTX 5090 (driver 617, class l128w0, 2026-10-06, job ember-tune-pc1-6): 1854 MHz core cap, power limit 100% (575 W). 84 W saved for 0.15% of rate: 127.71 MH/s at 226.8 W (0.563 MH/W) against 127.9 MH/s at 311 W untuned (0.411 MH/W), 37% more hashes per watt. The chosen clock is the ladder's floor (60% of the maximum), not the optimum; the next cut's ladder goes to 45% and the climb walks on from here.
    • NVIDIA GeForce RTX 4070 (driver 617, class l128w0, 2026-10-06, job ember-tune-pc1-6): 1863 MHz core cap, power limit 50% (100 W). 30 W saved for no rate lost: 28.78 MH/s at 75.6 W (0.381 MH/W) against 28.72 MH/s at 106 W untuned (0.271 MH/W), 41% more hashes per watt. The chosen clock is the ladder's floor (60% of the maximum), not the optimum; the next cut's ladder goes to 45%.
    -

    Rows: 0. Written from the fleet's tune records at build time.

    +

    Rows: 0. Written from the fleet's tune records at build time.

    Generated from the repository at build time. Times are UTC. Machine names are model names.

    +
    - + \ No newline at end of file diff --git a/site/partials/footer.html b/site/partials/footer.html index 764ec848..f6415340 100644 --- a/site/partials/footer.html +++ b/site/partials/footer.html @@ -1,57 +1,64 @@ - \ No newline at end of file + diff --git a/site/partials/head.html b/site/partials/head.html index 5ccac943..b2a6a4aa 100644 --- a/site/partials/head.html +++ b/site/partials/head.html @@ -1,5 +1,6 @@ + \ No newline at end of file diff --git a/site/partials/nav.html b/site/partials/nav.html index 32399782..5b195f3a 100644 --- a/site/partials/nav.html +++ b/site/partials/nav.html @@ -1,43 +1,58 @@ diff --git a/site/proof-core.js b/site/proof-core.js new file mode 100644 index 00000000..4e788645 --- /dev/null +++ b/site/proof-core.js @@ -0,0 +1,72 @@ +/* Igneum proof detail. A data-driven companion, not a mining-progress estimate. + * One orbital tile per displayed shard (up to 12). No time-based status promotion. + * IgneumProof.mount(canvas).setBlock(observerBlock); destroy() on unmount. + */ +(function(root){ +'use strict'; +var mounted=new WeakMap(),TAU=Math.PI*2; +function mount(canvas,opts){ + opts=opts||{};if(mounted.has(canvas))mounted.get(canvas).destroy(); + var ctx=canvas.getContext('2d');if(!ctx)throw new Error('A 2D canvas context is required.'); + var W=0,H=0,dpr=1,block=null,raf=0,disposed=false,paused=false,inView=true,lastPaint=0,frames=0,force=true; + var mq=matchMedia('(prefers-reduced-motion: reduce)'),reduce=mq.matches,motion=true,col={},ro,io,mo; + var phase=0,lastT=0; + function alpha(c,a){if(/^#[a-f\d]{6}$/i.test(c))return 'rgba('+parseInt(c.slice(1,3),16)+','+parseInt(c.slice(3,5),16)+','+parseInt(c.slice(5,7),16)+','+a+')';return c;} + function theme(){var s=getComputedStyle(document.documentElement);function c(k,f){return s.getPropertyValue(k).trim()||f;}col={ember:c('--ember','#F2541B'),gold:c('--molten','#FFB35C'),bone:c('--bone','#F4F1EC'),ash:c('--ash','#9A9A9E'),line:c('--line','#2A2A30'),surface:c('--graphite','#16161A'),bg:c('--row','#111114')};kick();} + function size(){var nw=canvas.clientWidth,nh=canvas.clientHeight,nd=Math.min(devicePixelRatio||1,2);if(W===nw&&H===nh&&dpr===nd&&canvas.width===Math.round(nw*nd)){kick();return;}W=nw;H=nh;dpr=nd;canvas.width=W*dpr;canvas.height=H*dpr;ctx.setTransform(dpr,0,0,dpr,0,0);kick();} + function poly(points,fill,stroke){ctx.beginPath();points.forEach(function(p,i){if(i===0)ctx.moveTo(p[0],p[1]);else ctx.lineTo(p[0],p[1]);});ctx.closePath();if(fill){ctx.fillStyle=fill;ctx.fill();}if(stroke){ctx.strokeStyle=stroke;ctx.stroke();}} + function iso(x,y,w,h,depth,fill,stroke){ + poly([[x-w,y],[x,y+h],[x,y+h+depth],[x-w,y+depth]],alpha(fill,.17),alpha(stroke,.4)); + poly([[x,y+h],[x+w,y],[x+w,y+depth],[x,y+h+depth]],alpha(fill,.07),alpha(stroke,.32)); + poly([[x,y-h],[x+w,y],[x,y+h],[x-w,y]],col.bg,stroke); + poly([[x,y-h],[x+w,y],[x,y+h],[x-w,y]],alpha(fill,.15),null); + } + function line(a,b,c,w){ctx.strokeStyle=c;ctx.lineWidth=w||1;ctx.beginPath();ctx.moveTo(a[0],a[1]);ctx.lineTo(b[0],b[1]);ctx.stroke();} + function draw(t){ + if(!W||!H||disposed)return;frames++; + if(lastT&&!reduce&&motion&&!paused)phase+=Math.min(t-lastT,70)/1000;lastT=t; + ctx.setTransform(dpr,0,0,dpr,0,0);ctx.clearRect(0,0,W,H); + var x=W*.5,y=H*.49,scale=Math.min(W/320,H/240),cw=43*scale,ch=23*scale; + var shards=block?block.shards||[]:[],active=shards.some(function(s){return s.state==='proving';}); + var glow=ctx.createRadialGradient(x,y,0,x,y,W*.43);glow.addColorStop(0,alpha(col.ember,.10));glow.addColorStop(1,alpha(col.ember,0));ctx.fillStyle=glow;ctx.fillRect(0,0,W,H); + // A stationary coordinate grid, not fabricated hashrate or work counters. + for(var k=-3;k<=3;k++){line([x-130*scale,y+k*18*scale-46*scale],[x+130*scale,y+k*18*scale+46*scale],alpha(col.line,.45));line([x-130*scale,y+k*18*scale+46*scale],[x+130*scale,y+k*18*scale-46*scale],alpha(col.line,.45));} + ctx.strokeStyle=alpha(col.line,.7);ctx.lineWidth=1;ctx.setLineDash([2,6]);ctx.beginPath();ctx.ellipse(x,y+10*scale,106*scale,59*scale,0,0,TAU);ctx.stroke();ctx.setLineDash([]); + var count=Math.min(12,shards.length); + for(var i=0;i12){ctx.font='9px ui-monospace, monospace';ctx.textAlign='center';ctx.fillStyle=col.ash;ctx.fillText('+ '+(shards.length-12)+' more shards in the list',x,H-12);} + } + function continuous(){return !disposed&&!document.hidden&&inView&&!reduce&&motion&&!paused&&block&&(block.shards||[]).some(function(s){return s.state==='proving';});} + function frame(t){raf=0;if(disposed||document.hidden||!inView)return;if(force||t-lastPaint>=1000/30){draw(t);lastPaint=t;force=false;}if(continuous())raf=requestAnimationFrame(frame);} + function kick(){force=true;if(!disposed&&!document.hidden&&inView&&!raf)raf=requestAnimationFrame(frame);} + function stop(){if(raf)cancelAnimationFrame(raf);raf=0;lastT=0;} + function visibility(){if(document.hidden)stop();else kick();} + function reduction(e){reduce=e.matches;stop();kick();} + var api={setBlock:function(b){block=b?{hash:b.hash,proven:b.proven===true,locked:b.locked===true,shards:(b.shards||[]).map(function(s){return {state:s.state};})}:null;canvas.setAttribute('aria-label',block?'Block proof detail: '+block.shards.map(function(s,i){return 'shard '+(i+1)+' '+s.state;}).join(', '):'Select a block to inspect its proof shards');kick();},setPaused:function(value){paused=!!value;stop();kick();},setMotion:function(value){motion=!!value;stop();kick();},getStats:function(){return {frames:frames,reducedMotion:reduce||!motion};},destroy:function(){if(disposed)return;disposed=true;stop();ro.disconnect();if(io)io.disconnect();mo.disconnect();root.removeEventListener('resize',size);document.removeEventListener('visibilitychange',visibility);mq.removeEventListener('change',reduction);mounted.delete(canvas);}}; + ro=new ResizeObserver(size);ro.observe(canvas);if('IntersectionObserver'in root){io=new IntersectionObserver(function(es){inView=es[0].isIntersecting;if(inView)kick();else stop();});io.observe(canvas);}mo=new MutationObserver(theme);mo.observe(document.documentElement,{attributes:true,attributeFilter:['data-theme','style','class']}); + root.addEventListener('resize',size);document.addEventListener('visibilitychange',visibility);mq.addEventListener('change',reduction);mounted.set(canvas,api);theme();size();return api; +} +root.IgneumProof={mount:mount,version:'2.0.0'}; +})(window); diff --git a/site/provenance.html b/site/provenance.html new file mode 100644 index 00000000..500f792b --- /dev/null +++ b/site/provenance.html @@ -0,0 +1,239 @@ + + + + + +Igneum provenance: built on the shoulders + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    +
    + +
    Provenance · the decision of 3 October 2026
    +

    Built on the shoulders

    +

    Igneum credits every borrowed component in public, replaces only what its own design requires, and measures every change. This table is the record: the origin and licence, what changed, why, and the measurement behind it.

    +
    +
    +
    + +
    + +

    Igneum provenance: what is borrowed, what changed, how it is measured

    +

    Decision of 3 October 2026. Igneum credits every borrowed component in public, replaces only what its own design requires, and measures every change. This table is the public record of that decision. It is kept current with docs/fork-divergence.md (the node fork, change by change) and docs/bench-log.md (every measurement with its command).

    +

    How to read the licence column. "Verified" means the LICENSE file or the crate's Cargo.toml was read in this repository on 3 October 2026. "Approximate" means the licence is stated from memory because the source is not cloned under vendor/ yet; it is checked again when the clone lands, and before the repository goes public.

    +
    +

    The table

    +
    ComponentOrigin (project, licence, repository)What Igneum changedWhy the design needs the changeHow the change is measured
    GHOSTDAG orderingKaspa, rusty-kaspa. ISC, verified (vendor/rusty-kaspa/LICENSE, "Copyright (c) 2022-2024 Kaspa developers"; workspace license = "ISC"). https://github.com/kaspanet/rusty-kaspaUnchanged algorithm. Parameters set for 1 block per second: k 18, 10 max parents, mergeset limit 180, merge depth 3,600 blocks (consensus/core/src/config/bps.rs, params.rs)Launch rate is 1 block a second (the design document), rising later. These are the values Kaspa mainnet ran before Crescendo, so nothing new is asserted about the orderingSpec section 2.1; bench-log "igneum-node devnet v0: 3-node igneum-devnet at 1 BPS"; a test in params.rs pins every value
    Node software (the fork)rusty-kaspa v2.1.0, commit 01b532e8 (22 Sep 2026). ISC, verified. Fork at vendor/igneum-node, one commit per change on top of the baseHeader gains vote_key_hash; genesis blocks; network ids igneum-*; devnet ports; DNS seeders emptied; address prefixes; emission schedule and 80/20 coinbase; PoW engine trait; PoW check moved after GHOSTDAG; rename of every user-visible string to igneumd. Full list: docs/fork-divergence.mdEach row there states the reason. The short version: finality rule v2 needs a vote key in every header, the emission is Igneum's own, the lottery hash needs chain state, and no Igneum node may ever dial a Kaspa peerdocs/fork-divergence.md (file, change, why, risk, merge note per row); bench-log devnet v0 and "first devnet blocks on the real lottery hash" entries; the four-node rename test of 3 Oct 2026
    Difficulty controllerKaspa sampled DAA (KIP-4) in rusty-kaspa, ISC, verified, kept as the retarget. Prior art studied: LWMA by Zawy (zawy12/difficulty-algorithms, licence approximate: MIT) and Monero's sorted and trimmed window (monero-project/monero, approximate: BSD-3-Clause). No code from eitherUnchanged in the fork today (comment block only, consensus/core/src/config/constants.rs). The hash speed steps at every hourly program change, so a rule that tracks a step within an epoch is in progress: a two-speed rule (fast response to a step, slow drift otherwise). Not in spec 0.1Programs differ in cost (35 to 48 Mhash/s across seeds on one GPU), so a 44-minute window spends half an epoch at the wrong block rateSpec section 2.3 names the two remedies and the gate 2 simpa run that decides; bench-log first-run and RTX 5090 entries hold the per-seed rates. The two-speed rule gets its own bench-log entry when it is simulated
    Random-program ideaRandomX by tevador, Monero. Licence approximate: BSD-3-Clause. https://github.com/tevador/RandomX (not yet cloned under vendor/; the design document asks for it)The idea only. Igneum's generator is new code (igneum-pow/src/generator.rs): a program drawn once per hourly epoch and compiled to native GPU code, with a per-hash random data path. RandomX draws a program per hash and interprets it on a CPUA GPU cannot interpret a fresh program per hash at a useful rate; it compiles one program per hour instead. The target hardware is the opposite of RandomX's by designSpec section 1 (generator, test vectors); bench-log "proto-metal first run", "RTX 5090 first run", "igneum-pow bit-exact" (96/96 vectors, three GPU vendors)
    Memory-hard datasetRandomX cache lineage (tevador, BSD-3-Clause approximate): a small cache that derives a large dataset by dependent readsNew construction, same shape: 256 MiB cache of chained ChaCha12 blocks, 8 dependent reads per item, dataset 1 GiB in the prototype and 2 GB at genesis, growing on a genesis-fixed schedule (igneum-pow/src/memhard.rs, proto-metal/MEMHARD.md)A light verifier must hold only the cache; a miner must hold the dataset; the dataset must outgrow any fixed chip memory. RandomX's dataset has one size for everproto-metal/MEMHARD.md section 2.2 (recompute 4.8x slower than load, Apple only); bench-log "memory-hard dataset" entries on Metal and the RTX 5090
    ChaCha, SplitMix64, FNV-1a inside the lottery hashChaCha by D. J. Bernstein (public domain, approximate); SplitMix64 by Steele, Lea and Flood (algorithm from the 2014 paper, approximate); FNV-1a by Fowler, Noll and Vo (public domain, approximate). All three re-implemented from the definitions in igneum-pow, no code importedUsed as published: ChaCha12 core with feed-forward for the cache fill, SplitMix64 as the program stream, FNV-1a 64 for seed words and the cache digestStandard, well-studied primitives for a cache fill and a seed stream; nothing in the design asks for moreSpec sections 1.3 and 1.8 with test vectors; bench-log "igneum-pow bit-exact" (cache digest 48c4f5bf24166b2e matches Swift and C++)
    ProgPoW and KAWPOWProgPoW (EIP-1057 text, ifdefelse/ProgPOW; KAWPOW on Ravencoin since 2020, RavenProject/Ravencoin, MIT approximate). Prior art, no code used. Not yet cloned; docs/fud-fixes.md item 48 asks for the clone and citation before the repository is publicNothing taken. The difference: ProgPoW and KAWPOW randomise the maths inside a fixed program shape every few blocks; Igneum regenerates the whole program every hour over a growing dataset, with automatic era draws and no human in the loopStated so that the "first" claim in the litepaper is accurate (FUD ledger M4)Litepaper "What has never been done before", row 1, rewritten 3 Oct 2026
    Class-group VDFChia, chiavdf. Apache-2.0, verified (vendor/chiavdf/LICENSE), commit 7e62ce14. Wesolowski's proof (Efficient Verifiable Delay Functions, EUROCRYPT 2019), a paper, no licenceNUDUPL and NUCOMP ported from chiavdf's qfb_nudupl and qfb_nucomp into proto-vdf (Rust, over GMP through rug); fresh 1024-bit prime discriminant per input; 256-bit Fiat-Shamir prime (Chia uses 264); Igneum tags for the epoch and era paths. The textbook composition is kept as an oracleThe program seed must come from a certified checkpoint with a delay no miner can skip, so the seed cannot be ground. Chia's group needs no trusted setupSpec section 4.2 (15,000 random cases agree with the oracle; 163,000 squarings per second; 4.5 ms verify); bench-log "proto-vdf" entry. GMP itself: LGPL-3.0 or GPL-2.0 dual, approximate, prototype only; the production dependency is decided with the wire format (O-4.5)
    revmEthereum ecosystem, bluealloy/revm. Licence approximate: MIT. https://github.com/bluealloy/revm (not yet cloned)Unchanged, credited. Driven by an Igneum block executor that feeds it the DAG's canonical sequence with the environment table of spec 7.1 and two-dimensional gasThe same EVM runs natively and inside the zkVM (reth, rsp and SP1 Reth all use it), so native and proven execution share one code pathdocs/design/execution-layer.md D6 and section 2.1; differential test plan against reth (section 8.5). Nothing measured yet
    SP1-class proversSuccinct, succinctlabs/sp1. Licence approximate: MIT or Apache-2.0. Not yet clonedUnchanged, behind the versioned ProofSystem trait (docs/design/execution-layer.md 5.6). Version 1 is SP1 (Hypercube class, hash-based). Devnet v1 runs a stub that signs claimsConsumer cards prove hash-based systems without elliptic-curve MSM; the trait makes a swap a release (90% signalling, 3-month overlap, one wrap), never a redesignNo SP1 shard has been proven on any card in this repository (FUD ledger P1, P3). Phase 2 gate: shard time on a 3060-class card, published pass or fail
    BLS12-381Curve by Barreto, Lynn and Scott; blst by Supranational. Licence approximate: Apache-2.0. https://github.com/supranational/blst (not yet cloned)Unchanged, credited. The header carries the BLAKE2b hash of a G1 compressed public key (48 bytes); every voter signs every 30-s checkpoint; signatures aggregateFinality rule v2 needs one aggregate signature per checkpoint from thousands of keysSpec section 3.1 (W1) and 2.4; sim/results_v2.md for the rule itself. Signature cost not yet measured
    Hashing in the noderusty-kaspa crypto/hashes, ISC, verified. Crates linked by the fork, licences read from the local cargo registry: blake2b_simd 1.0.2 (MIT), blake3 1.8.3 (CC0-1.0 or Apache-2.0), sha2 0.10.8 (MIT or Apache-2.0), keccak 0.1.6 (Apache-2.0 or MIT); sha3 0.10.8 not in the local registry, approximate: MIT or Apache-2.0Unchanged, credited. BLAKE2b with domain separation for block, transaction and PoW pre-hashes (BlockHash, TransactionHash, ...), BLAKE3 keyed for the sequencing-commitment and payload hashers, SHA-256 for ECDSA signing hashes, cSHAKE256 (Keccak) in the kHeavyHash stub that stays as the default engine and for pruning-proof block levelsThe chain's hash for everything except the lottery is the one the forked commit uses (spec 0.6), so nothing unverified enters consensushash_override_nonce_time gained one field (fork-divergence row 1); every header-hash test vector was regenerated and the four genesis hashes re-derived
    Address formatBitcoin BIP 173 character set (bech32, Pieter Wuille and Greg Maxwell; BIP licence approximate: BSD-2-Clause) with the CashAddr polymod checksum of Bitcoin Cash (the source cites bch.info), as implemented in rusty-kaspa crypto/addresses/src/bech32.rs, ISC, verifiedPrefixes only: igneum, igneumtest, igneumsim, igneumdev (Kaspa: kaspa, kaspatest, kaspasim, kaspadev). The script public key behind an address is unchangedNo Igneum address string may parse as a Kaspa address on any networkFork-divergence row 9; test vectors in addresses and txscript regenerated and passing
    The EVMEthereum (Yellow Paper and ethereum/execution-specs, CC0 approximate). Cancun opcode set, precompiles 0x01 to 0x09Semantics on a DAG: block.number is selected-chain height, block.timestamp is non-decreasing by a max rule, prevrandao is the VDF epoch seed, chain ids 4461, 4462, 4463; 0x0a absent; gas has a second dimensionBlocks on a DAG have no single parent and no header state root; proving cost is a second resource; the random beacon must be unbiasableSpec section 7.1 (normative table); devnet measurement R9 for timestamp drift; ethereum/tests replay in the differential plan
    kHeavyHash (kept as a stub)Kaspa, rusty-kaspa crypto/hashes/src/pow_hashers.rs and consensus/pow/src/matrix.rs, ISC, verifiedKept untouched as HeavyHashEngine, the default engine when the igneum-pow feature is off, and the block-level source for pruning proofs until seeds are threaded throughLets the devnet run and lets upstream pow changes merge cleanlyFork-divergence rows 14 and 15; open item in the same file (pruning-proof block levels)
    +
    +

    What is new in Igneum

    +

    Nothing here has a precedent that Igneum could have copied. Each item names the measurement or specification it rests on.

    +
    PieceWhat it isWhere it is specified or measured
    The hourly header-bound GPU programA program drawn per epoch from a VDF seed, compiled to native GPU code, with the nonce-zeroed header hash absorbed into the init words so one nonce serves one headerSpec section 1 and igneum-pow/src/bind.rs; bench-log "first devnet blocks on the real lottery hash"
    Sustained-mining finality, rule v2Vote weight is blue blocks per BLS vote key over a flat 30-day window; every voter signs every 30-s checkpoint; lock at 2/3 of active weight and at least 56.7% of total weight; no stake, no other chainSpec section 3; sim/results_v2.md (0 conflicting locks in every partition and eclipse scenario)
    Two-dimensional gas and the per-frame app shareExecution gas on Ethereum's schedule plus proving gas from a calibrated table; 20% of the priority fee attributed per call frame to the registered developer of the contract that ranSpec sections 5.1, 5.2; docs/design/execution-layer.md section 4
    The shard market and the native proving precompileShards cut from the native trace, assigned by sortition to 8 eligible provers for 10 s, then open; a Prover system contract that takes a job and returns the result by a later proof recordSpec section 7.2; docs/design/execution-layer.md sections 5 and 6
    Automatic era drawsEra parameters drawn every 6 months from chain state through a 1-h VDF, inside rules fixed at genesis; dataset growth and instruction-family unlocks by height, with no scheduled human releaseSpec section 4.4; spec section 1 era schedule (Designed, not yet in code)
    +
    +

    What we will adopt from upstream when it is ready

    +
    ItemSourceCondition
    DagKnightKaspa's parameterless successor to GHOSTDAG (Sompolinsky and Sutton, approximate), once it ships in a rusty-kaspa releaseMerged through tools/upstream/ after review against spec section 2; the finality rule reads blue blocks, so the weight table must be re-derived under the new ordering before activation
    Upstream security fixesrusty-kaspa tagged releasesEvery tagged release is fetched and merged on a branch by tools/upstream/sync-upstream.sh; any change to a consensus rule is reviewed against docs/spec before the merge commit
    Upstream pow and pruning-proof refactorsrusty-kaspaTaken as long as kaspa_pow::State stays untouched (the Igneum engine sits beside it, never inside it)
    +
    +

    Licence of Igneum's own code

    +

    Recommended: MIT, for the node fork's additions, igneum-pow, the prototypes and the tools. igneum-pow/Cargo.toml already declares license = "MIT" and should be read as provisional until the decision below.

    +

    Pending the maintainers' decision. Two obligations hold whatever is chosen: the fork keeps Kaspa's ISC copyright notice in vendor/igneum-node/LICENSE (ISC requires it), and the VDF code keeps chiavdf's Apache-2.0 notice and a statement of what was changed (Apache-2.0 section 4).

    +
    +

    Generated from the repository at build time. Times are UTC. Machine names are model names.

    +
    +
    + + + + + + + + \ No newline at end of file diff --git a/site/randomx.html b/site/randomx.html new file mode 100644 index 00000000..ccf2b47d --- /dev/null +++ b/site/randomx.html @@ -0,0 +1,234 @@ + + + + + +Igneum and RandomX + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    +
    + +
    Monero’s idea, finished for GPUs
    +

    RandomX, rebuilt for GPUs.

    +

    Random-program mining is the idea Igneum borrowed. Here is what changed when it was rebuilt for graphics cards, and what RandomX’s seven years say and do not say about this chain. The same text as the litepaper’s section.

    +
    +
    +
    +
    +

    RandomX has kept chips off Monero since 2019 (approximate) by making the mining program random, so the hardware that runs it well is the hardware everyone already owns. The one chip announced against it, Bitmain’s Antminer X9 (pre-orders from 26 December 2025 at 1 MH/s and 2,472 W, about USD 5,600), was withdrawn in mid-May 2026 before any unit shipped; RandomX 2.0 shipped on 25 March 2026 (monero-project/monero issue 10270). Igneum takes the same principle to graphics cards and adds what RandomX never had.

    +
    + + + + + + + + + + + +
    PropertyRandomX, MoneroIgneum
    Hardware it is built forCPUs. GPUs run it badly on purposeGPUs. Any card, any vendor. Bit-exact on Apple, NVIDIA and AMD, measured
    Random programPer hash, interpreted in a virtual machinePer hour, compiled to native GPU code. Per hash, the 128 dataset addresses change with the nonce
    DatasetAbout 2 GB, the same size since 2019, approximate2 GB, growing (the proposed schedule, fixed at the testnet genesis: 2 GB, doubling at years 4, 12 and 28); a 4 GB card mines about four years, an 8 GB card about twelve, approximate
    Light verification256 MB cache on a CPU, milliseconds256 MB cache on a CPU (512 MB from year 4), one warp under 10 ms, the gate. Measured 2.1 ms on one Apple M5 Max core for class v3 (3.4x class v2's 0.61 ms); a 2019-class core not yet
    Changes over timeNone. A fixed design, unchanged for seven yearsA new program every hour, its memory pattern with it; era draws and reserved families on a schedule fixed at genesis. Nobody touches it
    Seed grindingNot applicable, the program comes from the hash inputClosed by a verifiable delay between seed and program
    Useful workNone. Hashing onlyEvery NVIDIA card from 8 GB proves; 12 GB and up mine and prove; 24 GB on the stock server (eleven rented cards, RTX 3060 to RTX 5090, 6 October 2026); they sell proofs to other chains. AMD and Apple cards mine, and a prover for them lands when a zkVM ships one
    Track recordAbout seven years without a shipped chip; the one announced, Bitmain’s Antminer X9, was withdrawn in May 2026 before launchZero years. Every number above is measured and logged with the commands that produced it. The specification, reference hash, test vectors and simulators are public now (github.com/igneum-network/spec). The node, the miner and the wallet are in a private repository until the public testnet
    +

    Measured so far: the same hourly program, generated on an Apple M5 Max, compiled by Apple's Metal and NVIDIA's CUDA on an RTX 5090, produced identical hashes on both, 192 of 192 across two programs. On a 1 GB dataset the 5090 ran at about 228 million hashes a second and the Mac at about 45 million, both bound by random memory access rather than arithmetic. Those are prototype figures, not mining rates. The first prototype dataset was a closed-form function, and a miner could compute items instead of loading them: measured 111x faster that way on the Mac. The 256 MB cache construction replaced it on 3 October 2026. With the cache, computing items on the fly runs 4.8x slower than loading them, measured on the Mac, and the honest rate is unchanged on both vendors. Open: the same shortcut ratio on NVIDIA and on a discrete AMD card, and the time-memory trade-off between the two measured points. Inside the 5090's 96 MB cache the same program ran nearly six times faster, which is why the dataset starts at 2 GB and grows. On 4 October 2026 the live devnet crossed an hourly program change on all three vendors with no pause and no rejected block: a Mac at 26.7 million hashes a second, an RTX 5090 at 123 million and an integrated AMD chip at 2.7 million, every hash doing 128 distinct reads of the memory-hard dataset.

    + +
    +
    +
    + + + + + + + + \ No newline at end of file diff --git a/site/scenes.html b/site/scenes.html index c4318227..88c52d85 100644 --- a/site/scenes.html +++ b/site/scenes.html @@ -12,6 +12,7 @@ +
    -
    -
    -
    -
    Igneum Wallet · desktop
    -

    Your coins. Final means final.

    -

    A desktop wallet that holds the key the miner made for you, or one you make here from 24 words. It sends, receives and reads your history, and it verifies every finality certificate itself with the node's own code. No confirmation counts, no trusting the node.

    -
    - Download: public testnet - How final works +
    +
    + +
    +
    +
    Igneum Wallet · desktop
    +

    Your coins. Final means final.

    +

    A desktop wallet that holds the key the miner made for you, or one you make here from 24 words. It sends, receives and reads your history, and it checks every finality certificate itself with the node’s own code. No confirmation counts, no trusting the node.

    + +
    macOS firstWindows nextMetaMask export
    -
    macOS firstWindows nextMetaMask export
    -
    -
    -
    -
    Igneum Wallet
    - The wallet window: a balance in IGN, an example address with Send and Receive, node and finality panels, and a history of block rewards -
    Igneum Wallet on a private test network, 5 Oct 2026. The address is an example.
    -
    +
    IGNEUM WALLET0.1.5
    +
    + The wallet window, Home: a balance of 31.6321 IGN with the devnet note that coins have no value, an example address with Copy, Send and Receive, the node line synced to the miner app's node and verified to a checkpoint, and the recent transfers with their state words + The wallet window, Home, in light mode: a balance of 31.6321 IGN, an example address with Copy, Send and Receive, the node line and the recent transfers +

    Igneum Wallet 0.1.5, rendered from the wallet’s own mock state: example keys, 7 October 2026.

    -
    + -
    -
    -
    -

    Three states, checked here

    -

    Every transfer in the history is pending, in a block, or final. The third one is the wallet's own verdict.

    +
    +
    +
    +
    Pending, in a block, final

    Three states, checked here.

    +

    Every transfer in the history is pending, in a block, or final. The third one is the wallet’s own verdict.

    -
    pending
    Waiting for a block

    Signed on this machine and handed to the node. Nothing has carried it yet.

    -
    in a block
    Chain block 8

    A block carries it and the chain's height passed it. It can still be reorganised until a checkpoint covers it.

    -
    final · cp 5
    Under a verified checkpoint

    Its block sits under a 30-second checkpoint whose certificate this wallet verified: the voter list, the aggregate BLS signature, two thirds of all weight.

    +
    pending
    Waiting for a block

    Signed on this machine and handed to the node. Nothing has carried it yet.

    +
    in a block
    Chain block 8

    A block carries it and the chain’s height passed it. It can still be reorganised until a checkpoint covers it.

    +
    final · cp 5
    Under a verified checkpoint

    Its block sits under a 30-second checkpoint whose certificate this wallet verified: the voter list, the aggregate BLS signature, two thirds of all weight.

    -
    -
    -
    Transaction
    - A sent transfer of 1.5 IGN shown as final under checkpoint 5, certificate verified by this wallet, with amount, example addresses, fee paid, hash, block and the verified checkpoint at chain height -
    The transfer from the test run: 1.5 IGN, final under checkpoint 5, certificate verified by the wallet. Addresses are examples.
    -
    -
    -
    +
    +
    History
    + The wallet's History page: every transfer with the node's word, pending, proven, executed, finalised under a checkpoint verified here, and one failed with the fee still paid + The wallet's History page in light mode: every transfer with the node's word, pending, proven, executed, finalised under a checkpoint verified here +
    Every transfer with the node’s word: pending, proven, executed, finalised under a checkpoint this wallet verified. Igneum Wallet 0.1.5, rendered from its mock state with example keys, 7 October 2026.
    +
    +
    What the wallet checks before it says final
    1. The certificate as a block carried it: the finality section of the blocks after the checkpoint.
    2. The canonical voter list: every key above dust and not stripped, sorted by key hash, as many as the certificate says.
    3. The aggregate signature over the checkpoint, by the keys the bitmap names.
    4. -
    5. The rule: signed weight at least two thirds of the active weight and of the total weight. Then the transfer's block must sit under the checkpoint on the chain.
    6. +
    7. The rule: signed weight at least two thirds of the active weight and of the total weight. Then the transfer’s block must sit under the checkpoint on the chain.
    -

    The same steps the browser verifier on the home page runs, with the node's own finality code compiled into the wallet. The node's own "locked" field is never read.

    +

    The same steps the browser verifier on the home page runs, with the node’s own finality code compiled into the wallet. The node’s own "locked" field is never read.

    -
    -
    -
    -

    Every feature, one line each

    -

    Version 1, built on the miner's bones: the same local server, the same signed update manifest, the same key code.

    +
    +
    +
    +
    Version 1

    Every feature, one line each.

    +

    Built on the miner’s bones: the same local server, the same signed update manifest, the same key code.

    -
    01 · Your key

    Create or import, sealed on your disk

    The password is never written anywhere. The plaintext only ever exists in the engine's memory and is zeroed when the wallet locks.

    +
    01 · Your key

    Create or import, sealed on your disk

    The password is never written anywhere. The plaintext only ever exists in the engine’s memory and is zeroed when the wallet locks.

    Create: 24 words

    256 bits of entropy from the operating system, as 24 English words. The wallet asks for three of them typed back before it goes on.

    -
    Import

    Your 24 words, a raw private key, or the miner's own payout key file. One click brings the key the miner pays to into the wallet.

    +
    Import

    Your 24 words, a raw private key, or the miner’s own payout key file. One click brings the key the miner pays to into the wallet.

    Sealed with a password

    Argon2id (64 MiB, 3 passes) turns the password into a key; XChaCha20-Poly1305 seals the secret under it. The vault is one file in your user folder.

    The Ethereum path

    Keys follow BIP-39 and BIP-44 at the Ethereum path, so the same 24 words open the same account in MetaMask.

    @@ -249,25 +222,25 @@ td.num{font-variant-numeric:tabular-nums;white-space:nowrap}
    Send with the fee shown

    An EIP-1559 transfer. The review shows the amount, the fee at most as base fee plus tip, and what leaves the wallet at most. The zero address and more than the balance are refused.

    Receive by QR

    The code is drawn on your machine as SVG. No image service, no call across the network.

    History with rewards

    Transfers in and out, block rewards from the execution records, one per blue block, and proving payouts when a block carries a proof record.

    -
    Finality per transaction

    Pending, in a block, or final with the checkpoint index, verified here. How it checks.

    +
    Finality per transaction

    Pending, in a block, or final with the checkpoint index, verified here. How it checks.

    Lock

    One button locks the wallet and zeroes the key in memory. The password opens it again.

    -
    03 · Your node

    Reads the miner's node first

    When the miner is installed, the wallet uses its node on this machine. Nobody else sees your balance.

    +
    03 · Your node

    Reads the miner’s node first

    When the miner is installed, the wallet uses its node on this machine. Nobody else sees your balance.

    -
    1 · The miner app's node

    Found on this machine and used as it is. Nothing is started.

    +
    1 · The miner app’s node

    Found on this machine and used as it is. Nothing is started.

    2 · A public RPC

    Balances, sending and history work without a local node. Finality verification needs a node, so transfers stay "in a block" until one is there, and the wallet says so.

    3 · The bundled node

    The wallet starts its own copy of the node on its own ports, no mining, and stops it when the wallet quits.

    -
    Updates, signed

    The same Ed25519 key as the miner's manifest, checked an hour apart. The download is checked against the manifest's hash before Install now opens it.

    +
    Updates, signed

    The same Ed25519 key as the miner’s manifest, checked an hour apart. The download is checked against the manifest’s hash before Install now opens it.

    04 · MetaMask

    Export and add the network

    For people who already live in MetaMask. The key leaves this app only when you copy it.

    -
    Add to MetaMask

    One click adds the Igneum network with its chain id and RPC. Copy network settings puts the same values on the clipboard.

    +
    Add to MetaMask

    One click adds the Igneum network with its chain id and RPC. Copy network settings puts the same values on the clipboard. The same values, on this site.

    Export the key

    Behind the password, behind a warning: a copied key can be stolen from the clipboard, a screenshot or a notes app. Paste it straight into MetaMask and clear the clipboard.

    Desktop first

    macOS now, as a disk image. The Windows host is written and untested. No browser extension and no phone app yet.

    @@ -275,52 +248,51 @@ td.num{font-variant-numeric:tabular-nums;white-space:nowrap}
    -
    -
    -
    -

    The first run, timed

    +
    +
    +
    +
    Measured

    The first run, timed.

    A private test network, 5 Oct 2026: one node, one CPU miner paying to wallet A, wallet A sending to wallet B. The log entry ships with the wallet.

    -
    - +
    StepFrom the node's startWhat was seen
    + - + - +
    StepFrom the node’s startWhat was seen
    Wallet A created, 24 words, three typed back0.3 san address
    Wallet B: a wrong word refused, then created0.4 to 0.5 s"word 1 is not right"
    A's balance from block rewards3.5 s10.14 IGN at block 4
    A’s balance from block rewards3.5 s10.14 IGN at block 4
    Zero address, 999,999,999 IGN, a short address4.5 sall three refused by the quote
    Quote for 1.5 IGN to B4.6 sgas 25,380; base fee 1 gwei; tip 1 gwei; fee at most 0.00007614 IGN
    In a block5.6 schain block 8
    First locked checkpoint on the networkabout 170 sindex 5
    Final in wallet A175.2 sunder checkpoint 5, certificate verified by the wallet: 1 of 1 voters, 100% of total weight
    B's view of the same transfer175 s1.5 IGN, final
    B’s view of the same transfer175 s1.5 IGN, final
    -

    Send to final: 170.6 s, all of it the network's first lock on a fresh chain. On the live devnet checkpoints lock every 30 seconds once the weight window is full. 13 unit tests cover the words, the path, the vault, the signing and the finality state machine.

    +

    Send to final: 170.6 s, all of it the network’s first lock on a fresh chain. On the live devnet checkpoints lock every 30 seconds once the weight window is full. 13 unit tests cover the words, the path, the vault, the signing and the finality state machine.

    -
    -
    -
    -

    Get the wallet

    -

    Download only from this domain. Nobody from Igneum will ask for your seed. The file below is the one the wallet's signed manifest names, with its version and size.

    -

    Public testnet: not yet open; the devnet build is here for people who want to look.

    -

    Devnet: coins have no value and the chain may be reset.

    +
    +
    +
    +
    Downloads

    Get the wallet.

    +

    Download only from this domain. Nobody from Igneum will ask for your seed. The file below is the one the wallet’s signed manifest names, with its version and size.

    -

    The wallet reads this machine's node when the miner is installed. Without it, a public RPC for balances and sending, or the bundled node for everything.

    - Read more in the litepaper +

    Public testnet: not yet open; the devnet build is here for people who want to look.

    +

    Devnet. Coins have no value and the chain may be reset.

    +

    The wallet reads this machine’s node when the miner is installed. Without it, a public RPC for balances and sending, or the bundled node for everything. More in the litepaper.

    -
    -
    +
    +

    The miner pays this wallet.

    Install the miner, press Start, and the address it makes is the one this wallet imports with one click.

    @@ -329,69 +301,71 @@ td.num{font-variant-numeric:tabular-nums;white-space:nowrap}
    - - + diff --git a/site/yourcard.js b/site/yourcard.js new file mode 100644 index 00000000..7c843070 --- /dev/null +++ b/site/yourcard.js @@ -0,0 +1,17 @@ +/* The "your card" line: a measured card, and how often it finds a block at the network's hash rate right now. One block a + second is the target, so the wait is network hashes per second over the card's rate. The rates are the bench table's + measured numbers (site/miners.html); nothing here is a promise. Reads /api/live every 15 s. */ +(function () { + var CARDS = [['NVIDIA RTX 5090', 127.7], ['NVIDIA RTX 4070', 28.8], ['Apple M5 Max', 26.7], ['AMD RX 9070 XT', 17.8]]; + var els = document.querySelectorAll('[data-yourcard]'); if (!els.length) return; + var net = null, chosen = (function () { try { return localStorage.getItem('igneum-card'); } catch (e) { return null; } })(); + function dur(sec) { if (!(sec > 0)) return 'pending'; if (sec < 90) return Math.round(sec) + ' s'; if (sec < 5400) return Math.round(sec / 60) + ' min'; if (sec < 172800) { var h = Math.floor(sec / 3600), m = Math.round((sec % 3600) / 60); return h + ' h' + (m ? ' ' + m + ' min' : ''); } return Math.round(sec / 86400) + ' days'; } + function render() { els.forEach(function (el) { var r = parseFloat(el.querySelector('select').value) * 1e6, eta = el.querySelector('.eta'); eta.textContent = net && r ? 'every ' + dur(net / r) : 'pending'; }); } + els.forEach(function (el) { + el.innerHTML = 'Your cardfinds a block about pending at the network\u2019s hash rate right now.'; + el.querySelector('select').addEventListener('change', function (e) { var name = e.target.options[e.target.selectedIndex].text.split(' \u00b7 ')[0]; try { localStorage.setItem('igneum-card', name); } catch (x) {} document.querySelectorAll('[data-yourcard] select').forEach(function (s) { s.value = e.target.value; }); render(); }); + }); + function poll() { fetch('/api/live?window=30', { cache: 'no-store' }).then(function (r) { return r.json(); }).then(function (d) { if (d && d.ok && d.state && d.state.hashes_per_second_estimate > 0) { net = d.state.hashes_per_second_estimate; render(); } }).catch(function () {}); } + poll(); setInterval(function () { if (!document.hidden) poll(); }, 15000); + window.IgneumYourCard = { update: function (h) { if (h > 0) { net = h; render(); } } }; +})(); diff --git a/tools/build-remote.sh b/tools/build-remote.sh index c8e72f1f..9618ec3d 100755 --- a/tools/build-remote.sh +++ b/tools/build-remote.sh @@ -24,6 +24,18 @@ # A plain build is native glibc 2.39: the box, the fleet's # Ubuntu 24.04 hosts, never a seed or a rig (7 Oct 2026: # a seed took 14 restarts on a 2.39 binary). +# tools/build-remote.sh --priority gate -- test ... a RELEASE GATE (the app gate, the canary cut, the pre-push +# self-tests): nice 0, the full core set, a slot ahead of +# queued suites and benches +# tools/build-remote.sh --plan [--priority gate] -- print the resolved class (kind, nice, cores, jobs) and stop; +# no box, no crate needed (the CI check uses it) +# +# Scheduling (main, 7 October 2026, after a load of 190 on 96 threads: a release join bench and the 0.3.19 app gate starving each +# other and "builds" of 16 minutes): every SUITE (cargo test) and BENCH (cargo bench) runs under nice 10 on the last 32 cores with +# -j 32 unless the caller passes --priority gate; builds keep the box's own jobs rule (90 alone, 45 beside another slot holder); a +# gate runs at nice 0 on the full set and takes a slot ahead of queued suites and benches (remote-run.sh gate-pending marker). The +# class travels in the slot label ("; kind=suite nice=10 cores=32") and the JSONL line, so the dashboard's job card shows why a +# job is slow. A call without a priority flag defaults to the bounded class for suites and benches: tools/ci/build-kind-default-check.sh. # tools/build-remote.sh --self-test-repro [--full] from a fork worktree: igneum-miner built twice a minute # apart without sccache into one target dir must give one # sha256, and a per-run target path must not (prost's @@ -63,7 +75,7 @@ BS_TOOL=build-remote # flight cannot reach the running copy (7 Oct 2026: build-remote.sh was edited mid-run and died on shifted bytes after a 4-min build) # JOBS empty = the box decides: 90 alone, 45 beside another slot holder (remote-run.sh, main's ruling 6 Oct 2026) -JOBS="${JOBS:-}"; OUT=""; ARTEFACTS=""; TARGET_DIR="target"; FETCH=1; CARGO_ARGS=(); SELFTEST=0; FULL=0; SHIP=0; SHIP_CLASS="${SHIP_CLASS:-seed}"; GLIBC="${GLIBC:-}" +JOBS="${JOBS:-}"; OUT=""; ARTEFACTS=""; TARGET_DIR="target"; FETCH=1; CARGO_ARGS=(); SELFTEST=0; FULL=0; SHIP=0; SHIP_CLASS="${SHIP_CLASS:-seed}"; PRIORITY="${PRIORITY:-normal}"; PLAN=0; BOX="${BOX:-}"; GLIBC="${GLIBC:-}" while [ $# -gt 0 ]; do case "$1" in --jobs) JOBS="$2"; shift 2 ;; @@ -73,6 +85,10 @@ while [ $# -gt 0 ]; do --no-fetch) FETCH=0; shift ;; --self-test-repro) SELFTEST=1; shift ;; --ship) SHIP=1; case "${2:-}" in hive|rig|seed|linux|native) SHIP_CLASS="$2"; shift 2 ;; *) shift ;; esac ;; + --priority) PRIORITY="$2"; shift 2 ;; + --box) BOX="$2"; BOX_GIVEN=1; shift 2 ;; + --gate) PRIORITY=gate; shift ;; + --plan) PLAN=1; shift ;; --glibc) GLIBC="$2"; shift 2 ;; --full) FULL=1; shift ;; --) shift; CARGO_ARGS=("$@"); break ;; @@ -83,8 +99,37 @@ done [ "${CARGO_ARGS[0]:-}" = cargo ] && CARGO_ARGS=("${CARGO_ARGS[@]:1}") CARGO_ARGS_GIVEN=""; [ -n "${CARGO_ARGS[*]:-}" ] && CARGO_ARGS_GIVEN=1 -bs_host +# the scheduling class, from the cargo subcommand and the priority flag alone (no box, no crate): BR_NICE, BR_CORES (the last N of the +# box's 96; 0 = the full set), BR_JOBS_CAP (0 = the box's rule), BR_PRIORITY; the kind for the log is refined after bs_context +BR_NICE=0; BR_CORES=0; BR_JOBS_CAP=0; BR_PRIORITY="$PRIORITY"; SCHED_CLASS=build +case "$PRIORITY" in gate|normal) ;; *) bs_die "--priority takes gate or normal, not '$PRIORITY'" ;; esac +case "${CARGO_ARGS[0]:-build}" in + test) SCHED_CLASS=suite ;; + bench) SCHED_CLASS=bench ;; + check|clippy) SCHED_CLASS=check ;; + *) SCHED_CLASS=build ;; +esac +if [ "$PRIORITY" = gate ]; then BR_NICE=0; BR_CORES=0; BR_JOBS_CAP=0 +elif [ "$SCHED_CLASS" = suite ] || [ "$SCHED_CLASS" = bench ]; then BR_NICE=10; BR_CORES=32; BR_JOBS_CAP=32; fi +# an explicit --jobs above the bounded class's cap is clamped (main's rule: bounded unless a priority flag; 7 Oct 2026: two suites +# ran at -j 90 on a box at load 190 because their callers passed --jobs 90) +if [ "$BR_JOBS_CAP" -gt 0 ] && [ -n "$JOBS" ] && [ "$JOBS" -gt "$BR_JOBS_CAP" ]; then bs_log "--jobs $JOBS clamped to $BR_JOBS_CAP for a $SCHED_CLASS (pass --priority gate for the full set)"; JOBS=$BR_JOBS_CAP; fi +export BR_NICE BR_CORES BR_JOBS_CAP BR_PRIORITY +if [ "$PLAN" = 1 ]; then + k="$SCHED_CLASS"; [ "$PRIORITY" = gate ] && k=gate + printf 'kind=%s nice=%s cores=%s jobs=%s priority=%s\n' "$k" "$BR_NICE" "$( [ "$BR_CORES" = 0 ] && echo 96 || echo "$BR_CORES")" "$( [ "$BR_JOBS_CAP" = 0 ] && echo box || echo "$BR_JOBS_CAP")" "$PRIORITY" + exit 0 +fi + +# the box: --box N, else the route by class (suite and bench to box 2, prove to box 3, the rest to box 1; lib.sh bs_route) +if [ -z "$BOX" ]; then + case "$SCHED_CLASS:$PRIORITY" in *:gate) BOX=1 ;; suite:*|bench:*) BOX=$(bs_route "$SCHED_CLASS") ;; *) BOX=1 ;; esac +fi +bs_host "$BOX" bs_context +# a proving crate routes to box 3 unless the caller chose (its builds and suites alike) +if [ "$BS_CRATE_REL" = proving/igneum-prove ] && [ -z "${BOX_GIVEN:-}" ] && [ "$PRIORITY" != gate ]; then b=$(bs_route prove); [ "$b" != "$BOX" ] && { BOX=$b; bs_host "$BOX"; }; fi +bs_log "box $BOX ($BS_HOST) for class $SCHED_CLASS, priority $PRIORITY" if [ "$SELFTEST" = 1 ]; then [ "$BS_KIND" = node ] || bs_die "--self-test-repro runs from a fork worktree (igneum-miner and kaspad live there)" @@ -175,6 +220,9 @@ fi cmd="$(bs_repro_env)${pre}CARGO_TARGET_DIR='$TARGET_DIR' cargo $(printf '%q ' "${CARGO_ARGS[@]}")${JOBS:+-j $JOBS} 2>&1 | tee -a '$BS_REMOTE_WT/.build-remote.log'; rc=\${PIPESTATUS[0]}; [ \$rc = 0 ] && echo '$BS_SHA' > '.build-remote-sha-$TARGET_DIR'; ( exit \$rc )" # a subshell exit: the runner reads \$? and still prints its RESULT line label="$BS_WT/$BS_CRATE_REL cargo ${CARGO_ARGS[*]}" BR_KIND=$(bs_kind build-remote "$( [ "${CARGO_ARGS[0]}" = zigbuild ] && echo build || echo "${CARGO_ARGS[0]}")"); BR_COMMAND="cargo ${CARGO_ARGS[*]}"; BR_TARGET="${BR_TARGET_SHIP:-x86_64-unknown-linux-gnu}" +[ "$SCHED_CLASS" = bench ] && BR_KIND=bench +[ "$PRIORITY" = gate ] && BR_KIND=gate +label="$label; kind=$BR_KIND nice=$BR_NICE cores=$( [ "$BR_CORES" = 0 ] && echo 96 || echo "$BR_CORES")" for ((i = 0; i < ${#CARGO_ARGS[@]}; i++)); do [ "${CARGO_ARGS[$i]}" = --target ] && BR_TARGET="${CARGO_ARGS[$((i + 1))]:-}"; done BR_ARTEFACTS=""; [ "$FETCH" = 1 ] && BR_ARTEFACTS="$ARTEFACTS" export BR_KIND BR_COMMAND BR_TARGET BR_ARTEFACTS diff --git a/tools/ci/build-kind-default-check.sh b/tools/ci/build-kind-default-check.sh new file mode 100755 index 00000000..7a448c5a --- /dev/null +++ b/tools/ci/build-kind-default-check.sh @@ -0,0 +1,23 @@ +#!/usr/bin/env bash +# The scheduling classes of tools/build-remote.sh (main, 7 October 2026, the load-190 night): a build-remote call WITHOUT a priority +# flag must put every suite (cargo test) and bench (cargo bench) into the bounded class, nice 10 on 32 cores with -j 32, while a +# build keeps the box's own jobs rule and --priority gate gives nice 0 on the full set. This check runs the tool's --plan mode (no box, +# no crate) for the four shapes and compares the resolved class; a change that lets a bare `cargo test` run unbounded again fails it. +# +# tools/ci/build-kind-default-check.sh # exit 1 with the shape that resolved wrongly +# tools/ci/build-kind-default-check.sh --self-test # the same four shapes (the check IS its self-test: every expectation is a known case) +set -euo pipefail +cd "$(dirname "$0")/../.." +expect() { # + local want="$1"; shift + local got; got=$(bash tools/build-remote.sh --plan "$@" 2>/dev/null || true) + if [ "$got" = "$want" ]; then echo "build-kind: [$*] -> $got"; else echo "build-kind: [$*] resolved to '$got', expected '$want'" >&2; return 1; fi +} +fail=0 +expect 'kind=suite nice=10 cores=32 jobs=32 priority=normal' -- test -p kaspa-consensus-core --lib || fail=1 +expect 'kind=bench nice=10 cores=32 jobs=32 priority=normal' -- bench -p igneum-pow || fail=1 +expect 'kind=build nice=0 cores=96 jobs=box priority=normal' -- build --release -p kaspad || fail=1 +expect 'kind=gate nice=0 cores=96 jobs=box priority=gate' --priority gate -- test -p igneum-app || fail=1 +expect 'kind=check nice=0 cores=96 jobs=box priority=normal' -- check || fail=1 +[ "$fail" = 0 ] && echo "build-kind: a call without a priority flag bounds suites and benches; a gate runs unbounded at nice 0" +exit $fail diff --git a/tools/ci/export-exclude.txt b/tools/ci/export-exclude.txt index 7b1f244a..24ef752e 100644 --- a/tools/ci/export-exclude.txt +++ b/tools/ci/export-exclude.txt @@ -12,3 +12,6 @@ docs/analysis/horizon/polish.md # the CI failure classification of 6 October 2026 (an operations document: run ids, step names, the fixes) docs/analysis/ci-failures-2026-10-06.md +# 7 October 2026: the last research round (the mission lanes and the closed list): internal research written for the +# owner, quoting his words and the operations record; the public spec mirror carries none of it +docs/analysis/mission diff --git a/tools/ci/launch-gates-check.mjs b/tools/ci/launch-gates-check.mjs new file mode 100644 index 00000000..1e09e9eb --- /dev/null +++ b/tools/ci/launch-gates-check.mjs @@ -0,0 +1,135 @@ +#!/usr/bin/env node +// The launch-pack gate (mission item 10, docs/analysis/mission/mission.md 2.10; the rule-row rule of CLAUDE.md, +// 6 October 2026: a rule row closes only with its check). Three things, each an exit 1 with the line: +// 1. every row of the "Launch gates" table in docs/plans/testnet-go.md has a non-empty Check cell, and every repository +// path the cell names in backticks exists (a gate whose check names a script that is not there is not a gate); +// 2. the text handed to the site lane (docs/plans/launch-pack.md between and ) +// and the public income table (docs/analysis/income-tiers.md) carry none of the served-page patterns of +// site/forbidden-strings.txt nor the export patterns of tools/ci/forbidden-strings.txt, and no em dash; +// 3. the eight regulatory sentences in the handoff are the eight of docs/analysis/mission/future.md section 8.3, each +// numbered, in order, none dropped (the handoff may rephrase; each must cite its number). +// node tools/ci/launch-gates-check.mjs # exit 1 on any failure +// node tools/ci/launch-gates-check.mjs --self-test # a gate row without a check fails; a handoff with the founder's name fails +import { existsSync, readFileSync, mkdtempSync, writeFileSync, mkdirSync, rmSync } from 'node:fs'; +import { tmpdir } from 'node:os'; +import path from 'node:path'; +import { fileURLToPath } from 'node:url'; + +const HERE = path.dirname(fileURLToPath(import.meta.url)); +const ROOT = process.env.LAUNCH_GATES_ROOT || path.join(HERE, '..', '..'); +const GO = 'docs/plans/testnet-go.md'; +const PACK = 'docs/plans/launch-pack.md'; +const INCOME = 'docs/analysis/income-tiers.md'; + +function patterns(root) { + const read = f => { try { return readFileSync(path.join(root, f), 'utf8'); } catch { return ''; } }; + const lines = [...read('site/forbidden-strings.txt').split('\n'), ...read('tools/ci/forbidden-strings.txt').split('\n')]; + return lines.map(l => l.trim()).filter(l => l && !l.startsWith('#')).map(l => new RegExp(l)); +} + +export function gateRows(text) { + const start = text.indexOf('## Launch gates'); + if (start < 0) return null; + const section = text.slice(start); + const rows = []; + let header = null; + for (const line of section.split('\n')) { + if (!line.startsWith('|')) { if (header && rows.length) break; continue; } + const cells = line.split('|').slice(1, -1).map(c => c.trim()); + if (!header) { header = cells.map(c => c.toLowerCase()); continue; } + if (cells.every(c => /^-+$/.test(c))) continue; + const row = {}; header.forEach((h, i) => { row[h] = cells[i] || ''; }); + rows.push(row); + } + return rows; +} + +export function checkGates(root, problems) { + const text = readFileSync(path.join(root, GO), 'utf8'); + const rows = gateRows(text); + if (!rows) { problems.push(`${GO}: no "## Launch gates" section`); return; } + if (!rows.length) { problems.push(`${GO}: the Launch gates table has no rows`); return; } + for (const r of rows) { + const id = r.gate || r['#'] || '(no id)'; + const check = r.check || ''; + if (!check || /^(owed|none|tbd|n\/a)$/i.test(check)) problems.push(`${GO}: gate ${id} has no check`); + for (const m of check.matchAll(/`([^`]+)`/g)) { + const ref = m[1].split(/\s/)[0]; + if (/^(tools|docs|site|infra|packaging|proving|app)\//.test(ref) && !existsSync(path.join(root, ref))) problems.push(`${GO}: gate ${id} names ${ref}, which does not exist`); + } + } + return rows.length; +} + +export function handoff(root) { + const text = readFileSync(path.join(root, PACK), 'utf8'); + const a = text.indexOf(''), b = text.indexOf(''); + if (a < 0 || b < 0 || b < a) return null; + return text.slice(a, b); +} + +export function checkText(root, problems) { + const pats = patterns(root); + const h = handoff(root); + if (h === null) { problems.push(`${PACK}: no handoff block between and `); return; } + const bodies = [[PACK + ' (handoff)', h]]; + try { bodies.push([INCOME, readFileSync(path.join(root, INCOME), 'utf8')]); } catch { problems.push(`${INCOME}: missing`); } + for (const [name, body] of bodies) { + body.split('\n').forEach((line, i) => { + if (line.includes('\u2014')) problems.push(`${name}:${i + 1}: an em dash`); + for (const re of pats) if (re.test(line)) problems.push(`${name}:${i + 1}: forbidden pattern ${re.source}`); + }); + } + // the eight regulatory sentences, numbered 1 to 8 in order + const nums = [...h.matchAll(/\(8\.3 sentence (\d)[;)]/g)].map(m => Number(m[1])); + for (let k = 1; k <= 8; k++) if (!nums.includes(k)) problems.push(`${PACK} (handoff): regulatory sentence ${k} of future.md 8.3 is missing its "(8.3 sentence ${k})" mark`); + const ordered = nums.filter((v, i, arr) => arr.indexOf(v) === i); + if (ordered.join(',') !== '1,2,3,4,5,6,7,8') problems.push(`${PACK} (handoff): the eight sentences are not in order (${ordered.join(',')})`); + if (!/not legal advice; counsel is engaged/i.test(h)) problems.push(`${PACK} (handoff): the label "not legal advice; counsel is engaged" is missing`); +} + +function run(root) { + const problems = []; + const n = checkGates(root, problems); + checkText(root, problems); + return { problems, gates: n || 0 }; +} + +function selfTest() { + const fx = mkdtempSync(path.join(tmpdir(), 'launch-gates-')); + try { + for (const d of ['docs/plans', 'docs/analysis', 'site', 'tools/ci', 'tools/launch']) mkdirSync(path.join(fx, d), { recursive: true }); + writeFileSync(path.join(fx, 'site/forbidden-strings.txt'), 'the project lead\n'); + writeFileSync(path.join(fx, 'tools/ci/forbidden-strings.txt'), '/Users/\n'); + writeFileSync(path.join(fx, 'tools/launch/x.mjs'), ''); + const sentences = Array.from({ length: 8 }, (_, i) => `${i + 1}. sentence (8.3 sentence ${i + 1})`).join('\n'); + const good = `# go\n\n## Launch gates\n\n| Gate | What | Check |\n|---|---|---|\n| G1 | a | \`tools/launch/x.mjs\` runs |\n`; + const goodPack = `\n${sentences}\nnot legal advice; counsel is engaged\n\n`; + writeFileSync(path.join(fx, GO), good); writeFileSync(path.join(fx, PACK), goodPack); writeFileSync(path.join(fx, INCOME), 'clean\n'); + let r = run(fx); + if (r.problems.length) throw new Error(`self-test: the clean fixture failed: ${r.problems.join('; ')}`); + // a gate without a check + writeFileSync(path.join(fx, GO), good + '| G2 | b | |\n'); + r = run(fx); if (!r.problems.some(p => /G2 has no check/.test(p))) throw new Error('self-test: a gate row without a check passed'); + // a check naming a missing script + writeFileSync(path.join(fx, GO), good + '| G3 | c | `tools/launch/missing.mjs` |\n'); + r = run(fx); if (!r.problems.some(p => /does not exist/.test(p))) throw new Error('self-test: a check naming a missing script passed'); + writeFileSync(path.join(fx, GO), good); + // the founder's name in the handoff, an em dash, a missing sentence + writeFileSync(path.join(fx, PACK), goodPack.replace('1. sentence', '1. the project lead says')); + r = run(fx); if (!r.problems.some(p => /forbidden pattern the project lead/.test(p))) throw new Error('self-test: the founder\'s name in the handoff passed'); + writeFileSync(path.join(fx, PACK), goodPack.replace('2. sentence', '2. a \u2014 dash')); + r = run(fx); if (!r.problems.some(p => /em dash/.test(p))) throw new Error('self-test: an em dash in the handoff passed'); + writeFileSync(path.join(fx, PACK), goodPack.replace('(8.3 sentence 5)', '')); + r = run(fx); if (!r.problems.some(p => /sentence 5 of future.md 8.3 is missing/.test(p))) throw new Error('self-test: a dropped regulatory sentence passed'); + process.stdout.write('self-test passed: a gate without a check, a missing script, the founder\'s name, an em dash and a dropped sentence each fail; the clean fixture passes\n'); + return 0; + } finally { rmSync(fx, { recursive: true, force: true }); } +} + +if (process.argv[1] && path.resolve(process.argv[1]) === fileURLToPath(import.meta.url)) { + if (process.argv.includes('--self-test')) process.exit(selfTest()); + const { problems, gates } = run(ROOT); + if (problems.length) { for (const p of problems) process.stderr.write(`${p}\n`); process.exit(1); } + process.stdout.write(`launch gates: ${gates} gate rows, each with its check; the handoff text and the income table carry no forbidden pattern; the eight regulatory sentences are present in order\n`); +} diff --git a/tools/ci/ledger-text-check.mjs b/tools/ci/ledger-text-check.mjs index 27f9f735..cf24b8a1 100644 --- a/tools/ci/ledger-text-check.mjs +++ b/tools/ci/ledger-text-check.mjs @@ -14,7 +14,8 @@ const REQUIRED = { ['X2', 'Public testnet: not yet open; the devnet build is here for people who want to look'], ['X7', 'hello@igneum.network'], ['X31', 'The public testnet is weeks away: three seed nodes and the public RPC are up, and it opens when the go checklist closes.'], - ['X35', 'With the class v4 shadow work it is 2.1x to 3.9x'], + // 7 Oct 2026, 14:3x: the chip line of docs/plans/counter-asic-3-public-text-2026-10-07.md (the X9 label now lives on the litepaper) + ['X35', 'class v4, now on the vote, brings that to 2.1x to 3.9x'], ], 'litepaper.html': [ ['X3', 'Live rows arrive with the public testnet.'], @@ -22,10 +23,11 @@ const REQUIRED = { ['X8', 'No listing is arranged, promised or sought by the project'], ['X31', 'The public testnet is weeks away: three seed nodes and the public RPC are up, and it opens when the go checklist closes.'], ['C2', '2019 (approximate)'], - ['X34', 'Antminer X9 ships from July 2026 at 1 MH/s and 2,472 W, about USD 5,600, and RandomX 2.0 shipped on 25 March 2026'], - ['X34', 'with no chip publicly shipped until Bitmain'], - ['X35', 'it brings the chip to 2.1x to 3.9x'], - ['X35', 'and to 3.9x at the X9’s core (k about 0.33)'], + ['X34', 'was withdrawn in mid-May 2026 before any unit shipped; RandomX 2.0 shipped on 25 March 2026'], + ['X36', 'Bitmain opened Antminer X9 pre-orders on 26 December 2025 for July 2026 delivery, then withdrew the product in mid-May 2026 and refunded buyers before any unit shipped; none has been independently benchmarked.'], + ['X35', 'class v4, now on the vote, brings that to 2.1x to 3.9x'], + ['X35', '3.9x with the core Bitmain claimed for its Antminer X9 (k about 0.33), a product withdrawn before any unit shipped'], + ['X36', 'the X9 figure claimed, never measured'], ['M34', 'The work that waits can grow.'], ['M2', 'computing items on the fly runs 4.8x slower than loading them'], ['M4', 'ProgPoW, as KAWPOW on Ravencoin since 2020'], @@ -59,7 +61,7 @@ const REQUIRED = { ['G3', 'there is no team page'], ['G4', 'no admin keys in consensus'], ['G6', 'Pools can be bypassed on transaction choice'], - ['X34', 'About seven years without a public chip, then Bitmain'], + ['X34', 'About seven years without a shipped chip; the one announced, Bitmain'], ['C3', 'Chips arrived, as on Kaspa, whose hash was designed to welcome them'], ['C3', 'Kaspa has run in production since 2021 (approximate)'], ['C5', 'Inclusion is not confirmation on either chain'], diff --git a/tools/ci/pre-push.sh b/tools/ci/pre-push.sh index b84a64e9..659e9839 100755 --- a/tools/ci/pre-push.sh +++ b/tools/ci/pre-push.sh @@ -54,6 +54,7 @@ structural_checks() { tree_checks() { run "site build (in a temporary copy locally, in place in CI)" site_build run "internal link check of site/*.html" node tools/ci/link-check.mjs + run "every served page carries the full header (six items, Download, burger)" node tools/ci/site-nav-check.mjs run "ledger sentences present verbatim on their public pages" node tools/ci/ledger-text-check.mjs run "identity grep of the public export list and the served site" bash tools/ci/identity-check.sh run "shell inside .github/workflows parses (bash -n, the PowerShell 5.1 rule)" node tools/ci/check-workflow-shell.mjs @@ -71,19 +72,27 @@ tree_checks() { run "root prover playbooks kill the GPU server and unlink its socket" bash tools/ci/prover-socket-check.sh run "commit-string gate self-test" bash tools/ci/commit-string-check.sh --self-test run "build server remote checkout self-test" bash infra/build-server/remote-run.sh --self-test + run "a slot holder keeps its own line for the whole run (the watcher-trust rule)" bash infra/build-server/remote-run.sh --self-test-keeper run "the remote checkout resets the mirror's tree before the branch checkout (the stale-overlay class)" bash -c 'bash tools/ci/mirror-reset-check.sh --self-test && bash tools/ci/mirror-reset-check.sh' + run "the remote checkout's clean spares a lane's scratch (.igneum-scratch-spare, the fixed prefixes, never -x; the lost-scratch class)" bash -c 'bash tools/ci/scratch-spare-check.sh --self-test && bash tools/ci/scratch-spare-check.sh' run "long-running tools keep their body in one parsed block (the edited-while-running class)" bash -c 'bash tools/ci/whole-body-check.sh --self-test && bash tools/ci/whole-body-check.sh' + run "build-remote without a priority flag bounds suites and benches (nice 10, 32 cores); a gate runs unbounded" bash tools/ci/build-kind-default-check.sh run "no shell assignment hides behind a trailing comment (the swallowed-defaults class)" bash -c 'bash tools/ci/defaults-line-check.sh --self-test && bash tools/ci/defaults-line-check.sh' run "no script kills or finds a process by a plain name or a file name (pgrep/pkill -f literals, ps | grep)" bash -c 'bash tools/ci/kill-by-name-check.sh --self-test && bash tools/ci/kill-by-name-check.sh' run "the identity check's own self-test (excluded research path passes, exported leak fails)" bash tools/ci/identity-check.sh --self-test run "the Windows paths check's own self-test" bash tools/ci/windows-paths-check.sh --self-test run "the red watcher's own self-test (one line per run, posted once)" node tools/ci/red-watch.mjs --self-test run "faucet unit tests" node --test site/api/faucet.test.mjs + run "redesign package data tests (the /api/live contract the pages read)" node tools/site-redesign/tests/data-tests.cjs + run "the home hero's loop never idles in view, stops hidden, resumes without a jump" node tools/site-redesign/tests/hero-loop-test.cjs run "explorer, emission and public stats unit tests" node --test site/lib/explorer.test.mjs site/lib/emission.test.mjs site/api/public-stats.test.mjs run "ship tool self-test" node tools/ship-app.mjs --self-test run "relay unit tests" node --test relay/test/parse.test.mjs relay/test/auth.test.mjs relay/test/wake.test.mjs relay/test/ember.test.mjs run "miner app notice strip and update card tests" node --test app/igneum-app/ui/notices.test.mjs app/igneum-app/ui/update-card.test.mjs app/igneum-app/ui/view.test.mjs app/igneum-app/ui/tune-line.test.mjs run "no secret file names and no 64-hex secrets in the tree" bash -c 'bash tools/ci/no-secrets-check.sh --self-test && bash tools/ci/no-secrets-check.sh' + run "launch gates: every row with its check, the handoff text clean (self-test, then the tree)" bash -c 'node tools/ci/launch-gates-check.mjs --self-test && node tools/ci/launch-gates-check.mjs' + run "income per tier: the public table equals its inputs, the schedule arithmetic" bash -c 'node tools/launch/income-tiers.mjs --check && node --test tools/launch/income-tiers.test.mjs' + run "hash-origin report: a known-finished day and a known-failed day" node --test tools/observer/hash-origin.test.mjs } gated_refs() { diff --git a/tools/ci/scratch-spare-check.sh b/tools/ci/scratch-spare-check.sh new file mode 100755 index 00000000..8363218e --- /dev/null +++ b/tools/ci/scratch-spare-check.sh @@ -0,0 +1,50 @@ +#!/usr/bin/env bash +# The lost-scratch class (7 October 2026, 09:2x UK, the attack-pass lane's hazard AP-H1): infra/build-server/remote-run.sh +# checkout_tree() runs `git clean -fd` on the box mirror of a worktree before every build from any agent, so the attack rows' +# untracked scratch (attack-f3/, attack-f1-venv/, tools/attack/*/target) was deleted by the next build from another row. +# Rule: the clean spares a lane's scratch. It keeps the target and stamp excludes, carries the spare arguments (SPARE_ARGS, +# filled by spare_args from the fixed prefixes attack-*, scratch-*, target-attack-*, .build-remote.log and every glob in the +# mirror-local `.igneum-scratch-spare`), and never carries -x or -X (which would drop .git/info/exclude and the ignored files +# with it). This check reads checkout_tree() and spare_args() and fails when any of that is missing. +# +# tools/ci/scratch-spare-check.sh # exit 1 with the reason +# tools/ci/scratch-spare-check.sh --self-test # the real script passes; a clean line without SPARE_ARGS, one with -x, a script +# # that no longer reads .igneum-scratch-spare, and one missing a fixed prefix fail +set -euo pipefail +cd "$(dirname "$0")/../.." +FIXED='attack-* scratch-* target-attack-* .build-remote.log' +check() { # : exit 0 when checkout_tree's clean keeps its excludes, spares declared scratch and carries no -x + local f="$1" body line fixed p + body=$(sed -n '/^checkout_tree()/,/^}/p' "$f") + [ -n "$body" ] || { echo "scratch-spare: $f has no checkout_tree() function"; return 1; } + line=$(printf '%s\n' "$body" | grep -E '^[[:space:]]*git clean ' | head -1) + [ -n "$line" ] || { echo "scratch-spare: $f: no git clean line in checkout_tree"; return 1; } + if printf '%s\n' "$line" | grep -qE '(^|[[:space:]])-[A-Za-z]*[xX]'; then echo "scratch-spare: $f: the clean carries -x/-X (ignored files and .git/info/exclude would go): $line"; return 1; fi + for p in '-e target ' "-e 'target-*'" "-e '.build-remote-sha-*'" "-e '.cross-remote-sha-*'" '-e sccache'; do + printf '%s \n' "$line" | grep -qF -- "$p" || { echo "scratch-spare: $f: the clean lost the exclude $p: $line"; return 1; } + done + printf '%s\n' "$line" | grep -qF -- '"${SPARE_ARGS[@]}"' || { echo "scratch-spare: $f: the clean does not carry the spare arguments (\"\${SPARE_ARGS[@]}\"): $line"; return 1; } + printf '%s\n' "$body" | grep -qE '^[[:space:]]*spare_args ' || { echo "scratch-spare: $f: checkout_tree never calls spare_args before the clean"; return 1; } + sed -n '/^spare_args()/,/^}/p' "$f" | grep -qF '.igneum-scratch-spare' || { echo "scratch-spare: $f: spare_args() does not read the mirror-local .igneum-scratch-spare file"; return 1; } + fixed=$(grep -E '^SPARE_FIXED=' "$f" | head -1) + [ -n "$fixed" ] || { echo "scratch-spare: $f: no SPARE_FIXED list"; return 1; } + for p in $FIXED; do + printf '%s\n' "$fixed" | grep -qF -- "'$p'" || { echo "scratch-spare: $f: the fixed spare list lacks '$p': $fixed"; return 1; } + done + echo "scratch-spare: $f: the clean keeps its excludes, spares the fixed prefixes and .igneum-scratch-spare, and carries no -x" +} +if [ "${1:-}" = --self-test ]; then + t=$(mktemp -d); trap 'rm -rf "$t"' EXIT + real=infra/build-server/remote-run.sh + check "$real" >/dev/null || { echo "scratch-spare self-test: the real script FAILED the check"; exit 1; } + sed -E '/^[[:space:]]*git clean /s/ "\$\{SPARE_ARGS\[@\]\}"//' "$real" > "$t/no-spare.sh" + if check "$t/no-spare.sh" >/dev/null 2>&1; then echo "scratch-spare self-test: a clean without the spare arguments PASSED (the check is blind)"; exit 1; fi + sed -E '/^[[:space:]]*git clean /s/-qfd /-qfdx /' "$real" > "$t/with-x.sh" + if check "$t/with-x.sh" >/dev/null 2>&1; then echo "scratch-spare self-test: a clean with -x PASSED (the check is blind)"; exit 1; fi + sed '/^spare_args()/,/^}/s/\.igneum-scratch-spare/.somewhere-else/' "$real" > "$t/no-file.sh" + if check "$t/no-file.sh" >/dev/null 2>&1; then echo "scratch-spare self-test: a spare_args that ignores .igneum-scratch-spare PASSED (the check is blind)"; exit 1; fi + sed -E "/^SPARE_FIXED=/s/'scratch-\*' //" "$real" > "$t/no-fixed.sh" + if check "$t/no-fixed.sh" >/dev/null 2>&1; then echo "scratch-spare self-test: a fixed list without scratch-* PASSED (the check is blind)"; exit 1; fi + echo "scratch-spare self-test: the real script passes; no spare arguments, -x, no spare file, and a missing fixed prefix each fail"; exit 0 +fi +check infra/build-server/remote-run.sh diff --git a/tools/ci/site-nav-check.mjs b/tools/ci/site-nav-check.mjs new file mode 100644 index 00000000..38b67f8b --- /dev/null +++ b/tools/ci/site-nav-check.mjs @@ -0,0 +1,26 @@ +#!/usr/bin/env node +// Every served page carries the same header: the mark and wordmark, the six items (Litepaper, Miner, App, Wallet, Live devnet, +// Ledger) and the Download button, in the bar and in the sheet. A page with a shorter nav fails the build and the gate +// (the owner's rule, 7 October 2026: the header has all of these on every page and the mobile header works). +// node tools/ci/site-nav-check.mjs [site-dir] +import { readdirSync, readFileSync } from 'node:fs'; +import { join, dirname } from 'node:path'; +import { fileURLToPath } from 'node:url'; +const site = process.argv[2] || join(dirname(fileURLToPath(import.meta.url)), '..', '..', 'site'); +const ITEMS = [['/litepaper', 'Litepaper'], ['/miner', 'Miner'], ['/app', 'App'], ['/wallet', 'Wallet'], ['/live', 'Live devnet'], ['/ledger', 'Ledger']]; +const pages = readdirSync(site).filter(f => f.endsWith('.html')); +const bad = []; +for (const page of pages) { + const html = readFileSync(join(site, page), 'utf8'); + const nav = html.match(/