# 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, 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.

An item closes when its measurement is in `docs/bench-log.md` or its decision is in the design document, and the section it belongs to is updated at a MAJOR or MINOR step (section 0.4).

## 6.1 Section 1, the lottery hash

| Id | Item | What closes it | Gate |
|---|---|---|---|
| O-1.1 | Seed derivation is FNV-1a 64 plus SplitMix64, ad hoc (ledger M7) | Replace with a standard hash (candidate: BLAKE2b or SHA-256 into the eight words); re-run the weak-program census of O-1.3 on the result; new vectors | 1 |
| O-1.2 | Load count per program is not fixed, only its expectation; 40 to 232 loads per hash over 10,000 programs; hash rate scales with it (ledger M5) | Exact-load-count rule in the generator (draw exactly 16 load positions), re-fuzz 10,000 programs, confirm the loads-per-hash column is constant | 1 |
| O-1.3 | Weak programs: 3 seeds measured for bias out of the population; nothing rejects a program whose `or` chain saturates a register or whose load addresses collapse (ledger M6) | Census of at least 10^5 programs on the CPU interpreter: bit bias and avalanche on 2^12 nonces, distinct load addresses per hash, registers saturated by `or`, nonce-independent registers; a rejection rule in the generator; a bound on the advantage of a miner grinding across candidate blocks | 1 |
| O-1.4 | No cryptanalysis of the hash as a lottery: the init is a bijection of the nonce per register; the body is add-rotate-xor-multiply with `or`; no analysis of shortcuts or seed influence (`TESTS.md` section 8 item 1, ledger M7) | External review scoped to the fair-lottery properties of section 1.1 (no shortcut cheaper than honest evaluation, no exploitable bias), not general hash security | 1 |
| O-1.5 | Memory hardness is measured on Apple only: shortcut ratio 4.8x slower on the M5 Max; not measured on NVIDIA or AMD (`MEMHARD.md` section 3 item 1) | Run `--inline-dataset` (the CUDA and OpenCL equivalents) on the RTX 5090 and on an AMD discrete card; the ratio must stay above 1 on every card that mines | 1 |
| O-1.6 | Time-memory trade-offs between the two measured points, and a smarter attacker kernel (hoisting the t-only part of round 0, caching hot lines), were not attempted (`MEMHARD.md` item 2) | Draw the curve: store fraction f of the dataset, recompute the rest, for f in {0, 1/8, 1/4, 1/2, 1}; write the hoisting attacker and measure it | 1 |
| O-1.7 | Mixer M_r and the chained-block cache have had no cryptanalysis; weak `ROT` draws (all equal) possible and untested (`MEMHARD.md` item 3) | External review of section 1.8; a weak-key check on the mixer draw with a rejection rule if needed; decide whether to adopt RandomX's SuperscalarHash design instead | 1 |
| O-1.8 | Distinct cache lines touched per hash not measured; cache-resident shortcut ruled out by argument (832 of 4,194,304 lines per hash, 26,624 per unit) not by census (`MEMHARD.md` item 5); inlining-the-cache cost is an estimate (item 4) | Census over 2^20 nonces; write the cache-inlining attacker kernel and measure it | 1 |
| O-1.9 | The hash does not commit to the block header; the packs use the program seed as the init words (section 1.6) | Fix the pre-PoW header hash in section 2 (fork point a5), adopt the proposed `I = seed_words_from_bytes("igneum-block/" || H || nonce_hi)`, produce a header-bound vector set | 1, with 2 |
| O-1.10 | The day key derivation is not in the design document (section 1.12) | Decision: adopt the proposed `"igneum-day/" || d || program_seed of the day's first epoch`, or another; owner cryptographer | 1 |
| O-1.11 | Era parameter draw: no procedure exists; bounds proposed in section 1.13.1 | Design review of the bounds; every drawn configuration must pass the fuzz and stats runs of section 1.15; decide what "memory pattern" means for the draw | 1 |
| O-1.12 | Instruction-family reserve: no list exists; candidates in section 1.13.2 | Each candidate family passes cross-vendor conformance with its own edge vectors; fix the order and `W_new` at genesis | 1 |
| O-1.13 | Dataset growth: 2 GiB plus 0.5 GiB per year is Designed; the index mapping for non-power-of-two sizes changes the vectors (section 1.13.3) | Decision between the multiply-shift mapping (new vectors) and power-of-two steps (`AND MASK` kept); measure hash rate and shortcut ratio at 2 GiB on three vendors | 1 |
| O-1.14 | CPU verify measured on one M5 Max core only (Rust 0.41 to 0.58 ms); the 10 ms gate is for a 2019-class laptop core (ledger M9, design document "Three experiments") | Measure the Rust verifier on a 2019-class core at 104 and 144 loads with the memory-hard cache; if over 10 ms, apply lever (a) | 1 |
| O-1.15 | Cross-vendor conformance: AMD is one integrated gfx1036 chip; no discrete AMD card has run anything; Intel unmentioned; the fuzz and edge sets have run on Metal and the CPU references only (ledger M8) | Run the seven commands of `proto-opencl/README.md` on an AMD discrete card; run the 10,200-program fuzz set and the 14 edge programs on NVIDIA and AMD; Intel Arc after | 1 |
| O-1.16 | Runtime kernel compilation on real rigs (NVRTC, ROCm, mixed-generation cards, every hour) is unmeasured; the 18 to 52 ms compile figures are Metal on one Mac (ledger M11) | Miner client prototype on a multi-card rig; compile time and failure rate per hour | 4 |
| O-1.17 | ASIC gain under 2x is a Target, not a measurement (ledger M1) | Public benchmark with a leaderboard by card model and a standing bounty for any chip design beating a GPU by more than 2x, January 2027; the claim stays a target until the bounty has gone unclaimed for years | phase 2, standing |
| O-1.18 | The 64-bit output and the 256-bit target space (section 1.10) | See O-2.4 | 2 |
| O-1.19 | Epoch length 3,600 DAA s against difficulty tracking (section 1.12) | See O-2.1 | 2 |
| O-1.20 | The GPU cache-fill time varied 0.6 to 2.1 ms across runs with identical code; cause not isolated (`MEMHARD.md` item 7) | Isolate (GPU clock state suspected); no consensus consequence | none, note |

