@@ -985,21 +985,21 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
M24
Your two-lane controller oscillates for an hour when a second miner joins mid-epoch
4 October 2026
Watched your devnet this morning. The second 5090 came in at 10:12 and the difficulty never settled: 102M to 164M for forty minutes, 54 to 81 blocks a minute, three or four clamp steps stacked inside a second. Your fast lane and your slow lane disagree by a hair under the trigger and the rule flips between them every two minutes. One card joining is the mildest event a chain can see.
-Rolled out 4 October 2026, 18:37 local time): rule v2 activated on the live devnet at DAA 33,000 by the height switch after a 12-node cloud rehearsal (settle 157 to 272 s, no swing); node 1, the seed, the observer and the three app machines crossed the height on one chain with no fork and no restart of the chain (docs/bench-log.md, "difficulty rule v2 activated"). Still owed: the first v2 measurement on the devnet's own two-large-miner regime once PC 2 is back from proving. Was: Fix built, pending rollout (4 October 2026).
-The answer as first written
Correct, measured on the live chain and reproduced in the simulator (docs/analysis/difficulty-2026-10-04-oscillation.md). The cause is the reference lane: spec 2.3 of 3 October gave it the whole epoch, so a hash-rate step inside an epoch left it polluted by the pre-step blocks for the rest of the hour; the short lane read the true rate 11 to 25% above it, the 25% trigger flipped between the two on the short lane's noise, and the per-block clamps turned every flip into a ramp (3% a block up, 10% a block down). The DAG replay (sim/difficulty/sim.py --live, miners on two nodes with igneum-miner's template staleness, GHOSTDAG, the rule as the node runs it) reproduces the record: std of log difficulty 0.115 against 0.134, 4.3 peaks of 1.31x against 4 of 1.37x, 104M to 169M against 102M to 164M, 54 to 77 blocks a minute against 54 to 81. The brief's five candidates (longer short lane, 3% ease clamp, one clamp per DAA second, hysteresis, median of three) each leave it between 0.09 and 0.13 because none of them cleans the reference lane. Rule v2 caps the reference lane at the newest 600 DAA score of the epoch (the epoch lane only; Kaspa's sampled window is not consulted): 0.026 with 0 lane flips and the target on the true level (142.6M against 139M) on all three seeds; the chain-only simulator agrees (0.14 to 0.19 against 0.02 to 0.08). Cost on the synthetic set (seed 7): steady std of the block rate 0.049 against 0.038 (blocks per minute CV unchanged, 0.130 against 0.135), the 50x step-up settles in 65.5 s against 61.7 s, the 50x step-down 753 s against 629 s, hops slightly faster, the polluted window's overshoot halved. Under attack (attacks.py, seeds 7 to 9): the greedy hopper gains one more point (at most +2.5% against +1.5%), the forger's drift falls to within 1% (worst seed 1.5% against 2.7%), the pulsed rental, the epoch games and the polluted window are unchanged, the 50x step-down is 8% slower and the steady estimate a quarter noisier. Built behind a height switch, difficulty_v2_activation_daa (a consensus parameter, default never, set by the override file), so the devnet moves to v2 at a chosen DAA score on the same chain. The epoch boundary itself clears the pollution, which the live chain showed at 11:02 UTC (DAA 7,200: within 1.3% per minute from 11:07 with no flips, the hash rate having also stepped down there).
Rolled out 4 October 2026, 18:37 local time): rule v2 activated on the live devnet at DAA 33,000 by the height switch after a 12-node cloud rehearsal (settle 157 to 272 s, no swing); node 1, the seed, the observer and the three app machines crossed the height on one chain with no fork and no restart of the chain (a repository file, "difficulty rule v2 activated"). Still owed: the first v2 measurement on the devnet's own two-large-miner regime once the Windows machine is back from proving. Was: Fix built, pending rollout (4 October 2026).
+The answer as first written
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).
Builders
D1
Your users are a gate, not a fact
3 October 2026
The miners are your user base? Nine devnet identities today, a 1,000-miner testnet gate whose word 'independent' is still undefined (X5), and miners are the most mercenary users of all: they sell.
Conceded, stated
-The answer as first written
Correct on the count and on the definition. The claim in docs/design/developer-adoption.md section 2c is narrower than "users": miners are funded wallets that are present and have a continuing reason to transact (they are paid every block and pay power bills), which gives a specific set of apps (pools, payout contracts, hardware finance, hashrate forwards) a customer before any consumer app has one. Loyalty is not claimed. The number that makes the claim real is the testnet gate, with O-X.1's definition of independent.
The answer as first written
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.
D2
The app share pays nothing
5 October 2026
Run your own table. A 100,000-gas call at your devnet fees pays the app 20,000 gwei, four ten-millionths of a dollar at your base price. A million calls a day is $146 a year. 'Apps earn the gas they generate' is the Canto pitch, and Canto's chain has $1.4M of lending TVL.
-Conceded, stated 5 October 2026, night): site/litepaper.html, Building, Why build here, "a million 100,000-gas calls a day at a 1 gwei tip pays about 7,300 IGN a year"; Canto and Blast absent from the page (grep, tonight). Was: Conceded, not yet stated. Fix: the litepaper bullet "Apps earn the gas they generate ... Canto and Blast proved builders come for this" is replaced by the "Why build here" text proposed in docs/design/developer-adoption.md section 7, which states the number.
-The answer as first written
Correct. The app share is a property of the fee flow, not an income at launch: 20% of the priority fee, per call frame, and the priority fee on an uncongested chain is whatever wallets quote by default. At the three price inputs of docs/analysis/security-budget.md and a 1 gwei tip, a million calls a day pays $146, $730 or $7,300 a year (the last at a 10 gwei tip). What is new in it against Canto and Sonic is library attribution at the code address and factory inheritance, and the fact that it comes from the user's tip and never from emission. The 20% should not be raised: Sonic's 90% has distributed about $2M in a year across a whole chain, and a larger share comes out of the miners' and provers' side, which is the security budget. Blast announced its shutdown on 2 October 2026, so the sentence citing it must go now.
Conceded, stated 5 October 2026, night): a repository file, Building, Why build here, "a million 100,000-gas calls a day at a 1 gwei tip pays about 7,300 IGN a year"; Canto and Blast absent from the page (grep, tonight). Was: Conceded, not yet stated. Fix: the litepaper bullet "Apps earn the gas they generate ... Canto and Blast proved builders come for this" is replaced by the "Why build here" text proposed in a repository file section 7, which states the number.
+The answer as first written
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.
D3
Proof of work in 2027 is a perception cost you cannot measure
3 October 2026
@@ -1011,205 +1011,205 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
D4
No dollar, no DeFi
3 October 2026
No stablecoin and no bridge at genesis. 'Native USDC is requested from Circle' is a request. There is no DeFi without a dollar, and your consumer apps cannot exist until phase two.
Conceded by decision ledger E7, spec 7.3), restated here for builders.
-The answer as first written
Correct, and the sequence in docs/design/developer-adoption.md section 4 puts consumer apps third for this reason: after mainnet, after a bridge run by a named operator, after a published record of the app share and the job market. The alternative, a multisig bridge the project labels official, was refused on 3 October 2026. The sentence naming Circle is a request about a third party and the round-3 review already asked for it to go.
The answer as first written
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.
D5
I cannot debug a revert
5 October 2026
No eth_subscribe, no debug_traceTransaction, no eth_getProof, no explorer, no public RPC, no faucet, finalized resolves to the executed tip. You are inviting builders to a chain they cannot inspect.
-Conceded, scheduled 5 October 2026, night): docs/design/developer-adoption.md section 5, owner and gate named (the execution engineer; no outside team is invited before step 2 is done). Was: Conceded, scheduled. Sweep (5 October 2026): unchanged on the proving branch (no debug_*, eth_subscribe or eth_getProof in igneum/exec/src/rpc.rs); scheduled work, execution engineer.
-The answer as first written
Correct on every item on 4 October 2026 (docs/design/execution-layer.md 10.3 items 1, 6, 7). The order in docs/design/developer-adoption.md section 5: docs and the Hardhat and Foundry templates first; debug_*, eth_subscribe and eth_getProof second, because the Blockscout fork and Foundry's debugger need them; a public devnet RPC, the chain-id listing on ethereum-lists/chains, wallet tests (R11) and a faucet third; the explorer fourth. No outside team is invited before the second step is done.
Conceded, scheduled 5 October 2026, night): a repository file section 5, owner and gate named (the execution engineer; no outside team is invited before step 2 is done). Was: Conceded, scheduled. Sweep (5 October 2026): unchanged on the proving branch (no debug_*, eth_subscribe or eth_getProof in a repository file); scheduled work, execution engineer.
+The answer as first written
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.
D6
A forged job result reaches my contract and nobody vetoes it
5 October 2026
Segments have the native-execution veto. Jobs do not: full nodes cannot re-run an arbitrary program, so for a precompile job the proof is the only check. A soundness bug in SP1 writes whatever the attacker wants into my callback.
-Conceded, contained by rule, reviewed 5 October 2026, night): docs/review/d6-forged-job-result-2026-10-05.md. Next step: the three devnet checks of that review's section 6 (containment under a deliberately broken verifier; the version gate and the overlap; the callback boundary), on the phase 4 devnet once the precompile of design 6 exists (design 10.3 item 5). Was: Conceded, contained by rule, review scheduled. Sweep (5 October 2026): a review item (R12 with the cryptographer); nothing runnable.
+Conceded, contained by rule, reviewed 5 October 2026, night): a repository file. Next step: the three devnet checks of that review's section 6 (containment under a deliberately broken verifier; the version gate and the overlap; the callback boundary), on the phase 4 devnet once the precompile of design 6 exists (design 10.3 item 5). Was: Conceded, contained by rule, review scheduled. Sweep (5 October 2026): a review item (R12 with the cryptographer); nothing runnable.
The answer as first written
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.
Launch and operations
X23
One shipped key is an administrator channel to the founder's PCs
5 October 2026
Your relay accepts either the URL token or the x-igneum-key header for everything, including queuing PowerShell that the PC agent runs as administrator. The key is the log intake key, a literal in six tracked files and inside every Windows and prover package you have handed out. And the zip with both relay secrets sits on the downloads host behind the dl token, which is in your git history and in every installed app. One token, four hops, no privilege boundary.
-Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Was: Open, fatal as an operational fact (4 October 2026). The agent was live and elevated on PC 1 at 13:41 UTC (GET machines, read-only). Sweep (5 October 2026): the relay token was rotated on 4 October (~/.config/igneum/relay-token.old-2026-10-04 sits beside the new one); POST task with kind: run still needs only the token (relay/api/relay.mjs:114-119, no per-machine secret or signature), so the operational half stands. The 401 test needs the deployed relay and PC 1 (relay owner; rotation is the owner's).
-The answer as first written
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 Mac, 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.
Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. Was: Open, fatal as an operational fact (4 October 2026). The agent was live and elevated on the Windows machine at 13:41 UTC (GET machines, read-only). Sweep (5 October 2026): the relay token was rotated on 4 October (a config file sits beside the new one); POST task with kind: run still needs only the token (relay/api/relay.mjs:114-119, no per-machine secret or signature), so the operational half stands. The 401 test needs the deployed relay and the Windows machine (relay owner; rotation is the owner's).
+The answer as first written
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.
X24
The relay token rides in the URL on every request
5 October 2026
-Every poll of every agent and every page refresh puts the token in the path, so it is in the host's request logs, in browser history and in every terminal that ran tools/relay.mjs. You built an x-relay-token header and nobody uses it.
-Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Was: Open (4 October 2026); the print lines fixed: tools/relay.mjs shows /r/<token> in list and watch (only url prints the real one). Sweep (5 October 2026): x-relay-token is accepted (relay/lib/relay.mjs:38) but no client sends it (no match in relay/clients, tools/relay.mjs or app/igneum-app/src), so every request still carries the token in the path. The the host log check needs the deployment (relay owner).
-The answer as first written
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 tools/relay.mjs:24 all build the tokened URL, and tools/relay.mjs:83,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.
Every poll of every agent and every page refresh puts the token in the path, so it is in the host's request logs, in browser history and in every terminal that ran a repository file. You built an x-relay-token header and nobody uses it.
+Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. Was: Open (4 October 2026); the print lines fixed: a repository file shows /r/<token> in list and watch (only url prints the real one). Sweep (5 October 2026): x-relay-token is accepted (relay/lib/relay.mjs:38) but no client sends it (no match in relay/clients, a repository file or a repository file), so every request still carries the token in the path. The the host log check needs the deployment (relay owner).
+The answer as first written
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.
X25
The PC agent installs itself at every logon, at highest privilege, on every start
5 October 2026
Double-click once and the agent writes a scheduled task with /RL HIGHEST and a RunOnce key. Your README says it only re-arms for a reboot. Closing the window does nothing.
-Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Was: Open (4 October 2026). Sweep (5 October 2026): unchanged (relay/clients/igneum-agent.ps1:72, schtasks /SC ONLOGON /RL HIGHEST). The schtasks /Query check needs PC 1.
+Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. Was: Open (4 October 2026). Sweep (5 October 2026): unchanged (relay/clients/igneum-agent.ps1:72, schtasks /SC ONLOGON /RL HIGHEST). The schtasks /Query check needs the Windows machine.
The answer as first written
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.
X26
The feed is a permanent transcript, and it holds the dl token by design
5 October 2026
-One secret pages the whole history: every task body and every result transcript, usernames, hostnames, the folder that holds the secrets. And tools/relay.mjs writes the tokened download URL into task bodies before posting, so a relay leak is a dl-token leak.
-Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Was: Open (4 October 2026). Sweep (5 October 2026): unchanged in relay/api/relay.mjs (no retention or cap on feed). Relay owner.
-The answer as first written
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. tools/relay.mjs:76-80 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.
One secret pages the whole history: every task body and every result transcript, usernames, hostnames, the folder that holds the secrets. And a repository file writes the tokened download URL into task bodies before posting, so a relay leak is a dl-token leak.
+Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. Was: Open (4 October 2026). Sweep (5 October 2026): unchanged in relay/api/relay.mjs (no retention or cap on feed). Relay owner.
+The answer as first written
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.
X27
The relay has no clean rotation and no sender binding
5 October 2026
-Rotate the token and the key path stays open; rotate the key and every shipped package stops uploading logs. Any holder posts a result from any machine name, or registers a machine, and the Mac's watch prints it as truth.
-Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Was: Open (4 October 2026). Sweep (5 October 2026): unchanged (from is a free field in relay/api/relay.mjs; nothing binds a result to the caller's machine). Relay owner.
+Rotate the token and the key path stays open; rotate the key and every shipped package stops uploading logs. Any holder posts a result from any machine name, or registers a machine, and the Apple M5 Max's watch prints it as truth.
+Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. Was: Open (4 October 2026). Sweep (5 October 2026): unchanged (from is a free field in relay/api/relay.mjs; nothing binds a result to the caller's machine). Relay owner.
The answer as first written
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.
X28
Relay hygiene, minor
5 October 2026
-=== on secrets, no HSTS, a GET that acks, a reboot on any output containing RELAY-REBOOT, orphaned blobs, no rate limit anywhere, a WSL user igneum/igneum with NOPASSWD sudo, the username and secret folder posted on register, and a file in ~/.config/igneum whose name is a token.
-Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. The stray file is gone. Was: Open, minor (4 October 2026); two of the points fixed: secrets compared in constant time (relay/lib/auth.mjs, sameSecret, unit test in CI) and HSTS on the relay (relay/vercel.json). Sweep (5 October 2026): the remaining points unchanged; relay owner.
+=== on secrets, no HSTS, a GET that acks, a reboot on any output containing RELAY-REBOOT, orphaned blobs, no rate limit anywhere, a WSL user igneum/igneum with NOPASSWD sudo, the username and secret folder posted on register, and a file in a config file whose name is a token.
+Fixed on a branch, pending merge 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. The stray file is gone. Was: Open, minor (4 October 2026); two of the points fixed: secrets compared in constant time (relay/lib/auth.mjs, sameSecret, unit test in CI) and HSTS on the relay (relay/vercel.json). Sweep (5 October 2026): the remaining points unchanged; relay owner.
The answer as first written
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.
Governance and the founders
G12
The PoW schedule comes from the environment on every network, including mainnet
5 October 2026
Your mainnet gate refuses the override file. It does not refuse IGNEUM_POW_EPOCH_BLOCKS. A node without a file installs the schedule from the environment and Params.pow_epoch_blocks is never consulted.
-Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, docs/plans/release-0.3.5.md 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, docs/plans/release-0.3.6.md 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, local worktree vendor/igneum-node-fud, no remote; main repo branch fud-consensus). Was: Open (4 October 2026).
+Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, local worktree a repository file, no remote; main repo branch fud-consensus). Was: Open (4 October 2026).
G13
The update signature covers binaries that nobody signed
5 October 2026
-The runner fetches payload-inputs.zip and its sha256 from the same host, builds the installer, and the Mac signs the manifest over whatever the latest green run produced. A compromised dl project or runner ships as a genuine update.
-Fixed on a branch and verified locally 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. The GitHub run is owed (no push tonight). Was: Open (4 October 2026).
-The answer as first written
Correct. .github/workflows/windows.yml (step "payload inputs") checks the zip against a sha256 served beside it; packaging/windows/fetch-ci-artifacts.sh takes the latest green run and calls packaging/ota/publish-manifest.sh 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 Mac 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.
The runner fetches payload-inputs.zip and its sha256 from the same host, builds the installer, and the Apple M5 Max signs the manifest over whatever the latest green run produced. A compromised dl project or runner ships as a genuine update.
+Fixed on a branch and verified locally 5 October 2026, night): ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. The GitHub run is owed (no push tonight). Was: Open (4 October 2026).
+The answer as first written
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.
G14
Secrets and identity in the history of a repository with a public date
6 October 2026
The intake key is in six files across eight commits, the dl token in one, the review and ledger files are tracked, 51 tracked files carry the founder's first name, and every commit today is stamped with the local-time offset. The 3 October sweep said zero hits.
-Decided 6 October 2026, 17:25 UTC, by the owner; decisions item 8): the history rewrite runs the morning after the last of the close's branches merges, with every worktree removed first and both secrets rotated regardless. Was: Fixed on a branch, pending merge (5 October 2026, night), the tooling part: ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Decision owner: the owner for the rewrite date (docs/plans/ledger-decisions.md). Was: Open (4 October 2026); extends docs/fud-fixes.md section 5.
-The answer as first written
Correct, count-only. The key: packaging/mac/packaged-config.sh, infra/gpu-bench/upload.sh, proving/windows-wsl2/prove-block.sh, prove-shard.sh, proto-cuda/windows-miner/upload-log.bat, proto-cuda/windows-app/upload-log.bat, commits 78df757 to 4c9810f. The token: docs/plans/morning-2026-10-04.md:49, 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.
Decided 6 October 2026, 17:25 UTC, by the owner; decisions item 8): the history rewrite runs the morning after the last of the close's branches merges, with every worktree removed first and both secrets rotated regardless. Was: Fixed on a branch, pending merge (5 October 2026, night), the tooling part: ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. Decision owner: the owner for the rewrite date (a repository file). Was: Open (4 October 2026); extends a repository file section 5.
+The answer as first written
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.
Launch and operations
X18
Two nodes with two override files connect, and only some mismatches fork
5 October 2026
Your handshake compares the network name and nothing else. A PoW or difficulty mismatch forks and bans; a finality mismatch is a WARN; rollout-v2.sh throws the finality block away when it writes the file; the app rewrites the packaged file on every start.
-Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, docs/plans/release-0.3.5.md 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, docs/plans/release-0.3.6.md 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026).
+Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026).
Finality and attacks
F23
The equivocation ban is node-local, so honest nodes refuse each other's certificates
5 October 2026
Evidence detected from an RPC vote stamps the sink's DAA; evidence carried in a block stamps the carrier's DAA. Two honest nodes hold different until for the same key, their voter lists differ by one at every checkpoint between the two expiries, and voter_count refuses the other's certificate for good.
-Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, docs/plans/release-0.3.5.md 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, docs/plans/release-0.3.6.md 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026); reproduced by the red team the same evening on the stock s1 scenario (n0 kept the ban until DAA 726 against 239 on n1 and n2, 9 and 3 to 4 certificates refused "names N voters").
+Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026); reproduced by the red team the same evening on the stock s1 scenario (n0 kept the ban until DAA 726 against 239 on n1 and n2, 9 and 3 to 4 certificates refused "names N voters").
F24
A checkpoint determination is never revisited
5 October 2026
After a reorg deeper than checkpoint_depth, the node's record for that index names a block off its chain. Every certificate the network forms for that index is refused as conflicting, with no equivocation anywhere, and the node voted for a block that is not on its chain.
-Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, docs/plans/release-0.3.5.md 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, docs/plans/release-0.3.6.md 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026); extends F7 and C4.
+Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026); extends F7 and C4.
F25
The fast-time harnesses cannot start a node, and the timestamp probe tests the old rule
5 October 2026
-Both attack harnesses rebuild each node's override with JSON.parse and JSON.stringify of infra/fast-time/override-60x.json. That file now carries two u64::MAX sentinels (difficulty_v2_activation_daa, proving_v0_activation_daa); a JavaScript number cannot hold them, the round-trip writes 18446744073709552000, and igneumd refuses the file as a floating point where a u64 is expected. Every --fast-time run of tools/finality-attacks and tools/harness fails at the first node. Scenario 2 of tools/harness still probes the 132 s future bound and reports FAIL against the 10 s rule the node has carried since the timestamp fix.
-Fixed rolled out 5 October 2026, 0.3.5: both harness libraries reached master with the fud-consensus merge 7abce72 of the 0.3.5 cut; the sweep of 5 October ran run.mjs s4 and s5 --fast-time, fud.mjs and tonight's c4.mjs through them, every node started). Was: Fixed in both harnesses (4 October 2026, night: tools/finality-attacks/lib/net.mjs kept the sentinels as BigInt through the merge since the v3 runner of the evening; tools/harness/lib/net.mjs got the same reviver on branch fud-memory, merged into fud-consensus); the stale timestamp criterion of scenario 2 is not touched. Was: Open (4 October 2026, red-team run). Tooling, low severity: no consensus effect, but every fast-time attack run is blind until it is fixed.
-The answer as first written
Correct, measured. The red-team run's first scenario errored on it (docs/review/redteam-2026-10-04.md, "Tooling defect"); tools/proving-v0/run.mjs 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 tools/finality-attacks/lib/net.mjs and tools/harness/lib/net.mjs overrideParams, drop the two sentinel fields before stringify (absent means never) or splice the extra fields into the file text; in tools/harness/scenarios/s2-timestamp.mjs, probe max(pmt + 1, parent - 10 s) and the +10 s bound. Also stale: tools/exec-attacks/scenario3_pgas.mjs 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 (docs/review/redteam-2026-10-04.md row 28). And tools/finality-attacks 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).
Both attack harnesses rebuild each node's override with JSON.parse and JSON.stringify of a repository file. That file now carries two u64::MAX sentinels (difficulty_v2_activation_daa, proving_v0_activation_daa); a JavaScript number cannot hold them, the round-trip writes 18446744073709552000, and igneumd refuses the file as a floating point where a u64 is expected. Every --fast-time run of a repository file and a repository file fails at the first node. Scenario 2 of a repository file still probes the 132 s future bound and reports FAIL against the 10 s rule the node has carried since the timestamp fix.
+Fixed rolled out 5 October 2026, 0.3.5: both harness libraries reached master with the fud-consensus merge 7abce72 of the 0.3.5 cut; the sweep of 5 October ran run.mjs s4 and s5 --fast-time, fud.mjs and tonight's c4.mjs through them, every node started). Was: Fixed in both harnesses (4 October 2026, night: a repository file kept the sentinels as BigInt through the merge since the v3 runner of the evening; a repository file got the same reviver on branch fud-memory, merged into fud-consensus); the stale timestamp criterion of scenario 2 is not touched. Was: Open (4 October 2026, red-team run). Tooling, low severity: no consensus effect, but every fast-time attack run is blind until it is fixed.
+The answer as first written
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).
Launch and operations
X19
Operational knobs and silences in the shipped node
5 October 2026
A slow-clock node disconnects every peer on every relayed block and never says why; the handshake's time_offset is computed and unused; IGNEUM_ATTACK_TS_OFFSET_MS and IGNEUM_POW_STRIKES are compiled into the live binary; timestamp_deviation_tolerance is dead and still accepted.
-Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (fc0cb938 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3), suites PC 2 jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Mac), both on 815c7d64; the tip is fbb0082a. Was: Open, minor (4 October 2026). Sweep (5 October 2026): the app half is done (bench-log, "a node 60 s behind the clock is silently dead": the node card shows the skew with a Sync clock button, Start is blocked past 10 s, checked with IGNEUM_APP_FAKE_SKEW=-60); the node's one WARN line is filed in docs/plans/node-changes.md section 1 and not written; faketime is not installed on this Mac, so the node experiment was not run.
+Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (fc0cb938 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3), suites the Windows machine jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Apple M5 Max), both on 815c7d64; the tip is fbb0082a. Was: Open, minor (4 October 2026). Sweep (5 October 2026): the app half is done (bench-log, "a node 60 s behind the clock is silently dead": the node card shows the skew with a Sync clock button, Start is blocked past 10 s, checked with IGNEUM_APP_FAKE_SKEW=-60); the node's one WARN line is filed in a repository file section 1 and not written; faketime is not installed on this Mac, so the node experiment was not run.
The answer as first written
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.
X20
Cold-sync checkpoint determination is indices times chain length
5 October 2026
A fresh node starts next_index at 0 and walks the selected chain from the sink for every index. At mainnet length it never finishes its first resolution.
-Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (9e109c65 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3), suites PC 2 jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Mac), both on 815c7d64; the tip is fbb0082a. Was: Open, minor now (4 October 2026). Sweep (5 October 2026): unchanged on finality-fixes (processes/finality.rs:204 starts next_index at 1 and walks the chain per index). A 10^6-block simnet is 11.6 days of chain at 1 block/s and was not built. Fix row in section 2.5.
+Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (9e109c65 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3), suites the Windows machine jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Apple M5 Max), both on 815c7d64; the tip is fbb0082a. Was: Open, minor now (4 October 2026). Sweep (5 October 2026): unchanged on finality-fixes (processes/finality.rs:204 starts next_index at 1 and walks the chain per index). A 10^6-block simnet is 11.6 days of chain at 1 block/s and was not built. Fix row in section 2.5.
The answer as first written
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.
Mining and chips
M25
The miner takes the day length from its environment, and the schedule global can tear
5 October 2026
The template carries epoch and lead but not the day; the miner reads IGNEUM_POW_DAY_MS from its environment. And install_pow_schedule stores day, lead, epoch while pow_schedule loads epoch, lead, so a miner switched between schedules can wrap pow_epoch_seed_score.
-Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (3d4ec451 and fc0cb938 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3), suites PC 2 jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Mac), both on 815c7d64; the tip is fbb0082a. Was: Open, minor (4 October 2026). Sweep (5 October 2026): the schedule now rides in the override file as consensus params (a5ef8b07, in devnet-v4); the mismatch run was done (5 October 2026, 01:05 UTC, scratchpad/runs/batch3.sh under the run lock: one finality-fixes node with real PoW at genesis bits 2^16 on ports 29410 to 29412, pow_day_ms 86,400,000 in its override file; a control miner, then a miner started with IGNEUM_POW_DAY_MS=1440000, 2 CPU threads, 60 s each). Confirmed: the miner still takes the day from its environment (it built its cache for day 1,243,862 while the node and the control miner were on day 20,731); control 7 blocks accepted, 0 rejected; mismatched 0 accepted, 4 rejected, each as Reject(BlockInvalid) on the miner and block has invalid proof-of-work on the node, so the miner says that it is rejected and not why. Fix row 127: the day length in the template beside the epoch and lead, and a rejection reason that names the day. The environment fallback is G12, owned by the fud-consensus branch.
-The answer as first written
Correct. igneum/miner/src/main.rs:590-596; 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.
Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (3d4ec451 and fc0cb938 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3), suites the Windows machine jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Apple M5 Max), both on 815c7d64; the tip is fbb0082a. Was: Open, minor (4 October 2026). Sweep (5 October 2026): the schedule now rides in the override file as consensus params (a5ef8b07, in devnet-v4); the mismatch run was done (5 October 2026, 01:05 UTC, scratchpad/runs/batch3.sh under the run lock: one finality-fixes node with real PoW at genesis bits 2^16 on ports 29410 to 29412, pow_day_ms 86,400,000 in its override file; a control miner, then a miner started with IGNEUM_POW_DAY_MS=1440000, 2 CPU threads, 60 s each). Confirmed: the miner still takes the day from its environment (it built its cache for day 1,243,862 while the node and the control miner were on day 20,731); control 7 blocks accepted, 0 rejected; mismatched 0 accepted, 4 rejected, each as Reject(BlockInvalid) on the miner and block has invalid proof-of-work on the node, so the miner says that it is rejected and not why. Fix row 127: the day length in the template beside the epoch and lead, and a rejection reason that names the day. The environment fallback is G12, owned by the fud-consensus branch.
+The answer as first written
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.
M26
The interval fault guard freezes its baseline and loops
5 October 2026
On a trip you skip the STATUS print, so the baseline it would have updated stays frozen, and you roll the counters back to it. Any healthy rate over ten times a slow first interval trips again every interval, forever, with no STATUS line and no faults= for the app to read.
-Fixed rolled out 5 October 2026, 0.3.5: miner-reliability 945153ab merged into fork 20139145, docs/plans/release-0.3.5.md 1b; the guard tests in the 0.3.5 igneum-miner suite, 12 passed). Was: Fixed (4 October 2026, evening), fork commits aea5ac6d, 501363e0 and 945153ab on miner-reliability (igneum/miner/src/guard.rs; the second fixes a fill loop that spun forever after a guard kill, found by the test network). Replaced: Open (4 October 2026).
-The answer as first written
Correct. igneum/miner/src/main.rs:1404-1418 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.
Fixed rolled out 5 October 2026, 0.3.5: miner-reliability 945153ab merged into fork 20139145, a repository file 1b; the guard tests in the 0.3.5 igneum-miner suite, 12 passed). Was: Fixed (4 October 2026, evening), fork commits aea5ac6d, 501363e0 and 945153ab on miner-reliability (a repository file; the second fixes a fill loop that spun forever after a guard kill, found by the test network). Replaced: Open (4 October 2026).
+The answer as first written
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.
M27
A flapping node makes the worker rebuild once per template
5 October 2026
A prepare goes out whenever the wanted pair differs from the prepared one. No count, no interval, no once-per-epoch. Each one writes a pack on the CPU with the job loop stalled and costs the worker a full build; prepare-failed resends on the next fill.
-Fixed rolled out 5 October 2026, 0.3.5, as M26). Was: Fixed (4 October 2026, evening), fork commit aea5ac6d on miner-reliability (guard::PrepareLimiter): one prepare per pair per epoch, one retry after prepare-failed, none within 30 s of the last; a held prepare is printed once (PREPARE held ...). Measured with a worker that refused every prepare across three epochs: docs/bench-log.md, the same entry as M26. Replaced: Open (4 October 2026).
-The answer as first written
Correct. igneum/miner/src/main.rs:1113-1165, 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.
Fixed rolled out 5 October 2026, 0.3.5, as M26). Was: Fixed (4 October 2026, evening), fork commit aea5ac6d on miner-reliability (guard::PrepareLimiter): one prepare per pair per epoch, one retry after prepare-failed, none within 30 s of the last; a held prepare is printed once (PREPARE held ...). Measured with a worker that refused every prepare across three epochs: a repository file, the same entry as M26. Replaced: Open (4 October 2026).
+The answer as first written
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.
M28
The kernel text is bound only to its own directory
5 October 2026
The worker compiles whatever kernel_bound.cu it finds in a directory whose seeds.txt matches; the self-test checks the GPU against a vectors.h from the same directory. Nothing commits the text to what the generator would emit for the seed. 'Source check PASS' is a prefix equality.
-Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (miner; 3d4ec451 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3) and branch ledger-fork (workers), suites PC 2 jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Mac), both on 815c7d64; the tip is fbb0082a. Was: Open, minor (4 October 2026). The writer is the local miner and the directory is the user's own, so no privilege boundary is crossed. Sweep (5 October 2026): no kernel hash in program.json on any branch (git grep -i 'kernel_hash|program_hash' on miner-reliability finds nothing); the tampered-pack test needs a GPU worker. Fix row in section 2.5.
+Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (miner; 3d4ec451 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3) and branch ledger-fork (workers), suites the Windows machine jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Apple M5 Max), both on 815c7d64; the tip is fbb0082a. Was: Open, minor (4 October 2026). The writer is the local miner and the directory is the user's own, so no privilege boundary is crossed. Sweep (5 October 2026): no kernel hash in program.json on any branch (git grep -i 'kernel_hash|program_hash' on miner-reliability finds nothing); the tampered-pack test needs a GPU worker. Fix row in section 2.5.
The answer as first written
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.
Launch and operations
X21
A wrong program burns power with a green rate
5 October 2026
The CPU re-check counts mismatches and does nothing: no threshold, no stop. The app reads hash, now, template_age and synced from STATUS and nothing else, so mismatched= and WORKER FAULT never reach the card.
-Fixed rolled out 5 October 2026, 0.3.5: the miner half with miner-reliability in fork 20139145, the app half with app commit f7d2af7 of the 0.3.5 branch, docs/plans/release-0.3.5.md 1a). Was: Fixed (4 October 2026, evening), fork commit aea5ac6d (guard::MismatchGuard: three consecutive CPU re-check mismatches kill the worker, WORKER FAULT cpu re-check ...) and app commit f39e240 on miner-reliability (app/igneum-app/src/watchdog.rs: the app reads mismatched=, faults= and the WORKER FAULT lines, shows them on the card, and its own watchdog restarts a miner once for no status in 90 s or a zero rate for 60 s while synced, then marks the card faulted; a silent node is restarted in-process). Measured: docs/bench-log.md, the same entry as M26. Replaced: Open (4 October 2026).
-The answer as first written
Correct. igneum/miner/src/main.rs:1250-1261; app/igneum-app/src/engine.rs:~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.
Fixed rolled out 5 October 2026, 0.3.5: the miner half with miner-reliability in fork 20139145, the app half with app commit f7d2af7 of the 0.3.5 branch, a repository file 1a). Was: Fixed (4 October 2026, evening), fork commit aea5ac6d (guard::MismatchGuard: three consecutive CPU re-check mismatches kill the worker, WORKER FAULT cpu re-check ...) and app commit f39e240 on miner-reliability (a repository file: the app reads mismatched=, faults= and the WORKER FAULT lines, shows them on the card, and its own watchdog restarts a miner once for no status in 90 s or a zero rate for 60 s while synced, then marks the card faulted; a silent node is restarted in-process). Measured: a repository file, the same entry as M26. Replaced: Open (4 October 2026).
+The answer as first written
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.
X22
Worker restart paths, minor
5 October 2026
Two miners truncate the same packs\devnet while workers read it; every restart begins on the stale first pack; the restart loop has no cap; the 60 s stall guard wraps the self-heal build; a node can crash the miner through an expect; a worker without prepare support loops on export during IBD.
-Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (miner; 3d4ec451 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3) and branch ledger-fork (app), suites PC 2 jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Mac), both on 815c7d64; the tip is fbb0082a. Was: Open, minor (4 October 2026). Sweep (5 October 2026): two of the six fixed on miner-reliability (501363e0: a dead worker's stdin no longer spins the fill loop; 945153ab: a silent worker still runs the guards and STATUS); the shared packs\devnet truncation, the stale first pack, the expect crash and the IBD export loop remain; restart timing needs the PCs.
+Fixed on a branch, pending merge 5 October 2026, night): fork branch ledger-fixes-0311 fbb0082a (miner; 3d4ec451 rebased onto the 0.3.11 fork tip 89dfcb95 in round 3) and branch ledger-fork (app), suites the Windows machine jobs build-20261005-200049 (kaspa-consensus 95 passed, 0 failed, 3 ignored) and build-20261005-200606 (kaspa-consensus-core 101/0, kaspa-mining 52/0, igneum-exec 13/0, igneum-miner 17/0, kaspa-p2p-flows 32 passed 1 failed: the new clock-skew test's own arithmetic, corrected in bd1b676a and 33/0 on the Apple M5 Max), both on 815c7d64; the tip is fbb0082a. Was: Open, minor (4 October 2026). Sweep (5 October 2026): two of the six fixed on miner-reliability (501363e0: a dead worker's stdin no longer spins the fill loop; 945153ab: a silent worker still runs the guards and STATUS); the shared packs\devnet truncation, the stale first pack, the expect crash and the IBD export loop remain; restart timing needs the PCs.
The answer as first written
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.
Economics and the coin
E16
The 20% pool is burned on the live chain, and the text says it pays provers
5 October 2026
Your coinbase sends the 20% to an OP_RETURN tagged igneum-proving-pool-v0. Your own comment says provably burned. Your cap test counts it as supply. Your litepaper says, present tense, that it pays a standing prover population.
-Answered with evidence and stated 5 October 2026, night). Code half (5 October 2026, night, ledger close round 1: the 20% is burned on the UTXO ledger and paid on the EVM ledger from an escrow the executor credits by rule with the same 20%; one live block shows both; bench-log "5 October 2026 (night), ledger close round 1: X14 concentration in hashing, signing, proving and aggregation from the Mac node's RPCs, and E16 one live block"). Text half stated (5 October 2026, night): site/litepaper.html, Economics, emission table 20% row, "the coinbase's 20% output goes to an unspendable script tagged igneum-proving-pool-v0 and is burned there. Provers are paid from a separate escrow in the execution state, credited by rule with the same 20% of each blue block's subsidy" (from the fork at release-0.3.6 a24ab01a: consensus/core/src/igneum.rs:86-98, consensus/src/processes/coinbase.rs:113, igneum/exec/src/executor.rs:160-176 PROVING_POOL_ADDRESS, igneum/exec/src/proving.rs carried_payouts); the same sentence under the bar on site/index.html. Was: Open (4 October 2026). Sweep (5 October 2026): confirmed in code: devnet-v4 consensus/core/src/igneum.rs:93 burns the 20% under the tag igneum-proving-pool-v0; the proving branch pays proving_pool_credit from shard records (igneum/exec/src/proving.rs:304) and is not on the devnet. The live-block test needs the proving branch rolled out; the text belongs to the testnet-prep branch.
-The answer as first written
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 (site/litepaper.html:396, 414) and under the homepage bar (site/index.html:306, 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.
Answered with evidence and stated 5 October 2026, night). Code half (5 October 2026, night, ledger close round 1: the 20% is burned on the UTXO ledger and paid on the EVM ledger from an escrow the executor credits by rule with the same 20%; one live block shows both; bench-log "5 October 2026 (night), ledger close round 1: X14 concentration in hashing, signing, proving and aggregation from the Apple M5 Max node's RPCs, and E16 one live block"). Text half stated (5 October 2026, night): a repository file, Economics, emission table 20% row, "the coinbase's 20% output goes to an unspendable script tagged igneum-proving-pool-v0 and is burned there. Provers are paid from a separate escrow in the execution state, credited by rule with the same 20% of each blue block's subsidy" (from the fork at release-0.3.6 a24ab01a: consensus/core/src/igneum.rs:86-98, consensus/src/processes/coinbase.rs:113, a repository file PROVING_POOL_ADDRESS, a repository file carried_payouts); the same sentence under the bar on a repository file. Was: Open (4 October 2026). Sweep (5 October 2026): confirmed in code: devnet-v4 consensus/core/src/igneum.rs:93 burns the 20% under the tag igneum-proving-pool-v0; the proving branch pays proving_pool_credit from shard records (a repository file) and is not on the devnet. The live-block test needs the proving branch rolled out; the text belongs to the testnet-prep branch.
+The answer as first written
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.
Legal and regulatory
L9
"100% to miners and provers", "0% anyone else", and no word that devnet coins have no value
5 October 2026
The homepage says 100% to miners and provers and 0% to anyone else, beside a 1% client dev fee disclosed only in the litepaper. Nowhere on the site does it say the devnet's coins have no value or that the chain may be reset, and the Get the miner button is live.
-Conceded, stated 5 October 2026, night): site/index.html, site/miner.html and site/wallet.html, a line beside every download control, "Devnet: coins have no value and the chain may be reset."; site/index.html Economics tiles, "of emission to miners and provers; the protocol carries no fee" and "0% anyone else in the protocol", with the E16 sentence under the bar. Not done: the same line on site/live.html (not in this round's file list). Was: Open (4 October 2026); extends E5.
-The answer as first written
Correct. site/index.html:306, 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 (app/igneum-app/ui/index.html:45). 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.
Conceded, stated 5 October 2026, night): a repository file, a repository file and a repository file, a line beside every download control, "Devnet: coins have no value and the chain may be reset."; a repository file Economics tiles, "of emission to miners and provers; the protocol carries no fee" and "0% anyone else in the protocol", with the E16 sentence under the bar. Not done: the same line on a repository file (not in this round's file list). Was: Open (4 October 2026); extends E5.
+The answer as first written
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.
Mining and chips
M29
The litepaper's app paragraph describes an app that does not exist
5 October 2026
'Press one button, and the card is mining and proving to a wallet the app made for you, with earnings shown in IGN and in your currency ... offers a hardware wallet for your earnings.' Version 0.3.3 shows a hash rate and block counts.
-Conceded, stated 5 October 2026, night): site/litepaper.html, For miners, "One click, for everyone else", rewritten to Ember 0.3.9 from app/igneum-app/ui/index.html (hash rate, blocks found, node, next program, finality votes, the proving tile, the devnet v4 label, the 80% power cap, the Settings switches); "It shows no earnings in IGN or in any currency, and it has no hardware-wallet path"; earnings, currency, game pause and the hardware wallet moved to "Roadmap, Designed and not in the app". Was: Open (4 October 2026).
-The answer as first written
Correct. site/litepaper.html:424; 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.
Conceded, stated 5 October 2026, night): a repository file, For miners, "One click, for everyone else", rewritten to Ember 0.3.9 from a repository file (hash rate, blocks found, node, next program, finality votes, the proving tile, the devnet v4 label, the 80% power cap, the Settings switches); "It shows no earnings in IGN or in any currency, and it has no hardware-wallet path"; earnings, currency, game pause and the hardware wallet moved to "Roadmap, Designed and not in the app". Was: Open (4 October 2026).
+The answer as first written
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.
M30
A block or transaction flood grows the 0.3.4 node by hundreds of megabytes in a minute
5 October 2026
On the 3 October ordering-layer node (no execution layer) the resource-exhaustion scenario grew RSS by 4, 11 and 14 MB and the 50x block flood by 30 MB. On the 0.3.4 build, same harness, same scenarios, same 60 s: template flood +6 MB, submit flood +269 MB, mempool flood +270 MB, block flood 302 to 1,082 MB on both nodes (567 MB at 10 s, 824 MB at 20 s). The harness calls it a pass because its bound is baseline + 512 MB; a peer that keeps going is not bounded by the harness.
-Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, docs/plans/release-0.3.5.md 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, docs/plans/release-0.3.6.md 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-memory, merged into fud-consensus; main repo branch fud-memory, merged into fud-consensus). Was: Open (4 October 2026, red-team run).
-The answer as first written
Measured, cause not yet isolated. What changed between the two builds is the execution layer, which this node links: igneum/exec/src/service.rs 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 tools/harness s6 and s7 and require growth under 50 MB, the 3 October figure.
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-memory, merged into fud-consensus; main repo branch fud-memory, merged into fud-consensus). Was: Open (4 October 2026, red-team run).
+The answer as first written
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.
M31
The 0.3.4 node cannot produce a block template on mainnet, testnet or simnet parameters
5 October 2026
getBlockTemplate on a --simnet node from the finality-fixes build answers every call with Coinbase payload is above max length (204). Try to shorten the extra data. and the network never makes a block. The coinbase of this build carries the vote-key reveal, the proof-record section and the finality section; only DEVNET_PARAMS was raised to MAX_COINBASE_PAYLOAD_LEN_WITH_FINALITY (16,384). MAINNET_PARAMS, TESTNET_PARAMS and SIMNET_PARAMS still carry Kaspa's 204 (consensus/core/src/config/params.rs:705, 766, 828 against :900).
-Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, docs/plans/release-0.3.5.md 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, docs/plans/release-0.3.6.md 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus). Was: Open (4 October 2026, red-team run). Serious for anything that is not the devnet: a mainnet or testnet genesis on these parameters cannot be mined by a voting miner at all; harmless on the live devnet, whose parameters carry the raise.
-The answer as first written
Measured on the execution-layer attack network (tools/exec-attacks/net.sh runs --simnet with no override): three nodes up, 0 blocks, every template refused with that line (docs/review/redteam-2026-10-04.md 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.
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus). Was: Open (4 October 2026, red-team run). Serious for anything that is not the devnet: a mainnet or testnet genesis on these parameters cannot be mined by a voting miner at all; harmless on the live devnet, whose parameters carry the raise.
+The answer as first written
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.
Economics and the coin
E17
Unlogged inputs behind the economics, minor
6 October 2026
-The cap's 110 MH/s and its draw are not in the bench-log; the Mac's draw is not logged; the economy sim's one measured input is a 229 MH/s card against today's 124; mining-versus-pool flips from 4.9x for mining on today's devnet to 930x for proving at 10,000 cards and no document says it depends on fleet size; the app-share text omits '100,000-gas calls' and the open base unit; emission ran at up to 2x schedule; shard-scale prover cost is unmeasured on any GPU; the iGPU default off is right.
-Answered with evidence for PC 2 6 October 2026, night, ledger close round 2, bench-log "ledger close round 2: M16", the E17 columns): RTX 5090 honest 132.2 Mhash/s at 326.6 W median, 3,060 MHz, 50 to 54 C, 100% utilisation (0.40 Mhash/J); 346.9 W at 8 warps per block; the inline settings 415.7 W and 431.0 W (the power limit). Open, minor: the PC 1 line (the 9070 XT and the 5090 under the app's own cap) and the Mac's powermetrics line (sudo) are owed. Was: Open, minor: the PC 2 draw lines are in the queued M16 job. Was: Open, minor (the draw lines need the machines); text half stated (5 October 2026, night): site/litepaper.html, Building, Why build here, "a million 100,000-gas calls a day at a 1 gwei tip pays about 7,300 IGN a year, with 1 gwei taken as a billionth of an IGN (the base unit is Open)"; For miners, "Which of the two in-chain streams pays more per GPU-second depends on the size of the fleet" with the 4.9x and 930x arithmetic marked approximate. Was: Open, minor; the simulator half re-run (5 October 2026 sweep). sim/economy/sim.py with the 5090 class at 124 MH/s (the devnet's measured rate) in place of 229, scenarios a and b, 2 seeds, 111 s: baseline profit USD 5.59 per 5090 card-day (6.37 at 229), 3090 2.73 (1.66), 3060 1.34 (0.78), small 0.74 (0.39); under the b shock 4.52 / 2.25 / 1.46 / 0.30; no backlog, every block proven within 60 s, hash trough 75% of pre-event under b (82% at 229), 5% of cards off (10%), oscillation flag in 1 of 2 seeds. The direction is as the review said: a slower flagship card shifts income toward the smaller classes and makes the fleet more sensitive to the price shock. The draw lines (nvidia-smi on both PCs, powermetrics on the Mac) need the machines (person). Was: Open, minor (4 October 2026).
-The answer as first written
Correct on each point; docs/review/round-4-2026-10-04.md 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 Mac; 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 cap's 110 MH/s and its draw are not in the bench-log; the Apple M5 Max's draw is not logged; the economy sim's one measured input is a 229 MH/s card against today's 124; mining-versus-pool flips from 4.9x for mining on today's devnet to 930x for proving at 10,000 cards and no document says it depends on fleet size; the app-share text omits '100,000-gas calls' and the open base unit; emission ran at up to 2x schedule; shard-scale prover cost is unmeasured on any GPU; the iGPU default off is right.
+Answered with evidence for the Windows machine 6 October 2026, night, ledger close round 2, bench-log "ledger close round 2: M16", the E17 columns): RTX 5090 honest 132.2 Mhash/s at 326.6 W median, 3,060 MHz, 50 to 54 C, 100% utilisation (0.40 Mhash/J); 346.9 W at 8 warps per block; the inline settings 415.7 W and 431.0 W (the power limit). Open, minor: the the Windows machine line (the 9070 XT and the 5090 under the app's own cap) and the Apple M5 Max's powermetrics line (sudo) are owed. Was: Open, minor: the the Windows machine draw lines are in the queued M16 job. Was: Open, minor (the draw lines need the machines); text half stated (5 October 2026, night): a repository file, Building, Why build here, "a million 100,000-gas calls a day at a 1 gwei tip pays about 7,300 IGN a year, with 1 gwei taken as a billionth of an IGN (the base unit is Open)"; For miners, "Which of the two in-chain streams pays more per GPU-second depends on the size of the fleet" with the 4.9x and 930x arithmetic marked approximate. Was: Open, minor; the simulator half re-run (5 October 2026 sweep). a repository file with the 5090 class at 124 MH/s (the devnet's measured rate) in place of 229, scenarios a and b, 2 seeds, 111 s: baseline profit USD 5.59 per 5090 card-day (6.37 at 229), 3090 2.73 (1.66), 3060 1.34 (0.78), small 0.74 (0.39); under the b shock 4.52 / 2.25 / 1.46 / 0.30; no backlog, every block proven within 60 s, hash trough 75% of pre-event under b (82% at 229), 5% of cards off (10%), oscillation flag in 1 of 2 seeds. The direction is as the review said: a slower flagship card shifts income toward the smaller classes and makes the fleet more sensitive to the price shock. The draw lines (nvidia-smi on both PCs, powermetrics on the Apple M5 Max) need the machines (person). Was: Open, minor (4 October 2026).
+The answer as first written
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.
E18
The dev fee is a protocol fee with better PR
4 October 2026
A 1% dev fee in the official miner is 1% of the chain's hashrate paid to one company for as long as miners run it. Call it what it is: a founder allocation, hidden in the client, and nobody can tell how often it really fires.
Answered by design and with evidence 4 October 2026, evening; the owner's decision of that evening, branch dev-fee in both repositories).
-The answer as first written
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, igneum/miner/src/main.rs, 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.
The answer as first written
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.
Launch and operations
X29
Host and file hygiene, minor
6 October 2026
-The Mac's live node binds its gRPC to every interface. Four secrets or pointers in ~/.config/igneum are world-readable, one token is a filename, and the intake key rides on curl's command line. The manifest answers CORS * and the clock source is a cacheable page's Date header.
-Decided 6 October 2026, 17:25 UTC, by the owner; decisions item 9): node 1 binds its RPC to localhost at its next planned restart, and the wallet's node too; PC 2 on its own node or a tunnel. Was: Fixed on a branch, pending merge (5 October 2026, night), the curl part: ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Open: the live node's --rpclisten (decision, operator, group E) and the app's clock source (round 2). Was: Open, minor (4 October 2026). Sweep (5 October 2026): read-only checks on this Mac: every secret under ~/.config/igneum is now mode 600 (only ota-signing-key.pub is world-readable, as it should be), so that half is fixed; the live node still listens on every interface (lsof: igneumd on *:26610). The curl command line and the clock source were not re-checked.
-The answer as first written
Correct. --rpclisten=0.0.0.0:26610 on pid 33114 (no --unsafe-rpc, --disable-upnp); ls -la ~/.config/igneum; app/igneum-app/src/update.rs (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 PC 2 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.
The Mac's live node binds its gRPC to every interface. Four secrets or pointers in a config file are world-readable, one token is a filename, and the intake key rides on curl's command line. The manifest answers CORS * and the clock source is a cacheable page's Date header.
+Decided 6 October 2026, 17:25 UTC, by the owner; decisions item 9): node 1 binds its RPC to localhost at its next planned restart, and the wallet's node too; the Windows machine on its own node or a tunnel. Was: Fixed on a branch, pending merge (5 October 2026, night), the curl part: ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (a repository file) + 2 CI class checks. Open: the live node's --rpclisten (decision, operator, group E) and the app's clock source (round 2). Was: Open, minor (4 October 2026). Sweep (5 October 2026): read-only checks on this Mac: every secret under a config file is now mode 600 (only ota-signing-key.pub is world-readable, as it should be), so that half is fixed; the live node still listens on every interface (lsof: igneumd on *:26610). The curl command line and the clock source were not re-checked.
+The answer as first written
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.
X30
The live page and the bench page exposed operational detail
4 October 2026
@@ -1221,11 +1221,11 @@ details{margin-top:8px;font-size:14px;color:var(--ash)}summary{cursor:pointer;co
P23
An unwound transaction leaves the node's view until its sender resends it
6 October 2026
Your pool learns about chain blocks (on_chain_block) and about nothing else. A selected-chain reorg unwinds a transaction out of the executed set and the pool never gets it back. The RPC can say reorged out all it likes; the transaction is gone unless the wallet resends, and most wallets do not.
-Fixed on a branch, pending merge 6 October 2026, night, ledger close round 3): fork ledger-fixes-0311 fbb0082a (the P23 commit, on the merge of ledger-fixes and ledger-fixes-2 onto the 0.3.11 fork tip 89dfcb95); EvmPool::on_chain_removed (igneum/exec/src/pool.rs) and ExecService::requeue_unwound (service.rs) with ExecState::unwound collected by truncate_to; unit tests pool::tests::a_reorg_hands_the_unwound_transactions_back_to_the_pool_in_nonce_order and rpc::p17_tests::a_reorg_collects_the_unwound_transactions_in_chain_order_for_the_pool, igneum-exec 23 of 23 on the Mac (labelled a Mac run); the O-7.2 conformance run on the rebased binaries PASSED (409.9 s) with the reorged out case ending in executed 2.4 s later without a resend (n2's log: reorg: 1 unwound transactions handed back to the pool as pending, 0 refused; bench-log "ledger close round 3"); PC 2 job build-20261006-012543 built fbb0082a for Linux and Windows and ran the seven suites, exit 0 in 46 s, without the igneum-pow feature, so the Mac run is the suite evidence. Was: Open, found in round 2 (6 October 2026, night, the P17 conformance run on ledger-fixes-2); fix named, owner the execution engineer; round 3 (ledger-rebase) carries it with the fork rebase. Found by: the ledger-pc2 agent's O-7.2 conformance driver (tools/p17-conformance/run.mjs, the "reorged out" path), recorded as finding (1) in the P17 round-2 paragraph.
-The answer as first written
Correct. igneum/exec/src/pool.rs 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.
Fixed on a branch, pending merge 6 October 2026, night, ledger close round 3): fork ledger-fixes-0311 fbb0082a (the P23 commit, on the merge of ledger-fixes and ledger-fixes-2 onto the 0.3.11 fork tip 89dfcb95); EvmPool::on_chain_removed (a repository file) and ExecService::requeue_unwound (service.rs) with ExecState::unwound collected by truncate_to; unit tests pool::tests::a_reorg_hands_the_unwound_transactions_back_to_the_pool_in_nonce_order and rpc::p17_tests::a_reorg_collects_the_unwound_transactions_in_chain_order_for_the_pool, igneum-exec 23 of 23 on the Apple M5 Max (labelled a Mac run); the O-7.2 conformance run on the rebased binaries PASSED (409.9 s) with the reorged out case ending in executed 2.4 s later without a resend (n2's log: reorg: 1 unwound transactions handed back to the pool as pending, 0 refused; bench-log "ledger close round 3"); the Windows machine job build-20261006-012543 built fbb0082a for Linux and Windows and ran the seven suites, exit 0 in 46 s, without the igneum-pow feature, so the Apple M5 Max run is the suite evidence. Was: Open, found in round 2 (6 October 2026, night, the P17 conformance run on ledger-fixes-2); fix named, owner the execution engineer; round 3 (ledger-rebase) carries it with the fork rebase. Found by: the ledger-pc2 agent's O-7.2 conformance driver (a repository file, the "reorged out" path), recorded as finding (1) in the P17 round-2 paragraph.
+The answer as first written
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.
Source: docs/fud-ledger.md in the repository, rendered by tools/ledger-page.mjs. A criticism that is not here, or that shows an entry is wrong, is added with credit if wanted: hello@igneum.network or an issue on the specification repository.
+Source: the project's criticism ledger, a file in the repository, rendered to this page at build time; the repository is published at the public testnet. A criticism that is not here, or that shows an entry is wrong, is added with credit if wanted: hello@igneum.network or an issue on the specification repository.