Every criticism, answered or conceded

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Correct. The draw hides (M, R, pos, the op weights within +-2, the fold rotations) until 2 hours before each era, and none of those needs silicon. Biasing the draw is priced at 20 days of 100 percent of the network's hash for one more sample of the same space (lane section 5.4), so the draw is unbiasable at any price that matters and that is its whole job: it is a fairness device and a fork-free schedule, not a chip defence. What a chip wired for one program loses to is the hourly program itself; what the stored-dataset chip loses to is the latency shadow (class v4, 2.1x per joule at k = 1 and 3.9x at k about 0.33, the X9’s core, against the 5090 bench row; 0.9x and 1.7x against the Apple M5 Max; recalibrated under X35) and the price per joule, which is where the public claim now rests.

Correct. The measured 2.4 G/s had been read on 6 October as a mapping artefact ("the paper's point is that this mapping is the wrong one for random access"); the activate window says it is the DRAM's own limit, and a bank-interleaved mapping does not lift it because tFAW is enforced per channel by the die. The measurement that settles it is one AWS F2 hour (f2.6xlarge, Virtex UltraScale+ VU47P, 16 GB HBM2 in 2 stacks, 32 pseudo-channels, USD 1.98 an hour on demand): the chase kernel of a repository file 2.2 ported to a Vitis HLS AXI master over the HBM IP at 1 GiB across all 32 pseudo-channels, 256 to 4,096 lanes in flight, board power at 1 Hz; pass line 15 to 25 M reads/s/W (0.3x to 0.5x of the 5090), alarm 27 (0.5x), over 54 (1.0x) a Counter ASIC 4.0 item. Consequence per tier: none today (no FPGA mines); on the measured row a soft-overlay FPGA mines at an RX 9070 XT's rate per watt for about 7x the price (approximate), so no home or rig tier is displaced.

Correct on both counts, and the second was the sharper one. The X9 (Bitmain, about 1 MH/s at 2,472 W, approximate, github.com/monero-project/monero/issues/10270) is a shipped 3x per-joule edge over a desktop CPU on the best-known latency-bound random-program design, seven years after launch; it makes the k = 0.3 column of the chip model a product class rather than an attacker's claim, and the public headline is now the range 2.1x (k = 1) to 3.9x (k = 0.33) over the RTX 5090 at class v4, with the ladder taking the X9 bracket to about 2.8x by rung 2 and the Apple tier's to about 1.1x by rung 3. The ladder does not close the gap; it is the chain's only automatic answer, it moves at the pace of the cards that pay for it, and the honest card's watts remain the lever that moves every row (algorithm lane proposal 7). What the ladder gives up by design: a chip holding over 10 percent of weight can stall it, and the status quo it stalls is a rung the cards already run.

The first sentence is right and the page says it first: anything the lottery derives is derived from a seed and the state, so the only bytes a central node cannot compress away are the state's, 5,952 bytes at today's devnet state (93 records), and the chain cannot distinguish a card that derived the leaves from one that received them, exactly as it cannot distinguish a pool member from a solo miner today. The numbers are on the page: the leaves pass 45 MB per member per hour, the line where a WAN pool at 1 Gbit/s serving 10,000 members can no longer ship them inside the window, at about 700,000 state records; a LAN farm at 100 Gbit/s is never bounded below the 2 GiB sample cap. What the class does force, per machine and per hour: holding the current state or its leaves, a rebuild from it (32 ms on a 4090, measured on 6 October), and knowledge of the chain's reference block inside the ten-minute lead; a machine cut off from the chain for an hour stops producing valid blocks at the next refresh, where under a daily rule it kept mining until midnight. It also removes the recompute chip (the f = 0 row of chip-model-v3) as a category and moves nothing against the dataset-storing chip, which the page and the litepaper both say. The cost is measured and small (hash rate and watts unchanged on the 4090, build +1.4 ms resident, verifier +0.11 to 0.21 ms per unit); the risk is the serialisation, which is why the stream must rebuild to its root on the capturing node before it is served and why the gate crosses a day boundary with a non-trivial state before Devnet 2.

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.

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.

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.

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

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.

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.

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.

Correct. a repository file 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.

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.

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.

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.

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.

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.

