igneum/docs/fud-ledger.md

Igneum FUD ledger

Version 0.1, 3 October 2026. A living document. Published alongside the litepaper.

What this is

Every serious criticism or attack we expect against Igneum, written the way it will be posted, with the honest answer next to it. Where the answer is a measurement, the file that holds the measurement is named. Where the answer is a design rule, the rule is quoted. Where there is no answer yet, the entry says "Open" and names the experiment that will settle it and when. Where the critic is right, the entry says so.

The ledger exists because the only way a design survives public scrutiny is for every pick to have been answered in public before anyone else makes it. It is written against litepaper v0.1 and the design document as of 3 October 2026. Entries are never deleted. When the status of an entry changes, the old status stays in the history of this file.

Statuses used:

Status	Meaning
Answered with evidence	A measurement, simulation or cited precedent exists and is named
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.

Evidence locations referenced below: docs/bench-log.md, proto-metal/TESTS.md, sim/results.md, sim/finality_sim.py, proto-cuda/, the design document section "Finality rule, version 2, after the second hostile review" (called "design doc, Finality v2" here), its "Security model" table, and its "What the hostile review changed" table.

---

1. Mining and ASIC claims

M1. The program space is tiny

"Eleven integer ops, 64 instructions, 8 iterations, a splitmix register init. That is not RandomX. RandomX leans on a superscalar out-of-order CPU with floating point and branches. Yours is a sea of 32-bit ALUs and a memory bus. A chip for that is a weekend."

Status: Open, experiment scheduled.

Answer: Correct that the arithmetic is simple on purpose. Integer only, because floating point rounds differently per vendor and would split the chain (design doc, hostile review table, row 2). The defence is not the ALU work. It is random 4-byte reads over a dataset larger than any on-chip cache: the RTX 5090 runs the same program 5.8x faster when the dataset fits in its 96 MiB L2 (1,352 Mhash/s at 64 MiB against 229 at 1 GiB, bench-log, RTX 5090 sweep). A chip has to buy the same gigabytes of memory and loses the same latency. The honest target for a chip's gain is under 2x and it is a target, not a measurement. The experiment that tests it is the standing bounty for any chip design beating a GPU by more than 2x, live with the public benchmark in January 2027 (design doc, decisions table, row 1). Until a bounty has gone unclaimed for years the claim is a target.

Evidence: docs/bench-log.md (RTX 5090 dataset sweep), proto-metal/TESTS.md section 8 "Not demonstrated" item 2. Bounty: not yet.

Cross-reference (external review, 3 October 2026, night): the bounty's scoring rules, eligible hardware, judge and funding are M22; "under 2x" is a hash-rate target and not the economic threshold.

M2. Your own prototype is not memory-hard

"Your TESTS.md says computing the dataset inline runs 110x faster than loading it. You put the 228 Mhash/s number on the website anyway."

Status: Conceded, not yet stated in the litepaper.

Answer: True. The prototype dataset is a six-operation closed form, and --inline-dataset measured 4,888 Mhash/s against 44.6 honest on the M5 Max, about 110x. The litepaper quotes the 228 and 45 Mhash/s figures without that caveat. The fix is the 256 MB RandomX-style cache with eight dependent reads per item (design doc, Finality v2, Lottery seeds item 3), which is the next thing to build. The number that matters afterwards is the shortcut ratio, which must fall to about 1. The litepaper must carry the caveat until then.

Evidence: proto-metal/TESTS.md section 7. Fix: overclaims list, item 23.

M3. Kaspa said ASIC resistant too

"Every GPU coin promised this. IceRiver shipped a Kaspa chip in eighteen months. Why are you different?"

Status: Answered by design, with a correction to our own text.

Answer: First the correction: Kaspa did not promise ASIC resistance. kHeavyHash was designed to be friendly to specialised and optical hardware, and the Kaspa community expected chips (approximate, from memory; cite the Kaspa docs before quoting). Our litepaper's "Kaspa said ASIC resistant too" misstates them and will be reworded. What differs here: the program changes hourly and is compiled from a generator fixed at genesis, the dataset is derived daily and grows on a fixed schedule, and instruction families unlock by height from a genesis reserve. A chip that handles the whole program space is a GPU with the graphics parts removed. Precedent: RandomX has run on Monero since November 2019 with no chip publicly shipped (approximate).

Evidence: design doc, "ASIC resistance" section. Fix: overclaims list, items 11 and 49.

M4. ProgPoW already did this and you do not mention it

"A GPU program whose random maths changes every few blocks shipped on Ravencoin as KAWPOW in 2020. Your 'first' table says the GPU version was 'designed, discussed, never shipped'. That is false."

Status: Conceded, not yet stated in the litepaper.

Answer: Correct. ProgPoW, and KAWPOW on Ravencoin since May 2020 (approximate), regenerate a random maths sequence per period on GPUs. The design doc cites ProgPoW's fixed-footprint rule; the litepaper's firsts table does not. What Igneum adds over ProgPoW: a full kernel per hour compiled to native code, warp shuffles as the unit of work and verification, a daily dataset derived from a 256 MB cache, a verifiable delay between seed and program, automatic era draws from a genesis reserve, and a growing dataset. The row must be rewritten to name ProgPoW and KAWPOW as the closest precedent.

Evidence: none in the repository yet; the ProgPoW specification and the Ravencoin repository should be cloned into vendor/ and cited. Fix: overclaims list, item 5.

M5. Your load count varies 6x between programs

"TESTS.md: loads per hash ranged 40 to 232 across 10,000 programs. A 40-load program is ALU-bound and favours a chip for that hour. Your litepaper says the memory footprint and instruction count are fixed."

Status: Fixed (4 October 2026): generator version 2 draws exactly 16 load slots per program (spec 01 section 1.4.2, igneum-pow/src/generator.rs), and the fresh-source rule of 1.4.3 with the acceptance rule of 1.4.6 fixes the distinct count too, which the census showed is what the GPU pays for: every accepted program does 128 loads per hash of which at least 120 and typically 128 are distinct (20,000-program confirmation: mean 127.887, min 120.127). Apple OpenCL on the M5 Max runs every version 2 pack within 1 percent of the same rate (27.5 to 27.9 Mhash/s). Every vector was re-cut and all three workers re-checked (docs/bench-log.md, 4 October 2026 "generator version 2"). Still owed: the first RTX 5090 run on a version 2 pack. Was: Open, experiment scheduled.

Answer: Correct and a real gap. The instruction count is fixed (64 x 8); the load count is not, and the hash rate scales with it (104 loads gave 228 Mhash/s, 128 loads gave 185 on the 5090). The generator must fix the load count per program, or bound it tightly, so every hour is equally memory-bound and difficulty does not whiplash on the hour. This goes into the specification in phase 1 and is re-fuzzed. Until then the litepaper's sentence about fixed footprint is ahead of the prototype.

Evidence: proto-metal/TESTS.md section 1 (loads per hash 40 to 232), docs/bench-log.md (104 vs 128 loads). Fix: overclaims list, item 15.

M6. Weak programs

"Some hours the generator will emit a program whose OR chain saturates a register or whose load addresses collapse. That hour is both biased and shortcut-able. You have measured 3 seeds for bias out of an infinite population."

Status: Fixed (4 October 2026): the acceptance rule of spec 01 section 1.4.6 (igneum-pow/src/accept.rs, mirrored in proto-metal/main.swift) rejects a candidate with a stale load source, a register without an injecting write, a nonce-independent register bit, a lane-constant load site, more than 1 percent saturated final values, an output bit past 6 sigma, or fewer than 120 distinct addresses per hash on average, over 64 fixed units on the seed-keyed closed-form dataset; a rejected candidate is replaced by the next attempt of the seed, so every node agrees. Measured: 5.225 percent of 20,000 candidates rejected (4.130 static, 1.095 dynamic), 1.055 candidates per epoch; the rule costs 1.3 to 3.4 ms. The remaining question, whether 6 sigma at 2,048 nonces is the right bias threshold, is a prototype value of spec 1.16. Was: Open, experiment scheduled.

Answer: Correct. Three seeds were measured for bias (max deviation 2.90 sigma over 192 bit positions, avalanche mean 32.0, std 4.0, zero duplicates) and the population was not. Nothing yet rejects a weak program. The scheduled experiment is a weak-program census of at least 10^5 programs on the CPU interpreter measuring bias, distinct load addresses, OR saturation and nonce-independent registers, then a rejection rule written into the generator. Phase 1, before the spec is final.

Evidence: proto-metal/TESTS.md section 3 and section 8, "next three tests" item 1.

M7. No cryptographic analysis at all

"splitmix32(nonce ^ seed) ^ seed per register, then add-rotate-xor-multiply with OR. Nobody has looked at preimage, collision or seed-influence resistance. This is a toy hash that happens to be slow."

Status: Conceded, stated in the test report, not yet in the litepaper.

Answer: Correct. TESTS.md section 8 says exactly this. The lottery hash needs only to be a fair lottery: unpredictable output per nonce, no shortcut cheaper than honest evaluation, no bias a miner can exploit. It does not need to be a general-purpose cryptographic hash, and the design should say that explicitly and then prove the narrower property. The ad-hoc seed derivation (FNV-1a plus SplitMix) is to be replaced with a standard hash so the seed-to-program mapping is auditable. External review in phase 1.

Evidence: proto-metal/TESTS.md section 8, "Not demonstrated" item 1 and "next three tests" item 3.

M8. Only two vendors, two programs, one day

"'Any card, any vendor, bit-exact' rests on 192 vectors across two programs on one Apple chip and one NVIDIA card, all run on the same day. AMD is untested. Intel is unmentioned."

Status: Answered with evidence for what was measured; Open for AMD and Intel.

Answer: 192 of 192 vectors matched across Metal and CUDA on two programs, standalone and in batch. That is the measurement and it is small. AMD (ROCm or OpenCL) is the next run, then the full 10,200-program fuzz set on NVIDIA and AMD with the 14 edge-case programs, and the shuffle, mulhi and shift semantics must agree bit for bit on every vendor. Intel Arc after that. The litepaper says "Any card, any vendor" and should say what was measured.

Evidence: docs/bench-log.md (RTX 5090 first run), proto-metal/TESTS.md section 8 "next three tests" item 3. Fix: overclaims list, items 20 and 59.

M9. The 10 ms CPU verification gate is unmeasured

"0.02 ms per warp is with a six-op dataset formula. With a 256 MB cache and eight dependent reads per item it will be a different number, and you call it 'the measured gate'."

Status: Conceded, not yet stated in the litepaper.

Answer: Correct. The 0.015 to 0.021 ms figures are with the cheap closed-form dataset. The design bounds a warp to at most 4,096 distinct dataset items, each from eight dependent cache reads, so the verifier does about 32,000 random reads in 256 MB per warp. At roughly 100 ns per miss that is about 3 ms, approximate, which is why 10 ms is the gate. It has not been measured, and the design doc lists it as a promise until measured. The experiment is scheduled on an M5 Max and on a 2019-class laptop core.

Evidence: docs/bench-log.md (first run, CPU verify column), design doc Finality v2 "Residual risks" last bullet and "Three experiments before gate 3". Fix: overclaims list, items 16 and 21.

M10. "Bound by memory bandwidth" is wrong

"Your own log says random-access bound. The 5090 moves 95 GB/s of useful loads against 1,638 GB/s sequential. HBM cards and chips with wide random-access memory will beat consumer GDDR here."

Status: Answered with evidence, with a wording fix.

Answer: The log is right and the litepaper's word is wrong: the limit is random access latency, about 23.7 billion random 4-byte loads per second on the 5090 regardless of program. The wording will change. On the substance: a chip or a datacentre card still needs gigabytes of memory and still pays the random-access cost; HBM improves bandwidth more than it improves random 32-byte sector latency, approximate. Whether an H100-class card beats a 5090 per dollar on this workload is a measurement we have not made, and it belongs on the January 2027 leaderboard.

Evidence: docs/bench-log.md, RTX 5090 sections. Fix: overclaims list, item 14.

M11. Hourly JIT on real rigs

"50 ms compile is a Mac number. On a HiveOS rig the miner has to ship NVRTC or a ROCm compiler, compile for eight cards of mixed generation, and do it every hour without crashing. Every miner that tried runtime codegen had a bad year."

Status: Open, experiment scheduled.

Answer: Correct that the compile figures (18 to 52 ms) are Metal on one Mac. The 5090 run used an offline nvcc build. Runtime compile with NVRTC and with ROCm on a multi-card rig is unmeasured. KAWPOW miners do ship runtime kernel generation on both vendors, so the problem is known to be solvable (approximate, from memory). Measured in phase 2 with the miner client prototype.

Evidence: docs/bench-log.md compile columns. Rig measurement: not yet.

M12. Rentable hashrate is not just NiceHash

"You say rental is priced by the hour. Cloud GPUs are priced by the hour too. A thousand 5090-class cards for a day is a few thousand dollars."

Status: Answered by design for finality, Conceded for the lottery.

Answer: Both halves true. NiceHash and MiningRigRentals cannot list an algorithm whose kernel changes hourly without a stratum for it, so classic hashrate rental does not exist at launch. Cloud GPUs do, and they can out-mine a small chain's lottery cheaply. That is why finality is weighted by 30 days of blocks, not by today's hashrate: a renter with 60% of the network earns 59.9% of block rewards on day 1 and holds 0.0% of vote weight (sim, table B). What rental can do is take block rewards and stall finality after about three weeks. See F1 for the launch window, where this answer does not yet hold.

Evidence: sim/results.md table B.

M13. Macs mine too is marketing

"An M5 Max does 45 Mhash/s against 228 on a 5090 and costs more. 'Macs mine too' is a line for people who will lose money."

Status: Conceded, partly stated.

Answer: The measured ratio is about 5x in the 5090's favour, so a Mac is a poor miner per dollar. The litepaper says Macs mine; it should say Macs mine at about a fifth of a flagship card and that the one-click app shows projected earnings before it starts.

Evidence: docs/bench-log.md, two-card table.

---

2. Finality and attacks

F1. Finality is attackable for the first month

"Vote weight is 30 days of blocks. At genesis there are zero days. For the first weeks weight equals hashrate share, so anyone with two thirds of a tiny launch hashrate locks checkpoints alone. You say 'no certificate in the first hour'. An hour."

Status: Conceded, not yet stated in the litepaper. Experiment and rule change scheduled.

Answer: Correct, and this is the most dangerous entry in the ledger. With the active-weight denominator and a one-day honest head start, an attacker producing 75% of blocks from day 2 holds 0.75k/(1+k) of weight after k days and crosses two thirds on day 9 of the chain's life; an attacker arriving in hour two crosses it the same day. The window is empty, so the defence is absent. The 30-day emission ramp (10% to 100%) lowers the incentive without removing the attack. The design doc's answer, the one-hour merge-depth bound protecting the first month, bounds the damage of a reorg and does nothing about a bad lock. The rule under consideration: no certificate may form until the window has 30 days of history, so the chain runs plain GHOSTDAG under the one-hour merge-depth bound for its first month, exchanges are told to treat it so, and listings follow launch in any case. This goes to the gate 3 simulation and the litepaper will state it either way.

Evidence: arithmetic above (not yet in sim/); design doc, hostile review table row "No stake exists in the first month". Simulation of the launch month: not yet.

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: 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.

Evidence: sim/results.md table E and "What the simulation cannot tell us"; design doc Finality v2, Quorum item 4 and the "Simulation of the first version" paragraph.

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: 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.

Evidence: design doc Finality v2, Quorum item 2 and Checkpoints item 3. Fix: not yet.

F4. It is proof of stake with extra steps

"A two-thirds BLS committee that overrides the heaviest chain is a checkpoint committee. Bitcoin's entire point is that nothing overrides work. You built a PoS finality gadget and weighted it by past work instead of coins."

Status: Answered by design, with the concession stated.

Answer: The committee's weight is blocks mined in the last 30 days. There is no coin to buy, stake, delegate or slash, and the weight cannot be acquired faster than by mining in public. The design concedes what follows: pools hold their hashers' votes, so vote concentration equals pool concentration, as on Bitcoin, and a 51% owner who drives half the honest miners away for a month owns finality thereafter, "same as Bitcoin, with a month's warning". It is a finality overlay on proof of work. Calling it that in the litepaper is more honest than "powered by miners alone".

Evidence: design doc Finality v2, "Residual risks" bullets 3 and 4; sim/results.md table F.

F5. The headline arithmetic is misread on purpose

"'An attacker who brought the whole network's hashrate needs ten days for a third.' If I bring hashrate equal to the network I have half the blocks and need twenty days for a third and never reach two thirds. Your ten days assumes honest miners produce nothing."

Status: Conceded, wording to fix.

Answer: Correct reading. The 10 and 20 day figures assume the attacker produces 100% of blocks, which is the strongest attacker and therefore a true lower bound, and the sentence should say "an attacker producing every block on the chain". With half the blocks: 1/3 at day 20 and 2/3 never. With 60%: 1/3 on day 18 to 26 depending on the (now removed) cap, 2/3 never. With 75%: 2/3 on day 27 to 34.

Evidence: sim/results.md tables B and C. Fix: overclaims list, item 32.

F6. Equivocation costs nothing that matters

"A pool that signs two checkpoints loses its vote for 30 days. Not its blocks, not its coins. If two thirds of pools collude to double-spend an exchange, the penalty is a month of not voting."

Status: Conceded, stated in the litepaper and the design doc.

Answer: True. "Equivocation costs history, not coins." There is nothing to slash without stake, and the design refuses stake. What bounds the damage is the one-hour merge-depth rule (a bad lock cannot reorganise deeper than an hour) and that two thirds of weight takes 20 days of 100% hashrate in public to acquire. A colluding two-thirds of pools is the same actor set that can attack Bitcoin, and the litepaper says so.

Evidence: design doc Finality v2, Checkpoints item 4 and Residual risks bullet 1.

F7. A 2-minute checkpoint on a DAG with a 1-hour merge bound

"Kaspa treats an hour as the merge-depth bound at 1 bps. You vote on the selected-chain block at blue score 30i once the tip is 60 blocks past. Under real latency honest nodes will disagree on that block often enough to split votes at the same index and lose quorum."

Status: Open, experiment scheduled.

Answer: Fair. The depth d is "set from the devnet reorg-depth distribution, 60 at one block a second", and that distribution has not been measured. The devnet experiment in gate 3 runs with regional latency and records the reorg-depth distribution at each block rate; d is chosen so that a vote split at one index is rare and self-heals at the next. Until then 60 is a placeholder. The chain also runs without the finality module (plain GHOSTDAG) so a wrong d can be corrected without a stop.