## 6.2 Section 2, the ordering layer

| Id | Item | What closes it | Gate |
|---|---|---|---|
| O-2.1 | DAA window against per-epoch hash-rate steps: 2,641 s Kaspa window, candidate 1,800 s, or equalise cost per program (fork map c1, c2) | simpa run with programs stepping 30% every 3,600 blocks at both windows, with and without O-1.2's exact load count | 2 |
| O-2.2 | GHOSTDAG k = 18 at 1 BPS is Kaspa's table value; k was never exercised on the devnet (single serial miner) | Two-miner devnet at Igneum parameters; measure parallel-block rate and red-block rate | 2 |
| O-2.3 | Pruning depth must stay above the longest checkpoint gap and never pass the latest lock (section 2.1, F3) | Define the bound once the first-month rule (O-3.1) and the stall behaviour (section 3.3.1) fix the longest gap; implement in `block_depth.rs` and the virtual processor | 2, with 3 |
| O-2.4 | Mapping of the 64-bit hash into the 256-bit target and the block level for pruning proofs (fork map a3) | Decision: `target64 = target256 >> 192`, `level = leading_zeros(hash64)` capped at 64, or widen the output; check `calc_level_from_pow` callers | 2 |
| 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.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 |

## 6.3 Section 3, finality

| Id | Item | What closes it | Gate |
|---|---|---|---|
| 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 | 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 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 |
| O-3.11 | Key succession (W5): replay protection and what happens if both keys mine after the message | Specify the message (old key, new key, DAA score, signature) and that blocks naming the old key after inclusion earn nothing | 3 |
| O-3.12 | Vote message and certificate wire formats, aggregation rules, bitmap size at 10^4 keys | Specify with the P2P layer | 3 |
| O-3.13 | `finality_active` flag semantics and exchange guidance (section 3.9) are Designed and untested | Devnet stall test; exchange guidance reviewed by an operator | 3, 4 |

## 6.4 Section 4, seeds and the VDF

| Id | Item | What closes it | Gate |
|---|---|---|---|
| O-4.1 | `proto-vdf/src/classgroup.rs` (NUDUPL, NUCOMP, Lehmer partial xgcd) agrees with the textbook algorithms on 15,000 cases but has not been read by a second cryptographer against `vendor/chiavdf` | External review | 3 |
| O-4.2 | Reference core rate r_ref: 163,000 sq/s is this Mac with this code; x86 AVX-512 IFMA and chiavdf's assembly path differ | Run `vdf bench` on every devnet node type that will mine; fix `T_epoch = 600 r_ref`, `T_era = 3,600 r_ref` at genesis | 3 |
| O-4.3 | Whether the seed checkpoint must be certified or may be the uncertified selected-chain block at that blue score; the `seed_source` header field (section 4.3) | Decision at gate 3 with the devnet; this specification proposes uncertified-allowed so a finality pause does not stop mining | 3 |
| O-4.4 | Fallback for a node without the seed at an epoch boundary: option A (previous program valid for N blocks) or B (none) (section 4.7) | Measure time to first block after a boundary on the slowest devnet node type; decide | 3 |
| O-4.5 | HashPrime byte layout (mirror chiavdf or not); carry D in the proof so the verifier skips the 17 ms prime search; compact form encoding before the wire format freezes | Decision, cryptographer | 3 |
| O-4.6 | Reduction runs every squaring; chiavdf reduces only when `a` exceeds 8 limbs | Port; re-measure r_ref | 3 |
| O-4.7 | No fuzzing of `deserialize` on hostile bytes beyond validity checks; no VDF rate measured on NVIDIA or AMD hosts' CPUs | Fuzz the deserializer; bench on the devnet hosts (same run as O-4.2) | 3 |
| O-4.8 | The era draw must take the VDF output as its only randomness (`proto-vdf/README.md` item 6) | Check against section 1.13.1 once O-1.11 is fixed | 1, with 3 |
| O-4.9 | Grinding model assumptions: advantage uniform on 0 to 15% per program (the review's measured range), top-quartile keep rule, one block burned per candidate | Re-run `vdf grind` with the advantage distribution from the O-1.3 census | 3 |

## 6.5 Section 5, fees and economics

| Id | Item | What closes it | Gate |
|---|---|---|---|
| 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 | 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 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 | 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 (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, 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.