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

Spec: close F2, F3, P5, P8, C9, E7, G7, X6 by rule or decision (3 October 2026)

Browse source 
- 03-finality: Q2 participation from every vote seen in blocks (votes are
  block payload); 3.3.2 the eclipse case closed by the 56.7% floor with the
  sim v2 F2 numbers; 3.4.1 why aggregators cannot grind participation.
- 07-execution (new): EVM semantics on the DAG, shard sortition (8 provers,
  10 s, then open, no shard bond), bridges (none official, no bridged
  stablecoins at genesis, proof bridge with the consensus proof in phase two).
- 08-client-security (new): reproducible builds, release key in genesis and
  in hardware, no silent updates, consensus only by 90% signalling, notarised
  builds, official sources with the hash, seed confirmed before mining,
  hardware wallet, the permanent seed line.
- 00, 02, 05, README, 06: cross-references, O-2.8 removed, O-3.3, O-3.7,
  O-5.1, O-5.2, O-5.6 narrowed, O-8.1 added, counts kept at 60.
- Ledger: eight Status lines, status table, count table, overclaims 38, 40, 71.
- FUD fixes: rows 23, 26, 38, 62, 64, 66, 67, 70, 72, section 3 and 4.
- Site: bridge and stablecoin sentences no longer launch features; the seed
  line wherever the app appears.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-03 18:58:39 +00:00
parent 3095fca303
commit 95bdd48631
12 changed files with 239 additions and 57 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
docs/fud-fixes.md
View file