Evidence: design doc Finality v2, Checkpoints item 1 and "Three experiments before gate 3".

F8. The simulation has no network in it

"No latency, no DAG, no red blocks, no partitions, no VRF noise, perfect retarget. You published 'ten days' and 'twenty days' from that."

Status: Conceded, stated in the simulation report.

Answer: Correct. sim/results.md lists every one of those omissions under "What the simulation cannot tell us". The day counts are arithmetic on the window and hold for any model where blocks are counted; the things the model cannot see (red blocks, partitions, eclipse) are what gate 3's devnet is for. The litepaper quotes the day counts as design facts; it should attribute them to the model.

Evidence: sim/results.md, final section.

F9. Half the hashrate leaves and finality stalls for ten days

"Your own sim: 50% churn stalls the lock 10 to 11 days under the fail-safe rule. GPU coins lose half their hashrate in a week when the price halves. That is routine, not an attack."

Status: Answered by design.

Answer: That table is the all-keys denominator, which the simulation recommended for safety. Finality v2 chose the active-weight denominator with a 2-hour presence window instead, under which no churn level stalls more than two hours (sim table E, "active" column: 100% live share from day +1 at 30%, 35% and 50% churn). The price of that choice is F2. The two experiments in gate 3 decide the final rule; the litepaper states the 2-hour figure.

Evidence: sim/results.md table E; design doc Finality v2, Quorum item 4.

F10. Pools hold the votes

"Two pools at 70% of hashrate is normal on a GPU coin. On Igneum that is two operators holding finality."

Status: Conceded, stated in the design doc, not in the litepaper.

Answer: True. The vote key is named in the block header by whoever builds the block, which in a pool is the pool. The design doc states "Pools hold their hashers' votes. Vote concentration equals pool concentration, as on Bitcoin, and is public." Stratum v2 lets a hasher choose transactions when its pool supports it, and does nothing for the vote key. Solo mining is viable at one block a second (86,400 blocks a day), which widens the key set in a way Bitcoin's block rate does not, and the dust threshold of 100 blocks per 30 days is about 0.004% of hashrate. The litepaper's "governed by the people who power it, and by nobody else" must carry the pool sentence.

Evidence: design doc Finality v2, Residual risks bullet 3. Fix: overclaims list, item 44.

F11. VDFs are exotic

"A class-group VDF with Wesolowski proofs in a consensus-critical path, in a project with no cryptographer. Chia needed years and still got timelord ASICs."

Status: Answered by design, with the dependency conceded.

Answer: The VDF is used for one thing: making the hourly program unknowable within the roughly two seconds a miner has to decide whether to publish a block, closing a withhold-or-publish grind the review measured at about 130 to 1 for a 30% miner. The VDF input is a certified checkpoint at least one epoch before the epoch starts, so honest nodes have about 50 minutes of slack to evaluate a 10-minute VDF, and an evaluator 300x faster than reference would still be needed to beat the two-second decision window. Chia has run class-group VDFs in production since 2021, with faster hardware evaluators existing and not breaking it (approximate, from memory). The design doc lists the VDF as a new dependency and ships the evaluator in every node. The grinding simulation with and without the VDF is scheduled before gate 3.

Evidence: design doc Finality v2, Lottery seeds items 1 and 2, Residual risks bullet 5, "Three experiments before gate 3".

F12. Nothing outside the chain, except

"No Bitcoin anchoring, you say. You depend on Succinct's SP1, BLS12-381, a class-group VDF, NVIDIA's compiler and a fork of Kaspa's node."

Status: Answered by design.

Answer: Those are code dependencies, chosen because each is open source and replaceable, and none is another chain's consensus. "Nothing outside Igneum" in the litepaper means no other chain's state is read, and the sentence should be scoped that way. A soundness bug in the proof system is the one dependency that can hurt consensus; see P7.

Evidence: CLAUDE.md design paragraph; design doc "Decided" paragraph.

F13. Why prove every block if every node executes anyway

"Every node runs the transactions natively, so full nodes do not need the proof. You pay 20% of emission for a proof that your own nodes ignore."

Status: Answered by design.

Answer: Full nodes execute natively so users see state in about a second. The proof is for everyone who is not a full node: light clients, bridges, exchanges syncing from a checkpoint, and the external market, which needs a standing prover population with hardware already running. It is also what lets a new node sync from a proven checkpoint instead of replaying history. The 20% is paid for capacity as much as for the proofs themselves, and the litepaper should say that.

Evidence: design doc, "Proving speed on consumer GPUs" risk item and "Who needs" paragraph.

---

3. Proving and the zkEVM

P1. The 20-second shard is a number you made up

"'A 12 GB card proves one shard in about 20 seconds, measured on a mid-range card before launch.' So it is not measured. You wrote a target in the past tense."

Status: Conceded, not yet stated in the litepaper.

Answer: Correct. It is the phase 2 gate, to be measured on a 3060-class card, and no SP1 shard has been proven on any card in this repository yet. The sentence must be rewritten as a target.

Evidence: site/journey.json phase 2 gate. Measurement: not yet. Fix: overclaims list, item 27.

Cross-reference (external review, 3 October 2026, night): the phase 2 gate now carries an end-to-end acceptance standard, P16 and O-7.1; design R2's halve-and-re-measure fallback is no longer a pass.

P2. Real-time proving needs a hundred GPUs per block

"Succinct needed on the order of 160 consumer GPUs to prove Ethereum blocks in real time in 2025. You have one block a second. Your gas throughput will be a rounding error or your proofs will fall behind."

Status: Conceded, stated in the litepaper, with the dial explained.

Answer: True, and the litepaper says a full block needs a cluster of 100 to 200 consumer GPUs, approximate. Igneum's gas budget per block is a consensus constant set from measured prover throughput, so throughput is a function of how many cards are proving. With few provers at launch the chain carries little gas. The design treats that as a dial, not a failure, and the litepaper should publish the launch budget as a formula (cards proving times shards per card per minute) so builders can see it. Proving costs have fallen roughly an order of magnitude a year for three years, approximate, and the interface is swappable.

Evidence: design doc "Unit economics of a proof"; litepaper "What Igneum does not claim" item 1.

P3. A phone verifies in milliseconds is a SNARK-wrapper claim

"Hash-based STARK proofs are hundreds of kilobytes and take real work to verify. Milliseconds on a phone means a Groth16 or Plonk wrapper, and wrapping SP1 proofs needs a big machine for minutes."

Status: Open, experiment scheduled.

Answer: Correct. The light-client proof is the aggregated block proof wrapped once into a small curve-based proof, and wrapping is the aggregator's job. The cost and latency of that wrapper on consumer hardware is unmeasured and belongs in the phase 2 benchmark alongside the shard time. Until measured, the litepaper should say "wrapped for light clients".

Evidence: not yet. Fix: overclaims list, item 25.

P4. Trustless light clients need a consensus proof you do not have

"Checking 'one proof and one locked checkpoint' means verifying a BLS certificate against two thirds of active 30-day weight. Computing that weight needs 30 days of headers. Your own review scoped the consensus proof as phase two. The litepaper sells it at launch."

Status: Conceded, stated in the design doc, overclaimed in the litepaper.

Answer: Correct. The hostile review table says "One-proof light clients and committee-free bridges need a consensus proof, not just an execution proof. Scoped as phase two with honest cost." At launch a light client trusts a recent certificate it is given (as Ethereum light clients trust a sync committee checkpoint) and verifies execution from there. The firsts table row and the "Trustless light clients" paragraph must be re-scoped.

Evidence: design doc, hostile review table rows "Slashing an external prover" and "One-proof light clients". Fix: overclaims list, items 9 and 38.

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: 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".

Evidence: design doc, hostile review table row "EVM semantics on a DAG". Fix: overclaims list, items 35 and 36.

P6. The proving market is tiny

"Total rollup proving spend is low millions a year and Boundless, Succinct and the rollups' own clusters already fight for it. 'Igneum gives the proving market its cheapest supplier' is a line for miners who have not seen the numbers."

Status: Conceded, stated in the litepaper, with one overclaim to fix.

Answer: The litepaper says the market is small three times and calls external proving "upside, not a promise". The design doc estimates total spend at low millions of dollars a year, approximate, and says a GPU fleet of any size swamps it. Igneum does not depend on it: in-chain proving is paid from emission and gas regardless. The overclaim is "cheapest supplier": Boundless already admits home GPUs, and Succinct's and Boundless's provers must stake their own tokens, which an Igneum miner would also have to hold to bid there. "Marginal cost close to power" is defensible; "cheapest" is not.

Evidence: design doc "Market size, honestly" and "Existing prover networks" table (labelled from memory). Fix: overclaims list, items 12 and 58.

P7. A soundness bug in SP1 is a consensus failure

"SP1 has had disclosed soundness bugs. On Igneum a forged proof means 'a block with a wrong state cannot exist' becomes a wrong state that exists, and your upgrade path is a 90% miner vote with three months' notice."

Status: Conceded, not yet stated in the litepaper.

Answer: Correct that a live soundness bug cannot wait for a three-month release train. Full nodes execute natively, so a forged proof disagreeing with native execution is detectable by every full node, and the rule must be that a full node rejects a proof whose claimed state root differs from its own execution. That turns a soundness bug into a light-client problem rather than a chain split, and it must be written into the spec. The emergency path for the proof system version is a human one and the litepaper should say so, alongside the "nothing needs a human" sentence.

Evidence: design doc "Proof system churn" risk item. Rule: not yet. Fix: overclaims list, items 3 and 26.

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: 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.

Evidence: design doc "Proving speed on consumer GPUs" risk item and Finality v2 "Fees". Rule: not yet. Cross-reference (round 3, 3 October 2026): F17 reopened the per-key draw of spec 7.2, which a key-splitter sweeps by count; spec 7.2 step 2 was rewritten the same evening to draw by weight (blue blocks drawn uniformly from the window), so this entry stays closed.

P9. Shard griefing

"Claim a shard with a small bond and never prove it. Repeat. Finality waits on you."

Status: Answered by design, parameters open.

Answer: The bond is slashed and the shard reopens; the proving fee rises until someone proves it (security model table, "Prover cartel withholding proofs"). The open parameters are the bond size, the timeout, and whether an un-proven block delays only the proof (it does; execution and the 30-second lock do not wait for the proof). Set in phase 4.

Evidence: design doc, Security model table row 3.

P10. External jobs are paid off-chain, so where is the burn

"The Economics section says every outside customer pays in IGN and part is burned. The miner section says rollups pay in their own money and the income does not move with the IGN price. Both cannot be true."

Status: Conceded, contradiction to fix.

Answer: The litepaper contradicts itself. The design is: at launch external jobs are paid on the customer's chain, in the customer's currency, to a payout contract keyed by miner address, because Igneum cannot yet see Ethereum. The 10% burn in IGN applies when the job market settles on Igneum, which needs the proof bridge. The Economics section must say so.

Evidence: design doc "The first six months" risk item and hostile review table row "Slashing an external prover". Fix: overclaims list, item 55.

---

4. Economics and the coin

E1. Hard cap plus burn is a security budget cliff

"Monero chose tail emission so miners are paid for ever. You chose a 4 billion cap, halvings every two years, and you burn fees on top. By year twelve emission is under 1% a year and shrinking. Who pays for hashrate then?"

Status: Conceded by decision, stated in the design doc.

Answer: True, and the design doc records the choice: "A 1% tail is the Monero model and the safer choice for security on its own." The argument for the cap is that Igneum miners keep earning from in-chain proving fees and external jobs after emission fades, which Monero's miners cannot, and that a hard cap is the number miners trust. Emission in years 9 and 10 is 62.5 million IGN a year, 1.6% of supply; in years 11 and 12 it is 31.25 million, 0.8%. Bitcoin's inflation at its own year 10 was about 3.7%, approximate. Whether fee income replaces emission is unknowable today. A tail could be added by a 90% miner-signalled upgrade; nothing in the design prevents it.

Evidence: design doc "Decision: hard cap". Litepaper: "Supply" section states the cap, not the trade-off.

Cross-reference (external review, 3 October 2026, night): the budget through halvings at low fees, no demand and a flat price is modelled under E15, O-5.11.

E2. Half the coins in two years is an insider schedule

"Nearly a quarter of supply in year one, half by year two, founders mining from genesis with the software they wrote and a month's head start on the benchmark. That is a premine with a GPU."

Status: Answered by design, with the founder's edge conceded.

Answer: The schedule (1 billion a year halving every two years, 30-day ramp from 10% to 100%) is public, fixed at genesis and the same for every miner. The founders' only edge is familiarity with software that is public a month before launch with pools live on testnet. The founders mine from disclosed addresses, which nobody else is asked to do. What this does not answer is that early adopters of any fair launch hold a disproportionate share, as on Bitcoin and Kaspa. The litepaper says "the people who show up early get the most", which is both true and a sentence a lawyer will read twice (see L2).

Evidence: litepaper "Supply" and "Fair launch, announced".

E3. The 20% developer share enables wash gas

"Deploy a contract, spam it with your own transactions, collect 20% of your own priority fee back. If you also mine the block you collect all of it."

Status: Answered by design, with a metrics caveat.

Answer: The base fee is burned in full, so every wash transaction loses its whole base fee. Of the priority fee a developer alone gets back 20% and loses 80%. A developer who also mines the block including its own transaction gets 80% plus 20%, the whole priority fee, and still loses the full base fee in both gas dimensions. Wash gas is a guaranteed loss. What it can do is inflate an app's "gas earned" figure on a leaderboard at a cost of 20% of the priority fee, so no explorer ranking should be built on raw developer share without a self-dealing filter. Attribution is per call frame by gas consumed, with factory-deployed contracts inheriting the factory's registration.

Evidence: design doc Finality v2 "Fees"; litepaper "What a builder gets for being early".

E4. 5% of gas to the dev fund is a tax

"You say 100% of emission to miners, then take 5% of gas. Users are taxed instead."

Status: Closed by removal, 3 October 2026.

Answer: There is no development fund. The 5% of the priority fee and 5% of external job fees that earlier drafts routed to a fund contract under 60% miner signalling were removed on 3 October 2026. A switch that routes money to an address somebody controls is the first thing a critic points at, however it is gated, so the protocol carries no fee to any team, foundation or fund. The priority fee now splits 80% to the miner and provers of the block and 20% to the apps whose code ran; external jobs pay 90% to the provers who delivered and burn 10%. The team earns in the open by running provers in the job market and by the app share on the contracts it deploys. A grant mechanism can be added by miner signalling later if the community wants one.

Evidence: spec section 5.5; design doc "No development fund, so nothing to fight over". Fix: none outstanding; overclaims item 53 closed.

E5. "Not one coin to a founder" is false

"The official miner carries a 1% dev fee to the founder's company. That is 1% of all hashrate paid to one company for as long as miners run it, which is a founder allocation with better PR."

Status: Conceded, partly stated, homepage overclaims.

Answer: Correct in substance. The litepaper discloses the 1% dev fee and says any other client is welcome. The homepage says "Not one coin to a founder, a fund or a stake", which is true of emission and false of the dev fee. There is no development fund (removed 3 October 2026) and no protocol fee to the team; the team earns from the client dev fee, its pool, its provers in the job market and the app share on contracts it deploys, all in the open. All of that must be in one place in the litepaper under a heading a critic can quote.

Evidence: design doc "No development fund, so nothing to fight over". Fix: overclaims list, item 63.

E6. Two-year halvings bleed hashrate

"Every GPU coin that halved fast lost its miners at the second halving. You halve every two years for ever."

Status: Conceded, no experiment possible.

Answer: True that a halving halves emission income overnight if price and fees do nothing. The schedule was chosen for the cap and for front-loading the fair launch. Kaspa's smooth monthly reduction is a precedent for a steep schedule that kept hashrate while price rose (approximate). Igneum's in-chain proving pay does not halve with emission since it is paid from gas as well. Nothing here is a measurement; it is a bet, and the litepaper should present it as one.

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: 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.

Evidence: design doc, hostile review table row "One-proof light clients and committee-free bridges". Fix: overclaims list, item 71.

E8. Founders seeding the DEX is market making by insiders

"The founders seed the DEX with their own mined coins. That sets the first price and they hold the first liquidity."

Status: Conceded, stated.

Answer: True and stated in the litepaper. Mined coins are the only coins the founders can hold. The addresses are disclosed, so the seeding is visible. Whether to do it at all is a question for counsel (L1, L2).

Evidence: litepaper "Liquidity from the people who are there".

---

5. Governance and the founders

G1. No cryptography team

"One founder. The design doc says phases one and two 'need one cryptographer or proof-systems engineer' and none is named. The reviewers for gate 3 are 'named' in the litepaper and nobody is named."

Status: Conceded, not yet stated in the litepaper.

Answer: Correct. No cryptographer has been hired. The litepaper's gate 3 refers to "named reviewers" who do not yet exist. The honest text is: the specification is written for external review; reviewers will be named and paid before gate 3; until then every security claim here is a design claim. The hostile reviews so far were run by the founder with AI assistance (G2).

Evidence: design doc "Team" paragraph. Fix: overclaims list, item 50.

G2. An AI designed this

"The repo has .claude/agents/cryptographer.md. The commits are co-authored by a language model. The 'hostile review' was a chatbot role-playing a Kaspa researcher."

Status: Conceded, not yet stated in the litepaper.

Answer: True. The design, the reviews, the prototype code, the simulator and this ledger were produced by the founder working with AI models, and the commit history says so. What that does and does not mean: the measurements are measurements, reproducible from the commands in the logs; the simulation is code anyone can run; the design claims are design claims until external humans with names have tried to break them. The litepaper should disclose the method in one sentence and let the measurements stand on their own.

Evidence: .claude/agents/, commit trailers. Fix: add a disclosure sentence (overclaims list, item 73).

G3. Who are you

"Anonymous founder, GoDaddy domains, a Vercel site, a litepaper dated the same day as five 'milestones'. This is a template."

Status: Conceded, team page deferred by decision.

Answer: The founder's name is on every commit. The litepaper defers the team page to public testnet by decision, with disclosed mining addresses at genesis. There are no coins to sell and no sale planned, so there is nothing to run away with before block one. The five log entries dated 3 October 2026 are day one of the project and should be presented as that.

Evidence: design doc, decisions table row "Who are you?". Journey: site/journey.json.

G4. No admin keys, except in everything that matters

