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/" || 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. Sweep 5 October 2026: the gate is implemented (`min_daa = weight_window`, fin-fixes, merged into devnet-v4) and measured on the fork (harness s5 before and after, `docs/bench-log.md` "finality fixes F17 and F1"); the launch month under the gate is arithmetic in `docs/review/ledger-sweep-2026-10-05.md` (no lock before day 30; on day 30 an attacker with share s of blocks from day k holds s (31 - k) / 30, so 75% from day 2 holds 72.5% and locks alone, 51% from day 1 cannot; the lock-alone threshold is 69% from day 2). What is left is the decision to keep the gate at the full window, which the ledger (F1) recommends | 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. Sweep 5 October 2026: the chain model has run (`sim/difficulty/attacks` scenario 2: a 50x pulse earns 3.7% of the base's blocks per hash under the Igneum rule and 85% under Kaspa's, weight per hash 0.26 and 0.98, never above 1) and the fork agrees (harness s5, weight share over block share 0.999). The DAA inside `finality_v2.py` under both W2 forms is still not written (fud-fixes row 123) | 3 |
| O-3.15 | Vote keys with history can be bought, borrowed or stolen; every scenario in `sim/results_v2.md` models a renter who must mine (ledger F19, external review 3 October 2026) | `finality_v2.py` scenario: k% of weight changes hands at day 0 against the same k% arriving as fresh hashrate, for k in 20, 34 and 40, plus a 40/40/20 partition row under the active-set rules and the floor; report time to a conflicting lock; decide whether W5 makes the successor re-earn and whether weight decays when a key's block profile breaks | 3 |
| O-3.16 | What holds during a finality pause: the seed pipeline from uncertified checkpoint blocks (O-4.3, section 4.3), the survival of pre-pause locks (3.5) and `finality_active` false (3.9) are three texts and no statement (ledger F20) | Decide O-4.3 (this specification recommends uncertified-allowed); write the four pause guarantees into 3.7; devnet with a 45% silent set through 3 epoch boundaries: program advances on schedule, no seed fork, pre-pause locks survive the heal | 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 |
| O-5.9 | Mining against proving under shocks: external proving pays 10x, the IGN price falls, a large operator leaves, assignments go unfulfilled, clients maximise profit (ledger E12); design R8 covers the fee switch only and has not run | R8 simulation extended with the five shocks, then the phase 4 devnet with profit-only prover clients: backlog depth, time to clear, `f_p` and `B_p` paths, income per card. Sweep 5 October 2026: the simulation half ran in `sim/economy` (scenarios b, d, e: external 10x with a 70% price fall, the 20% operator leaving, a 30% operator never fulfilling; no backlog, every block proven within 60 s, hash trough 82% and 75%); the devnet half with profit-only clients is fud-fixes row 126 | 4 |
| O-5.10 | No single figure shows every payment route (emission, base fee, priority fee, external jobs at launch and after the bridge, the client dev fee) with currency, recipient, fee and burn (ledger E13) | Draw it, one route per row, in the litepaper Economics section and the customer brief; operator revenue never summed with protocol revenue | decision, execution engineer; before public repo |
| O-5.11 (decided) | **Decided 5 October 2026 by the owner: the 4,000,000,000 IGN cap is absolute, no tail emission (section 5.10).** The question was the security budget through halvings with low fees and no external demand at a flat IGN price (ledger E15), and whether a tail reward answers it. Measured by `docs/analysis/security-budget.md` (3 October) plus `python3 sim/economy/security_budget.py` (5 October 2026: fee grid, falling and rising paths, hashrate response at USD 0.12/kWh, 300 W, 124 MH/s): the subsidy to miners alone is under the USD 1,000,000 floor (the power of 3,169 cards) from year 7 at USD 0.005, year 11 at USD 0.02, never within 14 years at USD 0.10; no fee level in the grid moves a flat-price year; at the crossing USD 500,000 powers 1,584 cards and a 51% attacker matches them for USD 1,369 of electricity a day, USD 27,379 over 20 days. The security budget after the subsidy is the proving market plus fees; provers' income does not depend on emission | Closed. Section 5.10 states the table, the decision and the review trigger (5.10.3): if external proving revenue is under one fifth of the block subsidy over any 90-day window after year 5, the tail-reward question goes to the miners' signalling vote (5.7, 5.8; encoding O-5.3) and the protocol never changes emission without it. The litepaper Economics section and the homepage state the cap, the years and the trigger | decided; the trigger stands |

## 6.6 Sections 7 and 8, execution and client security

