diff --git a/docs/analysis/class-v6/connected-state.md b/docs/analysis/class-v6/connected-state.md new file mode 100644 index 000000000..110d463c5 --- /dev/null +++ b/docs/analysis/class-v6/connected-state.md @@ -0,0 +1,124 @@ +# Class v6: the connected-state variant (8 October 2026) + +The experiment of the external review the founder accepted (the 15:4x BST rules): the remaining chip edge (about 2.0x to 2.2x node-for-node, 2.2x to 2.6x a node ahead) survives because a specialist can separate storage, arithmetic and memory scheduling. This lane reorganised the class v5 work, same dataset, same read width (4 bytes), about the same operation count, so that live state feeds each load address, the memory result feeds mixed arithmetic and cross-lane exchange, and that updates the live state for the next address, with a 64-register window per lane that stays necessary across the whole dependent chain. Research class only, behind `--class cssx` in `igneum-pow` (`igneum-pow/src/connected.rs`, branch `class-v6-connected` on the box mirror); never a chain class. + +Every number below is measured unless marked modelled or owed. Times are UK (BST). + +## 1. The structure + +| Item | Class v5 (`mx8+sh256x27`, the control) | Connected state (`cs64s27x16`) | +|---|---|---| +| Registers per lane | 8 | 64 (the window) | +| Per iteration | 64 base instructions with 16 loads, then a 256-instruction block run 27 times | 16 steps: a load, then a 27-instruction block run 16 times | +| Load address | a base register, `x & MASK` (the era stride and site window under an era) | a window register, the same address rule | +| Memory result | xor into the load's destination | xor into `r[m_j]`; block instruction 0 reads it | +| Next address | whatever register the next load reads | written by the block's last instruction (add, sub, xor or shfl) from a fresh spine | +| Result | fold of 8 registers | fold of all 64 (`lo` over the first 32 at 7 i, `hi` over the second 32 at 9 i; the v5 fold at a window of 8) | +| Loads per hash | 128 | 128 | +| ALU instructions per hash | 55,680 (55,296 shadow + 384 base) | 55,296 (0.7 percent fewer) | +| Instruction text per iteration | 320 | 448 | +| Negative controls kept out | | no long program (1,024), no select tree, no wide read (W = 16), no scratchpad | + +The draw (deterministic from the seed words, attempt k re-seeded as every class): per step `a_j` then `m_j != a_j` (and the era window draws); per block instruction the op from the ten non-load families at the v5 weights, the source from the last four spine entries (the memory result first), the destination uniform over the window, the two immediates, the rotation, the selector bit and the shuffle mask. Four rules the first census pass forced, each a construction rather than a filter: + +1. The cover: the first 64 injecting destinations walk a drawn permutation of the window, so every register takes an injecting write (rule (b)); a uniform draw left one register without one in about 70 percent of candidates. +2. The fresh spine: only destinations of add, sub, xor, mad and shfl enter the spine, so every address is fresh by dataflow (rule (a')); with a lossy spine every seed exhausted 256 attempts. +3. Lossy ops feed the next injection: or, mul and mulhi write the register the next injecting instruction of the block writes, so their value enters the chain and no register accumulates a lossy op across the 16 passes (a 16-pass or saturated a register the block never re-injected, a 16-pass mul cleared its low bits: rule (c) refused every candidate). +4. The two closing instructions of a block come from add, sub, xor and shfl (the census lane's rule for a load source's writer): no product on the address writer (a 16-pass mad on the address register read bit z 57.6 at one site). + +The acceptance rule is the sub-version 3 rule over the window: (b), (a') (the fixpoint over the iteration's execution order), (c) over 64 units (constant bits per register, lane-constant sites, saturation at 1 percent of the window's final values, saturated sources, output bias, distinct addresses, the value-level index-bit read judged inside the site's era window), then (c'') at 0.98 and (c''') at 0.995 over 2^20 evaluations per site. (a) holds by construction. + +## 2. Liveness (seed `igneum-v6c/0`, attempt 0, program id 9ad55de91485542b) + +The tool (`igneum-pow liveness --class cs64s27x16 --seed `) walks the unrolled trace of one hash (128 loads, 55,296 ALU instructions). `live` is the backward set at an address: registers whose value just before the load feeds this or any later address. `dep` is the forward set: registers at the previous address whose values feed this address. + +| Measure | Value | +|---|---| +| live before each address | 63 of 64 at every address until the last iteration's tail; iteration 7: 63 62 60 60 60 57 57 54 53 51 45 36 25 20 9 1 | +| registers read by the result | 64 of 64 (the fold) | +| dep per step (the same every iteration, the text repeats) | 1 9 13 14 8 15 7 8 12 14 14 13 10 9 14 9; mean 11.2 of 64 | +| registers touched per block (read or written) | min 16, mean 20.4, max 24 of 64 | +| reads per register per hash | min 384, mean 1,724, max 3,208 | +| writes per register per hash | min 128, mean 866, max 1,664 | +| op mix of the 432 block instructions | add 82, mul 62, xor 51, shfl 51, sub 46, mulhi 39, rotl 35, mad 31, rotr 20, or 15 | + +Meaning: the whole window is necessary over the hash (no register can be dropped or parked for long: the longest gap between writes to one register is under one iteration), and every value is read by a later address, so there is no side calculation a specialist can move to a separate engine. The dependent chain per step is narrow: about 11 of the 64 registers at one address feed the next address through 432 operations, and a block touches about 20. That is the shape a specialist will exploit: a two-level file, about 20 registers hot per step and 44 warm, the hot set moving along the text; the k lane prices exactly that (section 5). The program listing is `liveness.txt` and `program.json` of the pack. + +## 3. Census (the census lane's sub-version 3 harness, `tools/attack/v6-census/v6census.sh`, (c''') 0.995 on, on a rented 5090 host with 40 threads, 16:01 to 16:08 BST) + +| Run | Seeds | Accepted | Exhausted | Rejections per candidate | Mean attempt | Max attempt | Window-bit refusals | Over 6 sigma (reported) | +|---|---|---|---|---|---|---|---|---| +| cs64 no era | 256 | 256 | 0 | 0.283 | 0.39 | 5 | off | 146 of 256 (max z 128) | +| control `mx8+sh256x27` no era (census lane, build-3) | 256 | 256 | 0 | 0.668 | 2.01 | 18 | off | 143 of 256 (max z 97) | +| cs64 eras 0 to 7, window-bit refusal on | 8 x 32 | 256 | 0 | 0.635 | 1.74 | 8 | 306 | 0 (max z 5.9) | +| control eras 0 to 7, refusal on (census lane, build-4) | 8 x 32 | 256 | 0 | 0.830 | 4.87 | 22 | 218 | 0 (max z 5.9) | +| cs64 eras 0 to 7, refusal off | 8 x 32 | 256 | 0 | 0.304 | 0.44 | 2 | off | 94 of 256 (max z 71.5) | + +The no-era rejections are all rule (c) (constant bits, saturation or bias in the 64-unit test); the control's are mostly (a') and (a), which this class satisfies by construction. The window-bit refusals sit on eras 0, 1, 4, 5 and 6 (55 to 64 each) and nearly vanish on eras 2 and 3 (0 and 1): the product-bit class (a product's low bits reaching an address bit through the era stride), the same class the control carries and the layer-1 index fold removes; this class does not change it either way. + +F8 form (`igneum-pow cs-uniform`, 16 seeds x 2^20 nonces, no era): the top 0.1 percent item share reads 0.9987 to 1.0016 of a uniform control of the same size (the control class 0.9993 to 1.0016); the worst per-site distinct ratio 0.9941 (seed 9, site 9; the sequential-nonce sample of the F8 tool, the acceptance's own 2^20 sample passed 0.995 on every accepted program). + +Meaning: the class censuses at least as well as v5 on every instrument of the harness and takes fewer attempts; it inherits v5's product-bit bias and the fix is the same fold. The acceptance costs about 3.7 s per candidate on one core (the (c'') pass dominates, 7 G lane-ops), against v5's 2.8 s. + +## 4. GPU cost + +Instrument: the class v5 nvcc harness (`proto-newpow/class-v5/bench.cu` on `box/ds55-v5`, the v5 design page's 4090 rows), compiled per pack with `-Xptxas -v`, 250 batches of 2^24, nvidia-smi at 1 Hz, both packs on the same card minutes apart; vectors 3 of 3 PASS and the dataset self-test PASS on every row. The cs64 pack is over the class v4 memory-hard dataset (no leaves); v5-genesis carries its 93 leaves. Stock means the card's own power limit and no clock lock. + +| Card | Pack | MH/s | Mean W | Microjoules per hash | Registers per thread | Spills | Resident blocks per SM (1 warp per block) | Fingerprint of 2^24 at base 0 | +|---|---|---|---|---|---|---|---|---| +| RTX 5090 (Vast 54862507, driver 580.159.03, 575 W cap), stock | cs64s27x16 | 64.93 | 574.8 | 8.853 | 80 | 0 | 24 | ad0cec2a42c84aff | +| RTX 5090, the same card | v5-genesis | 65.30 | 574.8 | 8.803 | 48 | 0 | 24 | ae74193ddad19e19 | +| RTX 4090 (RunPod 386yytbh4bkfnz, driver 580.159.04, 450 W cap), stock | cs64s27x16 | 62.44 | 268.8 | 4.305 | 87 | 0 | 20 | ad0cec2a42c84aff | +| RTX 4090, the same card | v5-genesis | 62.44 | 271.3 | 4.345 | 32 | 0 | 24 | ae74193ddad19e19 | +| RTX 5090 on PC 1 at the 1,300 MHz lock | both | OWED: PC 1 booked to 17:40 BST; the bound pack and the kit are at build-1:/srv/builds/igneum-wt-connected/cs-kit (sha c9aff54aaf10d79e) and the hash lane publishes the job when PC 1 frees | | | | | | | + +The kit worker (the brief's instrument, `igneum-worker-cuda --bench --batch-log2 24 --batches 250`, the class v5 kit's NVRTC worker of 7 October loading the pack's `kernel_bound.cu`; check PASS on both packs): + +| Card | Pack | MH/s | Mean W | Microjoules per hash | Registers per thread | Fingerprint | +|---|---|---|---|---|---|---| +| RTX 5090 (the Vast card above), stock | cs64s27x16 (bound pack) | 62.88 | 574.2 | 9.131 | 80 | ad0cec2a42c84aff | +| RTX 5090, the same card | v5-genesis | 62.96 | 571.4 | 9.076 | 48 | ae74193ddad19e19 | +| RTX 4090 (the RunPod card above), stock | cs64s27x16 (bound pack) | 62.41 | 269.4 | 4.317 | 87 | ad0cec2a42c84aff | +| RTX 4090, the same card | v5-genesis | 62.39 | 271.9 | 4.358 | 32 | ae74193ddad19e19 | + +Both instruments agree with each other on each card (the harness and the worker within 3 percent of rate) and agree on the comparison: the window moves energy per hash by +0.6 percent on the 5090 (harness and worker alike) and by -0.9 percent on the 4090 (harness and worker alike), inside the run-to-run noise of a power reading. The 4090 is not at its cap (269 W of 450) and both packs read the same rate to three figures, so there the hash is bound by the memory chain, not the ALU or the register file; the 5090 is at its 575 W cap and the window costs under 1 percent of rate. (The fingerprints are the same on both cards and both instruments: ad0cec2a42c84aff for cs64, ae74193ddad19e19 for v5-genesis.) + +Meaning: at stock the window costs the 5090 0.6 percent of energy per hash against a 10 percent budget; the compiled allocation is 80 registers per thread with no spill, so the window is in registers, not local memory, and the occupancy under this harness is the same as v5's. The harness reads 65 MH/s where the NVRTC worker reads about twice that on a 5090 (one warp per block, 24 resident blocks); the ratio between two packs on the same harness is the measurement, the absolute rate is not. The lock row is where the energy comparison binds (the 5090 at the lock reads 2.33 microjoules per hash on v5); the stock rows say the card is bound by its power cap in both cases and the window moves the rate by under 1 percent. + +## 5. The chip side + +The k lane (floor lane 2) priced the re-optimised core on the drawn program at 17:2x BST (synthesis only, a model and never a lower bound; its placed row is due 21:00 as an amendment). The core: 8 lanes, a 64 x 32-bit window per lane in clock-gated flops (a macro file reads within 5 percent), a 512-entry imem holding the 448-instruction text, one in-order op per cycle per lane (the spine's ILP is met by lane count, which is free), every class unit, the load's fold on the address path; gate-level random-input VCD, every pin annotated; 253,059 cells. + +| Row (the k lane's) | pJ per lane-op, ASAP7 | N5 (the card's node) | N3 | N2 | k at the 1,300 lock, N5 / N3 / N2 | k at stock, N5 / N3 | +|---|---|---|---|---|---|---| +| cs64s27x16, the re-optimised core (gated window, 512 imem) | 6.3 | 4.4 | 3.2 | 2.3 | 0.71 / 0.51 / 0.37 | 0.39 / 0.28 | +| the same window on the class v4 draw, 256 imem | 6.2 | 4.3 | 3.1 | 2.2 | 0.70 / 0.50 / 0.36 | 0.38 / 0.27 | +| the adversary's 32-register base, gated (the genesis window) | 4.5 | 3.2 | 2.3 | 1.6 | 0.51 / 0.37 / 0.26 | 0.28 / 0.20 | +| the GPU-shaped 64-register core, ungated (shadow-k.md, the earlier default) | 9.7 | 6.8 | 4.9 | 3.5 | 1.09 / 0.78 / 0.56 | 0.60 / 0.43 | + +What the adversary's re-optimisation did to each part of the structure: the gated file charges only the register written, so the whole-window liveness costs it nothing beyond the write it would make anyway and the hot-20 banking of section 2 is not even needed; the 16-pass loop and the 448 text cost the shared imem 0.1 pJ per lane-op; the narrow per-step chain sets the lane count, which is free. The window itself is worth +1.2 pJ per lane-op at N5 over the genesis window (+0.14 of k at the lock), the same knob as the design document's 64-register row; the connected organisation around it adds about 0.1 pJ. The placed ungated core came in 64 percent over its synthesis, so the placed figure is expected near 8 to 10 pJ at ASAP7 (k node-for-node near 0.9 to 1.1, approximate); both rows move together and the ratio below holds. + +## 6. The score and the verdict + +E_GPU over E_adversary, absolute convention, GDDR7 board (E_mem 0.466 microjoules per hash), E_chip = E_mem + 55,296 x e_chip, E_GPU = the 5090 at the lock (2.33 microjoules per hash on class v5) x 1.006 for the window (the stock rows of section 4; the lock row is owed): + +| Core | Node-for-node (N5) | A node ahead (N3) | Two nodes (N2) | +|---|---|---|---| +| cs64s27x16, re-optimised | 2.344 / (0.466 + 0.243) = 3.3x | 2.344 / (0.466 + 0.177) = 3.6x | 2.344 / (0.466 + 0.127) = 4.0x | +| the genesis window (the control) | 2.33 / (0.466 + 0.177) = 3.6x | 2.33 / (0.466 + 0.127) = 3.9x | 2.33 / (0.466 + 0.088) = 4.2x | +| the window's effect on the chip's edge | 1.10x | 1.08x | 1.05x | + +On the placed figures (both rows 64 percent higher) the pair reads about 2.2x and 2.4x node-for-node and the ratio stays near 1.1x. The gate was 1.25x node-for-node for the 1.5x one-node-ahead ambition; the row reads 1.10x node-for-node and 1.08x a node ahead. + +**Verdict: KILL as a class.** The hypothesis was that a connected organisation of the same work, with the window independently necessary across the whole chain, would deny a specialist its separation of storage, arithmetic and scheduling. It does not: the liveness rows show the window is necessary (63 of 64 at every address) and the chip answers with a clock-gated file that pays per write, not per live register, so necessity costs it nothing; the only term that reaches the chip is the window's own width (+0.14 k at the lock), which the design document already holds as its one robust core knob, and the connected structure adds about 0.1 pJ around it. The GPU side passes its budget with room (+0.6 percent of energy per hash at stock on the 5090, -0.9 percent on the 4090, 80 to 87 registers per thread with no spill), and the census passes every instrument with fewer attempts than v5; neither moves the score. The founder's accepted review stands in a sharper form than before: a specialist's edge against this family is a per-op energy ratio on a known op mix, and reorganising the dependency graph of the same ops does not change what an op costs on either side. + +What is kept: the generator variant and the liveness tool (research class, behind the flag) for the v7 tests below; the measured fact that a 64-register window costs a card under 1 percent at stock, which fixes the design document's modelled "about 0 rate" row; the kit worker and nvcc harness agreement on two cards. What is withdrawn: the "connected state" line as a resistance mechanism. + +## 7. What a v7 variant would test next + +- The index fold on the address (the layer-1 row) in this class, which removes the window-bit refusals on eras 0, 1, 4, 5 and 6 for the control and this class alike. +- A wider per-step chain: a spine of depth 8 to 16 so `dep` rises from about 11 toward the window, at the cost of ILP on the card (measure the rate first; the chain per step is what a two-level file exploits). +- The window at 32 and 16 (`cs32s27x16`, `cs16s27x16`) for the k curve, and the block at 16 x 27 (`cs64s16x27`, text 272) if the imem matters to the re-optimised core. +- The op-mix re-weight of the census lane at this structure (the two closing instructions already take the injecting table). +- The PC 1 lock row (informational now: the verdict does not turn on it; it lands as an amendment if PC 1 runs it). +- A knob that reaches a gated file: not more live state but more WRITES per op the chip cannot skip (every op writing two registers, or a window write per load), priced against the card's own write cost first; the k lane's placed row at 21:00 says whether even that moves k. diff --git a/docs/analysis/class-v6/logs/connected/bench-4090.log b/docs/analysis/class-v6/logs/connected/bench-4090.log new file mode 100644 index 000000000..83058c530 --- /dev/null +++ b/docs/analysis/class-v6/logs/connected/bench-4090.log @@ -0,0 +1,46 @@ +RESULT start 2026-10-08T15:14:09Z host=dbd4e396219f arch=sm_89 card=NVIDIA GeForce RTX 4090, 580.159.04, 450.00 W +RESULT pack packs/cs64-v6c0 +RESULT ptxas packs/cs64-v6c0 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads +RESULT ptxas packs/cs64-v6c0 ptxas info : Used 87 registers, used 0 barriers, 376 bytes cmem[0], 8 bytes cmem[2] +RESULT ptxas packs/cs64-v6c0 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads +RESULT ptxas packs/cs64-v6c0 ptxas info : Used 40 registers, used 0 barriers, 372 bytes cmem[0] +RESULT ptxas packs/cs64-v6c0 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads +RESULT ptxas packs/cs64-v6c0 ptxas info : Used 43 registers, used 0 barriers, 364 bytes cmem[0] +RESULT bench packs/cs64-v6c0 class-v5 bench pack "igneum-v6c/0" class control generator 2 (test harness: no pool, no network, no wallet) +RESULT bench packs/cs64-v6c0 GPU: NVIDIA GeForce RTX 4090 (128 SMs, cc 8.9, 24081 MiB), CUDA driver 13.0 runtime 12.8 +RESULT bench packs/cs64-v6c0 hash kernel: 87 registers/thread, 20 resident blocks/SM at 1 warp/block +RESULT bench packs/cs64-v6c0 device memory at start: 395 MiB used of 24081 MiB +RESULT bench packs/cs64-v6c0 cache fill (GPU): 1.84 ms first, 1.82 ms second +RESULT bench packs/cs64-v6c0 cache head and last 16 words against the pack: PASS +RESULT bench packs/cs64-v6c0 dataset build (GPU): 30.57 ms first, 30.54 ms second (16777216 items, 1024 MiB) +RESULT bench packs/cs64-v6c0 device memory after the build: 1675 MiB used +RESULT bench packs/cs64-v6c0 dataset self-test: head PASS, last PASS, samples 64 of 64 +RESULT bench packs/cs64-v6c0 vector warps against the pack: 3 of 3 PASS +RESULT bench packs/cs64-v6c0 fingerprint of 2^24 outputs at base 0: ad0cec2a42c84aff (lane 0 c2b2466c00d3f12b) +RESULT bench packs/cs64-v6c0 hash rate: 62.436 MH/s over 250 batches of 2^24 (GPU event time 67177.7 ms) +RESULT bench packs/cs64-v6c0 RESULT pack=igneum-v6c/0 class=control build_ms=30.54 rate_mhs=62.436 vectors=3/3 +RESULT smi packs/cs64-v6c0 samples 64 mean_power_w 268.8 mean_sm_mhz 2811 mean_mem_mhz 10251 +RESULT pack v5-genesis +RESULT ptxas v5-genesis cc1plus: fatal error: ../../bench.cu: No such file or directory +RESULT ptxas v5-genesis 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads +RESULT ptxas v5-genesis ptxas info : Used 32 registers, used 0 barriers, 376 bytes cmem[0] +RESULT ptxas v5-genesis 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads +RESULT ptxas v5-genesis ptxas info : Used 40 registers, used 0 barriers, 384 bytes cmem[0] +RESULT ptxas v5-genesis 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads +RESULT ptxas v5-genesis ptxas info : Used 43 registers, used 0 barriers, 364 bytes cmem[0] +RESULT bench v5-genesis class-v5 bench pack "igneum-genesis" class v5 generator 5 (test harness: no pool, no network, no wallet) +RESULT bench v5-genesis GPU: NVIDIA GeForce RTX 4090 (128 SMs, cc 8.9, 24081 MiB), CUDA driver 13.0 runtime 12.8 +RESULT bench v5-genesis hash kernel: 32 registers/thread, 24 resident blocks/SM at 1 warp/block +RESULT bench v5-genesis device memory at start: 395 MiB used of 24081 MiB +RESULT bench v5-genesis cache fill (GPU): 1.83 ms first, 1.81 ms second +RESULT bench v5-genesis cache head and last 16 words against the pack: PASS +RESULT bench v5-genesis leaves: 93 x 64 B from leaves.bin (5952 bytes), FNV-1a 64 850ad094a937a5c5 against the pack's 850ad094a937a5c5: PASS; state root 1c583d352bb9c75a06dadb8d82d42836ebe8afa82d0b413be87bf921741f1526, chain block af89be5ddbadb6f6b4aee28ac8f249713be5d4c12621e3cea7f83ceada3c66b3 (159357) +RESULT bench v5-genesis dataset build (GPU): 30.80 ms first, 30.75 ms second (16777216 items, 1024 MiB) +RESULT bench v5-genesis device memory after the build: 1677 MiB used +RESULT bench v5-genesis dataset self-test: head PASS, last PASS, samples 64 of 64 +RESULT bench v5-genesis vector warps against the pack: 3 of 3 PASS +RESULT bench v5-genesis fingerprint of 2^24 outputs at base 0: ae74193ddad19e19 (lane 0 61b73fdc4b19aa6e) +RESULT bench v5-genesis hash rate: 62.437 MH/s over 250 batches of 2^24 (GPU event time 67176.1 ms) +RESULT bench v5-genesis RESULT pack=igneum-genesis class=v5 build_ms=30.75 rate_mhs=62.437 vectors=3/3 +RESULT smi v5-genesis samples 64 mean_power_w 271.3 mean_sm_mhz 2805 mean_mem_mhz 10251 +RESULT end 2026-10-08T15:16:34Z diff --git a/docs/analysis/class-v6/logs/connected/bench-5090c.log b/docs/analysis/class-v6/logs/connected/bench-5090c.log new file mode 100644 index 000000000..364c48cb4 --- /dev/null +++ b/docs/analysis/class-v6/logs/connected/bench-5090c.log @@ -0,0 +1,40 @@ +RESULT start 2026-10-08T15:09:57Z host=f271665b754f arch=sm_120 card=NVIDIA GeForce RTX 5090, 580.159.03, 575.00 W +RESULT pack packs/cs64-v6c0 +RESULT ptxas packs/cs64-v6c0 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads +RESULT ptxas packs/cs64-v6c0 ptxas info : Used 80 registers, used 0 barriers +RESULT ptxas packs/cs64-v6c0 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads +RESULT ptxas packs/cs64-v6c0 ptxas info : Used 38 registers, used 0 barriers +RESULT ptxas packs/cs64-v6c0 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads +RESULT ptxas packs/cs64-v6c0 ptxas info : Used 41 registers, used 0 barriers +RESULT bench packs/cs64-v6c0 class-v5 bench pack "igneum-v6c/0" class control generator 2 (test harness: no pool, no network, no wallet) +RESULT bench packs/cs64-v6c0 GPU: NVIDIA GeForce RTX 5090 (170 SMs, cc 12.0, 32109 MiB), CUDA driver 13.0 runtime 12.8 +RESULT bench packs/cs64-v6c0 hash kernel: 80 registers/thread, 24 resident blocks/SM at 1 warp/block +RESULT bench packs/cs64-v6c0 device memory at start: 6188 MiB used of 32109 MiB +RESULT bench packs/cs64-v6c0 cache fill (GPU): 0.65 ms first, 0.65 ms second +RESULT bench packs/cs64-v6c0 cache head and last 16 words against the pack: PASS +RESULT bench packs/cs64-v6c0 dataset build (GPU): 29.75 ms first, 27.68 ms second (16777216 items, 1024 MiB) +RESULT bench packs/cs64-v6c0 device memory after the build: 7468 MiB used +RESULT bench packs/cs64-v6c0 dataset self-test: head PASS, last PASS, samples 64 of 64 +RESULT bench packs/cs64-v6c0 vector warps against the pack: 3 of 3 PASS +RESULT bench packs/cs64-v6c0 fingerprint of 2^24 outputs at base 0: ad0cec2a42c84aff (lane 0 c2b2466c00d3f12b) +RESULT bench packs/cs64-v6c0 hash rate: 64.929 MH/s over 250 batches of 2^24 (GPU event time 64598.6 ms) +RESULT bench packs/cs64-v6c0 RESULT pack=igneum-v6c/0 class=control build_ms=27.68 rate_mhs=64.929 vectors=3/3 +RESULT smi packs/cs64-v6c0 samples 128 mean_power_w 574.8 mean_sm_mhz 2778 mean_mem_mhz 13801 +RESULT pack v5-genesis +RESULT ptxas v5-genesis cc1plus: fatal error: ../../bench.cu: No such file or directory +RESULT bench v5-genesis class-v5 bench pack "igneum-genesis" class v5 generator 5 (test harness: no pool, no network, no wallet) +RESULT bench v5-genesis GPU: NVIDIA GeForce RTX 5090 (170 SMs, cc 12.0, 32109 MiB), CUDA driver 13.0 runtime 12.8 +RESULT bench v5-genesis hash kernel: 48 registers/thread, 24 resident blocks/SM at 1 warp/block +RESULT bench v5-genesis device memory at start: 6188 MiB used of 32109 MiB +RESULT bench v5-genesis cache fill (GPU): 0.65 ms first, 0.65 ms second +RESULT bench v5-genesis cache head and last 16 words against the pack: PASS +RESULT bench v5-genesis leaves: 93 x 64 B from leaves.bin (5952 bytes), FNV-1a 64 850ad094a937a5c5 against the pack's 850ad094a937a5c5: PASS; state root 1c583d352bb9c75a06dadb8d82d42836ebe8afa82d0b413be87bf921741f1526, chain block af89be5ddbadb6f6b4aee28ac8f249713be5d4c12621e3cea7f83ceada3c66b3 (159357) +RESULT bench v5-genesis dataset build (GPU): 27.57 ms first, 27.53 ms second (16777216 items, 1024 MiB) +RESULT bench v5-genesis device memory after the build: 7470 MiB used +RESULT bench v5-genesis dataset self-test: head PASS, last PASS, samples 64 of 64 +RESULT bench v5-genesis vector warps against the pack: 3 of 3 PASS +RESULT bench v5-genesis fingerprint of 2^24 outputs at base 0: ae74193ddad19e19 (lane 0 61b73fdc4b19aa6e) +RESULT bench v5-genesis hash rate: 65.303 MH/s over 250 batches of 2^24 (GPU event time 64228.4 ms) +RESULT bench v5-genesis RESULT pack=igneum-genesis class=v5 build_ms=27.53 rate_mhs=65.303 vectors=3/3 +RESULT smi v5-genesis samples 126 mean_power_w 574.8 mean_sm_mhz 2788 mean_mem_mhz 13801 +RESULT end 2026-10-08T15:12:13Z diff --git a/docs/analysis/class-v6/logs/connected/cs64-era-bt.tsv b/docs/analysis/class-v6/logs/connected/cs64-era-bt.tsv new file mode 100644 index 000000000..5220b4c2a --- /dev/null +++ b/docs/analysis/class-v6/logs/connected/cs64-era-bt.tsv @@ -0,0 +1,259 @@ +# cs64-era-bt class cs64s27x16 eras [0,1,2,3,4,5,6,7] seeds 32 era-widths 4 weights base bittest 1 bin 54b905920b91becc start 2026-10-08T15:01:08Z host f271665b754f threads 40 +cand era seed candidates accepted attempt bit_z bit_site bit_bit reasons +cs64-era-bt 0 16 9 1 8 3.2 7 8 c,=7;c=1; +cs64-era-bt 0 21 2 1 1 3.2 14 21 c=1; +cs64-era-bt 0 20 1 1 0 3.8 10 1 +cs64-era-bt 0 30 2 1 1 3.0 3 18 c,=1; +cs64-era-bt 0 19 3 1 2 3.6 1 19 c,=2; +cs64-era-bt 1 1 2 1 1 2.8 6 20 c=1; +cs64-era-bt 0 12 5 1 4 3.5 10 25 c,=3;c=1; +cs64-era-bt 0 18 4 1 3 3.2 11 13 c,=3; +cs64-era-bt 0 17 7 1 6 4.2 4 19 c,=4;c=2; +cs64-era-bt 0 6 1 1 0 5.1 3 19 +cs64-era-bt 0 28 5 1 4 5.9 12 19 c,=2;c=2; +cs64-era-bt 0 0 9 1 8 4.2 9 19 c,=5;c=3; +cs64-era-bt 0 5 2 1 1 3.9 5 1 c=1; +cs64-era-bt 0 29 1 1 0 4.2 8 22 +cs64-era-bt 1 0 9 1 8 3.2 14 26 c,=5;c=3; +cs64-era-bt 0 11 2 1 1 3.1 5 0 c,=1; +cs64-era-bt 0 7 4 1 3 2.9 11 20 c,=3; +cs64-era-bt 0 15 1 1 0 2.8 14 16 +cs64-era-bt 1 7 4 1 3 3.3 12 8 c,=3; +cs64-era-bt 0 25 2 1 1 3.3 2 14 c=1; +cs64-era-bt 0 13 5 1 4 3.2 13 11 c,=4; +cs64-era-bt 0 4 1 1 0 3.2 12 20 +cs64-era-bt 0 31 3 1 2 3.0 1 6 c,=1;c=1; +cs64-era-bt 0 22 1 1 0 3.0 1 19 +cs64-era-bt 0 26 3 1 2 3.4 3 13 c,=2; +cs64-era-bt 0 14 6 1 5 3.5 1 19 c,=4;c=1; +cs64-era-bt 0 10 4 1 3 3.0 0 18 c=2;c,=1; +cs64-era-bt 1 2 1 1 0 2.9 15 20 +cs64-era-bt 1 4 3 1 2 3.2 7 22 c,=2; +cs64-era-bt 0 27 2 1 1 3.9 15 19 c,=1; +cs64-era-bt 0 9 1 1 0 3.1 1 17 +cs64-era-bt 1 3 1 1 0 3.3 15 7 +cs64-era-bt 0 3 1 1 0 2.7 12 10 +cs64-era-bt 1 5 2 1 1 3.6 4 16 c=1; +cs64-era-bt 0 23 3 1 2 3.7 3 20 c,=2; +cs64-era-bt 0 8 7 1 6 5.3 8 19 c,=5;c=1; +cs64-era-bt 1 6 9 1 8 2.8 14 19 c,=6;c=2; +cs64-era-bt 0 1 6 1 5 3.3 0 8 c,=3;c=2; +cs64-era-bt 0 2 1 1 0 2.8 9 21 +cs64-era-bt 0 24 6 1 5 3.0 6 9 c,=5; +cs64-era-bt 1 8 7 1 6 5.3 8 6 c,=5;c=1; +cs64-era-bt 1 14 6 1 5 2.9 1 6 c,=4;c=1; +cs64-era-bt 1 15 1 1 0 3.2 6 1 +cs64-era-bt 1 22 1 1 0 3.3 4 25 +cs64-era-bt 1 11 2 1 1 3.1 3 6 c,=1; +cs64-era-bt 1 9 1 1 0 4.0 11 0 +cs64-era-bt 1 19 3 1 2 3.2 5 13 c,=2; +cs64-era-bt 1 10 4 1 3 4.0 10 17 c=2;c,=1; +cs64-era-bt 1 30 2 1 1 3.1 15 15 c,=1; +cs64-era-bt 1 13 5 1 4 3.3 7 3 c,=4; +cs64-era-bt 2 1 2 1 1 3.3 0 4 c=1; +cs64-era-bt 1 25 2 1 1 3.3 14 25 c,=1; +cs64-era-bt 1 12 5 1 4 3.1 2 9 c,=3;c=1; +cs64-era-bt 2 15 1 1 0 3.0 13 7 +cs64-era-bt 1 28 3 1 2 3.6 4 18 c,=1;c=1; +cs64-era-bt 1 16 9 1 8 3.3 13 18 c,=7;c=1; +cs64-era-bt 1 17 7 1 6 2.9 7 25 c,=4;c=2; +cs64-era-bt 1 20 1 1 0 3.0 15 9 +cs64-era-bt 1 21 2 1 1 2.6 11 19 c=1; +cs64-era-bt 2 5 2 1 1 3.0 10 12 c=1; +cs64-era-bt 2 13 2 1 1 3.1 2 26 c=1; +cs64-era-bt 1 27 2 1 1 5.8 15 6 c,=1; +cs64-era-bt 2 12 2 1 1 2.8 13 23 c=1; +cs64-era-bt 1 18 4 1 3 3.4 0 5 c,=3; +cs64-era-bt 1 29 1 1 0 3.9 10 6 +cs64-era-bt 1 31 4 1 3 3.5 1 23 c=2;c,=1; +cs64-era-bt 2 11 2 1 1 3.0 12 15 c=1; +cs64-era-bt 1 23 1 1 0 4.8 12 6 +cs64-era-bt 1 26 3 1 2 3.5 5 8 c,=2; +cs64-era-bt 2 3 1 1 0 2.6 11 1 +cs64-era-bt 1 24 6 1 5 2.9 0 19 c,=5; +cs64-era-bt 2 16 1 1 0 3.0 7 12 +cs64-era-bt 2 4 1 1 0 2.7 0 10 +cs64-era-bt 2 8 2 1 1 3.5 13 24 c=1; +cs64-era-bt 2 0 2 1 1 3.1 5 25 c=1; +cs64-era-bt 2 9 1 1 0 2.6 6 1 +cs64-era-bt 2 6 1 1 0 3.1 0 1 +cs64-era-bt 2 10 1 1 0 3.1 2 20 +cs64-era-bt 2 14 1 1 0 3.2 3 15 +cs64-era-bt 2 2 1 1 0 3.3 0 0 +cs64-era-bt 2 7 2 1 1 3.2 9 24 c=1; +cs64-era-bt 2 17 1 1 0 2.7 10 2 +cs64-era-bt 2 18 1 1 0 3.2 3 11 +cs64-era-bt 2 26 2 1 1 4.6 1 26 c=1; +cs64-era-bt 2 21 2 1 1 2.8 15 4 c=1; +cs64-era-bt 2 29 1 1 0 3.5 11 7 +cs64-era-bt 2 23 1 1 0 3.7 15 20 +cs64-era-bt 2 24 1 1 0 3.5 3 11 +cs64-era-bt 2 19 3 1 2 3.1 8 20 c=2; +cs64-era-bt 2 20 1 1 0 2.8 10 3 +cs64-era-bt 3 5 2 1 1 3.1 3 20 c=1; +cs64-era-bt 3 4 1 1 0 3.7 9 10 +cs64-era-bt 2 31 1 1 0 3.3 15 18 +cs64-era-bt 2 22 1 1 0 2.9 5 1 +cs64-era-bt 3 11 2 1 1 3.2 6 13 c,=1; +cs64-era-bt 3 1 2 1 1 3.3 9 13 c=1; +cs64-era-bt 2 30 1 1 0 3.1 8 20 +cs64-era-bt 3 16 1 1 0 3.2 13 0 +cs64-era-bt 3 2 1 1 0 3.1 3 25 +cs64-era-bt 3 8 2 1 1 3.3 0 14 c=1; +cs64-era-bt 3 0 2 1 1 3.2 0 7 c=1; +cs64-era-bt 2 28 2 1 1 3.0 2 23 c=1; +cs64-era-bt 2 27 1 1 0 3.3 9 18 +cs64-era-bt 3 14 1 1 0 2.8 2 18 +cs64-era-bt 2 25 2 1 1 3.1 2 7 c=1; +cs64-era-bt 3 20 1 1 0 3.4 2 2 +cs64-era-bt 3 6 1 1 0 3.1 2 9 +cs64-era-bt 3 18 1 1 0 2.8 9 2 +cs64-era-bt 3 22 1 1 0 3.0 11 11 +cs64-era-bt 3 9 1 1 0 3.4 3 9 +cs64-era-bt 3 3 1 1 0 3.3 2 14 +cs64-era-bt 3 10 1 1 0 3.8 5 4 +cs64-era-bt 3 15 1 1 0 2.7 7 3 +cs64-era-bt 3 13 2 1 1 3.1 0 25 c=1; +cs64-era-bt 3 12 2 1 1 3.4 14 17 c=1; +cs64-era-bt 3 7 2 1 1 3.2 8 17 c=1; +cs64-era-bt 3 19 3 1 2 3.3 13 17 c=2; +cs64-era-bt 3 26 2 1 1 3.3 5 16 c=1; +cs64-era-bt 3 21 2 1 1 3.0 0 15 c=1; +cs64-era-bt 3 29 1 1 0 3.0 5 7 +cs64-era-bt 3 31 1 1 0 3.4 15 8 +cs64-era-bt 3 17 1 1 0 3.0 2 12 +cs64-era-bt 3 23 1 1 0 2.9 3 25 +cs64-era-bt 3 25 2 1 1 3.2 13 6 c=1; +cs64-era-bt 4 1 2 1 1 3.3 12 22 c=1; +cs64-era-bt 3 24 1 1 0 3.5 13 5 +cs64-era-bt 3 27 1 1 0 2.9 15 13 +cs64-era-bt 3 28 2 1 1 4.4 15 0 c=1; +cs64-era-bt 4 12 5 1 4 3.6 7 23 c,=3;c=1; +cs64-era-bt 3 30 1 1 0 2.8 8 20 +cs64-era-bt 4 10 4 1 3 3.1 11 16 c=2;c,=1; +cs64-era-bt 4 6 1 1 0 5.0 3 10 +cs64-era-bt 4 2 1 1 0 2.9 10 22 +cs64-era-bt 4 0 9 1 8 3.7 9 10 c,=5;c=3; +cs64-era-bt 4 4 3 1 2 2.8 4 24 c,=2; +cs64-era-bt 4 5 2 1 1 3.3 15 27 c=1; +cs64-era-bt 4 11 2 1 1 3.7 8 16 c,=1; +cs64-era-bt 4 3 1 1 0 2.7 10 11 +cs64-era-bt 4 7 4 1 3 4.4 11 10 c,=3; +cs64-era-bt 4 19 3 1 2 3.4 2 0 c,=2; +cs64-era-bt 4 13 5 1 4 3.1 15 14 c,=3;c=1; +cs64-era-bt 4 8 7 1 6 5.1 12 10 c,=5;c=1; +cs64-era-bt 4 16 9 1 8 2.7 5 8 c,=7;c=1; +cs64-era-bt 4 15 1 1 0 3.2 14 25 +cs64-era-bt 4 9 1 1 0 3.7 6 8 +cs64-era-bt 4 24 6 1 5 3.7 7 11 c,=5; +cs64-era-bt 4 14 6 1 5 3.3 3 20 c,=4;c=1; +cs64-era-bt 4 21 2 1 1 2.8 8 10 c=1; +cs64-era-bt 4 31 4 1 3 3.4 3 20 c=2;c,=1; +cs64-era-bt 4 29 1 1 0 3.7 10 9 +cs64-era-bt 4 17 7 1 6 3.6 8 12 c,=4;c=2; +cs64-era-bt 4 28 3 1 2 3.3 8 6 c,=1;c=1; +cs64-era-bt 4 25 2 1 1 3.3 0 22 c=1; +cs64-era-bt 4 18 4 1 3 3.4 3 16 c,=3; +cs64-era-bt 4 20 1 1 0 3.2 9 11 +cs64-era-bt 5 7 4 1 3 4.0 11 22 c,=3; +cs64-era-bt 4 22 1 1 0 3.2 8 24 +cs64-era-bt 4 30 2 1 1 2.7 7 14 c,=1; +cs64-era-bt 5 1 2 1 1 3.2 9 2 c=1; +cs64-era-bt 4 26 3 1 2 3.6 12 24 c,=2; +cs64-era-bt 4 23 1 1 0 5.8 12 10 +cs64-era-bt 4 27 3 1 2 4.0 15 21 c,=2; +cs64-era-bt 5 3 1 1 0 3.1 5 8 +cs64-era-bt 5 2 1 1 0 3.0 2 6 +cs64-era-bt 5 5 2 1 1 3.5 14 23 c=1; +cs64-era-bt 5 6 1 1 0 4.6 3 22 +cs64-era-bt 5 8 7 1 6 5.2 8 22 c,=5;c=1; +cs64-era-bt 5 0 9 1 8 2.7 8 23 c,=5;c=3; +cs64-era-bt 5 4 3 1 2 3.0 12 20 c,=2; +cs64-era-bt 5 9 1 1 0 4.1 8 7 +cs64-era-bt 5 12 5 1 4 3.2 12 13 c,=3;c=1; +cs64-era-bt 5 14 6 1 5 3.7 1 22 c,=4;c=1; +cs64-era-bt 5 11 2 1 1 3.1 4 11 c,=1; +cs64-era-bt 5 10 4 1 3 3.2 6 5 c=2;c,=1; +cs64-era-bt 5 15 1 1 0 3.6 13 2 +cs64-era-bt 5 16 9 1 8 2.8 15 2 c,=7;c=1; +cs64-era-bt 5 20 1 1 0 3.3 2 16 +cs64-era-bt 5 21 2 1 1 3.1 10 16 c=1; +cs64-era-bt 5 17 7 1 6 3.0 5 19 c,=4;c=2; +cs64-era-bt 5 19 3 1 2 2.7 14 24 c,=2; +cs64-era-bt 5 13 5 1 4 3.2 10 13 c,=4; +cs64-era-bt 5 29 1 1 0 3.6 12 26 +cs64-era-bt 5 22 1 1 0 3.4 0 16 +cs64-era-bt 5 25 2 1 1 3.0 5 1 c=1; +cs64-era-bt 5 18 4 1 3 2.8 11 4 c,=3; +cs64-era-bt 5 30 2 1 1 3.0 15 21 c,=1; +cs64-era-bt 5 24 6 1 5 2.9 14 1 c,=5; +cs64-era-bt 5 23 1 1 0 5.7 12 22 +cs64-era-bt 5 27 2 1 1 5.0 15 22 c,=1; +cs64-era-bt 5 28 5 1 4 3.2 12 22 c,=2;c=2; +cs64-era-bt 6 5 2 1 1 2.8 5 11 c=1; +cs64-era-bt 5 26 3 1 2 3.2 5 21 c,=2; +cs64-era-bt 6 4 3 1 2 3.1 12 10 c,=2; +cs64-era-bt 6 2 1 1 0 3.1 0 9 +cs64-era-bt 6 0 9 1 8 3.0 1 26 c,=5;c=3; +cs64-era-bt 6 7 4 1 3 3.6 9 16 c,=3; +cs64-era-bt 6 6 9 1 8 3.1 10 5 c,=6;c=2; +cs64-era-bt 6 1 2 1 1 3.4 7 27 c=1; +cs64-era-bt 5 31 4 1 3 3.7 5 7 c=2;c,=1; +cs64-era-bt 6 11 2 1 1 3.0 6 22 c,=1; +cs64-era-bt 6 10 4 1 3 3.3 10 1 c=2;c,=1; +cs64-era-bt 6 3 1 1 0 4.0 10 5 +cs64-era-bt 6 18 4 1 3 3.2 13 25 c,=3; +cs64-era-bt 6 8 7 1 6 5.7 8 3 c,=5;c=1; +cs64-era-bt 6 9 1 1 0 2.5 9 4 +cs64-era-bt 6 14 6 1 5 4.0 12 12 c,=4;c=1; +cs64-era-bt 6 13 5 1 4 3.7 2 25 c,=4; +cs64-era-bt 6 12 5 1 4 2.7 2 3 c,=3;c=1; +cs64-era-bt 6 20 1 1 0 3.0 4 26 +cs64-era-bt 6 15 1 1 0 3.0 11 24 +cs64-era-bt 6 21 2 1 1 2.7 0 13 c=1; +cs64-era-bt 6 23 3 1 2 2.6 8 13 c,=2; +cs64-era-bt 6 27 2 1 1 3.0 6 17 c,=1; +cs64-era-bt 6 24 6 1 5 3.0 9 22 c,=5; +cs64-era-bt 6 31 4 1 3 3.6 1 16 c=2;c,=1; +cs64-era-bt 6 16 9 1 8 2.9 8 0 c,=7;c=1; +cs64-era-bt 6 19 3 1 2 3.0 15 2 c,=2; +cs64-era-bt 6 17 7 1 6 2.8 11 0 c,=4;c=2; +cs64-era-bt 6 29 1 1 0 3.2 14 17 +cs64-era-bt 6 26 3 1 2 2.7 7 21 c,=2; +cs64-era-bt 7 6 1 1 0 4.3 3 7 +cs64-era-bt 6 22 1 1 0 3.9 9 14 +cs64-era-bt 7 11 2 1 1 3.8 14 24 c,=1; +cs64-era-bt 6 30 2 1 1 2.7 7 7 c,=1; +cs64-era-bt 6 28 5 1 4 4.3 10 20 c,=2;c=2; +cs64-era-bt 7 1 2 1 1 2.9 8 11 c=1; +cs64-era-bt 6 25 2 1 1 3.0 2 1 c=1; +cs64-era-bt 7 0 2 1 1 3.3 1 12 c=1; +cs64-era-bt 7 5 2 1 1 3.3 4 23 c=1; +cs64-era-bt 7 4 1 1 0 3.1 13 14 +cs64-era-bt 7 12 5 1 4 3.3 4 5 c=3;c,=1; +cs64-era-bt 7 13 4 1 3 2.7 8 11 c,=2;c=1; +cs64-era-bt 7 9 1 1 0 3.4 12 24 +cs64-era-bt 7 2 1 1 0 2.6 5 8 +cs64-era-bt 7 3 1 1 0 3.8 14 22 +cs64-era-bt 7 10 4 1 3 4.0 13 25 c=2;c,=1; +cs64-era-bt 7 8 2 1 1 3.0 12 17 c=1; +cs64-era-bt 7 7 2 1 1 2.9 13 6 c,=1; +cs64-era-bt 7 15 1 1 0 2.7 14 22 +cs64-era-bt 7 14 1 1 0 3.1 11 1 +cs64-era-bt 7 21 2 1 1 2.8 7 21 c=1; +cs64-era-bt 7 17 1 1 0 3.3 5 11 +cs64-era-bt 7 25 2 1 1 2.9 14 21 c=1; +cs64-era-bt 7 24 1 1 0 3.2 3 20 +cs64-era-bt 7 26 2 1 1 2.3 3 20 c,=1; +cs64-era-bt 7 23 1 1 0 3.8 12 27 +cs64-era-bt 7 18 1 1 0 2.9 14 23 +cs64-era-bt 7 16 2 1 1 3.7 5 11 c,=1; +cs64-era-bt 7 27 2 1 1 3.5 13 8 c,=1; +cs64-era-bt 7 20 1 1 0 3.0 3 14 +cs64-era-bt 7 22 1 1 0 2.8 5 25 +cs64-era-bt 7 30 1 1 0 5.9 2 27 +cs64-era-bt 7 29 1 1 0 3.2 13 4 +cs64-era-bt 7 31 1 1 0 3.8 5 27 +cs64-era-bt 7 19 3 1 2 3.0 13 1 c=2; +cs64-era-bt 7 28 2 1 1 3.0 14 11 c=1; +# end 2026-10-08T15:07:36Z rows=257 diff --git a/docs/analysis/class-v6/logs/connected/cs64-era-nobt.tsv b/docs/analysis/class-v6/logs/connected/cs64-era-nobt.tsv new file mode 100644 index 000000000..29386837b --- /dev/null +++ b/docs/analysis/class-v6/logs/connected/cs64-era-nobt.tsv @@ -0,0 +1,259 @@ +# cs64-era-nobt class cs64s27x16 eras [0,1,2,3,4,5,6,7] seeds 32 era-widths 4 weights base bittest off bin 54b905920b91becc start 2026-10-08T15:01:08Z host f271665b754f threads 24 +cand era seed candidates accepted attempt bit_z bit_site bit_bit reasons +cs64-era-nobt 0 21 2 1 1 3.2 14 21 c=1; +cs64-era-nobt 0 6 1 1 0 5.1 3 19 +cs64-era-nobt 0 2 1 1 0 2.8 9 21 +cs64-era-nobt 0 4 1 1 0 3.2 12 20 +cs64-era-nobt 0 16 1 1 0 24.0 13 19 +cs64-era-nobt 0 12 2 1 1 12.5 15 19 c=1; +cs64-era-nobt 0 17 1 1 0 24.9 13 19 +cs64-era-nobt 0 8 2 1 1 32.0 3 19 c=1; +cs64-era-nobt 0 3 1 1 0 2.7 12 10 +cs64-era-nobt 0 15 1 1 0 2.8 14 16 +cs64-era-nobt 0 1 2 1 1 7.0 1 20 c=1; +cs64-era-nobt 0 19 3 1 2 3.6 1 19 c=2; +cs64-era-nobt 0 11 2 1 1 3.1 5 0 c=1; +cs64-era-nobt 0 7 2 1 1 46.9 13 19 c=1; +cs64-era-nobt 0 22 1 1 0 3.0 1 19 +cs64-era-nobt 0 10 1 1 0 16.2 6 19 +cs64-era-nobt 0 18 1 1 0 14.6 2 19 +cs64-era-nobt 0 0 2 1 1 10.8 0 19 c=1; +cs64-era-nobt 0 9 1 1 0 3.1 1 17 +cs64-era-nobt 0 14 1 1 0 65.0 8 19 +cs64-era-nobt 0 5 2 1 1 3.9 5 1 c=1; +cs64-era-nobt 0 23 1 1 0 7.4 12 19 +cs64-era-nobt 0 13 2 1 1 31.2 12 19 c=1; +cs64-era-nobt 0 20 1 1 0 3.8 10 1 +cs64-era-nobt 0 24 1 1 0 31.8 2 19 +cs64-era-nobt 0 30 1 1 0 46.5 14 19 +cs64-era-nobt 0 26 2 1 1 29.4 3 19 c=1; +cs64-era-nobt 0 31 1 1 0 6.9 0 19 +cs64-era-nobt 0 29 1 1 0 4.2 8 22 +cs64-era-nobt 0 28 2 1 1 70.2 15 19 c=1; +cs64-era-nobt 0 27 1 1 0 8.7 9 19 +cs64-era-nobt 1 3 1 1 0 3.3 15 7 +cs64-era-nobt 0 25 2 1 1 3.3 2 14 c=1; +cs64-era-nobt 1 0 2 1 1 11.4 0 6 c=1; +cs64-era-nobt 1 12 2 1 1 13.1 15 6 c=1; +cs64-era-nobt 1 5 2 1 1 3.6 4 16 c=1; +cs64-era-nobt 1 9 1 1 0 4.0 11 0 +cs64-era-nobt 1 4 1 1 0 10.9 6 7 +cs64-era-nobt 1 6 1 1 0 6.7 3 6 +cs64-era-nobt 1 1 2 1 1 2.8 6 20 c=1; +cs64-era-nobt 1 7 2 1 1 46.8 13 6 c=1; +cs64-era-nobt 1 10 1 1 0 14.5 6 6 +cs64-era-nobt 1 2 1 1 0 2.9 15 20 +cs64-era-nobt 1 11 2 1 1 3.1 3 6 c=1; +cs64-era-nobt 1 13 2 1 1 32.6 11 6 c=1; +cs64-era-nobt 1 15 1 1 0 3.2 6 1 +cs64-era-nobt 1 8 2 1 1 31.6 3 6 c=1; +cs64-era-nobt 1 14 1 1 0 63.5 8 6 +cs64-era-nobt 1 16 1 1 0 24.5 13 6 +cs64-era-nobt 1 17 1 1 0 24.0 13 6 +cs64-era-nobt 1 19 3 1 2 3.2 5 13 c=2; +cs64-era-nobt 1 21 2 1 1 2.6 11 19 c=1; +cs64-era-nobt 1 18 1 1 0 15.9 2 6 +cs64-era-nobt 1 20 1 1 0 3.0 15 9 +cs64-era-nobt 1 30 1 1 0 47.8 14 6 +cs64-era-nobt 1 23 1 1 0 4.8 12 6 +cs64-era-nobt 1 27 1 1 0 10.1 9 6 +cs64-era-nobt 2 1 2 1 1 3.3 0 4 c=1; +cs64-era-nobt 1 28 2 1 1 70.7 15 6 c=1; +cs64-era-nobt 1 24 1 1 0 30.4 2 6 +cs64-era-nobt 1 26 2 1 1 29.1 3 6 c=1; +cs64-era-nobt 1 22 1 1 0 3.3 4 25 +cs64-era-nobt 1 25 2 1 1 3.3 14 25 c=1; +cs64-era-nobt 1 29 1 1 0 3.9 10 6 +cs64-era-nobt 2 0 2 1 1 3.1 5 25 c=1; +cs64-era-nobt 2 3 1 1 0 2.6 11 1 +cs64-era-nobt 2 11 2 1 1 3.0 12 15 c=1; +cs64-era-nobt 2 7 2 1 1 3.2 9 24 c=1; +cs64-era-nobt 1 31 1 1 0 7.8 0 6 +cs64-era-nobt 2 2 1 1 0 3.3 0 0 +cs64-era-nobt 2 9 1 1 0 2.6 6 1 +cs64-era-nobt 2 10 1 1 0 3.1 2 20 +cs64-era-nobt 2 8 2 1 1 3.5 13 24 c=1; +cs64-era-nobt 2 6 1 1 0 3.1 0 1 +cs64-era-nobt 2 4 1 1 0 2.7 0 10 +cs64-era-nobt 2 5 2 1 1 3.0 10 12 c=1; +cs64-era-nobt 2 12 2 1 1 2.8 13 23 c=1; +cs64-era-nobt 2 16 1 1 0 3.0 7 12 +cs64-era-nobt 2 13 2 1 1 3.1 2 26 c=1; +cs64-era-nobt 2 14 1 1 0 3.2 3 15 +cs64-era-nobt 2 24 1 1 0 3.5 3 11 +cs64-era-nobt 2 15 1 1 0 3.0 13 7 +cs64-era-nobt 2 25 2 1 1 3.1 2 7 c=1; +cs64-era-nobt 2 20 1 1 0 2.8 10 3 +cs64-era-nobt 2 18 1 1 0 3.2 3 11 +cs64-era-nobt 2 19 3 1 2 3.1 8 20 c=2; +cs64-era-nobt 2 17 1 1 0 2.7 10 2 +cs64-era-nobt 2 22 1 1 0 2.9 5 1 +cs64-era-nobt 2 21 2 1 1 2.8 15 4 c=1; +cs64-era-nobt 2 23 1 1 0 3.7 15 20 +cs64-era-nobt 2 26 2 1 1 4.6 1 26 c=1; +cs64-era-nobt 2 29 1 1 0 3.5 11 7 +cs64-era-nobt 2 28 2 1 1 3.0 2 23 c=1; +cs64-era-nobt 2 27 1 1 0 3.3 9 18 +cs64-era-nobt 2 30 1 1 0 3.1 8 20 +cs64-era-nobt 3 1 2 1 1 3.3 9 13 c=1; +cs64-era-nobt 2 31 1 1 0 3.3 15 18 +cs64-era-nobt 3 0 2 1 1 3.2 0 7 c=1; +cs64-era-nobt 3 4 1 1 0 3.7 9 10 +cs64-era-nobt 3 6 1 1 0 3.1 2 9 +cs64-era-nobt 3 5 2 1 1 3.1 3 20 c=1; +cs64-era-nobt 3 3 1 1 0 3.3 2 14 +cs64-era-nobt 3 2 1 1 0 3.1 3 25 +cs64-era-nobt 3 7 2 1 1 3.2 8 17 c=1; +cs64-era-nobt 3 8 2 1 1 3.3 0 14 c=1; +cs64-era-nobt 3 17 1 1 0 3.0 2 12 +cs64-era-nobt 3 11 2 1 1 3.2 6 13 c=1; +cs64-era-nobt 3 9 1 1 0 3.4 3 9 +cs64-era-nobt 3 15 1 1 0 2.7 7 3 +cs64-era-nobt 3 18 1 1 0 2.8 9 2 +cs64-era-nobt 3 10 1 1 0 3.8 5 4 +cs64-era-nobt 3 19 3 1 2 3.3 13 17 c=2; +cs64-era-nobt 3 14 1 1 0 2.8 2 18 +cs64-era-nobt 3 21 2 1 1 3.0 0 15 c=1; +cs64-era-nobt 3 12 2 1 1 3.4 14 17 c=1; +cs64-era-nobt 3 13 2 1 1 3.1 0 25 c=1; +cs64-era-nobt 3 16 1 1 0 3.2 13 0 +cs64-era-nobt 3 24 1 1 0 3.5 13 5 +cs64-era-nobt 3 20 1 1 0 3.4 2 2 +cs64-era-nobt 3 22 1 1 0 3.0 11 11 +cs64-era-nobt 3 26 2 1 1 3.3 5 16 c=1; +cs64-era-nobt 3 29 1 1 0 3.0 5 7 +cs64-era-nobt 3 23 1 1 0 2.9 3 25 +cs64-era-nobt 3 31 1 1 0 3.4 15 8 +cs64-era-nobt 3 25 2 1 1 3.2 13 6 c=1; +cs64-era-nobt 4 1 2 1 1 3.3 12 22 c=1; +cs64-era-nobt 4 0 2 1 1 11.8 0 10 c=1; +cs64-era-nobt 3 28 2 1 1 4.4 15 0 c=1; +cs64-era-nobt 4 4 1 1 0 11.1 6 11 +cs64-era-nobt 3 30 1 1 0 2.8 8 20 +cs64-era-nobt 3 27 1 1 0 2.9 15 13 +cs64-era-nobt 4 3 1 1 0 2.7 10 11 +cs64-era-nobt 4 2 1 1 0 2.9 10 22 +cs64-era-nobt 4 6 1 1 0 5.0 3 10 +cs64-era-nobt 4 5 2 1 1 3.3 15 27 c=1; +cs64-era-nobt 4 7 2 1 1 47.7 13 10 c=1; +cs64-era-nobt 4 10 1 1 0 15.7 6 10 +cs64-era-nobt 4 9 1 1 0 3.7 6 8 +cs64-era-nobt 4 11 2 1 1 3.7 8 16 c=1; +cs64-era-nobt 4 12 2 1 1 15.9 15 10 c=1; +cs64-era-nobt 4 13 2 1 1 32.3 11 10 c=1; +cs64-era-nobt 4 8 2 1 1 33.1 3 10 c=1; +cs64-era-nobt 4 14 1 1 0 63.9 8 10 +cs64-era-nobt 4 15 1 1 0 3.2 14 25 +cs64-era-nobt 4 17 1 1 0 22.9 13 10 +cs64-era-nobt 4 16 1 1 0 22.5 13 10 +cs64-era-nobt 4 18 1 1 0 16.0 2 10 +cs64-era-nobt 4 20 1 1 0 3.2 9 11 +cs64-era-nobt 4 22 1 1 0 3.2 8 24 +cs64-era-nobt 4 28 2 1 1 70.4 15 10 c=1; +cs64-era-nobt 4 19 3 1 2 3.4 2 0 c=2; +cs64-era-nobt 4 29 1 1 0 3.7 10 9 +cs64-era-nobt 4 31 1 1 0 7.3 0 10 +cs64-era-nobt 4 25 2 1 1 3.3 0 22 c=1; +cs64-era-nobt 4 21 2 1 1 2.8 8 10 c=1; +cs64-era-nobt 4 26 2 1 1 30.5 3 10 c=1; +cs64-era-nobt 4 24 1 1 0 30.3 2 10 +cs64-era-nobt 4 27 1 1 0 9.1 9 10 +cs64-era-nobt 4 30 1 1 0 48.5 14 10 +cs64-era-nobt 4 23 1 1 0 5.8 12 10 +cs64-era-nobt 5 0 2 1 1 10.7 0 22 c=1; +cs64-era-nobt 5 1 2 1 1 3.2 9 2 c=1; +cs64-era-nobt 5 4 1 1 0 9.9 6 23 +cs64-era-nobt 5 3 1 1 0 3.1 5 8 +cs64-era-nobt 5 5 2 1 1 3.5 14 23 c=1; +cs64-era-nobt 5 2 1 1 0 3.0 2 6 +cs64-era-nobt 5 7 2 1 1 47.0 13 22 c=1; +cs64-era-nobt 5 6 1 1 0 4.6 3 22 +cs64-era-nobt 5 9 1 1 0 4.1 8 7 +cs64-era-nobt 5 10 1 1 0 14.9 12 22 +cs64-era-nobt 5 8 2 1 1 31.2 3 22 c=1; +cs64-era-nobt 5 11 2 1 1 3.1 4 11 c=1; +cs64-era-nobt 5 14 1 1 0 63.4 8 22 +cs64-era-nobt 5 12 2 1 1 13.0 15 22 c=1; +cs64-era-nobt 5 13 2 1 1 30.8 11 22 c=1; +cs64-era-nobt 5 15 1 1 0 3.6 13 2 +cs64-era-nobt 5 16 1 1 0 24.0 13 22 +cs64-era-nobt 5 18 1 1 0 13.4 2 22 +cs64-era-nobt 5 17 1 1 0 23.8 13 22 +cs64-era-nobt 5 19 3 1 2 2.7 14 24 c=2; +cs64-era-nobt 5 21 2 1 1 3.1 10 16 c=1; +cs64-era-nobt 5 20 1 1 0 3.3 2 16 +cs64-era-nobt 5 26 2 1 1 29.3 3 22 c=1; +cs64-era-nobt 5 24 1 1 0 30.5 2 22 +cs64-era-nobt 5 23 1 1 0 5.7 12 22 +cs64-era-nobt 5 22 1 1 0 3.4 0 16 +cs64-era-nobt 5 25 2 1 1 3.0 5 1 c=1; +cs64-era-nobt 5 27 1 1 0 10.1 9 22 +cs64-era-nobt 5 28 2 1 1 71.5 15 22 c=1; +cs64-era-nobt 5 29 1 1 0 3.6 12 26 +cs64-era-nobt 5 31 1 1 0 6.4 0 22 +cs64-era-nobt 5 30 1 1 0 46.0 14 22 +cs64-era-nobt 6 1 2 1 1 3.4 7 27 c=1; +cs64-era-nobt 6 0 2 1 1 11.7 0 3 c=1; +cs64-era-nobt 6 2 1 1 0 3.1 0 9 +cs64-era-nobt 6 3 1 1 0 4.0 10 5 +cs64-era-nobt 6 4 1 1 0 8.4 6 4 +cs64-era-nobt 6 6 1 1 0 6.1 3 3 +cs64-era-nobt 6 5 2 1 1 2.8 5 11 c=1; +cs64-era-nobt 6 7 2 1 1 47.9 13 3 c=1; +cs64-era-nobt 6 10 1 1 0 16.1 6 3 +cs64-era-nobt 6 8 2 1 1 32.0 3 3 c=1; +cs64-era-nobt 6 11 2 1 1 3.0 6 22 c=1; +cs64-era-nobt 6 9 1 1 0 2.5 9 4 +cs64-era-nobt 6 12 2 1 1 14.8 15 3 c=1; +cs64-era-nobt 6 13 2 1 1 31.9 11 3 c=1; +cs64-era-nobt 6 14 1 1 0 63.6 8 3 +cs64-era-nobt 6 15 1 1 0 3.0 11 24 +cs64-era-nobt 6 16 1 1 0 24.1 13 3 +cs64-era-nobt 6 17 1 1 0 22.9 13 3 +cs64-era-nobt 6 18 1 1 0 18.8 2 3 +cs64-era-nobt 6 19 3 1 2 3.0 15 2 c=2; +cs64-era-nobt 6 21 2 1 1 2.7 0 13 c=1; +cs64-era-nobt 6 20 1 1 0 3.0 4 26 +cs64-era-nobt 6 23 1 1 0 8.2 12 3 +cs64-era-nobt 6 22 1 1 0 3.9 9 14 +cs64-era-nobt 6 24 1 1 0 30.1 2 3 +cs64-era-nobt 6 26 2 1 1 29.5 3 3 c=1; +cs64-era-nobt 6 28 2 1 1 71.3 15 3 c=1; +cs64-era-nobt 6 25 2 1 1 3.0 2 1 c=1; +cs64-era-nobt 6 27 1 1 0 8.6 9 3 +cs64-era-nobt 6 29 1 1 0 3.2 14 17 +cs64-era-nobt 6 30 1 1 0 47.4 14 3 +cs64-era-nobt 6 31 1 1 0 6.2 0 3 +cs64-era-nobt 7 1 2 1 1 2.9 8 11 c=1; +cs64-era-nobt 7 0 2 1 1 3.3 1 12 c=1; +cs64-era-nobt 7 4 1 1 0 3.1 13 14 +cs64-era-nobt 7 6 1 1 0 4.3 3 7 +cs64-era-nobt 7 3 1 1 0 3.8 14 22 +cs64-era-nobt 7 2 1 1 0 2.6 5 8 +cs64-era-nobt 7 5 2 1 1 3.3 4 23 c=1; +cs64-era-nobt 7 7 2 1 1 2.9 13 6 c=1; +cs64-era-nobt 7 8 2 1 1 3.0 12 17 c=1; +cs64-era-nobt 7 10 1 1 0 15.2 6 27 +cs64-era-nobt 7 9 1 1 0 3.4 12 24 +cs64-era-nobt 7 11 2 1 1 3.8 14 24 c=1; +cs64-era-nobt 7 12 2 1 1 12.5 15 27 c=1; +cs64-era-nobt 7 14 1 1 0 3.1 11 1 +cs64-era-nobt 7 13 2 1 1 27.9 14 27 c=1; +cs64-era-nobt 7 15 1 1 0 2.7 14 22 +cs64-era-nobt 7 16 1 1 0 24.0 13 27 +cs64-era-nobt 7 17 1 1 0 3.3 5 11 +cs64-era-nobt 7 18 1 1 0 2.9 14 23 +cs64-era-nobt 7 19 3 1 2 3.0 13 1 c=2; +cs64-era-nobt 7 21 2 1 1 2.8 7 21 c=1; +cs64-era-nobt 7 20 1 1 0 3.0 3 14 +cs64-era-nobt 7 23 1 1 0 3.8 12 27 +cs64-era-nobt 7 22 1 1 0 2.8 5 25 +cs64-era-nobt 7 26 2 1 1 2.3 3 20 c=1; +cs64-era-nobt 7 24 1 1 0 3.2 3 20 +cs64-era-nobt 7 25 2 1 1 2.9 14 21 c=1; +cs64-era-nobt 7 28 2 1 1 3.0 14 11 c=1; +cs64-era-nobt 7 29 1 1 0 3.2 13 4 +cs64-era-nobt 7 27 1 1 0 10.0 9 27 +cs64-era-nobt 7 30 1 1 0 5.9 2 27 +cs64-era-nobt 7 31 1 1 0 3.8 5 27 +# end 2026-10-08T15:07:58Z rows=257 diff --git a/docs/analysis/class-v6/logs/connected/cs64-none.tsv b/docs/analysis/class-v6/logs/connected/cs64-none.tsv new file mode 100644 index 000000000..5291eb63c --- /dev/null +++ b/docs/analysis/class-v6/logs/connected/cs64-none.tsv @@ -0,0 +1,259 @@ +# cs64-none class cs64s27x16 eras [none] seeds 256 era-widths 4 weights base bittest off bin 54b905920b91becc start 2026-10-08T15:01:08Z host f271665b754f threads 40 +cand era seed candidates accepted attempt bit_z bit_site bit_bit reasons +cs64-none none 12 1 1 0 3.8 4 20 +cs64-none none 8 1 1 0 55.1 1 0 +cs64-none none 36 1 1 0 3.2 15 24 +cs64-none none 2 1 1 0 2.7 12 3 +cs64-none none 14 1 1 0 2.7 0 16 +cs64-none none 10 1 1 0 3.1 1 22 +cs64-none none 37 1 1 0 42.9 6 0 +cs64-none none 38 2 1 1 20.3 3 0 c=1; +cs64-none none 29 2 1 1 3.4 7 24 c=1; +cs64-none none 7 1 1 0 35.3 11 0 +cs64-none none 31 1 1 0 17.2 3 0 +cs64-none none 18 1 1 0 49.8 13 0 +cs64-none none 11 1 1 0 3.3 4 26 +cs64-none none 0 1 1 0 3.6 9 17 +cs64-none none 35 1 1 0 42.4 13 0 +cs64-none none 23 3 1 2 29.2 11 0 c=2; +cs64-none none 4 1 1 0 38.8 11 0 +cs64-none none 30 1 1 0 3.1 13 17 +cs64-none none 20 1 1 0 3.0 3 11 +cs64-none none 17 1 1 0 3.8 7 1 +cs64-none none 32 1 1 0 5.5 8 0 +cs64-none none 28 2 1 1 2.8 6 11 c=1; +cs64-none none 39 1 1 0 3.7 9 0 +cs64-none none 21 1 1 0 31.7 9 0 +cs64-none none 9 1 1 0 59.0 9 0 +cs64-none none 33 2 1 1 30.3 11 0 c=1; +cs64-none none 24 1 1 0 21.1 10 0 +cs64-none none 5 2 1 1 23.5 6 0 c=1; +cs64-none none 25 1 1 0 2.8 9 27 +cs64-none none 6 1 1 0 17.3 0 0 +cs64-none none 1 1 1 0 16.6 3 0 +cs64-none none 16 1 1 0 22.5 2 0 +cs64-none none 3 1 1 0 26.8 7 0 +cs64-none none 26 1 1 0 24.3 14 0 +cs64-none none 27 1 1 0 3.4 14 7 +cs64-none none 34 2 1 1 3.1 2 26 c=1; +cs64-none none 22 1 1 0 22.3 3 0 +cs64-none none 19 1 1 0 16.5 14 1 +cs64-none none 13 1 1 0 4.7 12 1 +cs64-none none 15 3 1 2 4.0 0 1 c=2; +cs64-none none 46 1 1 0 2.6 3 4 +cs64-none none 42 2 1 1 4.0 10 21 c=1; +cs64-none none 50 1 1 0 64.1 10 1 +cs64-none none 51 2 1 1 30.9 11 0 c=1; +cs64-none none 40 1 1 0 65.4 6 0 +cs64-none none 63 1 1 0 6.3 10 0 +cs64-none none 66 1 1 0 2.6 14 24 +cs64-none none 58 3 1 2 17.7 4 0 c=2; +cs64-none none 43 1 1 0 64.4 9 0 +cs64-none none 59 1 1 0 127.7 4 0 +cs64-none none 45 1 1 0 13.3 13 0 +cs64-none none 44 1 1 0 3.0 14 3 +cs64-none none 41 1 1 0 12.4 8 0 +cs64-none none 53 1 1 0 3.2 8 7 +cs64-none none 47 1 1 0 33.8 7 0 +cs64-none none 56 1 1 0 3.0 12 22 +cs64-none none 52 1 1 0 47.9 12 0 +cs64-none none 48 2 1 1 50.0 4 1 c=1; +cs64-none none 49 1 1 0 3.3 7 2 +cs64-none none 60 2 1 1 9.4 6 0 c=1; +cs64-none none 55 1 1 0 13.0 13 0 +cs64-none none 75 3 1 2 3.2 10 3 c=2; +cs64-none none 54 3 1 2 13.5 8 0 c=2; +cs64-none none 57 1 1 0 32.5 6 0 +cs64-none none 76 1 1 0 9.3 12 0 +cs64-none none 61 2 1 1 15.1 4 0 c=1; +cs64-none none 64 1 1 0 3.0 2 8 +cs64-none none 70 2 1 1 20.6 2 0 c=1; +cs64-none none 71 1 1 0 14.4 2 0 +cs64-none none 67 4 1 3 9.5 6 0 c=3; +cs64-none none 62 1 1 0 3.0 7 20 +cs64-none none 65 3 1 2 12.0 4 0 c=2; +cs64-none none 79 1 1 0 84.3 9 0 +cs64-none none 69 2 1 1 2.9 3 22 c=1; +cs64-none none 77 1 1 0 19.8 15 0 +cs64-none none 68 2 1 1 31.4 3 0 c=1; +cs64-none none 85 2 1 1 3.1 9 15 c=1; +cs64-none none 73 1 1 0 3.5 1 2 +cs64-none none 78 3 1 2 3.1 7 13 c=2; +cs64-none none 72 1 1 0 3.8 7 1 +cs64-none none 74 1 1 0 5.5 0 0 +cs64-none none 88 1 1 0 64.0 13 0 +cs64-none none 83 2 1 1 4.0 8 15 c=1; +cs64-none none 101 1 1 0 29.9 11 0 +cs64-none none 80 3 1 2 4.1 1 0 c=2; +cs64-none none 81 2 1 1 11.0 7 0 c=1; +cs64-none none 91 1 1 0 3.4 8 22 +cs64-none none 84 1 1 0 26.1 1 0 +cs64-none none 86 1 1 0 2.9 9 24 +cs64-none none 82 1 1 0 2.9 9 19 +cs64-none none 87 1 1 0 3.3 10 21 +cs64-none none 93 1 1 0 3.1 7 26 +cs64-none none 103 1 1 0 4.4 0 0 +cs64-none none 99 3 1 2 50.9 13 0 c=2; +cs64-none none 96 1 1 0 3.0 7 26 +cs64-none none 89 1 1 0 93.8 8 0 +cs64-none none 102 1 1 0 14.1 3 0 +cs64-none none 94 1 1 0 3.6 1 19 +cs64-none none 92 1 1 0 3.9 0 13 +cs64-none none 114 1 1 0 3.9 7 17 +cs64-none none 95 6 1 5 32.2 11 0 c=5; +cs64-none none 97 1 1 0 6.7 6 0 +cs64-none none 90 2 1 1 2.9 8 27 c=1; +cs64-none none 104 1 1 0 12.8 2 0 +cs64-none none 108 3 1 2 21.0 12 0 c=2; +cs64-none none 111 1 1 0 18.4 4 0 +cs64-none none 106 1 1 0 4.8 6 0 +cs64-none none 100 1 1 0 13.0 1 0 +cs64-none none 98 1 1 0 3.2 14 25 +cs64-none none 105 1 1 0 5.4 1 0 +cs64-none none 113 1 1 0 3.7 0 26 +cs64-none none 121 2 1 1 3.4 10 6 c=1; +cs64-none none 107 2 1 1 3.4 1 8 c=1; +cs64-none none 118 1 1 0 27.1 15 0 +cs64-none none 110 1 1 0 2.8 15 4 +cs64-none none 115 1 1 0 67.1 0 0 +cs64-none none 122 1 1 0 128.0 4 0 +cs64-none none 117 2 1 1 25.7 6 0 c=1; +cs64-none none 109 1 1 0 46.1 3 0 +cs64-none none 112 1 1 0 60.5 11 0 +cs64-none none 119 1 1 0 3.3 3 3 +cs64-none none 116 1 1 0 6.9 13 0 +cs64-none none 124 1 1 0 8.1 15 0 +cs64-none none 126 1 1 0 2.6 10 18 +cs64-none none 125 1 1 0 35.3 3 0 +cs64-none none 140 1 1 0 26.0 1 10 +cs64-none none 123 1 1 0 3.2 8 6 +cs64-none none 130 1 1 0 53.1 11 0 +cs64-none none 120 1 1 0 2.9 5 6 +cs64-none none 145 3 1 2 51.8 4 0 c=2; +cs64-none none 128 1 1 0 3.3 4 1 +cs64-none none 127 4 1 3 41.6 4 0 c=3; +cs64-none none 143 1 1 0 23.8 8 0 +cs64-none none 129 1 1 0 14.0 11 0 +cs64-none none 139 2 1 1 8.2 13 0 c=1; +cs64-none none 144 1 1 0 3.8 13 13 +cs64-none none 134 1 1 0 54.0 5 0 +cs64-none none 132 1 1 0 3.1 12 16 +cs64-none none 131 1 1 0 20.3 0 0 +cs64-none none 138 1 1 0 3.1 3 25 +cs64-none none 133 2 1 1 30.1 4 0 c=1; +cs64-none none 152 1 1 0 127.9 13 0 +cs64-none none 141 1 1 0 4.3 11 0 +cs64-none none 137 2 1 1 21.0 1 0 c=1; +cs64-none none 146 1 1 0 3.5 4 22 +cs64-none none 136 1 1 0 3.0 7 16 +cs64-none none 150 1 1 0 6.4 1 0 +cs64-none none 153 1 1 0 15.0 8 0 +cs64-none none 135 6 1 5 10.2 11 0 c=5; +cs64-none none 142 2 1 1 11.2 7 0 c=1; +cs64-none none 149 1 1 0 24.9 11 0 +cs64-none none 148 2 1 1 43.3 9 0 c=1; +cs64-none none 163 1 1 0 17.9 15 0 +cs64-none none 147 1 1 0 30.1 4 0 +cs64-none none 155 2 1 1 4.8 7 0 c=1; +cs64-none none 151 4 1 3 55.9 0 0 c=3; +cs64-none none 166 1 1 0 3.2 8 0 +cs64-none none 157 1 1 0 3.6 1 17 +cs64-none none 160 1 1 0 4.1 6 26 +cs64-none none 154 1 1 0 16.5 13 0 +cs64-none none 156 1 1 0 83.9 2 0 +cs64-none none 165 1 1 0 9.2 4 0 +cs64-none none 162 1 1 0 19.9 10 0 +cs64-none none 158 1 1 0 3.1 8 3 +cs64-none none 169 2 1 1 35.4 8 0 c=1; +cs64-none none 159 1 1 0 5.0 7 0 +cs64-none none 161 1 1 0 3.2 13 7 +cs64-none none 164 1 1 0 59.8 8 0 +cs64-none none 180 1 1 0 4.0 11 2 +cs64-none none 177 1 1 0 21.3 0 0 +cs64-none none 175 1 1 0 3.1 12 21 +cs64-none none 168 1 1 0 3.5 0 8 +cs64-none none 171 1 1 0 18.7 2 0 +cs64-none none 172 1 1 0 18.7 3 0 +cs64-none none 170 1 1 0 22.3 0 0 +cs64-none none 176 3 1 2 3.2 1 2 c=2; +cs64-none none 173 2 1 1 49.9 4 0 c=1; +cs64-none none 181 1 1 0 3.3 4 8 +cs64-none none 179 1 1 0 17.5 2 0 +cs64-none none 167 1 1 0 19.3 9 0 +cs64-none none 186 1 1 0 38.4 5 0 +cs64-none none 174 1 1 0 24.1 0 0 +cs64-none none 185 2 1 1 3.0 4 14 c=1; +cs64-none none 178 2 1 1 43.0 3 0 c=1; +cs64-none none 182 1 1 0 3.3 0 26 +cs64-none none 187 2 1 1 82.5 0 0 c=1; +cs64-none none 189 3 1 2 8.2 15 0 c=2; +cs64-none none 188 1 1 0 31.2 6 0 +cs64-none none 190 1 1 0 3.5 12 11 +cs64-none none 193 1 1 0 19.7 5 0 +cs64-none none 183 1 1 0 3.0 15 21 +cs64-none none 192 1 1 0 6.8 3 0 +cs64-none none 196 1 1 0 3.6 9 0 +cs64-none none 198 1 1 0 8.6 13 0 +cs64-none none 184 1 1 0 3.5 7 0 +cs64-none none 195 1 1 0 14.5 6 0 +cs64-none none 191 2 1 1 29.9 6 0 c=1; +cs64-none none 194 1 1 0 14.1 6 0 +cs64-none none 197 1 1 0 31.6 5 0 +cs64-none none 204 1 1 0 3.0 15 15 +cs64-none none 210 1 1 0 46.5 15 0 +cs64-none none 207 1 1 0 3.5 8 11 +cs64-none none 202 1 1 0 3.8 11 12 +cs64-none none 199 1 1 0 18.5 3 1 +cs64-none none 200 2 1 1 10.9 12 0 c=1; +cs64-none none 209 1 1 0 3.1 10 17 +cs64-none none 214 1 1 0 3.3 5 16 +cs64-none none 201 2 1 1 3.3 8 17 c=1; +cs64-none none 208 1 1 0 34.3 1 0 +cs64-none none 206 1 1 0 15.5 11 0 +cs64-none none 205 1 1 0 28.4 11 0 +cs64-none none 216 1 1 0 45.3 13 0 +cs64-none none 203 1 1 0 3.3 1 24 +cs64-none none 221 1 1 0 3.2 12 16 +cs64-none none 220 1 1 0 3.5 14 14 +cs64-none none 218 4 1 3 4.0 6 22 c=3; +cs64-none none 223 3 1 2 42.6 10 0 c=2; +cs64-none none 224 1 1 0 3.2 2 11 +cs64-none none 212 1 1 0 28.8 1 0 +cs64-none none 217 1 1 0 3.0 15 7 +cs64-none none 215 4 1 3 53.8 9 0 c=3; +cs64-none none 225 3 1 2 3.8 4 1 c=2; +cs64-none none 228 1 1 0 3.0 8 3 +cs64-none none 211 1 1 0 3.7 8 1 +cs64-none none 213 1 1 0 13.4 4 0 +cs64-none none 229 1 1 0 3.9 12 1 +cs64-none none 219 2 1 1 33.2 6 1 c=1; +cs64-none none 232 1 1 0 3.2 8 13 +cs64-none none 231 1 1 0 9.3 15 0 +cs64-none none 222 1 1 0 16.5 10 0 +cs64-none none 235 1 1 0 32.7 3 0 +cs64-none none 234 1 1 0 3.6 11 23 +cs64-none none 233 1 1 0 3.1 13 21 +cs64-none none 226 3 1 2 9.0 15 0 c=2; +cs64-none none 227 2 1 1 3.4 1 4 c=1; +cs64-none none 238 1 1 0 15.6 13 0 +cs64-none none 230 1 1 0 20.9 0 0 +cs64-none none 237 3 1 2 3.9 5 19 c=2; +cs64-none none 236 1 1 0 3.2 7 23 +cs64-none none 239 1 1 0 19.7 4 0 +cs64-none none 251 1 1 0 26.7 14 0 +cs64-none none 240 1 1 0 31.3 12 0 +cs64-none none 252 2 1 1 61.1 9 0 c=1; +cs64-none none 242 1 1 0 14.0 12 0 +cs64-none none 244 1 1 0 2.7 11 8 +cs64-none none 241 1 1 0 50.7 13 0 +cs64-none none 248 1 1 0 3.1 1 17 +cs64-none none 246 2 1 1 11.2 5 0 c=1; +cs64-none none 253 2 1 1 8.2 9 0 c=1; +cs64-none none 247 1 1 0 34.2 5 0 +cs64-none none 249 1 1 0 3.3 7 3 +cs64-none none 250 2 1 1 25.8 9 0 c=1; +cs64-none none 243 2 1 1 52.5 8 1 c=1; +cs64-none none 254 1 1 0 3.1 12 10 +cs64-none none 245 1 1 0 11.4 8 0 +cs64-none none 255 1 1 0 12.2 8 0 +# end 2026-10-08T15:07:34Z rows=257 diff --git a/docs/analysis/class-v6/logs/connected/uniform-cs64-none.tsv b/docs/analysis/class-v6/logs/connected/uniform-cs64-none.tsv new file mode 100644 index 000000000..08d76ac7d --- /dev/null +++ b/docs/analysis/class-v6/logs/connected/uniform-cs64-none.tsv @@ -0,0 +1,17 @@ +class era seed attempt program_id min_site_ratio min_site top0.1_share control_share ratio_to_control max_item_reads control_max reads +cs64s27x16 none 0 0 9ad55de91485542b 1.00006 15 0.002383 0.002382 1.0002 27 27 134217728 +cs64s27x16 none 4 0 ef05f7b4f74f8b34 0.99876 11 0.002381 0.002377 1.0016 26 29 134217728 +cs64s27x16 none 9 0 4f7dfb188ea079f8 0.99407 9 0.002382 0.002380 1.0010 27 28 134217728 +cs64s27x16 none 3 0 423f3fcb11ffd16c 0.99937 7 0.002380 0.002380 1.0001 27 28 134217728 +cs64s27x16 none 12 0 f2ee7ca7642ce409 1.00010 1 0.002378 0.002381 0.9987 27 27 134217728 +cs64s27x16 none 7 0 a05222bdb885f832 0.99795 11 0.002381 0.002379 1.0010 28 27 134217728 +cs64s27x16 none 10 0 d6229a4ebc3da203 1.00013 1 0.002381 0.002381 0.9999 28 27 134217728 +cs64s27x16 none 8 0 5d3c176e39a2d7bd 0.99565 1 0.002377 0.002379 0.9991 27 27 134217728 +cs64s27x16 none 1 0 118f3f6ee409eb00 1.00000 3 0.002379 0.002381 0.9990 26 27 134217728 +cs64s27x16 none 5 1 66da80dabf645c59 0.99958 6 0.002382 0.002379 1.0014 27 28 134217728 +cs64s27x16 none 15 2 7261a08393ef6b71 1.00000 2 0.002379 0.002380 0.9996 26 27 134217728 +cs64s27x16 none 6 0 0f25af70edd287cc 0.99985 0 0.002381 0.002380 1.0003 26 28 134217728 +cs64s27x16 none 11 0 b1ccae46f9288cc2 1.00008 14 0.002381 0.002382 0.9997 27 27 134217728 +cs64s27x16 none 2 0 53c13e9f37bad71f 1.00010 3 0.002380 0.002380 0.9999 26 29 134217728 +cs64s27x16 none 14 0 e84c88374beb684f 1.00010 6 0.002382 0.002382 1.0002 27 27 134217728 +cs64s27x16 none 13 0 87d88cf6b4db69a2 1.00011 10 0.002383 0.002383 1.0003 29 27 134217728 diff --git a/docs/analysis/class-v6/logs/connected/worker-4090.log b/docs/analysis/class-v6/logs/connected/worker-4090.log new file mode 100644 index 000000000..1d54c2ac2 --- /dev/null +++ b/docs/analysis/class-v6/logs/connected/worker-4090.log @@ -0,0 +1,17 @@ +RESULT worker pack packs/cs64-bound 15:17:37 +RESULT check packs/cs64-bound info igneum-worker-cuda 1.0 (4 October 2026): device 0 NVIDIA_GeForce_RTX_4090 (sm_89, 128 SMs), driver 13.0 from libcuda.so.1, NVRTC 12.8 from libnvrtc.so.12, target sm_89 (the device's architecture, listed by NVRTC) +RESULT check packs/cs64-bound check PASS packs/cs64-bound in 2953 ms: nvrtc 1813 cache 2 dataset 31 hot 0 check 1106 race 0 ms variant base class v2; self-test PASS (cache head, last line and FNV-1a 64 48c4f5bf24166b2e; dataset head, word [268435455] and 64 samples; 96 of 96 vector lanes) +RESULT check packs/cs64-bound epoch 69676e65756d2d7636632f30 day 6461792f323032362d31302d3033, dataset 2^28 words, cache 2^26 words in 65536 segments, 87 registers, 20 blocks/SM at 1 warp(s)/block, target sm_89 +RESULT bench packs/cs64-bound pack packs/cs64-bound on NVIDIA_GeForce_RTX_4090: nvrtc 1749 cache 2 dataset 31 hot 0 check 1101 race 0 ms variant base class v2; self-test PASS (cache head, last line and FNV-1a 64 48c4f5bf24166b2e; dataset head, word [268435455] and 64 samples; 96 of 96 vector lanes) +RESULT bench packs/cs64-bound warm-up dispatch (base 0): 268.83 ms; 250 timed dispatches of 16777216 nonces: mean 268.83 ms +RESULT bench packs/cs64-bound RESULT pack=packs/cs64-bound class=mx8+sh256x27 device=NVIDIA_GeForce_RTX_4090 arch=sm_89 regs=87 blocks_per_sm=20 warps=0 resident=2560 arena_mib=0 hot_mib=0 hot_slots=0 hot_fill_ms=0.00 nonces=16777216 batches=250 check=PASS fingerprint=ad0cec2a42c84aff mhs=62.408 loads=128 bytes=512 scratch_ops=0 time=wall +RESULT smi packs/cs64-bound samples 66 mean_power_w 269.4 mean_sm_mhz 2809 +RESULT worker pack v5-genesis 15:18:52 +RESULT check v5-genesis info igneum-worker-cuda 1.0 (4 October 2026): device 0 NVIDIA_GeForce_RTX_4090 (sm_89, 128 SMs), driver 13.0 from libcuda.so.1, NVRTC 12.8 from libnvrtc.so.12, target sm_89 (the device's architecture, listed by NVRTC) +RESULT check v5-genesis check PASS v5-genesis in 1722 ms: nvrtc 586 cache 2 dataset 31 hot 0 check 1102 race 0 ms variant base class v5 (state leaves 93, uploaded for the build and freed); self-test PASS (cache head, last line and FNV-1a 64 48c4f5bf24166b2e; dataset head, word [268435455] and 64 samples; 96 of 96 vector lanes) +RESULT check v5-genesis epoch 69676e65756d2d67656e65736973 day 6461792f323032362d31302d3033, dataset 2^28 words, cache 2^26 words in 65536 segments, 32 registers, 24 blocks/SM at 1 warp(s)/block, target sm_89 +RESULT bench v5-genesis pack v5-genesis on NVIDIA_GeForce_RTX_4090: nvrtc 559 cache 2 dataset 32 hot 0 check 1100 race 0 ms variant base class v5 (state leaves 93, uploaded for the build and freed); self-test PASS (cache head, last line and FNV-1a 64 48c4f5bf24166b2e; dataset head, word [268435455] and 64 samples; 96 of 96 vector lanes) +RESULT bench v5-genesis warm-up dispatch (base 0): 268.89 ms; 250 timed dispatches of 16777216 nonces: mean 268.89 ms +RESULT bench v5-genesis RESULT pack=v5-genesis class=mx8+sh256x27+state device=NVIDIA_GeForce_RTX_4090 arch=sm_89 regs=32 blocks_per_sm=24 warps=0 resident=3072 arena_mib=0 hot_mib=0 hot_slots=0 hot_fill_ms=0.00 nonces=16777216 batches=250 check=PASS fingerprint=ae74193ddad19e19 mhs=62.394 loads=128 bytes=512 scratch_ops=0 time=wall +RESULT smi v5-genesis samples 65 mean_power_w 271.9 mean_sm_mhz 2805 +RESULT worker end 15:20:03 diff --git a/docs/analysis/class-v6/logs/connected/worker-5090.log b/docs/analysis/class-v6/logs/connected/worker-5090.log new file mode 100644 index 000000000..1a5ac8d6f --- /dev/null +++ b/docs/analysis/class-v6/logs/connected/worker-5090.log @@ -0,0 +1,17 @@ +RESULT worker pack packs/cs64-bound 15:16:17 +RESULT check packs/cs64-bound info igneum-worker-cuda 1.0 (4 October 2026): device 0 NVIDIA_GeForce_RTX_5090 (sm_120, 170 SMs), driver 13.0 from libcuda.so.1, NVRTC 12.8 from libnvrtc.so.12, target sm_120 (the device's architecture, listed by NVRTC) +RESULT check packs/cs64-bound check PASS packs/cs64-bound in 2256 ms: nvrtc 1089 cache 3 dataset 30 hot 0 check 1130 race 0 ms variant base class v2; self-test PASS (cache head, last line and FNV-1a 64 48c4f5bf24166b2e; dataset head, word [268435455] and 64 samples; 96 of 96 vector lanes) +RESULT check packs/cs64-bound epoch 69676e65756d2d7636632f30 day 6461792f323032362d31302d3033, dataset 2^28 words, cache 2^26 words in 65536 segments, 80 registers, 24 blocks/SM at 1 warp(s)/block, target sm_120 +RESULT bench packs/cs64-bound pack packs/cs64-bound on NVIDIA_GeForce_RTX_5090: nvrtc 1086 cache 3 dataset 30 hot 0 check 1122 race 0 ms variant base class v2; self-test PASS (cache head, last line and FNV-1a 64 48c4f5bf24166b2e; dataset head, word [268435455] and 64 samples; 96 of 96 vector lanes) +RESULT bench packs/cs64-bound warm-up dispatch (base 0): 268.09 ms; 250 timed dispatches of 16777216 nonces: mean 266.80 ms +RESULT bench packs/cs64-bound RESULT pack=packs/cs64-bound class=mx8+sh256x27 device=NVIDIA_GeForce_RTX_5090 arch=sm_120 regs=80 blocks_per_sm=24 warps=0 resident=4080 arena_mib=0 hot_mib=0 hot_slots=0 hot_fill_ms=0.00 nonces=16777216 batches=250 check=PASS fingerprint=ad0cec2a42c84aff mhs=62.882 loads=128 bytes=512 scratch_ops=0 time=wall +RESULT smi packs/cs64-bound samples 65 mean_power_w 574.2 mean_sm_mhz 2797 +RESULT worker pack v5-genesis 15:17:29 +RESULT check v5-genesis info igneum-worker-cuda 1.0 (4 October 2026): device 0 NVIDIA_GeForce_RTX_5090 (sm_120, 170 SMs), driver 13.0 from libcuda.so.1, NVRTC 12.8 from libnvrtc.so.12, target sm_120 (the device's architecture, listed by NVRTC) +RESULT check v5-genesis check PASS v5-genesis in 1709 ms: nvrtc 505 cache 5 dataset 32 hot 0 check 1162 race 0 ms variant base class v5 (state leaves 93, uploaded for the build and freed); self-test PASS (cache head, last line and FNV-1a 64 48c4f5bf24166b2e; dataset head, word [268435455] and 64 samples; 96 of 96 vector lanes) +RESULT check v5-genesis epoch 69676e65756d2d67656e65736973 day 6461792f323032362d31302d3033, dataset 2^28 words, cache 2^26 words in 65536 segments, 48 registers, 24 blocks/SM at 1 warp(s)/block, target sm_120 +RESULT bench v5-genesis pack v5-genesis on NVIDIA_GeForce_RTX_5090: nvrtc 500 cache 3 dataset 30 hot 0 check 1156 race 0 ms variant base class v5 (state leaves 93, uploaded for the build and freed); self-test PASS (cache head, last line and FNV-1a 64 48c4f5bf24166b2e; dataset head, word [268435455] and 64 samples; 96 of 96 vector lanes) +RESULT bench v5-genesis warm-up dispatch (base 0): 258.26 ms; 250 timed dispatches of 16777216 nonces: mean 266.46 ms +RESULT bench v5-genesis RESULT pack=v5-genesis class=mx8+sh256x27+state device=NVIDIA_GeForce_RTX_5090 arch=sm_120 regs=48 blocks_per_sm=24 warps=0 resident=4080 arena_mib=0 hot_mib=0 hot_slots=0 hot_fill_ms=0.00 nonces=16777216 batches=250 check=PASS fingerprint=ae74193ddad19e19 mhs=62.963 loads=128 bytes=512 scratch_ops=0 time=wall +RESULT smi v5-genesis samples 65 mean_power_w 571.4 mean_sm_mhz 2798 +RESULT worker end 15:18:41 diff --git a/docs/analysis/class-v6/multi-family-adversary.md b/docs/analysis/class-v6/multi-family-adversary.md new file mode 100644 index 000000000..151aa21d6 --- /dev/null +++ b/docs/analysis/class-v6/multi-family-adversary.md @@ -0,0 +1,558 @@ +# The multi-family adversary: one programmable chip against the 180-day family bank (8 October 2026) + +Branch `class-v6-adversary` from the box mirror's master (c86a7e23), the adversary lane of the second external review +(the founder's 15:5x BST acceptance). The question the review put: does the 180-day family calendar add cost to a chip, +or only change its firmware? The answer is built as the adversary would build it: ONE programmable design that executes +every entry of the bank (`docs/analysis/rotation/layer3-family-bank.md`: 18 op families, 3 dataset atoms, the fold form +with drawn constants, 3 block shapes, the 64-register window, the per-era parameter draws), with the designer free to +choose lanes, clock, pipeline, banking, time-multiplexing, memory organisation and the memory arrangement itself, and +priced on a complete machine. Every chip figure is synthesis and placement of RTL written for this lane (Yosys 0.68 and +OpenROAD, the ORFS image, ASAP7, run on rented CPU hosts, never on the Mac, never on a Hetzner box); every GPU figure is +the record's measurement (`docs/analysis/counter-asic-4-research.md` 15.1a, the floor programme's tier table in the +design document 10.4). Labels as the record uses them: measured, modelled, claimed, approximate. The RTL, testbenches, +flow and collector are under `tools/chip-model/mf/`; the k lane's rows (`floor/shadow-k.md`) are cited, never re-run. + +The standing rules this file is written under (the review, 15:4x BST): the adversary's design is free; a synthesised +k is a model, never a lower bound; a family transition is credited with an obsolescence benefit only where a loss of +competitiveness is demonstrated; the stress life is 3 years, shown at 0.5, 1, 2 and 3; the cohort is the discrete-GPU +population, Apple reported and not headlined; every defence is scored after the adversary re-optimises. + +## 0. One page + +(filled from the rows below at each cut; section 8 carries the three-part statement) + +## 1. The design: what the adversary builds + +### 1.1 What it must execute + +| Bank entry | What the core does with it | Silicon or firmware | +|---|---|---| +| G1 to G7: add, sub, xor, or, rotl, rotr, and the lossy or | the ALU group, one unit per lane, operands isolated | silicon once; the mix weights are the program | +| G8, G9, G6: mul, mulhi, mad | one 32 x 32 multiplier per lane; mulhi is the high word of the same product; mad adds the third read | silicon once | +| G10 shfl (the 32-lane xor-mask shuffle) | a log2(LANES)-stage butterfly across the core's lanes, the mask from the instruction | silicon once per core | +| R1 shfla (lane + delta) | a general LANES:1 crossbar per lane, the delta from a register | silicon once per core (the one network a butterfly cannot emulate in one op) | +| R2 perm (prmt) | the 4-of-8 byte selector | silicon once | +| R3 popc and clz | a popcount tree and a priority encoder | silicon once | +| R4 bfe, R5 shl and shr, R6 sel, R7 andn | a shifter, a mask, a select, an and-not | silicon once (fractions of an adder each) | +| R8 mm8 (the int8 tile) | a u8 dot4 accumulate per lane (4 MACs per op; the card's m8n8k16 tile is 32 MACs per lane, so 8 chip ops per card tile) | silicon once | +| lop3 | the 8-bit truth table | silicon once | +| the load and the fold form | the lane's own multiplier computes `x * M`, then the rotate and the three masks with the era's constants in registers; the returned word writes the destination | silicon once; M, R, WM, OFF, MASK are registers written at the era | +| W = 4 wide reads | the fold step `x = rotl(x, r) * M ^ w` as an instruction (fwd), three per load | firmware | +| the 64-register window | 64 x 32 bits per lane in an SRAM macro | silicon once (the macro) | +| the 3 block shapes (64, 128, 256) | the program-length register; the imem holds 256 | firmware | +| the drawn select tree | a 32-entry op permutation ahead of decode, written at the era | firmware (a 160-bit register) | +| the op-mix band, the fold constants | the program and five registers | firmware | +| the 3 dataset atoms (mixer x4, x8, dr368) | the per-window dataset build runs on the same core as a program (the atoms are straight-line ARX and multiply code over 16 registers); the per-hash path never executes an atom | firmware; the build's cost is section 7 | + +### 1.2 The microarchitecture (the designer's choices) + +- **The register state is an SRAM macro, not flops.** One FakeRAM2.0 `fakeram7_64x256` (64 words x 256 bits, single + port) per 8 lanes: the lanes are SIMD, every lane reads the same register index, so one 256-bit access serves eight + lanes' 32-bit reads. The macro's LEF and Liberty come with the ORFS ASAP7 platform (ABKGroup FakeRAM2.0, 7 nm, + 0.70 V; area 1,517 um^2 for the 64 x 256, 365 um^2 for the 256 x 34); the placement, the wiring and the clock tree + see the macro as a real block. Its dynamic energy is NOT taken from the FakeRAM Liberty (a placeholder, 1.345 per + clock edge identical for every size, "VALUES NOT REALISTIC" in the generator's own config); section 2.3 replaces it + with a published macro energy band and the gate-level simulation supplies the exact access counts. +- **The instruction memory is two `fakeram7_256x34` macros** shared by every lane of the core (40 bits used of 68). +- **A single-port macro is time-multiplexed over a 5-phase slot:** read dst, read src, read src2 only when the op + needs it (mad, lop3, sel, mm8, shfla), execute, write back. A core retires LANES lane-ops per 5 cycles; throughput is + bought with lane count (die area), the cheapest resource the chip has, not with ports. +- **Every unit's operands are isolated** (AND-gated by its own select), so an unused unit does not toggle: adding a + family's unit costs leakage and a wider result mux, not switching on every op. The k lane's core evaluates every unit + every cycle; this is one of the reasons its figure is not a lower bound. +- **The era's draws are registers** (fold constants, program length, the select tree); a family epoch writes them. +- Clock 1,500 ps (667 MHz) at the TC corner, as the k lane; nothing pipelined beyond the slot; two builds: 8 lanes + (placed and routed) and 32 lanes (synthesised), each in two variants: `full` (every bank entry) and `base` (the 10 + genesis families with the load and the fold, the same microarchitecture): the difference between the two is what the + bank adds to the chip. + +### 1.3 What the card pays for the same instruction (the GPU side, measured) + +The 5090's pJ per counted op at stock and at the 1,300 MHz lock (15.1a): add-class 11.3 / 6.2, mul and mad 13.9 / 8.3, +mulhi 39.6 / 21.0, prmt 22.3 / 11.5, lop3 24.1 / 13.0, shfl 55.8 / 29.4, the u8 tile 4.1 / 2.2 per MAC. The reserve +families by the measured NVIDIA step-cost ratio to the add step (design 4.2): shfla 1.53, popc 1.50, clz 1.63, bfe +1.54, shl and shr 0.75, sel and andn about 1.0 (approximate), mm8 by the tile row (32 MACs per lane per instruction). + +## 2. Method + +### 2.1 The flow + +ORFS on ASAP7 (7.5-track RVT, TC corner 0.70 V, NLDM), the default flow: Yosys with ABC, floorplan at 40 percent +utilisation (30 for the 32-lane core) with the macros placed by the flow's macro placer under the BLOCKS power grid, +global and detailed placement, CTS, global and detailed routing, OpenRCX parasitics. Power is OpenSTA `report_power` +under the VCD of a random-input gate-level simulation of the netlist (iverilog; every instruction field drawn by +`$random`, the window initialised with random words, a random returned word on every load), with a propagated 0.5 +activity as the cross-check. Synthesis-only rows (no wires, no clock tree) are marked; placed rows carry the SPEF. The routed runs clock at +12,000 ps with the ABC target held at 1,500 ps: the unpipelined execute path (the multiplier, the fold and the +lane reduction) is 10.6 ns at ASAP7 TC, and at 1,500 ps the flow's timing repair spent its time on a path the +adversary would pipeline instead (two to three registers per lane, about 0.1 to 0.2 pJ per lane-op, inside the +band). Energy per op does not depend on the period; the leakage term does, and the collector restates it at the +1,500 ps equivalent for the routed rows (both are in `table.csv`). + +### 2.2 The activity and the steady state + +Each row is a tag: the op field fixed per family (`+fam=K`), or a drawn program: the class v4 draw over the 10 genesis +families (`mix`), the same with one load in 16 (`mixld`), the draw with two reserve families live at 4 points each +(`mix1`: shfla and mm8, the two dearest), every reserve family live at 4 points (`mix2`, the bank's bound, not a legal +draw), the W = 4 form (`mixw4`), the 64-instruction shape (`mix64`). Two run lengths per tag (500 and 2,000 clocks, 100 +and 400 slots) bracket the 326-clock load phase (reset, the era's registers, the 256-word program, the 64-word window +init) and the run-phase power is solved from the pair, as the k lane does. + +### 2.3 The SRAM macro energy (the one modelled term on the chip side) + +The FakeRAM Liberty's internal power is a placeholder, so the collector removes the macros' Liberty-attributed power +(reported separately per VCD with `report_power -instances`) and adds a modelled access energy times the exact +access count from the simulation (3 reads and 1 write per slot for a three-operand op, 2 reads and 1 write otherwise, +per 8 lanes; 2 imem reads per slot per core). The band: a 64 x 256 single-port macro at a 7 nm class node 3.5 pJ per +256-bit access (2.0 to 7.0); a 256 x 34 macro 1.5 pJ per access (0.8 to 3.0). Sources: Horowitz, ISSCC 2014 (45 nm: +an 8 KB SRAM read of 64 bits 10 pJ, 32 KB 20 pJ), scaled by the bits moved and by the energy-per-bit reduction from +45 nm to a 7 nm class node (about 0.1x to 0.2x, approximate, the same generation scaling the record applies to logic); +the k lane's "2 to 4 pJ per 32-bit read, approximate" for a 4 KB imem; CACTI-class estimates for a 16 Kbit macro at +7 nm (0.01 to 0.03 pJ per bit read, approximate). Every row carries the band; the low end is near a flop array with +perfect clock gating, the high end a conservative compiler macro. The macros' switching on their output nets (256 +bits into the lanes' latches) stays in the logic figure, measured. + +### 2.4 Node scaling (claimed) and what the method leaves out + +ASAP7 is a predictive 7 nm-class PDK; the row is stated at ASAP7 and scaled by the foundry's headline per-node +power reductions at the same speed (the k lane's factors, every one claimed): N5 = 0.70, N3 = 0.50, N2 = 0.36 of +ASAP7. Node-for-node against the 5090 (TSMC 4N, N5 class) is the N5 column; a node ahead is N3. Left out on the chip +side: the memory controller's queueing logic and the lane's address output (priced in the board model as the +controller die), test and clock distribution beyond the block; on the card side the 15.1a figure is the whole card's +marginal per counted op, which includes fetch, decode, operand collection and the register file, so the comparison +is the chip's whole lane (fetch, decode, window, units, network) against the card's whole lane. + +## 3. The rows: pJ per lane-op per family on the base core (synthesis only, 8 lanes) + +Synthesis only (no wires, no clock tree), 8 lanes, 1,500 ps, ASAP7 TC; "pJ logic" is OpenSTA's figure for the +standard cells under the VCD with the FakeRAM placeholder removed (its sequential and combinational parts beside it); +"pJ SRAM" the modelled macro term at the simulated access count (low / nominal / high, section 2.3); the per-op +figure is logic plus the nominal SRAM term, the band in brackets; the 5090 column is 15.1a (the reserve families +by the measured step ratio; the mix rows against the card's 10.3 pJ per op on the class v4 draw at the lock, 18.8 +unlocked by the ARX ratio, approximate). The full core: 95,678 cells and 3 macros (the base core 66,973 and 3 +macros: the bank adds 43 percent of the standard cells, 0.13 mW of leakage per 8 lanes, and 11 percent to the +energy of the class v4 draw on the same microarchitecture, the wider result mux and the leakage of the idle units). + +The full core (every bank entry): + +| Design | Stage | Family | Cells | Logic W | Leak W | pJ logic (seq / comb) | pJ SRAM (low / nom / high) | pJ/lane-op ASAP7 | N5 | N3 | N2 | 5090 pJ/op unlocked / lock | k N5 lock | k N3 lock | k N3 unlocked | +|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| +| mf8full | power_synth | mix | 95678 | 0.00514 | 0.000395 | 4.82 (0.88 / 3.6) | 0.99 / 1.76 / 3.52 | 6.58 (5.81 to 8.34) | 4.61 | 3.32 | 2.39 | 18.8 / 10.3 | 0.447 | 0.322 | 0.176 | +| mf8full | power_synth | mixld | 95678 | 0.00513 | 0.000395 | 4.81 (0.88 / 3.6) | 0.986 / 1.75 / 3.5 | 6.56 (5.79 to 8.31) | 4.59 | 3.31 | 2.38 | 18.8 / 10.3 | 0.446 | 0.321 | 0.176 | +| mf8full | power_synth | mix1 | 95678 | 0.00495 | 0.000395 | 4.64 (0.89 / 3.4) | 1.01 / 1.8 / 3.59 | 6.43 (5.65 to 8.23) | 4.5 | 3.24 | 2.33 | 18.8 / 10.3 | 0.437 | 0.315 | 0.172 | +| mf8full | power_synth | mix2 | 95678 | 0.00436 | 0.000396 | 4.09 (0.88 / 2.8) | 1 / 1.78 / 3.56 | 5.87 (5.09 to 7.65) | 4.11 | 2.96 | 2.13 | 18.8 / 10.3 | 0.399 | 0.287 | 0.157 | +| mf8full | power_synth | mixw4 | 95678 | 0.00508 | 0.000395 | 4.76 (0.88 / 3.5) | 0.977 / 1.73 / 3.47 | 6.49 (5.74 to 8.23) | 4.55 | 3.27 | 2.36 | 18.8 / 10.3 | 0.441 | 0.318 | 0.174 | +| mf8full | power_synth | mix64 | 95678 | 0.00488 | 0.000395 | 4.58 (0.88 / 3.3) | 0.993 / 1.76 / 3.53 | 6.34 (5.57 to 8.1) | 4.44 | 3.19 | 2.3 | 18.8 / 10.3 | 0.431 | 0.31 | 0.17 | +| mf8full | power_synth | add | 95678 | 0.003 | 0.000396 | 2.81 (0.86 / 1.6) | 0.95 / 1.69 / 3.38 | 4.5 (3.76 to 6.18) | 3.15 | 2.27 | 1.63 | 11.3 / 6.2 | 0.508 | 0.366 | 0.201 | +| mf8full | power_synth | sub | 95678 | 0.00299 | 0.000396 | 2.8 (0.86 / 1.6) | 0.95 / 1.69 / 3.38 | 4.49 (3.75 to 6.18) | 3.14 | 2.26 | 1.63 | 11.3 / 6.2 | 0.507 | 0.365 | 0.2 | +| mf8full | power_synth | xor | 95678 | 0.00308 | 0.000396 | 2.89 (0.86 / 1.7) | 0.95 / 1.69 / 3.38 | 4.57 (3.84 to 6.26) | 3.2 | 2.3 | 1.66 | 11.3 / 6.2 | 0.516 | 0.372 | 0.204 | +| mf8full | power_synth | or | 95678 | 0.00183 | 0.000397 | 1.72 (0.84 / 0.5) | 0.95 / 1.69 / 3.38 | 3.41 (2.67 to 5.09) | 2.38 | 1.72 | 1.24 | 11.3 / 6.2 | 0.385 | 0.277 | 0.152 | +| mf8full | power_synth | rotl | 95678 | 0.00318 | 0.000396 | 2.99 (0.86 / 1.8) | 0.95 / 1.69 / 3.38 | 4.67 (3.94 to 6.36) | 3.27 | 2.36 | 1.7 | 11.3 / 6.2 | 0.528 | 0.38 | 0.208 | +| mf8full | power_synth | rotr | 95678 | 0.003 | 0.000396 | 2.81 (0.86 / 1.6) | 0.95 / 1.69 / 3.38 | 4.5 (3.76 to 6.18) | 3.15 | 2.27 | 1.63 | 11.3 / 6.2 | 0.508 | 0.366 | 0.201 | +| mf8full | power_synth | mul | 95678 | 0.00265 | 0.000396 | 2.48 (0.85 / 1.3) | 0.95 / 1.69 / 3.38 | 4.17 (3.43 to 5.86) | 2.92 | 2.1 | 1.51 | 13.9 / 8.3 | 0.352 | 0.253 | 0.151 | +| mf8full | power_synth | mulhi | 95678 | 0.00249 | 0.000396 | 2.33 (0.85 / 1.1) | 0.95 / 1.69 / 3.38 | 4.02 (3.28 to 5.71) | 2.81 | 2.03 | 1.46 | 39.6 / 21 | 0.134 | 0.0965 | 0.0512 | +| mf8full | power_synth | mad | 95678 | 0.00562 | 0.000395 | 5.26 (0.91 / 4) | 1.2 / 2.12 / 4.25 | 7.39 (6.46 to 9.51) | 5.17 | 3.72 | 2.68 | 13.9 / 8.3 | 0.623 | 0.449 | 0.268 | +| mf8full | power_synth | shfl | 95678 | 0.00266 | 0.000397 | 2.49 (0.86 / 1.3) | 0.95 / 1.69 / 3.38 | 4.18 (3.44 to 5.87) | 2.93 | 2.11 | 1.52 | 55.8 / 29.4 | 0.0995 | 0.0716 | 0.0377 | +| mf8full | power_synth | load | 95678 | 0.00433 | 0.000395 | 4.06 (0.86 / 2.8) | 0.95 / 1.69 / 3.38 | 5.75 (5.01 to 7.44) | 4.03 | 2.9 | 2.09 | 13.9 / 8.3 | 0.485 | 0.349 | 0.209 | +| mf8full | power_synth | fwd | 95678 | 0.004 | 0.000395 | 3.75 (0.86 / 2.5) | 0.95 / 1.69 / 3.38 | 5.44 (4.7 to 7.13) | 3.81 | 2.74 | 1.97 | 13.9 / 8.3 | 0.459 | 0.33 | 0.197 | +| mf8full | power_synth | prmt | 95678 | 0.00255 | 0.000397 | 2.39 (0.86 / 1.2) | 0.95 / 1.69 / 3.38 | 4.07 (3.34 to 5.76) | 2.85 | 2.05 | 1.48 | 22.3 / 11.5 | 0.248 | 0.179 | 0.0921 | +| mf8full | power_synth | lop3 | 95678 | 0.003 | 0.000397 | 2.81 (0.91 / 1.5) | 1.2 / 2.12 / 4.25 | 4.94 (4.01 to 7.06) | 3.46 | 2.49 | 1.79 | 24.1 / 13 | 0.266 | 0.191 | 0.103 | +| mf8full | power_synth | shfla | 95678 | 0.00302 | 0.000397 | 2.83 (0.9 / 1.6) | 1.2 / 2.12 / 4.25 | 4.95 (4.03 to 7.08) | 3.47 | 2.5 | 1.8 | 17.3 / 9.49 | 0.365 | 0.263 | 0.144 | +| mf8full | power_synth | popc | 95678 | 0.0017 | 0.000397 | 1.59 (0.85 / 0.38) | 0.95 / 1.69 / 3.38 | 3.28 (2.54 to 4.97) | 2.3 | 1.65 | 1.19 | 17 / 9.3 | 0.247 | 0.178 | 0.0976 | +| mf8full | power_synth | clz | 95678 | 0.00173 | 0.000397 | 1.62 (0.85 / 0.41) | 0.95 / 1.69 / 3.38 | 3.31 (2.57 to 5) | 2.32 | 1.67 | 1.2 | 18.4 / 10.1 | 0.229 | 0.165 | 0.0906 | +| mf8full | power_synth | bfe | 95678 | 0.00182 | 0.000397 | 1.71 (0.85 / 0.49) | 0.95 / 1.69 / 3.38 | 3.39 (2.66 to 5.08) | 2.38 | 1.71 | 1.23 | 17.4 / 9.55 | 0.249 | 0.179 | 0.0983 | +| mf8full | power_synth | shl | 95678 | 0.00234 | 0.000397 | 2.19 (0.86 / 0.98) | 0.95 / 1.69 / 3.38 | 3.88 (3.14 to 5.57) | 2.71 | 1.95 | 1.41 | 8.48 / 4.65 | 0.584 | 0.42 | 0.231 | +| mf8full | power_synth | shr | 95678 | 0.00221 | 0.000397 | 2.07 (0.85 / 0.84) | 0.95 / 1.69 / 3.38 | 3.76 (3.02 to 5.45) | 2.63 | 1.89 | 1.36 | 8.48 / 4.65 | 0.566 | 0.407 | 0.224 | +| mf8full | power_synth | sel | 95678 | 0.0028 | 0.000397 | 2.63 (0.91 / 1.4) | 1.2 / 2.12 / 4.25 | 4.75 (3.83 to 6.88) | 3.33 | 2.4 | 1.72 | 11.3 / 6.2 | 0.537 | 0.386 | 0.212 | +| mf8full | power_synth | andn | 95678 | 0.00234 | 0.000397 | 2.19 (0.86 / 0.98) | 0.95 / 1.69 / 3.38 | 3.88 (3.14 to 5.57) | 2.72 | 1.96 | 1.41 | 11.3 / 6.2 | 0.438 | 0.315 | 0.173 | +| mf8full | power_synth | mm8 | 95678 | 0.0036 | 0.000396 | 3.37 (0.91 / 2.1) | 1.2 / 2.12 / 4.25 | 5.5 (4.57 to 7.62) | 3.85 | 2.77 | 2 | 16.4 / 8.8 | 0.437 | 0.315 | 0.169 | + +The base core (the 10 genesis families on the same microarchitecture; the comparator): + +| Design | Stage | Family | Cells | Logic W | Leak W | pJ logic (seq / comb) | pJ SRAM (low / nom / high) | pJ/lane-op ASAP7 | N5 | N3 | N2 | 5090 pJ/op unlocked / lock | k N5 lock | k N3 lock | k N3 unlocked | +|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| +| mf8base | power_synth | mix | 66973 | 0.00443 | 0.000263 | 4.15 (0.88 / 3) | 0.99 / 1.76 / 3.52 | 5.91 (5.14 to 7.66) | 4.13 | 2.98 | 2.14 | 18.8 / 10.3 | 0.401 | 0.289 | 0.158 | +| mf8base | power_synth | mixld | 66973 | 0.00439 | 0.000263 | 4.12 (0.88 / 3) | 0.986 / 1.75 / 3.5 | 5.87 (5.1 to 7.62) | 4.11 | 2.96 | 2.13 | 18.8 / 10.3 | 0.399 | 0.287 | 0.157 | +| mf8base | power_synth | add | 66973 | 0.00246 | 0.000264 | 2.31 (0.86 / 1.2) | 0.95 / 1.69 / 3.38 | 4 (3.26 to 5.68) | 2.8 | 2.01 | 1.45 | 11.3 / 6.2 | 0.451 | 0.325 | 0.178 | +| mf8base | power_synth | sub | 66973 | 0.00245 | 0.000264 | 2.29 (0.86 / 1.2) | 0.95 / 1.69 / 3.38 | 3.98 (3.24 to 5.67) | 2.79 | 2.01 | 1.44 | 11.3 / 6.2 | 0.449 | 0.324 | 0.178 | +| mf8base | power_synth | xor | 66973 | 0.00247 | 0.000264 | 2.32 (0.86 / 1.2) | 0.95 / 1.69 / 3.38 | 4 (3.27 to 5.69) | 2.8 | 2.02 | 1.45 | 11.3 / 6.2 | 0.452 | 0.326 | 0.179 | +| mf8base | power_synth | or | 66973 | 0.0016 | 0.000265 | 1.5 (0.84 / 0.42) | 0.95 / 1.69 / 3.38 | 3.19 (2.45 to 4.87) | 2.23 | 1.61 | 1.16 | 11.3 / 6.2 | 0.36 | 0.259 | 0.142 | +| mf8base | power_synth | rotl | 66973 | 0.00259 | 0.000264 | 2.43 (0.86 / 1.3) | 0.95 / 1.69 / 3.38 | 4.11 (3.38 to 5.8) | 2.88 | 2.07 | 1.49 | 11.3 / 6.2 | 0.464 | 0.334 | 0.183 | +| mf8base | power_synth | rotr | 66973 | 0.00251 | 0.000264 | 2.35 (0.86 / 1.3) | 0.95 / 1.69 / 3.38 | 4.04 (3.3 to 5.73) | 2.83 | 2.04 | 1.47 | 11.3 / 6.2 | 0.456 | 0.328 | 0.18 | +| mf8base | power_synth | mul | 66973 | 0.00229 | 0.000264 | 2.14 (0.85 / 1.1) | 0.95 / 1.69 / 3.38 | 3.83 (3.09 to 5.52) | 2.68 | 1.93 | 1.39 | 13.9 / 8.3 | 0.323 | 0.233 | 0.139 | +| mf8base | power_synth | mulhi | 66973 | 0.00217 | 0.000264 | 2.03 (0.84 / 0.96) | 0.95 / 1.69 / 3.38 | 3.72 (2.98 to 5.41) | 2.61 | 1.88 | 1.35 | 39.6 / 21 | 0.124 | 0.0893 | 0.0474 | +| mf8base | power_synth | mad | 66973 | 0.00472 | 0.000263 | 4.43 (0.9 / 3.3) | 1.2 / 2.12 / 4.25 | 6.55 (5.62 to 8.67) | 4.58 | 3.3 | 2.38 | 13.9 / 8.3 | 0.552 | 0.398 | 0.237 | +| mf8base | power_synth | shfl | 66973 | 0.00192 | 0.000265 | 1.8 (0.86 / 0.7) | 0.95 / 1.69 / 3.38 | 3.49 (2.75 to 5.17) | 2.44 | 1.76 | 1.27 | 55.8 / 29.4 | 0.083 | 0.0598 | 0.0315 | +| mf8base | power_synth | load | 66973 | 0.00359 | 0.000263 | 3.36 (0.86 / 2.3) | 0.95 / 1.69 / 3.38 | 5.05 (4.31 to 6.74) | 3.53 | 2.54 | 1.83 | 13.9 / 8.3 | 0.426 | 0.307 | 0.183 | + +Reading the rows. (1) The ALU-group families cost the chip 3.1 to 3.3 pJ per lane-op at N5 against the card's 6.2 +at the lock (k 0.51 to 0.53); or, popc, clz, bfe, prmt 2.3 to 2.9 (k 0.23 to 0.38); the multiply 2.9 (k 0.35); +mulhi 2.8 against the card's 21 (k 0.13); the shuffle 2.9 against 29.4 (k 0.10); mad is the dearest op for the +chip at 5.2 (three reads and two units, k 0.62) and the shifters the highest k (0.57 to 0.58) because the card +does them cheapest. (2) The SRAM term is 1.7 pJ nominal per lane-op (0.95 to 3.4): a third of the row; the +sequential term (the phase latches, the instruction register, the counters at five edges per op) 0.86 pJ; the rest +is the units and the macro output nets. (3) The reserve families are cheaper for the chip than the genesis +families: every live-family mix sits under the class v4 draw, and the bound with all eight live reads 11 percent +under it, because the card's dearest instructions (mulhi, shfl, mad) are the genesis ones. + + +## 4. The whole-hash energy and k per family, node-for-node and a node ahead + +The whole-hash shadow is 102,612 chip ops (the 102,100 counted shadow ops of the record plus the 512-instruction +base program; W = 4 adds 384 fold steps). The chip's cost is absolute (its own pJ at its node); the card's premium +on the same draw is the measured 0.652 microjoules at the lock, moved by the live family's measured step ratio at 4 +points of 79 (modelled). Node-for-node is N5 (the 5090's own class), a node ahead N3; every factor claimed. + +design mf8full stage power_synth; the class v4 draw on the core: 6.58 pJ per lane-op ASAP7, 4.61 N5, 3.32 N3 (band 4.07 to 5.84 at N5) + +| Family live (4 points of 79) or draw | Chip pJ per op N5 / N3 (band) | 5090 pJ per op at the lock | k N5 / N3 | Chip shadow per hash, microjoules N5 / N3 (the mix with the family live) | Change vs the class v4 draw | The card's premium per hash at the lock (modelled from the step ratio) | Change | +|---|---|---|---|---|---|---|---| +| the class v4 draw (10 genesis families) | 4.61 / 3.32 (4.07 to 5.84) | 10.3 | 0.45 / 0.32 | 0.473 / 0.340 | +0.0 percent | 0.652 | +0.0 percent | +| add (unit row, every instruction) | 3.15 / 2.27 (2.63 to 4.33) | 6.2 | 0.51 / 0.37 | 0.323 / 0.233 | -31.7 percent | 0.392 | -39.8 percent | +| sub (unit row, every instruction) | 3.14 / 2.26 (2.63 to 4.32) | 6.2 | 0.51 / 0.36 | 0.322 / 0.232 | -31.8 percent | 0.392 | -39.8 percent | +| xor (unit row, every instruction) | 3.20 / 2.30 (2.68 to 4.38) | 6.2 | 0.52 / 0.37 | 0.328 / 0.236 | -30.5 percent | 0.392 | -39.8 percent | +| or (unit row, every instruction) | 2.38 / 1.72 (1.87 to 3.57) | 6.2 | 0.38 / 0.28 | 0.245 / 0.176 | -48.2 percent | 0.392 | -39.8 percent | +| rotl (unit row, every instruction) | 3.27 / 2.36 (2.75 to 4.45) | 6.2 | 0.53 / 0.38 | 0.336 / 0.242 | -29.0 percent | 0.392 | -39.8 percent | +| rotr (unit row, every instruction) | 3.15 / 2.27 (2.63 to 4.33) | 6.2 | 0.51 / 0.37 | 0.323 / 0.233 | -31.7 percent | 0.392 | -39.8 percent | +| mul (unit row, every instruction) | 2.92 / 2.10 (2.40 to 4.10) | 8.3 | 0.35 / 0.25 | 0.299 / 0.216 | -36.7 percent | 0.525 | -19.4 percent | +| mulhi (unit row, every instruction) | 2.81 / 2.03 (2.30 to 3.99) | 21.0 | 0.13 / 0.10 | 0.289 / 0.208 | -38.9 percent | 1.329 | +103.9 percent | +| mad (unit row, every instruction) | 5.17 / 3.72 (4.52 to 6.66) | 8.3 | 0.62 / 0.45 | 0.531 / 0.382 | +12.3 percent | 0.525 | -19.4 percent | +| shfl (unit row, every instruction) | 2.93 / 2.11 (2.41 to 4.11) | 29.4 | 0.10 / 0.07 | 0.300 / 0.216 | -36.5 percent | 1.861 | +185.4 percent | +| load (unit row, every instruction) | 4.03 / 2.90 (3.51 to 5.21) | 8.3 | 0.48 / 0.35 | 0.413 / 0.297 | -12.6 percent | 0.525 | -19.4 percent | +| prmt live | 2.85 / 2.05 (2.34 to 4.03) | 11.5 | 0.25 / 0.18 | 0.464 / 0.334 | -1.9 percent | 0.662 | +1.5 percent | +| lop3 live | 3.46 / 2.49 (2.81 to 4.94) | 13.0 | 0.27 / 0.19 | 0.467 / 0.336 | -1.3 percent | 0.688 | +5.6 percent | +| shfla live | 3.47 / 2.50 (2.82 to 4.95) | 9.5 | 0.37 / 0.26 | 0.467 / 0.336 | -1.3 percent | 0.669 | +2.7 percent | +| popc live | 2.30 / 1.65 (1.78 to 3.48) | 9.3 | 0.25 / 0.18 | 0.461 / 0.332 | -2.5 percent | 0.669 | +2.5 percent | +| clz live | 2.32 / 1.67 (1.80 to 3.50) | 10.1 | 0.23 / 0.17 | 0.461 / 0.332 | -2.5 percent | 0.673 | +3.2 percent | +| bfe live | 2.38 / 1.71 (1.86 to 3.56) | 9.5 | 0.25 / 0.18 | 0.461 / 0.332 | -2.5 percent | 0.670 | +2.7 percent | +| shl live | 2.71 / 1.95 (2.20 to 3.90) | 4.7 | 0.58 / 0.42 | 0.463 / 0.333 | -2.1 percent | 0.644 | -1.3 percent | +| shr live | 2.63 / 1.89 (2.12 to 3.81) | 4.7 | 0.57 / 0.41 | 0.462 / 0.333 | -2.2 percent | 0.644 | -1.3 percent | +| sel live | 3.33 / 2.40 (2.68 to 4.81) | 6.2 | 0.54 / 0.39 | 0.466 / 0.336 | -1.4 percent | 0.652 | +0.0 percent | +| andn live | 2.72 / 1.96 (2.20 to 3.90) | 6.2 | 0.44 / 0.32 | 0.463 / 0.333 | -2.1 percent | 0.652 | +0.0 percent | +| mm8 live | 3.85 / 2.77 (3.20 to 5.34) | 8.8 | 0.44 / 0.31 | 0.469 / 0.337 | -0.8 percent | 0.699 | +7.2 percent | +| fwd (unit row, every instruction) | 3.81 / 2.74 (3.29 to 4.99) | 8.3 | 0.46 / 0.33 | 0.391 / 0.281 | -17.3 percent | 0.525 | -19.4 percent | +| the draw with shfla and mm8 live (measured mix) | 4.50 / 3.24 (3.96 to 5.76) | 10.3 | 0.44 / 0.31 | 0.462 / 0.333 | -2.2 percent | 0.652 | +0.0 percent | +| every reserve family live at 4 points (the bound, measured mix) | 4.11 / 2.96 (3.56 to 5.35) | 10.3 | 0.40 / 0.29 | 0.422 / 0.304 | -10.8 percent | 0.652 | +0.0 percent | +| the draw with one load in 16 | 4.59 / 3.31 (4.06 to 5.82) | 10.3 | 0.45 / 0.32 | 0.471 / 0.339 | -0.3 percent | 0.652 | +0.0 percent | +| W = 4: three fold steps per load | 4.55 / 3.27 (4.02 to 5.76) | 10.3 | 0.44 / 0.32 | 0.466 / 0.336 | -1.3 percent | 0.652 | +0.0 percent | +| the 64-instruction shape | 4.44 / 3.19 (3.90 to 5.67) | 10.3 | 0.43 / 0.31 | 0.455 / 0.328 | -3.7 percent | 0.652 | +0.0 percent | + +The whole-hash edge per joule with the class v4 shadow on the core (absolute: the chip pays its own pJ whatever the card does): +| Memory (E_mem, microjoules) | Chip E_hash N5 / N3 | vs 5090 lock 2.33 | vs 5090 stock 3.36 | vs 5080 lock 2.06 | vs M5 Max 1.40 | +|---|---|---|---|---|---| +| GDDR7 board (0.466) | 0.939 / 0.806 | 2.5x / 2.9x | 3.6x / 4.2x | 2.2x / 2.6x | 1.5x / 1.7x | +| HBM3 one stack (0.321) | 0.794 / 0.661 | 2.9x / 3.5x | 4.2x / 5.1x | 2.6x / 3.1x | 1.8x / 2.1x | +| SRAM N2 die at W = 1 (0.036) | 0.509 / 0.376 | 4.6x / 6.2x | 6.6x / 8.9x | 4.1x / 5.5x | 2.8x / 3.7x | + +The same edge on the base core (the genesis-only comparator): 2.6x / 3.0x microjoules per hash +on the GDDR7 board at N5 / N3, 3.8x / 4.4x against the 5090 at its lock; the bank costs the +adversary 5 percent of its edge (0.939 against 0.890 microjoules on the GDDR7 board, 2.5x against 2.6x), which is +the whole answer to the review's question in one number: the 180-day calendar costs a chip that carries the bank +about 11 percent of its shadow energy and 43 percent of its core cells, and no epoch costs it a part. + + +## 5. The placed rows (8 lanes, routed, SPEF) and the 32-lane core + +ROWS_PLACED + +## 6. The board: joules per valid hash and USD per sustained MH/s for the complete machine + +The complete machine: the memory devices at their modelled random-read energy and activate ceiling (chip-model-v3 +5.3, unmeasured; the 5090 reaches 82 percent of the GDDR7 figure, the sustained fraction here), the controller and +PHY die, the core die sized to retire the hash's ops at the memory's sustained rate (lanes at 667 MHz over 5 phases; +0.002 mm^2 per lane at N5 from the 8-lane core's floorplan at 40 percent utilisation scaled x0.55, approximate; USD +0.36 per mm^2 of N5 from sram-mirror's yield model; 50 uW of leakage per lane, the synthesis figure), power delivery +(PSU 92 percent, VRM 90 percent), cooling (3 percent), a board and assembly (USD 200), and one full node per 100 +machines (85 W and USD 1,500 shared: the state-derived dataset's host, priced as the review's rule 3 asks). The +"high" case takes the memory's lower ceiling (the 5090's measured 17.5 G on GDDR7; the JEDEC tFAW floor on HBM3), +the high read energy and the high SRAM term together. GPU rows: the 5090 at its lock 2.33 microjoules at 134.76 +MH/s, USD 1,999 plus USD 150 of rig share (USD 15.9 per MH/s; at the USD 3,000 street price 23.4); the 5080 at its +lock 2.06 at 71.20 MH/s, USD 999 plus 150 (USD 16.1 per MH/s); the discrete-GPU cohort by count (design 3.4 and +10.4: 8 GB 22 percent, 12 GB 22, 16 GB 28, 24 GB and up 16, the rest 10 and 11 GB) at its tuned points about 3.6 +microjoules (2.5 to 4.5, approximate: the 5070 and 5070 Ti 1.7 to 1.75 modelled, the 4070 3.58 measured, the 4090 +3.64, the 3090 6.4, the 9070 XT 8.1 measured) and about USD 18 per MH/s (14 to 28); the M5 Max 1.40 at 27.9 MH/s is +reported in section 4, not headlined. + +Node-for-node (N5), the full core at 4.61 pJ per lane-op: + +core 4.61 pJ per lane-op (band 4.07 to 5.84), 102612 ops per hash, leakage 50 uW per lane, 0.002 mm^2 per lane at N5 + +| Memory arrangement | Case | Sustained MH/s | Machine W | microjoules per hash (whole machine) | Core lanes | Core mm^2 (N5) | Capex USD | USD per MH/s | vs 5090 lock 2.33 (J / USD) | vs 5080 lock 2.06 | vs cohort 3.6 / USD 18 | +|---|---|---|---|---|---|---|---|---|---|---|---| +| GDDR7 board, 16 devices, 64 channels (the 5090 memory without the GPU) | nominal | 136 | 175 | 1.280 | 104,960 | 210 | 661 | 4.84 | 1.8x / 3.3x | 1.6x / 3.3x | 2.8x / 3.7x | +| GDDR7 board, 16 devices, 64 channels (the 5090 memory without the GPU) | low | 136 | 154 | 1.132 | 104,960 | 210 | 661 | 4.84 | 2.1x / 3.3x | 1.8x / 3.3x | 3.2x / 3.7x | +| GDDR7 board, 16 devices, 64 channels (the 5090 memory without the GPU) | high | 112 | 180 | 1.603 | 86,235 | 172 | 647 | 5.77 | 1.5x / 2.8x | 1.3x / 2.8x | 2.2x / 3.1x | +| HBM3 one stack (activate ceiling unmeasured; JEDEC tFAW floor 2.3 G) | nominal | 71 | 77 | 1.084 | 54,656 | 109 | 704 | 9.91 | 2.1x / 1.6x | 1.9x / 1.6x | 3.3x / 1.8x | +| HBM3 one stack (activate ceiling unmeasured; JEDEC tFAW floor 2.3 G) | low | 71 | 70 | 0.984 | 54,656 | 109 | 704 | 9.91 | 2.4x / 1.6x | 2.1x / 1.6x | 3.7x / 1.8x | +| HBM3 one stack (activate ceiling unmeasured; JEDEC tFAW floor 2.3 G) | high | 15 | 34 | 2.228 | 11,748 | 23 | 673 | 44.09 | 1.0x / 0.4x | 0.9x / 0.4x | 1.6x / 0.4x | +| HBM3 eight stacks (an H100-class package) | nominal | 566 | 559 | 0.987 | 435,713 | 871 | 3,079 | 5.44 | 2.4x / 2.9x | 2.1x / 3.0x | 3.6x / 3.3x | +| HBM3 eight stacks (an H100-class package) | low | 566 | 502 | 0.886 | 435,713 | 871 | 3,079 | 5.44 | 2.6x / 2.9x | 2.3x / 3.0x | 4.1x / 3.3x | +| HBM3 eight stacks (an H100-class package) | high | 122 | 217 | 1.772 | 93,987 | 188 | 2,833 | 23.18 | 1.3x / 0.7x | 1.2x / 0.7x | 2.0x / 0.8x | +| SRAM full store, one N2 reticle, 2 GiB at W = 1 (the strongest five-year chip) | nominal | 535 | 400 | 0.747 | 411,225 | 822 | 1,211 | 2.27 | 3.1x / 7.0x | 2.8x / 7.1x | 4.8x / 7.9x | +| SRAM full store, one N2 reticle, 2 GiB at W = 1 (the strongest five-year chip) | low | 609 | 403 | 0.662 | 468,572 | 937 | 1,252 | 2.06 | 3.5x / 7.8x | 3.1x / 7.8x | 5.4x / 8.8x | +| SRAM full store, one N2 reticle, 2 GiB at W = 1 (the strongest five-year chip) | high | 419 | 394 | 0.940 | 322,466 | 645 | 1,147 | 2.74 | 2.5x / 5.8x | 2.2x / 5.9x | 3.8x / 6.6x | + +Lifetime cost in USD per TH (10^12 hashes), capex spread over the life plus electricity at USD 0.08 per kWh: +| Machine | 0.5 y | 1 y | 2 y | 3 y | of which electricity | +|---|---|---|---|---|---| +| 5090 at the lock | 1.063 | 0.557 | 0.305 | 0.220 | 0.0518 | +| 5080 at the lock | 1.069 | 0.557 | 0.302 | 0.216 | 0.0458 | +| cohort card | 1.222 | 0.651 | 0.365 | 0.270 | 0.0800 | +| GDDR7 board, 16 devices, 64 channels chip | 0.335 | 0.182 | 0.105 | 0.080 | 0.0284 | +| HBM3 one stack chip | 0.653 | 0.338 | 0.181 | 0.129 | 0.0241 | +| HBM3 eight stacks chip | 0.367 | 0.194 | 0.108 | 0.079 | 0.0219 | +| SRAM full store, one N2 reticle, 2 GiB at W = 1 chip | 0.160 | 0.088 | 0.053 | 0.041 | 0.0166 | + +A node ahead (N3), the same machine: + +|---|---|---|---|---|---|---|---|---|---|---|---| +| GDDR7 board, 16 devices, 64 channels (the 5090 memory without the GPU) | nominal | 136 | 150 | 1.101 | 104,960 | 147 | 638 | 4.67 | 2.1x / 3.4x | 1.9x / 3.5x | 3.3x / 3.9x | +| GDDR7 board, 16 devices, 64 channels (the 5090 memory without the GPU) | low | 136 | 133 | 0.972 | 104,960 | 147 | 638 | 4.67 | 2.4x / 3.4x | 2.1x / 3.5x | 3.7x / 3.9x | +| GDDR7 board, 16 devices, 64 channels (the 5090 memory without the GPU) | high | 112 | 155 | 1.380 | 86,235 | 121 | 628 | 5.61 | 1.7x / 2.8x | 1.5x / 2.9x | 2.6x / 3.2x | +| HBM3 one stack (activate ceiling unmeasured; JEDEC tFAW floor 2.3 G) | nominal | 71 | 64 | 0.905 | 54,656 | 77 | 693 | 9.75 | 2.6x / 1.6x | 2.3x / 1.7x | 4.0x / 1.8x | +| HBM3 one stack (activate ceiling unmeasured; JEDEC tFAW floor 2.3 G) | low | 71 | 59 | 0.824 | 54,656 | 77 | 693 | 9.75 | 2.8x / 1.6x | 2.5x / 1.7x | 4.4x / 1.8x | +| HBM3 one stack (activate ceiling unmeasured; JEDEC tFAW floor 2.3 G) | high | 15 | 31 | 2.004 | 11,748 | 16 | 671 | 43.93 | 1.2x / 0.4x | 1.0x / 0.4x | 1.8x / 0.4x | +| HBM3 eight stacks (an H100-class package) | nominal | 566 | 458 | 0.808 | 435,713 | 610 | 2,985 | 5.27 | 2.9x / 3.0x | 2.5x / 3.1x | 4.5x / 3.4x | +| HBM3 eight stacks (an H100-class package) | low | 566 | 411 | 0.726 | 435,713 | 610 | 2,985 | 5.27 | 3.2x / 3.0x | 2.8x / 3.1x | 5.0x / 3.4x | +| HBM3 eight stacks (an H100-class package) | high | 122 | 189 | 1.548 | 93,987 | 132 | 2,812 | 23.02 | 1.5x / 0.7x | 1.3x / 0.7x | 2.3x / 0.8x | +| SRAM full store, one N2 reticle, 2 GiB at W = 1 (the strongest five-year chip) | nominal | 724 | 398 | 0.550 | 557,288 | 780 | 1,196 | 1.65 | 4.2x / 9.7x | 3.7x / 9.8x | 6.5x / 10.9x | +| SRAM full store, one N2 reticle, 2 GiB at W = 1 (the strongest five-year chip) | low | 828 | 402 | 0.485 | 636,578 | 891 | 1,236 | 1.49 | 4.8x / 10.7x | 4.2x / 10.8x | 7.4x / 12.1x | + +Reading. (1) The complete GDDR7 machine reads 1.8x the 5090 at its lock per joule node-for-node (1.5x to 2.1x) and +2.1x a node ahead (1.7x to 2.4x); against the 5080 at its lock 1.6x (1.3x to 1.8x) and 1.9x; against the cohort +card 2.8x and 3.3x. Per dollar of capex it is 3.3x the 5090 at MSRP (4.8x at the street price) and 3.7x the cohort, +because the board carries the same USD 320 of memory and USD 76 of core silicon where the card carries a 750 mm^2 +GPU. (2) The HBM3 one-stack machine is no better per joule than GDDR7 once the controller, the host and the power +train are in, and its dollars per MH/s are twice the card's at the modelled ceiling and 2.7x worse than the card at +the JEDEC tFAW floor: the "same DRAM" assumption is tested and the adversary's cheapest memory IS the card's memory, +so the GDDR7 board is the machine the economics must answer. (3) The N2 SRAM die at the hash's own width is the +strongest machine at 3.1x per joule node-for-node (2.5x to 3.5x) and 4.2x a node ahead, and 7x per dollar of +silicon, with the project cost (USD 100 M to 500 M, claimed) as its only hold. (4) Over a 3-year life the GDDR7 +machine's cost per TH is 0.080 USD against the 5090's 0.220 and the cohort's 0.270 (2.7x to 3.4x); at a 1-year life +3.1x; electricity is a quarter of the machine's lifetime cost and a fifth of the card's, so the per-joule edge is +the smaller half of the economic edge and the capex per MH/s the larger. The profitability surface the review asks +for (development, fleet capital, share, margin, electricity, pre-production, discounting, residual, operator and +manufacturer apart) takes these per-TH rows as its inputs; it is the economics lane's, not this file's. + + +## 7. The lifetime answer: what each transition needs, and what is credited + +The rule: a transition is credited only where the next entry needs a physical resource this design cannot supply +economically; firmware changes (a program, a register, a weight) are credited zero. "Performance loss" is the change in +the chip's energy per hash when the entry is live at its draw weight (4 points of 79 for a reserve family; the whole +program for an atom or a shape), from the rows of sections 3 and 4; the GPU's own change on the same draw is beside it. + +| Transition (the next epoch draws it) | Physical resource it needs | Does this design hold it? | Chip loss at the draw weight | The card's change on the same draw (measured ratio) | Credited obsolescence benefit | +|---|---|---|---|---|---| +| G1 to G7 (the ARX group) at any band weight | the ALU group | yes | 0 to +3 percent of the shadow energy across the band (the unit rows 3.1 to 3.3 pJ at N5 against the draw's 4.6) | 1.00 | 0 | +| G8, G9, G6 (mul, mulhi, mad) at any band weight | the multiplier and the third read | yes | -1 to +2 percent at B = 4 (mul 2.9, mulhi 2.8, mad 5.2 pJ at N5) | mul 1.1, mulhi about 3.4 (the card's dearest ALU op) | 0 | +| G10 shfl at its cap (8 points) | the lane butterfly | yes (per core) | 0 (2.9 pJ at N5, under the draw's mean) | 4.9x the add per op | 0 (the card pays 29.4 pJ for the move the chip pays about 1) | +| R1 shfla live (4 points) | a general lane crossbar | yes (per core; the one network a butterfly cannot emulate in one op) | 0 (2.9 pJ at N5, under the draw's mean)A | 1.53 (NVIDIA), 1.91 (Apple) | 0 | +| R2 perm live | a byte selector | yes | -1.9 percent | 1.30 | 0 | +| R3 popc and clz live | a popcount tree, a priority encoder | yes | -2.5 percent | 1.50 and 1.63 | 0 | +| R4 to R7 (bfe, shl and shr, sel, andn) live | a shifter, a mask, a select, an and-not | yes | -2.1 to -1.4 percent | 0.75 to 1.54 | 0 | +| R8 mm8 live | a u8 dot4 per lane (8 chip ops per card tile) | yes | -0.8 percent (3.9 pJ per dp4a at N5, 1.0 pJ per MAC, against the card's 2.2 pJ per MAC at the lock) | the tile: 2.43 the add step per card instruction (32 MACs) | 0 (the chip's MAC is cheaper than the card's by 4x to 30x on the public figures; this is the card's loss, not the chip's) | +| the op-mix band draw (B = 4 on injecting families) | nothing: the program | yes | within the family rows above | within 11 percent per instruction (shadow-k 6.2) | 0 | +| the fold constants draw | five registers | yes | 0 | 0 | 0 | +| the block shape draw (64, 128, 256) | the program-length register; 256 words of imem | yes | -3.7 percent at 64 (the imem term; 0 at 128 and 256) | 64 ran 2.5 to 3.5 percent faster than 256 on the 5090 and the M5 Max (measured) | 0 | +| the read-width draw W = 4 (16 bytes) | three fwd instructions per load (firmware); the same DRAM sector | yes | +0.3 percent per hash (384 fold steps at 3.8 pJ) | within 2.7 percent on the 5090 and the 9070 XT, within 1 on the M5 Max (measured) | 0 | +| the 64-register window | the 64 x 256 macro per 8 lanes | yes (built in) | 0 (it is the base) | modelled: occupancy to about half on a 5090 or 4090, the rate expected to hold (the hash lane) | 0 | +| the dataset atom draw A1 / A2 / A3 (mixer x4, x8, dr368) | nothing per hash; the per-window build is a program on the same core (section 7.1) | yes | 0 per hash; the build 0.72 J per window per machine at 1 GiB (0.2 mW averaged), 1.45 J at 2 GiB | the card's rate unmoved by the atom (within 0.1 MH/s on the 5090, measured) | 0 | +| a new op family outside the 18 (a bank refresh, a release) | a unit the die lacks | no: the chip emulates it from the 18 at the vendor penalty, as the cards do (1.5x to 2.4x per op, measured on the cards) or loses its 4 points | at 4 points of 79: at most 4 / 79 x (penalty - 1) of the shadow energy, about 2 to 6 percent (modelled) | the same emulation on every card that predates the release, 0 on a card with the native op | 0 unless the family is one the 18 cannot emulate; none proposed is | +| a new read atom W = 8 (32 bytes, `admissible: false` today) | seven fwd instructions per load; the same GDDR7 sector; on an SRAM die +0.3 nJ of wire per read (floor lane 3) | yes | +0.7 percent per hash (896 fold steps) | free by the measured rows (one sector per load on NVIDIA) | 0 | +| the dataset floor step (layer 2: 5.5 / 8.5 / 11.5 GiB) | device memory: 3 to 6 GDDR7 devices more, or 3 to 6 N2 reticles on the SRAM die | yes on DRAM (USD 60 to 120 more); the SRAM die's ticket rises USD 1,000 per step | 0 per joule on DRAM; the SRAM die's USD per MH/s unmoved (every die powered) | the tuned 5090 pays 4, 8 and 10 percent more energy per hash at 2, 4 and 8 GiB (measured) | 0 per joule; a capex ticket on the SRAM die only (floor lane 3) | + +Reading, before the numbers: nothing in the bank asks for a resource the design lacks, because the bank is public at +genesis and its whole op-family set is a few adders per lane and two networks per core. What the bank does to this +chip is the per-op cost of carrying the unit set (sections 3 and 5: the full core against the base core on the same +microarchitecture) and the leakage of the units that are not live, and that is the number the credit must come from. + +### 7.1 The per-window dataset build on the chip (the atoms' only cost) + +Under class v5 the dataset is rebuilt from the chain's state every window (3,600 s). A 1 GiB build is 157 G ops +(measured as 13.4 ms on a 5090; the record's row 7). On this core at 4.61 pJ per lane-op (N5) that is 0.72 J per +window per machine, 0.0002 W averaged over the window, against a machine of hundreds of watts: 0.0001 percent of +the machine's energy, the same for every atom within the atom's op count (x4 half of x8, dr368 about x4's). The +chip's node is the host the board model carries (one full node per 100 machines: 85 W and USD 1,500 shared); a +specialised machine with a host keeping the dataset current is inside the adversary model by the review's rule (3), +and this is its price: under 1 W and USD 15 per machine. + + +## 8. Energy resistance, economic resistance and response capability, stated separately + +Three separate things, each with its own number and its own holder. + +**Energy resistance** is a property of the memory system and the shadow, not of the calendar. Against the +adversary's re-optimised chip the complete GDDR7 machine reads 1.8x the 5090 at its lock per joule node-for-node +(1.5x to 2.1x), 2.1x a node ahead; 1.6x and 1.9x against the 5080 at its lock; 2.8x and 3.3x against the cohort +card; the N2 SRAM die 3.1x and 4.2x. The bank moves these by 5 percent in the honest side's favour (the chip's +shadow energy +11 percent for carrying 18 families instead of 10) and no more; the register window moves them by +0.03 to 0.13 of k and no more. What holds the per-joule number is the shadow's size on the card's own operating +point and the memory system's activate ceiling; what would move it is a memory arrangement the chip cannot buy, and +section 6 says there is none: the chip's cheapest memory is the card's own. + +**Economic resistance** is capex per sustained MH/s and the project cost against the chain's revenue. The chip's +machine costs USD 4.84 per MH/s against the card's 16 to 18, so over a 3-year life it mines at 0.080 USD per TH +against 0.22 to 0.27: 2.7x to 3.4x, of which electricity is the smaller half. The calendar does not shorten that +life: no transition in the bank retires the chip, so the 3-year stress life holds in full and the withdrawn headline +("dies within an epoch, under 1x over its life") stays withdrawn. What holds the economics is the project (USD 20 M +to 75 M for the GDDR7-board chip, floor lane 5; USD 100 M to 500 M for the SRAM die, claimed) against the miner +revenue the chain pays, which is the profitability surface the review asks for and the economics lane owns; the +dataset floor is a ticket on the SRAM die only (USD 1,000 per step) and nothing on the DRAM board (USD 60 per step). + +**Response capability** is what the bank actually buys: the chain can change its object every 180 days without a +release, and a chip that carries the bank follows by firmware at a per-transition loss of -3.7 to +0.7 percent of +its shadow energy (zero credited). A family outside the bank costs that chip an emulation penalty of 2 to 6 percent +of the shadow at 4 points, which every card that predates the release pays too; a structural change (a new read +atom, a new derivation) costs the chip a host update and the cards a release. So the bank is a response channel +whose value per event is the per-transition loss column, not a chip retirement; it is worth keeping for what it is +(no fork for a family change, a fixed-function datapath dead on day one, section 7's table) and must not be served as +energy or economic resistance. + + +## 9. Consequences per tier (the standing rule) + +| Tier | What the rows mean for it | What is being done | +|---|---|---| +| Home miner, one 8 GB card | Against the adversary's machine the cohort card sits 2.8x to 3.3x behind per joule and 3.7x per dollar; the bank does not change that, the operating-point lock does not reach this tier (no Blackwell lever on Ampere; Ada's lock is worth 1.2x); the first dataset step (5.5 GiB) retires this card from mining | the schedule's replacement cost (USD 350 to 450 to a 16 GB card) is stated beside the step; the 24 Gb device case shows the chip pays USD 700 once for the same horizon | +| One 12 GB card | the same per joule; mines through the 8.5 GiB step, loses proving coexistence at the first step (7.3 + 8.6 GB over 12), leaves mining at 11.5 GiB | the mine-or-prove routing (0.3.21) and the replacement cost; the step offsets (section 11) | +| One 16 GB card (the 5080 at its lock, the 9070 XT) | the 5080 at its lock is the honest NVIDIA floor: 1.6x behind the chip machine node-for-node, 1.9x a node ahead; the 9070 XT 4x to 5x behind; mines through every step, loses proving coexistence at 8.5 GiB | the per-dollar edge (3.3x) is the number the project-cost wall must answer; the lock stays the one lever | +| One 24 or 32 GB card (the 5090 at its lock, the M5 Max) | 1.8x / 2.1x behind the chip machine; the M5 Max about 1.5x (reported); mines and proves through every step | nothing on the card side moves this; the rotation layers are response capability, not resistance | +| A rig | per joule its cards; per dollar 3.3x behind the chip at MSRP, 4.8x at street; over 3 years 2.7x to 3.4x per TH | the issuance trigger and the share-pattern detector (the record's item 4) stay the instruments; the profitability surface is the economics lane's | +| A pool user | a chip fleet is a few operators at 1.1 to 1.3 microjoules; the detector on the observer is what tells a pool a chip has arrived | unchanged | +| The public claim | the chip line this file supports: "a chip that survives rotation is a GPU-shaped core on the card's own memory; it reads about 1.8x the best honest card per joule on the same node, 2.1x a node ahead, and about 3x per dollar; the rotation calendar changes its firmware, not its cost" | served only on the coordinator's word, after the placed rows | + +## 10. Sources and what is owed + +- The GPU side: `docs/analysis/counter-asic-4-research.md` 15.1a (the 5090 microbench, 8 October 2026, measured); + the floor programme's tier table (`docs/design/class-v6-rotating-family.md` 10.4: the 5090 at the 1,300 lock 2.33 + microjoules at 134.76 MH/s and 312.5 W, the 5080 at the 1,100 lock 2.06 at 71.20 MH/s and 146.6 W, stock 3.36 and + 3.48, the 4070, 4090, 3090 and 9070 XT rows, the M5 Max 1.40); the reserve families' step costs, design 4.2 + (measured on the cards); the card population by count, design 3.4 (approximate). +- The chip side: this lane's RTL and flow (`tools/chip-model/mf/`), ORFS on ASAP7 (Clark et al., Microelectronics + Journal 2016; the 7.5-track RVT library, TC corner), FakeRAM2.0 macros (ABKGroup, the ORFS platform's + `fakeram7_64x256` and `fakeram7_256x34`, LEF and Liberty; the generator's own config marks its values "not + realistic", so only area, pins and placement are taken from it); the k lane's rows (`floor/shadow-k.md`, the + shuffle row 1.24 pJ per lane-op routed, relayed 16:0x BST) cited as published. +- The SRAM access energy band: Horowitz, "Computing's energy problem (and what we can do about it)", ISSCC 2014 + (45 nm: 8 KB SRAM 10 pJ per 64-bit read, 32 KB 20 pJ); the scaling to a 7 nm class node approximate; the k lane's + imem figure (2 to 4 pJ per 32-bit read, approximate); CACTI-class estimates (approximate). +- Node scaling (claimed): TSMC's technology pages for N5, N3E and N2, read 8 October 2026 (shadow-k section 7). +- The board: `docs/analysis/chip-model-v3.md` 5.3 and 5.5 (the GDDR7 and HBM3 random-read engines, the activate + ceilings, the static and controller allowances, the prices, all modelled or claimed; the 5090 at 82 percent of the + GDDR7 ceiling, measured); `floor/sram-and-floor.md` 2.1 (the SRAM die at W = 1, modelled); the power delivery, + cooling and host allowances are this file's (approximate; the sensitivity is stated beside each). +- The dataset build: the record's row 7 (a 1 GiB rebuild 157 G ops, 13.4 ms on a 5090, measured). + +Owed: the k lane's crossbar, scratch and tile rows (in place and route at 16:0x BST); the placed 32-lane core (the +8-lane core is placed; the 32-lane row is synthesis only); a real PDK memory compiler's figure for the two macros +(FakeRAM gives area and pins only); the 64-register window's GPU cost measured (the hash lane's generator line); +the HBM3 activate ceiling (unmeasured, the AWS F2 hour); the profitability surface of the review's rule (2) over the +lifetime rows of section 6, which this file states as cost per TH and leaves the NPV to the economics lane. + + +## 11. The data-local and memory-sharing adversary (the ProgPoW audit's threat; the third review, 17:5x BST) + +The threat: split the dataset across processors and move the intermediate computation to the processor nearest +the next item, share datasets, keep partial caches, recompute, re-lay the dataset, run several engines off one +set-up; price the cheapest combination of moving state, moving data, recomputing and local resources against the +live state of class v6, and say whether the necessary state makes data-local execution dear enough to erase any +memory-system saving. The cost model, explicit, every term labelled: + +| Term | Per dependent read | Source | +|---|---|---| +| The live state a hash carries across a read | 64 registers x 32 bits = 2,048 bits (61 of 64 necessary across the chain, the review's reading of the fold rule) plus pc, nonce and era pointer about 64 bits: **about 2,100 bits** | the class program (`verify::fold_words`: every register is consumed) | +| The data a read returns, with its address and control | 32 bits of data, 32 of address, about 16 of control: **about 80 bits** at W = 1 (176 at W = 4, 304 at W = 8) | floor lane 3, section 2.1 (modelled) | +| Moving bits on one die (global wire) | 1.3 pJ per bit across a 24 mm die (0.65 to 2.6) | floor lane 3 (approximate) | +| Moving bits between dies on a package | UCIe 0.5 pJ per bit (0.25 to 0.5) | claimed (UCIe via SNIA), floor lane 3 | +| Moving bits between packages on a board | 5 to 10 pJ per bit (a PCB SerDes link; approximate, from memory) | approximate | +| A dependent random 32-byte read from GDDR7 / HBM3 | 2.0 / 1.2 nJ (1.5 to 2.6 / 1.0 to 1.5) | chip-model-v3 5.3 (modelled) | +| An on-die SRAM read at W = 1 | 0.25 nJ (0.20 to 0.35) including the wire | floor lane 3 (modelled) | +| Recomputing one item instead of reading it | 9,360 ops, about 43 nJ on this core at N5 (4.61 pJ per op) and 6.3 nJ on a wired mixer pipeline (chip-model-v3 5.2) | modelled | +| The per-window set-up (the 1 GiB build and the host) | 0.7 J per machine per window, 0.85 W and USD 15 of host per machine | section 7.1 | + +The four forms, priced per read at W = 1 (the hash's own width), nominal with the band: + +| Form | What moves | Cost per read | Against the baseline (data to the lane, 80 bits) | +|---|---|---|---| +| Baseline: the state stays in its lane, the data travels to it | 80 bits of data, address and control | on a die 0.10 nJ (0.05 to 0.21); on a package 0.04; the DRAM read itself 2.0 nJ beside it | 1x | +| Data-local on one die: the state travels to the macro holding the item | about 2,100 bits | 2.7 nJ (1.4 to 5.5) of wire per read: **27x the baseline's wire, and 11x the whole GDDR7 read** | 27x | +| Data-local across dies on a package (the dataset split over chiplets) | about 2,100 bits over UCIe plus the local read | 1.05 nJ (0.5 to 1.05) of hop per read: half a GDDR7 read, four SRAM reads | 26x the baseline hop | +| Data-local across packages on a board (the dataset split over boards) | about 2,100 bits over a SerDes link | 10 to 21 nJ per read: 5x to 10x a GDDR7 read | 260x | +| Memory sharing: N engines over one dataset | nothing new: the engines are the lanes in flight the baseline already has (1,172 on the GDDR7 board at the activate ceiling); the set-up is shared at 0.7 J per window | 1x | 1x | +| A partial store that recomputes the rest (the pebbling curve, chip-model-v3 5.4 with the two corrections) | a recomputed item costs 9,360 ops | 43 nJ on this core, 6.3 nJ wired, against 2.0 nJ read: **monotone, the full store is the cheapest point at every f** | 3x to 21x per recomputed item | +| A hot-item SRAM beside the DRAM (the window-layer distribution: the hottest half of the items serves 72 percent of the reads, adv-cache-2) | an SRAM read for 72 percent of the reads, a DRAM read for the rest | 0.25 x 0.72 + 2.0 x 0.28 = 0.74 nJ per read on the memory side, for USD 250 per GiB of SRAM (about half the dataset) | a capex trade bounded by the GDDR7 row above and the SRAM-die row below; no new form | +| An alternative layout (the 16 load sites and their era windows: bank the dataset by site) | nothing per read: every read is still an activate on the device that holds the item | 1x | 1x | + +Reading. (1) The necessary state is the whole argument: a read returns 80 bits and the state that must meet it is +2,100, so moving the computation to the data costs 26x the bits of moving the data to the computation, on every +medium. On one die that is 2.7 nJ of wire against 0.10; on a package half a DRAM read; across boards five to ten DRAM +reads. There is no memory-system saving for data-local execution to erase: the dependent read must be served by the +device that holds the item in every form, and what the data's trip to the lane costs (0.10 nJ on a die, 0.04 on a +package) is already the cheapest term in the model. So the ProgPoW audit's threat does not apply to a hash whose +live state is 26x its read width; it applies to a hash whose state is a few words, which class v6 is not. (2) +Memory sharing is the baseline, not an attack: the chip's lanes already share one dataset and one set-up; the +per-hash share of the set-up is 10^-15 J and of the host USD 0.15 per machine. (3) Partial stores and recomputation +are priced by the pebbling curve and lose at every point; the hot-item SRAM is a capex trade between the two rows +of section 6, not a new form. (4) Cumulative memory complexity of one evaluation, stated as the bound a chip must +pay: 128 dependent random reads, each an activate and a 32-byte sector, 4 KB of sector traffic and 128 x 2,100 bits +of state carried in a lane (never moved); 256 nJ of memory energy per hash on GDDR7 (154 on HBM3, 32 on the SRAM +die) plus 0.47 microjoules of shadow on this core at N5. Bandwidth hardness: the GDDR7 board is bound by activates +(21.3 G per second over 16 devices, 166 MH/s per board) at 38 percent of its pin bandwidth (682 GB/s of sectors of +1,792), so the hard quantity is the activate rate per dollar of devices, not bytes per second, and a chip cannot buy +more activates per device than the card has. (5) Bounded by this cost model: data-local execution (26x by the bit +count, no physical design needed), memory sharing (the baseline), partial stores (monotone), layouts (per read +invariant). Needing physical design before a number is a bound: the HBM activate ceiling (unmeasured; the AWS F2 +hour), the SRAM die's wire term (0.5 to 2.0 nJ per 64 bytes until a placed macro array exists), the on-package hop +(UCIe's 0.5 pJ per bit is a claim), and the data-local form on a 3D-stacked SRAM (a vertical hop at about 0.1 pJ per +bit, approximate, would cut the one-die row to about 0.2 nJ, still 2x the baseline and still no saving). + +## 12. The dataset comparison that decides class v7 (the third review, 17:5x BST) + +Two datasets, each with the adversary's burden (a chip with a host keeping it current) and the commodity burden +(what every honest node pays at the boundaries), priced on the record's figures: + +| | State-coupled dataset (class v5 and v6: derived from the chain's execution state at the era cut) | Epoch-defined bounded dataset with a published support horizon (derived from the certified checkpoint's hash at the era cut; the size schedule published years ahead) | +|---|---|---| +| Adversary: sync bandwidth | the day stream and the leaves: 16.5 KB/s to 10,000 members, 45 MB per member per window today (the record 2a.2); grows with the state | the seed: 32 bytes per era; the schedule: a constant | +| Adversary: update cost | the rebuild 0.7 J per machine per window (0.0001 percent of its energy); the host's execution of every block (85 W, USD 1,500 per 100 machines: 0.85 W and USD 15 per machine, under 1 percent) | the rebuild only (the same 0.7 J); a light client following checkpoints (bytes, watts of nothing) | +| Adversary: storage | the state (hundreds of MB today, unbounded) on the host; the dataset on the machine | the dataset only | +| Adversary: adversarial state growth | raises the HOST's cost (storage, re-execution), never the dataset's size (the atom folds the state into a dataset of the schedule's size); the growth is paid in gas by whoever causes it | none | +| Adversary: what is excluded | the stale machine (its dataset wrong the moment its host is) and the recompute chip; not a specialised machine with a host (the review's rule 3), which pays under 1 percent | the stale machine (a chip missing the epoch flip mines a dead object, as a stale card does); the recompute chip is excluded by the pebbling curve, not by the dataset; the seed is unknown before the checkpoint, so nothing precomputes | +| Commodity: the boundaries | today's eight crossing faults were all state boundaries: the crossing, the partition, the snapshot, the cold start (the 15:42Z deep-reorg reset, the pruning-point anchor, the snapshot resumed under the next object, the stale stream); every family epoch is a state-agreement event (layer 3, section 3) | one boundary kind: the checkpoint's hash, which every node holds by the chain's own rule; no stream, no snapshot, no re-execution on the mining path | +| Commodity: re-execution per node | about 10 minutes from genesis on Devnet 3, hours on the shared devnet, and the dataset is wrong until it is done | none for mining (execution continues for the EVM, decoupled from the hash) | +| Commodity: proving coexistence | unchanged by the coupling (set by the dataset's size and the prover's 8.6 GB) | the same | +| Commodity: the cold start and the partition | a node that missed the lead serves nothing for a window; a partition's two sides derive two datasets | a node derives the dataset from any header it accepts; a partition's two sides derive the same dataset while they share the checkpoint | + +The growth schedule 5.5 / 8.5 / 11.5 GiB, per step (the hash lane's VRAM rows: the dataset needs about 1.3x its size +in device memory with the working set; the tier room 75 percent of card memory, 50 percent of Apple unified; the +prover 8.6 GB beside it): + +| Step | Adversary burden | Commodity burden: who leaves mining | Who loses proving coexistence | Owners' replacement cost (approximate street prices, October 2026) | The 24 Gb GDDR7 case | +|---|---|---|---|---|---| +| 5.5 GiB at the v6 epoch | GDDR7 board: 0 (16 x 2 GB holds it); SRAM die: 3 reticles, USD 1,500 of ticket | the 6 GB and 8 GB tiers (25 percent by count): about 7.3 GiB of device memory needed | the 12 GB tier (22 percent): 7.3 + 8.6 over 12; it mines or proves | an 8 GB card to a 16 GB card: USD 350 to 450 (a 16 GB 5060 Ti or 9060 XT class) | none needed | +| 8.5 GiB two years on | GDDR7 board: 0 (the 32 GB board holds it); the SRAM die 5 reticles, USD 2,500 | the 10 and 11 GB tiers (9 percent) and the 16 GB unified Mac (about 8 GiB of room): about 11 GiB needed | the 16 GB tier (28 percent): 11 + 8.6 over 16; it mines or proves | a 10 or 12 GB card to a 16 GB card: USD 350 to 450; a 16 GB Mac has no upgrade | none needed | +| 11.5 GiB at four years | GDDR7 board: 0; the SRAM die 6 reticles, USD 3,000 | the 12 GB tier (22 percent): about 15 GiB needed | the 24 GB tier mines and proves (15 + 8.6 under 24) | a 12 GB card to a 16 GB card: USD 350 to 450 | none needed | +| The 24 Gb (3 GB) GDDR7 devices (Micron ended 2 GB production, 3 GB at USD 60 to 70 each, the TrendForce note) | a 16-device board at 48 GB for USD 1,000 of memory instead of 320: the adversary over-provisions ONCE for the whole horizon, USD 9.9 per MH/s instead of 4.84, still 1.6x the card per dollar and unchanged per joule | the 50-series cards on 3 GB devices (the 5090 32 GB, the 5080 Super class at 24 GB) carry the schedule to year 4 and beyond; the schedule retires the 8 and 12 GB tiers, not the chip | | | the schedule's one effect on the chip is a USD 700 memory ticket, paid once | + +Reading: the schedule is a commodity-side cost at every step (a quarter of the cards by count at 5.5 GiB, a further +third losing proving coexistence at 8.5, the 12 GB tier out at 11.5; USD 350 to 450 per displaced owner) and a chip-side +cost only on the SRAM die, and the 24 Gb device removes even the DRAM board's small ticket. The state coupling buys, +against the chip, the exclusion of a stale machine (which the epoch seed also buys) and a host at under 1 percent of +the machine's cost; it costs the honest side every state boundary the devnet has crossed this week. + +The recommendation, five lines: +1. Class v7 derives the dataset from the certified checkpoint's hash at the era cut (an epoch-defined bounded + dataset), with the size schedule published at genesis as the support horizon; the execution state stays in the + headers for the EVM and leaves the hash. +2. The dataset floor schedule stays (5.5 / 8.5 / 11.5 GiB, steps offset from the family flips), served as a ticket + on an SRAM die and as a retirement of the 8 GB tier at the first step and the 12 GB tier at the third, with the + replacement cost per owner stated; the 24 Gb device is priced in as the DRAM chip's one-time USD 700. +3. The family bank and its 180-day calendar stay, served as response capability with a zero obsolescence credit + per transition (section 8), never as energy or economic resistance. +4. The chip line served is the complete machine's: 1.8x per joule node-for-node and 2.1x a node ahead on the + GDDR7 board against the Blackwell tier at its lock, 3x against the cohort, 3.3x per dollar; the hold is the + project cost against miner revenue (the profitability surface, the economics lane). +5. The data-local threat is closed by the live state (26x the bits of the read; no saving to erase) and needs no + design change; the three terms that still need physical design before they are bounds (the HBM activate + ceiling, the SRAM die's wire, the on-package hop) are named in section 11 and owed. diff --git a/docs/build/build.md b/docs/build/build.md index 0a96b7fba..64f153607 100644 --- a/docs/build/build.md +++ b/docs/build/build.md @@ -16,11 +16,12 @@ This file is the source of [igneum.network/build](https://igneum.network/build). | | Devnet 3 | Testnet | Mainnet | |---|---|---|---| -| Chain id | 4464 (`0x1170`) since its class v5 floor on 8 October 2026; 4463 below it | 4462 (`0x116e`) | 4461 (`0x116d`) | -| Network id | `igneum-devnet-3` | `igneum-testnet-1` | not started | -| RPC | `https://rpc.devnet.igneum.network` (a node you run serves `http://127.0.0.1:26790`) | `https://rpc.testnet.igneum.network` (answers; nothing mines there yet, so a transaction waits) | none | +| Chain id | {{rm:network.chain_id}} (`{{rm:network.chain_id_hex}}`) since its class v5 floor on 8 October 2026; 4463 below it | 4462 (`0x116e`) | 4461 (`0x116d`) | +| Network id | `{{rm:network.id}}` | `igneum-testnet-1` | not started | +| RPC | `{{rm:network.rpc}}` (a node you run serves `http://127.0.0.1:26790`) | `https://rpc.testnet.igneum.network` (answers; nothing mines there yet, so a transaction waits) | none | | Coins | no value, resets without notice | no value, resets with notice | not started | | Symbol, decimals | IGN, 18 | IGN, 18 | IGN, 18 | +| Machine-readable | [/release.json](/release.json): the chain id, the source commits and fingerprints, the mining class, the finality rule, the proof program ids, the fee schedule and the current version per platform, with a generated date | | | Devnet 3 is where you build today. It is a developer network: it resets without notice and its coins have no value. Its public RPC takes the read methods, `eth_sendRawTransaction` and a wRPC websocket at `/ws`, at 20 requests a second per address. The public testnet exists, its RPC answers, and no blocks are being produced on it until it opens. Mainnet has no date. Devnet 3 answered 4463 until its class v5 floor at DAA 68,400 on 8 October 2026 and 4464 from it; read it with `eth_chainId` rather than fixing it, since a transaction signed for the wrong id is refused. diff --git a/docs/design/developer-adoption.md b/docs/design/developer-adoption.md index 0acd30303..1d5ebc41e 100644 --- a/docs/design/developer-adoption.md +++ b/docs/design/developer-adoption.md @@ -182,7 +182,7 @@ What a builder expects on day one, what Igneum has, and the order to build the r | Item | Expected | Igneum has | Lacks | Order | |---|---|---|---|---| -| EVM | Cancun, same bytecode | Cancun opcodes, precompiles 0x01 to 0x09, revm 43; chain ids 4461 / 4462 / 4463; viem 2.57 drove deploy, write, read and fee estimation through stock paths | EIP-7702, 0x0a, blobs (by design); the documented differences table of spec 7.1 must be in the developer docs | Docs: 1 | +| EVM | Cancun, same bytecode | Cancun opcodes, precompiles 0x01 to 0x09, revm 43; chain ids 4461 / 4462 / 4463 (historical: Devnet 3 answers chain id 4464 since its class v5 floor at DAA 68,400 on 8 October 2026, 4463 below it; the current id is in /release.json); viem 2.57 drove deploy, write, read and fee estimation through stock paths | EIP-7702, 0x0a, blobs (by design); the documented differences table of spec 7.1 must be in the developer docs | Docs: 1 | | RPC | Full `eth_*`, `debug_*`, `trace_*`, subscriptions | 25 `eth_*` methods, `igneum_getTransactionStatus`, `igneum_getSegment`, `igneum_getBudgets`, `igneum_estimateGas` (both dimensions); HTTP JSON-RPC 2.0 with batches, port 26790 | `eth_getProof`, `eth_subscribe`, `debug_traceTransaction`, `trace_block`, `eth_getUncle*`, `IgneumInfo` (design 10.3 item 7); `pending`, `safe`, `finalized` all resolve to the executed tip | 2 (debug and subscribe are what Blockscout and Foundry's debugger need) | | RPC providers | A public endpoint, then third parties | None public. The devnet is the team's three nodes and a seed | A public devnet RPC with a rate limit; chain-id registration on ethereum-lists/chains before the public testnet (design 8.1) | 3 | | Tooling templates | Hardhat and Foundry work | Designed: templates "ship with the devnet" with the three things to tell a developer (design 8.3) | The templates themselves; a `vm.warp` note (past timestamps rejected) | 1 | diff --git a/docs/design/execution-layer.md b/docs/design/execution-layer.md index f0466d162..3c5034cf9 100644 --- a/docs/design/execution-layer.md +++ b/docs/design/execution-layer.md @@ -461,7 +461,7 @@ Rule change, 4 October 2026 (findings F-exec-A and F-exec-B of the attack suite, | Miner address | Low 20 bytes of the header's `vote_key_hash` (`evm::miner_evm_address`) | The body has no `miner` field yet. A miner that wants to spend its rewards passes `--vote-key-hash 0x000000000000000000000000
` to `igneum-miner`. After the finality branch merges, `vote_key_hash` is the hash of a BLS key, so this rule must give way to the body's `miner` field (10.4) | | Units | 1 sompi = 1e10 wei; 1 IGN = 1e18 wei | Subsidies come from `igneum::block_subsidy` in 8-decimal sompi; the EVM is 18-decimal. The open "8 or 18 decimals" decision is unchanged; this is the fixed scaling at the bridge named there | | Rewards | 80% of every blue block's subsidy to its miner, 20% to the proving pool escrow `0x...0220`, both credited in the segment that merges the block; reds unpaid | Design 4.4, with the pool held in a keyless account until proof records exist | -| Simnet | Devnet block rate and depths (1 BPS, k 18, mergeset 180, merge depth 3,600) with proof of work skipped; chain id 4463 shared with the devnet | A CPU test network of the devnet DAG shape | +| Simnet | Devnet block rate and depths (1 BPS, k 18, mergeset 180, merge depth 3,600) with proof of work skipped; chain id 4463 shared with the devnet (historical: Devnet 3 answers chain id 4464 since its class v5 floor at DAA 68,400 on 8 October 2026, 4463 below it; the current id is in /release.json) | A CPU test network of the devnet DAG shape | | Mempool hold | A transaction stays in every template until a block carrying it is added to the DAG (any block, this node's or a peer's: the executor subscribes to consensus `BlockAdded`); then it is held for 30 s or until the executor removes it (executed) or offers it again (a chain block skipped it); a transaction skipped twice is dropped | Kaspa's own rule (`mining/src/manager.rs`, `handle_new_block_transactions`). Replaced the 4-second hand-out cooldown on 5 October 2026 (fork `tx-gossip`, `pool.rs IN_BLOCK_HOLD`, `service.rs listen_block_added`): the cooldown made a sender mineable 1 s in 5 and inclusion came in 50-s bursts (bench-log, 5 October 2026 afternoon); with the hold a transaction is offered to every template until a block has it | | Reorgs | Post-segment states for the last 64 chain blocks; deeper reorgs replay from genesis | Observed depth on the test network: 1 to 3 with Poisson-paced miners. A fixed per-template hold had made the three stub miners mine in lockstep rounds, and with equal work per block the GHOSTDAG hash tie-break then kept two equal-work chains alive from genesis (flips 48 deep every few seconds); `igneum-miner --hold-ms` is exponential now | | Block tags | `pending`, `safe` and `finalized` all resolve to the executed tip | The virtual's segment is not executed eagerly and no certified checkpoint exists on this branch; the RPC does not pretend otherwise | diff --git a/docs/design/phone-app.md b/docs/design/phone-app.md index 0a3ad7018..05306ace5 100644 --- a/docs/design/phone-app.md +++ b/docs/design/phone-app.md @@ -44,7 +44,7 @@ Full-header mode (spec 10.4 item 6, the lottery verified on the phone) is not in | Key storage | iOS Secure Enclave through the Keychain with device-only, biometric-gated access; Android Keystore with StrongBox when the device has it, else TEE-backed. The signing key for an EVM transaction is secp256k1, which the enclaves do not sign natively, so the private key is wrapped by an enclave key and unwrapped into memory only for the duration of one signature (approximate: the common pattern on both platforms) | Designed | | Seed | BIP-39, 24 words, generated on device; shown once, confirmed by re-entering words in random positions (spec 8.5 item 1's rule for the desktop app, applied here); optional second confirmation after 24 hours | Designed | | Derivation | BIP-44 path `m/44'/coin'/0'/0/n` with Igneum's SLIP-44 coin type; the coin type is unregistered (Open, P1 below) and the app uses Ethereum's 60 until it is, so a seed restored into any Ethereum wallet shows the same addresses | Designed, Open | -| Address | 20-byte EVM address, chain id 4461 / 4462 / 4463 (spec 7.4), EIP-155 signatures, transaction types 0, 1, 2 (design document, execution layer, 1.1) | Designed | +| Address | 20-byte EVM address, chain id 4461 / 4462 / 4463 (spec 7.4) (historical: Devnet 3 answers chain id 4464 since its class v5 floor at DAA 68,400 on 8 October 2026, 4463 below it; the current id is in /release.json), EIP-155 signatures, transaction types 0, 1, 2 (design document, execution layer, 1.1) | Designed | | Gas | One gas limit and one price, as the node quotes them with proving gas folded in (spec 7.1, "quoted gas price"); the app shows the quote and never lets a user set a limit below the estimate | Designed | | Status line | Every transaction shows executed, proven, locked as `igneum_getTransactionStatus` reports them, with the app's own verification state beside it: "locked" is shown only when the engine has verified the certificate that covers the block | Designed | | Backup | None by the project. The app offers no cloud backup of the seed and refuses the platform's automatic keychain sync for the wallet entries; the user writes the words down | Designed (spec 8.5 item 3) | diff --git a/docs/evidence.md b/docs/evidence.md index b962f79b2..40556bc8b 100644 --- a/docs/evidence.md +++ b/docs/evidence.md @@ -2,12 +2,13 @@ 4 October 2026. One row per claim the homepage (`site/index.html`) and the litepaper (`site/litepaper.html`) make. Every number here is copied from `docs/bench-log.md`, which names the machine, the date and the command, or from the result files it names; nothing is restated from memory. Where a bench-log figure is approximate, this table says so. -## The five labels +## The six labels | Label | Meaning | |---|---| | designed | A decision in the design document or the specification. No code carries it, or the code is a stub | | implemented | Code exists in this repository with test vectors, and the vectors pass. Not run as a measurement of the claim | +| activated | The code is live on a named chain by its activation height, and a node's own line says so. Not yet a measurement of the claim | | tested by the team | The claim was measured or exercised by the project's own people and agents on a named machine, and the result is in the bench log | | reproduced externally | Somebody outside the project ran the published command on their own hardware and got the published result | | reviewed independently | Somebody outside the project, paid or not, read the code or the rule and published their finding | @@ -18,8 +19,9 @@ Four rules for reading the table: 2. A status applies to the exact version in the row. An audit of one version never covers a newer one; when the version changes, the status falls back to "tested by the team" until the new version is reproduced or reviewed again. 3. "Tested by the team" on one machine is one machine. The rows say which. Discrete AMD, Intel and a 2019-class CPU core have not run anything. 4. The 12-node cloud network of 4 October 2026 (`infra/cloud-devnet`, cloud VMs in five locations) is the project's own. Rows that cite it are tested by the team, not reproduced externally. +5. The labels stay distinct and a claim never moves up a label without the artefact that label names (the table "What would move a row"). The public reference repository exists now (the specifications, the `igneum-pow` crate, the simulators and the test material, at git.igneum.network); the full node, the miner and the proving code open later, so a row that cites them is tested by the team until they do. -Versions in the table: `igneum-pow` is the Rust crate at `igneum-pow/Cargo.toml`, version 0.2.0 since 4 October 2026 (generator version 2; 0.1.0 rows are marked). "Repo" commits are this repository's. "Fork" commits are `vendor/igneum-node` and its worktrees (`-v4`, `-diff`, `-exec`, `-harness`, `-fin-fixes`), which are not in this repository's history; the row names the fork commit or branch as the bench log does. The first devnet is devnet v4 (genesis 10:05 BST, 4 October 2026, branch `devnet-v4`). Devnet 3 (`igneum-devnet-3`, chain id 4463, release 0.3.22) made its first block at 17:06 UTC on 7 October 2026 with every upgrade on from block zero (class v4 sub-version 3, the era VDF, difficulty v2, finality v3, proving v0 and v1, the ladder at rung 0, calibrated fees) and locked its first checkpoint at 19:02 UTC; rows that name the live devnet without a chain are the first devnet's, and Devnet 3 readings are marked. The spec is `docs/spec/` version 0.1. +Versions in the table: `igneum-pow` is the Rust crate at `igneum-pow/Cargo.toml`, version 0.2.0 since 4 October 2026 (generator version 2; 0.1.0 rows are marked). "Repo" commits are this repository's. "Fork" commits are `vendor/igneum-node` and its worktrees (`-v4`, `-diff`, `-exec`, `-harness`, `-fin-fixes`), which are not in this repository's history; the row names the fork commit or branch as the bench log does. The first devnet is devnet v4 (genesis 10:05 BST, 4 October 2026, branch `devnet-v4`). Devnet 3 (`igneum-devnet-3`, chain id 4463 from genesis and {{rm:network.chain_id}} since its class v5 floor at DAA 68,400; node {{rm:source.node.commit}} on {{rm:source.node.branch}}, igneum-pow {{rm:source.pow.commit}}, {{rm:read_at_short}}; the current state is the [release manifest](/release.json), filled at build time) made its first block at 17:06 UTC on 7 October 2026 with every upgrade on from block zero (class v4 sub-version 3, the era VDF, difficulty v2, finality v3, proving v0 and v1, the ladder at rung 0, calibrated fees) and locked its first checkpoint at 19:02 UTC; rows that name the live devnet without a chain are the first devnet's, and Devnet 3 readings are marked. The spec is `docs/spec/` version 0.1. ## The table @@ -38,10 +40,10 @@ Versions in the table: `igneum-pow` is the Rust crate at `igneum-pow/Cargo.toml` | 11 | Hashrate that arrived today has almost no vote: ten days of the whole network's hashrate to reach a third of the weight, twenty for two thirds; 51% never reaches two thirds while honest miners stay | Litepaper Finality; homepage firsts | tested by the team | repo `bbb264a`; `sim/finality_v2.py` | Scenario B of `sim/finality_v2.py`, seeds 7 and 11 | share(t) = (t/30) x a/(1+a) holds to 0.04 points; a renter equal to the whole honest network (a = 1) crosses 1/3 on day 20 and never reaches 2/3; a = 9 crosses 1/3 on day 11.1 and 2/3 on day 22.2. The ten-day figure is a = infinity, honest miners gone. 3 October 2026, Apple M5 Max. A model with 1,000 Pareto keys and no DAG; the live devnet's window is two hours old, so the claim has no live measurement yet | none yet | | 12 | The difficulty rule recovers from a hashrate step within minutes, where Kaspa's sampled rule never settles. A step inside an epoch set the rule oscillating on the live devnet on 4 October 2026; rule v2 removes it in the simulator and on a test network and is built but not yet rolled out | Spec 2.3; litepaper Speed (implied); bench page | tested by the team | repo `e9328c6`, `abb5a5d` (attacks), `67bf226` (rule v2); fork `difficulty` branch (timestamp fix) and `devnet-v4` `a21ff239` (`difficulty_v2_activation_daa`, `REF_WINDOW_V2 = 600`); `sim/difficulty/sim.py --live` | The live record `sim/difficulty/records/live-2026-10-04.csv` (8,090 headers, `pull_live.py`) and the hash-rate record beside it; `sim/difficulty/sim.py` on the synthetic set and the DAG replay; `sim/difficulty/attacks/attacks.py`; `sim/difficulty/testnet_v2.py` (3 nodes, activation at DAA 900); `cargo test --release -p kaspa-consensus --lib difficulty` (15 pass); bench-log "difficulty controller", "difficulty rule under attack", "timestamp attack fixed", "difficulty rule v2" | Live devnet v4, 4 October 2026 (UTC): a second RTX 5090 joining 7 minutes into an epoch (about 152 to 280 MH/s) hardened the difficulty 70M to 144M in 90 s and then swung by about a third for 40 minutes around the true level of 139M while the epoch-long reference lane carried the join; that card leaving for 4 minutes eased 116M to 67M and back to 106M; the epoch boundary with both PCs restarting took 152M to 77M in 3 minutes, after which the rule held within 1.3% per minute with no flips. Cause: the reference lane covered the whole epoch, so a mid-epoch step polluted it for the hour and the 25% trigger flipped on the short lane's noise. The DAG replay reproduces the record (std of log difficulty 0.115 against 0.134, 4.3 peaks against 4). Rule v2 (reference window 600 DAA) on the replay: std 0.026, 0 flips, mean 142.6M against 139M true; on a 3-node test network the v2 nodes eased a leave with no peak and held a rejoin within 3% after 60 s, and a node without the activation height forked off at it as designed. Rule v2 rolled onto the 12-node cloud network on 4 October (all nodes crossed the height on one chain; a hash-rate step then settled in 160 to 270 s with no swing) and activates on the devnet at DAA 33,000 the same evening. Timestamp forging (ledger M23) fixed the same day: a 50% forger drifts the rate under 1.1% where the 3 October rule gave it a 9.9x difficulty. Simulator, settled seconds: x50 step 62 to 66 (Kaspa 1,542), /50 step 657 to 753 (Kaspa 12,296). Apple M5 Max under load 7 to 442; the DAG model is fitted on one scale; the pool hopper's 0.7-point excess over Kaspa's rule stays open | none yet | | 13 | Every node executes the ordered transactions natively and reaches the same state root | Litepaper Proving ("Every node executes ... natively"), Building ("runs on Igneum unchanged") | tested by the team | repo `f5f8c80`, `8dae48b`; fork `devnet-v4` `dc749905`; revm 43.0.3 | `node tools/evm-smoke/smoke.mjs` against a 3-node `igneumd`; `igneum-exec-diff seq.json`; bench-log "execution layer devnet v3" and "devnet-v4 integration" | Simnet, 3 October 2026: 87 of 87 viem checks, state roots identical on 3 nodes at four heights, 57 executed and 19 skipped transactions agree with plain revm, 0 mismatches. Merged node on real proof of work, 4 October 2026: 84 of 85 checks (the miss needs parallel blocks the network did not produce in 36 s), 59 transfers in 10 chain blocks, state roots identical on 3 nodes, `igneum-exec-diff` 0 mismatches over 59 transactions; the live devnet v4 runs this execution layer. Apple M5 Max. The prover is a stub; state is rebuilt from genesis at start; no EVM transaction relay between nodes | none yet | -| 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 | +| 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 at that version (4464 since the class v5 floor, 8 October 2026); 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: at launch the strongest chip in the public model reaches 2.1x (a core as good as a GPU lane, k = 1) to 3.4x (a core three times better, k about 0.33) per joule against an RTX 5090 under class v4, live from genesis on the testnet and the mainnet; the ladder's second rung brings it to about 2.8x; class v5 makes the dataset the chain's state so a stateless or stale chip is wrong on every item; the hot-set cache is bounded at 1.067x at the ceiling and the weak-day FPGA at 12 percent on 15 days a century, both routed to the next class; datacentre silicon does not change the question; a stored-dataset chip pays for itself only at about USD 100 M of market cap in two years; without class v4 the same chip would reach 5x to 9x (the class v3 baseline, the devnet's starting state, never the launch state) | the home page's chip line, the litepaper's chip section (/litepaper#chip-model), the miner page's line | tested by the team (every card, the verifier, the two attack-pass bounds, the H100), the chip itself modelled, class v5 and the ladder designed, the X9 figure claimed against a CPU core 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/analysis/ca3-v4-uniform.md`; `docs/design/class-v5-stored-state.md`; the H100 and market-cap rows of 7 October; `docs/plans/cryptanalysis/in-house-pass.md` (the internal adversarial pass) | the chip model's arithmetic in its file; the card rows by the benchmark package; the attack-pass harnesses `tools/attack/f8-uniform` and the F4 census; the verifier by `igneum-pow bench` | 136 MH/s at 350 W (5090, bench) and 290 W (app); the class v4 efficiency passes (bench log "7 to 8 October 2026, the class v4 efficiency passes: the core clock lock on the RTX 5090 and the RTX 5080", measured): the 5090 at 136.84 MH/s and 475.5 W unlocked, 134.98 at 316.3 W at a 1,400 MHz core lock, the best points class v4 at 1,200 MHz (133.80 MH/s, 305.1 W, 0.439 MH/W) and class v3 at 1,300 MHz (134.62, 223.3 W, 0.603), the premium 145 W unlocked and 82 W at the best points, the knee 1,300 MHz; the RTX 5080 (8 October 2026, the dock card of the three-card Windows rig) at 71.41 MH/s and 253.1 W unlocked under class v4 against 71.28 at 169.7 W under class v3, the best points class v4 at 1,100 MHz (71.20 MH/s, 146.6 W, 0.486 MH/W) and class v3 at 1,000 MHz (71.11, 103.7 W, 0.686), the premium 83.4 W unlocked and 41 W at the best points, the knee between 1,000 and 900 MHz; per tier: a 5080 owner on class v4 locked near 1,100 MHz pays 147 W instead of 253 for 0.3 percent less rate, MH per watt up 72 percent, the lever Ember Tune's core-clock knob in 0.3.24; 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; 2.1x, 3.4x, 2.8x at launch; the shadow's premium on a 5090 81.8 W at its knee (class v4 at the 1,200 MHz lock 133.80 MH/s at 305.1 W; class v3 at 1,300 MHz 134.62 at 223.3 W; 7 October 2026); 1.067x at the ceiling; 12 percent on 15 days a century; 10.85 ms at rung 3; USD 100 M; 5.1x to 9.2x the class v3 baseline; 6 and 7 October 2026, the M5 Max, PC 2's RTX 5090, PC 1's RX 9070 XT and RTX 4070, a rented H100 SXM, igneum-build-1 The k about 0.33 bound is the implied core of Bitmain's Antminer X9 (RandomX; 1,000 KH/s, 2,472 W, 2.47 J per KH, USD 5,600; pre-orders 26 December 2025), withdrawn in mid-May 2026 with buyers refunded before any unit shipped, no independent benchmark, commodity Sophgo SG2044 server SoCs with an AES accelerator, no tapeout: a claimed, unmeasured figure carried as the pessimistic bound, not a calibration point (attack pass AP-F5-1, 7 October 2026). | none yet; the next test is the internal adversarial pass (three lanes new to the hash code, outsider inputs only, reports published whole), whose floor reading is in (measured, 8 October 2026; ledger AP-F8-1 and AP-F8-6): nine of nine hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test, and no outside review has run yet | +| 17 | The chip resistance claim, served as the class v6 close words it, the claim statement above the sentence: Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes. Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment. Beside it: class v4 is live from the first block on the testnet and the mainnet; class v5 makes the dataset the chain's state so a stateless or stale chip is wrong on every item; the hot-set cache is bounded at 1.067x at the ceiling and the weak-day FPGA at 12 percent on 15 days a century, both routed to the next class; datacentre silicon does not change the question; the three statements (energy resistance, economic resistance, response capability) are served separate, with the harness and the scoring rule linked | the home page's chip line, the litepaper's chip section (/litepaper#chip-model), the miner page's line | the GPU side tested by the team (the RTX 5080 and RTX 5090 clock-lock passes under class v4, every card, the verifier, the two attack-pass bounds, the H100); the chip core synthesised on ASAP7 and scaled to N3, claimed; the chip's memory modelled; the node column claimed scaling; the economic surface modelled, first cut, conditional; the rotation schedule measured per boundary; class v5 designed; the Antminer X5 an observed comparison, not a ceiling; the X9 a withdrawn pre-order, never benchmarked | `docs/design/class-v6-rotating-family.md` section 10 (10.0 to 10.0h, the close and its two accepted external reviews, 8 October 2026); `docs/design/class-v5-stored-state.md` sections 0, 13 and 14 and `docs/design/class-v5-harness/` (branch class-v5); `docs/design/class-rotation-four-layers.md`; `docs/analysis/chip-model-v3.md` 5 and 6; `docs/analysis/latency-shadow-2026-10-06.md`; `docs/analysis/attack-pass/f8-uniform.md`, `f4-weakday.md`, `docs/analysis/ca3-v4-uniform.md`; the H100 row of 7 October; `docs/plans/cryptanalysis/in-house-pass.md` (the internal adversarial pass) | the scoring rule in the close (the minimum over workloads of the maximum over free adversarial designs of the GPU's joules per hash over the adversary's, under the 10 percent GPU-cost budget at the lock, the verifier limit, cross-vendor correctness and hardware accessibility); the card rows by the benchmark package; the class v5 harness and the family harness; the attack-pass harnesses `tools/attack/f8-uniform` and the F4 census; the verifier by `igneum-pow bench` | 136 MH/s at 350 W (5090, bench) and 290 W (app); the class v4 efficiency passes (bench log "7 to 8 October 2026, the class v4 efficiency passes: the core clock lock on the RTX 5090 and the RTX 5080", measured): the 5090 at 136.84 MH/s and 475.5 W unlocked, 134.98 at 316.3 W at a 1,400 MHz core lock, the best points class v4 at 1,200 MHz (133.80 MH/s, 305.1 W, 0.439 MH/W) and class v3 at 1,300 MHz (134.62, 223.3 W, 0.603), the premium 145 W unlocked and 82 W at the best points, the knee 1,300 MHz; the RTX 5080 (8 October 2026, the dock card of the three-card Windows rig) at 71.41 MH/s and 253.1 W unlocked under class v4 against 71.28 at 169.7 W under class v3, the best points class v4 at 1,100 MHz (71.20 MH/s, 146.6 W, 0.486 MH/W) and class v3 at 1,000 MHz (71.11, 103.7 W, 0.686), the premium 83.4 W unlocked and 41 W at the best points, the knee between 1,000 and 900 MHz; per tier: a 5080 owner on class v4 locked near 1,100 MHz pays 147 W instead of 253 for 0.3 percent less rate, MH per watt up 72 percent, the lever Ember Tune's core-clock knob in 0.3.24; 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; the GPU side of the close: the RTX 5080 at its 1,100 MHz lock 2.06 microjoules per hash and the RTX 5090 at its 1,300 MHz lock 2.33 (class v4, 8 October 2026); the modelled bracket about 2.3x to 3.3x a node ahead and 2.0x to 2.9x node for node (approximate, provisional; the clock-gated base core k about 0.37 at N3, the gated window adding about 0.13; the first placed core 64 percent above synthesis), the placed gated row expected near 2.6x to 3.1x and 2.3x to 2.7x and served when it lands; the shadow's premium on a 5090 81.8 W at its knee (class v4 at the 1,200 MHz lock 133.80 MH/s at 305.1 W; class v3 at 1,300 MHz 134.62 at 223.3 W; 7 October 2026); 1.067x at the ceiling; 12 percent on 15 days a century; 10.85 ms at rung 3; 6 to 8 October 2026, the M5 Max, the desk rigs' RTX 5090, RTX 5080, RX 9070 XT and RTX 4070, rented pods, a rented H100 SXM, igneum-build-1 Bitmain's Antminer X9 (RandomX; 1,000 KH/s, 2,472 W, 2.47 J per KH, USD 5,600; pre-orders 26 December 2025) was withdrawn in mid-May 2026 with buyers refunded before any unit shipped, no independent benchmark, commodity Sophgo SG2044 server SoCs with an AES accelerator, no tapeout: it is a precedent on the served pages, not a chip core against the model (attack pass AP-F5-1, 7 October 2026; the close's 10.0f, 8 October 2026). Withdrawn from the served pages on 8 October 2026 and not restated: the 2.1x and 3.4x launch line, the 5x to 9x class v3 baseline, the ladder's 2.8x row, the USD 100 M pay-back row, any chip-arrival probability, the lifetime claim and the USD 300 M and 340 M lines. | none yet; the next test is the internal adversarial pass (three lanes new to the hash code, outsider inputs only, reports published whole), whose floor reading is in (measured, 8 October 2026; ledger AP-F8-1 and AP-F8-6): nine of nine hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test, and no outside review has run yet | | 18 | The chip resistance measurements: the program is latency-bound (dependent reads spread over the whole dataset), not bandwidth-bound, on every card we own, and sits beyond a card's on-chip cache; measured 8 October 2026: the distinct-index floor holds at 0.995 on every accepted program, about half of epochs carry one load site with a biased address bit at the era's stride rotation, priced at about 1.6 percent of a hash's reads to a chip storing half the dataset and nothing to one storing all of it (`docs/analysis/class-v6/family-gate.md`, lane D; adv-cache-2's `report-chained-cache-2.md` section 2.3 on its branch; ledger AP-F8-7) | 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 | @@ -103,6 +105,9 @@ Versions in the table: `igneum-pow` is the Rust crate at `igneum-pow/Cargo.toml` | Row | Before | After | Why | |---|---|---|---| | 17 | the 5090's efficiency pass | the RTX 5080's clock-lock pass beside it (71.41 MH/s at 253.1 W unlocked, 71.20 at 146.6 W at 1,100 MHz, the premium 83.4 W to 41 W) and the per-tier reading | the bench log's efficiency-passes entry | +| versions | chain id 4463, release 0.3.22 | the chain id at genesis and since the floor, the node, pow and app versions read from the release manifest at build time (/release.json) | an accepted external review: no status page hand-carries a number | +| labels | five labels | six: "activated" between implemented and tested by the team; the reference-repository wording corrected (specs, pow crate, simulators and test material public; node, miner and proving later) | the same review | +| 17 | the 2.1x to 3.4x launch line, the 5x to 9x baseline, the 2.8x rung, the USD 100 M pay-back row | the class v6 close's served sentence with the bracket (about 2.3x to 3.3x a node ahead, 2.0x to 2.9x node for node, approximate and provisional until the placed gated core row), the three statements separate, the harness and scoring-rule links, every number labelled | two accepted external reviews of the close (`docs/design/class-v6-rotating-family.md` 10.0f and 10.0g); the lifetime claim and the USD 300 M and 340 M lines withdrawn before they were served | ## What would move a row @@ -110,6 +115,7 @@ Versions in the table: `igneum-pow` is the Rust crate at `igneum-pow/Cargo.toml` |---|---|---| | designed | implemented | Code in this repository with test vectors that pass | | implemented | tested by the team | A bench-log entry with the machine, the date, the command and the number | -| tested by the team | reproduced externally | The repository public (at the public testnet), the command published, and a third party's run with the same result, linked from the row | +| implemented | activated | A node's own start line on a named chain naming the rule and its activation height | +| tested by the team | reproduced externally | The code the row names public in the reference repository (the specifications, the pow crate, the simulators and the test material are; the full node, the miner and the proving code open later), the command published, and a third party's run with the same result, linked from the row | | reproduced externally | reviewed independently | A named reviewer's published finding on that version. Funding for review is `docs/plans/funding.md` | | any | the row's status falls back | A new version of the code or rule the row names | diff --git a/docs/fork-divergence.md b/docs/fork-divergence.md index 76bc20c19..fabc2352f 100644 --- a/docs/fork-divergence.md +++ b/docs/fork-divergence.md @@ -115,7 +115,7 @@ Implements `docs/design/execution-layer.md` D1 to D10 and section 8.2 on a 3-nod | File (vendor/igneum-node-exec/) | What changed | Why | Risk | Upstream-merge note | |---|---|---|---|---| -| `consensus/core/src/evm.rs` (new), `consensus/core/src/lib.rs`, `consensus/core/Cargo.toml` (sha3) | `EvmTransaction = Vec` (raw EIP-2718 bytes), `evm_tx_hash` (keccak256), `evm_chain_id` (4461 / 4462 / 4463, simnet shares the devnet id), `miner_evm_address` (low 20 bytes of `vote_key_hash`), `BLOCK_EXECUTION_GAS_LIMIT` 30 M, `MAX_EVM_BODY_BYTES` 1 MiB, the `EvmTemplateSource` trait | Design D1, D8, 8.1; the devnet rule for the `miner` address until the body carries a 20-byte field | Low | Pure addition. | +| `consensus/core/src/evm.rs` (new), `consensus/core/src/lib.rs`, `consensus/core/Cargo.toml` (sha3) | `EvmTransaction = Vec` (raw EIP-2718 bytes), `evm_tx_hash` (keccak256), `evm_chain_id` (4461 / 4462 / 4463, simnet shares the devnet id) (historical: Devnet 3 answers chain id 4464 since its class v5 floor at DAA 68,400 on 8 October 2026, 4463 below it; the current id is in /release.json), `miner_evm_address` (low 20 bytes of `vote_key_hash`), `BLOCK_EXECUTION_GAS_LIMIT` 30 M, `MAX_EVM_BODY_BYTES` 1 MiB, the `EvmTemplateSource` trait | Design D1, D8, 8.1; the devnet rule for the `miner` address until the body carries a 20-byte field | Low | Pure addition. | | `consensus/core/src/block.rs` | `Block` and `MutableBlock` gain `evm_transactions` (`Arc>` / `Vec`); `Block::new` keeps its signature (empty EVM list), `with_evm_transactions`, `from_arcs_with_evm`; `MutableBlock::set_evm_transactions` recomputes the merkle root and re-finalizes the header | Design D1: EVM transactions in the body | Medium by spread: every `Block {..}` literal in the tree had to name the field (six sites) | Upstream additions of `Block` literals will fail to compile until the field is added; the compiler finds them. | | `consensus/core/src/merkle.rs` | `calc_block_hash_merkle_root(utxo_txs, evm_txs)`: leaves are Kaspa's transaction hashes followed by keccak256 of each raw EVM transaction | Design D7: `hash_merkle_root` is reused as the body commitment and now covers the EVM transactions. With no EVM transactions the root equals Kaspa's, so no genesis hash moved | Low | Pure addition; `calc_hash_merkle_root` is untouched. | | `consensus/src/model/stores/block_transactions.rs` | Stored body is `BlockBody(utxo_txs, evm_txs)`; `get_evm`, `insert_batch` and `insert` take both | One store, one write per body | Low | Database format changed: a node from before this branch must resync. `insert` has one more argument; upstream call sites conflict trivially. | diff --git a/docs/fud-ledger.md b/docs/fud-ledger.md index 32d32c148..aa5b2b13e 100644 --- a/docs/fud-ledger.md +++ b/docs/fud-ledger.md @@ -2335,6 +2335,8 @@ Evidence: `docs/design/latency-ladder.md` (the k column, the rung table at k = 0 Status: Fixed, stated; restated (7 October 2026, evening, by order of the coordinator; the chip-text rewrite e57da45a, on master at 25f38035): the served texts give the floor and the premium at the 5090's measured knee: 2.1x per joule with a core as good as a GPU lane (k = 1), 3.4x with one three times better (k about 0.33), no core below about 1.8 pJ per op in the model's range, the premium 81.8 W at the best points, Ember Tune named as how a user gets there; the ledger pin for X35 moved to the new sentence; `site/litepaper.html#chip-model` and the home line. +Status: Fixed, stated; restated (8 October 2026, afternoon, by order of main after two accepted external reviews of the class v6 close; `docs/design/class-v6-rotating-family.md` 10.0f to 10.0h): the served chip text is the third review's claim statement ("Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes.") above the review's sentence, both verbatim on the home line, the litepaper's abstract, chip section and limits item, and the miner page, with rotation named an optional improvement and no threshold as the economic headline (the coexistence model owed): "Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment." Every number carries its label (the bracket about 2.3x to 3.3x a node ahead and 2.0x to 2.9x node for node, modelled, approximate and provisional, served on main's "serve the bracket now" order of 16:2x UK until the k lane's placed gated core row lands; the GPU side measured on the RTX 5080 and RTX 5090 lock rows of 8 October 2026 and the card's measured cost of the window (a rented 5090 and 4090 at stock, within 5 percent per load); the chip core synthesised on ASAP7 and scaled to N3, claimed, its memory modelled; the node column claimed scaling). The three statements (energy resistance, economic resistance, response capability) are served separate; the harness and the scoring rule are linked beside the sentence. Struck from every served page: the 2.1x and 3.4x launch line, the 5x to 9x baseline, the ladder's 2.8x row, the USD 100 M pay-back row and the k about 0.33 column; never served and not to be: the lifetime claim, the USD 300 M and 340 M lines, any chip-arrival probability, the 725d2945 sentence. The pins for X35 moved to the new sentence (`tools/ci/ledger-text-check.mjs`). Was: the 2.1x to 3.4x range at the 5090's knee, below. + ### 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." @@ -2355,6 +2357,8 @@ Evidence: `site/index.html`; `site/litepaper.html`; `tools/ci/ledger-text-check. Status: Fixed, stated; restated further (7 October 2026, evening, from the counter-asic-4 research file d7721ebe; on master at 25f38035): the X9's claimed ratio is against a CPU core, not a GPU lane, so the texts no longer use it as a pessimistic chip core; every served sentence says so; the pin for X36 moved. +Status: Fixed, stated; restated (8 October 2026, afternoon, with X35): the X9 appears on the served pages only as a precedent (the pre-order, the withdrawal, no benchmark) and no served sentence uses its claimed core as a chip core against the model; the Antminer X5 is served as an observed comparison, not a ceiling (the close's 10.0f); the pin for X36 moved to that phrase. Was: the k about 0.33 column carried as the X9's claimed core, below. + ### X37. The class v4 energy premium is a cost the user pays, not a line in a model "Your chip model counts joules per hash for the attacker. What does class v4 cost the miner at the wall, and can any hash-side change bring that premium to zero?" diff --git a/docs/ledger-public.md b/docs/ledger-public.md index 9e7f46bc9..31eccf5e5 100644 --- a/docs/ledger-public.md +++ b/docs/ledger-public.md @@ -2,7 +2,7 @@ Generated by `tools/ledger/export-public.mjs` from `docs/fud-ledger.md`; a gate check fails when the two drift. One row per item: the claim or criticism, its status, what was done, and the evidence. Internal identifiers, times of day and team-member names are left out on purpose; the full ledger is published with the repository. -194 items. By status: Conceded, stated 52; Fixed 31; Decided 22; Fixed on a branch, pending merge 14; Answered by design 9; Answered with evidence 6; Fixed, stated 4; Closed by rule 3; Open 3; Spec fixed 2; Answered by design, with a correction to our own text 1; Answered with evidence, stated 1; Answered by design for finality, Conceded for the lottery 1; Conceded, implemented, stated 1; Rule implemented and measured; launch month simulated 1; Answered by design, with the concession stated 1; Conceded, stated in the litepaper and the design doc 1; Answered with evidence at 1 block/s 1; Conceded, stated in the simulation report 1; Answered by design, with the dependency conceded. Update 7… 1; Conceded, stated in the litepaper, with the dial explained 1; Closed by spec 1; Conceded by decision, stated in the design doc 1; Answered by design, with the founder's edge conceded 1; Answered by design, with a metrics caveat 1; Closed by removal, 3 October 2026 1; Conceded, stated in the litepaper 1; Conceded, stated in the design doc 1; Measured on the live node line, and the overlay does NOT… 1; Conceded, stated in the simulation 1; Conceded in part, labelled, stated 1; Fixed in the node 1; Answered with evidence for the largest body the rules allow 1; Fixed in the proving code 1; Fixed in the spec 1; Rule fixed 1; Rule written 1; Fixed, logged 1; Answered with evidence for the test half 1; Fixed in the node and shipped, rule not yet activated on… 1; Simulation half run 1; Answered with evidence for all four 1; Written 1; Designed 1; Fixed and confirmed 1; Rolled out 1; Conceded by decision 1; Conceded, scheduled, stated 1; Conceded, contained by rule, stated 1; Fixed on a branch and verified locally 1; Answered with evidence and stated 1; Answered with evidence for PC 2 1; Answered by design and with evidence 1; Fixed, stated; restated 1; Fixed, stated; restated further 1; Fixed in part, finding bounded, stated 1; Open, priced 1; Fixed as a genesis lever, measurement owed 1. +194 items. By status: Conceded, stated 52; Fixed 31; Decided 22; Fixed on a branch, pending merge 14; Answered by design 9; Answered with evidence 6; Fixed, stated 4; Closed by rule 3; Open 3; Spec fixed 2; Fixed, stated; restated 2; Answered by design, with a correction to our own text 1; Answered with evidence, stated 1; Answered by design for finality, Conceded for the lottery 1; Conceded, implemented, stated 1; Rule implemented and measured; launch month simulated 1; Answered by design, with the concession stated 1; Conceded, stated in the litepaper and the design doc 1; Answered with evidence at 1 block/s 1; Conceded, stated in the simulation report 1; Answered by design, with the dependency conceded. Update 7… 1; Conceded, stated in the litepaper, with the dial explained 1; Closed by spec 1; Conceded by decision, stated in the design doc 1; Answered by design, with the founder's edge conceded 1; Answered by design, with a metrics caveat 1; Closed by removal, 3 October 2026 1; Conceded, stated in the litepaper 1; Conceded, stated in the design doc 1; Measured on the live node line, and the overlay does NOT… 1; Conceded, stated in the simulation 1; Conceded in part, labelled, stated 1; Fixed in the node 1; Answered with evidence for the largest body the rules allow 1; Fixed in the proving code 1; Fixed in the spec 1; Rule fixed 1; Rule written 1; Fixed, logged 1; Answered with evidence for the test half 1; Fixed in the node and shipped, rule not yet activated on… 1; Simulation half run 1; Answered with evidence for all four 1; Written 1; Designed 1; Fixed and confirmed 1; Rolled out 1; Conceded by decision 1; Conceded, scheduled, stated 1; Conceded, contained by rule, stated 1; Fixed on a branch and verified locally 1; Answered with evidence and stated 1; Answered with evidence for PC 2 1; Answered by design and with evidence 1; Fixed in part, finding bounded, stated 1; Open, priced 1; Fixed as a genesis lever, measurement owed 1. | Id | Claim or criticism | Status | What was done | Evidence | |---|---|---|---|---| @@ -186,8 +186,8 @@ Generated by `tools/ledger/export-public.mjs` from `docs/fud-ledger.md`; a gate | X32 | The roadmap carried calendar months beside a testnet that is weeks away | Fixed, stated | Every calendar month is out of the roadmap. | [site/litepaper.html](../site/litepaper.html) | | X33 | The public benchmark dated "January 2027" | Fixed, stated | Both sentences read "The public benchmark with a leaderboard ships with the public testnet." (`site/litepaper.html`, For miners and Questions miners ask). | [site/litepaper.html](../site/litepaper.html) | | X34 | RandomX described as chip-free | Fixed, stated | Four sentences corrected, each with the X9 as the stated fact and its date; every sentence that only names the technique stands. | [site/index.html](../site/index.html) | -| X35 | The class v4 chip headline stated as one number, 2.1x | Fixed, stated; restated | The served texts give the floor and the premium at the 5090's measured knee: 2.1x per joule with a core as good as a the team (k = 1), 3.4x with one three times better (k about 0.33), no core below about 1.8 pJ per op… | [docs/design/latency-ladder.md](../docs/design/latency-ladder.md) | -| X36 | The X9 described as a shipping chip | Fixed, stated; restated further | The X9's claimed ratio is against a CPU core, not a the team, so the texts no longer use it as a pessimistic chip core; every served sentence says so; the pin for X36 moved. | [site/index.html](../site/index.html) | +| X35 | The class v4 chip headline stated as one number, 2.1x | Fixed, stated; restated | The served chip text is the third review's claim statement ("Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its… | [docs/design/latency-ladder.md](../docs/design/latency-ladder.md) | +| X36 | The X9 described as a shipping chip | Fixed, stated; restated | The X9 appears on the served pages only as a precedent (the pre-order, the withdrawal, no benchmark) and no served sentence uses its claimed core as a chip core against the model; the Antminer X5 is served as an… | [site/index.html](../site/index.html) | | X37 | The class v4 energy premium is a cost the user pays, not a line in a model | Answered with evidence | Measured on the RTX 5090, 145 W of premium unlocked and 82 W at the knee; the RTX 5080 at stock 84 W, its grid running; the team identity says the premium needed for 2x at k = 1 is 103 W at the lock and a premium of… | [docs/plans/counter-asic-3-status.md](../docs/plans/counter-asic-3-status.md) | | N1 | A 0.3.15 node on the live file wrote blocks every 0.3.14 node rejected | Fixed | The class v4 signal (PROPOSED, `docs/plans/counter-asic-3-node.md` section 6) is the producer's object version in the high byte of the header version; the first 0.3.15 build stamped it from the binary alone, so on the… | [infra/fast-time/node-compat.mjs](../infra/fast-time/node-compat.mjs) | | N2 | Any peer could crash any pruned node with a sync request below its retention | Fixed | `SyncManager::antipast_hashes_between` (the IBD headers path, `RequestHeaders`) unwrapped the GHOSTDAG reads of the requested low block and of every chain block of the walk; a pruned node holds no GHOSTDAG data below… | unit test `a_sync_request_below_retention_is_an_error_not_a_panic` (a chain of six headers, the genesis's GHOSTDAG… | diff --git a/docs/plans/explorer.md b/docs/plans/explorer.md index 53fd65530..e4a650aa8 100644 --- a/docs/plans/explorer.md +++ b/docs/plans/explorer.md @@ -28,7 +28,7 @@ Blockscout indexes through standard JSON-RPC. Its documented requirements (docs. Cost of one instance on Hetzner (the price list the seeds are on, `docs/plans/seed-nodes.md`: cx23 2 vCPU 4 GB at USD 6.49 net a month; larger types not priced here): Blockscout's own AWS example is 4 vCPU 16 GB plus a 2 vCPU 8 GB database. The matching Hetzner shape is one box in the 8 GB to 16 GB class plus Postgres on the same box for a devnet, a second box for the database when the chain carries real traffic. Price it from the Hetzner API when the box is ordered; the figure here is approximate: USD 15 to 40 a month for the single box, under USD 80 for two. Plus an Igneum node on the same box or next to it (Blockscout wants a local, unlimited RPC; the public `rpc.testnet.igneum.network` is rate limited to 20 req/s, `docs/plans/testnet-go.md`). -What it costs in work, in hours not weeks: the two missing `eth_` methods (small, same shape as their by-number siblings); a decision on tracing (the `debug_` namespace with revm inspectors, design 8.2, is the larger piece and is not needed to run Blockscout without internal transactions); Blockscout's env file and a Docker compose on the box; the chain's entry in its config (chain id 4463 devnet, 4462 testnet, 4461 mainnet, design 8.1); contract verification through Sourcify or Blockscout's own verifier microservice. +What it costs in work, in hours not weeks: the two missing `eth_` methods (small, same shape as their by-number siblings); a decision on tracing (the `debug_` namespace with revm inspectors, design 8.2, is the larger piece and is not needed to run Blockscout without internal transactions); Blockscout's env file and a Docker compose on the box; the chain's entry in its config (chain id 4463 devnet, 4462 testnet, 4461 mainnet (historical: Devnet 3 answers chain id 4464 since its class v5 floor at DAA 68,400 on 8 October 2026, 4463 below it; the current id is in /release.json), design 8.1); contract verification through Sourcify or Blockscout's own verifier microservice. ## 3. What Igneum needs that must be ours diff --git a/docs/plans/paid-pilot.md b/docs/plans/paid-pilot.md new file mode 100644 index 000000000..599aa83e4 --- /dev/null +++ b/docs/plans/paid-pilot.md @@ -0,0 +1,88 @@ +# The paid pilot: one external customer's exact workload, with repeat paid jobs + +Pin: Igneum 2.0, "Architecture and product", the proving business ladder, step two. Written 8 October 2026, 16:5x BST, from the code and the landed measurements; nothing here assumes demand. The external proving market is unbuilt and stays out of every revenue assumption until a customer has paid for repeat jobs. Prices quoted from public sources carry their URL; where a market publishes no price the cell says "no public price". Chip percentages are not published. + +## 1. The customer profile that fits the fleet's demonstrated edge + +What the pipeline proves today, from the code: + +- One program only. The host embeds two guests and refuses to run with any other: the shard program (program id 0x2b1a81cb..., 2,832,504 bytes) and the aggregator (0x474678f3...), both pinned in `proving/igneum-prove/elf/manifest.json` (SP1 crate 6.8.1, circuit v6.1.0) and checked at every start (`proving/igneum-prove/host/src/pinned.rs`, `include_bytes!` of the committed ELFs and verifying keys). The shard program is the Igneum chain's own EVM block transition: a range of transactions over a state witness, with rewards, the proving-pool credit and payouts applied by shard 0 (`proving/igneum-prove/core/src/shard.rs`, `ShardInput`, `shard_statement`). There is no path for an outside program. +- Inputs are a block fixture cut from a node's `igneum_exportSegments` dump by `igneum-prove-export` (`proving/igneum-prove/export/src/main.rs`); the plan cuts shards at the consensus proving budget `S_p`. +- Proof stages: execute, core, compressed; the aggregator folds shard proofs by recursion into one block proof and chains it to the previous segment's (`proving/igneum-prove/core/src/agg.rs`; `--mode chain`, `aggregate`, `verify-segment` in the host). The on-chain wrap (Groth16 or Plonk over bn254) is a trait method that returns an error and is not run (`proving/igneum-prove/host/src/proof_system.rs`). +- Verification: SP1's light verifier with the pinned verifying key (`--mode verify`); the node re-executes every carried record natively and drops a record whose result differs (litepaper, "How a block gets proven"). +- The job loop is the chain's own: every 10 s the app asks its node for shards assigned to its vote keys (`igneum_getAssignedShards`), exports, cuts, proves `--mode compressed`, signs and submits (`igneum_submitProofRecord`) (`app/igneum-app/src/prover.rs`). No job enters from outside. +- Hardware, measured: NVIDIA only (SP1's CUDA prover is Linux x86_64; Windows runs it in WSL2). The fixed 4,717,439-cycle shard (`proving/fixtures/fees-v1-shards2.json`, shard 0) proves compressed on the patched server at threshold 2^26 in 13.2 s on an RTX 3060 12 GB (7,525 MiB peak) and 8.2 s on an RTX 4060 8 GB (7,532 MiB), 6.3 s on an RTX 4090 and a 5090 (8.0 GB) (`docs/analysis/prover-tiers-real-cards.md`, 6 October; the 8 and 12 GB rows re-measured 8 October, v6-coexist). At the 5.5 GiB dataset floor an 8 GB or 12 GB card cannot hold the miner and the prover at once (13.6 GB together) and time-shares them; 24 GB and 32 GB cards hold both. +- Proof delivery on the devnet today: shards assigned by sortition to eight provers for a 10 s exclusive window, then open to anyone; no bond, no deadline beyond the record window of 600 chain blocks (`docs/spec/07-execution.md` 7.2, 7.7). + +The profile that fits that edge, stated as constraints rather than a market claim: + +1. The workload is an SP1 program (the one well-tested backend; a second backend only where justified, never interchangeable). Programs for other zkVMs are out of the pilot. +2. The job is sized in the fleet's proven range: shards of a few million cycles each, proved compressed in seconds to tens of seconds on one consumer card, and aggregated by recursion. A job that needs one proof of hundreds of millions of cycles on one card inside a wall-clock bound of seconds does not fit a consumer fleet. +3. Delivery is minutes, not seconds. A customer whose product needs a proof under 10 s of a large block (Ethereum real-time proving) needs a cluster; the fleet's edge is many independent cards on domestic power, so the fit is throughput with latency in minutes. +4. The customer verifies the proof on its own chain with its own verifier, under a program id it pins. Igneum delivers a compressed proof (or the customer's own aggregation of ours); the final wrap for an EVM verifier is either run by the customer's existing pipeline or is the first item the pilot builds (section 4). +5. The customer pays on its own chain in its own currency (the launch rule of `docs/spec/05-fees-and-economics.md` 5.4; route 4 of `docs/commercial/prover-customer-brief.md`). Settlement in IGN waits for the proof bridge. +6. Repeat is intrinsic: the customer has a steady stream of the same program with new inputs (blocks, batches, light-client updates), so "repeat paid jobs" is the normal shape of their demand, not a favour. + +## 2. Three candidate customer classes, ranked + +The founder's word on who is "no idea who". These are classes with one named example each, chosen for fit to the constraints above, not for known interest. Every example is from public sources as of 8 October 2026 and has not been contacted. Nothing here claims demand. + +| Rank | Class | Named example | Why they would pay | What they pay today | +|---|---|---|---|---| +| 1 | OP Stack rollups proving with OP Succinct (SP1 range proofs of their own blocks, aggregated and wrapped for L1) | Celo mainnet (OP Succinct Lite on SP1 Hypercube since 26 May 2026, per the Celo forum: https://forum.celo.org/t/op-succinct-sp1-hypercube-upgrade-live-on-celo-mainnet/13349); Mantle is the other named production user (https://blog.succinct.xyz/succinct-2025-recap/) | Their workload is the closest thing to ours that exists: SP1, EVM block execution, shard-sized range proofs, compressed then aggregated, with latency in minutes. A second supplier is a liveness and price story for a chain that depends on one prover network. | No fixed public price. Succinct's network sells by reverse auction in PROVE per PGU plus a dynamic base fee, no published rate (https://docs.succinct.xyz/docs/protocol/spn/auction). Succinct's own figure for OP Succinct: average proving cost 0.5 to 1 cent per transaction (https://blog.succinct.xyz/op-succinct/). A community estimate used for budgeting is USD 1.50 per billion PGU (https://hackmd.io/@damian666/rkqyehOOge); treat as an assumption, not a rate. | +| 2 | SP1 light-client bridges (sync-committee and storage proofs on a fixed program, one job per update, on a timetable) | Gnosis OmniBridge on SP1 Helios (Succinct reports more than USD 40 million TVL and USD 1.5 billion of stablecoin flow verified by its consensus proofs: https://blog.succinct.xyz/succinct-2025-recap/); IBC Eureka connects 120 Cosmos chains the same way | A fixed program, small inputs, a clock (every sync period or every update), tolerance for delivery in minutes: the exact "repeat paid jobs" shape, and a customer that cares more about a proof arriving every period from independent operators than about raw speed. | No public price per update. Paid through the Succinct network's auction (above); no per-proof rate is published. | +| 3 | Ethereum L1 block proving for the Ethereum Foundation's zkEVM programme (optional execution proofs today, mandatory later) | The ethproofs.org provers: ZisK on 8 x RTX 5090 and Axiom OpenVM 2.1 on 16 x 5090 (https://ethproofs.org/) | The programme is the largest standing demand for SP1-class proofs and it is public and measured. The buyer class (staking operators, client teams, the Foundation) would pay for proofs from independent operators once proofs are mandatory. | Cost, not price: USD 0.0057 (ZisK, 8 x 5090) and USD 0.0068 (Axiom, 16 x 5090) per block on ethproofs.org; no one pays per proof today (provers are funded, not paid per block). Ranked third because the real-time target (10 s per block on a rig under USD 100,000) is a cluster workload, not a consumer-card one; the fleet fits only the non-real-time tier. | + +Taiko, the first proving customer named in `CLAUDE.md` (a based rollup whose multi-proof design accepts SP1 proofs, per `docs/commercial/prover-customer-brief.md`, approximate), belongs to class 1 and stays a candidate inside it; Celo is the named example because its OP Succinct deployment is the exact SP1 range-program shape the pilot pins, on the public record. + +Not ranked, noted for the record: Kaspa's EVM layers (Igra, Kasplex) share the node lineage and a miner community (`docs/commercial/prover-customer-brief.md`), but neither publishes an SP1 workload today, so there is no exact workload to pin. + +## 3. The pilot shape + +One workload, one program id, one price, one clock. Everything below is the proposal the outreach brief carries; the numbers are ours to change before signature and are not a market claim. + +| Item | The pilot | +|---|---| +| Workload | The customer's SP1 range program as deployed (rank 1: the OP Succinct range program; rank 2: the SP1 Helios update program). One program, one version, for the whole pilot. | +| Program identity | The customer's verifying key hash (the SP1 `vk` hash their on-chain verifier pins), recorded in the job and checked by the prover before any work (the same rule as `pinned.rs`: setup must derive the pinned id or the job is refused). A version change is a new pilot. | +| Inputs | The customer supplies the SP1 stdin blob per job (for a range proof: the L1 head, the L2 block range and the witness their own tooling produces); Igneum does not reconstruct inputs for a foreign chain. Inputs are content-addressed (sha256 in the job) so a re-run is reproducible. | +| Output | A compressed SP1 proof of that program over those inputs, plus the public values, returned to the address and endpoint the customer names. The customer's own pipeline aggregates and wraps for L1 as it does today; a wrap by Igneum is a phase-two item (section 4). | +| Verification rule | The customer verifies every proof with SP1's verifier against the pinned vk before it is counted; a proof that fails verification is not a delivered job and is not paid. Igneum keeps the same check on its side before sending (`--mode verify` generalised to the customer's vk). | +| Delivery time | 30 minutes from job receipt to proof returned, measured on the customer's clock. Reasoning: a range of OP Stack blocks is a few shards of our measured size (seconds each on one card) plus queueing across independent operators; minutes is the honest unit for a fleet, and 30 minutes leaves room for a reassignment after one failed card. | +| Price per job | Cost-based, quoted per billion cycles of the program's execution, with a floor per job. From the measured rows: a 4060 proves 4.7 M cycles in 8.2 s at 115 W, so one billion cycles is about 29 minutes of card time, about 0.06 kWh (USD 0.01 at USD 0.15 per kWh) plus about USD 0.005 of card amortisation (USD 300 over three years); a 5090 does the same in about 22 minutes at 330 W (USD 0.018 of power, USD 0.035 of amortisation). Pilot quote: USD 0.25 per billion cycles, minimum USD 2 per job, so the operator's margin is several times its cost on every card tier and the quote sits well under the USD 1.50 per billion PGU budgeting figure the SP1 community uses. Priced in dollars, paid on the customer's chain (route 4), never a fixed number after the pilot: the launch rule prices a job at or above the subsidy the card forgoes, which moves with network hash. | +| Repeat cadence | One job per hour for rank 1 (a range proof an hour is a small slice of a chain's stream and leaves their existing supplier in place); one job per update for rank 2 (about one per sync period). | +| Pass condition | 500 paid jobs over 4 weeks, at least 99 percent delivered inside 30 minutes and every one verified by the customer, paid at the quoted rate with no job disputed. Reasoning: four weeks crosses more than 600 hourly program epochs and the operators' own churn, so a pass is not one good week; 500 jobs resolve the on-time rate to a fifth of a percent and are enough for the per-card cost table to be read back against real power bills; "paid" means money moved on the customer's chain for every counted job, so a subsidised or waived job does not count. Fewer than 500 paid jobs, or any week under 99 percent, is a fail, published either way. | + +## 4. What the pipeline is missing to serve it + +Checklist from the code, each item with the file or crate it touches. Nothing below is built; the first three are the gate for accepting a single job. + +- [ ] External program identity. The host accepts only the embedded guests (`proving/igneum-prove/host/src/pinned.rs`; `proving/igneum-prove/elf/manifest.json`). Needed: a permitted-programs registry (program id, vk hash, SP1 circuit version) that the host loads for a job, with the same "setup must derive the pinned id" refusal; the protocol pins the list (Igneum 2.0 pin: program identities and verifier versions pinned in the protocol). +- [ ] Generic inputs. The fixture path is Igneum's block fixture (`proving/igneum-prove/export/src/main.rs`, `proving/igneum-prove/core/src/fixture.rs`). Needed: a job input blob (SP1 stdin bytes, content-addressed) fed to `prove_shard` in `proving/igneum-prove/host/src/proof_system.rs` without the shard statement wrapper. +- [ ] Verification against the customer's vk. `--mode verify` uses the pinned key (`host/src/main.rs`). Needed: verify with the job's vk before sending. +- [ ] Job intake. The only job source is the chain's shard assignment (`igneum_getAssignedShards`, `igneum_exportSegments`, `igneum_submitProofRecord`, consumed by `app/igneum-app/src/prover.rs`). Needed: a job object (program id, input hash, deadline, price, payout address, customer endpoint), an intake endpoint in the node's proof pool (the node repository, `igneum-node`), and a second branch in the app's prover loop that takes a customer job when no chain shard is assigned (spec 7.2's sortition stays untouched: external jobs never pre-empt the chain's own proofs). +- [ ] Aggregation and wrap. The aggregator guest is Igneum's segment statement (`proving/igneum-prove/core/src/agg.rs`, `aggregator/src/main.rs`); `wrap` is unimplemented (`proof_system.rs`). For the pilot the customer aggregates and wraps; phase two is a generic aggregation program and the bn254 wrap, so Igneum can deliver an on-chain-verifiable proof. +- [ ] Payment. Route 4 (customer chain, payout contract keyed by miner address) is "Designed" with no code (`docs/spec/05-fees-and-economics.md` 5.4; `docs/commercial/prover-customer-brief.md` route 4); `pool/src/payout.rs` pays IGN inside Igneum's pool only. Needed: the payout contract on the customer's chain, the job-to-payout record, and a receipt the app shows; settlement in IGN waits for the proof bridge (spec 7.3) and is out of the pilot. +- [ ] SLA. The chain has a 10 s exclusive window and open claiming with no bond and no job deadline (`docs/spec/07-execution.md` 7.2, items 3 and 4); the brief's bond and timeout are open (O-5.6). Needed for a customer: a deadline on the job, a reassignment rule when the first operator misses it, a retry budget, and a delivered-on-time log that produces the pass condition's numbers (the app's `/api/state` tile and the node's `igneum_getProvingStatus` are where the counters live today). +- [ ] Memory profile shipped. The patched `sp1-gpu-server` that fits 8 and 12 GB cards (threshold 2^26) is a served artefact, not in the shipped app (litepaper, "Proving"); the served sm_89 tarball still carries the stock server in `home/.sp1/bin` (found 8 October, with the floor lane). Needed: the patched server in the app payload for every tier, and the time-sharing rule for 8 and 12 GB cards (mine or prove, never both at the dataset floor). +- [ ] Reporting. A per-job record (program id, input hash, cycles, card, seconds, verified, paid) kept by the operator and summarised for the customer; today's RESULT lines go to a log only (`host/src/main.rs`). + +## 5. Outreach brief (one page, served text rules: no founder name, UK English) + +**Igneum proving pilot** + +A GPU-secured network for Ethereum-compatible applications and verifiable computation. + +Igneum is a proof-of-work network mined on consumer graphics cards, where the NVIDIA cards that secure the chain also prove its blocks with SP1 and can prove yours. We are looking for one customer with one exact workload for a paid pilot. + +What we have measured. The chain's own block shards (about 4.7 million cycles each) prove compressed in 8 to 13 seconds on 8 GB and 12 GB cards and in 6 seconds on 24 GB and 32 GB cards, on rented hardware from eleven card models, with every proof verified. Shard proofs are aggregated by recursion into one proof per block. Proving runs on NVIDIA cards; AMD and Apple cards mine. Proven execution is not finality, EVM compatibility is not Ethereum security, and zero-knowledge proofs are not privacy. + +What the pilot is. One SP1 program of yours, one version, pinned by its verifying key. You send inputs per job; we return a compressed proof you verify with SP1's verifier against that key before it counts. Delivery inside 30 minutes of receipt. One job an hour, or one per update, for four weeks. A proof that fails your verifier is not a delivered job and is not paid. + +What it costs. A pilot quote of USD 0.25 per billion cycles of your program, minimum USD 2 per job, paid in your currency on your chain to a payout contract keyed by the operator who delivered. The quote is built from measured power and card cost on the fleet and is stated plainly so you can compare it with what you pay now. + +What we ask of you. The program and verifying key as deployed; at least 100 historical inputs with expected public values so our provers and your verifier agree before any job carries value; the deadline and the maximum cycles per job; the address that receives proofs; and a published pass or fail at the end: 500 paid jobs over four weeks, 99 percent inside the deadline. + +What we do not claim. The external proving market is not yet built and is not in our revenue assumptions. Your pilot would be the first external workload on the network; the job intake, payment contract and delivery log are built for it and published with their measurements. Nothing in this brief is an offer to sell a token. + +Contact: through the repository and the site's team page. diff --git a/docs/provenance.md b/docs/provenance.md index 788320fd3..2b8fda547 100644 --- a/docs/provenance.md +++ b/docs/provenance.md @@ -21,7 +21,7 @@ How to read the licence column. "Verified" means the LICENSE file or the crate's | BLS12-381 | Curve 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 aggregate | Finality rule v2 needs one aggregate signature per checkpoint from thousands of keys | Spec section 3.1 (W1) and 2.4; `sim/results_v2.md` for the rule itself. Signature cost not yet measured | | Hashing in the node | rusty-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.0 | Unchanged, 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 levels | The chain's hash for everything except the lottery is the one the forked commit uses (spec 0.6), so nothing unverified enters consensus | `hash_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 format | Bitcoin 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, verified | Prefixes only: `igneum`, `igneumtest`, `igneumsim`, `igneumdev` (Kaspa: `kaspa`, `kaspatest`, `kaspasim`, `kaspadev`). The script public key behind an address is unchanged | No Igneum address string may parse as a Kaspa address on any network | Fork-divergence row 9; test vectors in `addresses` and `txscript` regenerated and passing | -| The EVM | Ethereum (Yellow Paper and ethereum/execution-specs, CC0 approximate). Cancun opcode set, precompiles 0x01 to 0x09 | Semantics 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 dimension | Blocks on a DAG have no single parent and no header state root; proving cost is a second resource; the random beacon must be unbiasable | Spec section 7.1 (normative table); devnet measurement R9 for timestamp drift; `ethereum/tests` replay in the differential plan | +| The EVM | Ethereum (Yellow Paper and ethereum/execution-specs, CC0 approximate). Cancun opcode set, precompiles 0x01 to 0x09 | Semantics 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 (historical: Devnet 3 answers chain id 4464 since its class v5 floor at DAA 68,400 on 8 October 2026, 4463 below it; the current id is in /release.json); 0x0a absent; gas has a second dimension | Blocks on a DAG have no single parent and no header state root; proving cost is a second resource; the random beacon must be unbiasable | Spec 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, verified | Kept 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 through | Lets the devnet run and lets upstream pow changes merge cleanly | Fork-divergence rows 14 and 15; open item in the same file (pruning-proof block levels) | ## What is new in Igneum diff --git a/docs/spec/07-execution.md b/docs/spec/07-execution.md index 7ac8c99ce..3ee48cf76 100644 --- a/docs/spec/07-execution.md +++ b/docs/spec/07-execution.md @@ -57,7 +57,7 @@ Nothing in consensus changes for any of this: the segment claim already commits | Parameter | Value | Label | |---|---|---| -| Chain id | 4461 / 4462 / 4463 (mainnet / testnet / devnet) | Designed | +| Chain id | 4461 / 4462 / 4463 (mainnet / testnet / the shared devnet); Devnet 3 answers 4464 since its class v5 floor at DAA 68,400 (8 October 2026) and 4463 below it, the id a function of the block's DAA score | Designed; the Devnet 3 value measured (the current id is in /release.json) | | BLOCKHASH reach | 256 chain blocks | Designed (Ethereum's) | | PREVRANDAO source | 10-minute epoch VDF output, keccak256 with the chain height | Designed | | Opcode set, precompiles | Cancun; 0x01 to 0x09 | Designed | diff --git a/site/bench.html b/site/bench.html index 50302c13c..410ee4be7 100644 --- a/site/bench.html +++ b/site/bench.html @@ -254,20 +254,20 @@ table{min-width:560px}

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

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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)

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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)

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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)

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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)

@@ -280,23 +280,23 @@ table{min-width:560px}

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)

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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)

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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)

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)

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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)

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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)

@@ -335,7 +335,7 @@ table{min-width:560px}

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

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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).

@@ -350,7 +350,7 @@ table{min-width:560px}
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)

Historical record of 2026-10-03: the code and the chain as they stood that day. The chain's current state is the release manifest.

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)
@@ -362,7 +362,7 @@ table{min-width:560px}

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)

Historical record of 2026-10-04: the code and the chain as they stood that day. The chain's current state is the release manifest.

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.

@@ -376,7 +376,7 @@ table{min-width:560px}

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 founder's 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)

Historical record of 2026-10-04: the code and the chain as they stood that day. The chain's current state is the release manifest.

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
@@ -387,7 +387,7 @@ table{min-width:560px}

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)

Historical record of 2026-10-04: the code and the chain as they stood that day. The chain's current state is the release manifest.

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}/.

@@ -411,7 +411,7 @@ table{min-width:560px}
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)

Historical record of 2026-10-04: the code and the chain as they stood that day. The chain's current state is the release manifest.

Decision of 4 October 2026 (the founder, 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".

@@ -451,7 +451,7 @@ table{min-width:560px}
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)

Historical record of 2026-10-04: the code and the chain as they stood that day. The chain's current state is the release manifest.

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
@@ -503,7 +503,7 @@ table{min-width:560px}

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)

Historical record of 2026-10-04: the code and the chain as they stood that day. The chain's current state is the release manifest.

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.

@@ -523,7 +523,7 @@ table{min-width:560px}

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)

Historical record of 2026-10-04: the code and the chain as they stood that day. The chain's current state is the release manifest.

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
diff --git a/site/build.html b/site/build.html index b84f04b15..6b24c4954 100644 --- a/site/build.html +++ b/site/build.html @@ -261,7 +261,7 @@ table{min-width:560px}

The EVM you already know. Solidity deploys unchanged. Standard JSON-RPC, EIP-1559 transactions, the chain id in the signature, cancun as the EVM version. Gas has two dimensions on Igneum, execution and proving, and the node folds the second into the price it quotes, so eth_estimateGas and eth_gasPrice work as they do on Ethereum.

Networks

-
Devnet 3TestnetMainnet
Chain id4464 (0x1170) since its class v5 floor on 8 October 2026; 4463 below it4462 (0x116e)4461 (0x116d)
Network idigneum-devnet-3igneum-testnet-1not started
RPChttps://rpc.devnet.igneum.network (a node you run serves http://127.0.0.1:26790)https://rpc.testnet.igneum.network (answers; nothing mines there yet, so a transaction waits)none
Coinsno value, resets without noticeno value, resets with noticenot started
Symbol, decimalsIGN, 18IGN, 18IGN, 18
+
Devnet 3TestnetMainnet
Chain id4464 (0x1170) since its class v5 floor on 8 October 2026; 4463 below it4462 (0x116e)4461 (0x116d)
Network idigneum-devnet-3igneum-testnet-1not started
RPChttps://rpc.devnet.igneum.network (a node you run serves http://127.0.0.1:26790)https://rpc.testnet.igneum.network (answers; nothing mines there yet, so a transaction waits)none
Coinsno value, resets without noticeno value, resets with noticenot started
Symbol, decimalsIGN, 18IGN, 18IGN, 18
Machine-readable/release.json: the chain id, the source commits and fingerprints, the mining class, the finality rule, the proof program ids, the fee schedule and the current version per platform, with a generated date

Devnet 3 is where you build today. It is a developer network: it resets without notice and its coins have no value. Its public RPC takes the read methods, eth_sendRawTransaction and a wRPC websocket at /ws, at 20 requests a second per address. The public testnet exists, its RPC answers, and no blocks are being produced on it until it opens. Mainnet has no date. Devnet 3 answered 4463 until its class v5 floor at DAA 68,400 on 8 October 2026 and 4464 from it; read it with eth_chainId rather than fixing it, since a transaction signed for the wrong id is refused.

Endpoints and tools

diff --git a/site/build.mjs b/site/build.mjs index 70ff80120..ae9f034b0 100644 --- a/site/build.mjs +++ b/site/build.mjs @@ -125,11 +125,27 @@ ${shareHtml(path, title, desc)} `; } +// The release manifest (8 October 2026, an accepted external review): site/release-manifest.json is served at /release.json +// (vercel.json rewrite) and every number a status page carries from it sits in ..., filled here +// at build; tools/ci/release-manifest-check.mjs holds the committed pages to the manifest and the manifest to its sources. +const RM = JSON.parse(readFileSync(join(here, 'release-manifest.json'), 'utf8')); +export function rmValue(path) { + const v = path.split('.').reduce((o, k) => (o == null ? undefined : o[k]), RM); + if (v === undefined) throw new Error(`release-manifest.json: no value at ${path}`); + return typeof v === 'number' && !/_id$/.test(path) ? v.toLocaleString('en-GB') : String(v); // an id is never grouped +} +export function fillManifest(html) { + // the hand pages carry ; the markdown sources carry {{rm:path}} (their renderer escapes raw HTML) + html = html.replace(/\{\{rm:([a-z0-9_.-]+)\}\}/g, (m, p) => `${rmValue(p).replace(/&/g, '&').replace(/`); + return html.replace(/[^<]*<\/span>/g, (m, p) => `${rmValue(p).replace(/&/g, '&').replace(/`); +} 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'); + // a dated log entry is a historical record (8 October 2026): the label sits under its heading, the current state is /release.json + const hist = (p) => p.replace(/^(

[\s\S]*?<\/h2>)/, (m, h, d) => `${h}

Historical record of ${d}: the code and the chain as they stood that day. The chain's current state is the release manifest.

`); + return parts.filter(p => p.trim()).map(p => `
${hist(p)}
`).join('\n'); } function page(title, desc, bodyHtml, toc, note, { path = '/bench', heading = title, eyebrow, crumb, filter = true } = {}) { const active = path.replace(/^\//, ''); @@ -282,7 +298,8 @@ for (const [src, file, title, desc, heading, lead, eyebrow] of [ ]) { const mdp = join(docs, 'build', src); if (!existsSync(mdp)) continue; // the gate builds a copy of site/ alone: the committed page stands, as for /bench - const { html, toc } = md(readFileSync(mdp, 'utf8')); + const { html: mdHtml, toc } = md(readFileSync(mdp, 'utf8')); + const html = fillManifest(mdHtml); const path = '/' + file.replace(/\.html$/, ''); writeFileSync(join(here, file), page(title, desc, html, toc, lead, { path, heading, crumb: heading, eyebrow, filter: false }).replace('

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

', `

Generated from docs/build/${src} in the repository at build time. Times are UTC.

`)); built.push(file); @@ -372,7 +389,7 @@ function renderEvidence(html) { const start = src.indexOf('\n| # | Claim |'); const end = src.indexOf('\n## Count by status'); if (start < 0 || end < 0) throw new Error('evidence.md: claims table not found'); const rows = src.slice(start, end).split('\n').filter(l => /^\| \d+ \|/.test(l)); - const LABELS = ['designed', 'implemented', 'tested by the team', 'reproduced externally', 'reviewed independently']; + const LABELS = ['designed', 'implemented', 'activated', 'tested by the team', 'reproduced externally', 'reviewed independently']; const inl = t => esc(t.trim()).replace(/`([^`]+)`/g, (m, c) => `${c}`); const cells = l => l.replace(/^\| /, '').replace(/ \|$/, '').split(' | '); const counts = Object.fromEntries(LABELS.map(k => [k, 0])); @@ -436,6 +453,30 @@ for (const [file, active] of PAGES) { html = stampDownloads(html, file, downloads); html = stampMarks(html); if (file === 'evidence.html') html = renderEvidence(html); + // /economics, "Who pays for proving" (8 October 2026, an accepted external review): the model table is computed here from + // site/lib/emission.mjs (the node's constants) and the release manifest, never typed; the measured rows on the page are the + // observer's proving view as read that day. Labels: the per-day pool is modelled from the schedule; the per-shard and per-key + // lines hold today's measured shard and key counts constant; nothing here is a price. + if (file === 'economics.html' && html.includes('')) { + const em = await import('./lib/emission.mjs'); + const ign = (s) => Number(em.sompiToIgn(s)); + const fmt = (n, d = 2) => n.toLocaleString('en-GB', { maximumFractionDigits: d, minimumFractionDigits: d }); + const PV = RM.proving_view; // the measured 24-hour read on the page (shards paid, IGN paid, keys, planned) + const daa = Number(PV.read_daa); + const poolShare = Number(RM.fees.subsidy_split.proving_pool_percent) / 100; + const rows = []; + const line = (label, subsidyIgn, when, note) => { + const poolBlock = subsidyIgn * poolShare, poolDay = poolBlock * 86400; + rows.push(`${label}${fmt(subsidyIgn, 3)}${fmt(poolBlock, 3)}${fmt(poolDay, 0)}${fmt(poolDay / PV.shards_planned_24h, 2)}${fmt(poolDay / 24 / PV.prover_keys_24h, 1)}${when}${note ? `; ${note}` : ''}`); + }; + line('Today, inside the launch ramp', ign(em.blockSubsidy(daa)), `DAA ${daa.toLocaleString('en-GB')}, ${(em.rampFactor(daa) * 100).toFixed(1)} percent of the full rate`, 'modelled; the measured payout is in the row above'); + const names = ['Full rate (years 1 to 2)', 'After the first halving (years 3 to 4)', 'After the second (years 5 to 6)', 'After the third (years 7 to 8)', 'After the fourth (years 9 to 10)', 'After the fifth (years 11 to 12)']; + names.forEach((n, p) => line(n, ign(em.subsidyPerSecond(p)), `period ${p} of the schedule`, p === 0 ? 'from day 30' : '')); + const table = `
${rows.join('')}
WhenSubsidy per block, IGNPool per block, IGNPool per day, IGNPer planned shard, IGNPer prover key per hour, IGNBasis
+

Modelled from emission.rs (the schedule as site/lib/emission.mjs carries it) and the release manifest at build time, with today's measured shard count (${PV.shards_planned_24h.toLocaleString('en-GB')} planned in 24 hours) and key count (${PV.prover_keys_24h}) held constant; the per-shard figure is the pool's credit per planned shard, the per-key figure the pool per day divided by the keys and by 24. More shards or more keys lower both; a block's unproven shards leave their credit in the escrow.

`; + html = inject(html, 'proving-model', table, file); + } + html = fillManifest(html); if (file === 'index.html' && html.includes('')) html = inject(html, 'journey', ``, file); // /income (8 October 2026): the calculator's card list is the bench table's current rows, stock and tuned apart, inlined // at build so the page needs no fetch; a row's watts carry their class when they were read under another (watts_class) diff --git a/site/claims.html b/site/claims.html index c06d21d24..1265730e6 100644 --- a/site/claims.html +++ b/site/claims.html @@ -251,7 +251,7 @@

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). At launch the strongest chip in our public model reaches 2.1x per joule against an RTX 5090 with a core as good as a GPU lane and 3.4x with one three times better, under class v4 from the first block: a memory-controller chip that stores the whole dataset and carries a GPU-class datapath beside its memory for the 100,000 ops per hash in the shadow, the range running from a chip core as costly per operation as a GPU lane (k = 1, modelled on the 5090’s measured watts at its knee, 7 October 2026) to a core three times better per operation (k about 0.33); the withdrawn Antminer X9’s claimed figure is a ratio against a CPU core, not a GPU lane, so it does not stand for a chip core against us; the ladder’s second rung takes that bracket to about 2.8x (modelled, 7 October 2026). Class v5 then makes the dataset the chain’s own state, so a chip that stores it or recomputes it is wrong on every item (designed, 7 October 2026). The baseline the work started from, never the launch state: without class v4 the same stored-dataset chip would reach 1.2x per chip and 5x to 9x per joule in our model (6 October 2026); the Ethash chips of this class reached 2.1x to 4.8x (Linzhi Phoenix 2020, Jasminer X4 2021, Antminer E9 2022). The strongest recompute chip we can price, holding the whole 256 MiB cache on-die, reaches under 1x per chip against an RTX 5090 (the published model, 5 October 2026: 0.92x per unit of silicon with a 3x fixed-function allowance, approximate). Sources: the chip model analysis (6 October 2026); the ASIC history’s Ethash rows; Counter ASIC 3.0 item 8 (the chip’s per-joule edge over the RTX 5090 falls from 5.6x to 2.1x on GDDR7 at k = 1 and to 3.4x at a core three times better, the 5090 at 0.2% less rate; gates G1 to G6 passed, 6 October 2026). No hash has stayed free of chips forever; Igneum does not claim to. Monero’s RandomX has held its miners on commodity hardware for about seven years: one chip shipped against it, Bitmain’s Antminer X5 (September 2023), at 1.46x per joule over a desktop CPU; the one announced beyond it, the Antminer X9, was withdrawn in mid-May 2026 before any unit shipped, its claimed core (k about 0.33) never measured; RandomX v2 was released on 25 March 2026 with its activation pending. 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 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). Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes. Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment. The labels: the bracket modelled, approximate and provisional (the GPU side measured on the RTX 5080 and RTX 5090 at their core locks under class v4, 8 October 2026; the chip core synthesised on ASAP7 and scaled to N3, claimed, its placed gated row pending; its memory modelled). Class v5 makes the dataset the chain’s own state, so a chip that stores it or recomputes it is wrong on every item (designed, 7 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 (the published model, 5 October 2026: 0.92x per unit of silicon with a 3x fixed-function allowance, approximate). Sources: the class v6 close, section 10 (8 October 2026); the ASIC history’s Ethash rows; the chip model analysis (6 October 2026). No hash has stayed free of chips forever; Igneum does not claim to. Monero’s RandomX has held its miners on commodity hardware for about seven years: one chip shipped against it, Bitmain’s Antminer X5 (September 2023), an observed comparison, not a ceiling; the one announced beyond it, the Antminer X9, was withdrawn in mid-May 2026 before any unit shipped, its claimed core never measured; RandomX v2 was released on 25 March 2026 with its activation pending. 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.
    • diff --git a/site/economics.html b/site/economics.html index b9a227ac6..d16b403bb 100644 --- a/site/economics.html +++ b/site/economics.html @@ -4,7 +4,7 @@ Igneum economics: the emission as the node encodes it - + @@ -215,7 +215,7 @@
    Igneum/Economics

    The economics, as the node encodes them.

    -

    Every number below is read from the node’s source at one commit, with the file and the line. No price of IGN appears and nothing is projected: this page says what the code pays, to whom, and from what.

    +

    Every number below is read from the node’s source at one commit, with the file and the line, and the constants the chain runs on are the release manifest’s, filled at build time (node f8da7515, read 8 October 2026, 15:50 UK). No price of IGN appears and nothing is projected: this page says what the code pays, to whom, and from what.

    Source: the node fork, branch release-0.3.25-node at e0644958 (the Devnet 3 cut of 8 October 2026), confirmed by the node lane on 8 October 2026; every line number is that commit’s. Devnet 3 inherits the devnet parameters (consensus/core/src/config/params.rs 2173 and 2207).

    @@ -225,7 +225,7 @@
    - + @@ -238,8 +238,8 @@
    FieldCURRENT (Devnet 3 today, mainnet)TESTNET_1 (igneum-testnet-1)Where
    Launch rate3,168,808,781 base units a DAA second (109 IGN x 108 / 31,557,600, floored: one billion IGN in year one)100 IGN a DAA secondemission.rs 85 to 123; igneum.rs 34
    Launch rate3,168,808,781 base units a DAA second (109 IGN x 108 / 31,557,600, floored: one billion IGN in year one)100 IGN a DAA secondemission.rs 85 to 123; igneum.rs 34
    Ramp2,592,000 s (30 days) from 10 percent7,776,000 s (90 days) from 10 percentigneum.rs 76 launch_ramp
    Step63,115,200 s (two years), the rate halved each step (decay 231 of 232)2,629,800 s (a month), the rate times 2-1/24 each step (decay 4,172,697,914 of 232: a two-year half-life)emission.rs 85 to 123
    Tailnone: the curve runs to zero and the sum is the hard cap, 4,000,000,000 IGN1 percent of supply a year (100 basis points) once the glide falls below itemission.rs 69 to 71
    - - + + @@ -249,15 +249,15 @@
    ShareGoes toStateWhere
    80 percentthe miner whose key found the blockin consensus on every networkconsensus/core/src/igneum.rs 44 (PROVING_POOL_SHARE_PERCENT = 20), applied at 87 and 202
    20 percentthe proving pool, paid per shard to the provers of a segment record from a keyless escrow accountin consensus; the escrow is PROVING_POOL_ADDRESS in the execution layerigneum.rs 44; igneum/exec/src/config.rs
    80 percentthe miner whose key found the blockin consensus on every networkconsensus/core/src/igneum.rs 44 (PROVING_POOL_SHARE_PERCENT = 20), applied at 87 and 202
    20 percentthe proving pool, paid per shard to the provers of a segment record from a keyless escrow accountin consensus; the escrow is PROVING_POOL_ADDRESS in the execution layerigneum.rs 44; igneum/exec/src/config.rs
    A silent block’s bonusa slice of the producer’s share moved to the pool when the producer did not sign its checkpoints, nothing destroyeddesigned and in the code, not active: signing_bonus_activation_daa is u64::MAX on every objectigneum.rs 96 silent_split; params.rs 1717
    0any team, foundation, fund or treasuryno such output exists in the subsidy and no protocol tip reaches any addressigneum.rs; spec 05 section 5.5
    - - - + + +
    RouteWhat happensStateWhere
    Base fee, execution gasburned in full: gas used times the execution base fee, debited and credited to no one; the proving dimension is the proving payment two rows downin the code on Devnet 3igneum/exec/src/executor.rs 320 to 371 (327 and 357, 328 and 360)
    Priority fee (the tip)80 percent to the block’s miner; 20 percent to the developer registrations of the contracts whose code ran, pro rata by each frame’s gas; an unregistered frame’s part is credited to nobody, which is a burn; no part of the tip reaches the provers (spec O-5.7 closed at zero, 8 October 2026)in the code on Devnet 3executor.rs 335 to 339; igneum/exec/src/pgas.rs 290; igneum/exec/src/config.rs 76 (DEVELOPER_SHARE_PERCENT = 20)
    The proving payment (pgas used times the proving base fee, the congestion price of proving capacity)90 percent to the block’s proving pool, paid per shard to its provers by consensus proving cost; 10 percent burned (the decision of 8 October 2026 that resolves the tip-share question: provers are paid by users for proving, not from the tip)designed, not in the code: on Devnet 3 the whole proving base fee is still burned (executor.rs 357 and 360); the routing is pinned behind an activation constantspec 05 sections 5.1 and 5.3; docs/design/proving-payment.md
    Base fee, both gas dimensionsburned in full: gas used times the execution base fee, pgas used times the proving base fee, debited and credited to no onein the code on Devnet 3igneum/exec/src/executor.rs 320 to 371 (327 and 357, 328 and 360)
    Priority fee (the tip)80 percent to the block’s miner; 20 percent to the developer registrations of the contracts whose code ran, pro rata by each frame’s gas; an unregistered frame’s part is credited to nobody, which is a burnin the code on Devnet 3executor.rs 335 to 339; igneum/exec/src/pgas.rs 290; igneum/exec/src/config.rs 76 (DEVELOPER_SHARE_PERCENT = 20)
    External proving jobs90 percent to the provers who delivered, 10 percent burned, once jobs settle in IGNdesigned, not in the code: no constant exists; at launch a job is paid on the customer’s own chainspec 05 section 5.4; the litepaper’s Proving section
    The provers’ part of the tipdesigned: a share of the producer’s 80 percent paid per block to the block’s provers in the proportion the proving protocol defines, per shard with the pool creditdesigned, not in the code: no constant exists; the executor credits the whole 80 percent to the miner (executor.rs 335 to 339)spec 05 sections 5.2 and 5.3

    The proving-fee market

    -

    The second income of a card is the proving pool above: 20 percent of every block, paid per shard against a valid proof record, plus 90 percent of every block’s proving payment, which users pay at the congestion price of proving capacity (the proving base fee); nothing from the priority fee, which stays whole to the block. The price a prover must charge an outside customer is the subsidy it forgoes while it proves, which falls as one over the network’s hash rate; the formula and its measured inputs are in the litepaper (Building on Igneum). The market itself is designed and not built. What the pool pays today is measured: on Devnet 3 in the 24 hours to 12:16 UK on 8 October 2026 the chain paid 8,209 shards, 9,913.09 IGN in all, to 29 prover keys; 905 shards were paid in the hour to that minute; the lag from a proven block to the block that pays its shards read p50 514 and p90 953 DAA seconds; 40,502 shards were planned and 54 proving at that minute (the observer’s proof tables, read through /api/explorer?proving=1; the same numbers live on the proving page). Devnet 3 IGN has no value; the rows show the mechanism paying, not an income.

    +

    The second income of a card is the proving pool above: 20 percent of every block, paid per shard against a valid proof record. A provers’ part of the priority fee is designed (spec 05, 5.2: a share of the producer’s 80 percent paid per block to the block’s provers) and is not in the code: today the whole 80 percent of the tip goes to the miner, the executor’s line above, and the pool is the only thing that pays an internal prover. The price a prover must charge an outside customer is the subsidy it forgoes while it proves, which falls as one over the network’s hash rate; the formula and its measured inputs are in the litepaper (Building on Igneum). The market itself is designed and not built. What the pool pays today is measured: on Devnet 3 in the 24 hours to 12:16 UK on 8 October 2026 the chain paid 8,209 shards, 9,913.09 IGN in all, to 29 prover keys; 905 shards were paid in the hour to that minute; the lag from a proven block to the block that pays its shards read p50 514 and p90 953 DAA seconds; 40,502 shards were planned and 54 proving at that minute (the observer’s proof tables, read through /api/explorer?proving=1; the same numbers live on the proving page). Devnet 3 IGN has no value; the rows show the mechanism paying, not an income.

    The client fee and the fund it fills

    @@ -269,6 +269,30 @@
    +

    Who pays for proving

    +

    Three incomes, kept apart. Each has its own source and its own state.

    +
    + + + +
    IncomeWhere it comes fromWho gets itState
    Block securitythe block subsidy (80 percent of each block) and 80 percent of the priority feethe miner whose key found the blockin consensus on every network (measured)
    Internal provingthe proving pool: a fifth of each block’s subsidy (20 percent), paid per shard against a valid proof record; nothing else pays an internal prover todaythe prover keys that delivered the shardsin consensus on Devnet 3 (measured below); the provers’ part of the tip designed, not in the code
    External customerspayments from other chains for proofs, settled in IGN: 90 percent to the provers, 10 percent burnedthe provers who took the jobdesigned, not implemented: no constant exists, no job has been paid
    +

    The proving base fee pays nobody. A transaction’s pgas times the proving base fee is burned in full today (executor.rs, the base-fee row above). It is not a prover’s income and it does not fill the pool. The pool is filled by the subsidy alone, and the subsidy halves every two years.

    +

    What the pool pays, measured

    +

    On Devnet 3 in the 24 hours to 12:16 UK on 8 October 2026: 8,209 shards paid, 9,913.09 IGN in all, to 29 prover keys; 40,502 shards planned, so about a fifth of the planned shards were proven and paid and the rest left their credit in the escrow; 905 shards paid in the last hour; the lag from a proven block to the block that pays p50 514 and p90 953 DAA seconds. Per shard paid that is about 1.21 IGN; per key about 12 shards and 14 IGN an hour averaged over the day, across keys that prove at very different rates (measured; the observer’s proof tables through /api/explorer?proving=1).

    +

    What reaches provers under the schedule, modelled

    +

    Low fees and no external demand, which is the chain today: the pool is a fifth of the subsidy and nothing else. The table holds today’s shard count and key count constant and walks the halvings. No price of IGN appears; whether a row covers a card’s electricity depends on the price, which this page does not state.

    + +
    WhenSubsidy per block, IGNPool per block, IGNPool per day, IGNPer planned shard, IGNPer prover key per hour, IGNBasis
    Today, inside the launch ramp3.8940.77967,2861.6696.7DAA 65,900, 12.3 percent of the full rate; modelled; the measured payout is in the row above
    Full rate (years 1 to 2)31.6886.338547,57013.52786.7period 0 of the schedule; from day 30
    After the first halving (years 3 to 4)15.8443.169273,7856.76393.4period 1 of the schedule
    After the second (years 5 to 6)7.9221.584136,8933.38196.7period 2 of the schedule
    After the third (years 7 to 8)3.9610.79268,4461.6998.3period 3 of the schedule
    After the fourth (years 9 to 10)1.9810.39634,2230.8449.2period 4 of the schedule
    After the fifth (years 11 to 12)0.9900.19817,1120.4224.6period 5 of the schedule
    +

    Modelled from emission.rs (the schedule as site/lib/emission.mjs carries it) and the release manifest at build time, with today's measured shard count (40,502 planned in 24 hours) and key count (29) held constant; the per-shard figure is the pool's credit per planned shard, the per-key figure the pool per day divided by the keys and by 24. More shards or more keys lower both; a block's unproven shards leave their credit in the escrow.

    + +

    Per card, per hour, now and at each halving

    +

    A card’s proving income is its shards times the credit per shard. Measured rates: an RTX 5090 proves an empty live shard beside its miner in 7.0 to 7.7 s and a full shard in 10.9 s alone, about 37 s a shard end to end (export, cut, key set-up, prove, sign, submit), 1.4 shards a minute; an RTX 3060 (12 GB) proves the v1 shard beside its miner in 37.5 s; an RTX 4060 (8 GB) proves it alone in 18.4 s (the engineering log, 4 to 6 October 2026). At those rates one card can prove 80 to 100 shards an hour, more than the 905 an hour the whole chain paid to 29 keys, so today a prover is limited by the shards on offer, not by its card: the hourly figure per key in the table is the ceiling an evenly shared pool gives, and a 5090 and a 3060 take the same credit per shard. At each halving the credit per shard halves with the pool; a card’s watts do not. (Modelled from the measured rates; the chain’s shard count is the real limit.)

    +

    Two honest routes to sustain it

    +
    + + +
    RouteWhat it doesWhat it is worthState
    A defined share of fees to the proving poola fixed percentage of the base fees burned today (both gas dimensions) credited to the pool instead, by a rule at genesis or a class changeeach percent of the share adds one percent of the day’s burned base fees to the pool. Priced per unit, not predicted: at 100,000 IGN of base fees burned in a day (a hypothetical volume, not a forecast) a 10 percent share adds 10,000 IGN a day, about today’s measured payout; at Devnet 3’s fee volume today it adds almost nothing, because almost nothing is burneddesigned as an option; no constant exists
    External settlement in IGNother chains pay for proofs in IGN; 90 percent to the provers, 10 percent burnedthe price a prover must charge is the subsidy it forgoes while it proves: per shard, (card hash ÷ network hash) × 0.8 × the block subsidy × shard seconds. For an RTX 5090 at 136 MH/s on a 1 GH/s network and a 37 s shard that is about 16 IGN a shard inside the ramp today and about 128 IGN at the full rate, against the pool’s 1.2 IGN a shard measured; the quote falls as one over network hash and is competitive near 100 GH/s (the litepaper, Building on Igneum)designed; the settlement contract is not built
    +

    The chip question (whether a chip gets built against the hash, and what it would earn) is a conditional argument of its own on the litepaper’s chip model, not part of this page.

    Units and decimals

    @@ -281,7 +305,7 @@

    The symbol is IGN on every network. A wallet shows 18 decimals everywhere; on Devnet 3 the chain pays in 8 and the bridge shows the same amount at 18.

    What this page does not do

    -

    It names no price, projects no income and models no market. The income page turns these rules into IGN a day for a card you pick, and money a day only at a price you type. Devnet and testnet IGN have no value.

    +

    It names no price and models no market; the proving model above walks the subsidy schedule at today’s measured shard and key counts and states no price. The income page turns these rules into IGN a day for a card you pick, and money a day only at a price you type. Devnet and testnet IGN have no value.

    Not legal advice.

    diff --git a/site/evidence.html b/site/evidence.html index daa6c7c28..303047ed0 100644 --- a/site/evidence.html +++ b/site/evidence.html @@ -4,7 +4,7 @@ Igneum evidence - + @@ -254,57 +254,59 @@ td.mono{font-family:var(--f-mono);font-size:12.5px;min-width:180px}td.iv{color:v
    31 claims · 5 labels · 8 Oct 2026

    Evidence.

    -

    Every claim the homepage and the litepaper make, one row each, with one of five labels: designed (a decision, no code), implemented (code with passing test vectors), tested by the team (measured by the project on a named machine, in the engineering log), reproduced externally (a third party ran the published command and got the published result) and reviewed independently (a named outside reviewer published a finding on that version). Nothing on this chain has been reproduced externally or reviewed independently; every row says so. A label belongs to the exact version in the row, and an audit of one version never covers a newer one. The 12-node cloud network of 4 October 2026 is the project's own, so its rows are tested by the team, not reproduced externally.

    +

    Every claim the homepage and the litepaper make, one row each, with one of six labels: designed (a decision, no code), implemented (code with passing test vectors), activated (live on a named chain by its activation height, on the node’s own line), tested by the team (measured by the project on a named machine, in the engineering log), reproduced externally (a third party ran the published command and got the published result) and reviewed independently (a named outside reviewer published a finding on that version). Nothing on this chain has been reproduced externally or reviewed independently; every row says so. A label belongs to the exact version in the row, and an audit of one version never covers a newer one. The 12-node cloud network of 4 October 2026 is the project's own, so its rows are tested by the team, not reproduced externally.

    designed
    6

    A decision in the design document or the specification. No code, or a stub

    implemented
    3

    Code in the repository with test vectors that pass. Not measured as the claim

    +
    activated
    0

    Live on a named chain by its activation height, on the node’s own line. Not yet a measurement of the claim

    tested by the team
    22

    Measured or exercised by the project on a named machine, with the command in the log

    reproduced externally
    0

    None yet. Nobody outside the project has run a published command yet

    reviewed independently
    0

    None yet. What review would cost and who pays is in the funding plan

    -
    +

    The table is wider than this screen. Scroll it sideways.

    NetworkConsensus sideEVM sideWhere
    - + - - - - - - - - - - - - + + + + + + + + + + + + - - - + + + - - + + - + - - - - + + + +
    #ClaimStatusVersion or commitReproducible testResult, date, machineIndependent verification
    1A new mining program every hour, compiled by the miner, with no human in the loop and no pause in mining
    Homepage hero and "This hour's program"; litepaper Mining
    		tested by the teamigneum-pow 0.2.0; repo b27da39, 1292110, 100c5d7; fork devnet-v4 6457ca95The live devnet v4: the node announces next_epoch_seed 150 DAA past the seed score, igneum-miner sends prepare to its worker, the worker builds the next program while the current one mines; Metal (proto-metal/igneum-bench), CUDA and OpenCL workers; bench-log "first hourly program swap on the live devnet"Epoch boundary at DAA 3,600 (10:05:07 UTC, 4 October 2026) crossed live on three vendors: the Apple M5 Max M5 Max (Metal) compiled the next program in 82 ms, 449 DAA before the boundary, swapped in 0.01 ms, 26.7 MH/s before and after; the RTX 5090 compiled in 1,285 ms, swapped in 0.00 ms, 121.8 before and 123.4 MH/s after; the integrated AMD chip 2.74 MH/s before and after. 0 restarts, 0 rejected blocks, 0 rebuilds. The epoch seed is the epoch block hash; the delay of row 2 is not wired in. At a later boundary (DAA 18,000) one OpenCL worker on the RTX 5090 Windows rig stayed on the previous epoch after an app reinstall and answered 514 jobs with a seed mismatch; fixed in the miner (3bfe346f, workers emit a need line), the swap time of that forced prepare not measurednone yet
    1A new mining program every hour, compiled by the miner, with no human in the loop and no pause in mining
    Homepage hero and "This hour's program"; litepaper Mining
    		tested by the teamigneum-pow 0.2.0; repo b27da39, 1292110, 100c5d7; fork devnet-v4 6457ca95The live devnet v4: the node announces next_epoch_seed 150 DAA past the seed score, igneum-miner sends prepare to its worker, the worker builds the next program while the current one mines; Metal (proto-metal/igneum-bench), CUDA and OpenCL workers; bench-log "first hourly program swap on the live devnet"Epoch boundary at DAA 3,600 (10:05:07 UTC, 4 October 2026) crossed live on three vendors: the Apple M5 Max M5 Max (Metal) compiled the next program in 82 ms, 449 DAA before the boundary, swapped in 0.01 ms, 26.7 MH/s before and after; the RTX 5090 compiled in 1,285 ms, swapped in 0.00 ms, 121.8 before and 123.4 MH/s after; the integrated AMD chip 2.74 MH/s before and after. 0 restarts, 0 rejected blocks, 0 rebuilds. The epoch seed is the epoch block hash; the delay of row 2 is not wired in. At a later boundary (DAA 18,000) one OpenCL worker on the RTX 5090 Windows rig stayed on the previous epoch after an app reinstall and answered 514 jobs with a seed mismatch; fixed in the miner (3bfe346f, workers emit a need line), the swap time of that forced prepare not measurednone yet
    2The program seed passes through a 10-minute verifiable delay from a certified checkpoint, so nobody can grind the seed
    Litepaper Mining, vs RandomX ("Closed by a verifiable delay")
    		implementedrepo 792776e; proto-vdf/proto-vdf full 10-minute runs and the tamper cases in proto-vdf/README.md; bench-log "proto-vdf"Class group 1024-bit: 163,000 squarings per second, 10-min eval 585.4 s, prove 9.1 s on 12 threads, verify 4.47 ms, 516-byte proof; wrong checkpoint, flipped seed bit and T+1 all rejected; grinding model gains 0 blocks per epoch with the delay against +3.62 at a 30% advantage without it. 3 October 2026, Apple M5 Max, one core. Prototype only: not in the node on 4 October either, not reviewed against chiavdf (O-4.1)none yet
    3The dataset is memory-hard: computing an item costs more than loading it, and every hash does 128 distinct dataset reads
    Litepaper Mining and vs RandomX; homepage vs RandomX ("Memory 2 GB, growing")
    		tested by the teamrepo 58a5a63 (memory-hard), b27da39 (generator 2); igneum-pow 0.2.0 (memhard.rs, generator.rs, accept.rs); spec 01 sections 1.4.2 to 1.4.6; proto-metal/MEMHARD.mdproto-metal/igneum-bench --inline-dataset against the honest run at 1 GiB and 256 MiB; igneum-census --gen v2 --warps 64 over 20,000 programs; bench-log "memory-hard dataset" and "generator version 2 adopted"Honest 45.2 Mhash/s, inline (never reads the dataset) 9.49 Mhash/s, ratio 0.21 at 1 GiB, 0.10 at 256 MiB. 3 October 2026, Apple M5 Max. Generator 2, 4 October 2026: 20,000 programs, 128 static loads on every program, distinct addresses per hash mean 127.9, minimum 120.1; 5.2% of candidates rejected by the acceptance rule. The price of the 128 fresh reads is the hash rate: Apple OpenCL 45.0 MH/s on a version 1 program with 80 distinct loads against 27.5 to 27.9 on version 2; the RTX 5090 229 MH/s on a 104-load version 1 program at 1 GiB (3 October) against 121.8 to 124.2 MH/s mining version 2 on the live devnet (4 October). Apple only for the shortcut ratio (O-1.5); the on-die cache question of ledger M16 is unchangednone yet
    4The same program produces identical hashes on three GPU vendors, cache and dataset included
    Litepaper vs RandomX ("Bit-exact on Apple, NVIDIA and AMD, measured"), For miners; homepage
    		tested by the teamrepo f2e903e, 0f1fdaf (version 1 packs), b27da39 (version 2 packs igneum-genesis-mh, igneum-devnet-v4-epoch0); igneum-pow 0.2.0The 96 test vectors of a pack through proto-metal/igneum-bench, proto-cuda/host.cu, proto-opencl/host.c; batch fingerprint at --batch-log2 24; the miner's CPU re-check of every share a GPU worker finds on the devnet; bench-log entries "RTX 5090, memory-hard dataset", "AMD gfx1036", "RTX 5090 through NVIDIA OpenCL", "generator version 2 adopted", "the gfx1036 worker fault"Version 1: 96/96 on Apple Metal (M5 Max), NVIDIA CUDA and NVIDIA OpenCL (RTX 5090, Windows), AMD OpenCL (Ryzen 7 9800X3D integrated gfx1036, 1 compute unit), Apple OpenCL, pocl and two CPU references; batch fingerprint 98af644e993239e2 over 16.7 million nonces identical on the AMD chip and the 5090, 3 October 2026. Version 2: 96/96 on Apple Metal, Apple OpenCL and the CUDA and OpenCL emulators with identical fingerprints; on real NVIDIA and AMD silicon the version 2 vectors have not run as a pack, but both mined accepted blocks on the live devnet with the CPU re-check clean on every share (RTX 5090 at 124.2 MH/s, gfx1036 at 3.3 MH/s), 4 October 2026. The AMD device is an integrated chip; no discrete AMD card and no Intel card has run anything (O-1.15)none yet
    5A CPU verifies one hash in under 10 ms by simulating one warp
    Litepaper Mining ("about ten milliseconds"), vs RandomX; roadmap gate 2
    		tested by the teamrepo 75cac18, b27da39; igneum-pow 0.2.0 (verify.rs)cargo test and the crate bench in igneum-pow/; bench-log "igneum-pow: Rust crate bit-exact with proto-metal" and "generator version 2 adopted"0.411 to 0.579 ms per 32-lane warp steady, 0.41 to 0.87 ms cold, average of 20, 1 GiB dataset, cache held, one M5 Max performance core, 3 October 2026; version 2 units 0.631 ms (average of 20), cold 0.67 to 0.81 ms, 4 October 2026. Gate margin about 16x on this core. Not measured on a 2019-class laptop core (O-1.14)none yet
    6The hash is bound to the header: one nonce serves one header, and a wrong nonce is rejected
    Spec 1.6; litepaper Mining (implied by "checks a hash")
    		tested by the teamrepo 33f7b33, 9812466, b27da39; igneum-pow 0.2.0 (bind.rs, bound vectors re-cut for version 2, 39 crate tests)igneum-miner bad-nonce against a devnet node; igneum-pow hash-bound for the 96-nonce job across the 2^32 lane boundary; bench-log "first devnet blocks on the real lottery hash" and "generator version 2 adopted"833 blocks accepted by igneum-lottery-v1-bound on 3 nodes, 0 rejections; bad-nonce gave Reject(BlockInvalid); Metal, OpenCL and CUDA (emulated) workers bit-exact with the crate on the lane-boundary job, 3 October 2026, Apple M5 Max. Version 2: the node's engine reports igneum-lottery-v2-bound, 39 of 39 crate tests, and the live devnet v4 accepts its blocks under it, 4 October 2026none yet
    7The devnet runs at one block a second
    Homepage stats ("1 / s"); litepaper Speed; roadmap phase 3
    		tested by the teamrepo 9812466, e9328c6, 8dae48b; fork devnet-v4 dc749905The merged node's 3-node test network (igneum-devnet-880, 960 s); the live devnet v4 record sim/difficulty/records/live-2026-10-04.csv; the 12-node cloud network's arrival logs; bench-log "devnet-v4 integration", "difficulty rule v2", "first devnet blocks"Devnet 3, 7 October 2026: first block accepted at 17:06 UTC, 85 of 85 GPU blocks by 17:10 UTC and 287 by 17:14 UTC, 0 rejected (docs/plans/release-0.3.22.md section 5). Merged node, 4 October 2026, Apple M5 Max: 1,055 blocks in 960 s, 1.03 blocks/s, sink identical on 3 nodes at 31 of 31 samples, 0 rejected. Live devnet v4 the same day: 49 to 81 blocks a minute while two RTX 5090s joined and left (row 12), 1.1 to 1.2 blocks/s in the oscillating window, then within 1.3% per minute with one PC and the Apple M5 Max. The 12-node cloud network at one block a second: 644 blocks in a 10-minute window. The 3 October CPU devnet: 1.29 blocks/s over 641 s, 1.03 after the first retarget. The phase 3 gate also asks for proofs under 60 s behind the tip; no proof is on the chain (row 15)none yet
    8Blocks are mined by GPUs on Apple and NVIDIA
    Homepage live strip; journey phase 3 ("GPU miners on three vendors")
    		tested by the teamrepo 9812466, e9328c6, d7e1f89, 2309c8d; fork devnet-v4Metal worker proto-metal/igneum-bench --serve driven by igneum-miner --worker; the live devnet v4 hash-rate record sim/difficulty/records/live-2026-10-04-hashrate.csv (587 worker STATUS lines by run id); bench-log "first devnet blocks", "devnet v4 cut-over", "difficulty rule v2", "first machine on the Igneum Miner app"Metal: 506 jobs, 5,636 blocks found and accepted, 0 rejected, 0 CPU/GPU mismatches, 28.2 MH/s wall, 3 October 2026. Live devnet v4, 4 October 2026: the three-card Windows rig's RTX 5090 at 122 MH/s with 8 identities, the RTX 5090 Windows rig's at 124 MH/s with 8 identities (117 to 119 MH/s inside the one-click app, 34 accepted blocks in its first minute, CPU re-check OK on every share), the Apple M5 Max's Metal worker at 26.7 MH/s; 17 vote keys signed the first finality lock (row 10); from the afternoon an Apple silicon laptop outside the project at 21.0 MH/s through the app (row 30). Two RTX 5090s and two Apple chips; no other NVIDIA model has minednone yet
    9Blocks are mined by a GPU on AMD
    Journey phase 3 ("three vendors")
    		tested by the teamrepo 2c4b30f (generic OpenCL worker, --pack), 112acf6 (fault guards); bound kernel kernel_bound.cl in the packigneum-worker-opencl.exe --pack on the RTX 5090 Windows rig's integrated Radeon against the live devnet v4 through the Windows package; bench-log "the gfx1036 worker fault", "first hourly program swap", "first machine on the Igneum Miner app"the RTX 5090 Windows rig's integrated gfx1036 (1 compute unit) mined on the live devnet on 4 October 2026: 8 accepted blocks at 3.3 MH/s over 577 s with the CPU re-check clean, and 2.74 MH/s through the hourly program swap with 0 rejected. At about 600 s the AMD runtime began answering every call with success while running nothing (906 jobs became 56,384 in 30 s, 4.3 GH/s of phantom work); not reproduced on Apple OpenCL in 4,565 jobs with 0 leaked objects; the worker and miner now refuse a job 20x faster than the mean or an unchanged output buffer and restart (112acf6), and the next gfx1036 run names the guard that fires. One integrated chip; no discrete AMD card has run anythingnone yet
    10Checkpoints lock every 30 s of chain at two thirds of all 30-day weight, and the floor stops conflicting locks in partitions and eclipses for as long as neither side's own new blocks carry it past two thirds of its window (about 10 days of a 30-day window at a 50/50 split)
    Litepaper Finality, "What Igneum does not claim"; homepage "locked every 30 seconds"
    		tested by the teamrepo a3a9833 (2/3 floor, O-3.15), bbb264a (simulation), c16ccf1; fork devnet-v4 6457ca95 (FLOOR_NUM / FLOOR_DEN 2/3), da1eb889 (F17 by-weight sortition, F1 first-month gate min_daa = window); spec 3.3, 3.3.1, 3.7, 3.9The live devnet v4 (getFinalityCheckpoints, tools/observer/observer.mjs, /api/checkpoint); sim/finality_v2.py --floor 1.0, scenarios A to L; the three-node, six-voter partition runs igneum-devnet-921 to -923; tools/finality-attacks scenarios 1 to 6 and 8; bench-log "first finality lock on the live devnet", "finality floor 2/3", "finality v2 attack harness", "finality fixes F17 and F1"Devnet 3, 7 October 2026: finality rule v3 from block zero, first lock at 19:02 UTC, under two hours after the first block (docs/plans/release-0.3.22.md). The first devnet: the first lock on the live devnet was checkpoint 242 at 11:03:44 UTC on 4 October 2026, two hours after genesis (the window and min_daa are 7,200 DAA), with 77.4% of all weight and of active weight signed by 12 aggregated votes from 17 vote keys; observer.mjs saw it 0.7 s after the miner's own lock line. By 13:21 UTC the observer held 280 certificates, indices 241 to 522 (DAA 7,229 to 17,982), 17 to 27 voters, no index with two hashes. Test networks, 4 October 2026, Apple M5 Max: a 4/2 split locked on the 4 side (67.9%) 2 to 8 s after the cut and never on the 2 side, 0 conflicts; a 3/3 split locked on neither side for 150 s with 0 conflicts, where the 3 October floor (56.7%) would have locked both sides at 76 and 106 s; the rule guarantees one lock history for partitions shorter than the window bound W / (3R) (200 s on that test network's 1,800-DAA window, about 40 minutes on the devnet, about 10 days at the 30-day mainnet window); beyond that bound each side can reach two thirds of its own window, so the next finality rule freezes the weight table at the last certified checkpoint and pauses instead. Simulator with the 2/3 floor: 0 conflicts up to a 33% equivocator (34% splits a 50/50 partition), silent weight pauses locks from 34%, a 50/50 partition locks alone from day 10.1. Harness: equivocating keys stripped on every node, Sybil dust at zero weight, a pulsed miner's weight equal to its block share (ratio 0.96 to 1.0), the first-month gate stops a young window locking under one key. Not demonstrated: certificate injection on the wire, an eclipse with a private fork, the 2-hour presence window at mainnet lengthnone yet
    11Hashrate that arrived today has almost no vote: ten days of the whole network's hashrate to reach a third of the weight, twenty for two thirds; 51% never reaches two thirds while honest miners stay
    Litepaper Finality; homepage firsts
    		tested by the teamrepo bbb264a; sim/finality_v2.pyScenario B of sim/finality_v2.py, seeds 7 and 11share(t) = (t/30) x a/(1+a) holds to 0.04 points; a renter equal to the whole honest network (a = 1) crosses 1/3 on day 20 and never reaches 2/3; a = 9 crosses 1/3 on day 11.1 and 2/3 on day 22.2. The ten-day figure is a = infinity, honest miners gone. 3 October 2026, Apple M5 Max. A model with 1,000 Pareto keys and no DAG; the live devnet's window is two hours old, so the claim has no live measurement yetnone yet
    12The difficulty rule recovers from a hashrate step within minutes, where Kaspa's sampled rule never settles. A step inside an epoch set the rule oscillating on the live devnet on 4 October 2026; rule v2 removes it in the simulator and on a test network and is built but not yet rolled out
    Spec 2.3; litepaper Speed (implied); bench page
    		tested by the teamrepo e9328c6, abb5a5d (attacks), 67bf226 (rule v2); fork difficulty branch (timestamp fix) and devnet-v4 a21ff239 (difficulty_v2_activation_daa, REF_WINDOW_V2 = 600); sim/difficulty/sim.py --liveThe live record sim/difficulty/records/live-2026-10-04.csv (8,090 headers, pull_live.py) and the hash-rate record beside it; sim/difficulty/sim.py on the synthetic set and the DAG replay; sim/difficulty/attacks/attacks.py; sim/difficulty/testnet_v2.py (3 nodes, activation at DAA 900); cargo test --release -p kaspa-consensus --lib difficulty (15 pass); bench-log "difficulty controller", "difficulty rule under attack", "timestamp attack fixed", "difficulty rule v2"Live devnet v4, 4 October 2026 (UTC): a second RTX 5090 joining 7 minutes into an epoch (about 152 to 280 MH/s) hardened the difficulty 70M to 144M in 90 s and then swung by about a third for 40 minutes around the true level of 139M while the epoch-long reference lane carried the join; that card leaving for 4 minutes eased 116M to 67M and back to 106M; the epoch boundary with both PCs restarting took 152M to 77M in 3 minutes, after which the rule held within 1.3% per minute with no flips. Cause: the reference lane covered the whole epoch, so a mid-epoch step polluted it for the hour and the 25% trigger flipped on the short lane's noise. The DAG replay reproduces the record (std of log difficulty 0.115 against 0.134, 4.3 peaks against 4). Rule v2 (reference window 600 DAA) on the replay: std 0.026, 0 flips, mean 142.6M against 139M true; on a 3-node test network the v2 nodes eased a leave with no peak and held a rejoin within 3% after 60 s, and a node without the activation height forked off at it as designed. Rule v2 rolled onto the 12-node cloud network on 4 October (all nodes crossed the height on one chain; a hash-rate step then settled in 160 to 270 s with no swing) and activates on the devnet at DAA 33,000 the same evening. Timestamp forging (ledger M23) fixed the same day: a 50% forger drifts the rate under 1.1% where the 3 October rule gave it a 9.9x difficulty. Simulator, settled seconds: x50 step 62 to 66 (Kaspa 1,542), /50 step 657 to 753 (Kaspa 12,296). Apple M5 Max under load 7 to 442; the DAG model is fitted on one scale; the pool hopper's 0.7-point excess over Kaspa's rule stays opennone yet
    13Every node executes the ordered transactions natively and reaches the same state root
    Litepaper Proving ("Every node executes ... natively"), Building ("runs on Igneum unchanged")
    		tested by the teamrepo f5f8c80, 8dae48b; fork devnet-v4 dc749905; revm 43.0.3node tools/evm-smoke/smoke.mjs against a 3-node igneumd; igneum-exec-diff seq.json; bench-log "execution layer devnet v3" and "devnet-v4 integration"Simnet, 3 October 2026: 87 of 87 viem checks, state roots identical on 3 nodes at four heights, 57 executed and 19 skipped transactions agree with plain revm, 0 mismatches. Merged node on real proof of work, 4 October 2026: 84 of 85 checks (the miss needs parallel blocks the network did not produce in 36 s), 59 transfers in 10 chain blocks, state roots identical on 3 nodes, igneum-exec-diff 0 mismatches over 59 transactions; the live devnet v4 runs this execution layer. Apple M5 Max. The prover is a stub; state is rebuilt from genesis at start; no EVM transaction relay between nodesnone yet
    14Ethereum bytecode runs unchanged, with the documented differences of spec 7.1
    Homepage Build card; litepaper Building
    		tested by the teamas 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 nodenone yet
    3The dataset is memory-hard: computing an item costs more than loading it, and every hash does 128 distinct dataset reads
    Litepaper Mining and vs RandomX; homepage vs RandomX ("Memory 2 GB, growing")
    		tested by the teamrepo 58a5a63 (memory-hard), b27da39 (generator 2); igneum-pow 0.2.0 (memhard.rs, generator.rs, accept.rs); spec 01 sections 1.4.2 to 1.4.6; proto-metal/MEMHARD.mdproto-metal/igneum-bench --inline-dataset against the honest run at 1 GiB and 256 MiB; igneum-census --gen v2 --warps 64 over 20,000 programs; bench-log "memory-hard dataset" and "generator version 2 adopted"Honest 45.2 Mhash/s, inline (never reads the dataset) 9.49 Mhash/s, ratio 0.21 at 1 GiB, 0.10 at 256 MiB. 3 October 2026, Apple M5 Max. Generator 2, 4 October 2026: 20,000 programs, 128 static loads on every program, distinct addresses per hash mean 127.9, minimum 120.1; 5.2% of candidates rejected by the acceptance rule. The price of the 128 fresh reads is the hash rate: Apple OpenCL 45.0 MH/s on a version 1 program with 80 distinct loads against 27.5 to 27.9 on version 2; the RTX 5090 229 MH/s on a 104-load version 1 program at 1 GiB (3 October) against 121.8 to 124.2 MH/s mining version 2 on the live devnet (4 October). Apple only for the shortcut ratio (O-1.5); the on-die cache question of ledger M16 is unchangednone yet
    4The same program produces identical hashes on three GPU vendors, cache and dataset included
    Litepaper vs RandomX ("Bit-exact on Apple, NVIDIA and AMD, measured"), For miners; homepage
    		tested by the teamrepo f2e903e, 0f1fdaf (version 1 packs), b27da39 (version 2 packs igneum-genesis-mh, igneum-devnet-v4-epoch0); igneum-pow 0.2.0The 96 test vectors of a pack through proto-metal/igneum-bench, proto-cuda/host.cu, proto-opencl/host.c; batch fingerprint at --batch-log2 24; the miner's CPU re-check of every share a GPU worker finds on the devnet; bench-log entries "RTX 5090, memory-hard dataset", "AMD gfx1036", "RTX 5090 through NVIDIA OpenCL", "generator version 2 adopted", "the gfx1036 worker fault"Version 1: 96/96 on Apple Metal (M5 Max), NVIDIA CUDA and NVIDIA OpenCL (RTX 5090, Windows), AMD OpenCL (Ryzen 7 9800X3D integrated gfx1036, 1 compute unit), Apple OpenCL, pocl and two CPU references; batch fingerprint 98af644e993239e2 over 16.7 million nonces identical on the AMD chip and the 5090, 3 October 2026. Version 2: 96/96 on Apple Metal, Apple OpenCL and the CUDA and OpenCL emulators with identical fingerprints; on real NVIDIA and AMD silicon the version 2 vectors have not run as a pack, but both mined accepted blocks on the live devnet with the CPU re-check clean on every share (RTX 5090 at 124.2 MH/s, gfx1036 at 3.3 MH/s), 4 October 2026. The AMD device is an integrated chip; no discrete AMD card and no Intel card has run anything (O-1.15)none yet
    5A CPU verifies one hash in under 10 ms by simulating one warp
    Litepaper Mining ("about ten milliseconds"), vs RandomX; roadmap gate 2
    		tested by the teamrepo 75cac18, b27da39; igneum-pow 0.2.0 (verify.rs)cargo test and the crate bench in igneum-pow/; bench-log "igneum-pow: Rust crate bit-exact with proto-metal" and "generator version 2 adopted"0.411 to 0.579 ms per 32-lane warp steady, 0.41 to 0.87 ms cold, average of 20, 1 GiB dataset, cache held, one M5 Max performance core, 3 October 2026; version 2 units 0.631 ms (average of 20), cold 0.67 to 0.81 ms, 4 October 2026. Gate margin about 16x on this core. Not measured on a 2019-class laptop core (O-1.14)none yet
    6The hash is bound to the header: one nonce serves one header, and a wrong nonce is rejected
    Spec 1.6; litepaper Mining (implied by "checks a hash")
    		tested by the teamrepo 33f7b33, 9812466, b27da39; igneum-pow 0.2.0 (bind.rs, bound vectors re-cut for version 2, 39 crate tests)igneum-miner bad-nonce against a devnet node; igneum-pow hash-bound for the 96-nonce job across the 2^32 lane boundary; bench-log "first devnet blocks on the real lottery hash" and "generator version 2 adopted"833 blocks accepted by igneum-lottery-v1-bound on 3 nodes, 0 rejections; bad-nonce gave Reject(BlockInvalid); Metal, OpenCL and CUDA (emulated) workers bit-exact with the crate on the lane-boundary job, 3 October 2026, Apple M5 Max. Version 2: the node's engine reports igneum-lottery-v2-bound, 39 of 39 crate tests, and the live devnet v4 accepts its blocks under it, 4 October 2026none yet
    7The devnet runs at one block a second
    Homepage stats ("1 / s"); litepaper Speed; roadmap phase 3
    		tested by the teamrepo 9812466, e9328c6, 8dae48b; fork devnet-v4 dc749905The merged node's 3-node test network (igneum-devnet-880, 960 s); the live devnet v4 record sim/difficulty/records/live-2026-10-04.csv; the 12-node cloud network's arrival logs; bench-log "devnet-v4 integration", "difficulty rule v2", "first devnet blocks"Devnet 3, 7 October 2026: first block accepted at 17:06 UTC, 85 of 85 GPU blocks by 17:10 UTC and 287 by 17:14 UTC, 0 rejected (docs/plans/release-0.3.22.md section 5). Merged node, 4 October 2026, Apple M5 Max: 1,055 blocks in 960 s, 1.03 blocks/s, sink identical on 3 nodes at 31 of 31 samples, 0 rejected. Live devnet v4 the same day: 49 to 81 blocks a minute while two RTX 5090s joined and left (row 12), 1.1 to 1.2 blocks/s in the oscillating window, then within 1.3% per minute with one PC and the Apple M5 Max. The 12-node cloud network at one block a second: 644 blocks in a 10-minute window. The 3 October CPU devnet: 1.29 blocks/s over 641 s, 1.03 after the first retarget. The phase 3 gate also asks for proofs under 60 s behind the tip; no proof is on the chain (row 15)none yet
    8Blocks are mined by GPUs on Apple and NVIDIA
    Homepage live strip; journey phase 3 ("GPU miners on three vendors")
    		tested by the teamrepo 9812466, e9328c6, d7e1f89, 2309c8d; fork devnet-v4Metal worker proto-metal/igneum-bench --serve driven by igneum-miner --worker; the live devnet v4 hash-rate record sim/difficulty/records/live-2026-10-04-hashrate.csv (587 worker STATUS lines by run id); bench-log "first devnet blocks", "devnet v4 cut-over", "difficulty rule v2", "first machine on the Igneum Miner app"Metal: 506 jobs, 5,636 blocks found and accepted, 0 rejected, 0 CPU/GPU mismatches, 28.2 MH/s wall, 3 October 2026. Live devnet v4, 4 October 2026: the three-card Windows rig's RTX 5090 at 122 MH/s with 8 identities, the RTX 5090 Windows rig's at 124 MH/s with 8 identities (117 to 119 MH/s inside the one-click app, 34 accepted blocks in its first minute, CPU re-check OK on every share), the Apple M5 Max's Metal worker at 26.7 MH/s; 17 vote keys signed the first finality lock (row 10); from the afternoon an Apple silicon laptop outside the project at 21.0 MH/s through the app (row 30). Two RTX 5090s and two Apple chips; no other NVIDIA model has minednone yet
    9Blocks are mined by a GPU on AMD
    Journey phase 3 ("three vendors")
    		tested by the teamrepo 2c4b30f (generic OpenCL worker, --pack), 112acf6 (fault guards); bound kernel kernel_bound.cl in the packigneum-worker-opencl.exe --pack on the RTX 5090 Windows rig's integrated Radeon against the live devnet v4 through the Windows package; bench-log "the gfx1036 worker fault", "first hourly program swap", "first machine on the Igneum Miner app"the RTX 5090 Windows rig's integrated gfx1036 (1 compute unit) mined on the live devnet on 4 October 2026: 8 accepted blocks at 3.3 MH/s over 577 s with the CPU re-check clean, and 2.74 MH/s through the hourly program swap with 0 rejected. At about 600 s the AMD runtime began answering every call with success while running nothing (906 jobs became 56,384 in 30 s, 4.3 GH/s of phantom work); not reproduced on Apple OpenCL in 4,565 jobs with 0 leaked objects; the worker and miner now refuse a job 20x faster than the mean or an unchanged output buffer and restart (112acf6), and the next gfx1036 run names the guard that fires. One integrated chip; no discrete AMD card has run anythingnone yet
    10Checkpoints lock every 30 s of chain at two thirds of all 30-day weight, and the floor stops conflicting locks in partitions and eclipses for as long as neither side's own new blocks carry it past two thirds of its window (about 10 days of a 30-day window at a 50/50 split)
    Litepaper Finality, "What Igneum does not claim"; homepage "locked every 30 seconds"
    		tested by the teamrepo a3a9833 (2/3 floor, O-3.15), bbb264a (simulation), c16ccf1; fork devnet-v4 6457ca95 (FLOOR_NUM / FLOOR_DEN 2/3), da1eb889 (F17 by-weight sortition, F1 first-month gate min_daa = window); spec 3.3, 3.3.1, 3.7, 3.9The live devnet v4 (getFinalityCheckpoints, tools/observer/observer.mjs, /api/checkpoint); sim/finality_v2.py --floor 1.0, scenarios A to L; the three-node, six-voter partition runs igneum-devnet-921 to -923; tools/finality-attacks scenarios 1 to 6 and 8; bench-log "first finality lock on the live devnet", "finality floor 2/3", "finality v2 attack harness", "finality fixes F17 and F1"Devnet 3, 7 October 2026: finality rule v3 from block zero, first lock at 19:02 UTC, under two hours after the first block (docs/plans/release-0.3.22.md). The first devnet: the first lock on the live devnet was checkpoint 242 at 11:03:44 UTC on 4 October 2026, two hours after genesis (the window and min_daa are 7,200 DAA), with 77.4% of all weight and of active weight signed by 12 aggregated votes from 17 vote keys; observer.mjs saw it 0.7 s after the miner's own lock line. By 13:21 UTC the observer held 280 certificates, indices 241 to 522 (DAA 7,229 to 17,982), 17 to 27 voters, no index with two hashes. Test networks, 4 October 2026, Apple M5 Max: a 4/2 split locked on the 4 side (67.9%) 2 to 8 s after the cut and never on the 2 side, 0 conflicts; a 3/3 split locked on neither side for 150 s with 0 conflicts, where the 3 October floor (56.7%) would have locked both sides at 76 and 106 s; the rule guarantees one lock history for partitions shorter than the window bound W / (3R) (200 s on that test network's 1,800-DAA window, about 40 minutes on the devnet, about 10 days at the 30-day mainnet window); beyond that bound each side can reach two thirds of its own window, so the next finality rule freezes the weight table at the last certified checkpoint and pauses instead. Simulator with the 2/3 floor: 0 conflicts up to a 33% equivocator (34% splits a 50/50 partition), silent weight pauses locks from 34%, a 50/50 partition locks alone from day 10.1. Harness: equivocating keys stripped on every node, Sybil dust at zero weight, a pulsed miner's weight equal to its block share (ratio 0.96 to 1.0), the first-month gate stops a young window locking under one key. Not demonstrated: certificate injection on the wire, an eclipse with a private fork, the 2-hour presence window at mainnet lengthnone yet
    11Hashrate that arrived today has almost no vote: ten days of the whole network's hashrate to reach a third of the weight, twenty for two thirds; 51% never reaches two thirds while honest miners stay
    Litepaper Finality; homepage firsts
    		tested by the teamrepo bbb264a; sim/finality_v2.pyScenario B of sim/finality_v2.py, seeds 7 and 11share(t) = (t/30) x a/(1+a) holds to 0.04 points; a renter equal to the whole honest network (a = 1) crosses 1/3 on day 20 and never reaches 2/3; a = 9 crosses 1/3 on day 11.1 and 2/3 on day 22.2. The ten-day figure is a = infinity, honest miners gone. 3 October 2026, Apple M5 Max. A model with 1,000 Pareto keys and no DAG; the live devnet's window is two hours old, so the claim has no live measurement yetnone yet
    12The difficulty rule recovers from a hashrate step within minutes, where Kaspa's sampled rule never settles. A step inside an epoch set the rule oscillating on the live devnet on 4 October 2026; rule v2 removes it in the simulator and on a test network and is built but not yet rolled out
    Spec 2.3; litepaper Speed (implied); bench page
    		tested by the teamrepo e9328c6, abb5a5d (attacks), 67bf226 (rule v2); fork difficulty branch (timestamp fix) and devnet-v4 a21ff239 (difficulty_v2_activation_daa, REF_WINDOW_V2 = 600); sim/difficulty/sim.py --liveThe live record sim/difficulty/records/live-2026-10-04.csv (8,090 headers, pull_live.py) and the hash-rate record beside it; sim/difficulty/sim.py on the synthetic set and the DAG replay; sim/difficulty/attacks/attacks.py; sim/difficulty/testnet_v2.py (3 nodes, activation at DAA 900); cargo test --release -p kaspa-consensus --lib difficulty (15 pass); bench-log "difficulty controller", "difficulty rule under attack", "timestamp attack fixed", "difficulty rule v2"Live devnet v4, 4 October 2026 (UTC): a second RTX 5090 joining 7 minutes into an epoch (about 152 to 280 MH/s) hardened the difficulty 70M to 144M in 90 s and then swung by about a third for 40 minutes around the true level of 139M while the epoch-long reference lane carried the join; that card leaving for 4 minutes eased 116M to 67M and back to 106M; the epoch boundary with both PCs restarting took 152M to 77M in 3 minutes, after which the rule held within 1.3% per minute with no flips. Cause: the reference lane covered the whole epoch, so a mid-epoch step polluted it for the hour and the 25% trigger flipped on the short lane's noise. The DAG replay reproduces the record (std of log difficulty 0.115 against 0.134, 4.3 peaks against 4). Rule v2 (reference window 600 DAA) on the replay: std 0.026, 0 flips, mean 142.6M against 139M true; on a 3-node test network the v2 nodes eased a leave with no peak and held a rejoin within 3% after 60 s, and a node without the activation height forked off at it as designed. Rule v2 rolled onto the 12-node cloud network on 4 October (all nodes crossed the height on one chain; a hash-rate step then settled in 160 to 270 s with no swing) and activates on the devnet at DAA 33,000 the same evening. Timestamp forging (ledger M23) fixed the same day: a 50% forger drifts the rate under 1.1% where the 3 October rule gave it a 9.9x difficulty. Simulator, settled seconds: x50 step 62 to 66 (Kaspa 1,542), /50 step 657 to 753 (Kaspa 12,296). Apple M5 Max under load 7 to 442; the DAG model is fitted on one scale; the pool hopper's 0.7-point excess over Kaspa's rule stays opennone yet
    13Every node executes the ordered transactions natively and reaches the same state root
    Litepaper Proving ("Every node executes ... natively"), Building ("runs on Igneum unchanged")
    		tested by the teamrepo f5f8c80, 8dae48b; fork devnet-v4 dc749905; revm 43.0.3node tools/evm-smoke/smoke.mjs against a 3-node igneumd; igneum-exec-diff seq.json; bench-log "execution layer devnet v3" and "devnet-v4 integration"Simnet, 3 October 2026: 87 of 87 viem checks, state roots identical on 3 nodes at four heights, 57 executed and 19 skipped transactions agree with plain revm, 0 mismatches. Merged node on real proof of work, 4 October 2026: 84 of 85 checks (the miss needs parallel blocks the network did not produce in 36 s), 59 transfers in 10 chain blocks, state roots identical on 3 nodes, igneum-exec-diff 0 mismatches over 59 transactions; the live devnet v4 runs this execution layer. Apple M5 Max. The prover is a stub; state is rebuilt from genesis at start; no EVM transaction relay between nodesnone yet
    14Ethereum bytecode runs unchanged, with the documented differences of spec 7.1
    Homepage Build card; litepaper Building
    		tested by the teamas 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 at that version (4464 since the class v5 floor, 8 October 2026); 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 nodenone yet
    15Every 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
    		implementedrepo 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.6proving/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 the RTX 5090 Windows rig in 34 s, verified on the Apple M5 Max 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 onenone yet
    16A 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
    		designedspec 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 cardnone yet
    17The chip resistance claim: at launch the strongest chip in the public model reaches 2.1x (a core as good as a GPU lane, k = 1) to 3.4x (a core three times better, k about 0.33) per joule against an RTX 5090 under class v4, live from genesis on the testnet and the mainnet; the ladder's second rung brings it to about 2.8x; class v5 makes the dataset the chain's state so a stateless or stale chip is wrong on every item; the hot-set cache is bounded at 1.067x at the ceiling and the weak-day FPGA at 12 percent on 15 days a century, both routed to the next class; datacentre silicon does not change the question; a stored-dataset chip pays for itself only at about USD 100 M of market cap in two years; without class v4 the same chip would reach 5x to 9x (the class v3 baseline, the devnet's starting state, never the launch state)
    the home page's chip line, the litepaper's chip section (/litepaper#chip-model), the miner page's line
    		tested by the team (every card, the verifier, the two attack-pass bounds, the H100), the chip itself modelled, class v5 and the ladder designed, the X9 figure claimed against a CPU core and never measureddocs/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/analysis/ca3-v4-uniform.md; docs/design/class-v5-stored-state.md; the H100 and market-cap rows of 7 October; docs/plans/cryptanalysis/in-house-pass.md (the internal adversarial pass)the chip model's arithmetic in its file; the card rows by the benchmark package; the attack-pass harnesses tools/attack/f8-uniform and the F4 census; the verifier by igneum-pow bench136 MH/s at 350 W (5090, bench) and 290 W (app); the class v4 efficiency passes (bench log "7 to 8 October 2026, the class v4 efficiency passes: the core clock lock on the RTX 5090 and the RTX 5080", measured): the 5090 at 136.84 MH/s and 475.5 W unlocked, 134.98 at 316.3 W at a 1,400 MHz core lock, the best points class v4 at 1,200 MHz (133.80 MH/s, 305.1 W, 0.439 MH/W) and class v3 at 1,300 MHz (134.62, 223.3 W, 0.603), the premium 145 W unlocked and 82 W at the best points, the knee 1,300 MHz; the RTX 5080 (8 October 2026, the dock card of the three-card Windows rig) at 71.41 MH/s and 253.1 W unlocked under class v4 against 71.28 at 169.7 W under class v3, the best points class v4 at 1,100 MHz (71.20 MH/s, 146.6 W, 0.486 MH/W) and class v3 at 1,000 MHz (71.11, 103.7 W, 0.686), the premium 83.4 W unlocked and 41 W at the best points, the knee between 1,000 and 900 MHz; per tier: a 5080 owner on class v4 locked near 1,100 MHz pays 147 W instead of 253 for 0.3 percent less rate, MH per watt up 72 percent, the lever Ember Tune's core-clock knob in 0.3.24; 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; 2.1x, 3.4x, 2.8x at launch; the shadow's premium on a 5090 81.8 W at its knee (class v4 at the 1,200 MHz lock 133.80 MH/s at 305.1 W; class v3 at 1,300 MHz 134.62 at 223.3 W; 7 October 2026); 1.067x at the ceiling; 12 percent on 15 days a century; 10.85 ms at rung 3; USD 100 M; 5.1x to 9.2x the class v3 baseline; 6 and 7 October 2026, the M5 Max, the RTX 5090 Windows rig's RTX 5090, the three-card Windows rig's RX 9070 XT and RTX 4070, a rented H100 SXM, igneum-build-1 The k about 0.33 bound is the implied core of Bitmain's Antminer X9 (RandomX; 1,000 KH/s, 2,472 W, 2.47 J per KH, USD 5,600; pre-orders 26 December 2025), withdrawn in mid-May 2026 with buyers refunded before any unit shipped, no independent benchmark, commodity Sophgo SG2044 server SoCs with an AES accelerator, no tapeout: a claimed, unmeasured figure carried as the pessimistic bound, not a calibration point (attack pass AP-F5-1, 7 October 2026).none yet; the next test is the internal adversarial pass (three lanes new to the hash code, outsider inputs only, reports published whole), whose floor reading is in (measured, 8 October 2026; ledger AP-F8-1 and AP-F8-6): nine of nine hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test, and no outside review has run yet
    18The chip resistance measurements: the program is latency-bound (dependent reads spread over the whole dataset), not bandwidth-bound, on every card we own, and sits beyond a card's on-chip cache; measured 8 October 2026: the distinct-index floor holds at 0.995 on every accepted program, about half of epochs carry one load site with a biased address bit at the era's stride rotation, priced at about 1.6 percent of a hash's reads to a chip storing half the dataset and nothing to one storing all of it (docs/analysis/class-v6/family-gate.md, lane D; adv-cache-2's report-chained-cache-2.md section 2.3 on its branch; ledger AP-F8-7)
    Litepaper Mining ("waits on memory latency, not on maths or bandwidth"), vs RandomX; the numbers page
    		tested by the teamreadwidth 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 loadLatency-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 2026none yet
    19The 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 teamca2-mixer 1ab8b21 (tests/mixer.rs, tests/scratch.rs), ca2-era 78c0ee4, ca2-soundness a465881 (docs/analysis/scratch-soundness.md), igneum-pow/tests/packs.rsThe 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 cardClass 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 (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) 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
    17The chip resistance claim, served as the class v6 close words it, the claim statement above the sentence: Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes. Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment. Beside it: class v4 is live from the first block on the testnet and the mainnet; class v5 makes the dataset the chain's state so a stateless or stale chip is wrong on every item; the hot-set cache is bounded at 1.067x at the ceiling and the weak-day FPGA at 12 percent on 15 days a century, both routed to the next class; datacentre silicon does not change the question; the three statements (energy resistance, economic resistance, response capability) are served separate, with the harness and the scoring rule linked
    the home page's chip line, the litepaper's chip section (/litepaper#chip-model), the miner page's line
    		the GPU side tested by the team (the RTX 5080 and RTX 5090 clock-lock passes under class v4, every card, the verifier, the two attack-pass bounds, the H100); the chip core synthesised on ASAP7 and scaled to N3, claimed; the chip's memory modelled; the node column claimed scaling; the economic surface modelled, first cut, conditional; the rotation schedule measured per boundary; class v5 designed; the Antminer X5 an observed comparison, not a ceiling; the X9 a withdrawn pre-order, never benchmarkeddocs/design/class-v6-rotating-family.md section 10 (10.0 to 10.0h, the close and its two accepted external reviews, 8 October 2026); docs/design/class-v5-stored-state.md sections 0, 13 and 14 and docs/design/class-v5-harness/ (branch class-v5); docs/design/class-rotation-four-layers.md; docs/analysis/chip-model-v3.md 5 and 6; docs/analysis/latency-shadow-2026-10-06.md; docs/analysis/attack-pass/f8-uniform.md, f4-weakday.md, docs/analysis/ca3-v4-uniform.md; the H100 row of 7 October; docs/plans/cryptanalysis/in-house-pass.md (the internal adversarial pass)the scoring rule in the close (the minimum over workloads of the maximum over free adversarial designs of the GPU's joules per hash over the adversary's, under the 10 percent GPU-cost budget at the lock, the verifier limit, cross-vendor correctness and hardware accessibility); the card rows by the benchmark package; the class v5 harness and the family harness; the attack-pass harnesses tools/attack/f8-uniform and the F4 census; the verifier by igneum-pow bench136 MH/s at 350 W (5090, bench) and 290 W (app); the class v4 efficiency passes (bench log "7 to 8 October 2026, the class v4 efficiency passes: the core clock lock on the RTX 5090 and the RTX 5080", measured): the 5090 at 136.84 MH/s and 475.5 W unlocked, 134.98 at 316.3 W at a 1,400 MHz core lock, the best points class v4 at 1,200 MHz (133.80 MH/s, 305.1 W, 0.439 MH/W) and class v3 at 1,300 MHz (134.62, 223.3 W, 0.603), the premium 145 W unlocked and 82 W at the best points, the knee 1,300 MHz; the RTX 5080 (8 October 2026, the dock card of the three-card Windows rig) at 71.41 MH/s and 253.1 W unlocked under class v4 against 71.28 at 169.7 W under class v3, the best points class v4 at 1,100 MHz (71.20 MH/s, 146.6 W, 0.486 MH/W) and class v3 at 1,000 MHz (71.11, 103.7 W, 0.686), the premium 83.4 W unlocked and 41 W at the best points, the knee between 1,000 and 900 MHz; per tier: a 5080 owner on class v4 locked near 1,100 MHz pays 147 W instead of 253 for 0.3 percent less rate, MH per watt up 72 percent, the lever Ember Tune's core-clock knob in 0.3.24; 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; the GPU side of the close: the RTX 5080 at its 1,100 MHz lock 2.06 microjoules per hash and the RTX 5090 at its 1,300 MHz lock 2.33 (class v4, 8 October 2026); the modelled bracket about 2.3x to 3.3x a node ahead and 2.0x to 2.9x node for node (approximate, provisional; the clock-gated base core k about 0.37 at N3, the gated window adding about 0.13; the first placed core 64 percent above synthesis), the placed gated row expected near 2.6x to 3.1x and 2.3x to 2.7x and served when it lands; the shadow's premium on a 5090 81.8 W at its knee (class v4 at the 1,200 MHz lock 133.80 MH/s at 305.1 W; class v3 at 1,300 MHz 134.62 at 223.3 W; 7 October 2026); 1.067x at the ceiling; 12 percent on 15 days a century; 10.85 ms at rung 3; 6 to 8 October 2026, the M5 Max, the desk rigs' RTX 5090, RTX 5080, RX 9070 XT and RTX 4070, rented pods, a rented H100 SXM, igneum-build-1 Bitmain's Antminer X9 (RandomX; 1,000 KH/s, 2,472 W, 2.47 J per KH, USD 5,600; pre-orders 26 December 2025) was withdrawn in mid-May 2026 with buyers refunded before any unit shipped, no independent benchmark, commodity Sophgo SG2044 server SoCs with an AES accelerator, no tapeout: it is a precedent on the served pages, not a chip core against the model (attack pass AP-F5-1, 7 October 2026; the close's 10.0f, 8 October 2026). Withdrawn from the served pages on 8 October 2026 and not restated: the 2.1x and 3.4x launch line, the 5x to 9x class v3 baseline, the ladder's 2.8x row, the USD 100 M pay-back row, any chip-arrival probability, the lifetime claim and the USD 300 M and 340 M lines.none yet; the next test is the internal adversarial pass (three lanes new to the hash code, outsider inputs only, reports published whole), whose floor reading is in (measured, 8 October 2026; ledger AP-F8-1 and AP-F8-6): nine of nine hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test, and no outside review has run yet
    18The chip resistance measurements: the program is latency-bound (dependent reads spread over the whole dataset), not bandwidth-bound, on every card we own, and sits beyond a card's on-chip cache; measured 8 October 2026: the distinct-index floor holds at 0.995 on every accepted program, about half of epochs carry one load site with a biased address bit at the era's stride rotation, priced at about 1.6 percent of a hash's reads to a chip storing half the dataset and nothing to one storing all of it (docs/analysis/class-v6/family-gate.md, lane D; adv-cache-2's report-chained-cache-2.md section 2.3 on its branch; ledger AP-F8-7)
    Litepaper Mining ("waits on memory latency, not on maths or bandwidth"), vs RandomX; the numbers page
    		tested by the teamreadwidth 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 loadLatency-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 2026none yet
    19The 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 teamca2-mixer 1ab8b21 (tests/mixer.rs, tests/scratch.rs), ca2-era 78c0ee4, ca2-soundness a465881 (docs/analysis/scratch-soundness.md), igneum-pow/tests/packs.rsThe 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 cardClass 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 (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) 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
    20No 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
    		implementedrepo 6ac80a3; fork "igneum-node devnet v0"; consensus/core/src/igneum.rs, coinbase.rscargo 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 happenednone yet
    21The proving pool's 20% reaches shard provers and aggregators
    Litepaper Economics; homepage "20% provers"
    		tested by the teamspec 5.3; proving/igneum-prove carries the prover's payout address in every shard proof (ledger P12)None. The pool output exists (row 20); the payout from it against proof records is unwritten. Since 5 October 2026: the payout rule is live on the devnet (proving.rs shard_payouts, the carrying segment pays the first valid record per shard its part of the segment's pool credit)The escrow accumulated on the simnet (92.55 IGN at the end of the v3 run) and nothing can draw it. Rule decided: per block, divided among shards by consensus proving cost, sortition to 8 provers for 10 s then open (spec 7.2). The economy model of 4 October 2026 (sim/economy, 1,000 operators, 30 days) kept every block proven within 60 s under six stress scenarios; a model, not hardware Live devnet, 5 October 2026: 388 shards paid by 16:02 UTC, 446.13 IGN from the pool to the RTX 5090 Windows rig's payout address, 0.8813 IGN per mergeset block of the proven segment (bench-log entries of 5 October: "the first shards proven, verified and paid" and "real transactions, the first non-empty shard proven and paid")none yet
    22The base fee is burned in full and the priority fee splits 80% to the miner and provers, 20% to the apps whose code ran
    Homepage Economics caption and Build card; litepaper "Where fees go"
    		tested by the teamrepo f5f8c80; fork worktree vendor/igneum-node-exectools/evm-smoke/smoke.mjs receipt checks; bench-log "execution layer devnet v3"Transfer receipt: burnedProvingFee 200 gwei, minerTip 16,800 gwei (80%), unregistered developer share 4,200 gwei burned; contract call: 80% to the miner, 20% credited to the payee the constructor registered, balance delta equal. 3 October 2026, Apple M5 Max simnet. The provers' part of the 80% is not split out (no provers exist); the base fee stayed at the 1 gwei floor throughoutnone yet
    21The proving pool's 20% reaches shard provers and aggregators
    Litepaper Economics; homepage "20% provers"
    		tested by the teamspec 5.3; proving/igneum-prove carries the prover's payout address in every shard proof (ledger P12)None. The pool output exists (row 20); the payout from it against proof records is unwritten. Since 5 October 2026: the payout rule is live on the devnet (proving.rs shard_payouts, the carrying segment pays the first valid record per shard its part of the segment's pool credit)The escrow accumulated on the simnet (92.55 IGN at the end of the v3 run) and nothing can draw it. Rule decided: per block, divided among shards by consensus proving cost, sortition to 8 provers for 10 s then open (spec 7.2). The economy model of 4 October 2026 (sim/economy, 1,000 operators, 30 days) kept every block proven within 60 s under six stress scenarios; a model, not hardware Live devnet, 5 October 2026: 388 shards paid by 16:02 UTC, 446.13 IGN from the pool to the RTX 5090 Windows rig's payout address, 0.8813 IGN per mergeset block of the proven segment (bench-log entries of 5 October: "the first shards proven, verified and paid" and "real transactions, the first non-empty shard proven and paid")none yet
    22The base fee is burned in full and the priority fee splits 80% to the miner and provers, 20% to the apps whose code ran
    Homepage Economics caption and Build card; litepaper "Where fees go"
    		tested by the teamrepo f5f8c80; fork worktree vendor/igneum-node-exectools/evm-smoke/smoke.mjs receipt checks; bench-log "execution layer devnet v3"Transfer receipt: burnedProvingFee 200 gwei, minerTip 16,800 gwei (80%), unregistered developer share 4,200 gwei burned; contract call: 80% to the miner, 20% credited to the payee the constructor registered, balance delta equal. 3 October 2026, Apple M5 Max simnet. The provers' part of the 80% is not split out (no provers exist); the base fee stayed at the 1 gwei floor throughoutnone yet
    23No fee to any team, foundation or fund; 0 admin keys in consensus
    Homepage Economics tiles and caption; litepaper "No fund, no foundation" and Governance
    		designedspec 5.5, 5.6 (decided 3 October 2026); spec 08Reading: no coinbase output, fee route or consensus key in the fork names any party (coinbase.rs, docs/fork-divergence.md)The emission code has two outputs (row 20) and the fee code has three routes (row 22), none to a team. The 1% fee of the official client is a client setting, not a protocol rule, and is not implemented. The release key of spec 08 signs client updates (the Igneum Miner app's over-the-air manifest since 4 October 2026, Ed25519) and holds no consensus power; its custody policy is open (O-8.1)none yet
    24External proving jobs pay 90% to the provers who delivered and burn 10%, once settled in IGN
    Homepage "IGN burned from jobs, phase two"; litepaper Proving and Economics
    		designedspec 5.4None. Needs the proof bridge (spec 7.3, phase two) and the settlement switch (O-5.2)At launch jobs are paid on the customer's chain in the customer's currency and nothing is burned (ledger P10). No job market code existsnone yet
    25The 4 billion cap, halving every two years, with a 30-day ramp from 10%
    Homepage "4B IGN hard cap"; litepaper Supply and the emission chart
    		tested by the teamrepo 6ac80a3; fork consensus/core/src/igneum.rscargo test -p kaspa-consensus-core igneum; bench-log "igneum-node devnet v0"Ramp day 0 paid 10.03% of the full rate (317,767,704 units at DAA 806); the schedule table and the cap assert in the crate's own tests. 3 October 2026, Apple M5 Max. Base unit (8 or 18 decimals) is open (O-2.6); the spec was changed to follow the code's 365.25-day year (ledger E9) and a test that reads the published numbers back is still owednone yet
    25The 4 billion cap, halving every two years, with a 30-day ramp from 10%
    Homepage "4B IGN hard cap"; litepaper Supply and the emission chart
    		tested by the teamrepo 6ac80a3; fork consensus/core/src/igneum.rscargo test -p kaspa-consensus-core igneum; bench-log "igneum-node devnet v0"Ramp day 0 paid 10.03% of the full rate (317,767,704 units at DAA 806); the schedule table and the cap assert in the crate's own tests. 3 October 2026, Apple M5 Max. Base unit (8 or 18 decimals) is open (O-2.6); the spec was changed to follow the code's 365.25-day year (ledger E9) and a test that reads the published numbers back is still owednone yet
    26A phone or browser verifies the chain from a locked checkpoint, at about 3.44 MB per day in checkpoint mode
    Homepage "Browser checks Igneum" card; litepaper Building ("Light clients"), firsts row 6
    		designedspec 10 (10.5 bytes per day: 3.44 MB at 1,000 voters, 6.68 MB at 10,000, derived, approximate); repo f874f80 for the browser card; site/api/checkpoint.mjsNone for the byte figure; site/verify/ for the card against /api/checkpoint. BLS verification on a phone and in WebAssembly is O-10.3; the full-header mode on a phone is O-10.4Since 11:03 UTC on 4 October 2026 the homepage card verifies the live devnet's own certificates in the tab (index 522 with 27 voters at 13:42 UTC), BLS aggregate against the voter list the node serves, light client v0; before that it verified the 3 October test network's. The byte figure is arithmetic on designed sizes (header 400 bytes, proof 400 bytes), measured nowhere; the execution proof the card would also check is not on the chain (row 15)none yet
    27The node survives malformed input, floods, withholding, partitions and eclipses
    Litepaper Speed ("GHOSTDAG, the BlockDAG consensus proven on Kaspa"); spec 2
    		tested by the teamrepo 394030c, 8dae48b, 6b5bd92; fork worktree vendor/igneum-node-harness and devnet-v4; tools/harness/; infra/cloud-devnet/experiments/partition.shtools/harness/ against a private igneumd test network; the merged node's harness scenarios 2 and 5; the cloud network's 10-minute partition of Singapore (results/2026-10-04/partition-sin-20261004-110906/partition.md); bench-log "consensus attack harness", "devnet-v4 integration"3 October 2026, Apple M5 Max: 63 malformed cases, node up on every one; withholding at 10% to 45% within 2 sigma of share; partitions of 120 s to 3,700 s healed to one chain in 10 s; eclipse victims rejoined in 10 s; 50x floods left template p95 under 4 ms; one FAIL, a 45% withholder releasing every 20 blocks took 50.7% of blues (bound 47.4%). Merged node, 4 October 2026: 63 cases, node up, 0 cache builds; the 10 s timestamp floor and future bound exact. Cloud network, 4 October 2026: 12 nodes in five locations on their own chain, Singapore cut off by iptables for 10 minutes; the two minority nodes adopted the majority chain 10 and 14 s after the heal with reorgs of 445 and 516 blocks, the majority's deepest reorg was 2 blocks, 0 conflicting locks (none were possible: the weight window stood at DAA 3,030 of 7,200). CPU miners only; the finality rules under partition are row 10none yet
    28Headers are validated cheaply before the lottery engine runs, so forged timestamps cannot force 256 MiB cache builds
    Spec 2.4; ledger M15
    		tested by the teamrepo 0953ec7, 8dae48b; fork worktree vendor/igneum-node-r3 branch r3-fixes at 5166ee26, merged into devnet-v4measure_m15_attack_before_and_after (ignored test, release, --features igneum-pow); kaspa-pow 8, header_processor 1, p2p pow_guard 2 tests; harness scenario 5 on the merged node50 forged headers: before, 50 cold builds in 10,595 ms and the live day evicted; after, 0 builds, all 50 rejected in 14 ms, 3 October 2026, Apple M5 Max under load 60 to 110. Merged node, 4 October 2026: 63 harness cases with 0 cache builds (the node log shows one build, the honest day) and the M15 p2p cases disconnected by the strike guard; the live devnet v4 runs it. Measured through the validate path with skip_proof_of_work, not the daemon RPCnone yet
    29Blocks reach every node well inside GHOSTDAG's delay bound across continents
    Litepaper Speed (GHOSTDAG at one block a second); spec 03 C1 (lock latency); infra/cloud-devnet/README.md
    		tested by the teamrepo 6b5bd92; infra/cloud-devnet/experiments/latency.sh, analyze.py; the Linux cross-build infra/cross/build-linux.sh12 igneumd nodes on cloud VMs in Helsinki, Falkenstein, Ashburn, Hillsboro and Singapore (own chain igneum-devnet-20, one CPU trickle miner each), a ping matrix, then 10 minutes of per-node arrival logs joined on block hash; results/2026-10-04/latency/propagation.md and rtt-by-region.md644 blocks in the window, 642 seen by at least 80% of nodes; arrival at a node minus the first arrival anywhere: p50 343 ms, p90 497 ms, p99 666 ms, max 2,313 ms; by region p50 239 ms (Falkenstein) to 413 ms (Singapore), p90 455 to 632 ms; inter-region RTT 35 ms (Helsinki to Falkenstein) to 289 ms (Ashburn to Singapore); first arrival minus header time median 490 ms. 4 October 2026. The network is the project's own: 12 nodes not 20 (a new account's limits), CPU hash rate only, clocks by chrony, one evening of data; the 5 s bound behind GHOSTDAG k is a design parameter this run did not challengenone yet
    30One click: install, press start, the card mines; the app looks after its node
    Homepage Mine section ("One click: install, press start"); litepaper "One click, for everyone else"; journey phase 5
    		tested by the teamrepo 3bb50d6, 2c4b30f, 6461540 (package 0.3.0: prebuilt NVRTC CUDA worker and generic OpenCL worker, driver only), a1a33cb, 7c794df, 0d4498e, 6c083db (Igneum Miner 0.3.0), 78903cd (0.3.1, over-the-air updates)Igneum-Miner-Setup-0.3.0.exe (runner-built, unsigned) on a an RTX 5090 on Windows with an RTX 5090 and no toolchain; proto-cuda/nvrtc/emu/serve-check.sh on the Apple M5 Max; proto-cuda/windows-app/TEST.md; bench-log "one-click Windows workers", "first machine on the Igneum Miner app", "a node 60 s behind the clock is silently dead", "the gfx1036 worker fault"Four machines by 14:45 UTC on 4 October 2026: the RTX 5090 Windows rig, then the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) (RTX 5090 at 110 MH/s under the 80% power cap), the project's Apple M5 Max (25 MH/s) and the outside Apple silicon laptop (row 29), all on Igneum Miner 0.3.1. The NVRTC worker compiled the pack on the card with no toolchain installed and mined at 124.2 MH/s, equal to the nvcc-built worker, 0 rejected, CPU re-check clean; inside the app 117 to 119 MH/s with 34 accepted blocks in the first minute, the integrated AMD chip at 3.3 MH/s beside it (row 9). Two defects found by the install, both fixed the same hour: a clock 62 s slow after a power cut made the node reject every relayed block for 12 minutes with no visible reason (the app now reads the skew from the node's warnings, the block timestamps over the EVM RPC and an HTTPS Date header, warns over 5 s and blocks Start over 10 s, with a one-click clock sync; checked on the Apple M5 Max with a fake 60 s skew; a one-line node warning is filed), and the node card said "syncing" while the miner was already accepted. The Mac could only emulate the NVIDIA path (17 of 17 sampled hashes) and the AMD path on Apple OpenCL (15 of 15). Over-the-air updates were dry-run on a private devnet (0.3.0 to 0.3.1 and back), not on a user's machine. The installer is unsigned (SmartScreen "run anyway"). Second machine, the same afternoon: a friend of the project installed Igneum Miner 0.3.1 from the DMG on an Apple silicon laptop with no toolchain and no instructions beyond five steps; the node synced from the seed, the Metal worker reported ready, 33 accepted blocks and 0 rejected in 7 minutes at 21.0 MH/s average, CPU re-check OK on every share, uploads arriving every minute under its per-install id. That laptop is not the project's hardware, but the result is observed through the project's own log intake and reported by the project, so it stays tested by the team until an outsider publishes a run of their own. The devnet's other GPU machines (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) and the Apple M5 Max) run the same workers through the launcher, not the appnone yet
    27The node survives malformed input, floods, withholding, partitions and eclipses
    Litepaper Speed ("GHOSTDAG, the BlockDAG consensus proven on Kaspa"); spec 2
    		tested by the teamrepo 394030c, 8dae48b, 6b5bd92; fork worktree vendor/igneum-node-harness and devnet-v4; tools/harness/; infra/cloud-devnet/experiments/partition.shtools/harness/ against a private igneumd test network; the merged node's harness scenarios 2 and 5; the cloud network's 10-minute partition of Singapore (results/2026-10-04/partition-sin-20261004-110906/partition.md); bench-log "consensus attack harness", "devnet-v4 integration"3 October 2026, Apple M5 Max: 63 malformed cases, node up on every one; withholding at 10% to 45% within 2 sigma of share; partitions of 120 s to 3,700 s healed to one chain in 10 s; eclipse victims rejoined in 10 s; 50x floods left template p95 under 4 ms; one FAIL, a 45% withholder releasing every 20 blocks took 50.7% of blues (bound 47.4%). Merged node, 4 October 2026: 63 cases, node up, 0 cache builds; the 10 s timestamp floor and future bound exact. Cloud network, 4 October 2026: 12 nodes in five locations on their own chain, Singapore cut off by iptables for 10 minutes; the two minority nodes adopted the majority chain 10 and 14 s after the heal with reorgs of 445 and 516 blocks, the majority's deepest reorg was 2 blocks, 0 conflicting locks (none were possible: the weight window stood at DAA 3,030 of 7,200). CPU miners only; the finality rules under partition are row 10none yet
    28Headers are validated cheaply before the lottery engine runs, so forged timestamps cannot force 256 MiB cache builds
    Spec 2.4; ledger M15
    		tested by the teamrepo 0953ec7, 8dae48b; fork worktree vendor/igneum-node-r3 branch r3-fixes at 5166ee26, merged into devnet-v4measure_m15_attack_before_and_after (ignored test, release, --features igneum-pow); kaspa-pow 8, header_processor 1, p2p pow_guard 2 tests; harness scenario 5 on the merged node50 forged headers: before, 50 cold builds in 10,595 ms and the live day evicted; after, 0 builds, all 50 rejected in 14 ms, 3 October 2026, Apple M5 Max under load 60 to 110. Merged node, 4 October 2026: 63 harness cases with 0 cache builds (the node log shows one build, the honest day) and the M15 p2p cases disconnected by the strike guard; the live devnet v4 runs it. Measured through the validate path with skip_proof_of_work, not the daemon RPCnone yet
    29Blocks reach every node well inside GHOSTDAG's delay bound across continents
    Litepaper Speed (GHOSTDAG at one block a second); spec 03 C1 (lock latency); infra/cloud-devnet/README.md
    		tested by the teamrepo 6b5bd92; infra/cloud-devnet/experiments/latency.sh, analyze.py; the Linux cross-build infra/cross/build-linux.sh12 igneumd nodes on cloud VMs in Helsinki, Falkenstein, Ashburn, Hillsboro and Singapore (own chain igneum-devnet-20, one CPU trickle miner each), a ping matrix, then 10 minutes of per-node arrival logs joined on block hash; results/2026-10-04/latency/propagation.md and rtt-by-region.md644 blocks in the window, 642 seen by at least 80% of nodes; arrival at a node minus the first arrival anywhere: p50 343 ms, p90 497 ms, p99 666 ms, max 2,313 ms; by region p50 239 ms (Falkenstein) to 413 ms (Singapore), p90 455 to 632 ms; inter-region RTT 35 ms (Helsinki to Falkenstein) to 289 ms (Ashburn to Singapore); first arrival minus header time median 490 ms. 4 October 2026. The network is the project's own: 12 nodes not 20 (a new account's limits), CPU hash rate only, clocks by chrony, one evening of data; the 5 s bound behind GHOSTDAG k is a design parameter this run did not challengenone yet
    30One click: install, press start, the card mines; the app looks after its node
    Homepage Mine section ("One click: install, press start"); litepaper "One click, for everyone else"; journey phase 5
    		tested by the teamrepo 3bb50d6, 2c4b30f, 6461540 (package 0.3.0: prebuilt NVRTC CUDA worker and generic OpenCL worker, driver only), a1a33cb, 7c794df, 0d4498e, 6c083db (Igneum Miner 0.3.0), 78903cd (0.3.1, over-the-air updates)Igneum-Miner-Setup-0.3.0.exe (runner-built, unsigned) on a an RTX 5090 on Windows with an RTX 5090 and no toolchain; proto-cuda/nvrtc/emu/serve-check.sh on the Apple M5 Max; proto-cuda/windows-app/TEST.md; bench-log "one-click Windows workers", "first machine on the Igneum Miner app", "a node 60 s behind the clock is silently dead", "the gfx1036 worker fault"Four machines by 14:45 UTC on 4 October 2026: the RTX 5090 Windows rig, then the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) (RTX 5090 at 110 MH/s under the 80% power cap), the project's Apple M5 Max (25 MH/s) and the outside Apple silicon laptop (row 29), all on Igneum Miner 0.3.1. The NVRTC worker compiled the pack on the card with no toolchain installed and mined at 124.2 MH/s, equal to the nvcc-built worker, 0 rejected, CPU re-check clean; inside the app 117 to 119 MH/s with 34 accepted blocks in the first minute, the integrated AMD chip at 3.3 MH/s beside it (row 9). Two defects found by the install, both fixed the same hour: a clock 62 s slow after a power cut made the node reject every relayed block for 12 minutes with no visible reason (the app now reads the skew from the node's warnings, the block timestamps over the EVM RPC and an HTTPS Date header, warns over 5 s and blocks Start over 10 s, with a one-click clock sync; checked on the Apple M5 Max with a fake 60 s skew; a one-line node warning is filed), and the node card said "syncing" while the miner was already accepted. The Mac could only emulate the NVIDIA path (17 of 17 sampled hashes) and the AMD path on Apple OpenCL (15 of 15). Over-the-air updates were dry-run on a private devnet (0.3.0 to 0.3.1 and back), not on a user's machine. The installer is unsigned (SmartScreen "run anyway"). Second machine, the same afternoon: a friend of the project installed Igneum Miner 0.3.1 from the DMG on an Apple silicon laptop with no toolchain and no instructions beyond five steps; the node synced from the seed, the Metal worker reported ready, 33 accepted blocks and 0 rejected in 7 minutes at 21.0 MH/s average, CPU re-check OK on every share, uploads arriving every minute under its per-install id. That laptop is not the project's hardware, but the result is observed through the project's own log intake and reported by the project, so it stays tested by the team until an outsider publishes a run of their own. The devnet's other GPU machines (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) and the Apple M5 Max) run the same workers through the launcher, not the appnone yet
    31Card lifetime: a 4 GB card mines about four years and an 8 GB card about twelve, under the dataset's step schedule (2 GB at genesis, doubling at years 4, 12, 28, 60) with the cache freed after the daily build
    Litepaper Hardware and vs RandomX ("Dataset" row); homepage Mine card and "Memory" row
    		designeddocs/analysis/card-lifetime-2026-10-05.md (branch card-lifetime 1fecfe2); spec 1.13.3 option (b) recommended to the owner 5 October 2026 (docs/plans/counter-asic-2-rollout.md 6c)The per-tier working-set arithmetic of that document (GTX 1650, RTX 3050, RTX 3060, RTX 4090 tiers) against the step scheduleA design claim: under the continuous mapping (a) a 4 GB card is out within 1 to 1.5 years and an 8 GB card at 6 to 7.5 years, so the sentence is true only under the step schedule (b), which the spec has not yet fixed (O-1.13)none yet
    -

    Click a column heading to sort; click again to reverse. Versions: igneum-pow is the Rust crate at version 0.2.0 (generator version 2, 4 October 2026); repo commits are this repository's; fork commits are the node fork and its worktrees, named by message as the engineering log names them. Source of every number: the engineering log. The source of this page is docs/evidence.md in the repository.

    +

    Click a column heading to sort; click again to reverse. Versions: igneum-pow is the Rust crate at version 0.2.0 (generator version 2, 4 October 2026); Devnet 3 runs node f8da7515 on release-0.3.25-node with igneum-pow 1c420786, chain id 4464 since its class v5 floor (4463 from genesis), read 8 October 2026, 15:50 UK; the current state, machine-readable, is the release manifest, which fills these at build time. The labels stay distinct: a claim never moves up a label without the artefact the next table names. The public reference repository exists now (the specifications, the pow crate, the simulators and the test material, at git.igneum.network); the full node, the miner and the proving code open later, so a row that cites them is tested by the team until they do. Repo commits are this repository's; fork commits are the node fork and its worktrees, named by message as the engineering log names them. Source of every number: the engineering log. The source of this page is docs/evidence.md in the repository.

    What would move a row

    + - +
    FromToWhat it takes
    designedimplementedCode in this repository with test vectors that pass
    implementedactivatedA node’s own start line on a named chain naming the rule and its activation height
    implementedtested by the teamA bench-log entry with the machine, the date, the command and the number
    tested by the teamreproduced externallyThe command published, and a third party's run with the same result, linked from the row
    tested by the teamreproduced externallyThe code the row names public in the reference repository (the specifications, the pow crate, the simulators and the test material are; the node, the miner and the proving code open later), the command published, and a third party’s run with the same result, linked from the row
    reproduced externallyreviewed independentlyA named reviewer's published finding on that version. Funding for review is docs/plans/funding.md
    anythe row's status falls backA new version of the code or rule the row names
    diff --git a/site/index.html b/site/index.html index de54eef65..803359de4 100644 --- a/site/index.html +++ b/site/index.html @@ -265,7 +265,7 @@
    01
    The same card finds the block and proves it.

    Both jobs pay. When you stop, the card still games.

    02
    A fair start.

    Nobody holds a coin before block one. 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.

    -
    03
    Built for graphics cards.

    At launch the strongest chip in our public model reaches 2.1x per joule against an RTX 5090 with a core as good as a GPU lane, 3.4x with one three times better, under class v4 from the first block; a 5090 locked at its knee pays 82 W for that shadow work. Class v5 then makes the dataset the chain’s own state, so a chip that stores it or recomputes it is wrong on every item. Without class v4 the same chip would reach 5x to 9x. The model and every measurement are public.

    +
    03
    Built for graphics cards.

    Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes. Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment. Modelled on measured cards (8 October 2026), the chip core synthesised, claimed and awaiting its placed row; a 5090 locked at its knee pays 82 W for the class v4 shadow work (measured, 7 October 2026). Every number with its label, the harness and the scoring rules.

    diff --git a/site/lc/core.js b/site/lc/core.js index 8f9a3c390..7e2541584 100644 --- a/site/lc/core.js +++ b/site/lc/core.js @@ -265,7 +265,7 @@ export function verifyBalance(cp, proof, deps) { const step = (name, fn) => { try { const d = fn(); steps.push({ name, ok: true, detail: d }); return d; } catch (e) { steps.push({ name, ok: false, detail: String(e.message || e) }); throw e; } }; const done = extra => ({ ...extra, steps, ms: Math.round((now() - t0) * 10) / 10 }); try { - const cert = step('certificate: BLS aggregate over the checkpoint, 2/3 of active and 17/30 of total weight', () => { + const cert = step('certificate: BLS aggregate over the checkpoint, 2/3 of active and 2/3 of total weight', () => { const r = verifyCheckpoint(cp, { blake2b, bls }); if (!r.verified) throw new Error(r.reason); return `checkpoint ${r.index}, ${r.signers} of ${r.voters} voters, ${(r.weight_fraction_total * 100).toFixed(1)}% of total weight, ${r.headers_checked} headers to the previous lock`; @@ -338,7 +338,7 @@ export function verifyReceipt(receipt, deps) { const done = extra => ({ ...extra, steps, ms: Math.round((now() - t0) * 10) / 10 }); try { const cp = receipt.checkpoint.certificate; - const cert = step('certificate: BLS aggregate over the checkpoint, 2/3 of active and 17/30 of total weight', () => { + const cert = step('certificate: BLS aggregate over the checkpoint, 2/3 of active and 2/3 of total weight', () => { const r = verifyCheckpoint(cp, { blake2b, bls }); if (!r.verified) throw new Error(r.reason); if (strip(cp.hash) !== strip(receipt.checkpoint.hash) || receipt.chain_id !== cp.chain_id) throw new Error('the receipt names another checkpoint or chain than its certificate'); diff --git a/site/lc/verify-receipt.js b/site/lc/verify-receipt.js index 1b2d9e03e..c91c0c46c 100644 --- a/site/lc/verify-receipt.js +++ b/site/lc/verify-receipt.js @@ -5390,7 +5390,7 @@ function verifyReceipt(receipt2, deps2) { const done = (extra) => ({ ...extra, steps, ms: Math.round((now() - t0) * 10) / 10 }); try { const cp = receipt2.checkpoint.certificate; - const cert = step("certificate: BLS aggregate over the checkpoint, 2/3 of active and 17/30 of total weight", () => { + const cert = step("certificate: BLS aggregate over the checkpoint, 2/3 of active and 2/3 of total weight", () => { const r2 = verifyCheckpoint(cp, { blake2b: blake2b2, bls: bls2 }); if (!r2.verified) throw new Error(r2.reason); if (strip(cp.hash) !== strip(receipt2.checkpoint.hash) || receipt2.chain_id !== cp.chain_id) throw new Error("the receipt names another checkpoint or chain than its certificate"); diff --git a/site/ledger.html b/site/ledger.html index f9ead22c1..c75bffb9b 100644 --- a/site/ledger.html +++ b/site/ledger.html @@ -1383,15 +1383,15 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
    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
+
X35

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

8 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; restated 7 October 2026, evening, by order of the coordinator; the chip-text rewrite e57da45a, on master at 25f38035): the served texts give the floor and the premium at the 5090's measured knee: 2.1x per joule with a core as good as a GPU lane (k = 1), 3.4x with one three times better (k about 0.33), no core below about 1.8 pJ per op in the model's range, the premium 81.8 W at the best points, Ember Tune named as how a user gets there; the ledger pin for X35 moved to the new sentence; a repository file#chip-model and the home line.
+
Fixed, stated; restated 8 October 2026, afternoon, by order of main after two accepted external reviews of the class v6 close; a repository file 10.0f to 10.0h): the served chip text is the third review's claim statement ("Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes.") above the review's sentence, both verbatim on the home line, the litepaper's abstract, chip section and limits item, and the miner page, with rotation named an optional improvement and no threshold as the economic headline (the coexistence model owed): "Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment." Every number carries its label (the bracket about 2.3x to 3.3x a node ahead and 2.0x to 2.9x node for node, modelled, approximate and provisional, served on main's "serve the bracket now" order of 16:2x UK until the k lane's placed gated core row lands; the GPU side measured on the RTX 5080 and RTX 5090 lock rows of 8 October 2026 and the card's measured cost of the window (a rented 5090 and 4090 at stock, within 5 percent per load); the chip core synthesised on ASAP7 and scaled to N3, claimed, its memory modelled; the node column claimed scaling). The three statements (energy resistance, economic resistance, response capability) are served separate; the harness and the scoring rule are linked beside the sentence. Struck from every served page: the 2.1x and 3.4x launch line, the 5x to 9x baseline, the ladder's 2.8x row, the USD 100 M pay-back row and the k about 0.33 column; never served and not to be: the lifetime claim, the USD 300 M and 340 M lines, any chip-arrival probability, the 725d2945 sentence. The pins for X35 moved to the new sentence (a repository file). Was: the 2.1x to 3.4x range at the 5090's knee, below.
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
+
X36

The X9 described as a shipping chip

8 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; restated further 7 October 2026, evening, from the counter-asic-4 research file d7721ebe; on master at 25f38035): the X9's claimed ratio is against a CPU core, not a GPU lane, so the texts no longer use it as a pessimistic chip core; every served sentence says so; the pin for X36 moved.
+
Fixed, stated; restated 8 October 2026, afternoon, with X35): the X9 appears on the served pages only as a precedent (the pre-order, the withdrawal, no benchmark) and no served sentence uses its claimed core as a chip core against the model; the Antminer X5 is served as an observed comparison, not a ceiling (the close's 10.0f); the pin for X36 moved to that phrase. Was: the k about 0.33 column carried as the X9's claimed core, below.
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).

diff --git a/site/light.html b/site/light.html index c734a52bd..8ea44bec9 100644 --- a/site/light.html +++ b/site/light.html @@ -275,7 +275,7 @@

What is checked, in order

    -
  1. The certificate: the aggregate BLS signature of the signers over igneum-vote-v1/igneum-devnet-3 || index || checkpoint hash, the canonical voter order, the rule (two thirds of active weight, 17/30 of total), and the header chain from the previous lock.
    2. +
  2. The certificate: the aggregate BLS signature of the signers over igneum-vote-v1/igneum-devnet-3 || index || checkpoint hash, the canonical voter order, the rule (two thirds of active weight and two thirds of total weight), and the header chain from the previous lock.
  3. The header path from the carrier block up to the certified checkpoint: every header hash recomputes (BLAKE2b-256 keyed BlockHash over the header fields), every next header names the previous as a direct parent.
  4. The coinbase transaction is in the carrier block: its hash recomputes (BLAKE2b-256 keyed TransactionHash over the serialized transaction) and the merkle path reaches the header's hash_merkle_root.
  5. The segment record in the coinbase extra data: the aggregator's BLS signature over the record under the network's tag, whether the key is a voter with weight or a prove-only key, and the statement names the chain and the block whose state it commits.
    6. diff --git a/site/litepaper.html b/site/litepaper.html index 81261008b..af5e0e685 100644 --- a/site/litepaper.html +++ b/site/litepaper.html @@ -343,7 +343,7 @@ body.all .pager{display:none}

    Abstract

    -

    Igneum is a proof-of-work blockchain built for graphics cards, where NVIDIA cards also prove every block with zero-knowledge proofs and sell proving to other chains. At launch the strongest chip in our public model reaches 2.1x per joule against an RTX 5090 with a core as good as a GPU lane, 3.4x with one three times better, under class v4 from the first block; class v5 makes the dataset the chain’s own state, so a chip that stores it or recomputes it is wrong on every item; without class v4 the same chip would reach 5x to 9x: the chip model, every number labelled measured, modelled, claimed or designed.

    +

    Igneum is a proof-of-work blockchain built for graphics cards, where NVIDIA cards also prove every block with zero-knowledge proofs and sell proving to other chains. Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes. Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment. The chip model: every number labelled measured, modelled or claimed, the harness and the scoring rules beside it.

    It runs the Ethereum virtual machine, so anything built for Ethereum runs on Igneum unchanged. Transactions are included in about one second, proven within about a minute at launch, and locked by miners within about two. There is no premine, no pre-sale, no treasury taken from emission, no stake anywhere in consensus, and no dependence on any other chain. Mining stays open to anyone with a GPU because the mining program changes every hour, so a chip built for one program is useless for the next, and a chip for the whole program space is a GPU without the graphics parts. No scheduled human release is needed to keep it that way. Writing new code, including an emergency fix to the proof system, is the one thing that takes a person, and it activates only on miner signalling.

    1 / s
    blocks, rising to 10
    @@ -433,7 +433,7 @@ body.all .pager{display:none}
    Five layers plus the external proving market. A block flows down the column; outside demand feeds the same miners from the side.

    Live on Devnet 3, 7 October 2026

    -

    Devnet 3 (igneum-devnet-3, chain id 4463) made its first block at 18:06 UK on 7 October 2026 with every upgrade on from block zero, and locked its first checkpoint at 20:02 UK. The first devnet ran from 3 October 2026 and took each upgrade by height. Coins on Devnet 3 have no value and the chain may be reset. What is on it:

    +

    Devnet 3 (igneum-devnet-3, chain id 4464 since its class v5 floor at DAA 68,400, 4463 from genesis to the floor; the chain’s current state is the release manifest) made its first block at 18:06 UK on 7 October 2026 with every upgrade on from block zero, and locked its first checkpoint at 20:02 UK. The first devnet ran from 3 October 2026 and took each upgrade by height. Coins on Devnet 3 have no value and the chain may be reset. What is on it:

    @@ -466,20 +466,19 @@ body.all .pager{display:none}
    LayerStateSince

    Three ideas carry the chip resistance. The hash rewrites itself. A new program every hour, drawn from the chain. Its memory pattern changes with it. The rules change on a schedule fixed at launch. No release, no vote. These are automatic schedule changes: they defeat a chip wired for one datapath and they need no human fork. Against a chip that stores the dataset every drawn parameter is firmware, and what meets that chip is the latency-shadow work (class v4) and the price per joule (the Horizon lane analysis, 6 October 2026, section 5.4; ledger M32). It waits on memory, not maths. Every hash is a chain of random reads into a table too big for a chip to carry. Measured (8 October 2026; lane D’s family harness at the acceptance rule’s own 2^20 sample over 4,900 drawn eras, and the chained-cache pass’s reading of the night before): every hash’s 128 dependent reads land across the whole dataset and the distinct-index floor holds at 0.995 on every accepted program; about half of epochs carry one load site whose address bit at the era’s stride rotation is biased, which prices about 1.6 percent of a hash’s reads to a chip storing half the dataset and nothing to a chip storing all of it; the next class folds the product’s low bits before the rotation, so no era lands a biased bit on an address bit. The wait is the same physics for everyone. Miners hold the switch. Spare defences are written into the rules, switched off. A miner signal turns one on, at the class-change threshold: miners signal three things at three thresholds, 60 percent of blue blocks over two weeks for a parameter genesis leaves open, 90 percent for an upgrade (new code), and 95 percent with a floor height for a class change. No fork.

    -

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

    +

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

    The chip model

    -

    We price the strongest chip we can design against an RTX 5090 and publish the arithmetic. Class v4 is live from the first block on the testnet and the mainnet (the ladder’s rung 0 at genesis), so the launch number is the class v4 row. The honest card: an RTX 5090 mines class v3 at 136 MH/s on 350 W in the bench and 290 W in the app (measured, 6 October 2026); under class v4 the same card reads 136.84 MH/s at 475.5 W unlocked and 134.98 MH/s at 316.3 W at a 1,400 MHz core lock, and 133.80 MH/s at 305.1 W at 1,200 MHz, against a class v3 control of 134.68 MH/s at 228.0 W (measured, 7 October 2026); an Apple M5 Max at 27 MH/s on 21 W (measured, 6 October 2026); an H100 SXM at 249 MH/s, 98 percent of its random-read ceiling like the 5090, 1.78x the 5090’s hash at 1.15x the tuned 5090’s hash per watt and a third of the hash per rented dollar (measured, 7 October 2026), so datacentre silicon does not change the chip question. The CPU verifier takes 2.33 ms per warp of 32 hashes on one M5 Max core under class v4 (measured, 6 October 2026), against a gate of 10 ms.

    -
    - - - - - - - +

    Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes. Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment.

    +

    The labels. The bracket is modelled and provisional: its floor is the clock-gated base core and its ceiling the first placed core, which came in 64 percent above synthesis (wires and the clock tree); the honest figure is the placed gated core’s and replaces the bracket when its row lands. The GPU side is measured: an RTX 5080 at its 1,100 MHz core lock, 2.06 microjoules per hash, and an RTX 5090 at its 1,300 MHz lock, 2.33 microjoules per hash, both under class v4, on the project’s own rigs and rented pods, 8 October 2026; the card’s cost of the window is measured too (a rented RTX 5090 and RTX 4090 at stock, 8 October 2026: within 5 percent per load with the liveness chain, no register spill). The chip side is synthesised and claimed: the clock-gated sequencer core with the 64-register window on ASAP7, scaled to N3 on the foundry’s headline factors (k about 0.37 at N3 and 0.51 node for node for the base core, the gated window adding about 0.13 of k against an adversary with a flop register file; the window’s liveness measured at 61 of 64 values necessary, its cost to the card measured under 5 percent); the window’s k is synthesis-derived and not a lower bound, and the multi-family adversary lane’s first core (its state in a macro) reads the window’s defence as close to nothing, a disagreement between two models that the placed rows settle. The chip’s memory is modelled: the GDDR7 board of the chip model. The placed gated figure is expected near 2.6x to 3.1x a node ahead and 2.3x to 2.7x node for node (approximate) and is served when its row lands.

    +

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

    +
    The chip and the classEdge over an RTX 5090 per jouleLabel and date
    At launch: a memory-controller chip that stores the whole dataset, under class v4 (about 100,000 integer ops per hash in the latency shadow, so the chip carries a GPU-class datapath beside its memory)2.1x with a core as costly per op as a GPU lane (k = 1); 3.4x with a core three times better per op (k about 0.33); no core below about 1.8 pJ per op is in the model’s range, and the withdrawn Antminer X9’s claimed figure is a ratio against a CPU core, not a GPU lane, so it is not a chip core against usmodelled on the 5090’s measured watts at its knee, 7 October 2026 (the shadow’s premium 81.8 W at the best points: class v4 at the 1,200 MHz lock 133.80 MH/s at 305.1 W against class v3 at 1,300 MHz 134.62 at 223.3 W; a user gets there through Ember Tune’s core-clock knob, 0.3.24)
    The same chip at the ladder’s second rung (about 200,000 ops per hash), reached by miner signalabout 2.8xmodelled, 7 October 2026
    Any chip under class v5, where the dataset is the chain’s own statea stateless or stale chip is wrong on every item, so the stored-dataset chip and the recompute chip are removed as categories; the verifier pays 0.2 ms more per warpdesigned, 7 October 2026
    A chip caching the hottest 0.1 percent of items (about 1 MB of SRAM)bounded at 1.067x at the ceiling, 1.005x on about half the hours and 1.048x on 5 percentmeasured census of 1,024 programs, 7 October 2026; the source rule in the next class
    A per-day FPGA that recomputes the dataset with cheap multipliers on a weak dayat most 12 percent more multiplier area on an FPGA’s per-day build on 15 days a century, nothing on the other days and nothing for any chipmeasured census of 2^24 days, 7 October 2026; the rule in the next class
    When a stored-dataset chip pays for itselfat about USD 100 M of market cap in the first two years, not beforemodelled, 7 October 2026
    The baseline the work started from: the same chip under class v3, without the shadow (the Ethash class)5x to 9x (5.1x on GDDR7, 9.2x on eight HBM3 stacks; the Ethash chips of this class reached 2.1x to 4.8x)modelled, 6 October 2026; the precedent measured by others, 2020 to 2022; never the launch state
    + + +
    StatementWhat it saysLabel and date
    Energy resistanceThe bracket above: about 2.3x to 3.3x for the strongest specialised design a node ahead of the GPU tier, 2.0x to 2.9x on the GPU’s own node, provisional until the placed gated core row lands; two nodes ahead follows from that row. The honest tier moves to the next node with every GPU generation; a chip must tape out again.modelled on measured cards, 8 October 2026, approximate and provisional; the node column is claimed scaling
    Economic resistanceWhether a chip gets built depends on development cost, deployment economics and productive hardware lifetime. The first cut of the profitability surface: the price at which a project pays scales as the project cost over its share of the chain times its discounted life, and moves by under 5 percent with the per-joule edge; a fixed-lane chip under rotation needs 4x the price a programmable one needs. No threshold is the headline: the coexistence model that prices the conditions (docs/analysis/class-v6/coexistence-model.md) is owed and is served when it exists.modelled, first cut, 8 October 2026; conditional until the cut lands
    Response capabilityRotation is an optional improvement, not the mechanism. A passed rotation boundary proves the rotation works, not that hardware dies. The schedule: a new program every hour, a parameter era every week, a family epoch every 180 days, an emergency vote when miners call one.measured per boundary, 8 October 2026

    What a miner sees from this. Class v4 costs a 5090 145 W more unlocked, 88 W more at a 1,400 MHz core lock and 82 W at the best operating points (class v4 at 1,200 MHz, class v3 at 1,300; the knee is 1,300 MHz on both), for 0.2 percent more rate (measured, 7 October 2026; the 80 W read on 6 October was at the app's tuned cap); an M5 Max 16 W more for 1.5 percent, an RX 9070 XT and an RTX 4070 nothing (measured, 6 October 2026). The ladder that sets how much work rides in the shadow starts at rung 0 at genesis and climbs by miner signal; its third rung is inadmissible today because a server core verifies it in 10.85 ms, over the gate (measured, 7 October 2026). Devnet 3 runs class v4 from its first block (7 October 2026); the first devnet started on class v3 and reaches class v4 by miner signal at a published height. Classes rotate on findings and at least yearly; a class change is a release activated by block height. Class v5 crosses on Devnet 3 by height; class v6 is the design in progress (opened 8 October 2026), with four layers as its spine: per-era draws of the parameters a release now fixes, a dataset whose size tracks the chain state, scheduled family epochs by height, and the acceptance floor generalised to every era’s draw. The next test of the model is an internal adversarial pass, not an independent review: three lanes that have never worked on the hash code attack the mixer, the chained cache and the acceptance rule with only what an outsider has (the public kit, the frozen object, the spec, the harnesses) and publish the break or the bound they reach. No outside review has run yet.

    -

    No hash has stayed free of chips forever. Igneum does not claim to. It states the gain its own model finds, the response takes a week, and both are measured. The model is public: the numbers; the claim is tested by the in-house adversarial pass and the public benchmark. Monero has run on RandomX since November 2019; one chip shipped against it, Bitmain’s Antminer X5 (September 2023), a board of RISC-V chips at 1.46x per joule over a desktop CPU, on silicon believed mining privately from about 2021; RandomX v2 was released on 25 March 2026 with its mainnet activation pending. 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.4x over an RTX 5090), and the defence that held was a maintained algorithm with a credible upgrade path, which is what the ladder is.

    +

    No hash has stayed free of chips forever. Igneum does not claim to. It states the gain its own model finds and the response the rotation makes, and both carry their labels. The precedents, as sourced (nameplate and community tables, about 20 percent either way; every figure with its URL and date in the close): Monero has run on RandomX since November 2019, its rules stable since then and its programs varying per hash; one chip shipped against it, Bitmain’s Antminer X5 (September 2023), 46 months after the fork, at 6.37 J per kH at the wall against a stated CPU measurement, an observed comparison, not a ceiling. 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. RandomX v2 was released on 25 March 2026 with its mainnet activation pending. Ethash ran 36 months to a first chip worse than a GPU; the iPollo V2H reads about 14x today. Kaspa ran 21 months to its first chip, at 167x to 725x. The commodity cohort Igneum protects is the discrete-GPU population; the Apple row is reported beside it, never as the headline.

    +

    The scoring rule and the harness. The edge is the minimum over workloads of the maximum over free adversarial designs of the GPU’s joules per hash over the adversary’s, under four conditions: the 10 percent GPU-cost budget at the lock, the verifier limit, cross-vendor correctness and hardware accessibility. The rejected designs stand as negative controls with their measured rows: the long program, the select tree, the wide read, the scratchpad. The next programme: the connected-state experiment, the mixed integer and FP32 candidate, the multi-family programmable adversary; rotation is not expected to deliver the missing joule. The scoring rules and every row, section 10. The harness and its readings (measured, 8 October 2026): the acceptance floor at 0.995 refuses nine of nine hot sets (0.9809 to 0.9919) and 2.435 percent of 4,600 drawn programs, 0 of 61 in the era reading (section 14); the attack families F8, F4, F9 and F1 pass, F8 with a residue of 61 of 64 (section 13); the attempts census and the attempt-3 read (section 0).

    One thing takes a person, here and on every chain that exists: writing new code. A chain cannot safely write its own generator, and it cannot safely tell a chip from a wave of honest new cards by hashrate alone. If the design above ever failed, anyone could publish a new generator and miners would switch it on by signalling, as Monero's community can fork. Igneum is built to make that day unlikely, and does not depend on avoiding it.

    @@ -684,7 +683,7 @@ body.all .pager{display:none}
    - + @@ -835,7 +834,7 @@ body.all .pager{display:none}

    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). At launch the strongest chip in our public model reaches 2.1x per joule against an RTX 5090 with a core as good as a GPU lane and 3.4x with one three times better, under class v4 from the first block: a memory-controller chip that stores the whole dataset and carries a GPU-class datapath beside its memory for the 100,000 ops per hash in the shadow, the range running from a chip core as costly per operation as a GPU lane (k = 1, modelled on the 5090’s measured watts at its knee, 7 October 2026) to a core three times better per operation (k about 0.33); the withdrawn Antminer X9’s claimed figure is a ratio against a CPU core, not a GPU lane, so it does not stand for a chip core against us; the ladder’s second rung takes that bracket to about 2.8x (modelled, 7 October 2026). Class v5 then makes the dataset the chain’s own state, so a chip that stores it or recomputes it is wrong on every item (designed, 7 October 2026). The baseline the work started from, never the launch state: without class v4 the same stored-dataset chip would reach 1.2x per chip and 5x to 9x per joule in our model (6 October 2026); the Ethash chips of this class reached 2.1x to 4.8x (Linzhi Phoenix 2020, Jasminer X4 2021, Antminer E9 2022). The strongest recompute chip we can price, holding the whole 256 MiB cache on-die, reaches under 1x per chip against an RTX 5090 (the published model, 5 October 2026: 0.92x per unit of silicon with a 3x fixed-function allowance, approximate). Sources: the chip model analysis (6 October 2026); the ASIC history’s Ethash rows; Counter ASIC 3.0 item 8 (the chip’s per-joule edge over the RTX 5090 falls from 5.6x to 2.1x on GDDR7 at k = 1 and to 3.4x at a core three times better, the 5090 at 0.2% less rate; gates G1 to G6 passed, 6 October 2026). No hash has stayed free of chips forever; Igneum does not claim to. Monero’s RandomX has held its miners on commodity hardware for about seven years: one chip shipped against it, Bitmain’s Antminer X5 (September 2023), at 1.46x per joule over a desktop CPU; the one announced beyond it, the Antminer X9, was withdrawn in mid-May 2026 before any unit shipped, its claimed core (k about 0.33) never measured; RandomX v2 was released on 25 March 2026 with its activation pending. 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 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). Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes. Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment. The labels: the bracket modelled, approximate and provisional (the GPU side measured on the RTX 5080 and RTX 5090 at their core locks under class v4, 8 October 2026; the chip core synthesised on ASAP7 and scaled to N3, claimed, its placed gated row pending; its memory modelled). Class v5 makes the dataset the chain’s own state, so a chip that stores it or recomputes it is wrong on every item (designed, 7 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 (the published model, 5 October 2026: 0.92x per unit of silicon with a 3x fixed-function allowance, approximate). Sources: the class v6 close, section 10 (8 October 2026); the ASIC history’s Ethash rows; the chip model analysis (6 October 2026). No hash has stayed free of chips forever; Igneum does not claim to. Monero’s RandomX has held its miners on commodity hardware for about seven years: one chip shipped against it, Bitmain’s Antminer X5 (September 2023), an observed comparison, not a ceiling; the one announced beyond it, the Antminer X9, was withdrawn in mid-May 2026 before any unit shipped, its claimed core never measured; RandomX v2 was released on 25 March 2026 with its activation pending. 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.
      • diff --git a/site/miner.html b/site/miner.html index b13968432..bb5cfb414 100644 --- a/site/miner.html +++ b/site/miner.html @@ -298,6 +298,7 @@ pre b{color:var(--molten-text);font-weight:500}

      Ember for Linux and HiveOS

      a tarball for rigs and Hive flight sheets

      For the rig people. One tarball, the miner and the node inside, the same signed manifest as the desktop apps.

      Download the tarball v0.3.22 · 28.8 MB +

      Current versions: Windows 0.3.20, macOS 0.3.20, HiveOS 0.3.22, the wallet 0.1.5; the node on Devnet 3 igneumd/2.1.0-f8da7515, read 8 October 2026, 15:50 UK. The machine-readable list, with every file’s SHA-256, is /release.json.

      HiveOS Flight Sheet. Miner: Custom. Installation URL: https://dl.igneum.network/dl/public/igneum-hive-0.3.22.tar.gz. Miner name igneum, wallet and worker 0x<your 40-hex payout address>.%WORKER_NAME%. Hive itself is untested on our side: tell us what breaks.

      sha256 8ad6dcef9edc57dcd33e8d5a97cbef5cdda0e384a6e56d3f62f8903029c4c764

      @@ -335,7 +336,7 @@ pre b{color:var(--molten-text);font-weight:500}
    LeverWhat it doesState, 5 Oct 2026Measured
    1. Compiler race every hourAt every hourly program the worker compiles up to 17 variants of the kernel (unroll, load path, register budget, threads per block), checks each bit for bit against the base kernel, times each for 2 s with mining paused, and keeps the fastest for the hour. The hash never changesShipped in the Metal and CUDA workers+17.3% on the genesis seed and +21.2% on the hourly seed, Apple M5 Max, Metal, 14 variants, under load, ratios only. The RTX 5090 race is built and not yet run
    1. Compiler race every hourAt every hourly program the worker compiles up to 17 variants of the kernel (unroll, load path, register budget, threads per block), checks each bit for bit against the base kernel, times each for 2 s with mining paused, and keeps the fastest for the hour. The hash output is bit for bit the sameShipped in the Metal and CUDA workers+17.3% on the genesis seed and +21.2% on the hourly seed, Apple M5 Max, Metal, 14 variants, under load, ratios only. The RTX 5090 race is built and not yet run
    2. Per-card auto-tune from the fleetEvery race writes a record to the fleet log. The best variant per card model is aggregated and sent back to every machine inside the signed update manifest, so a new card starts from the fleet's best and keeps racingShipped. The fleet is small, so no table yetNo fleet table yet
    3. Hash per wattSteps an NVIDIA card's power cap from 100% to 50% of its default in 10% steps, holds each for 60 s, and keeps the best MH per watt. The tile shows live MH per watt. The sweep never restarts the worker, so the hour's program is never lostIn the app for NVIDIA cards. AMD and Apple: not supportedThe first sweep on a card is pending. The RTX 5090 drew 290 W at p95 under a 460 W cap, so the cap did not bind
    4. Template latencyThe miner subscribes to new templates instead of polling, the node builds the next template ahead, and the workers switch without draining the batch. Target under 50 ms from a new block to the card working on it, solo against the local nodeIn 0.3.6Switched p50 46 to 52 ms, p90 118 to 130 ms, 3-node fast-time network, CPU miners, 0 rejected

    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); at launch the chip reaches 2.1x per joule under class v4 with a core as good as a GPU lane, 3.4x with one three times better (modelled on measured watts at the 5090's knee: the shadow costs that card 82 W at its best point, and Ember Tune lands the lock by itself), and under class v5 it is wrong on every item because the dataset is the chain’s own state (designed). Without class v4 it would be 5x to 9x. The model and the measurements are public.

    +

    Your card against the strongest chip we can price. Igneum remains competitive on accessible commodity GPUs even when specialised mining hardware is assumed to exist, remain compatible and seek profit; its security does not rely on identifying that hardware or retiring it through emergency changes. Class v6 adopts the 64-register window and retains it across every rotation. Current modelling places the strongest specialised designs assessed against the GPU tier at about 2.3x to 3.3x energy-efficiency advantage a node ahead (2.0x to 2.9x on the GPU's own node), a bracket that is approximate and provisional until the placed gated core rows land. The long-program and select-tree proposals were rejected. Economic resistance depends on development cost, deployment economics and productive hardware lifetime; family transitions receive an obsolescence benefit only where a loss of competitiveness is demonstrated; programmable multi-epoch designs are included in the assessment. The GPU side is measured: an RTX 5080 and an RTX 5090 at their core locks under class v4 (8 October 2026); the chip core is synthesised and claimed, its placed row pending; its memory is modelled. Under class v5 the chip is wrong on every item because the dataset is the chain’s own state (designed). Every number with its label, the harness and the scoring rules.

    diff --git a/site/provenance.html b/site/provenance.html index b4ed7a64c..d577c1280 100644 --- a/site/provenance.html +++ b/site/provenance.html @@ -256,7 +256,7 @@ table{min-width:560px}

    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.

    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)
    +
    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 (historical: Devnet 3 answers chain id 4464 since its class v5 floor at DAA 68,400 on 8 October 2026, 4463 below it; the current id is in /release.json); 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.

    diff --git a/site/receipt.html b/site/receipt.html index 3367eb07f..9a36fec70 100644 --- a/site/receipt.html +++ b/site/receipt.html @@ -278,7 +278,7 @@
  6. The transaction hash is keccak256 of the raw signed transaction in the file, so the recipient, the amount and the data are the signed ones.
  7. The transaction is a leaf of the including block's hash_merkle_root (BLAKE2b-256 keyed MerkleBranchHash up the path).
  8. Every header from the including block to the certified checkpoint recomputes and links to the next by a direct parent.
    9. -
  9. The certificate over that checkpoint verifies: the aggregate BLS signature of the signers, the voter order, two thirds of active weight and 17/30 of total.
    10. +
  10. The certificate over that checkpoint verifies: the aggregate BLS signature of the signers, the voter order, two thirds of active weight and two thirds of total weight.

The payment receipt adds: the record's carrier block up to the checkpoint, the segment record's signature, the shard receipts roots hashing to the statement's commitment, the shard's receipts rebuilding that root with this transaction's receipt at its position. Not proven by either file: the voter table with weights comes from the node (spec 10.1), and the SP1 proof behind the statement is verified by nodes, not here. In the four words below: the inclusion receipt authenticates included and finalised, reports executed and claims nothing about proven; the payment receipt authenticates included, executed, proven and finalised under the trust assumptions stated.

diff --git a/site/release-manifest.json b/site/release-manifest.json new file mode 100644 index 000000000..4c480d02b --- /dev/null +++ b/site/release-manifest.json @@ -0,0 +1,243 @@ +{ + "format": "igneum-release-manifest-v1", + "generated": "2026-10-08T15:55:00Z", + "read_at": "read 8 October 2026, 15:50 UK, from the Devnet 3 seed and the fleet census (the node lane), the download index and the ELF manifest", + "labels": { + "measured": "read from a running node, a binary or a record", + "designed": "in the specification or the design document, not yet carried by code on the live chain", + "modelled": "a model's figure", + "claimed": "stated by a third party, not measured here" + }, + "network": { + "id": "igneum-devnet-3", + "name": "Igneum Devnet 3", + "kind": "developer network: resets without notice, its coins have no value", + "chain_id": 4464, + "chain_id_hex": "0x1170", + "chain_id_below_floor": 4463, + "chain_id_note": "4464 since the class v5 floor at DAA 68,400 (crossed 8 October 2026, 12:57 UK); 4463 from genesis to the floor; a transaction carries the id in force at its block", + "genesis": { + "first_block_utc": "2026-10-07T17:06:00Z", + "first_lock_utc": "2026-10-07T19:02:00Z", + "note": "every upgrade on from block zero: era VDF, finality v3, fees v1, proving v1, the latency ladder at rung 0" + }, + "rpc": "https://rpc.devnet.igneum.network", + "explorer": "https://igneum.network/explorer", + "faucet": "https://faucet.igneum.network", + "vote_domain": "igneum-vote-v1/igneum-devnet-3", + "decimals": 8, + "block_target_seconds": 1, + "consensus_digest": "2066aa57505e5ecbd585d061364abb0032d5b5b29cc41c54f4b38cb81c2ba6eb", + "label": "measured", + "others": [ + { + "id": "igneum-testnet-1", + "chain_id": 4462, + "chain_id_hex": "0x116e", + "rpc": "https://rpc.testnet.igneum.network", + "state": "armed: three seed nodes and the public RPC are up, nothing mines until the go word", + "genesis_hash": "87617621714af1bf33bd17f291f90a7e0bff760a669bba53083ea8c0f7cbd840", + "decimals": 18 + }, + { + "id": "igneum-mainnet", + "chain_id": 4461, + "chain_id_hex": "0x116d", + "state": "not started", + "decimals": 18 + } + ] + }, + "source": { + "repository": "https://git.igneum.network/igneum-network/igneum", + "repository_note": "the public reference repository: the specifications, the igneum-pow crate, the simulators and the test material; the full node, the miner and the proving code open later", + "node": { + "fork_of": "rusty-kaspa v2.1.0 (01b532e8)", + "branch": "release-0.3.25-node", + "commit": "f8da7515", + "version_string": "igneumd/2.1.0-f8da7515", + "pin": "c9ad753a (the move of 8 October 2026, 15:25 UK)", + "pending": "acaf08b0, cut 15:43 UK, gates running, its move not yet named", + "label": "measured" + }, + "pow": { + "crate": "igneum-pow", + "version": "0.2.0", + "commit": "1c420786", + "freeze": "class-v5-freeze 2026-10-07", + "tree_fingerprint": "cbc5bd0aa10585c8576e71e37a8ee47a045ae51754e9ddf749d0c21e6a535f88", + "binary_line": "igneum-pow fingerprint cbc5bd0aa10585c8 (the freeze)", + "below_floor": "017e7037 (class v4 sub-version 3, the audit-freeze-2026-10-07 tag) paired below the class v5 floor", + "label": "measured" + }, + "app": { + "name": "Ember", + "channel": "devnet-3", + "note": "the shipped artefacts and their SHA-256 are the versions block; the app ships from the same repository" + } + }, + "mining": { + "class": "v5", + "class_since_daa": 68400, + "class_at_genesis": "v4", + "class_note": "class v4 (the latency shadow, about 100,000 integer ops per hash at the ladder's rung 0) from block zero; class v5 (the dataset keyed by the chain's own state) from DAA 68,400", + "block_version": 1538, + "program": { + "epoch_daa": 3600, + "epoch_lead_daa": 601, + "vdf_minutes": 10, + "instructions": 64, + "loads_per_program": 16, + "lanes": 32, + "registers_per_lane": 8, + "dataset_reads_per_hash": 128 + }, + "dataset": { + "items_log2": 24, + "size": "1 GiB on the devnets (2^24 items at the genesis size)", + "keyed_by": "the execution state after the epoch's reference block (class v5)", + "cache": "256 MiB day cache (class v3 lineage)", + "growth": "no growth step is set on Devnet 3; the genesis-fixed schedule of spec 1.13.3 is a mainnet matter; class v6's step schedule (5.5 / 8.5 / 11.5 GiB) is a design on its branch, not live" + }, + "ladder": { + "rung": 0, + "ops_per_hash": "about 100,000", + "move_rule": "90 percent of blue blocks in each of seven consecutive days, one rung at a time" + }, + "label": "measured; the dataset growth line designed" + }, + "finality": { + "rule": "v3", + "since_checkpoint_daa": 0, + "statement": "a checkpoint locks when the signers hold at least two thirds of active weight and at least two thirds of total weight; weight is blue blocks per vote key over a flat 30-day window of past-median time", + "checkpoint_interval_daa": 30, + "checkpoint_depth": 20, + "weight_window_seconds": 2592000, + "presence_window_seconds": 7200, + "dust": 5, + "presence": 20, + "aggregators": 8, + "ban_daa": 7200, + "certificate_fold_daa": 3, + "frozen_table": "the weight table is frozen at the last certified checkpoint on the selected chain (spec 03 Q5), active for every checkpoint from DAA 0 on Devnet 3", + "node_line": "Finality v2 (igneum-devnet-3): interval 30 depth 20 window 7200 DAA dust 5 presence 20 aggregators 8 ban 7200 fold 3; rule v3 from checkpoint DAA 0", + "label": "measured" + }, + "proving": { + "verifier_in_consensus": "off", + "verifier_note": "proving v0: every producer verifies off the consensus path; consensus checks the record's statement against native execution and its signature; the in-consensus verifier switches on when the proven share of blocks reads one (ledger P21)", + "shard_market": "on from DAA 0: segment records of 8 blocks, unproven after 600 DAA, aggregator share 1,000 bps", + "proof_system": "SP1", + "sp1_circuit_version": "v6.1.0", + "sp1_crate_version": "6.8.1", + "pinned_at": "2026-10-05T16:20:38Z", + "shard_program_id": "0x2b1a81cb413236cf063077b46ed3111628f6c41036bcf6e23ee4cbbf5679ef7a", + "shard_elf_sha256": "0x150f4c05a2951fc56174a87089707a030b18df8fbe7e053a66459edb83053083", + "shard_vk_sha256": "0x8b4da5bff86d963f4210a78e5d800a1cd00ab41b158f6962f4ac009edc249d4c", + "aggregator_program_id": "0x474678f35f7545db28055d5e5bbc308231d84a5a072202087a2a8d5b09123896", + "aggregator_elf_sha256": "0x143d9c243dd12e87e90be71f6b8cd42353e513bf8ce78903ef6f972f1bc9aa7b", + "aggregator_vk_sha256": "0xad17bc1ae5be816554dbb13cb5b4d242678adfb8e1a4f7247ceb8b5ba9001b9f", + "manifest_file": "proving/igneum-prove/elf/manifest.json", + "label": "measured" + }, + "fees": { + "subsidy_split": { + "miner_percent": 80, + "proving_pool_percent": 20, + "where": "consensus/core/src/igneum.rs 44" + }, + "base_fee": { + "route": "burned in full, both gas dimensions (gas times the execution base fee, pgas times the proving base fee)", + "where": "igneum/exec/src/executor.rs 320 to 371" + }, + "priority_fee": { + "miner_percent": 80, + "developer_percent": 20, + "note": "the developer part goes to the registrations of the contracts whose code ran, pro rata by each frame's gas; an unregistered frame's part is a burn", + "where": "executor.rs 335 to 339; pgas.rs 290" + }, + "proving_fee_ceiling": { + "value": 90000, + "multiple": 4, + "note": "the proving-fee ceiling of the live object" + }, + "external_jobs": { + "provers_percent": 90, + "burn_percent": 10, + "state": "designed, not in the code" + }, + "dev_fee": { + "percent": 1, + "mechanism": "one block template in a hundred with the dev payout address, a counter, not a draw", + "default": "on", + "off": "--dev-fee 0, the app switch, DEV_FEE=0 on HiveOS; none in pool mode", + "where": "igneum/miner/src/main.rs 718" + }, + "emission": { + "launch_rate_base_units_per_daa_second": 3168808781, + "year_one_ign": 1000000000, + "ramp_seconds": 2592000, + "ramp_start_percent": 10, + "halving_seconds": 63115200, + "cap_ign": 4000000000, + "tail": "none", + "where": "consensus/core/src/emission.rs 85 to 123; igneum.rs 34, 76" + }, + "label": "measured in the code on Devnet 3; external jobs designed" + }, + "versions": { + "miner-hive": { + "version": "0.3.22", + "file": "igneum-hive-0.3.22.tar.gz", + "sha256": "8ad6dcef9edc57dcd33e8d5a97cbef5cdda0e384a6e56d3f62f8903029c4c764", + "size": 28771228, + "url": "https://dl.igneum.network/dl/public/igneum-hive-0.3.22.tar.gz" + }, + "miner-mac": { + "version": "0.3.20", + "file": "Igneum-Miner-0.3.20.dmg", + "sha256": "73796c5febc2050646f038c1f8c32a1d854033d125d0c02478b983ea8020419e", + "size": 44467804, + "url": "https://dl.igneum.network/dl/public/Igneum-Miner-0.3.20.dmg" + }, + "miner-windows": { + "version": "0.3.20", + "file": "Igneum-Miner-Setup-0.3.20.exe", + "sha256": "45b2f3fb54f40f839cde8efac53b40eca3738a4009af1a4e356f6445883df6b5", + "size": 63025372, + "url": "https://dl.igneum.network/dl/public/Igneum-Miner-Setup-0.3.20.exe" + }, + "wallet-mac": { + "version": "0.1.5", + "file": "Igneum-Wallet-0.1.5.dmg", + "sha256": "daf259f272934f0c1a8155ef68762c344164ae8a77c8d0621d0fceed0fb163fa", + "size": 20122390, + "url": "https://dl.igneum.network/dl/public/Igneum-Wallet-0.1.5.dmg" + } + }, + "versions_updated": "2026-10-07T20:43:23Z", + "sources": { + "network": "docs/build/build.md (the Networks table); the node lane's read of build-1's seed", + "node": "docs/plans/release-0.3.22.md and the node lane's read; the version string from igneumd --version", + "pow": "packaging/pow-freeze.txt; the binaries' fingerprint line", + "finality": "docs/spec/03-finality.md 3.3; the node's start line", + "proving": "proving/igneum-prove/elf/manifest.json; docs/fud-ledger.md P21", + "fees": "site/economics.html (the file and line of every constant); site/lib/emission.mjs", + "versions": "site/downloads.json (dl.igneum.network's index)" + }, + "read_at_short": "read 8 October 2026, 15:50 UK", + "proving_view": { + "read_at": "12:16 UK on 8 October 2026", + "read_daa": 65900, + "read_daa_note": "approximate: DAA seconds since genesis at 17:06 UTC on 7 October 2026, one a second", + "shards_paid_24h": 8209, + "ign_paid_24h": "9,913.09", + "prover_keys_24h": 29, + "shards_planned_24h": 40502, + "paid_per_hour": 905, + "lag_p50_daa": 514, + "lag_p90_daa": 953, + "source": "the observer's proof tables through /api/explorer?proving=1, the proving page", + "label": "measured" + } +} diff --git a/site/vercel.json b/site/vercel.json index c8ceddbd4..7a5b8a018 100644 --- a/site/vercel.json +++ b/site/vercel.json @@ -37,6 +37,10 @@ "source": "/address/:addr", "destination": "/address" }, + { + "source": "/release.json", + "destination": "/release-manifest.json" + }, { "source": "/benchmarks", "destination": "/miners" diff --git a/tools/ci/checks.txt b/tools/ci/checks.txt index 325456ec1..55da9c617 100644 --- a/tools/ci/checks.txt +++ b/tools/ci/checks.txt @@ -9,6 +9,7 @@ no founder name, personal login, earlier business or personal address in any tra every check in tools/ci/checks.txt has its run line here and every run line is listed (a conflict resolution cannot drop a check unseen; self-test first) site build (in a temporary copy here, in place only inside GitHub Actions) internal link check of site/*.html +the release manifest: site/release-manifest.json parses, its versions are downloads.json's, its proof ids the ELF manifest's, /release.json served, every data-rm span on a committed page carries its value every served page carries the slim bar (mark, Mine, Network, Learn, Download) with every route in its panels and the sheet (self-test, then the tree) vendor marks: site/lib/marks.mjs is brand/marks/vendor-marks.mjs byte for byte (the app and the site draw one set) the phone menu opens and is seen at 390 px on every page (self-test first; needs the box or CI browser, says so without one) diff --git a/tools/ci/ledger-text-check.mjs b/tools/ci/ledger-text-check.mjs index 7fca5f218..81246ed8b 100644 --- a/tools/ci/ledger-text-check.mjs +++ b/tools/ci/ledger-text-check.mjs @@ -14,8 +14,9 @@ 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 armed: three seed nodes and the public RPC are up, and it opens on the go word.'], - // 7 Oct 2026, 18:3x: the launch-first chip line of docs/plans/counter-asic-3-public-text-2026-10-07.md section 1 - ['X35', 'At launch the strongest chip in our public model reaches 2.1x per joule against an RTX 5090 with a core as good as a GPU lane, 3.4x with one three times better, under class v4 from the first block'], + // 8 Oct 2026, afternoon: the class v6 close's served sentence (docs/design/class-v6-rotating-family.md 10.0h), verbatim + ['X35', 'a bracket that is approximate and provisional until the placed gated core rows land'], + ['X35', 'its security does not rely on identifying that hardware or retiring it through emergency changes'], ], 'litepaper.html': [ ['X3', 'Live rows arrive with the public testnet.'], @@ -25,9 +26,9 @@ const REQUIRED = { ['C2', 'Monero has run on RandomX since November 2019'], ['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', 'so the launch number is the class v4 row'], - ['X35', '3.4x with a core three times better per op (k about 0.33); no core below about 1.8 pJ per op is in the model’s range'], - ['X36', 'the withdrawn Antminer X9’s claimed figure is a ratio against a CPU core, not a GPU lane, so it is not a chip core against us'], + ['X35', 'Class v6 adopts the 64-register window and retains it across every rotation.'], + ['X35', 'The long-program and select-tree proposals were rejected.'], + ['X36', 'an observed comparison, not a ceiling'], ['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'], diff --git a/tools/ci/link-check.mjs b/tools/ci/link-check.mjs index 324e87b2f..273798dc7 100644 --- a/tools/ci/link-check.mjs +++ b/tools/ci/link-check.mjs @@ -23,6 +23,9 @@ function resolves(target) { return candidates.some(c => existsSync(c) && statSync(c).isFile()); } +// a literal vercel.json rewrite (no :param) resolves to its destination (/release.json -> /release-manifest.json, 8 October 2026) +const rewrites = Object.fromEntries((JSON.parse(readFileSync(join(site, 'vercel.json'), 'utf8')).rewrites || []).filter(r => !r.source.includes(':')).map(r => [r.source, r.destination])); +const resolvesOrRewritten = (p) => resolves(p) || (rewrites[p.replace(/[?].*$/, '')] != null && resolves(rewrites[p.replace(/[?].*$/, '')])); for (const page of pages) { const html = readFileSync(join(site, page), 'utf8'); const ids = new Set([...html.matchAll(/\sid="([^"]+)"/g)].map(m => m[1])); @@ -34,7 +37,7 @@ for (const page of pages) { checked++; if (t.startsWith('#')) { if (t.length > 1 && !ids.has(t.slice(1))) broken.push(`${page}: fragment ${t}`); continue; } const [path, frag] = t.split('#'); - if (!resolves(path)) { broken.push(`${page}: ${t}`); continue; } + if (!resolvesOrRewritten(path)) { broken.push(`${page}: ${t}`); continue; } if (frag) { const rel = path.replace(/[?].*$/, '').replace(/^\//, ''); const file = [join(site, rel), join(site, `${rel}.html`), join(site, rel, 'index.html')].find(c => existsSync(c) && statSync(c).isFile()); diff --git a/tools/ci/pre-push.sh b/tools/ci/pre-push.sh index 695938a82..cfd968da5 100755 --- a/tools/ci/pre-push.sh +++ b/tools/ci/pre-push.sh @@ -107,6 +107,7 @@ never_push_checks() { tree_checks() { run "site build (in a temporary copy here, in place only inside GitHub Actions)" site_build run "internal link check of site/*.html" node tools/ci/link-check.mjs + run "the release manifest: site/release-manifest.json parses, its versions are downloads.json's, its proof ids the ELF manifest's, /release.json served, every data-rm span on a committed page carries its value" node tools/ci/release-manifest-check.mjs run "every served page carries the slim bar (mark, Mine, Network, Learn, Download) with every route in its panels and the sheet (self-test, then the tree)" bash -c 'node tools/ci/site-nav-check.mjs --self-test && node tools/ci/site-nav-check.mjs' run "vendor marks: site/lib/marks.mjs is brand/marks/vendor-marks.mjs byte for byte (the app and the site draw one set)" cmp brand/marks/vendor-marks.mjs site/lib/marks.mjs run "the phone menu opens and is seen at 390 px on every page (self-test first; needs the box or CI browser, says so without one)" node tools/site/sheet-test.mjs --self-test diff --git a/tools/ci/release-manifest-check.mjs b/tools/ci/release-manifest-check.mjs new file mode 100644 index 000000000..1513dfbc9 --- /dev/null +++ b/tools/ci/release-manifest-check.mjs @@ -0,0 +1,50 @@ +// Release manifest check (8 October 2026, an accepted external review): site/release-manifest.json is served at /release.json +// and is the one source of the chain's identity, sources, class, finality rule, proof ids, fees and versions on the status +// pages. This holds it together: the manifest parses and carries every block; its versions are the download index's; its +// proof ids are the ELF manifest's (when the tree carries it); vercel.json serves it at /release.json; every +// on a committed page carries the manifest's value; and no forbidden string is in it. +// node tools/ci/release-manifest-check.mjs exit 1 listing every fault +import { readFileSync, existsSync, readdirSync } from 'node:fs'; +import { join, dirname } from 'node:path'; +import { fileURLToPath } from 'node:url'; +const root = join(dirname(fileURLToPath(import.meta.url)), '..', '..'); +const site = join(root, 'site'); +const fails = []; +const m = JSON.parse(readFileSync(join(site, 'release-manifest.json'), 'utf8')); +for (const k of ['format', 'generated', 'read_at', 'network', 'source', 'mining', 'finality', 'proving', 'fees', 'versions', 'sources']) if (!(k in m)) fails.push(`manifest: no "${k}" block`); +if (!/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$/.test(m.generated || '')) fails.push('manifest: "generated" is not an ISO UTC date'); +if (m.network?.chain_id !== 4464 || m.network?.chain_id_hex !== '0x1170') fails.push('manifest: Devnet 3 chain id is 4464 (0x1170)'); +if (!/two thirds of active weight and at least two thirds of total weight/.test(m.finality?.statement || '')) fails.push('manifest: the finality statement must say two thirds of active and two thirds of total weight'); +if (m.proving?.verifier_in_consensus !== 'off') fails.push('manifest: the verifier is off in consensus (ledger P21) until that row moves'); +const dl = JSON.parse(readFileSync(join(site, 'downloads.json'), 'utf8')); +for (const [k, v] of Object.entries(dl.files)) { + const w = m.versions?.[k]; + if (!w) { fails.push(`manifest: versions.${k} missing (in downloads.json)`); continue; } + for (const f of ['version', 'file', 'sha256', 'size']) if (w[f] !== v[f]) fails.push(`manifest: versions.${k}.${f} is ${w[f]}, downloads.json says ${v[f]}`); +} +if (m.versions_updated !== dl.updated) fails.push(`manifest: versions_updated ${m.versions_updated} is not downloads.json's ${dl.updated}`); +const elfp = join(root, 'proving', 'igneum-prove', 'elf', 'manifest.json'); +if (existsSync(elfp)) { + const e = JSON.parse(readFileSync(elfp, 'utf8')); + for (const [a, b] of [['shard_program_id', e.shard.program_id], ['shard_elf_sha256', e.shard.elf_sha256], ['shard_vk_sha256', e.shard.vk_sha256], ['aggregator_program_id', e.aggregator.program_id], ['aggregator_elf_sha256', e.aggregator.elf_sha256], ['aggregator_vk_sha256', e.aggregator.vk_sha256], ['sp1_circuit_version', e.sp1_circuit_version], ['sp1_crate_version', e.sp1_crate_version], ['pinned_at', e.pinned_at]]) + if (m.proving[a] !== b) fails.push(`manifest: proving.${a} is ${m.proving[a]}, the ELF manifest says ${b}`); +} +const vercel = JSON.parse(readFileSync(join(site, 'vercel.json'), 'utf8')); +if (!(vercel.rewrites || []).some(r => r.source === '/release.json' && r.destination === '/release-manifest.json')) fails.push('vercel.json: no rewrite /release.json -> /release-manifest.json'); +const value = (p) => { const v = p.split('.').reduce((o, k) => (o == null ? undefined : o[k]), m); return v === undefined ? undefined : (typeof v === 'number' && !/_id$/.test(p) ? v.toLocaleString('en-GB') : String(v)); }; +let spans = 0; +for (const f of readdirSync(site).filter(f => f.endsWith('.html'))) { + const html = readFileSync(join(site, f), 'utf8'); + for (const [, p, text] of html.matchAll(/([^<]*)<\/span>/g)) { + spans++; + const want = value(p); + if (want === undefined) fails.push(`${f}: data-rm="${p}" names no manifest value`); + else if (text.replace(/&/g, '&').replace(/</g, '<') !== want) fails.push(`${f}: data-rm="${p}" carries "${text.slice(0, 60)}", the manifest says "${want.slice(0, 60)}" (rebuild the site)`); + } +} +if (spans < 10) fails.push(`only ${spans} data-rm spans on the committed pages; the status pages read the manifest`); +const raw = readFileSync(join(site, 'release-manifest.json'), 'utf8'); +for (const pat of readFileSync(join(root, 'tools', 'ci', 'forbidden-strings.txt'), 'utf8').split('\n').filter(l => l && !l.startsWith('#'))) + if (new RegExp(pat).test(raw)) fails.push(`manifest: forbidden string ${pat}`); +if (fails.length) { console.error(`release-manifest check: ${fails.length} fault(s)\n ${fails.join('\n ')}`); process.exit(1); } +console.log(`release-manifest check: manifest ${m.generated}, ${Object.keys(m.versions).length} platform versions match downloads.json, proof ids match the ELF manifest, /release.json served, ${spans} data-rm spans carry the manifest's values`);