"'There are no admin keys.' The DEX, the lending market, the bridge and the dev fund contract all ship from your team. Bridges are where the admin keys live."

Status: Conceded, wording fix needed.

Answer: Correct. Consensus has no admin keys. The genesis apps are contracts and each will have an upgrade policy; the bridge's is the one that matters, and if it starts as a committee bridge (E7) it has keys by definition. The development fund contract named in the quote no longer exists: the fund was removed on 3 October 2026. The litepaper's sentence must be scoped to consensus and each genesis contract must publish its key policy before launch.

Evidence: litepaper "Governance". Fix: overclaims list, item 46.

G5. No multi-client

"One node implementation, a rusty-kaspa fork with a zkEVM bolted on. A bug is a chain halt. Ethereum learned this in 2016."

Status: Conceded, stated in the litepaper.

Answer: True at launch. The litepaper names a second independent client as the first priority after launch; there is no development fund to pay for it (removed 3 October 2026), so whoever builds it pays for it. The finality module is separable and the chain runs on plain GHOSTDAG without it, which contains one class of bug. A second client before mainnet is not in the 13-month plan and the litepaper should not imply it is.

Evidence: litepaper "Governance", last bullet.

G6. Stratum v2 does not make pools unable to censor

"Job declaration in Stratum v2 is optional for pools. 'Pools cannot censor' is false. And the vote key stays with the pool regardless."

Status: Conceded, wording fix needed.

Answer: Correct. Stratum v2 job declaration lets a hasher choose transactions when its pool supports it, and the official pool software will support it. Pools can still decline, and the vote key in the header is the pool's. The sentence becomes "Pools can be bypassed on transaction choice" with the vote-key caveat.

Evidence: none in repository. Fix: overclaims list, item 45.

Cross-reference (external review, 3 October 2026, night): whether members use declared templates is measured under O-9.5; concentration reporting is X14.

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: 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.

Evidence: not yet.

G8. Governance by hashrate is governance by two pools

"90% of blocks to activate an upgrade, 60% to spend the fund. Two pools decide both."

Status: Conceded, stated in the design doc.

Answer: True in the same way it is true on Bitcoin, where miner signalling activated SegWit and Taproot. The thresholds are high so that nothing passes without near-consensus. Since 3 October 2026 there is no fund to spend: the 60% threshold applies only to parameters that the genesis rules leave to miners, and 90% to upgrades. The litepaper should name pool concentration as the governance risk rather than imply every miner votes.

Evidence: design doc Finality v2, Residual risks bullet 3.

---

6. Comparisons

C1. vs Monero: GPUs were excluded on purpose

"RandomX runs badly on GPUs because a GPU is already specialised hardware that most people do not own. 'Monero's idea, finished for GPUs' misses the point of Monero's idea."

Status: Answered by design.

Answer: Monero chose the CPU for egalitarian reasons and accepted botnets as the price. Igneum chooses the GPU because the thesis is paid proving, which CPUs cannot do, and refuses a CPU lane because of botnets. It is a different trade, and the litepaper should say "Monero's technique, applied to GPUs" rather than "finished".

Evidence: litepaper "For miners", hardware paragraph. Wording: overclaims list, item 74.

C2. vs Monero: "no chip in seven years" is not proof

"Absence of a public RandomX ASIC is not evidence one cannot exist. Monero is also a small prize."

Status: Conceded, label needed.

Answer: True. "No chip publicly shipped, approximate" is the defensible phrasing. The argument from Monero is precedent, not proof, and the bounty exists because precedent is not proof.

Evidence: none. Fix: overclaims list, item 17.

C3. vs Kaspa: you misrepresent them

"Kaspa never claimed ASIC resistance and did not get 'captured'. It also has 10 bps in production and a GHOSTDAG you are forking. Say thank you."

Status: Conceded, wording fix.

Answer: Correct on both counts. kHeavyHash was built to be hardware-friendly and Kaspa's ASIC transition was expected by its community (approximate). The litepaper's "captured by specialised chips within two years, as Kaspa was" and "Kaspa's fair launch, with no utility" are unfair and will be rewritten. Igneum forks rusty-kaspa and borrows the block-rate step plan from Crescendo; the litepaper should credit both.

Evidence: none in repository; vendor/rusty-kaspa to be cloned and cited. Fix: overclaims list, items 8, 11, 29 and 49.

C4. vs Kaspa: a finality overlay changes GHOSTDAG's guarantees

"GHOSTDAG's safety comes from blue work. A certificate that overrides blue work and a pruning point that never passes the latest lock are changes to the security model, not features on top."

Status: Open, experiment scheduled.

Answer: True. Among candidate tips (those passing through every certified checkpoint) GHOSTDAG selects by blue work under the 3,600-second merge-depth bound; a certified checkpoint removes other tips from candidacy. That is a change, and its interaction with pruning, with red blocks in the attacker's weight and with latency is exactly what the gate 3 devnet measures. The module is separable so GHOSTDAG alone remains the fallback.

Evidence: design doc Finality v2, Fork choice items 1 to 4; sim/results.md final section.

C5. vs Ethereum: you compare inclusion to finality

"'Included in about one second, against twelve on Ethereum.' Inclusion in a DAG is not confirmation. Ethereum's twelve seconds is a slot, its finality is about thirteen minutes, and you compare your two-minute lock to that as if a two-minute lock by a pool committee were the same thing."

Status: Conceded, wording fix.

Answer: The numbers are approximately right and the framing is loose. Inclusion is not confirmation on either chain; Igneum's two-minute lock is a committee-of-miners finality with the limits in F4 and F6; Ethereum's finality is economic with slashing. The sentence should state both sides' mechanism, not just the minutes.

Evidence: litepaper "Speed". Fix: overclaims list, item 30.

C6. vs Ethereum: every one of your components is a research project

"A random-program hash with no analysis, a VDF, BLS sortition, STARK recursion on consumer cards, a 2D fee market, a DAG with EVM semantics. Ethereum has a thousand researchers and shipped these one at a time over a decade."

Status: Conceded, not yet stated.

Answer: True. Each component has a precedent in production somewhere (RandomX, Chia, Algorand and Ethereum for BLS and VRF, SP1, Kaspa) and no chain combines them. That is the risk the gates exist to price. The roadmap's four gates are kill points and the litepaper says so; it should also say the combination is the risk.

Evidence: litepaper "Roadmap".

C7. vs Bitcoin: hashrate that follows price is the design, you penalise it

"Bitcoin's miners come and go with price and the chain is fine. Your 30-day weight under-weights every honest newcomer for a month and lets old miners lock alone for 20 days after a doubling."

Status: Conceded, stated in the simulation.

Answer: Correct. Table D: a new honest cohort equal to the old one reaches 0.9x its hashrate share on day 28 to 31, and the old cohort can lock alone for 20 to 23 days. The design accepts this because a doubling overnight is indistinguishable from a rental burst. Rewards are unaffected; only the vote waits. The litepaper should say "a new miner votes after a month".

Evidence: sim/results.md table D.

C8. vs Ergo, Ravencoin, Conflux: GPU mining has a home

"Ergo has been GPU-mined since 2019 with no ASIC. Ravencoin runs KAWPOW. Conflux is a GPU-mined DAG with an EVM space since 2020. 'GPU mining has no home' is false and your firsts table skips all three."

Status: Conceded, not yet stated.

Answer: Correct. Those chains exist and run on GPUs today (approximate). The accurate claim is that GPU mining lost its Ethereum-scale home in 2022 and that none of those chains proves its blocks or sells proving. Conflux in particular (GPU, DAG, EVM) belongs in the firsts table as the closest precedent for the combination, and the litepaper must name it.

Evidence: none in repository; to be cited from their repositories. Fix: overclaims list, items 10 and 11.

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: 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.

Evidence: design doc "Existing prover networks" table, Aleo row.

C10. vs Boundless and Succinct: you cannot bid there without their tokens

"'The Igneum miner client also bids on other proving networks.' Boundless provers post collateral in ZKC and Succinct provers stake PROVE. Your miner needs to buy their tokens to bid. And they already have home GPUs, so 'cheapest supplier' is false."

Status: Conceded, wording fix.

Answer: Correct on both points (approximate, from memory; verify against their current docs). The client can bid where a miner chooses to hold the collateral; the litepaper should not imply free entry, and "cheapest supplier" becomes "a supplier whose marginal cost is close to power".

Evidence: design doc "Existing prover networks" table, labelled approximate. Fix: overclaims list, items 12 and 58.

C11. vs everyone: "firsts" that are not

"'A chain your browser verifies by itself' is phase two by your own doc. 'The GPU version never shipped' ignores KAWPOW. 'Finality immune to rentals' is 'not moved by rentals'. Three of your six firsts are wrong on day one."

Status: Conceded, table to rewrite.

Answer: Correct. The firsts table is rewritten in the overclaims list: each row states the closest precedent accurately, including ProgPoW/KAWPOW and Conflux, and marks the light-client row as phase two. The claim that stands is that no chain combines GPU mining, per-block ZK proofs, an EVM and a mining-weighted finality overlay, and the table should say "we know of none" and invite correction.

Evidence: this ledger. Fix: overclaims list, items 4 to 9.

C12. vs Monero: you borrowed the hash idea and left out the point

"Monero's idea is privacy. You took RandomX and shipped a transparent ledger. Calling it 'Monero's idea, finished' is cheek."

Status: Answered by design.

Answer: Transactions on Igneum are public, as on Ethereum. Privacy features and shielded pools were considered and rejected on 3 October 2026, because the chain's purpose is an EVM whose state is proven and sold to other chains, which needs public state. The litepaper borrows one technique from Monero, the random program, and should say so plainly rather than "Monero's idea".

Evidence: CLAUDE.md rules (privacy rejected). Fix: overclaims list, item 68.

---

7. Legal and regulatory

L1. It is a security under Howey

"A founder's company earns a dev fee, runs a pool and a proving business, seeds the DEX, pays 'launch grants', and the roadmap ends in 'exchange listings after'. Expectation of profit from the efforts of others, in writing."

Status: Open, counsel not yet engaged.

Answer: There is no sale, no premine, no allocation and no promise of return, and nothing in consensus is controlled by the team and no protocol fee reaches it (the development fund was removed on 3 October 2026), which is the structure that regulators have treated most favourably (approximate: compare the SEC's own framework on sufficiently decentralised networks and MiCA's exemption for tokens created automatically as a reward for maintaining a distributed ledger, approximate quotation). The weak points a lawyer will circle are the ones quoted: founder-run pool and proving business, founder-seeded DEX, launch grants, and the phrase "exchange listings after". None is in consensus; all are promotional. The litepaper must drop the listing sentence and counsel must review the founder-business paragraph before v0.2. The legal entity is "offshore, parked" in the design doc, which is not an answer.

Evidence: design doc "Legal" paragraph. Fix: overclaims list, items 75 and 76.

L2. Financial promotion rules

"Several jurisdictions now treat a cryptoasset promotion to their consumers as regulated: the UK since October 2023 needs an authorised approver, the EU under MiCA has its own marketing rules, the US has the Howey test. 'The people who show up early get the most' on a domain you own is a promotion wherever the reader sits."

Status: Open, counsel not yet engaged.

Answer: A litepaper describing how to mine a coin that does not exist is arguably not an invitation to engage in investment activity, and the regime has carve-outs for information that is not an inducement (approximate; this needs an opinion from counsel in the jurisdiction the project is established in, which is offshore and not yet named). Sentences that read as inducements to acquire ("show up early get the most", "half of all supply in the first two years") should be rewritten as schedule facts before v0.2. Country-code domains such as igneum.co.uk redirect to igneum.network and carry no separate content.

Evidence: none. Fix: overclaims list, item 77.

L3. GoDaddy domains are a seizure risk

"Fifteen domains at a US registrar on US nameservers behind a US host. One court order and igneum.network is a parking page."

Status: Conceded, mitigation scheduled.

Answer: True. GoDaddy and Vercel are both US companies and have both complied with takedowns. Mitigations: an ENS or equivalent name and an IPFS mirror of the site and litepaper, the site's content hash published in the repository and in the genesis block, at least one non-US registrar for a second TLD, and the chain itself never depending on any domain (seed nodes are addresses in the client, not DNS only). Phase 5.

Evidence: CLAUDE.md "Domains". Mitigation: not yet.

L4. Paying testnet miners real money is a payment before launch

"'Testnet miners are paid real money for real proofs from phase five.' That is a business paying contractors in crypto across borders with no entity."

Status: Open.

Answer: Correct that it needs an entity, terms and tax treatment before it happens. The payments come from the customer rollup on its own chain, not from Igneum, but the arrangement is organised by the project. Counsel before phase 5.

Evidence: design doc "The first six months".

L5. Trademark

"Igneum. Have you checked EUIPO, USPTO and the UK IPO? There is no evidence you did."

Status: Open.

Answer: No clearance search is recorded in the repository. One is required before the name is used commercially, in all three registers and in Nice classes 9, 36 and 42, approximate. Until then the name is provisional and the litepaper should not claim otherwise.

Evidence: none.

L6. A permissionless job market paid in dollars is money transmission

"Rollups pay dollars for proofs through your contract and your client picks the winner."

Status: Answered by design.

Answer: At launch jobs are paid on the customer's chain, in the customer's asset, by the customer's contract, to the prover's address; Igneum operates no custody and takes no cut off-chain. When the market settles on Igneum the fee split is consensus, not a company. Counsel confirms before phase 4.

Evidence: design doc "The first six months".

---

8. Launch and community

X1. "Reproducible from the repository" and the repository is private

"Your site links to github.com/igneum-network/igneum. It 404s. 'Every number above is measured, published, and reproducible from the repository' is false today."

Status: Conceded, fix now.

Answer: Correct. Either the repository goes public with the litepaper or the sentence and the GitHub link come off the site until January 2027. Publishing the bench logs, the simulator and the test report with the litepaper is the cheaper fix and the honest one.

Evidence: site/index.html footer link; CLAUDE.md says private. Fix: overclaims list, item 22.

Cross-reference (external review, 3 October 2026, night): publishing the harnesses, vectors, simulators and spec now, labelled experimental, is G11, a decision for the project lead.

X2. "Get the miner" with no miner

"A big button that says 'Get the miner' on a chain with no miner, no testnet and no benchmark. Vapourware CTA."

Status: Conceded, fix now.

Answer: Correct. The button should say what exists: "Benchmark: January 2027".

Evidence: site/index.html. Fix: overclaims list, item 61.

X3. "Proven by fire" when nothing has run

"Tagline: Proven by fire. Status: pre-specification, pre-testnet. 'Watch the chain prove itself' with nothing on the page."

Status: Conceded in part, labelled.

Answer: The tagline plays on "proven" as in ZK proofs and "cupel". The homepage marks every live panel "PREVIEW", "prototype" or "at testnet", which is honest. The sentence "All of it will be on this page, live" is a promise about a future testnet and should say when. The tagline stays; nothing in the ledger depends on it.

Evidence: site/index.html. Fix: overclaims list, item 62.

X4. Thirteen months with one founder

"Kaspa took years with a research team. You schedule a spec, a devnet, a finality review, a job market, a one-click app, pools, a rollup customer and a mainnet in thirteen months."

Status: Conceded, stated.

Answer: The roadmap is aggressive and every phase is a gate that can repeat or stop the project, which the litepaper says. The design doc budgets six people at peak and none are hired. The honest addition: dates slip, gates do not.

Evidence: litepaper "Roadmap"; design doc "Team".

X5. 1,000 independent miners is a Sybil number

"Your testnet gate is 1,000 independent miners for 30 days. One person with a script is 1,000 miners."

Status: Conceded, measurement to define.

Answer: Correct. "Independent" needs a definition that can be measured: distinct ASNs, distinct hardware fingerprints from the benchmark, or signed attestations from pool operators. Defined in phase 4, before the gate is tested.

Evidence: site/journey.json phase 5 gate.

Cross-reference (external review, 3 October 2026, night): the definition and the four concentration metrics are X14, O-X.1.

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: 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.

Evidence: not yet.

X7. No community exists

"No Discord, no forum, no mailing list, no contact address on the site, and a ledger that says 'criticisms can be submitted'. Where?"

Status: Conceded, fix now.

Answer: Correct. The site needs a contact route before the litepaper is shared, and the repository needs to be public or a public issue tracker needs to exist. Until then this ledger's submission line points at a route that does not exist.

Evidence: site/index.html (no contact route). Fix: overclaims list, item 78.

X8. Exchange listings as a roadmap item

"'Mainnet fair launch: Genesis with no premine, 30-day ramp, exchange listings after.' You put listings in the roadmap."

Status: Conceded, fix now.

Answer: Correct. No listing is arranged, promised or sought by the project. The phrase comes off the roadmap and the homepage journey.

Evidence: litepaper "Roadmap", site/journey.json. Fix: overclaims list, item 75.

X9. Launch hashrate will be trivial

"Day one of a GPU coin with a 10% emission ramp is a few hundred cards. Anyone with a cloud account out-mines it for the price of lunch, and your finality has no history to lean on."

Status: Conceded, stated in part; see F1.

Answer: True. The lottery is as attackable as any new proof-of-work chain for as long as it is small, and finality adds nothing until the window fills. The protections are the one-hour merge-depth bound, no listings before launch, and the proposed rule that no certificate forms until the window has 30 days of history. The litepaper must say that the first month is proof of work only.

Evidence: sim/results.md table A (full weight only from day 32 to 41 from zero history). Fix: overclaims list, item 31.

X10. Five milestones in one day

"Your Journey log shows five entries, all dated 3 October 2026. That is one day's work presented as a history."

Status: Conceded, label needed.

Answer: It is one day's work, and the log says the date on every line. The label "Day one" above the entries would remove the impression of theatre.

Evidence: site/journey.json.

---

Count by status

Status	Count	Entries
Answered with evidence	2	M8, M10
Answered by design	13	M3, M12, F4, F9, F11, F12, F13, P9, E2, E3, C1, C12, L6
Open, experiment or decision scheduled	9	M1, M11, F7, P3, C4, L1, L2, L4, L5
Fixed (4 October 2026, generator version 2)	2	M5, M6
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

Several entries carry two statuses; the table counts each entry once by its leading status. Total entries: 80.

---

Overclaims to remove from public text now

Each item quotes the current text exactly and gives the replacement. Sources: site/litepaper.html (LP), site/index.html (HP), site/journey.json (J).

