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

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.

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

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

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.

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 15% developer share enables wash gas

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

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 15% and loses 85%. A developer who also mines the block including its own transaction gets 65% plus 15% and loses 20% of the priority fee plus the full base fee. 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: Answered by design, wording fix needed.

Answer: The fund takes 5% of the priority fee (the base fee is burned in full), and 5% of external job fees, and no emission. Spending needs 60% of hashrate signalling over two weeks. The litepaper says "5% of gas" and should say "5% of the priority fee". Whether a fee-funded, miner-controlled fund is a "tax" is a word choice; the number is 5% of tips.

Evidence: design doc Finality v2 "Fees". Fix: overclaims list, item 56.

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. The design doc also says the founder's company carries development from that fee, its pool and its proving business until usage funds the development fund. All of that must be in one place in the litepaper under a heading a critic can quote.

Evidence: design doc "Funding development for ever without taxing miners". 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: 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 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 says a second independent client is the development fund's first priority. 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.

G7. The one-click app is an update key over the network

"An app that auto-updates on ten thousand machines is an admin key. Whoever signs the update controls the miners, the wallets the app made, and the vote keys."

Status: Open, policy scheduled.

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. 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: 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, 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. UK financial promotion rules

"The founder is in the UK. Since October 2023 a cryptoasset promotion to UK consumers needs an authorised approver. 'The people who show up early get the most' on a .co.uk you own is a promotion."

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 a UK opinion). 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. igneum.co.uk redirects to igneum.network and should keep doing so.

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.

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.

X6. The one-click app is a honeypot vector

"An installer that creates a wallet, holds keys and mines, promoted to people who have never run a miner. Fake copies will be the first Google result. Defender flags every miner as malware."

Status: Open, policy scheduled.

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	14	M3, M12, F4, F9, F11, F12, F13, P9, E2, E3, E4, C1, C12, L6
Open, experiment or decision scheduled	19	M1, M5, M6, M11, F2, F3, F7, P3, P5, P8, E7, G7, C4, C9, L1, L2, L4, L5, X6
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."

39. LP building: "Canto and Blast proved builders come for this." Replace with: "Canto's contract-secured revenue and Blast's gas sharing showed builders respond to it."

40. LP building: "Stablecoins at genesis. USDC and USDT bridged through the proof bridge, canonical versions on Igneum, the way Arbitrum and Base launched." Replace with: "Stablecoins. USDC and USDT bridged to Igneum as canonical versions. Whether the genesis bridge is proof-verified or committee-attested is decided in phase 4 and will be labelled."

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 and the development fund contract 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 development fund's first priority and 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" Replace with: "5% of the priority fee and 5% of external job fees go to a development fund"

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.

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 UK promotions opinion.

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