igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

Merge GitHub master 40a7fbe0 into the mirror's master (diverged while GitHub is suspended: the shipper's ship-docs merges on the mirror, the site and ca3 landings on GitHub; the union, so the mirror's master is the one line GitHub's master takes when it lifts)

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

# Conflicts:
#	docs/plans/release-0.3.21.md
This commit is contained in:
igneum-labs 2026-10-07 18:05:45 +00:00
commit 4730571d25
327 changed files with 25006 additions and 19789 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

62
docs/analysis/ca3-v4-uniform.md Normal file
View file

@ -0,0 +1,62 @@
# AP-F8-1 under the windows-union model: the hot set is the load source, not the window (7 October 2026)
Branch `ca3-v4-uniform` from master b92a5fd4, worker "v4-hash", on the attack-pass finding AP-F8-1 (`docs/analysis/attack-pass/f8-uniform.md`, branch attack-pass; logs `/srv/builds/igneum-wt-attack/target-attack-f8/log/`). Main's rulings bound this file: no generator change to class v4 on the live devnet; the analysis and its harness only. Every GPU-free number here is arithmetic on F8's logged counts or a run of the static census tool `tools/ca3-v4-uniform/` on igneum-build-1 (built through `tools/build-remote.sh`, rule R1); the chip figures are the terms of `docs/analysis/chip-model-v3.md` and are approximate.
## 1. The null F8's numbers must be read against
Layer 8 (`docs/plans/era-layout.md` 1.4, spec 01 1.13.1 as proposed) gives every load site a window draw `k_off = below(3)`: the site reads the whole dataset, an aligned half or an aligned quarter, at a 2^26-word floor. A quarter-window site concentrates its reads 4x on its quarter and a half-window site 2x on its half, by design; the union of the 16 windows is the whole dataset. For p1 (the devnet epoch-0 program, id c120d7963abdcd96) the 16 draws `0:2:1 1:1:1 2:1:1 3:1:1 4:0:0 5:1:1 6:0:0 7:2:2 8:1:1 9:1:1 10:2:0 11:0:0 12:0:0 13:0:0 14:2:0 15:1:1` (site:k:offset) give an expected read density by quarter of 3.25 : 2.25 : 5.75 : 4.75 sixteenths of the flat mean, which at 2^26 nonces (512 reads per item flat) is 416, 288, 736 and 608 reads per item. The top-f share of a Poisson mixture with those means (`uniform-model.txt`, exact Poisson for p1, a normal approximation for the census):
| Share of all reads on the top f of items, 2^26 nonces | Flat Poisson (F8's control) | Windows-union model, p1 | F8 measured, p1 | Beyond the window model |
|---|---|---|---|---|
| f = 0.1 percent | 0.115 | 0.160 | 0.520 | +0.36 |
| f = 0.5 percent | 0.565 | 0.784 | 1.515 | +0.73 |
| f = 1 percent | 1.120 | 1.553 | 2.495 | +0.94 |
So the window model moves the null from 0.115 to 0.160 percent at f = 0.1 percent (1.39x, not F8's 4.05x) and from 1.12 to 1.55 at f = 1 percent; it explains the 64-item-bucket sigma of p2 that F8 already attributed to the window layer, and it explains every per-site attribution row of p1 except one: sites with a half window over the hot region land 0.20 percent of their reads in the top 0.1 percent (sites 1, 2, 3, 5, 9 at 0.201), quarter-window sites 0 or about 0.4 (sites 0, 10, 14 at 0.000, site 7 at 0.241 straddling), whole-dataset sites 0.10. Site 15 lands 6.374 percent. The excess over the model (+0.36 at f = 0.1 percent) is one site.
## 2. The 153x item is the load source, and the model predicts it to the item
p1's site 15 is the load at instruction 63 (`load dst=3 src=6`, window half 1). Its source r6 was last written at instruction 61: `or dst=6 src=4` (`r6 |= r4`, `verify.rs` Op::Or), after a fresh dataset load into r6 at 47. An OR of two near-uniform registers sets each bit with probability 3/4, so the source takes the all-ones value with probability (3/4)^32 = 1.0e-4 per read and the values of popcount 31, 30, ... with 32, 496, ... times (3/4)^k (1/4)^(32 - k). The era map `y = rotl(x * 0x9ad30d99, 29)`, the half window and the interleave split (`memhard::Layout::split`, positions 0, 2, 12, 13) send x = 0xffffffff to item 0xca5b92: F8's hottest item exactly. F8's next seven items (0x8a5b92, 0xaa5b92, 0xba5b92, 0x825b92, 0xe65b92, 0x985b92, 0xbcc392) are exactly the seven one-zero-bit sources whose zero bit survives the window mask (bits 29, 28, 27, 26, 25, 24 and 15): 7 of 7. The measured count fixes the bit bias: 78,479 reads of 2^26 x 8 site-15 reads is p^32 at p = 0.7585 (r4 is slightly biased itself), and at that p the popcount model predicts 77,348 all-ones reads and 4.86 percent of site 15's reads into the top 0.1 percent of items (measured 6.37; 3.92 at p = 3/4). Per hash that is 4.86 / 16 = 0.30 percent of all reads, and 0.160 + 0.30 = 0.46 against F8's 0.520 at f = 0.1 percent; at f = 1 percent 14.5 / 16 = 0.90, and 1.55 + 0.90 = 2.46 against 2.495.
The same arithmetic for the other lossy writers (`uniform-model.txt`): a `mul` last writer zeroes the low bits by the operands' trailing zeros, so 1.07 percent of the site's reads land on the 0.1 percent of values with 10 or more trailing zeros (p2's `mul`-sourced sites 0 and 14 measured 0.971 and 0.966 percent); a `mulhi` last writer is dense near zero, 0.79 percent on the lowest 0.1 percent of values. An `or` whose operand was itself last written by `or` compounds the bias (3/4 to 7/8 to 15/16): p3's site 15 (`or` at 30, the load at 62) puts 72.4 percent of its reads into the top 0.1 percent, 4.6 percent of all reads on 16,777 items.
This is a fault class, not the window model: the acceptance rule's part (a) (`accept.rs` check_stale_loads) takes any write as a fresh source, and part (c)'s saturation count looks at the 16,384 final register values, not at a load's source mid-program, so an `or`, `mul` or `mulhi` as a load's last writer passes. The per-hash distinct-address check still holds (p1 127.999 items per hash; p3 127.97: a saturated site repeats its item inside a hash), and the acceptance rule's floor of 120 distinct of 128 admits exactly one site repeating its item in all 8 iterations and no more.
## 3. How common it is: the static census (`tools/ca3-v4-uniform`, 1,024 chain-shaped class v4 programs plus F8's p1 to p3)
For every load site, the op that last wrote its source in execution order (base instructions before it, else the shadow block of the previous iteration, else the base instructions after it): injecting (add, sub, xor, mad, shfl, load), bijective (rotl, rotr) or lossy (or, mul, mulhi). Run on igneum-build-1 (`uniform-census.txt`, binary sha256 ce9f83fe... then the narrowed chain rule).
| Census over 1,024 programs | Count | Share |
|---|---|---|
| Load sites by last writer: injecting / bijective / lossy | 11,368 / 2,121 / 2,943 of 16,432 | 69 / 13 / 18 percent; 2.87 lossy sites per program |
| Programs with at least one lossy-sourced load | 992 | 96.6 percent |
| ... with an `or`-sourced load (p1's class, 0.30 percent of all reads per site) | 498 | 48.5 percent |
| ... with an `or`-of-`or` chain (p3's class, about 4.5 percent of all reads per site) | 50 | 4.9 percent |
| ... with a `mul`-sourced load (0.067 percent per site) / a `mulhi`-sourced load (0.049) | 751 / 661 | 73.1 / 64.4 percent |
| Predicted S_0.1 percent (window model plus the lossy sites): median / 90th / 99th / max | 0.45 / 0.88 / 5.29 / 9.82 percent | against the window model's 0.115 to 0.251 |
| p1 / p2 / p3 predicted against F8 measured | 0.579 / 0.323 / 4.72 | 0.520 / 0.272 / 4.60 |
F8's proposed gate (the top 0.1 percent within 1.2x of the window-model control on every one of 64 seeds) fails 96.6 percent of today's programs, because any lossy-sourced site alone exceeds it (0.16 + 0.05 at the least); it is a generator change in a gate's clothing. A 2x bound fails 69.7 percent, 3x 48.9 percent; a bound of S_0.1 percent at or under 1 percent of all reads fails 6.9 percent (the `or` chains and the multi-`or` programs). The static rule "no load whose source's last writer is `or`" fails 48.4 percent; "no lossy last writer" 96.6 percent.
## 4. What the skew is worth to a chip (chip-model-v3.md terms, approximate)
A hot-set cache of the top 0.1 percent of items is 16,777 items x 64 B = 1.07 MB of SRAM, 0.53 mm^2 and $0.25 at 0.49 mm^2 and $0.23 per MB. It serves 0.52 percent of p1's reads (0.16 of them the window model's), 4.6 percent of p3's. The hash is latency-bound on its dependent reads, so a read served on die is time saved: a chip gains at most 1.005x on p1 and 1.048x on p3 from the cache. The ceiling under the live rule: part (c)'s 120-of-128 floor admits one site repeating its item in all 8 iterations and no more (two saturated sites fail it), so at most 8 of 128 reads, 6.25 percent, can sit on a constant item, and a chip's edge from this whole class is at most 1 / (1 - 0.0625) = 1.067x, in 64 bytes of SRAM, on the hours whose program carries such a site. The public claim rests on 2x margins (chip-model-v3.md); 1.067x does not move it, and the union of the windows is still the whole dataset every hour, so no window-level cache exists. What moves: per tier nothing in rate or watts (the honest card reads the hot item from L2 as the chip would), and the 5 percent rule of 2.0 is untouched.
## 5. The two options for the flip, priced (main's ruling 3; nothing ships on this without the project lead's word)
| Option | What changes | Cost | Risk |
|---|---|---|---|
| A. A class amendment in 0.3.19 before the flip: the generator draws a load's source from the registers whose last writer injects (or rule (a) tightened to the same), class v4 re-pinned | a new program stream: new vectors, the seven gate packs re-exported, the six gates again (the hash side G1 to G3 and the verifier re-run here in about an hour of Mac and PC 2 time; G4 to G6 the node lane), every node before the flip by the one-box-at-a-time fleet rule | hours of gate time, a fleet rollout, the 0.3.19 ship on the line | a node that misses the build splits the chain at the flip; the fix itself is small (one draw rule) |
| B. Hold v4 at the floor as it is; the source rule in class v5 | nothing on the devnet; the attack-pass record carries the window null and the bound | a hot set on 48 percent of hours worth up to 1.005x to a chip, on 5 percent of hours up to 1.05x, 1.067x at the rule's ceiling, no chain risk | the public line must state the bound, not "uniform" |
The number that decides it: 1.067x at the ceiling against the 2x margin of the chip claim. Recommendation: B, with the v5 item below, unless the project lead wants the tail tight now.
## 6. The acceptance bound for the next class (main's ruling 4)
Definition: for a program, H = W_0.1(windows) + sum over load sites of h(last writer of the source), with W from the Poisson mixture of the 16 window draws (0.115 to 0.251 percent at 2^26 nonces) and h = 0.30 percent for `or`, 4.5 for an `or` chain, 0.067 for `mul`, 0.049 for `mulhi`, 0 for an injecting or bijective writer (the figures of section 2 at the measured bias). The bound: H at or under 1.2 x W, which is the static rule "every load's source was last written by an injecting op or a rotate" (any lossy writer breaks 1.2x). Its cost as a rejection rule on today's stream: 96.6 percent of candidates, about 30 attempts per seed on average. The cheaper form is a generator draw, not a rejection: draw a load's source from the registers whose last writer injects (today's rule draws from every written register), which costs no attempts and leaves rule (a) as it is. Either way the 64-seed census of F8's phase E is the gate, with the dynamic check extended to count saturated load sources over the 64 units beside the final values.
## 7. What is unverified
- The per-site h figures are the popcount and trailing-zeros models at the biases F8 measured on p1 and p2; p3's chain figure is F8's measurement, not a model. F8's phase E (64 seeds, dynamic) is the test of the whole table.
- The window model's top-f shares for the census use a normal approximation per quarter (p1's exact Poisson 0.160 against 0.159).
- No GPU run and no timing here; every number is a count or arithmetic.

86
docs/analysis/era-vdf-2026-10-07.md Normal file
View file

@ -0,0 +1,86 @@
# The era VDF: built, measured and gated (7 October 2026)
Era VDF lane, 7 October 2026, from the attack pass's F7 row (`docs/analysis/attack-pass/f7-era.md`, sub-row a: the node's era seed was a plain chain block hash, grindable with one block of hash at no delay, and the 1-hour VDF of spec 04 section 4.4 did not exist in the node). Repository branch `era-vdf` (this record, the spec text, the harness `tools/era-vdf/`, the fast-time fields); node fork branch `era-vdf-node` on the 0.3.19 line (`release-0.3.19-node` dc141409). Every number below names its log on igneum-build-1 under `/srv/builds/igneum-wt-era-vdf/ev-*/`.
## 1. What was built
| Piece | Where | What |
|---|---|---|
| The integer | `consensus/core/src/era_vdf/bigint.rs` | a fixed-width signed integer (40 limbs, 2,560 bits) on the stack: add, sub, mul, shifts, Knuth division with floor, truncated, exact and Euclidean remainders, the extended gcd and the partial extended gcd with Lehmer's word steps (chiavdf `xgcd_partial.c`), modpow, sqrt and the fourth root, Miller-Rabin with the first 30 primes as bases; every operation checked against `num-bigint` on 20,000 random operands of the class group's sizes, the known-failed shapes first |
| The class group | `era_vdf/classgroup.rs` | `proto-vdf/src/classgroup.rs` (3 October 2026) on the fixed-width integer: NUDUPL and NUCOMP ported line by line from chiavdf's `qfb_nudupl` and `qfb_nucomp`, the plain duplication and Cohen 5.4.7 kept as the oracles the tests hold them to on random forms at 256, 512 and 1,024 bits; serialization as sign byte plus fixed width, 258 bytes a form |
| Wesolowski | `era_vdf/wesolowski.rs` | eval with serialized checkpoints (at most 2^16, 17 MB), the 12-bit-digit block prover bucketed per residue class and parallel over them, the naive prover as the oracle, verify; T + 1, another y, another pi and another input refused |
| The hash chain | `era_vdf/hashchain.rs` | scheme 1: T sequential SHA-256 applications from a tagged start; verification by recomputation; one step short refused |
| The scheme byte and the seed | `era_vdf/mod.rs` | `vdf_scheme` 0 and 1, `EraVdfProof` and its wire form, `era_vdf_input` (the chain's BLAKE2b keyed `IgneumEraVdfInput` over `chain_id || n || the day's blue hashes`), `era_seed_of` = SHA-256 of the scheme byte, the input, T and y |
| The switch | `consensus/core/src/config/params.rs`, `igneum.rs` | `pow_era_blocks` and `pow_era_lead` as override fields (the constants everywhere; in the digest when they differ), `era_vdf_activation_daa` (never), `vdf_scheme` (0), `era_vdf_t` (the reference T); the three in the digest once the activation is set (the 0.3.15 rule); installed with the PoW schedule |
| The node side | `consensus/src/processes/era_vdf.rs`, `model/stores/era_vdf.rs` | the cut rule (the chain block below the cut, memoised and re-validated by reachability), the day-of-blues input (memoised per cut block), the evaluator thread started by the virtual processor a quarter of the lead past the cut, the record store (one row per era), the header processor's wait when a header arrives before the record, the template's `era_seed` None while evaluating, `submit` for a record from outside (verified against this chain's input) |
| The template and the miner | `PowEpochInfo`, `RpcPowEpochInfo`, `rpc.proto` fields 37 to 44, `igneum-miner` | the era schedule, the VDF's state, scheme, T and input in every template; the miner holds while the node reports no era seed ("era VDF: the node is still evaluating"); `igneum-miner vdf bench|eval|verify` with the node's own code |
| The harness | `tools/era-vdf/reroll.mjs` | the F7 re-roll harness against the REAL era cut (era 120 DAA, lead 20 on the merged fast-time file; ports 30100 and up, suffix 1010), `--vdf off` the stand-in, `--vdf on` the VDF at a fast T, the adversary running the node's evaluator over its candidate before publishing |
## 2. The parameters
Measured 7 October 2026 on igneum-build-2 (AMD EPYC 9454P, 96 threads, Ubuntu 24.04), one core under `/srv/builds/_bin/lease cores 31` at nice 10 while the box ran other lanes' suites (load 25 to 75), with the node's own code (`igneum-miner vdf bench`, logs `ev-vdf-bench3.log`, `ev-vdf-bench5.log` in this lane's scratch) and chiavdf 7e62ce14 built on the box against GMP 6.3.0 (`ev-chiavdf`).
| Parameter | Value | Label |
|---|---|---|
| Group | class group, 1,024-bit prime discriminant `D = -HashPrime("igneum-era-discriminant" \|\| input)`, `\|D\| = 7 mod 8` | Implemented (spec 4.2) |
| Generator, Fiat-Shamir prime, proof plan | `(2, 1, (1 - D) / 8)`; 256 bits; 12-bit digits, at most 2^16 serialized checkpoints (17 MB) | Implemented |
| Proof on the wire | 529 bytes: scheme (1), T (8), two 258-byte forms with 2-byte lengths; `y` and `pi` 258 bytes each | Measured |
| Scheme byte | `vdf_scheme` 0 = class group, 1 = hash chain; genesis 0 everywhere | Implemented |
| Reference rate, scheme 0 | 30,589 and 40,117 squarings/s in two 10-s runs on the box core (the spread is the box's load); 30,000 is the reference | Measured |
| `T_era`, scheme 0 | 3,600 x 30,000 = 108,000,000 squarings (`ERA_VDF_T_CLASS_GROUP`): 60 min at the reference, 45 at the faster run | Measured, set |
| Prove, scheme 0 | eval + prove 11.6 s at T 401,167 (eval 10.0 s): the single-thread block prover is about 14 percent of the evaluation, parallel over residue classes in the node (up to 8) | Measured |
| Verify, scheme 0 | 21.9 and 22.6 ms with the group held (mean of 20); 184 ms with the discriminant derived, the derivation being 161 to 167 ms, once per era | Measured (section 5 for the gate) |
| Reference rate, scheme 1 | 16.2 and 17.0 million SHA-256/s (SHA-NI); 16,000,000 is the reference; `T_era` = 57,600,000,000 hashes (`ERA_VDF_T_HASH_CHAIN`) | Measured, set |
| Verify, scheme 1 | recomputation: 10.1 s for T 170 million, the full hour at `T_era` | Measured |
| Discriminant search | 161 to 167 ms per era (Miller-Rabin with the first 30 primes on the fixed-width integer) | Measured |
| chiavdf on the same core | 208.8 K squarings/s (`vdf_bench square`, NUDUPL over GMP, 1,000,000 iterations); the AVX-512 IFMA path (`square_asm`) gave 127.3 K at 20,000 iterations and stalled at 300,000 and above in this build (built outside its Makefile's `FAST_MACHINE` flags), so the IFMA number is not established here | Measured; the asm path unestablished |
| Delay on the fastest prover measured | 108,000,000 / 208,800 = 517 s against the 1-s block interval (517x) and the 2-s publish window (259x); a prover 10x chiavdf's GMP path (the ceiling Chia's and the EF's hardware efforts aimed at, approximate, from memory) would still take 52 s, 26x the window | Computed from the measurements |
| The gate "at least 60x one block interval on the fastest known prover" | 517x on chiavdf's GMP path, the fastest evaluator measured on this hardware; PASS as measured, with the IFMA path unestablished (above) and the 10x hardware ceiling still 52x | PASS (measured), caveat recorded |
The node's own evaluator is 5.2 to 6.8x slower than chiavdf's GMP path on the same core. That ratio only moves the honest side: `T_era` is set from the node's rate, so an honest node finishes in the hour; the attacker's margin is the delay at the fastest prover, above.
## 3. The gate: the re-roll harness with the VDF off and on
`tools/era-vdf/reroll.mjs` on igneum-build-2 (the box under other lanes' suites, nice 10; logs and per-cut JSON under `/srv/builds/igneum-wt-era-vdf/ev-harness-out/reroll-vdf-{on,off}-5.json`), three nodes of the fork at this record's commit on the fast-time file with `skip_proof_of_work`, era 120 DAA and lead 20 (cuts at `S = 120 n - 20`, one every two minutes), ports 30100 and up, suffix 1010; two honest virtual miners share 1 block/s on nodes 0 and 1; the adversary on node 2 holds a block A built on the tip at `S - 1` and tries to make it the era's cut block. With the VDF on, the adversary runs the node's own evaluator (`igneum-miner vdf eval`, the network's T) over its candidate before publishing; T is set from a 3-s bench at the start so the delay is about 5 s on one core of this box, five times the block interval.
| Run | Switch | Cuts | A accepted | A became the cut block | Known-draw re-rolls (the seed the adversary knew before publishing is the era's seed) | Adversary's evaluation | Nodes agree on the era seed | Gate | Harness |
|---|---|---|---|---|---|---|---|---|---|
| vdf-off-5 (the stand-in, 15:08 to 15:22 UTC) | `era_vdf_activation_daa` never | 6 (eras 2 to 7) | 6 of 6 | 6 of 6 | 6 of 6: the seed is `hash(A)` every time | none needed: the draw of hash(A) is known the instant A is built | 3 of 3 on every era | FAIL (the known-pass fires) | SOUND |
| vdf-on-5 (the era VDF, 14:54 to 15:08 UTC) | activation 0, scheme 0, T 189,650 (5 s on this core) | 6 (eras 2 to 7) | 6 of 6 | 0 of 6 | 0 of 6 | 5.38 to 6.64 s, during which the honest chain advanced 3 to 10 blocks; A arrived behind them and never became the cut block | 3 of 3 on every era, the record ready (state 3) at every era start | PASS (silent) | SOUND |
What the two runs say. Under the stand-in a miner with one block of hash at the right second owns the era draw outright on this network: holding the block at `S - 1` and publishing it the moment the chain reaches `S - 1` makes it the cut block in every one of six cuts (the attack lane's epoch-cut run saw 1 of 6, with the honest block often landing first; here the adversary is faster to the second), and its draw is known the instant the block is built. Under the VDF the same adversary cannot know any candidate's draw before T steps have run; while it ran them the honest chain moved 3 to 10 blocks, so its block arrived behind the cut and the seed came from the delay over the day of blues ending at the honest cut block, the same on all three nodes. The second half of the written argument of F7 (a) holds in the node, not only on paper: the re-roll needs the draw inside the window, and the window is 1 s against a delay of 5 s here and 517 s at the fastest prover measured on the production T (section 2).
The known-pass and the known-fail ran on the same binaries, file and ports, the VDF switch the only difference. A first VDF-off run with a lookup defect in the harness (the adversary's block not found, so the verdict read "held") was discarded once the node's own log showed the adversary's hash as the cut block in 5 of 5 cuts; the harness now reads A from that log line. Two runs that overlapped on the box through a stale node of an earlier run were discarded as well (their nodes disagreed because they were two networks); the two runs above ran alone.
## 4. The cut rule and the certified checkpoint (for the finality lane)
The node names `C_era(n)` as the last selected-chain block below the cut on the header's own chain (the block the stand-in used), which is the checkpoint block the lead rule names under the O-4.3 decision of 3 October 2026 (certified or not). Three facts decide it:
1. Determinism. A header's validity must be a function of its own past. "The certificate carried by a block in the header's past, for the highest-index checkpoint with DAA score at most the cut" is such a function, but a certificate that lands after the era starts flips the reading between headers of one era (a header before the carrier reads the fallback, a header after it reads the certificate), so the certified binding needs a second rule: the carrier must sit at most half a lead above the cut (3,600 DAA s, the merge depth) and be a chain ancestor of the header; under that rule every honest header of the era reads the same certificate once the network merged the carrier, and a header on a chain that never merged it reads the fallback, consistently with its own past. The chain-block reading needs no second rule.
2. Liveness. A finality pause across the cut (a third of weight leaving in an hour is a 30-day pause under rule v3) leaves the certified binding without a checkpoint for the era; the chain-block reading always has one, which is the reason O-4.3 was decided the way it was for the epoch.
3. The defence. The grinding defence is the delay: no candidate's draw is knowable for T steps, whichever block is the cut. The binding moves which block a withholder would have to be the author of, not whether withholding pays; both readings leave the withholder with a coin flip it cannot see.
The change, if the finality lane wants the certified binding: `EraVdfManager::cut_block` (one function; the input, the delay and the seed are unchanged), plus the second rule above and a test with a certificate carried late.
## 5. The verify gate on a 2019-class core
The gate was "the VDF verifies in under 10 ms on a 2019-class core". Measured: 21.9 and 22.6 ms with the group held on the box core (above), which the F6 row's calibration puts at about 1.19x on an i7-9700K (the O-1.14 run: 6.0 ms on the 2019 core against 5.06 ms on the box proxy), so about 26 ms on a 2019 core, labelled a proxy: no 2019 host was rented this lane (Vast rentals are a purchase; not made without the project lead's word). NOT MET, by 2.2x on the box and about 2.6x on the proxy.
Where the time goes and what closes it: a verification is two 256-bit exponentiations, about 770 group operations at 28 µs each; the operation is NUDUPL on the fixed-width integer, whose cost is the extended gcd (Lehmer rounds on 8-limb numbers) and the reduction. Three rounds of this lane moved it from 345 µs (a Lehmer convention defect that fell back to plain division every round) to 28 µs (the convention, i64 word division, 34 limbs, the x86-64 128-by-64 division); the next 2.2x is chiavdf's Pulmark reducer (reduce only when `a` exceeds 8 limbs, O-4.6) and a limb-level NUDUPL that keeps the partial gcd's intermediates in words, or GMP through `rug` behind a feature on the x86-64 Linux and Windows builds (chiavdf's 208 K/s is 6x this evaluator, which would put the verification near 4 ms as the prototype measured), with the fixed-width path the fallback for wasm and macOS. Owed, not blocking: the verification runs once per era (180 days) on a node that imports a record rather than evaluating; every mining node evaluates and never verifies.
## 6. Consequences per tier (the standing rule of 5 October 2026)
| Tier | What the era VDF costs | What it means |
|---|---|---|
| A home miner, any card (8, 12, 16, 24 or 32 GB), any vendor, Windows, Linux or macOS | one CPU core for about 60 min once per 180 days at the reference rate (a 2019-class desktop core about 72 min by the F6 calibration), 17 MB of host RAM for the prover's checkpoints during it, 0 bytes on the card; the node starts it a quarter of the lead past the cut and holds the record from then | nothing changes on the card or in the hash rate; the 2-hour lead covers a core half the reference speed; a node that was off across the cut evaluates on arrival and its miner holds until the record lands (the miner says so every 10 s) |
| A rig (one node, several cards) | the same one core on the rig's host, once per era | nothing per card |
| A pool user | the pool's node evaluates; the member's miner takes `era_seed` from the template as today | nothing |
| A light client or a syncing node | verifies an imported record in 22 ms (26 ms on a 2019 core, proxy) plus the 165-ms discriminant derivation, once per era; under scheme 1 it recomputes the hour | the 10-ms gate is missed (section 5); operationally one verification per 180 days |
| The protocol | the era draw's input is unknowable for 517 s on the fastest prover measured, against a 1-s block interval: the stand-in's one-block grind is closed (section 3) | the freeze of the draw procedure and the C_era cut rule no longer waits on the VDF's existence; it waits on the two decisions of `ledger-decisions.md` |
## 7. What is owed
- The P2P relay of an era record to a syncing peer and the RPC import (spec 4.5, O-4.10), before era 1 of any network with the switch set.
- The external review of the class-group port (O-4.1): the port is a second implementation checked against the textbook algorithms and `num-bigint`, not a review.
- The attack pass's F7 status row (branch `attack-pass`, `docs/analysis/attack-pass-2026-10.md`) reads INCOMPLETE pending this lane; the line for it, from section 3: "F7 (a): the era VDF is in the node (fork `era-vdf-node`); the re-roll harness against the real era cut fires with it off (6 of 6 cuts, the seed the adversary's block) and is silent with it on (0 of 6 across six cuts, the adversary's 5-s evaluation against a 1-s block interval, three nodes agreeing on every era seed); PASS, the delay 517 s on the fastest prover measured at the production T."
- The decisions of `docs/plans/ledger-decisions.md` (the activation per network, the cut's binding).

29
docs/bench-log.md
View file

@ -2652,3 +2652,32 @@ in the same shape and reports a box behind its wanted binary.
| Rig | the same, and a rig that leaves is itself a weight removal: at 459 MH/s on tonight's devnet it is about 20 percent of the weight, over the hour's budget by itself |
| Pool | a pool node is one voter carrying its members' whole weight; a pool restart is the largest single removal on the network and must be sliced like the fleet's |
| The network | finality by miner weight is only as steady as the miners' uptime; until public hash dwarfs the fleet, the fleet's supervisor is a consensus component |
## 7 October 2026, the first 16 GB card: an RTX 5060 Ti in a Thunderbolt enclosure on PC 2 (branch bench-5060ti)
Machine: PC 2 (`1ccfe586`, Windows 11), an ASUS Dual GeForce RTX 5060 Ti (16 GB GDDR7, Blackwell sm_120, PnP `PCI\VEN_10DE&DEV_2D04&SUBSYS_8A111043`) in a Razer Core X V2 Thunderbolt enclosure ("USB4 Router (2.0), Razer - Core X V2", bus `0B:00.0`), beside the RTX 5090 on its own supply; NVIDIA driver 610.47 (WDDM 32.0.16.1047, the 5090's driver, nothing installed for the new card); the installed app 0.3.19 and its own `igneum-worker-cuda.exe` (NVRTC 12.8). Jobs `fetch-5060ti-packs-20261007` (the kit: `tools/bench-5060ti/make-kit.sh`, the class v4 pack at sub-version 1 and the v3 control, sha256 `fd8393ed...`, 105,892 bytes) and `run-5060ti-bench-20261007-b` (`tools/bench-5060ti/pc2-5060ti-bench.ps1`, 14:44:19Z, ran 14:45:05 to 14:58:11Z, exit 0; the 5060 Ti alone through the runner's `--cards-off`, the 5090 mining throughout; run `-a` died in 1 s on an argument-binding fault in the nvidia-smi query and is void). PC 2 lost power twice that day, so the job WRITES NO POWER LIMIT: it reads `power.limit` against `power.default_limit` (180 W = 180 W, range 150 to 198 W) and the row says `limit_is_stock=yes`. Read back with `node tools/jobs.mjs run-5060ti-bench-20261007-b`.
**Detection** (the app's first poll after the restart, run `win-1ccfe586-20261007-143611`, 14:36:16Z): `GPUs: NVIDIA GeForce RTX 5090 (CUDA); NVIDIA GeForce RTX 5060 Ti (CUDA); AMD Radeon(TM) Graphics (OpenCL, gfx1036)` and `cards: NVIDIA GeForce RTX 5090 [discrete, off] | NVIDIA GeForce RTX 5060 Ti [discrete, off] | ...`; the app started a miner on it by itself (`nvidia-1ccfe586-2`, `--device 1`, 8 identities, the default). The kind reads `discrete`, not `external`: the app does not know it is an eGPU. nvidia-smi in the job: index 1, 16,311 MiB, PCIe link gen 4 x4 current against gen 4 x16 maximum (the Thunderbolt link: a quarter of the slot's lanes), 43 C idle. The freeze lane's cause class for the 15:10 UK hang on the first boot with the card: not the card (no TDR, no Thunderbolt or PCIe link event; Kernel-Power 41 + 6008, no bugcheck, the power shape again).
**G1 and the window** (the installed CUDA worker, `--bench --batch-log2 24 --block-warps 1`, the card alone, `CUDA_VISIBLE_DEVICES` on its UUID so every row names the device; nvidia-smi every 2 s on the card, the loaded samples at utilisation 90 percent and over):
| Pack | Dispatches of 2^24 | Self-test | Fingerprint 2^24 at base 0 | MH/s |
|---|---|---|---|---|
| mx8-devnet-epoch0 (the class v3 control) | 5 | PASS | 90f794dd556f7a3b (= the control everywhere) | 30.895 |
| v4-devnet-epoch0 (class v4, sub-version 1, program id 1a4230699a6b9c60) | 5 | PASS | 867dbc45cfb36b4d (= Metal, Apple OpenCL, the RTX 5090) | 30.879 |
| v4-devnet-epoch0, the 10-minute window at the stock limit | 1,105 (602 s) | PASS | 867dbc45cfb36b4d | 30.882 |
| Row | Value |
|---|---|
| NVIDIA RTX 5060 Ti 16 GB, class v4, CUDA (NVRTC), driver 610.47, PCIe 4.0 x4 through the enclosure | 30.9 MH/s over 10 minutes on the card alone |
| Watts at the stock limit (180 W default, unchanged) | 114.8 W mean, 115 W p50 over the window; 0.269 MH/W; SM 2,753 MHz, memory 13,801 MHz, 60 C maximum |
| The class v4 shadow against the control | 0.1 percent (the 5090 paid 0.2, the 9070 XT 3, the B580 0.1) |
| The efficient point | OWED to the app's Ember Tune: nothing set by the job; PC 2's Power Helper refused every request since the restart ("the helper did not run sequence 0 within 15 s", 14:39Z), so no ladder ran on either card |
| Prove beside the miner (16 GB tier) | BLOCKED, not measured: the shipped WSL2 host (sha `71bc2438...`) carries no `IGNEUM_CUDA_DEVICE` selector, so aimed at anything it proves on CUDA device 0 (the 5090) through the app's own socket `/tmp/sp1-cuda-0.sock`; the selector lives in the prover-floor host (`proof_system.rs`, branch prover-floor) and is the owed cut. The job's inventory: the floor server IS on PC 2 (`/opt/igneum-floor/bin/sp1-gpu-server`, 6.8.1 build `e911facb...`, 166,665,880 bytes) beside the stock one (`~/.sp1/bin`, `c2642ad1...`), WSL sees the card as CUDA device 1 |
| Card-picker entry (`site/yourcard.js`) | `['NVIDIA RTX 5060 Ti', 30.9]`, added; the public table row in `site/miner-bench.json` |
Against the 5090 on the same PC (122 MH/s at 308 W, 0.396 MH/W): 25.3 percent of its hash at 37 percent of its draw, 68 percent of its hash per watt. The dependent-read ceiling was not probed (the memprobe step is not in this job); at 128 loads a hash 30.9 MH/s is 3.95 G dependent reads a second, between the 9070 XT (2.4 to 2.7 G) and the 5090 (16 to 18 G).
Consequences per tier (the rule of 5 October 2026): a 5060 Ti owner (16 GB, Windows) mines at 30.9 MH/s and 115 W from the box with nothing to set: about 5,100 blocks a day at the 522 MH/s the devnet showed at 14:44Z (one every 17 s, approximate: the network rate moves), about a quarter of a 5090 owner's 20,200, for 2.76 kWh a day (£0.79 at 28.5 p against the 5090's £2.11); through a Thunderbolt enclosure the x4 link costs nothing measurable (the hash is bound by the card's own memory latency, not the link; the 5090's PCIe-slot rows are the comparison), so a laptop with a Thunderbolt 4 port and this enclosure is a 31 MH/s miner. The 8 GB 5060 Ti: the same hash is the expectation (the 1 GiB dataset fits), a line owed. Proving on the 16 GB tier: the fleet's 4060 Ti 16 GB row (9.0 GB peak beside the miner on the patched server) says this card would mine and prove with about 7 GB spare, approximate until the host with the device selector ships; today the app's prover default leaves it off ("a full shard needs a 24 GB card") and the measured read is owed to the prover-floor host cut. Linux and HiveOS take the same CUDA worker (owed a line). What the lane does next: the prover-floor host's selector into the shipped WSL2 bundle, then the prove-beside read on this card; the Power Helper fault on PC 2 to the Ember lane (no efficient point on any PC 2 card until it answers).
Found on the way: inside a PowerShell `@( ... )` the comma binds before `+`, so `'--query-gpu=' + $f, '--format=csv'` is one argument (run a, void in 1 s; the query string is built first now); a bare string inside a function that also returns a value is swallowed into the caller's variable (the sampler line; `[Console]::Out.WriteLine` now); the app's `kind` for a Thunderbolt card reads `discrete` (a word for the Cards page to earn: `external`, which the state already names).

2
docs/evidence.md
View file

@ -41,7 +41,7 @@ Versions in the table: `igneum-pow` is the Rust crate at `igneum-pow/Cargo.toml`
| 14 | Ethereum bytecode runs unchanged, with the documented differences of spec 7.1 | Homepage Build card; litepaper Building | tested by the team | as row 13; fixes `F-exec-A`, `F-exec-B` (spec 7.5) | `tools/evm-smoke/smoke.mjs`: deploy via viem, `increment`, `hashLoop`, `eth_estimateGas`, `eth_getLogs`; `tools/exec-attacks` scenarios 1 and 3; bench-log "execution layer attack fixes" | Deployment, calls, reverts, logs and gas estimates behave as viem expects; chain id 4463; the prototype pgas table gives 0.0095 to 0.028 pgas per gas, below the design's band before calibration, 3 October 2026. 4 October 2026: a transaction that would cross the block's proving budget is refused by the mempool and, if forced in, aborted and charged with its nonce advanced (25 of 25 checks; 30 of 30 malformed cases). Apple M5 Max. The `Prover` precompile, proof records and the shard planner are not in the node | none yet |
| 15 | Every block is proven, with the proof landing within about a minute at launch | Homepage stats ("~60 s to a proof"); litepaper Proving; roadmap phase 3 gate | implemented | repo `d7e1f89` (GPU proof), `e01a3cc`, `292e800`, `eedd136` (`proving/igneum-prove`: shard cutter, MPT witnesses, shard and aggregator guests); SP1 6.8.1; spec 7.2, 7.6 | `proving/windows-wsl2` (SETUP-PROVER, PROVE-BLOCK) on the RTX 5090; `igneum-prove-host --mode block` on `proving/fixtures/`; bench-log "proving v0 on the RTX 5090" and "proving: devnet v4 shards" | First GPU proof of an Igneum block, 4 October 2026, RTX 5090 (WSL2, SP1 cuda, mining paused): fixture `block-78-increment` (2 transactions), core proof 1.4 s (7.3 MB, verify 0.221 s), compressed proof 2.7 s (1.27 MB, verify 0.038 s), post-state and receipts roots identical to the node's; 15.7x and 20.6x faster than a loaded M5 Max CPU. The same day on that CPU (load 38 to 47): a three-shard block proved shard by shard and aggregated by recursion, 19 min (1,139 s) end to end, 245 to 337 s per compressed shard proof, every proof verified. What is not there: no proof is produced, carried or checked on the chain (the devnet prover is a stub that signs claims), the proving pool pays nobody (row 21), the block proven is far below one shard, and the 60-second figure remains a design target; the pass mark is the standard in `docs/benchmarks/proving-e2e.md`. Second RTX 5090 run, 4 October 2026 evening (job run-20261004-173115): a full shard at the provisional S_p (6.75 M pgas, 60.8 M cycles) executed in 1.63 s, core proof 8.3 s (18.1 MB), compressed proof 10.9 s (1.27 MB, verify 0.040 s); a two-shard block (13.5 M pgas) proved shard by shard (11.7 s and 10.0 s) and aggregated in 2.2 s, 24 s of GPU stages end to end, every proof verified, six tampered witnesses rejected. The two host defects (an abort after the upload, an idle wait that turned out to be an unbuffered 18 MB proof save through the WSL2 file bridge, 24 minutes) are fixed (ledger P20) 5 October 2026, live devnet with real transactions (bench-log "real transactions, the first non-empty shard proven and paid"): block 72704 shard 0, 29 transfers, 5,800 pgas, proven on PC 2 in 34 s, verified on the Mac in 0.297 s and paid 1.7623 IGN, 53 s after the chain block executed; of about 1,400 blocks in the 20-minute window 36 were proven (the one prover takes the newest shard assigned to it), so "every block" is not yet true; a second content shard (72803, all copies skipped) failed the native-execution veto on the exporter's block structure, fixed with fixtures the same day, the node side pending the 0.3.9 rollout 5 October 2026, evening (bench-log "proving v1"): the aggregated segment record, the chain rule and the unproven rule are implemented behind `proving_v1_activation_daa` (branch proving-v1, not on the devnet before 0.3.11); on the RTX 5090 a chain of 8 consecutive live blocks proved and aggregated by recursion in 135.6 s with the miner on the card (17 s a block, one proof of 1,272,909 bytes attesting all 8, verified in 0.04 s); the 3-node fast-time harness paid a segment record 1.0 s after submission and refused a late one after its deadline (21 checks); the devnet itself, with one prover, carried proofs for 2.4% of blocks over 30 minutes at a block-to-record latency p50 44 s, p99 52 s. The "within about a minute" holds per proven block; "every block" needs 18 mining 5090s or 6 proving-only cards at empty blocks on the measured rates, and the mandatory rule stays off until the share is one | none yet |
| 16 | A 12 GB card proves one shard in about 20 s (WITHDRAWN 5 October 2026: a 24 GB card proves a full shard at the adopted size in 4.3 s; 32 GB mines and proves) | Litepaper Proving ("The proving budget"); roadmap gate 2 | designed | spec 5.1 (Target), 7.6 (`S_p` provisional, 7,500,000 pgas = `B_p` / 4) | `PROVE-SHARD.bat` on the RTX 5090 (pending); the end-to-end standard in `docs/benchmarks/proving-e2e.md`; bench-log "proving: devnet v4 shards" | Measured on a 32 GB card, not yet on a 12 GB card. A shard at the provisional `S_p` is 60.8 M SP1 cycles on the prototype pgas table (9 cycles per pgas, 44 per EVM gas; the modexp entry about 100x its SP1 cost); on an RTX 5090 (4 October 2026 evening, job run-20261004-173115) it executed in 1.63 s and its compressed proof took 10.9 s, verified in 0.040 s, so the 32 GB card is inside the 20 s target with margin. Whether a 12 GB card proves it at all, and in what time, is the next measurement (an RTX 3060 and an RTX 5060 Ti 16 GB are on order). A per-shard time can be met by shrinking the shard, so the project does not use it as a pass mark 5 October 2026, evening (bench-log "proving v1", the S_p curve): measured on the RTX 5090 with SP1 6.8.1's GPU prover, the card to itself, 1-s nvidia-smi samples: an empty shard 13,874 MiB and 2.2 s; a full shard at the ADOPTED v1 budget (30,000 pgas, 4.7 M cycles) 20,434 MiB and 4.3 s; the full prototype shard (6.75 M pgas, 60 M cycles) 28,307 MiB and 10.8 s; beside the miner 15,670 and 30,039 MiB. No environment knob of SP1 moves the 13.9 GB floor and the GPU server has no options of its own, so on this build a 12 GB card proves nothing, a 16 GB card only empty shards, a 24 GB card the adopted full shard alone and beside the miner (22,210 MiB and 13.2 s, measured on the 32 GB card: the 5090's allocation pattern, not yet a run on a 24 GB card) and a 32 GB card the prototype shard beside the miner with 2.5 GB spare. The litepaper line now says so; the 12 GB gate returns when a prover build with a smaller floor is measured on a 12 GB card | none yet |
| 17 | The chip resistance claim: the strongest chip in the public model reaches 5x to 9x per joule against an RTX 5090 today (modelled); class v4 brings it to 2.1x (k = 1) to 3.9x (k about 0.33, claimed by a withdrawn product) and its second rung to about 2.8x (modelled on measured watts); class v5 makes the dataset the chain's state so a stateless or stale chip is wrong on every item (designed, +0.2 ms verifier); the hot-set cache bounded at 1.067x at the ceiling (measured census of 1,024 programs) and the weak-day FPGA at most 12 percent on 12 days a century (measured census) are bounded and routed to the next class; datacentre silicon (H100 SXM, measured 7 October) does not change the question; a stored-dataset chip pays for itself only at about USD 100 M of market cap in two years (modelled) | The home page's chip line, the litepaper's chip model section, the miner page's line (the texts of `docs/plans/counter-asic-3-public-text-2026-10-07.md`) | tested by the team (every card, the verifier, the two attack-pass censuses, the H100), the chip itself modelled, class v5 and the ladder designed, the X9 core claimed and never measured | `docs/analysis/chip-model-v3.md` 5 and 6; `docs/analysis/latency-shadow-2026-10-06.md`; `docs/plans/counter-asic-3-status.md`; `docs/analysis/attack-pass/f8-uniform.md`, `f4-weakday.md`; `docs/design/class-v5-stored-state.md`; the H100 and market-cap rows of 7 October; `docs/plans/funding.md` (the three lots) | The chip model re-run on the measured class v3 and v4 rates, watts and verifier times; the hot-set census of 1,024 programs and the weak-day census of 2^24 days on the attack-pass branch; the H100 SXM bench row | 136 MH/s at 350 W (5090, bench) and 290 W (app); 27 MH/s at 21 W (M5 Max); 249 MH/s (H100 SXM) at 98 percent of its read ceiling, 1.78x hash, 1.15x MH/W, a third per rented dollar; 2.33 ms per warp; 5.1x to 9.2x; 2.1x, 3.9x, 2.8x; 1.067x at the ceiling; 12 percent on 12 days a century; 10.85 ms at rung 3; USD 100 M; 6 and 7 October 2026 | none yet; the three cryptanalysis lots are the next test |
| 17 | The chip resistance claim: at launch the strongest chip in the public model reaches 2.1x (k = 1) to 3.9x (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 12 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 core claimed and never measured | `docs/analysis/chip-model-v3.md` 5 and 6; `docs/analysis/latency-shadow-2026-10-06.md`; `docs/plans/counter-asic-3-status.md`; `docs/analysis/attack-pass/f8-uniform.md`, `f4-weakday.md`, `docs/analysis/ca3-v4-uniform.md`; `docs/design/class-v5-stored-state.md`; the H100 and market-cap rows of 7 October; `docs/plans/funding.md` (the three lots) | the chip model'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); 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.9x, 2.8x at launch; 1.067x at the ceiling; 12 percent on 12 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 | none yet; the three cryptanalysis lots are the next test |
| 18 | The chip resistance measurements: the program is latency-bound (random reads), not bandwidth-bound, on every card we own, and sits beyond a card's on-chip cache | Litepaper Mining ("waits on memory latency, not on maths or bandwidth"), vs RandomX; the numbers page | tested by the team | readwidth e752fc7 (`docs/plans/read-width.md`), ca2-era 78c0ee4, ca2-cache 2de19e5 (`docs/plans/hot-table.md`) | The dependent-read probes at 32 to 1,024 MiB and the hash rate per class on the three cards; the latency-bound share = rate over the probe ceiling per load | Latency-bound share at the 1 GiB dataset: RTX 5090 0.96 (v2) and 1.01 (v3), RX 9070 XT 0.87 and 0.95, M5 Max 1.01 and 1.06; wider reads do not close the AMD gap (the 9070 XT does 2.4 G dependent reads per second at every width; the 5090 goes bandwidth-bound at 64 B, share 0.58); a 32 to 96 MiB hot table is not kept resident by any card while the dataset streams (g 0.80 to 0.87 in the added form). 5 October 2026 | none yet |
| 19 | The lottery hash is sound as a hash: uniform output, deterministic, no out-of-bounds read, fuzzed; class v3 bit-exact on the three vendors | Litepaper vs RandomX ("Every number above is measured and logged"), the numbers page | tested by the team | ca2-mixer 1ab8b21 (`tests/mixer.rs`, `tests/scratch.rs`), ca2-era 78c0ee4, ca2-soundness a465881 (`docs/analysis/scratch-soundness.md`), `igneum-pow/tests/packs.rs` | The crate suite (53 + 4 + 19 + 7), the Metal fuzz, edge, stats and determinism runs on the v3 construction, the pack vectors and 2^24 fingerprints on Metal, Apple OpenCL, the RTX 5090 and the RX 9070 XT, the 1,024-hash CPU re-check per card | Class v3 (mixer x8 + era): 200-program fuzz 200 of 200 on Metal, every tenth on Apple OpenCL; the pinned v3 packs 3/3 + 3/3 and 96 of 96 lanes on Metal and Apple OpenCL; the six era packs' fingerprints equal on the three vendors (PC 1 job run-ca2-era-pc1-20261005, 5 October 2026); the v2 exports byte-identical on the v3 crate; the final-class PC rows and the G2 re-check: job run-ca2-era-pc1b-20261005 (pending at the time of writing) | none yet |
| 20 | No premine, no pre-sale, no allocation: every coin is minted by the schedule and every coin goes to the block producer (80%) and the proving pool (20%) | Homepage stats and Economics tiles; litepaper Supply, Economics | implemented | repo `6ac80a3`; fork "igneum-node devnet v0"; `consensus/core/src/igneum.rs`, `coinbase.rs` | `cargo test -p kaspa-consensus-core igneum` (8 pass: subsidy table, ramp, split, cap) and `cargo test -p kaspa-consensus coinbase` (8 pass); `igneum-miner inspect 40`; bench-log "igneum-node devnet v0" | Coinbases on the devnet: 80/20 exact on 39 of 39 single-payee blocks, the 20% to the `igneum-proving-pool-v0` output; the per-second schedule sums to under the 4,000,000,000 cap by less than 100 coins; 3,168,808,781 units per DAA second in years 0 to 2, halving at 63,115,200 DAA s. 3 October 2026, Apple M5 Max. The devnet genesis carries no allocation; the mainnet genesis does not exist yet, so the claim is about the code and the stated rule, not a launch that has happened | none yet |

31
docs/fud-ledger.md
View file

@ -299,7 +299,7 @@ Sweep (5 October 2026, evening): stated. `site/litepaper.html`, Finality ends wi
### F11. VDFs are exotic
"A class-group VDF with Wesolowski proofs in a consensus-critical path, in a project with no cryptographer. Chia needed years and still got timelord ASICs."
Status: Answered by design, with the dependency conceded.
Status: Answered by design, with the dependency conceded. Update 7 October 2026 (era VDF lane): the era VDF is in the node (spec 4.4 Implemented, behind `era_vdf_activation_daa`, never until the project lead sets it per network), on a fixed-width integer with no C library, with the hash-chain fallback behind the genesis scheme byte for the day a class group's order is computable; the attack pass's F7 harness fires against the stand-in (1 of 6 cuts re-rolled at no delay) and is silent against the VDF (0 of 6); the measured rates, prove and verify times and the margin against the fastest known prover (chiavdf's AVX-512 path on the same box) are in `docs/analysis/era-vdf-2026-10-07.md`. The timelord-ASIC point is answered by the margin table of spec 4.6: the delay only has to exceed the 2-s publish window, and it does so by orders of magnitude on the fastest evaluator measured. The external review (O-4.1) is still owed. Was: Answered by design, with the dependency conceded.
Answer: The VDF is used for one thing: making the hourly program unknowable within the roughly two seconds a miner has to decide whether to publish a block, closing a withhold-or-publish grind the review measured at about 130 to 1 for a 30% miner. The VDF input is a certified checkpoint at least one epoch before the epoch starts, so honest nodes have about 50 minutes of slack to evaluate a 10-minute VDF, and an evaluator 300x faster than reference would still be needed to beat the two-second decision window. Chia has run class-group VDFs in production since 2021, with faster hardware evaluators existing and not breaking it (approximate, from memory). The design doc lists the VDF as a new dependency and ships the evaluator in every node. The grinding simulation with and without the VDF is scheduled before gate 3.
@ -2435,6 +2435,35 @@ Same rule as the counts above. 167 entries.
The bucket "Decided or closed by rule" counts each entry once: M8, M11 and P16 move there from Answered, so Answered is 28 less those three plus M16 and E17, as the table states; the sum of the rows is 167 with M8, M11, P16 and F3, F17 counted in Decided only.
## Round 5 entry (7 October 2026, afternoon): the class v4 load-source amendment
### AP-F8-1. A load whose source was last written by `or`, `mul` or `mulhi` makes a cross-hash hot set
"The item histogram of class v4 over 2^26 nonces is not uniform: the top 0.1 percent of items take 0.520 percent of reads against 0.115 for a uniform control (4.05x), one item takes 78,479 reads (153x the mean), and site 15 feeds 6.37 percent of its reads into that top 0.1 percent in every iteration." (attack-pass row F8, `docs/analysis/attack-pass/f8-uniform.md`, 7 October 2026)
Status: Fixed on a branch, pending the 0.3.20 node ship (7 October 2026, afternoon; the project lead's word 15:2x UK: option A, "do this but limit the testing, get it pushed"): `ca3-v4-amend` a0aaca92 (the generator and the packs) and 1748fd1d (the PC 2 playbook), on origin/master 5c08c6e0 plus `ca3-v4-uniform` 095f84a7 (the analysis). The node side rides `release-0.3.20-node`; the stamp is agreed with the node lane (a283f5f0d364ceef0). Was: a finding (7 October 2026, morning).
Answer: Correct as a fault, wrong as a null. The window layer (spec 01 1.13.1 as proposed, `docs/plans/era-layout.md` 1.4) moves the uniform null from 0.115 to 0.160 percent at the top 0.1 percent (1.39x, not 4.05x) and explains every per-site row of F8's attribution except site 15. Site 15's source r6 was last written by `or r6, r4` (instruction 61, the load at 63), a non-injective op whose output bits are 1 with probability 3/4, so the all-ones source recurs with probability (3/4)^32 per read; the era map sends it to item 0xca5b92, F8's hottest item exactly, and F8's next seven items are exactly the seven one-zero-bit sources whose zero survives the window mask. The popcount model at the measured bias (p = 0.7585) predicts 77,348 all-ones reads against 78,479, and the program's top-0.1-percent share at 0.58 against 0.52. The acceptance rule's part (a) takes any write as a fresh source and part (c) counts saturation on final register values only, so the class of fault passes it: of 1,024 chain-shaped class v4 programs 96.6 percent carry a load whose source's last writer is `or`, `mul` or `mulhi`, 48.5 percent an `or`-sourced one (0.30 percent of all reads per site), 4.9 percent an `or`-of-`or` chain (p3's class: 72 percent of that site's reads, 4.6 percent of all reads, on 0.1 percent of items). The ceiling under rule (c)'s 120-of-128 floor is one site repeating its item in all 8 iterations, 6.25 percent of reads, a chip edge of at most 1.067x in 64 bytes of SRAM; the public claim's 2x margin stands, and the public line says "bounded", not "uniform" (`docs/analysis/ca3-v4-uniform.md` sections 1 to 4).
The amendment (a0aaca92): in class v4's chain draw a load's source is drawn only from registers whose last writer injects (add, sub, xor, mad, shfl, load) or is a rotate (rotl, rotr), never one last written by `or`, `mul` or `mulhi` (`generator.rs` candidate_from_words_class, keyed on the era-composed V4_CLASS; no attempts lost, rule (a) unchanged; v2, v3 and the generator-2 ladder packs byte-identical). Split protection (the node lane's form): generator stays 4 and a generator-4 program id appends `"sub/" || PROGRAM_SUBVERSION_V4 (= 1) as little-endian u16` inside `program_id()`, so a binary from before the rule and one after it never share a program id for one seed and the node's id check catches a split; packs carry `IGNEUM_PROGRAM_SUBVERSION 1` and `"sub_version": 1`, and packcheck refuses a generator-4 pack whose sub-version is absent or other. The node side (release-0.3.20-node, built to a0aaca92): kaspa-pow's test pins 1a4230699a6b9c60 must-equal and c120d7963abdcd96 must-differ through `generator::program_id` with the suffix, and the amended class signals object byte 5 in the header (CLASS_SIGNAL_V4 = 5; the tally counts byte 5 and above), so a block of the 6 October stream (byte 4) never counts towards the flip and a byte-4 node forks alone at it; object 6 is class v5's. The seven gate packs re-exported (devnet epoch 0 and eras 0 to 5): id 1a4230699a6b9c60 (was c120d7963abdcd96, pinned as the must-differ vector in `tests/recheck.rs`), fingerprints Metal = Apple OpenCL 867dbc45cfb36b4d, 2146ecacc8c75a8e, fe52602393f6d3d4, 3b206471a13912b4, c3f03c4a5d7333aa, f1dfd7209f15bb97, 8c194da64fadf31d; the v3 control 73bcbfe8ccf988f1 / 90f794dd556f7a3b untouched; the zip of the eight packs sha256 889ec99976d2728b4b5035bfa476032e5b6a13b928968fc45236d5f25084aa39.
Evidence: `docs/analysis/ca3-v4-uniform.md` (the model, the census `tools/ca3-v4-uniform`, the chip pricing); F8's logs under `/srv/builds/igneum-wt-attack/target-attack-f8/log/`; the tests limited by the project lead's word to what prevents a split and proves the fix: the vectors (the seven packs' ids and fingerprints above), the `igneum-pow` crate suite on igneum-build-1 at 8c728ca3 (`tools/build-remote.sh -- test --release`, rc 0, 77 s, 12:1x UTC: 61 lib + 7 derive + 4 mixer + 19 packs + 2 recheck + 7 scratch = 100 passed, 0 failed, the pinned v2 and v3 packs byte-identical and the v4 must-equal and must-differ ids as pinned), the pairing of the fork's kaspa-pow with this igneum-pow on igneum-build-1 (PAIRING-LINE), and one G1 run on the RTX 5090 (PC 2 job run-ca3-v4-amend-g1-pc2-20261007, 09:41:07 to 09:41:28Z, exit 0, the installed 0.3.17 worker sha256 14b6637e..., NVRTC, beside the app's miner, the prover on, the lock held 09:40:22 to 09:41:51Z): self-test PASS on all eight packs and every 2^24 fingerprint equal to the Mac's (the seven above and the control 90f794dd556f7a3b), NVRTC 188 to 332 ms per pack, the 1 GiB build 38 to 49 ms.
Sub-version 2 (7 October 2026, afternoon; main's ruling B2: 0.3.20 ships sub-version 1 as object byte 5 untouched, and sub-version 2 is object byte 7, built on this branch at 07a809a7): the attack-pass lane's F8 census on sub-version 1 (64 chain-shaped seeds, the window-model control, 2^24 nonces) read 53 of 64 PASS and 11 FAIL at 1.2x, worst p31 at 29.27x, and named three residual classes, all a constant delivered through a writer the one-writer rule admits: saturation or zero preserved through rotl, rotr or a load after a saturated load (p6, p23, p26, p31, p34), zero from mulhi (p45), and the iteration boundary (an `or` at 63 feeding a load at 1, p11); p4, p10 and p25 at 1.28x to 1.57x are the window model's own tail. (An F9 hot-set census read on the same day was withdrawn by its author: its harness drew outside the rule and its metric counted the era's designed windows as hot; F8 is the one re-gate instrument.) Sub-version 2 closes the three: the draw takes a load's source only from a register fresh by dataflow (fresh at the start; a load keeps freshness only from a fresh source; add, sub, xor, mad, shfl from either operand; rotl, rotr from their operand; or, mul, mulhi never), keyed on the class v4 shape on every draw path; rule (a') of the acceptance rule runs that freshness to its fixpoint over the loop (base then shadow block) and rejects a candidate whose load reads an unfresh register in the steady state; rule (c') counts, per load site, the source values equal to 0 or all-ones over the 64 units' 16,384 evaluations and rejects at 164 or more. The devnet epoch-0 seed's attempt 0 is rejected and attempt 1 accepted: id a788661687db4bb3 (c120d7963abdcd96 and 1a4230699a6b9c60 the must-differ pair), fingerprints Metal = Apple OpenCL e370fb2080b7dbb1, b7237555d31fc3cf, b6b167fa15dfe2c9, 28bdf65eff33f2c4, e26d38c46f3f1b16, dd8fdf6ff4f59eed, 8bf40f5cb858d835 (13:01Z), the packs zip sha256 69c36772cd79e44e2ddd589466d9c64a94a13c9e970e9f27bd76feabb9b4581b; the seven 256-block ladder packs of `packs-ca3-shadow` re-exported under the rule (their measured rates stand as the old stream's). Nothing is proposed for sub-version 2 until the attack-pass lane's two gates on 07a809a7 are green (the 64-seed census under 1.2x on every seed, the hot-set census on the chain path); its suite, pairing (after the node lane's re-pin to byte 7) and G1 lines are added below as they land. The static census (`tools/ca3-v4-uniform`, box 2, 13:12Z) over 1,024 chain-shaped seeds plus F8's p1 to p3 at sub-version 2: 0 lossy-sourced load sites of 16,432 (14,329 injecting, 2,103 bijective), 0 programs with an `or`-, `mul`- or `mulhi`-sourced load, the no-era draw path giving the devnet epoch-0 seed the pack's own id a788661687db4bb3 (one stream on every path); the cost of rules (a') and (c'): 1.99 attempts per seed on average against 0.05 before (p2's seed took five), which is 2 ms of generation per rejected attempt on one core, nothing a miner or node notices. The crate suite at 526fa757 on box 2 (`tools/build-remote.sh --box 2 -- test --release`, route line "box 2 for class suite, priority normal", rc 0, 66 s, 13:15Z): 61 lib + 7 derive + 4 mixer + 19 packs + 2 recheck + 7 scratch = 100 passed, 0 failed, the pinned v2 and v3 packs byte-identical and the three v4 ids as pinned (a788661687db4bb3 equal; c120d7963abdcd96 and 1a4230699a6b9c60 differ).
AP-F8-2 (7 October 2026, 13:xx UTC, the attack-pass lane on sub-version 2 at 07a809a7): chain-shaped seed igneum-f9/331672 exhausted the 32 attempts under rule (a') and the generator panicked, which on the chain is an epoch no node can draw, a liveness halt; the measured (a') plus (c') rejection rate of about two thirds per attempt puts the exhaustion probability at about (2/3)^32, 2e-6 per epoch seed (sub-version 1 exhausted 0 of 10^6). Main's ruling: the draw is total and no consensus path panics. Fixed at 8bdcbdd8 with the stream unchanged (re-export diff 0; the id a788661687db4bb3 and the fingerprints stand, so sub-version 2 keeps its number and the running censuses): the attempt cap of the class v4 shape is 256 (`MAX_ATTEMPTS_V4`; v2 and v3 keep 32), which puts the exhaustion probability under 1e-45 at a worst-case draw of about half a second on one core; after the cap the seed takes the last-resort program, deterministic and accepted as drawn, the candidate at attempt 256 with every `or`, `mul` and `mulhi` of the base program and the shadow block rewritten to `xor`, so every register stays fresh from the init words on and rule (a') holds by construction. The spec text for class v4 therefore reads: attempts 0 to 255 under rules (a), (b), (a'), (c) and (c'), then the last-resort program; the probability of reaching it is (r)^256 for a per-attempt rejection rate r, under 1e-45 at the measured r of about 2/3. Tests: `class_v4_draw_is_total_with_the_last_resort` (the last resort on real (a')-rejected candidates, every load fresh after it, no lossy op left, the chain path over 64 seeds without a panic, the cap per class). The 10^6-seed exhaustion count at the fixed commit is the attack-pass lane's measurement (its re-gate string is 8bdcbdd8); the 4,096-seed census with the attempt histogram (box 2, 13:33Z, `tools/ca3-v4-uniform --n 4096 --f8` at 8bdcbdd8): 4,099 chain-shaped programs, 0 lossy-sourced load sites of 65,584 (57,304 injecting, 8,280 bijective), 0 exhaustions, the accepted attempt geometric with ratio 0.674 (1,338 at attempt 0, 921, 620, 408, 274, 189, 127, 75, 55, 40, 16, 11, 12, 6, 5, then one each at 16 and 17; mean 1.98), so the measured per-attempt rejection rate is r = 0.674 and the exhaustion probability is 0.674^32 = 3e-6 under the old cap and 0.674^256 = 1e-44 under the class v4 cap. The crate suite at 8bdcbdd8 on box 2 (route line "box 2 for class suite, priority normal", rc 0, 80 s, 13:31Z): 62 lib + 7 derive + 4 mixer + 19 packs + 2 recheck + 7 scratch = 101 passed, 0 failed, the total-draw test included. G1 for sub-version 2 on a fleet RTX 5090 (main's order; the fleet lane, p1-5090, driver 580.173.02, sm_120, the box's Linux NVRTC worker `igneum-worker-cuda 1.0 (4 October 2026)` sha256 97e036e2..., which carries no program and compiles each pack's own text; the kit zip sha256 asserted before the put; 13:43:22 to 13:44:07Z): `--bench --batches 5 --batch-log2 24 --block-warps 1` on all eight packs, self-test PASS on every pack with the cache FNV 448274a57f508cbc and every 2^24 fingerprint equal to the Mac's (the control 90f794dd556f7a3b and the seven above); the rates (120 to 142 MH/s beside the box's own miner loop) are a reference only. The Windows G1 on PC 2 (job run-ca3-v4-sub2-g1-pc2-20261007b, published 13:46:33Z under the PC 2 lock, ran 13:46:36 to 13:46:50Z, exit 0; app 0.3.19, the installed worker sha256 14b6637e..., the RTX 5090 switched off by the runner's --cards-off before the script and restored on exit, igneum-worker-cuda running 0 before and after, the prover untouched): self-test PASS on all eight packs with the cache FNV 448274a57f508cbc, every 2^24 fingerprint equal to the Mac's and the fleet's (the control 90f794dd556f7a3b and the seven above), NVRTC 197 to 317 ms per pack, the 1 GiB build 22 to 34 ms, 115 to 130 MH/s with the card alone (a reference, 5 batches).
AP-F8-2, the exhaustion half, FIXED-AND-PASSED at 8bdcbdd8 on the attack-pass lane's 10^6 chain-shaped seeds through the chain path (14:03:53Z): 0 exhausted, 0 panics, 4 seeds past attempt 31 (three at 32, one at 35; 4e-6, inside (2/3)^32), max attempt 35, no seed at the last resort; r = 0.67, mean 2.0 attempts per seed.
Sub-version 2's hot-set half did not read green: F8's 64-seed gate at 39 of 64 had 8 over 1.2x of the window model (p23 4.82x, p19 3.32x, p15 2.57x, p18 2.50x, p34 1.25x; p4, p8, p10 unattributed at 1.22x to 1.50x). AP-F8-3 (7 October 2026, 14:0x UTC, the hash lane): the cause of the whole residual is that `accept.rs` never executed the latency-shadow block. Its interpreter (`run_unit`) was written for class v2 and v3 and ran the 64 base instructions per iteration and nothing after instruction 63, while the hash (`verify.rs`, the kernels) runs the shadow 27 times at the end of every iteration; so every dynamic acceptance test (c), (c') judged a class v4 program the chain never hashes. Main's word (14:1x UTC): 0.3.21 ships object byte 5 (sub-version 1); sub-version 3 is 0.3.22's and starts with this fix. Sub-version 3, first commit: `run_unit` executes the shadow block after instruction 63 of every iteration, `reps` times with the iteration's sel, as the hash does; the test `acceptance_executes_the_shadow_block_as_the_verifier_does` pins the acceptance's execution to `verify.rs` on the devnet epoch-0 program and the six test eras (the output bit counts over the 64 units equal, and different with the shadow stripped), so the two paths cannot diverge silently again; `PROGRAM_SUBVERSION_V4` = 3 (a new acceptance verdict is a new stream); the devnet epoch-0 seed still accepts at attempt 1, so its program and fingerprint are sub-version 2's (e370fb2080b7dbb1) under the new id a785001687d8688a (the must-differ set: c120d7963abdcd96, 1a4230699a6b9c60, a788661687db4bb3); the packs zip sha256 4f2445c50c58d76a5544023492d8b858d0b07c5e372d31f9c90c4ce51f829154. The class behind p23, localised from its program and reproduced in the acceptance's own execution: site 7 (instruction 38) reads r6 after 25 `mulhi r6`, 31 `or r6 |= r4`, 35 `xor r6 ^= r4`, which is `r6 & ~r4`, an AND mask the lineage rule counted as fresh because the xor's operand is the or's; over 2^20 evaluations on the closed-form words site 7 reads 874,953 distinct word indices against about 1,046,500 for every other site (0.84 of uniform; 2.2 s on one core), over 2^24 8,979,203 against about 16,260,000 (0.55; 35 s). The second sub-version 3 commit (held, prepared in the worktree) is a per-site distinct-index ratio against the uniform expectation of the site's window, its threshold set from the clean seeds' spread and its sample size from the cost line above; the dynamic bounds as first specified (a most-repeated-value bound at 16,384 and a distinct floor at 2^19.5 over 2^20) do not reach p23 and are not committed. The crate suite at ddacfbd3 on box 2 (route "box 2 for class suite, priority normal", rc 0, 41 s, 14:20Z): 63 lib + 7 derive + 4 mixer + 19 packs + 2 recheck + 7 scratch = 102 passed, 0 failed, the agreement test included. F8's final 64-seed table on sub-version 2 (the attack-pass lane, 14:2x UTC): 9 over 1.2x (p23 4.82x, p19 3.32x, p15 2.57x, p18 2.50x, p56 2.01x, p10 1.50x, p8 1.38x, p34 1.25x, p4 1.22x), the 55 clean seeds at 0.9915x to 1.144x; the 256-item bucket entropy over the window separates the strong four only (0.637 to 0.974 against a clean minimum of 0.9865 over 848 site rows), so the threshold of the second commit's distinct-index ratio comes from a run of that ratio on the 55 clean seeds at 2^20. The static census at ddacfbd3 (box 2, 14:22Z, 4,096 chain-shaped seeds plus F8's p1 to p3): 4,099 programs, 0 lossy-sourced load sites of 65,584, 0 exhaustions, the accepted attempt geometric as before (1,328 at attempt 0, 917, 622, 409, 284, ... one each at 16 and 17; mean 1.998, max 17), so the shadow-executed verdicts move a handful of seeds' attempts and nothing else; the devnet epoch-0 seed at attempt 1, id a785001687d8688a.
Sub-version 3, second commit (7 October 2026, 14:44 UTC, the hash lane; the sub-version number stays 3 and the stream is unchanged: re-export diff 0 on the eight packs, the id a785001687d8688a, the seven fingerprints and the zip sha256 stand), two rules. The shared-operand rule, in the draw's source rule and in the acceptance's (a') pass: or-then-xor or or-then-sub on one operand is `d & ~s`, xor-then-or is `d | s`, so the second write leaves the register lossy although either op alone injects; any write to either register clears the relation. On p23 the chain's attempt 1 (id d65122675f16a1c7) now draws site 7 (instruction 38) from r5 and passes; the devnet epoch-0 seed still draws attempt 1, the same program. Rule (c''), the distinct-index ratio: over 4,096 units (2^20 evaluations per site, the closed-form words, the shadow executed) every load site's count of distinct word indices against the uniform expectation on its window (N - N^2 / 2W, the window 2^28 >> min(win, 2)) must reach 0.98 (`MIN_DISTINCT_RATIO_V4`), the last test of the chosen candidate; a candidate under it is rejected and the next attempt drawn under the 256 cap and the last resort. The floor from the 64-seed run at 2^20 (box 2): the 55 clean seeds' minimum over their site rows 0.9960 (p1 0.9990, median 1.0000); the strong five p23 0.8361, p18 0.9274, p19 0.9335, p15 0.9432, p56 0.9654; 0.98 sits 0.015 from each side. The chain's own candidates it refuses (the test `class_v4_distinct_ratio_rejects_the_low_entropy_band`, box 2, 2.1 to 2.2 s each): p15 attempt 3 id 52638ea2e8b0fd68 site 2 at 0.943, p18 attempt 2 id 9a37e9489d8ba698 site 6 at 0.927, p19 attempt 0 id 79d7441de0689223 site 15 at 0.933, p56 attempt 2 id 486a8ad2701ec3b5 site 2 at 0.965; p23's attempt 1 with site 7 put back to r6 is refused by (a') (`UnfreshLoadSource`) and, run anyway, by the ratio at 0.836 (874,928 distinct of 1,048,576). Main's rule for a staged 2^24 pass (taken only if 2^24 separates the weak four from the clean seeds by at least the 2^20 gap) was decided by the 2^24 lines (box 2, 35 s per seed on one core): the weak four p34 0.9181, p4 0.9614, p8 0.9630, p10 0.9612; the clean seeds p44 0.9612, p52 0.9613, p3 0.9971, p2 and p5 1.0004; p23's attempt 1 1.0004. Two clean seeds sit on the weak four's value, so a 2^24 floor that reaches the weak four rejects clean seeds, and the 0.961 that recurs on both sides is a band the ratio reads at 2^24 that F8's hot-set gate did not flag on p44 or p52. Committed: the ratio at 0.98 over 2^20 alone (`ACCEPT_UNITS_DISTINCT_V4` = 4096), no 2^24 stage. Open tail: p4, p8, p10 and p34 (1.22x to 1.50x on F8's gate) read 0.9927 to 0.9963 at 2^20, inside the clean spread; unattributed and chased. The (B) most-repeated-value bound stays in the file unwired (`MAX_SOURCE_REPEAT_V4`, `most_repeated`). Cost: the chosen candidate's acceptance gains one 2^20 pass, 2.1 to 2.2 s on one box-2 core, once per epoch draw per node.
The second sub-version 3 commit is 017e70376489251e18564c0abce7e466e606c8b3 (pushed 15:10 UTC's preceding hour, pre-push gate GREEN, CI run 37639406567 success). The crate suite at 017e7037 on box 2 (rc 0, 184 s): 64 lib + 7 derive + 4 mixer + 19 packs + 2 recheck + 7 scratch = 103 passed, 0 failed, 3 diagnostics ignored; the lib tests took 140.8 s against ddacfbd3's 41 s for the whole suite, because every class v4 draw in the tests now pays the 2^20 pass on its chosen candidate (2.2 s each); that is CI time, not node time. The static census at 017e7037 (box 2, 15:1x UTC, 4,096 chain-shaped seeds plus F8's p1 to p3, the draws in parallel over the box's cores since the ratio pass makes the serial run a four-hour job): 4,099 programs, 0 lossy-sourced load sites of 65,584 (57,322 inject, 8,262 bijective), 0 exhaustions; the accepted attempt 1,297 at attempt 0, 899, 609, 416, 298, 197, 125, 92, 54, 46, 21, 14, 13, 9, 6, 0, 2, 1 (mean 2.086, max 17) against ddacfbd3's 1,328, 917, 622, 409, 284, ... (mean 1.998, max 17): the ratio refuses about 4 percent of the candidates that pass every other test, one more attempt on about one seed in twelve; the devnet epoch-0 seed at attempt 1, id a785001687d8688a; F8's p2 at attempt 5, p3 at attempt 1. The attack-pass lane's class check of ddacfbd3's shadow-executed verdicts against 8bdcbdd8 (598,678 chain-shaped seeds): 11,990 (2.0 percent) accept at a different attempt, 0 exhausted, max attempt 32; on 017e7037 the pairing holds (the devnet epoch-0 program draws as a785001687d8688a) and its 64-seed gate at 2^24 and 10^6 exhaustion count were running at 15:1x UTC (finish about 16:05 UTC).
F8's 64-seed gate on 017e7037 (the attack-pass lane, box 2, last seed 16:00:20 UTC): 60 of 64 under 1.2x; the four over are the named tail and nothing else (p10 1.5036x, p8 1.3776x, p34 1.2505x, p4 1.2167x; hottest items 355 to 541 reads of 2^31, unattributed, inside the ratio's clean spread); p23, p19, p15, p18 and p56 under the line; the clean spread 0.9915x to 1.144x. Exhaustion on 017e7037: 0 in the attack-pass lane's 20,532 chain-shaped seeds (max attempt 29) plus this lane's 4,099 (max 17); the 10^6 count continues as a strengthening line. Cost line for the node: the chain's epoch draw now pays the 2^20 ratio pass on every candidate that reaches it (the accepted one, and the about 4 percent that fail there), 2.2 s per pass on one box-2 core, so about 2.3 s per epoch draw on that core and, by the attack-pass lane's reading, about 4 to 5 s per epoch per node on slower cores; the earlier rejections cost milliseconds. From the attack-pass lane sub-version 3 at 017e7037 reads green on both gates with the named tail; its close line went to the plan, main and the Counter ASIC lane. This row stays open on the tail (p4, p8, p10, p34) until it is attributed or ruled accepted.
Owed (recorded, not run, by the project lead's word): G2 (the CPU verifier on 1,024 hashes per card) on the amended stream; G3 (the Metal fuzz, edge, stats and determinism runs) on the amended stream; the hash-rate ladder re-measure on the M5 Max and the RTX 5090 (the amendment changes the base program's source draws, not the op mix or the load count, so the latency-bound rows of `docs/analysis/latency-shadow-2026-10-06.md` are expected to hold within their spread; unmeasured); AMD (the RX 9070 XT, PC 1); the 2019-class verifier core (O-1.14); F8's phase E (the 64-seed dynamic census) on the amended stream, which is the attack-pass lane's and the test of the per-op table. The row reads FIXED-AND-PASSED only after phase E passes against the amended class.
## Genesis forward-compatibility entries (7 October 2026, mission item 8, branch `genesis-forward`)
The three genesis fields of `docs/analysis/mission/mission.md` section 2.8, built on the node fork branch `genesis-forward` (from release-0.3.19-node dc141409) and the repo branch `genesis-forward`; the design and the gates in `docs/design/genesis-forward.md`. Every switch is never on the devnet (its digest c562d70e... does not move); the testnet genesis sets all three (the testnet lane re-pins and re-digests).

18
docs/plans/counter-asic-3-public-text-2026-10-07.md
View file

@ -1,33 +1,33 @@
# The chip claim, public text (7 October 2026, 14:3x UK, on the project lead's "this needs updating with all of our updates"; served since 11:03 UK on master 9162c847 with main's two cuts: no mention of the disclosure prize until the publish word, and row 17 in evidence.md's eight-column shape)
# The chip claim, public text (7 October 2026; REWRITTEN LAUNCH-FIRST 18:3x UK on the project lead's "I thought we were making it 2.1 from launch?": the testnet and mainnet objects set program_class_v4_activation_daa to 0, so class v4 is live from genesis and the launch number is 2.1x to 3.9x on day one; the 5x to 9x is the class v3 baseline the work started from, stated only as that; the devnet's own activation height is a devnet fact only. Served since 11:03 UK on master 9162c847 with main's two cuts: no mention of the disclosure prize until the publish word, and row 17 in evidence.md's eight-column shape)
Three texts and one ledger row, written by the Counter ASIC lane, which owns the chip model. Every number carries its label: measured (a card or a chain we ran, with the date), modelled (arithmetic on cited parts), claimed (a vendor's figure, never measured by us), designed (a rule in a class, not yet measured). Sources: `docs/analysis/chip-model-v3.md` sections 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` and `f4-weakday.md` (branch attack-pass), `docs/design/class-v5-stored-state.md`, the datacentre and market-cap rows of 7 October (lanes 3 and the fleet), the cryptanalysis plan in `docs/plans/funding.md`.
## 1. The home page's chip line (replaces the hero sentence served since 6 October 16:21Z)
Built for graphics cards. In our public model the strongest chip reaches 5x to 9x per joule against an RTX 5090 today; class v4, now on the vote, brings that to 2.1x to 3.9x, and class v5 makes the dataset the chain's own state, so a chip that stores it or recomputes it is wrong on every item. The model and every measurement are public.
Built for graphics cards. At launch the strongest chip in our public model reaches 2.1x to 3.9x per joule against an RTX 5090, under class v4 from the first block. 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.
## 2. The litepaper's chip section (replaces the paragraph that begins "The chip model: 5x to 9x per joule")
The chip model. We price the strongest chip we can design against an RTX 5090 and publish the arithmetic. 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); 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.
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); 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.
| The chip and the class | Edge over an RTX 5090 per joule | Label and date |
|---|---|---|
| A memory-controller chip that stores the whole dataset (the Ethash class), class v3 | 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 |
| The same chip 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 the GPU's (k = 1); 3.9x with the core Bitmain claimed for its Antminer X9 (k about 0.33), a product withdrawn before any unit shipped | modelled on measured card watts, 6 October 2026; the X9 figure claimed, never measured |
| The same chip at the ladder's second rung (about 200,000 ops per hash) | about 2.8x | modelled, 7 October 2026 |
| 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 the GPU's (k = 1); 3.9x with the core Bitmain claimed for its Antminer X9 (k about 0.33), a product withdrawn before any unit shipped | modelled on measured card watts, 6 October 2026; the X9 figure claimed, never measured |
| The same chip at the ladder's second rung (about 200,000 ops per hash), reached by miner signal | about 2.8x | modelled, 7 October 2026 |
| Any chip under class v5, where the dataset is the chain's own state | a 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 warp | designed, 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 percent | measured 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 day | at most 12 percent more hash rate on 12 days a century, nothing on the other days and nothing for any chip | measured census of 2^24 days, 7 October 2026; the rule in the next class |
| When a stored-dataset chip pays for itself | at about USD 100 M of market cap in the first two years, not before | modelled, 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 |
What a miner sees from this. Class v4 costs a 5090 about 80 W more for 0.2 percent of rate, an M5 Max 16 W more for 1.5 percent, an RX 9070 XT and an RTX 4070 nothing (all measured, 6 October 2026). The ladder that sets how much work rides in the shadow starts at rung 0 at the testnet 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). The next test of the model is not ours: the cryptanalysis plan buys three external lots against the mixer, the chained cache and the acceptance rule.
What a miner sees from this. Class v4 costs a 5090 about 80 W more for 0.2 percent of rate, an M5 Max 16 W more for 1.5 percent, an RX 9070 XT and an RTX 4070 nothing (all 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). On the devnet, which started on class v3, class v4 arrives by miner signal at a published height (a devnet fact, not a launch one). The next test of the model is not ours: the cryptanalysis plan buys three external lots against the mixer, the chained cache and the acceptance rule.
## 3. The miner page's line
Your card against the strongest chip we can price: an RTX 5090 at 136 MH/s on 350 W (measured 6 October 2026), the chip 5x to 9x per joule in the public model today, 2.1x to 3.9x under class v4 (modelled on measured watts), and under class v5 wrong on every item because the dataset is the chain's own state (designed); the model and the measurements are public.
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 to 3.9x per joule under class v4 (modelled on measured watts), 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.
## 4. The ledger row (docs/evidence.md row 17, in the table's eight columns as served)
| # | Claim | Where it is made | Status | Version or commit | Reproducible test | Result, date, machine | Independent verification |
|---|---|---|---|---|---|---|---|
| 17 | The chip resistance claim: the strongest chip in the public model reaches 5x to 9x per joule against an RTX 5090 today; class v4 brings it to 2.1x (k = 1) to 3.9x (k about 0.33) and its second rung 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 12 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 | 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 core claimed and never measured | `docs/analysis/chip-model-v3.md` 5 and 6; `docs/analysis/latency-shadow-2026-10-06.md`; `docs/plans/counter-asic-3-status.md`; `docs/analysis/attack-pass/f8-uniform.md`, `f4-weakday.md`, `docs/analysis/ca3-v4-uniform.md`; `docs/design/class-v5-stored-state.md`; the H100 and market-cap rows of 7 October; `docs/plans/funding.md` (the three lots) | the chip model'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); 27 MH/s at 21 W (M5 Max); 249 MH/s (H100 SXM) at 98 percent of its read ceiling, 1.78x hash, 1.15x MH/W, a third per rented dollar; 2.33 ms per warp; 5.1x to 9.2x; 2.1x, 3.9x, 2.8x; 1.067x at the ceiling; 12 percent on 12 days a century; 10.85 ms at rung 3; USD 100 M; 6 and 7 October 2026, the M5 Max, PC 2's RTX 5090, PC 1's RX 9070 XT and RTX 4070, a rented H100 SXM, igneum-build-1 | none yet; the three cryptanalysis lots are the next test |
| 17 | The chip resistance claim: at launch the strongest chip in the public model reaches 2.1x (k = 1) to 3.9x (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 12 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 core claimed and never measured | `docs/analysis/chip-model-v3.md` 5 and 6; `docs/analysis/latency-shadow-2026-10-06.md`; `docs/plans/counter-asic-3-status.md`; `docs/analysis/attack-pass/f8-uniform.md`, `f4-weakday.md`, `docs/analysis/ca3-v4-uniform.md`; `docs/design/class-v5-stored-state.md`; the H100 and market-cap rows of 7 October; `docs/plans/funding.md` (the three lots) | the chip model'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); 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.9x, 2.8x at launch; 1.067x at the ceiling; 12 percent on 12 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 | none yet; the three cryptanalysis lots are the next test |

14
docs/plans/counter-asic-3-status.md
View file

File diff suppressed because one or more lines are too long

2
docs/plans/era-layout.md
View file

@ -171,7 +171,7 @@ Filled from a CPU census over programs (section 6).
## 8. What is unverified
- Everything in section 6 marked pending.
- The 1-hour VDF does not exist; the devnet stand-in of section 2 is a proposal.
- The 1-hour VDF: BUILT on 7 October 2026 (era VDF lane, after the attack pass's F7 row named it the gating dependency): `kaspa_consensus_core::era_vdf` (the class-group Wesolowski scheme on a fixed-width integer and the hash-chain fallback behind the genesis byte `vdf_scheme`), `kaspa_consensus::processes::era_vdf` (the cut rule, the day-of-blues input, the evaluator thread, the record store), behind `Params::era_vdf_activation_daa` (never on every network until the project lead's word per network); the stand-in of section 2 stands below the activation and is what the VDF reads its input from above it. Verified: the F7 re-roll harness against the real era cut fires with the VDF off and is silent with it on across 6 cuts (`tools/era-vdf/reroll.mjs`, the record `docs/analysis/era-vdf-2026-10-07.md` section 3), the parameters and the measured prove and verify times are in spec 04 section 4.6. Still unverified: the P2P relay of a record to a syncing peer (spec 4.5, owed before era 1 of any network with the switch set), the binding of the cut to the certified checkpoint (left at the O-4.3 reading, one function to change), an external review of the class-group port (O-4.1), and the 2019-class-core verify time, which is measured on a proxy until a 2019 host is rented (record section 5).
- The interleave's value against a chip with a programmable address decoder is nil (1.2); the claim is limited to hard-wired layouts.
- The window floor of 2^26 words is set by the 5090's L2 (96 MiB) and the 9070 XT's Infinity Cache (64 MB, vendor figures); a future card with a larger cache moves the floor, which is a genesis constant.
- No cryptanalysis of the stride (a multiply and a rotate before the mask); it is a bijection, so the address distribution is that of the register value, as today.

7
docs/plans/ledger-decisions.md
View file

@ -112,3 +112,10 @@ Standing rulings of the same hour: "We dont want to penalise holders" (dormant-c
| 3 | The latency ladder | Approved | The six rungs (27, 35, 53, 88, 173, 267 passes), rungs 0 to 2 admissible, rung 3 re-measured on a quiet core before genesis, 4 and 5 inadmissible until verifiers allow; every step by 90 percent in each of seven windows, never unconditional; `latency_ladder_activation_daa` = 0 on the testnet at rung 0. |
| 4 | Cryptanalysis | Approved, "make sure they find ZERO flaws, also cut costs if possible" | The engagement runs at the low point (about USD 80,000) unless a quote forces more; an internal attack pass precedes it so the firms find nothing new; every finding is fixed before the testnet go. The contracting entity and the prize are still the project lead's to confirm. |
| 5 | Re-cut the testnet genesis | Approved | One cut with 18 decimals, `TESTNET_1`, and the switches on from genesis: proof verification, the leave item, the signing bonus, finality v3, the ladder at rung 0. Nothing live is touched; the go checklist decides the date. |
## Era VDF (7 October 2026, 12:xx UK, era VDF lane): two decisions for the project lead
Question 1, the activation. The era VDF (spec 04 section 4.4) is in the node behind `era_vdf_activation_daa`, never on every network, with the genesis scheme byte `vdf_scheme` 0 (the class group) and `era_vdf_t` at the reference rate of igneum-build-1's core (spec 4.6). Facts: the F7 harness shows the stand-in grindable with one block of hash at no delay and the VDF closing it; the first era with a VDF is era 1, 180 days after a network's genesis; the P2P record relay (O-4.10) is owed before then. Recommendation: igneum-testnet-1 and mainnet carry `era_vdf_activation_daa: 0` in their genesis objects (the switch costs nothing before era 1 and the digest then pins it from the start); the live devnet keeps never (it will not reach era 1). Unblocks: the freeze of the era draw procedure and the C_era cut rule, which the attack pass's F7 row holds open on the VDF.
Question 2, the cut's binding (O-4.11). The node names the cut block as the chain block the lead rule names, certified or not (the O-4.3 reading of 3 October 2026), so a finality pause across the cut never leaves an era without a seed and the rule is a function of the header's past alone. The design document's wording binds the era draw to the last certified checkpoint. Facts: the grinding defence does not depend on the binding (the delay makes any candidate's draw unknowable); the certified binding couples the era seed to finality liveness and needs a rule for a certificate that lands after the cut (`docs/analysis/era-vdf-2026-10-07.md` section 4). Recommendation: keep the O-4.3 reading for the era as for the epoch; one function (`EraVdfManager::cut_block`) changes if the finality lane wants the certified binding. Unblocks: the sentence in spec 4.4 step 1 stops carrying "under the O-4.3 reading" once decided.

16
docs/plans/relay-deploy-2026-10-07.md Normal file
View file

@ -0,0 +1,16 @@
# Relay deploy, 7 October 2026 (the X23 tree, MF-11)
| What | Value |
|---|---|
| Deployed | 2026-10-07 15:38 BST, from branch update-return bd9b4f4e, relay/ |
| Production deployment | https://igneum-relay-iabqarnby-igneum.vercel.app (inspect KHyscUSVKueXueqxvZBRKkaUHwJR), aliased https://relay.igneum.network |
| Previous production | https://igneum-relay-bgy767z40-igneum.vercel.app |
| Env added | RELAY_RUN_PUB (the public half of ~/.config/igneum/relay-run-key, made by `node tools/relay.mjs keygen` the same hour); RELAY_INTAKE_COMPAT unset |
| Read-backs | /wake answers; fn=machines carries the bound field; the console page answers 200 and c/machines carries poll fields; a v1-shaped register by hostname (key tier) answers named:false bound:false; a signed start-app from the Mac answers 200 (item 394); an unsigned run from master's old tool is refused |
## Rollback
`cd relay && npx --yes vercel@latest --global-config ~/.config/igneum/vercel --scope igneum rollback https://igneum-relay-bgy767z40-igneum.vercel.app`
(or `vercel promote https://igneum-relay-bgy767z40-igneum.vercel.app`). Seconds; nothing to undo in the database: the X23 code adds relay_machines.secret_hash and the
table relay_wake_seen, both ignored by the old code. What a rollback loses: signed run verification (the old relay never
had it), the start-app kind, the ping; PC 2's new agent registers by hostname on either.

52
docs/plans/release-0.3.20.md
View file

@ -501,3 +501,55 @@ sha256 45be9b02d1b002f5 asserted at the put, igneumd/2.1.0-c4459193 in the node'
**PC 2 out of the waves too (main via the Counter lane, 14:5x BST):** the project lead is taking PC 2 down for cable work (PC 1 is back, but it is his desk and no job goes to it); both PCs update on their pollers on return, their lock lines "offline at the sweep, updates on return". The sub-version-2 Windows G1 completed on PC 2 before it went down (13:46:36 to 13:46:50Z, exit 0, eight of eight fingerprints equal to the Mac's). Wave 1 is the Mac, the hands and the fleet.
**c19-1's last pin lines (the fleet; FORM END rc 0 at 13:50:53Z):** mining at +666 s 34.3 MH/s, mined 66, accepted 66, rejected 0, got_reject 0, wrong_version 0, isSynced true at the tip on every read, the exec follower moving; the hub holds 41 blocks by c19-1's key 2c7cc291d38579e0 in its last 700, rejects naming the pod 0; the restart on the kept datadir 13:47:15Z: the stop and the start inside seven seconds (09124180's poll proving itself against b7cc37e7's LOCK death), synced again 13:48:39Z (157,048 blocks, 4 peers), 84 seconds after the kill, isSynced true on the first read and never false after; 109 templates in the read, max template_ms 3,432, "template fetch timed out" 0; the kept read passed at 13:38Z. Every line the rule reads is in from c19-1; CASES END from c20-1 is the one left (about 14:50Z). c19-1 stays up until the shipper's word. p1-5090 ran the sub-version-2 G1 meanwhile (eight of eight equal to the Mac's) and is back under its supervisor.
**The prover roll corrected (the fleet, 15:0x BST):** box-prover's "RESULT paid" line read the segment record's `paid` field without comparing its keyHash to the box's own, so a segment paid to ANY prover printed as the box's pay; this morning's PAIRED verdicts rested on it. The truth from hub-1's segment records (157486..164691, 899 segments, 378 paid) by paid.keyHash: p1-4090 94, p2-4090-3 54, hub-1 41, p1-4070 20, p2-4070-1 11, p12-vast 3, two keys the registry does not hold (bb9f9057a373f647 99, the devnet's biggest payer; e809e39672ed32db 56), and ZERO in two hours for p1-5090, p2-4090-1b, p2-3090-1 to 4 and p1-a5000. So: the pair is on 13 of 13 and pairs on every box; 5 of 13 are paid by the chain's record, 7 are not (their logs under read: race or stuck); the 12 GB race reading was half right (p2-4070-1 at 12 GB is paid 11 times while the 3090s and the 5090 are not, so card size is not what holds those six). The 12 GB line, real: p12-vast was paid three segments by its own key on the bare 55768f88 node, each claimed behind the settled floor (164438 claimed 13:41:00Z paid at carrier 164494 5.8388 IGN; 164502 at 13:45:06Z paid 4.8263; 164510 at 13:48:58Z paid 4.5727); on c4459193 with the verifier env (13:31 to 13:37Z) the statement was accepted and no race won in that window: the pin's line is "statement accepted, 0 paid in six minutes", not blocking. box-prover fixed (gpu-fleet 4c872785: a paid line only on its own key, "paid_other" otherwise), on every standing box; running provers take it at their next restart by kill file, which the sweep's prover roll does. Who holds bb9f9057 and e809e396 (PC 2's app, the Mac, the hands' CPU prover) is for main.
**Docs on master (15:01 BST):** the 0.3.20 plan, release-rules.md and the 0.3.21 plan landed as ship-docs-0320 3ad0c60d through tools/ci/merge-to-master.sh (the full gate green on the branch, 52 checks; the merge 41e0eb45). From here plan rows land the same way.
**The two paid prover keys outside the fleet's registry (15:3x BST):** e809e39672ed32db (56 segments in two hours) is PC 2's card 1, identity 1 (label win-1ccfe586-1-1; read by the build-server lane's read-only job run-20261007-142054 on PC 2 at 15:38 BST through the installed igneum-miner's key-hash; PC 2 is back since the cable work). bb9f9057a373f647 (99 segments, the devnet's biggest payer) is none of PC 2's seven labels, nor the Mac's (mac-d937c69d-1 = 8fafda27…), and build-1 runs no prover; PC 1 (labels win-ae432dc7-1/-2 and their identities) is the remaining candidate, its key read by the project lead from the Prove page's Details on main's ask (no job on PC 1). For 0.3.21 the app reports its vote key hashes to the intake on every poll, so this is never a hand read again.
**Devnet 2 (the fleet, 15:4x BST):** dn2-override.json is an eleven-field object without the v4 floor or window, so Devnet 2 has no flip date and the 13 October line does not apply to its lock lines; igneumd-83702a35 and c4459193 both print digest 4a0b8726… on it, so wave 3 is a plain binary swap on the four pods (read-back 4a0b8726) and bps-seed moves at the build-server lane's convenience with no digest step. The cases on c20-1: the poison pod mining from 14:41:25Z, the thirteen polls to about 14:54Z, the restart and the hub read after: CASES END about 14:57Z (15:57 BST); the per-box sweep form rehearsed on w-target meanwhile. The publish about 16:00 BST on it.
## 38. 0.3.20 LIVE (15:54:17 BST, 7 October 2026)
**Main's word (15:4x BST):** (b): publish on the dc141409 cases plus the diff argument and the c19-1 relay evidence; the separate-host relay re-run (CASES END about 17:15 BST) is a halt condition: a FAIL stops the sweep after the wave in progress and rolls back by the per-box form; no public Discord card or site version bump until it reads PASS. The cases rerun on c20-1 was void on its relay half: RunPod put the target, the relay and the poison pods on one host and a pod cannot reach another on its own host by the public address (the no-hairpin class); the poison half stood (13 rejected, 0 accepted). The hairpin class is a rent-time host check in the fleet's script.
**The cut:** live DAA 294,073 at 15:51 BST; the floor-moved file ov16-floor-900000.json (sha256 294f1f80f1c8aecf…): program_class_v4_activation_daa 831600 → 900000, window 86400 unchanged, the fifteen other fields as live; digest on c4459193 4bbbe8162ea9fff277aa5b16b4ffad9e2262ba5e6a5acac7b697ff77211e7328 (the live file reads eada4bda on the same binary). Staged in a scratch copy of the downloads folder (publish-manifest.sh --no-deploy --public with the DMG 73796c5f and the installer 45b2f3fb; publish-public.sh --hive with igneum-hive-0.3.20.tar.gz d9dd12df); the staged manifest differed from the live one in the override object alone; the staged folder's names differed from the live one in the 0.3.20 files added and the 0.3.19 and 0.3.17 public files pruned. The deploy step: the staged folder onto the live one, `vercel deploy --prod` (Production igneum-qu5chjxiq, aliased dl.igneum.network), 15:54:17 BST. Read back: the live manifest version 0.3.20, mac 73796c5f, windows 45b2f3fb, floor 900000; the three public aliases 200 (windows exe, mac dmg, hive tar).
**The sweep's go (15:55 BST):** the fleet's wave 1 (hub-1 first, pool-1, the eight heaviest; the fleet-native pair a8d08da5 / 474273ce; read-back by commit string c4459193, digest 4bbbe816, synced; the lock line "sweep complete before 13 October 09:00 UK (the margin; the floor is now DAA 900,000)"), the hands in the same minutes (the build-server lane, mode 2 with the object and the digest), wave 2 on the first lock on the new side, wave 3 the Devnet 2 four as a plain swap (4a0b8726), bps-seed at the build-server lane's convenience with no file change; the seeds and the RPC filter untouched (main's (b)); PC 1 and PC 2 on their pollers on return; the Mac on its poller; the Mac mini a fresh install when the project lead has it up. The Discord card and the site's version line held for the relay re-run's PASS.
**Correction to the sweep's node pair (16:02 BST):** the fleet-native igneumd a8d08da5 named in the go is gone: the shipper's scratch copy was overwritten at 13:55Z by the stopped 55768f88 chain's native step (05016dee, no c4459193 string) and the box's target-0320 path with it. The sweep's node pair for every fleet box is the build-server lane's c4459193 hands pair from the same tree (igneum 00249643, igneum-pow 8c728ca3, build-1, native 2.39, the string read back): igneumd a80ed39caf885d314f97ce88863afcb307cbb4acc45a10828b2443a41e5d27d2 (57,628,576 B), igneum-miner 70a5180f30fab73fde0b3f33cfd37d2d68899eab70290b86c924e02980b09afd (10,214,648 B). The shipped artefacts are unaffected: the hive tar (d9dd12df, smoked with c4459193 ×2), the Windows exes in the installer (49502cc7, c4459193 ×2) and the Mac node in the DMG (b306baba, c4459193 ×2) were verified from their own files. Scratch rule note: a chain writing into a shared --out directory must stop before another candidate starts; the restart on a new candidate reused the same out paths.
**Wave 1, the hands (the build-server lane, 15:56:09 to 15:57:45 BST, rc 0):** igneumd a80ed39c installed as /srv/hands/bin/igneumd-2.1.0-c4459193, the sixteen-field object written (floor 900000, window 86400). observer-node restarted 15:57:08 from eada4bda: first executing line "exec state loaded from a snapshot: tip 165393", digest 4bbbe816 MATCHES, the commit string present, powEngine igneum-pow, blockrate bps 1, finalityDepth 43200, ghostdagK 18, mergeDepth 3600, pruningDepth 108000. node1 restarted 15:57:30: tip 165348, digest MATCHES, the string present, powEngine igneum-pow. Lock line carried. Seeds and the RPC filter untouched; bps-seed follows.
**Interface 1.0.1 over the air (main's order, the shipper as publisher; 16:03:37 BST):** the 0.3.20 tree's app/igneum-app/ui packed as igneum-ui-1.0.1.tar.gz (408,212 B, sha256 0749f37c67c028c8cf1052ed099fea0f1cc159ad6cefdc75d74d2f2de1d9fc45), min_engine 0.3.20, signed with the release key (igneum-ota-sign sign-ui; key fingerprint 8f186e37…), staged first in a scratch copy of the downloads folder (the only field differing from the live token manifest: `ui`; the release notes kept by passing them back), then the deploy step (the staged folder onto the live one, vercel deploy, aliased 16:03 BST). `publish.mjs --verify`: the live manifest's ui entry against the bundle in the folder, sha256 matches, signature verifies. Not published to the public manifest: the publisher's --public arm fails on the ui entry ("the public igneum-app-latest.json would still carry the token": the ui URL is under the token path and publish-public.sh has no ui rewrite), so dl/public/ui/ is missing by design today; the apps read the token manifest, which is where the channel lives; the --public ui arm is a 0.3.21 packaging fix. The Mac's app taking 1.0.1 on its poller: read back below when it polls (hourly, or Settings > Check now).
**Wave 1 (the fleet, 14:59:08Z):** on igneumd a80ed39c (the floor file 294f1f80 read 4bbbe816 on it on the scratch pod at 14:58Z), the lock before at checkpoint 9259, 80.4 percent; hub-1, pool-1, p1-5090, p1-4090, p2-4090-3, p2-4090-1b, p2-3090-1 to -4 moving in parallel; the miner 70a5180f for the prover roll behind the waves. The relay re-run's three pods carried the old file (eada4bda) and would have read a false FAIL beside the swept fleet; the floor file put on c19-1, c21-relay and c21-poison at 15:00:37Z, the run restarted 15:02Z after a script fault of the fleet's (fixed): CASES END about 16:20Z (17:20 BST), a read on the live digest. bps-seed is build-1 itself (a bare process under /home/build/dn2seed), the build-server lane's, the digest unmoved there.
**Wave 1 read-back (the fleet, 15:04:51Z):** hub-1 on a80ed39c, igneumd/2.1.0-c4459193, digest 4bbbe816, override 294f1f80, the N13 rewrite line once, synced at 162,489 with 6 peers, the miner back; the same read on p1-5090, p1-4090, p2-4090-3, p2-3090-4 (1 to 2 peers, climbing); p2-4090-1b and p2-3090-2 on the new binary and digest with 0 peers yet (the old-digest peers refuse them, the new ones are the boxes landing beside them; miners held by the supervisor's zero-peer rule until they peer); pool-1's daemon stopped and its node starting on the supervisor's next pass; p2-3090-1 and p2-3090-3 not answering that read's ssh in time (the next pass). The panic counts on the first boxes (10 to 20) are the RocksDB LOCK class from the supervisor's retries while the old process still held the datadir, not consensus; every node is up regardless. The certificate line between waves about 15:10Z.
**bps-seed (the build-server lane, 16:07:49 to 16:08:00 BST):** the Devnet 2 seed is a bare process on build-1 (/home/build/fleet-share/igneumd-83702a35…, --devnet-suffix=2, appdir /home/build/dn2seed, the eleven-field devnet2-override.json b75d1f58); both binaries read 4a0b8726 on that file first; SIGTERM, the native c4459193 (a80ed39c) started with the identical argument line, down 11 s; read back igneumd/2.1.0-c4459193, the string twice, the digest 4a0b8726 unchanged, the N13 line on the kept datadir, GRPC and P2P up, 23 "PoW accepted" in 20 s, no panic.
**The Mac (this machine, in wave 1 on its poller):** its hourly check at 16:01 BST had read the 0.3.19 manifest (published 10:23Z) though the CDN served 0.3.20 since 15:54 BST, a stale read of seven minutes (the app's own cache or a stale edge; a 0.3.21 note for the ui-ota health ping, which reads the same path); Settings > Check now at 16:04:58 BST read 0.3.20 (published 15:02:36Z), downloaded and ready by 16:05:20; the apply is the app's own (auto_update on), awaited; interface 1.0.1 after it.
**0.3.21:** update-return-21b a64c193f (the eGPU card kind for a USB4 or Thunderbolt router in the device's parent chain, the Power Helper's fault line and its stale-prefix fix; app tests 255 + 32 + 8, UI 76) is ready on the lane's side; its push to origin is refused by GitHub ("remote: Internal Server Error", three tries 15:08 to 15:10Z), the lane retrying.
**The Mac's apply is held by the app's own guard (16:12 BST):** update ready, wait = "the network lost 33% of its identities in the last 10 minutes; holding the update": the wave sweep restarts ten fleet nodes at once (each miner off for the 80 s restart, the zero-peer boxes held longer), the app reads that as an identity drop and holds its apply until the count recovers, then applies at its rollout slot (":MM past the hour", the per-machine minute). The guard is right by design (an app must not update into a shedding network); the consequence is that the apps' pollers apply after the fleet's waves settle, not alongside them. For the rules: a wave sweep and the apps' identity-drop guard interact this way; the publish record names the apps' apply times as they land. The Mac's apply time is read back below.
**Wave 1 complete, wave 2 started (the fleet, 15:12 to 15:22Z):** all ten read back on the pin (a80ed39c, igneumd/2.1.0-c4459193, digest 4bbbe816, the file 294f1f80, the N13 rewrite line once, synced or catching up): hub-1 (10 peers), pool-1 (its node restarted 15:08:27Z), p1-5090, p1-4090, p2-4090-3, p2-3090-4, and p2-4090-1b, p2-3090-1, p2-3090-2, p2-3090-3. The fault behind the last four: the standing nodes run `--addpeer=<the Hetzner seed> --nodnsseed`; the seed's own move refused their handshake and they dialled nothing for 17 minutes at 0 peers (the six others had the hub in their address books); fixed by HUB_PEER (the hub as a second addpeer) in their supervisors and a kill-file restart, all four at 3 peers. The lock: hub-1's last LOCKED at checkpoint 9263 (15:05:03Z, 49.9 percent at the moment of locking; the folded certificate 98.1 percent, 13 of 16 voters, weight 4,954); no LOCKED since, the digest split's expected shape while the four wave-2 voters still vote on the old side; the first new-side lock being read. Wave 2 (p1-a5000, p1-4070, p2-4070-1, p1-3080) started 15:22Z on the 98.1 reading (their move brings weight onto the new side). Rule for the fleet's supervisors (from this): every standing node carries the hub as a second addpeer, so a seed's move never leaves a box peerless.
**Master re-pinned (16:21 BST):** packaging/windows/node-source.pin on master moved to c4459193 (master-pin-0320 a0b44b48 through merge-to-master.sh, the full gate 55 checks green; the merge 6996ad3f), so master's windows-ci reads green at its payload-inputs step again (red on every master run since 6 October 21:15Z on the stale pin); release rule 14: master is re-pinned at every publish, a named line in the cut list.
**The Mac on 0.3.20 and interface 1.0.1 (16:23 BST):** the identity-drop guard lifted as wave 1 settled; the app applied 0.3.20 on its own (updated_from 0.3.19), its node log node-20261007-152327.log starting 16:23:27 BST on igneumd/2.1.0-c4459193, digest 4bbbe816 on its own kept datadir (the N13 rewrite line once), synced at 164,411 blocks with 5 peers at 16:25; interface 1.0.1 taken over the air at 16:23:58 BST (source ota, published_version 1.0.1, active_version 1.0.1, embedded 1.0.0, confirmed true, no error). The Mac is in wave 1 as ordered.
**Wave 2 and the first lock on the new side (the fleet, 15:23 to 15:29Z):** p1-a5000, p1-4070, p2-4070-1, p1-3080 read back on the pin (a80ed39c, c4459193, 4bbbe816, 294f1f80, the rewrite line once, synced); three sat peerless on the seed-only addpeer (wave 1's class) and carry the hub peer since 15:26Z. The lock: the old side's last at 9263 (15:05:03Z); the new side locked from checkpoint 9313 at 15:28:08Z (84.9 percent of active, 70.1 of total), 9315, 9316 (87.5 of active, 74.9 of total); a 23-minute gap while the table's weight split across the two digests, votes accepted at the hub throughout, no certificate at two thirds until all fourteen stood on the new digest with peers; the folded certificate at 9317 78.3 percent (14 to 15 voters). Equivocation warnings on the hub at 9280 and 9292 by four keys that are not fleet vote keys (e15fe94b, a405c3e6, 7b8ef6fd, ea53bd41: the Mac, PC 2 or the hands re-voting across the split); the fleet's keys did not equivocate. The supervisor rule is in: box-standing.sh adds the hub as a second addpeer by default (gpu-fleet 34ef30f8, README item 20, CLAUDE.md), on all fourteen, live at each next kill-file restart (seven already). Wave 3 (the Devnet 2 four, a binary swap, digest 4a0b8726) started 15:29Z; the prover roll runs behind waves 1 and 2 (the 70a5180f miner, the pair under bin-0320, box-prover with the key check and the drift flag). For the rules: a digest-moving sweep costs the chain its locks for the length of the split (23 minutes here); the hub plus the heaviest voters in one wave shortens it, and every node carrying the hub as a peer shortens it further.
**Known red on the published pin, test-only (the node lane after the era VDF lane's read, 16:3x BST):** two consensus INTEGRATION test targets, consensus/tests/igneum_installed_signals.rs (`block_template_uses_current_block_version`) and consensus/tests/igneum_order_tests.rs, assert the signalled header version 1026 (object 4) while 8097d600 moved the class signal to object 5 and the header carries 1282; red on c4459193 and every commit since 8097d600; outside the suite set the node lane ran (the two installing-test targets were split into their own binaries this morning for the test-order race and left out of the set). The code is right; the tests are stale, 6b94c823's class. The pin stays c4459193 as published and swept (its binaries keep their commit string); the test-only fix (branch signal-tests-fix on the mirror, 1026 → 1282) is the FIRST step of 0.3.21's node order on 55768f88, and the rule from now: the two integration targets are in every suite set (`cargo test -p kaspa-consensus` without --lib). era-vdf-node 394a5902 is 0.3.22's (the shipper's call; every network at never, era 1 at least 180 days past a genesis).
## 39. SWEEP COMPLETE (15:39Z, 16:39 BST)
The devnet: hub-1, pool-1 and the twelve voters on igneumd a80ed39c (string c4459193), the floor file 294f1f80, digest 4bbbe816, the N13 rewrite line once each, synced, the miners back (the 70a5180f miner as the prover roll reaches each box); the first new-side lock 9313 at 15:28:08Z after the 23-minute split, locks every 20 to 40 seconds since at 70 to 81 percent of the total, the folded certificate 78 to 82 percent of the table. The hands (observer-node, node1) and the Mac on the pin with 4bbbe816; the Mac on interface 1.0.1. Devnet 2: dn2-seed, dn2-1, dn2-2, dn2-3 and bps-seed on c4459193, digest 4a0b8726 unchanged; a ten-minute four-way split from the fleet's Devnet 2 move (dn2-seed's supervisor env rebuilt without EVM_PORT and P2P_PORT, box-dn2.sh with no defaults, the seed's node refusing "--evm-rpclisten=127.0.0.1:"), healed at 15:36:25Z, all four at block 76,857 and a new lock at checkpoint 2313 at 15:39:38Z. The testnet seeds on 1c19441d by main's (b). PC 1 and PC 2 update on their pollers on return; the Mac mini a fresh install. Every lock line: "sweep complete before 13 October 09:00 UK (the margin; the floor is now DAA 900,000)". The prover roll runs behind the waves (p1-a5000 refused by design on its drift flag; hub-1 claiming on the pin). Open on the sweep: the relay re-run on c19-1 on the live digest, CASES END about 16:25Z (17:25 BST), the halt condition and the Discord card's gate; build-1's port 26621 (the Devnet 2 seed's p2p) reads closed from outside (a firewall rule predating the sweep; the build-server lane reads it); the two PCs' return.
The fleet's six faults in the sweep, each a rule in its tooling now: the seed-only addpeer (seven peerless boxes, 23 minutes without a lock; the hub as a default second peer, 34ef30f8); the pool kill file's "all" taking pool-1's supervisor; the loop's expected digest and wanted sha left on the old pin; the cases script re-putting the old object (OVERRIDE input); the sweep's pow read-back term; the Devnet 2 env filter. The shipper's: the speculative build chains sharing one --out directory (a candidate's artefacts overwritten by the next chain's; the sweep's pair taken from the build-server lane's copy at /srv/artefacts/0320-c4459193/ instead), and the first order to the seeds with the devnet file (corrected before any box moved).
**0.3.21 staging word given at 16:39 BST** (the node lane: c631c64b first on 55768f88, then the eight in order; the whole suite set; the candidate's binary with every gate from the build on the warm set). The reliability injector pod rented at the same minute.

23
docs/plans/release-0.3.21.md
View file

@ -12,14 +12,18 @@ Tree: release-0.3.21 on origin, from release-0.3.20's closed tree (the 0.3.20 cu
| sub-version 2 (the hash lane's 07a809a7, byte 7, id a788661687db4bb3), pending the F8 census (about 15:00 BST; pass = all 64 seeds under 1.2x of the window model plus the suite and G1 lines); if it fails or slips past 20:00 BST the node ships byte 5 again with the re-pin dropped | the Counter lane, the node lane | held |
| the fork gate from horizon-node (6eb21fc9, six commits on finality.rs) | the node lane | dry-merged clean into c4459193 |
| the node's own rust-toolchain.toml | the node lane | in place on its worktree |
| the under-12 GB prove-instead switch (section 2) | the shipper | to write after the 0.3.20 publish |
| the per-architecture prover server (section 3) | the shipper, the fleet | to write after the 0.3.20 publish |
| the under-12 GB prove-instead switch (section 2) | the shipper | in: settings.prove_instead, Cmd::ProveHold, the Prove page's row, provedefault helpers and tests; app gate on build-2 230 + 32 + 8, UI 74 |
| the per-architecture prover server (section 3) | the reliability lane (the app's capability check, MF-10 in cbd6f3a4), the fleet (the kit's server per arch) | the app half in |
| pool-finish 434e8b9b (the pool crate: the TLS 1.3 member port with the authorize binding, the open pool, pool.md 10; fork pool-finish-node b0444f51 off 8097d600: the pool-mode miner, the IGNS/IGNP codec, pool_split_activation_daa at never on every network, so the digest does not move) and pool-mf-row 343dd83b (MF-11 in the register) | the pool lane | main's word 14:2x BST: rides 0.3.21 with the split switch at never; if it reds a 0.3.21 gate or costs more than one rebase round it moves to 0.3.22 |
| apps-harmony (the builder's redesign, Overview as the landing tab, the Prove switch fix), then gpu-logos on top of it, then ui-overlap-fixes, then scene-parity, in that order as they land, each with its own gate line | the UI lanes | to come |
| the UI branches (apps-harmony parked by the project lead's word, 14:2x BST; the Prove switch fix moved to gpu-logos): gpu-logos-21 in at fee49fc5, earnings-tidy-21 in, scene-parity-21 in, ui-overlap-fixes nothing to merge | the UI lanes | done |
| MF-11 (the app not returning after update-now; PC 2 silent since the 0.3.19 update-now at 10:34Z, its relay agent dead with it, so no job or task reaches it): the register row, the UI lane owning the cause, the relay agent as a service surviving the app as the restart path | the reliability lane, the UI lane, the relay lane | the row asked |
| the ids commit 55768f88 (`resolve_program_ids`: the override's fields, then the env or the host, then the embedded verifying keys; the exec suite 32 with the bare-node test known-failed first; built 13:35Z sha 279b1b690e854fc9): 0.3.21's FIRST node commit by main's word, with the ids gate (rule 4c) on every candidate | the node lane | on the mirror; its gates run under rule 4a |
| the 0.3.21 node order (main, 14:4x BST), each with its own gate line, one rebase round or 0.3.22: on c4459193, 55768f88; miner-reliability-20 f067f7c1 and the late-join commit 70e4601e; pool-finish-node b0444f51; horizon-node 6eb21fc9 (the deep fork-choice fix, fork_gate never set); peer-directory-node db28d331 (the peer directory prototype, peer_directory_activation_daa at never, the IGNP announce only under --announce); the sub-version-2 re-pin held for the census. The horizon lane rebases its two onto c4459193 at the sweep-end word | the node lane, the horizon lane | staged tonight |
| pool-finish-21 at 5e557171 on origin (release-0.3.21 5d153892 plus the ten pool commits, the tenth d5265fb3 the `--template-parallel` fix, default 2: the ten-member window's daemon queued ten template calls on one gRPC connection past its own timeout, 1,891 lines, no job for 36 minutes; site/miner.html carries the pool-fee sentence); igneum-pool 28 at 5e557171 on build-2, the app gate 226 + 32 + 8 at 54dd4c06 (the last commit touches pool/ and docs only); merged after the three UI branches with the app gate rerun at the merge | the pool lane | ready to merge |
| the genesis-forward lane's f95178a1 (consensus/src/consensus/services.rs, +5 −1: the difficulty manager takes `params.pow_epoch_blocks` instead of the process-wide static; names the lib-suite flake behind the horizon lane's two reds and main's "difficulty flake": two pruning-proof tests install a 60-block schedule process-wide, and a TestConsensus built in that window refuses block 61 with UnexpectedDifficulty; the lib suite 114 of 114 twice on build-2; the daemon unchanged) | the genesis-forward lane, the node lane | taken last in the node order, its own commit, the lib suite as its line |
| ui-overlap-fixes: nothing to merge for the miner (tools/ci/overlap-check.mjs read 0 overlaps on 4c89372a and on 50ffa562, the run on 3dc0832a in flight); the wallet's one finding at 927ad832 on ui-overlap-fixes-wallet off wallet-0.1.5 is the wallet's cut; the detector lands on master with the site fixes | the overlap lane | closed for 0.3.21 |
| the app reports its vote key hashes to the intake on every poll (main, 15:2x BST: the two paid devnet keys outside the fleet's registry could only be read by hand on the PCs; chainfacts keeps reading the node's keys too): the labels from prover::labels and igneum-miner key-hash once per labels change, a `keys` field on the app's intake row, the console's machine line showing the first eight of each | the shipper | to write after the 0.3.20 publish, before the 19:30 app gate |
| update-return (the MF-11 lane, bd9b4f4e off 4c89372a), main's word 15:2x BST: the app half (ota.rs: the Windows helper owns the update's return with the kept exe set, a 120 s api/state poll, a rollback and one intake line either way; engine.rs: the read-back line "update-return: app <v> up after the update from <from>", FAULT pc-restart after a power loss, the tuner ceiling and the refused-cap ladder; ember.rs; jobrun.rs the job-channel ping on wake; bootcheck.rs; platform.rs), app/windows/host.cpp (a dead engine restarted, WM_QUERYENDSESSION answered; about 60 new C++ lines) and the installer (/IGNOTA=2) ride 0.3.21 if they rebase in one round as update-return-21; the cut's windows.yml run compiling host.cpp is a NAMED GATE LINE (no host.cpp ships uncompiled). The relay half (the v3 agent as a service, playbooks, the X23 signed-run lib) lands through master on the relay lane's line with the relay deploy decision, main's | the update-return lane | rebasing |
| 0.3.20's version strings moved to 0.3.21 | the shipper | 0d7b9bd0 |
| master 819d536b merged (the 51-check gate; build-remote routes by load; the hands script's pgrep in the bracket form) | the shipper | c83ca904, 0b75cf52 |
@ -64,3 +68,16 @@ No node gate for 0.3.21: the app tree ships over the node already in the field (
## 7. LIVE on the Mac, 18:41:50 BST (main's ruling: the Mac entry now, Windows as its own entry)
Deploy runbook r0321/deploy.sh --mac-only --go (preflight: the staged manifest equals the live one on consensus.override, floor 900000, 16 fields, interface 1.0.1; the DMG present and read back). Copied into the live folder at 18:40:44 BST, Vercel deploy, the live manifest read back at 18:41:50 BST: version 0.3.21, channel devnet, mac Igneum-Miner-0.3.21-c4459193.dmg 490919d9 (44,538,877 bytes), windows none, floor 900000, ui 1.0.1; the DMG from the live URL 490919d9. The 0.3.20 hive package and the floor file unchanged. The Mac poller takes it within the hour or on Check now. The Windows entry lands as its own entry when an installer passes PC 2's smoke: (2a) a per-user Inno Setup 6 install on PC 2 by job (unelevated, fail clean) and (2b) the window host by mingw on the box run in parallel; a PC 1 build job (MSVC) wins over (2b) if the project lead allows one; (2c) windows.yml when GitHub returns is the last resort. Testnet re-arm line (the node lane, 18:38 BST): fork 6ed56f63 on release-0.3.22-node, digest 87d103b6 with no file, genesis 52a3e6a9 (5 October 00:00Z, past), every gate green on the exact commit; Devnet 3's digest on that binary still 83eb50cd. The 0.3.22 node pin candidate: N15 dfae08e5 as 34a2dbaa on 6ed56f63, gates running from 18:39 BST. Signing bonus (for the project lead, the node lane): supply unchanged, only who is paid (a silent producer 72 and the pool 28 instead of 80 and 20; fees untouched); waits for 0.3.23 whatever the decision (c7ea1e21 silent_split missing).
**scene-parity-21-sizing in (15:0x BST):** 7e15bf2f on 3dc0832a: live-dag.js 2.0.4 (the box's height follows the lanes through onSize and autoHeight, for /live; the app passes neither, its frames byte-identical, the parity test equal on every comparison); scene/, site/ and the app copy byte-equal; no Rust change, the app gate of 20c9153b stands; pre-push 56 green. The same 2.0.4 is on master at b9017422 and served by igneum.network.
**pool-finish-21 in (15:0x BST):** 2eea335f (the ten pool commits rebased onto 3dc0832a, no conflict; the pool-fee sentence in site/miner.html). Lines at that tip on build-2: igneum-pool 28; the app gate 229 + 32 + 8. Merged after scene-parity-21-sizing (JS only, so the Rust gate stands). The app side of 0.3.21 now carries: driver-check, miner-reliability-21 (cbd6f3a4), gpu-logos-21 with the Prove switch fix, earnings-tidy-21, scene-parity-21 and its sizing (live-dag.js 2.0.4), pool-finish-21; still mine: the under-12 GB prove-instead switch (section 2). The app gate on the final tree runs on build-2 about 19:30 BST or as soon as the switch lands.
**N15 rides 0.3.21's node line (the node lane, 15:1x BST):** branch numbering-fix at d8bceca5 (a6864e36 then d8bceca5, from 52e96c94): chain_path checks the first added block's selected parent against the tip record before anything is appended and hands the orphan records above the fork point to the reorg unwind (the shape that left p1-5090 two high: a reorg's removed list one short at 15:51Z on 6 October); a start-time self-check once per process walks the records from the restart pin against the DAG's selected parents, names the first break, unwinds above it and lets the follower re-walk (the shape that left p2-3090-3 46 high from a snapshot carrying its source's break); recordsContinuous and continuityBreak on igneum_getProvingStatus and igneum_getExecStatus (null, true, or false with the break's block), box-prover claiming only on true. The number is canonical by construction from the pin; the carrier's refusal by number stands (the statement binds the number). Two unit tests known-failed first; the exec suite 35 and the kaspad check green on build-2 at 14:13Z; the live line is the fleet's restart of p1-5090 and p2-3090-3 on the 0.3.21 candidate (the self-check naming #155958 and #158875, the unwind, offset 0 after). The 0.3.21 node order, final, on byte 5: 52e96c94, f067f7c1, b0444f51, 437f0438, 2e32d5f6, f95178a1, a6864e36, d8bceca5.
**update-return-21 in (15:3x BST):** 9d838ae5, one commit on b4289c4a (the app half: ota.rs, engine.rs, jobrun.rs, ember.rs, platform.rs, main.rs, bootcheck.rs; app/windows/host.cpp; Igneum-Miner.iss /IGNOTA=2; one round, main.rs's mod list by union). Lines on the tree: build-2 app tests 247 + 32 + 8; UI 74; the Windows cross green on build-1 (igneum-app.exe 4,172,288 B sha256 5b0598ad…, system DLLs only). host.cpp compiles in the cut's windows.yml run: the named gate line. The relay half stays on update-return for the relay lane's line through master.
**first-block-21 in (16:0x BST):** 6e555d47 on 064fb02b (ladder.rs: first_block_shown persisted in ladder.json, Ladder::start_run; engine.rs start_run at load and started_at on the state; app.js staleCard, firstWait, the first rung reading the flag; the ui-mock secondblock scenario). Lines: build-2 app gate 254 + 32 + 8 (seven new ladder tests); UI 67 (view 46, one new known-failed first); pre-push 56. No installer, node or host change. Captures ~/Desktop/igneum-previews-2026-10-07/first-block/01 and 02.
**Three more in (16:2x BST):** update-return-21b a64c193f (the eGPU card kind from a USB4 or Thunderbolt router in the device's parent chain, the Power Helper's fault line and its stale-prefix fix; app 255 + 32 + 8, UI 76); first-block-21 at cc9141cb replacing 6e555d47 (main's "seen once": the first-block card waits until a window has shown it, POST api/card/seen, ladder.rs card_seen; app 255 + 32 + 8, UI 67); miner-reliability-21 at 018440ae (the register: MF-11 in the update-return lane's words, MF-12 the pool stall, MF-13 the Power Helper's stale count; code unchanged since 4a28eb59, CI success). UI tests on the merged tree 76 of 76; the app gate on build-2 at the merged tip below. GitHub refused pushes with "Internal Server Error" from about 15:25 to 16:18 BST, transient.
**The node order, final (16:3x BST):** on 55768f88: c631c64b first (the test-only fix of the two stale integration targets, 1026 → 1282; both green on build-2 at 15:34Z), then 52e96c94, f067f7c1, b0444f51, 437f0438, 2e32d5f6, f95178a1, a6864e36, d8bceca5; the tip's suite set runs the consensus crate whole (`-p kaspa-consensus` without `--lib`: the lib and both integration targets) beside consensus-core, the miner, kaspa-pow, the exec suite and the three checks (the suite rule from the 0.3.20 known-red finding). era-vdf-node 394a5902 is 0.3.22's.

BIN
docs/plans/site-ui-5-shots/404__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 224 KiB

After

Width:  |  Height:  |  Size: 215 KiB

BIN
docs/plans/site-ui-5-shots/404__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 225 KiB

BIN
docs/plans/site-ui-5-shots/404__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 238 KiB

After

Width:  |  Height:  |  Size: 222 KiB

BIN
docs/plans/site-ui-5-shots/404__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 240 KiB

BIN
docs/plans/site-ui-5-shots/app-band__1440-dark.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 31 KiB

BIN
docs/plans/site-ui-5-shots/app__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.1 MiB

After

Width:  |  Height:  |  Size: 1 MiB

BIN
docs/plans/site-ui-5-shots/app__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 1.2 MiB

BIN
docs/plans/site-ui-5-shots/app__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 586 KiB

After

Width:  |  Height:  |  Size: 553 KiB

BIN
docs/plans/site-ui-5-shots/app__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 597 KiB

BIN
docs/plans/site-ui-5-shots/bench__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 478 KiB

After

Width:  |  Height:  |  Size: 476 KiB

BIN
docs/plans/site-ui-5-shots/bench__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 478 KiB

BIN
docs/plans/site-ui-5-shots/bench__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 367 KiB

After

Width:  |  Height:  |  Size: 374 KiB

BIN
docs/plans/site-ui-5-shots/bench__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 364 KiB

BIN
docs/plans/site-ui-5-shots/claims__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 549 KiB

After

Width:  |  Height:  |  Size: 537 KiB

BIN
docs/plans/site-ui-5-shots/claims__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 548 KiB

BIN
docs/plans/site-ui-5-shots/claims__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 549 KiB

After

Width:  |  Height:  |  Size: 536 KiB

BIN
docs/plans/site-ui-5-shots/claims__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 547 KiB

BIN
docs/plans/site-ui-5-shots/dev-fee__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 332 KiB

After

Width:  |  Height:  |  Size: 312 KiB

BIN
docs/plans/site-ui-5-shots/dev-fee__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 332 KiB

BIN
docs/plans/site-ui-5-shots/dev-fee__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 277 KiB

After

Width:  |  Height:  |  Size: 262 KiB

BIN
docs/plans/site-ui-5-shots/dev-fee__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 276 KiB

BIN
docs/plans/site-ui-5-shots/download__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 590 KiB

After

Width:  |  Height:  |  Size: 567 KiB

BIN
docs/plans/site-ui-5-shots/download__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 605 KiB

BIN
docs/plans/site-ui-5-shots/download__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 518 KiB

After

Width:  |  Height:  |  Size: 492 KiB

BIN
docs/plans/site-ui-5-shots/download__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 528 KiB

BIN
docs/plans/site-ui-5-shots/evidence__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 517 KiB

After

Width:  |  Height:  |  Size: 475 KiB

BIN
docs/plans/site-ui-5-shots/evidence__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 516 KiB

BIN
docs/plans/site-ui-5-shots/evidence__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 309 KiB

After

Width:  |  Height:  |  Size: 249 KiB

BIN
docs/plans/site-ui-5-shots/evidence__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 311 KiB

BIN
docs/plans/site-ui-5-shots/explorer__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 381 KiB

After

Width:  |  Height:  |  Size: 350 KiB

BIN
docs/plans/site-ui-5-shots/explorer__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 385 KiB

BIN
docs/plans/site-ui-5-shots/explorer__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 263 KiB

After

Width:  |  Height:  |  Size: 255 KiB

BIN
docs/plans/site-ui-5-shots/explorer__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 266 KiB

BIN
docs/plans/site-ui-5-shots/faucet__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 335 KiB

After

Width:  |  Height:  |  Size: 300 KiB

BIN
docs/plans/site-ui-5-shots/faucet__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 335 KiB

BIN
docs/plans/site-ui-5-shots/faucet__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 276 KiB

After

Width:  |  Height:  |  Size: 255 KiB

BIN
docs/plans/site-ui-5-shots/faucet__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 276 KiB

BIN
docs/plans/site-ui-5-shots/home__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.2 MiB

After

Width:  |  Height:  |  Size: 1.1 MiB

BIN
docs/plans/site-ui-5-shots/home__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 1.2 MiB

BIN
docs/plans/site-ui-5-shots/home__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 558 KiB

After

Width:  |  Height:  |  Size: 571 KiB

BIN
docs/plans/site-ui-5-shots/home__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 586 KiB

BIN
docs/plans/site-ui-5-shots/journey__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 328 KiB

After

Width:  |  Height:  |  Size: 304 KiB

BIN
docs/plans/site-ui-5-shots/journey__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 336 KiB

BIN
docs/plans/site-ui-5-shots/journey__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 327 KiB

After

Width:  |  Height:  |  Size: 305 KiB

BIN
docs/plans/site-ui-5-shots/journey__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 337 KiB

BIN
docs/plans/site-ui-5-shots/ledger__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 345 KiB

After

Width:  |  Height:  |  Size: 344 KiB

BIN
docs/plans/site-ui-5-shots/ledger__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 346 KiB

BIN
docs/plans/site-ui-5-shots/ledger__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 374 KiB

After

Width:  |  Height:  |  Size: 350 KiB

BIN
docs/plans/site-ui-5-shots/ledger__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 372 KiB

BIN
docs/plans/site-ui-5-shots/litepaper__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 488 KiB

After

Width:  |  Height:  |  Size: 480 KiB

BIN
docs/plans/site-ui-5-shots/litepaper__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 489 KiB

BIN
docs/plans/site-ui-5-shots/litepaper__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 396 KiB

After

Width:  |  Height:  |  Size: 381 KiB

BIN
docs/plans/site-ui-5-shots/litepaper__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 398 KiB

BIN
docs/plans/site-ui-5-shots/live__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 676 KiB

After

Width:  |  Height:  |  Size: 504 KiB

BIN
docs/plans/site-ui-5-shots/live__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 611 KiB

BIN
docs/plans/site-ui-5-shots/live__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 377 KiB

After

Width:  |  Height:  |  Size: 368 KiB

BIN
docs/plans/site-ui-5-shots/live__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 386 KiB

BIN
docs/plans/site-ui-5-shots/metamask__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 407 KiB

After

Width:  |  Height:  |  Size: 377 KiB

BIN
docs/plans/site-ui-5-shots/metamask__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 407 KiB

BIN
docs/plans/site-ui-5-shots/metamask__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 350 KiB

After

Width:  |  Height:  |  Size: 340 KiB

BIN
docs/plans/site-ui-5-shots/metamask__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 351 KiB

BIN
docs/plans/site-ui-5-shots/miner-band__1440-dark.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
docs/plans/site-ui-5-shots/miner__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 677 KiB

After

Width:  |  Height:  |  Size: 552 KiB

BIN
docs/plans/site-ui-5-shots/miner__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 682 KiB

BIN
docs/plans/site-ui-5-shots/miner__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 477 KiB

After

Width:  |  Height:  |  Size: 401 KiB

BIN
docs/plans/site-ui-5-shots/miner__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 285 KiB

BIN
docs/plans/site-ui-5-shots/miners__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 225 KiB

After

Width:  |  Height:  |  Size: 223 KiB

BIN
docs/plans/site-ui-5-shots/miners__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 223 KiB

BIN
docs/plans/site-ui-5-shots/miners__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 244 KiB

After

Width:  |  Height:  |  Size: 213 KiB

BIN
docs/plans/site-ui-5-shots/miners__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 242 KiB

BIN
docs/plans/site-ui-5-shots/provenance__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 426 KiB

After

Width:  |  Height:  |  Size: 417 KiB

BIN
docs/plans/site-ui-5-shots/provenance__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 425 KiB

BIN
docs/plans/site-ui-5-shots/provenance__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 333 KiB

After

Width:  |  Height:  |  Size: 321 KiB

BIN
docs/plans/site-ui-5-shots/provenance__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 331 KiB

BIN
docs/plans/site-ui-5-shots/randomx__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 396 KiB

After

Width:  |  Height:  |  Size: 401 KiB

BIN
docs/plans/site-ui-5-shots/randomx__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 393 KiB

BIN
docs/plans/site-ui-5-shots/randomx__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 396 KiB

After

Width:  |  Height:  |  Size: 411 KiB

BIN
docs/plans/site-ui-5-shots/randomx__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 392 KiB

BIN
docs/plans/site-ui-5-shots/wallet-band__1440-dark.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/plans/site-ui-5-shots/wallet-band__390-dark.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
docs/plans/site-ui-5-shots/wallet-full__1440-dark.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 1.7 MiB

BIN
docs/plans/site-ui-5-shots/wallet-full__390-dark.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 1.2 MiB

BIN
docs/plans/site-ui-5-shots/wallet__1440-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 571 KiB

After

Width:  |  Height:  |  Size: 652 KiB

BIN
docs/plans/site-ui-5-shots/wallet__1440-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 201 KiB

BIN
docs/plans/site-ui-5-shots/wallet__390-dark.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 427 KiB

After

Width:  |  Height:  |  Size: 411 KiB

BIN
docs/plans/site-ui-5-shots/wallet__390-light.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 451 KiB

4
docs/spec/01-lottery-hash.md
View file

@ -428,7 +428,7 @@ Designed at the level of a sentence in the design document ("a new instruction m
### 1.13.1 Era seed and draw
The era seed `E_n` is the 32-byte output of the 1-hour VDF of section 4.4. One SplitMix64 stream seeded from `seed_words_from_bytes("igneum-era/" || n_le64 || E_n)` words 0 and 1, drawn in a fixed order, sets the era parameters within genesis-fixed bounds:
The era seed `E_n` is the 32-byte output of the 1-hour VDF of section 4.4 (in the node from `era_vdf_activation_daa`, 7 October 2026, era VDF lane: the delay over the hash of the cut block's day under the genesis scheme byte; before the activation, and on every network today, the devnet stand-in below). One SplitMix64 stream seeded from `seed_words_from_bytes("igneum-era/" || n_le64 || E_n)` words 0 and 1, drawn in a fixed order, sets the era parameters within genesis-fixed bounds:
| Parameter | Base (era 0) | Draw | Bound |
|---|---|---|---|
@ -448,7 +448,7 @@ The table layout and the working-set window (Counter ASIC 2.0 layers 4 and 8, de
3. `R = 1 + below(31)`: the stride rotation.
4. to 7. `r_i = next()` for `i` in 0..3: the interleave draws. With `b = log2(W)` and `free = 4 - b`, `c = [b, ..., 15]`; for `i` in `0..free`: `j = i + (r_i mod (16 - b - i))`, swap `c[i]` and `c[j]`; the interleave is `pos = [0, ..., b - 1] ++ sort(c[0..free])`, four ascending bit positions below 16.
The era parameters are `(W, M, R, pos)`. Dataset mapping under class v3: word `w` holds word `j(w)` of item `t(w)`, where bit `i` of `j(w)` is bit `pos[i]` of `w` and `t(w)` is `w` with bits `pos[0..3]` removed; with `pos = [0, 1, 2, 3]` this is `dataset[w] = item(w >> 4)[w AND 15]` byte for byte; an item keeps its value at every dataset size of at least 2^16 words, and the `W` words of one aligned load lie in one item, so the 4,096-item verifier bound of 1.11 holds. Load address under class v3, for a load site with window draws `(k_off, o)` and a dataset of `2^D` words: `k = min(k_off, D - 26)`, `y = rotl(x * M, R)`, `idx = ((y AND (MASK >> k)) OR ((o AND (2^k - 1)) << (D - k))) AND MASK` (uniform on the window, branch-free, three operations before the mask), one text form in Metal, CUDA and OpenCL. The window draws per instruction (layer 8), after the nine draws of 1.4.3: `k_off = below(3)` (the dataset, a half or a quarter) and `o = low32(next()) AND (2^k_off - 1)`, used only on a load slot, so a class v3 program takes 720 draws; the window never goes below 2^26 words (256 MiB, above the largest on-chip cache in the benchmark) nor above the dataset, and sixteen sites with drawn offsets cover the dataset with high probability (a windows-union census over 300 programs: the SRAM mirror a chip would need is the whole dataset in every hour). The acceptance rule of 1.4.6 is unchanged in its tests and mirrors this address at its constant `D = 28`. Devnet stand-in for `E_n` until the VDF of 4.4 is in the node: era 0 the genesis block hash; era `n >= 1` the hash of the last selected-chain block whose DAA score is below `15,552,000 n - 7,200`. What the interleave buys and does not: a chip that hard-wires one layout reads the wrong 15 words with every word once the era draws another; a chip whose address decoder can permute its address lines pays nothing (stated in the plan). The stride is a bijection with no cryptanalysis yet (Open).
The era parameters are `(W, M, R, pos)`. Dataset mapping under class v3: word `w` holds word `j(w)` of item `t(w)`, where bit `i` of `j(w)` is bit `pos[i]` of `w` and `t(w)` is `w` with bits `pos[0..3]` removed; with `pos = [0, 1, 2, 3]` this is `dataset[w] = item(w >> 4)[w AND 15]` byte for byte; an item keeps its value at every dataset size of at least 2^16 words, and the `W` words of one aligned load lie in one item, so the 4,096-item verifier bound of 1.11 holds. Load address under class v3, for a load site with window draws `(k_off, o)` and a dataset of `2^D` words: `k = min(k_off, D - 26)`, `y = rotl(x * M, R)`, `idx = ((y AND (MASK >> k)) OR ((o AND (2^k - 1)) << (D - k))) AND MASK` (uniform on the window, branch-free, three operations before the mask), one text form in Metal, CUDA and OpenCL. The window draws per instruction (layer 8), after the nine draws of 1.4.3: `k_off = below(3)` (the dataset, a half or a quarter) and `o = low32(next()) AND (2^k_off - 1)`, used only on a load slot, so a class v3 program takes 720 draws; the window never goes below 2^26 words (256 MiB, above the largest on-chip cache in the benchmark) nor above the dataset, and sixteen sites with drawn offsets cover the dataset with high probability (a windows-union census over 300 programs: the SRAM mirror a chip would need is the whole dataset in every hour). The acceptance rule of 1.4.6 is unchanged in its tests and mirrors this address at its constant `D = 28`. Devnet stand-in for `E_n` below the activation of the VDF of 4.4 (the VDF is in the node since 7 October 2026, behind `era_vdf_activation_daa`, never until the project lead sets it per network): era 0 the genesis block hash; era `n >= 1` the hash of the last selected-chain block whose DAA score is below `15,552,000 n - 7,200`, the same block the VDF reads its input from once active. The attack pass's F7 harness showed the stand-in grindable with one block of hash at no delay (1 of 6 cuts) and the VDF closing it (`docs/analysis/era-vdf-2026-10-07.md`). What the interleave buys and does not: a chip that hard-wires one layout reads the wrong 15 words with every word once the era draws another; a chip whose address decoder can permute its address lines pays nothing (stated in the plan). The stride is a bijection with no cryptanalysis yet (Open).
"Memory pattern" in the design document is read here as the item-address pattern (the cache line index word, `s[0]` in 1.8.5, and the XOR-all-sixteen rule); the proposal is to leave it fixed at era 0 and let the unlocked families change the kernel instead, because every change to the item derivation changes the verify time and must be re-measured.

41
docs/spec/04-seeds-and-vdf.md
View file

@ -1,6 +1,6 @@
# Igneum protocol specification, section 4: epoch and era seeds through the class-group VDF
Spec version 0.1, 3 October 2026. Status of this section: Measured for the VDF primitive on one machine (`proto-vdf/`, `docs/bench-log.md` entry "proto-vdf, Wesolowski VDF"); Designed for the pipeline; Open where marked. The class-group code has not been reviewed by a second cryptographer (`proto-vdf/README.md`, open item 1).
Spec version 0.1, 3 October 2026. Status of this section: Measured for the VDF primitive on one machine (`proto-vdf/`, `docs/bench-log.md` entry "proto-vdf, Wesolowski VDF"); the ERA path Implemented in the node on 7 October 2026 (era VDF lane, fork branch `era-vdf-node` on the 0.3.19 line: `consensus/core/src/era_vdf/`, `consensus/src/processes/era_vdf.rs`; record `docs/analysis/era-vdf-2026-10-07.md`), behind `era_vdf_activation_daa` (never on every network until the project lead sets it per network), with the scheme byte of 4.2 and the measured reference rates of 4.6; the EPOCH path (4.3) still Designed. The class-group code has not been reviewed by a second cryptographer (O-4.1; the node's port is a second implementation of the same algorithms on a fixed-width integer, checked against `num-bigint` and against the textbook composition, not a review).
## 4.1 Why a delay
@ -24,7 +24,16 @@ proof = (T, y, pi)
verify: rederive D and x, recompute l, check pi^l * x^(2^T mod l) == y, recompute output
```
Tags (Implemented in `proto-vdf/src/seed.rs` for the epoch path): `tag_D = "igneum-epoch-discriminant"`, `tag_l = "igneum-vdf-challenge"`, `tag_out = "igneum-program-seed"`. The era path uses `"igneum-era-discriminant"` and `"igneum-era-seed"` (Designed, not yet in code). Prime |D| kills the 2-torsion, the low-order element Wesolowski must exclude. Whether to mirror chiavdf's byte layout for HashPrime exactly, and whether the proof should carry D (the verifier otherwise pays a 17 ms average prime search), are Open (O-4.5).
Tags (Implemented in `proto-vdf/src/seed.rs` for the epoch path): `tag_D = "igneum-epoch-discriminant"`, `tag_l = "igneum-vdf-challenge"`, `tag_out = "igneum-program-seed"`. The era path (Implemented, `kaspa_consensus_core::era_vdf`) uses `"igneum-era-discriminant"` and `"igneum-era-seed"`, with the scheme byte in the seed preimage: `E_n = SHA-256("igneum-era-seed" || scheme || input || T_be64 || y)`. Prime |D| kills the 2-torsion, the low-order element Wesolowski must exclude. The node derives D itself once per era (the search is a per-era one-off, measured in 4.6) and verifies with the group held; HashPrime's byte layout is this specification's (a 64-bit big-endian counter suffix, not chiavdf's in-place increment), which O-4.5 keeps open only for tooling compatibility.
**The scheme byte and the fallback (7 October 2026, era VDF lane; mission item 8, `docs/analysis/mission/future.md` 7.4 item 5).** The era VDF is one of two schemes behind a genesis byte `vdf_scheme` (`Params::vdf_scheme`, in the digest with the activation and T once the activation is set), the same shape as the vote keys' `sig_scheme`: a flip is a class change under the 95 percent signal with a floor height, never a fork. The bytes are coordinated with the genesis-forward lane's `sig_scheme` (0 = BLS12-381 there; the two bytes are separate fields with the same mechanism, `era_vdf::scheme_known` and `igneum::sig_scheme_of_class` the two tables a class change fills).
| Byte | Scheme | Delay | Proof | Verify | Why it exists |
|---|---|---|---|---|---|
| 0 | Wesolowski over the class group of a 1,024-bit prime discriminant derived from the input (this section) | T squarings | (y, pi), 516 bytes (13 bytes of framing on the wire, `EraVdfProof::to_bytes`) | two short exponentiations, milliseconds (4.6) | the production choice: no trusted setup, Chia precedent |
| 1 | SHA-256 hash chain: `s_0 = SHA-256("igneum-era-hash-chain" || input)`, `s_{i+1} = SHA-256(s_i)`, `y = s_T` | T hashes | the end state, 32 bytes | recomputation: the full delay on one core | the post-quantum fallback: a class group's order is computable on a cryptographically relevant quantum computer (Hallgren's algorithm, polynomial time for imaginary quadratic class groups), and a known order collapses `x^(2^T)` to one short exponentiation; a sequential hash has no known quantum shortcut (Grover does not apply to a sequence) |
The fallback costs every verifier the full delay, which 4.5 already asks of every mining node (one core for an hour per era); what it loses is the 5 ms check for light clients and syncing nodes, who then take `E_n` from the chain's own work (a block mined under the wrong `E_n` fails its proof of work under the right program) or recompute. The flip is sized, not scheduled: `T` for scheme 1 at the reference core is in 4.6.
| Parameter | Value | Label |
|---|---|---|
@ -56,12 +65,14 @@ Determinism of step 1 is the point of the rule: which block is "the checkpoint a
## 4.4 The era seed pipeline
Designed (design document: "The era draw applies a one-hour delay function to the hash of all blue blocks in the day ending at the last certified checkpoint one epoch before the boundary"). Era n is the DAA-score interval `[15,552,000 n, 15,552,000 (n + 1))` (section 1.12).
Implemented in the node on 7 October 2026 (era VDF lane; design document: "The era draw applies a one-hour delay function to the hash of all blue blocks in the day ending at the last certified checkpoint one epoch before the boundary"; `consensus/src/processes/era_vdf.rs`, `consensus/core/src/era_vdf/`). Era n is the DAA-score interval `[15,552,000 n, 15,552,000 (n + 1))` (section 1.12; `igneum::pow_era_blocks`, a constant on every network that a private test network's override file may shorten with `pow_era_blocks` and `pow_era_lead`, in the digest when it does). The pipeline applies to every era whose start is at or above `Params::era_vdf_activation_daa` and never to era 0 (genesis seeds it); below the activation the devnet stand-in of `docs/plans/era-layout.md` section 2 stands (the cut block's hash itself).
1. `C_era(n)` is the highest-index checkpoint whose block has DAA score at most `15,552,000 n - 7,200` (2 hours of lead, 2x the 1-hour evaluation).
2. `input = Hash(chain_id || n_le64 || h_1 || h_2 || ... || h_m)` where `h_1..h_m` are the hashes of the blue blocks in `C_era(n)`'s past with DAA score in `(daa(C_era(n)) - 86,400, daa(C_era(n))]`, in ascending (blue score, hash) order, and `Hash` is the chain's BLAKE2b-based hash. This is a function of `C_era(n)`'s past, so it is as deterministic as 4.3 step 1.
3. Run 4.2 with `T = T_era = 6 x T_epoch` and the era tags. `E_n` is the output.
4. The era draw of section 1.13.1 consumes `E_n` as its only randomness (`proto-vdf/README.md` open item 6: check that nothing else enters the draw).
1. **The cut block.** The cut of era n is the DAA score `15,552,000 n - 7,200` (2 hours of lead, 2x the 1-hour evaluation; `igneum::pow_era_seed_score`). `C_era(n)` is the last selected-chain block below the cut on the chain of the header being validated (`class_signal::seed_below`, the block the stand-in used as `E_n`). This is the checkpoint block the cut rule names under the O-4.3 decision of 3 October 2026 (3.11 item 6: the seed checkpoint is the chain block the lead rule names, certified or not, so a finality pause never stops the program): a function of the header's own past, so two nodes validating one header derive one `C_era(n)`, and a header on a chain that reorged across the cut names another block and is validated under that block's seed. Binding `C_era(n)` to the certified checkpoint instead (the certificate carried by a block in the header's past, the design document's wording) is a change to one function, `EraVdfManager::cut_block`; it would couple the era seed to finality liveness (a pause across the cut leaves the era without a seed) and needs a deterministic rule for a certificate that lands late, which the record (`docs/analysis/era-vdf-2026-10-07.md`, section 4) spells out for the finality lane; the grinding defence does not depend on it, since the delay is what makes any candidate's draw unknowable.
2. **The input.** `input = Hash(chain_id || n_le64 || h_1 || h_2 || ... || h_m)` where `h_1..h_m` are the hashes of the blue blocks in `C_era(n)`'s past with DAA score in `(daa(C_era(n)) - day, daa(C_era(n))]`, `day` being the dataset day (`pow_day_ms / 1,000`, 86,400 DAA s on the devnet) at the network's block rate, in ascending (blue score, hash) order, and `Hash` the chain's BLAKE2b-256 keyed `"IgneumEraVdfInput"` (`era_vdf::era_vdf_input`; `chain_id` the prefixed network name the finality votes use). Walked as the class signal walks a window: every chain block's mergeset blues once each, down to the merge depth below the day's start. A function of `C_era(n)`'s past, memoised per cut block.
3. **The delay.** `era_vdf::evaluate(scheme, input, T_era)` with `scheme = Params::vdf_scheme` and `T_era = Params::era_vdf_t` (4.6): under scheme 0, 4.2 with the era tags; under scheme 1, the hash chain. Every node runs it itself on one thread (the prover's residue classes on up to 8), started by the virtual processor once the sink is a quarter of the lead past the cut (the epoch seed's confirm margin: right at the cut the selected chain still flips between sibling tips), and persisted (`DbEraVdfStore`, one row per era: input, proof, `E_n`) when it ends, an hour before any header of the era can exist under the 2x lead. A header that arrives before the node holds the record (a node syncing across an era boundary with no peer's proof, 4.5) waits for the evaluation on the header processor's thread.
4. **The seed.** `E_n = SHA-256("igneum-era-seed" || scheme || input || T_be64 || y)`, which the era draw of section 1.13.1 consumes as its only randomness (O-4.8: the draw's preimage is `"igneum-era/" || E_n`, nothing else; the node hands the generator `E_n` alone through `EpochSeeds::era`). Every block template reports `E_n` as `era_seed`, the input, the scheme, T and the evaluation state (`PowEpochInfo`), and reports no `era_seed` while the node is still evaluating, on which the miner holds (`igneum-miner`: "era VDF: the node is still evaluating").
The gate the attack pass set (F7 sub-row a, `docs/analysis/attack-pass/f7-era.md`): the re-roll harness fires with the VDF off and is silent with it on. Measured 7 October 2026 on the box, `tools/era-vdf/reroll.mjs` against the real era cut on a fast-time network (era 120 DAA, lead 20): the record's section 3 carries both runs.
## 4.5 Who evaluates, who verifies
@ -69,6 +80,8 @@ Every mining node evaluates both VDFs itself: one CPU core for 10 minutes each h
There is no timelord role and no race: unlike Chia, the chain does not wait for the VDF; it uses a VDF output that was fixed 20 minutes (epoch) or 2 hours (era) earlier. "No node evaluates" means no miner is running a CPU, which means nobody is mining.
Implemented for the era (7 October 2026): every node evaluates (4.4 step 3) and holds the record; `EraVdfManager::submit` accepts a record from outside when its input is the one this node derives for the era, its scheme and T are the network's, its proof verifies and its output is the seed of the proof. What is still owed before era 1 of any network with the switch set (180 days after that network's genesis at the earliest): the P2P message type that gossips the record and serves it to a syncing peer, and the RPC that imports one; until then a node syncing across an era boundary evaluates the delay itself on its header processor's thread (4.4 step 3).
## 4.6 T from a reference core rate, fixed at genesis
Designed (`proto-vdf/README.md`, parameter recommendation). Before genesis, run `vdf bench` (or chiavdf's `vdf_bench`) on every devnet node type that will mine, take the fastest honest single-core NUDUPL rate observed as `r_ref` (squarings per second), and fix at genesis:
@ -80,6 +93,20 @@ Designed (`proto-vdf/README.md`, parameter recommendation). Before genesis, run
Choosing the fastest honest core, not the median, keeps the stated 10 minutes an upper bound for honest nodes and leaves the attacker margin intact. T MUST NOT be derived from on-chain timing, which is manipulable. T is a genesis constant; hardware will get faster over the years and the margin will erode slowly from 300x, which a fixed T covers for decades, and the upgrade path of section 5.7 exists if it is ever needed.
**The era constants as set (7 October 2026, era VDF lane; `docs/analysis/era-vdf-2026-10-07.md` section 2).** The reference rate is the NODE's own evaluator (the fixed-width-integer class group of `kaspa_consensus_core::era_vdf`), not chiavdf's, because an honest node runs the node's code and must finish inside the lead: the two rules are "T from the honest evaluator's rate" and "the margin against the fastest prover anyone can run". Measured on one core of igneum-build-2 (AMD EPYC 9454P, nice 10, the box under load):
| Constant | Value | Basis |
|---|---|---|
| `ERA_VDF_REFERENCE_SQUARINGS_PER_S` | 30,000 | the node's evaluator at 30,589 and 40,117 squarings/s in two runs; the lower run is the reference, so the hour is an upper bound at it |
| `T_era`, scheme 0 (`ERA_VDF_T_CLASS_GROUP`, `Params::era_vdf_t`) | 108,000,000 squarings | 3,600 x 30,000; 45 to 60 min on the box core, about 72 min on a 2019-class core (the F6 calibration), inside the 2-hour lead |
| `ERA_VDF_REFERENCE_HASHES_PER_S` | 16,000,000 | SHA-256 chain at 16.2 and 17.0 million/s (SHA-NI) |
| `T_era`, scheme 1 (`ERA_VDF_T_HASH_CHAIN`) | 57,600,000,000 hashes | 3,600 x 16,000,000 |
| Verify, scheme 0 | 21.9 to 22.6 ms with the group held; the discriminant derivation 161 to 167 ms once per era | the 10-ms gate is missed by 2.2x on the box core; the record's section 5 says what closes it (O-4.6's reducer, a limb-level NUDUPL, or GMP behind a feature on x86-64) |
| Prove, scheme 0 | about 14 percent of the evaluation single-threaded, parallel over residue classes | at T 401,167: eval 10.0 s, prove 1.6 s |
| The fastest prover measured | chiavdf's NUDUPL over GMP at 208.8 K squarings/s on the same core (its AVX-512 IFMA path was not established in this build) | the delay at that prover: 517 s, 517x the 1-s block interval and 259x the 2-s window; at a hardware prover 10x faster, 52 s, still 26x the window |
The epoch constants (`T_epoch`) stay as this section designs them until the epoch path is implemented; a measured `T_epoch` would be 600 x the same reference rate, 18,000,000 squarings.
| Attacker evaluator speed vs reference | Epoch delay | Era delay | Beats the 2-s window |
|---|---|---|---|
| 1x | 600 s | 3,600 s | no, margin 300x |

Some files were not shown because too many files have changed in this diff Show more