1. LP cover: "A proof-of-work chain whose miners also prove every block, run Ethereum's apps, and built so no chip can ever take your place." Replace with: "A proof-of-work chain whose miners also prove every block, run Ethereum's apps, and are protected from specialised chips by a program that changes every hour."

2. LP abstract: "Mining stays open to anyone with a GPU because the mining program itself changes every hour, so there is nothing for a specialised chip to be built for." Replace with: "Mining stays open to anyone with a GPU because the mining program changes every hour, so a chip built for one program is useless for the next, and a chip for the whole program space is a GPU without the graphics parts."

3. LP abstract: "Nothing in it ever needs a human to keep it that way." Replace with: "No scheduled human release is needed to keep it that way. Writing new code, including an emergency fix to the proof system, is the one thing that takes a person, and it activates only on miner signalling."

4. LP firsts: "Every piece of Igneum has a precedent somewhere. The combination has none, and six of the pieces are firsts on their own." Replace with: "Every piece of Igneum has a precedent somewhere. We know of no chain that combines them. The table names the closest precedent for each piece and will be corrected when shown wrong."

5. LP firsts row: "A mining program that regenerates itself, for GPUs | RandomX does it for CPUs on Monero, since 2019 | The GPU version. Designed, discussed, never shipped" Replace with: "A mining program that regenerates itself, for GPUs | RandomX on Monero since 2019 for CPUs. ProgPoW, as KAWPOW on Ravencoin since 2020, changes its maths sequence every few blocks on GPUs | A full kernel per hour, a daily dataset from a 256 MB cache, a verifiable delay before the seed, and era draws from a genesis reserve"

6. LP firsts row: "Ethereum apps on a GPU-mined chain whose state cannot be wrong" Replace with: "Ethereum apps on a GPU-mined chain whose state is proven every block"

7. LP firsts row: "Finality held by miners and immune to hour-long rentals" Replace with: "Finality held by miners and not moved by hour-long rentals"

8. LP firsts row: "Kaspa's fair launch, with no utility." Replace with: "Kaspa's fair launch."

9. LP firsts row: "A chain your browser verifies by itself | Light clients trust a committee | One proof plus one locked checkpoint, no trust" Replace with: "A chain your browser verifies by itself (phase two) | Light clients trust a committee | One execution proof plus one locked checkpoint at launch; a consensus proof that makes the checkpoint self-verifying is phase two"

10. LP: "GPU mining lost its home in 2022. Igneum is the first chain built so that it can never be taken away again: not by a chip, not by a merge to proof of stake, not by a rental attack, and not by a foundation." Replace with: "GPU mining lost its largest home in 2022. Igneum is built to make it hard to take away: by a chip, by a merge to proof of stake, by a rental attack, or by a foundation."

11. LP: "Every chain that tried to take it in since has either been captured by specialised chips within two years, as Kaspa was, or has stayed too small to pay the power bill." Replace with: "Since then the GPU chains have gone two ways. Chips arrived, as on Kaspa, whose hash was designed to welcome them. Or the chain stayed small: Ergo, Ravencoin and Conflux still mine on GPUs at a fraction of the 2022 fleet, approximate."

12. LP: "It gives the proving market its cheapest supplier." Replace with: "It gives the proving market a supplier whose marginal cost is close to power."

13. LP glance: "New program every hour, so only a GPU runs it well" Replace with: "New program every hour, so a chip for last hour's program is useless"

14. LP mining: "random reads over a multi-gigabyte dataset that changes daily, so the program is bound by memory bandwidth." Replace with: "random reads over a multi-gigabyte dataset that changes daily, so the program is bound by random memory access. Measured: an RTX 5090 hashes at 95 GB/s of useful 4-byte loads against 1,638 GB/s of sequential writes."

15. LP mining: "The memory footprint and instruction count are fixed and only the maths sequence is random, so no hour favours one vendor's cards and nobody gains by grinding the seed." Replace with: "The memory footprint, instruction count and load count are fixed by the generator and only the maths sequence is random, so no hour favours one vendor's cards. The prototype does not yet fix the load count (40 to 232 per hash across 10,000 programs); the specification will."

16. LP mining: "checks a hash on an ordinary CPU in about ten milliseconds by simulating one warp" Replace with: "checks a hash on an ordinary CPU in under ten milliseconds by simulating one warp, the gate. Measured at 0.02 ms with the prototype's cheap dataset; the 256 MB cache version is not yet measured."

17. LP mining: "Igneum runs for ever on the generator fixed at genesis, exactly as Monero has run on RandomX since 2019 with no chip built." Replace with: "Igneum runs on the generator fixed at genesis, as Monero has run on RandomX since 2019 with no chip publicly shipped, approximate."

18. LP mining: "A chip that dropped the graphics parts and kept the parallel cores and the memory would gain under 2x, approximate, which is below what pays for a tapeout, and that is the same margin that has protected Monero for seven years." Replace with: "Our target is that a chip that dropped the graphics parts and kept the parallel cores and the memory gains under 2x, below what pays for a tapeout. That is a design target, not a measurement. Ethash chips reached roughly 1.5 to 2x, approximate, and the standing bounty exists to test the target."

19. LP mining: "Igneum is built so that day never comes, and it does not depend on it." Replace with: "Igneum is built to make that day unlikely, and does not depend on avoiding it."

20. LP vs RandomX table: "GPUs. Any card, any vendor. Bit-exact on Apple and NVIDIA, measured" Replace with: "GPUs. Bit-exact on Apple and NVIDIA across two programs, 192 of 192 vectors. AMD and Intel not yet run."

21. LP vs RandomX table: "256 MB cache on a CPU, one warp under 10 ms, the measured gate" Replace with: "256 MB cache on a CPU, one warp under 10 ms, the gate. Not yet measured with the cache."

22. LP vs RandomX table: "Zero years. Every number above is measured, published, and reproducible from the repository" Replace with: "Zero years. Every number above is measured and logged. The repository opens with the January 2027 benchmark." Or open the repository now and keep the sentence.

23. LP: "Measured so far: the same hourly program, generated on an Apple M5 Max, compiled by Apple's Metal and NVIDIA's CUDA on an RTX 5090, produced identical hashes on both, 192 of 192 across two programs. On a 1 GB dataset the 5090 ran at about 228 million hashes a second and the Mac at about 45 million, both bound by random memory access rather than arithmetic." Append: "These are prototype numbers. The prototype dataset is a closed-form function and can be shortcut about 110x by computing items instead of loading them. The 256 MB cache construction replaces it, and the numbers will be re-measured."

24. LP proving: "Proving is the one useful GPU workload that is cheaply verifiable by construction." Replace with: "Proving is a useful GPU workload that is cheaply verifiable by construction."

25. LP proving: "A proof is right or it is not, and a phone can check it in milliseconds." Replace with: "A proof is right or it is not. Wrapped for light clients, a phone checks it in milliseconds; the wrapping cost is a phase two measurement."

26. LP proving: "Because the proof computes the state from the ordered sequence, a block with a wrong state cannot exist." Replace with: "Because the proof computes the state from the ordered sequence, no node accepts a block with a wrong state root, and full nodes also execute natively and reject a proof that disagrees with their own execution."

27. LP proving: "Shard size is set so a 12 GB card proves one shard in about 20 seconds, measured on a mid-range card before launch and raised by schedule as hardware improves." Replace with: "Shard size will be set so a 12 GB card proves one shard in about 20 seconds. That number is the phase two gate and is not yet measured. It rises by schedule as hardware improves."

28. LP proving: "No other proof-of-work chain has a seat in it." Replace with: "We know of no other proof-of-work chain selling proofs to other chains."

29. LP speed: "Igneum orders blocks with GHOSTDAG, the BlockDAG consensus proven on Kaspa." Replace with: "Igneum orders blocks with GHOSTDAG, the BlockDAG consensus Kaspa has run in production since 2021, forked from rusty-kaspa."

30. LP speed: "A transaction is included in about one second, against twelve on Ethereum, and locked in about two minutes against roughly thirteen." Replace with: "A transaction is included in the DAG in about one second (an Ethereum slot is twelve) and locked by miners in about two minutes (Ethereum reaches finality in about thirteen, approximate). Inclusion is not confirmation on either chain, and the two finality mechanisms differ: see the FUD ledger."

31. LP finality: "A locked checkpoint overrides the heaviest chain, so no amount of fresh hashrate can reorganise past it." Replace with: "A locked checkpoint overrides the heaviest chain, so fresh hashrate cannot reorganise past it. Two thirds of 30-day weight can, and the first month of the chain has no history to weigh, so the chain runs on proof of work alone until the window fills."

32. LP finality: "Even an attacker who brought the whole network's hashrate would need ten days of mining in public to hold a third of the weight, and twenty days to hold two thirds." Replace with: "Even an attacker producing every block on the chain, with honest miners gone, would need ten days of mining in public to hold a third of the weight, and twenty to hold two thirds. An attacker matching the honest network needs twenty days for a third and never reaches two thirds."

33. LP finality: "which is the same limit Bitcoin lives with, with a month's warning attached." Keep. Add after it: "Pools carry their hashers' votes, so vote concentration equals pool concentration, and it is public."

34. LP finality: "Only miners who are present count: a key that stops signing drops out of the denominator within two hours, so a silent minority cannot freeze finality and a lock never waits for miners who have left." Append: "The same two hours are the exposure to a partition or an eclipse that stops honest votes without stopping honest blocks. The gate 3 devnet measures it."

35. LP building: "Anything that runs on Ethereum runs on Igneum unchanged. Same Solidity, same bytecode, same wallets, same tools, a different chain id." Replace with: "Ethereum bytecode runs on Igneum. Same Solidity, same wallets, same tools, a different chain id, and block number, timestamp, blockhash, coinbase and prevrandao defined over the ordered sequence. Contracts that depend on those are told what changed, and contracts heavy in pairing or modexp precompiles pay more here because proving cost is metered."

36. LP building: "Three things run on Igneum that run nowhere else." Replace with: "Three things Igneum offers at the base layer that we know no other EVM chain offers."