@ -7,10 +7,10 @@ Decisions of 3 October 2026 applied throughout: (a) no development fund, priorit
## 1. Summary
1. The ledger holds 80 entries and 78 overclaim items. Every entry appears once below: 64 open or conceded entries across 74 rows in section 2, and 16 answered entries that still carry a fix in section 2.1.
2. Open: 19 entries. 8 close on a measurement, 7 on a specification or design decision, 4 on counsel or a search (L1, L2, L4, L5).
2. Open: 11 entries after the evening closures of 3 October 2026 (F2, F3, P5, P8, C9, E7, G7, X6 closed by rule or decided; section 4). 7 close on a measurement, 4 on counsel or a search (L1, L2, L4, L5).
3. Conceded: 45 entries. 13 are already stated in public text, 32 are not.
4. Answered: 16 entries. All 16 still carry a wording fix, an experiment or a counsel check.
5. Overclaims: 78 items. 7 already fixed (5, 6, 9, 22, 23, 27, 47), 3 partly fixed (11, 31, 75), 68 still present or still missing. Item 23 is fixed but stale. Item 73 must not be applied as written.
5. Overclaims: 78 items. 10 already fixed (5, 6, 9, 22, 23, 27, 38, 40, 47, 71), 3 partly fixed (11, 31, 75), 65 still present or still missing. Item 23 is fixed but stale. Item 73 must not be applied as written.
6. The 3 October decisions close E4 outright, narrow G4, G8 and L3, and change E3, E5, G3 and G5 (section 4). The dev fund removal forces a rewrite of 11 places in the site, spec and design files (row 7).
7. EXPOSES: six items. CLAUDE.md (full name, other companies, registrar, database region, personal GitHub handle), the cryptographer agent file, the commit handle igneum-labs, the +0100 timezone on every commit, the earlier ledger text "The founder is in the UK" still in git history, and the ledger itself in the tree. All are fixed in section 5.
8. Measured since the ledger was written: the 256 MB cache dataset is built and bit-exact on Apple, NVIDIA (CUDA and OpenCL) and an AMD integrated chip; the shortcut is 4.8x slower than honest on Apple; CPU verify is 0.41 to 1.2 ms per warp with the cache; the VDF grinding simulation ran. Items 16, 20, 21, 23, 56 and 78 need these facts, not the ledger's replacements.
@ -45,10 +45,10 @@ Who: the project lead (decision or account), Claude (text, spec, code, simulatio
| 20 | P2 | Launch gas budget unstated | Publish the launch budget as a formula: cards proving times shards per card per minute | Claude | now | no |
| 21 | P3 | "a phone can check it in milliseconds" | Item 25 | Claude | now | no |
| 22 | P4 | "Trustless light clients ... need no multisig" (LP 171) | Item 38 (item 9 is done) | Claude | now | no |
| 23 | P5 | "runs on Igneum unchanged" (abstract and LP 168); "Three things run on Igneum that run nowhere else" | Items 35 and 36, plus the abstract sentence | Claude | now | no |
| 23 | P5 | "runs on Igneum unchanged" (abstract and LP 168); "Three things run on Igneum that run nowhere else" | Items 35 and 36, plus the abstract sentence; the documented differences now exist in spec 7.1 (P5 closed 3 October 2026), so the replacement can point at them | Claude | now | no |
| 24 | P6, C10 | "cheapest supplier", "lowest cost", "last provers to switch off" (LP 73, 222, 277, 293) | Items 12, 49 and 55, plus the "guaranteed income floor" paragraph | Claude | now | no |
| 25 | P7 | "a block with a wrong state cannot exist"; "Nothing in it ever needs a human" | Items 3 and 26 | Claude | now | no |
| 26 | P10, E7 | Economics says outsiders pay in IGN and part is burned; the miner section says they pay in their own money; "Stablecoins at genesis ... through the proof bridge" (LP 176, 284) | Items 40, 52 and 71 | Claude | now | no |
| 26 | P10, E7 | Economics says outsiders pay in IGN and part is burned; the miner section says they pay in their own money; "Stablecoins at genesis ... through the proof bridge" (LP 176, 284) | Items 40 and 71 applied 3 October 2026 (E7 decided, spec 7.3); item 52 (the P10 contradiction in Economics) still open | Claude | now | no |
| 27 | E1, E6 | Supply states the cap, not the tail-emission trade-off; halvings presented as fact, not a bet | Two sentences in Supply: the tail alternative and why the cap was chosen; the halving schedule is a bet, a tail can be added by 90% signalling | Claude | now | no |
| 28 | G1 | "named reviewers" who do not exist; "The specification is public" (LP 271) | Items 48 and the third item of 78 | Claude | now | no |
| 29 | G2 | Method undisclosed | Item 72. Keep the Co-Authored-By trailers in the history: they are the evidence the entry cites | Claude; the project lead confirms the trailers stay | now | no |
@ -60,7 +60,7 @@ Who: the project lead (decision or account), Claude (text, spec, code, simulatio
| 35 | C7 | New miners vote after a month, unstated | One sentence in Finality: a new miner's vote reaches full weight after a month; its rewards do not wait | Claude | now | no |
| 36 | F1, X9 | First month: Finality has the thin-weights sentence (item 31 partly done); "Fair launch" and "What Igneum does not claim" do not; "exchanges are told to treat it so" missing; "no amount of fresh hashrate" remains | Finish item 31; apply item 75 and the second item of 78 | Claude | now | no |
| 37 | F8 | Day counts quoted as facts | Item 74 | Claude | now | no |
| 38 | F2 | The two-hour window's exposure unstated | Item 34 | Claude | now | no |
| 38 | F2 | The two-hour window's exposure unstated | Item 34; the source text is now spec 3.3.2 (F2 closed by the floor, 3 October 2026) | Claude | now | no |
| 39 | X3 | "All of it will be on this page, live" with no date | Item 61 | Claude | now | no |
| 40 | F12 | "Nothing in Igneum's consensus depends on anything outside Igneum" (LP 166) | Scope to "no other chain's state"; name the code dependencies (SP1, BLS12-381, class-group VDF, rusty-kaspa) in one line | Claude | now | no |
| 41 | F13 | Why prove if every node executes: unstated | One sentence under the 20% row: the share pays a standing prover population, and the proof serves light clients, bridges and sync from a proven checkpoint | Claude | now | no |
@ -84,17 +84,17 @@ Who: the project lead (decision or account), Claude (text, spec, code, simulatio
| 59 | L6 | Dollar-paid job market read as money transmission | Counsel confirms the no-custody structure before phase 4 | counsel | before testnet | no |
| 60 | M11 | Hourly compile on real rigs unmeasured | O-1.16: miner client prototype on a multi-card rig; compile time and failure rate per hour | measurement | before testnet | no |
| 61 | F1 | No weight in the first month | O-3.1: launch-month simulation; decide the no-certificate-for-30-days rule; the litepaper states it either way | Claude (sim), the project lead (decision) | before testnet | no |
| 62 | F3 | Participation grinding through the bitmap | O-3.3: choose among the section 3.4 candidates, simulate with a hostile aggregator | Claude | before testnet | no |
| 62 | F3 | Participation grinding through the bitmap | Closed by rule 3 October 2026: spec 3.3 Q2 and 3.4.1, participation from every vote seen in blocks. Remaining: O-3.3, the per-block vote bound and the re-run under the block reading | Claude (sim) | before testnet | no |
| 63 | F7 | Checkpoint depth 60 is a placeholder | O-3.2: devnet with regional latency, reorg-depth distribution per block rate | measurement | before testnet | no |
| 64 | F2 | Presence window as an eclipse vector | O-3.7: devnet single-node eclipse; choose the 2-hour window or the 7-day silent-key rule | measurement | before testnet | no |
| 64 | F2 | Presence window as an eclipse vector | Closed by rule 3 October 2026: spec 3.3.2, the 56.7% floor. Remaining: O-3.7, the devnet single-node eclipse as confirmation; no rule choice | measurement | before testnet | no |
| 65 | C4 | The overlay changes GHOSTDAG's guarantees | O-3.8: devnet runs with the module on and off; adversary simulation from real pool-hashrate traces | measurement | before testnet | no |
| 66 | P8, C9 | First-come shards centralise | O-5.1: sortition of shards in the spec; measure on the phase 4 devnet | Claude (spec), measurement | before testnet | no |
| 67 | P5 | EVM semantics on a DAG | O-2.8: execution-layer spec for number, timestamp, blockhash, coinbase and prevrandao over the ordered sequence; proving cost folded into the quoted gas price | Claude | before testnet | no |
| 66 | P8, C9 | First-come shards centralise | Closed by rule 3 October 2026: spec 7.2, sortition to 8 provers for 10 s then open, no shard bond. Remaining: O-5.1, the parameters on the phase 4 devnet | measurement | before testnet | no |
| 67 | P5 | EVM semantics on a DAG | Closed by spec 3 October 2026: spec 7.1 (number, timestamp and its monotonicity rule, blockhash, PREVRANDAO from the epoch VDF, coinbase, gas limit, chain id, quoted gas price); O-2.8 removed | done | done | no |
| 68 | P7 | Soundness-bug handling | Spec rule: a full node rejects a proof whose state root differs from its own execution; the proof-system version has a stated human emergency path | Claude | before testnet | no |
| 69 | P9 | Shard bond and timeout open | O-5.6 on the phase 4 devnet | measurement | before testnet | no |
| 70 | E7, P10 | Genesis bridge trust model undecided | O-5.2: committee-attested and labelled, or no bridged stablecoins at genesis | the project lead | before testnet | no |
| 70 | E7, P10 | Genesis bridge trust model undecided | Decided 3 October 2026: spec 7.3, no bridged stablecoins at genesis, no official bridge, proof bridge with the consensus proof in phase two; LP and HP text changed. Remaining: O-5.2, how the IGN settlement switch is activated | done (the project lead); Claude for O-5.2 | before testnet | no |
| 71 | G1 | No cryptographer; no named reviewers | Contract a cryptographer for phases 1 and 2; name and pay external reviewers before gate 3 | the project lead | before testnet | EXPOSES: contracts come from the entity; reviewers are told the founder is pseudonymous |
| 72 | G7, X6 | The update channel is a key; the installer is a honeypot vector | Policy: signed reproducible builds, hashes in the repo, key in hardware with a published policy, official download list, seed shown before mining, a standing "nobody asks for a seed" note; antivirus flagging documented | Claude (policy), the project lead (key custody) | before testnet | no |
| 72 | G7, X6 | The update channel is a key; the installer is a honeypot vector | Decided 3 October 2026: spec 08-client-security.md (reproducible builds, release key in genesis and in hardware, no silent updates, consensus only by 90% signalling, notarised builds, official sources with the hash, seed confirmed before mining, hardware wallet, the permanent line). The line is on HP and LP. Remaining: O-8.1, the key custody policy and toolchain publication | the project lead (key custody) | before testnet | no |
| 73 | X5 | "1,000 independent miners" is a Sybil number | Define independence measurably (distinct ASNs, benchmark hardware fingerprints, pool attestations) before the gate is tested | Claude drafts, the project lead decides | before testnet | no |
| 74 | G4 | Genesis contract and bridge key policies | Publish each genesis contract's key policy before launch (O-5.4 without the fund contract) | Claude, the project lead | before mainnet | no |
@ -161,9 +161,9 @@ Checked against the files this evening. "present" means the quoted text is still
| 35 | LP building | present | also the abstract "runs on Igneum unchanged" |
| 36 | LP building | present | |
| 37 | LP building | present | |
| 38 | LP building | present | |
| 38 | LP building | fixed | applied 3 October 2026 |
| 39 | LP building | present | "Canto and Blast proved" |
| 40 | LP building | present | |
| 40 | LP building | fixed | applied 3 October 2026 with the decided text, not the ledger's replacement |
| 41 | LP builders ask | present | |
| 42 | LP builders ask | present | |
| 43 | LP governance | present | |
@ -194,7 +194,7 @@ Checked against the files this evening. "present" means the quoted text is still
| 68 | LP and HP heading | present | both |
| 69 | LP roadmap | missing | |
| 70 | LP mining table | present | |
| 71 | LP builders | present | heading and the builders-ask answer |
| 71 | LP builders | fixed | heading, the Arbitrum and Base line, "an Ethereum bridge, ship at genesis" and the builders-ask answer, 3 October 2026 |
| 72 | LP cover | missing | the sentence names the method only, never a location |
| 73 | LP who are you | do not apply | the founder is pseudonymous now; use the row 9 text |
| 74 | LP finality | missing | |
@ -214,6 +214,16 @@ Closed:
- X7, the ledger submission route: moot by (b). A contact route for the litepaper is still needed (row 3).
- Overclaim 30's cross-reference to the ledger: dropped by (b). Overclaim 53 and the fund half of 46: superseded by (a), rewrite instead of applying.
Closed on the evening of 3 October 2026 (written into `docs/spec/` the same evening):
- F2: the quorum floor of rule v2 is the answer to the eclipse case (spec 3.3.2). O-3.7 is confirmation only.
- F3: participation from every vote seen in blocks, votes are block payload (spec 3.3 Q2, 3.4.1). O-3.3 keeps the parameter.
- P5: EVM semantics on the DAG (spec 7.1). O-2.8 removed.
- P8 and C9: shard sortition, 8 provers, 10 s, then open, no shard bond (spec 7.2). O-5.1 keeps the measurement; O-5.6 is the job bond only.
- E7: no bridged stablecoins at genesis, no official bridge, proof bridge in phase two (spec 7.3). Overclaims 38, 40 and 71 applied; O-5.2 keeps the settlement switch.
- G7 and X6: client security policy (spec 08). The permanent line is on HP and LP. O-8.1 is the key custody policy.
- The ledger's Count by status table and the eight Status lines were updated by the same commit.
Changed, not closed:
- E3 (wash gas): under 80/20 a developer alone gets 20% of its own tip back and loses 80%. A developer who also mines the block gets 80% plus 20%, less the provers' part of the 80%. The only certain loss is the base fee. The ledger's "guaranteed loss of 20% of the tip plus the base fee" no longer holds. the project lead confirms the 15% priority-fee burn is gone on purpose; if not, the split is 80/20 of what remains after a burn and the numbers in row 7 change.

27
docs/fud-ledger.md
View file

@ -16,6 +16,7 @@ Statuses used:
| Answered by design | A consensus rule or a design decision answers it; no measurement is needed or possible yet |
| Open, experiment scheduled | We do not know. The experiment and its date are named |
| Conceded | The critic is right. "Stated" means the litepaper already says so; "not yet stated" means the litepaper must change, and the fix is in the overclaims list at the end |
| Closed by rule, Decided, Closed by removal | A rule now in `docs/spec/`, a decision by the project lead, or a removal answers it as of the date given, and the spec section is named. The status it replaced is kept on the line |
Submitting a criticism: open an issue on the repository once it is public (January 2027, with the benchmark), or use the contact route on igneum.network. Anything that is not already in this ledger, or that shows an entry here is wrong, gets added with credit if wanted.
@ -158,7 +159,7 @@ Evidence: arithmetic above (not yet in `sim/`); design doc, hostile review table
### F2. The two-hour presence window is an eclipse vector
"Cut the big pools' vote gossip for two hours, not their blocks, and the remaining keys become 100% of active weight. A faction with a fifth of the weight locks alone. You chose liveness over safety and called it a feature."
Status: Open, experiment scheduled.
Status: Closed by rule (3 October 2026). Spec section 3.3.2: the 56.7%-of-total floor in Q3 is the answer; 0 conflicting locks at 1, 2 and 4 h against a 34% attacker (`sim/results_v2.md` F2); the devnet eclipse of O-3.7 is confirmation only. Was: Open, experiment scheduled.
Answer: Correct that the presence window trades safety for liveness. The design doc says so: "any event that keeps honest keys from signing (eclipse, partition, targeted DoS) shrinks the denominator and lets a smaller faction lock," and the simulation recommends the fail-safe all-keys denominator while the design chose the presence window as the working default. The mitigation in the rule is that a lock requires the certificate's unscaled weight to reach two thirds of active weight, so an eclipsed set still has to be out for most of the 240 checkpoints before the denominator moves far, and votes travel in blocks as well as as their own messages. That is an argument, not a measurement. The gate 3 experiment is a devnet with regional latency and a single-node eclipse recording whether conflicting locks appear, plus the choice between a 2-hour and a 7-day silent-key rule. Until it runs, this entry stays open.
@ -167,7 +168,7 @@ Evidence: `sim/results.md` table E and "What the simulation cannot tell us"; des
### F3. Participation grinding through the bitmap
"The aggregator picks which votes go in the certificate once quorum is reached. A block producer carries the certificate it likes. Drop a rival pool's votes from your bitmaps for two hours and its participation factor falls, your share rises."
Status: Open, experiment scheduled.
Status: Closed by rule (3 October 2026), parameter open. Spec section 3.3 Q2 and 3.4.1: participation is computed from every vote seen in blocks over the presence window (votes are block payload), never from the certificates an aggregator chose; the per-block vote bound is O-3.3. Was: Open, experiment scheduled.
Answer: This is a new finding from writing this ledger and it is not in the design doc. The participation factor is "observed certified votes over P divided by expected votes". If "observed" means votes present in certificates carried in blocks, then whoever aggregates and whoever produces blocks can shape it. Candidate fixes: participation computed from all votes seen in blocks (votes as transactions, not only certificates), or a certificate must include every valid vote the aggregator received above a size bound, or participation falls only on checkpoints where the key's vote appears in no certificate and no block. Goes to the cryptographer for phase 1 and to the gate 3 simulation.
@ -306,7 +307,7 @@ Evidence: design doc, hostile review table rows "Slashing an external prover" an
### P5. EVM "unchanged" on a DAG is false
"block.number, block.timestamp, blockhash, coinbase, prevrandao. On a DAG none of these mean what Solidity assumes. Plus your 2D fee market: wallets estimate one gas, you charge two."
Status: Open, specification scheduled.
Status: Closed by spec (3 October 2026). Spec section 7.1 fixes block.number, timestamp and its monotonicity rule, blockhash, PREVRANDAO from the epoch VDF, coinbase, gas limit, chain id and the quoted gas price; "unchanged" is not claimed. Was: Open, specification scheduled.
Answer: Correct. The review listed this and the answer is "to be defined over the ordered sequence in the spec", phase 1. Timestamp and number come from the ordered sequence; blockhash and coinbase need a definition; prevrandao can be derived from the epoch VDF. The proving-cost dimension is folded into the quoted gas price by the node so `eth_estimateGas` keeps working, and a contract heavy in pairing or modexp precompiles will cost more here than on Ethereum. "Unchanged" should become "same bytecode, with these documented differences".
@ -333,7 +334,7 @@ Evidence: design doc "Proof system churn" risk item. Rule: not yet. Fix: overcla
### P8. Fastest prover wins all the shards
"Aleo's lesson was that proving as a race centralises to the fastest. Your shards are claimed first-come with a bond. The lowest-latency datacentre claims every shard before a home card sees it."
Status: Open, design change scheduled.
Status: Closed by rule (3 October 2026). Spec section 7.2: sortition keyed to the block assigns each shard to 8 eligible provers for a 10-s window, then open claiming; parameters measured at the phase 4 devnet (O-5.1). Was: Open, design change scheduled.
Answer: Fair, and the lottery/proving separation does not by itself fix it. If claims are first-come, latency wins. The candidate rule is sortition of shards: a VRF keyed to the block assigns each shard to a set of eligible provers, weighted by past proving or by a lottery, with fallback to open claiming after a timeout. This is a phase 1 specification item and a phase 4 devnet measurement. The 20% proving pool is paid per block as a fixed amount divided by consensus proving cost, so a prover's income is bounded by the shards it is assigned, not by how many it can grab.
@ -418,7 +419,7 @@ Evidence: none; decision in design doc "Supply".
### E7. No stablecoin liquidity without a trusted bridge
"USDC and USDT 'bridged through the proof bridge at genesis'. The bridge needs a consensus proof you have scoped as phase two. So genesis stablecoins either wait or run on a multisig you said you would never have."
Status: Open, design decision scheduled.
Status: Decided (3 October 2026). Spec section 7.3: no bridged stablecoins at genesis, no bridge is called official, anyone may run one at their own risk, the proof bridge arrives with the consensus proof in phase two. Overclaims 38, 40 and 71 applied. Was: Open, design decision scheduled.
Answer: Correct. The Ethereum-side bridge contract verifying Igneum state at launch has to verify a lock certificate, which means knowing the voter set and weights; that is the consensus proof scoped as phase two. Options: a committee-attested bridge at launch, clearly labelled as such, with the proof bridge replacing it; or no bridged stablecoins at genesis. The litepaper must stop presenting the proof bridge as a genesis feature until the decision is made. Phase 4.
@ -494,7 +495,7 @@ Evidence: none in repository. Fix: overclaims list, item 45.
### G7. The one-click app is an update key over the network
"An app that auto-updates on ten thousand machines is an admin key. Whoever signs the update controls the miners, the wallets the app made, and the vote keys."
Status: Open, policy scheduled.
Status: Decided (3 October 2026). Spec section 8 (8.1 to 8.3): reproducible builds with hashes in the repository, every release signed by the key published in genesis and held in hardware, the client refuses a mismatched signature, no silent updates, consensus never changes through the app. Was: Open, policy scheduled.
Answer: Correct. The update channel is a key and will be named as one: signed, reproducible builds with published hashes; no silent updates; the app refuses an update whose signature does not match the key published at genesis; the key is held in hardware and its policy published. Consensus rules never change through the app, since activation needs 90% of blocks signalling. Phase 5.
@ -588,7 +589,7 @@ Evidence: none in repository; to be cited from their repositories. Fix: overclai
### C9. vs Aleo: you will centralise the same way
"Aleo tried proofs as consensus and the fastest prover won. You keep the lottery separate but the proving pool is still a race."
Status: Open, design change scheduled.
Status: Closed by rule (3 October 2026). Spec section 7.2, with P8. Was: Open, design change scheduled.
Answer: See P8. The separation protects block production from prover centralisation; it does not by itself protect the proving pool. Sortition of shards is the scheduled fix.
@ -731,7 +732,7 @@ Evidence: `site/journey.json` phase 5 gate.
### X6. The one-click app is a honeypot vector
"An installer that creates a wallet, holds keys and mines, promoted to people who have never run a miner. Fake copies will be the first Google result. Defender flags every miner as malware."
Status: Open, policy scheduled.
Status: Decided (3 October 2026). Spec section 8 (8.4 and 8.5): notarised builds on every platform, downloads only from the domain and the repository with the hash beside the button, seed shown and confirmed before mining, hardware wallet option, and the permanent line "Nobody from Igneum will ever ask for your seed." wherever the app appears. Was: Open, policy scheduled.
Answer: Correct on all three. Mitigations: signed, notarised builds on every platform; reproducible builds with hashes in the repository; downloads only from the domain and the repository with the hash shown; seed phrase shown and confirmed before mining starts, with a hardware-wallet option; a published list of the only official download locations and a standing note that nobody from the project ever asks for a seed. Antivirus flagging is a known cost of shipping a miner and the app will document it. Phase 5.
@ -780,8 +781,9 @@ Evidence: `site/journey.json`.
| Status | Count | Entries |
|---|---|---|
| Answered with evidence | 2 | M8, M10 |
| Answered by design | 14 | M3, M12, F4, F9, F11, F12, F13, P9, E2, E3, E4, C1, C12, L6 |
| Open, experiment or decision scheduled | 19 | M1, M5, M6, M11, F2, F3, F7, P3, P5, P8, E7, G7, C4, C9, L1, L2, L4, L5, X6 |
| Answered by design | 13 | M3, M12, F4, F9, F11, F12, F13, P9, E2, E3, C1, C12, L6 |
| Open, experiment or decision scheduled | 11 | M1, M5, M6, M11, F7, P3, C4, L1, L2, L4, L5 |
| Closed by rule, Decided or Closed by removal (3 October 2026) | 9 | E4, F2, F3, P5, P8, C9, E7, G7, X6 |
| Conceded, stated in the litepaper or design doc | 13 | F6, F8, P2, P6, E1, E6, E8, G3, G5, G8, C7, X3, X4 |
| Conceded, not yet stated (fix in the overclaims list) | 32 | M2, M4, M7, M9, M13, F1, F5, F10, P1, P4, P7, P10, E5, G1, G2, G4, G6, C2, C3, C5, C6, C8, C10, C11, L3, X1, X2, X5, X7, X8, X9, X10 |
@ -906,12 +908,14 @@ Replace with: "We know of no other EVM chain with a prover network in its base l
38. LP building: "Trustless light clients. Because every block is proven, a phone or a browser verifies Igneum's state by checking one proof and the latest locked checkpoint. Bridges built on that need no multisig, the piece that has failed in the biggest bridge hacks."
Replace with: "Light clients. Because every block is proven, a phone or a browser verifies Igneum's state from one proof and a locked checkpoint it is given. Making the checkpoint itself self-verifying, which is what removes the multisig from bridges, needs a consensus proof and is phase two."
Applied 3 October 2026 (E7 decided, spec 7.3).
39. LP building: "Canto and Blast proved builders come for this."
Replace with: "Canto's contract-secured revenue and Blast's gas sharing showed builders respond to it."
40. LP building: "Stablecoins at genesis. USDC and USDT bridged through the proof bridge, canonical versions on Igneum, the way Arbitrum and Base launched."
Replace with: "Stablecoins. USDC and USDT bridged to Igneum as canonical versions. Whether the genesis bridge is proof-verified or committee-attested is decided in phase 4 and will be labelled."
Replace with (decision of 3 October 2026, spec 7.3; the earlier replacement "decided in phase 4 and will be labelled" is superseded): "Stablecoins. None are bridged at genesis. No bridge is official, anyone may run one at their own risk, and the proof bridge that needs no multisig arrives with the consensus proof in phase two."
Applied 3 October 2026, with the builders-ask answer rewritten to match.
41. LP builders: "And the only user base a new chain has ever had that did not have to be paid to arrive."
Delete.
@ -1006,6 +1010,7 @@ Replace with: "Ethereum's growing dataset ran Bitmain's E3 out of memory in 2020
71. LP builders: "Stablecoins at genesis" heading and "the way Arbitrum and Base launched"
Covered by item 40; remove "at genesis" until E7 is decided.
Applied 3 October 2026: E7 decided (no bridged stablecoins at genesis, spec 7.3); the heading, the Arbitrum and Base comparison, "an Ethereum bridge, ship at genesis" and "bridged through the proof bridge at genesis" in the builders-ask answer are all gone.
72. LP cover status line: "Status pre-specification, pre-testnet"
Keep. Add: "Method: designed and prototyped by the founder with AI assistance; measurements reproducible from the logs; external review before gate 3."

4
docs/spec/00-overview.md
View file

@ -14,8 +14,10 @@ This specification defines the Igneum layer 1 so that a stranger can reimplement
| 4 | `04-seeds-and-vdf.md` | The epoch and era seed pipeline through the class-group VDF |
| 5 | `05-fees-and-economics.md` | Fees, splits, burns, signalling thresholds, no development fund |
| 6 | `06-open-items.md` | Every parameter or rule that is unmeasured, unreviewed or marked open, with the experiment that closes it |
| 7 | `07-execution.md` | The normative part of the execution layer: EVM semantics on the DAG, shard assignment by sortition, bridges |
| 8 | `08-client-security.md` | The official client and its release process: reproducible builds, the release key, no silent updates, distribution, the seed |
Out of scope for version 0.1: the zkEVM execution layer, the chunked proving protocol, the proof format carried in headers, the external job market, the P2P wire format, the RPC surface, the miner client and pool protocol. Where a later section depends on one of these, the dependency is named as a forward reference and the behaviour the dependency must provide is stated.
Out of scope for version 0.1: the rest of the zkEVM execution layer (transaction model, gas tables, proof records, the proving interface; `docs/design/execution-layer.md`), the chunked proving protocol, the proof format carried in headers, the external job market's contract, the P2P wire format, the RPC surface, the pool protocol. Where a later section depends on one of these, the dependency is named as a forward reference and the behaviour the dependency must provide is stated.
## 0.2 Normative language

4
docs/spec/02-consensus.md
View file

@ -57,7 +57,7 @@ Kaspa's `Header` (version, parents, hash_merkle_root, accepted_id_merkle_root, u
Also edited (fork map d): p2p `p2p.proto:76 to 89`, `convert/header.rs:13, 45`; RPC `rpc.proto:25`, `model/header.rs:85, 105, 248`; genesis headers; the headers store (serde, re-sync needed); header mass.
Certificates (section 3, C3) travel in the block body, not the header: every block carries the highest certificate its producer knows, and a block whose selected chain does not pass through every certified checkpoint in its past is invalid (post-PoW validation, fork map e2).
Certificates (section 3, C3) and votes (section 3, Q2) travel in the block body, not the header: every block carries the highest certificate its producer knows and every valid vote it has received for the presence window that is not already in its past, and a block whose selected chain does not pass through every certified checkpoint in its past is invalid (post-PoW validation, fork map e2).
## 2.5 Emission (fork points b1, b2, b3)
@ -97,7 +97,7 @@ Designed (hostile review table, "Parallel blocks include the same transaction").
3. A later copy still occupies block space (mass) in the block that includes it, so the including miner bears the cost.
4. Transactions from one account are subject to the EVM nonce rule over the same ordered sequence: a transaction whose nonce is not the account's next nonce at its position is skipped, not failed, and pays nothing. This is Kaspa's "skip conflicting spends" pattern applied to the EVM.
Block number, timestamp, blockhash, coinbase and prevrandao over the ordered sequence are out of scope for 0.1 and Open (ledger P5, O-2.8).
Block number, timestamp, blockhash, coinbase and prevrandao over the ordered sequence are fixed in section 7.1 (ledger P5, closed 3 October 2026).
## 2.7 What the devnet showed and did not show

35
docs/spec/03-finality.md
View file

@ -37,7 +37,7 @@ All in public, on the hashrate charts. 51% never reaches 2/3 while honest miners
## 3.3 Quorum
- **Q1.** Presence window P = 240 checkpoint indices (2 hours of blue score at 1 BPS).
- **Q2.** Participation of key k at index i, "cert reading": the number of indices j in `[i - 240, i - 1]` for which a certificate containing k's vote is in the past of C_i, divided by 240, capped at 1. An index with no certificate in C_i's past credits nobody. A key whose first block is fewer than 240 indices old counts 1. This reading is objective (every node computes it from certificates in C_i's past) and self-healing; the "seen" reading is rejected as not objective and the "frozen" reading as total with extra steps (`sim/results_v2.md`, "Recommended parameters").
- **Q2.** Participation of key k at index i, "block reading" (rule of 3 October 2026, ledger F3): the number of indices j in `[i - 240, i - 1]` for which a valid vote by k at index j appears in the past of C_i, divided by 240, capped at 1. A vote "appears in the past of C_i" when it is carried, as a vote or inside a certificate, by any block in the past of C_i, blue or red. A key whose first block is fewer than 240 indices old counts 1. Votes are block payload: every block MUST carry every valid vote its producer has received for an index in `[i_b - 240, i_b]` (i_b the highest checkpoint index determined in the block's past) that is not already carried by a block in its past, up to the per-block vote bound of O-3.3; votes for one `(index, checkpoint hash)` pair MAY be aggregated inside the block into one BLS signature with a bitmap. A block that omits a vote it has received is not invalid (no node can prove what another received); the rule binds honest producers and the argument of 3.3.2 says why that is enough. This reading is objective, since every node computes it from the same past of C_i, and self-healing, since a missed index rolls out of the window after 240 indices. The "cert reading" of the simulation (only votes inside certificates count) is a subset of it and was the reading the simulation ran with; the node-local "seen" reading is rejected as not objective and the "frozen" reading as total with extra steps (`sim/results_v2.md`, "Recommended parameters").
- **Q3.** Active weight at i is the sum over voters of weight x participation. Total weight at i is the sum of weight over all keys above dust. A certificate for index i locks when the unscaled weight of its signers is at least **2/3 of active weight** AND at least **56.7% of total weight** (the floor 0.85 x 2/3 = 17/30). Both tests use weights and participation computed at C_i, so any node can verify a certificate from C_i's past.
- **Q4.** Certificate grace: an aggregator closes a certificate at the later of quorum time and `t0 + grace`, where grace MUST be at least 3x the worst honest one-way network delay (15 s in the simulation at a 2-s delay; at a 5-s delay the slowest region already lost 1.7 points of participation to a 15-s grace, `sim/results_v2.md` A). The value is Open (O-3.4) and does not affect validity, only which votes a certificate carries.
@ -61,12 +61,43 @@ The mechanism active alone fails by: a side that cannot see the other side's vot
What the floor costs: liveness ends between 40% and 45% of weight silent (total alone: 34%; active alone: above 55%), 50% churn stalls 4.1 days, and at 40% silent or 35% churn the margin is one pool outage thin. The safety bound stays at 1/3 of weight for every event tested; the liveness bound moves from 1/3 (total) to about 42% silent.
The simulation ran with the cert reading of participation. The block reading of Q2 credits a superset of the same votes (every vote in a certificate is in a block, and votes carried outside certificates are added), so a key's participation under the block reading is never lower than under the cert reading. For a key that is silent (C) or gone (D) nothing changes, because it emits no votes. For a key whose votes arrive late (F1 below) the block reading keeps it in the denominator for longer, which raises the weight a lock needs. That direction is safe; its cost in lock latency and in the C and D stall figures is the re-run named in O-3.3, with the per-block vote bound as the parameter.
### 3.3.2 The eclipse case (ledger F2): closed by the floor
Decision of 3 October 2026. The presence window of Q1 is an eclipse vector on its own: a faction that keeps the big pools' votes from the rest of the network for two hours, without stopping their blocks, becomes the whole of active weight and locks alone. The answer is not a longer window or a silent-key rule; it is the second test of Q3, already in the rule. A lock needs at least 56.7% of total weight whatever the presence window says, so an eclipsed or isolated faction can never lock unless it holds a majority of all 30-day weight, and a faction that holds that much is a public 51% event of 3.1, not an eclipse.
The numbers (`sim/results_v2.md`, section F, seed 7, 1,000 keys, one pool holding 20% of total weight always online in its own region):
| Scenario | Denominator | Conflicting locks at 1 / 2 / 4 h | First conflict | Pool participation, minimum | Pool back to 1 after the eclipse ends |
|---|---|---|---|---|---|
| F1: pool receives every block and vote D hours late and votes correctly, late | any | 0 / 0 / 0 | never | 0.500 at 1 h, 0.000 at 2 and 4 h | 120 to 125 min |
| F2: a 34% attacker feeds the pool a private fork, signs both forks; eclipsed side holds 54% of weight, honest side 46% | active alone (cert reading) | 10 / 65 / 174 | 49 min | 0.787 / 0.562 / 0.108 | 115 / 85 / 20 min |
| F2, same | active + floor 0.80 (lock needs 53.3% of total) | 10 / 65 / 174 | 49 min | same as active alone | same |
| F2, same | **active + floor 0.85 (lock needs 56.7% of total, rule Q3)** | **0 / 0 / 0** | **never** | 0.738 / 0.471 / 0.000 | 125 min |
| F2, same | total alone | 0 / 0 / 0 | never | 0.738 / 0.471 / 0.000 | 125 min |
Why 0.85 and not 0.80: the eclipsed side in F2 holds 54% of total weight, which clears a 53.3% floor and fails a 56.7% one. Under the active denominator alone the eclipsed view certifies the attacker's fork 49 minutes in, once its denominator has decayed below 54% / (2/3) = 81%; the 0.85 floor binds before that point at every eclipse length tested, and the honest side saw 0 stalls during and after the heal in every row. A pure delay (F1) never produced a conflicting lock under any denominator because 80% of weight kept signing; its only cost falls on the delayed pool, which leaves the denominator and returns to participation 1 about two hours after its view catches up.
What this does not prove. The model grants the attacker the eclipse for free and lets it mine its fork at its full rate for the pool alone while still signing the honest chain (`sim/results_v2.md`, "cannot tell us"). The attacker in F2 holds 34%, above the 1/3 safety bound of 3.7, which is the point: with the floor, even a faction above the bound cannot turn an eclipse into a conflicting lock. The devnet single-node eclipse of O-3.7 confirms the rule against a real network; it does not reopen the choice of rule.
## 3.4 Sortition
- **S1.** At launch every voter signs every checkpoint. A private VRF, keyed to the vote key and the checkpoint, selects 8 aggregators per checkpoint who publish certificates; anyone MAY aggregate and publish. Aggregator failure costs latency, not safety: the simulation's lock latency (median 2.5 s) assumes one aggregator per region and no failures, so it is a lower bound (`sim/results_v2.md`, "cannot tell us").
- **S2.** If the number of voters above dust exceeds 8,192 at a checkpoint, the genesis rules switch, at that checkpoint and without a release, to Algorand-style binomial sub-user sortition with an expected 4,000 sub-users per checkpoint and both Q3 thresholds applied to expected sampled weight. The exact VRF construction, the binomial sampling procedure and the threshold on sampled weight are Open (O-3.5).
Ledger F3 (participation grinding through the bitmap: an aggregator or block producer that drops a rival's votes from certificates lowers that rival's participation) is Open (O-3.3). Candidate fixes: a certificate MUST include every valid vote the aggregator received above a size bound; or participation also counts votes carried in blocks as transactions; or participation falls only on indices where the key's vote appears in no certificate and no block.
### 3.4.1 Participation grinding (ledger F3): closed by the block reading
Decision of 3 October 2026. Under a cert-only reading, whoever aggregates and whoever produces blocks could shape a rival's participation: drop its votes from the certificates you publish and carry, and after two hours its factor has fallen and your share of active weight has risen. Q2 closes this by computing participation from every vote seen in blocks over the presence window, never only from the votes an aggregator chose to certify. Aggregators choose what goes into a certificate; they choose nothing about participation.
Why an aggregator or a block producer cannot push a key's participation below the honest level:
1. A vote is credited if it appears in any block in the past of C_i, blue or red, as a vote or inside a certificate. Certificates are one carrier among many, so the aggregator's bitmap selects nothing. An aggregator that drops a vote from its certificate changes which certificate locks (Q3 still has to be met by the votes it kept), not whether the vote counts for presence.
2. A single block producer controls one block's payload. To keep k's vote for index j out of the past of C_i, every producer of every block that ends up in the past of C_i, over the up to 240 indices between j and i, has to omit it, and the rule of Q2 makes every honest producer carry it. Under GHOSTDAG the past of C_i includes red blocks and every block merged within the 3,600-s bound, so an honest block that carries the vote is in the past of C_i within an hour of being mined.
3. k is a voter only if it holds weight, which means it mined at least 100 blue blocks in the window. k carries its own votes in its own blocks, so suppressing k's participation means keeping k's own blocks out of the DAG for the whole presence window. That is excluding a miner from the chain for two hours, which is the eclipse of 3.3.2, where the floor already stops a lock, or a majority attack of 3.1, which the rule never claimed to survive.
4. Nobody can raise participation falsely, because a vote is a BLS signature by k. Nobody can be made to vote twice at one index without producing equivocation evidence (3.6).
The honest level is therefore the number of indices at which k actually voted and its vote reached any honest producer within the window. A producer that receives votes and omits them lowers nothing while one honest block carries them; it only spends its own block space on less. The per-block vote bound, the window the carriage rule covers, and the lock latency and C and D stall figures under the block reading are the parameter re-run of O-3.3.
## 3.5 Fork choice

11
docs/spec/05-fees-and-economics.md
View file

@ -13,7 +13,7 @@ Designed. Every transaction pays a base fee in both gas dimensions:
| Execution gas | EVM execution, Ethereum's rule | Ethereum's EIP-1559-style base fee over the ordered sequence |
| Proving-cost gas | Proving cycles the transaction will cost the provers | A second base fee adjusted per block from the unproven backlog, smoothed over the difficulty window (section 2.3) so cards do not flip between hashing and proving every block |
The base fee in both dimensions is **burned in full**. A miner cannot stuff blocks with its own transactions for free; wash gas loses its whole base fee (ledger E3). The proving-cost budget per block is a consensus constant set from measured prover throughput (phase 2 gate: one shard on a 12 GB card in about 20 s, Target, unmeasured, ledger P1), so a transaction that is cheap to run and brutal to prove cannot stall the provers for everyone. How the node folds the proving-cost dimension into the quoted gas price so `eth_estimateGas` keeps working is an execution-layer matter and Open (ledger P5, O-2.8).
The base fee in both dimensions is **burned in full**. A miner cannot stuff blocks with its own transactions for free; wash gas loses its whole base fee (ledger E3). The proving-cost budget per block is a consensus constant set from measured prover throughput (phase 2 gate: one shard on a 12 GB card in about 20 s, Target, unmeasured, ledger P1), so a transaction that is cheap to run and brutal to prove cannot stall the provers for everyone. How the node folds the proving-cost dimension into the quoted gas price so `eth_estimateGas` keeps working is fixed in section 7.1 (ledger P5, closed 3 October 2026).
## 5.2 Priority fee split
@ -34,7 +34,7 @@ Self-dealing: a developer who also mines the including block collects 80% plus 2
## 5.3 Proving pool
Designed. The 20% emission share (section 2.5) and the provers' part of the 80% tip share are paid per block as a fixed amount for that block, divided among the block's shards by consensus proving cost, so a stuffed block earns no more than an honest one. Shards are claimed with a small bond, slashed on a bad or late proof, and a withheld shard reopens with a rising fee until someone proves it (design document, security model table). First-come claiming favours the lowest-latency datacentre (ledger P8, C9); sortition of shards by a VRF keyed to the block, weighted by past proving, with open claiming after a timeout, is the scheduled replacement and is Open (O-5.1). Bond size and timeout are Open (O-5.6). An unproven block delays only its proof; execution and the 30-s lock do not wait for it (ledger P9).
Designed. The 20% emission share (section 2.5) and the provers' part of the 80% tip share are paid per block as a fixed amount for that block, divided among the block's shards by consensus proving cost, so a stuffed block earns no more than an honest one. Shards are not claimed first-come and carry no bond: each shard is assigned by sortition to 8 eligible provers for a 10-s exclusive window, then open to anyone, and the first valid proof included in a block is paid (section 7.2, decided 3 October 2026, ledger P8, C9). The parameters 8 and 10 s are set on the phase 4 devnet (O-5.1). A withheld shard costs nothing to bond against because nothing waits on an assigned prover: an unproven block delays only its proof; execution and the 30-s lock do not wait for it (ledger P9). The bond, slashed on a bad or late proof, remains in the external job market (5.4), where a customer does wait; its size and timeout are Open (O-5.6).
## 5.4 External job market
@ -45,7 +45,7 @@ Designed. At launch external proving jobs are paid on the customer's chain, in t
| 90% | The provers who delivered the job |
| 10% | Burn |
The burn applies only to IGN-settled jobs (ledger P10). The timing of the switch and the bridge's trust model are Open (O-5.2).
The burn applies only to IGN-settled jobs (ledger P10). The bridge's trust model is decided (section 7.3, 3 October 2026): no bridge is official, no bridged stablecoin exists at genesis, and the proof bridge arrives with the consensus proof in phase two. IGN settlement switches on when that bridge exists; how the switch is activated is Open (O-5.2).
## 5.5 No development fund
@ -55,7 +55,7 @@ The 60% signalling mechanism stays as a general governance tool (5.8): a paramet
## 5.6 No stake, no treasury
- No consensus rule reads a balance. No bond, deposit or stake affects block validity, vote weight, fork choice or finality. The prover shard bond of 5.3 is an execution-layer escrow, not a consensus weight.
- No consensus rule reads a balance. No bond, deposit or stake affects block validity, vote weight, fork choice or finality. The external job bond of 5.4 is an execution-layer escrow, not a consensus weight; shards carry no bond at all (section 7.2).
- No unit of emission goes anywhere but the block producer (80%) and the proving pool (20%).
- The team holds no consensus key, no purse and no protocol fee (hostile review table, "A team that controls a treasury").
@ -80,7 +80,8 @@ Designed, Open (O-5.3). Each block carries a bitfield; bit b set means "this blo
| Parameter signalling window | 1,209,600 DAA s | Designed (design document: "over two weeks") |
| Upgrade signalling threshold | 90% of blue blocks | Designed |
| Upgrade window, activation delay | not set | Open (O-5.3) |
| Shard bond, claim timeout | not set | Open (O-5.6) |
| Shard assignment | sortition, 8 provers, 10-s window, no bond (section 7.2) | Designed (3 October 2026) |
| External job bond, claim timeout | not set | Open (O-5.6) |
| Proving-cost budget per block | from the phase 2 measurement | Target |
| Emission to any treasury | 0 | Designed |
| Protocol fee to any team, foundation or fund | 0 | Designed (3 October 2026) |

33
docs/spec/06-open-items.md
View file

@ -1,6 +1,6 @@
# Igneum protocol specification, section 6: open items
Spec version 0.1, 3 October 2026. Status of this section: Open by definition. Every parameter or rule in sections 1 to 5 that is unmeasured, unreviewed or marked open is listed here once, with the experiment or decision that closes it and the gate it belongs to. Sources: the Open entries of `docs/fud-ledger.md`, the "unproven" and "not demonstrated" lists of `proto-metal/MEMHARD.md` and `proto-metal/TESTS.md`, the open items of `proto-vdf/README.md`, the "cannot tell us" sections of `sim/results.md` and `sim/results_v2.md`, and the notes of `docs/fork-map.md`.
Spec version 0.1, 3 October 2026. Status of this section: Open by definition. Every parameter or rule in sections 1 to 5, 7 and 8 that is unmeasured, unreviewed or marked open is listed here once, with the experiment or decision that closes it and the gate it belongs to. Sources: the Open entries of `docs/fud-ledger.md`, the "unproven" and "not demonstrated" lists of `proto-metal/MEMHARD.md` and `proto-metal/TESTS.md`, the open items of `proto-vdf/README.md`, the "cannot tell us" sections of `sim/results.md` and `sim/results_v2.md`, and the notes of `docs/fork-map.md`.
Gates: gate 1 = the lottery hash frozen (section 1 at version 1.0; cryptographer). Gate 2 = the fork runs a devnet at Igneum parameters (consensus engineer). Gate 3 = finality and seeds reviewed externally (section 3 at 1.0; cryptographer). Gate 4 = 1,000 independent miners for 30 days (miner-community lead). Phase 2 = the proving benchmark, out of scope for 0.1 but named where a parameter here waits on it. Items that are not a gate's business are marked "decision" with an owner.
@ -42,7 +42,6 @@ An item closes when its measurement is in `docs/bench-log.md` or its decision is
| O-2.5 | Header validation gains a chain-state dependency (the epoch seed) and must stay deterministic from headers plus certificates during IBD and pruning-proof validation (fork map a4, risk High) | Implement `seed_source` validation; sync a node from genesis and from a pruning point on the devnet | 2 |
| O-2.6 | Base unit: 10^18 (EVM) or 10^8 (fork map b2) | Decision, owner execution engineer with consensus engineer | 2 |
| O-2.7 | Apportioning the DAA-score increment among several blue blocks in one mergeset at higher block rates (section 2.5) | Define before the first block-rate step; at 1 BPS the mergeset is usually one block | 2, before the 4 BPS step |
| O-2.8 | EVM semantics on a DAG: block number, timestamp, blockhash, coinbase, prevrandao over the ordered sequence; folding the proving-cost dimension into the quoted gas price (ledger P5) | Execution-layer specification; prevrandao from the epoch VDF is the candidate | decision, execution engineer |
| O-2.9 | `docs/fork-divergence.md` does not exist | Write it as the fork is made | 2 |
| O-2.10 | Block-rate steps to 4 and 10 BPS each re-derive k, parents and mergeset limit and are hard forks (hostile review table) | Each step has its own test campaign, as Kaspa's Crescendo | later, consensus engineer |
@ -52,11 +51,11 @@ An item closes when its measurement is in `docs/bench-log.md` or its decision is
|---|---|---|---|
| O-3.1 | The first month: no weight exists; an attacker producing 75% of blocks from day 2 crosses 2/3 on day 9 (ledger F1). C5 says first hour; this specification proposes first 30 days | Launch-month simulation (not yet in `sim/`); decision; litepaper states the rule either way | 3 |
| O-3.2 | Checkpoint depth d = 60 is a placeholder (ledger F7) | Devnet with regional latency records the reorg-depth distribution at each block rate; set d so a vote split at one index is rare | 3 |
| O-3.3 | Participation grinding through the certificate bitmap (ledger F3): aggregators and block producers can shape rivals' participation | Choose among the candidate fixes of section 3.4; simulate with a hostile aggregator | 3 |
| O-3.3 | Parameters of the block reading of participation (rule closed 3 October 2026, section 3.3 Q2 and 3.4.1; ledger F3): the per-block vote bound and the carriage window, and the simulation ran with the narrower cert reading | Add vote carriage in blocks and a hostile aggregator to `finality_v2.py`; re-run A, C, D and F1 under the block reading; set the per-block vote bound and confirm the carriage window of 240 indices | 3 |
| O-3.4 | Certificate grace value; must be at least 3x the worst honest one-way delay (section 3.3, Q4) | Measure one-way delays on the devnet across regions; set grace | 3 |
| O-3.5 | VRF construction for aggregator selection and the binomial sub-user sortition above 8,192 voters (S1, S2) | Specify (candidate: BLS-based VRF on the vote key, Algorand's binomial sampling); simulate the threshold on sampled weight | 3 |
| O-3.6 | What a node does with two valid certificates at one index after a partition heals; post-heal fork choice is unmodelled (`sim/results_v2.md`, "cannot tell us") | Adopt or replace the proposal in section 3.5; devnet partition-and-heal test | 3 |
| O-3.7 | The presence window is an eclipse vector (ledger F2); the floor closes it in the model for 1, 2 and 4 h at a 34% attacker (F2) but the model grants the attacker the eclipse for free | Devnet with a single-node eclipse recording whether conflicting locks appear; choice between the 2-hour window and a 7-day silent-key rule | 3 |
| O-3.7 | The eclipse case is closed by the quorum floor (section 3.3.2, 3 October 2026; ledger F2): 0 conflicting locks at 1, 2 and 4 h against a 34% attacker in the model, but the model grants the attacker the eclipse for free | Devnet with a single-node eclipse recording whether conflicting locks appear, as confirmation of the rule; no rule choice remains | 3 |
| O-3.8 | The simulation has no DAG: conflict counts are index collisions; red blocks, merge under the 3,600-s bound and the finality overlay's effect on GHOSTDAG's guarantees are unmodelled (ledger C4, F8) | Devnet runs with the finality module on and off; a churn and adversary simulation driven by real pool-hashrate traces from mid-cap GPU coins (design document, "Three experiments") | 3 |
| O-3.9 | Model assumptions that move the numbers: perfect or instant DAA retarget (real lag of the order of an hour, approximate), uptime 97% / 99.5% is a guess, silent sets random by key not by pool or region, keys are free, VRF noise absent (`sim/results.md` and `results_v2.md`) | Re-run `finality_v2.py` with a DAA lag model, a top-pool silent set and a regional silent set; price keys through the P2P layer | 3 |
| O-3.10 | Equivocation evidence is detected only at the heal and is forward-looking; certificates signed by equivocators are not revoked in the model | Decide revocation (section 3.5 proposal) and simulate | 3 |
@ -82,24 +81,34 @@ An item closes when its measurement is in `docs/bench-log.md` or its decision is
| Id | Item | What closes it | Gate |
|---|---|---|---|
| O-5.1 | First-come shard claiming lets the lowest-latency datacentre take every shard (ledger P8, C9) | Specify sortition of shards (VRF keyed to the block, weighted by past proving, open claiming after a timeout); measure on the phase 4 devnet | decision, cryptographer; measure in 4 |
| O-5.2 | External job settlement: on the customer's chain at launch, in IGN with a 10% burn once the proof bridge exists; the bridge's trust model at launch (committee-attested or proof-verified) is undecided (ledger P10, E7) | Decision before phase 4; the litepaper stops presenting the proof bridge as a genesis feature until then | decision, execution engineer |
| O-5.1 | Shard sortition parameters: 8 assigned provers and the 10-s exclusive window (rule specified 3 October 2026, section 7.2; ledger P8, C9) | Phase 4 devnet with 20 nodes and 3 prover speeds: shard latency, share of shards won by the fastest prover (require under 25%), and the gain from a producer grinding segment content to move the draw; set 8 and 10 s | 4 |
| O-5.2 | External job settlement switches from the customer's chain to IGN with a 10% burn when the proof bridge exists (phase two, section 7.3; the trust model was decided 3 October 2026, ledger E7): how the switch is activated | Decision with the consensus proof: activation by the 90% upgrade signal or by a genesis rule keyed to the first verified bridge proof | decision, execution engineer |
| O-5.3 | Signalling encoding: version bits or a separate field, window length and activation delay for upgrades, proposal registration format (section 5.7, 5.8) | Specify with the consensus engineer; BIP 9 is the model | 2 |
| O-5.4 | Every genesis contract's upgrade and key policy (ledger G4); the development fund contract is gone (fund removed 3 October 2026) | Publish before launch | 4 |
| O-5.5 | The proving-cost gas dimension: the metering table per opcode and precompile, and the per-block budget from the phase 2 measurement | Phase 2 benchmark; execution-layer specification | phase 2 |
| O-5.6 | Shard bond size and claim timeout (ledger P9) | Set on the phase 4 devnet | 4 |
| O-5.6 | External job bond size and claim timeout (ledger P9); shards carry no bond since the sortition rule of section 7.2 | Set on the phase 4 devnet | 4 |
| O-5.7 | The provers' proportion of the 80% tip share (section 5.2) | Defined by the chunked proving protocol | phase 2 |
| O-5.8 | Developer registration format at deployment and the re-registration transaction (section 5.2) | Execution-layer specification | decision, execution engineer |
## 6.6 Count
## 6.6 Sections 7 and 8, execution and client security
Section 7 carries no open item of its own: its measurements are O-5.1 (shard sortition parameters) and O-5.2 (the IGN settlement switch), listed above. Section 8 has one.
| Id | Item | What closes it | Gate |
|---|---|---|---|
| O-8.1 | The release key policy (section 8.2): who the steward is, the hardware, how a signature is produced, rotation and revocation; and the per-platform reproducible-build toolchain of section 8.1 | Publish the policy and the toolchain before the public testnet; a third party reproduces one release from it | decision, the project lead (key custody); before public testnet |
## 6.7 Count
| Section | Open items |
|---|---|
| 1 | 20 |
| 2 | 10 |
| 3 | 13 |
| 2 | 9 (O-2.8 closed 3 October 2026 by section 7.1) |
| 3 | 13 (O-3.3 and O-3.7 narrowed to parameters and confirmation on 3 October 2026) |
| 4 | 9 |
| 5 | 8 |
| 5 | 8 (O-5.1, O-5.2 and O-5.6 narrowed on 3 October 2026) |
| 7 | 0 |
| 8 | 1 |
| Total | 60 |
By gate (an item shared between two gates is counted at the earlier one): 16 belong to gate 1, 11 to gate 2, 21 to gate 3, 4 to gate 4, 3 to phase 2, 4 are decisions with a named owner outside a gate, and 1 (O-1.20) is a note with no consensus consequence.
By gate (an item shared between two gates is counted at the earlier one): 16 belong to gate 1, 11 to gate 2, 21 to gate 3, 4 to gate 4, 3 to phase 2, 3 are decisions with a named owner outside a gate (O-5.2, O-5.8, O-8.1), 1 (O-2.10) waits on a later block-rate step, and 1 (O-1.20) is a note with no consensus consequence.

68
docs/spec/07-execution.md Normal file
View file

@ -0,0 +1,68 @@
# Igneum protocol specification, section 7: execution
Spec version 0.1, 3 October 2026. Status of this section: Designed. Nothing here is implemented or measured. This section is the normative extract of `docs/design/execution-layer.md` (design version 0.1), which holds the reasons, the rejected alternatives and the precedents for every rule below. Where the two disagree, this section is wrong and the design document's decision table is right until the next MAJOR step (section 0.4). The rest of the execution layer (the transaction model, the two gas dimensions and the pgas table, proof records, the proving interface, the native proving precompile, the RPC surface) stays in the design document for 0.1.
Terms. A chain block is a block on the selected chain. The segment of chain block C is C's mergeset in GHOSTDAG order, with C last; the executor runs segments in selected-chain order (design document, section 1.2). A segment is executed natively by every node, proven by miners in shards, and locked by the finality rule of section 3 independently of its proof.
## 7.1 EVM semantics
Decided 3 October 2026 (ledger P5, closed by this section). Igneum runs Ethereum bytecode. Contracts see the environment of the chain block C whose segment is executing. The table is normative; a conforming executor MUST return these values. Ported contracts get this table as the documented differences; "unchanged" is not claimed.
| Opcode or field | Igneum value | Ethereum value | Note for ported contracts |
|---|---|---|---|
| `block.number` (NUMBER) | The selected-chain height of C: genesis 0, each chain block +1, contiguous | Block height | About one per second at launch but not fixed; use timestamps for time. Blue score and DAA score are readable from the system contract `IgneumInfo` |
| `block.timestamp` (TIMESTAMP) | `ts(C) = max(ts(parent chain block), C.timestamp_ms div 1000)` | Header timestamp, strictly increasing | Non-decreasing by rule; equal values happen at one block a second. The header timestamp alone may step backwards within Kaspa's tolerance (above the past median of a 27-sample window, below now plus 132 s), so the executor MUST apply the max rule and MUST NOT use the raw header value |
| `blockhash(n)` (BLOCKHASH) | The hash of chain block n for `number - 256 <= n < number`, else 0 | Same | Hashes of merged non-chain blocks are not reachable from the EVM; `IgneumInfo` exposes the mergeset of a chain block |
| `block.prevrandao` (PREVRANDAO, and DIFFICULTY) | `keccak256(epoch_seed ‖ number)`, where `epoch_seed` is the 10-minute class-group VDF output for the epoch that contains C (section 4) | RANDAO mix | Unbiasable by the producer. Predictable for the whole epoch (about 1 h) by anyone who has evaluated the VDF, so it is fine for a shuffle revealed later and wrong for a per-block lottery; adversarial randomness goes through the proving precompile with a committed input |
| `block.coinbase` (COINBASE) | The `miner` address of the block that first included the executing copy of the transaction (design document, section 1.3) | Fee recipient | Also the address that receives the producer's part of the 80% tip share, so the correspondence Ethereum contracts assume holds. For a transaction in a red block it is the red block's miner, who is paid that share |
| `block.gaslimit` (GASLIMIT) | The per-block execution gas limit `B_e`, a consensus constant | Header gas limit | A segment can hold up to the mergeset limit of blocks (180 at 1 BPS), so a segment's total can exceed `gaslimit` |
| `block.basefee` (BASEFEE) | The execution base fee `f_e` at this segment | Same | The proving base fee `f_p` is readable from `IgneumInfo` |
| `block.chainid` (CHAINID) | 4461 mainnet, 4462 public testnet, 4463 devnet | 1 | Registered on ethereum-lists/chains before the public testnet |
| BLOBHASH, BLOBBASEFEE | Zero and 1 respectively; no blob transactions | EIP-4844 | As on L2s without blobs |
| Opcode set | Cancun (PUSH0, TSTORE, TLOAD, MCOPY, SELFDESTRUCT per EIP-6780) | Cancun or later | EIP-7702 and the Prague BLS precompiles are deferred to phase two |
| Precompiles | 0x01 to 0x09 (ecrecover, sha256, ripemd160, identity, modexp, ecadd, ecmul, ecpairing, blake2f); 0x0a absent and returns failure | Cancun has 0x0a | Heavy precompiles cost more here because proving gas is charged |
The timestamp rule in words: the EVM clock never runs backwards, and it never runs ahead of the header clock. Under a burst of back-dated headers inside the 132-s tolerance the EVM clock holds still rather than stepping back; its drift from wall-clock under that attack is the devnet measurement R9 of the design document.
Quoted gas price. Every transaction is metered in execution gas and in proving gas and charged `gas_used x (f_e + tip) + pgas_used x f_p` wei against the signed budget `gas_limit x max_fee_per_gas` (design document, section 4.1). Wallets sign one gas limit and one price, so the node folds the second dimension into the quote: `eth_gasPrice` returns `f_e + f_p x (pgas_est / gas_est) + tip` and `eth_estimateGas` returns a gas limit that covers both charges at that quote. A transaction heavy in pairing or modexp sees a higher quoted price than on Ethereum. Rationale and the rejected second-limit transaction type: design document, section 4.1.
Rationale for every row, the precedents (Conflux eSpace, Kasplex, Igra) and the rejected blue-score alternative for `block.number`: design document, section 3.
## 7.2 Shard assignment
Decided 3 October 2026 (ledger P8 and C9, closed by this section). Every segment is cut into shards by proving gas at transaction boundaries, deterministically from the native trace, so every node computes the same shard list and the same shard ids `(segment hash, shard index)` (design document, section 5.1). Shards are not claimed first-come. They are assigned by sortition:
1. **Eligible provers.** The vote keys above dust under section 3 (at least 100 blue blocks in the trailing 30-day window at the chain block that heads the segment). The finality-rule population is the proving population; there is no separate registration.
2. **Sortition.** For each shard, every eligible key k is ranked by `H("igneum-shard/" ‖ epoch_seed ‖ shard_id ‖ vote_key_hash(k))`, H the chain's hash of section 0.6, as an unsigned integer; the 8 lowest ranks are assigned to the shard. `epoch_seed` is the VDF output of section 4 for the epoch containing the chain block, so the producer cannot bias it, and `shard_id` commits to the segment, so the assignment is keyed to the block and known to every node the moment the segment is executed. The function is public and deterministic: it needs no private key and no proof of evaluation. Whether to replace the hash ranking with the private VRF of section 3.4 (so assignees are hidden until they prove) is settled together with O-3.5; nothing else in this section depends on the choice.
3. **Exclusive window.** From the moment the segment is executed, the 8 assignees hold the shard for 10 s of DAA time. A valid proof of the shard by any of the 8 that is included in a block during the window earns the shard's part of the proving pool (section 5.3); a proof by anyone else is valid but unpaid.
4. **Open claiming.** After the window any prover MAY prove the shard, and the first valid proof included in a block earns the shard's part of the pool. There is no claim and no shard bond: nothing waits on an assigned prover, so there is nothing to bond against (ledger P9). The bond remains in the external job market, where a customer does wait (section 5.4).
5. **Inclusion.** Shard proofs gossip like votes and any block producer MAY include them (design document, section 5.4). A block is invalid if a proof record it carries fails verification or names a state the node's own execution disagrees with (design document, section 5.5).
What the rule gives. A datacentre cannot sweep every shard by latency, because for 10 s only 8 drawn provers are paid, and the draw is proportional to the number of eligible keys a prover holds, which is bounded by its 30-day mining. Income from the pool is bounded by the shards a prover is assigned plus the shards nobody assigned proves in time, not by how many it can grab. A segment producer could grind transaction content to move the assignment; it gains only if it is also one of the many eligible provers, and the draw of 8 out of the whole population makes the gain small. Its size is part of the measurement below.
Parameters 8 and 10 s are Designed. They are set on the phase 4 devnet from the shard-time distribution across three prover speeds, with the acceptance test that the fastest prover wins under 25% of shards (design document, R7; O-5.1).
## 7.3 Bridges
Decided 3 October 2026 (ledger E7, closed by this section).
1. There are no bridged stablecoins at genesis. No USDC, USDT or other bridged asset is a launch feature, and the project does not request, label or seed a canonical bridged version of any asset before a proof bridge exists.
2. No bridge is called official. Igneum ships no bridge contract at genesis and endorses none. Anyone MAY deploy a bridge on Igneum, at their own risk and their users', and it is labelled by whoever runs it, never by the protocol or the project.
3. The proof bridge arrives with the consensus proof. A bridge contract on another chain that verifies Igneum state without a committee needs to verify a lock certificate, which means knowing the voter set and weights; that is the consensus proof of the design document, section 7, scoped as phase two. When it exists, the segment proof carries a self-verifying certificate and a bridge on Ethereum needs no relayer and no multisig. Until it exists, a light client is given a recent certificate and the key set out of band (ledger P4).
4. Settlement of the external job market in IGN, with its 10% burn, starts when the proof bridge lets Igneum see the payment (section 5.4). At launch customers pay on their own chain.
Nothing in consensus changes for any of this: the segment claim already commits to the chain block hash, which is what the consensus proof folds in.
## 7.4 Parameters in this section
| Parameter | Value | Label |
|---|---|---|
| Chain id | 4461 / 4462 / 4463 (mainnet / testnet / devnet) | Designed |
| BLOCKHASH reach | 256 chain blocks | Designed (Ethereum's) |
| PREVRANDAO source | 10-minute epoch VDF output, keccak256 with the chain height | Designed |
| Opcode set, precompiles | Cancun; 0x01 to 0x09 | Designed |
| Provers assigned per shard | 8 | Designed, set at the phase 4 devnet (O-5.1) |
| Exclusive proving window | 10 DAA s | Designed, set at the phase 4 devnet (O-5.1) |
| Shard claim bond | none | Designed |
| Bridged stablecoins at genesis | none | Decided (3 October 2026) |
| Official bridge | none | Decided (3 October 2026) |

54
docs/spec/08-client-security.md Normal file
View file

@ -0,0 +1,54 @@
# Igneum protocol specification, section 8: client security
Spec version 0.1, 3 October 2026. Status of this section: Decided (3 October 2026, ledger G7 and X6). Nothing here is implemented. This section binds the official client (the one-click Igneum app on Windows, macOS and Linux, and the headless miner it wraps) and the project's release process. It binds no other client: any client is welcome, and a client that ignores this section is not an invalid node, only one the project did not ship.
The two findings it answers. An app that auto-updates on ten thousand machines is an admin key over the miners, the wallets the app made and the vote keys (G7). An installer that creates a wallet, holds keys and mines, promoted to people who have never run a miner, is a honeypot for fake copies and a target for every antivirus (X6). Both are true. The rules below name the key, bound it, and make the real app distinguishable from a fake by anyone who looks.
## 8.1 Reproducible builds
1. Every release of the official client MUST be reproducible: a build from the tagged source on the documented toolchain MUST produce byte-identical binaries on every supported platform.
2. The repository MUST carry, at the release tag, the hash of every released binary, the toolchain versions, and the command that reproduces the build.
3. A release whose hashes a third party cannot reproduce is withdrawn and the cause published.
## 8.2 The release key
1. Every release MUST be signed by the release key. The release key's public half is published in the genesis block and is therefore in every node's copy of the chain; it is also in the repository and on the domain.
2. The private half is held in hardware by the steward named in the published key policy. It never exists on a networked machine. The policy (who holds it, how a signature is produced, how the key is rotated or revoked) is published before the public testnet (O-8.1).
3. The client MUST refuse any update whose signature does not verify under the release key. A refused update is reported to the user, with the hash it saw, and the running version continues.
4. There are no silent updates. The client MAY check for a release and MUST show the version, its hash and the reproduction instructions; installation proceeds only when the user accepts it. The client never applies an update while mining without the user's acceptance for that version.
5. Rotation of the release key is itself a signed release under the old key, published with a stated reason and a stated date, and is the only path to a new key. A key that is lost is a key that is revoked by its own last signed release, and the client then accepts no update at all until the user installs a new client by hand from the repository.
## 8.3 The client cannot change consensus
1. Consensus rules change only through the upgrade path of section 5.7: new code activates when 90% of blue blocks in the signalling window carry the signal. A client release carries code; it carries no activation. The chain, not the app, decides when a rule takes effect, and 90% of miners have to say so in their blocks.
2. The client MUST NOT set a signalling bit without a user choice shown in the interface, and the default MUST be the choice the user last made, never the release's preference.
3. A release that changed a consensus rule without an activation signal would fork its users off the chain, which is the only thing a hostile release key can do to consensus, and it is visible to everyone within one block.
## 8.4 Distribution
1. Builds on every platform are notarised or signed with the platform's own mechanism (Apple notarisation, Windows Authenticode, a signed Linux package or AppImage) in addition to the release key.
2. Downloads are offered only from the project's domain and from the repository's release page. The hash of the file is shown beside every download button. No app store, mirror, torrent or third-party site is an official source, and the domain publishes the list of the only official sources.
3. Shipping a miner means antivirus products flag it. The app documents this and never asks the user to disable protection; it tells the user how to verify the hash instead.
## 8.5 Keys and the seed
1. The app creates the user's wallet locally. Before mining starts, the seed phrase MUST be shown and the user MUST confirm it (by re-entering the words or an equivalent check). Mining does not start until the confirmation succeeds.
2. The app MUST offer a hardware wallet as the destination for earnings, so a user who never wants a seed on the mining machine does not need one.
3. The seed is never transmitted, never backed up by the project, and never asked for by any update, support route or message. The permanent line, verbatim, appears wherever the app appears: on the download page, in the installer, on the seed screen and in every support channel:
**Nobody from Igneum will ever ask for your seed.**
4. The vote key of section 3 is a separate key, created by the app and held by the app, and its loss costs the user weight, not coins (W5 of section 3 moves weight to a successor key). The app shows it as a mining key and never as a wallet.
## 8.6 Parameters in this section
| Parameter | Value | Label |
|---|---|---|
| Release key publication | genesis block, repository, domain | Decided |
| Release key custody | hardware, held by the named steward, policy published before public testnet | Decided; policy Open (O-8.1) |
| Silent updates | none | Decided |
| Consensus activation through the client | impossible; 90% of blue blocks signalling (section 5.7) | Decided |
| Official download sources | the project's domain and the repository release page, hash shown beside the button | Decided |
| Seed shown and confirmed before mining | required | Decided |
| Hardware wallet option | required | Decided |
| The permanent line | "Nobody from Igneum will ever ask for your seed." | Decided, verbatim |

6
docs/spec/README.md
View file

@ -7,10 +7,12 @@
| 0 | `00-overview.md` | Designed | Scope, normative language, what is implemented and what is designed, versioning, how to submit a break |
| 1 | `01-lottery-hash.md` | Measured (construction, vectors on three GPU vendors and two CPU references); Designed (header binding, day key, growth, era schedule); Open where marked | Seed words, generator, memory-hard cache and items, 32-lane unit and the wave64 rule, CPU verifier, epoch, day and era schedules, test vectors, determinism, conformance, the prototype-value list |
| 2 | `02-consensus.md` | Designed | The ordering layer as a delta on rusty-kaspa: 1 BPS and the steps, k, merge depth, DAA, header fields, emission, duplicate inclusion |
| 3 | `03-finality.md` | Designed (simulated without a DAG, not implemented, not reviewed) | Weight W1 to W5, checkpoints C1 to C5, quorum Q1 to Q4 with the 56.7% floor and the simulation that justifies it, sortition, fork choice, equivocation, residual risks, the first month, exchange guidance |
| 3 | `03-finality.md` | Designed (simulated without a DAG, not implemented, not reviewed) | Weight W1 to W5, checkpoints C1 to C5, quorum Q1 to Q4 with the 56.7% floor and the simulation that justifies it, the eclipse case closed by the floor (3.3.2), participation from votes in blocks (Q2, 3.4.1), sortition, fork choice, equivocation, residual risks, the first month, exchange guidance |
| 4 | `04-seeds-and-vdf.md` | Measured (primitive, one machine); Designed (pipeline); Open (fallback) | Class-group Wesolowski VDF, T from a genesis reference rate, 20-minute and 2-hour leads, proof format, who evaluates, fallback options |
| 5 | `05-fees-and-economics.md` | Designed | Base fee burned, priority fee 80/20 with per-frame attribution and the factory rule, proving pool, job market 90/10, no development fund, parameter signalling at 60%, upgrades at 90%, no stake, no treasury |
| 6 | `06-open-items.md` | Open | 60 items, each with the experiment or decision that closes it and its gate |
| 6 | `06-open-items.md` | Open | 60 items, each with the experiment or decision that closes it and its gate; O-2.8 closed and O-3.3, O-3.7, O-5.1, O-5.2 and O-5.6 narrowed on 3 October 2026 |
| 7 | `07-execution.md` | Designed (normative extract of `docs/design/execution-layer.md`; nothing implemented or measured) | EVM semantics on the DAG (number, timestamp and its monotonicity rule, blockhash, PREVRANDAO from the epoch VDF, coinbase, gas limit, chain id, the quoted gas price), shard assignment by sortition (8 provers, 10-s window, then open, no bond), bridges (none official, no bridged stablecoins at genesis, proof bridge with the consensus proof in phase two) |
| 8 | `08-client-security.md` | Decided (3 October 2026; nothing implemented) | Reproducible builds with hashes in the repository, the release key published in genesis and held in hardware, the client refuses unsigned updates and never updates silently, the client cannot change consensus (90% signalling), notarised builds, official download sources with the hash beside the button, seed shown and confirmed before mining, hardware wallet option, the permanent line "Nobody from Igneum will ever ask for your seed." |
Prototype values (carried by the implementation today, part of the test vectors, confirmed or replaced at gate 1): seed derivation; 64 instructions x 8 iterations; 8 registers; the op weights including the 25% load weight; the output fold rotations; the 256 MiB cache, 64 lines per segment and ChaCha12; 8 item rounds and the mixer shape; the 1 GiB pack dataset against the 2 GiB genesis size; the 3,600 DAA s epoch; the era length, draw bounds and reserve list; the header binding of the init words. The full table with what fixes each is section 1.16.

2
site/index.html
View file

@ -350,7 +350,7 @@ footer .wrap{padding-block:48px 32px}
<a href="#journey" class="btn dark"><svg viewBox="0 0 24 24" width="18" height="18" fill="currentColor" aria-hidden="true"><path d="M16.4 12.6c0-2.3 1.9-3.4 2-3.5-1.1-1.6-2.8-1.8-3.4-1.8-1.4-.1-2.8.8-3.5.8-.7 0-1.8-.8-3-.8-1.5 0-3 .9-3.8 2.3-1.6 2.8-.4 7 1.2 9.3.8 1.1 1.7 2.4 2.9 2.3 1.2 0 1.6-.7 3-.7s1.8.7 3 .7c1.3 0 2-1.1 2.8-2.3.9-1.3 1.2-2.6 1.3-2.6-.1 0-2.5-.9-2.5-3.7zM14.1 5.8c.6-.8 1.1-1.9.9-3-.9 0-2 .6-2.7 1.4-.6.7-1.1 1.8-1 2.9 1.1.1 2.1-.5 2.8-1.3z"/></svg>macOS</a>
<a href="#journey" class="btn dark"><svg viewBox="0 0 24 24" width="18" height="18" fill="currentColor" aria-hidden="true"><path d="M12 2c-2.4 0-4 1.9-4 4.6 0 1.2.2 2 0 2.8-.6 1.4-2.1 2.9-2.6 4.9-.3 1.1-.1 2 .3 2.6-.6.4-1.3 1-1.1 1.7.3 1 2.1 1.2 3.2 1.8.7.4 1.5.6 2.1.1.6.2 1.3.3 2.1.3s1.5-.1 2.1-.3c.6.5 1.4.3 2.1-.1 1.1-.6 2.9-.8 3.2-1.8.2-.7-.5-1.3-1.1-1.7.4-.6.6-1.5.3-2.6-.5-2-2-3.5-2.6-4.9-.2-.8 0-1.6 0-2.8C16 3.9 14.4 2 12 2zm-1.4 4.2c.5 0 .8.5.8 1.2s-.3 1.2-.8 1.2-.8-.5-.8-1.2.3-1.2.8-1.2zm2.8 0c.5 0 .8.5.8 1.2s-.3 1.2-.8 1.2-.8-.5-.8-1.2.3-1.2.8-1.2zM12 9.3c.9 0 1.9.5 1.9 1s-1 1.2-1.9 1.2-1.9-.7-1.9-1.2 1-1 1.9-1zm0 3.4c2.2 0 3.6 2.6 3.6 4.4 0 1.5-1.6 2.3-3.6 2.3s-3.6-.8-3.6-2.3c0-1.8 1.4-4.4 3.6-4.4z"/></svg>Linux</a>
<a href="#journey" class="btn" style="color:#0C0C0E;border-color:#0C0C0E"><svg viewBox="0 0 24 24" width="18" height="18" fill="none" stroke="currentColor" stroke-width="2" stroke-linejoin="round" aria-hidden="true"><path d="M12 2.5l8.2 4.75v9.5L12 21.5l-8.2-4.75v-9.5z"/><path d="M12 7.5l4.3 2.5v5L12 17.5l-4.3-2.5v-5z"/></svg>HiveOS</a>
<p style="font-size:14px;color:#55534F">One click: install, press start, the card mines and proves to a wallet the app makes for you. Available at public testnet. Open source, 1% dev fee like every miner you already run.</p>
<p style="font-size:14px;color:#55534F">One click: install, press start, the card mines and proves to a wallet the app makes for you. Available at public testnet. Open source, 1% dev fee like every miner you already run. Download only from this domain or the repository, check the hash beside the button, and write down the seed the app shows you. Nobody from Igneum will ever ask for your seed.</p>
</div>
</div>
</section>

14
site/litepaper.html
View file

@ -314,17 +314,17 @@ body.all .pager{display:none}
<p>Three things run on Igneum that run nowhere else.</p>
<ol>
<li><strong>Proving as a native primitive.</strong> A contract can request a proof of any computation and pay for it in gas, and the miners produce it. A game proves a fair shuffle. A lending market proves its solvency. A rollup elsewhere posts a job and gets its proof back. No other EVM chain has a prover network in its base layer.</li>
<li><strong>Trustless light clients.</strong> Because every block is proven, a phone or a browser verifies Igneum's state by checking one proof and the latest locked checkpoint. Bridges built on that need no multisig, the piece that has failed in the biggest bridge hacks.</li>
<li><strong>Light clients.</strong> Because every block is proven, a phone or a browser verifies Igneum's state from one proof and a locked checkpoint it is given. Making the checkpoint itself self-verifying, which is what removes the multisig from bridges, needs a consensus proof and is phase two.</li>
<li><strong>Rollups that settle here.</strong> A rollup posting to Igneum gets its proofs from the same miners that secure it, in the same flow. Settlement and proving in one place costs less than paying a proving network and a settlement layer separately.</li>
</ol>
<p>The first apps, a DEX, a lending market and an Ethereum bridge, ship at genesis so there is somewhere to use the coin from day one.</p>
<p>The first apps, a DEX and a lending market, ship at genesis so there is somewhere to use the coin from day one. No bridge is official: anyone may run one at their own risk, and the proof bridge arrives with the consensus proof in phase two.</p>
<h3>What a builder gets for being early</h3>
<ul>
<li><strong>Apps earn the gas they generate.</strong> 20% of every transaction's priority fee goes to the contracts whose code ran, by gas consumed inside each, paid every block to the developer address registered at deployment. Canto and Blast proved builders come for this. On Igneum it comes out of fees, never out of miner emission.</li>
<li><strong>Stablecoins at genesis.</strong> USDC and USDT bridged through the proof bridge, canonical versions on Igneum, the way Arbitrum and Base launched. Native USDC is requested from Circle during public testnet. Igneum issues no stablecoin of its own.</li>
<li><strong>Stablecoins.</strong> None are bridged at genesis. No bridge is official, anyone may run one at their own risk, and the proof bridge that needs no multisig arrives with the consensus proof in phase two. Native USDC is requested from Circle during public testnet. Igneum issues no stablecoin of its own.</li>
<li><strong>Liquidity from the people who are there.</strong> The DEX is seeded by the founders' own mined coins and by miners, and every miner is a funded wallet from day one.</li>
<li><strong>Launch grants.</strong> Paid from the founders' own mined coins, never from emission, to the first apps that bring users.</li>
<li><strong>A minute of proof lag costs you nothing.</strong> Execution is immediate, the block is locked by miners in about two minutes, and the proof is a guarantee on top. A bridge withdrawal waits for the lock, about two minutes, against seven days on an optimistic rollup.</li>
<li><strong>A minute of proof lag costs you nothing.</strong> Execution is immediate, the block is locked by miners in about two minutes, and the proof is a guarantee on top. A bridge built on Igneum can release a withdrawal after the lock, about two minutes, against seven days on an optimistic rollup.</li>
</ul>
</section>
@ -391,7 +391,7 @@ body.all .pager{display:none}
<h3>What a miner's hour looks like</h3>
<p>The card hashes the lottery continuously. When the client sees a shard or an external job it can win, it switches the card to proving for a few seconds, posts the proof, and goes back to hashing. The client does the switching and the miner sees one balance. The official client is open source and charges a 1% dev fee, like every miner you already run, and any other client is welcome.</p>
<h3>One click, for everyone else</h3>
<p>Farm operators get HiveOS support on day one. Everyone else gets the Igneum app: install it on Windows, macOS or Linux, press one button, and the card is mining and proving to a wallet the app made for you, with earnings shown in IGN and in your currency, and mining paused while you game. It is the same client with a face on it. Mining never runs in a browser, because browser compute is slow and browser mining has meant malware since Coinhive. The browser is for the dashboard, and for verifying the chain.</p>
<p>Farm operators get HiveOS support on day one. Everyone else gets the Igneum app: install it on Windows, macOS or Linux, press one button, and the card is mining and proving to a wallet the app made for you, with earnings shown in IGN and in your currency, and mining paused while you game. It is the same client with a face on it. The app shows you the seed phrase and has you confirm it before mining starts, offers a hardware wallet for your earnings, updates only when you accept a release signed by the key published in the genesis block, and is downloaded only from this domain or the repository with its hash shown beside the button. Nobody from Igneum will ever ask for your seed. Mining never runs in a browser, because browser compute is slow and browser mining has meant malware since Coinhive. The browser is for the dashboard, and for verifying the chain.</p>
<h3>Fair launch, announced</h3>
<p>Launch date and miner software published a month ahead. Pools live on testnet. HiveOS support on day one. The founders mine from genesis like everyone else, with disclosed addresses and the same software. Nobody has coins before block one.</p>
</section>
@ -444,9 +444,9 @@ body.all .pager{display:none}
<h3>Proof of work, in 2027?</h3>
<p>Igneum's miners are paid for proving, not only for hashing, so the energy buys a proof of every block as well as the ordering of it. Proof of work also gives what stake cannot: no stake to capture, no builder cartel between you and the block, no foundation that can change the rules, and a chain whose state is proven at the base layer, which Ethereum does not have today.</p>
<h3>What does a one-minute proof mean for my app?</h3>
<p>Nothing you wait for. Your transaction executes in about a second. A miner lock arrives in about two minutes and that is the finality your contract sees. The proof follows and makes the state unforgeable. Liquidations and trades act on executed state at once, as on any chain. Bridge withdrawals wait for the lock, about two minutes.</p>
<p>Nothing you wait for. Your transaction executes in about a second. A miner lock arrives in about two minutes and that is the finality your contract sees. The proof follows and makes the state unforgeable. Liquidations and trades act on executed state at once, as on any chain. A bridge built on Igneum waits for the lock, about two minutes.</p>
<h3>Which stablecoin, and is there liquidity?</h3>
<p>USDC and USDT, bridged through the proof bridge at genesis as the canonical versions on Igneum. Native USDC is requested from Circle during testnet. The DEX is seeded at launch by the founders' own mined coins and by miners, and every miner is a funded wallet.</p>
<p>None is bridged at genesis, and no bridge is official. Native USDC is requested from Circle during testnet, and anyone may run a bridge at their own risk until the proof bridge arrives with the consensus proof in phase two. The DEX is seeded at launch by the founders' own mined coins and by miners, and every miner is a funded wallet.</p>
<h3>What do I get for being early?</h3>
<p>20% of the priority fee on every transaction that runs your code, paid to you every block. Launch grants from the founders' mined coins. A place in the wallet's Apps tab and the explorer from day one. And the only user base a new chain has ever had that did not have to be paid to arrive.</p>
<h3>How do I deploy?</h3>