Section 7 carried no open item of its own at 0.1: its measurements are O-5.1 (shard sortition parameters) and O-5.2 (the IGN settlement switch), listed above. Two were added on 3 October 2026 (night) from the external review, and section 8 gained two beside its 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 |
| O-7.1 | The phase 2 gate could be passed by shrinking the shard (design R2's fallback); no end-to-end standard existed (ledger P16) | The benchmark standard: fixed published workload, job received to proof accepted (queueing, transfers, proving, aggregation, verification, payment), median and slowest 5% and 1%, failure and retry rates, full cost, per advertised card with mining and proving compatibility stated separately, no growing backlog, reproduced by three unrelated operators from published code and configuration; `site/journey.json` phase 2 carries it in one sentence | phase 2 |
| O-7.2 | Interfaces show three states (executed, proven, locked); included is a list, not a state (ledger P17; `docs/design/execution-layer.md` 2.4 now states the four-state rule) | Wallet and RPC conformance set on the devnet: one transaction through each of included, executed, proven, finalised and the three failure paths (skipped, reorged out, finality paused); the phone app and the explorer show the same word as the RPC | 2, with phase 2 |
| O-8.2 | The official client and the phone monitor show earnings without netting power, and do not separate mining from proving income, list failed jobs or show the pending release (ledger X17) | Display rules in the client and in phone-app 4.1: net after an entered tariff, incomes separate per card and day, failed and retried jobs with reasons, running release and hash with the pending one; measured against the pool protocol's `stats` on the phase 4 devnet | 4 |
| O-8.3 | Proving jobs run strangers' guest programs on the machine that holds the wallet, seed and vote key; no isolation design exists (ledger X17) | Design: prover process under a separate OS user or sandbox, holds no key, signs payout claims through a local socket only; reviewed before the first external job; escape test with a hostile guest program on the phase 4 devnet | 4 |

## 6.8 Gate 4 and the public product (no spec section)

Added 3 October 2026 (night) from the external review. These items belong to no section of the specification; their letter follows the ledger's launch section.

| Id | Item | What closes it | Gate |
|---|---|---|---|
| O-X.1 | "Independent" for the 1,000-miner gate is undefined (ledger X5) and concentration in hashing, checkpoint signing, proving and aggregation is unreported (ledger X14) | Define independence (distinct ASNs, benchmark hardware fingerprints, pool attestations); compute the four concentrations as top-1, top-3 and top-10 shares over 30 days from chain data; publish on the live page beside the gate | 4 |
| O-X.2 | "The chain runs without its founders" is untested (ledger X15) | On the public testnet, stop every project-run node, miner, prover, aggregator, seed node, observer and the site for 24 h at a published time; record blocks per second, proof lag, certificates per hour, and a fresh node's sync from the client's seed list | 4, before mainnet |
| O-X.3 | No evidence page; the bench-log does not say who ran a test or whether anyone outside has (ledger X16) | One row per public claim: status, version, test, result, and one of implemented / tested by the team / reproduced externally / reviewed independently; audits tied to versions; published with the benchmark | phase 2, standing |

## 6.7 Count

| Section | Open items |
|---|---|
| 1 | 20 |
| 2 | 9 (O-2.8 closed 3 October 2026 by section 7.1) |
| 3 | 16 (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; O-3.15 and O-3.16 added the same night, external review) |
| 4 | 9 |
| 5 | 11 (O-5.1, O-5.2 and O-5.6 narrowed on 3 October 2026; O-5.9 to O-5.11 added the same night, external review; O-5.11 decided 5 October 2026, section 5.10) |
| 7 | 2 (added 3 October 2026, night) |
| 8 | 3 (O-8.2 and O-8.3 added the same night) |
| X (6.8) | 3 |
| Total | 73 |

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.

Added 3 October 2026 (night, external review): 12 items. 2 at gate 3, 1 at gate 2, 5 at gate 4, 2 at phase 2, 1 decision (O-5.10), 1 before mainnet (O-5.11).

## 6.8 Added 3 October 2026 with section 3.11, Guarantees

Section 3.11 states the finality guarantees with their assumptions and derives the bounds from Q3. Four items follow from the derivation and one decision is recorded.

| Id | Item | What closes it | Gate |
|---|---|---|---|
| O-3.15 (decided) | **Decided 4 October 2026 by the project lead: f = 1, the floor is 2/3 of total weight (Q3).** The trade it settled: with the floor at f x 2/3 of total, two conflicting certificates need equivocators holding 4f/3 - 1 of total weight across a partition that outlasts the presence decay, and liveness survives up to 1 - 2f/3 of weight silent; at f = 0.85 that was 13.3% and 43.3%, at f = 1 both are one third. Since active weight never exceeds total, the active test of Q3 is implied and a lock is two thirds of all 30-day weight signing; finality pauses whenever less than two thirds is connected and signing, the chain continues on proof of work meanwhile, and the node reports it. Measured after the decision: `sim/results_v2.md`, "Floor 2/3" (H: 0 conflicts through a 33% equivocator, conflicts at minute 0 from 34%; L1: the pause begins between 32% and 34% silent in the model, 33% silent locks 11% of checkpoints; L2: 35% churn stalls about 1.4 days and 50% churn 10 days, the total-denominator figures of D; L4: a side of a long honest partition holds two thirds of its own window from day 30 (2/3 - s) / (1 - s), 10 days at 50/50 against 4 under the old floor); the three-node, six-voter devnet of `docs/bench-log.md`, "finality floor 2/3" (scenario 6A: no lock on either side of a 3/3 split; 6B: the 4 side locks at exactly 2/3, inclusive) | Closed. The litepaper states both numbers (two thirds to lock, pause below two thirds signing) | 3 |
| O-3.16 (text closed) | 3.3.1 ("the safety bound stays at 1/3 of weight for every event tested") and 3.7 item 1 ("safety holds with under one third") stated the connected-network bound only; under the 0.85 floor 3.11 item 2 gave 1/3 only while every honest voter's votes reached every honest node within 41 minutes, falling to 4/30 beyond that | Closed 4 October 2026 by O-3.15: at f = 1 the bound is one third in every view whatever the presence window says (two certificates need 4/3 of weight in signatures), and 3.3.1, 3.7, 3.11.2 and the litepaper say so. What remains is the window bound of 3.3.1 (a side that mines alone for a third of the window holds two thirds of its own table), stated there and in 3.7 item 9, measured in L4 and on the devnet (6A) | 3 (text) |
| O-3.17 | Two valid certificates at one index: 3.5's proposal (strike the equivocators, re-evaluate, treat the index as uncertified if neither or both lock) makes a verified lock revocable (R3.17, ledger F16). 3.11 item 4 replaces it: a verified certificate is never withdrawn, the node reports `finality_conflict`, clears `finality_active`, keeps following the certificate it verified first, and the split is resolved by operators through F5, as Kaspa resolves a finality conflict by notification and not by rule (`vendor/rusty-kaspa/consensus/notify/src/notification.rs`, `FinalityConflict`) | Replace the paragraph in 3.5 with 3.11 item 4; implement `finality_conflict` in the node; devnet test that forces a double certificate and checks that no node ever reports a lock it later withdraws. Closes the rule half of O-3.6; the devnet half stays | 3 |
| O-3.18 (narrowed) | The liveness bound T of 3.11 item 3 was derived under the block reading of Q2 (absent keys decay, present keys hold 1), which recovers more slowly than the cert reading the simulator runs. With the floor at 2/3 (O-3.15, 4 October 2026) the presence decay no longer enters T: a lock needs two thirds of total whatever participation says, so T = I + d + G + Delta (107 s) whenever two thirds is connected and signing, and below that finality pauses for as long as the shortfall lasts (silence) or until the missing weight ages out (churn, 30 (1 - 1/(3x)) days for a set holding x). What is left is the exit from a pause under the block reading: the first lock after the silent set returns is 0 minutes under the cert reading (`sim/results_v2.md` J and L1) | The O-3.3 re-run under the block reading reports the first lock after a 40% silent set returns and confirms or corrects the 0-minute figure | 3 |
| O-4.3 (decision) | Decided 3 October 2026 by 3.11 item 6: the seed checkpoint is the selected-chain block at the checkpoint blue score the lead rule names, certified or not, so a finality pause never stops the hourly program. Remaining: implement `seed_source` from the checkpoint block (the devnet keys the program on the header's `daa_score`, R3.26) and run an epoch boundary through a forced pause on the devnet | Implementation and the devnet pause test | 3 |
| O-3.19 (narrowed) | Q2 credits participation for "a valid vote by k at index j" and the node credits any vote at the index whatever block it names (3.10). A key can then vote for a block of its own at every index, keep participation 1 and its weight in the active denominator, and never add to a certificate. Under the 0.85 floor that pushed the honest lock threshold from 17/30 of total up to 2/3 of total; under the 2/3 floor (O-3.15, 4 October 2026) honest voters need 2/3 of total for every lock anyway, so the attack changes no lock and no bound. What it still distorts is the report: a key voting for private blocks reads as present. 3.11.1 reads Q2 as crediting only a vote that names C_j on the selected chain of C_i | Write the reading into Q2 and the node's participation count as a reporting rule; no re-run of C is needed for the lock threshold | 3 (reporting) |

Count after this addition: section 3 has 19 items (O-3.15 to O-3.19 added; O-3.6 narrowed to the devnet test), section 4 keeps 9 with O-4.3 decided and awaiting implementation; total 66.

Update of 4 October 2026 (floor 2/3): O-3.15 decided and O-3.16 closed as text (both kept in the table with their resolution), O-3.18 and O-3.19 narrowed as stated in their rows. Section 3 keeps 17 open items.