Correct. The weight is a quantity that is at stake, earned by work alone over 30 days, not transferable, not purchasable, and already stripped in full for equivocation (spec 3.6). That is a slashable bond made of blocks, with no coin and no stake class; the "then it is stake" objection and its answer (the weight cannot be bought, borrowed or bridged, so capture by capital is removed; the last-days attack is bounded by the 30-day re-earn) are in the lane file, section 4.1. Extending the strip to execution-layer faults (the lane's 3.2) is an idea, not a rule, and the public text does not claim it.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

Correct; it is P21's finding read from the payer's side. The fix is the security lane's proposal 1: a record whose aggregated segment proof does not verify against the pinned aggregator key is invalid in consensus; the per-shard v0 record stays payout-only until then and is capped at the exclusive window. Consequence per tier: no honest miner loses anything today, since the pool is paid per valid record and the devnet's producers are the project's; the risk is a dishonest producer at the public testnet, which is why the fix lands in 0.3.16, before it.

Correct. The lane's simulation puts a ten-day refusal at 5.5 M IGN stranded (section 4.2: the pool share paid falls to 0.67 with 0.33 stranded during the refusal, 182,387 IGN a day averaged); the devnet already burns the coinbase's 20% output at an unspendable script, so nothing is lost that was ever claimable today. The rule: an unproven shard's credit rolls forward into the next proven segment's pool instead of sitting in the escrow. Consequence per tier: a prover sees a larger pool after a refusal instead of a smaller one; nothing changes for a miner or a pool user.

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.

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

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.

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.

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.

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.

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.

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

Correct. The whole public proving market is three to four orders of magnitude under year-1 emission at any price input (the lane's table: Ethereum L1 at the Sep 2026 cost USD 36 a day, at the Dec 2025 cost 288; year-1 emission 13,700 at USD 0.005, 54,800 at 0.02, 273,800 at 0.10). The cost curve falls 3x to 30x a year, so dollars per proof fall as fast as volume rises. The design's own claim stays the defensible one: a second income that keeps cards on after the subsidy fades (spec 5.10.2), never the main one by 2030.

Correct. Electricity is under a cent per billion cycles on every card; the price is h/N x the subsidy per shard. At 100 GH/s a card proving alone is at 1 to 3x the published market and a card beside its miner at 0.2 to 0.4x, the only row where Igneum undercuts the market, and it rests on the 4% hash loss measured on one card. Consequence per tier: at launch a home miner earns more hashing than proving for outsiders at any card size; a rig the same; the proving market is upside for the fleet as a whole only as network hash grows.

Correct. The fee block carries the dev address in the producer output only; the 20% pool output and the per-record escrow are untouched, so the fee's base is 80% of emission. Consequence per tier: a miner on Ember with the fee on gives up 1 in 100 of its own block rewards and nothing of its proving pay; off with one flag, the same on every tier.

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

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.

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.

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.

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.

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.

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.

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.

Correct. The three numbers are three different things: a parameter is a dial inside rules genesis fixed, an upgrade is new code every node must run, a class change moves the hash itself and so takes the highest bar with a floor height as the backstop against a holdout. The lane's game (section 4.3): a 6 percent holdout costs near zero and buys only delay to the floor; a 30 percent pool holds a veto over upgrades at 90 and over class changes until the floor.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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

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.

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.

True. the US registrar and the host 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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

Correct in mechanism and unmeasured in size. a repository file 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 (a repository file, "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 (a repository file 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).

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. a repository file 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.

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

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 a repository file as open), measured on a mixed rig through 24 epoch changes (O-1.16). Extends M11.

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.

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.

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; a repository file 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.

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.

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.

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.

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.

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. a repository file 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.

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

Correct. a repository file 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.

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.

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

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.

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

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; a repository file'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.

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.

Correct. Fix: a repository file, "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.

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

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

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.

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

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

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

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 owner'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.

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.

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.

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, a repository file, script a repository file): 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: a repository file, "finality rule v3".

Correct. P1 conceded that the 20-s figure is a target; this is about how the target is tested. a repository file 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.

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

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.

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

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.

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.

The fact is conceded in X1 (the repository is private and the site says reproducible) and the pre-publication steps are in a repository file section 5 (ledger out of the tree, the project rules file 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 a repository file/, each labelled experimental, with the node fork following when the gate-2 work is in. the owner 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.

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 owner's call and needs the entity, terms and tax treatment of L4 first.

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.

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

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.

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

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.

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.

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.

Correct on every point, and measured first by our own attack run (a repository file, 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).

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.

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.

Correct, measured on the live chain and reproduced in the simulator (a repository file). 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 (a repository file --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).

Correct on the count and on the definition. The claim in a repository file 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.

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 a repository file 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.

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.

Correct, and the sequence in a repository file 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.

Correct on every item on 4 October 2026 (a repository file 10.3 items 1, 6, 7). The order in a repository file 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.

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.

Correct. relay/lib/relay.mjs:33-42 returns a truthy value for either secret and relay/api/relay.mjs:111-124 accepts kind: run with flags.elevated from it; relay/clients/igneum-agent.ps1:165-166 runs every item returned, as administrator, within 20 s. README.md:7 and make-clients.sh:8 make RELAY_KEY the intake key. The hosted igneum-relay-clients.zip carries the relay token and the key in four files; the dl token that guards it is 0644 on the Apple M5 Max, in commit c47ff03, and in igneum-app.json of every install. Fix, in order: the zip off the host; rotate the relay token; a relay key of its own; a second per-machine secret or an Ed25519 signature over {id, to, body} for run; rotate the intake key and repackage. Review ids R4.4.1, R4.4.2, R4.5.1.

Correct. relay/vercel.json:6 rewrites /r/<token>/api/<fn> to a query string; igneum-agent.ps1:14, send.ps1:26, send.sh:11, agent.sh:10 and a repository file all build the tokened URL, and a repository file,88,125 print it. Referrer-Policy: no-referrer and X-Robots-Tag are set (vercel.json:12-13); there is no HSTS. Fix: the header in every client, the URL token kept for the phone's page only, HSTS, and the print lines masked. Review id R4.4.3.

Correct. Arm-Restart (igneum-agent.ps1:68-79) runs at :154 on every start; README.md:42 describes it as the reboot_continue path. Fix: arm only when a task asks for a reboot, and remove the task and the key on a clean exit. Review id R4.4.4.

Correct. ITEM_COLS (relay/lib/relay.mjs:92) includes body; feed returns up to 500 per call with no retention and no cap; delete leaves blobs. a repository file substitutes __DL_BASE__ with the tokened base and playbooks/miner-v4.ps1:12 and prover-setup.ps1:12 print it into the transcript. Today's 12 items hold 0 copies (count-only). Fix: retention (30 days), a cap on feed, the dl base passed as an environment value the agent holds rather than text in the body, blob deletion with the row. Review id R4.4.5.

Correct. authed() has two independent secrets with equal power; insertItem takes from as free text (relay/api/relay.mjs:30); register creates rows for any hostname (:148-162). Fix: the relay's own key (X23), from bound to the registered machine for result and register by a per-machine secret, and a documented rotation (token, relay key, intake key) with what each breaks. Review ids R4.4.6, R4.4.7.

Correct on each point: relay/lib/relay.mjs:38,40; relay/vercel.json:8-16; relay/api/relay.mjs:85; igneum-agent.ps1:133; :145; no limiter in either function; relay/playbooks/wsl-setup.ps1:39-40 and prover-setup.ps1:21; igneum-agent.ps1:41, :113; the stray file next to desec-token (3 Oct 19:33). Fix when convenient; the stray file today. Review ids R4.4.9 to R4.4.13.

Correct. .github/workflows/windows.yml (step "payload inputs") checks the zip against a sha256 served beside it; a repository file takes the latest green run and calls a repository file by default; the node fork is not in the repository the runner builds, so spec 08 item 4 has nothing to reproduce from. Fix: a detached Ed25519 signature over payload-inputs.zip made on the Apple M5 Max and verified in CI before the build; OTA_SKIP=1 by default with the signing step naming the run id it signs. Review id R4.5.2.

Correct, count-only. The key: a repository file, a repository file, a repository file, prove-shard.sh, a repository file, a repository file, commits 78df757 to 4c9810f. The token: a repository file, commit c47ff03. git check-ignore returns nothing for the ledger, fixes and review files. The CI identity grep covers the public export list, by design. Fix: both secrets join section 5 step 4's rewrite list (and are rotated regardless); TZ=UTC in the commit path now. Review ids R4.4.8, R4.5.3, R4.5.4.

Correct, measured. The red-team run's first scenario errored on it (a repository file, "Tooling defect"); a repository file already edits the file as text for this reason. Scenario 2 live probe: past floor pmt+1, future flip between +130.00 and +130.01 s of the probe's own offsets, every stamp from +10 s rejected; the node is right, the criterion is stale. Smallest fix: in a repository file and a repository file overrideParams, drop the two sentinel fields before stringify (absent means never) or splice the extra fields into the file text; in a repository file, probe max(pmt + 1, parent - 10 s) and the +10 s bound. Also stale: a repository file waits for an over-budget transaction to be included and skipped with BlockProvingBudget; since F-exec-B the mempool refuses it with the metered pgas, so the check should accept ProvingGasAboveBlockLimit from the pool (a repository file row 28). And a repository file scenario 5 compares the burster's share of the weight window with its share of the whole run, which only agree when the run is shorter than the window (row 17).

Correct. blockrelay/flow.rs:201, router.rs:215-224, flow_context.rs:819, peer.rs:13; virtual_processor/processor.rs:1663-1670 (merged in baa8bc8a); pow_guard.rs:28. The 10 s bound itself is right in shape (two constants, both directions, not overridable). Fix: one WARN from time_offset at handshake, the attack switches behind a feature flag, the dead field refused. Review ids R4.1.6 to R4.1.8.

Correct. processes/finality.rs:413-421. About 3 x 10^12 store reads at a 10^7-block chain, approximate. Fix: start from the last certified index carried in headers, walk once. Review id R4.1.10.

Correct. a repository file; consensus/core/src/igneum.rs:156-172, 198-204. Fix: the day length in the template; one atomic struct swap. Review id R4.1.9.

Correct. a repository file with the update at :1452-1454 skipped by continue; the restart has no cap and no growing back-off (:1213-1216). A slow first interval (a game on the GPU, a foreground self-heal build on a slow card) is enough. Fix: update the baseline on a trip, or compare to the previous interval; cap restarts with a growing back-off. Review id R4.2.1.

Correct. a repository file, 1337-1339; worker.cpp:644-658; host.c:1208-1225. Estimated loss 30 to 60 percent against a node that alternates seeds per template; a stale home node on a fork is the realistic trigger. Fix: at most one prepare per pair per epoch and none within 30 s of the last. Review id R4.2.2.

Correct. packfile.h:~262-283, 306-345; worker.cpp:414-416, 596-620; emu/test.sh:57-66. The CPU re-check (main.rs:1250-1256) stops a wrong program from earning, not from running. Fix: a hash of the emitted kernel in program.json, derived from the seed by the miner and checked by both workers; one sentence in the docs that the chain commits to the seed, not the text. Review id R4.2.4.

Correct. a repository file; a repository file:~1762-1780 (zero matches for either string). The PowerShell launcher matches them (igneum-common.ps1:843), which is what README.txt and TEST.md describe. Fix: stop the worker after 3 consecutive mismatches and show it on the card; the app reads both fields. Review id R4.2.3.

Correct on each: engine.rs:~2047-2055 and emit.rs:1156-1163; main.rs:1206-1228; worker.cpp:684-703; main.rs:~581, 893; main.rs:1373-1380 with engine.rs:~1405-1411 (the 14:20 export during IBD, bench-log). Each costs a restart, none loses the run. Review ids R4.2.5 to R4.2.10.

Correct for the live devnet-v4 line. coinbase.rs:112-113; consensus/core/src/igneum.rs:86-98, 329-333; evidence row 21. Proving v0 on the proving branch carries payouts in the shard statement (P21, P22) and the live chain does not run it. Until it does, a prover earns 0 from the pool and the spendable cap is 3.2 billion. Fix: one sentence in the litepaper Economics table (a repository file, 414) and under the homepage bar (a repository file, 446-448): burned until the payout ships, no prover paid today; a burned-so-far figure on the live page; a decision on whether the payout reclaims the burned share or pays from new emission. Review ids R4.7.1, R4.7.2.

Correct. a repository file, 382, 446-448; grep for "no value", "reset", "wiped", "test coins" across site/*.html finds nothing; the only disclaimer is the app's welcome screen (a repository file). Fix: "devnet: coins have no value and the chain may be reset" beside the button and on the live page; the homepage tiles match the litepaper's dev-fee sentence. Review ids R4.7.3, R4.7.5.

Correct. a repository file; the app's sources have no earnings, currency or hardware-wallet path (grep of src/*.rs and ui/app.js); the prover service exists for the proving branch's chain. Fix: rewrite the paragraph to 0.3.3 (hash rate, blocks, devnet label, power cap, the prover setting where it applies) and move earnings, currency and the hardware wallet to a roadmap sentence. When an IGN figure is ever shown, derive it from accepted blocks over the last hour times the per-block subsidy, never from hash share, and label the network. Review id R4.7.4.

Measured, cause not yet isolated. What changed between the two builds is the execution layer, which this node links: a repository file keeps every ChainBlockRecord in ExecState.records (:304, :419, pushed and never truncated) plus tx_index and inclusions maps per transaction, and the mempool flood's 14,998 rejected transactions cost 270 MB, so rejected transactions are retained somewhere too. Smallest fix: bound ExecState.records to the record window plus the pruning depth and drop tx_index/inclusions entries with them; discard a rejected transaction's bytes at rejection; then re-run a repository file s6 and s7 and require growth under 50 MB, the 3 October figure.

Measured on the execution-layer attack network (a repository file runs --simnet with no override): three nodes up, 0 blocks, every template refused with that line (a repository file row 27). Smallest fix: set max_coinbase_payload_len: MAX_COINBASE_PAYLOAD_LEN_WITH_FINALITY on the three other networks, and add a unit test that builds a coinbase with a key reveal, the maximum record section and a full certificate and checks it under every network's limit. The red-team run worked around it with {"max_coinbase_payload_len": 16384} in an override file.

Correct on each point; a repository file section 7 holds the arithmetic. Fix: one nvidia-smi draw line per setting with the rate beside it on both PCs; one powermetrics line on the Apple M5 Max; the sim rerun at 124 MH/s with the comparison stated as a function of fleet size; "a million 100,000-gas calls a day" in the litepaper. Review ids R4.7.7 to R4.7.13.

The fee exists and is disclosed; the rest is wrong in three places. (1) It is software-level, not protocol-level: no consensus rule, coinbase rule or emission rule knows of it. The chain pays whatever payout address a block template names, and the miner software names the dev address for one template in 100. A different client, or the same client with --dev-fee 0 (a switch in the app's Settings, DEV_FEE=0 on HiveOS), pays nothing and the chain treats its blocks exactly the same. That is the norm for GPU miners (lolMiner, T-Rex, approximate as to their percentages) and the litepaper says so beside the words "the protocol carries no fee". (2) It is auditable, not hidden: the choice is a template counter, not a random draw. Template n (from 0) is a fee template when floor((n + 1) p / 100) > floor(n p / 100), which at p = 1 is exactly the templates 99, 199, 299, ...; the source is one function (fee_slot, a repository file, section "Software dev fee"), the miner prints dev fee 1% (1 block in 100) to 0x<address>; --dev-fee 0 turns it off at start, logs dev-fee block <hash> for each one and counts fee=N in its status line, and igneum-miner payouts <node> reads the chain back and lists blocks per payout address with the dev address tagged. (3) It takes nothing from anyone else's security: a fee block keeps the user's vote key, so the user's finality weight is unchanged; only the execution-layer payout of that block moves.

Correct. the RPC listen flag on the process (no --unsafe-rpc, --disable-upnp); ls -la a config file; a repository file (https_time, upload_log); the dl host's headers. the host rewrote Date to now on a cache hit today, so the cached-Date failure did not show. Fix: RPC on loopback with the Windows machine on a tunnel or its own node; chmod 600; the stray file removed; the key passed to curl through -K` or a header file; an uncacheable path for the clock source. Review ids R4.5.5 to R4.5.7.

Correct at discovery; fixed before this document was written. The evidence page was brought up to the day's measurements in 86e5857 and bf4d7ec (rows 29 and 30, rows 10, 12 and 15 restated).

The date was the plan of 3 October 2026 and the chain overtook it: the testnet genesis was fixed on 5 October, the three seeds and rpc.testnet.igneum.network are up, and the remaining work is the go checklist. Rows that quoted the month (X3, O-X.2's blocker note, overclaim item 75's replacement text) read the new sentence by reference to this row.

Dates were the plan of 3 October 2026; the gates are the plan. "Dates slip. Gates do not." was already the roadmap's own sentence, and the roadmap now says only the gates. The owner gives a month if he wants one.

The month was the plan of 3 October 2026. The benchmark tool is part of the testnet's go checklist, so it ships with the testnet; no month is given for either.

The precedent Igneum cites is now a complete one: a fixed random program held CPU mining for about seven years and then a chip shipped. Igneum's program changes every hour from a genesis-fixed schedule, its dataset grows, and the chip model on the numbers page prices the chip that stores the dataset rather than assuming none can be built. The X9's rate and power are Bitmain's published figures, not our measurement.

One number was the model's k = 1 column; the X9 made the k = 0.33 column a product rather than a claim, so the public figure is the range. Rung 2 of the ladder (the top admissible rung on 6 October 2026) takes the X9 bracket from about 3.9x to about 2.8x and does not close it; the ladder moves at the pace of the cards that pay for it (M34).

Correct. a repository file has on_chain_block and no reorg hook, so a transaction unwound by a selected-chain reorg is neither re-queued nor re-executed; the new state word reports reorged out with reorgedFrom, which tells a wallet to resend and tells nobody else. Fix: on every virtualChainChanged removal the executor hands the unwound transactions back to the pool as pending (nonce order kept, the same validity checks as a fresh submission, the 10,000-hash memory of P17 cleared on re-inclusion); a unit test that unwinds a block and sees its transactions re-queued; the conformance driver's reorged out case then ends in executed again without a resend.