igneum/docs/spec/06-open-items.md

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/"
O-1.10	The day key derivation is not in the design document (section 1.12)	Decision: adopt the proposed `"igneum-day/"
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
O-3.14	Finality simulation with the DAA in the loop under a pulsed rental (ledger M14 and F14, round 3): every run of sim/results_v2.md assumed a perfect retarget, and the devnet of 3 October 2026 showed DAA time running 2.9x the wall clock for 17 minutes after a hashrate step	finality_v2.py with Kaspa's sampled DAA and the controller chosen at gate 2 (section 2.3) in the loop, a 50x renter pulsing two minutes in every hour, under both forms of W2 and Q1 (DAA-score blocks as simulated; median-time buckets as specified in section 3.1 and 3.3), reporting the day the renter crosses a third and the chain's block rate meanwhile; logged in docs/bench-log.md; confirms or reverts the median-time form	3

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	14 (O-3.3 and O-3.7 narrowed to parameters and confirmation on 3 October 2026; O-3.14 added the same evening, round 3)
4	9
5	8 (O-5.1, O-5.2 and O-5.6 narrowed on 3 October 2026)
7	0
8	1
Total	61

By gate (an item shared between two gates is counted at the earlier one): 16 belong to gate 1, 11 to gate 2, 22 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.