37. LP building: "No other EVM chain has a prover network in its base layer." Replace with: "We know of no other EVM chain with a prover network in its base layer."

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 (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.

42. LP builders: "The afternoon is the hard part." Delete.

43. LP governance: "Igneum is governed by the people who power it, and by nobody else." Replace with: "Igneum is governed by the hashrate that powers it. Pools carry their hashers' votes, so pool concentration is the governance risk, and it is public."

44. LP governance: "Pools cannot censor. Igneum uses Stratum v2 from day one, so each miner chooses its own transactions even inside a pool." Replace with: "Pools can be bypassed on transaction choice. Igneum ships Stratum v2 job declaration from day one, so a miner chooses its own transactions when its pool supports it. Vote keys stay with the pool."

45. LP governance: "There are no admin keys. Nothing in consensus can be paused, upgraded or reversed by any key." Replace with: "There are no admin keys in consensus. Nothing in consensus can be paused, upgraded or reversed by any key. The genesis apps publish their own key policies before launch; the bridge's is the one to read."

46. LP governance: "Upgrades need a second independent node client, funded from the development fund as its first priority." Replace with: "At launch there is one node client. A second independent client is the first priority after launch, anyone can build it, and it is not in the 13-month plan."

47. LP miners ask: "Kaspa said ASIC resistant too, and IceRiver shipped a chip in eighteen months." Replace with: "Every GPU coin got a chip in the end. Kaspa got one in about eighteen months." And in the answer: "Kaspa's hash was one fixed function, designed to be hardware-friendly, and simple enough to put on silicon."

48. LP miners ask: "Correct, and it is the first thing the external review is paid to break. The specification is public, the review is gate 3 with named reviewers and a bounty" Replace with: "Correct, and it is the first thing the external review will be paid to break. The specification will be public, reviewers will be named and paid before gate 3, and a bounty is attached. Until then every finality claim here is a design claim backed by a simulation without a network in it."

49. LP miners ask: "What Igneum can promise is that its miners have the lowest cost in that market" Replace with: "What Igneum can promise is that its miners' marginal cost in that market is close to power"

50. LP not claimed: "A chip is impossible. No. A chip is pointless, because the target moves before it ships." Replace with: "A chip is impossible. No. A chip is a bad bet, because the target moves before it ships."

51. LP not claimed: "That is harder than attacking Bitcoin, where a majority can reorganise at once" Replace with: "That is a different limit from Bitcoin's, where a majority can reorganise at once: Bitcoin's defence is the cost of the majority, Igneum's is the month in public."

52. LP economics: "It is gas, it is the proving currency, and it is what every outside customer pays in. Part of every payment is burned." Replace with: "It is gas and the proving currency, and part of every payment on Igneum is burned. Outside customers pay in their own currency on their own chain at launch; settlement in IGN with a 10% burn follows when the proof bridge lets Igneum see the payment."

53. LP economics and governance: "5% of gas and 5% of external job fees go to a development fund" Closed by removal, 3 October 2026: there is no development fund. The paragraph now reads "No fund, no foundation, no fee to the team" and the governance bullet names 60% signalling as the tool for parameters that genesis leaves to miners.

54. LP economics: "Nearly a quarter of all supply is mined in the first year and half in the first two, so the people who show up early get the most." Replace with: "Nearly a quarter of all supply is mined in the first year and half in the first two. Emission halves every two years for ever."

55. LP miners: "so Igneum miners have the lowest marginal cost in the proving market and are the last provers to switch off" Replace with: "so Igneum miners' marginal cost in the proving market is close to power, which is an edge over data-centre provers and nothing more"

56. LP miners: "NVIDIA and AMD both work, because the mining program is generated for the architecture both share" Replace with: "NVIDIA is measured bit-exact against Apple. AMD is the next run. The program is generated for the warp architecture all three share."

57. LP miners: "The dataset starts at 2 GB and grows by half a gigabyte a year, so a 4 GB card mines for about four years and an 8 GB card for more than a decade, approximate." Keep (labelled). HP equivalent "Any card with 4 GB today, 8 GB for the next decade." add "approximate".

58. LP roadmap: "Genesis with no premine, 30-day ramp, exchange listings after" Replace with: "Genesis with no premine, 30-day ramp. No listing is arranged, promised or sought by the project." Same change in J phase 6.

59. HP hero: "The first chain built so no chip can ever take your place." Replace with: "A chain built so a chip gains too little to take your place."

60. HP: "Get the miner" (button, twice) Replace with: "Benchmark: January 2027"

61. HP: "All of it will be on this page, live." Replace with: "All of it will be on this page, live, from public testnet in August 2027."

62. HP economics: "Not one coin to a founder, a fund or a stake." Replace with: "Not one coin of emission to a founder, a fund or a stake. The official client carries a 1% dev fee to the founder's company, as every GPU miner does; any client without it is welcome."

63. HP: "A mining program that rewrites itself every hour, so no chip can be built for it." Replace with: "A mining program that rewrites itself every hour, so a chip built for one hour is useless the next."

64. HP: "No premine, no stake, no foundation, no merge to anything else, ever." Replace with: "No premine, no stake, no foundation, no merge to proof of stake."

65. HP footer and nav: "GitHub" link to a private repository. Make the repository public or remove the link until it is.

66. HP vs RandomX table: identical to LP items 20 to 22; same replacements.

67. HP: "RandomX proved that a random program beats a chip when the only hardware that runs it well is the hardware everyone already owns." Replace with: "RandomX has kept chips off Monero since 2019 by making the program random, so the hardware everyone already owns runs it best, approximate."

68. LP vs RandomX: "Monero's idea, finished for GPUs" Replace with: "Monero's technique, applied to GPUs"

69. LP roadmap: "Each gate is a measurement published whether it passes or fails. Miss it and the phase repeats or the project stops." Keep. Add under the table: "Dates slip. Gates do not."

70. LP mining table: "Ethereum's growing dataset killed Bitmain's E3 miner in 2020 this way, with nobody doing anything" Replace with: "Ethereum's growing dataset ran Bitmain's E3 out of memory in 2020, approximate, with nobody doing anything"

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."

73. LP "Who are you?" answer Append: "The founder's name is on every commit. No cryptographer is yet hired; the design doc budgets one for phases one and two."

74. LP, every finality number quoted from the simulation (ten days, twenty days, two hours) Add once, in the Finality section: "Day counts come from a model with no network latency, no DAG and no partitions (sim/results.md). The gate 3 devnet replaces them with measurements."

75. LP "Fair launch, announced": "Pools live on testnet." Append: "The first month of mainnet runs on proof of work alone while vote weights build; exchanges are told to treat it so."

76. LP, anywhere a launch sentence reads as an inducement to acquire ("the people who show up early get the most", "Half of the 4 billion cap is mined in the first two years" as a chart caption) Rewrite as schedule facts without the "so" clause (item 54), pending a promotions opinion from counsel in the project's jurisdiction.

77. HP and LP: no contact route anywhere. Add one before sharing the litepaper, and point the FUD ledger's submission line at it.

78. LP "What Igneum does not claim" Add three items: "A memory-hard prototype. Not yet: the current dataset can be shortcut 110x; the 256 MB cache replaces it." "Finality in the first month. Not until the 30-day window has history." "A cryptography team. Not yet; external reviewers are named before gate 3."

---

Round 3 entries (3 October 2026, evening): the specification and the running code

Added by docs/review/round-3-2026-10-03.md, which holds the full argument for each, the reviewer who raised it, and the five to fix first. Entries are placed under their section letters below and numbered on from the last entry of each section. Existing entries are unchanged; where one is extended the new entry says so. Count after this block: 107 entries (80 plus 27). Of the 27: 0 fatal, 18 serious, 9 minor by the review's ranking (M18, M21, P13, P15, C13, L8, G10, X12 and the text half of E11 are the minor ones).

M14. A pulsed rental against the block-count DAA buys weight at a discount

"Bring 50x the hashrate for two minutes once an hour. Kaspa's window keeps the 661 most recent samples, so you mine thousands of blocks at the old target before it moves, and when you leave the honest network crawls for hours at your difficulty. Weight is blocks over a window of blocks. You get a third of the window in a week for the price of a 1.6x average."

Status: Open, experiment scheduled as O-3.14 (3 October 2026). The weight half is written into the spec, see F14; the controller half is gate 2 (O-2.1).

Answer: Correct in mechanism and unmeasured in size. sim/results_v2.md runs every scenario with a perfect retarget (its assumption table) and no finality run has a DAA model (O-3.9). Tonight's honest step on the devnet showed the lag: 5.67 blocks a second in a two-minute bucket after the first retarget, 2,248 blocks in eight minutes against 480 expected, and 1.5 blocks a second an hour later (docs/review/round-3-2026-10-03.md, "Tonight's devnet"). The review's estimate is that a pulse buys under two windows of blocks (about 5,000) and the chain crawls after each, so the amplifier over the formula is about 2x at the cost of a visible attack; the estimate is not a simulation. The same lag is the farm operator's hop profit (sim/difficulty/sim.py profiles hop3, hop10, polluted), for which no result is in the bench-log. Fix in two parts: the controller (gate 2, O-2.1, with the simulation results logged) and the weight rule (F14).

Evidence: node1.log of 3 October 2026 and sim/difficulty/devnet-2026-10-03.csv; sim/results_v2.md assumptions. Experiment: finality_v2.py with the Kaspa DAA and the two-lane candidate in the loop against a 50x pulsed renter, reporting the day it crosses a third; sim/difficulty/sim.py results in the bench-log. Review id R3.1.

M15. A header with any past timestamp or any claimed DAA score makes the node build a 256 MiB cache

"Your PoW check runs after GHOSTDAG and before the checks that validate daa_score and the past-median timestamp. The engine keys the program on the header's own daa_score and the cache on its own timestamp, and keeps three entries. I send headers with random past days. Each one costs you a 0.18-second ChaCha12 fill and evicts the honest epoch."

Status: Open, fix named.

Answer: Correct. validate_header (consensus/src/pipeline/header_processor/processor.rs:293 to 301) runs the isolation checks (timestamp against the future only, pre_ghostdag_validation.rs:48), GHOSTDAG, check_pow_and_calc_block_level, and only then pre_pow_validation with check_difficulty_and_daa_score. epoch_seed (processor.rs:325) reads header.daa_score; day_index reads header.timestamp; IgneumEngine::KEEP is 3. docs/fork-divergence.md flags the ordering as a GHOSTDAG cost; the cache thrash is the sharper form. Fix: run the DAA-score and past-median checks before the PoW check; derive the day from DAA score (spec 1.12) or from the selected parent's window; KEEP 4; a per-peer cap on cache builds.

Evidence: the files and lines above. Fix: review's first of five. Review id R3.26.

M16. The 256 MiB cache fits on a die, so the recompute attacker is compute bound

"Your 4.8x-slower shortcut ran with the cache in DRAM behind a chip that cannot hold it. Put 256 MiB of SRAM on a die and the dataset is never needed: 128 items per hash at about 1,170 integer operations and 8 near-free reads each. That is 150,000 operations per hash, and integer operations per dollar is where silicon beats a GPU."

Status: Open, experiment scheduled.

Answer: Correct as arithmetic, unmeasured as a device. From spec 1.8.4 and 1.8.5 an item costs 9 mixer applications of about 130 operations and 8 cache reads; under the proposed 16-load rule a hash derives 128 items. A 5090-class integer budget (about 50 T operations a second, approximate) gives about 0.33 Ghash/s against the honest 141 Mhash/s projection, about 2.4x at equal silicon before any chip-versus-GPU efficiency, and a 256 MiB SRAM is about 250 to 300 mm^2 on a current node (approximate, from wafer-scale parts). The cache size was set to beat a GPU's L2 (spec 1.16), not a die. The lever is the cache size and the mixer cost, both prototype values at gate 1. Monero's precedent does not price this (C13). An FPGA does not reach it (review, chip designer, attack 3).

Evidence: spec 1.8, 1.16; proto-metal/MEMHARD.md 2.2 (Apple only). Experiment: --inline-dataset on the RTX 5090 at a 64 MiB cache (inside its 96 MiB L2, the SRAM emulation) and at 256 MiB against the honest 1 GiB kernel; the O-1.6 time-memory curve; a CPU fill and verify time at a 1 GiB cache. Decision at gate 1: cache size "exceeds what one die can hold, and grows". Review ids R3.5 and the chip designer's pricing.

M17. Every ahead-of-time miner stops at the epoch boundary; whoever compiles in process mines alone

"Your log: last block of epoch 0 at 21:12:14, nothing for the next 91 seconds while the Windows launcher killed eight identities, re-exported, rebuilt two binaries and restarted them. The Metal worker compiles in 129 ms. The first 2.5% of every hour goes to whoever does not use your launcher."

Status: Open, fix named.

Answer: Correct for the devnet client. Under the v0 seed rule (the last block of the previous epoch) nobody can compile early and the gap is structural; under the spec's VDF pipeline the seed is known 1,200 DAA seconds ahead (spec 4.3) and an honest client compiles ahead, so the gap is a client defect, not consensus. Fix: in-worker NVRTC and runtime OpenCL compilation (listed in docs/fork-divergence.md as open), measured on a mixed rig through 24 epoch changes (O-1.16). Extends M11.

Evidence: node1.log 21:12:14 to 21:13:45; proto-cuda/windows-miner/start-mining.ps1 (exit 42 handling); bench-log Metal compile figures. Review id R3.7.

M18. The per-hash random data path is a one-bit select

"Your add picks one of two immediates by a bit of r0. A chip computes both and muxes. Calling that a data-dependent path next to ProgPoW is marketing."

Status: Conceded, wording fix.

Answer: Correct. Spec 1.4.1: sel is r0 at the top of each iteration and each add selects imm or imm2 by one bit of it. It costs a chip nothing and defends nothing; the defence is the random reads. The litepaper's vs RandomX row should drop "random data path" or say what it is.

Evidence: spec 1.4.1. Fix: site/litepaper.html vs RandomX row, "Random program" (review, RandomX author, sentence). Review id R3.8.

M19. The census that justifies the generator rule has blank cells, and the spec still carries the free load count

"Section 7.1 of your census has FRESH2_DIST, FRESH2_P and FRESH2_CAND where the proposed generator's numbers go, section 7.2 is the word FRESH2_ACCEPTED, section 7.3 is CF_AGREEMENT, and the spec text you propose cites a rejection rate called REJECT-RATE. Until it is filled and adopted every hour is a different coin."

Status: Open, measurement in progress.

Answer: Correct. The current-generator census is complete (100,000 programs, 94.8% with a redundant load, hash rate tracking distinct loads 56 to 152 per hash at the 1st to 99th percentile); the fixed16-fresh2 run that fixes the proposed rule's own rejection rate and candidate count is not in the document, and section 1.4.2 of the spec still draws the load count freely. Fix: finish the run, fill the cells, adopt G1 + G2 + R into spec 1.4 with new vectors (spec 1.16 schedules the re-cut), and run ten programs on the 5090 under the new generator. Extends M5 and M6.

Evidence: docs/analysis/weak-program-census-2026-10-03.md sections 7 and 9. Review id R3.6.

M20. Pruning proofs are checked with the kHeavyHash stub

"Wait thirty hours, start a fresh node, and watch it reject the honest pruning proof: validate.rs:192 runs kHeavyHash on headers mined under the lottery, which pass with probability 2^-28. And if you loosen that, I forge levels with an ASIC that already exists."

Status: Open, acknowledged, fix named.

Answer: Correct. consensus/src/processes/pruning_proof/validate.rs:192 calls calc_block_level_check_pow, which runs the stub, and apply.rs and mod.rs call calc_block_level the same way; docs/fork-divergence.md records that seeds must be threaded through pruning-proof validation before a pruning network. The devnet will pass its pruning depth (108,000 blocks, sooner after tonight's overshoot) and a fresh node will show it. Fix: derive the epoch and day for proof headers from the proof's own headers (fork map a4, O-2.5) and remove the stub from the proof path.

Evidence: the files above. Test: sync a fresh node from the 30-hour devnet. Review id R3.3.

M21. GHOSTDAG k is Kaspa's table value for Kaspa-sized bodies

"k = 18 assumes a 5-second delay bound measured with Kaspa's blocks. Yours carry EVM transactions and recursive proof records."

Status: Open, extends O-2.2.

Answer: Correct. Spec 2.1 takes k, max parents and the mergeset limit from Kaspa's table at 1 BPS. O-2.2's two-miner devnet measures the parallel and red rate; it should run with proof-bearing bodies of the size section 5.4 of the execution design implies, and k should be re-derived from the measured delay.

Evidence: spec 2.1; docs/design/execution-layer.md 5.4. Review id R3.4.

F14. Weight in blocks over a window in blocks under a lagging retarget

"Your day counts assume the block supply is capped at one a second. It is not during a retarget lag, and weight is counted in blocks."

Status: Rule written (3 October 2026): spec 3.1 W2 and 3.3 Q1 are denominated in past-median time, weight as a key's share of each 60-s bucket summed over 30 days; the simulated DAA-score form is kept beside it. O-3.14 (added the same evening) confirms or reverts it at gate 3. Was: Open, rule change proposed.

Answer: Correct; this is the finality half of M14. Spec W2 counts blue blocks over a window of 2,592,000 DAA seconds, and DAA seconds are blocks, so a burst both inflates a key's count and ages the window. Proposed change: denominate the vote window (W2) and the presence window (Q1) in past-median time, and define weight as a key's share of the blue blocks in each 60-second median-time bucket summed over the trailing 30 days, so 50x the blocks in one minute is one minute of weight. The simulation of M14 decides.

Evidence: spec 3.1 W2, 3.3 Q1; sim/results_v2.md assumptions. Experiment: the M14 run under both definitions. Review id R3.1.

F15. Merge depth is not the reorg bound; the finality depth is

"You tell exchanges that in month one the one-hour merge-depth bound limits a reorganisation. check_bounded_merge_depth only forbids merging an old red. The virtual switches to any heavier chain until the finality point, which you kept at 12 hours."

Status: Spec fixed (3 October 2026): spec 2.1 names the finality depth as the reorg bound and merge depth as a merge limit only, spec 3.8 and 3.9 tell exchanges to wait 12 hours of past-median time when finality_active is false, and the simnet reorg test is written into 2.1 for gate 2. The litepaper Finality paragraph (first-month sentence and the merge-depth sentence) and "What Igneum does not claim" item 4 now name the 12-hour finality depth and call merge depth a merge limit (same evening). Was: Open, text and rule fix named.

Answer: Correct on reading the fork. post_pow_validation.rs:79 bounds which reds a block may merge; the selected-chain switch is bounded by the finality point (virtual_processor/processor.rs:1626, FINALITY_DURATION 43,200 DAA seconds). So the month-one reorg bound is 12 hours of DAA time, not one hour, and spec 3.8, 3.9, litepaper "Finality" and "What Igneum does not claim" item 4 rest on the wrong constant. Fix: state the finality depth as the bound, in median time (M14 explains why not DAA time), or lower FINALITY_DURATION and accept Kaspa's finality-conflict handling at that depth; test with a heavier private chain forked 2, 6 and 13 hours back on simnet.

Evidence: the files above. Review id R3.2.

F16. A lock can become uncertified after a heal

"Section 3.5: two certificates at one index, strike the equivocators, re-evaluate, and if neither or both still lock the index is uncertified. So the lock my node reported and I credited on is revocable."

Status: Open, decision at gate 3 (extends O-3.6).

Answer: Correct as the proposal stands. For an exchange "locked" must be irrevocable or it is a confirmation count. The alternative is Kaspa's: a verified certificate is never re-evaluated; two certificates at one index are a chain split that halts finality_active until an operator intervenes, and the node never reports a lock it may withdraw. Equivocation costing history and not coins (F6) means the attacker who caused the split keeps the deposit either way. Decision at gate 3; the devnet partition-and-heal test of O-3.6 measures whichever rule is chosen.

Evidence: spec 3.5, 3.9. Review id R3.17.

Cross-reference (external review, 3 October 2026, night): what holds during a pause, and the seed pipeline through it, is F20, O-3.16.

F17. Keys are free and the official client mints eight per card

"Your launcher runs 8 identities per vendor, each with its own vote key. For the vote that is harmless by design. For shard sortition, which ranks every eligible key and takes 8, it is the whole game: 1% of hashrate holds 259 keys above dust. And a few thousand PCs cross your 8,192-voter switch, whose construction is open."

Status: Rule fixed (3 October 2026): spec 7.2 step 2 draws the 8 assignees by weight (blue blocks drawn uniformly from the window, their keys assigned, with the 1-key-versus-1,000-keys test in O-5.1), and spec 3.1 W6 states that keys are free and weight is the only Sybil-resistant quantity. Still open: the client's one-key default, S2 (O-3.5) and the bitmap size (O-3.12). P8 stays closed. Was: Open, rule change proposed. Reopens P8.

Answer: Correct. Spec 7.2 step 2 ranks per key and eligibility is 100 blue blocks in 30 days (0.004% of hashrate at one block a second), so a miner with share s holds up to s x 2,592,000 / 100 keys and the draw of 8 is dominated by whoever splits most. proto-cuda/windows-miner/start-mining.ps1 derives a key per identity (MINERS default 8). O-5.1's acceptance test (fastest prover under 25% of shards) does not catch a splitter, who wins by count. Fix: draw the 8 assignees by weight (8 blue blocks uniformly from the window, take their keys), so splitting changes nothing; the client defaults to one key per operator; specify S2 (O-3.5) and the bitmap size (O-3.12) before the count can cross 8,192.

Evidence: spec 7.2, 3.4; the launcher. Cross-reference added to P8. Review id R3.14.

F18. "A silent minority cannot freeze finality" is false under the floor

"Your own simulation: 45% silent stalls finality for as long as they stay silent, 40% gives 138 stalls in three days, 50% churn stalls 4.1 days. The litepaper says a silent minority cannot freeze it and a lock never waits for miners who have left."

Status: Fixed (3 October 2026). site/litepaper.html Finality carries the replacement sentence and "What Igneum does not claim" carries the pause item ("Finality that never pauses"). Was: Conceded, not yet stated; text fix named.

Answer: Correct. The sentence was true of the active-only rule and was not updated when the 56.7% floor was added (spec 3.3.1 states the liveness cost honestly: liveness ends between 40% and 45% silent). Fix: the replacement sentence in the review (exchange engineer, sentence), and a line in "What Igneum does not claim".

Evidence: sim/results_v2.md C and D; spec 3.3.1; site/litepaper.html Finality. Review id R3.18.

P11. The native-execution veto makes block validity depend on the node's current selected chain

"Section 5.5: a block is invalid if a proof record names a segment not on the node's selected chain, or disagrees with the node's own execution. Two honest nodes with different tips disagree on the same block. You removed the hidden-block penalty for this exact reason."

Status: Fixed (3 October 2026): spec 7.2 item 5 and docs/design/execution-layer.md 5.5 and D12 are relative to the carrying block's own selected-parent chain; the two-node reorg test is a row in the design document's 8.5. Was: Open, text fix named.

Answer: Correct. docs/design/execution-layer.md 5.5 (D12) and spec 7.2 item 5 reference the node's selected chain, which is a property of its virtual, not of the block's past. Fix: a proof record is valid if the chain block it names is on the carrying block's own selected-parent chain and its post_root and receipts equal the execution of that segment along that chain, which every node computes from the block's past. Add a two-node reorg test to section 8.5.

Evidence: the two sections. Review id R3.9.

P12. An aggregator can name itself as every prover

"ProofRecord.provers is who is paid and nothing in a shard proof's statement says who proved it. I aggregate eight gossiped shard proofs and write my key eight times."

Status: Fixed in the proving code (4 October 2026, proving/igneum-prove): every shard proof's public values carry the prover's payout address (ShardOutput.prover), the aggregated block proof commits keccak over the provers in shard order and the shard program's verifying-key hash (BlockOutput.provers, BlockOutput.shard_vk), and the host verifier checks both before it accepts a claim. Still to do in the node: ProofRecord.provers must hash to BlockOutput.provers or the record is invalid (acceptance test A5); records are not on devnet v4 yet. Was: Open, format fix named.

Answer: Correct. Section 5.1's shard statement (pre-root, transactions, post-root, receipts) and the ProofSystem trait of 5.6 carry no prover identity; 4.4 credits the pool to the record's provers. Fix: each shard proof's public input includes the prover's payout key, aggregation carries the keys as public outputs, and a record whose list does not match them is invalid; acceptance test A5 checks the match, not only the credit.

Evidence: docs/design/execution-layer.md 5.1, 5.4, 5.6, 9.2 A5. Review id R3.10.

P13. The litepaper still claims shards with a bond

"'Miners claim shards with a small bond.' Your spec 7.2 decided sortition with no bond the same day."

Status: Fixed (3 October 2026): site/litepaper.html, Proving, "How a block gets proven". Was: Conceded, fix now.

Answer: Correct. Fix: "Shards are assigned by lot to eight provers for ten seconds, then open to anyone; there is no bond." (site/litepaper.html, Proving, "How a block gets proven".)

Evidence: spec 7.2. Review id R3.13.

P14. Two definitions of the proving base fee, and a quote that cannot know the ratio

"Spec 5.1 adjusts f_p from the unproven backlog smoothed over the difficulty window; design 4.1 adjusts it EIP-1559 style toward B_p / 2. And eth_gasPrice has no calldata, so your fold returns an average and a modexp-heavy transaction reverts on the budget and pays for it."

Status: Open, decision named.

Answer: Correct on both. Fix: one controller definition in both files; eth_gasPrice documented as a network-average fold with eth_estimateGas (which has the calldata) returning the limit that covers both charges; and the R1 band measurement (pgas / gas inside 0.1 to 10 for 95% of ethereum/tests) as the evidence that the average is usually close. R8 and R11 remain the experiments.

Evidence: spec 5.1; docs/design/execution-layer.md 4.1, 4.3, 9.1. Review id R3.11.

P15. RPC blocks are segments, so gasUsed can exceed gasLimit

"A segment holds up to 180 blocks and your RPC block is the segment. Indexers assert gasUsed <= gasLimit."

Status: Open, minor, extends R10.

Answer: Correct; spec 7.1 states that a segment's total can exceed gaslimit. Fix: report the segment's limit as k x B_e in the RPC block, or document the invariant break for Blockscout (R10).

Evidence: spec 7.1; docs/design/execution-layer.md 8.2. Review id R3.12.

E9. The specification's year is 365 days; the code's is 365.25

"Spec 2.5: 31,536,000 DAA seconds a year, halving every 63,072,000, about 31.7098 IGN a second. igneum.rs: 31,557,600, 63,115,200, 31.688 IGN. Which one is the money?"

Status: Fixed (3 October 2026): spec 2.5 follows the code (365.25-day year, 63,115,200-s halving, 31.688 IGN per DAA second, 8 decimals noted under O-2.6). The test that asserts the published numbers against igneum.rs is the code owner's row in docs/fud-fixes.md. Was: Open, decision now.

Answer: Correct. consensus/core/src/igneum.rs (SECONDS_PER_YEAR = 31_557_600, HALVING_INTERVAL_SECONDS = 63_115_200, BASE_SUBSIDY_PER_SECOND_SOMPI = 3_168_808_781) and spec 2.5 disagree; docs/fork-divergence.md's per-second table follows the code. Fix: pick one (the code's values are tested and summed under the cap) and rewrite spec 2.5 and the litepaper's schedule to match, with a test that asserts the published numbers against the code.

Evidence: the two files. Review id R3.19.

E10. Reds are paid in the code and "more blocks never means more coins" is false

"Spec 2.5: red blocks are unpaid, emission is keyed to DAA score so more blocks never means more coins. coinbase.rs pays a red's 80% to the merging miner and its 20% to the pool, and every blue block in the DAA window mints E(daa). Tonight your chain minted 4.7x the schedule for eight minutes."

Status: Fixed (3 October 2026): spec 2.5 says reds inside the DAA window are paid to the merging miner (80%) and the pool (20%), that E is paid per block so coins are blocks times E under the controller's rate, and that the cap is unaffected; "more blocks never means more coins" is withdrawn. The litepaper Speed sentence ("never per block") was rewritten the same evening: emission per block on a schedule keyed to difficulty-adjusted time, reds in the window paid, coins track blocks within the controller's accuracy. Was: Conceded, text fix named.

Answer: Correct. consensus/src/processes/coinbase.rs:102 to 109 follows Kaspa's rule for reds; block_subsidy is paid per blue (and red) block in the DAA window, so coins are blocks times E and the controller's rate sets the short-run emission, as on every proof-of-work chain. Timestamps still cannot mint. Fix: spec 2.5 to say what the code does (reds paid to the merger, emission per block under the controller's rate, the cap unaffected), or the code to say what the spec does; the review recommends the code's rule.

Evidence: the files; docs/review/round-3-2026-10-03.md, "Tonight's devnet". Review id R3.20.

E11. The homepage burns job fees at launch

"'Jobs through Igneum's own market are paid in IGN and 10% of each fee is burned', with a tile 'IGN burned from jobs, at launch'. Your spec 5.4 settles launch jobs on the customer's chain with no burn. You fixed the litepaper (P10) and left the homepage."

Status: Fixed (3 October 2026): site/index.html, "Proofs sold to other chains" caption and the tile now read "phase two"; the quoted paragraph had already left the page when the homepage was trimmed (commit 047892e). Was: Conceded, fix now.

Answer: Correct. Fix: site/index.html, "Proofs sold to other chains": "Jobs are paid on the customer's chain at launch; settlement in IGN with a 10% burn follows the proof bridge in phase two", and the tile's label to "phase two". Extends P10 and overclaim 52.

Evidence: spec 5.4; site/index.html. Review id R3.24.

C13. Monero's seven years do not price a 256 MiB SRAM die

"RandomX's cache is 256 MiB too. Nobody built the die for Monero because the prize was small. That is not evidence about the die."

Status: Conceded, label needed; extends C2.

Answer: Correct. The precedent argument transfers the cache size and not the economics; see M16 for the pricing and the lever.

Evidence: none beyond M16. Review id R3.16.

L7. "Where the price comes from"

"A heading in a document that says it is not an offer, followed by 'both reduce supply as they happen'. That is a value-accrual argument under a heading about price."

Status: Fixed (3 October 2026): heading "Where fees go" and the sentence deleted, site/litepaper.html Economics. Counsel review of the section remains under L1 and L2. Was: Open, counsel; text fix now.

Answer: Correct as a reading. Fix: the heading becomes "Where fees go" and the sentence "Demand comes from use of the chain and from outsiders buying proofs, and both reduce supply as they happen" is deleted; counsel reviews the Economics section (L1, L2).

Evidence: site/litepaper.html, Economics. Review id R3.23.

L8. Third-party names as implied outcomes

"'Native USDC is requested from Circle during public testnet.' 'Canto and Blast proved builders come for this.' Names of companies next to outcomes you do not control."

Status: Conceded, wording fix.

Answer: Correct. Fix: "The project will ask Circle for native USDC during public testnet; whether it is issued is Circle's decision" and the Canto and Blast sentence as overclaim 39 already rewrites it.

Evidence: site/litepaper.html, Building, Questions builders ask. Review id R3.25.

G9. The release-key steward is one person, and a lost key cannot be revoked

"Spec 8.2: the key that signs the software every miner runs is held by 'the steward named in the published key policy', policy deferred to testnet. And item 5 says a lost key is revoked by its own last signed release, which a lost key cannot sign."

Status: Rule fixed (3 October 2026): spec 8.2 item 5, rotation signed by the current key and revocation signed by the previous key (a pre-signed certificate for K0), both published in a block; item 2 moves the policy to before the client ships and adds the entity and jurisdiction. Steward disclosure itself remains (O-8.1, L1). Was: Open, policy and rule fix named; extends O-8.1.

Answer: Correct on both. The steward is the control point a regulator writes down, and the revocation path as written freezes the update channel for ever on a lost key. Fix: a pre-signed revocation certificate held apart from the signing key, or a 2-of-3 key set with the policy published before the client ships rather than before testnet; and the entity and jurisdiction that employ the steward named with it (L1).

Evidence: spec 8.2. Review id R3.21.

G10. The signalling default on first run

"8.3 says the default is the choice the user last made. On first run there is none."

Status: Open, minor.

Answer: Correct. Fix: first run signals nothing until the user chooses, shown in the interface.

Evidence: spec 8.3 item 2. Review id R3.22.

X12. Tonight's numbers are quoted before they are logged, and the worker efficiency gap is unexplained

"The 50x step, the trough near 9 million, 5.5 blocks a second and two-thirds efficiency over eight processes are in the brief and not in the bench-log. And the chain saw 70 to 83 MH/s from a card that benches 229, which is a third, not two thirds."

Status: Conceded, fix now.

Answer: Correct. The bench-log is append-only and the project's rule is that a number exists when it is logged with its command. Tonight's run needs its entry: the step profile, the retarget trajectory from the CSV (134.2 M to 14.2 M expected hashes by DAA 812, further per the brief), the 2-minute block-rate buckets, the epoch-boundary gap, and the launcher's summed status against the block rate, with the gap explained (template age, sibling blocks dropped by the one-block-per-job rule, or queue stalls across eight processes).

Evidence: /tmp/igneum-devnet/node1.log, sim/difficulty/devnet-2026-10-03.csv, the launcher log on the PC. Review id R3.15.

---

External review entries (3 October 2026, night): the litepaper

Added by docs/review/external-2026-10-03.md, which holds the reviewer's text verbatim and the point-by-point classification (13 already answered, 15 new, 1 wrong). The reviewer is a general-purpose AI assistant; its claims about third parties are approximate. Entries are placed under their section letters and numbered on from the last entry of each section. Count after this block: 122 entries (107 plus 15). Every entry is Open with its experiment or decision named.

M22. The ASIC challenge has no scoring rules, and 2x is not the economic line

"Your bounty says 'beats a GPU by more than 2x'. Per what? Hashes per second, per joule, per dollar, on the average program or the worst hour? A chip at 1.6x with half the capital cost wins. And nobody has published eligible hardware, funding or a judge."

Status: Open, decision for the project lead (terms, judge and funding) and experiment scheduled (extends O-1.17).

Answer: Correct. M1 and O-1.17 name a bounty for "more than 2x" without a metric, a judge or a fund, and 2x is a design target for the hash, not an economic threshold: a chip at 1.5x per joule and 3x per dollar of capital is an economic ASIC whatever the hash-rate ratio says. The scoring rules go out with the January 2027 benchmark: hashes per second and per joule measured per program over a published set of at least 100 epochs, reported as a distribution (worst decile, median), never as one average; capital cost per unit of hash rate at a stated volume; a longevity term against the instruction-family reserve and the dataset growth of spec 1.13; and the shortcut classes (recomputation, partial storage, weak-program selection) scored separately. Eligible hardware assumptions, the judge, the reward and the payer are the project lead's decisions (fud-fixes row 50: the payer is the entity). The supportable public claim until a design has been scored: across the tested workloads and the stated economic assumptions, consumer GPUs remain competitive against the best independently proposed specialised design. Extends M1, M16 and C13.

Evidence: M1, O-1.17, spec 1.13 and 1.16, M16's arithmetic. Experiment: the scoring rules published with the benchmark, then the first scored submission. Review: external, point 4.

F19. Old vote keys can be bought; fresh hashrate cannot buy weight

"Weight is 30 days of blocks per key, and keys are free to make and free to sell. I do not rent hashrate for 20 days. I buy, borrow or steal the vote keys of pools that already mined those 20 days. Your simulation models the renter and never the buyer."

Status: Open, experiment scheduled (O-3.15).

Answer: Correct, and the ledger had no entry for it. Spec 3.1 W6 says weight is the only Sybil-resistant quantity because it takes public mining to earn; it does not say what happens when an earned key changes hands. A compromised or sold key carries its whole 30-day history, so the 10-day and 20-day figures of F5 apply only to an attacker who mines; a buyer's day count is zero. What limits it today: W5 moves weight to a successor only by a message the old key signs (O-3.11), equivocation strips a key for 30 days (3.6), and pool keys are few and public (F10). What is missing: the acquisition cost of the top pools' keys against the hashrate cost of F5, whether weight should decay faster than 30 days when a key's blocks stop matching its earlier profile, and whether W5 should make the successor re-earn. Gate 3, in finality_v2.py: k% of weight changes hands at day 0 against the same k% arriving as fresh hashrate, for k in 20, 34 and 40, with the 40/40/20 partition row the reviewer asked for under the active-set rules and the floor, reporting time to a conflicting lock under each.

Evidence: spec 3.1 W5 and W6, 3.6; sim/results_v2.md (renter scenarios only). Experiment: O-3.15. Review: external, point 2.

F20. During a finality pause the program must keep advancing, and nothing says which guarantees survive

"Your epoch seed is a VDF of a certified checkpoint. When finality pauses for four days, your own 50% churn figure, which checkpoint seeds hour 50? And when the pause ends, what exactly was still guaranteed in between?"

Status: Open, decision scheduled at gate 3 (O-3.16, with O-4.3).

Answer: Correct on the gap. Spec 4.3 proposes that the seed checkpoint may be the uncertified selected-chain block at the checkpoint blue score, so a pause does not stop mining, and O-4.3 leaves the decision to gate 3; the design document still says an epoch cannot start without a valid proof. No text states what holds during a pause: that blocks, execution and proofs continue (3.7 item 2 says proof of work in practice), that every lock before the pause stands (3.5), that finality_active is false and exchanges wait on the 12-hour finality depth (3.9), and that the seed pipeline advances from uncertified checkpoint blocks with the reorg exposure that implies (a 1,200-DAA-s lead plus d). Gate 3 takes the uncertified option or states the stop; this ledger recommends uncertified, as spec 4.3 does, and the four guarantees go into spec 3.7. Test: the devnet with the finality module stalled by a 45% silent set (3.3.1 row C) through at least 3 epoch boundaries, recording that the program advanced on schedule, that no node forked on the seed, and that the pre-pause locks survived the heal.

Evidence: spec 4.3 (O-4.3), 3.3.1, 3.5, 3.7 item 2, 3.9. Experiment: O-3.16. Review: external, point 2.

F22. Certificates carry 8 to 10 of 12 votes on a healthy network, so locks sit a hair above the floor

"Two of your cloud checkpoints locked at 66.8% against a 66.7% floor with every node connected. One slow aggregator and finality pauses."

Status: Fix built, pending rollout (4 October 2026, evening; branch finality-fixes of the node, behind finality_v3_activation_daa, docs/plans/finality-v3-rollout-devnet.md). Was: Open, found by the team (4 October 2026, 12-node cloud devnet, second partition run).

Answer: True as measured, and the cause is not a cut-off at all: the node builds the certificate the instant the votes it holds meet Q3, and carries that one. Measured on the cloud logs of the healthy stretch 11:45 to 14:00 UTC (212 indices, infra/cloud-devnet/results/2026-10-04/f22-vote-timing.md, script tools/finality-attacks/vote-timing.py): the first certificate was built median 1.24 s (p99 1.71 s) after the first node determined the checkpoint, with 7 to 10 of 12 signers (mean 8.27); by then 10.24 votes had been issued on average, so about two were in flight (the miner's 1-s poll, a 250-ms gossip pump per hop, inter-region RTT up to 289 ms) and about two were issued later; the last of the 12 votes was issued median 1.45 s, p90 2.36 s after the first determination. Holding for 1 s after the first build would have carried all 12 votes at 192 of 212 indices; the other 20 are one event, miners 01, 06 and 11 down together for 10 minutes across indices 377 to 396 (the afternoon hop.sh restarts), not relay lag. The fix (spec Q4, rule v3): the first certificate still forms at quorum, so lock latency is unchanged; once every voter has signed, or certificate_fold DAA seconds after the determination (3 on devnet, 6 on mainnet), a node rebuilds the certificate from every vote it has seen and gossips the heavier one, and every node replaces a held certificate with a verified heavier one over the same block. Presence needs nothing: under the block reading of Q2 a late vote already counts once any block carries it. Unit test fold_round_carries_late_votes_and_heavier_certificates_replace (node, processes::finality). Network figures: docs/bench-log.md, "finality rule v3".

Evidence: infra/cloud-devnet/results/2026-10-04/partition-sin-20261004-140305/partition.md, f22-vote-timing.md; bench-log "Hetzner partition and hash-step", "finality rule v3"; spec 3.3 Q4, 3.10.

P16. The proving gate can be passed by shrinking the shard

"'A mid-range GPU proves a shard in under 20 s.' Your own R2 says: if missed, halve the shard and re-measure. That is the trap. Fix the workload first, measure the whole journey, and have strangers reproduce it."

Status: Open, experiment scheduled (O-7.1). The journey's phase 2 gate was rewritten the same night.

Answer: Correct. P1 conceded that the 20-s figure is a target; this is about how the target is tested. docs/design/execution-layer.md 9.1 R2 passes at any shard size by halving S_p until the time fits, so a pass says nothing about throughput, and R4 measures the wrapper only. The phase 2 benchmark now has an acceptance standard: a fixed published workload (real transactions, never empty blocks or tiny shards) with its shard plan, proven end to end from job received to proof accepted, including queueing, transfers, aggregation, verification and payment; the median and the slowest 5% and 1%; failure and retry rates; full cost (electricity, host, bandwidth, aggregation, failed work, hardware); results per advertised card with mining and proving compatibility stated separately; sustained with no growing backlog; reproduced by at least three unrelated operators from the published code and configuration. A halved shard is a new declared workload, never a pass. The reviewer's figure for SP1's cluster requirement (NVIDIA, 24 GB, approximate; not checked, SP1 is not in vendor/) is why a 12 GB card has to show the whole pipeline, which R2 and R4 already target.

Evidence: P1; execution-layer 9.1 R2 and R4; docs/bench-log.md (no shard has been proven on any card). Experiment: O-7.1. Review: external, point 1.

P17. Interfaces must show four states, and the design shows three

"Included, executed, proven, finalised are four different facts. Your status call returns executed, proven, locked and a list of blocks. A wallet that shows a balance at 'included' is lying by omission."

Status: Open, rule written (3 October 2026, night) in docs/design/execution-layer.md 2.4; experiment scheduled (O-7.2).

Answer: Correct. Design 2.3 defines executed, proven and locked; igneum_getTransactionStatus carries included_in as a list and never as a state; the phone app (phone-app 3 and 9) shows three words. A transaction in a block not yet on a selected chain, or in a merged block waiting its turn in the sequence, is included and nothing more, and on a DAG that gap is routine. The rule now in 2.4: every RPC, wallet, explorer and app reports exactly one of included, executed, proven, finalised (the user-facing word for locked), never a stronger word than the chain's own state, and shows "finality not active" in place of finalised while finality_active is false (3.9). Proven says nothing about availability: full blocks are what every full node holds (F13) and a light client takes data from nodes under spec 10.1. Test: a wallet and RPC conformance set on the devnet, one transaction through each state and the three failure paths (skipped, reorged out, finality paused).

Evidence: execution-layer 2.3, 2.4, 8.2; phone-app 3 and 9; spec 3.9, 10.1. Experiment: O-7.2. Review: external, point 2.

E12. Selfish operators under a price shock

"Outside proving pays ten times more and IGN halves in a week. Every rational operator leaves hashing for jobs. Do your internal proofs go unproven, do queues grow, does anything bring them back? Assume nobody runs your client's scheduler."

Status: Open, simulation and testnet experiment scheduled (O-5.9).

Answer: The premise that the design relies on voluntary scheduling is wrong; the stress test is missing. Nothing in spec 5.3 or 7.2 asks an operator to prove at a loss: the 20% pool is paid per block as a fixed amount divided by proving cost, shards go by sortition then open claiming, and an unproven block delays only its proof (P9). The two base fees re-price when provers leave (spec 5.1: f_p rises from the unproven backlog) and the backlog rule of design 4.3 halves B_p per 600 blocks of backlog, so the chain carries less gas rather than falling behind. What is not shown is the loop under the reviewer's shocks. R8 simulates f_e, f_p and the hash-or-prove switch against devnet fee traces; it has not run, and it models no external price ten times the internal one, no falling IGN price, no large operator leaving, no deliberately unfulfilled assignments and no profit-only clients. O-5.9 adds those five to the R8 simulation and then to the phase 4 devnet with profit-only prover clients, reporting backlog depth, time to clear, the f_p and B_p paths, and income per card under each shock. Extends P8, P9, E6 and R8.

Evidence: spec 5.1, 5.3, 7.2; execution-layer 4.3, 9.1 R8. Experiment: O-5.9. Review: external, point 3.

E13. One diagram per payment route, or operator income and protocol income blur

"Your customer brief says dollars on the customer's chain; your economics section says IGN with a burn; your tiles said 'at launch'. Draw every route separately: currency, recipient, fee, any IGN purchase, any burn."

Status: Open, document scheduled (O-5.10).

Answer: Correct. P10 fixed the contradiction in words and E11 fixed the tile; no single figure shows the routes. There are five: emission (80% producer, 20% proving pool, per block); base fee (burned in full on both gas dimensions); priority fee (80% miner and provers, 20% called app, unregistered share burned); external jobs at launch (customer's chain, customer's currency, payout contract by miner address, no burn); external jobs after the proof bridge (IGN on Igneum, 90% provers, 10% burn). A sixth is the official client's 1% dev fee to the entity (E5), which is operator income and never protocol income. The diagram goes in the litepaper's Economics section and in the customer brief, one route per row with currency, recipient, fee and burn, and no row that adds operator revenue to protocol revenue. Boundless's documented lifecycle (request, bidding, verification, payment) is the reviewer's comparison and approximate (C10).

Evidence: spec 2.5, 5.1 to 5.4; docs/commercial/prover-customer-brief.md; P10, E5, E11. Decision: O-5.10. Review: external, point 5.

E14. No funding table

"Who pays for development, the independent review, the infrastructure and an incident response, from what, and what happens if revenue is late? You have no fund by design, which means you have no table either."

Status: Open, decision for the project lead.

Answer: Correct. The fund was removed on purpose (E4) and the team earns from the 1% client fee, its pool, its provers and the app share (E5); none of that is costed, and the second client has no funder (fud-fixes row 47), nor do the external reviewers (G1), the bounty (M22), the seed nodes or the public infrastructure. The table: each cost line (development, independent review, infrastructure, incident response, the bounty, the second client) against its source (the entity's own money, the client fee, the proving business, a grant mechanism added by signalling), labelled funded, dependent on future revenue, or unfunded, with the consequence if revenue is late. It assumes a flat IGN price, which is E15's test. The table is internal until counsel has read it (L1, L2); the litepaper states which lines are unfunded.

Evidence: E4, E5, G1, G5; fud-fixes rows 47, 50, 71. Decision: the project lead, before the repository goes public. Review: external, point 6.

E15. The security budget through successive halvings with low fees and no external demand

"Walk the schedule forward: emission halves every two years, the base fee is burned, the priority fee is small on a quiet chain, and nobody buys proofs. What does a card earn in year 7, and at what price does hashrate leave? Report what reaches miners and provers apart from what is burned."

Status: Open, simulation scheduled (O-5.11); extends E1 and E6.

Answer: Correct that the ledger concedes the cliff (E1) and the halving bet (E6) and has computed neither. O-5.11 is a model: emission per spec 2.5 through year 12; a fee grid (priority fee per block at low, medium and high use; external jobs at zero, low and the brief's launch assumption); hashrate as a function of income per card at a stated electricity price under a flat, a falling and a rising IGN price; reporting per year the payments to miners and to provers apart from the burn, the hashrate that income supports, and the cost of a 51% rental against it. The honest output is the year and the price at which the budget fails under the no-demand, flat-price case, stated in the litepaper's Supply section next to the tail-emission alternative. The flat-price column is the one that counts.

Evidence: spec 2.5, 5.1 to 5.4; E1, E6. Experiment: O-5.11. Review: external, point 6.

G11. Publish the inspectable components now, labelled experimental

"The organisation has no public repository. Harnesses, test vectors, simulators and the specification could be public tonight, marked experimental. Waiting for January is a choice, and it reads as hiding."

Status: Open, decision for the project lead.

Answer: The fact is conceded in X1 (the repository is private and the site says reproducible) and the pre-publication steps are in docs/fud-fixes.md section 5 (ledger out of the tree, CLAUDE.md rewritten, history rewritten, licence). The reviewer asks for an earlier date than January 2027 and a narrower scope: the benchmark harnesses, the test vectors, the simulators and docs/spec/, each labelled experimental, with the node fork following when the gate-2 work is in. the project lead decides which components, under which licence, and when; section 5 runs first in any case. The reviewer's companion advice, one proof-request workflow and one reference application before any broader app set, is the same decision's scope: the genesis-app list (G4, O-5.4) is not a prerequisite for the benchmark or the testnet.

Evidence: X1; docs/fud-fixes.md section 5. Decision: the project lead. Review: external, point 7.

X13. One paying customer for a stated reason

"'One rollup signs for testnet' is a letter of intent with no money. A customer who pays once, pays again without a rebate, and then a second unrelated customer, is evidence. A signature is not."

Status: Open, experiment scheduled (the pilot itself), decision for the project lead on timing and terms; extends L4 and the customer brief.

Answer: Correct. The phase 4 gate is a signature and the brief says so ("a signed letter of intent with no payment"). The progression is adopted and the brief carries it at its next version: agree the workload, proof format, deadline, failure rate and price before the pilot; publish the outcome and the customer's own reason for buying; then repeat purchases without reimbursement; then several unrelated customers. The reviewer places the paid pilot before public testnet; the journey has it in phase 5. Phase 4 keeps the signature as its gate and phase 5's line gains the paid pilot; moving it earlier is the project lead's call and needs the entity, terms and tax treatment of L4 first.

Evidence: site/journey.json phases 4 and 5; docs/commercial/prover-customer-brief.md; L4, L6. Experiment: the pilot, reported in the bench-log with the agreed numbers. Review: external, point 5.

X14. Concentration is unmeasured in four places

"Define independent for the 1,000-miner gate, then report concentration in hashing, checkpoint signing, proving and aggregation, because a thousand miners behind two pools is two."

Status: Open, measurement scheduled (O-X.1); extends X5.

Answer: Correct. X5 conceded that "independent" needs a measurable definition (distinct ASNs, benchmark hardware fingerprints, pool attestations) and left it to phase 4. The four concentrations can each be computed from chain data: blue blocks per vote key and per pool (hashing), signed weight per key in certificates (checkpoint signing), proof records per prover key (proving, once P12's fix puts the key in the statement), and certificates and proof records per aggregator key (aggregation). The gate reports all four as top-1, top-3 and top-10 shares over 30 days, beside the independence count, on the live page. Transaction choice inside pools is a separate measurement and is already scheduled: whether members of the reference pool use declared templates (spec 9.4.2, mode C) is recorded under O-9.5.

Evidence: X5, F10, P12, spec 9.4.2. Experiment: O-X.1. Review: external, point 6.

X15. Remove the founders from a test network and show what continues

"'The chain runs without its founders' is a sentence. Take the team's miners, provers, aggregators, seed nodes, observer and site off a running testnet and show what keeps producing blocks, proofs and locks."

Status: Open, experiment scheduled (O-X.2).

Answer: Correct, and it is the right test for the litepaper's sentence (Governance). The test: on the public testnet, at a published time, stop every node, miner, prover, aggregator and seed node the project runs, take the observer feed and the live page down, and record for 24 hours: blocks per second, proof lag, certificates per hour, and a fresh node syncing from the seed list in the client (spec 10.6). What continues is what the sentence may claim. Dependencies the test will expose: the seed list, the release key (G7), the reference pool, the VDF evaluators (every node ships one, 4.5) and the founders' own hashrate share (E2).

Evidence: site/litepaper.html Governance; spec 10.6, 4.5; G7, E2. Experiment: O-X.2, before mainnet. Review: external, point 6.

X16. An evidence page with four labels

"Every claim needs a status, a software version, the test that produced it, the result and whether anyone outside reproduced it. 'Implemented', 'tested by the team', 'reproduced externally' and 'reviewed independently' are four different things, and your bench-log uses one voice for all of them."

Status: Open, publication scheduled (O-X.3).

Answer: Correct. The bench-log records machine, command and number; the spec labels rules Designed, Measured, Target or Decided; neither says who ran a test or whether anyone else has. The evidence page ships with the benchmark release and carries one row per public claim: the claim, its status, the exact version (commit and release), the reproducible test (command or script), the result with its bench-log entry, and one of the four labels, with audits and reviews tied to the version they read. "Tested by the team" is the only label any row can carry tonight; G2's disclosure applies to the whole page. The ledger's own statuses map onto the labels and are not replaced by them.

Evidence: docs/bench-log.md; docs/spec/README.md labels; G2. Publication: O-X.3. Review: external, point 7.

X17. The miner app must show net earnings and keep jobs away from keys

"Show me what a card earns after my electricity tariff, mining and proving separately, which jobs failed and why, which release I am on and whether I accepted it, and promise that a proving job can never read my wallet. Your spec covers the update and the seed, and nothing else on that list."

Status: Open, design and measurement scheduled (O-8.2, O-8.3); update control and the seed are answered by design (spec 8.2 item 4, 8.5).

Answer: Update control and the seed are decided (spec 8.2 item 4: no silent updates, the user accepts each release; 8.5: seed confirmed, hardware wallet). The litepaper promises earnings "in IGN and in your currency" and M13 promised projected earnings before mining starts; neither nets off power. New requirements for the official client and the phone monitor: (a) net earnings per card after an electricity tariff the user enters, the gross beside it; (b) mining income and proving income reported separately, per card and per day; (c) hardware compatibility and power limits per card, with mining and proving capability stated separately as the benchmark reports them (P16); (d) every failed or retried job visible with its reason; (e) the running release, its hash and any pending release the user has not accepted; (f) isolation: proving jobs run guest programs supplied by strangers, so the prover process holds no wallet key, no seed and no vote key, runs under a separate OS user or sandbox, and reaches the signer only through a local socket that signs payout claims and nothing else, designed and reviewed before the first external job runs. The phone app carries (a), (b), (d) and (e) as display rules (phone-app 4.1).

Evidence: spec 8.2, 8.5; site/litepaper.html For miners; M13; proto-cuda/windows-app/README.txt. Experiment: O-8.2 (display rules measured against the pool protocol's stats on the phase 4 devnet), O-8.3 (isolation design reviewed, then an escape test with a hostile guest program). Review: external, point 7.

Execution attack findings (4 October 2026): fixed

P18. The mempool queues transactions no block can carry

"Send a transaction with a gas limit above the block limit and the node says thank you and keeps it. It can never be mined. Fill the queue with them."

Status: Fixed (4 October 2026). Spec 7.5 item 3; igneum/exec/src/pool.rs EvmPool::add.

Answer: Correct, and low: the queue slot was reserved against the sender's funds, so it was self-limited. The mempool now refuses gas_limit > B_e at admission with the error "gas limit N above the block execution gas limit B_e", as geth refuses gas > block gas limit. Measured: gas_limit 30,000,001 refused; 30,000,000 admitted and executed; unit test pool::gas_limit_is_bounded_by_the_block_execution_limit.

Evidence: docs/bench-log.md, 4 October 2026 "execution layer attack fixes"; the 3 October attack entry, F-exec-A.

P19. An over-budget proving transaction runs for free, every time, and blocks its sender

"One big modexp costs more proving gas than a block allows. The node executes it in full, then skips it unpaid because it does not fit. Every node does that on every inclusion, and the sender's next nonces sit behind it forever. Free CPU on the whole network for the price of a signature."

Status: Fixed (4 October 2026). Spec 7.5 items 1 to 4; igneum/exec/src/pgas.rs, executor.rs, pool.rs, rpc.rs.

Answer: Correct, medium. The 3 October attack run showed it: a 9,000-call modexp loop ran 10.85 ms of native work, was skipped with BlockProvingBudget, paid nothing, and the sender's 14,000 and 20,000 loops were never includable behind it. Four rules now hold. (1) pgas is metered incrementally against the including block's remaining B_p and the transaction halts before the opcode or precompile that would cross it, so native work is bounded by B_p. (2) An aborted transaction is executed, not skipped: status 0, charged for the gas and pgas consumed to the abort, nonce advanced, so a later copy skips by the nonce rule at one account read and the sender's later nonces are free. (3) The mempool refuses a transaction whose estimated pgas exceeds B_p and the template packs by the estimate. (4) eth_estimateGas names the pgas when the cap is hit and igneum_estimateGas returns both dimensions. Measured after the fix: the same loop is refused by the mempool; a hostile miner's inclusion is cut at 29,998,593 pgas after 11.4 ms, the sender pays 0.0394 IGN, the nonce advances, a second inclusion costs 35 us, the next nonce executes; igneum-exec-diff 0 mismatches. What remains open is node policy, not consensus: the admission estimate costs up to B_p of simulation per heavy submission, under the RPC's state lock.

Evidence: docs/bench-log.md, 4 October 2026 "execution layer attack fixes" (before and after table); the 3 October attack entry, F-exec-B; unit tests executor::over_budget_pgas_is_aborted_charged_and_the_nonce_advances, executor::the_cap_is_the_remaining_block_budget, executor::estimate_reports_the_cap, pool::estimated_proving_gas_is_bounded_by_the_block_proving_limit, pool::template_never_exceeds_the_remaining_proving_budget.

Difficulty attack findings (4 October 2026): fixed

P20. The SP1 GPU client panics on shutdown and the compressed stage waited ten minutes

"Your first GPU proof run aborted with a core dump. What else aborts?"

Status: Fixed in the host, to be confirmed on the PC (4 October 2026, afternoon). (1) igneum-prove-host holds a Tokio runtime for the whole run (main enters it before anything else) and drops the proof system inside it, then shuts the runtime down with a 10-s grace, so sp1-cuda's tokio::spawn in Drop finds a runtime. (2) Every stage prints a STAGE ... start line and a RESULT line with a UTC timestamp, and the setup line splits client creation from the two key setups (on the Mac CPU the client creation alone is 30 to 50 s of a 40 to 60 s setup; bench-log 4 October 2026, shards). The next PC run (PROVE-SHARD.bat) shows whether the gap sits before the first compressed stage and how long it is on the card. Was: Open, found by the team (4 October 2026, morning, first RTX 5090 run through WSL2, SP1 6.8.1).

Answer: Two separate things, neither in the proof. (1) After every proof was written, verified and uploaded, sp1-cuda's client dropped its session key outside a Tokio runtime and panicked in its destructor (sp1-cuda-6.8.1/src/pk.rs:63, client.rs:221), so the host exited 134 with the results already on disk. Fix in our host: hold a runtime for the client's lifetime or drop the proof system inside one. (2) Between the core proof (08:49:10 UTC) and "Proving with mode: Compressed" (08:59:02 UTC) the host was silent for ten minutes while the card was idle; the compressed mode's recursion setup on first use is the suspect, and the second run must time it. Both go on the proving e2e benchmark standard as fixed overheads to measure, not hide.

Evidence: docs/bench-log.md "4 October 2026, proving v0 on the RTX 5090"; results file block-78-increment-cuda-20261004-084838.json on the PC; log intake id 10154. Experiment: O-7.4 (re-run with --mode compressed alone and a timestamp per stage).

M23. Forge timestamps inside the rules and the controller mines you a 10x difficulty for free

"Your fast controller clamps every solvetime to 20 s both ways and says the next honest block cancels a forged one. Good: I stamp every block of mine at the earliest the past median allows, the honest block after me gets clamped to +20 s, the pair sums to zero, and your lanes measure 1 - 2a(1 - a) of real time at my share a. With half the hashrate your chain runs at a fifth of its rate and 9.9x the difficulty, on no extra hash. Kaspa's window only drifts 5 to 11%. And while I am at it, 85 blocks a second of PoW-less input drives your target below 2^64 and calc_work panics the node."

Status: Fixed (4 October 2026). Spec 2.3 rules 1 and 4 and the timestamp rules; difficulty branch of vendor/igneum-node (consensus/core/src/igneum.rs difficulty module, consensus/src/model/stores/clock.rs, header_processor/{pre_ghostdag_validation,post_pow_validation,processor}.rs, processes/difficulty.rs, virtual_processor/processor.rs); sim/difficulty/sim.py.

Answer: Correct on every point, and measured first by our own attack run (sim/difficulty/attacks/README.md, scenarios 3 and 7): in the simulator a 50% forger took the block rate to 0.12 (earliest stamp) and 0.56 (latest) of target; on a 3-node test network to 0.24 and 0.59 blocks/s at 3x and 1.9x difficulty on an unchanged hash rate; the flood underflowed the 192-bit work type after 4,142 blocks. Spec 2.3's "the next honest block cancels it" was the bug, not the defence. Three rules now hold. (A) A header may be at most 10 s ahead of the node's clock (FUTURE_TOLERANCE_MS, Kaspa's 132 s kept only as the past-median window size) and at least its selected parent's timestamp minus 10 s (BACK_TOLERANCE_MS) beside the past-median rule, so every forgery is inside half the solvetime cap. (B) Every chain step of the short and epoch lanes is measured on a sanitised clock stored per header, c(b) = max(c(p) + clamp(t(b) - c(p), -20 T, +20 T), t(b) - 60 T), step = min(c(b) - c(p), 20 T), so forged steps telescope and are paid back by the honest blocks after them instead of cancelling to zero. (C) Both rule paths bound the output at 2^128 (bound_target), so block work stays under 2^128. Measured after the fix, simulator, seeds 7 to 9: the forger at 30% or 50%, earliest, latest or alternating, drifts the rate +0.4% to +1.1% after an hour (worst seed +2.7%, difficulty ratio 1.00, worst gap 10 s); the base profiles move by under 10% on the 3-seed means (down50 faster, polluted peak 12x against 8x, hopping and the record unchanged within noise); the flood stops at 2^128 after about 2,630 blocks with no panic (unit test). Test network, 3 igneumd nodes, 50% forger for 15 minutes: earliest allowed stamps, chain rate 0.82 blocks/s in the honest phase and 0.88 during forging at difficulty 102k to 100k (last five minutes 0.83 at 106k); latest allowed, 0.78 to 0.89 at 102k to 97k; 0 rejected of 986 and 1,028 blocks, delivered hash unchanged (A 0.110 and 0.112 MH/s, F 0.109 and 0.111); the 3 October rule on the same schedule fell to 0.24 blocks/s at 275k and 0.59 at 170k. Either part alone fails: the bounds without the clock still lose 36% and 83% to past-stamping, the clock under Kaspa's 132 s bounds collapses at 50% (the clock's lag is a martingale once the forgery range exceeds half the cap).

Evidence: docs/bench-log.md, 4 October 2026 "difficulty rule: timestamp attack fixed"; docs/analysis/difficulty-2026-10-03.md addendum (before and after table); sim/difficulty/attacks/README.md; unit tests igneum::tests::sanitised_clock_telescopes_a_forged_stamp, difficulty::tests::igneum_clock_steps_pay_a_forgery_back, difficulty::tests::igneum_flood_at_85_blocks_per_second_stops_at_the_minimum_target, difficulty::tests::both_rules_share_the_target_floor. Review ids: attack README scenarios 3 and 7.

Proving v0 findings (4 October 2026, afternoon): stated, not fixed

P21. The SP1 proof is not what consensus checks in proving v0

"Your proof records pay provers, and the node pays a record whose statement matches its own execution whether or not the SP1 proof behind it verifies. A prover can sign the native statement without proving anything."

Status: Open, stated in spec 7.7 item 4 (4 October 2026). Branch proving of the fork, igneum/exec/src/proving.rs.

Answer: Correct for v0, and by design for now. The consensus check on a carried record is the native-execution veto (spec 7.2 item 5): the statement must equal the node's own 328-byte shard statement for that shard and payout address, so no record can move state or pay for a wrong claim. The SP1 proof is verified off the consensus path by the proof pool's verifier (igneum-prove-host --mode verify), and a producer offers only verified records to its templates; a producer that includes unverified records (trust mode, test networks only) can pay a prover who did not prove. The damage is bounded to that prover's payout. What closes it: the aggregated segment record of design 5.4 verified in consensus, which needs the SP1 verifier inside the node (the SDK dependency the node does not carry today) or a bounded in-consensus verification budget. Until then the devnet runs v0 with every producer verifying.

P22. The rewards and payouts are inputs to the shard proof, not outputs

"The shard guest takes the segment's rewards and the prover payouts as data and commits the post-root after them. A host can feed any list and the proof still verifies."

Status: Open, stated in spec 7.7 item 6 (4 October 2026).

Answer: Correct, and already true of the rewards since devnet v4 (BlockFixture.rewards, proving_pool_credit): the shard statement is "from this pre-root, these transactions, these rewards and payouts, the post-root is X". The node checks the statement against its own execution, which used the rewards and payouts consensus derived, so a proof over a different list does not match any node's statement and pays nothing. Closing it in the proof itself means the aggregator deriving the rewards and payouts from consensus data it verifies (the mergeset's blue blocks and the carried records), which is the consensus-proof work of design section 7.

Status updates, 4 October 2026 (branch fin-fixes, commit da1eb889)

• F17 (keys are free, the draw is per key). Status: Fixed in the node (4 October 2026). is_aggregator draws the 8 aggregators by weight, output x total < 8 x weight x 2^64, so a splitter holds the tickets its weight buys and no more; spec 3.10 S1 row; unit test sortition_is_by_weight_not_key_count (200 dust keys plus 6 real ones); attack harness scenario 2 re-run: honest keys drew 1.61 seats per crowded checkpoint against 1.55 expected by weight, where master drew 0.32 against 0.33 per key (docs/bench-log.md, "finality fixes F17 and F1"). Still open from this entry: the client's one-key default, S2 (O-3.5), the bitmap size (O-3.12). Was: Rule fixed (spec 7.2 and W6), node per key.
• F1 (finality is attackable for the first month). Status: Fixed in the node on spec 3.8's recommended rule (4 October 2026); the litepaper statement and the launch-month simulation (O-3.1) remain. min_daa = weight_window (2,592,000 DAA s on mainnet, 7,200 on devnet): no checkpoint certifies and no certificate is accepted while the window behind it is younger than its full length, and the node reports "finality not active, window filling, N of M"; spec 3.10 C5 row; unit test no_certificate_while_the_window_is_filling; attack harness scenario 5 re-run: master locked checkpoint 1 at DAA 29 by the burster's key alone (1 of 1 voters, 22 of 22 weight), fin-fixes locked nothing under the window and first at checkpoint 61 (DAA 1,829) with 5 of 6 voters (docs/bench-log.md, same entry). Was: Conceded, not yet stated in the litepaper; experiment and rule change scheduled.

Status updates, 4 October 2026 (the floor raised to two thirds, O-3.15; branch devnet-v4)

the project lead's decision of 4 October 2026: the total-weight floor of Q3 is 2/3, not 17/30. A lock needs two thirds of all 30-day weight signing (the active test is implied), and finality pauses whenever less than two thirds of the weight is connected and signing; the chain continues on proof of work meanwhile and the node reports it. Spec 3.3, 3.3.1, 3.7, 3.9, 3.11; sim/results_v2.md, "Floor 2/3"; docs/bench-log.md, "finality floor 2/3"; litepaper Finality and "What Igneum does not claim".

• F2 (the two-hour presence window is an eclipse vector). Status: Closed by rule, floor raised (4 October 2026). A lock needs two thirds of total weight whatever the presence window says, so an eclipsed faction can lock only with two thirds of the network inside the eclipse, which is the twenty-day public event of spec 3.1. Re-measured at the 2/3 floor: the poisoned eclipse (34% attacker plus a 20% pool, the eclipsed side at 54%) gives 0 conflicting locks and 0 locks on the eclipsed side at 1, 2 and 4 h in every seed (sim/results_v2.md L3 and F2's floor1.00 rows). Was: Closed by rule (the 56.7% floor).
• F16 (a lock can become uncertified after a heal). Status: rule unchanged (spec 3.11.4: a verified certificate is never withdrawn, O-3.17 implements the conflict report). What the floor changes is how the state F16 describes arises: two certificates at one index now need equivocators holding at least one third of total weight in every scenario (two certificates need 4/3 of weight in signatures), not 13.3% across a partition that outlasts the presence decay (sim/results_v2.md H at 2/3: 0 conflicts and no lock on either side through a 33% equivocator, conflicts from minute 0 at 34%). Ten days of 100% hashrate in public, or the long-partition case of F21.
• F18 ("a silent minority cannot freeze finality" is false under the floor). Status: Fixed again (4 October 2026). The litepaper now says a lock needs two thirds of all 30-day weight and that finality pauses whenever less than two thirds is connected and signing. The pause threshold moved from about 42% of weight silent to one third: in the model, whose keys are in outage 2.2% of the time, 30% silent locks every checkpoint, 32% locks 88%, 33% locks 11% and 34% locks none for as long as it stays silent (sim/results_v2.md L1). Was: Fixed (56.7% sentence).
• F9 (half the hashrate leaves and finality stalls for ten days). Status: Conceded, stated (4 October 2026). Under the 2/3 floor the critic's number is back: 50% churn pauses finality for 10 days and 35% churn for 1.4 days, until the departed weight ages out of the window (sim/results_v2.md D's total column, which the 2/3 floor equals arithmetically, and L2). The chain runs on proof of work meanwhile, the node reports the pause, and the litepaper says so. This is the price of the one-third safety bound and was taken knowingly. Was: Answered by design (the active denominator recovered in two hours).
• F21 (new, from attack scenario 6A). "Your floor is a fraction of a table each side computes for itself. Cut the network in half and leave it cut: after a while each half's window is full of its own blocks, each half holds two thirds of its own table, and both lock without any attacker at all. Your simulation never saw it because it kept the weights global." Status: Fix built, pending rollout (4 October 2026, evening): rule v3, spec 3.3 Q5, the frozen weight table, on the node's finality-fixes branch behind finality_v3_activation_daa (docs/plans/finality-v3-rollout-devnet.md). The rule: a certificate also needs its signers to hold two thirds of the weight table at the last certified checkpoint on C_i's chain, at that table's weights, while that checkpoint is less than one window old. Both sides of a partition share that table and neither can fill it, so no side under two thirds locks until 30 days have passed without a certified checkpoint; at the heal locking resumes on one chain. Proved first in sim/finality_v2.py scenario M (sim/results_v2.md, "Rule v3"): 50/50, 60/40 and 55/45 splits never lock in 12 days (v2: days 10.2, 5.2, 7.9), both sides of a 31-day split lock alone at day 30.00 when the frozen table expires, the 70/30 majority locks at once under both rules, every pre-heal lock is kept and the first lock after the heal comes 0 minutes in, the 34% equivocator still conflicts (the one-third bound of 3.11.2 is untouched). The price, stated in 3.7 item 2: a set of one third or more that stops mining and signing at once pauses finality for 30 days (v2: 1.7 days at 35%, 10.1 at 50%); a gradual departure costs nothing because every certified checkpoint re-freezes the table. A view still cannot count blocks it has never seen, so a partition longer than a window forks as before; the fix moves the bound from a third of the window to the whole of it. Node: processes::finality (frozen_table, the Q5 test in evaluate), unit test frozen_table_holds_a_side_without_the_other_keys_for_one_window; network figures in docs/bench-log.md, "finality rule v3". Was: Conceded, stated (4 October 2026): spec 3.3.1, 3.7 item 9, 3.9 guidance; sim/results_v2.md L4 (view-local weights). Correct. A side with pre-split share s holds s + (1 - s) t / 30 of its own table on day t and two thirds of it from day 30 (2/3 - s) / (1 - s): day 10 at 50/50 (day 4 under the old floor), day 5 for the 60 side of 60/40 (at once under the old floor). On the devnet the old floor fell at 84 s of a young 1,439-DAA window (docs/bench-log.md, "finality v2 attack harness", S6A); at 2/3 the same cut on a full 1,800-DAA window held for the whole 150-s split and fell at 205 s against a predicted W / (3R) = 200 s (docs/bench-log.md, "finality floor 2/3", 6A and 6A long heal). What the devnet adds to the simulation: after the heal the other side's blocks are merged red, so each side's own share jumps rather than drifts, both sides of a 50/50 split certify their own checkpoints within 10 s of each other, and F1 then pins each node to its own certified chain: 26 conflicting certificates and 23 disagreeing locked indices across three nodes, no equivocation, a finality fork that the network heal did not undo and that only an operator's trusted certificate (F5, not implemented) can resolve. No rule removes it, because a view cannot count blocks it has never seen; the floor at two thirds moved the day from 4 to 10, and the exchange guidance treats a node partitioned for more than a day as proof of work until it has rejoined. A rule option for gate 3, not adopted: evaluate the floor against the table of the last locked checkpoint while no newer lock exists, which trades F9's 10-day recovery for a manual override.

M24. Your two-lane controller oscillates for an hour when a second miner joins mid-epoch

"Watched your devnet this morning. The second 5090 came in at 10:12 and the difficulty never settled: 102M to 164M for forty minutes, 54 to 81 blocks a minute, three or four clamp steps stacked inside a second. Your fast lane and your slow lane disagree by a hair under the trigger and the rule flips between them every two minutes. One card joining is the mildest event a chain can see."

Status: Fix built, pending rollout (4 October 2026). Was: Open (10:46 UTC, 4 October 2026, the live finding).

Answer: Correct, measured on the live chain and reproduced in the simulator (docs/analysis/difficulty-2026-10-04-oscillation.md). The cause is the reference lane: spec 2.3 of 3 October gave it the whole epoch, so a hash-rate step inside an epoch left it polluted by the pre-step blocks for the rest of the hour; the short lane read the true rate 11 to 25% above it, the 25% trigger flipped between the two on the short lane's noise, and the per-block clamps turned every flip into a ramp (3% a block up, 10% a block down). The DAG replay (sim/difficulty/sim.py --live, miners on two nodes with igneum-miner's template staleness, GHOSTDAG, the rule as the node runs it) reproduces the record: std of log difficulty 0.115 against 0.134, 4.3 peaks of 1.31x against 4 of 1.37x, 104M to 169M against 102M to 164M, 54 to 77 blocks a minute against 54 to 81. The brief's five candidates (longer short lane, 3% ease clamp, one clamp per DAA second, hysteresis, median of three) each leave it between 0.09 and 0.13 because none of them cleans the reference lane. Rule v2 caps the reference lane at the newest 600 DAA score of the epoch (the epoch lane only; Kaspa's sampled window is not consulted): 0.026 with 0 lane flips and the target on the true level (142.6M against 139M) on all three seeds; the chain-only simulator agrees (0.14 to 0.19 against 0.02 to 0.08). Cost on the synthetic set (seed 7): steady std of the block rate 0.049 against 0.038 (blocks per minute CV unchanged, 0.130 against 0.135), the 50x step-up settles in 65.5 s against 61.7 s, the 50x step-down 753 s against 629 s, hops slightly faster, the polluted window's overshoot halved. Under attack (attacks.py, seeds 7 to 9): the greedy hopper gains one more point (at most +2.5% against +1.5%), the forger's drift falls to within 1% (worst seed 1.5% against 2.7%), the pulsed rental, the epoch games and the polluted window are unchanged, the 50x step-down is 8% slower and the steady estimate a quarter noisier. Built behind a height switch, difficulty_v2_activation_daa (a consensus parameter, default never, set by the override file), so the devnet moves to v2 at a chosen DAA score on the same chain. The epoch boundary itself clears the pollution, which the live chain showed at 11:02 UTC (DAA 7,200: within 1.3% per minute from 11:07 with no flips, the hash rate having also stepped down there).

Evidence: sim/difficulty/records/live-2026-10-04.csv and live-2026-10-04-hashrate.csv; sim/difficulty/results.md "Live replay"; docs/bench-log.md, 4 October 2026 "difficulty rule v2"; unit tests difficulty::tests::reference_window_switches_at_the_activation_height, difficulty::tests::v2_reference_window_follows_a_step_inside_the_epoch_where_v1_eases_into_it, difficulty::tests::v1_and_v2_agree_in_a_steady_epoch, params::tests::override_params_carry_the_difficulty_v2_activation. Rollout: the bench-log entry names the binaries and the order (Hetzner chain first, then the devnet nodes with the activation DAA in their override file).

---

9. Developers and apps (4 October 2026)

Added 4 October 2026 from docs/design/developer-adoption.md (section 6, ten reasons a founder says no). Only the conceded objections are entered; the answered ones are in that document with their evidence. Entries are numbered D for developers.

D1. Your users are a gate, not a fact

"The miners are your user base? Nine devnet identities today, a 1,000-miner testnet gate whose word 'independent' is still undefined (X5), and miners are the most mercenary users of all: they sell."

Status: Conceded, stated.

Answer: Correct on the count and on the definition. The claim in docs/design/developer-adoption.md section 2c is narrower than "users": miners are funded wallets that are present and have a continuing reason to transact (they are paid every block and pay power bills), which gives a specific set of apps (pools, payout contracts, hardware finance, hashrate forwards) a customer before any consumer app has one. Loyalty is not claimed. The number that makes the claim real is the testnet gate, with O-X.1's definition of independent.

Evidence: docs/bench-log.md 4 October 2026 (devnet v4, 9 identities); site/journey.json phase 5; ledger X5.

D2. The app share pays nothing

"Run your own table. A 100,000-gas call at your devnet fees pays the app 20,000 gwei, four ten-millionths of a dollar at your base price. A million calls a day is $146 a year. 'Apps earn the gas they generate' is the Canto pitch, and Canto's chain has $1.4M of lending TVL."

Status: Conceded, not yet stated. Fix: the litepaper bullet "Apps earn the gas they generate ... Canto and Blast proved builders come for this" is replaced by the "Why build here" text proposed in docs/design/developer-adoption.md section 7, which states the number.

Answer: Correct. The app share is a property of the fee flow, not an income at launch: 20% of the priority fee, per call frame, and the priority fee on an uncongested chain is whatever wallets quote by default. At the three price inputs of docs/analysis/security-budget.md and a 1 gwei tip, a million calls a day pays $146, $730 or $7,300 a year (the last at a 10 gwei tip). What is new in it against Canto and Sonic is library attribution at the code address and factory inheritance, and the fact that it comes from the user's tip and never from emission. The 20% should not be raised: Sonic's 90% has distributed about $2M in a year across a whole chain, and a larger share comes out of the miners' and provers' side, which is the security budget. Blast announced its shutdown on 2 October 2026, so the sentence citing it must go now.

Evidence: docs/design/developer-adoption.md section 2a tables; docs/evidence.md row 22; docs/bench-log.md 3 October 2026 (execution layer devnet v3); MoneyCheck 3 October 2026 (Blast); DefiLlama via search 4 October 2026 (Canto).

D3. Proof of work in 2027 is a perception cost you cannot measure

"My investors and the exchanges I need read 'GPU-mined' as 2021. Whatever your proofs do, the label costs me."

Status: Conceded, no experiment possible.

Answer: Correct that the cost exists and that nothing in the design measures it. The argument the litepaper makes ("Questions builders ask": the energy buys a proof of every block as well as its ordering; no stake to capture, no builder cartel, no foundation that can change the rules) is an argument and not a measurement. The only evidence that will exist is whether rows 1 and 2 of the adoption sequence (miner apps, verifiable-compute apps) sign despite the label.

Evidence: none possible; site/litepaper.html "Questions builders ask".

D4. No dollar, no DeFi

"No stablecoin and no bridge at genesis. 'Native USDC is requested from Circle' is a request. There is no DeFi without a dollar, and your consumer apps cannot exist until phase two."

Status: Conceded by decision (ledger E7, spec 7.3), restated here for builders.

Answer: Correct, and the sequence in docs/design/developer-adoption.md section 4 puts consumer apps third for this reason: after mainnet, after a bridge run by a named operator, after a published record of the app share and the job market. The alternative, a multisig bridge the project labels official, was refused on 3 October 2026. The sentence naming Circle is a request about a third party and the round-3 review already asked for it to go.

Evidence: spec 7.3; ledger E7; docs/review/round-3-2026-10-03.md line 344.

D5. I cannot debug a revert

"No eth_subscribe, no debug_traceTransaction, no eth_getProof, no explorer, no public RPC, no faucet, finalized resolves to the executed tip. You are inviting builders to a chain they cannot inspect."

Status: Conceded, scheduled.

Answer: Correct on every item on 4 October 2026 (docs/design/execution-layer.md 10.3 items 1, 6, 7). The order in docs/design/developer-adoption.md section 5: docs and the Hardhat and Foundry templates first; debug_*, eth_subscribe and eth_getProof second, because the Blockscout fork and Foundry's debugger need them; a public devnet RPC, the chain-id listing on ethereum-lists/chains, wallet tests (R11) and a faucet third; the explorer fourth. No outside team is invited before the second step is done.

Evidence: docs/design/execution-layer.md 10.1 (RPC table, "Missing"), 10.3; design 8.1, 8.4, R10, R11.

D6. A forged job result reaches my contract and nobody vetoes it

"Segments have the native-execution veto. Jobs do not: full nodes cannot re-run an arbitrary program, so for a precompile job the proof is the only check. A soundness bug in SP1 writes whatever the attacker wants into my callback."

Status: Conceded, contained by rule, review scheduled.

Answer: Correct. Design 6 says it in those words. The containment: a job output cannot mint IGN or touch system contracts (R12), jobs are gated behind the proof-system version with the three-month overlap and the 90% signal (design 5.6), and the emergency path for a live soundness bug is the version bump of spec 5.7. The rule for an app, the same one the customer brief gives rollups: anything that acts irreversibly on a job output keeps its own fallback. R12 is reviewed with the cryptographer before devnet v2.

Evidence: docs/design/execution-layer.md 6, 5.6, 9.1 R12; spec 5.7; ledger P7; docs/commercial/prover-customer-brief.md "Risks".