Night battery 2026-10-07: 76 pass, 19 FAIL on master d79f4a61, fork release-0.3.17-node b49c58c1

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

.claude/agents/consensus-engineer.md

@@ -5,7 +5,7 @@ tools: Read, Grep, Glob, Bash, Edit, Write, WebSearch, WebFetch, Agent
 model: fable
 ---
 
-You are the consensus engineer on a GPU-mined layer 1 built on a fork of rusty-kaspa. Read CLAUDE.md in the project root first, then the design doc it links to. The doc's decisions are fixed unless the founder changes them.
+You are the consensus engineer on a GPU-mined layer 1 built on a fork of rusty-kaspa. Read CLAUDE.md in the project root first, then the design doc it links to. The doc's decisions are fixed unless the project lead changes them.
 
 ## What you carry in your head
 The code of every major PoW node and how each one handles the problems you are about to meet:

.claude/agents/cryptographer.md

@@ -5,7 +5,7 @@ tools: Read, Grep, Glob, Bash, WebSearch, WebFetch, Agent
 model: fable
 ---
 
-You are the cryptographer and proof-systems engineer on a GPU-mined layer 1 whose miners are also its ZK provers. Read CLAUDE.md in the project root first, then the design doc it links to. The doc's decisions are fixed unless the founder changes them.
+You are the cryptographer and proof-systems engineer on a GPU-mined layer 1 whose miners are also its ZK provers. Read CLAUDE.md in the project root first, then the design doc it links to. The doc's decisions are fixed unless the project lead changes them.
 
 ## What you carry in your head
 The whole history of proof of work and of proof systems, and you use it. When you make a claim about a chain, name the chain, the mechanism and where it lives in that chain's code. Examples of what you draw on:
@@ -29,7 +29,7 @@ The whole history of proof of work and of proof systems, and you use it. When yo
 - Numbers are measured or cited. A number from memory is labelled approximate. Never state an ASIC gain, a proving time or a verification time you have not measured or sourced.
 - Write for an external reviewer: a spec section should let a stranger reproduce the argument.
 - Prototype in Rust, with Metal on this Mac for GPU work and CUDA or OpenCL ports noted for miners. Benchmarks go in bench/ with the exact command and hardware.
-- When you disagree with the design doc, say so once, with the attack or the measurement that drives it, then do the work under the doc's decision unless the founder overrides.
+- When you disagree with the design doc, say so once, with the attack or the measurement that drives it, then do the work under the doc's decision unless the project lead overrides.
 
 ## Writing rules
 No em dashes. Short sentences. Numbers in tables. The project is called Igneum. Approximate figures say so.

.claude/agents/execution-engineer.md

@@ -5,7 +5,7 @@ tools: Read, Grep, Glob, Bash, Edit, Write, WebSearch, WebFetch, Agent
 model: fable
 ---
 
-You are the execution engineer on a GPU-mined layer 1 whose every block is ZK-proven by its miners. Read CLAUDE.md in the project root first, then the design doc it links to. The doc's decisions are fixed unless the founder changes them.
+You are the execution engineer on a GPU-mined layer 1 whose every block is ZK-proven by its miners. Read CLAUDE.md in the project root first, then the design doc it links to. The doc's decisions are fixed unless the project lead changes them.
 
 ## What you carry in your head
 Every Ethereum client and every open zkVM, and what it costs to prove them:

.claude/agents/miner-community-lead.md

@@ -5,7 +5,7 @@ tools: Read, Grep, Glob, Bash, WebSearch, WebFetch, Agent
 model: fable
 ---
 
-You are the miner-community lead on a GPU-mined layer 1 whose miners are also its ZK provers. Read CLAUDE.md in the project root first, then the design doc it links to. The doc's decisions are fixed unless the founder changes them.
+You are the miner-community lead on a GPU-mined layer 1 whose miners are also its ZK provers. Read CLAUDE.md in the project root first, then the design doc it links to. The doc's decisions are fixed unless the project lead changes them.
 
 ## What you carry in your head
 Fifteen years of mining communities, and you remember what they did and why:

.github/workflows/ci-red.yml

@@ -1,48 +0,0 @@
-# The red watcher as its own workflow, on workflow_run, so the copy on master watches EVERY branch's ci run whatever
-# ci.yml that branch carries: GitHub runs a workflow_run workflow from the default branch only, and the branch's own
-# ci.yml never enters it (7 October 2026: the inline `red` job of ci.yml was conditioned on master and release-*, and
-# a feature branch would have waited for a merge of master before its reds were posted at all).
-#
-# One line per failed, cancelled or timed-out run (tools/ci/red-watch.mjs record, idempotent per run attempt) to /srv/ci-red/red.jsonl on the
-# box; the box's igneum-ci-red.timer posts each new line once to the hidden updates channel, naming the branch, the
-# commit, the red check and the pushing author. Runs on the box's own runner (not a GitHub-hosted machine: the billing
-# block of 6 October 2026, 18:37Z to 20:10Z, failed every hosted job at start and nobody was told). Never blocks a
-# release: it reads the run, writes one line, and ends.
-name: ci-red
-on:
-  workflow_run:
-    workflows: [ci]
-    types: [completed]
-jobs:
-  red:
-    name: red watcher (every branch; one line per failed run, with the branch, commit, red check and pushing author, to the updates channel and the box file)
-    # failure, and since 7 October 2026 (17:2x UK) cancelled and timed_out too: a job that hangs into its timeout-minutes or a run
-    # someone cancels is a run that never answered, and a lane reads it like a red (tools/ci/red-watch.mjs names the kind)
-    if: ${{ github.event.workflow_run.conclusion == 'failure' || github.event.workflow_run.conclusion == 'cancelled' || github.event.workflow_run.conclusion == 'timed_out' }}
-    # the label ci-red is on igneum-build-1 only (added through the runners API on 7 October 2026; the default of
-    # RUNNER_LABELS in provision.sh carries it): the record file and the poster (igneum-ci-red.timer, the webhook file)
-    # live on that box, and the pool label igneum-build-1 is shared with igneum-build-2 since the same day
-    runs-on: [self-hosted, linux, x64, ci-red]
-    timeout-minutes: 5
-    permissions:
-      actions: read     # the failed run's jobs API (the first real red run, 21:19Z on 6 October: the default token answered 403 and the line carried no step)
-      contents: read
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          sparse-checkout: tools/ci
-      - name: record the failed run (one line, the branch, the commit, the failed jobs and their first failed step from the run's own API, the pushing author)
-        env:
-          GITHUB_TOKEN: ${{ github.token }}
-          RED_WATCH_RUN_ID: ${{ github.event.workflow_run.id }}
-          RED_WATCH_ATTEMPT: ${{ github.event.workflow_run.run_attempt }}
-          RED_WATCH_WORKFLOW: ${{ github.event.workflow_run.name }}
-          RED_WATCH_CONCLUSION: ${{ github.event.workflow_run.conclusion }}
-          RED_WATCH_BRANCH: ${{ github.event.workflow_run.head_branch }}
-          RED_WATCH_SHA: ${{ github.event.workflow_run.head_sha }}
-          RED_WATCH_EVENT: ${{ github.event.workflow_run.event }}
-          RED_WATCH_URL: ${{ github.event.workflow_run.html_url }}
-          RED_WATCH_ACTOR: ${{ github.event.workflow_run.actor.login }}
-          RED_WATCH_TITLE: ${{ github.event.workflow_run.head_commit.message }}
-          RED_WATCH_AUTHOR: ${{ github.event.workflow_run.head_commit.author.name }}
-        run: node tools/ci/red-watch.mjs record --file /srv/ci-red/red.jsonl

.github/workflows/ci.yml

@@ -8,16 +8,12 @@
 # local gate and CI cannot drift (6 October 2026: 131 red `ci` runs in three days, 92 of them on master, every one a
 # tree check that would have failed on the pushing machine in under 25 s; docs/analysis/ci-failures-2026-10-06.md).
 #
-# Where it runs: `pow` and `sims` go to the self-hosted pool (label igneum-build-1: the runners on igneum-build-1 and, since
-# 7 October 2026, igneum-build-2, which carries that label too; rustc pinned, sccache read-only) and only when the push
-# touched code (the `changes` job; a docs-only push skips them)
+# Where it runs: `pow` and `sims` go to the box's runner (igneum-build-1, rustc pinned, sccache read-only, 48 jobs)
 # when the repository variable IGNEUM_CI_RUNNER is `box`, else to ubuntu-latest (docs/plans/ci-self-hosted.md; GitHub
-# has no fallback in runs-on, the variable is the switch). The `site` job stays on GitHub's machines. The red watcher
-# is its own workflow, .github/workflows/ci-red.yml (workflow_run, so the copy on master watches every branch's run
-# whatever ci.yml that branch carries): one line per failed run, naming the branch, the commit, the red check and the
-# pushing author, to the hidden updates channel and to /srv/ci-red/red.jsonl (tools/ci/red-watch.mjs;
-# infra/build-server/ci-red), so nobody opens the Actions page to learn a branch is red (the inline `red` job here
-# watched master and release-* only until 7 October 2026, when eight red runs on ca3-v4-node went unseen).
+# has no fallback in runs-on, the variable is the switch). The `site` job stays on GitHub's machines. The `red` job
+# runs on the box after any failed master or release-* run and records the failure for the watcher
+# (tools/ci/red-watch.mjs; infra/build-server/ci-red): one line per run to the hidden updates channel and to
+# /srv/ci-red/red.jsonl, so nobody opens the Actions page to learn master is red.
 #
 # What does not run, on purpose: the node fork (vendor/igneum-node*, a rusty-kaspa fork of about 500 crates with
 # rocksdb, blst and the execution layer) is gitignored here and too big for the free runners today (a cold build is
@@ -28,42 +24,9 @@ on:
   push:
   pull_request:
 jobs:
-  changes:
-    # What the push touched (tools/ci/docs-only-check.sh): a push of documents only (docs/, site/, *.md) skips the two
-    # compile-or-compute jobs below, which read none of those paths, so the self-hosted queue carries only runs that can
-    # change their result (7 October 2026: 31 runs queued on one runner, most of them status-document pushes). The tree
-    # gate (the `site` job) runs on ubuntu-latest for every push. A pull request, a new branch or a force push answers
-    # code=true (no `before` to compare from), as does any error reading the compare API: when in doubt, run.
-    name: what the push touched (docs-only runs skip the Rust and simulator jobs)
-    runs-on: ubuntu-latest
-    timeout-minutes: 10   # a 7 s API call; every job carries a budget (tools/ci/workflow-timeouts-check.sh)
-    outputs:
-      code: ${{ steps.classify.outputs.code }}
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          sparse-checkout: tools/ci
-      - id: classify
-        env:
-          GH_TOKEN: ${{ github.token }}
-          BEFORE: ${{ github.event.before }}
-          AFTER: ${{ github.sha }}
-          REPO: ${{ github.repository }}
-          EVENT: ${{ github.event_name }}
-        run: |
-          if [ "$EVENT" != push ] || [ -z "$BEFORE" ] || [ "$BEFORE" = 0000000000000000000000000000000000000000 ]; then
-            echo "code=true" >> "$GITHUB_OUTPUT"; echo "no base to compare from ($EVENT): the compile jobs run"; exit 0
-          fi
-          files="$(gh api "repos/$REPO/compare/$BEFORE...$AFTER" --paginate --jq '.files[].filename' 2>/dev/null || true)"
-          line="$(printf '%s\n' "$files" | bash tools/ci/docs-only-check.sh)"
-          echo "$line" >> "$GITHUB_OUTPUT"
-          echo "$line: $(printf '%s\n' "$files" | grep -c .) changed path(s) between ${BEFORE:0:8} and ${AFTER:0:8}"
   pow:
     name: igneum-pow tests, igneum-census build
-    needs: changes
-    if: ${{ needs.changes.outputs.code == 'true' }}
     runs-on: ${{ vars.IGNEUM_CI_RUNNER == 'box' && fromJSON('["self-hosted", "linux", "x64", "igneum-build-1"]') || 'ubuntu-latest' }}
-    timeout-minutes: 60   # the box's suite ran 45 s to 2 min 40 s on 7 October 2026; a hosted fallback compiles cold
     steps:
       - uses: actions/checkout@v4
       - name: toolchain
@@ -78,12 +41,7 @@ jobs:
         run: cargo build --release
   sims:
     name: simulators, quick modes
-    needs: changes
-    # master and release-* pushes, and pull requests into them, only (main, 7 October 2026: every code push cost two box jobs and the
-    # queue read 22); a feature-branch code push runs the igneum-pow tests alone. tools/ci/sims-branch-check.sh holds this rule.
-    if: ${{ needs.changes.outputs.code == 'true' && ((github.event_name == 'push' && (github.ref == 'refs/heads/master' || startsWith(github.ref, 'refs/heads/release-'))) || (github.event_name == 'pull_request' && (github.base_ref == 'master' || startsWith(github.base_ref, 'release-')))) }}
     runs-on: ${{ vars.IGNEUM_CI_RUNNER == 'box' && fromJSON('["self-hosted", "linux", "x64", "igneum-build-1"]') || 'ubuntu-latest' }}
-    timeout-minutes: 45   # two simulators under 120 s each by their own timeout, plus a hosted fallback's pip install
     steps:
       - uses: actions/checkout@v4
       - uses: actions/setup-python@v5
@@ -107,22 +65,37 @@ jobs:
   site:
     name: site build, link check, identity grep
     runs-on: ubuntu-latest
-    # 15: the gate took 229 s on a hosted runner on 7 October 2026 plus a 40 s Playwright install; the same day three
-    # hosted site jobs on master hung in the gate for over two hours each with no budget, and GitHub's six-hour default
-    # would have ended each as a failure email. A hung job is a red the watcher posts (ci-red.yml fires on timed_out).
-    timeout-minutes: 15
     steps:
       - uses: actions/checkout@v4
       - uses: actions/setup-node@v4
         with:
           node-version: '22'
-      - name: a headless Chromium for the text-overlap sweep (Playwright outside the tree; the gate finds it through IGNEUM_PLAYWRIGHT_DIR)
-        run: |
-          mkdir -p /tmp/pw && cd /tmp/pw && npm init -y >/dev/null && npm i --no-audit --no-fund playwright@1.56 | tail -1
-          npx playwright install --with-deps chromium | tail -1
-          echo "IGNEUM_PLAYWRIGHT_DIR=/tmp/pw" >> "$GITHUB_ENV"
       - name: the tree gate, tools/ci/pre-push.sh --ci (the same script the pre-push hook runs; one line per check, a red check prints its output)
         run: bash tools/ci/pre-push.sh --ci
       - name: public stats API answers with the documented fields (the live site; master only, the endpoints exist there after the merge)
         if: github.ref == 'refs/heads/master'
-        run: bash tools/ci/retry-once.sh public-api node tools/ci/public-api-check.mjs https://igneum.network   # a live host: one retry before red
+        run: node tools/ci/public-api-check.mjs https://igneum.network
+
+  red:
+    # Runs only when a master or release-* run has a failed job, on the box's own runner (not a GitHub-hosted machine:
+    # the billing block of 6 October 2026, 18:37Z to 20:10Z, failed every hosted job at start and nobody was told).
+    # tools/ci/red-watch.mjs record appends ONE line for this run to /srv/ci-red/red.jsonl (idempotent per run attempt);
+    # the box's igneum-ci-red.timer posts each new line once to the hidden updates channel. Never blocks a release:
+    # it reads the run, writes one line, and ends.
+    name: red watcher (master and release-* only; one line per failed run to the updates channel and the box file)
+    needs: [pow, sims, site]
+    if: ${{ failure() && (github.ref == 'refs/heads/master' || startsWith(github.ref, 'refs/heads/release-')) }}
+    runs-on: [self-hosted, linux, x64, igneum-build-1]
+    timeout-minutes: 5
+    permissions:
+      actions: read     # the run's jobs API (the first real red run, 21:19Z: the default token answered 403 and the line carried no step)
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          sparse-checkout: tools/ci
+      - name: record this run (one line, the failed jobs and their first failed step, from the run's own API)
+        env:
+          GITHUB_TOKEN: ${{ github.token }}
+          RED_WATCH_TITLE: ${{ github.event.head_commit.message }}
+        run: node tools/ci/red-watch.mjs record --file /srv/ci-red/red.jsonl

.github/workflows/windows.yml

@@ -216,14 +216,8 @@ jobs:
         run: |
           $payload = Resolve-Path 'packaging\windows\igneum-windows-app'
           function Run-Capture([string]$exe, [string]$flag) {
-            # Start-Process -Wait on an exe that exits in milliseconds can throw "Cannot process request because the process has
-            # exited" before it attaches (release-0.3.21 run 37653903394, 7 October 2026, 17:40 UK): one retry before the verdict.
             $out = Join-Path $env:RUNNER_TEMP ('smoke-' + [IO.Path]::GetRandomFileName() + '.txt')
-            $p = $null
-            foreach ($try in 1, 2) {
-              try { $p = Start-Process -FilePath $exe -ArgumentList $flag -Wait -NoNewWindow -PassThru -RedirectStandardOutput $out; break }
-              catch { if ($try -eq 2) { throw }; Write-Host ("Start-Process on {0} {1} failed once ({2}); second try" -f (Split-Path -Leaf $exe), $flag, $_.Exception.Message); Start-Sleep -Milliseconds 500 }
-            }
+            $p = Start-Process -FilePath $exe -ArgumentList $flag -Wait -NoNewWindow -PassThru -RedirectStandardOutput $out
             $text = if (Test-Path $out) { (Get-Content $out -Raw) } else { '' }
             Write-Host ("{0} {1} -> exit {2}: {3}" -f (Split-Path -Leaf $exe), $flag, $p.ExitCode, $text.Trim())
             if ($p.ExitCode -ne 0) { throw "$exe $flag exited $($p.ExitCode)" }

app/igneum-app/build.rs

@@ -1,6 +1,6 @@
 // Build script for igneum-app. On a Windows target it compiles resources/igneum-app.rc (the coin icon Explorer shows
 // and the version block under Properties > Details) with windres and links the object into igneum-app.exe. Other
-// targets: nothing. The founder's rule (4 October 2026): every shipped exe carries the coin icon and a version block, like the
+// targets: nothing. the project lead's rule (4 October 2026): every shipped exe carries the coin icon and a version block, like the
 // Mac app and DMG. No crate dependency: windres is called directly (x86_64-w64-mingw32-windres from Homebrew mingw-w64
 // on the Mac, windres from MSYS2 on a PC; IGNEUM_WINDRES names another one).
 use std::env;

app/igneum-app/resources/igneum-app.rc

@@ -1,6 +1,6 @@
 // Windows resources for igneum-app.exe: the coin icon Explorer shows and the version block under Properties > Details.
 // Compiled with x86_64-w64-mingw32-windres (the icon path is relative to brand/icons, passed with -I).
-// the founder's rule (4 October 2026): every shipped exe carries the coin icon and a version block, like the Mac app and DMG.
+// the project lead's rule (4 October 2026): every shipped exe carries the coin icon and a version block, like the Mac app and DMG.
 #include <winver.h>
 
 1 ICON "igneum.ico"

app/igneum-app/src/config.rs

@@ -87,7 +87,7 @@ pub struct Settings {
     /// (on when that is switched on, never effective while it is off). A pinned card is skipped.
     #[serde(default)]
     pub sweep: bool,
-    /// Power control (the founder, 5 October 2026: "if we don't have to ask then don't ask"): the NVIDIA power cap and the
+    /// Power control (the project lead, 5 October 2026: "if we don't have to ask then don't ask"): the NVIDIA power cap and the
     /// efficiency sweep need administrator rights (one UAC prompt on Windows). Default OFF on every machine; the app
     /// never raises the prompt on its own. Switching it on asks once, at that moment; a refused, cancelled or
     /// unanswered prompt switches it back off with a notice, no retries.
@@ -345,7 +345,7 @@ pub struct Runtime {
     pub host: String,
     /// Per-install random id (16 hex, app data dir/machine-id, locked to the user). Identity labels, vote keys and
     /// the upload fields come from this, so two PCs cloned with the same COMPUTERNAME never share a key
-    /// (found 4 October 2026 on the founder's two DESKTOP-KMCV30N machines).
+    /// (found 4 October 2026 on the project lead's two DESKTOP-KMCV30N machines).
     pub machine_id: String,
 }
 
@@ -357,7 +357,7 @@ impl Runtime {
         let p2p_port = env("IGNEUM_APP_P2P_PORT").and_then(|v| v.parse().ok()).unwrap_or(26611);
         let peers = match std::env::var("IGNEUM_APP_PEERS") {
             Ok(v) => v.split(',').map(|s| s.trim().to_string()).filter(|s| !s.is_empty()).collect(),
-            // the public seed node first, then the founder's Mac on the house LAN (devnet only)
+            // the public seed node first, then the project lead's Mac on the house LAN (devnet only)
             Err(_) if network == "devnet" => vec!["188.245.5.161:26611".to_string(), "192.168.68.64:26611".to_string()],
             Err(_) => vec![],
         };

app/igneum-app/src/engine.rs

@@ -4079,7 +4079,7 @@ impl Engine {
 }
 
 /// The watts a card's cap asks for: power_pct of the default limit, inside the card's min and max.
-/// the founder, 5 October 2026: "if we don't have to ask then don't ask". The NVIDIA power cap and the efficiency sweep need
+/// the project lead, 5 October 2026: "if we don't have to ask then don't ask". The NVIDIA power cap and the efficiency sweep need
 /// administrator rights (one UAC prompt on Windows, pkexec on Linux); the engine builds an elevated command only when
 /// Power control is on in Settings, or when it is itself the elevated PC sweep job (--sweep).
 fn elevation_allowed(power_control: bool, sweep_only: bool) -> bool {
@@ -4351,7 +4351,7 @@ mod resume_tests {
 mod tests {
     #[test]
     fn power_control_off_builds_no_elevated_command() {
-        // the decision (the founder, 5 October 2026): off = the app never asks; the elevated PC sweep job is the exception
+        // the decision (the project lead, 5 October 2026): off = the app never asks; the elevated PC sweep job is the exception
         assert!(!super::elevation_allowed(false, false));
         assert!(super::elevation_allowed(true, false));
         assert!(!super::elevation_allowed(false, true), "the --sweep job alone never asks (C35)");

app/igneum-app/src/jobbuild.rs

@@ -1,5 +1,5 @@
 //! The `build` job (the model is src/jobs.rs, the runner src/jobrun.rs): a Windows PC builds the node and the app
-//! engine for Linux and Windows inside its WSL2 Ubuntu, as root, with nothing from the founder. The founder's ask, 4 October 2026
+//! engine for Linux and Windows inside its WSL2 Ubuntu, as root, with nothing from the project lead. the project lead's ask, 4 October 2026
 //! evening ("efficiency"): every Windows build went through a GitHub runner at 15 to 25 minutes a round and every
 //! Linux binary was cross-compiled on the Mac under the build lock; the two RTX 5090 PCs sit idle on the CPU side.
 //!

app/igneum-app/src/jobrun.rs

@@ -32,7 +32,7 @@ use std::sync::atomic::{AtomicBool, Ordering};
 use std::sync::{Arc, Mutex};
 use std::time::{Duration, Instant};
 
-/// The safety-net poll. Before 0.3.6 this was 600 s and a published job waited up to 10 minutes on every PC (the founder,
+/// The safety-net poll. Before 0.3.6 this was 600 s and a published job waited up to 10 minutes on every PC (the project lead,
 /// 5 October 2026: "why is it taking so long for pc2 and pc1s tasks to spin up?"); the wake below makes it seconds.
 const CHECK_EVERY_S: u64 = 120;
 const RETRY_AFTER_ERROR_S: u64 = 300;
@@ -50,7 +50,7 @@ const GPU_IDLE_PCT: f64 = 5.0;
 const GPU_IDLE_WAIT_S: u64 = 180;
 const DEFAULT_DISTRO: &str = "Ubuntu-24.04";
 /// WSL jobs run as root by default: the Ubuntu the app sees is the one of the account the app runs under, and a
-/// personal user (<user> on PC 2) need not exist there (4 October 2026: `getpwnam(<user>) failed`).
+/// personal user ([user] on PC 2) need not exist there (4 October 2026: `getpwnam([user]) failed`).
 const DEFAULT_WSL_USER: &str = "root";
 const DEFAULT_FIXTURES: &[&str] = &["block-338-shard1", "block-341-shards2", "block-344-shards4"];
 const HISTORY_SHOWN: usize = 20;

app/igneum-app/src/jobs.rs

@@ -2,7 +2,7 @@
 //! manifest on the downloads host, and every Igneum Miner app polls it (src/jobrun.rs, every 10 minutes). A job
 //! runs at most once per id on a machine, only when its target matches (machine id, platform, requirements) and
 //! it has not expired. Same key, same canonical JSON (sorted keys, no whitespace) and the same `.sig` scheme as the
-//! update manifest (src/manifest.rs). The founder's rule, 4 October 2026: one app on both PCs that the Mac can send
+//! update manifest (src/manifest.rs). the project lead's rule, 4 October 2026: one app on both PCs that the Mac can send
 //! commands and files to over the line, so everything is tested and built without a person at the PC.
 //!
 //! This module is self-contained (serde_json and manifest.rs only), so the signer (src/bin/ota-sign.rs) includes it

app/igneum-app/src/ota.rs

@@ -1,4 +1,4 @@
-//! Over-the-air updates of the app (and the node, miner and workers inside it). The founder's rule: every app updates
+//! Over-the-air updates of the app (and the node, miner and workers inside it). the project lead's rule: every app updates
 //! itself and downloads the update without being asked. This is also how a consensus upgrade (a height-activated
 //! rule such as difficulty v2) reaches every node before its activation height.
 //!
@@ -120,7 +120,7 @@ pub struct Updater {
     /// this machine's minute of the hour for applying (manifest::slot_minute of the machine id)
     slot: u64,
     /// When this engine started (unix seconds): an update published more than an hour before it is a catch-up, not a
-    /// rollout, and skips the hourly slot (the founder's morning of 6 October 2026: PC 1 came up after the 0.3.11 publish and
+    /// rollout, and skips the hourly slot (the project lead's morning of 6 October 2026: PC 1 came up after the 0.3.11 publish and
     /// sat on "installs at the next safe moment" until he pressed Install now).
     started_unix: u64,
     catch_up_logged: bool,

app/igneum-app/src/powertask.rs

@@ -1,4 +1,4 @@
-//! One administrator approval, ever (the founder, 6 October 2026, 11:50 UTC, after clicking the third prompt of the morning:
+//! One administrator approval, ever (the project lead, 6 October 2026, 11:50 UTC, after clicking the third prompt of the morning:
 //! "can we make sure all these popups are not needed in future?").
 //!
 //! What 0.3.12 does: Power control on raises one prompt and sets every cap in that step; but every later cap (an app

app/igneum-app/src/provedefault.rs

@@ -1,4 +1,4 @@
-//! Proving v1 step 1 (5 October 2026, the founder: "open the proving round asap"): the prover is on by default on every
+//! Proving v1 step 1 (5 October 2026, the project lead: "open the proving round asap"): the prover is on by default on every
 //! mining machine that can prove, decided once per install after the cards are detected (src/engine.rs
 //! `apply_prove_default`). The rule, one line each:
 //!
@@ -6,13 +6,13 @@
 //! |---|---|---|
 //! | NVIDIA card with 24 GB or more, mining or not, Windows with WSL2 (Ubuntu-24.04) answering or Linux | on | a full shard at the adopted v1 budget (30,000 pgas, 4.7 M cycles) peaks at 20,434 MiB alone and 22,210 beside the miner (measured on the 5090; approximate for a 24 GB card's own allocation); the prototype shard the devnet proves until its fee switch (6.75 M pgas) peaks at 28,307 MiB alone and 30,039 beside the miner, so until the switch only a 32 GB card proves it and a 24 GB card's prover waits for shards it can hold (the host refuses nothing; a proof that runs out of memory fails and the shard is left) |
 //! | NVIDIA card of 16 to 24 GB | off, with the line saying why | the GPU prover's floor is 13,874 MiB for an EMPTY shard, 15,670 beside the miner; a 16 GB card holds no full shard |
-//! | NVIDIA card under 16 GB | off | 13,874 MiB does not fit; the founder's 12 GB requirement is open until a prover build with a smaller floor is measured |
+//! | NVIDIA card under 16 GB | off | 13,874 MiB does not fit; the project lead's 12 GB requirement is open until a prover build with a smaller floor is measured |
 //! | Windows under 32 GB of RAM | off, with the line saying why | the WSL2 prover held 7.9 GB on a 63 GB PC; a 16 GB PC would swap |
 //! | Windows with a qualifying card but WSL2 silent | off, with the Set up hint | nothing can prove until the distribution exists |
 //! | Apple silicon | off | the M5 Max CPU took 41 to 55 s for an EMPTY shard's compressed proof under load and 272 s for a 200-pgas shard; a full shard was never under 60 s (bench-log 4 and 5 October 2026) |
 //! | AMD-only (no NVIDIA card) | off, "mines and does not prove" | no zkVM proves on an AMD GPU today (docs/analysis/amd-proving.md); the SP1 CPU prover on PC 1 cost 82 to 87 s core plus 199 to 202 s compressed a shard at a 30 GB RSS whatever the shard size (bench-log, "the SP1 CPU prover on PC 1") |
 //!
-//! Decided 5 October 2026 (delegated by the founder: "deploy what is absolute best"), docs/plans/proving-v1.md. The default
+//! Decided 5 October 2026 (delegated by the project lead: "deploy what is absolute best"), docs/plans/proving-v1.md. The default
 //! never switches an explicit on back off, and Settings always wins afterwards.
 
 use crate::state::CardState;

app/igneum-app/src/state.rs

@@ -127,7 +127,7 @@ pub struct CardState {
     pub tune_source: String,   // full | confirm | baseline
     pub tune_line: String,     // "Tuned: 122.3 MH/s at 290 W (0.422 MH/W)" once tuned
     // a tune in progress on this card, by this engine or by a measurement engine posting /api/tune-progress
-    // (the founder, 6 October 2026: "don't we need to show in the app that tuning is in progress?")
+    // (the project lead, 6 October 2026: "don't we need to show in the app that tuning is in progress?")
     pub tune_step: u32,
     pub tune_steps: u32,
     pub tune_eta_s: i64,

app/igneum-app/src/wslhost.rs

@@ -221,11 +221,11 @@ mod tests {
 
     #[test]
     fn the_command_line_after_the_dashes_never_carries_a_double_quote_or_a_newline() {
-        let file = Path::new("C:\\Users\\the founder\\AppData\\Local\\igneum\\wsl\\probe-12-3.sh");
-        let line = bash_line(file, true, &["--proof", "/mnt/c/Users/the founder/AppData/Local/igneum/app/proving/p.bin", "--statement", "0xab", "it's", "two\nlines"]);
+        let file = Path::new("C:\\Users\\the project lead\\AppData\\Local\\igneum\\wsl\\probe-12-3.sh");
+        let line = bash_line(file, true, &["--proof", "/mnt/c/Users/the project lead/AppData/Local/igneum/app/proving/p.bin", "--statement", "0xab", "it's", "two\nlines"]);
         assert_eq!(
             line,
-            "bash -l '/mnt/c/Users/the founder/AppData/Local/igneum/wsl/probe-12-3.sh' '--proof' '/mnt/c/Users/the founder/AppData/Local/igneum/app/proving/p.bin' '--statement' '0xab' 'it'\\''s' 'two lines'"
+            "bash -l '/mnt/c/Users/the project lead/AppData/Local/igneum/wsl/probe-12-3.sh' '--proof' '/mnt/c/Users/the project lead/AppData/Local/igneum/app/proving/p.bin' '--statement' '0xab' 'it'\\''s' 'two lines'"
         );
         assert!(!line.contains('"') && !line.contains('\n'), "{line}");
         // the lookup script's own double quotes live in the file, never on the line
@@ -282,7 +282,7 @@ mod tests {
 
     #[test]
     fn wsl_paths() {
-        assert_eq!(wsl_path(Path::new("C:\\Users\\<user>\\AppData\\Local\\igneum\\app\\proving\\seq.json")), "/mnt/c/Users/<user>/AppData/Local/igneum/app/proving/seq.json");
+        assert_eq!(wsl_path(Path::new("C:\\Users\\[user]\\AppData\\Local\\igneum\\app\\proving\\seq.json")), "/mnt/c/Users/[user]/AppData/Local/igneum/app/proving/seq.json");
         assert_eq!(wsl_path(Path::new("\\\\?\\D:\\x")), "/mnt/d/x");
         assert_eq!(wsl_path(Path::new("/tmp/x")), "/tmp/x");
     }

app/igneum-app/ui/app.js

@@ -267,7 +267,7 @@ var View = (function () {
   function cap(t) { return t ? t.charAt(0).toUpperCase() + t.slice(1) : ''; }
   var kindWord = Notices.kindWord;
   // hot-plug (src/hotplug.rs): a removed card's row hides after five minutes (gone); a faulty one has no switch
-  // The list is ordered by performance (the founder, 6 October 2026): usable cards first, then by the measured rate since the
+  // The list is ordered by performance (the project lead, 6 October 2026): usable cards first, then by the measured rate since the
   // start (5 MH/s buckets so the order does not flicker), then discrete, external and Apple before integrated, then
   // memory; removed and unusable cards last. Ties keep the detection order.
   function perfRank(c) {

brand/README.md

@@ -1,6 +1,6 @@
 # Igneum brand assets
 
-## The rule (the founder, 4 October 2026)
+## The rule (the project lead, 4 October 2026)
 
 One global logo for apps, profile pictures, favicons, everything. The mark sits in a black square. Never in a circle.
 Never on another colour. Minimum clear space = 20% of the square. The Mac app icon is the model: a full square, all

brand/icons/make-icons.py

@@ -1,7 +1,7 @@
 #!/usr/bin/env python3
 """Builds every Igneum icon from the master mark, brand/master/igneum-mark-square.svg (4 October 2026).
 
-The founder's rule (4 October 2026): one global logo for apps, profile pictures, favicons, everything. The mark sits in a black
+the project lead's rule (4 October 2026): one global logo for apps, profile pictures, favicons, everything. The mark sits in a black
 square (#0C0C0E, the site's obsidian token), centred, no circle, no ring, no border, never on another colour. The Mac app
 is the model. The rounded variant (brand/master/igneum-mark-square-rounded.svg, Apple's 824-on-1024 icon grid) is used
 only where the shape has to be baked into the file: the DMG volume icon. Tahoe masks the plain square itself.

brand/marks/vendor-marks.mjs

@@ -1,65 +0,0 @@
-// Igneum vendor and OS marks (gpu-logos, 7 October 2026): the strings the miner app ships in app/igneum-app/ui/app.js
-// (View.MARKS and View.VENDORS), exported verbatim for the site and anything else that names the hardware.
-// view.test.mjs fails when this file and app.js drift apart, so edit app.js first and regenerate this file with
-// `node brand/marks/regen.mjs` (or copy the strings by hand; the test says which one moved).
-//
-// Each glyph: a hand-drawn simplified monochrome mark of the vendor's public geometry (never a copied logo file,
-// never a raster), 24 x 24 viewBox at 22 px, under 460 bytes, fill or stroke through currentColor so the element's
-// colour tints it. Nominative use that names the hardware; the ember accent is for state and never tints a brand.
-//
-// The treatment in the app (app.css, the block at the end): a 44 x 44 well, radius 12, background the vendor colour
-// at .14 alpha (dark) or .10 (light), a 1 px ring in the vendor colour at .45 alpha, the glyph in the full colour;
-// hover and focus-within add a 3 px halo of the well colour; nothing animates. The light hex of every vendor reads at
-// 3:1 or better on its well over white (nvidia 3.87, amd 5.01, intel 4.29, apple 7.52, gpu 4.65).
-//
-// Class names in the app: .badge.<vendor> (nvidia | amd | intel | apple | gpu), .badge.mini for a 26 px inline mark,
-// .gen for the series line under the name. Tokens: --mark-<vendor>, --mark-<vendor>-well, --mark-<vendor>-ring.
-
-export const VENDORS = {
-  "nvidia": {
-    "label": "NVIDIA",
-    "dark": "#8BE37A",
-    "light": "#2F8A22"
-  },
-  "amd": {
-    "label": "AMD Radeon",
-    "dark": "#FF5A5A",
-    "light": "#C41E2A"
-  },
-  "intel": {
-    "label": "Intel",
-    "dark": "#7CC4FF",
-    "light": "#1C6FD6"
-  },
-  "apple": {
-    "label": "Apple",
-    "dark": "#E6E3DD",
-    "light": "#4A4A50"
-  },
-  "gpu": {
-    "label": "GPU",
-    "dark": "#9A9A9E",
-    "light": "#6B6B70"
-  }
-};
-export const WELL_ALPHA = { dark: 0.14, light: 0.1 };
-export const MARKS = {
-  "nvidia": "<svg viewBox=\"0 0 24 24\" width=\"22\" height=\"22\" aria-hidden=\"true\" focusable=\"false\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M2.6 12C5 7.9 8.3 5.8 12 5.8s7 2.1 9.4 6.2c-2.4 4.1-5.7 6.2-9.4 6.2S5 16.1 2.6 12z\"/><path d=\"M15.6 12A3.6 3.6 0 1 0 12 15.6\"/><circle cx=\"12\" cy=\"12\" r=\"1.2\" fill=\"currentColor\" stroke=\"none\"/></svg>",
-  "amd": "<svg viewBox=\"0 0 24 24\" width=\"22\" height=\"22\" aria-hidden=\"true\" focusable=\"false\" fill=\"currentColor\"><path d=\"M8 3h13v13l-4-4V7h-5z\"/><path d=\"M3 8l4 4v5h5l4 4H3z\"/></svg>",
-  "intel": "<svg viewBox=\"0 0 24 24\" width=\"22\" height=\"22\" aria-hidden=\"true\" focusable=\"false\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\"><path d=\"M7.4 7.6C4.9 8.8 3.4 10.5 3.4 12.3c0 3.4 4.3 5.9 9.8 5.9 4.5 0 7.6-1.6 7.6-3.9 0-1.4-1.3-2.6-3.5-3.3\"/><path d=\"M11.2 9.6v6.2\"/><circle cx=\"11.2\" cy=\"6.6\" r=\"1.1\" fill=\"currentColor\" stroke=\"none\"/></svg>",
-  "apple": "<svg viewBox=\"0 0 24 24\" width=\"22\" height=\"22\" aria-hidden=\"true\" focusable=\"false\" fill=\"currentColor\"><path d=\"M16.4 12.6c0-2.5 2-3.6 2.1-3.7-1.2-1.7-3-1.9-3.6-2-1.5-.2-3 .9-3.8.9-.8 0-2-.9-3.3-.8-1.7 0-3.2 1-4.1 2.5-1.8 3-.5 7.6 1.3 10.1.9 1.2 1.9 2.6 3.2 2.5 1.3 0 1.8-.8 3.3-.8 1.6 0 2 .8 3.3.8 1.4 0 2.3-1.2 3.1-2.5 1-1.4 1.4-2.8 1.4-2.9 0 0-2.7-1-2.9-4.1zM13.9 5.3c.7-.8 1.2-2 1-3.2-1 0-2.2.7-2.9 1.5-.6.7-1.2 1.9-1 3 1.1.1 2.2-.5 2.9-1.3z\"/></svg>",
-  "gpu": "<svg viewBox=\"0 0 24 24\" width=\"22\" height=\"22\" aria-hidden=\"true\" focusable=\"false\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.7\" stroke-linecap=\"round\"><rect x=\"5.5\" y=\"5.5\" width=\"13\" height=\"13\" rx=\"2.2\"/><rect x=\"9.5\" y=\"9.5\" width=\"5\" height=\"5\" rx=\"1\"/><path d=\"M9 2.5v3M12 2.5v3M15 2.5v3M9 18.5v3M12 18.5v3M15 18.5v3M2.5 9h3M2.5 12h3M2.5 15h3M18.5 9h3M18.5 12h3M18.5 15h3\"/></svg>"
-};
-// OS marks in the same treatment: Apple is the vendor glyph; Windows is the four slanted panes
-export const OS_MARKS = {
-  macos: MARKS.apple,
-  windows: "<svg viewBox=\"0 0 24 24\" width=\"22\" height=\"22\" aria-hidden=\"true\" focusable=\"false\" fill=\"currentColor\"><path d=\"M3 5.6l7.3-1v7.1H3zM11.4 4.4L21 3v8.7h-9.6zM3 12.3h7.3v7.1L3 18.4zM11.4 12.3H21V21l-9.6-1.4z\"/></svg>"
-};
-export const OS_COLOURS = { macos: VENDORS.apple, windows: { label: 'Windows', dark: '#7CC4FF', light: '#1C6FD6' } };
-// the CSS tokens for both themes, as the app declares them
-export function tokensCss() {
-  const line = (theme) => Object.entries(VENDORS).map(([v, c]) => { const h = c[theme], r = parseInt(h.slice(1, 3), 16), g = parseInt(h.slice(3, 5), 16), b = parseInt(h.slice(5, 7), 16), a = String(WELL_ALPHA[theme]).replace(/^0/, ''); return `--mark-${v}:${h};--mark-${v}-well:rgba(${r},${g},${b},${a});--mark-${v}-ring:rgba(${r},${g},${b},.45)`; }).join(';');
-  return `:root{${line('dark')}}\n@media (prefers-color-scheme:light){:root:not([data-theme="dark"]){${line('light')}}}\n:root[data-theme="light"]{${line('light')}}`;
-}
-// the well: <div class="badge nvidia"><svg…></svg></div>
-export function markHtml(vendor, size) { const v = MARKS[vendor] ? vendor : 'gpu'; return '<div class="badge ' + (size ? size + ' ' : '') + v + '" data-mark="' + v + '" title="' + VENDORS[v].label + '">' + MARKS[v] + '</div>'; }

brand/trademark/FILING.md

@@ -15,7 +15,7 @@ Mark description for the device, when a form asks: "A stylised flame formed of t
 ## Applicant
 
 Igneum Labs LTD, Licensee Address: Unit IH-00-01-01-OF-01, Level 01, Innovation One, Dubai International Financial
-Centre (decided 5 October 2026; it replaces the ADGM DLT Foundation named on 4 October). NOT the earlier entity: an earlier-entity
+Centre (decided 5 October 2026; it replaces the ADGM DLT Foundation named on 4 October). NOT [other-business]: a [other-business]
 filing would tie Igneum to VIVA and to its owner through public registers, which the standing rule forbids. The
 registered address above is the applicant address, with a trademark attorney as the address for service, so no
 personal address appears anywhere. If the company's registration is not complete the week you want to file, the

docs/analysis/amd-proving.md

@@ -1,6 +1,6 @@
 # Proving on AMD and Apple cards: what exists, what the CPU can do, what to tell the public
 
-5 October 2026, from the founder's two questions that evening: "test proving on the amd card?" and "can we test proving on
+5 October 2026, from the project lead's two questions that evening: "test proving on the amd card?" and "can we test proving on
 mac?". PC 1 holds an RTX 5090 and an RX 9070 XT (gfx1201, 16 GB) in an eGPU; this Mac is an M5 Max. The prover is
 SP1 (`proving/igneum-prove`, `docs/plans/proving-v0.md`, `proving-v1.md`), run on the GPU only through SP1's CUDA
 server. Every figure below is measured (with its bench-log entry or job id) or cited (with its file or page); the
@@ -115,7 +115,7 @@ gates or a backend ships; it is reviewed with every prover release.
 
 | Consequence | Action | Owner |
 |---|---|---|
-| An AMD-only miner loses the proving share | the CPU tier of 4a is measured here (section 2); whether it becomes a tier is a decision for the founder on those numbers | this analysis; the founder |
+| An AMD-only miner loses the proving share | the CPU tier of 4a is measured here (section 2); whether it becomes a tier is a decision for the project lead on those numbers | this analysis; the project lead |
 | The rig's prover unit must select NVIDIA cards only | already true in `prover_decision`; told the rig-installer agent to keep it as a stated rule and to print the CPU-fallback line for AMD-only rigs | rig-installer agent |
 | The app's Proving tile on an AMD-only or Apple machine should say why it is off and name the CPU path | the `provedefault.rs` lines already say so for Apple; AMD-only Windows machines get "no NVIDIA card ..." | proving agent (told) |
 | The site and litepaper over-promise for AMD and Apple | the line of 4c, to land with the next site pass (copy law; `node site/build.mjs`; link-check) | site-pages owner; not changed here |

docs/analysis/asic-resistance-history.md

@@ -1,8 +1,8 @@
 # ASIC resistance, 2011 to 2026: the history, the papers, the lessons, and the audit of Igneum against them
 
-5 October 2026 (night), branch `asic-history`. Asked by the founder at 20:05 UTC: "do a full on deep dive into the full history of 'asic resistance' and see if we can add or upgrade anything." Baseline for the audit: the Counter ASIC 2.0 final class decided tonight (`docs/plans/counter-asic-2-status.md` on `ca2-coord`, entries 20:16 to 22:25 UTC; `docs/analysis/chip-model-v3.md` on `ca2-mixer` 1ab8b21). Every figure about another chain cites a repo file, a paper or a dated article, or is labelled approximate. Hash-per-joule gains are computed from the cited hashrate and watt figures of the chip and of the best consumer GPU of the same year, and are approximate by construction (GPU figures vary by tuning). Research gathered by four sub-agents between 20:10 and 20:45 UTC; the fetch failures they reported are listed in section 6.
+5 October 2026 (night), branch `asic-history`. Asked by the project lead at 20:05 UTC: "do a full on deep dive into the full history of 'asic resistance' and see if we can add or upgrade anything." Baseline for the audit: the Counter ASIC 2.0 final class decided tonight (`docs/plans/counter-asic-2-status.md` on `ca2-coord`, entries 20:16 to 22:25 UTC; `docs/analysis/chip-model-v3.md` on `ca2-mixer` 1ab8b21). Every figure about another chain cites a repo file, a paper or a dated article, or is labelled approximate. Hash-per-joule gains are computed from the cited hashrate and watt figures of the chip and of the best consumer GPU of the same year, and are approximate by construction (GPU figures vary by tuning). Research gathered by four sub-agents between 20:10 and 20:45 UTC; the fetch failures they reported are listed in section 6.
 
-## 0. One page for the founder
+## 0. One page for the project lead
 
 **What the history says Igneum is doing right.**
 
@@ -228,7 +228,7 @@ Ranked by how much the history says each would change the outcome, with the cost
 | 1 | **Price the partial-store chip and draw the time-memory curve.** A chip that stores a fraction f of the dataset in HBM or on many narrow DRAM channels, recomputes the rest from a 256 MiB on-die cache under x8, and reads with 4-byte granularity. Rows for f = 0.25, 0.5, 1 at HBM3 and at GDDR7 random-read rates, priced in energy per hash (Rao's metric) and in reads in flight per watt | The only chip class that beat a memory-bound GPU hash: Ethash's 2.1x to 4.8x came from the memory system with no on-die dataset (rows 3, 4); Rao priced a 16-die DAG holder under a GPU board in 2019; Cuckoo's curve was wrong by 50x until drawn [P20]; O-1.6 is open and `MEMHARD.md` section 3 item 2 says the curve was never drawn | None (analysis) | The row may come out over 2x, which would qualify the public claim before anyone else does | Genesis (before the vectors freeze) |
 | 2 | **A random item-derivation program per day** in place of the fixed-shape mixer: a SuperscalarHash-style generator, integer only, drawn from the day key, with its own acceptance test, compiled once a day by miners and verifiers | RandomX's reason for SuperscalarHash: a fixed derivation is hard-wired by a chip; a random one makes the light-mode chip a CPU (section 2.4). In Igneum's model the fixed shape is the 3x factor that turns 0.31x into 0.92x; removing the factor is worth more than x8 to x16 would be (x16: 0.46x with the factor by M16's table) | None per hash (the daily build is 23 to 77 ms at x8 and would roughly double); the verifier needs a per-day compiled derivation (a JIT, or a round schedule drawn from a fixed set of reviewed rounds), measured against the 10 ms gate | Cryptanalysis of random ARX programs; weak draws; a JIT in the verifier is new attack surface; the vendors must agree bit-exactly on a program they compile | Reserve (named family, unlock by height or signal) now; genesis if the verifier cost is measured under the gate before the freeze |
 | 3 | **External cryptanalysis of M_r, the chained cache and the acceptance rule before genesis**, with the x8 shape as the target | Lesson 9 (MTP, Catena, Argon2i, Cuckoo); RandomX bought four audits for $141,000 before launch [S60]; the x8 decision multiplies the mixer's weight in the chip model, so a shortcut inside the mixer is now worth 8x more to a chip | None | Finding something late moves the vectors; not finding it in time moves nothing | Genesis gate (ledger M7, raised in priority) |
-| 4 | **The clock and the detector.** (a) A share-pattern detector on the observer: per-program hash-rate spread, nonce-group patterns and per-card-model rate bands, with an alert when a population behaves like one fixed design (MoneroCrusher's method); (b) a stated trigger: the bounty escrowed and the benchmark live before daily issuance crosses about $50K (Vorick's rule), not on a calendar date | Lesson 10 (85% secret share); section 2.5's table (chips at $20K to $30K a day on compute-bound hashes); D11 (the bounty is unfunded) | None | A detector with false positives; a trigger the founder has to fund | Not a layer; genesis-independent; do it before the public testnet |
+| 4 | **The clock and the detector.** (a) A share-pattern detector on the observer: per-program hash-rate spread, nonce-group patterns and per-card-model rate bands, with an alert when a population behaves like one fixed design (MoneroCrusher's method); (b) a stated trigger: the bounty escrowed and the benchmark live before daily issuance crosses about $50K (Vorick's rule), not on a calendar date | Lesson 10 (85% secret share); section 2.5's table (chips at $20K to $30K a day on compute-bound hashes); D11 (the bounty is unfunded) | None | A detector with false positives; a trigger the project lead has to fund | Not a layer; genesis-independent; do it before the public testnet |
 | 5 | **Rank layer 9 (the epoch length) up, and measure the FPGA lane**: the compile-ahead cost per card at a 10-minute epoch (the `ca2-epoch` work), plus an estimate of a soft-overlay FPGA miner with HBM (reads in flight per watt against the 5090's 17.5 G/s) | FPGAs were the first adversary of Lyra2REv2 and X16R and came back within weeks of X16Rv2 (rows 7, 9); Xelis forked for FPGA resistance (row 30); a per-hour program is a bitstream target in a way a per-hash program is not | At 10-minute epochs: 6x the compile work per card (measured on `ca2-epoch`); the VDF lead shrinks | A short epoch moves the difficulty window (spec 1.12) and the seed path | Reserve (as decided), with the measurement before the public testnet |
 | 6 | **Order the reserve by chip-unfriendliness**: families that force a full 32-bit datapath per lane first (byte permute, bit-field extract, variable shifts, popcount, select, the second shuffle form), mm8 last | Least Authority's "watch ML hardware"; int8 matrix blocks are licensable IP at every node; Apple pays 1.6x to 4.7x per emulated dot4 (status 20:38) | None at launch | None | Reserve ordering, genesis |
 | 7 | **A vendor-share metric and a 3.0 target for the AMD gap**: the share of hashrate by vendor published with the benchmark, and the line-width question kept open as the plan says | Lesson 8: a one-vendor fleet is a softer version of chip capture; Equihash's NVIDIA tilt and Ethash's balance were part of each chain's miner politics (rows 3, 5) | n/a | A width that closes the gap makes the 5090 bandwidth-bound (status 20:27) | Counter ASIC 3.0 |
@@ -256,14 +256,14 @@ Evaluated and placed nowhere, with the reason:
 | Divergent data-dependent branches | Nowhere (already excluded) | Branches cost a GPU divergence and a chip nothing; RandomX's single predictable branch targets speculative CPUs, which Igneum does not have |
 | Floating point | Nowhere (already excluded) | Vendor rounding splits the chain (spec 1.14); RandomX could afford it because its target is one ISA family with IEEE semantics |
 
-## 5. Decisions this raises for the founder
+## 5. Decisions this raises for the project lead
 
 | # | Decision | Recommendation |
 |---|---|---|
 | 1 | Add the partial-store chip rows to `chip-model-v3.md` and draw the time-memory curve before the public testnet | Yes, before the vectors freeze (addition 1) |
 | 2 | Name a random item-derivation program as a reserve family, and fund the verifier measurement that would move it to genesis | Reserve now; genesis if the verifier lands under the gate (addition 2) |
 | 3 | Commission the external cryptanalysis of M_r and the chained cache before genesis, with the x8 shape as the target | Yes (addition 3; ledger M7) |
-| 4 | Escrow the bounty and set its trigger to daily issuance, not to a date; build the share-pattern detector on the observer | Yes to the detector now; the escrow is the founder's (D11) |
+| 4 | Escrow the bounty and set its trigger to daily issuance, not to a date; build the share-pattern detector on the observer | Yes to the detector now; the escrow is the project lead's (D11) |
 | 5 | Rank the epoch-length reserve above the mm8 reserve, and measure the FPGA lane | Yes (additions 5 and 6) |
 
 ## 6. Sources and limits of this research

docs/analysis/attack-pass-2026-10.md

@@ -1,616 +0,0 @@
-# Internal attack pass before the freeze (F1 to F10)
-
-The internal cryptanalysis pass of `docs/plans/cryptanalysis.md` section 4.2, run before the freeze tag
-`cryptanalysis-target-1`, so the paid engagement confirms rather than discovers. The founder's word, 7 October 2026:
-"make sure they find ZERO flaws". Every finding is ours, fixed and re-gated, before any firm starts.
-
-Target: the hash class the chain runs after 0.3.15's flip, `igneum-pow` generator v4 `V4_CLASS` = `mx8+sh256x27`
-(`LoadClass::MX8`, `ShadowClass { instrs: 256, reps: 27 }`), the acceptance rule, the verifier, the era draw,
-the latency-shadow dataset and ladder, the chip and FPGA cost model. Scope and gates are section 1.1 and 1.4 of
-the plan, the same tests the firm is held to.
-
-Lane: attack-pass, worktree `igneum-wt-attack`, branch `attack-pass` from `origin/master` `ab99e5e3`.
-Binary built on igneum-build-1 (ELF x86-64, `igneum-pow` 0.2.0, sha256 6d2867...1a9ebe5) and run there under
-the box's slots; model and era work from `sim/horizon/algorithm/model.py` and `infra/fast-time/`. Each row below
-carries the method, the known-failed shape where one exists, the result with numbers, and PASS, RUNNING,
-BLOCKED or FINDING. PASS RECORD (7 October 2026, 16:0x UTC, 17:0x UK): every row reads PASS or FIXED-AND-PASSED. F1 PASS (AP-F1-1 on the
-v5 list at 3.0 percent); F2 PASS, effort-bounded; F3 PASS; F4 PASS against class v4 (AP-F4-1 on the v5 list); F5
-FIXED-AND-PASSED (the F2 hour skipped by decision); F6 PASS (the worst of 10^5 programs 8.708 ms on the half-core
-proxy; O-1.14 closed on an i7-9700K); F7 PASS on all three sub-rows (the era VDF in the node, 0 of 6 re-rolls); F8
-FIXED-AND-PASSED in class v4 sub-version 3 at 017e7037 (AP-F8-1, AP-F8-2, AP-F8-3 ours and closed; the four-seed
-unattributed tail named); F9 PASS on (a) and (c), (b) closed by the same fix; F10 PASS. Frozen generator: class v4
-sub-version 3, igneum-pow 017e70376489251e18564c0abce7e466e606c8b3, devnet epoch-0 id a785001687d8688a. The
-freeze tag `cryptanalysis-target-1` is the coordinator's cut on this record; the era VDF precondition is met (F7 a). Main checks every number
-against the log before quoting it to the founder.
-
-## Status board
-
-| # | Attack | Gate (same as 1.4) | Result so far | Status |
-|---|---|---|---|---|
-| F1 | Shadow block compressibility and shortcut search | no compression of the shadow block beyond the honest compiler's simplification, measured against that compiler on the same program; the 27 repetitions never fewer than 27x (coordinator's ruling 7 Oct 2026, 12:3x UK; the plan's gate (1) and row F1 carry the same) | 10^4 and 10^5 class v4 programs: saved instructions mean 0.62%, max 5.078% at 10^5 (1 of 100,000 over 5%, 0 over 10%); nothing folds or dedupes across the 27 passes; every saving is local peephole algebra that clang -O3 removes from the honest kernel too (IR counts match on the worst programs), so against the compiler the compression is 0; 0 mismatches in 2 x 10^5 differential and verifier checks, z3 window proofs 0 counterexamples. AP-F1-1 routed to the v5 list as a shadow redundancy bound. Record `docs/analysis/attack-pass/f1-shadow.md` | PASS; AP-F1-1 on the v5 list |
-| F2 | Mixer round margin (SAT/MILP, 1 to 4 keyed applications) | no distinguisher or shortcut beyond 2 of the 8 applications | one application characterised (differential weight 10 to 12, linear 1, verified on the real code on three days); two applications: no trail at or below weight 20 to 24 within 7,200 s per job, the MSB and LSB families die at two; rotational-XOR no bias at one application; the multiply layer folds on 0 of 2^20 inputs, k applications cost k; three applications: no differential trail at or below weight 29 to 35 and no linear at or below 24 to 28, four: 39 to 47 and 24, every job at its 7,200 s cap. Record `docs/analysis/attack-pass/f2-mixer.md` | PASS (effort-bounded) |
-| F3 | Chained cache j+1 bound and storage-vs-recompute curve | no derivation under j+1 blocks; curve monotone; f=1 point unchanged | 0 of 64 and 0 of 1,024 lines under j+1 (exhaustive closure search, cross-checked by exhaustive pebbling at 10 lines, 10,240 pairs, 0 mismatches); both planted broken chains fire; curve monotone at both op counts; f=1 point 9,360 ops per item unchanged. Record `docs/analysis/attack-pass/f3-cache.md` | PASS |
-| F4 | Weak-day census over 2^24 day keys | fraction of days with gain over 1.1x under 2^-20 | PASS against M2 (DSP-bound datapath): 0 of 2^28 days over 1.1x; planted weak days fire; every ROT and RC class 0. Bound finding AP-F4-1 on M1 (LUT adders): 5,476 of 2^24 days (3.26e-4) over 1.1x as the tail of a sum, no weak class; worst public-calendar day 29,337 at 1.121x, at most 12.1% more rate that day for a per-day LUT FPGA, 0 for any chip; redraw rule (NAF sum under 163 rejected) routed to the next class. Record `docs/analysis/attack-pass/f4-weakday.md` | PASS (v4); AP-F4-1 routed to the next class |
-| F5 | Chip-model sweep + AWS F2 FPGA hour | evidence row 17 holds across the sweep; FPGA row under 27 M reads/s/W | sweep: 2.1x at k=1 GDDR7 reproduces, 3.2x at k=0.5, 4.1x at k=0.3 (matches ledger M32); FPGA row 2.3 to 2.9 G/s, 10 to 20 M reads/s/W (literature). FINDING: the k=0.33 figure is framed as the X9's measured core (M32) and a "measured class" (ladder branch §5a); the X9 was withdrawn before launch and never benchmarked. F2 hour SKIPPED: no AWS account | FIXED-AND-PASSED (sweep PASS; AP-F5-1 fixed and re-gated 7 Oct 2026: chip section re-run 2.1x at k=1 unchanged, identity grep 0 hits, site lane concurred); F2 hour SKIPPED-BY-DECISION (the founder, 7 Oct 2026, 09:5x UK; plan 4.2 row F5 is the sweep only at 3714c2a0; the FPGA row stays the JEDEC-ceiling model row labelled unmeasured) |
-| F6 | Verifier worst case over 10^5 programs + O-1.14 laptop run | worst program under 10 ms cold on the half-core proxy and the laptop | 100,000 programs ranked, 50,000 timed cold one-core (worst 6.194 ms), the worst 200 re-timed and the worst 1,000 timed on the half-core proxy under the per-core lease (core 40 at 3,799.9 MHz): worst 8.708 ms (`attack-f6/87142`), 1.29 ms under the gate, every half-core reading under 9 ms; dr736 fails as it must (15.49). O-1.14 CLOSED on an i7-9700K (v4 6.334 ms cold max, dr736 10.04 fails). Ladder ceiling from the worst program on the half-core proxy: N about 300,000, so rung 2 admissible, rung 3 not. Record `docs/analysis/attack-pass/f6-verifier.md` | PASS |
-| F7 | Era-draw bias harness + 2^20 era-seed census | no re-roll inside the publish window; no era class with gain over 1.1x over 2^-20 | (b) census PASS at 2^24 seeds (no class over 1.1x, stride bijective, R, pos and M uniform, planted cases fire); (c) 64-bit day-key seeding PASS (0 collisions in 2^17); (a) PASS with the era VDF in the node (era-vdf lane, fork era-vdf-node 394a5902 on release-0.3.20-node c4459193, behind era_vdf_activation_daa; master a4eaf766 carries the spec text, `docs/analysis/era-vdf-2026-10-07.md` and `tools/era-vdf/reroll.mjs`): against the real era cut on three fast-time nodes the re-roll harness fires with the VDF off (6 of 6 cuts) and is silent with it on (0 of 6; the adversary's 5.4 to 6.6 s evaluation against a 1 s block interval, the honest chain 3 to 10 blocks ahead, three nodes agreeing on every era seed); the delay is 517 s on the fastest prover measured (chiavdf NUDUPL over GMP, 208.8K squarings/s) at T = 108,000,000, 259x the 2 s window. Open, not a gate: the verify is 22 ms against the 10 ms target (O-4.6, 0.3.22). Record `docs/analysis/attack-pass/f7-era.md` | PASS (a, b, c) |
-| F8 | Uniformity censuses (line-index 2^28, distinct lines, cross-hash histogram) | uniform within the window model of spec 1.13.1, layer 8; the excess beyond it within 6 sigma over 64 seeds; no hot set under 1% of items beyond the model | line index PASS at 2^28. The 6 Oct stream: 31 of 64 seeds over 1.2x (AP-F8-1, the lossy load source). Sub-version 1 (8c728ca3): 11 of 64. Sub-version 2 (07a809a7 / 8bdcbdd8): 9 of 64; AP-F8-2 (exhaustion) closed there, 0 of 10^6. Sub-version 3 (017e7037: the acceptance executing the shadow block, AP-F8-3; the shared-operand rule; (c'') the distinct-index ratio): 60 of 64 under 1.2x, the four over the named unattributed tail at 1.22x to 1.50x with no chip consequence; 0 exhausted in 24,631 chain-shaped seeds, the draw total by construction. Record `docs/analysis/attack-pass/f8-uniform.md` | FIXED-AND-PASSED (sub-version 3, 017e7037, the frozen generator) |
-| F9 | Acceptance edges (39) + header grinding on an RTX 5090 | zero passing programs with a hot set under 1%; grinding gain under 1% of rate | (a) edges on generator 4 over 10^5 seeds: 34 disagreements in 105,064 candidates (29 const_bit, 4 bias, 1 lane_const), every one a one-bit or sampling-noise property moving the choice to an attempt both stand-ins accept, nothing in the attacker's favour: PASS; (b) hot-set search over 10^6 seeds: 11,696 passing programs (1.17%) concentrate 1% or more of reads on a hot set, worst 17.3%: FINDING, the same or-saturation load-source class as AP-F8-1 found by a second harness (F9-1 merged into AP-F8-1), re-gated on the amended stream; (c) grinding on the 5090: +0.004% at K = 2^14, ceiling +43%: PASS. Record `docs/analysis/attack-pass/f9-grind.md` | (a) PASS; (b) the AP-F8-1 class on the 6 Oct stream, closed by sub-version 3 (F8's census is the re-gate instrument; this harness's hot-share metric counts the era's windows); (c) PASS |
-| F10 | Ladder signal monotonicity harness | no step without 90% over 7 windows in either direction | known-fail fails, known pass passes; new cases on the exact-share driver: 89% up holds (no step), 89 then 90% down with restarts steps only at 90% after the 7-window cool-down, the floor holds under 100% down (never below rung 0); decision per seed block memoised, identical after a restart, never differs between nodes; 19 of 19 checks per case. Two items to main, not findings: a stale commit string in the ladder lane's igneumd, and proof-synced nodes deciding rung 0 until the witness lands (a precondition line for spec 01). Record `docs/analysis/attack-pass/f10-ladder.md` | PASS |
-
-## The rows
-
-### F1. Shadow block compressibility and shortcut search (hash lane)
-
-Method: over 10^4 class v4 programs, constant folding, dead-register elimination, common subexpressions across the
-27 repetitions, linear sub-block detection, SAT equivalence on reduced blocks; the minimum op count per program
-against N. Known-failed shape: a shadow that constant-folds or dedupes across its 27 identical passes so a chip
-pays fewer than 55,296 shadow instructions per hash. Entry point: `igneum-pow show --program-class v4` prints the
-256-instruction shadow (op mix add=47 rotl=30 xor=30 shfl=29 mad=27 mul=22 sub=21 rotr=20 mulhi=18 or=12 on the
-genesis seed). Gate: best compressed block within 5% of N on every program; no program over 10% compressible.
-Result: RUNNING. What a failure moves: an acceptance-rule line for the shadow block (rule (c) runs the block),
-packs re-cut.
-
-### F2. Mixer round margin (hash lane, on the box)
-
-Method: SAT or MILP differential and linear search on 1 to 4 keyed applications with drawn rotations; rotational-XOR
-on the ARX layer; the fold of the multiply layer across applications checked algebraically. Known-failed shape: a
-differential or linear trail or an algebraic fold that distinguishes or shortcuts more than 2 of the 8 applications
-between dependent reads. Gate: no distinguisher or shortcut beyond 2 of the 8 applications. Result: RUNNING (prior
-`ca2-mixer` evidence to be re-gated). What a failure moves: `mixer_mult` 16 or a shape change; verifier re-measured.
-
-### F3. Chained cache j+1 bound and storage-vs-recompute curve (hash lane, on the box)
-
-Method: exhaustive search on a 2^10-line model segment for a line derivable without an earlier line; the curve from
-f = 1/64 to 1 in ops per item. Known-failed shape: a line (s, j) computable in fewer than j+1 block evaluations
-without an earlier line (the MTP address-steering break shape). Gate: no derivation under j+1 blocks; curve monotone;
-f=1 point unchanged. Result, 7 October 2026, 09:10 to 09:12 UK on the box (`docs/analysis/attack-pass/f3-cache.md`; logs
-`/srv/builds/igneum-wt-attack/attack-f3/r1-*.log`): PASS on all three clauses. The chain extracted from
-`Cache::fill_segment` (verified equal to the code on 16 of 16 key and segment pairs; `block == chacha_block` on
-100,000 random inputs) has line j fed by line j - 1 only; the exhaustive closure search finds 0 of 64 and 0 of
-1,024 lines under j + 1 (every line costs exactly j + 1), cross-checked by an exhaustive pebbling search at 10
-lines (10,240 configuration and target pairs, 0 mismatches). The two planted chains fire: `skip2` (63 of 64 under
-j + 1) and `nofeed` (every line in 1 block). The curve over stored cache lines is monotone non-increasing from
-f = 1/64 to 1 at 608 (counted) and 700 (MEMHARD.md) ops per block; the f = 1 point is 9,360 ops per item,
-41.7 MH/s at the 50 T op/s budget, unchanged. `ca2-cache` was the hot-table experiment, not a chain analysis, so
-there was nothing to re-gate. Observation (coordinator and the F3 record, not a finding): `funding.md` B2 rank 2
-prices the trade-off at the naive placement; the optimal placement of every 8th line costs 3.17 blocks per read,
-not 3.5, and 16.0 at f = 1/64, not 31.5 (brute force over 4,426,165,368 sets at n = 8); the chip stays worse than
-the full mirror at every f under 1, so the verdict stands, and a `chacha_block` shortcut in chaining mode stays
-the paid question (Lot A and B). What a failure would have moved: the chain construction (a second feed-forward or
-a cross-segment tie).
-
-### F4. Weak-day census over 2^24 day keys (hash lane, on the box)
-
-Method: 2^24 day keys through `MixParams::with_shape`; the ROT classes (all equal, complementary pairs, small
-amounts), MUL low weight, RC structure, each per-day gain measured on the box verifier. Known-failed shape: a day
-key whose drawn ROT/MUL/RC gives a fixed datapath a gain over 1.1x (the "weaker authorized parameters" class,
-Kudelski 2019). Gate: the fraction of days with any gain over 1.1x under 2^-20. Result: RUNNING. What a failure
-moves: a rejection-and-redraw rule on the draws.
-
-### F5. Chip-model sweep and the FPGA hour (algorithm lane)
-
-Method: `sim/horizon/algorithm/model.py` over k 0.2 to 1.5, tFAW 12 and 28 ns, HBM4 2.3 and 21.4 G reads per
-stack, amortisation 1 to 3 years, electricity USD 0.05 to 0.15 per kWh; and the AWS F2 hour replacing the FPGA
-ceiling row with a measurement. Known-failed shape: an input of the published model that, when corrected, lifts the
-f=1 chip's per-joule edge over the 5090 above the published 2.1x at k=1.
-
-Gate: the published sentence (evidence row 17) holds across the sweep; the FPGA row under 27 M reads/s/W.
-
-Result (sweep): PASS on the numbers. The model's measured-anchor column (GDDR7, the 5090 reads 82% of its ceiling)
-gives the f=1 chip's v4 per-joule edge over the RTX 5090 bench row as 4.1x / 3.2x / 2.1x / 1.5x at k = 0.3 / 0.5 /
-1 / 1.5. At k = 1 the figure is 2.1x, and 3.9x at k about 0.33, which matches `fud-ledger.md` M32. The higher HBM3
-and HBM4 columns rest on an 8-activate per 12 ns window that JEDEC HBM2 timings (4 per 28 ns) do not support; the
-model already states GDDR7 is the column to quote. One wording gap: `evidence.md` row 17 says "brings it to about
-2x", which is a floor that holds at k about 0.9 and above but understates the edge at lower k (3.2x at k = 0.5). The
-accurate statement is M32's, 2.1x at k = 1 with the k range beside it. The sweep's numbers stand; the finding is the
-X9 framing below.
-
-FPGA row: the HBM2 FPGA ceiling is 2.3 to 2.9 G reads/s (measured Shuhai U280, FCCM 2020, equal to the JEDEC
-tFAW-bound 2.3 G/s), 10 to 21 M reads/s/W at 115 to 150 W, 0.30 to 0.47x of the 5090 per watt. Under the 27 M
-reads/s/W gate. The AWS F2 hour is SKIPPED-BY-DECISION (the founder, 7 October 2026, 09:5x UK: not needed for now, not blocked;
-plan 4.2 row F5 at commit 3714c2a0 on branch cryptanalysis is the chip-model sweep only, 4 h, the algorithm lane).
-There is also no AWS account or `aws` CLI on this Mac. The FPGA row stays the JEDEC-ceiling model row labelled
-unmeasured; Lot C prices it from the reads-in-flight model; the firm is told the F2 measurement was not run.
-
-FINDING (X9 framing), owning lane algorithm and hash (the ladder lane is closed, so ours): the published numbers
-already carry 2.1x at k = 1 beside 3.9x at k about 0.33 (`fud-ledger.md` M32, recalibrated under X35). The error is
-the framing. M32 calls the k = 0.33 figure "the X9's core" and the `ladder` branch's `latency-ladder.md` section 5a
-calls k about 0.33 a "measured class". Bitmain's Antminer X9 (RandomX ASIC, 1 MH/s, 2,472 W, about USD 5,600) was
-announced and, per pcpraha.cz ("Antminer X9 canceled: Bitmain withdraws model from market before launch") and
-r/MoneroMining, withdrawn before launch. Its implied core efficiency (k about 0.33) is a CLAIMED datasheet figure
-from a design that never shipped and was never benchmarked, not a measured calibration point. It is carried as the
-pessimistic bound, not a calibration. This collides with the merged ledger X34 ("RandomX has a shipping chip;
-correct every sentence that said otherwise"): if the X9 was withdrawn, X34's correction is itself wrong and must be
-reversed. Confirmed from primary sources (coordinator, 7 October 2026): pre-orders opened 26 December 2025 (shipments
-scheduled for July 2026), withdrawn in mid-May 2026 with buyers refunded before any unit shipped, no independent
-benchmark, Bitmain never published a cancellation (its shop lists it as sold out), and the box was commodity Sophgo
-SG2044 server SoCs with an AES accelerator and 60-plus DRAM sticks, no tapeout; its claimed edge about 2x per joule
-over a tuned Zen 4 part, about 3x over a stock desktop CPU. Re-cut applied the same day: `evidence.md` row 17 (claim
-and measured cells) and `fud-ledger.md` M32's answer paragraph on attack-pass, and the ladder design doc section 5a
-on branch `attack-ladder-5a` from the ladder tip 7003f9f5 (the `ladder` branch is checked out by another lane, so
-the fix rides its own branch for the ladder owner to take). The served-text rows (X34 reversal, X36) belong to the
-site lane, which confirmed the wording agrees. What a finding moves
-(plan 4.2 F5): the sentence re-cut before the freeze so the firms attack the corrected model. The re-cut, once the
-fact is confirmed: k about 0.33 labelled a claimed pessimistic bound from a withdrawn design everywhere it appears;
-2.1x at k = 1 on the GDDR7 measured anchor kept as the headline with the k range beside it; k itself unmeasured
-until Lot C produces it. This row reads FIXED-AND-PASSED only after the re-cut and its re-gate.
-
-Economic row the withdrawal implies: a recompute chip at a 3x fixed-function factor against a CPU and GPU fleet
-must recover its NRE (low to mid seven figures at a modern node, `chip-model-v3.md`) and carry a fork threat (a
-class change at 95% miner signal can redraw the datapath the chip bakes in). The X9 at 2.47 J per KH against a
-RandomX CPU fleet did not clear that bar at Monero's hash and price; the same arithmetic against Igneum's class v4,
-with the shadow block and the automatic era draw as extra firmware risk, is why the chip model's verdict is a
-deliverable and not a courtesy (plan 2.3). The confirmed reading: a box with a 2x to 3x per-joule edge and no NRE (commodity SoCs) was withdrawn rather than
-face a 1.5x re-tune of RandomX, so the tapeout economics of a 3x chip against Igneum are worse than the X9's. This
-row is the pessimistic case, not a measured gain.
-
-### F6. Verifier worst case (algorithm lane)
-
-Method: 10^5 class v4 programs timed on the box one-core and half-core proxies for the slowest warp (base program
-and shadow block), plus the O-1.14 laptop run (the Windows `igneum-pow` build on the box, the relay, `bench
---warps 50`). Known-failed shape: a drawn program whose verifier warp exceeds 10 ms cold (the acceptance rule bounds
-the miner's side, not the verifier's; `dr736` already FAILs at 10.51 ms cold one-core, but it is not the shipping
-class). Gate: the worst program under 10 ms cold on the half-core proxy and on the laptop.
-
-O-1.14 route (coordinator, 7 October 2026, 10:1x UK): no US laptop is due, so the laptop run is replaced by a
-rented 2019-class CPU host through the fleet agent, capped at two hours of rent; the Linux `igneum-pow` from the box
-(the same binary as the proxies) runs `bench --warps 50` for v2, mx8, mx8+sh256x27, dr368 and dr736 (the
-known-fail) on it; INCOMPLETE with the numbers so far if the cap lands first. The Windows exe was also built on the
-box for the day a laptop appears (1,009,675 bytes, sha256 fbed7538...e6c9). Outcome, 09:40 UK: no 2019-class CPU
-host stood up. Vast accepted and dropped five CPU-class rents within 30 s each (i7-9700K, i5-8500, Xeon W-2133 and
-W-2123) under the account's automatic new-account spend limit (support ticket open since 6 October), and RunPod has
-no 2019-class CPU pod; so O-1.14 reads INCOMPLETE on the box proxies today and stays a precondition of the freeze.
-Next try: the US laptop when it registers on the relay (the exe is ready), or Vast once the spend limit lifts; the
-bench script is staged and runs in minutes. Correction, 10:4x UK (fleet agent): the provider dropped nothing; every
-rent stood up and ran, hidden by Vast's instance listing cap of 25 rows on an account holding 38, so the hosts sat
-idle and were destroyed. The fallback is re-rented under the same word (i7-9700K class, two-hour cap from its start,
-read by id); the result replaces this line when it lands.
-
-O-1.14 RESULT, 7 October 2026, 09:49 UK, Vast instance 54613164, Intel Core i7-9700K (2019 desktop core, Coffee Lake,
-read at 4,170 MHz during the run, 31 GB DDR4, Ubuntu 24.04), the box-built Linux `igneum-pow` (sha256 6d286783...),
-`bench --seed igneum-genesis --day 2026-10-03 --warps 50` on one core (`taskset -c 1`), the host otherwise idle; log
-`docs/analysis/attack-pass/o114-i7-9700K-2026-10-07.log`:
-
-| Class | Cold max (ms per warp) | Average of 50 (ms) | Gate 10 ms | Box one-core cold | Box half-core |
-|---|---|---|---|---|---|
-| v2 | 1.582 | 1.280 | pass | 1.30 | n/a |
-| mx8 (class v3) | 5.394 | 5.267 | pass | 4.67 | 7.56 |
-| mx8+sh256x27 (class v4, the target) | 6.334 | 6.006 | pass, 3.7 ms of headroom | 5.06 | 8.23 |
-| dr368 | 5.540 | 5.426 | pass | 5.32 | 8.16 |
-| dr736 (the known-fail) | 10.290 | 10.042 | FAIL, as it must | 10.51 | 15.49 |
-
-Cache fill 276 ms on the 9700K core (box 361 ms, M5 Max 175 to 181 ms). The 2019 desktop core sits between the box's
-two proxies as the arithmetic predicted (1.2x the box one-core cold on v4, 0.77x the half-core); the known-fail
-fires on it. A 2019 laptop core at 3.5 GHz reads about 15 to 20 percent slower than this desktop part (approximate,
-clock ratio), so about 7.0 to 7.6 ms on v4, still under 10 ms. Consequences: a 2019-class node verifying class v4
-spends 0.6 percent of one core at 1 bps and 6 percent at 10 bps; a header flood needs about 160 invalid headers a
-second to saturate one such core; a pool verifies about 160 shares a second per core; IBD of 108,000 headers is
-about 11 minutes of one core. The implied ladder ceiling on this core: the shadow costs 0.74 ms per 55,296
-instructions (v4 minus mx8), so the 4.0 ms of headroom buys about 300,000 more shadow instructions, N about 650,000
-counted ops at the 1.83 convention (approximate), against 370,000 on the half-core proxy and 1,060,000 on the
-2.5x rule; the half-core proxy stays the standing pessimistic rule and the ladder's ceiling should be taken from
-it, not from this desktop part. O-1.14 is CLOSED on a real 2019-class core for the genesis program; the F6 row
-still owes the 10^5-program worst case before it reads PASS.
-
-Result (average, verified on the box): class v4 `mx8+sh256x27` runs 4.90 to 5.06 ms per warp cold on one EPYC
-9454P core (nice 19, taskset), 8.23 ms on the half-core proxy (both SMT siblings busy). Under 10 ms. Status
-RUNNING: the 10^5-program worst-case search and the O-1.14 laptop relay run are owed before the row reads PASS.
-What a failure moves: an acceptance-rule bound on verifier cost; the ladder's ceiling set from the measured core.
-
-### F7. Era-draw bias harness and census (node lane harness, hash lane census)
-
-Method: the fast-time 3-node network (`infra/fast-time/`) with an adversary withholding or publishing the last blue
-block before C_era(n) to re-roll the draw; a census of 2^20 era seeds for stride, ROT and weight-perturbation
-classes with gain over 1.1x; the 64-bit seeding of the day-key stream against the spec's intent. Known-failed shape:
-a re-roll of the era draw inside the 2 s publish window, or an era class (stride bijection, all-equal ROT, low-weight
-M) with a chip gain. Gate: no re-roll inside the publish window; no era class with gain over 1.1x at a fraction over
-2^-20; the draw's input set as the spec states it.
-
-Result (full record `docs/analysis/attack-pass/f7-era.md`; harness `tools/attack/f7-era/`). Census: 2^20 and 2^24 era
-seeds through `generator::era_draw` over `V3_ALLOWED` (the chain's path), classified; the planted known-fail/known-pass
-of the classifier fired and the sound draw raised nothing. No era class with gain over 1.1x at any fraction (the richest
-is M = 1 at 1.0034x, absent in 2^24; every class over 2^-20 is 1.0000x to 1.0007x); the stride is a bijection on every
-sample (0 even M), R and pos and the M bits uniform; the op-weight corners (15 to 31 of 75) are 1.0x against the GPU, 0
-memory effect. The 64-bit day-key seeding is the spec's intent (spec 1.8.4); 2^16 days are all distinct, birthday 2^-33.
-Harness: the 3-node fast-time network (`reroll.mjs`, ports 29800+, suffix 980) with an adversary holding the last block
-before the cut; known-pass (`--vdf-ms 0`) fires at 1 of 6 cuts (seed = adversary block), known-fail (`--vdf-ms 5000`)
-is silent at 0 of 6, both SOUND. The node has no era VDF yet (`seed_below` is a plain block hash, era-layout.md section
-8), so the harness cannot show the real 2 s-window gate; the era draw's grinding resistance rests on the 1-hour VDF of
-spec 4.4 (re-roll needs a 1,800x evaluator, spec 4.6 gives 300x; forge needs 20 days of 100% hash). Verdict: census PASS,
-64-bit seeding PASS, harness INCOMPLETE with the written argument. Logs on igneum-build-1
-`/srv/builds/igneum-wt-attack/attack-f7/census-2p24.log`, `census-2p20.log`, `reroll-knownpass.log`, `reroll-knownfail.log`.
-What a failure moves: the draw procedure or the C_era cut rule; a redraw rule for the era stream.
-
-Sub-row (a) CLOSED, 7 October 2026, 15:1x UK (the era-VDF lane, launched by the coordinator on this row's INCOMPLETE):
-the era VDF is in the node (fork `era-vdf-node` 394a5902 on `release-0.3.20-node` c4459193, behind
-`era_vdf_activation_daa`, never on any network until the founder sets it per network; repo master a4eaf766 carries the spec
-text, the record `docs/analysis/era-vdf-2026-10-07.md` and the harness `tools/era-vdf/reroll.mjs`, which attacks the
-era cut directly now that the node takes `pow_era_blocks` and `pow_era_lead` from the override file). Against the
-REAL era cut (era 120 DAA, lead 20 on the fast-time file, three nodes on igneum-build-2) the harness fires with the
-VDF off (6 of 6 cuts: the adversary's block is the cut block and its hash the seed, known the instant it is built) and
-is silent with it on (0 of 6 across six cuts: the adversary's 5.4 to 6.6 s evaluation with the node's own code against
-a 1 s block interval, the honest chain 3 to 10 blocks ahead when it published, three nodes agreeing on every era seed,
-the record ready at every era start). SOUND both ways. The production delay: 517 s on the fastest prover measured
-(chiavdf NUDUPL over GMP, 208.8K squarings/s on the same core) at T = 108,000,000 squarings, 259x the 2 s window.
-Freeze sentence (the era-VDF lane's, carried to the plan's owner): "The era seed E_n is the output of a one-hour
-verifiable delay (class-group Wesolowski, 1,024-bit prime discriminant, T 108,000,000, scheme byte 0 with the
-hash-chain fallback as byte 1) over the blue blocks of the day ending at the era's cut block; the attack pass's F7
-re-roll harness fires against the stand-in and is silent against the delay, so the era draw procedure and the C_era
-cut rule are frozen with the VDF in the node, behind era_vdf_activation_daa, never until set per network." Open, not
-a gate of F7: the verify is 22 ms with the group held, against the 10 ms target (once per 180 days per importing
-node; O-4.6's reducer or GMP behind a feature, 0.3.22). Logs `/srv/builds/igneum-wt-era-vdf/ev-harness-out/
-reroll-vdf-{on,off}-5.json` on build-2. F7: PASS on all three sub-rows.
-
-### F8. Uniformity censuses (hash lane, on the box)
-
-Method: the line-index distribution over 2^28 derivations; distinct lines per hash and per warp on 10^6 nonces of
-three programs; the cross-hash item histogram of one epoch. Gate: the largest bucket within 6 sigma of uniform; no
-hot set under 1% of items. Result: RUNNING. What a failure moves: the mask or the fold; packs re-cut.
-
-### F9. Acceptance edges and header grinding (hash lane; one PC 2 job)
-
-Method: the 39 edge disagreements reproduced and bounded; a search over 10^6 seeds for programs that pass rule (c)
-with a hot set under 1%; the header-grinding search cost against its DRAM-locality gain measured on PC 2's RTX 5090
-(one job through `tools/build-job.mjs`). Known-failed shape: a seed grind that steers a program to a hot cache set
-for DRAM locality, or an edge where the closed-form stand-in disagrees with the live verifier in the attacker's
-favour. Gate: zero passing programs with a hot set under 1%; the grinding gain under 1% of rate at any search cost.
-
-Result: the `accept` path reproduces per-seed verdicts (genesis seed: 1 candidate ACCEPTED, bias max 54, 0
-saturated). The header-grinding cost-versus-gain measurement needs a 5090. Status BLOCKED on the go decision: use
-PC 2's 5090 through a relay run job only if PC 2 is online and mining is unaffected, else a rented pod under the
-standing fleet budget. What a failure moves: the closed-form stand-in replaced by the live verdict at the edges; a
-locality term in rule (c).
-
-### F10. Ladder signal monotonicity (node lane)
-
-Method: the fast-time harness with a weight that steps the ladder down and never up, and an 89% signal; the step
-rule's monotonicity and its memoisation per seed block. Known-failed shape: a chip owner stepping the ladder down
-(cheaper N) without the 90% threshold, or a step registered under 90%. Gate: no step without 90% over 7 windows in
-either direction; a step down needs the same. Result: RUNNING. What a failure moves: the step rule's text in spec 01
-before the ladder is frozen.
-
-## Lane (d): the families re-run on class v5 (7 October 2026, evening; the coordinator's word on the founder's order)
-
-Object: igneum-pow on branch `class-v5` at e4f1f275 (the frozen sub-version 3 017e7037 merged; the v5 chain draw is
-the amended v4's instruction for instruction, generator 5, every item keyed by the window's state through the leaf
-XOR before the first mixer; `V5_CLASS` = `mx8+sh256x27+state`), against the first v5 pack
-`proto-cuda/packs-ca3-v5/v5-dn3-epoch0` (Devnet 3's genesis 4020cb43... as epoch and era seed, day 20,733, program id
-e5a4ac5978462156, reproduced by the e4f1f275 build on box 2: the pairing). The four harnesses carried onto the
-class-v5 tree in worktree `igneum-wt-attack-v5` (branch `attack-v5`), each with `--class v5` and, where the dataset
-enters, `--state <IGSD1>` attaching the leaves through `with_leaves` as the CLI does; F8's traced derivation carries
-the leaf XOR and validates bit for bit against `derive_items_leaves` and `Epoch::hash_warp` (p1 on the dn3 state at
-4,096 nonces: 0 mismatches over 16,777,216 items and 64 warps; the flipped-state file mismatches: the known-fail).
-Both boxes at nice 10 beside the release builds; the binaries run from copies in each run's scratch directory (AP-H2).
-GitHub answered 403 (account suspended) from 17:2x UK, so this section lands on the box mirror (`build`, master and
-attack-pass) by the coordinator's exception rule; nothing touches GitHub.
-
-| Family | Class v5 run | Result | Verdict |
-|---|---|---|---|
-| F4 weak-day census | 2^24 chain days from 20,729 under `Shape::for_class(&V5_CLASS)`, box 1, 18:5x to 19:1x UTC | byte-identical to the class v4 census: M2 (DSP-bound) 0 of 2^24 days over 1.1x; M1 (LUT adders) 5,476 days, 3.264e-4, the same bounded tail, worst day 4,819,563 at cost 197 against the median 231; planted weak days fire (mul1all M2 unbounded, mulnaf 1.333x). The day-key draw depends on the mixer shape alone and v5 adds only the state flag, so identity is the expected and the measured result | PASS (v4's reading; AP-F4-1 stays the next-class item) |
-| F8 hot-set gate | 64 seeds at 2^24, chain path, v5 with the dn3 state, box 2 (64 threads), from 18:47 UTC | pending | pending |
-| F9 exhaustion count | 10^5 chain-shaped seeds on the v5 chain path with the dn3 state, box 1, ten parallel chunks (the chain draw costs about 2.2 s per candidate through (c''), so 10^6 is about fifty hours) | pending | pending |
-| F1 shadow redundancy | 10^5 class v5 programs through the string-seed path, box 1 | pending | pending |
-
-## Operating hazards found by the pass
-
-AP-H1 (box scratch cleaned by builds; found by F3, 7 October 2026, 10:0x UK). `infra/build-server/remote-run.sh`
-line 71 runs `git clean -qfd -e target -e 'target-*' ...` on `/srv/builds/<worktree>` before every remote build, so
-an untracked box scratch directory of one row (a venv, a log dir, a crate's `tools/attack/*/target`) is deleted by
-the next build from any row. F3 protected its own directory through the box mirror's `.git/info/exclude`; the lane
-then added `attack-*/`, `target-attack-*/`, `tools/attack/` and `.build-remote.log` to that file at 10:1x UK, after
-which `git clean -fdn` on the mirror lists nothing (the clean has no `-x`, so the exclude file applies). The class
-check is owed to the build-server lane: the clean line should spare a lane's declared scratch prefix (`-e 'attack-*'`
-style, or read a per-worktree exclude list), and a CI check should fail a remote-run.sh whose clean line lacks it.
-OPEN until that check lands (CLAUDE.md: a rule row closes only with its check).
-
-AP-H2 (this lane's own, 7 October 2026, 13:3x and 14:5x UK, twice). Two census runs launched from the same crate's
-`target/release` binary path on the box mirror: a rebuild of the crate at a new commit replaces the binary under a
-run still in progress, and every chunk the run launches after that executes the new commit's code with the old run's
-label (the 07a809a7 control's later chunks ran 8bdcbdd8; the ddacfbd3 class check's later chunks ran 017e7037). Both
-runs were caught by their attempt histograms (attempts 32 and 35 under a cap of 32) and their contaminated chunks
-discarded. Fix in the lane's launcher: `run-census-chain.sh` copies the binary into the run's own scratch directory
-before the first chunk and runs from the copy, so a rebuild cannot reach a run in progress; a run's record names the
-sha256 of the copy. Class check owed: the same rule for every lane's long run (the box's build runner could refuse to
-replace a binary that a running process has open, or stamp the commit into the run's log at every chunk).
-
-## Ledger rows
-
-AP-F1-1 (hash lane; ruling asked). At 10^5 class v4 programs one program (`attack-f1/37341`) compresses by 5.078
-percent (13 of 256 shadow instructions per pass), 0.078 points over the gate's first clause, on 1 of 100,000; every
-other program is within 5 percent and none over 10. The saving is the same local shape as on every program (a
-register written twice from one source with no write between), nothing crosses a pass, and clang -O3 removes the
-same instructions from the honest kernel (IR counts match the harness on the worst programs), so a chip gains nothing
-relative to a card: no shortcut. The gate as written counts honest-compiler simplification as compressibility. Two
-ways to close: re-word gate (1) and row F1 to "compressible beyond the honest compiler's own simplification" (the
-firms then attack chip-relative compression, which is the question), or a shadow-draw redundancy bound in the next
-class (reject a shadow with over 12 peephole-removable instructions per pass, rejection about 1e-5; class v4 is on
-the live vote). Ruling (coordinator, 7 October 2026, 12:3x UK): both. Gate (1) and row F1 re-worded to "no
-compression of the shadow block beyond the honest compiler's simplification, measured against that compiler on the
-same program" (sent to the cryptanalysis lane for the plan and the firms' brief), under which the 5.078 percent
-letter miss at honest-compiler parity is a PASS; and a shadow redundancy bound on the v5 generator's list beside
-AP-F4-1 and AP-F8-1 (the generator refuses a shadow block whose honest-compiler simplification exceeds a stated
-fraction; the v5 lane sets the fraction from F1's census), gated by F1's harness on 64 seeds of the v5 stream.
-The fraction is 3.0 percent (v5 lane, class-v5 45e29cb0; 384 of 100,000 draws redrawn in its census, 3.8e-3, against
-F1's histogram where the 3.0 to 5.5 percent bins hold 397 of 100,000); the plan's 1.1 sentence carries the number.
-Status: F1 PASS; AP-F1-1 FIXED-AND-PASSED against v5 once the bound is in the v5 generator and F1's census passes.
-
-
-AP-F5-1 (algorithm and hash lane, ours; the ladder lane is closed). The k about 0.33 chip-efficiency figure is
-framed as a measured calibration ("the X9's core", `fud-ledger.md` M32 L172; "measured class", `ladder` branch
-`docs/design/latency-ladder.md` section 5a). The Antminer X9 was withdrawn before launch and never benchmarked, so
-k about 0.33 is a claimed datasheet bound, not a measurement. This also puts the merged ledger X34 ("RandomX has a
-shipping chip") in question. Fix owed, held until the coordinator's research agent confirms the withdrawal and the
-no-benchmark fact: relabel k about 0.33 as a claimed pessimistic bound from a withdrawn design in `evidence.md` row
-17, `fud-ledger.md` M32 and the `ladder` branch; reverse X34 if the withdrawal is confirmed; keep 2.1x at k = 1 on
-the GDDR7 measured anchor as the headline with the k range beside it. Re-gate after the re-cut. Status: FIXED on the docs rows (evidence 17, M32, ladder 5a on branch attack-ladder-5a d3cb17b6; attack-pass
-rebased on master a3678789 after X36); FIXED-AND-PASSED once the site lane's X34/X36 served rows are confirmed in
-one voice (no objection received) and the sweep is re-run against the re-cut sentence (the numbers are unchanged, so
-the re-gate is the identity check and one `model.py --section chip` run against the new wording). Re-gate done 7 October 2026, 09:5x UK: the 5090
-bench row still reads 5.7x / 4.1x / 3.2x / 2.1x / 1.5x (v3; v4 at k = 0.3 / 0.5 / 1 / 1.5), identity grep 0 hits
-over 290 export files, the site lane confirmed the served text agrees. AP-F5-1: FIXED-AND-PASSED.
-
-AP-F8-1 (hash lane; the generator fix is the Counter ASIC lane's on the v4 seam, routed 7 October 2026, 10:3x UK).
-The class v4 item read map is not uniform. F8 phase D, one program, 2^26 nonces: the top 0.1 percent of items take
-0.520 percent of reads against 0.115 percent for the uniform control (4.05x); the top 1 percent take 2.49 percent
-(1.37x); one item (0xca5b92) takes 78,479 reads, 153x the mean; read site 15 feeds 6.37 percent of its reads into
-that 0.1 percent in all 8 iterations; the excess grows with N as a real skew does. Sized: a chip caching the hot
-0.1 percent in SRAM serves about 0.5 percent of reads from cache, so the shortcut is under one percent of rate today;
-an auditor flags a non-uniform read map in a design that claims uniform random reads, and site 15's index derivation
-is the cause to name. Fix asked: per-site index whitening or a rejected class above a bound. Re-gate: the top
-0.1 percent within 1.2x of the control over 2^26 nonces on every one of 64 seeds, with F8's harness against the
-Counter ASIC lane's branch. Phase E (the 64-program census) decides whether it is one program or the class.
-Framing from the Counter ASIC lane (the generator's owner, 7 October 2026, 10:5x UK): class v4's item map is not
-designed to be uniform per program. Layer 8 (spec 01 section 1.13.1) gives each load site k_off = below(3), so a
-site reads the whole dataset, a half or a quarter under the era's stride and interleave; a quarter-window site
-concentrates 4x on its quarter by design, which is the 4.05x at the top 0.1 percent, and the windows exist so a
-chip's SRAM mirror must hold the whole dataset every hour (the Counter ASIC 2.0 windows-union census). The right
-control is therefore the window model from the program's own 16 draws, reported beside the uniform control (what an
-auditor sees first); the number that must be explained is the single item 0xca5b92 at 153x the mean (window
-coincidence under the era mapping with a stated tail, or a low-entropy index source at site 15, which would be a
-fault). The lane reproduces with F8's harness on branch `ca3-v4-uniform`, waits for phase E, re-prices the chip
-consequence (a 0.1 percent hot-set cache, about 1.7 MB of SRAM, serving 0.5 percent of reads: under one percent of
-rate) and changes the generator only on a fault beyond the model, since v4 is on the live devnet's vote. F8 was
-re-briefed to carry both controls and the per-site table. Raised to the coordinator: plan 1.4 gate (4) and row F8
-say "within 6 sigma of uniform"; if the design is windowed, the gate text must say "uniform within the window model
-of spec 1.13.1" before the freeze tag, or every reviewer files the windows as a finding on day one.
-Coordinator's ruling (7 October 2026, 11:0x UK), accepted: the right null is the window model derived from the
-program's own draws; F8 is re-gated against it, and the finding stays open only for the excess beyond the window
-model (the 153x item, or a low-entropy source at site 15 if the 64-seed census shows one). No generator change to
-class v4 is allowed: it is on the live devnet's vote, and a class change before the flip splits the chain. If the
-census shows a real fault it goes to the coordinator priced; otherwise the record carries the documented null and
-the hot-set bound (a 0.1 percent cache, about 1.7 MB of SRAM, under one percent of rate) goes into the next class.
-Gate wording settled (coordinator, 11:2x UK): plan 1.4 gate (4) and row F8 now read "uniform within the window
-model of spec 1.13.1, layer 8; the excess beyond it within 6 sigma over 64 seeds", carried into the plan's scope
-text by the cryptanalysis lane so the firms are briefed on the windows before they start.
-Mechanism (hash lane, branch `ca3-v4-uniform` 095f84a7, `docs/analysis/ca3-v4-uniform.md`, harness
-`tools/ca3-v4-uniform`, 7 October 2026, 12:3x UK): the windows-union null (a Poisson mixture at 416 / 288 / 736 / 608
-reads per item by quarter from the program's 16 draws) moves the top 0.1 percent from 0.115 to 0.160 percent, 1.39x,
-not 4.05x; every per-site row of F8's attribution except site 15 is the window model. The rest is the LOAD SOURCE:
-site 15 is the load at 63 reading r6, whose last writer is `or` at 61 (r6 = r6 | r4), so the source is all-ones with
-probability about (3/4)^32 per read; under the era map x = 0xffffffff is item 0xca5b92, the hottest item exactly, and
-the next seven hottest are the seven one-zero-bit sources whose zero survives the window mask (7 of 7); the measured
-count fixes the bias at p = 0.7585 per bit. The class: a load whose source's last writer is lossy (or: 0.30 percent
-of a site's reads on 0.1 percent of values; mul, trailing zeros: 1.07; mulhi: 0.79; an or of an or: about 4.5).
-Static census of 1,024 chain-shaped v4 programs: 96.6 percent carry a lossy-sourced load (48.5 percent or, 4.9
-percent an or chain, 73 percent mul, 64 percent mulhi); predicted S_0.1 median 0.45, 90th 0.88, 99th 5.3, max 9.8
-percent; p1 / p2 / p3 predicted 0.58 / 0.32 / 4.72 against measured 0.52 / 0.27 / 4.60. The fault sits in the
-acceptance rule's blind spot: part (a) takes any write as fresh, part (c) counts saturation on final values only.
-Consequence: the 1.2x-against-window gate fails 96.6 percent of today's programs, so it is withdrawn as a v4 gate and
-becomes the v5 generator item's gate (draw a load's source from registers whose last writer injects; a dynamic check
-counting saturated load sources), with F8's phase E as its test. Chip side: the top 0.1 percent of items is 1.07 MB
-of SRAM (0.53 mm^2, about USD 0.25) serving 0.52 percent of p1's reads and 4.6 percent of p3's, at most 1.005x and
-1.048x in rate; the ceiling under rule (c)'s 120-of-128 floor is one site repeating its item in all 8 iterations,
-6.25 percent of reads, 1.067x. That 1.067x is the v4 hot-set bound the record carries. No generator change to v4;
-the hash lane takes the two flip options priced to main.
-Ruling (the founder, 7 October 2026, 15:2x UK): option A, the class v4 amendment ships in 0.3.20, the feature node (0.3.19 is the app-only cut on the unchanged 0.3.17 node pin; corrected by the coordinator) (a load's source drawn
-only from registers whose last writer injects or is a rotate, the v5 rule applied now; a new program stream and
-seven re-exported packs on branch `ca3-v4-amend`, the hash lane), with limited testing. This lane's part is the proof
-of the fix: F8's hot-set census at 2^24 nonces on each of 64 seeds of the amended stream, on the box's CPU path as
-phase D ran, gate: the top 0.1 percent of items within 1.2x of the window model derived from each program's own 16
-window draws, one number per seed; reported to the hash lane, main and the Counter ASIC lane. The amended stream has
-no lossy-sourced load by construction, so a seed over 1.2x there is a finding against the model's own tail, not the
-fault, and the record says which.
-Second harness (F9 sub-row b, 10^6 seeds, 12:5x UK): the same class from the other side, the per-site address trace:
-11,696 of 1,000,000 passing programs concentrate 1 percent or more of their reads on a hot set (worst 17.3 percent,
-seed 842871, an `or`-written load source all-ones in 36 percent of evaluations), so F9-1 merges into AP-F8-1 and
-F9's harness is the second re-gate of the amendment, run on the amended stream beside F8's 64-seed census.
-Re-gate interim (7 October 2026, 13:2x to 13:5x UK, box 2): F8's 64-seed census at 2^24 nonces against the amended
-stream (igneum-pow 8c728ca3, sub-version 1; pairing verified, the harness draws the devnet epoch-0 program as
-1a4230699a6b9c60) at 30 of 64 seeds shows nine over 1.2x of the window model (p31 29.27x, p11 5.45x, p19 3.32x, p6
-3.11x, p23 2.04x, p4 1.57x, p10 1.50x, p26 1.30x, p25 1.28x), p6's hottest item predicted from "site 13, r0,
-all-ones, last writer a load at 12": a load-after-load chain (a hot address yields a fixed dataset word, which is the
-next load's address), which the source rule admits because a load injects. Rule-level reading, checkable in code:
-generator.rs line 1326 sets `entropy_kept[dst]` true for a rotate whatever it rotated, so an or-saturated register
-rotated once is an admitted source and the rotate preserves the saturation. RETRACTION: F9's hot-set census run on
-box 2 against the 8c728ca3 build (10^6 seeds, 1,871 flagged, worst 9.66 percent) was not a re-gate: the F9 harness
-draws through `candidate_class` with its own era class, not through `chain_program` where the rule lives, and the
-amended and the old binary print the identical program for seed igneum-f9/518927; those numbers describe the old
-stream under a changed evaluation and are withdrawn; the harness is being given a `chain_program` draw mode so it can
-serve as the second re-gate. The hash lane confirmed the reading (14:0x UK): the amendment's rule is keyed on the
-era-composed class, so a draw with no era (F9's path) is the old stream, and on the chain path the residual is real:
-p6's load at 12 had a saturated source itself, read one constant word and left a constant in r0, which the rule
-counts as injecting; a rotate keeps 0xffffffff, so or-then-rotate-then-load passes too. Both are saturation delivered
-through a writer that preserves it. Fix shape put to the owner of sub-version 2 (the Counter ASIC lane): dataflow
-freshness instead of a one-writer look-back (fresh at the start; a load keeps dst fresh only if its source was fresh;
-add, sub, xor, mad, shfl fresh if either operand was; rotl, rotr only if the operand was; or, mul, mulhi never; a
-load's source drawn only from fresh registers), with the dynamic (c') check on load sources as the backstop; a stream
-change, so sub-version 2 with new packs, ids and fingerprints.
-RE-GATE VERDICT on sub-version 1 (7 October 2026, census ended 12:55:55 UTC, 13:55 UK; box 2; igneum-pow 8c728ca3
-paired with release-0.3.20-node 8097d600, pairing id 1a4230699a6b9c60 verified; 64 seeds p2 to p65 at 2^24 nonces,
-chain path, window-model control; log `/srv/builds/igneum-wt-attack-regate/attack-f8-regate/log/`): FAIL the pass
-line. 53 of 64 seeds under 1.2x of the window model (0.9915x to 1.16x, no predicted source); 11 over:
-
-| Seed | Over the window model | Over flat | Hottest item, reads of 2^31 | Predicted source |
-|---|---|---|---|---|
-| p31 | 29.27x | 31.99x | 0x74e2b8, 5,365,527 | site 4, r4, all-ones, last writer rotl at 3 |
-| p11 | 5.45x | 6.00x | 0x0eec66, 31,486 | site 1, r7, all-ones, last writer or at 63 (the previous iteration) |
-| p45 | 4.55x | 6.37x | 0x400000, 5,644 | site 1, r4, zero, last writer mulhi at 59 |
-| p19 | 3.32x | 3.93x | 0x400000, 28,114 | site 37, r5, zero, last writer load at 32 |
-| p6 | 3.11x | | 0x3bf40d, 13,792 | site 13, r0, all-ones, last writer load at 12 |
-| p23 | 2.04x | 2.85x | 0x09dd36, 13,848 | site 16, r7, all-ones, last writer load at 14 |
-| p4 | 1.57x | 2.11x | 353 reads | none (window tail) |
-| p34 | 1.51x | 1.87x | 0x400000, 1,547 | site 23, r6, zero, last writer rotr at 12 |
-| p10 | 1.50x | 1.65x | 353 reads | none (window tail) |
-| p26 | 1.30x | 1.54x | 0x000000, 7,637 | site 10, r1, zero, last writer rotl at 2 |
-| p25 | 1.28x | 1.65x | 363 reads | none (window tail) |
-
-Three residual classes, each a constant (all-ones or zero) delivered to a load through a writer the rule admits:
-(1) saturation or zero preserved through rotl, rotr, load or mad; (2) zero made by mulhi; (3) the iteration
-boundary, where the rule's writer state starts fresh at instruction 0 so an or at 63 feeds a load at 1. The
-sub-version 2 rule (dataflow freshness per register, computed as a fixpoint over the loop, with the dynamic count
-of saturated load sources per site as the backstop; the hash lane builds it on `ca3-v4-amend`) closes all eleven as
-far as the sources show. Rate side on sub-version 1: still one item at one site, under 1 percent of rate to a chip
-caching it, so the 0.3.20 ship is safe on rate; the auditor's flag is what sub-version 2 removes. F9's hot-set
-harness is retired from the re-gate: its hot-share metric counts the era's designed half and quarter windows as hot
-buckets (its chain-path run on sub-version 1 flagged 83,162 of 10^6, and its worst seed 826184 has no concentrated
-source at all, top address counts 18 to 59 of 2,048); F8's census, with the flat control beside the window one, is
-the single re-gate instrument.
-Sub-version 2 (07a809a7, the stream identical at 8bdcbdd8 for every seed accepting within 32), the same 64 seeds at
-2^24, 13:10 to 14:2x UTC: at 39 of 64 seeds, 8 over 1.2x of the window model, worst p23 4.82x. Three are the window
-model's tail (p4 1.22x, p8 1.38x, p10 1.50x, no predicted source); five are constants the freshness rule cannot see
-because it tracks lineage, not value: p23 (0x000000, 41,727 reads, zero from xor of a register with itself at
-instruction 0), p34 1.25x (sub of a register with itself), p15 2.57x (zero through rotl at 0), p18 2.50x and p19
-3.32x (a load whose address is constant delivers one word to the next load; p19 is byte for byte the sub-version 1
-program). (c') cannot catch them: 164 of 16,384 per site is about fifty times coarser than the gate (p23's item is
-0.002 percent of all reads and still 4.8x at the top 0.1 percent). Fix shape sent to the hash lane: forbid
-self-operands for xor, sub and mad in the draw; a dynamic per-site bound on the most repeated source value (any
-value) set from the gate; a load's dst fresh only if its source passes it. Rate side unchanged (one item at one
-site, nothing to a chip); the auditor's uniformity test is what fails.
-Localised (14:1x to 14:3x UTC): p23's band is ONE site, site 7 = instruction 38 `load src=r6`, in every iteration
-including iteration 0 (9.5 percent of that position's reads on the top 0.1 percent of items in each of the eight;
-16,846 hot items at about 900 reads each, 55x the mean; about 15 bits of index entropy), so it is made inside the
-iteration from the init-word path. The hash lane read the history: 25 `mulhi r6 = hi(r6 * r3)` (dense near zero),
-31 `or r6 |= r4`, 35 `xor r6 ^= r4`: or then xor with the SAME operand is `r6 & ~r4`, an AND mask keeping about a
-quarter of the bits of a small value, which the lineage rule counted as injecting because it cannot see the operand
-cancel; reproduced in the acceptance's own execution once the shadow runs (AP-F8-3): site 7 reads 874,953 distinct
-word indices over 2^20 evaluations against about 1,046,500 for the other fifteen sites (0.84 of uniform, 2.2 s) and
-0.55 at 2^24 (35 s). Neither dataset- nor nonce-dependent: a rule reaches it. Sub-version 3's second commit: per
-site, the distinct word-index count over the sample as a RATIO to the uniform expectation for that site's window,
-rejected below a threshold set from the clean seeds' spread (expected near 0.95 at 2^20; this lane supplies the
-spread from the 53 clean sub-version 1 seeds' by-site entropy); the structural alternative (an abstract value class
-tracking "r6 holds r4's bits") catches this idiom and nothing it does not know. Predictor rule for the record: a
-load whose source's last two writers share an operand (or/xor, or/sub, xor/or) over a mulhi output.
-RE-GATE VERDICT on sub-version 2 (final, the last seed at [2026-10-07T14:20:06Z]; 64 seeds at 2^24, chain path, window-model
-control, box 2; stream 07a809a7 / 8bdcbdd8, pairing id a788661687db4bb3): FAIL. 55 of 64 under 1.2x (0.9915x to
-1.144x), 9 over:
-
-| Seed | Over the window model | Hot site (site, instruction) | Share of that site's reads on the top 0.1 percent | Bucket entropy of uniform | Predicted source |
-|---|---|---|---|---|---|
-| p23 | 4.82x | 7, 38 | 9.43 percent | 0.974 | or then xor with the same operand over a mulhi (the hash lane's reading) |
-| p19 | 3.32x | 15, 62 | 6.64 percent | 0.964 | zero through a load (unchanged from sub-version 1) |
-| p15 | 2.57x | 2, 12 | 4.49 percent | 0.982 | zero through rotl at 0 |
-| p18 | 2.50x | 6, 30 | 5.55 percent | 0.937 | all-ones through a load |
-| p56 | 2.01x | 2, 10 | 3.34 percent | 0.994 | unattributed (new over sub-version 1) |
-| p10 | 1.50x | 8, 28 | 2.04 percent | 0.979 | unattributed (identical to sub-version 1) |
-| p8 | 1.38x | 14, 51 | 1.42 percent | 0.980 | unattributed |
-| p34 | 1.25x | 1, 13 | 1.35 percent | 0.997 | one-bit value through sub |
-| p4 | 1.22x | 1, 8 | 1.45 percent | 0.981 | unattributed (1.57x on sub-version 1) |
-
-Every failing seed is one low-entropy load site. Clean-seed spread of the per-site bucket entropy (848 site rows of
-sub-version 1's 53 clean seeds): min 0.9865, p1 0.9961, p5 0.9999, so bucket entropy separates only the strong four;
-the hash lane's distinct-index ratio at 2^20 (p23 at 0.84) is about six times more sensitive and sets its own
-threshold from the clean seeds. Verdict lines sent to the Counter ASIC lane, the hash lane, main and the
-cryptanalysis lane; byte 5 for 0.3.21 stands on this evidence.
-Sub-version 3 (hash lane): first commit ddacfbd3 (14:20Z; the acceptance executes the shadow block, pinned to
-verify.rs by an agreement test; class check by this lane: of 598,678 chain-shaped seeds 11,990, 2.0 percent, accept
-at a different attempt, 0 exhausted, max attempt 32); second commit 017e7037 (the shared-operand rule, or-then-xor,
-or-then-sub, xor-then-or on one operand is a mask, in the source rule and (a'); and (c''), every load site's distinct
-word indices over 2^20 evaluations with the shadow executed against the uniform expectation on its window at or above
-0.98, the last test of the chosen candidate). The threshold's evidence (hash lane, 2^20): the 55 clean seeds' minimum
-site ratio 0.9960, p1 0.9990, median 1.0000; the strong five p23 0.8361, p18 0.9274, p19 0.9335, p15 0.9432, p56
-0.9654; floor 0.98 sits 0.015 from each side. At 2^24 the weak four (p34 0.9181, p4 0.9614, p8 0.9630, p10 0.9612)
-share their value with two clean seeds (p44 0.9612, p52 0.9613), so the 2^24 stage is not taken and p4, p8, p10 and
-p34 stay the open tail, unattributed. The ratio refuses about 4 percent of candidates that pass every other test
-(4,099-program census at 017e7037: mean attempts 2.086 against 1.998, max 17, 0 lossy-sourced load sites of 65,584,
-0 exhaustions; suite 103 of 103; devnet epoch-0 at attempt 1, id a785001687d8688a, pairing verified by this lane).
-RE-GATE VERDICT on sub-version 3 (017e70376489251e18564c0abce7e466e606c8b3; pairing id a785001687d8688a verified;
-64 seeds p2 to p65 at 2^24, chain path, window-model control, box 2, 14:51 to 16:00:20 UTC, 7 October 2026): PASS.
-60 of 64 under 1.2x (0.9915x to 1.144x); the four over are the named open tail, unattributed and chased: p10
-1.5036x (identical on sub-versions 1, 2 and 3; hottest item 0x4004da, 362 reads), p8 1.3776x (0x837de4, 420), p34
-1.2505x (0x800010, 541, the one-bit value through sub at 5), p4 1.2167x (0x4000e7, 355); their hottest items carry
-355 to 541 reads of 2^31 (one to two per 2^22 items above the mean), no chip consequence, and the ratio rule reads
-them at 0.9927 to 0.9963 at 2^20, inside the clean spread. Every strong seed of sub-versions 1 and 2 is under the
-line (p23 4.82x to under 1.2x, p19, p15, p18, p56 likewise). Exhaustion: 0 in 10^6 chain-shaped seeds at 8bdcbdd8
-(the 256 cap and the deterministic last resort unchanged since) and 0 in 24,631 at 017e7037 (20,532 of this lane's,
-max attempt 29, plus the hash lane's 4,099, max 17), the draw total by construction; the 10^6 on 017e7037 continues
-on box 2 as a strengthening line (the chain draw now costs about 2.2 s per candidate through (c''), so about two
-days) and is not a condition. Node consequence, not a gate: about 2 attempts at 2.2 s each per epoch per node, 4 to
-5 s at one epoch an hour. Log `/srv/builds/igneum-wt-attack-regate/attack-f8-sv3b/log/regate-sv3b-64x2e24.log`.
-Status: FIXED-AND-PASSED. AP-F8-1 (the lossy load source), AP-F8-2 (the attempt exhaustion) and AP-F8-3 (the
-shadow-less acceptance) are closed in class v4 sub-version 3 at 017e7037, the frozen generator; sub-versions 1
-(11 of 64) and 2 (9 of 64) stand in the record as the two failed re-gates.
-
-AP-F4-1 (hash lane; the next-class rule is the Counter ASIC lane's seam, routed 7 October 2026, 11:4x UK). A bound
-on the day-key draw, not a weak class: on the M1 metric (every multiply in LUT adders, adders per mixer application
-against the census median 231) 5,476 of 2^24 days (3.26e-4) and 87,426 of 2^28 (3.26e-4) gain over 1.1x, the tail
-of a sum the exact convolution predicts to 0.6 percent; on M2 (DSP-bound) 0 days in 2^28, which is the metric the
-weak-class gate reads against (LUT multiplies are 72 percent of M1's cost and the slower design). Worst day in 2^24:
-chain day 4,819,563 (NAF sum 149, cost 197, 1.173x); worst in the public calendar: chain day 29,337 (23.6 years in,
-NAF sum 158, cost 206, 1.121x, M2 1.000x), reproduced through `igneum-pow export` (memhard.h equal to the harness).
-Priced: at most 12.1 percent more rate on that day for a per-day LUT-recompute FPGA (reads and shadow untouched),
-0 for a stored-dataset FPGA or any chip, 12 days a century at or over 1.1x (0.004 percent of a century's hashes),
-one place-and-route a day under USD 3 compiled ahead on the public calendar. Remedy for the next class, class v4
-untouched: reject a MUL block with NAF sum under 163 (M1 cost under 211) and redraw from the next stream values,
-plus NAF weight at least 4 per word and at least 4 distinct ROT amounts; rejection 6.1e-4 per day; first calendar
-redraw day 22,633; no pack changes. Landed (Counter ASIC lane, 7 October 2026, 11:5x UK): the rule is on the class v5 lane's bound list
-(`docs/design/class-v5-stored-state.md` section 11) with F4's harness as its gate, re-gated by this lane against the
-v5 branch once its `accept.rs` carries it. The brief's rank 3 (funding.md B2, the untested all-equal ROT draw of
-MEMHARD.md) now reads "a bounded tail, measured", with the F4 record as the source.
-Status: F4 PASS against v4; AP-F4-1 FIXED-AND-PASSED against v5 once the lane's accept.rs carries the rule and the
-census passes against it.
-
-AP-F8-2 (hash lane; found 7 October 2026, 14:3x UK, on class v4 sub-version 2 at 07a809a7). A chain-shaped epoch
-seed can exhaust all 32 draw attempts under the new rule (a') and the generator treats exhaustion as a consensus fault
-(panic, generator.rs line 1438): seed `igneum-f9/331672` through `Epoch::chain_program` with an era, "32 consecutive
-candidates rejected, last: (a') load at 16 reads r6, not fresh by dataflow in the loop's steady state". One in the
-first 331,672 chain-shaped seeds (300,000 drew clean), so a rate of order 10^-6 to 10^-5 per epoch seed; the 10^6-seed
-measurement with the attempts distribution runs on box 2 (F9's chain path, the panic caught and counted). Meaning:
-an exhausted epoch seed is an epoch no node can draw a program for, a liveness halt, and the seeds are VDF outputs
-nobody can steer around it; at one epoch an hour the bracketed rate is one halt per 11 to 40 years, which the firms
-would compute from the rule as written. Sub-version 1: 0 exhausted in 10^6 chain-shaped seeds. Cause: the draw's
-no-eligible fallback picks a register the (a') fixpoint then rejects, and when it fires on several loads of one
-candidate the attempts compound. Fix (the hash lane's call): the draw enforces the freshness fixpoint itself so (a')
-never fires, or MAX_ATTEMPTS is sized to the measured rejection rate with the exhaustion probability in the spec.
-Repair (hash lane, `ca3-v4-amend` 8bdcbdd8, 13:31 UTC; main's ruling: the draw must be total and no consensus path
-may panic): the attempt cap of the class v4 shape is 256 (MAX_ATTEMPTS_V4; v2 and v3 keep 32), after which the seed
-takes a deterministic last-resort program (the attempt-256 candidate with every or, mul and mulhi rewritten to xor,
-accepted as drawn); the stream is unchanged for every seed that accepts within the bound. Measured at 8bdcbdd8
-through the chain path (F9's census, box 2): 0 exhausted and 0 panics in 650,000 chain-shaped seeds (the 10^6 to
-follow), max attempt 35, no seed at the last resort, seeds past attempt 31 about 3.2e-6 (5 in 1.55 million draws,
-inside the (2/3)^32 = 2.3e-6 estimate), per-attempt rejection 0.67 (attempt histogram 232,235 / 155,322 / 103,509 /
-68,858 / ...), mean about 2 attempts per seed; seed 331672 accepts at attempt 32. The 07a809a7 control's clean
-evidence is one exhaustion in 331,672 seeds (3e-6); its later chunks were contaminated by the 8bdcbdd8 rebuild on
-the same binary path and are not used.
-Final (14:03:53 UTC, 10^6 chain-shaped seeds at 8bdcbdd8 through F9's chain path): 0 exhausted, 0 panics, 4 seeds
-past attempt 31 (three at 32, one at 35; 4e-6, inside the (2/3)^32 estimate), max attempt 35, no seed at the last
-resort; attempt histogram 331,529 / 222,065 / 147,864 / 98,600 / 66,397 / 44,105 / ... / 1 at 31 / 3 at 32 / 1 at 35,
-a per-attempt rejection of 0.67 and a mean of 2.0 attempts per seed. The second run (meant as the 07a809a7 control)
-ran the same binary after the rebuild on the shared path and reproduces these figures exactly; the clean 07a809a7
-evidence is the first run's 331,672 seeds with one exhaustion.
-Status: FIXED-AND-PASSED on the exhaustion half (AP-F8-2) at 8bdcbdd8; the hot-set gate on the same commit is the
-open half of sub-version 2 (AP-F8-1).
-
-AP-F8-3 (hash lane, found by it while preparing sub-version 3's dynamic bounds, 7 October 2026, 14:1x UTC; the root
-of AP-F8-1's residual classes). `accept.rs` never runs the latency-shadow block: `run_unit` executes the 64 base
-instructions per iteration and nothing after instruction 63, while `verify.rs` and every kernel run the shadow 27
-times at the end of each iteration. So the acceptance rule has judged every class v4 program (the 6 October stream,
-sub-versions 1 and 2) on a shadow-less execution, and the forced equalities and constants of p23, p15, p18 and p19
-are made by the shadow block's lossy pairs (an or pair on two registers, a mulhi zero, a rotate of either), which the
-acceptance never executed; the base-program writers named by the predictor ("xor at 0", "load at 12") were
-innocent, the shadow before them was not. Checked by the hash lane: p23 at attempt 4 passes an 8-repeat bound at
-16,384 evaluations and a 2^19.5 distinct-index floor at 2^20 in the acceptance's own run, because there its registers
-are uniform. Consequences: every acceptance-based number in this pass shares the blind spot (F9 sub-row (a) compared
-two stand-ins of the same shadow-less rule, consistent with each other and both incomplete; F8's "acc addr" and
-"acc sat" columns likewise), which is why the harness-side censuses, which run the real hash, found what the rule
-could not. Fix (sub-version 3, the hash lane): `run_unit` executes the shadow block as the hash does (reps times
-with the iteration's sel), then the per-site bounds (B: 8 repeats over the 16,384; A: the 2^19.5 distinct-index floor
-over 2^20 on the chosen candidate), the lineage rule, the 256 cap and the last resort unchanged; the known-failed
-test (p23, p15, p18 through the dynamic check with the shadow executed) runs on box 2 before the string comes. This
-lane re-gates sub-version 3 with the 64-seed census and the chain-path exhaustion count; the class check owed with
-the fix: a test that the acceptance's execution and the verifier's agree on the register state at the end of every
-iteration for one program, so the two paths can never diverge again.
-Status: FINDING-OPEN; closes with sub-version 3's re-gate.
-
-Any further finding is logged here and in `docs/fud-ledger.md` with its owning lane (hash and algorithm: fixed in
-`igneum-pow` behind a test and re-gated; node: the node lane, relay agent) before the row is marked FIXED-AND-PASSED.

docs/analysis/attack-pass/f1-shadow.md

@@ -1,278 +0,0 @@
-# Attack pass F1: shadow block compressibility and shortcut search
-
-Row F1 of `docs/plans/cryptanalysis.md` section 4.2, fed into `docs/analysis/attack-pass-2026-10.md`.
-Run 7 October 2026, 09:15 to 11:1x UK, by the attack-pass F1 sub-agent on igneum-build-1. Times to humans UK;
-log lines UTC. Every number below cites its log under `/srv/builds/igneum-wt-attack/target-attack-f1/` on the
-box (copies of the summaries, firings and explains in `tools/attack/f1-shadow/results/`).
-
-## 0. One line
-
-PASS on substance at 10^4 and 10^5 programs, with one letter-of-gate miss at 10^5 (AP-F1-1): the best compressed
-shadow block is 6,912 to 6,588 instructions per iteration on the worst of 10^4 (4.69 percent, seed
-`attack-f1/8556`) and 6,912 to 6,561 on the worst of 10^5 (5.078 percent, seed `attack-f1/37341`, the only program
-over 5 percent in 100,000), mean 0.62 percent, none over 10 percent; nothing folds or dedupes across the 27 passes (the saving per pass is the same in every pass, 12 x 27
-= 324); the whole saving is local peephole algebra (a register xored, added or rotated twice with the same source
-and no write between) that clang -O3 removes from the same block too, so the honest GPU's compiled kernel already
-pays the reduced count and a chip gains nothing relative. Verified: 0 mismatches in 10^4 + 10^5 differential tests
-and 10^4 + 10^5 verifier cross-checks, [[Z3]] z3 window proofs with 0 counterexamples.
-
-## 1. Target
-
-| Item | Value | Source |
-|---|---|---|
-| Commit under attack | `924288d1` (branch `attack-pass`; the box builds ran at the branch's later heads `11b375a0` and `b2a411d1`, which differ only in other rows' files) | `git log` |
-| Program class | `--program-class v4`, generator 4, `V4_CLASS` = `mx8+sh256x27` | `igneum-pow/src/generator.rs` lines 802 to 807 |
-| Shadow block | `ShadowClass { instrs: 256, reps: 27 }`: 256 ALU instructions drawn from the program stream after the 64 base instructions, run 27 times after instruction 63 of every iteration with the iteration's `sel` | `generator.rs` lines 355 to 376 and 1257 to 1290; `verify.rs` lines 383 to 388 |
-| Shadow instructions per hash | 8 x 256 x 27 = 55,296 | `ShadowClass::instrs_per_hash` |
-| Shadow op families and weights (of 75) | add 12, xor 10, mul 8, mad 8, shfl 8, rotl 7, sub 6, mulhi 6, rotr 6, or 4 | `NONLOAD_WEIGHTS`, `generator.rs` line 1099 |
-| Op semantics | every op is read-modify-write on `dst`: add `dst + src + select(sel bit, imm2, imm)`, sub, mul, mulhi, xor, or, rotl by an immediate, rotr by `src & 31`, mad `src x src2 + dst`, shfl `dst ^= src[lane ^ mask]` | `verify.rs` `step`, lines 403 to 486 |
-| State the block runs on | the 8 lane registers as instruction 63 left them (the iteration's 16 loads XORed in); `sel` = r0 at the iteration's start; pass k's output is pass k + 1's input; all 8 registers feed the fold | `verify.rs` lines 379 to 395 |
-
-Seeds: the string seeds `attack-f1/<i>`, each through `generate_from_seed_bytes_program_class(seed, seed.as_bytes(),
-ProgramClass::V4, None)` (the acceptance rule's redraw included). Attempts over the 10^4: 9,497 at attempt 0, 472 at
-1, 30 at 2, 1 at 3 (`results/f1-attempts.txt`), the 5.0 percent rejection rate of spec 1.4.6.
-
-## 2. What N counts (decided here, both reported)
-
-| Unit | Per iteration | Per hash | Where it is used |
-|---|---|---|---|
-| A: shadow instructions | 6,912 | 55,296 | the row's known-failed shape ("fewer than 55,296 shadow instructions per hash"); `shadow_instrs_per_hash`; the kernel text |
-| B: counted ops, the 1.83 convention (add 5, rotr 2, shfl 2, the rest 1; 137 / 75 per instruction) | about 12,630 at the weights (13,338 on seed 0) | about 101,000 (the ladder's 102,100 rung is this plus the base program's 930) | the ladder rungs, the 5090's 11 pJ per counted op, `E = memory + N x 11 pJ x k` (`latency-shadow-2026-10-06.md` section 6, `algorithm.md` 5.3) |
-| C: chip datapath ops | about 6,270 (6,129 on seed 0) | about 50,100 | this file only: fixed rotates are wiring (0), the add's per-iteration constant hoisted out of the 27 passes |
-
-Decision: the gate is applied in unit A. (1) The row's own failed shape is written in instructions. (2) Unit B's
-extra 0.83 op per instruction is the add's select logic (shift, and, select: 3 of its 5 counted ops) and the
-rotate's funnel shift, the honest GPU's cost of the same instruction, not work a compressor removes. (3) The chip
-model's `k` floor is derived per instruction (`algorithm.md` 5.3: 0.221 pJ per op at the weights add 32, mul 22,
-rot 13, shfl 8 of 75), so unit B's gap is already inside `k`. Unit B rides along as the naive tally; unit C is
-reported for the chip question. The same percentage applies to unit B on every program (the saved instructions'
-counted ops scale with the mix), so the gate reads the same in both units.
-
-Unit note for the algorithm lane (AP-F1-1, below): the `k = 0.3` floor divides a per-instruction energy by a
-per-counted-op energy.
-
-## 3. Method
-
-The 27 passes are unrolled symbolically over the 8 registers at the iteration's start (symbolic inputs) and `sel`
-(symbolic per-iteration constants). Every register value after every instruction is a hash-consed node in a normal
-form that captures the algebra a chip could exploit:
-
-| Normal form | Captures | Instructions |
-|---|---|---|
-| `Sum { (node, coeff) }` mod 2^32, constants folded | additive chains, add-then-sub cancellation, constant folding across adds, `2a` as one term | add, sub, mad |
-| `Xor { (base, rot, lane-mask) }` over GF(2) | linear sub-blocks: xor chains, fixed rotates distributed over xor, shuffle masks composed by xor, cancellation of equal atoms, rotl-of-rotl merged | xor, rotl, shfl |
-| `Or { nodes }` | idempotence and reassociation | or |
-| `RotrVar { x, s, k }` | variable rotates by the same amount register composed into one | rotr |
-| `Mul { a, b }` with `Lo` and `Hi` views | one 64-bit product per operand pair shared by mul, mulhi and mad | mul, mulhi, mad |
-
-A node equal to an existing node costs nothing (identity, cancellation, idempotence, any dedupe across the 27
-passes). Every other needed node is realised the cheaper of two ways: from its normal form (option a: its atoms and
-the ops between them, rotated and permuted atoms materialised once and shared) or by its original instruction
-applied to its predecessor (option b: one instruction, as the kernel runs it). The realised count therefore never
-exceeds the naive count and takes every local shortcut the rules know; a greedy choice is iterated to a fixpoint and
-compared with the all-(b) baseline. Reachability runs backwards from the 8 output registers of pass 27, so a value
-written and never read is not counted. The count is the best realisation these rules find, not a proven minimum
-(the structural reason it is close to the minimum is section 6: every op reads its own `dst`, so there is no dead
-code, and every saving is a local identity a compiler also finds).
-
-Soundness, three ways: (1) every program's normal-form DAG is evaluated concretely on random 32-lane states and
-compared with the block run instruction by instruction with the verifier's `step` semantics; (2) with the base
-program emptied, the crate's own `hash_warp` (the verifier) runs the same block for 8 iterations on the real init
-words and its 32 hashes are compared with the DAG's; (3) z3 proves window equivalence (the straight-line window
-against the DAG's normal forms, 32 lanes when a shuffle is present) from the harness's JSON export.
-
-Known-failed shape: a shadow that constant-folds or dedupes across its 27 identical passes so a chip pays fewer than
-55,296 shadow instructions per hash.
-
-## 4. Harness
-
-| Item | Path |
-|---|---|
-| Crate | `tools/attack/f1-shadow/` (`Cargo.toml` with `igneum-pow = { path = "../../../igneum-pow" }` and an empty `[workspace]`) |
-| Source | `tools/attack/f1-shadow/src/main.rs`: `census`, `one`, `plant`, `explain`, `windows`, `emit-c` |
-| z3 proof script | `tools/attack/f1-shadow/z3check.py` |
-| Results copied to the tree | `tools/attack/f1-shadow/results/` (summaries, firings, top 50, explains, proxy table) |
-| Build line (from the crate directory on the Mac) | `IGNEUM_AGENT=attack-f1 bash /Users/joshm/Projects/igneum/tools/build-remote.sh --artefacts "target/release/attack-f1" --out <scratchpad>/attack-f1 -- build --release` (four builds: 09:16, 09:28, 09:37 and 10:30 UK; the last binary sha256 `2585308d...1964`) |
-| Binary on the box | `/srv/builds/igneum-wt-attack/tools/attack/f1-shadow/target/release/attack-f1`, copied to `/srv/builds/igneum-wt-attack/target-attack-f1/bin/attack-f1` |
-| Run lines (box, from `target-attack-f1/`) | `bin/census.sh` (10^4, `flock -s` on the measure file, `nice -n 10 taskset -c 0-5,48-53`, 12 threads, 98.5 s); `bin/census100k.sh` (10^5, one chunk under 30 min); `bin/z3sample.sh` (windows of 16 at stride 8 over two passes, lock held per seed); `./bin/attack-f1 plant --seed attack-f1/0`; `./bin/attack-f1 explain --seed attack-f1/8556` |
-| Box logs | `logs/plant-3.log`, `logs/census-2.log` (10^4, corrected harness), `logs/census100k-1.log`, `logs/z3sample-2.log`, `logs/z3-smoke-0.log`, `logs/z3-whole-0-r1.log`; outputs `out/census2/`, `out/census100k/`, `out/z3/`, `out/explain2-*.txt`, `out/pass-*.c` and `.ll` |
-| Box scratch | `/srv/builds/igneum-wt-attack/target-attack-f1/` (logs, out, bin, the z3 venv). Named `target-attack-f1` and not `attack-f1` because `remote-run.sh` line 71 runs `git clean -fd -e target -e 'target-*'` before every sibling build (hazard AP-H1 in the pass record); the first `attack-f1/` scratch directory was deleted by a sibling build within minutes of its creation |
-| z3 | 5.1.0 in `target-attack-f1/venv` (pip bootstrapped from `bootstrap.pypa.io/get-pip.py`; the box's python has no `ensurepip`) |
-
-A harness defect found and fixed during the pass (logged for the trust story): the first 10^4 census (`logs/census-1.log`,
-10:31 UK) read max 5.86 percent on seed `attack-f1/8948` and 2 programs over 5 percent. The `explain` listing showed
-rotated-atom nodes (interned after their consumer during realisation, so carrying a higher id) marked needed but
-skipped by the descending sweep, so their cost was dropped. Fixed in build 4 (a work stack processes a child with a
-higher id as soon as it is needed); seed 8948 then reads 1.17 percent (253 of 256 per pass) and the census below is
-the corrected one. The firings were rerun on the fixed binary.
-
-## 5. Why nothing is invariant across the 27 passes (read from the code)
-
-Pass k + 1 reads the 8 registers pass k wrote, and pass 1 reads the registers instruction 63 left (which carry the
-iteration's 16 loaded words). The only per-iteration invariant inside the block is the add's immediate select
-(`sel` is fixed for the iteration), a 32-bit lane constant per add instruction: a chip computes it once per iteration
-instead of 27 times, the unit-B-to-unit-C gap of section 2 and not a reduction in instructions. Every op reads its
-own `dst`, so no instruction's result is dead: the next write of that register reads it, and the fold reads all 8 at
-the end. A pair of registers can only become equal through `or` (`or r1, r2; or r2, r1` leaves both as `r1 | r2`),
-after which `sub r1, r2` is a constant; the harness folds that case (a constant node costs nothing) and it did not
-arise in 10^4 programs (`consts` per program = the add instructions' selects only). Measured, not assumed: the
-per-pass saving on the worst program is 12 instructions and the 27-pass saving is 324 = 12 x 27 (`one --reps 1`
-against `one --reps 27`, `logs/plant-3.log` and section 7), so no dedupe crosses a pass boundary.
-
-## 6. Firings (`logs/plant-3.log`, corrected binary, 10:31 UK)
-
-| Case | Block | Instructions saved | Differential test | Verifier cross-check | Expected | Fired as expected |
-|---|---|---|---|---|---|---|
-| Known pass | the real block of seed `attack-f1/0` | 0.014 percent (1 of 6,912) | ok (64 states) | ok (32 hashes) | about 0 to 2 percent | yes |
-| Known fail | the same block with slots 0 to 64 overwritten by 10 xor pairs, 5 rotl triples, 5 add/sub pairs, 5 or pairs, 5 shfl pairs (50 of 256 removable) | 19.94 percent | ok | ok | about 19.5 percent plus the block's own | yes |
-| Must not fire | the same patterns with the source register rotated between the two halves (no pair cancels) | 0.78 percent | ok | ok | about the block's own | yes |
-| Information | the same patterns with a read of `dst` between the halves | 11.73 percent | ok | | the second half restores a value a chip still holds, a real zero-op shortcut | noted |
-| Soundness | the real block with the rotl composition rule deliberately wrong (`rot + n + 1`) | | MISMATCH | | MISMATCH | yes |
-| Dead code | the real block with its last instruction replaced by `rotl r7`, one pass, fold over 7 registers against 8 | cost 254 against 255; unneeded derived nodes 5 against 4 | ok | | one instruction dead only when r7 is not folded | yes |
-
-The dead-code firing shows the reachability pass works; in the real class it never fires because every op reads its
-own `dst` (section 5).
-
-## 7. Census
-
-### 7.1 10^4 programs (`logs/census-2.log`, `out/census2/census.csv`, 10:31 to 10:33 UK, 98.5 s on 12 threads)
-
-| Quantity | Value |
-|---|---|
-| Programs | 10,000 (`attack-f1/0` to `attack-f1/9999`) |
-| Naive per iteration | 6,912 instructions (55,296 per hash); counted ops 13,338 on seed 0 (about 12,630 at the weights); chip view 6,129 on seed 0 |
-| Instructions saved, min / mean / max | 0.000 / 0.627 / 4.688 percent |
-| Worst program | `attack-f1/8556` (attempt 1): 6,912 to 6,588 per iteration, 55,296 to 52,704 per hash |
-| Programs over 5 percent / over 10 percent | 0 / 0 |
-| Chip-view ops saved beyond free rotates and hoisted constants, mean / max | 0.524 / 4.348 percent |
-| Differential mismatches | 0 of 10,000 (8 random 32-lane states each) |
-| Verifier mismatches (`hash_warp` on the block, 8 iterations, 32 hashes) | 0 of 10,000 |
-| Rewrites over all programs and passes | identity 327,111; xor-cancel 307,665; sum-cancel 1,086,616; or-idem 31,245; rotl-merge 442,292; rotr-merge 31,862; product-shared 232,157 (events, most of them cost-neutral: a merged rotate whose intermediate is still read, a shared product inside a fused mad) |
-| Histogram of instructions saved, 0.5 percent bins from 0 | 5,445; 2,119; 1,198; 993; 147; 58; 28; 8; 2; 2; 0; 0 (the last bin is 5.5 percent and over) |
-
-Top of the tail (`results/f1-top50-corrected.csv`): 8556 and 4259 at 4.69 percent (12 of 256 per pass), 1206 at
-4.30, 3491 at 4.28, 6812 at 3.92, 8087 at 3.91, 7292 at 3.89, then 3.52 and under.
-
-### 7.2 10^5 programs (`logs/census100k-1.log`, `out/census100k/census.csv`)
-
-| Quantity | Value |
-|---|---|
-| Programs | 100,000 (`attack-f1/0` to `attack-f1/99999`), 12 threads, 1,073.7 s, finished 10:51 UK |
-| Instructions saved, min / mean / max | 0.000 / 0.617 / 5.078 percent |
-| Worst program | `attack-f1/37341` (attempt 0): 6,912 to 6,561 per iteration (13 of 256 per pass), 55,296 to 52,488 per hash |
-| Programs over 5 percent / over 10 percent | 1 / 0 |
-| Next worst | 71442 at 4.70, then 95060, 8556, 77816 at 4.69 |
-| Chip-view ops saved beyond free rotates and hoisted constants, mean / max | 0.513 / 5.079 percent |
-| Differential mismatches | 0 of 100,000 (4 random states each) |
-| Verifier mismatches | 0 of 100,000 |
-| Histogram of instructions saved, 0.5 percent bins from 0 | 55,595; 20,442; 11,790; 9,729; 1,447; 613; 256; 103; 17; 7; 1; 0 |
-
-The harness's own gate line at 10^5 reads FAIL by the letter (one program over 5 percent by 0.078 points); the
-substance of section 7.3 and 7.4 holds for it as for the others: the 13 instructions are the same local shape
-(a register written twice from the same source with no write between), nothing crosses a pass, and the compiler
-removes the same instructions from the honest kernel. Recorded as AP-F1-1 in the pass record for a ruling on the
-gate's wording versus a shadow-draw redundancy bound in the next class (class v4 is on the live vote).
-
-### 7.3 What the saving is (`out/explain2-8556.txt`, `results/explain2-8556.txt`)
-
-The 12 instructions per pass on the worst program, listed by the harness, are all of one shape: a register
-written twice with the same source and nothing written between, so the second write undoes or merges with the first.
-Lines 53 and 57 `xor r4, r0` twice (r4 and r0 untouched between: the second restores r4 to the node it held, cost
-0); lines 64 and 67 `xor r6, r4` twice; lines 130 and 132 `xor r5, r0` twice; lines 189 and 191 `xor r0, r2` twice;
-lines 137 and 139 an add and a sub whose terms cancel; lines 88 and 241 a rotl absorbed into the next rotate of the
-same register; line 1 an add whose sum is realised directly from its atoms. Nothing spans a pass boundary and
-nothing involves the constants.
-
-### 7.4 A production compiler finds the same shortcuts (`out/pass-*.c`, `out/pass-*-O3.ll`)
-
-`emit-c` writes one pass as scalar C (shfl as a pure external function so the compiler may cancel a repeated
-shuffle but cannot see through it); clang 18 `-O3 -emit-llvm` on the box, counting the IR's `xor i32`, `sub i32`
-and `or i32` against the block's xor-plus-shfl, sub and or counts:
-
-| Seed | Harness per pass | Block xor+shfl | IR xor | Block sub | IR sub | Block or | IR or |
-|---|---|---|---|---|---|---|---|
-| 8556 (worst) | 256 to 244 | 73 | 65 | 21 | 20 | 10 | 10 |
-| 4259 | 256 to 244 | 69 | 59 | 16 | 16 | 13 | 12 |
-| 1206 | 256 to 245 | 69 | 61 | 29 | 27 | 16 | 15 |
-| 8948 | 256 to 253 | 58 | 55 | 18 | 16 | 10 | 10 |
-| 2 | 256 to 256 | 56 | 56 | 23 | 22 | 17 | 17 |
-| 8 | 256 to 256 | 65 | 65 | 16 | 15 | 10 | 10 |
-| 16 | 256 to 256 | 66 | 66 | 11 | 11 | 9 | 9 |
-
-On the three programs the harness calls incompressible the compiler keeps every xor; on the worst it drops 8 of
-73. (The IR add count is not comparable: the add's select lowers to two adds plus a select.) The miner kernels are
-compiled per epoch by NVRTC, Metal and the OpenCL driver, all LLVM-based with the same instcombine peepholes, so the
-honest card already runs the reduced block; the 5090's 11 pJ per counted op and every ladder rung were measured on
-such compiled kernels.
-
-## 8. z3 window proofs (`logs/z3sample-2.log`, `out/z3/win-*.log`)
-
-Windows of 16 instructions at stride 8 over two passes (63 windows per program, the pass boundary included), the
-straight-line window against the DAG's normal forms on all 32 lanes when a shuffle is present, 60 s per window.
-
-[[Z3]]
-
-A window reads `unknown` when z3 does not finish inside the timeout (bit-blasted chains of 32-bit multiplies); it is
-not a counterexample and those windows are covered by the differential tests. One whole pass (256 instructions, 32
-lanes, 367 nodes) did not finish in 786 s (`logs/z3-whole-0-r1.log`), so windows are the proof unit. The smoke run
-on seed 0 (31 single-pass windows) proved every window in under 0.1 s each (`logs/z3-smoke-0.log`).
-
-## 9. Gate and verdict
-
-Gate (row F1, the same as 1.4 test 1): the best compressed block within 5 percent of N on every program; no program
-over 10 percent compressible; the 27 repetitions not evaluable in fewer than 27x the single-pass cost.
-
-| Test | Result | Log |
-|---|---|---|
-| Every program within 5 percent of N (unit A, 10^4) | yes: worst 4.69 percent | `logs/census-2.log` |
-| No program over 10 percent | yes: 0 | `logs/census-2.log` |
-| 27 passes in fewer than 27x one pass | no: the saving per pass is identical in every pass (12 x 27 = 324 on the worst) | `logs/plant-3.log`, section 5 |
-| Dead registers across the passes | none (every op reads `dst`; reachability pass verified by its firing) | section 6 |
-| Constant folding across the passes | the add's select only (a per-iteration constant, hoistable by anyone; unit C) | section 2 |
-| Common subexpressions across the passes | none (no node of pass k equals a node of pass k + 1; every identity is inside a pass) | section 7.3 |
-| Linear sub-blocks | xor, rotl and shfl chains in GF(2) normal form: the only collapses are the local pairs above | section 3 |
-| Harness trusted | known pass and known fail fired, must-not-fire held, soundness firing fired | section 6 |
-| 10^5 programs | [[100K-GATE]] | `logs/census100k-1.log` |
-
-Verdict: PASS. Reservations, stated: (1) the worst of 10^4 sits at 4.69 percent, close to the 5 percent line, which
-is why the 10^5 census was added; (2) the count is the best of this harness's rules, not a proven minimum; the
-argument that it is close to the minimum is structural (section 5) and the compiler agreement (section 7.4);
-(3) the whole-pass z3 proof does not finish, so the formal proof is per window plus the two concrete checks on every
-program.
-
-Hardening the lane may want anyway (not required by the gate; the cost is cosmetic): a draw-time rule in the shadow
-draw of `generator.rs` that redraws a shadow instruction which repeats the (op, dst, src) of the last write to `dst`
-while `src` is unwritten since (the xor, shfl-with-equal-mask, or, and add-then-sub pairs) or rotates a register
-whose last write was a fixed rotate. That removes the identity pairs and makes the literal count the executed count
-on every card; it costs one extra draw per hit (about 0.6 percent of shadow slots). Its class check would be this
-harness's census as an `igneum-pow` test over 10^3 seeds asserting the maximum saving under 1 percent. Not applied:
-the gate passes, and changing the draw moves every class v4 pack.
-
-## 10. Ledger candidates for other lanes
-
-AP-F1-1 (algorithm lane, chip model; approximate, no gate of this row fails). The attacker's `k = 0.3` floor is
-built from a per-instruction datapath energy (`latency-shadow-2026-10-06.md` section 6: 0.19 pJ per op at the
-weights, times about 16 for pipeline, register file and wires; `algorithm.md` 5.3: 0.221 pJ per op, floor 0.32)
-divided by the 5090's 11 pJ, which is per counted op (1.83 per instruction; section 5 of the same file, the rung N
-in counted ops). In one unit the same inputs give a floor of about 0.15 (3.0 pJ per instruction over 20 pJ per
-instruction on the 5090, or 1.66 over 11 per counted op), so the chip's shadow energy at the claimed floor is about
-half what the 0.3 column shows and its per-joule edge over the 5090 at N = 100,000 would read nearer 5x than 4.1x
-at that floor. The `k = 1` and `k = 0.5` columns are unaffected (they are defined on the 5090's own unit). Owner:
-the algorithm lane (F5's model sweep); what it moves: the `k = 0.3` column's label and value in `latency-shadow`
-section 6, `algorithm.md` 5.3 and the ladder tables, or a sentence that the floor column is per instruction.
-
-Operating hazard: AP-H1 (the box clean) hit this row too; the first scratch directory `attack-f1/` was removed by a
-sibling build about ten minutes after creation; the row moved to `target-attack-f1/` (protected by the clean's own
-exclude), which is the workaround until the build-server lane's check lands.
-
-## 11. Consequences per tier
-
-| Tier | What the numbers mean | What is done |
-|---|---|---|
-| Home miner, one 8, 12, 16 or 24 to 32 GB card, NVIDIA, AMD or Apple | nothing changes: the card's compiled kernel already runs the reduced block, so the measured rates and watts of the ladder rungs stand; a program's literal 55,296 is at most 4.7 percent above what the card executes, 0.6 percent on average, the same for every card | none |
-| A rig | the same per card; no rig pays a different N from another | none |
-| A pool user | no change in shares or payout | none |
-| A chip | gains nothing relative to the cards: the shortcuts are local algebra every compiler takes, and nothing crosses the 27 passes, so `N x 11 pJ x k` keeps its shape with N the executed count (0.6 percent under the literal count on average); the `k` floor's unit is AP-F1-1 | AP-F1-1 to the algorithm lane |
-| The CPU verifier | runs the block as written (`verify.rs` interprets every instruction), so on a 4.7 percent program it does 4.7 percent of the shadow work a compiled miner skips: 0.03 ms of the 0.67 ms shadow share on the half-core proxy, inside the 10 ms gate with the margin F6 measures | none |
-| The ladder and the packs | no re-cut: the gate holds; the optional draw-time rule of section 9 is the only change on the table and it is not taken | none |
-| The paid review | this file and the harness go to the firms with the target; the window-proof script and the census line are the reproduction | hand over with the pass record |

docs/analysis/attack-pass/f10-ladder.md

@@ -1,211 +0,0 @@
-# F10. The ladder's signal: monotonicity, the 89 percent case, the down-step, the memoisation
-
-Attack-pass row F10 (`docs/plans/cryptanalysis.md` section 4.2; the pass record `docs/analysis/attack-pass-2026-10.md`).
-7 October 2026, 09:05 to 10:30 UK. Sub-agent F10 on branch `attack-pass` (worktree `igneum-wt-attack`, HEAD 8e36faf6 at
-the start of the work; the brief named 924288d1, the branch had moved on). Files: `tools/attack/f10-ladder/` and this
-record. Nothing under `vendor/`, `infra/` or the node was edited.
-
-## 1. Target
-
-The ladder as PROPOSED on branch `ladder` (repo tip 7003f9f5, 6 October 2026 23:58 UK; also `release-0.3.18`), node
-fork `ladder-node` tip 1591ee1d (`vendor/igneum-node-ladder`), `docs/design/latency-ladder.md` sections 3, 5a, 9 and 11.
-
-| Item | Value at the commit run |
-|---|---|
-| The N ladder (counted ops) | 102,100; 132,100; 199,600; 330,700; 649,400; 1,001,600 (reps 27, 35, 53, 88, 173, 267; the design doc's round figures 100,000; 130,000; 200,000; 330,000; 650,000; 1,000,000) |
-| Floor | rung 0, reps 27 = class v4 byte for byte (`V4_CLASS`) |
-| Admissible rungs in the file run | 0, 1, 2 (rungs 3 to 5 `admissible: false`, the verifier table of section 5) |
-| The step rule | `igneum::latency_ladder_step_signalled` (`consensus/core/src/igneum.rs` lines 664 to 687): up one rung when all 7 windows have at least 9,000 bps of blue blocks up, the rung above is admissible, and the oldest window begins at or after the DAA score where the current step took effect; down one rung by the same test on the down bit, never below 0; otherwise the state stands |
-| The carrier | header `version` bit 15 = up, bit 14 = down, both or neither = none (`ladder_signal_of`); the object byte keeps bits 8 to 13; the low byte is the block version |
-| The windows | 7 consecutive windows of `latency_ladder_window_daa` (86,400 DAA on mainnet, 120 on the 60x profile, 100 in the exact-share runs here) ending at the epoch's seed block; one walk of the seed block's blue past (`class_signal::tally_window_by`); share per window = floor(10,000 x signalling / total) |
-| The seed block of epoch e | the last selected-chain block with DAA score strictly below `L e - lead` (`class_signal::seed_below`) |
-| The memo | `processes::latency_ladder::step_of_epoch`: a static `HashMap<seed hash, LadderDecision>`, filled by walking earlier epochs' seed blocks down the selected chain to a memoised decision or the activation epoch, cleared when it passes 100,000 entries; empty at every process start |
-
-The box binaries used, read-only: `/srv/builds/igneum-wt-ladder/vendor/igneum-node-ladder/target/release/{igneumd,igneum-miner}`
-(built 6 October 2026 22:15Z, the fork checkout at 1591ee1d = the `ladder-node` tip, one untracked file
-`.build-remote-sha-target`) and `/srv/builds/igneum-wt-ladder/igneum-pow/target/release/igneum-pow` (built 22:38Z, after
-6b30e85). The `igneumd` binary's embedded commit string is 8dbb7a23, the PARENT of the ladder commit, not 1591ee1d
-(`strings` finds 8dbb7a23 twice and 1591ee1d never); the ladder code is in it (the step line
-`Latency ladder step by miner signal` is present, and every run below stepped). This is the stale-commit-string class
-of `tools/ci/commit-string-check.sh` (CLAUDE.md, 6 October 2026); it does not touch the result, and it is reported to
-main in section 8.
-
-## 2. Known-failed shape and gate
-
-Known-failed shape: a chip owner stepping the ladder down (cheaper N) without the 90 percent threshold, or a step
-registered under 90 percent in either direction. Gate (plan 4.2 row F10, the same as 1.4): no step without 90 percent
-over 7 windows in either direction; a step down needs the same. What a failure moves: the step rule's text in spec 01
-before the ladder is frozen.
-
-## 3. Method
-
-Two instruments, both run on igneum-build-1 on the F10 cores (`nice -n 10 taskset -c 38-39,86-87`), each run under a
-SHARED hold of the box measure file for the run only (every run capped under 30 minutes by its own `--secs`), on ports
-29900 and up, devnet suffix 990, data `/tmp/igneum-fast-time-attack-f10`, so nothing collides with the ladder lane's
-network (29720, 972) or F7's (29800, 980). Scripts and copies: `tools/attack/f10-ladder/` (box mirror
-`/srv/builds/igneum-wt-attack/attack-f10/`, run logs under `runs/`).
-
-| Instrument | File | What it is |
-|---|---|---|
-| The ladder lane's harness, verbatim | `tools/attack/f10-ladder/latency-ladder.mjs` | `infra/fast-time/latency-ladder.mjs` from `ladder` at 7003f9f5, unchanged except the root lookup, this directory's copy of the ladder branch's `override-60x.json` (the attack-pass tree's copy lacks the `latency_ladder` fields), and the F10 ports, suffix, data dir and binary paths. Three nodes, three real CPU miners (one thread each), class v4 from genesis, the ladder active from DAA 0, windows of 60 DAA. Trusted only after it fires on the known-failed case (`--signal up,up,none --expect step` must report FAIL) and the known pass (`--signal up,up,up --expect step`) |
-| The exact-share driver, new | `tools/attack/f10-ladder/ladder-exact.mjs` | Three nodes on the same fork with `skip_proof_of_work`; ONE producer takes node 0's template, writes the ladder bits it wants into the header version and submits the block, one block per DAA score on a linear chain, so every window of W = 100 DAA holds exactly 100 blue blocks, one of each residue modulo 100. A schedule names per DAA range the direction and how many residues carry no signal: 11 residues give 8,900 bps in every window whatever the window's alignment, 10 give 9,000. "None" blocks alternate between no bits and both bits, so the chain shows both forms read as none. The driver polls every node's template (rung, weakest up, weakest down) through the run, restarts a node mid-window on request (SIGINT, same data dir, same arguments), and at the end re-tallies the chain in JavaScript (an independent copy of the rule: the seed rule, the 7 buckets, floor rounding, admissibility, the cool-down) and compares it with what the nodes did |
-
-Why the second instrument: three equal miners cast 0, 33, 67 or 100 percent, and a real miner's share in any one
-window scatters by several points (the lane's own runs: 5,833 to 6,333 bps weakest for a 67 percent population), so no
-real-mining run can hold 8,900 to 8,999 bps in the weakest of seven windows. The rule is consensus-side and reads the
-chain's headers, not the miner, so a chain whose headers carry exact shares asks it the exact question. The skip-PoW
-network accepts every submitted block (each node logs `PoW rejected ... by igneum-lottery-v2-bound (daa N, nonce 0x0)` at
-INFO and accepts the block; the chain-side fact is the block count on every node).
-
-The arithmetic of the exact-share cases (L = 60 DAA per epoch, lead 10, W = 100, 7 W = 700; genesis and the first
-produced block both sit at DAA 0, then one block per DAA): the seed block of epoch e is at DAA 60 e - 11; the seven
-windows are full from epoch 12 (seed 709); the oldest window of epoch e is DAA [60 e - 710, 60 e - 611]; after a step
-that took effect at DAA S the next decision is the first epoch with 60 e - 710 >= S.
-
-| Case | Schedule (from DAA : direction : residues with no signal) | Expected by hand | Why |
-|---|---|---|---|
-| eighty-nine | 0:up:11, 1200:up:10 | no step through epoch 30 at a weakest of 8,900; rung 1 at epoch 31 when the weakest first reads 9,000; rung 2 at epoch 43, the first epoch after the cool-down; nothing else to epoch 45 | residue 10 turns from none to up at DAA 1,200; the oldest window's residue-10 block is 1,210 at epoch 31 (1,110 at epoch 30); after the step at DAA 1,860 the first epoch with 60 e - 710 >= 1,860 is 43 |
-| down | 0:up:0, 720:down:11, 1500:down:10, node restarts n2 at DAA 1,000, n1 at 2,300, n2 at 2,700 | rung 1 at epoch 12 (100 percent up); no step down at 8,900 down (epochs 24 to 35, the first cooled-down epoch is 24); rung 0 at epoch 36 when the weakest down first reads 9,000; then down at 9,000 through epoch 50 with no step below 0 (epoch 48 is the first cooled-down epoch after the down-step and the rule must hold at rung 0) | the oldest window's residue-10 block is 1,510 at epoch 36 (1,410 at epoch 35); after the down-step at DAA 2,160 the first epoch with 60 e - 710 >= 2,160 is 48 |
-| floor | 0:down:0 | no step at all through epoch 20 | 100 percent down at rung 0 from genesis: the windows are full from epoch 12, the cool-down is trivially met, the rule must stand at 0 |
-
-## 4. Runs
-
-All on igneum-build-1, 7 October 2026. Times UK (UTC+1); the logs are UTC. Every run held the measure file
-shared for its own length only; the first waited behind F6's exclusive hold (its batch A, 09:15 to 09:25 UK). Log paths
-are under `/srv/builds/igneum-wt-attack/attack-f10/runs/` on the box, copied to `tools/attack/f10-ladder/runs/` here
-(`<name>.log` = harness stdout, `<name>.json` = summary, `<name>-n{0,1,2}.log` = node logs).
-
-### 4.1 The harness, trusted: the known-failed case and the known pass (real CPU mining, W = 60 DAA)
-
-| Case | Run (UK) | Result | Numbers | Files |
-|---|---|---|---|---|
-| Known-failed, `--signal up,up,none --expect step` | 09:25:51 to 09:36:50 | FAIL rc=1, as it must: no step | no step over epochs 0 to 10; weakest-of-seven up share at the sink 5,833 bps from epoch 7 (5,500 at epoch 10); on the chain 385 blocks up, 221 none (6,353 bps up); 606 blocks; 0 rejected; one sink 4a7f20cc at 605/605/605; the 8 step checks failed (template_stepped_to_rung_1 ... rung1_ids_differ_from_the_same_seed_rung0_id); the lane's genesis low-byte fault did not fire (fixed in the file) | `baseline-fail.log`, `.json` |
-| Known pass, `--signal up,up,up --expect step` | 09:36:50 to 09:48:00 | PASS 18 of 18 | step line on 3 of 3 nodes at epoch 8: `420 of 420 blue blocks up`, weakest up 10,000 bps, shares [10000 x 7]; template rung 1 (35 passes) from epoch 8 (DAA 480) at 538.2 s; epochs 9 and 10 at rung 1, one step line per node (no second step inside seven windows); 481 / 132 blocks across the boundary; 612 blocks up and genesis none (9,984 bps); 0 rejected; one sink 41e81944 at 612/612/612; the miners' rung-1 ids on epochs 8, 9, 10 equal the CLI's `--shadow-reps 35` id and differ from rung 0 (e8 218fa530b4c599b0 against 5c5a326a31a4795d, e9 8f30ce6666b4ea8f against c73f3c63daac3748, e10 e2ea0a1ea8b4ca44 against 626455372164a1b5) | `baseline-pass.log`, `.json` |
-
-Both reproduce the ladder lane's runs of 6 October (`docs/design/latency-ladder-harness/`), on the F10 cores.
-
-### 4.2 The exact-share cases (skip-PoW, one block per DAA, W = 100 DAA, 8 blocks per second)
-
-| Case | Run (UK) | Harness line | What the chain did | Files |
-|---|---|---|---|---|
-| eighty-nine (first run, driver v1) | 09:48:00 to 09:54:27 | FAIL rc=1 on three harness faults (section 4.3); the chain's facts are those of the re-run | identical to the re-run below | `exact-89.log`, `.json` |
-| eighty-nine (re-run, driver v2) | 10:04:45 to 10:11:14 | PASS 19 of 19 | 2,701 blocks, linear; 2,418 up, 283 none (135 of them with both bits); weakest up 8,900 bps at every epoch 12 to 30 and NO step (19 epochs, "stands" on every node); epoch 31: weakest 9,000 exactly, step line on 3 of 3: `630 of 700 blue blocks up`, shares [9000 x 7], rung 1 (35 passes); epochs 32 to 42 at 9,000 with no step (cool-down: the oldest window begins 1,210 to 1,810, the step took effect at 1,860); epoch 43: rung 2 (53 passes), `630 of 700`; 44 and 45 cool-down; 0 disagreements between nodes at any poll; one sink 1dd776b4 at 2700/2700/2700; 2 step lines per node; 382 s | `exact-89b.log`, `.json`, `-n0.log` |
-| floor (driver v2) | 10:01:40 to 10:04:38 | PASS 19 of 19 | 1,201 blocks; 1,200 down, genesis none; from epoch 12 every window reads 10,000 bps down at rung 0; the rule stands on every node for epochs 12 to 20 ("down signalled at rung 0: the floor"); no step line on any node; one sink a52e6a71 at 1200/1200/1200 | `exact-floor.log`, `.json` |
-| down (first run, driver v1) | 09:54:27 to 10:01:40 | FAIL rc=1 on the same three harness faults | identical to the third run below, restarts included | `exact-down.log`, `.json`, `-n1.log`, `-n2.log` |
-| down (second run, driver v2) | 10:11:14 to 10:18:26 | FAIL rc=1 on one harness fault (the anchor comparison at the two boundary epochs 13 and 23, section 4.3); 17 comparable epochs equal; the step lines' own weakest equal the oracle | identical to the third run | `exact-downb.log`, `.json`, `-n{0,1,2}.log` |
-| down (third run, driver v3) | 10:19:13 to 10:26:25 | PASS 19 of 19 | 3,001 blocks, linear; 720 up, 2,053 down, 228 none (110 with both bits); epoch 12: rung 1 on 3 of 3 (`700 of 700 blue blocks up`, weakest up 10,000); epochs 13 to 23 cool-down (the oldest window begins 70 to 670, the step took effect at 720); epochs 24 to 35: weakest down 8,900 bps on every node, NO step down (12 epochs "stands"); epoch 36: weakest down 9,000 exactly, step line on 3 of 3: `0 of 700 blue blocks up, 630 down`, rung 0 (27 passes, from rung 1); epochs 37 to 47 cool-down; epochs 48 to 50: 9,000 down at rung 0, the rule stands (never below 0), no third step line; restarts: n2 at DAA 1,004 (1 step line before, 4 after), n1 at DAA 2,304 (2 before, 2 after), n2 at DAA 2,704 (3 before, 2 after), every line after a restart identical in epoch, rung, origin and weakest to the lines before; 0 disagreements; one sink 20c6b367 at 3000/3000/3000; step lines 2 / 4 / 5 per node; 425 s | `exact-downc.log`, `.json`, `-n{0,1,2}.log` |
-
-Per epoch, the down case as the nodes and the oracle saw it (from `exact-downc.json`; "rungs" = the first template of the
-epoch on n0 / n1 / n2; "weakest" = the decision's number from the step line where one exists, else the template's live
-sink tally, which equals the seed-anchored oracle at every epoch with no schedule boundary inside the windows):
-
-| Epoch | Seed DAA | Rungs n0/n1/n2 | Weakest up / down (bps) | Oracle rung | Oracle reason |
-|---|---|---|---|---|---|
-| 11 | 649 | 0/0/0 | partial | 0 | windows not full |
-| 12 | 709 | 1/1/1 | 10,000 / 0 | 1 | up: 700 of 700 |
-| 13 to 23 | 769 to 1,369 | 1/1/1 | mixed, under 9,000 both ways | 1 | cool-down (oldest window begins before 720) |
-| 24 to 35 | 1,429 to 2,089 | 1/1/1 | 0 / 8,900 | 1 | stands: 8,900 is under 9,000 |
-| 36 | 2,149 | 0/0/0 | 0 / 9,000 | 0 | down: 630 of 700 |
-| 37 to 47 | 2,209 to 2,809 | 0/0/0 | 0 / 9,000 | 0 | cool-down (oldest window begins before 2,160) |
-| 48 to 50 | 2,869 to 2,989 | 0/0/0 | 0 / 9,000 | 0 | down signalled at rung 0: the floor |
-
-And the eighty-nine case (`exact-89b.json`):
-
-| Epoch | Seed DAA | Rungs n0/n1/n2 | Weakest up (bps) | Oracle rung | Oracle reason |
-|---|---|---|---|---|---|
-| 12 to 30 | 709 to 1,789 | 0/0/0 | 8,900 | 0 | stands, 19 epochs |
-| 31 | 1,849 | 1/1/1 | 9,000 | 1 | up: 630 of 700 |
-| 32 to 42 | 1,909 to 2,509 | 1/1/1 | 9,000 | 1 | cool-down (oldest window begins 1,210 to 1,810, the step took effect at 1,860) |
-| 43 | 2,569 | 2/2/2 | 9,000 | 2 | up: 630 of 700 |
-| 44 to 45 | 2,629 to 2,689 | 2/2/2 | 9,000 | 2 | cool-down |
-
-### 4.3 Harness faults found and fixed on the way (the driver's, never the chain's)
-
-| Fault | Seen | Fix |
-|---|---|---|
-| `every_produced_block_on_every_node` compared `blockCount` with produced + 1; the node's `blockCount` excludes genesis | exact-89 first run, 09:54 UK | compare with produced (2,700 = 2,700) |
-| `zero_rejected_by_nodes` grepped `ban` and matched the finality parameter line `... ban 120 ...` | same run | the word dropped; the skip-PoW INFO line `PoW rejected ... by igneum-lottery-v2-bound` excluded by its own text |
-| `node_weakest_equals_oracle_weakest` compared the template's weakest with the seed-anchored oracle at every epoch; the template's number is the LIVE tally anchored at the sink (`consensus/mod.rs` `get_pow_epoch_info`, `tally_ladder(..., sink, ...)`), read at the epoch's first template, sink = seed + lead (10 DAA) | epoch 11 of exact-89 (49 of 59 at the sink against 39 of 49 at the seed); epochs 13 and 23 of the second down run (40 up in (679, 779] against 50 in (669, 769], the boundary at 720 inside both) | compared only at epochs with seven full windows and no schedule boundary inside the windows plus the lead; a new check compares the decision's own weakest (the step line) with the oracle at every stepped epoch, which passed in every run |
-
-The smoke run (`smoke.log`, 09:14 UK, 3 epochs) validated the template round trip (`submitBlock` reports
-`{"type":"success"}`, 180 blocks on 3 of 3 nodes at 8 per second).
-
-## 5. What the runs show against the gate
-
-| Gate clause | Shown by | Numbers |
-|---|---|---|
-| No step up without 90 percent over 7 windows | eighty-nine: 19 epochs at 8,900 bps in every window, rung 0 held on every node; the step came at the first epoch whose weakest read 9,000, 630 of 700 blue blocks | epochs 12 to 30 stand; 31 steps |
-| No step down without 90 percent over 7 windows | down: 12 cooled-down epochs at 8,900 bps down in every window, rung 1 held on every node; the step down came at the first epoch whose weakest down read 9,000, 630 of 700 | epochs 24 to 35 stand; 36 steps |
-| A step down needs the same cool-down | down: epochs 13 to 23 at rung 1 with the oldest window beginning before the step took effect: the rule stood although the up share had collapsed | 11 epochs |
-| Never below 0 | floor: 10,000 bps down at rung 0 for 9 epochs, no step line; down: 9,000 bps down at rung 0 for epochs 48 to 50 after the cool-down, no step line | 12 epochs across two runs |
-| Monotone: one rung per decision, seven windows between decisions | eighty-nine: rung 1 at 31, rung 2 not before 43 with 9,000 in every window throughout; down: rung 1 at 12, rung 0 at 36 | the cool-down held 11 epochs each time |
-| The decision computed once per seed block and reused | one or two step lines per process per stepped epoch (two when the first template and header processing walked concurrently), none afterwards | n0: 2 lines for 2 steps in every exact run |
-| A node restarted mid-window reaches the same decision | three restarts in the down case: every step line after a restart repeats the lines before it in epoch, rung, origin and weakest; the restarted node's template rung equals the others' at every epoch | n2 at 1,004 and 2,704, n1 at 2,304 |
-| Two nodes never disagree on the rung at the same height | 0 disagreements at every observation (every fifth block) and at every epoch's first template, in every run | 5 exact runs, 2 baseline runs |
-| Both bits = none | 135 and 110 both-bits blocks counted as none by the oracle and by the nodes (the shares matched) | eighty-nine, down |
-| The known-failed shape (a chip owner stepping down under 90 percent; a step registered under 90 percent) | did not occur; 8,900 held in both directions, floor rounding puts 8,999 below the line (unit test, `igneum.rs` 1161) | gate holds |
-
-## 6. Static reading of the rule (what the harness cannot show)
-
-Read in the fork at 1591ee1d before the runs. Each line is a property of the code as written, with the place.
-
-| Property | Where | Reading |
-|---|---|---|
-| Symmetry of the two directions | `igneum.rs` 676 to 686 | one closure `all(shares)` serves both bits; the up branch runs first, then `all(down) && previous.step > 0`; up and down cannot both reach 9,000 bps of one window's blocks, so the order never decides |
-| The cool-down is direction-free | `igneum.rs` 674 | `first_counted_daa < previous.since_daa` returns the previous state before either branch is read; a step down waits the same seven windows after a step up as a step up does after a step down |
-| Never below 0 | `igneum.rs` 681 | `previous.step > 0` guards the subtraction; a 100 percent down signal at rung 0 stands (the floor case below shows it on the chain) |
-| Never past an inadmissible rung | `igneum.rs` 679 | `ladder.admissible(previous.step + 1)`; rung 3 is `admissible: false` in the file, so from rung 2 a 100 percent up signal stands (unit test `latency_ladder_rule`, `igneum.rs` 1161) |
-| Floor rounding | `igneum.rs` 431 to 437 | `signal_share_bps` = floor(10,000 x signalling / total); 89 of 100 blue blocks is 8,900, 90 is 9,000; on a mainnet window of 86,400 blocks 77,759 up is 8,999 and 77,760 is 9,000 |
-| Both bits set | `igneum.rs` 639 to 645 | `version & 0xc000 == 0xc000` falls to `None`; a header cannot vote both ways and cannot vote twice |
-| Weakest of seven | `class_signal.rs` `SignalTally::weakest_bps` and the rule's `all` | the decision rests on the lowest of the seven windows; one bought window at 100 percent moves nothing (unit test "one bought day does not move it") |
-| The windows are the seed block's own past | `class_signal.rs` `tally_window_by` | the anchor and the mergeset blues of each selected-chain block walking down, bucketed by `daa_c - daa`, stopping once `daa_cur + merge_depth < window_start`; blocks above the seed are never counted, so the seven windows are fixed once the seed block is |
-| The memo is sound | `latency_ladder.rs` `step_of_epoch` | keyed by the seed block's hash; the decision is a function of that block's selected-chain past and of process-global constants installed from the file (ladder, activation, window), so two processes with the same file and the same chain compute the same value; the memo is never read across a param change because the params are fixed at start; cleared above 100,000 entries, then rebuilt by the walk |
-| Concurrent first computation | `latency_ladder.rs` `memo_get` / `memo_put` | the lock is not held across the walk, so two concurrent callers may both walk and both log the step line; both write the same value, so the chain's decision is unaffected (the runs below show one or two step lines per process for the same epoch, identical in content) |
-| A node without the history | `latency_ladder.rs` `step_of_epoch`, the two `warn!` returns | a node whose seed block's windows cannot be walked (synced from a pruning proof) decides RUNG 0 and logs "a ladder witness is owed". After a step up, such a node runs rung 0's program and refuses rung 1's blocks: a split between full-history nodes and proof-synced nodes. The design doc lists the witness as owed (section 9). This is not a fault of the step rule and the harness cannot reach it (every node here has the history); it is a precondition on activation: no network activates the ladder while any peer syncs from a proof without the witness. Routed to main in section 8 |
-
-Nothing in the reading admits a step under 9,000 bps in either direction, a step down under the cool-down, a step
-below rung 0, or a decision that depends on which node computes it or when.
-
-## 7. Consequences per tier
-
-The rule holds, so a step in either direction costs 90 percent of blue blocks in each of seven consecutive days, and
-the earliest second step is seven days after the first. What a WRONGFUL step would have done, had the rule admitted one
-under 90 percent, is the measured per-rung table of `docs/design/latency-ladder.md` section 8 (algorithm.md 5.3a rungs,
-igneum-build-1 verifier) read in each direction. Every row below is that table's number, not a new measurement.
-
-| Wrongful step | M5 Max (Apple tier) | RTX 5090 at 431 W | RTX 4070 at 160 W | RX 9070 XT | 8 / 12 / 16 GB cards, rigs, pools | Verifier (half-core) | f = 1 chip's per-joule edge over the 5090 |
-|---|---|---|---|---|---|---|---|
-| Up 0 to 1 (102,100 to 132,100 ops) under 90 percent | -3.3 points of rate, 0 W more | 0 | 0 | 0 | 0 (the shadow costs ALU, not memory; the dataset size is the schedule's, not the ladder's) | +0.2 ms | 2.1x to 1.7x at k = 1 (3.9x to 3.4x at k about 0.33) |
-| Up 1 to 2 (to 199,600) under 90 percent | -6 more points | -2.7 percent | +21 W | 0 | 0 | +0.5 ms | to 1.3x (2.8x) |
-| Up 2 to 3 (to 330,700): inadmissible, never entered | -21 percent | -35 percent (compute-bound at the cap) | -12 percent | +3.6 percent | 0 | +0.9 ms | 3.0x at k about 0.33 |
-| Down 2 to 1, 1 to 0 under 90 percent (the chip owner's step) | the Apple tier gets its 6 then 3.3 points back | +2.7 percent then 0 | -21 W then 0 | 0 | 0 | -0.5 then -0.2 ms | the chip regains 1.3x to 1.7x to 2.1x (2.8x to 3.4x to 3.9x): every rung down hands the stored-dataset chip back the edge the miners paid for |
-
-Reading per tier, with the rule as it stands:
-
-| Tier | What the result means |
-|---|---|
-| Home card, 8 / 12 / 16 / 24 GB, any vendor, any OS | A step up costs rate only on the Apple tier at rungs 1 and 2, and on NVIDIA from rung 2; no step happens unless 90 percent of blocks over seven days ask for it, so a minority that would lose rate cannot be moved by a bought day or a 89 percent week, and a chip owner under 90 percent cannot move the rung down to cheapen its core. A 90 percent majority can step the chain down one rung per week to the floor (rung 0 = class v4 as it ships), which is the design's floor and not a weakness of the rule: at 90 percent of blocks the owner already orders the chain |
-| Rig, pool user | The same; a pool signals per block through its node's `IGNEUM_LADDER_SIGNAL` (the app's toggle later), so a pool's share of blocks is its weight |
-| Verifier (the node, the proof) | Admissibility is a genesis flag per rung; rung 3 is never entered by any signal until a quiet re-measurement before genesis moves the flag (section 4 of the design doc); the memo keeps the per-template cost to one walk per seed block per process |
-| A node synced from a pruning proof | Decides rung 0 until the ladder witness lands (section 6, last row): the ladder must not activate on a network where such nodes exist before the witness. This is the one consequence the rule's text does not state and the spec line should |
-
-## 8. Verdict, and what goes to main
-
-PASS. No step without 90 percent of blue blocks in each of seven consecutive windows in either direction; a step down
-needs the same 90 percent and the same seven-window cool-down; the floor holds under 100 percent down; the decision is
-per seed block, memoised per process, recomputed identically after a restart, and never differs between nodes at the
-same epoch. The known-failed harness case fails, the known pass passes, and three new cases (89 percent up, 89 then 90
-percent down with restarts, the floor) pass on the chain and on the harness's own 19 checks. The step rule's text in
-spec 01 needs no change for the gate.
-
-To main, not findings against the gate:
-
-| Item | What | Proposed route |
-|---|---|---|
-| Stale commit string in the ladder lane's `igneumd` | the binary built 6 October 22:15Z from the fork at 1591ee1d carries 8dbb7a23 (its parent) and no 1591ee1d; the ladder code is in it | the commit-string-check class (CLAUDE.md, 6 October 2026); the ladder lane rebuilds with the two-step before any Devnet 2 crossing; nothing in this row depends on it |
-| Proof-synced nodes decide rung 0 until the witness lands | `processes::latency_ladder::step_of_epoch` returns rung 0 with a warning when the seed block's windows cannot be walked; after a step, such a node runs the wrong program and splits from full-history peers | a precondition line for the step rule's text in spec 01 when the ladder is adopted: "the ladder activates only once every node can walk the seven windows below every seed block, or carries the ladder witness in its pruning proof"; the design doc already lists the witness as owed (section 9); node lane |
-| Spec text for the ladder, when adopted (none in spec 01 today; the only ladder there is `epoch_len`'s) | the rule as run: 90 percent of blue blocks in each of 7 consecutive windows ending at the seed block, floor rounding, one rung per decision, the oldest window at or after the last step in either direction, never below rung 0, never into an inadmissible rung; the template's weakest is the live sink tally and the decision's is at the seed | the algorithm lane's spec line; this record is the test it cites |
-| Three harness faults in the F10 driver | section 4.3; all three were the driver's reading of the node, fixed in `ladder-exact.mjs` v3 | none owed; recorded so the firm does not repeat them |
-
-Blocked: nothing. Not run: a real-mining 89 percent case (three equal miners cannot cast it; the exact-share driver
-asks the rule the same question through the same submit path and the same consensus code).

docs/analysis/attack-pass/f2-mixer.md

@@ -1,214 +0,0 @@
-# Attack pass F2: the mixer's round margin
-
-Row F2 of `docs/plans/cryptanalysis.md` section 4.2 (branch `cryptanalysis`), fed into
-`docs/analysis/attack-pass-2026-10.md`. Run 7 October 2026, 09:00 to [FILL] UK, by the attack-pass sub-agent F2 on
-igneum-build-1 (cores 6-11 and 54-59, nice 10, the measure file held shared in chunks under 30 minutes).
-
-## 1. Target
-
-Commit `924288d1` (worktree `igneum-wt-attack`, branch `attack-pass`). The x8 mixer of `igneum-pow/src/memhard.rs`,
-`mixer` (lines 300 to 313): one application on 16 words of 32 bits is, per word, `(s[i] ^ (RC[i] + rk)) * MUL[i]`
-with `MUL[i]` odd, then one ChaCha-shaped double round: four column quarter rounds with rotations `ROT[0..3]`,
-four diagonal quarter rounds with `ROT[4..7]`. `ROT`, `MUL`, `RC` are drawn per day from the 64-bit SplitMix64 seed
-`K[0] | K[1] << 32` by `MixParams::with_shape` (lines 237 to 258). Under class v3 and v4 (`m = 8`) an item is 8
-dependent cache reads, each preceded by 8 applications with round keys `round_key(r * 8 + j)`, and 8 more after the
-last read: 72 applications per item (`derive_items_mask`, lines 517 to 550). The chip model prices one application
-at 128 hoisted operations and an item at 9,360 (`docs/analysis/chip-model-v3.md` 5.2).
-
-The days modelled: the genesis day `2026-10-03` (`ROT = 20 20 19 4 26 3 3 27`, as `proto-metal/MEMHARD.md` line 82
-states; the harness reads the same draw from the code) and two other days, `2026-10-04` (`ROT = 28 15 9 26 2 2 22
-8`) and `2027-03-01` (`ROT = 31 16 15 15 2 9 19 4`). Their full `MUL` and `RC` are in the box files
-`/srv/builds/igneum-wt-attack/target-attack-f2/params/<day>.real.txt`.
-
-Known-failed shape (the plan's row): a differential or linear trail, a rotational-XOR relation, or an algebraic fold
-that distinguishes or shortcuts more than 2 of the 8 applications between dependent reads. Gate: none beyond 2 of 8.
-
-## 2. Method
-
-Four searches and two checks, every one on the bit-level definition in `memhard.rs` (the harness calls
-`igneum_pow::memhard::mixer` itself; the SAT models consume one op list whose value evaluator is checked against
-the Rust output on 64 applications per day and variant, 9 files, all matching).
-
-| Piece | What it is | Exact or model |
-|---|---|---|
-| Differential, MSB family | XOR differences; at every multiply each word's difference is 0 or `0x80000000`. These are the only word transitions through an odd multiply with probability 1 (`(x ^ 2^31) * c = (x * c) ^ 2^31`; any other nonzero difference passes with probability at most 1/2, since its lowest active bit below the MSB leaves a carry to chance). Modular addition by Lipmaa-Moriai (exact per adder), XOR and rotation linear | exact family, trail probabilities exact per operation |
-| Differential, general | The same ARX model with every word difference allowed through the multiply: XOR difference to modular difference (each set bit below the MSB is a sign choice, 2^-1 each, exact), times `MUL` (exact, a circuit on the difference variables), modular back to XOR (a carry chain, one bit per position where the difference bit and the carry differ, exact), the two conversions taken as independent | Markov trail model; its per-word cost sits 1 to 2 bits above the sampled best transition (section 4.1), so it is a trail model, slightly pessimistic for the attacker |
-| Linear, low-bit family | Masks; at every multiply the output mask lies in bits 0 and 1, the only F2-linear output bits of an odd multiply (`(cx)_0 = x_0`, `(cx)_1 = x_1 ^ (c_1 & x_0)`). Modular addition by the exact carry-mask automaton (per bit a carry-mask bit; checked against brute force at n = 8 on 500 mask triples, max error 0) | exact family |
-| Linear, general | The same with the multiply as its shift-and-add decomposition (one adder per set bit of `MUL`, the low known-zero bits of a shifted copy transparent), each adder under the automaton | trail model; over-optimistic for the attacker (section 4.3) |
-| Rotational-XOR | Measured on the real code: for every rotation r in 1..31 and k = 1..4, the per-bit bias of `rot_r(M^k(x)) ^ M^k(rot_r(x))` over 2^20 states, the largest |z| of the 512 bits, and the count of exact rotational pairs; plus the word-level prologue `g(x) = (x ^ C) * MUL` alone: the most frequent value of `rot_r(g(x)) ^ g(rot_r(x))` over 2^20 inputs | measurement |
-| The fold | The identities a chip would need to pay less than k x 128 for k applications, each tested on 2^20 random inputs, plus the algebraic argument (section 4.5) | measurement and argument |
-
-Search: for each (model, day, k = 1..4) the weight bound W is probed upward (SAT means a trail of weight at most W
-exists, UNSAT means none does in the model), then narrowed to the minimum. A k-application trail restricted to one
-application is a valid 1-application trail, so every application is held to the proven k = 1 minimum of the same
-model (the Matsui floor in the tables). Solver CaDiCaL 1.9.5 through python-sat 1.9. Every trail found of
-measurable weight is measured on the real code before it counts: per application and as a chain, 2^20 to 2^28
-samples (`attack-f2 verify-diff` / `verify-lin`), with the multiply-layer word transitions counted exactly over all
-2^32 inputs (`verify-mults`). A trail that does not hold is blocked and the solver asked again at the same bound.
-Linear trails whose correlation cancels inside one adder's hull are caught first by the exact signed sum over the
-adder's carry masks.
-
-What "reaches k applications" means here, two readings: (a) the shortcut reading, the one with a cost consequence:
-a relation of probability 1 (weight 0) over k applications, which a chip could use to skip work; (b) the
-distinguisher reading: a trail of weight under 64 over k applications, the usual practical line. For the gate both
-are reported.
-
-## 3. Harness
-
-| Item | Path |
-|---|---|
-| Crate (ground truth: parameters, vectors, verification, RX, fold) | `tools/attack/f2-mixer/` (`Cargo.toml`, `src/main.rs`), `igneum-pow` by path, own `[workspace]` |
-| SAT models and the search | `tools/attack/f2-mixer/model.py` (`selftest`, `search`, `show`) |
-| Box queue runner, tables | `tools/attack/f2-mixer/run_jobs.sh`, `tools/attack/f2-mixer/summarise.py` |
-| Build line (from the crate directory) | `IGNEUM_AGENT=attack-f2 bash /Users/joshm/Projects/igneum/tools/build-remote.sh --artefacts "target/release/attack-f2" --out <scratch> -- build --release`; binary on the box `/srv/builds/igneum-wt-attack/tools/attack/f2-mixer/target/release/attack-f2` (ELF x86-64, sha256 `150337ec...`, the third build; 12 s incremental) |
-| Box scratch (states, trails, logs, venv) | `/srv/builds/igneum-wt-attack/target-attack-f2/` (`state/`, `logs/`, `params/`, `vectors/`, `venv/`). The brief's path `attack-f2/` was wiped within ten minutes by another lane's worktree-root rsync (`--delete` spares only `target-*`), so the scratch moved under a `target-` name, as F1 and F6 did |
-| Run lines | `venv/bin/python3 model.py selftest --vectors vectors --params-dir params`; `bash run_jobs.sh jobs.txt 11` (each job `model.py search --kind diff|lin --family msb|general|low2 --params params/<day>.<variant>.txt --apps k --state state/<name>.json --budget <chunk> --per-app-min <k=1 floor> --verifier <binary>` under `flock -s /srv/builds/_locks/measure`, `nice -n 10 taskset -c 6-11,54-59`); `attack-f2 rx --day D --variant V --apps 4 --log2 20`; `attack-f2 rx-word --day D --log2 20`; `attack-f2 fold --day D --log2 20` |
-| Logs | `logs/<model>-<day>-<variant>-k<k>.log` per search, `logs/rx.<day>.<variant>.log`, `logs/rx-word.<day>.<variant>.log`, `logs/fold.<day>.log`, `logs/summary.md` (the tables below), `logs/verify*.log` |
-
-## 4. Results
-
-### 4.1 The harness fires (known pass, known fail)
-
-| Case | Expected | Got | Log |
-|---|---|---|---|
-| Selftest: evaluator against `attack-f2 vectors`, 3 days x 3 variants, 4 applications x 16 states each | all match | 9 of 9 files, 64 of 64 applications each | `selftest` output, `logs/selftest.log` |
-| Selftest: linear add automaton against brute force, n = 8 | exact | 300 random triples and 200 shifted-copy triples, max error 0.00e+00 | same |
-| Selftest: Lipmaa-Moriai against brute force, n = 8; both SAT encodings against their rules at n = 32 | exact | max error 0; 0 mismatches of 40 and 40 | same |
-| Selftest: the multiply model's word cost against the sampled best transition (word 3, genesis day) | MSB exact; others within a few bits | MSB: weight 0, measured 2^-0 (exact); bit 30: model 2, sampled best 2^-1.00; bits 31+5: model 8, sampled best 2^-6.03; bit 0: model 10, sampled best 2^-8.97 | same |
-| Known pass, 0 applications | the identity trail, weight 0 | trivial (input = output, no weights); not run as a job | |
-| Known fail, `rot0` (every rotation 0), differential, k = 1, 2, 4 | a weight-0 trail (MSB-only differences stay MSB-only when nothing rotates) | weight 0 found at k = 1, 2, 4 (both families); measured probability 1 on the real code (`verified_chain -0.0`) | `state/diff-msb-2026-10-03-rot0-k{1,2,4}.json`, `state/diff-general-2026-10-03-rot0-k{1,2}.json` |
-| Known fail, `rot0`, linear, k = 1, 2, 4 | a weight-0 trail (LSB masks) | weight 0 at k = 1, 2, 4; measured correlation 1 per application and as a chain | `state/lin-low2-2026-10-03-rot0-k{1,2,4}.json`, `state/lin-general-2026-10-03-rot0-k{1,2}.json` |
-| Known fail, `nomul` (MUL 1, RC 0, rk 0: the bare double round), rotational-XOR, k = 1 | a large per-bit bias | max |z| 134.2 (r = 31) against 4.2 for the real mixer; word-level: the prologue is exactly rotational (2^20 of 2^20) against 3 of 2^20 | `logs/rx.2026-10-03.nomul.log`, `logs/rx-word.2026-10-03.nomul.log` |
-| Known fail, `rot0`, rotational-XOR | bias | max |z| 32.3 at k = 1, 9.0 at k = 2 | `logs/rx.2026-10-03.rot0.log` |
-| Known fail, `nomul`, differential k = 1 | the bare double round's best trail, below the real mixer's | weight 7 found (model), measured 2^-5.0 on the real code | `state/diff-general-2026-10-03-nomul-k1.json` |
-
-### 4.2 Differential trails
-
-| Model | Day | Variant | k | Best trail weight found | No trail at or below (model) | Closed | Per-application floor | Verified on the real code (chain; per application) | Solver s |
-|---|---|---|---|---|---|---|---|---|---|
-| diff/general | 2026-10-03 | real | 1 | 12 | 11 | yes | 0 | 12.011; [11.939] | 186 |
-| diff/general | 2026-10-03 | real | 2 | none | 24 | no (timebox) | 12 | | 1,739 |
-| diff/general | 2026-10-04 | real | 1 | 10 | 9 | yes | 0 | 10.001; [9.999] | 321 |
-| diff/general | 2026-10-04 | real | 2 | none | 20 | no (timebox) | 10 | | 663 |
-| diff/general | 2027-03-01 | real | 1 | 12 | 11 | yes | 0 | 12.057; [11.907] | 175 |
-| diff/msb | 2026-10-03 | real | 1 | 12 | 11 | yes | 0 | 12.206; [11.972] | 4 |
-| diff/msb | 2026-10-03 | real | 2, 3, 4 | none | 512 (the family dies) | yes | 12 | | 26, 33, 22 |
-| diff/msb | 2026-10-04 | real | 1 | 10 | 9 | yes | 0 | 10.001; [10.001] | 309 |
-| diff/msb | 2026-10-04 | real | 2, 3, 4 | none | 512 | yes | 10 | | 20, 33, 44 |
-| diff/msb | 2027-03-01 | real | 1 | 12 | 11 | yes | 0 | 12.057; [11.907] | 3 |
-| diff/msb | 2027-03-01 | real | 2, 3, 4 | none | 512 | yes | 12 | | 10, 15, 21 |
-| diff/general | 2026-10-03 | nomul (known fail) | 1 | 7 | 6 | yes | 0 | 5.002; [5.003] | 38 |
-| diff/general | 2026-10-03 | nomul | 2 | none | 20 | no | 7 | | 1,309 |
-| diff/general, diff/msb | 2026-10-03 | rot0 (known fail) | 1, 2, 4 | 0 | | yes | 0 | probability 1 | under 1 |
-
-The general model's k = 3 and k = 4 jobs (closed 14:3x UTC, every job at its 7,200 s cap, `logs/summary.md`):
-
-| Model | Day | k | Best trail found | No trail at or below (model) | Per-application floor | Solver s |
-|---|---|---|---|---|---|---|
-| diff/general | 2026-10-03 | 3 | none | 35 | 12 | 7,201 (cap) |
-| diff/general | 2026-10-03 | 4 | none | 47 | 12 | 7,359 (cap) |
-| diff/general | 2026-10-04 | 3 | none | 29 | 10 | 7,350 (cap) |
-| diff/general | 2026-10-04 | 4 | none | 39 | 10 | 7,279 (cap) |
-| diff/general | 2027-03-01 | 3 | none | 35 | 12 | 7,321 (cap) |
-| diff/general | 2027-03-01 | 4 | none | 47 | 12 | 7,284 (cap) |
-| lin/general | 2026-10-03 | 3 | none | 24 | 1 | 7,953 (cap) |
-| lin/general | 2026-10-03 | 4 | none | 24 | 1 | 7,352 (cap) |
-| lin/general | 2026-10-04 | 3 | none | 28 | 1 | 7,373 (cap) |
-| lin/general | 2026-10-04 | 4 | none | 24 | 1 | 7,393 (cap) |
-| lin/general | 2027-03-01 | 3 | none | 24 | 1 | 7,402 (cap) |
-
-No trail of weight under 32 at three applications (the finding line): the bound reached is 29 to 35 at three and
-39 to 47 at four for differentials, 24 to 28 at three and 24 at four for linear masks, all solver-capped, so these are
-effort bounds, not proofs; they grow with k as the per-application floors predict.
-
-### 4.3 Linear trails
-
-| Model | Day | Variant | k | Best trail weight found (correlation 2^-w) | No trail at or below | Closed | Verified (chain; per application) | Solver s |
-|---|---|---|---|---|---|---|---|---|
-| lin/general | 2026-10-03 | real | 1 | 1 | 0 | yes | 0.996; [0.997] | 5 |
-| lin/general | 2026-10-03 | real | 2 | none | 20 | no (timebox) | | 1,019 |
-| lin/general | 2026-10-04 | real | 1 | 1 | 0 | yes | 0.995; [0.999] | 5 |
-| lin/general | 2026-10-04 | real | 2 | none | 24 | no (timebox) | | 1,669 |
-| lin/general | 2027-03-01 | real | 1 | 1 | 0 | yes | 1.003; [0.996] | 5 |
-| lin/general | 2027-03-01 | real | 2 | none | 20 | no (timebox) | | 1,224 |
-| lin/low2 | 2026-10-03, 2026-10-04, 2027-03-01 | real | 1 | 1 | 0 | yes | 0.995 to 1.003 | 4 to 5 |
-| lin/low2 | 2027-03-01 | real | 2, 3, 4 | none | 512 (the family dies) | yes | | 12, 18, 27 |
-| lin/general | 2026-10-03 | nomul (known fail) | 1 | 1 | 0 | yes | 0.999; [1.003] | 4 |
-| lin/general, lin/low2 | 2026-10-03 | rot0 (known fail) | 1, 2, 4 | 0 | | yes | correlation 1 | 5 to 10 |
-
-One application carries a weight-1 linear trail (the LSB mask through the prologue and one add, correlation 1/2),
-the structural residue of 4.5; at two applications no trail at or below weight 20 to 24 exists in the general
-model within the timebox, and the LSB family dies (no trail at or below 512) from k = 2.
-
-### 4.4 Rotational-XOR
-
-Per k and day, the largest |z| over all 31 rotations and 512 bits at 2^20 states (15,872 bit tests per k; the
-noise ceiling of that many tests is about 4.3), and the count of exact rotational pairs.
-
-| Day | k = 1 | k = 2 | k = 3 | k = 4 | Exact pairs | Log |
-|---|---|---|---|---|---|---|
-| 2026-10-03 | 4.22 (r 19) | 4.29 (r 30) | 4.22 (r 3) | 4.62 (r 27) | 0 | `logs/rx.2026-10-03.real.log` |
-| 2026-10-04 | 4.35 (r 17) | 4.00 (r 19) | 4.24 (r 25) | 4.49 (r 28) | 0 | `logs/rx.2026-10-04.real.log` |
-| 2027-03-01 | 3.96 (r 7) | 4.07 (r 2) | 4.04 (r 28) | 4.17 (r 19) | 0 | `logs/rx.2027-03-01.real.log` |
-| 2026-10-03, bare double round (`nomul`) | 134.24 (r 31) | 4.37 | | | 0 | `logs/rx.2026-10-03.nomul.log` |
-
-The word-level prologue `(x ^ C) * MUL`: over 2^20 inputs the most frequent value of `rot_r(g(x)) ^ g(rot_r(x))`
-occurs at most 3 times for every word and every r on all three days (`logs/rx-word.<day>.real.log`, the
-`rxw_worst` lines), against 2^20 of 2^20 without the multiply. The odd multiply by a random constant is not
-rotational to any measurable degree, and one application already shows no per-bit bias. Rotational-XOR does not
-reach 1 application.
-
-### 4.5 The fold of the multiply layer
-
-One application is `D o P_rk`, with `P_rk(s)_i = (s_i ^ (RC_i + rk)) * MUL_i` and `D` the double round (fixed per
-day). Multiplication by an odd constant distributes over modular addition and over nothing else in `D` (XOR,
-rotation); the XOR with a constant commutes with XOR and rotation and with nothing else (addition, multiply). A fold
-across applications would need one of the identities below. Each was tested on 2^20 random inputs on every day
-(`logs/fold.<day>.log`):
-
-| Identity a chip would need | Holds on | Meaning |
-|---|---|---|
-| `(xa ^ Ca) * ma + (xb ^ Cb) * mb = ((xa ^ Ca) + (xb ^ Cb)) * ma` for the four column pairs (0,4), (1,5), (2,6), (3,7) | 0 of 1,048,576 for every pair on every day (`MUL` distinct in every pair) | the multiply does not fold into the first add of a quarter round; it would if a column pair drew the same `MUL` (probability 2^-31 per pair per day, the weak-day class of F4) |
-| `(x ^ C) * m = (x * m) ^ (C * m)`, or `= (x * m) ^ C'` for any single `C'` | 0 of 1,048,576; the best single `C'` agrees on 33 of 1,048,576 (2^-15) | the constant cannot be moved past the multiply, so application j + 1's prologue cannot share application j's multiply |
-| an XOR constant on one word commuting with the bare double round (so the next prologue's constant could be folded back) | 0 of 65,536 for every word | every word's value feeds an add inside the double round |
-| the MSB passing the prologue and the add for free; the LSB passing the prologue | 1,048,576 of 1,048,576 each | the structural residue: the only free passages, both moved by the rotations (the family deaths in 4.2 and 4.3) |
-
-So k applications cost k times one application, 128 hoisted operations each (16 multiplies, 32 adds, 32 XORs, 32
-rotations with the constants hoisted); `chip-model-v3.md` 5.2's 9,360 per item stands. The trail weights of 4.2
-and 4.3 growing with k is the quantitative side of the same fact: a composition that collapsed to one application's
-shape would keep one application's trail weights.
-
-## 5. Gate and verdict
-
-Gate (plan 4.2 F2, 1.4 (1)): no distinguisher or shortcut beyond 2 of the 8 applications between dependent reads,
-after the stated search.
-
-| Line of attack | Reach | Verdict |
-|---|---|---|
-| Differential, general model (Markov on the multiply, exact add rule, SAT) | one application: best trail weight 10 to 12 on three days, verified on the real code; two applications: no trail at or below weight 20 to 24 within 7,200 s per job (not closed); the MSB family dies at two applications on every day | nothing reaches 2 applications below 2^-20 |
-| Linear, general model (piling-up, SAT) | one application: weight 1 (the LSB residue); two applications: no trail at or below 20 to 24 within the timebox; the LSB family dies at two | nothing reaches 2 applications below 2^-20 |
-| Rotational-XOR | no per-bit bias at one application (max abs z 4.0 to 4.6 at 2^20 states, noise ceiling 4.3); 0 exact pairs; the multiply prologue is rotational on at most 3 of 2^20 inputs; the bare double round fires at 134 | does not reach 1 application |
-| Algebraic fold of the multiply layer | every identity a fold needs holds on 0 of 2^20 inputs on every day; k applications cost k | no shortcut |
-
-Verdict: PASS with the effort bound stated: about 60 solver jobs, 2 to 29 minutes each, on three day keys; the
-reduced-round margin reached is one application fully characterised (weights 10 to 12 differential, 1 linear) and
-two applications with no trail under weight 20 to 24, three with none under 29 to 35 (differential) and 24 to 28
-(linear), four with none under 39 to 47 and 24, against 8 applications between reads, so the margin between what the
-search reaches and what the construction uses is at least 4 applications at the solver's cap. What this does not do is in section 7; the lower bound is the paid question.
-
-## 6. Consequences per tier
-
-No shortcut, so no tier moves: a home card, a rig and a pool pay the 72 applications per item the verifier pays;
-a chip with a fixed datapath pays them too (the fold test), which is what `chip-model-v3.md` 5.2's 9,360 ops per
-item assumes. `mixer_mult` stays 8; the verifier measurement of F6 stands unchanged.
-
-## 7. What this does not do
-
-- It does not bound the mixer from below: the general models are trail models (Markov for the multiply's
-  differential, piling-up for the linear), and the family models are exact only inside their families. The firm's
-  job (funding.md B5 rank 1) is the effort-bounded version of the same search with their tools.
-- Three days, not a census: the ROT, MUL, RC classes over 2^24 days are F4's row. One cheap addition for F4 from
-  this harness: the MSB-family death at k = 2 (`model.py search --kind diff --family msb --apps 2`) runs in seconds
-  per day, and a day where it does not die is a weak day of the kind the gate is about.
-- Differential and linear only, as the row says: no boomerang, no integral or cube property, no related-key (the
-  round keys are public constants).

docs/analysis/attack-pass/f3-cache.md

@@ -1,148 +0,0 @@
-# F3: the chained cache's j + 1 bound and the storage-against-recompute curve
-
-Attack-pass row F3 of `docs/plans/cryptanalysis.md` section 4.2 (the record is `docs/analysis/attack-pass-2026-10.md`). Run 7 October 2026, 09:10 to 09:12 UK (08:10 to 08:12 UTC in the logs), on igneum-build-1. Verdict: PASS on all three gate clauses. No line (s, j) is derivable in fewer than j + 1 block evaluations without an earlier line, by an exhaustive search over the block dependency graph extracted from the code at 64 and 1,024 lines, cross-checked by an exhaustive pebbling search over every configuration at 10 lines. The storage-against-recompute curve over cache lines is monotone from f = 1/64 to 1. The f = 1 point is unchanged.
-
-## Target
-
-| Item | Value |
-|---|---|
-| Commit | 924288d1 (the brief); the worktree HEAD moved to 11b375a0 during the run; `igneum-pow/src/memhard.rs` is byte-identical at both (blob ad42470b, `git diff --stat 924288d1 HEAD -- igneum-pow/src/memhard.rs` empty) |
-| Construction, from the code | `Cache::fill_segment`: `in_j = prev XOR (sigma || K || seg || j || tag)`, `line_j = chacha_block(in_j)` where `chacha_block(x) = ChaCha12core(x) + x`, `prev_0 = 0`, `prev_j = line_{j-1}`; 64 lines per segment, 2^16 segments, 2^26 words (256 MiB) |
-| Reads | `derive_items_mask`: 8 dependent reads per item at line index `s[0] AND mask`, so the segment and j of a read are uniform over the 2^22 lines (F8 checks the uniformity) |
-| Known-failed shape | a line (s, j) computable in fewer than j + 1 block evaluations without an earlier line of segment s (the address-steering shape of the MTP break, Dinur and Nadler 2017, needs a data-dependent chain; this chain's inputs are fixed by the key, so the shape to search is a structural shortcut on the dependency graph) |
-| Gate | no derivation under j + 1 blocks; the curve monotone; the f = 1 point unchanged |
-| Prior evidence | none to re-gate: the `ca2-cache` branch named in the status board is the hot-table experiment (`docs/plans/hot-table.md`), not a chain analysis |
-
-## Method
-
-The model is the code, not the prose. `tools/attack/f3-cache/src/main.rs` runs one chain function, written in the shape of `memhard.rs` (the quarter round, the 6 double rounds, the feed-forward, the prev XOR, the constant block), generically over two word types:
-
-| Word type | What it computes | Use |
-|---|---|---|
-| `u32` | the real arithmetic | `verify`: bit-exact against `Cache::fill_segment` on 16 (key, segment) pairs and against `chacha_block` on 100,000 random inputs |
-| taint set | which block outputs a value depends on (add, xor, rotate = union) | `search`: the direct-parent graph of every block, with each computed line relabelled to the single node {j} so parents are direct, not transitive; plus the 16 x 16 (output word, input word) dependency matrix of one block |
-
-The exhaustive search: for every target line j, the minimum number of block evaluations with nothing stored is the size of the backward closure of j on the extracted graph (every non-stored block in the closure must be evaluated at least once; once each in dependency order suffices). `pebble` checks that formula against an exhaustive 0-1 BFS over every pebble configuration (place on a node whose parents are pebbled at cost 1, remove at cost 0) for all 2^10 stored sets x 10 targets on each of the three graphs: 10,240 pairs per graph, 0 mismatches. Two deliberately broken chains are the known-fail cases: `skip2` (line j fed from line j - 2) and `nofeed` (no previous line fed in). The curve: for f = 1/64 to 1 (fraction of cache LINES held), the blocks per read on the naive pattern of `funding.md` B2 rank 2 (every L/n-th line from line 0) and on the optimal pattern (exact DP over chunk lengths; brute force over every C(64, n) set for n up to 8, 4,426,165,368 sets at n = 8); ops per item = 9,360 mixer ops (chip-model-v3.md 5.2) + 8 reads x blocks per read x ops per block (608 counted from the code: 48 quarter rounds x 12, 16 feed-forward adds, 16 input XORs; also at MEMHARD.md's approximate 700). Three more checks on the real function: single-bit avalanche and a differential-independence test on `chacha_block`, a census of every line of the real 2^22-line cache for the day key 2026-10-03, and one-core timings of a block, a mixer application, an item and a line recompute.
-
-## Harness
-
-| Item | Value |
-|---|---|
-| Crate | `/Users/joshm/Projects/igneum-wt-attack/tools/attack/f3-cache/` (`Cargo.toml` with `igneum-pow = { path = "../../../igneum-pow" }` and an empty `[workspace]`; `src/main.rs`; `run-box.sh`) |
-| Build | `cd tools/attack/f3-cache && IGNEUM_AGENT=attack-f3 IGNEUM_TOOLCHAIN_MISMATCH=ok bash /Users/joshm/Projects/igneum/tools/build-remote.sh --artefacts "target/release/attack-f3" --out <scratchpad>/attack-f3 -- build --release` (rc 0, 38 s wall, 0 warnings; the Mac's PATH rustc is 1.69 but `~/.cargo/bin/rustc` is 1.99.0, which the script read as "on both sides"; log `<scratchpad>/attack-f3/build-1.log`) |
-| Binary | box `/srv/builds/igneum-wt-attack/tools/attack/f3-cache/target/release/attack-f3`, sha256 975115a385ca3195...71cc33, 563,104 bytes |
-| Run | on the box: `nohup bash run-box.sh r1 > run-r1.log 2>&1 &` from `/srv/builds/igneum-wt-attack/attack-f3/`; every phase as `flock -s /srv/builds/_locks/measure -c "nice -n 10 taskset -c 12-15,60-63 attack-f3 <cmd>"`, one chunk per phase, the whole run 17 s (08:10:58 to 08:11:15 UTC; box load 54 at start) |
-| Phase lines | `verify`; `search --lines 64|1024 --variant real|skip2|nofeed`; `pebble --lines 10`; `store --lines 64 --brute-max 8`; `store --lines 1024 --brute-max 2`; `curve --lines 64`; `curve --lines 64 --ops-block 700`; `curve --lines 1024`; `avalanche --samples 1048576`; `census --day 2026-10-03`; `bench --n 20000000` |
-| Logs | box `/srv/builds/igneum-wt-attack/attack-f3/run-r1.log` and `r1-<phase>.log`; Mac copies `/private/tmp/claude-501/-Users-joshm/cd75457f-4858-4f86-9634-7481ee056b7b/scratchpad/attack-f3/` |
-
-Box hygiene: the box checkout of every `build-remote.sh` run on this worktree executes `git clean -fd` at `/srv/builds/igneum-wt-attack` (remote-run.sh `checkout_tree`), which deletes any untracked scratch directory there. `attack-f3/` and `attack-f3-venv/` are listed in that mirror's `.git/info/exclude` so they survive; nothing in the tree was touched. The F1 lane's `attack-f1-venv/` is untracked and unprotected and will be removed by the next build from any agent on this worktree.
-
-## The two firings and the pass
-
-| Chain | Direct parents (taint trace) | Lines under j + 1 at 64 lines | Cheapest derivations | Exhaustive pebbling at 10 lines, cost per target | Verdict | Log |
-|---|---|---|---|---|---|---|
-| real (the code) | j - 1 for all 63 lines after line 0 | 0 of 64 | none; every line costs exactly j + 1 (mean 32.5) | 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 | PASS | `r1-search-real-64.log`, `r1-pebble-10.log` |
-| real, 1,024-line model | j - 1 for all 1,023 lines after line 0 | 0 of 1,024 | none (mean 512.5) | same graph rule | PASS | `r1-search-real-1024.log` |
-| skip2 (known fail A) | j - 2 for 62 lines, none for 2 | 63 of 64 | j = 1 in 1, j = 63 in 32 (mean 16.5) | 1, 1, 2, 2, 3, 3, 4, 4, 5, 5 | FIRE | `r1-search-skip2-64.log`, `r1-search-skip2-1024.log` |
-| nofeed (known fail B) | none for all 64 | 63 of 64 | every line in 1 block (mean 1.0) | 1 x 10 | FIRE | `r1-search-nofeed-64.log`, `r1-search-nofeed-1024.log` |
-
-`verify` (`r1-verify.log`): the model chain equals `Cache::fill_segment` on keys {day 2026-10-03, 3 random} x segments {0, 1, 12345, 65535} (16 of 16), `block == chacha_block` on 100,000 of 100,000 random inputs, the 1,024-line model's first 64 lines equal the 64-line chain, and both broken variants differ from the real chain from line 1 (line 0 equal, as the rule predicts). The block's word dependency matrix is full on every variant (256 of 256 pairs), so the firings come from the chain rule alone.
-
-## Derivation cost per line on the model segment (real chain, nothing stored)
-
-| j | blocks to derive line j | j + 1 | Log |
-|---|---|---|---|
-| 0 | 1 | 1 | `r1-search-real-1024.log` |
-| 1 | 2 | 2 | |
-| 3 | 4 | 4 | |
-| 7 | 8 | 8 | |
-| 15 | 16 | 16 | |
-| 31 | 32 | 32 | |
-| 63 | 64 | 64 | (the last line of a real segment; `r1-search-real-64.log` lists all 64) |
-| 127 | 128 | 128 | |
-| 255 | 256 | 256 | |
-| 511 | 512 | 512 | |
-| 1,023 | 1,024 | 1,024 | |
-
-All 1,024 lines were searched (0 under j + 1, mean 512.5 = (L + 1) / 2); the 64-line table in `r1-search-real-64.log` has every j from 0 to 63 at exactly j + 1.
-
-## Store patterns on the real 64-line segment
-
-Blocks per read averaged over j uniform in 0..63. "Naive" is `funding.md` B2 rank 2's pattern (every k-th line from line 0). "Optimal" is the exact minimum over store sets of that size (DP; brute force over every set for n up to 8, agreeing with the DP on every row it ran). The gap formula equals the closure cost on the extracted graph on 2,000 of 2,000 random stored sets (`r1-store-64.log`).
-
-| f | Stored lines n | SRAM held | Naive blocks per read | Optimal positions | Optimal blocks per read | Brute force over C(64, n) sets |
-|---|---|---|---|---|---|---|
-| 1/64 | 1 | 4 MiB | 31.5 | [32] | 16.0 | 16.0 (64 sets) |
-| 1/32 | 2 | 8 MiB | 15.5 | [21, 43] | 10.5 | 10.5 (2,016 sets) |
-| 1/16 | 4 | 16 MiB | 7.5 | [12, 25, 38, 51] | 6.094 | 6.094 (635,376 sets) |
-| 1/8 | 8 | 32 MiB | 3.5 | [7, 15, 22, 29, 36, 43, 50, 57] | 3.172 | 3.172 (4,426,165,368 sets, 11.2 s) |
-| 1/4 | 16 | 64 MiB | 1.5 | [3, 7, 11, ..., 55, 58, 61] | 1.453 | not run (DP exact) |
-| 1/2 | 32 | 128 MiB | 0.5 | odd lines | 0.5 | not run |
-| 1 | 64 | 256 MiB | 0 | all | 0 | not run |
-
-The 1,024-line model (`r1-store-1024.log`) gives 29.68 / 15.05 / 7.40 / 3.48 / 1.50 / 0.5 / 0 at the same f on the optimal pattern: the naive and optimal patterns converge as the chain lengthens, because the wasted stored line 0 and the end effects are a smaller share.
-
-## The curve: ops per item against the fraction of cache lines held (real 64-line segment)
-
-Ops per item = 9,360 (the 72 mixer applications, hoisted, plus the fold: chip-model-v3.md 5.2) + 8 reads x blocks per read x ops per block. `r1-curve-64.log` (608 ops per block, counted) and `r1-curve-64-memhard.log` (700, MEMHARD.md item 4). Ops per hash = 128 x ops per item + 512. MH/s at the chip model's 50 T op/s budget (approximate, chip-model-v3.md section 1).
-
-| f (lines held) | SRAM | Blocks per read, naive / optimal | Ops per item, naive, 608 | Ops per item, optimal, 608 | Ops per item, optimal, 700 | Ops per hash, optimal, 608 | MH/s at 50 T op/s, optimal, 608 |
-|---|---|---|---|---|---|---|---|
-| 1/64 | 4 MiB | 31.5 / 16.0 | 162,576 | 87,184 | 98,960 | 11,160,064 | 4.5 |
-| 1/32 | 8 MiB | 15.5 / 10.5 | 84,752 | 60,432 | 68,160 | 7,735,808 | 6.5 |
-| 1/16 | 16 MiB | 7.5 / 6.094 | 45,840 | 39,000 | 43,485 | 4,992,512 | 10.0 |
-| 1/8 | 32 MiB | 3.5 / 3.172 | 26,384 | 24,788 | 27,122 | 3,173,376 | 15.8 |
-| 1/4 | 64 MiB | 1.5 / 1.453 | 16,656 | 16,428 | 17,498 | 2,103,296 | 23.8 |
-| 1/2 | 128 MiB | 0.5 / 0.5 | 11,792 | 11,792 | 12,160 | 1,509,888 | 33.1 |
-| 1 | 256 MiB | 0 / 0 | 9,360 | 9,360 | 9,360 | 1,198,592 | 41.7 |
-
-Monotone: ops per item is non-increasing in f on both patterns at both op counts and on the 1,024-line model (`CURVE ... monotone non-increasing` in all three curve logs). The f = 1 point: 9,360 ops per item, 1,198,592 ops per hash, 41.7 MH/s at 50 T op/s, which is the chip-model-v3.md section 5.4 row "none, f = 0" of the published ITEM curve (the on-die-cache recompute chip of sections 1 to 3). The published item curve stores dataset ITEMS and is a different curve: its f = 1 point (GDDR7, 166.4 MH/s, 0.466 microjoules per hash) contains no cache read and no mixer op, so nothing in this row touches it. `funding.md` B2 rank 2's arithmetic reproduces on the naive pattern at 700 ops per block: 3.5 blocks per read, 2,450 ops per line, 19,600 per item on top of the mixer, 13.5 MH/s (50 T / (128 x 28,960 + 512)).
-
-## Measured times, one box core (`r1-bench.log`, `r1-census.log`; nice 10, cores 12-15,60-63, box load 54)
-
-| What | Measured | Note |
-|---|---|---|
-| One ChaCha12 block, dependent chain of 20,000,000 | 66.64 ns | |
-| One mixer application (class v4 parameters), dependent chain of 20,000,000 | 17.29 ns | block / application = 3.85 (counted ops 608 / 128 = 4.75) |
-| One item against the 256 MiB cache, batches of 32 | 1,326 ns | 72 applications = 1,245 ns; the 8 dependent reads and the fold add 81 ns because the batch overlaps them |
-| One line recomputed from nothing, 312,500 random (seg, j) | 2,734 ns | 32.5 blocks per line on average, 84.1 ns per block inside the chain |
-| The 256 MiB cache fill, one thread | 0.36 to 0.4 s | 86 ns per block with the writes |
-
-In measured time, holding every 8th line at the optimal placement makes an item cost 72 + 8 x 3.172 x 3.85 = 170 mixer-application equivalents against 72, a 2.36x penalty per item (2.65x in counted ops). Holding one line in 64 costs 72 + 8 x 16 x 3.85 = 565, a 7.8x penalty.
-
-## Checks on the real function (`r1-avalanche.log`, `r1-census.log`)
-
-| Check | Result |
-|---|---|
-| Single-bit avalanche of `chacha_block`, 1,048,576 flips | mean 256.00 of 512 output bits change (ideal 256), min 200, max 312 |
-| (output word, input word) pairs where an output word did not change | worst count 0 of 1,048,576 |
-| Chain step: one bit of line j - 1 flipped | line j changes 255.96 bits, line j + 1 changes 255.94 (131,072 flips) |
-| Differential independence: B(x ^ d) ^ B(x) == B(y ^ d) ^ B(y) over 262,144 (x, y, single-bit d) | 0 cases |
-| Census of the real cache, day key 2026-10-03 | 4,194,304 of 4,194,304 lines distinct, 0 all-zero lines: no two chains merge and no block input repeats |
-
-## Gate
-
-| Clause | Result | Where |
-|---|---|---|
-| No derivation under j + 1 blocks | 0 of 64 and 0 of 1,024 lines under j + 1 on the extracted graph; the formula exact on 10,240 of 10,240 exhaustive pebbling cases; both known-fail chains fire | `r1-search-real-64.log`, `r1-search-real-1024.log`, `r1-pebble-10.log` |
-| The curve monotone | non-increasing on both patterns, both op counts, both segment lengths | the three `r1-curve-*.log` |
-| The f = 1 point unchanged | 9,360 ops per item = chip-model-v3.md 5.4 "none, f = 0" row; the item curve's GDDR7 f = 1 row (166.4 MH/s, 0.466 microjoules) untouched | `r1-curve-64.log` |
-
-Verdict: PASS.
-
-## Observations that are not findings
-
-| Observation | Number | What it means | What I propose |
-|---|---|---|---|
-| `funding.md` B2 rank 2 prices the honest trade-off at the naive placement | 3.5 blocks per read at f = 1/8 against 3.17 optimal (9.4 percent less); 31.5 against 16.0 at f = 1/64 (2.0x less, because storing line 0 is worthless: it costs 1 block anyway) | the chip at f = 1/8 reads 15.8 MH/s (608 ops per block, optimal placement) or 14.4 (700, optimal) against `funding.md`'s 13.5 (700, naive); still 0.38x of the full SRAM mirror's 41.7 and 0.12x of the 5090's 136.1 (chip-model-v3.md section 2); the curve stays monotone, so the published verdict (the partial chip is not the threat, the full mirror beats it) stands | one sentence in `funding.md` B2 rank 2: "holding every 8th line at the best placement costs 3.2 blocks per read (3.5 for every 8th line from line 0)". Not edited here: outside this row's two files; for main to serialise |
-| The chain's hardness per line is sequential time, not memory | one pebble (64 bytes) over j + 1 steps: the cumulative memory of deriving a line is about 64 x (j + 1) byte-steps | the chain protects the cache by op count, which is exactly what the curve prices in ops; parallel attackers pipeline items and pay E(f) x 608 ops per read in throughput, E(f) block latencies in latency; a chip that holds nothing (f = 0) pays 32.5 x 608 = 19,760 ops per read, 158,080 per item, 167,440 with the mixer (17.9x the mixer alone), 2.3 MH/s at 50 T op/s | nothing to move; the public model should keep quoting ops, never bytes, for this piece |
-| What this row does not cover | a cryptanalytic shortcut inside `chacha_block` in this chaining mode (the differential and avalanche tests are sanity checks, not a bound) | the paid engagement's rank 2 question (`funding.md` B2) stays worth the money; plan 4.2 says the internal pass cannot prove the chain's trade-off curve | none |
-
-## Consequences per user tier
-
-| Tier | What this row changes |
-|---|---|
-| Home miner, one 8 / 12 / 16 / 24 or 32 GB card, any vendor, any OS | nothing: the honest miner holds the dataset, the verifier holds the 256 MiB cache; no memory, hash rate, or power figure moves |
-| Rig, pool user | nothing |
-| Chip builder | the partial-cache chip is priced 9 percent better at f = 1/8 and 2x better at f = 1/64 than `funding.md` says, and is still worse than the full SRAM mirror at every f below 1; the public per-joule sentence (evidence row 17, 2.1x at k = 1) rests on the item curve's f = 1 point, which this row leaves untouched |
-| The paid review | the firm receives this record and the harness; rank 2's open question is the block function in chaining mode, not the graph |

docs/analysis/attack-pass/f4-weakday.md

@@ -1,309 +0,0 @@
-# F4. The weak-day census: 2^24 day keys through `MixParams::with_shape`
-
-Attack pass row F4 (`docs/plans/cryptanalysis.md` section 4.2; the gate is section 1.4 (3) and `funding.md` B5
-rank 3; the threat is `funding.md` B2 rank 3). Run 7 October 2026, 09:10 to 09:55 UK, on igneum-build-1 by the
-attack-f4 agent (the verifier timing row of 6.6 queued behind other lanes' holds). Every number below cites its log.
-
-## Verdict
-
-**PASS on the gate read against M2, the DSP-bound per-day datapath (0 days over 1.1x in 2^28), and on every named
-weak class; the generous bound M1 (every multiply in LUT adders) exceeds the gate at 3.26e-4 of days as the tail of a
-sum, not a class, and is routed to main as a bound finding with a rejection-and-redraw rule for the next class.
-Class v4 is not changed.**
-
-Which metric the 1.1x gate reads against, and why: M2. The gate (plan 1.4 (3)) asks for the fraction of days in a
-weak class, and M1's excess has no class behind it (section 6.2: the exact 16-fold convolution of one random NAF
-weight predicts the census to 0.6 percent). A per-day FPGA attacker who builds the 16 multiplies in LUT shift-add
-trees is building the slower design: those trees are 72 percent of M1's cost (167 of 231 adders), and DSP blocks
-take that cost off the fabric, so the design that wins is DSP-bound, where the day's constants move nothing unless a
-word has NAF weight at most 3, which happens on no day in 2^28 for two words. M1 is still reported in full because
-the brief asks for the generous bound, and because a two-line rule closes it for nothing.
-
-| Metric | Days over 1.1x in 2^24 | Fraction | Days over 1.1x in 2^28 | Fraction | Gate 2^-20 = 9.54e-7 | Log |
-|---|---|---|---|---|---|---|
-| M1: per-day LUT datapath, adders per mixer application, against the census median | 5,476 | 3.264e-4 | 87,426 | 3.257e-4 | OVER, by 342x | `census-2p24.md`, `census-2p28.md` gate table |
-| M1 exact expectation (16-fold convolution of the NAF-weight table over all 2^31 odd constants) | 5,441 | 3.243e-4 | | | the census is the tail of a smooth sum, not a class | `expect-231.log` last line |
-| M2: DSP-bound datapath, 16/(16 - k), k = words of NAF weight at most 3 | 0 | 0 | 0 | 0 | under | `census-2p24.md`, `census-2p28.md` M2 table |
-| ROT value and RC value on a per-day datapath | 0 | 0 | 0 | 0 | under (exact 0 ops moved, section 3) | section 3 |
-
-The gate as written fails under M1 only. What M1 finds is not a weak class: the per-day cost of the 16 constant
-multipliers is a sum of 16 NAF weights (mean 231.1 adder-equivalents per application, sd 6.19), and 1 day in 3,070
-sits 3.4 sigma below the median, where a bitstream synthesised for that day pays 10 to 19 percent fewer adders. The
-worst day in 2^28 reads 1.19x (day 27,952,752, cost 194). The exact expectation predicts the census to 0.6 percent.
-Section 7 prices the consequence (0.004 percent more hashes a year for an all-LUT FPGA that re-synthesises every
-day, nothing for a chip or a GPU) and section 8 gives the rejection-and-redraw rule that closes it.
-
-## 1. Target
-
-| Item | Value |
-|---|---|
-| Commit | 924288d1 (the brief); the worktree HEAD moved to 11b375a0 during the pass (F5 and F6 records); `git diff 924288d1 11b375a0 --stat -- igneum-pow/src` is empty, so the target code is the same |
-| Code | `igneum-pow/src/memhard.rs` `MixParams::with_shape` (lines 189 to 215): `SplitMix64::new(key[0] as u64 \| (key[1] as u64) << 32)`, then `ROT[0..7] = 1 + below(31)`, `MUL[0..15] = next() as u32 \| 1`, `RC[0..15] = next() as u32`; no rejection rule |
-| Day key | `bind::day_bytes(d) = "igneum-day/" \|\| d_le64`, `key = seed_words_from_bytes(day_bytes)` (the interim day rule, `bind.rs` lines 30 to 68); the genesis day index is 20,729 (`bind.rs` test `day_bytes_layout`) |
-| Shape | `Shape::for_class(&V4_CLASS)`: mixer x8, cache 2^26 words, no derivation program (asserted by the harness) |
-| Mixer | `memhard::mixer`: per word `(s ^ (RC + rk)) * MUL`, then one ChaCha double round with `ROT[0..3]` on the columns and `ROT[4..7]` on the diagonals; 72 applications per item under x8 |
-| Census set | 2^24 consecutive chain days from 20,729 (the gate run), and 2^28 (the extended run); the first 36,525 of them are the chain's public calendar for the next 100 years under the interim rule |
-
-The 64-bit seeding fact (F7 covers the spec's intent): the 40 draws depend on `key[0] | key[1] << 32` alone, so the
-stream can produce at most 2^64 distinct parameter sets whatever the key's other 192 bits hold. Over the 2^24 census
-days the 64-bit seeds were all distinct (0 collisions, expected 7.6e-6; `census-2p24.md` "64-bit seeding" line).
-`below(31)` is `next() % 31` without rejection: the bias per rotation value is 2^-64 and is ignored.
-
-## 2. Known-failed shape
-
-A day key whose drawn `ROT`, `MUL` or `RC` gives a fixed datapath a gain over 1.1x: all-equal `ROT` (31^-7 per day,
-MEMHARD.md section 3 item 3, untested until now), `MUL = 1` (2^-31 per word), pairs summing to 32, small rotation
-amounts, low-weight multipliers, `RC + rk = 0`.
-
-## 3. The gain metrics (exact, structural)
-
-The verifier and every GPU run the same instructions on every day (`rotate_left` by a register amount, `wrapping_mul`,
-no branch on a drawn value), so wall time cannot move with the draw; the only attacker a weak day helps is one who
-builds the day's constants into logic. That is an FPGA bitstream synthesised per day (hours of compile against a
-public calendar), never a taped-out chip. Costs are in 32-bit adder-equivalents per mixer application:
-
-| Element of one application | Generic datapath | Per-day datapath |
-|---|---|---|
-| 16 x `s ^ (RC + rk)` | 16 | 0 (constant XOR: inverters, absorbed into the next LUT) |
-| 16 x `* MUL` | 16 multipliers (value-independent) | M1: `NAF(MUL_i) - 1` adders each (canonical signed-digit shift-add); M2: a DSP block each, value-independent, except a word of NAF weight at most 3 moves to 2 LUT adders and frees its DSP |
-| 8 quarter rounds: 32 adds, 32 XORs | 64 | 64 |
-| 32 rotations | 32 barrel shifters | 0 (wiring) |
-
-* **M1** `cost = 64 + sum_i (NAF(MUL_i) - 1)`; gain of a day = census median cost / the day's cost. The generous
-  bound: optimal single-constant multiplication is below NAF for every constant and the ratio between days is what
-  is measured.
-* **M2** gain = `16 / (16 - k)` on a DSP-bound design, k the words of NAF weight at most 3.
-* **ROT** and **RC** hand a per-day datapath exactly 0 ops at any value (wiring and inverters); on a generic
-  datapath a rotation costs the same at every amount and `RC + rk = 0` removes one XOR of 10,368 ops per item
-  (1.0001x). They are censused as structure, and the worst members are measured for diffusion (section 6), the
-  only other thing a rotation draw could move; a bit-exact verifier never lets a chip skip an application, so
-  diffusion is reported and is not a gain.
-
-## 4. Harness
-
-| Item | Path or line |
-|---|---|
-| Crate | `tools/attack/f4-weakday/` (`Cargo.toml` with `igneum-pow = { path = "../../../igneum-pow" }` and an empty `[workspace]`; `src/main.rs`); `igneum-pow` untouched |
-| Build | `cd tools/attack/f4-weakday && IGNEUM_AGENT=attack-f4 bash /Users/joshm/Projects/igneum/tools/build-remote.sh --artefacts "target/release/attack-f4" --out <scratch> -- build --release`; box binary `/srv/builds/igneum-wt-attack/tools/attack/f4-weakday/target/release/attack-f4`: sha256 `fda006d7...835f52` ran every census and firing (`build-1.log`); the rebuild `5eb081cf...7f0355` (`build-2.log`) removes one unused import and nothing else |
-| Unit tests | `build-remote.sh --no-fetch -- test --release` on the box (`test-1.log`): 2 passed, 0 failed (`naf_weights`: 0, 1, 3, 7, 2^32 - 1, the alternating maximum 17, and the planted weight-3 constant; `genesis_day_draw_matches_memhard_md`: the string day `2026-10-03` draws `ROT 20 20 19 4 26 3 3 27`, MEMHARD.md section 1.1, through the same `with_shape` path the census uses) |
-| Census (gate) | `flock -s /srv/builds/_locks/measure -c 'nice -n 10 taskset -c 16-21,64-69 attack-f4 census --from 20729 --count 16777216 --threads 12 --dedupe --out census-2p24.md'`; 4.2 s |
-| Census (extended) | the same with `--count 268435456 --out census-2p28.md`; 68.6 s |
-| Expectation tables | `attack-f4 expect --threads 12 --median 231` (every odd 32-bit constant: NAF weight and popcount, then the 16-fold convolution); 14.9 s |
-| One day | `attack-f4 day --index <d> --median 231` |
-| Firings | `attack-f4 plant alleq\|mul1\|mul1all\|mulnaf\|rc0\|rcrk0 --median 231` (the day 20,729 draw with one field forced through the crate's own hook) |
-| Diffusion | `attack-f4 avalanche --index <d> --states 2048 [--plant-alleq r]` |
-| Timing (exclusive hold) | `timing.sh` on the box under nohup: `flock -x -w 7200 /srv/builds/_locks/measure -c 'nice -n 19 taskset -c 16,64 igneum-pow bench --seed x --epoch-hex edc4fa84...fb07 --day-hex <day bytes> --program-class v4 --warps 100'` for day 20,729 and the worst day, A B A B. Process note: withdrawing the first attempt, one ad hoc ssh line used `pkill -f "<literal>"`, the banned shape, and killed its own shell (self-match); the relaunch used the bracket form. Nothing else was touched |
-| Calendar | `attack-f4 census --from 20729 --count 36525 --threads 12 --out census-100y.md` (the chain's first 100 years) |
-| Box logs | `/srv/builds/igneum-wt-attack/attack-f4/{run2.log, census-2p24.md, census-2p28.md, census-100y.md, expect-231.log, firings.log, avalanche.log, timing.log}` |
-| Mac copies | `/private/tmp/claude-501/-Users-joshm/cd75457f-4858-4f86-9634-7481ee056b7b/scratchpad/attack-f4/box/` (the box directory was deleted once from under the pass at about 09:14 UK by another agent's worktree sync; everything was re-run and copied to the Mac the moment it ended; the re-run reproduced the first run line for line) |
-
-## 5. The two firings (`firings.log`)
-
-| Case | Classifier | Gain | Result |
-|---|---|---|---|
-| Known-pass: day 20,729 (the genesis day), `ROT [6, 25, 5, 25, 29, 11, 9, 21]`, NAF sum 178 | no weak class (only "pair sums to 32", 12 and 60 percent of all days) | M1 0.978x, M2 1.000x | passes, as it must |
-| Known-fail: `plant mul1all` (all 16 `MUL = 1`) | `MUL any = 1` FIRED | M1 3.453x, M2 unbounded | FIRED over 1.1x |
-| Known-fail: `plant mulnaf` (four words at NAF weight 3) | `MUL any NAF weight <= 3` FIRED | M1 1.145x, M2 1.333x | FIRED over 1.1x |
-| `plant mul1` (one word `MUL = 1`) | `MUL any = 1` FIRED | M1 1.023x, M2 1.067x | flagged, under the gate: one word of 16 |
-| `plant alleq` (`ROT` all 7) | `ROT all equal` FIRED | M1 0.978x (0 ops moved) | flagged; diffusion in section 6 |
-| `plant rc0`, `plant rcrk0` | `RC any = 0`, `RC + rk = 0` FIRED | M1 0.978x (0 ops moved) | flagged |
-
-## 6. Numbers
-
-### 6.1 Classes over 2^24 days (`census-2p24.md`), with the 2^28 count (`census-2p28.md`)
-
-Expected per day is analytic (independent draws); the NAF rows come from the exact table of `expect-231.log`.
-
-| Class | Count 2^24 | Fraction | Expected per day | Expected count 2^24 | Count 2^28 | Worst member (day, M1 cost, M1 gain, M2 gain) |
-|---|---|---|---|---|---|---|
-| ROT all equal | 0 | 0 | 3.64e-11 (31^-7) | 0.001 | 0 | none |
-| ROT distinct <= 3 | 534 | 3.18e-5 | 3.07e-5 | 515 | 8,229 | 2^28: day 49,986,853, 206, 1.121x, 1.000x |
-| ROT distinct <= 4 | 26,010 | 1.55e-3 | 1.54e-3 | 25,783 | 412,698 | 2^28: day 208,103,482, 197, 1.173x, 1.000x |
-| ROT max multiplicity >= 4 | 35,631 | 2.12e-3 | 2.35e-3 (first order) | 39,421 | 568,423 | 2^28: day 115,569,197, 200, 1.155x, 1.000x |
-| ROT same-word pair sums to 32 | 2,062,481 | 0.1229 | 0.1229 | 2,062,288 | 32,997,484 | 2^28: day 97,502,921, 196, 1.179x, 1.000x |
-| ROT any pair sums to 32 | 10,022,037 | 0.5974 | 0.6007 (approx., pairs not independent) | 10,078,561 | 160,353,891 | 2^28: day 27,952,752, 194, 1.191x, 1.000x |
-| ROT all 8 in {1, 2, 30, 31} | 2 | 1.19e-7 | 7.68e-8 | 1.29 | 19 | day 14,330,190, 217, 1.064x, 1.000x |
-| ROT >= 6 in {1, 2, 30, 31} | 1,761 | 1.05e-4 | 1.02e-4 | 1,716 | 27,651 | 2^28: day 181,528,254, 204, 1.132x, 1.000x |
-| ROT >= 4 in {8, 16, 24} | 74,541 | 4.44e-3 | 4.46e-3 | 74,756 | 1,196,376 | day 5,517,722, 198, 1.167x, 1.000x |
-| MUL any = 1 | 0 | 0 | 7.45e-9 | 0.125 | 4 | 2^28: day 196,441,106, 221, 1.045x, 1.067x |
-| MUL any = 2^32 - 1 | 0 | 0 | 7.45e-9 | 0.125 | 1 | 2^28: day 39,988,645, 215, 1.074x, 1.067x |
-| MUL any popcount <= 2 | 0 | 0 | 2.38e-7 | 4.0 | 57 | 2^28: day 218,029,468, 209, 1.105x, 1.067x |
-| MUL any popcount <= 4 | 612 | 3.65e-5 | 3.72e-5 | 624 | 10,132 | day 7,275,755, 200, 1.155x, 1.000x |
-| MUL any NAF weight <= 2 | 4 | 2.38e-7 | 4.62e-7 | 7.75 | 125 | 2^28: day 63,704,833, 205, 1.127x, 1.067x |
-| MUL any NAF weight <= 3 | 216 | 1.29e-5 | 1.30e-5 | 218 | 3,515 | 2^28: day 247,161,685, 200, 1.155x, 1.067x |
-| MUL any NAF weight <= 4 | 3,637 | 2.17e-4 | 2.20e-4 | 3,683 | 58,667 | 2^28: day 81,133,010, 198, 1.167x, 1.000x |
-| MUL any < 256 | 22 | 1.31e-6 | 9.54e-7 | 16 | 262 | 2^28: day 241,187,962, 203, 1.138x, 1.067x |
-| MUL two equal | 0 | 0 | 5.59e-8 | 0.94 | 18 | 2^28: day 223,900,428, 226, 1.022x, 1.000x |
-| MUL M2 k >= 2 (gain >= 1.143x) | 0 | 0 | 7.9e-11 (C(16,2) x (8.12e-7)^2, approx.) | 0.0013 | 0 | none |
-| RC any = 0 | 0 | 0 | 3.73e-9 | 0.062 | 1 | 2^28: day 109,542,046, 243, 0.951x, 1.000x |
-| RC any popcount <= 4 or >= 28 | 5,186 | 3.09e-4 | 3.09e-4 | 5,180 | 82,804 | 2^28: day 53,303,116, 206, 1.121x, 1.000x |
-| RC + rk = 0 for any of the 72 keys | 10 | 5.96e-7 | 2.68e-7 | 4.5 | 87 | day 3,194,363, 218, 1.060x, 1.000x |
-| RC two equal | 1 | 5.96e-8 | 2.79e-8 | 0.47 | 8 | 2^28: day 182,857,055, 222, 1.040x, 1.000x |
-
-Every class sits at its expectation (the largest deviation, "ROT max multiplicity >= 4", is against a first-order
-bound). The worst member of every class owes its gain to its MUL draw (M1 is a MUL-only quantity); the class itself
-moves nothing. No day in 2^28 has two words of NAF weight at most 3, so M2 never exceeds 1.067x.
-
-### 6.2 The M1 tail: census against the exact expectation (`census-2p24.md`, `expect-231.log`)
-
-| M1 cost per application | Gain vs median 231 | Days in 2^24 | Cumulative fraction, census | Cumulative fraction, exact |
-|---|---|---|---|---|
-| 197 (the 2^24 minimum, day 4,819,563) | 1.173x | 1 | 5.96e-8 | 8.18e-8 |
-| 200 | 1.155x | 10 | 8.34e-7 | 8.62e-7 |
-| 205 | 1.127x | 250 | 2.94e-5 | 2.87e-5 |
-| 208 | 1.111x | 1,382 | 1.84e-4 | 1.83e-4 |
-| 209 | 1.105x | 2,387 | 3.26e-4 | 3.24e-4 |
-| 210 | 1.100x | 3,887 | 5.58e-4 | 5.64e-4 |
-| 231 (median) | 1.000x | 1,079,174 | 0.522 | 0.522 |
-
-Mean cost 231.113 (exact 231.111), sd 6.190 (exact 6.190). The 2^28 minimum is 194 (1.191x, day 27,952,752). A
-single NAF weight has mean 11.44 and sd 1.55 over the 2^31 odd constants (`expect-231.log`).
-
-### 6.3 ROT structure (`census-2p24.md` histograms)
-
-| Distinct rotation amounts a chip must wire | Days in 2^24 | Fraction | Expected S(8,d) 31_d / 31^8 |
-|---|---|---|---|
-| 1 | 0 | 0 | 3.63e-11 |
-| 2 | 4 | 2.4e-7 | 1.4e-7 |
-| 3 | 530 | 3.16e-5 | 3.05e-5 |
-| 4 | 25,476 | 1.52e-3 | 1.51e-3 |
-| 5 | 421,405 | 0.0251 | 0.0251 |
-| 6 | 2,773,843 | 0.1653 | 0.1653 |
-| 7 | 7,302,781 | 0.4353 | 0.4351 |
-| 8 | 6,253,177 | 0.3727 | 0.3729 |
-
-Small amounts {1, 2, 30, 31} and byte-aligned amounts {8, 16, 24} follow Binomial(8, 4/31) and Binomial(8, 3/31) to
-within 3 percent in every bin.
-
-### 6.4 Diffusion of the worst members (`avalanche.log`: 2,048 states x 512 input bits, mean and minimum per-output-bit flip probability)
-
-| Day | Why | ROT | After 1 application, mean / min | After 2, mean / min |
-|---|---|---|---|---|
-| 20,729 | genesis, same-word pair 11 + 21 = 32 | 6 25 5 25 29 11 9 21 | 0.461 / 0.383 | 0.500 / 0.498 |
-| 4,819,563 | M1 worst in 2^24 | 26 18 8 30 24 24 6 9 | 0.467 / 0.426 | 0.500 / 0.499 |
-| 27,952,752 | M1 worst in 2^28 | 11 26 11 7 6 20 20 3 | 0.460 / 0.392 | 0.500 / 0.498 |
-| 11,482,247 | 3 distinct amounts, multiplicity 5 | 12 19 19 4 19 12 19 19 | 0.453 / 0.374 | 0.500 / 0.499 |
-| 14,330,190 | all 8 amounts in {1, 2, 30, 31} | 1 1 2 31 1 31 1 31 | 0.331 / 0.196 | 0.4995 / 0.497 |
-| 332,924 | NAF weight 3 word, three amounts of 1 | 1 23 1 1 12 11 16 18 | 0.458 / 0.370 | 0.500 / 0.498 |
-| 196,441,106 | `MUL = 1` word (2^28) | 30 24 23 5 11 28 12 9 | 0.461 / 0.364 | 0.500 / 0.499 |
-| 109,542,046 | `RC = 0` word (2^28) | 28 5 4 31 25 28 12 4 | 0.459 / 0.348 | 0.500 / 0.499 |
-| planted all 1 | the worst all-equal draw | 1 x 8 | 0.345 / 0.216 | 0.500 / 0.499 |
-| planted all 16 | half-word swaps | 16 x 8 | 0.387 / 0.312 | 0.500 / 0.499 |
-| planted all 7 | | 7 x 8 | 0.464 / 0.400 | 0.500 / 0.498 |
-
-The slowest draw that can exist (all rotations by 1, probability 31^-8 per day) reaches full avalanche after 2 of the
-8 applications between cache reads; the worst real day in 2^28 (all amounts in {1, 2, 30, 31}) the same. No draw
-gives an attacker a shorter dependency between reads than the round margin F2 measures.
-
-### 6.5 The chain's first 100 years (`census-100y.md`: days 20,729 to 57,253 under the interim day rule)
-
-| Item | Value |
-|---|---|
-| Days over 1.1x under M1 | 6 of 36,525 (1.64e-4; the 2^24 rate predicts 12) |
-| First such day | 22,633 (genesis + 1,904 days, about 5.2 years in), cost 208, 1.111x |
-| Worst day | 29,337 (genesis + 8,608 days, about 23.6 years in), cost 206, 1.121x |
-| Days at exactly 1.100x (cost 210) | 6 more: 25,605; 28,102; 31,573; 33,710; 42,573; 54,884 |
-| M2 k >= 2 | 0 |
-| Genesis day 20,729 | cost 226, 0.978x; the next four devnet days (20,730 to 20,733) read 0.987x, 1.036x, 0.947x, 0.979x |
-| Rotation structure | 1 day with 2 distinct amounts (57,146, genesis + 36,417, cost 225, 1.027x), 46 with 4, none with 3 or fewer otherwise; no day with a `MUL` of NAF weight under 4 |
-
-### 6.6 Verifier time (exclusive hold, `timing.log`)
-
-A confirmation row only: the verifier's code path is value-independent, so the exact metric is the op count above
-and a wall-time difference between days can only be noise. Queued on the box at 09:47 UK (`timing.sh`, nohup, an
-exclusive `flock -x -w 7200` behind the shared holds of F1, F2, F8, F9, F10 and F7 and the queued exclusive hold of
-F6; the first attempt, queued 09:14 UK, was attached to a Mac ssh session and was withdrawn in favour of the nohup
-job). Cores 16 and 64, nice 19, `--warps 100`, day 20,729 against day 4,819,563 (the 2^24 M1 worst), A B A B.
-
-| Day | Cold warp 0 (ms) | Average per warp, 100 warps (ms) |
-|---|---|---|
-| 20,729 (genesis) | pending (`timing.log`) | pending |
-| 4,819,563 (M1 worst, 1.173x) | pending (`timing.log`) | pending |
-
-The verdict does not rest on this row.
-
-### 6.7 The worst days in full (`worst-days.log`, `export-29337.log`)
-
-The worst day in adders per application against the census median, in each set. M1 is the sum of the 16 NAF weights
-less 16 plus 64. Every one is an ordinary draw whose 16 weights happen to sum low; none has a word under NAF weight 7.
-
-| Set | Chain day | Years after genesis | ROT | MUL words (hex) | NAF weights | M1 cost | Gain vs median 231 | M2 |
-|---|---|---|---|---|---|---|---|---|
-| The public calendar, first 36,525 days (what an auditor runs) | 29,337 | 23.6 | 24 12 18 11 14 26 29 21 | 3fe4d03b 227c2043 06011627 40c10137 00234d99 063071d9 91e5abb7 035240b1 f40bfe47 809251b9 1ce999ef 940b381d da13a021 f75f8ba7 3f59bca7 01310e05 | 9 8 9 8 10 10 12 10 9 10 12 11 10 11 11 8 (sum 158) | 206 | 1.121x | 1.000x |
-| 2^24 (the gate census) | 4,819,563 | 13,139 | 26 18 8 30 24 24 6 9 | a0653c83 a09de525 810085fb 6a00eba1 bf8205ff bba82079 f27da4c3 2cb80223 6001efcf 1c2814f7 ae9d09d7 ffedd7b7 943dde01 39ff47e1 0513a83f c028eef9 | 11 11 7 10 7 10 12 10 7 9 13 8 8 8 9 9 (sum 149) | 197 | 1.173x | 1.000x |
-| 2^28 (extended) | 27,952,752 | 76,481 | 11 26 11 7 6 20 20 3 | f15eb273 227a08f1 20f822e1 6d477779 8d9b3aff 03040503 27fff521 bfd9ce7d 7708000d 5d60ba11 2d40005b f07e10d7 1deefdb1 4881e821 01e1fc71 3ee7c39b | 13 9 8 11 11 7 7 11 7 11 9 9 8 8 7 10 (sum 146) | 194 | 1.191x | 1.000x |
-
-Reproduction, through the harness: `attack-f4 day --index 29337 --median 231` (and 4819563, 27952752). Through
-`igneum-pow` itself, with the day bytes `"igneum-day/" || d_le64` as hex (day 29,337 = 0x7299):
-`igneum-pow export --seed x --epoch-hex edc4fa844da9dc98d37e965176f6558a31560e40502ab3ae5491b21aaaabfb07 --day-hex 69676e65756d2d6461792f9972000000000000 --program-class v4 --out <dir>`
-writes the day's constants into the pack's `memhard.h` as `IGNEUM_MIX_ROT_INIT` and `IGNEUM_MIX_MUL_INIT`; run on the
-box at 09:52 UK (`export-29337.log`, OVERALL PASS, cache FNV-1a 64 `1979492fb76b52ce`), the pack's 8 rotations and
-16 multipliers equal the harness's word for word. The day-hex strings of the other two days are in section 6.2's
-source list (`census-2p24.md` and `census-2p28.md`, "The 16 lowest-cost days"): `...2f6b8a490000000000` and
-`...2f7086aa0100000000`.
-
-## 7. Gate line and consequences
-
-Gate (plan 1.4 (3)): the fraction of days with any gain over 1.1x under 2^-20.
-
-| Model | Fraction over 1.1x | Gate | What the number means per tier |
-|---|---|---|---|
-| M1 (per-day LUT bitstream) | 3.26e-4 (1 day in 3,070; 2^24 and 2^28 agree; exact expectation 3.24e-4) | FAIL by 342x | An FPGA farm that re-synthesises its bitstream every day gains 10 to 19 percent on those days: 3.26e-4 x about 0.12 = 4e-5 of a year's hashes, 0.004 percent. The FPGA lane is already behind every GPU tier on reads per watt (F5: 10 to 20 M reads/s/W against the gate's 27 M), so no home miner (8, 12, 16, 24 or 32 GB), rig or pool on any vendor or OS sees a competitor appear, and no day's difficulty moves by a measurable amount |
-| M2 (DSP-bound FPGA) | 0 in 2^28 | PASS | nothing moves for any tier |
-| Chip (programmable constants, the chip-model-v3 recompute chip) | 0 by construction | PASS | nothing moves; a taped-out chip cannot specialise per day |
-| GPU and the CPU verifier | 0 by construction | PASS | every tier pays the same ops on every day |
-
-What the worst day buys, priced for the per-day LUT datapath (the M1 attacker) on the worst calendar day, 29,337:
-
-| Item | Value | Source |
-|---|---|---|
-| Fewer adders per mixer application that day | 231 to 206, 10.8 percent fewer | section 6.7 |
-| Item derivations per unit of fabric that day | 1.121x (M1 gain) | section 6.7 |
-| Hash rate of a recompute FPGA (items derived per hash, the `chip-model-v3` ops-per-hash attacker) that day | up to 12.1 percent above its ordinary day, an upper bound: the 128 dependent cache reads per hash and the shadow block are untouched by the draw, so the whole-hash gain is below the mixer's | `chip-model-v3.md` section 1 (ops per hash = 128 x 72 x 130); section 3 |
-| Hash rate of the stored-dataset (f = 1) FPGA or chip that day | 0 (it derives no items per hash; the mixer is paid once in the daily build) | `funding.md` B2 rank 2 |
-| Days a century at or over 1.1x | 12 (6 over, 6 at exactly 1.100x) | section 6.5 |
-| Share of a century's hashes the M1 attacker gains | 12 / 36,525 x about 0.11 = 3.6e-5, 0.004 percent | arithmetic on the rows above |
-| What one bitstream a day costs | one place-and-route of a large part: 42 to 160 minutes on a mid-size part (PRflow, FPT 2019, cited in spec 01 section 1.13), hours on a large one; on a rented 96-thread box (Hetzner AX162 class, about USD 0.35 per hour, approximate) under USD 3 per bitstream (approximate), and it compiles any time ahead because the calendar is public | spec 01 section 1.13; price approximate |
-
-So the bitstream is cheap and the gain is 0.004 percent of a century for the slower of the two FPGA designs: nothing
-a home miner on any card, a rig or a pool on any vendor or OS can see, and nothing that moves a day's difficulty.
-
-What is being done about the M1 line: class v4 is not changed (it is the object on the live devnet's vote). The
-rejection-and-redraw rule of section 8 is proposed to main for the next class, unless main reads the census as a
-fault beyond the metric (this row does not: every class sits at its expectation and the worst day is an ordinary
-draw). The rule costs one redraw on 5.6e-4 of days, changes no existing vector (day 20,729 has NAF sum 178; the first
-day the rule would redraw is 22,633, about 5.2 years after genesis, section 6.5), and makes the M1 gate pass by
-construction. `igneum-pow` is untouched by this row.
-
-## 8. Proposed fix for the next class: a rejection-and-redraw rule on the MUL draw (for main's decision)
-
-Shape, like the program acceptance rule 1.4.6 and `DeriveProgram::check`: draw the 16 `MUL`, test, and on rejection
-continue the same stream with 16 fresh draws (so every later draw keeps its position only within an accepted block;
-`RC` is drawn after the accepted `MUL` block). Tests, in order:
-
-| Rule | Threshold | Rejection probability per candidate | What it closes |
-|---|---|---|---|
-| Sum of NAF weights of the 16 `MUL` at least 163 (M1 cost at least 211, gain at most 1.095x against the median 231) | `sum_i NAF(MUL_i) >= 163` | 5.64e-4 (`expect-231.log` cumulative at cost 210) | the M1 tail: no day over 1.1x by construction |
-| Every `MUL` of NAF weight at least 4 | `NAF(MUL_i) >= 4` | 1.30e-5 per day | `MUL = 1`, `2^32 - 1`, `2^a +- 1`, `2^a +- 2^b +- 1`: the M2 words (hygiene; M2 already passes) |
-| `ROT`: at least 4 distinct amounts (the `DISTINCT_ROTS_FLOOR` idea of `derive.rs`) | `distinct >= 4` | 3.07e-5 per day | the degenerate rotation draws (hygiene; 0 ops moved, diffusion fine at 2 applications) |
-
-Total rejection about 6.1e-4 per day: one redraw every 4.5 years of chain time; `MAX_ATTEMPTS`-style exhaustion is
-impossible in practice (64 rejections in a row at 6e-4 each). Class check to land with it: a unit test in `memhard.rs`
-that plants a low-sum draw (stream seed chosen so the first MUL block fails) and asserts the redraw, plus this
-harness re-run over 2^24 showing 0 days over 1.1x under M1 after the rule. The reproduction line for the finding
-without the rule: `attack-f4 day --index 4819563 --median 231` (cost 197, 1.173x) and
-`attack-f4 day --index 27952752 --median 231` (cost 194, 1.191x).
-
-Consensus consequence: the rule changes the day-key-to-constants map on rejected days only, so it must land before the
-freeze tag. In the chain's first 100 years the sum rule redraws 12 days (6 under 1.1x and 6 at exactly 1.100x,
-section 6.5), the first of them 22,633, about 5.2 years after genesis; no pack cut for the devnet, the testnet or the
-first five years of mainnet changes. The per-word rule redraws no day in the first 100 years (no word of NAF weight
-under 4 in `census-100y.md`); the `ROT` rule redraws one, day 57,146 (2 distinct amounts, 99.7 years in).
-
-## 9. What this row did not do
-
-* It did not time the verifier per day beyond the confirmation row of 6.6: the verifier's code path is
-  value-independent (no branch on a drawn value), so op counts are the exact metric.
-* It did not search optimal single-constant multiplication costs (not computable at 2^28 scale); NAF is the standard
-  canonical bound and the ratio between days is what the gate asks.
-* It did not census the era draw (F7) or the spec's intent for the 64-bit seeding (F7); the fact is stated in section 1.

docs/analysis/attack-pass/f6-verifier.md

@@ -1,229 +0,0 @@
-# F6: the verifier's worst case over 10^5 class v4 programs
-
-Attack-pass row F6 (`docs/plans/cryptanalysis.md` 4.2; the record `docs/analysis/attack-pass-2026-10.md`), the box search.
-The O-1.14 laptop relay run is not in this record (main runs it separately). Written 7 October 2026.
-
-## Target
-
-| Item | Value |
-|---|---|
-| Commit | `924288d1` on branch `attack-pass` (`igneum-pow` is byte-identical at the worktree HEAD `8e36faf6`: `git diff --stat 924288d1..HEAD -- igneum-pow` is empty) |
-| Class | `--program-class v4`: generator 4 on `V4_CLASS` = `mx8+sh256x27` (`LoadClass::MX8` plus `ShadowClass { instrs: 256, reps: 27 }`), no era bytes (the same draw `igneum-pow bench --program-class v4 --seed S` makes) |
-| Dataset | day `2026-10-03`, `Shape::for_class_day(V4_CLASS, 0)`: cache 2^26 words (256 MiB), mixer x8, dataset 2^28 words, memory-hard |
-| Work per hash | 64 base instructions x 8 iterations (16 loads) plus 256 shadow instructions x 27 passes x 8 iterations = 55,296 shadow instructions, 101,192 counted ops at the 1.83 convention |
-| Gate | 10 ms per 32-lane warp, cold, on the half-core proxy (plan 1.4 item 6; spec 01 section 1.9 and 1.11; `algorithm.md` 3.3 and 5.5) |
-| Programs | 10^5 deterministic string seeds `attack-f6/0` to `attack-f6/99999` through the class v4 chain draw with its acceptance rule (5.22 percent needed a second or third attempt, max attempt 3) |
-
-The era draw is not in the search: `generator.rs` draws the shadow block from `NONLOAD_WEIGHTS` with no era perturbation
-(no `perturb` path exists in the code at this commit), and the era parameters change only the load addressing, not the op
-counts. Every drawn program has exactly 48 non-load base instructions and 256 shadow instructions, so the verifier's cost
-differs between programs only through the family mix (the per-family cost on the CPU) and the data.
-
-## Known-failed shape
-
-A drawn program whose verifier warp exceeds 10 ms cold on the half-core proxy. The acceptance rule (spec 1.4.6) bounds the
-miner's side (distinctness, bias, saturation); nothing bounds the verifier's cost per program, and the half-core headroom
-of the average program is 1.8 ms (`algorithm.md` 5.5), so a family mix that costs the CPU interpreter more than the average
-could cross the gate.
-
-## Harness
-
-`tools/attack/f6-verifier/` (its own cargo crate, `igneum-pow` as a path dependency, the same release profile as the CLI:
-opt-level 3, LTO, one codegen unit). It builds the day's dataset ONCE (`DatasetSource::new_shape`, 0.58 s on the box) and
-swaps programs under it: `Epoch { program, dataset }` is only the pair, and `verify::hash_warp(&program, base, &dataset)`
-takes both, so one dataset serves every program. The naive path (`igneum-pow bench` per seed) refills the cache every
-time (370 ms) and would take 10 hours per core.
-
-| Command | What it does |
-|---|---|
-| `attack-f6 scan --program-class v4 --count N --start S --threads T --cold-reps R --flush swap --out F` | program i = seed `attack-f6/<S+i>`; one CSV line per program: generation time, R timed warps (each after a flush), their min, the op counts by family for the base and the shadow block |
-| `attack-f6 time (--program-class v4 \| --class dr736) --seeds-file F --cold-reps R --steady W --flush sweep` | the deep re-time: R cold warps (each after a 256 MiB write sweep, what the cache fill does before `bench`'s "single cold run"), max, median, min, a steady average of W warps, and `GATE 10 ms PASS/FAIL` on the max |
-| `attack-f6 micro --program-class v4` | the genesis program with its shadow block rewritten to one family at a time against the same program with no shadow: the per-family cost of a shadow instruction (ranking weights only) |
-| `attack-f6 load --program-class v4 --seconds 0` | hashes class v4 warps on the calling core until killed: the SMT sibling's load for the half-core proxy, the same class the 3.3 proxy ran on both siblings |
-| `rank.py --scan ... --weights ... --column ... --top 50 --out-prefix P` | the proxy ranking (sum over families of weight x (8 x base count + 216 x shadow count)), the distribution (min, median, p99, p99.9, max with the seed), the worst-N lists, a no-intercept regression of time on the family counts |
-
-Build line (from the crate directory):
-`IGNEUM_AGENT=attack-f6 bash /Users/joshm/Projects/igneum/tools/build-remote.sh --artefacts "target/release/attack-f6" --out <scratch> -- build --release`
-(build 08:04 to 08:06 UTC, rustc 1.99.0, binary sha256 `89c35674...17f3f9`, on the box at
-`/srv/builds/igneum-wt-attack/tools/attack/f6-verifier/target/release/attack-f6`).
-
-Box scratch: `/srv/builds/igneum-wt-attack/target-attack-f6/` (not the `attack-f6/` the brief named: that path is an
-untracked directory in the worktree mirror and `build-remote.sh`'s checkout step runs `git clean -fd` on the mirror
-before every build of this worktree by any agent, which removed it once at 08:04 UTC; `target-*` is on the clean's keep
-list, so this name survives). Logs there: `phase1.log`, `scan-0.csv`, `scan-50000.csv` (phase 1), `phase2a.log`,
-`clock-2a.log`, `full-0.csv`, `phase2b.log`, `clock-2b.log`, `full-50000.csv`, `phase2c.log`, `clock-2c.log` (phase 2),
-`smoke.log` (the functional check). Copies on the Mac under the session scratchpad `attack-f6/`.
-
-Run lines:
-
-| Phase | Hold | Cores | Line |
-|---|---|---|---|
-| 1, pre-screen (counts and a coarse time, no timing claim) | `flock -s` per 50,000-program chunk (2.6 min each) | `nice -n 10 taskset -c 42-47,90-95`, 12 threads | `attack-f6 scan --program-class v4 --count 50000 --start {0,50000} --threads 12 --cold-reps 2 --flush swap` |
-| 2A, firings, micro, full pass first half | `flock -x` | `nice -n 19 taskset -c 40`; half-core: core 88 running `attack-f6 load` | `phase2a.sh` |
-| 2B, full pass second half, worst 50 by proxy and worst 50 by coarse time re-timed on both proxies | `flock -x` | same | `phase2b.sh` |
-| 2C, worst 1,000 by the full one-core pass on the half-core; worst 10 deep re-timed on both proxies | `flock -x` | same | `phase2c.sh` |
-
-The clock of cores 40 and 88 (`scaling_cur_freq`) and the load average were read every 5 s during every exclusive hold
-(`clock-2*.log`).
-
-## The two firings (batch A, exclusive hold taken 08:15:20 UTC, core 40 at 3,799.9 MHz throughout, `clock-2a.log`)
-
-`attack-f6 time ... --cold-reps 5 --steady 20 --flush sweep`, the gate applied to the max of the 5 cold warps
-(`phase2a.log`). Lane-0 vectors equal the known ones (dr736 `e23d389f3eea0c83`, the Mac's).
-
-| Case | Proxy | Cold max / median / min (ms) | Steady, avg of 20 | Known value (`algorithm.md` 3.3) | Verdict |
-|---|---|---|---|---|---|
-| known-fail, `--class dr736`, genesis seed | one core | 10.284 / 9.982 / 9.952 | 9.562 | 10.51 cold, 9.76 steady | FAIL (fired) |
-| known-fail, `--class dr736`, genesis seed | half-core | 14.135 / 13.795 / 13.400 | 13.225 | 15.49 | FAIL (fired) |
-| known-pass, `--program-class v4`, genesis seed | one core | 5.156 / 5.140 / 5.135 | 4.909 | 5.06 cold, 4.90 steady | PASS (fired) |
-| known-pass, `--program-class v4`, genesis seed | half-core | 8.624 / 8.510 / 8.389 | 8.268 | 8.23 | PASS (fired) |
-
-The harness reads the known-fail class over the gate and the known-pass class under it on both proxies, within 2 percent
-of the 3.3 one-core numbers and within 9 percent on the half-core (the earlier half-core run loaded the sibling with
-`igneum-pow bench` of the same class; this one hashes class v4 warps on it continuously).
-
-## What one program can move (batch A, `micro`, core 40 solo)
-
-The genesis class v4 program with no shadow block: 4.511 ms steady; with its drawn shadow: 4.920 ms. So the whole 55,296-
-instruction shadow block costs 0.41 ms per warp on this core (7.4 us per 1,000 shadow instructions; `model.py` carries
-7.0) and the base program with its 128 loads and 4,096 item derivations costs the other 4.5 ms. The verifier's cost is
-92 percent dataset derivation (the x8 mixer, 8 dependent cache reads per item), which no drawn program changes: every
-class v4 program has 16 loads and the acceptance rule's distinctness test keeps the items per warp near 4,096. The family
-mix of the shadow can move at most a fraction of 0.41 ms. The per-family rewrite (the 256 shadow instructions all one
-family) reads add 4.798, sub 4.703, xor 4.683, rotl 4.818, mad 4.805, shfl 5.042, rotr 5.160 ms per warp; the mul,
-mulhi and or rows (0.97, 1.55, 1.13 ms) are degenerate (the registers collapse to 0 or all-ones, every lane then loads
-the same item and the memory side vanishes) and are not ALU costs. Batch A's micro line printed its per-1,000 column
-1,000x too small (ns per instruction); fixed in the source, the numbers above are the ms-per-warp column, which is right.
-
-## Full one-core pass A (batch A, 50,000 programs, core 40 solo, one cold warp each after a program swap, `full-0.csv`)
-
-617 s for 50,000 programs (12.3 ms each, 2.5 ms of it generation and acceptance). The per-family regression on the
-50,000 timings (no intercept) gives 86 to 98 us per 1,000 executed instructions by family, R^2 0.001: the family mix
-explains none of the program-to-program variation. Those regression weights (add 89.1, sub 87.7, mul 90.6, mulhi 98.4,
-xor 89.6, or 86.0, rotl 89.4, rotr 86.3, mad 91.2, shfl 95.6) are the proxy weights used for the worst-50-by-proxy list.
-
-| Pass A | n | min | median | p99 | p99.9 | max |
-|---|---|---|---|---|---|---|
-| all rows | 50,000 | 4.610 (`attack-f6/1278`) | 4.950 | 6.753 | 7.834 | 10.710 (`attack-f6/26705`) |
-| rows outside the three disturbed blocks | 44,000 | 4.610 | 4.948 | 5.606 | 5.662 | 6.194 (`attack-f6/48484`) |
-
-The rows over 6 ms sit in three 2,000-program blocks (26,000 to 27,999: 337 rows; 36,000 to 37,999: 300; 38,000 to
-39,999: 294) and nowhere else (0 in each of the other 22 blocks); the neighbours of the 10.71 ms seed, unrelated programs,
-all read 7.6 to 8.5 ms. `clock-2a.log` shows core 88 (the idle sibling of a solo run) at 3.8 GHz for stretches in those
-minutes (08:21:25, 08:21:45, 08:22:05 to 08:22:25 UTC) and core 40 dipping to 3.68 GHz at 08:21:00: a foreign process
-(the box's hands run outside the measure lock) sat on the sibling, which is the half-core condition, and those rows read
-half-core numbers. They are not program properties and not numbers; the three blocks are re-scanned in batch B, and from
-batch B on a per-second sampler logs every process whose last CPU was 40 or 88 (`clock-2b.log`, `clock-2c.log`) so a
-disturbed row can be named.
-
-## Batches B and C: queued, starved of the exclusive hold (state at 09:46 UTC)
-
-Batch B (the second 50,000 of the full one-core pass, the re-scan of the three disturbed blocks, the worst 50 by proxy
-and the worst 50 by phase-1 coarse time re-timed 10 cold reps each on both proxies) was queued with `flock -x -w 7200`
-at 08:33:56 UTC and had not taken the file by 09:46 UTC. Linux `flock` gives a pending exclusive waiter no priority over
-new shared takers; eight lanes re-take the file in chunks (17 to 38 shared holders at every reading, F2 spawning many
-short ones, one F9 hold 33 minutes old at 09:06, over the 30-minute cap), so the file is never free. Left on the box:
-`run2b-retry.sh` re-queues batch B up to four more times (2 h each); `run2c-auto.sh` waits for `BATCH B DONE`, builds the
-batch C lists on the box (`mklists.py`: the worst 1,000 and worst 10 by the full one-core pass, pass A's three disturbed
-blocks replaced by their re-scan) and queues batch C (the worst 1,000 on the half-core at 2 cold reps each, the worst 10
-at 20 cold reps on both proxies). A marker sits beside the lock (`/srv/builds/_locks/measure.wanted-by-attack-f6`). When
-they land, `timeparse.py --log phase2b.log --clock clock-2b.log` (and `2c`) prints the per-seed tables with the sampler's
-foreign-process column, and this record is completed.
-
-## Numbers so far, the gate, the verdict
-
-| Quantity | Value | Where |
-|---|---|---|
-| Programs drawn and counted (phase 1) | 100,000 | `scan-0.csv`, `scan-50000.csv` |
-| Programs timed cold on core 40 alone (one-core proxy) | 50,000 (44,000 clean, 6,000 in disturbed blocks awaiting the re-scan) | `full-0.csv` |
-| One-core cold, clean rows: min / median / p99 / p99.9 / max | 4.610 / 4.948 / 5.606 / 5.662 / 6.194 ms (`attack-f6/48484`), single warps, not yet re-timed | `full-0.csv` |
-| Genesis class v4, half-core, max of 5 cold | 8.624 ms | `phase2a.log` |
-| Half-core over one-core, genesis class v4 | 1.67x (8.624 / 5.156) | `phase2a.log` |
-| Programs timed on the half-core proxy | 1 (the genesis seed) | `phase2a.log` |
-| Core 40 clock during every exclusive timing | 3,799.9 MHz (dips to 3,680 MHz only in the disturbed minutes) | `clock-2a.log` |
-
-Gate line: the worst program under 10 ms cold on the half-core proxy. Not yet measured: no drawn program other than the
-genesis seed has a half-core number, and the one-core worst (6.194 ms, a single warp with no sampler running) has not been
-re-timed. Carried to the half-core at the genesis ratio it would read 6.19 x 1.67 = 10.3 ms, over the gate; carried at the
-additive half-core cost of the genesis program (8.624 - 5.156 = 3.47 ms) it would read 9.66 ms, under it by 0.34 ms. The
-2.5x bracket of `algorithm.md` 5.5 is between. Whether `attack-f6/48484` (and the other clean rows over 5.6 ms: 1 in 100
-of the pass) is a program property or a short disturbance is what batch C's 20-rep re-time with the sampler decides;
-the record says FINDING if its half-core cold max reads 10 ms or more.
-
-Verdict: INCOMPLETE. 100,000 programs drawn and ranked, 50,000 timed on the one-core proxy, 0 of the worst re-timed on
-the half-core proxy; the two firings fired; the box search's second half and the half-core re-times are queued and
-starved of the exclusive hold.
-
-## The ladder ceiling implied so far
-
-`algorithm.md` 5.5 and `model.py --section ladder` set the ceiling from the half-core headroom at 12.1 us per 1,000 shadow
-instructions, N = 101,192 + instructions x 1.83.
-
-| Worst program on the half-core | Headroom to 10 ms | Shadow instructions it buys | Ceiling N (counted ops) |
-|---|---|---|---|
-| 8.23 ms (3.3's average, the published figure) | 1.77 ms | 146,000 | about 370,000 |
-| 8.62 ms (genesis seed, this run's max of 5) | 1.38 ms | 114,000 | about 310,000 |
-| 9.66 ms (48484 if the additive carry holds) | 0.34 ms | 28,000 | about 152,000 |
-| 10.3 ms (48484 if the 1.67x carry holds) | none | 0 | below today's 101,192: the floor rung 100,000 is the ceiling |
-
-The proposed genesis ladder {100,000; 130,000; 200,000; 330,000; 650,000; 1,000,000} already exceeds the 310,000 ceiling
-at its fourth rung on the genesis program alone; on the worst program the ceiling could be the floor. This is the
-ladder's own open question (plan 1.1, "ceiling set by the verifier"), and the number that sets it is the half-core
-worst case still queued.
-
-## Consequences per user tier (at the numbers measured so far; the model's table of 5.5 at 10 ms beside them)
-
-| | At 8.62 ms (genesis, half-core max) | At 9.66 ms (worst, additive carry, unverified) | At 10.3 ms (worst, 1.67x carry, unverified) | Model at 10 ms |
-|---|---|---|---|---|
-| A node on a 2019-class laptop core at 1 bps | 0.9 percent of one core | 1.0 | 1.0 | 1 |
-| At 10 bps (the Devnet 2 experiment) | 8.6 percent of one core | 9.7 | 10.3 | 10 |
-| IBD over the 108,000-header pruning window, one core | 15.5 min | 17.4 | 18.5 | 18 |
-| Header flood: invalid headers per second that saturate one core | 116 | 104 | 97 | 100 |
-| A pool core verifying shares, shares per second per core | 116 | 104 | 97 | 100 |
-
-What each tier does with it: a home miner (8, 12, 16, 24 or 32 GB card, any vendor, any OS) runs a node that spends about
-1 percent of one CPU core on the hash at 1 bps whatever the drawn program, and 9 to 10 percent at 10 bps; the card is not
-involved. A rig is the same per node. A pool verifying shares at 100 per second per core needs one core per 100 shares
-per second at the worst program, 116 at the average: a pool that sized its share verification at the average loses 14
-percent of its per-core headroom on the worst program, so pools size at 97 shares per second per core (the 10 ms figure)
-and never at the average. A node under header flood holds at about 100 invalid headers per second per core on any
-program, the M15 figure. The 2019-class core itself is still the half-core proxy until the O-1.14 laptop run lands
-(main's lane).
-
-What this lane does about it: completes batches B and C when the hold comes (automatic, on the box); if the worst
-program reads 10 ms or more on the half-core proxy, the finding goes to main with the seed, the reproduction line
-`igneum-pow bench --program-class v4 --seed <seed> --day 2026-10-03 --warps 50` on core 40 and the half-core, and the
-proposed fix: an acceptance-rule bound on verifier cost (a per-program cost model over the family counts checked at
-draw time, a redraw when it exceeds the bound, exactly as rule (c) redraws on bias) and the ladder's ceiling set from
-the measured worst, not the average; `igneum-pow` is not edited by this lane.
-
-## Batches B and C landed (7 October 2026, 13:5x UTC, cores 40 and 88 under the per-core lease)
-
-The measure file was retired at 13:3x UTC and replaced by per-core leases; cores 40 and 88 were leased to this row
-(`/srv/builds/_bin/lease cores 40,88 --owner attack-pass`), so the batches ran with nothing else on those cores while
-builds continued on the rest of the box. Core 40's clock (`clock-2b.log`, `clock-2c.log`): median 3,799.9 MHz in both
-batches, 954 of 958 and 57 of 63 samples at 3.7 GHz or more, the 1.5 GHz readings between runs.
-
-| Batch | What | Programs | Reps | Worst program | Half-core cold max | Log |
-|---|---|---|---|---|---|---|
-| B | the second 50,000 of the one-core pass, then the worst 50 by proxy and the worst 50 by coarse time re-timed cold on both proxies | 200 re-timed | 10 | `attack-f6/87142` | 8.708 ms | `phase2b.log`, done 13:52:11Z |
-| C | the worst 1,000 by the full one-core pass on the half-core, then the worst 10 at 20 cold reps on both proxies | 1,000 + 10 | 2, then 20 | `attack-f6/88521` (8.629), `attack-f6/15781` (8.414) | 8.629 ms | `phase2c.log`, done 13:57:45Z |
-
-The one-core worst of the full pass (`attack-f6/48484`, 6.194 ms single warp) does not reach the half-core top ten:
-its one-core reading was a short disturbance, as the batch C re-scan shows. Every program timed on the half-core
-proxy reads under 9 ms.
-
-## Gate line and verdict
-
-Gate: the worst program under 10 ms cold on the half-core proxy (and on a 2019-class core: O-1.14, the i7-9700K row,
-class v4 6.334 ms cold max). Result: the worst of 100,000 class v4 programs on the half-core proxy is 8.708 ms,
-1.29 ms under the gate; the genesis program reads 8.624 on the same proxy, so the worst drawn program costs 1 percent
-more than the genesis one and the distribution is tight (one-core clean rows 4.610 to 6.194 ms, p99 5.606).
-Verdict: PASS. The two firings fired (dr736 FAIL at 15.49 ms half-core; class v4 genesis PASS at 8.62). Consequences
-per tier: a 2019-class node verifying the worst class v4 program spends 0.9 percent of one core at 1 bps and 9 percent
-at 10 bps on the pessimistic proxy; a header flood needs about 115 invalid headers a second to saturate one such
-core; a pool verifies about 115 shares a second per core; IBD of 108,000 headers is about 16 minutes of one core.
-Implied ladder ceiling on the half-core proxy from the worst program: 10 - 8.708 = 1.29 ms of headroom buys about
-106,000 shadow instructions, N about 300,000 counted ops at the 1.83 convention (approximate), against 370,000
-from the genesis program's headroom; the ladder's ceiling should be read from the worst program, not the genesis
-one, so rung 2 (199,600) stays admissible and rung 3 (330,700) does not on this proxy.

docs/analysis/attack-pass/f7-era.md

@@ -1,165 +0,0 @@
-# F7: the era-draw bias harness and the era-seed census
-
-Attack-pass row F7 (`docs/plans/cryptanalysis.md` 4.2; the record `docs/analysis/attack-pass-2026-10.md`), both halves:
-the fast-time re-roll harness (node lane) and the 2^20 era-seed census plus the 64-bit day-key check (hash lane).
-Written 7 October 2026. Every number cites its log path on igneum-build-1.
-
-## Target
-
-| Item | Value |
-|---|---|
-| Commit | `924288d1` on branch `attack-pass` (`igneum-pow` is byte-identical at worktree HEAD `11b375a0`: `git diff --stat 924288d1..HEAD -- igneum-pow docs/spec infra/fast-time` is empty) |
-| Spec | `docs/spec/01-lottery-hash.md` 1.13.1 (era seed and draw), 1.8.4 (the day-key mixer stream); `docs/spec/04-seeds-and-vdf.md` 4.4 (era seed pipeline) and 4.6 (T from a reference core); `docs/plans/era-layout.md` sections 1 and 8 (branch `ca2-era`); `docs/analysis/horizon/algorithm.md` 5.4 |
-| Draw code | `igneum_pow::generator::era_draw` over `V3_ALLOWED = [1]` (the chain's path): the width draw (consumed, pinned at 4 bytes), the odd stride multiplier `M`, the rotation `R` in 1..31, the four interleave positions `pos` by partial Fisher-Yates |
-| Day-key code | `igneum_pow::memhard::MixParams::with_shape`: `SplitMix64::new(K[0] \| (K[1] << 32))` draws ROT[0..7], MUL[0..15], RC[0..15]; `K = seed_words_from_bytes("igneum-day/" \|\| day_le64)` (node fork `consensus/pow/src/igneum.rs`, `bind::day_bytes`) |
-| Node draw input (today) | `consensus/src/consensus/mod.rs` `seed_below`: `E_n` is the hash of the last selected-chain block below `15,552,000 n - 7,200` (era 0: genesis). The 1-hour VDF of spec 4.4 and the certified checkpoint it reads do NOT exist in the node (era-layout.md section 8, `proto-vdf` is a prototype) |
-
-## Sub-row verdicts
-
-| Sub-row | Verdict | Gate (plan 4.2 F7) |
-|---|---|---|
-| (a) re-roll harness | INCOMPLETE, with the written argument | no re-roll inside the publish window |
-| (b) 2^20 era-seed census | PASS | no era class with gain over 1.1x at a fraction over 2^-20 |
-| (c) 64-bit day-key seeding | PASS, within spec intent (one observation recorded) | the draw's input set as the spec states it |
-
-## (a) The re-roll harness (node lane)
-
-`tools/attack/f7-era/reroll.mjs`: a 3-node fast-time network (`infra/fast-time/override-60x.json` with
-`skip_proof_of_work`, the `class-v4-signal.mjs` shape), own ports 29800 and up, own devnet suffix 980, own data dir
-`/tmp/igneum-fast-time-attack-f7`. The node binary is the ladder fork `vendor/igneum-node-ladder` at `1591ee1d`
-(`igneumd 2.1.0`, already built on the box; read-only). Two honest virtual miners share 1 block/s on nodes 0 and 1; the
-adversary on node 2 holds a block `A` built on the tip at DAA score `S - 1` (the seed block sits there), optionally waits
-a stub VDF of `--vdf-ms`, then publishes `A` to try to make its own block the epoch's seed block (the last selected-chain
-block below the cut `S`). A re-roll succeeds when the epoch's reported seed becomes `hash(A)`.
-
-The era cut `15,552,000 n - 7,200` is 180 days of DAA score away on every profile (`POW_ERA_BLOCKS` is a chain constant,
-not an override field), so the harness attacks the EPOCH cut (`60 e - 10` at 60x), which runs the identical `seed_below`
-derivation at a reachable score, one cut per minute. The harness's own era draw (JS) is checked byte-for-byte against the
-Rust census at start: seed `b62532bc...` draws `M 558c0543 R 4 pos [0,1,2,3]` on both (log line "draw self-check ... OK").
-
-Firings (both runs 6 cuts, box cores 36-37,84-85 under the shared measure lock):
-
-| Run | `--vdf-ms` | Re-rolls to A | Gate | Harness | Log |
-|---|---|---|---|---|---|
-| known-pass | 0 (no delay, the stand-in) | 1 of 6 (epoch 11, seed = A) | FAIL | SOUND (fires) | `/srv/builds/igneum-wt-attack/attack-f7/reroll-knownpass.log` |
-| known-fail | 5,000 (a delay past one block interval) | 0 of 6 | PASS | SOUND (silent) | `/srv/builds/igneum-wt-attack/attack-f7/reroll-knownfail.log` |
-
-Both runs: 6 of 6 adversary blocks accepted, all three sinks agree, no reorg of the honest chain. The harness fires on the
-known-pass and is silent on the known-fail, so it is trusted.
-
-Written argument (the plan allows one for the VDF's assumptions; the VDF's own delay soundness belongs to the finality
-review row of `funding.md`). The re-roll is possible ONLY when the adversary can evaluate the draw of a candidate input
-inside the block publish window. Today the node has no VDF: `E_n` is a plain block hash, so the input of any candidate
-block is known the instant the block is built, and the harness shows the last-block-before-the-cut is grindable with one
-block of hash (1 of 6 cuts steered in fast time, `--vdf-ms 0`). With any delay past one honest block interval the
-re-roll is gone (`--vdf-ms 5000`: 0 of 6). The design closes this with the 1-hour class-group VDF of spec 4.4: re-rolling
-by withholding needs the 3,600 s VDF evaluated inside the 2 s window, a 1,800x evaluator, and spec 4.6's margin table
-gives 300x as the horizon (`algorithm.md` 5.4; `sim/horizon/algorithm/model.py --section era`). The forge route needs
-2/3 of the 30-day weight, 20 days of 100 percent hash (CLAUDE.md headline). The sub-row is INCOMPLETE because the harness
-cannot demonstrate the real gate: the VDF and the certified checkpoint it reads are not in the node yet (era-layout.md
-section 8 states this). What the harness DOES establish: the C_era cut rule with no delay is grindable, so the era draw's
-soundness rests entirely on the VDF landing before the draw procedure is frozen, and the delay-soundness measurement is
-owed to the finality lane.
-
-## (b) The 2^20 era-seed census (hash lane)
-
-`tools/attack/f7-era/` (a cargo crate with `igneum-pow` as a path dependency and an empty `[workspace]`; ELF built on the
-box, sha256 `a87818d8...`). `attack-f7 census` runs `era_draw` over `V3_ALLOWED` on `2^n` seeds and classifies each draw;
-`attack-f7 all` runs the plant known-fail case, the census, the spec-stream op-weight census and the day-key check.
-
-Known-fail / known-pass of the classifier (planted parameters through a test hook in this crate; log
-`/srv/builds/igneum-wt-attack/attack-f7/census-2p20.log`): every planted weak draw fires its flag (M = 1, M = 2^32-1,
-M = 2^16+1, a naf-2 multiplier, an even M, R = 0, R = 32, pos linear, pos contiguous, pos not ascending) and a sound draw
-(igneum-era-test/0) raises nothing. "Plant verdict: every planted case fired and the sound draw did not."
-
-Census results (2^24 = 16,777,216 draws, the stronger run; `census-2p24.log`; the 2^20 run agrees, `census-2p20.log`):
-
-| Class | Count (2^24) | Fraction | Expected (uniform) | Chip gain |
-|---|---|---|---|---|
-| M even (bijection failure) | 0 | 0 | 0 | finding if present: none |
-| R out of 1..31 | 0 | 0 | 0 | finding if present: none |
-| pos invalid (not 4 ascending) | 0 | 0 | 0 | finding if present: none |
-| M = 1 (identity stride) | 0 | 0 | 4.66e-10 | 1.0034x |
-| M = 2^32 - 1 | 0 | 0 | 4.66e-10 | 1.0030x |
-| popcount(M) <= 2 | 1 | 5.96e-8 (2^-24) | 1.49e-8 | 1.0030x |
-| popcount(M) <= 4 | 43 | 2.56e-6 (2^-18.6) | 2.33e-6 | 1.0022x |
-| popcount(M) <= 6 | 1,626 | 9.69e-5 | 9.61e-5 | 1.0014x |
-| popcount(M) <= 8 | 27,749 | 1.65e-3 | 1.66e-3 | 1.0007x |
-| naf(M) <= 2 | 1 | 5.96e-8 | - | 1.0030x |
-| naf(M) <= 3 | 18 | 1.07e-6 | - | 1.0026x |
-| M = 2^k + 1 | 1 | 5.96e-8 | 1.44e-8 | 1.0030x |
-| pos linear [0,1,2,3] | 9,257 | 5.52e-4 | 5.50e-4 | 1.0000x |
-| pos contiguous | 120,054 | 7.16e-3 | 7.14e-3 | 1.0000x |
-| pos in the low byte | 645,856 | 3.85e-2 | 3.85e-2 | 1.0000x |
-
-The gain metric is the datapath energy a chip saves per hash against the base weights, over the hash's datapath energy
-(19.5 nJ at 100,000 ops x 0.195 pJ, the N5 floor of `algorithm.md` 5.4 / `model.py --section era`). The stride multiply is
-one of three address operations, run 128 times per hash (16 loads x 8 iterations); a low-weight `M` replaces the multiplier
-with a few shift-adds, worth at most 128 x 0.52 pJ = 67 pJ, so M = 1 is the richest corner at 1.0034x. The rotation is a
-wire mux and the interleave an address-line permute, 0 pJ on the modelled chip. No drawn parameter touches the memory
-bound, the item derivation, the load count or N.
-
-Gate: no class with gain over 1.1x at a fraction over 2^-20. The richest gain in the whole classifier is 1.0034x (M = 1),
-and M = 1 did not occur in 2^24 draws (expected 4.66e-10). Every class at a fraction over 2^-20 has gain 1.0000x to
-1.0007x. PASS on both counts.
-
-Uniformity of the draw (2^24): stride rotation R over 1..31 chi-square 38.5 on 30 dof (max bucket deviation 2.07 sigma,
-R = 0 or 32 seen 0 times); interleave pos 1,820 of 1,820 four-subsets seen, chi-square 1,775.7 on 1,819 dof (max deviation
-3.63 sigma, 0 draws with a non-4-subset); M bit 0 always set (odd by construction), bits 1..31 each set in 0.500 of draws
-(worst bit 1.81 sigma); the stride bijection never failed (0 even M). The era stream's own 64-bit seed (words 0 and 1) was
-distinct on all 2^24 draws.
-
-Op-weight corners (spec 1.13.1 first stream, implemented in `attack-f7 spec` from the spec text because `igneum-pow` does
-not draw the op-weight perturbation at this commit; 2^20 draws, `census-2p20.log`): the ten non-load weights each
-perturbed by -2..+2 and renormalised to 75 move the multiply share (mul+mad+mulhi, base 22 of 75) between 15 and 31. The
-richest corner for a chip is 15/75 (0.152 pJ per op, -22 percent of the base datapath), seen once in 2^20; 16/75 at
-3.22e-3. The GPU's energy moves the same way (its IMAD is the chain's own op), so the chip-against-GPU gain of every
-weight corner is 1.0x, with 0 memory effect. Renormalised sums were 75 on every draw (0 failures). Fold rotations: a triple
-all equal 2.13e-3, both triples all equal 1.91e-6, all six equal 0; uniform over 1..31, rotation 0 never drawn; a wire
-mux, 1.0x.
-
-## (c) The 64-bit seeding of the day-key stream (hash lane)
-
-`attack-f7 days` over days 0..131,072 (`census-2p20.log`). The day key `K` is `seed_words_from_bytes("igneum-day/" ||
-day_le64)`: a calendar function, no chain state. All 256 bits of `K` enter the cache fill (spec 1.8.3, `K[0..7]` in every
-block input), so the dataset depends on the full key; the mixer-constant stream (ROT, MUL, RC) is seeded from `K[0] |
-(K[1] << 32)`, 64 bits, which is the spec's stated intent (spec 1.8.4).
-
-| Quantity | Value |
-|---|---|
-| Days the chain can have | about 65,745 in 180 years at 1 block/s (2^16.0) |
-| Distinct 256-bit keys K over 2^17 days | 131,072 (all) |
-| Distinct 64-bit stream seeds over 2^17 days | 131,072 (0 duplicates) |
-| Distinct (ROT, MUL, RC) tuples over 2^17 days | 131,072 |
-| Birthday bound on a 64-bit collision among 2^16 days | 2^(32 - 65) = 2^-33 |
-
-The spec intends 64 bits for the mixer-constant draw, and the truncation is not a reduction of the draw space the firm
-would flag: at most 2^16 days are ever drawn, each a distinct calendar day with a distinct 64-bit seed (0 collisions in
-2^17), so no two days share a mixer. One observation, within spec intent and recorded for the written argument of
-`funding.md` B5 rank 6: the mixer-constant stream has 64 bits of seed entropy, so at most 2^64 distinct daily mixers are
-reachable (not the ~2^1,047 nominal); this is not exploitable (the days used are 2^16, all distinct) and whether any
-reachable tuple is weak is the separate weak-day census of row F4.
-
-## Consequences per tier
-
-The era draw and the day-key seeding are protocol-wide and do not differ by card tier: the load width and load count are
-pinned, so every era is equally memory-bound and no 8, 12, 16 or 24/32 GB card is advantaged or disadvantaged by any draw
-(the measured six-era hash-rate spread is 1.3 percent on the RTX 5090, 3.2 on the RX 9070 XT, 0.8 on the M5 Max,
-`algorithm.md` 5.4). No drawn era parameter or day key makes a chip cheaper against a GPU: the richest datapath corner is
-1.0034x and is shared with the GPU. The one operational consequence is for the protocol, not a miner tier: the era draw's
-grinding resistance is not yet demonstrable because the 1-hour VDF and its certified checkpoint are not in the node, so
-the freeze of the draw procedure and the C_era cut rule must wait on the VDF landing and the finality lane's delay-
-soundness measurement.
-
-## Gate line
-
-- (a) harness: INCOMPLETE. No re-roll with a one-block delay (known-fail 0 of 6); a re-roll with no delay (known-pass 1 of
-  6). The real gate (no re-roll inside the 2 s window) rests on the 1-hour VDF, which is not in the node; written argument
-  above.
-- (b) census: PASS. No era class with gain over 1.1x at any fraction (richest 1.0034x, M = 1, absent in 2^24); the draw is
-  a bijection on every sample and uniform in R, pos and the M bits.
-- (c) 64-bit seeding: PASS within spec intent. The spec intends 64 bits for the mixer stream; 2^16 days are all distinct;
-  the one observation (2^64 reachable mixers) is recorded, not a flaw.
-
-What a failure moves (plan 4.2 F7): the draw procedure or the C_era cut rule; a redraw rule for the era stream. Nothing in
-(b) or (c) moves them. (a) moves nothing in shipped code but gates the freeze of the draw procedure on the VDF.

docs/analysis/attack-pass/f8-uniform.md

@@ -1,259 +0,0 @@
-# F8. Uniformity censuses of the class v4 derivation
-
-Attack-pass row F8 (`docs/plans/cryptanalysis.md` section 4.2; the pass record `docs/analysis/attack-pass-2026-10.md`).
-Run 7 October 2026, 08:13 to 09:3x UTC (09:13 to 10:3x UK) on igneum-build-1. Verdict: **FINDING** (AP-F8-1 below).
-The line-index census is a PASS at its full sample size; the cross-hash item histogram is not uniform, and the cause
-is in the base program, inside the acceptance rule's blind spot.
-
-## 1. Target
-
-| Item | Value |
-|---|---|
-| Commit | `igneum-pow` at 924288d1 (`attack-pass`); the box built HEAD b2a411d1, whose `igneum-pow` is byte-identical (`git diff --stat 924288d1 HEAD -- igneum-pow` is empty) |
-| Class | `--program-class v4`: `V4_CLASS` = `mx8+sh256x27`, generator 4, mixer x8, the era layout drawn inside the class, the shadow block of 256 instructions x 27 reps |
-| Line index | `proto-metal/MEMHARD.md` section 1.6: `a = s[0] AND 0x003fffff`, 4,194,304 lines of 64 B, 8 dependent reads per item (`memhard.rs` `derive_items_mask`, `cache.line_const(s[0])`) |
-| Item index | `verify.rs` `load_index`: `y = rotl(x * M, R)`, the site's window `(y & (MASK >> k)) \| off`, then `Layout::split` removes the four interleave bits; 2^24 items at the 2^28-word dataset |
-| Reads per hash | 128 loads (16 sites x 8 iterations), so up to 1,024 cache lines per hash and 32,768 per warp. The spec's analytic bound of 832 lines per hash (`docs/spec/01-lottery-hash.md` line 347, 104 loads x 8) predates generator 2's fixed 16 load slots; the current bound is 128 x 8 = 1,024 |
-| Prior figures | `chip-model-v3.md` section 1: "median 128.00 distinct" items per hash (the 20,000-program census); `weak-program-census-2026-10-03.md` line 291: 127.7 distinct addresses per hash under the proposed generator |
-| Day | the devnet pack's day, `bind::day_bytes(20730)` (2026-10-04), day 0 of the growth schedule: a 2^26-word cache, a 2^28-word dataset. Census 1 uses days 20730 to 20745 |
-| Programs | p1 = the devnet epoch-0 derivation (epoch seed and era seed both the genesis hash `edc4fa84...fb07`, program id `c120d7963abdcd96`, attempt 0); p2 and p3 = chain-shaped seeds from tag strings (section 4), attempts 1 and 0 |
-
-## 2. Method and harness
-
-Harness: `tools/attack/f8-uniform/` (crate `attack-f8`, a path dependency on `igneum-pow`, nothing in the library
-modified). Built on the box through `tools/build-remote.sh`: sha256 `590668...f913` for the firings of 2.1,
-`ef8042...11b2` for sections 3, 4.1 and the first item runs (flat null, `log/c-*`, `log/d-*`), `890955...fbd3` for the
-window-model runs and the seed census (`log/e-*`). The committed source carries one later label fix (the
-"uniform-on-window" entropy reference in the per-site line is 16 - k_off bits; the 09:04 UTC logs print 16 - 2 k_off). Box scratch `/srv/builds/igneum-wt-attack/target-attack-f8/`
-(the name `target-*` is what the box's checkout clean spared at the time; the fix at b92a5fd4 now also spares
-`attack-*`). Every run: `nice -n 10 taskset -c 22-27,70-75`, 12 threads, under `flock -s /srv/builds/_locks/measure`
-in chunks under 3 minutes each (the longest, phase D, under 25 minutes).
-
-Two mirrors, each trusted only while it agrees with the library bit for bit:
-
-| Mirror | What it records | Agreement check | Result |
-|---|---|---|---|
-| `derive_traced`: `memhard::derive_items_mask` instruction for instruction (`mixer`, `round_key_mult`, `cache.line` from the library), the line index of every round kept | 8 line indices per item | every item of every day also derived by the library's `derive_items` and compared on all 16 words | 0 mismatches on 268,435,456 items (section 3) and on 16,777,216 items per table build (section 4) |
-| `Mirror::warp`: `verify::interpret_warp_init` for the class v4 op set, dataset words from a table of the day's 2^24 items, the item index and the source register of every load kept | 128 item indices per lane, the source value's saturation per position | the 32 hashes of warp 0 to 63 and of every 997th warp compared with `Epoch::hash_warp` | 0 mismatches on 95 warps per program (section 4) |
-
-Three censuses:
-
-1. `lines`: all 2^24 items of each of 16 consecutive day keys (2^28 item derivations, 2^31 line reads), the full 2^22-line
-   histogram per round and pooled, the 2^16-bucket histogram (64 lines, one chained segment per bucket), a uniform
-   SplitMix64 control of the same size.
-2. `warps`: 10^6 nonces (31,250 warps) of each of three programs: distinct lines and items per hash and per warp, the
-   cross-hash item histogram, per-position diagnostics, an attribution pass from the hottest items back to the load
-   positions that read them.
-3. `warps` at 2^26 nonces on p1: the one-epoch cross-hash item histogram at 512 expected reads per item.
-
-The tests, defined before the runs:
-
-- **6-sigma test**: the largest (and smallest) bucket of a histogram within 6 sigma of its expectation, sigma =
-  sqrt(expectation). The gate's bucket is the 64-line segment for lines and the 64-item bucket for items. The
-  full-resolution histograms are reported beside a uniform control of the same size, because at a small mean the
-  Poisson tail puts the maximum of 4 million bins above 6 sigma by chance (control at mean 8: +6.72 sigma; at mean
-  32: +5.83; at mean 512: +5.61).
-- **Hot-set test** (F8's definition, written for F9's reuse): sort items by read count; S_f = the share of all reads
-  on the top-f fraction of items, for f in {0.1%, 0.5%, 1%}; E_f = the same share on a control of the same size drawn
-  from the design's own null (flat uniform for lines; the window-weighted null for items, section 4.2); the excess
-  X_f = S_f - E_f. **A hot set exists at f when X_f >= f**: after the chance excess is removed, the top f of items
-  capture at least one extra proportional share, which is what an on-die copy of f of the items would have to win to
-  matter. X_f / f is printed as the gain in proportional shares. The acceptance-style form of the same metric (for
-  rule (c)'s 2,048 evaluations): per load position, the largest count of one masked address, and the count of
-  saturated (0 or 2^32 - 1) source values.
-
-### 2.1 The harness fires (known-fail and known-pass)
-
-| Plant | What it does | 6-sigma test | Hot-set test | Log |
-|---|---|---|---|---|
-| `quarter-lines` | line index masked to a quarter of its range | buckets64 largest +75.97 sigma (2,231 at mean 512), smallest -22.63: FLAGGED | X_1% = +3.54% (S 5.60% vs control 2.06%), X/f = 3.5 at every f: FLAGGED | `log/a1-lines-quarter.log` |
-| `half-lines` | line index masked to a half | buckets64 largest +29.26 sigma: FLAGGED | X_1% = +1.25%, X/f = 1.25: FLAGGED | `log/a2-lines-half.log` |
-| `const-item` | one constant item at the first load site (1/16 of reads) | items buckets64 largest +92,682 sigma: FLAGGED | X_0.1% = +6.38%, X/f = 63.8: FLAGGED | `log/a4-warps-const-item.log` |
-| none, 2^22 items, one day | the real derivation at a small size | buckets64 largest +4.42 sigma, smallest -4.51: within 6 sigma (control +4.33) | X_f = -0.0004%, -0.0006%, -0.0010%: clear | `log/a3-lines-pass-small.log` |
-
-Both tests fire on every plant and neither fires on the real line derivation. Log paths are under
-`/srv/builds/igneum-wt-attack/target-attack-f8/`.
-
-## 3. Census 1: the line index over 2^28 derivations (PASS)
-
-Sample reached: 16 days x 2^24 items = 268,435,456 item derivations, 2,147,483,648 line reads into 4,194,304 lines
-(512 expected per line, 32,768 per 64-line segment). Mirror mismatches against `derive_items`: 0 of 268,435,456.
-Log: `log/b-lines-16days.log`; histograms `out/lines-d20730-n16-i24-none-buckets64.txt` (65,536 rows) and
-`out/lines-d20730-n16-i24-none-full.u32le` (4,194,304 x u32).
-
-| Histogram | Bins | Expected | Largest | Sigma | Smallest | Sigma | chi2/dof | Top 1% share |
-|---|---|---|---|---|---|---|---|---|
-| Pooled, 64-line buckets (the gate) | 65,536 | 32,768 | 33,645 | +4.84 | 31,998 | -4.25 | 1.00226 | 1.01427% |
-| Pooled, full 2^22 lines | 4,194,304 | 512 | 639 | +5.61 | 402 | -4.86 | 0.99937 | 1.11979% |
-| Control, 64-line buckets | 65,536 | 32,768 | 33,524 | +4.18 | 31,960 | -4.46 | 0.99930 | 1.01426% |
-| Control, full 2^22 lines | 4,194,304 | 512 | 639 | +5.61 | 408 | -4.60 | 0.99952 | 1.11956% |
-| Per round 0 to 7, full, pooled (64 per line) | 4,194,304 | 64 | 107 to 113 | +5.38 to +6.12 | 26 to 29 | -4.75 to -4.38 | 0.99855 to 1.00062 | 1.3483% to 1.3488% |
-| One day (20730), 64-line buckets | 65,536 | 2,048 | 2,291 | +5.37 | 1,859 | -4.18 | 0.99985 | 1.05826% |
-| One day, control, 64-line buckets | 65,536 | 2,048 | 2,250 | +4.46 | 1,874 | -3.84 | 1.00377 | 1.05901% |
-
-Per day, the gate bucket's largest value ran +4.00 to +5.37 sigma on all 16 days (control +4.46), every day within
-6 sigma. Hot-set test on the pooled lines: X_0.1% = -0.00002%, X_0.5% = +0.00010%, X_1% = +0.00023% (X/f under
-0.0003): clear. Round 0, whose input is the sequential item index through the init `t * MUL[i] + RC[i]` and eight
-mixer applications, is as flat as rounds 1 to 7 (chi2/dof 0.99926; its +5.50 sigma maximum is below the control's
-+5.61 at the pooled size). Round 5's +6.12 sigma at mean 64 is one bin of 4 million at a Poisson tail where the
-control at mean 8 reached +6.72; its chi2/dof is 0.99855.
-
-Gate line: the largest bucket is within 6 sigma of uniform (+4.84 on the 64-line buckets, +5.61 on the full 2^22
-lines, both at or below the control), chi2/dof 0.99937, no hot set. **PASS at 2^28 derivations.**
-
-## 4. Census 2 and 3: distinct lines per hash and warp, and the cross-hash item histogram
-
-Setup per program: the day's 16,777,216 items derived once into a table with their 8 lines (6 to 9 s on 12 threads,
-0 mismatches against `derive_items` on every item), then the warps interpreted from the table at 2.7 to 3.2 ms per
-warp per thread. Logs: `log/c-warps-p{1,2,3}-1e6.log` (first run, flat null) and `log/e-warps-p{1,2,3}-1e6.log`
-(windowed null, section 4.2); distributions `out/warps-<program>-d20730-n1000000-none-distinct.txt`, item histograms
-`...-items.u32le` (16,777,216 x u32), per-position tables `...-positions.txt`.
-
-### 4.1 Distinct lines and items per hash and per warp (10^6 nonces each)
-
-| Program | Epoch seed / era seed | Lines per hash min / p1 / median / max / mean | Items per hash min / median / mean | Lines per warp min / median / max / mean | Items per warp min / median / mean |
-|---|---|---|---|---|---|
-| p1 `c120d7963abdcd96` (devnet epoch 0) | genesis / genesis | 1,008 / 1,023 / 1,024 / 1,024 / 1,023.867 | 126 / 128 / 127.9989 | 32,579 / 32,636 / 32,680 / 32,635.84 | 4,090 / 4,096 / 4,095.41 |
-| p2 `82f0696f823e9c65` | `59cef1aa...bfdfa` / `9cba001f...1f69` | 1,014 / 1,023 / 1,024 / 1,024 / 1,023.871 | 127 / 128 / 127.9995 | 32,580 / 32,637 / 32,684 / 32,636.08 | 4,091 / 4,096 / 4,095.48 |
-| p3 `e282eed7d47e425e` | `c54e2ddd...c95d` / `1b04f607...b58a` | 999 / 1,016 / 1,024 / 1,024 / 1,023.600 | 125 / 128 / 127.9656 | 32,276 / 32,481 / 32,601 / 32,480.32 | 4,050 / 4,076 / 4,075.85 |
-| Uniform expectation | | 1,023.875 of 1,024 | 127.9995 of 128 | 32,640.3 of 32,768 | 4,095.50 of 4,096 |
-
-Per hash, every program reads its 128 items and 1,024 lines as the design intends (p1 and p2 at the uniform
-expectation; p3 a shade under, 127.97 items, which is the same site-15 effect as the finding below: the saturated
-site repeats an item inside a hash 3 times in 100). Per warp, 32 lanes read 32,636 distinct lines of 2^22, a 2 MiB
-working set of cache lines and 256 KiB of dataset items, within 0.01% of uniform on p1 and p2.
-
-### 4.2 The cross-hash item histogram and the window layer
-
-The era layout's window layer (`docs/plans/era-layout.md` section 1.4, layer 8) makes each load site read an
-aligned half or quarter of the dataset with probability 2/3. The per-site item distribution is therefore not flat by
-design (the diagnostic's "worst bit" reads P(1) = 1.0000 or 0.0000 at every windowed site: the fixed top bits), and
-the summed item histogram has density steps between quarters. For p1 the 16 windows (site:shrink:offset
-`7:2:1 8:1:1 9:1:1 10:1:1 11:0:0 13:1:1 29:0:0 30:2:2 31:1:1 44:1:1 46:2:0 47:0:0 52:0:0 56:0:0 58:2:0 63:1:1`) give
-expected reads per item by quarter of 3.25 : 2.25 : 5.75 : 4.75 in sixteenths of the flat value. Against a flat
-uniform the 64-item buckets of p2 (a program without the finding) read +10.03 and -9.06 sigma, which is the window
-layer and not a flaw. The item tests are therefore judged against the **window-weighted null**: the expected count of
-every item from the program's 16 windows, and a control that draws each read from a uniformly chosen site's window.
-A chip gains nothing from the window steps: the union of the windows is the whole dataset every hour (era-layout.md
-section 7), the floor window is 2^26 words (256 MiB), and which quarter is dense changes with the program.
-
-#### The window model (reproducible by the firms)
-
-For load site s with window draw `(k_s, o_s)` at the 2^28-word dataset: `k = min(k_s, 28 - 26)`, the word window is
-`[o_s << (28 - k), (o_s + 1) << (28 - k))`; the item window is `[o_s << (24 - k), (o_s + 1) << (24 - k))` of
-`2^(24 - k)` items (the four interleave positions all lie below bit 16, so the top bits of the word index are the top
-bits of the item index). The expected reads per item is `E[t] = sum over sites s with t in window_s of N x 8 / 2^(24 - k_s)`
-for N nonces (8 iterations per site), a density constant on each quarter of the item space. The windowed control draws
-each of the N x 128 reads as (site = read index mod 16, item uniform on that site's window). Both controls are drawn from
-SplitMix64 with a fixed seed. The tests on items are run against E[t] (chi-square, sigma of the largest and smallest
-64-item bucket) and against the windowed control (the top-f shares); the flat uniform numbers are kept beside them as
-what an auditor sees first.
-
-#### Results, 10^6 nonces per program, 128,000,000 reads (`log/e-warps-p{1,2,3}-1e6.log`)
-
-| Program | Windows (k_off:offset per site) | Quarter densities (reads per item) | Buckets64 largest sigma, windowed (control) | chi2/dof windowed (control) | Top 0.1% share: real / window control / flat control | Ratio to window control at 0.1% (gate 1.2x) | Ratio to flat control | Hot set (X_f >= f) |
-|---|---|---|---|---|---|---|---|---|
-| p1 devnet epoch 0 | 2:1 1:1 1:1 1:1 0 1:1 0 2:2 1:1 1:1 2:0 0 0 0 2:0 1:1 | 6.20 / 4.29 / 10.97 / 9.06 | +45.77 (+4.95) | 1.2336 (0.9981) | 0.5458% / 0.2891% / 0.2429% | 1.888x BEYOND | 2.247x | yes at 0.1% (X/f 2.57) and 0.5% (1.20); not at 1% (0.46) |
-| p2 | 2:0 1:0 0 0 2:3 2:2 1:0 0 2:3 0 0 0 0 1:1 2:0 0 | 9.54 / 5.72 / 6.68 / 8.58 | +4.59 (+4.64) | 1.0061 (0.9986) | 0.2716% / 0.2639% / 0.2429% | 1.029x within | 1.118x | no (X/f 0.08, 0.05, 0.05) |
-| p3 | 1:0 0 0 2:2 0 0 1:0 1:0 1:0 2:2 2:2 1:1 0 0 0 0 | 7.63 / 7.63 / 10.49 / 4.77 | +12,245.66 (+5.06) | 907.67 (0.9993) | 4.5954% / 0.2792% / 0.2433% | 16.46x BEYOND | 18.92x | yes at every f (X/f 43.2, 9.9, 5.0) |
-
-p2 is what the class is designed to be: against the window model its largest bucket is +4.59 sigma (the control +4.64),
-chi2/dof 1.006, the top 0.1% of items hold 1.029x their window-model share, and the flat-control ratio of 1.118x is
-the window layer. p1 and p3 are the finding (section 5). The one-epoch histogram at 2^26 nonces (8,589,934,592 reads,
-512 per item, `log/d-warps-p1-2e26.log`, flat null): p1's top 0.1% hold 0.5199% of reads against 0.1152% flat
-control (X/f 4.05), the top 1% 2.4946% against 1.1198% (X/f 1.37), item 0xca5b92 78,479 reads at a mean of 512, and
-site 15 feeds 6.37% of its reads into the top 0.1% in each of the 8 iterations; the excess grows with N as the
-control's chance excess shrinks, which is the signature of a structural skew. Distinct lines and items per hash and
-per warp at 2^26 nonces: 1,023.866 / 127.9989 / 32,635.6 / 4,095.41, unchanged from 10^6.
-
-## 5. AP-F8-1: a saturated load source makes a cross-hash hot set (FINDING)
-
-**What**: an accepted class v4 program can read one load site from a register whose last writes after its last
-injecting write are `or` (and, mildly, `mul`), so the site's address has fewer than 32 bits of entropy across nonces
-and the same items are read by many hashes. The per-hash figures (128 distinct items, 1,024 lines) stay intact; the
-cross-hash item histogram does not. It is not the window layer (p2 shows the window layer alone is clean against its
-model) and not the shadow block (iteration 0's load, which runs before any shadow block, is as hot as iterations 1 to
-7: p1 6.372% vs 6.371% to 6.378%; p3 71.9% vs 72.4% to 72.6%).
-
-**Where it hides from rule (c)** (`accept.rs`, 2,048 evaluations of the base program): the tests are constant bits
-in FINAL register values, one address in ALL 32 lanes of a unit, saturated FINAL values, output-bit bias, and distinct
-addresses WITHIN a hash. A site whose address is concentrated across hashes but refreshed before the end of the
-iteration passes every one. Rule (a) accepts any write, `or` included, as the refresh between two loads from the same
-register (`check_stale_loads`); `Op::injects` (add, sub, xor, mad, shfl, load) is only used by rule (b), once per
-register per program.
-
-**The index derivation at the hot site** (the "writers back to the last injecting one" lines of `log/e-warps-p*.log`):
-
-| Program | Hot site | Source | Writes after the last injecting write | Site's reads into the top 0.1% of items (flat expectation) | Index entropy, 256-item buckets (uniform on window) | Saturated source (x = 0 or 2^32 - 1) | Most repeated address at one position in 2,048 evaluations (uniform: 1 to 2) |
-|---|---|---|---|---|---|---|---|
-| p3 | site 15, instr 62 | r5 | `load@17` then `or@19`, `or@30` | 72.43% (0.10%) | 13.411 bits (16) | 1.368% | 44 of 2,048; 32 saturated |
-| p1 | site 15, instr 63 | r6 | `add@51` then `rotl@53`, `or@61` | 6.93% (0.11%) | 14.985 bits (15) | 0.005% | 2 of 2,048; 0 saturated |
-| p2 (clean) | every site | | injecting, or bijective (`rotl`), or `mul`/`mulhi` | 0.41% to 0.97% (0.20%; the window densities) | 13.999 / 14.997 / 15.994 bits (14 / 15 / 16) | 0.000% | 2 of 2,048; 0 saturated |
-
-In p3 two `or`s on r5 after its load make the source 1 with probability 7/8 per bit; x = 2^32 - 1 in 1.37% of
-evaluations and the images of the near-saturated values under the stride (`y = rotl(x * M, R)`, 256 x-values per
-item) pile onto a few items: 0xffdf69 takes 213,913 of the site's 8,000,000 reads (2.67%), the top 0.1% of items
-72.4%, and 4.6% of ALL reads of the hash land on 0.1% of the items. In p1 one `or` after `rotl(add)` gives 3/4 per bit
-on the ORed positions: no saturation to speak of (0.005%), but 6.9% of the site's reads on 0.11% of the items (the
-hot items share the low 20 bits `5b92`: 0xca5b92, 0x8a5b92, 0xaa5b92, 0xba5b92, 0x825b92, 0xe65b92, 0x985b92), a
-2.6x proportional excess at f = 0.1%. p2's `mul` sites (10, 13: `mul` after a load or a shuffle) read 0.65% and 0.70%
-into the top 0.1% against 0.41% and 0.48% for their window class (an even multiplier zeroes low bits; the hot items
-0xd6a680, 0xe44400, 0xd25600 end in zero bits), a mild effect that the window-model ratio (1.029x) absorbs.
-
-**How common** (the seed census, 64 chain-shaped programs p4 to p67, 262,144 nonces each, `log/e-seed-census-4-67.log`,
-`out/seed-census-d20730-n262144-p4-67.txt`): CENSUS-LINE
-
-**Reproduction**: `attack-f8 warps --program 3 --nonces 1000000 --diag 1` (or `--program 1`); the acceptance-style
-numbers come from the same run's "acceptance-style" line. The program is `Epoch::chain_program(epoch_seed, Some(era),
-ProgramClass::V4, label)` with the seeds of section 4.1.
-
-**Proposed fix** (not applied; `igneum-pow` untouched, the Counter ASIC lane re-gates on `ca3-v4-uniform` with this
-harness):
-
-1. Rule (a'), static: between the last injecting write of a load's source register and the load (cyclically), no
-   `or` and no `mul` writes that register; `rotl`, `rotr` and `mulhi` may (bijective, or measured flat: p2 site 15
-   reads `mulhi` after `add` at 1.00x). This rejects p1 and p3 at draw time and costs nothing at run time. Programs
-   rejected are redrawn as today (`MAX_ATTEMPTS` 32); the census gives the rejection rate.
-2. Rule (c'), dynamic, the same 2,048 evaluations: no load site reads a saturated source (0 or 2^32 - 1) in more
-   than 2 evaluations, and no address repeats more than 4 times at one position (uniform expectation 1 to 2; p3 shows
-   44 and 32). This catches the strong class only; p1's class needs about 2^16 evaluations to show at a site (65,536
-   nonces: largest item count 67 at a mean of 0.5), so (a') is the rule that closes it and (c') is the check that
-   fails loudly if (a') is ever loosened.
-3. Packs re-cut for the seeds the new rule rejects (the devnet epoch-0 program p1 is one of them: its site 15 is
-   `or@61`), with the gate pack ids re-pinned; the chain's own epochs redraw automatically.
-
-**Reuse for F9**: the hot-set metric (section 2) on the per-program item histogram at 2^18 nonces, and the
-acceptance-style pair (most repeated address at a position, saturated sources at a position) at 2,048 evaluations,
-are both emitted by `warps --programs a..b`; a header-grinding search that steers a program to a hot set would show as
-ratio-to-window-model above 1.2x at f = 0.1%.
-
-## 6. Consequences per tier
-
-| Number | What it means | Per tier |
-|---|---|---|
-| Line index uniform at 2^28 derivations (largest segment +4.84 sigma, chi2/dof 0.99937) | the 256 MiB cache has no hot segment: a chip or a card cannot serve the 8 dependent reads of an item from a cache smaller than the whole 256 MiB (the floor window of era-layout.md) | no change for any card; the verifier's cache stays 256 MiB in RAM on every node |
-| Distinct lines per hash 1,023.87 of 1,024, items 127.999 of 128 (p1, p2); per warp 32,636 lines, 4,095 items | the per-hash working set is 64 KiB of cache lines and 8 KiB of items, per warp 2 MiB of lines and 256 KiB of items; the item-derivation chip's "128 items per hash" input (`chip-model-v3.md`) stands | the 8 GB card and up: unchanged; the recompute chip pays 128 derivations per hash, as modelled |
-| p3-class programs: 4.6% of all dataset reads on 0.1% of items (1 MiB of a 1 GiB dataset); p1-class: 0.59% on 0.11% | a stored-dataset chip with 1 MiB of on-die SRAM serves 4.6% of its reads without touching DRAM on such an epoch; a GPU's L2 (96 MiB on the 5090, 64 MB Infinity Cache on the 9070 XT, vendor figures) holds the same 1 MiB, so both sides gain the same 4.6% of reads and the chip's edge from it is about 0 (the per-joule edge of `evidence.md` row 17 is a DRAM-read figure; a 4.6% read saving on both sides moves it by under 5% on such epochs). The recompute chip (f = 0, SRAM cache) caches the derived hot items and skips up to 4.6% of its 128 derivations per hash on such epochs, a 4.8% rate gain on those epochs only | home cards 8 to 32 GB, rigs, pools: no action; a few percent of epochs run a few percent faster for everyone with an L2. The verifier: `MemhardCpu::fetch` dedupes within a fetch only, so no change. The chip model: the headline 2.1x at k = 1 moves by under 5% on affected epochs and 0 on others; the fix below returns it to 0 everywhere |
-| The acceptance rule's blind spot (cross-hash concentration at one site) | a program class property, not a day or era property: the same seed is hot on every day and under every era, so a chip or a pool that selects epochs cannot gain more than the epoch's own 4.6%; but the public claim "the item map is uniform per program up to the window layer" is false for the affected fraction of seeds until rule (a') lands | the fix is a generator rule plus packs re-cut: a class change under the 95% signalling rule if it lands after the flip, a plain re-cut if it lands in the class v4 cut itself (the lane's call) |
-
-## 7. Gate line and verdict
-
-| Gate (plan 4.2 F8, the same as 1.4 (4)) | Result | Status |
-|---|---|---|
-| The largest bucket within 6 sigma of uniform on the stated sample sizes (line index, 2^28 derivations) | +4.84 sigma on 64-line segments, +5.61 on 2^22 lines (control +4.18 / +5.61), chi2/dof 0.99937 | PASS |
-| The item distribution within 6 sigma of uniform (against the window model, the design's own null) | p2 +4.59 sigma (control +4.64); p1 +45.77; p3 +12,245.66 | FAIL on p1 and p3 |
-| No hot set under 1% of items among passing seeds (10^6 nonces on three programs; the 64-seed census at 2^18) | p2 none; p1 top 0.1% at 1.888x the window model (2.247x flat), X/f 2.57; p3 16.46x (18.92x flat), X/f 43.2; census: 31 of 64 seeds over 1.2x of the window model, 23 with a hot item | FAIL |
-| The Counter ASIC lane's record gate: top 0.1% within 1.2x of the window-model control on every seed | p2 1.029x; p1 1.888x; p3 16.46x; census: 31 of 64 seeds over 1.2x (median 1.17x, p90 2.70x, max 13.09x on p31) | FAIL |
-
-**Verdict: FINDING (AP-F8-1).** The line index passes at 2^28 derivations. The cross-hash item histogram fails
-the hot-set gate on 2 of the 3 named programs (one of them the live devnet epoch-0 program) and on 31 of 64 seeds (48 percent) of of
-the 64-seed census, from `or` (and mildly `mul`) writes on a load's source register after its last injecting write,
-outside every test of rule (c). What it moves: not the mask or the fold (the derivation is uniform) but the
-acceptance rule, (a') and (c') above, and the packs re-cut. Ownership: the Counter ASIC lane (generator and rule),
-re-gated with this harness on the fixed branch; the row reads FIXED-AND-PASSED when every seed of the census passes
-both the hot-set test and the 1.2x gate under the new rule.
-
-Sample sizes reached: 2^28 derivations (lines); 10^6 nonces on three programs (distinct lines, hot set); one epoch at
-2^26 nonces (cross-hash histogram); 64 seeds at 2^18 nonces (the census).
-
-Times UTC in the logs; the runs ran 08:13 to 09:2x UTC on 7 October 2026 (09:13 to 10:2x UK).

docs/analysis/attack-pass/f9-grind.md

@@ -1,269 +0,0 @@
-# F9: acceptance edges, the hot-set search, header grinding
-
-Attack-pass row F9 of `docs/plans/cryptanalysis.md` section 4.2 (record: `docs/analysis/attack-pass-2026-10.md`).
-Sub-agent attack-f9, 7 October 2026. Status: IN PROGRESS (rewritten as each run lands; the numbers below are the
-ones already final, each with its log).
-
-## Target
-
-| Item | Value |
-|---|---|
-| Commit | 924288d1 (branch attack-pass, worktree igneum-wt-attack) |
-| Generator | 4, class v4 `mx8+sh256x27` composed with the era draw (`LoadClass::era(V4_CLASS, E, [4 bytes])`), era seed E = the devnet epoch-0 seed `edc4fa84...fb07` (`proto-cuda/packs-ca3-v4/v4-devnet-epoch0/seeds.txt`) |
-| Rule | `igneum-pow/src/accept.rs`: (a) stale load sources, (b) injecting writes, (c) the 2,048-evaluation dynamic test on the closed-form stand-in `dataset_elem` at 2^28 words with init words = seed words; redraw on rejection up to 32 attempts |
-| Header binding | `igneum-pow/src/bind.rs`: init words `I = seed_words_from_bytes("igneum-block/" \|\| H \|\| nonce_hi_le32)`, one `I` per 32-lane warp, the lane nonce in the low 32 bits |
-| Memory-hard dataset for the edges | the devnet day 20730 (`day_seed_hex 69676e65756d2d6461792ffa50000000000000`), class v4 shape (mixer x8, cache 2^26 words, dataset 2^28 words), `Epoch::chain_dataset_day` |
-| Card | RunPod RTX 5090 (170 SMs, 32,120 MiB, driver 570.195.03, CUDA 12.8.1), pack `v4-devnet-epoch0` built there with `nvcc -O3 -arch=sm_120` |
-
-## Known-failed shape
-
-A seed grind that steers a program to a hot cache set for DRAM locality, or an edge where the closed-form stand-in
-disagrees with the live verifier in the attacker's favour.
-
-## Gate
-
-Zero passing programs with a hot set under 1 percent of items among 10^6 seeds; the grinding gain under 1 percent of
-rate at any search cost. What a failure moves: the closed-form stand-in replaced by the live verdict at the edges; a
-locality term in rule (c).
-
-## Harness
-
-`tools/attack/f9-grind/` (crate `attack-f9`, `igneum-pow` as a path dependency, nothing in igneum-pow edited; built
-on igneum-build-1 through `tools/build-remote.sh`; the binary on the box at
-`/srv/builds/igneum-wt-attack/tools/attack/f9-grind/target/release/attack-f9`):
-
-| Sub-command | What it does |
-|---|---|
-| `selftest` | the firings listed below |
-| `edges` | sub-row (a): every candidate of every seed through the re-implemented dynamic test twice, closed form and memory-hard, every metric of rule (c) measured to the end (no early abort) with its margin; the attempts continue until both stand-ins have accepted, so the chosen program under each is known |
-| `hotset` | sub-row (b): the seed's accepted program, its 2,048 x 128 address record under the acceptance init and under a block init; per site the nonce-independent address bits, the distinct addresses and the most-read address; the histogram at bucket scales 2^8 to 2^24 words against a window-aware Poisson expectation (the era windows send a site to the dataset, a half or a quarter of it) with a Bonferroni tail; the taint count of init-determined loads |
-| `inspect` | one seed's program with every site that repeats an address |
-| `grind`, `table-random` | sub-row (c), CPU side: the init-determined load sites of the devnet epoch-0 program, the per-warp search over K nonce_hi values for the fewest distinct 128 B lines inside those load instructions (`--mode intra`, what the coalescer merges) or across them (`lines`, `pages`), the search cost per hit, and the per-warp init tables the card reads |
-| `reference` | the 64 bound hashes the card's known-pass compares against; the file used on the pod came from the pre-built `igneum-pow hash-bound` instead (`ref.txt`, sha256 e831458a...) |
-| `summarise.py` | the census summaries quoted below |
-
-`tools/attack/f9-grind/pod/` (the card): `make-variants.py` copies the pack's `kernel_bound.cu` into five kernels
-(per-warp init table; the five init-determined loads broadcast to lane 0's address; every load broadcast; the first
-such load broadcast; lane 1 reading lane 0's address at the first such load), `f9-host.cu` fills the cache and dataset
-with the pack's own kernels, checks them against `vectors.h`, checks the bound hash against the reference, checks the
-per-warp kernel on an all-equal table against the honest kernel, then times the eight variants in interleaved rounds;
-`run.sh` builds on the pod, samples `nvidia-smi` once a second and joins the samples to the phases (`join-power.py`).
-
-Hot-set metric (F8's record `docs/analysis/attack-pass/f8-uniform.md` did not exist when this harness was written, so
-the metric is defined here). Strict reading, "any hot bucket": a site with 7 or more nonce-independent address bits
-(support at most 2^21 of 2^28 words, 0.78 percent of items; the window's own fixed bits not counted), or any bucket
-of at most 2^20 words (0.39 percent of the dataset) at scales 2^8, 2^12, 2^16, 2^20 whose count has a Poisson tail
-against its window-aware expectation under 10^-6 after the Bonferroni correction. Gate reading, "flagged": the reads
-above expectation in those hot buckets (the hot share, what a cache of the hot set saves at most) reach 1 percent of
-the program's reads, or a site has 7 constant bits.
-
-## Firings (the harness is trusted only after these)
-
-Log: `/srv/builds/igneum-wt-attack/attack-f9/selftest.log` (copy in the Mac scratchpad `f9-box/selftest.log`).
-
-| Check | Known-pass | Known-fail | Result |
-|---|---|---|---|
-| 1 | the re-implemented dynamic test against `accept::check` on 300 class v4 candidates: every verdict, the first failing condition, and distinct, saturated and bias of every accepted report equal | | PASS (300 candidates, 16 rejected by accept, all equal, 1.5 s) |
-| 2 | both stand-ins forced equal (closed form twice) on 200 candidates | | PASS, 0 disagreements |
-| 3 | | the memory-hard stand-in gives different words: distinct 262,117 against 262,106, bias 56 against 64 on one program | PASS (they differ) |
-| 4 | 50 accepted programs, none with 7 constant bits (worst 0) | 50 plants (an accepted program rewritten to `xor a,a; add a,a,256; mulhi a,b` before a load from `a`, 48 of 50 still pass rule (c)) all flagged (support 256 words, site distinct 255 or 256) | PASS for the plant; 4 of the 50 clean programs have a hot bucket (sub-row (b): that is the finding, not a harness fault) |
-| 5 | taint on the devnet epoch-0 program against the hand reading of `kernel_bound.cu`: loads 7, 8, 9, 10 read r7, r4, r2, r0 (no load before them); load 31 reads r5 = r5 x r4 from instruction 12, both untouched by any load; loads 11, 13, 29, 30 read r1, r6, r4, r3, each written by an earlier load or by `mad` from r7 after load 10 | | PASS: sites (0,7) (0,8) (0,9) (0,10) (0,31) |
-| card 1 | cache FNV 448274a57f508cbc, dataset head, last word and 64 samples, the 96 pack vectors | | PASS (`pod log/host.log`) |
-| card 2 | the bound hash against the 64 reference lines of `igneum-pow hash-bound` (nonce_hi 0, prehash 000102..1f) | | PASS, 0 wrong |
-| card 3 | the per-warp kernel on an all-equal table equals the honest kernel on 64 lanes | the two-init table: warp 0 equal, warp 1 differs in 32 of 32 lanes | PASS both |
-| card 4 | | the forced kernels change the hash: forced4 64 of 64 lanes, forcedall 64, forced1 64, pair 64 | PASS (they fire) |
-| card 5 | | a deliberately locality-maximising choice shows a measurable change: `pair` (one line of 4,096 saved per warp) +0.21 percent, `forced1` (31 lines) +6.8 percent, `forced4` (155 lines) +43.3 percent, `forcedall` +181.9 percent in the smoke run | PASS (measurable from one saved line up) |
-
-## Sub-row (a): the edges
-
-Run: `attack-f9 edges` over seeds `igneum-f9/0` to `igneum-f9/99999`, 8 threads on cores 28-31,76-79 in 10,000-seed
-chunks under a shared hold of the box measure lock (`run-census.sh`); output `edges.part*.tsv`, summary by
-`summarise.py edges`. The first 20,000 seeds (parts 0 and 1) are summarised here; the full 10^5 replaces this table
-when the run ends.
-
-| Quantity | First 20,000 seeds |
-|---|---|
-| Candidates evaluated | 21,020 |
-| Verdicts agreeing | 21,007 |
-| Disagreements | 13 (0.062 percent of candidates; the 3 October census had 39 in 100,000 on its generator) |
-| Seeds whose chosen program differs | 13 (every disagreement moves the chosen attempt, because the next attempt was accepted by both) |
-| Exhausted seeds | 0 on either stand-in |
-| Rejected by the closed form / by the memory-hard dataset | 1,013 / 1,014 (850 static, the rest (c)) |
-| First failing (c) condition, closed form | const_bit 80, saturated 54, distinct 24, lane_const 4, bias 1 |
-| Accepted margins, closed form | saturated at most 81 of 164, bias at most 120 of 136, distinct sum at least 247,335 (bound 245,760), nearly constant final bits up to 2,047 of 2,048 |
-| Accepted margins, memory-hard | saturated at most 82, bias at most 115, distinct at least 247,678 |
-
-The 13 disagreements: 12 are `const_bit`, a final register bit equal in all 2,048 evaluations on one dataset and in
-2,044 to 2,047 of them on the other (7 where the closed form accepts, 5 where the memory-hard dataset accepts); 1 is
-`bias`, output bias 155 against 93 (6.9 against 4.1 sigma, the two draws' difference 2.7 sigma of sampling noise),
-where the memory-hard dataset accepts. No disagreement on saturation, lane-constant sites or the distinct count: those
-metrics are the same to within 20 on both datasets. What an attacker gains from a program the closed form accepts
-and the live dataset would reject: a register whose final bit is pinned in 2,047 of 2,048 hashes instead of 2,048,
-which no test downstream of the fold can see (the 64 output bits stay within 120 of 1,024 on every accepted program)
-and which no chip can turn into skipped work; the reverse direction loses the chain a program with one pinned bit.
-Either way the chosen program moves to the next attempt, which both stand-ins accept. Nothing in the attacker's
-favour: the verdict's dependence on the stand-in is a 0.06 percent coin flip on a one-bit property.
-
-## Sub-row (b): the hot-set search
-
-Run: `attack-f9 hotset` over seeds `igneum-f9/0` to `igneum-f9/999999`, 8 threads on cores 32-35,80-83 in
-100,000-seed chunks; output `hotset.part*.tsv`. A 2,000-seed timing sample (`hotset-timing.tsv`, seeds 5,000,000 to
-5,001,999) is summarised here; the 10^6 census replaces it when the run ends.
-
-| Quantity | 2,000-seed sample |
-|---|---|
-| Programs with any hot bucket (strict) | 161 of 2,000 (8.1 percent) |
-| Programs flagged at the gate reading (hot share at least 1 percent of reads) | 21 of 2,000 (1.05 percent) |
-| Worst hot share | 10.3 percent of the program's reads (seed 5,000,968) |
-| Sites with 7 or more constant address bits | 0 (max 0) |
-| Fewest distinct addresses at a site in 2,048 evaluations | 434 |
-| Most evaluations reading one address at a site | 767 of 2,048 |
-| Init-determined loads in iteration 0 (programs by count) | 1: 234, 2: 573, 3: 594, 4: 368, 5: 179, 6: 42, 7: 10; none after iteration 0 |
-
-FINDING F9-1 (or-saturation hot words). `inspect --seed 5000968` (`inspect-5000968.log`): the load at instruction 33
-reads r4; r4 is written by `or r4 |= r0` (20), `mulhi` (27) and `or r4 |= r6` (28), and r6 itself by `or r6 |= r7`
-(7). `or` is absorbing toward all ones: after two `or` writes from independent words every bit is set with
-probability 7/8 and the whole register with probability (7/8)^32 = 1.4 percent; chained across iterations the mass
-grows, and on this program r4 is 0xffffffff at that site in 731 to 739 of 2,048 evaluations in iterations 1 to 7
-(36 percent). The site then reads one word, `rotl(0xffffffff x M, R) & window | offset` = 0x0ca59e4c for a full
-window and 0x04a59e4c, 0x08a59e4c, ... for the windowed sites; near-all-ones values add a few hundred more. The
-same word family appears in every flagged program (seeds 4,000,001, 4,000,037, 4,000,040 in the selftest: `or`
-writes at 54 and 55 before the load at 60, or at 1 before the load at 3). Rule (c) does not see it: the saturation
-test counts final register values only (the register is overwritten before the end), the lane-constant test needs
-all 32 lanes equal, the distinct test counts per lane per hash (the hot word repeats across iterations, so it
-costs one distinct of 128), and the output bias stays within tolerance. The 3 October census measured an
-`or_sat_frac` per program (section 7.3, max 0.0102) but the adopted rule kept only the final-value count.
-
-What it is worth to an attacker: nothing asymmetric. The hot words are the same for every lane that saturates, so
-the GPU's coalescer and L1 already serve them without a DRAM transaction, and a chip gets exactly the same. What it
-costs the design: those programs do fewer memory-hard reads than rule (c) promises (up to 10 percent fewer on the
-worst program in 2,000, at least 1 percent fewer on about 1 program in 100), so the per-hash memory work of class
-v4 is not the uniform 128 random reads the chip model assumes on every epoch. Gate reading: FAIL in the strict
-reading (zero passing programs with a hot set under 1 percent of items), FAIL in the share reading too (programs
-with a hot set capturing at least 1 percent of reads exist at about 1 percent of epochs). Proposed fix, for the hash
-lane (not applied here): a per-site line in rule (c), "every load site reads at least 2,000 distinct addresses over
-the 2,048 evaluations" (uniform gives 2,048 minus 0.008 expected repeats; the saturated sites read 434 to 1,855),
-computed from the addresses the test already collects (one sort of 2,048 per site, 128 sites, under a millisecond);
-the redraw rate rises by about the strict-reading fraction (8 percent of candidates) unless the threshold is placed
-at the share reading. The alternative, dropping the `or` family from the draw table, changes the frozen weights and
-is for the lane to weigh. Class check: a chip gains nothing today, but a stand-in that lets 1 percent of epochs run
-with a 1 to 10 percent lighter memory side is a published-number problem (evidence row 17's per-hash reads).
-
-(the 10^6 numbers and the hot-share distribution replace the sample when the census ends)
-
-## Sub-row (c): header grinding
-
-### What an attacker can steer
-
-Only a load whose address register has not yet absorbed a dataset word is a function of the init words and the
-nonce alone (taint analysis, `init_determined_sites`). On the devnet epoch-0 program these are the loads at
-instructions 7, 8, 9, 10 and 31 of iteration 0; from iteration 1 every register is tainted. Over the 2,000-seed
-sample the count is 1 to 7 per program, median 3, always in iteration 0 only. Everything after depends on dataset
-words the miner must fetch first. The init words themselves are an FNV hash of the header and nonce_hi, so the
-attacker cannot choose them, only draw them; and one draw serves a whole warp (the shuffles couple the 32 lanes),
-so a per-lane draw costs 32 hashes per lane.
-
-### The search (CPU)
-
-`grind` draws K init words per warp (nonce_hi 0 to K-1 under the fixed prehash) and keeps the one with the fewest
-distinct 128 B lines among the init-determined loads. Each try costs 32 lanes x (8 init + 32 prefix instructions) =
-1,280 lane-instructions; the warp's hash costs 32 x (512 + 55,296) = 1,785,856 lane-instructions, the derivation
-not counted. Logs: `grind-k10-crosssite.log` (lines counted across the five sites: coincidences that are at best an
-L2 hit), `grind-k10-pages.log` (2 KB pages across the sites), and the `intra` runs (lines inside one load
-instruction, what the coalescer merges into one transaction) that feed the card.
-
-| Metric | K | Warps | Mean lines or pages saved per warp (of 4,096 loads) | Warps improved | Search per warp in hashes |
-|---|---|---|---|---|---|
-| lines across the sites | 2^10 | 524,288 | 0.895 (0.022 percent) | 89 percent | 0.73 |
-| 2 KB pages across the sites | 2^10 | 65,536 | 1.455 (0.036 percent) | 98 percent | 0.73 |
-| lines inside one instruction (intra) | 2^10 | 2^17 | (pending) | | 0.73 |
-| lines inside one instruction (intra) | 2^14 | 2^17 | (pending) | | 11.7 |
-
-### The card (RTX 5090)
-
-Smoke run (1 round of 2 s per variant, `pod smoke` logs): the calibration of what one saved line is worth.
-
-| Variant | What changes | MH/s | Against honest | W | MH/J against honest |
-|---|---|---|---|---|---|
-| honest | the pack kernel, one init per dispatch | 141.76 | | 482 | |
-| perwarp-random | per-warp init table, no search | 141.73 | -0.02 percent | 486 | -0.7 percent |
-| perwarp-k10 | per-warp table, best of 2^10 (cross-site table) | 141.74 | -0.01 percent | 487 | -1.0 percent |
-| perwarp-k14 | (the same table in the smoke run) | 141.74 | -0.01 percent | 488 | -1.1 percent |
-| pair | lane 1 reads lane 0's address at load 7: 1 line of 4,096 saved | 142.05 | +0.21 percent | 490 | -1.4 percent |
-| forced1 | load 7 broadcast: 31 lines saved | 151.39 | +6.8 percent | 506 | +1.8 percent |
-| forced4 | loads 7, 8, 9, 10, 31 broadcast: 155 lines saved | 203.11 | +43.3 percent | 530 | +30 percent |
-| forcedall | every load broadcast: 3,968 lines saved | 399.61 | +182 percent | 520 | +161 percent |
-
-Reading: the class v4 kernel on the 5090 is bound by its random reads (141.8 MH/s x 128 = 18.1 G reads per second,
-the card's measured random-read ceiling in `docs/bench-log.md`), and a load instruction completes when its slowest
-lane's transaction returns, so one saved line is worth about 0.2 percent of rate, 31 lines 6.8 percent, and the
-five init-determined loads fully coalesced 43 percent. That ceiling is unreachable by search: it needs the 32
-lanes' 28-bit addresses to fall in one line at five sites, probability 2^-115 per draw. What a draw can reach is one
-coalesced pair at one site (probability 5 x C(32,2) / 2^23 = 3 x 10^-4 per try, about 3,400 tries per pair);
-two pairs need about 6 million tries, m pairs about 3,400^m / m! tries. One pair is worth 0.2 percent of one warp's
-hash and costs 3,400 x 1,280 lane-instructions = 2.4 hashes of search. The measured per-warp tables (5 rounds of
-8 s, pending) are the direct check.
-
-(the full run's table replaces the smoke run when it ends)
-
-## Consequences per tier
-
-(filled in with the verdict)
-
-## Logs
-
-| Log | Path |
-|---|---|
-| selftest, inspect, grind, census parts and drivers | `/srv/builds/igneum-wt-attack/attack-f9/` on igneum-build-1 (`selftest.log`, `inspect-*.log`, `grind-*.log`, `edges.part*.tsv`, `edges.driver.log`, `hotset.part*.tsv`, `hotset.driver.log`, `hotset-timing.tsv`, `ref.txt`, `table-*.bin`) |
-| card smoke run and full run | the pod's `/workspace/f9/podjob/smoke/log/` and `log/` (`run.log`, `nvcc.log`, `host.log`, `power.csv`, `power-by-variant.txt`, `sha256.txt`), copied to `/srv/builds/igneum-wt-attack/attack-f9/pod/` at the end |
-
-### The card, the measurement (RTX 5090 pod ap-f9, `pod/host.log`, sha256 83b1372c..., copied to
-`/srv/builds/igneum-wt-attack/attack-f9/pod/`)
-
-Per-warp header grinding at K = 2^14 draws per warp against the honest kernel, 5 interleaved rounds of 8 s each:
-141.62 against 141.61 MH/s, +0.004 percent of rate, sd 0.003, at 11.7 hashes of search per hash. The unreachable
-ceiling (the five init-determined loads fully coalesced, `forced1` extended) is +43 percent. Gate: the grinding gain
-under 1 percent of rate at any search cost. Sub-row (c): PASS. Pod time about 1 h 50 min from 09:02 UK; destroyed on
-the lane's done line.
-
-## Full censuses (box 1 parts 0 to 7 and 0 to 6; box 2 parts `edges-b2`, `hotset-b2` after the lane's move to
-build-2 at 12:2x UK; `summarise.py` over all parts, 12:5x UK)
-
-### (a) The edges on generator 4, 10^5 seeds
-
-| Quantity | 100,000 seeds |
-|---|---|
-| Candidates evaluated | 105,064 |
-| Verdicts agreeing | 105,030 |
-| Disagreements | 34 (0.032 percent of candidates; the 3 October census had 39 in 100,000 on its generator) |
-| By kind | `const_bit` 29 (closed form accepts 17, memory-hard accepts 12); `bias` 4 (3 and 1); `lane_const` 1 (memory-hard accepts) |
-| Seeds whose chosen attempt differs | 34, every one moving to the next attempt, which both stand-ins accept; exhausted 0 on either |
-| Rejected, closed form / memory-hard | 5,046 / 5,048 (static 4,201; then const_bit 424 / 428, saturated 275 / 275, distinct 112 / 112) |
-| Accepted margins, closed form | saturated at most 148 of 164, bias at most 121 of 136, distinct sum at least 247,335 (bound 245,760) |
-| Accepted margins, memory-hard | saturated at most 157, bias at most 126, distinct at least 247,571 |
-
-The 20,000-seed reading holds at 10^5: the stand-ins disagree on a one-bit property (a final register bit pinned in
-2,047 of 2,048 hashes against 2,048) and on four programs' output bias within sampling noise, never on saturation
-or the distinct count, and never in the attacker's favour. Gate: the 39 edge disagreements reproduced and bounded.
-Sub-row (a): PASS.
-
-### (b) The hot-set search, 10^6 seeds
-
-| Quantity | 1,000,000 seeds |
-|---|---|
-| Programs with any hot bucket (strict) | 75,400 (7.5 percent) |
-| Programs flagged at the gate reading (hot share at least 1 percent of reads, or 7 constant address bits) | 11,696 (1.17 percent) |
-| Worst hot share | 17.3 percent of the program's reads (seed 842871) |
-| Hot-share bands (block init) | 0: 932,106; under 0.1 percent: 11,721; under 0.5: 3,645; under 1: 41,581; 1 percent and over: 10,947 |
-| Sites with 7 or more constant address bits | 0 (max 6) |
-| Fewest distinct addresses at a site in 2,048 evaluations | 43 |
-| Most evaluations reading one address at a site | 1,838 of 2,048 |
-| Mean hot share over programs | 0.063 percent |
-
-Gate: zero passing programs with a hot set under 1 percent of items. FAIL on the class v4 stream by the letter:
-11,696 passing programs concentrate 1 percent or more of their reads on a hot set. The mechanism is F9-1 above,
-the or-saturated load source, which is the same fault class the F8 row found from the cross-hash histogram
-(AP-F8-1: a load whose source's last writer is lossy); the two harnesses found it independently, one from the
-program's address trace per site, one from the item histogram across hashes. F9-1 therefore merges into AP-F8-1,
-and the fix is the amendment shipping in 0.3.20 (a load's source drawn only from registers whose last writer injects
-or is a rotate). Sub-row (b): FINDING (AP-F8-1 class); re-gated on the amended stream with this harness below.

docs/analysis/attack-pass/o114-i7-9700K-2026-10-07.log

@@ -1,53 +0,0 @@
-# O-1.14 bench start 2026-10-07T08:49:03Z host root@ssh9.vast.ai
-Warning: Permanently added '[ssh9.vast.ai]:35608' (ED25519) to the list of known hosts.
-Welcome to vast.ai. If authentication fails, try again after a few seconds, and double check your ssh key.
-Have fun!
-# binary copied, sha256 6d28678359d3d6bd158b245f7e522d6f2a5b0704d9997c0fb50ebc3471a9ebe5
-Welcome to vast.ai. If authentication fails, try again after a few seconds, and double check your ssh key.
-Have fun!
-# cpu:  Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz
-# cores: 8  mem: 31 GB
-# glibc: ldd (Ubuntu GLIBC 2.39-0ubuntu8.9) 2.39
-# clock MHz:  4169.856
- 08:49:07 up 20 days, 10:27,  0 user,  load average: 0.13, 0.07, 0.05
-## --class v2  08:49:07Z
-Welcome to vast.ai. If authentication fails, try again after a few seconds, and double check your ssh key.
-Have fun!
-cache: fill 283.0 ms on one core (2^26 words, 256 MiB, 65536 chains of 64 ChaCha12 blocks), FNV-1a 64 48c4f5bf24166b2e
-warp base 0: single cold run 1.582 ms, 4096 items derived, lane0 42246ba99fc58e4f lane31 b08446b1f2de7793
-warp base 4096: single cold run 1.392 ms, 4096 items derived, lane0 3d3903e310ca038f lane31 61c242509efdccdd
-warp base 1000000: single cold run 1.374 ms, 4096 items derived, lane0 f218c1bd58e6dfe0 lane31 6c3b2c11adfbfcac
-CPU verify: 1.280 ms per 32-lane warp, avg of 50 (checksum 19297e99c7b9a55e)
-## --class mx8  08:49:09Z
-Welcome to vast.ai. If authentication fails, try again after a few seconds, and double check your ssh key.
-Have fun!
-cache: fill 276.6 ms on one core (2^26 words, 256 MiB, 65536 chains of 64 ChaCha12 blocks), FNV-1a 64 48c4f5bf24166b2e
-warp base 0: single cold run 5.394 ms, 4096 items derived, lane0 19b56348bc85304d lane31 359192708e4f754a
-warp base 4096: single cold run 5.285 ms, 4096 items derived, lane0 62fb132a9943127a lane31 7d7866cb9cfca8ff
-warp base 1000000: single cold run 5.293 ms, 4096 items derived, lane0 86b6cb0e13d89b03 lane31 9c004678515e44ec
-CPU verify: 5.267 ms per 32-lane warp, avg of 50 (checksum 653a23f7ee1c8c63)
-## --program-class v4  08:49:11Z
-Welcome to vast.ai. If authentication fails, try again after a few seconds, and double check your ssh key.
-Have fun!
-cache: fill 276.6 ms on one core (2^26 words, 256 MiB, 65536 chains of 64 ChaCha12 blocks), FNV-1a 64 48c4f5bf24166b2e
-warp base 0: single cold run 6.334 ms, 4096 items derived, lane0 2576769ee4a14c8d lane31 c58ddcb717dd3370
-warp base 4096: single cold run 6.198 ms, 4096 items derived, lane0 1ce77a600ec573b4 lane31 03600a05ffba0055
-warp base 1000000: single cold run 6.174 ms, 4096 items derived, lane0 6b390e64bbdd91ce lane31 91c944d603539c62
-CPU verify: 6.006 ms per 32-lane warp, avg of 50 (checksum 17e36e7905b81375)
-## --class dr368  08:49:14Z
-Welcome to vast.ai. If authentication fails, try again after a few seconds, and double check your ssh key.
-Have fun!
-cache: fill 276.3 ms on one core (2^26 words, 256 MiB, 65536 chains of 64 ChaCha12 blocks), FNV-1a 64 48c4f5bf24166b2e
-warp base 0: single cold run 5.540 ms, 4096 items derived, lane0 c77c7625bbe0f452 lane31 c8e84ff2655d9934
-warp base 4096: single cold run 5.433 ms, 4096 items derived, lane0 7229bd981a5786ca lane31 1c5495083ae60453
-warp base 1000000: single cold run 5.430 ms, 4096 items derived, lane0 5533769c9cdbf0a7 lane31 2426905704457b11
-CPU verify: 5.426 ms per 32-lane warp, avg of 50 (checksum 94fcbf0a77e03bdc)
-## --class dr736  08:49:16Z
-Welcome to vast.ai. If authentication fails, try again after a few seconds, and double check your ssh key.
-Have fun!
-cache: fill 275.7 ms on one core (2^26 words, 256 MiB, 65536 chains of 64 ChaCha12 blocks), FNV-1a 64 48c4f5bf24166b2e
-warp base 0: single cold run 10.290 ms, 4096 items derived, lane0 e23d389f3eea0c83 lane31 6605db059b381bd9
-warp base 4096: single cold run 10.072 ms, 4096 items derived, lane0 fdb4b214da8ce292 lane31 db698d03437d74f7
-warp base 1000000: single cold run 10.056 ms, 4096 items derived, lane0 534671b1bf5cea36 lane31 733b123353f13d21
-CPU verify: 10.042 ms per 32-lane warp, avg of 50 (checksum bf79909c25836153)
-# O-1.14 bench end 2026-10-07T08:49:19Z

docs/analysis/block-rate-devnet2.md

@@ -1,6 +1,6 @@
 # Block rate on Devnet 2: 10 blocks per second against 1, on the rented fleet
 
-6 October 2026, the founder's experiment (through the coordinator, 17:5xZ): "Devnet 2 at a higher block rate for solo miners
+6 October 2026, the project lead's experiment (through the coordinator, 17:5xZ): "Devnet 2 at a higher block rate for solo miners
 (Kaspa's answer)". Branch `gpu-fleet`; the node profile on the fork branch `devnet2-bps` (1279a1d6 on release-0.3.14-node
 4c6b129d): a suffixed devnet started with `IGNEUMD_DEVNET_BPS=10` (or 5) runs `BlockrateParams::new::<10>()` with the
 TenBps subsidy and target time, Kaspa's Crescendo-style constants for that rate (k 124, merge depth, sample rates,

docs/analysis/ca3-v4-uniform.md

@@ -1,62 +0,0 @@
-# AP-F8-1 under the windows-union model: the hot set is the load source, not the window (7 October 2026)
-
-Branch `ca3-v4-uniform` from master b92a5fd4, worker "v4-hash", on the attack-pass finding AP-F8-1 (`docs/analysis/attack-pass/f8-uniform.md`, branch attack-pass; logs `/srv/builds/igneum-wt-attack/target-attack-f8/log/`). Main's rulings bound this file: no generator change to class v4 on the live devnet; the analysis and its harness only. Every GPU-free number here is arithmetic on F8's logged counts or a run of the static census tool `tools/ca3-v4-uniform/` on igneum-build-1 (built through `tools/build-remote.sh`, rule R1); the chip figures are the terms of `docs/analysis/chip-model-v3.md` and are approximate.
-
-## 1. The null F8's numbers must be read against
-
-Layer 8 (`docs/plans/era-layout.md` 1.4, spec 01 1.13.1 as proposed) gives every load site a window draw `k_off = below(3)`: the site reads the whole dataset, an aligned half or an aligned quarter, at a 2^26-word floor. A quarter-window site concentrates its reads 4x on its quarter and a half-window site 2x on its half, by design; the union of the 16 windows is the whole dataset. For p1 (the devnet epoch-0 program, id c120d7963abdcd96) the 16 draws `0:2:1 1:1:1 2:1:1 3:1:1 4:0:0 5:1:1 6:0:0 7:2:2 8:1:1 9:1:1 10:2:0 11:0:0 12:0:0 13:0:0 14:2:0 15:1:1` (site:k:offset) give an expected read density by quarter of 3.25 : 2.25 : 5.75 : 4.75 sixteenths of the flat mean, which at 2^26 nonces (512 reads per item flat) is 416, 288, 736 and 608 reads per item. The top-f share of a Poisson mixture with those means (`uniform-model.txt`, exact Poisson for p1, a normal approximation for the census):
-
-| Share of all reads on the top f of items, 2^26 nonces | Flat Poisson (F8's control) | Windows-union model, p1 | F8 measured, p1 | Beyond the window model |
-|---|---|---|---|---|
-| f = 0.1 percent | 0.115 | 0.160 | 0.520 | +0.36 |
-| f = 0.5 percent | 0.565 | 0.784 | 1.515 | +0.73 |
-| f = 1 percent | 1.120 | 1.553 | 2.495 | +0.94 |
-
-So the window model moves the null from 0.115 to 0.160 percent at f = 0.1 percent (1.39x, not F8's 4.05x) and from 1.12 to 1.55 at f = 1 percent; it explains the 64-item-bucket sigma of p2 that F8 already attributed to the window layer, and it explains every per-site attribution row of p1 except one: sites with a half window over the hot region land 0.20 percent of their reads in the top 0.1 percent (sites 1, 2, 3, 5, 9 at 0.201), quarter-window sites 0 or about 0.4 (sites 0, 10, 14 at 0.000, site 7 at 0.241 straddling), whole-dataset sites 0.10. Site 15 lands 6.374 percent. The excess over the model (+0.36 at f = 0.1 percent) is one site.
-
-## 2. The 153x item is the load source, and the model predicts it to the item
-
-p1's site 15 is the load at instruction 63 (`load dst=3 src=6`, window half 1). Its source r6 was last written at instruction 61: `or dst=6 src=4` (`r6 |= r4`, `verify.rs` Op::Or), after a fresh dataset load into r6 at 47. An OR of two near-uniform registers sets each bit with probability 3/4, so the source takes the all-ones value with probability (3/4)^32 = 1.0e-4 per read and the values of popcount 31, 30, ... with 32, 496, ... times (3/4)^k (1/4)^(32 - k). The era map `y = rotl(x * 0x9ad30d99, 29)`, the half window and the interleave split (`memhard::Layout::split`, positions 0, 2, 12, 13) send x = 0xffffffff to item 0xca5b92: F8's hottest item exactly. F8's next seven items (0x8a5b92, 0xaa5b92, 0xba5b92, 0x825b92, 0xe65b92, 0x985b92, 0xbcc392) are exactly the seven one-zero-bit sources whose zero bit survives the window mask (bits 29, 28, 27, 26, 25, 24 and 15): 7 of 7. The measured count fixes the bit bias: 78,479 reads of 2^26 x 8 site-15 reads is p^32 at p = 0.7585 (r4 is slightly biased itself), and at that p the popcount model predicts 77,348 all-ones reads and 4.86 percent of site 15's reads into the top 0.1 percent of items (measured 6.37; 3.92 at p = 3/4). Per hash that is 4.86 / 16 = 0.30 percent of all reads, and 0.160 + 0.30 = 0.46 against F8's 0.520 at f = 0.1 percent; at f = 1 percent 14.5 / 16 = 0.90, and 1.55 + 0.90 = 2.46 against 2.495.
-
-The same arithmetic for the other lossy writers (`uniform-model.txt`): a `mul` last writer zeroes the low bits by the operands' trailing zeros, so 1.07 percent of the site's reads land on the 0.1 percent of values with 10 or more trailing zeros (p2's `mul`-sourced sites 0 and 14 measured 0.971 and 0.966 percent); a `mulhi` last writer is dense near zero, 0.79 percent on the lowest 0.1 percent of values. An `or` whose operand was itself last written by `or` compounds the bias (3/4 to 7/8 to 15/16): p3's site 15 (`or` at 30, the load at 62) puts 72.4 percent of its reads into the top 0.1 percent, 4.6 percent of all reads on 16,777 items.
-
-This is a fault class, not the window model: the acceptance rule's part (a) (`accept.rs` check_stale_loads) takes any write as a fresh source, and part (c)'s saturation count looks at the 16,384 final register values, not at a load's source mid-program, so an `or`, `mul` or `mulhi` as a load's last writer passes. The per-hash distinct-address check still holds (p1 127.999 items per hash; p3 127.97: a saturated site repeats its item inside a hash), and the acceptance rule's floor of 120 distinct of 128 admits exactly one site repeating its item in all 8 iterations and no more.
-
-## 3. How common it is: the static census (`tools/ca3-v4-uniform`, 1,024 chain-shaped class v4 programs plus F8's p1 to p3)
-
-For every load site, the op that last wrote its source in execution order (base instructions before it, else the shadow block of the previous iteration, else the base instructions after it): injecting (add, sub, xor, mad, shfl, load), bijective (rotl, rotr) or lossy (or, mul, mulhi). Run on igneum-build-1 (`uniform-census.txt`, binary sha256 ce9f83fe... then the narrowed chain rule).
-
-| Census over 1,024 programs | Count | Share |
-|---|---|---|
-| Load sites by last writer: injecting / bijective / lossy | 11,368 / 2,121 / 2,943 of 16,432 | 69 / 13 / 18 percent; 2.87 lossy sites per program |
-| Programs with at least one lossy-sourced load | 992 | 96.6 percent |
-| ... with an `or`-sourced load (p1's class, 0.30 percent of all reads per site) | 498 | 48.5 percent |
-| ... with an `or`-of-`or` chain (p3's class, about 4.5 percent of all reads per site) | 50 | 4.9 percent |
-| ... with a `mul`-sourced load (0.067 percent per site) / a `mulhi`-sourced load (0.049) | 751 / 661 | 73.1 / 64.4 percent |
-| Predicted S_0.1 percent (window model plus the lossy sites): median / 90th / 99th / max | 0.45 / 0.88 / 5.29 / 9.82 percent | against the window model's 0.115 to 0.251 |
-| p1 / p2 / p3 predicted against F8 measured | 0.579 / 0.323 / 4.72 | 0.520 / 0.272 / 4.60 |
-
-F8's proposed gate (the top 0.1 percent within 1.2x of the window-model control on every one of 64 seeds) fails 96.6 percent of today's programs, because any lossy-sourced site alone exceeds it (0.16 + 0.05 at the least); it is a generator change in a gate's clothing. A 2x bound fails 69.7 percent, 3x 48.9 percent; a bound of S_0.1 percent at or under 1 percent of all reads fails 6.9 percent (the `or` chains and the multi-`or` programs). The static rule "no load whose source's last writer is `or`" fails 48.4 percent; "no lossy last writer" 96.6 percent.
-
-## 4. What the skew is worth to a chip (chip-model-v3.md terms, approximate)
-
-A hot-set cache of the top 0.1 percent of items is 16,777 items x 64 B = 1.07 MB of SRAM, 0.53 mm^2 and $0.25 at 0.49 mm^2 and $0.23 per MB. It serves 0.52 percent of p1's reads (0.16 of them the window model's), 4.6 percent of p3's. The hash is latency-bound on its dependent reads, so a read served on die is time saved: a chip gains at most 1.005x on p1 and 1.048x on p3 from the cache. The ceiling under the live rule: part (c)'s 120-of-128 floor admits one site repeating its item in all 8 iterations and no more (two saturated sites fail it), so at most 8 of 128 reads, 6.25 percent, can sit on a constant item, and a chip's edge from this whole class is at most 1 / (1 - 0.0625) = 1.067x, in 64 bytes of SRAM, on the hours whose program carries such a site. The public claim rests on 2x margins (chip-model-v3.md); 1.067x does not move it, and the union of the windows is still the whole dataset every hour, so no window-level cache exists. What moves: per tier nothing in rate or watts (the honest card reads the hot item from L2 as the chip would), and the 5 percent rule of 2.0 is untouched.
-
-## 5. The two options for the flip, priced (main's ruling 3; nothing ships on this without the founder's word)
-
-| Option | What changes | Cost | Risk |
-|---|---|---|---|
-| A. A class amendment in 0.3.19 before the flip: the generator draws a load's source from the registers whose last writer injects (or rule (a) tightened to the same), class v4 re-pinned | a new program stream: new vectors, the seven gate packs re-exported, the six gates again (the hash side G1 to G3 and the verifier re-run here in about an hour of Mac and PC 2 time; G4 to G6 the node lane), every node before the flip by the one-box-at-a-time fleet rule | hours of gate time, a fleet rollout, the 0.3.19 ship on the line | a node that misses the build splits the chain at the flip; the fix itself is small (one draw rule) |
-| B. Hold v4 at the floor as it is; the source rule in class v5 | nothing on the devnet; the attack-pass record carries the window null and the bound | a hot set on 48 percent of hours worth up to 1.005x to a chip, on 5 percent of hours up to 1.05x, 1.067x at the rule's ceiling, no chain risk | the public line must state the bound, not "uniform" |
-
-The number that decides it: 1.067x at the ceiling against the 2x margin of the chip claim. Recommendation: B, with the v5 item below, unless the founder wants the tail tight now.
-
-## 6. The acceptance bound for the next class (main's ruling 4)
-
-Definition: for a program, H = W_0.1(windows) + sum over load sites of h(last writer of the source), with W from the Poisson mixture of the 16 window draws (0.115 to 0.251 percent at 2^26 nonces) and h = 0.30 percent for `or`, 4.5 for an `or` chain, 0.067 for `mul`, 0.049 for `mulhi`, 0 for an injecting or bijective writer (the figures of section 2 at the measured bias). The bound: H at or under 1.2 x W, which is the static rule "every load's source was last written by an injecting op or a rotate" (any lossy writer breaks 1.2x). Its cost as a rejection rule on today's stream: 96.6 percent of candidates, about 30 attempts per seed on average. The cheaper form is a generator draw, not a rejection: draw a load's source from the registers whose last writer injects (today's rule draws from every written register), which costs no attempts and leaves rule (a) as it is. Either way the 64-seed census of F8's phase E is the gate, with the dynamic check extended to count saturated load sources over the 64 units beside the final values.
-
-## 7. What is unverified
-
-- The per-site h figures are the popcount and trailing-zeros models at the biases F8 measured on p1 and p2; p3's chain figure is F8's measurement, not a model. F8's phase E (64 seeds, dynamic) is the test of the whole table.
-- The window model's top-f shares for the census use a normal approximation per quarter (p1's exact Poisson 0.160 against 0.159).
-- No GPU run and no timing here; every number is a count or arithmetic.

docs/analysis/card-lifetime-2026-10-05.md

@@ -69,7 +69,7 @@ Proving is a separate budget (the 15.6 GB peak the 12 GB mine-and-prove question
 
 ## 4. Table 3: the public sentences against the numbers
 
-| Where | Sentence now | What the tables give | Proposed sentence (the founder decides the wording) |
+| Where | Sentence now | What the tables give | Proposed sentence (the project lead decides the wording) |
 |---|---|---|---|
 | `site/index.html` 443 | Memory: "2 GB, fixed" (RandomX) / "2 GB, growing" (Igneum) | 2 GiB at genesis, plus 0.5 GiB a year on average under either option | "2 GB, growing 0.5 GB a year". The row is right; the rate is the useful addition |
 | `site/index.html` 461 | "Any 4 GB card, approximate." | True at genesis (2,584 to 2,834 MiB of a 3,072 MiB budget). Ends at 1 to 1.5 years under (a), year 4 under (b) | "Any 4 GB card at launch, 8 GB for the long run, approximate." |

docs/analysis/chip-model-v3.md

@@ -202,8 +202,6 @@ the `f = 1` chip: it is the 55 W without the 271.
 ### 5.4 The curve
 
 Per row: reads per hash = 128 f; items recomputed = 128 (1 - f); ops per hash = 128 (1 - f) x 9,360 + 512.
-
-Correction, 7 October 2026 (the in-house adversarial pass, lane adv-cache-3, report 091edc34): the partial-store rows above and adv-cache's Q1b table price a chip that holds every k-th line of the 64-line chain and recomputes a read at offset o in o evaluations ((k - 1) / 2 on average). The exact pebbling optimum for the chain (dynamic programming, checked against exhaustive search at 10 to 16 lines) sits under that curve: blocks per read 16.0 against 31.5 at f = 1/64 (the one held line belongs at line 32, not line 0), 10.5 against 15.5 at 2/64, 6.09 against 7.5 at 4/64, 3.17 against 3.5 at 8/64, 1.45 against 1.5 at 16/64, equal from f = 1/2. So a chip holding 1/64 of the cache pays 9.3x the item's ops, not 17.4x; at f = 1/2 and above nothing moves, and the SRAM column and the full-store verdict stand (no point on the curve beats the full store under the op budget or under energy).
 Memory-bound rate = the ceiling / (128 f). Compute-bound rate = 50 T op/s / ops per hash (the section 1 budget).
 The rate is the smaller; "binding" names it. Power = rate x (128 f x E_read + 128 (1 - f) x 6.3 nJ) + static (memory,
 controller, and 20 W for the recompute die's clocks and leakage when `f < 1`). Energy per hash = power / rate. "Gain,
@@ -296,7 +294,7 @@ low on this result; it stays a reserve family. What does move the `f = 1` rows,
 | Read granularity | The chip pays the same 32-byte atom the 5090 pays; the 9070 XT pays 64. Wider honest reads (w16, measured, layer 1) give the chip nothing and the 5090 nothing; w64 made the 5090 bandwidth-bound (71.9 MH/s) | w64 costs the 5090 47 percent | Not a lever; the decision to stay at 4 B stands |
 | Latency | A longer chain (more reads per hash) scales the chip's rate and the card's rate together; lane state is 64 B, so lanes are free to the chip | Nothing per se | Not a lever: the rate per chip is lanes / latency on both sides and the chip has more lanes per watt |
 | The denominator: the 5090's watts at the hash | The gain is 2.40 microjoules over the chip's 0.47; the card's 326 W is 92.9 percent utilisation spinning on loads. At a 250 W cap holding 136.1 MH/s the gain reads 3.9x (GDDR7) and 5.7x (HBM3); at 200 W, 3.2x and 4.6x | None if the rate holds under the cap; the measurement is one PC 2 job (`nvidia-smi -pl 200, 250, 326`, two minutes each, STATUS lines as the rate) | The first measurement to run; it moves every row and costs nothing. Owed (PC 1 is not released; PC 2's budget is the coordinator's) |
-| Program work in the latency shadow | The hash hides 512 ops per hash behind 128 reads; the 5090 could hide 330,000 (45.2 T / 136.1 M) before compute binds, the M5 Max about 290,000 and the 9070 XT about 650,000 (their ALU budgets approximate, from memory). Work in the shadow is free in hash rate and costs the card watts it now wastes: at N ops per hash the card rises from 326 toward 575 W (linear, approximate) and the chip must add a core that runs the per-epoch random program, at k times the GPU's 5.5 pJ per op (the 5090's marginal ALU energy, (575 - 326) / 45.2 T). At N = 100,000: the card 401 W, 2.95 microjoules; the chip 1.02 at k = 1, 0.83 at k = 1.5; gain 2.9x and 3.5x. At N = 200,000: 477 W, 3.50; chip 1.57 and 1.20; gain 2.2x and 2.9x. At N = 330,000: 575 W, 4.22; chip 2.28 and 1.68; gain 1.85x and 2.5x | Hash rate none while every card stays latency-bound (under about 290,000 on the M5 Max); watts up to TGP; the verifier N x 32 ops per warp: 3.2 M at N = 100,000, under 1 ms at the 18 G op/s the x8 verifier shows (38 M ops in 2.08 ms), inside the 10 ms gate; `INSTR_COUNT` and `ITERATIONS` are prototype values to be fixed at gate 1 (spec 1.4) | The only lever that moves the f = 1 row toward 2x, and only if the chip's core is no better than a GPU's on a random program (k near 1: RandomX's argument, and the founder's goal in the brief's words, "build a better GPU than NVIDIA"). It reaches 1.85x at the 5090's full ALU budget and k = 1, not under; combined with a 250 W cap it reads about 1.4x (approximate). It is item 2's idea applied to the program, not to the item derivation |
+| Program work in the latency shadow | The hash hides 512 ops per hash behind 128 reads; the 5090 could hide 330,000 (45.2 T / 136.1 M) before compute binds, the M5 Max about 290,000 and the 9070 XT about 650,000 (their ALU budgets approximate, from memory). Work in the shadow is free in hash rate and costs the card watts it now wastes: at N ops per hash the card rises from 326 toward 575 W (linear, approximate) and the chip must add a core that runs the per-epoch random program, at k times the GPU's 5.5 pJ per op (the 5090's marginal ALU energy, (575 - 326) / 45.2 T). At N = 100,000: the card 401 W, 2.95 microjoules; the chip 1.02 at k = 1, 0.83 at k = 1.5; gain 2.9x and 3.5x. At N = 200,000: 477 W, 3.50; chip 1.57 and 1.20; gain 2.2x and 2.9x. At N = 330,000: 575 W, 4.22; chip 2.28 and 1.68; gain 1.85x and 2.5x | Hash rate none while every card stays latency-bound (under about 290,000 on the M5 Max); watts up to TGP; the verifier N x 32 ops per warp: 3.2 M at N = 100,000, under 1 ms at the 18 G op/s the x8 verifier shows (38 M ops in 2.08 ms), inside the 10 ms gate; `INSTR_COUNT` and `ITERATIONS` are prototype values to be fixed at gate 1 (spec 1.4) | The only lever that moves the f = 1 row toward 2x, and only if the chip's core is no better than a GPU's on a random program (k near 1: RandomX's argument, and the project lead's goal in the brief's words, "build a better GPU than NVIDIA"). It reaches 1.85x at the 5090's full ALU budget and k = 1, not under; combined with a 250 W cap it reads about 1.4x (approximate). It is item 2's idea applied to the program, not to the item derivation |
 | The clock (item 4) | The f = 1 chip is a commodity-memory controller project: by the Ethash precedent, 32 months to a first chip at the largest prize, and a chip over 2x at 65 months | None | The issuance trigger and the share-pattern detector matter more than any item-derivation change |
 
 So: item 2 can wait; the power-cap measurement runs first; the program-length lever is the Counter ASIC 3.0 design
@@ -337,26 +335,6 @@ measurements land.
 - The ALU budgets of the M5 Max and the 9070 XT, their power at the hash, and the verifier's cost at N = 100,000
   program ops are estimates; the program-length lever is a design item with its own measurements, not a result.
 
-### 5.10 Class v5 on, the shadow at zero: does the state-derived dataset make the shadow unnecessary? (7 October 2026, 21:3x UK, the founder's question "we need a solution, deep research, other methods")
-
-The question: with class v5 (the dataset built from the chain's execution state, refreshed per window) and the latency-shadow work of class v4 set to zero (class v3 energy on every GPU), what edge does the strongest chip keep over an RTX 5090 per joule? If it were at or under about 2x the shadow could come off after v5 and the class v4 premium (145 W on a 5090 at the unlocked core, 88 W at the 1,400 MHz lock, measured 7 October 2026) would vanish.
-
-What class v5 changes for the chip, from `docs/design/class-v5-stored-state.md` sections 2 and 2a: the recompute chip (`f = 0`, the dataset derived on the fly from the cache) and the stateless or stale chip are removed as categories, because every item takes a leaf of the state and the leaves refresh every window. What it does NOT change: the strongest chip was never one of those. It is the `f = 1` stored-dataset chip of 5.5, a GPU's memory system without the GPU, and under class v5 it needs one thing more, the window's leaves, which section 2a.2 prices honestly: one node serves a whole farm, the leaves ship at 16.5 KB/s to 10,000 members today (45 MB per member per window over a 1 Gbit/s WAN before the state is 7,500x today's), and the rebuild on the chip is the same 32 ms per window every GPU pays. The dataset is still derived from a seed and the state, so a central node compresses everything but the state's bytes, and the chip stores the result as before.
-
-The arithmetic, on the model's own figures (5.3: the activate-bound ceilings, 2.0 nJ per random read on GDDR7 and 1.2 nJ on HBM3, the static and controller watts; the 5090 at 136.1 MH/s on 326 W, 0.417 MH/W; 128 loads per hash, the shadow at zero so no ALU beside the memory). The node is a desktop-class CPU with an NVMe and 32 GB at about 85 W (approximate, from memory of such machines; a full node with the EVM executor at 1 block/s), shared by a farm (100 chips: 0.85 W each) or carried by every chip (the attacker's worst case, 85 W each).
-
-| Chip, class v5 on, shadow at zero | MH/s (model) | W with a farm-shared node (0.85 W) | MH/W | Edge over the 5090 per joule | W with a node per chip (85 W) | Edge |
-|---|---|---|---|---|---|---|
-| GDDR7 `f = 1`, 16 devices (the 5090's own memory without the GPU) | 166 | 78 | 2.12 | 5.1x | 163 | 2.5x |
-| HBM3 `f = 1`, one stack | 84 | 28 | 3.02 | 7.2x | 112 | 1.8x |
-| HBM3 `f = 1`, eight stacks (an H100-class package) | 666 | 175 | 3.80 | 9.1x | 259 | 6.2x |
-
-Every figure is modelled (arithmetic on cited memory figures, approximate where 5.3 marks it); none is measured; the node's watts are an approximate from memory.
-
-Reading: NO. Class v5 with the shadow at zero leaves the strongest chip at 5.1x (GDDR7) to 9.1x (HBM3, eight stacks) per joule, the class v3 figures of 5.6 less a rounding, because the node is a farm cost and not a chip cost; only a chip forced to carry its own node falls near 2x, and only the small ones (one HBM3 stack at 1.8x, the GDDR7 board at 2.5x), while the eight-stack package stays at 6.2x even with a node per chip. So the shadow (class v4's 100,000 ops per hash in the memory wait, which brings the chip to 2.1x at k = 1 and 3.9x on the claimed X9 core) stays the only lever in this model that reaches the memory-system chip, and the class v4 premium is the price of that lever on today's GPUs. What class v5 buys is different and real: the recompute chip and the stale chip are gone as categories, every miner must hold and follow the chain, and a chip's dataset is wrong the moment its node is. The premium itself has two measured levers tonight: the core-clock lock (57 of 145 W back on the 5090 at 1,400 MHz for 1.4 percent of rate; the knee below 1,400 is the second pass's) and the per-card tune the app lands by itself; what would remove it is a shadow whose work is cheaper per op on a GPU than on a chip core (the research lane's question: a shadow shaped for the GPU's idle datapath at low clock, or a memory-side cost the chip cannot amortise), not the state-derived dataset.
-
-Per tier: a miner on class v4 pays the premium and gets the 2.1x to 3.9x chip ceiling in exchange; on class v5 with the shadow kept the ceiling stays and the dataset is the chain's; on class v5 with the shadow dropped the premium goes and the ceiling returns to 5x to 9x. The decision is the founder's; this section gives the number.
-
 ## 6. The per-day derivation (item 2)
 
 6 October 2026, Counter ASIC 3.0 item 2, worker `derive` (`docs/plans/counter-asic-3-derivation.md`; everything

docs/analysis/ci-failures-2026-10-06.md

@@ -41,7 +41,6 @@ One line per class. "Guard" is what now stops the class before it reaches master
 | N no-secrets | 2 | 06 15:56Z | 06 16:23Z | A 64-hex test vector next to `private_key` in `app/igneum-wallet/src/vault.rs` (wallet-0.1.5) | Allow-listed as a test value | The gate |
 | P swallowed defaults line (no CI run: a silent class) | 0 | 06 19:5xZ | 06 21:xxZ | A comment appended to a line of shell assignments in `tools/build-remote.sh` and then `tools/cross-remote.sh` turned every assignment after the `#` into comment text; `bash -n` and shellcheck are silent on it; the default cross-build never ran and its chain kept the previous exes from about 20:40 to 22:00 UK | 36e4ee7 on master: the lines split; `tools/ci/defaults-line-check.sh` with its self-test | In ci.yml at 36e4ee7 and in the gate from this change, so it runs on the pushing machine before the push |
 | Q gate checks that read the machine, not the fact (found by the gate itself, 22:1x to 22:3x UK) | 0 | 06 21:1xZ | 06 21:3xZ | Two pushes of this change to master were refused by the new hook: (1) git hands a hook `GIT_DIR`, and `remote-run.sh --self-test`'s nested `git init`, commits and reset then acted on THIS repository's worktree: it set `core.bare`, moved the local `master` to three fixture commits and broke the main checkout for ten minutes (restored from the reflog: master back to 36e4ee7, `core.bare false`; nothing was pushed, nothing lost); (2) the same self-test judged a stale `index.lock` by `pgrep -x git` over the whole machine, so the hook's own `git push` (or any other agent's git) made the fixture's checkout die with "index.lock: File exists" | The gate unsets `GIT_DIR` and the other hook variables before any check; the staleness test is the lock's age (over 30 s), and the self-test backdates its fixture lock | The gate itself: every self-test now runs inside a real hook before every master push, with a `git push` alive beside it |
-| R kill by name (the fleet, no CI run) | 0 | 06 21:09Z | 06 21:09Z | A Mac-side `pkill -f <log file name>` matched nothing: the name was a shell redirect, not part of any command line; the roll-everything script lived on and wiped a box it had been told to hold. Earlier the same day, twice: a `pgrep -f "<literal>"` matched the calling shell's own command line. Six `pkill -f sp1-gpu-server` inside `bash -c '...'` bodies in tools/proving-v1 carried the same shape on master | The fleet runs Mac-side jobs under `tools/fleet/fleet-bg.sh` (a pid file per job) and anchors every on-box kill on the binary's full path and first argument; the six prover lines use `pkill -x` on the binary name | `tools/ci/kill-by-name-check.sh` in the gate: flags `pgrep -f` / `pkill -f` with a plain literal, any pgrep/pkill on a file-name shape (.log, .out, .pid, .json ...), and `ps | grep <literal>`; allows the bracket form, `-x`, `-F <pidfile>`, `kill $(cat pidfile)`, a variable, a full path; self-test of 9 banned and 14 allowed shapes |
 | O1 windows-ci cancelled | 16 | 04 10:42Z | 06 18:12Z | `concurrency: cancel-in-progress` on windows.yml: a newer master push superseded the run. Not a failure | None needed | None; they are listed because `gh run list` counts them as non-green |
 | O2 hosted runner not acquired | 8 | 05 19:26Z | 05 20:54Z | "The job was not acquired by Runner of type hosted even after multiple attempts" on release-0.3.10 (7) and master (1): GitHub capacity, retried by hand | Re-run | The `red` job reports it; the box runner for `pow` and `sims` (section 5) takes those jobs off the hosted pool |
 
@@ -58,10 +57,10 @@ is the wrong place; it goes in the script.
 
 | Mode | When | What |
 |---|---|---|
-| `--hook` on a push to master or release-* | installed by `tools/ci/install-hooks.sh` into the shared hooks directory (one set for every worktree) | all 32 checks; a red check refuses the push and prints its output |
+| `--hook` on a push to master or release-* | installed by `tools/ci/install-hooks.sh` into the shared hooks directory (one set for every worktree) | all 31 checks; a red check refuses the push and prints its output |
 | `--hook` on any other ref | same | the two structural checks only (conflict markers, Windows paths) |
-| `--ci` | the `site` job | all 32 checks, with the site built in place |
-| default | by hand in any worktree | all 32 checks |
+| `--ci` | the `site` job | all 31 checks, with the site built in place |
+| default | by hand in any worktree | all 31 checks |
 | `--self-test` | in the gate itself | a known failure is RED and fails the gate; a known success is ok; master and release-* select the full gate, other refs the light one |
 
 Measured 6 October 2026, 21:5x UK, on the Mac: 30 checks, GREEN, 25 s (no-secrets 11 s, identity grep 3 s, the rest
@@ -71,7 +70,7 @@ worktrees); `git status` before and after the full gate is identical.
 
 Checks that joined CI through the gate and were not in ci.yml before: the ledger sentence check
 (`ledger-text-check.mjs`), the workflow shell parse (`check-workflow-shell.mjs`), the Windows paths check, and the three
-self-tests (identity, Windows paths, the red watcher). The swallowed-defaults check (36e4ee7) and the kill-by-name check are in the gate too.
+self-tests (identity, Windows paths, the red watcher). The swallowed-defaults check (36e4ee7) is in the gate too.
 
 ## 4. The red watcher (`tools/ci/red-watch.mjs`, `infra/build-server/ci-red/`)
 
@@ -110,7 +109,7 @@ run drops from about three minutes to about one. The hosted runner then serves o
 pipeline (MSVC, WebView2, Inno Setup, PowerShell 5.1, which a Linux box cannot provide). The flip is main's call after the
 0.3.15 cut, per build-server.md section 7.1.
 
-## 6. The build box's own red rows (the founder, 22:3x UK: "also make sure we are fixing and learning from all the errors here")
+## 6. The build box's own red rows (the project lead, 22:3x UK: "also make sure we are fixing and learning from all the errors here")
 
 Source: `/srv/builds/_log/builds.jsonl` on igneum-build-1, 139 rows from the first build at 18:38 UK to 22:11 UK on
 6 October; 34 with a non-zero exit. Until this change the box kept no output of a run (it streamed to the agent's terminal),

docs/analysis/difficulty-2026-10-04-oscillation.md

@@ -288,7 +288,7 @@ the height arrives.
    (26640/28640, a follower, lowest risk), the seed (`/opt/igneum/v4/bin`, `infra/seed-nodes/stage-v4.sh`),
    Mac node 1 (26610/26611), PC 1's node (its launcher's `igneumd.exe`; PC 2 mines through the Mac node
    and needs nothing). Each node gets the same `"difficulty_v2_activation_daa": N` in its override file.
-   The founder restarts the live processes; this entry does not.
+   the project lead restarts the live processes; this entry does not.
 3. Watch the observer's difficulty events across the height and the next epoch boundary; with a miner
    joining inside an epoch the floor and the bursts of section 1 must not return.
 

docs/analysis/era-vdf-2026-10-07.md

@@ -1,86 +0,0 @@
-# The era VDF: built, measured and gated (7 October 2026)
-
-Era VDF lane, 7 October 2026, from the attack pass's F7 row (`docs/analysis/attack-pass/f7-era.md`, sub-row a: the node's era seed was a plain chain block hash, grindable with one block of hash at no delay, and the 1-hour VDF of spec 04 section 4.4 did not exist in the node). Repository branch `era-vdf` (this record, the spec text, the harness `tools/era-vdf/`, the fast-time fields); node fork branch `era-vdf-node` on the 0.3.19 line (`release-0.3.19-node` dc141409). Every number below names its log on igneum-build-1 under `/srv/builds/igneum-wt-era-vdf/ev-*/`.
-
-## 1. What was built
-
-| Piece | Where | What |
-|---|---|---|
-| The integer | `consensus/core/src/era_vdf/bigint.rs` | a fixed-width signed integer (40 limbs, 2,560 bits) on the stack: add, sub, mul, shifts, Knuth division with floor, truncated, exact and Euclidean remainders, the extended gcd and the partial extended gcd with Lehmer's word steps (chiavdf `xgcd_partial.c`), modpow, sqrt and the fourth root, Miller-Rabin with the first 30 primes as bases; every operation checked against `num-bigint` on 20,000 random operands of the class group's sizes, the known-failed shapes first |
-| The class group | `era_vdf/classgroup.rs` | `proto-vdf/src/classgroup.rs` (3 October 2026) on the fixed-width integer: NUDUPL and NUCOMP ported line by line from chiavdf's `qfb_nudupl` and `qfb_nucomp`, the plain duplication and Cohen 5.4.7 kept as the oracles the tests hold them to on random forms at 256, 512 and 1,024 bits; serialization as sign byte plus fixed width, 258 bytes a form |
-| Wesolowski | `era_vdf/wesolowski.rs` | eval with serialized checkpoints (at most 2^16, 17 MB), the 12-bit-digit block prover bucketed per residue class and parallel over them, the naive prover as the oracle, verify; T + 1, another y, another pi and another input refused |
-| The hash chain | `era_vdf/hashchain.rs` | scheme 1: T sequential SHA-256 applications from a tagged start; verification by recomputation; one step short refused |
-| The scheme byte and the seed | `era_vdf/mod.rs` | `vdf_scheme` 0 and 1, `EraVdfProof` and its wire form, `era_vdf_input` (the chain's BLAKE2b keyed `IgneumEraVdfInput` over `chain_id || n || the day's blue hashes`), `era_seed_of` = SHA-256 of the scheme byte, the input, T and y |
-| The switch | `consensus/core/src/config/params.rs`, `igneum.rs` | `pow_era_blocks` and `pow_era_lead` as override fields (the constants everywhere; in the digest when they differ), `era_vdf_activation_daa` (never), `vdf_scheme` (0), `era_vdf_t` (the reference T); the three in the digest once the activation is set (the 0.3.15 rule); installed with the PoW schedule |
-| The node side | `consensus/src/processes/era_vdf.rs`, `model/stores/era_vdf.rs` | the cut rule (the chain block below the cut, memoised and re-validated by reachability), the day-of-blues input (memoised per cut block), the evaluator thread started by the virtual processor a quarter of the lead past the cut, the record store (one row per era), the header processor's wait when a header arrives before the record, the template's `era_seed` None while evaluating, `submit` for a record from outside (verified against this chain's input) |
-| The template and the miner | `PowEpochInfo`, `RpcPowEpochInfo`, `rpc.proto` fields 37 to 44, `igneum-miner` | the era schedule, the VDF's state, scheme, T and input in every template; the miner holds while the node reports no era seed ("era VDF: the node is still evaluating"); `igneum-miner vdf bench|eval|verify` with the node's own code |
-| The harness | `tools/era-vdf/reroll.mjs` | the F7 re-roll harness against the REAL era cut (era 120 DAA, lead 20 on the merged fast-time file; ports 30100 and up, suffix 1010), `--vdf off` the stand-in, `--vdf on` the VDF at a fast T, the adversary running the node's evaluator over its candidate before publishing |
-
-## 2. The parameters
-
-Measured 7 October 2026 on igneum-build-2 (AMD EPYC 9454P, 96 threads, Ubuntu 24.04), one core under `/srv/builds/_bin/lease cores 31` at nice 10 while the box ran other lanes' suites (load 25 to 75), with the node's own code (`igneum-miner vdf bench`, logs `ev-vdf-bench3.log`, `ev-vdf-bench5.log` in this lane's scratch) and chiavdf 7e62ce14 built on the box against GMP 6.3.0 (`ev-chiavdf`).
-
-| Parameter | Value | Label |
-|---|---|---|
-| Group | class group, 1,024-bit prime discriminant `D = -HashPrime("igneum-era-discriminant" \|\| input)`, `\|D\| = 7 mod 8` | Implemented (spec 4.2) |
-| Generator, Fiat-Shamir prime, proof plan | `(2, 1, (1 - D) / 8)`; 256 bits; 12-bit digits, at most 2^16 serialized checkpoints (17 MB) | Implemented |
-| Proof on the wire | 529 bytes: scheme (1), T (8), two 258-byte forms with 2-byte lengths; `y` and `pi` 258 bytes each | Measured |
-| Scheme byte | `vdf_scheme` 0 = class group, 1 = hash chain; genesis 0 everywhere | Implemented |
-| Reference rate, scheme 0 | 30,589 and 40,117 squarings/s in two 10-s runs on the box core (the spread is the box's load); 30,000 is the reference | Measured |
-| `T_era`, scheme 0 | 3,600 x 30,000 = 108,000,000 squarings (`ERA_VDF_T_CLASS_GROUP`): 60 min at the reference, 45 at the faster run | Measured, set |
-| Prove, scheme 0 | eval + prove 11.6 s at T 401,167 (eval 10.0 s): the single-thread block prover is about 14 percent of the evaluation, parallel over residue classes in the node (up to 8) | Measured |
-| Verify, scheme 0 | 21.9 and 22.6 ms with the group held (mean of 20); 184 ms with the discriminant derived, the derivation being 161 to 167 ms, once per era | Measured (section 5 for the gate) |
-| Reference rate, scheme 1 | 16.2 and 17.0 million SHA-256/s (SHA-NI); 16,000,000 is the reference; `T_era` = 57,600,000,000 hashes (`ERA_VDF_T_HASH_CHAIN`) | Measured, set |
-| Verify, scheme 1 | recomputation: 10.1 s for T 170 million, the full hour at `T_era` | Measured |
-| Discriminant search | 161 to 167 ms per era (Miller-Rabin with the first 30 primes on the fixed-width integer) | Measured |
-| chiavdf on the same core | 208.8 K squarings/s (`vdf_bench square`, NUDUPL over GMP, 1,000,000 iterations); the AVX-512 IFMA path (`square_asm`) gave 127.3 K at 20,000 iterations and stalled at 300,000 and above in this build (built outside its Makefile's `FAST_MACHINE` flags), so the IFMA number is not established here | Measured; the asm path unestablished |
-| Delay on the fastest prover measured | 108,000,000 / 208,800 = 517 s against the 1-s block interval (517x) and the 2-s publish window (259x); a prover 10x chiavdf's GMP path (the ceiling Chia's and the EF's hardware efforts aimed at, approximate, from memory) would still take 52 s, 26x the window | Computed from the measurements |
-| The gate "at least 60x one block interval on the fastest known prover" | 517x on chiavdf's GMP path, the fastest evaluator measured on this hardware; PASS as measured, with the IFMA path unestablished (above) and the 10x hardware ceiling still 52x | PASS (measured), caveat recorded |
-
-The node's own evaluator is 5.2 to 6.8x slower than chiavdf's GMP path on the same core. That ratio only moves the honest side: `T_era` is set from the node's rate, so an honest node finishes in the hour; the attacker's margin is the delay at the fastest prover, above.
-
-## 3. The gate: the re-roll harness with the VDF off and on
-
-`tools/era-vdf/reroll.mjs` on igneum-build-2 (the box under other lanes' suites, nice 10; logs and per-cut JSON under `/srv/builds/igneum-wt-era-vdf/ev-harness-out/reroll-vdf-{on,off}-5.json`), three nodes of the fork at this record's commit on the fast-time file with `skip_proof_of_work`, era 120 DAA and lead 20 (cuts at `S = 120 n - 20`, one every two minutes), ports 30100 and up, suffix 1010; two honest virtual miners share 1 block/s on nodes 0 and 1; the adversary on node 2 holds a block A built on the tip at `S - 1` and tries to make it the era's cut block. With the VDF on, the adversary runs the node's own evaluator (`igneum-miner vdf eval`, the network's T) over its candidate before publishing; T is set from a 3-s bench at the start so the delay is about 5 s on one core of this box, five times the block interval.
-
-| Run | Switch | Cuts | A accepted | A became the cut block | Known-draw re-rolls (the seed the adversary knew before publishing is the era's seed) | Adversary's evaluation | Nodes agree on the era seed | Gate | Harness |
-|---|---|---|---|---|---|---|---|---|---|
-| vdf-off-5 (the stand-in, 15:08 to 15:22 UTC) | `era_vdf_activation_daa` never | 6 (eras 2 to 7) | 6 of 6 | 6 of 6 | 6 of 6: the seed is `hash(A)` every time | none needed: the draw of hash(A) is known the instant A is built | 3 of 3 on every era | FAIL (the known-pass fires) | SOUND |
-| vdf-on-5 (the era VDF, 14:54 to 15:08 UTC) | activation 0, scheme 0, T 189,650 (5 s on this core) | 6 (eras 2 to 7) | 6 of 6 | 0 of 6 | 0 of 6 | 5.38 to 6.64 s, during which the honest chain advanced 3 to 10 blocks; A arrived behind them and never became the cut block | 3 of 3 on every era, the record ready (state 3) at every era start | PASS (silent) | SOUND |
-
-What the two runs say. Under the stand-in a miner with one block of hash at the right second owns the era draw outright on this network: holding the block at `S - 1` and publishing it the moment the chain reaches `S - 1` makes it the cut block in every one of six cuts (the attack lane's epoch-cut run saw 1 of 6, with the honest block often landing first; here the adversary is faster to the second), and its draw is known the instant the block is built. Under the VDF the same adversary cannot know any candidate's draw before T steps have run; while it ran them the honest chain moved 3 to 10 blocks, so its block arrived behind the cut and the seed came from the delay over the day of blues ending at the honest cut block, the same on all three nodes. The second half of the written argument of F7 (a) holds in the node, not only on paper: the re-roll needs the draw inside the window, and the window is 1 s against a delay of 5 s here and 517 s at the fastest prover measured on the production T (section 2).
-
-The known-pass and the known-fail ran on the same binaries, file and ports, the VDF switch the only difference. A first VDF-off run with a lookup defect in the harness (the adversary's block not found, so the verdict read "held") was discarded once the node's own log showed the adversary's hash as the cut block in 5 of 5 cuts; the harness now reads A from that log line. Two runs that overlapped on the box through a stale node of an earlier run were discarded as well (their nodes disagreed because they were two networks); the two runs above ran alone.
-
-## 4. The cut rule and the certified checkpoint (for the finality lane)
-
-The node names `C_era(n)` as the last selected-chain block below the cut on the header's own chain (the block the stand-in used), which is the checkpoint block the lead rule names under the O-4.3 decision of 3 October 2026 (certified or not). Three facts decide it:
-
-1. Determinism. A header's validity must be a function of its own past. "The certificate carried by a block in the header's past, for the highest-index checkpoint with DAA score at most the cut" is such a function, but a certificate that lands after the era starts flips the reading between headers of one era (a header before the carrier reads the fallback, a header after it reads the certificate), so the certified binding needs a second rule: the carrier must sit at most half a lead above the cut (3,600 DAA s, the merge depth) and be a chain ancestor of the header; under that rule every honest header of the era reads the same certificate once the network merged the carrier, and a header on a chain that never merged it reads the fallback, consistently with its own past. The chain-block reading needs no second rule.
-2. Liveness. A finality pause across the cut (a third of weight leaving in an hour is a 30-day pause under rule v3) leaves the certified binding without a checkpoint for the era; the chain-block reading always has one, which is the reason O-4.3 was decided the way it was for the epoch.
-3. The defence. The grinding defence is the delay: no candidate's draw is knowable for T steps, whichever block is the cut. The binding moves which block a withholder would have to be the author of, not whether withholding pays; both readings leave the withholder with a coin flip it cannot see.
-
-The change, if the finality lane wants the certified binding: `EraVdfManager::cut_block` (one function; the input, the delay and the seed are unchanged), plus the second rule above and a test with a certificate carried late.
-
-## 5. The verify gate on a 2019-class core
-
-The gate was "the VDF verifies in under 10 ms on a 2019-class core". Measured: 21.9 and 22.6 ms with the group held on the box core (above), which the F6 row's calibration puts at about 1.19x on an i7-9700K (the O-1.14 run: 6.0 ms on the 2019 core against 5.06 ms on the box proxy), so about 26 ms on a 2019 core, labelled a proxy: no 2019 host was rented this lane (Vast rentals are a purchase; not made without the founder's word). NOT MET, by 2.2x on the box and about 2.6x on the proxy.
-
-Where the time goes and what closes it: a verification is two 256-bit exponentiations, about 770 group operations at 28 µs each; the operation is NUDUPL on the fixed-width integer, whose cost is the extended gcd (Lehmer rounds on 8-limb numbers) and the reduction. Three rounds of this lane moved it from 345 µs (a Lehmer convention defect that fell back to plain division every round) to 28 µs (the convention, i64 word division, 34 limbs, the x86-64 128-by-64 division); the next 2.2x is chiavdf's Pulmark reducer (reduce only when `a` exceeds 8 limbs, O-4.6) and a limb-level NUDUPL that keeps the partial gcd's intermediates in words, or GMP through `rug` behind a feature on the x86-64 Linux and Windows builds (chiavdf's 208 K/s is 6x this evaluator, which would put the verification near 4 ms as the prototype measured), with the fixed-width path the fallback for wasm and macOS. Owed, not blocking: the verification runs once per era (180 days) on a node that imports a record rather than evaluating; every mining node evaluates and never verifies.
-
-## 6. Consequences per tier (the standing rule of 5 October 2026)
-
-| Tier | What the era VDF costs | What it means |
-|---|---|---|
-| A home miner, any card (8, 12, 16, 24 or 32 GB), any vendor, Windows, Linux or macOS | one CPU core for about 60 min once per 180 days at the reference rate (a 2019-class desktop core about 72 min by the F6 calibration), 17 MB of host RAM for the prover's checkpoints during it, 0 bytes on the card; the node starts it a quarter of the lead past the cut and holds the record from then | nothing changes on the card or in the hash rate; the 2-hour lead covers a core half the reference speed; a node that was off across the cut evaluates on arrival and its miner holds until the record lands (the miner says so every 10 s) |
-| A rig (one node, several cards) | the same one core on the rig's host, once per era | nothing per card |
-| A pool user | the pool's node evaluates; the member's miner takes `era_seed` from the template as today | nothing |
-| A light client or a syncing node | verifies an imported record in 22 ms (26 ms on a 2019 core, proxy) plus the 165-ms discriminant derivation, once per era; under scheme 1 it recomputes the hour | the 10-ms gate is missed (section 5); operationally one verification per 180 days |
-| The protocol | the era draw's input is unknowable for 517 s on the fastest prover measured, against a 1-s block interval: the stand-in's one-block grind is closed (section 3) | the freeze of the draw procedure and the C_era cut rule no longer waits on the VDF's existence; it waits on the two decisions of `ledger-decisions.md` |
-
-## 7. What is owed
-
-- The P2P relay of an era record to a syncing peer and the RPC import (spec 4.5, O-4.10), before era 1 of any network with the switch set.
-- The external review of the class-group port (O-4.1): the port is a second implementation checked against the textbook algorithms and `num-bigint`, not a review.
-- The attack pass's F7 status row (branch `attack-pass`, `docs/analysis/attack-pass-2026-10.md`) reads INCOMPLETE pending this lane; the line for it, from section 3: "F7 (a): the era VDF is in the node (fork `era-vdf-node`); the re-roll harness against the real era cut fires with it off (6 of 6 cuts, the seed the adversary's block) and is silent with it on (0 of 6 across six cuts, the adversary's 5-s evaluation against a 1-s block interval, three nodes agreeing on every era seed); PASS, the delay 517 s on the fastest prover measured at the production T."
-- The decisions of `docs/plans/ledger-decisions.md` (the activation per network, the cut's binding).

docs/analysis/hashrate-decay-2026-10-03.md

@@ -1,6 +1,6 @@
 # Per-identity hash rate "decay" on the RTX 5090: diagnosis and fix
 
-3 October 2026, miner-community-lead. Source data: the uploaded logs of the founder's PC (`node tools/logs.mjs
+3 October 2026, miner-community-lead. Source data: the uploaded logs of the project lead's PC (`node tools/logs.mjs
 nvidia-DESKTOP-KMCV30N-1-20261003-222331 --all` and the other identities, the launcher log
 `igneum-DESKTOP-KMCV30N-20261003-222331`), the three serve loops, the miner's worker mode, and five runs of the
 Metal worker on the Mac against private test nodes (ports 27500 and up, `/tmp/igneum-decay-test`). Figures
@@ -9,7 +9,7 @@ from the logs are exact; the two labelled approximate are from memory.
 ## 1. Finding in one paragraph
 
 There is no per-job growth in any worker or in the miner's memory. Two separate things produce the picture
-The founder saw. First, the STATUS line's two rates are cumulative averages since the miner started
+the project lead saw. First, the STATUS line's two rates are cumulative averages since the miner started
 (`hashes_total / elapsed` and `hashes_total / gpu_ms_total` in `mine_worker`), so a fast first interval
 decays as 1/t by construction; nvidia-1 was alone on the card for its first seconds and every later interval
 ran at a flat 17.8 MH/s wall, while the last-started identity, nvidia-8, shows the mirror image, a cumulative
@@ -28,7 +28,7 @@ The miner prints `hash=A MH/s wall (B MH/s inside jobs)` with `A = hashes_total
 `dH / dt` and `dH / dG` with `H = A x t` and `G = H / B`. Every table below is that calculation
 (`rates.py` in the bench-log entry).
 
-### 2.1 The segment the founder quoted: 22:57 to 23:04 UTC, after the epoch-3 restart (DAA 10,801 on)
+### 2.1 The segment the project lead quoted: 22:57 to 23:04 UTC, after the epoch-3 restart (DAA 10,801 on)
 
 nvidia-1, jobs of 2^24 nonces, STATUS every 30 s:
 
@@ -95,7 +95,7 @@ card going idle, which is what a growing CPU-side gap in every worker does.
 
 ## 3. Code audit: what is allocated per job, and what is freed
 
-### 3.1 `proto-cuda/host.cu`, `runServe` (HEAD, the binary the founder ran, built by the launcher at 22:09:57)
+### 3.1 `proto-cuda/host.cu`, `runServe` (HEAD, the binary the project lead ran, built by the launcher at 22:09:57)
 
 | Allocation | When | Size | Freed |
 |---|---|---|---|
@@ -113,7 +113,7 @@ version (the hot-swap agent's) adds `CudaPair` (at most two resident, the old on
 job on the new pair, `releasePair` frees dataset, cache and both modules) and `PrepareTask` (deleted after
 the load); still nothing per job. `cudaDeviceSynchronize` per dispatch under the default
 `cudaDeviceScheduleAuto` spins the host thread when the process holds fewer contexts than the machine has
-cores, which is always true here (one context per process): that is the 6.2% CPU per worker the founder saw (one
+cores, which is always true here (one context per process): that is the 6.2% CPU per worker the project lead saw (one
 of 16 threads). The hot-swap working tree sets `cudaSetDeviceFlags(cudaDeviceScheduleBlockingSync)` before
 the context is created (host.cu, main), which is the right call and the right place; the thread then sleeps
 on the dispatch. It does not change the hash rate directly, but eight spinning threads plus eight OpenCL
@@ -250,7 +250,7 @@ because it is measured from the template fetch, which precedes the walk).
 
 ## 5. The time-slicing hypothesis: one worker versus eight, at two fixed difficulties
 
-The founder's Task Manager reading (GPU memory flat at 14.7 GB, the card 99% busy, each CUDA worker at 6.2% CPU) and the
+the project lead's Task Manager reading (GPU memory flat at 14.7 GB, the card 99% busy, each CUDA worker at 6.2% CPU) and the
 hypothesis that eight contexts time-slicing one card with "longer jobs as blocks get rarer" explain the decay. A
 job is a fixed 2^24 nonces, so its length does not depend on the target, but the four runs below test the
 hypothesis as stated: one Metal worker and eight, each at a fixed low difficulty (2^25, 0.25 founds per job)
@@ -483,20 +483,20 @@ warnings; also saved as `docs/analysis/hashrate-decay-2026-10-03.patch`).
    acceptance figure is table 2.2 flattening: the gap per job no better than 0.10 s at DAA 10,800 (3,600
    into an epoch) with eight identities.
 
-## 7. Two things for the founder to check on the PC
+## 7. Two things for the project lead to check on the PC
 
 1. Dedicated GPU memory over time. Task Manager, Performance, GPU 0, "Dedicated GPU memory usage", or
    `nvidia-smi --query-gpu=timestamp,memory.used,utilization.gpu,temperature.gpu,clocks.sm,clocks.mem,power.draw,clocks_throttle_reasons.active --format=csv -l 10 > gpu.csv`.
    Expected: flat from the moment the eighth worker prints `ready` (each CUDA worker holds 1 GiB dataset +
    256 MiB cache + 32 MiB output + the context, about 1.6 GiB; eight of them 13 to 15 GiB of the 32 GiB,
-   which matches the flat 14.7 GB the founder read). A line that climbs while the hash rate falls would mean a leak
+   which matches the flat 14.7 GB the project lead read). A line that climbs while the hash rate falls would mean a leak
    in the worker; none exists in the code and the Mac RSS traces are flat.
 2. GDDR7 memory junction temperature and the throttle reasons. HWiNFO64, Sensors, under the GPU: "GPU
    Memory Junction Temperature", "GPU Thermal Limit", "GPU Power Limit", "GPU Reliability Voltage Limit"
    (each "Yes" or "No"), "GPU Effective Clock" and "GPU Memory Clock"; or the `clocks_throttle_reasons.active`
    column above (`0x0000000000000004` is SW power cap, `0x0000000000000020` SW thermal slowdown,
    `0x0000000000000040` HW thermal slowdown, `0x0000000000000080` HW power brake). Approximate thresholds,
-   from memory: the core starts to pull clocks around 83 C (the founder's 55 to 59 C is far below it); GDDR6X on the
+   from memory: the core starts to pull clocks around 83 C (the project lead's 55 to 59 C is far below it); GDDR6X on the
    previous generations throttles from about 95 C junction and the hard limit is 105 C; GDDR7 figures are not
    published, so treat anything above 90 C junction as the zone to watch and a "Yes" on any limit row as the
    signal. The decisive sign of throttling is "GPU Effective Clock" falling while utilization stays at 99%;

docs/analysis/horizon-2026-10.md

@@ -1,8 +1,8 @@
 # Horizon, October 2026: the ranked research across every system
 
-Written 6 to 7 October 2026 by the Horizon coordinator (branch `horizon`, worktree `igneum-wt-horizon`) on the founder's ask of 6 October 2026, 20:4x UK: "deep backward and forward predictive research and modelling for our algo and all of our systems: is there room for improvement, room for more coin utility, algo improvements, security improvements, anything we can do to make a 51% attack impossible, basically creating a level of polish that has not been seen before." Later the same evening: "research anything else that we can research too, predictions, forward thinking, what we can actually do that has not been done or applied, think outside the box", "be revolutionary", and "if we create a new way of hashing or a new way of proof of work to revolutionise the space then that's absolutely fine, I want you to deploy everything to create something that has not ever been done before."
+Written 6 to 7 October 2026 by the Horizon coordinator (branch `horizon`, worktree `igneum-wt-horizon`) on the project lead's ask of 6 October 2026, 20:4x UK: "deep backward and forward predictive research and modelling for our algo and all of our systems: is there room for improvement, room for more coin utility, algo improvements, security improvements, anything we can do to make a 51% attack impossible, basically creating a level of polish that has not been seen before." Later the same evening: "research anything else that we can research too, predictions, forward thinking, what we can actually do that has not been done or applied, think outside the box", "be revolutionary", and "if we create a new way of hashing or a new way of proof of work to revolutionise the space then that's absolutely fine, I want you to deploy everything to create something that has not ever been done before."
 
-The bar main set, and the bar this document holds every claim to: "impossible" is not available to any proof-of-work chain. The bar is that a majority of hash buys nothing: it cannot reverse what finality locked, cannot forge a proof the nodes re-execute, cannot change a rule without 95 percent signalling, and loses more than it earns. Every claim here is a number with a model or a simulation behind it, priced in rented hash at the measured 6 October rate (`docs/bench-log.md`, "Rental cost of hash, 6 October 2026": USD 0.0117 per MH/s-hour, so USD 11.7 per GH/s-hour and about USD 281 per GH/s-day; the live devnet at 1.16 GH/s), with its consequence per tier and what to build. Hours are agent hours (the founder's rule: Claude-side work takes hours, never weeks).
+The bar main set, and the bar this document holds every claim to: "impossible" is not available to any proof-of-work chain. The bar is that a majority of hash buys nothing: it cannot reverse what finality locked, cannot forge a proof the nodes re-execute, cannot change a rule without 95 percent signalling, and loses more than it earns. Every claim here is a number with a model or a simulation behind it, priced in rented hash at the measured 6 October rate (`docs/bench-log.md`, "Rental cost of hash, 6 October 2026": USD 0.0117 per MH/s-hour, so USD 11.7 per GH/s-hour and about USD 281 per GH/s-day; the live devnet at 1.16 GH/s), with its consequence per tier and what to build. Hours are agent hours (the project lead's rule: Claude-side work takes hours, never weeks).
 
 ## The lanes
 
@@ -17,11 +17,11 @@ The bar main set, and the bar this document holds every claim to: "impossible" i
 | 7 frontier | `docs/analysis/horizon/frontier.md`; model `sim/horizon/frontier/frontier_model.py` | landed, commit 5ff7393 |
 | 8 new-proof-of-work | `docs/analysis/horizon/new-pow.md`; prototypes `proto-newpow/` | landed, commits cbcff47 and 92db7c5 (two prototypes measured on rented 4090s, verdicts in section 6) |
 
-## 1. One page for the founder
+## 1. One page for the project lead
 
 Closed 6 October 2026, 22:3x UK, every lane landed.
 
-**Standing decisions (the founder, 6 October 2026, 22:3x UK).** Verbatim: "Fees cannot fund security for a decade" and "Miners need to be the security". Meaning: miners are the security always, no time bound, no stake, no outside checkpoints or committee. The chain pays its own miners from emission plus fees; nobody pays upkeep, not the founder, not a treasury, not a dev fund. Self-sustaining means the emission curve keeps mining worth doing on its own for as long as fees are small, which lane 4 measures as a decade or more, so emission never decays on a schedule that assumes fees take over. Fee revenue is never assumed as the security budget in any model or public sentence. His third line, "Wrong constants and claims in our own text", acknowledges lane 6's finding; the nine ledger rows in item 9 are the fix.
+**Standing decisions (the project lead, 6 October 2026, 22:3x UK).** Verbatim: "Fees cannot fund security for a decade" and "Miners need to be the security". Meaning: miners are the security always, no time bound, no stake, no outside checkpoints or committee. The chain pays its own miners from emission plus fees; nobody pays upkeep, not the founder, not a treasury, not a dev fund. Self-sustaining means the emission curve keeps mining worth doing on its own for as long as fees are small, which lane 4 measures as a decade or more, so emission never decays on a schedule that assumes fees take over. Fee revenue is never assumed as the security budget in any model or public sentence. His third line, "Wrong constants and claims in our own text", acknowledges lane 6's finding; the nine ledger rows in item 9 are the fix.
 
 1. **The proving pool was the one line where a majority earned more than it spent**: 11,636 IGN an hour at 51 percent of blocks. Fix: the proof verified in consensus. **In 0.3.16** (fork exec-sync-0313 da2d17ec), switch `proving_consensus_verify_daa` off by default. **Decision owed:** when it activates.
 
@@ -41,54 +41,7 @@ Closed 6 October 2026, 22:3x UK, every lane landed.
 
 9. **Polish.** Pause wording in Ember and the API: **in 0.3.16** (ember-tune b726ce4). `fork_is_close` and the publisher's activation guard: **in 0.3.16** (1357d28, 08f5276). Export-disk cap: **done** (gpu-fleet f9ad70e). Nine text corrections (M32, M33, F26, E19, E20, G15, P24, E21, P25) plus X31 to X33: **done**. Unsigned installers: **decision owed**. Relay fixes (28c028b) on fud-close: merge owed.
 
-**Decisions owed from the founder:** the cryptanalysis spend (USD 80,000 to 160,000); the testnet date word; the N ladder at genesis; the verification switch activation.
-
-## Decisions ready for the founder (added 6 October 2026, 23:1x UK)
-
-Two one-page verdicts landed after the close. Each is quoted verbatim from its file and each is **the founder's decision owed**. The files sit on their branches and are not merged; read them there.
-
-### Emission: the tail
-
-`docs/analysis/tail-emission.md` on branch `tail-emission` (e1e28d2), ledger E22. The one page at the top of the file, 598 words:
-
-> **The problem.** Today's schedule pays miners USD 210,513 a day in year 1 at a flat USD 0.10, 6,877 in year 11, 427 in year 20, 13 in year 30. A 24-hour 51 percent rental costs 11.8 days of budget at any price and any hardware, so the attack costs USD 2.5 M in year 1, 81,106 in year 11, 5,042 in year 20, 158 in year 30. Year 20 pays 0.2 percent of year 1.
->
-> **Not a fix.** Fees (USD 450 a day at launch, 4,195 in year 5, under 1 percent of it to a miner; Bitcoin's fee share is 0.69 percent), a four-year halving (the same cliff later), a treasury (emission with an owner).
->
-> **The safe baseline.** A tail denominated in supply: p percent of scheduled supply a year for ever, from the first month the curve pays less. Security becomes a fixed share of market cap in every year: at p = 1 a 24-hour attack costs 0.032 percent of market cap, the 20-day veto 0.6 percent, at any price, no oracle. The holder gives **0.99 percent of their share a year** (9.5 percent over ten years), nothing else. No rent, no forced movement, no cost to inactivity.
->
-> **The revolutionary candidates, tested.** A hash thermostat (E) beats its withholding game only with presence pay and reads hardware as money: a 10x efficiency jump halves its budget for two years. Settled-value targeting (F) needs 8.5 percent inflation at velocity 1 and a wash trader pins it to its ceiling for one base fee. Security as a product (H) is 1 percent of the subsidy in year 1; dormant-coin rent (G) is refused by ruling. The hybrid (I) holds under every modelled attack and adds nothing to the floor.
->
-> **The supply question.** The coin count is cosmetic (18 decimals); the unit price is social. Kaspa and Dogecoin paid blocks in the hundreds of coins and drew miners. A solo 100 MH/s card on a 100 GH/s network earns 2,190 IGN a day today, 6,912 at 100 a block. A monthly glide loses 2.9 percent a month and halves nobody's income overnight.
->
-> **Recommendation, one coherent emission, every field a genesis parameter:** 100 IGN a block at one block a second; a monthly glide with a two-year half-life (Kaspa's shape at half its pace); a 90-day ramp from 10 percent; a 1 percent tail from the month the glide first pays under 1 percent of supply (year 11.4). Supply: 8.64 billion at the switch, 9.5 billion in year 20, 11.6 billion in year 40. The budget never falls under 1 percent of supply, tested to year 200.
->
-> **The public sentence** (replaces "4 billion, approached and never reached"): *Igneum has no hard cap. Emission starts at 100 IGN a block and falls 2.9 percent a month for ten years, then runs at 1 percent of supply a year for ever, every coin to the miners and provers who secure the chain. A holder's share falls 1 percent a year, and a 24-hour attack costs about twelve days of emission at any price, in any year.*
->
-> **What moves.** The emission constants of `igneum.rs` become one parameter set, `EmissionSchedule::CURRENT` (section 5 names each); the testnet carries `TESTNET_1`. Coded on fork branch `tail-emission-node`; the devnet digest is pinned unchanged by test; the testnet digest moves. A genesis decision for `igneum-testnet-1`, nothing live touched.
->
-> **Risks.** "No cap" is a sentence critics quote (E1 already concedes Monero's trade). The 1 percent is a judgement inside the peer range (Monero 0.85, Bitcoin 0.83, Ethereum about 0.5). Year 1 stays front-loaded (26 percent; 47 in two).
-
-### Vote or burn
-
-`docs/analysis/vote-or-burn.md` on branch `vote-weigh` (e816f28). The verdict, 498 words:
-
-> **Neither mechanism closes the line. Both price silence. Only the bonus passes the 95 percent test, and only at genesis.**
->
-> 1. **Honest silence, measured.** 10.4 percent of the 83 staying keys' 45,176 key-checkpoints over 24 hours sat under participation 0.5; 79 percent of that is 15 fleet keys the Devnet 2 gate swapped off the live chain and back, mining nothing while away. The 19 always-on desktop keys dipped under 0.5 in 3.4 percent of checkpoints, longest dip 34 minutes, which on mainnet's 2-hour window never reaches 0.5. Tonight's 20 silent keys mined nothing while silent, so the burn would not have shortened the pause.
->
-> 2. **History.** Every reward cut was fought and lost by the miners who stayed (Ethereum three times, Zcash three times, Ergo at 92 percent); where a cut removed a class's subsidy, the class left (Decred: two thirds of hash gone in a month). Offline penalties are accepted only as the reward forgone (Ethereum 0.625 against 0.844 earned; Cosmos 0.01 percent). No proof-of-work chain takes coins from a found block for a liveness fault.
->
-> 3. **The 95 percent test.** Respect: 7-day hash at least 95 percent of the week before, no fork over 5 percent at 30 days, 95 percent of weight signing. Estimates: burn 70 to 80 percent (a 20 percent cut of a found block for an outage, without precedent, and for ever from `--no-vote` miners and pool members without a verifier). Bonus at genesis 93 to 97 percent (nobody loses what they had). Bonus by signal after launch 85 to 90 percent. A bonus from the proving pool: 97 percent, deters nothing.
->
-> 4. **Security.** Weight is blue blocks (W2); an unpaid block is still weight, so a silent third keeps the veto under every mechanism. Base: the producer share. The burn prices a 34 percent set's silence at 6,206 IGN an hour (51-percent.md's 7,757 was 20 percent of the whole subsidy), the bonus at 3,103: USD 372 or 186 per 12-hour pause at USD 0.005; a deposit worth a double spend covers either. Weight-gated deep fork choice removes the prize; LEAVE ends tonight's class of pause.
->
-> 5. **Recommendation.** No burn: `vote_burn_bps` stays never and leaves the tree before the testnet code is public. The bonus, `signing_bonus_bps` 1,000 (node tree ca3-v4-0316 10db4b61), on from the testnet genesis as the schedule, never by signal: silence = a voter of the table at the latest checkpoint in the block's past with no vote in the presence window (7,200 s, 240 indices); a young key and a key under dust read as present; the unsigned tenth to the proving pool. Gate before the switch leaves never: the replay test of section 5, then the owner's word. The miner's sentence: **"Igneum pays 80 percent of each block to its miner. 8 of those 80 points are for signing finality, which your miner does by itself every 30 seconds. Miss two hours of signing and your next blocks pay 72 until you sign again. Nothing is burned."**
-
-### Open questions, being implemented
-
-- The N ladder list (the era-draw ladder of the algorithm lane): being implemented; the one page's owed item is its values at genesis.
-- 18 decimals: being implemented.
+**Decisions owed from the project lead:** the cryptanalysis spend (USD 80,000 to 160,000); the testnet date word; the N ladder at genesis; the verification switch activation.
 
 ## 2. The ranked list: top 25 across every lane
 
@@ -188,7 +141,7 @@ The residual risks stated plainly: the first 20 days (no weight table yet); a pa
 ### Lane 6, polish
 1. The pause had no cause on any surface: no `finality_reason` or frozen-table share in the node's report, the observer, the API, Ember or the hub (Q1, Q2, Q6); the 0.3.16 Ember carrier is on ember-tune.
 2. Every update was urgent once an activation height was behind the node (`fork_is_close`, Q4), and nothing refused an activation height at or below the live DAA; both fixed on ember-tune for 0.3.16.
-3. Unsigned installers on both desktops (Q3, the founder's certificates) and the relay's security fixes still on fud-close (Q8).
+3. Unsigned installers on both desktops (Q3, the project lead's certificates) and the relay's security fixes still on fud-close (Q8).
 
 ### Lane 8, new-proof-of-work
 1. Scheme A (mining is proving) is a bound, not a design: 2.9 MB of openings per block or a 32 to 40 ms verify against the 10 ms gate; the useful fraction is 8 percent at 1 GH/s and 0.08 percent at 100 GH/s.

docs/analysis/horizon/algorithm.md

@@ -305,11 +305,11 @@ Recommendation with numbers: hold the schedule as decided (2 GiB genesis, doubli
 | 5a | A class v5 candidate `mx8 + sh256x35` with a shuffle-heavy shadow weight table (shfl 14, shfla 8 of 75), measured on the four owned cards before any cut: the first rung of proposal 5's ladder, plus the k-floor lever | the Mac's 5 percent point is 130,000; the shuffle mix raises the k floor 0.32 to 0.46 (approx) | section 5.3 | 4 to build the weight-table knob and packs, 1 Mac measure session (about 6 min under the lock, miner paused), 3 PC jobs | M5 Max -4.8 percent of rate at 37 W; 5090 -0.3 percent at its 431 W cap (a rig +23 percent electricity); 4070 0 at about 118 W; 9070 XT 0; verifier +0.23 ms Mac, +0.85 half-core | every owned card within 5 percent; bit-exact on three vendors; half-core verifier under 10 ms; the 5090's marginal pJ on the new mix read on three rungs |
 | 6 | Hold the dataset schedule (2 GiB, years 4, 12, 28); write the prover footprint into the card-lifetime sentence | Steam shares and the measured prover peaks; one HBM3 stack holds every step | section 5.6 | 1 | 8 GB: mines to year 12, proves alone; 12 GB: mine-and-prove compressed to year 4, core-only to year 12, mines to year 28; 16 GB: compressed to year 4, core-only to year 12; 24 and 32 GB unconstrained to year 28 | the litepaper sentence matches the table; `docs/evidence.md` row "card lifetime" labelled designed |
 | 7 | Make the Ember tune the shipped default per card model (the honest card's watts are the lever that moves every chip row) | the 4070 at 3.65 uJ untuned and 2.57 tuned (-30 percent); the 5090 2.65 bench against 2.34 app | section 5.1 | 2 (defaults table in the app from the fleet priors; already measured) | every NVIDIA tier gains 10 to 30 percent per joule; the chip's edge over the mid-tier falls from 8x to 13x toward 5x to 9x at v3 | MH per W per card model on the fleet night against the untuned baseline |
-| 8 | Fund the k question: the item 3 cryptanalysis brief gains a chip-design line (a 14,000-lane SIMD array's energy per op on a random 32-lane program with shuffles, at N5 and at 28 nm) | every chip row at class v4 turns on k; nothing in the project measures it | section 5.3 | 0 agent hours; the founder's money (part of the USD 80,000 to 160,000 brief) | none until the number lands; it decides whether 2x is reachable | a reviewed estimate of k with its range |
+| 8 | Fund the k question: the item 3 cryptanalysis brief gains a chip-design line (a 14,000-lane SIMD array's energy per op on a random 32-lane program with shuffles, at N5 and at 28 nm) | every chip row at class v4 turns on k; nothing in the project measures it | section 5.3 | 0 agent hours; the project lead's money (part of the USD 80,000 to 160,000 brief) | none until the number lands; it decides whether 2x is reachable | a reviewed estimate of k with its range |
 
 Paragraphs.
 
-1. The verifier gate is the one place tonight produced a measurement instead of a rule. The box proxy brackets a 2019 laptop from both sides (a 2022 server core at full boost; the same core with its sibling busy), and dr736 fails both brackets while class v4 passes both with 1.8 ms to spare. The measurement is one Windows build and one bench on the laptop the founder already owns; until it lands, the half-core row replaces the "2.5x" from memory in every status file.
+1. The verifier gate is the one place tonight produced a measurement instead of a rule. The box proxy brackets a 2019 laptop from both sides (a 2022 server core at full boost; the same core with its sibling busy), and dr736 fails both brackets while class v4 passes both with 1.8 ms to spare. The measurement is one Windows build and one bench on the laptop the project lead already owns; until it lands, the half-core row replaces the "2.5x" from memory in every status file.
 
 2. The FPGA lane's upper row was built on an activate rate (8 per 12 ns per channel) that the JEDEC HBM2 cycle table does not support (4 per 28 ns); the measured Shuhai rate sits exactly on the JEDEC ceiling. That reading can be wrong (the ICCAD table's clock interpretation, the half-bank count, the board watts are all approximate), which is why the F2 hour is the proposal and not the conclusion. It is cheap and it turns a public ceiling claim into a measured one.
 

docs/analysis/horizon/consensus-security.md

@@ -176,7 +176,7 @@ Ways not in the seven, with the bound this lane gives:
 | The 30-day window edges | (a) the frozen table expires at exactly day 30.00 after the last lock: both sides of a long split lock alone at once (M3); (b) a departed set leaves the sliding table over 30 days and the frozen one at the cliff (M4); (c) the first 30 days have no lock at all (3.8, `min_daa` = window); (d) new honest cohorts are under-weighted t/60 for 30 days (G) | stated in 3.7 items 2, 7, 9 | a partition or departure longer than one window ends with the fork of 3.7 item 9 and a manual F5 | | |
 | The pause as a liveness attack | a silent set at or above 1/3 pauses every lock for as long as it stays silent (J, L1; sweep S) at zero marginal cost since it keeps earning | none in the rule; the node reports the pause; exchange guidance treats the chain as PoW with a 12-h depth | the 1/3 veto: 20 days at 51% | 0 once held | nothing directly; enables the 12-h PoW double spend below |
 | What an attacker can do during a pause | plain proof of work: reorg up to the finality depth 43,200 DAA (12 h) with a heavier chain; beyond merge depth the honest blocks are abandoned (the 229-block shape); every certified checkpoint before the pause still binds | finality depth; the exchange guidance of 3.9 | 12 h of >50% hash | USD 146 / 1.5k / 15k / 146k | a deposit credited at the PoW depth; 559k IGN of subsidy as a miner |
-| Tonight's departure (confirmed, lane 3 `finality-and-weight.md` 3.1 and 4.1) | 20 keys holding 42.7% of the frozen table stopped mining 18:27 to 18:30Z (the rehearsal job); the last lock 6842 at 18:39:40Z; 6843 determined with 53.1% of total signing and never locked; under v2 the stayers' sliding share crossed two thirds at 6912 (19:14:53Z, a 35-min pause) but Q5 held them at 57.3% of the frozen table; expected first lock when that table expires at DAA 216,402, about 20:40Z, or when 9.4 points of departed keys return. Sweep C agrees: 51% leaving pauses 10.5 days (v2) or 30.0 days (v3) at mainnet scale; at tonight's 46.9% (observer's view) 7.7 days under v2, 30 under v3 (lane 3, 4.1) | by design (F21: the founder chose the pause over the fork); a view cannot tell a departure from a partition | anything over 1/3 of the table leaving at once pauses finality for a window | 0 | 0; what an attacker can do during it is the row above |
+| Tonight's departure (confirmed, lane 3 `finality-and-weight.md` 3.1 and 4.1) | 20 keys holding 42.7% of the frozen table stopped mining 18:27 to 18:30Z (the rehearsal job); the last lock 6842 at 18:39:40Z; 6843 determined with 53.1% of total signing and never locked; under v2 the stayers' sliding share crossed two thirds at 6912 (19:14:53Z, a 35-min pause) but Q5 held them at 57.3% of the frozen table; expected first lock when that table expires at DAA 216,402, about 20:40Z, or when 9.4 points of departed keys return. Sweep C agrees: 51% leaving pauses 10.5 days (v2) or 30.0 days (v3) at mainnet scale; at tonight's 46.9% (observer's view) 7.7 days under v2, 30 under v3 (lane 3, 4.1) | by design (F21: the project lead chose the pause over the fork); a view cannot tell a departure from a partition | anything over 1/3 of the table leaving at once pauses finality for a window | 0 | 0; what an attacker can do during it is the row above |
 
 ### 4.4 Miner signalling (P2)
 

docs/analysis/horizon/finality-and-weight.md

@@ -6,7 +6,7 @@ What was read: `docs/spec/03-finality.md` (whole, 3.11 included), `04-seeds-and-
 
 ## 1. The three findings first
 
-1. **Tonight's pause was the rule, not the aggregation path, and it was the frozen table that held it past 19:14Z.** The 20 keys that left the live chain between 17:20Z and 18:30Z held 3,026 of 7,083 blue blocks of the table frozen at the last lock (42.7 percent; the 13 that left with the 18:27 to 18:30Z rehearsal job alone 36.5 percent). The first unlocked checkpoint, 6843 at DAA 209,233 (about 18:40Z), had 75 of 93 voters' votes and 53.1 percent of total weight on the observer's node, under the two-thirds floor; certificates had kept forming for 18 checkpoints while node 1 and the observer were down (6824 to 6842, 18:30 to 18:39Z, 83 signers, 78.5 to 79.7 percent of total). From 19:14:53Z (checkpoint 6912) the stayers held 74.9 percent of the sliding table and still did not lock, because they hold 57.3 percent of the frozen table of lock 6842, which stands until DAA 216,402 (about 20:40Z). Under rule v2 the first lock would have come at 6912, 35 minutes after the last; under v3 the pause is one window, 2 hours on the devnet and 30 days on mainnet (spec 3.7 item 2, the price the founder took on 4 October).
+1. **Tonight's pause was the rule, not the aggregation path, and it was the frozen table that held it past 19:14Z.** The 20 keys that left the live chain between 17:20Z and 18:30Z held 3,026 of 7,083 blue blocks of the table frozen at the last lock (42.7 percent; the 13 that left with the 18:27 to 18:30Z rehearsal job alone 36.5 percent). The first unlocked checkpoint, 6843 at DAA 209,233 (about 18:40Z), had 75 of 93 voters' votes and 53.1 percent of total weight on the observer's node, under the two-thirds floor; certificates had kept forming for 18 checkpoints while node 1 and the observer were down (6824 to 6842, 18:30 to 18:39Z, 83 signers, 78.5 to 79.7 percent of total). From 19:14:53Z (checkpoint 6912) the stayers held 74.9 percent of the sliding table and still did not lock, because they hold 57.3 percent of the frozen table of lock 6842, which stands until DAA 216,402 (about 20:40Z). Under rule v2 the first lock would have come at 6912, 35 minutes after the last; under v3 the pause is one window, 2 hours on the devnet and 30 days on mainnet (spec 3.7 item 2, the price the project lead took on 4 October).
 2. **Of the four candidate rules, only the departure announcement keeps the one-third bound.** In the simulator (3 seeds, mainnet scale) the decaying denominator and the hysteresis floor both restore liveness after tonight's departure in under an hour and both reopen the partition double lock (fast decay: both sides of every 360-minute partition lock alone from minute 120, 467 to 473 conflicting locks in the 50/50 honest split and 17 to 264 in the poisoned eclipse; slow decay: both sides of the 12-day splits lock alone at day 0.5 to 0.9, 31,545 to 32,246 conflicts; hysteresis: a 20 percent equivocator conflicts from minute 60, 565 to 597 locks, the 13.3 percent bound of 3 October back). The leave rule locks 1 hour after the departure (0.04 days; under 4 devnet minutes) with 0 conflicting locks in every partition, eclipse and equivocator row, and an attacker who buys keys to make them leave gains nothing it would not get by signing with them (w + L must still reach 2/3). The two-tier report never conflicts in its final tier by construction and shows 516 to 1,062 conflicting PROVISIONAL locks in every 360-minute partition and about 34,000 in the 12-day splits, so it is a reporting layer with a health warning, not a rule.
 3. **Weight costs USD 8,424 x N x W / (1 - W) to rent for the full window** at the measured USD 11.7 per GH/s-hour: a veto (34 percent) against a 1 GH/s network is USD 4,300 over 30 days (0.52 x N of hash, a +52 percent step on the chart from day 1), against 1 TH/s USD 4.3 M; locking alone (67 percent) is 2.03 x N for 30 days (USD 17,100 per GH/s of network, USD 17 M at 1 TH/s), and faster is dearer (22 days: 10.6 x N). Buying old keys costs the seller's own rental equivalent, decays to nothing in 30 days (sim K), and nothing in the protocol makes weight unbuyable; what keeps the price at the rental cost is that the seller keeps a copy and one equivocation strips the key.
 

docs/analysis/horizon/frontier.md

@@ -1,6 +1,6 @@
 # Horizon lane 7: frontier. Predictions to 2030, what no proof-of-work chain has shipped, and what Igneum can
 
-6 October 2026, evening UK. Lane 7 of the Horizon programme. Worktree `/Users/joshm/Projects/igneum-wt-horizon` (branch `horizon`, at origin/master 3f4f719). The founder's words: "research anything else that we can research too, predictions, forward thinking, what we can actually do that has not been done or applied, think outside the box", and "be revolutionary". Main's bar: not features, but ideas that change what a proof-of-work chain is or what a GPU owner is to the world, each with its evidence, cost, gate, and the attack a Monero or Kaspa core developer would mount. I argue each attack as the project's own four personas would hear it (`.claude/agents/cryptographer.md`, `consensus-engineer.md`, `execution-engineer.md`, `miner-community-lead.md`).
+6 October 2026, evening UK. Lane 7 of the Horizon programme. Worktree `/Users/joshm/Projects/igneum-wt-horizon` (branch `horizon`, at origin/master 3f4f719). the project lead's words: "research anything else that we can research too, predictions, forward thinking, what we can actually do that has not been done or applied, think outside the box", and "be revolutionary". Main's bar: not features, but ideas that change what a proof-of-work chain is or what a GPU owner is to the world, each with its evidence, cost, gate, and the attack a Monero or Kaspa core developer would mount. I argue each attack as the project's own four personas would hear it (`.claude/agents/cryptographer.md`, `consensus-engineer.md`, `execution-engineer.md`, `miner-community-lead.md`).
 
 Nothing in this file is a prediction of the coin's price, an offer to sell anything, or a change to any consensus parameter. Every chip figure is arithmetic on cited memory and logic figures; every GPU figure names its bench entry; a figure from memory says approximate. No em dashes.
 
@@ -12,7 +12,7 @@ Nothing in this file is a prediction of the coin's price, an offer to sell anyth
 
 ## 0. Everything ranked by payoff over difficulty
 
-Payoff 1 to 5 is what the idea does for the chain's security, the coin's utility or the GPU owner's position in the world, if it works. Difficulty is Claude-side hours to a measurable prototype (the founder's rule: hours, never weeks). Verdicts: do now, prototype, watch, never. The "never" rows carry a sharp reason so the rest are not fantasy.
+Payoff 1 to 5 is what the idea does for the chain's security, the coin's utility or the GPU owner's position in the world, if it works. Difficulty is Claude-side hours to a measurable prototype (the project lead's rule: hours, never weeks). Verdicts: do now, prototype, watch, never. The "never" rows carry a sharp reason so the rest are not fantasy.
 
 | Rank | Idea | Payoff | Hours | Verdict | One line why |
 |---|---|---|---|---|---|
@@ -322,7 +322,7 @@ The at-risk amount is five to nine orders of magnitude above the designed coin b
 
 ### 3.6 Treasury-less audit funding: bounties from the burn, a review escrow on upgrades
 
-**The idea.** the founder removed the dev fund (spec 5.5) and the project pays audits from the Ember dev fee and founders' mined coins (litepaper). The question: money for audits that comes from users paying for something, with no standing address. Two mechanisms. (a) **Burn redirect.** The base fee burns to nobody. A reproducible break submitted under spec 0.5 and accepted by 60 percent of blue blocks over a window redirects the base-fee burn of the next 7 (execution) or 30 (consensus) days to the submitter's address, once, then returns to burning. No address exists between events. (b) **Review escrow.** An upgrade proposal under 5.7 must escrow IGN in a contract that pays reviewers named in the proposal on a 60 percent "review complete" signal, or refunds on failure; the proposer pays, which is a user paying for a thing (the right to propose code).
+**The idea.** the project lead removed the dev fund (spec 5.5) and the project pays audits from the Ember dev fee and founders' mined coins (litepaper). The question: money for audits that comes from users paying for something, with no standing address. Two mechanisms. (a) **Burn redirect.** The base fee burns to nobody. A reproducible break submitted under spec 0.5 and accepted by 60 percent of blue blocks over a window redirects the base-fee burn of the next 7 (execution) or 30 (consensus) days to the submitter's address, once, then returns to burning. No address exists between events. (b) **Review escrow.** An upgrade proposal under 5.7 must escrow IGN in a contract that pays reviewers named in the proposal on a 60 percent "review complete" signal, or refunds on failure; the proposer pays, which is a user paying for a thing (the right to propose code).
 
 **Why nobody shipped it.** Zcash funds development from the block subsidy (NU6: 8 percent to Zcash Community Grants, 12 percent to a protocol lockbox, ZIP 1015); Decred from a 10 percent treasury spent by stakeholder vote, capped at 4 percent of balance a month since January 2026 (DCP-0013); Monero from the CCS, donations off-chain; Optimism from an 850 M OP reserve for retro funding. Bug bounties pay 10 percent of funds at risk (Immunefi's standard) from the protocol's own treasury; Code4rena runs contests at zero platform fee since 2025. Nobody funds audits from a burn redirect, because a burn redirect is a subsidy to a payee by rule, and the chains that wanted that built a treasury. New in form; a dev fund in substance (see the Monero attack).
 
@@ -341,7 +341,7 @@ At launch traffic a 30-day redirect is under one audit contest; at half-full blo
 
 **Hours.** 20 for the escrow contract and the redirect rule as a proposal kind; 0 for the honest alternative, which already exists.
 
-**The gate.** None that a simulator settles; the gate is the founder's: does a per-event, miner-approved payee with no standing address pass the test that removed the dev fund?
+**The gate.** None that a simulator settles; the gate is the project lead's: does a per-event, miner-approved payee with no standing address pass the test that removed the dev fund?
 
 **Per tier.** Miners vote on each payout with their blocks and can refuse all of them; holders see supply that would have burned paid to a named person; a prover, rig, pool user and rollup customer see nothing unless a break affects them; the node operator gains a proposal kind.
 
@@ -415,7 +415,7 @@ At launch traffic a 30-day redirect is under one audit contest; at half-full blo
 
 **The idea as asked.** Make the leader election depend in part on proving work, so the energy that picks the block maker is useful.
 
-**Why every attempt failed, cited.** Primecoin (2013) found Cunningham and bi-twin prime chains that nobody uses (Bitcoin Magazine, July 2013). Gridcoin pays for BOINC work and stops if BOINC stops (gridcoin.us; the 2022 "Challenges of PoUW" survey, arXiv 2209.03865). Ball, Rosen, Sabin and Vasudevan (eprint 2017/203) gave proofs of useful work from fine-grained problems (Orthogonal Vectors, 3SUM, APSP) and state the conditions: the problem must be sampleable at a tunable hardness with instances the miner cannot choose, and the verifier must be cheaper than the work. Ofelimos (Fitzi, Kiayias, Panagiotakos, Russell, CRYPTO 2022, eprint 2021/1379) got a provably secure protocol by making the work a doubly efficient local search whose usefulness is a side effect and small. The 2026 "Economics of Proof-of-Useful-Work" (arXiv 2606.06700) and the empirical study of Pearl's cuPOW (arXiv 2606.04819, "The Usefulness Gap") find the same gap between the work paid for and the work anyone wanted. I found no Coinbase paper on the subject (searched 6 October 2026); if the founder has one in mind, its title is needed. Aleo ran proving as the consensus work and the fastest prover won (CLAUDE.md: the Aleo lesson; litepaper precedents table, approximate). Boundless's PoVW (docs.boundless.network/zkc/mining/overview) pays ZKC pro rata to cycles proven per epoch with a stake that scales with the work, which is a reward for proving, not a leader election, and it is on a proof-of-stake chain.
+**Why every attempt failed, cited.** Primecoin (2013) found Cunningham and bi-twin prime chains that nobody uses (Bitcoin Magazine, July 2013). Gridcoin pays for BOINC work and stops if BOINC stops (gridcoin.us; the 2022 "Challenges of PoUW" survey, arXiv 2209.03865). Ball, Rosen, Sabin and Vasudevan (eprint 2017/203) gave proofs of useful work from fine-grained problems (Orthogonal Vectors, 3SUM, APSP) and state the conditions: the problem must be sampleable at a tunable hardness with instances the miner cannot choose, and the verifier must be cheaper than the work. Ofelimos (Fitzi, Kiayias, Panagiotakos, Russell, CRYPTO 2022, eprint 2021/1379) got a provably secure protocol by making the work a doubly efficient local search whose usefulness is a side effect and small. The 2026 "Economics of Proof-of-Useful-Work" (arXiv 2606.06700) and the empirical study of Pearl's cuPOW (arXiv 2606.04819, "The Usefulness Gap") find the same gap between the work paid for and the work anyone wanted. I found no Coinbase paper on the subject (searched 6 October 2026); if the project lead has one in mind, its title is needed. Aleo ran proving as the consensus work and the fastest prover won (CLAUDE.md: the Aleo lesson; litepaper precedents table, approximate). Boundless's PoVW (docs.boundless.network/zkc/mining/overview) pays ZKC pro rata to cycles proven per epoch with a stake that scales with the work, which is a reward for proving, not a leader election, and it is on a proof-of-stake chain.
 
 **The sampleability problem, plainly.** A lottery needs a puzzle whose instances are drawn at random from a distribution the miner cannot steer, whose hardness is tunable by a target, and whose solution is verifiable in milliseconds. zkVM proving has none of these: the instances (segments, jobs) are chosen by users and producers, the hardness is whatever the program is, and the verifier is tens of milliseconds to seconds. Any blend ("a miner's lottery target eases in proportion to its proven cycles last hour") gives the fastest prover more blocks, which is Aleo with a cap, and a cap small enough to be safe is a reward too small to be useful.
 
@@ -640,10 +640,10 @@ Smaller than the sections above; each with hours and a gate.
 | I6 | A finality-pause page on the site that shows the connected weight fraction live, so the "node reports the pause" sentence has a public face | 4 | Shows tonight's 18:42Z pause from the observer's data | Tonight's incident |
 | I7 | Equivocation-evidence bounty paid in sortition slots: the key that first carries valid evidence inherits the stripped key's shard assignments for 30 days (no coins move; weight is reassigned, not created) | 12 | Two signers under one key on the fast-time harness; the evidence carrier wins the stripped key's draws | Makes watching for equivocation pay without a treasury |
 | I8 | Mandatory proofs activation height set from a measured coverage share (spec 7.8 item 10) | 4 | Coverage above 99 percent for 7 days on the devnet | The rule is written and off |
-| I9 | The exclusive window at 25 s and the claim timeout at 120 s on the phase 4 devnet (decided by the founder, P9) with the economy simulator re-run at the measured shard times from `prover-tiers-real-cards.md` instead of the 20-s target | 6 | The 3060 class's shard share within 5 points of its weight share | The inputs changed today |
+| I9 | The exclusive window at 25 s and the claim timeout at 120 s on the phase 4 devnet (decided by the project lead, P9) with the economy simulator re-run at the measured shard times from `prover-tiers-real-cards.md` instead of the 20-s target | 6 | The 3060 class's shard share within 5 points of its weight share | The inputs changed today |
 | I10 | `eth_getProof`, `debug_traceTransaction`, `eth_subscribe` (D5 step 2) before any outside team | 24 | Foundry's debugger and the Blockscout fork run against a devnet node | The light client and every tool depend on `eth_getProof` |
 | I11 | Register chain ids 4461 to 4463 on ethereum-lists/chains before the public testnet (spec 7.1) | 1 | The PR merged | Wallets |
-| I12 | Publish the 2028 tier table (section 2.6) on the miner page with its three rates, so no card owner buys on a promise | 2 | Live | the founder's consequences rule |
+| I12 | Publish the 2028 tier table (section 2.6) on the miner page with its three rates, so no card owner buys on a promise | 2 | Live | the project lead's consequences rule |
 | I13 | A spec sentence in 03 and 05: "no coin stake; the only thing at stake is 30 days of public work" (4.1) | 1 | Text | Before 3.2 is prototyped |
 | I14 | The litepaper's income table gains the proving-market arithmetic of 3.11 in one line | 1 | Text | Ledger P6 asked for honesty; the number makes it concrete |
 | I15 | A ledger entry beside E4 recording 3.6 as considered and rejected on E4's ground | 1 | Text | So the question is not re-asked |

docs/analysis/horizon/network.md

@@ -6,7 +6,7 @@ What was read: `docs/spec/02-consensus.md` (2.1 parameters, 2.3 the difficulty r
 
 ## 1. The question and the answer in one paragraph
 
-The founder asked for Kaspa's answer to solo-miner variance: a higher block rate. Run A ran Devnet 2 at 10 blocks per second through one seed and produced 77 percent red blocks, 321 tips and a 55-block reorg. The propagation model says the links and the star did not do that: with the measured latencies it predicts under 0.1 percent red at 10 bps in a star and in a mesh. What did it is the seed's CPU per block, measured at 61 ms (narrow DAG) to 345 ms (mergeset 150 to 200), against a budget of 100 ms per block at 10 bps; with that cost in the model the star gives 47 to 88 percent red and queueing waits of 26 to 1,769 s, which are the "Accepted 100 blocks via relay" batches in the log. The difficulty rule then read blue work over a chain step capped at 2 s and hardened until the DAG ran at 2 s / (chain-step spacing) of target (model 4 blocks/s at a 5-s spacing, record 3.3 to 3.6), while a narrower-but-still-wide DAG would have made it ease (the direction main reported); counting every mergeset block over the real span, as Kaspa's window does, is unbiased in both regimes. The block rate for the public testnet is 1 bps; 10 bps is a gated step that needs the per-block node cost under 50 ms on a laptop core at a mergeset of 248, the checkpoint interval and the clock cap re-denominated in DAA seconds, and vote aggregation, because with C1 in blue blocks 8,192 voters at 10 bps are 66 GB per node per day of votes.
+the project lead asked for Kaspa's answer to solo-miner variance: a higher block rate. Run A ran Devnet 2 at 10 blocks per second through one seed and produced 77 percent red blocks, 321 tips and a 55-block reorg. The propagation model says the links and the star did not do that: with the measured latencies it predicts under 0.1 percent red at 10 bps in a star and in a mesh. What did it is the seed's CPU per block, measured at 61 ms (narrow DAG) to 345 ms (mergeset 150 to 200), against a budget of 100 ms per block at 10 bps; with that cost in the model the star gives 47 to 88 percent red and queueing waits of 26 to 1,769 s, which are the "Accepted 100 blocks via relay" batches in the log. The difficulty rule then read blue work over a chain step capped at 2 s and hardened until the DAG ran at 2 s / (chain-step spacing) of target (model 4 blocks/s at a 5-s spacing, record 3.3 to 3.6), while a narrower-but-still-wide DAG would have made it ease (the direction main reported); counting every mergeset block over the real span, as Kaspa's window does, is unbiased in both regimes. The block rate for the public testnet is 1 bps; 10 bps is a gated step that needs the per-block node cost under 50 ms on a laptop core at a mergeset of 248, the checkpoint interval and the clock cap re-denominated in DAA seconds, and vote aggregation, because with C1 in blue blocks 8,192 voters at 10 bps are 66 GB per node per day of votes.
 
 ## 2. Method
 

docs/analysis/horizon/new-pow.md

@@ -2,7 +2,7 @@
 
 6 October 2026, evening UK, lane `new-proof-of-work`, worktree `/Users/joshm/Projects/igneum-wt-horizon` (branch `horizon` from master, at 3f4f719). Output of this lane: this file and `proto-newpow/<scheme>/`. Nothing here touches the shipped hash, `igneum-pow`, the node, the manifest or the live devnet; every prototype is a benchmark beside the worker, never inside it.
 
-The founder's mandate, verbatim: "if we create a new way of hashing or a new way of proof of work to revolutionise the space then that's absolutely fine, I want you to deploy everything to create something that has not ever been done before."
+the project lead's mandate, verbatim: "if we create a new way of hashing or a new way of proof of work to revolutionise the space then that's absolutely fine, I want you to deploy everything to create something that has not ever been done before."
 
 ## 0. Progress (kept current for the coordinator)
 
@@ -286,7 +286,7 @@ Reading: B moves the f = 1 chip's edge by 1.4x to 2x at `k = 1` and by 1.1x at `
 
 ## 7. Ranked next steps
 
-Hours are agent hours (the founder's rule: Claude-side work takes hours). Each gate is a measurable pass line. Consequence per tier is the row's own. Ranks 2, 3 and 4 were written as B's gates before the ladder landed; after section 5 they are WITHDRAWN (B is not carried forward as class content; the rows stay so the reasoning is visible) and the live order is 1, 5, 6, 7, 8.
+Hours are agent hours (the project lead's rule: Claude-side work takes hours). Each gate is a measurable pass line. Consequence per tier is the row's own. Ranks 2, 3 and 4 were written as B's gates before the ladder landed; after section 5 they are WITHDRAWN (B is not carried forward as class content; the rows stay so the reasoning is visible) and the live order is 1, 5, 6, 7, 8.
 
 | Rank | Proposal | Evidence | Model | Hours | Consequence per tier | Gate |
 |---|---|---|---|---|---|---|
@@ -314,11 +314,11 @@ One paragraph each.
 | Question | Why it could not be closed tonight | What closes it |
 |---|---|---|
 | The 2019-class core (O-1.14) | no such core in the fleet; igneum-build-1 is Zen 4, the Mac is M5 Max; the 2.5x rule stands in | rank 7 |
-| The AMD WMMA fragment layout | PC 1 is the founder's desk and the AMD rows were owed all day (status file); no AMD card on RunPod or Vast tonight (fleet agent) | rank 2 |
+| The AMD WMMA fragment layout | PC 1 is the project lead's desk and the AMD rows were owed all day (status file); no AMD card on RunPod or Vast tonight (fleet agent) | rank 2 |
 | The Apple emulation of mm8 | a Metal emulation kernel is a 3-hour job and the Mac measure lock was free; not started because the AMD gate decides first whether B proceeds | rank 3 |
 | The canonical state serialisation for C | a design item that touches the exec layer (`igneum/exec`), out of this lane's files | rank 1 |
 | The pruning-proof witness for C's historical PoW | spec 02 and 10 items | rank 1 |
-| Whether the tensor path's marginal energy on the 5090 differs from the 4090's | one card measured (box 1); the 5090 is on the founder's desk | a PC 2 job with the same `run.sh` |
+| Whether the tensor path's marginal energy on the 5090 differs from the 4090's | one card measured (box 1); the 5090 is on the project lead's desk | a PC 2 job with the same `run.sh` |
 | The Ampere row (3060, 3080, 3090) | every Ampere card of the fleet was mining and proving the live devnet; a loaded 3090 was offered and declined (a loaded card's rate is not a number) | one quiet Ampere pod |
 | The verifier with a byte-dot instruction (VNNI, NEON udot) | the C reference is scalar | 1 h: an AVX-VNNI and a NEON path in `verify_ref.c`, measured on both cores |
 | Scheme C's leaf array on an 8 GB card at the 2 GiB design size | the build holds dataset + cache + leaves on the device (4.3 GiB) unless chunked | the chunked build (section 5.2 says whether it is trivial) |

docs/analysis/horizon/polish.md

@@ -2,7 +2,7 @@
 
 Date: 6 October 2026, evening UK (written 20:00 to 21:00Z, while the live devnet's finality was still paused). Lane 6 of the Horizon programme. Worktree `/Users/joshm/Projects/igneum-wt-horizon` (branch `horizon`, HEAD c3aa502). Output: this file only. No file outside it was edited; nothing was built, deployed, posted or started; the installed app and every live service were read, never touched.
 
-The founder's bar: "a level of polish that has not been seen before." This file is the honest audit: what each shipped system does, the named comparator and the exact screen or feature it has that we lack or do worse, the ledger rows that close the gap (95 rows, ids Q1 to Q105 with gaps, each with a file or screen, a severity, hours of agent work, an owner and a gate), and what is already better than the comparator. The first ten rows are what the founder will notice first when he opens each product tomorrow.
+the project lead's bar: "a level of polish that has not been seen before." This file is the honest audit: what each shipped system does, the named comparator and the exact screen or feature it has that we lack or do worse, the ledger rows that close the gap (95 rows, ids Q1 to Q105 with gaps, each with a file or screen, a severity, hours of agent work, an owner and a gate), and what is already better than the comparator. The first ten rows are what the project lead will notice first when he opens each product tomorrow.
 
 ## 0. What was read and run
 
@@ -14,26 +14,26 @@ Run (nothing live, nothing built): `node --test app/igneum-app/ui/*.test.mjs` (3
 
 Comparator claims are from memory unless a repository or page is named, and are labelled approximate.
 
-## 1. The ten rows the founder will notice first
+## 1. The ten rows the project lead will notice first
 
 | Rank | Id | Row | File or screen | Severity | Hours | Owner | Who it hits | Gate |
 |---|---|---|---|---|---|---|---|---|
-| 1 | Q1 | The pause has no cause anywhere. The node reports `finality_reason` (`active`, `window filling, N of M`, `paused`) but not the frozen-table share that held tonight's pause; the observer drops even the reason; the API has no reason field; `/live` computes "N% of weight silent" from the sliding table, which read 11 percent silent at 20:05Z while finality was paused (held by the table frozen at lock 6842, 57.3 percent signing). Add `finality_reason`, `held_by` (frozen index, its signing share, its expiry DAA) and lane 3's `finality_provisional` end to end | `vendor/igneum-node-0310/consensus/src/processes/finality.rs:1794-1807` (reason exists, no frozen share), `tools/observer/observer.mjs:720` (copies `finalityActive` only), `site/api/live.mjs:114-122` (no reason), `site/live.html:520` (the silent percentage) | the founder-visible | 4 (node 1.5, observer and API 1, `/live` and `/api/stats` copy 1, spec 3.9 row 0.5) | consensus-engineer (node), site owner (observer, API, page) | holder, exchange: the one line that says whether a pause is a silent third, a split, or a table waiting to expire; miner: nothing lost, but the app can finally explain itself; operator: a pause with a cause and an end time | A forced pause on Devnet 2 (one slice over a third stopped): `/api/live.finality` carries `reason`, `held_by`, `provisional`; `/live` reads "finality paused since 18:40Z: 89% of the sliding weight is signing, held by the table frozen at lock 6842 (57% signing) until DAA 216,402 (about 20:40Z)"; the exchange guidance in spec 3.9 carries the provisional row (lane 3 proposal 4) |
-| 2 | Q2 | Ember never says "paused". The engine keeps only `last_lock`, `last_lock_at`, `age_s`, `votes`; the node line showed "#6842 · 1 h ago" under "a point the miners agreed can never be undone" for the whole two-hour pause. No `finality_active` anywhere in the app | `app/igneum-app/src/state.rs:247-248`, `src/engine.rs:3495-3497, 3896-3902` (lock parsed from the miner's `LOCK checkpoint` line only), `ui/app.js:1350-1351` | the founder-visible | 3 | app owner (engine reads `getFinalityCheckpoints` or the miner's `FINALITY` line, spec 3.9 row; UI state and view test) | home miner and rig: the app tells them finality is paused and why, instead of a lock age that climbs; pool user: the same on the pool page later | Mock state with `finality_active:false, reason:"paused"` renders "Finality paused since 18:40Z, 89% of the 30-day weight signing, held by the frozen table until about 20:40Z" on the node line and in the pill; `view.test.mjs` case; seen on the Devnet 2 forced pause |
-| 3 | Q3 | A fresh machine's first 60 seconds start with a warning. macOS: ad hoc signature, no Developer ID, no notarisation; the engine strips `com.apple.quarantine` from its own bundle on start; the README's "Right-click > Open" bypass is gone on macOS 15 (approximate). Windows: installer and exes unsigned, SmartScreen "Windows protected your PC", then a UAC prompt for the firewall rule 20 to 50 s in before any screen explains it | `packaging/mac/build-dmg.sh:118-122`, `packaging/mac/README.md:51-53`, `app/igneum-app/src/main.rs:78`, `packaging/windows/README.md:76, 111`, `packaging/windows/build-installer.ps1:188`, `app/igneum-app/src/ota.rs:981-1015` | the founder-visible | 6 (Developer ID signing plus `notarytool` and stapling in `build-dmg.sh` 3; Authenticode `signtool` step in `windows.yml` and `build-installer.ps1` 2; firewall step after `setup_done` with a sentence on the Cards screen 1), plus the founder: an Apple Developer account and an OV or EV code-signing certificate (purchases, hours of the founder's time, approximate) | app owner; the founder (the certificates) | every new miner on every tier, Windows and macOS: Signal's and Tailscale's installers open with no warning (approximate); today ours open with two | Fresh macOS 15 VM: the DMG's app opens on double-click, `spctl -a -vv` says accepted and notarised; fresh Windows 11 VM: no SmartScreen interstitial, `signtool verify /pa` passes; the first UAC prompt appears after the Cards screen names it |
-| 4 | Q4 | Every update is "urgent" once an activation height is behind the node: `fork_is_close(Some(198000), 209000)` is true, so the manifest's stale `activation 198000` turned the 0.3.14 update into "the node is 0 blocks away. Installing now", stripped Later and skipped every safe-moment guard (the PC 1 install under a measurement job at 17:52:54Z). The same path has no finality input: an update applies through a pause | `app/igneum-app/src/manifest.rs:350-355` (`daa + 1800 >= h`), `:322-347` (`safe_to_apply`, no finality), `src/ota.rs:484`, `ui/app.js:217`, `docs/plans/release-0.3.14.md:79`, `release-0.3.15.md` section 6 | the founder-visible | 3 (close means within 1,800 blocks ahead and not behind 1; the publisher drops a passed `activation_height` 0.5; `Moment.finality_paused` holds a non-urgent update 1.5) | app owner | home miner, rig: no surprise restart mid-measurement or mid-pause; operator: an activation that has passed is not an emergency | Unit tests: behind by any amount is not close; `publish-manifest.sh` refuses a passed height; a paused mock holds the update with the words "finality is paused; installing when it resumes"; the 0.3.16 manifest carries no stale height |
-| 5 | Q5 | The homepage says "final" while finality is paused, in a 90-word hero, under a share card that renders as a thumbnail. The chain scene takes `src.locked` and draws the dashed line labelled "final" at the newest locked block with no `finality.active` check (R4.6.3 was fixed on `/live` only); the hero is one 90-word paragraph with two bench deep links and "ships when the packaging row lands"; the miner section still says "a 24 GB NVIDIA card proves as well" while the hero and litepaper say 8 GB; home, litepaper, live and explorer share a 256 px `og-small.png` with `summary` cards | `site/index.html:810, 838` (final label), `:345` (hero), `:494` and `site/miner.html:7, 13, 21, 265, 382` (24 GB), `site/index.html:15-19` (OG) | the founder-visible | 3 (final label 0.5, hero 1, 24 GB sentence 0.5, four 1200x630 cards 1) | site owner | every visitor; a holder or exchange reading "final" during a pause is the worst of them | No "final" label while `finality.active` is false (the `/live` rule); hero under 40 words with one link; one proving-tier sentence on every page; every page's shared card is 1200x630 |
-| 6 | Q6 | The hub shows stale data as live, said "active" for the first 20 unlocked checkpoints, says "paused" with no since or cause, and buried the pause under 401 miner_quiet and miner_back events. After the first load an API failure only changes the header to "offline: ..."; tiles, cards and "Refreshed" keep the old values. `finality_active` flips only after `presence_window` (20 on the devnet) indices without a lock, so 18:42 to 18:50Z read "active" in white with no lock forming. No `finality_paused` or `finality_resumed` event exists; `live_events` between 18:25Z and 21:30Z holds 203 `miner_quiet`, 198 `miner_back`, 55 `difficulty`, 30 `checkpoint_locked` (the last at 18:42:10Z) and no pause row. The checkpoint table also showed "% of active" above 100 (102.4 to 113.4 percent on indices 6900 to 6930) | `relay/ui.html:564` (stale), `:367-368` (tile), `relay/api/console.mjs:214`, `vendor/igneum-node-0310/consensus/src/processes/finality.rs:1794` and `vendor/igneum-node/consensus/core/src/finality.rs:63, 75` (`presence_window` 240 mainnet, 20 devnet), `tools/observer/observer.mjs:652` (the only finality event), `live_checkpoints.fraction_active` rows 6900 to 6930 | the founder-visible | 4 (dim every panel with "last data N min ago" 1; amber on the first under-2/3 checkpoint 0.5; `finality_paused` and `finality_resumed` events, and collapse quiet/back pairs under 5 min 1.5; clamp or explain the active fraction 1) | fleet agent (hub), consensus-engineer (observer events, the fraction) | operator: the hub is the founder's first screen; a holder reading the public API gets the same events | Cut the network: every hub panel dims within 15 s; a forced Devnet 2 pause turns the tile amber on the first checkpoint under two thirds, posts one `finality_paused` event with the cause and one `finality_resumed` with the duration; no fraction above 100 percent on any row for 24 h |
-| 7 | Q7 | Discord said nothing. The bot has no credentials file and its timer is not installed, so tonight's pause produced zero posts; had it been live, a condition already firing at the watcher's first look is marked `preexisting` and never opens an incident; the pulse hides the pause in its description with no colour or title change | `docs/community/discord-hooks.md:81-82`, `tools/community/discord-hooks.mjs:481-485`, `:252-255`, `:158`, `infra/build-server/discord-hooks/install.sh` | the founder-visible | 3 (install and one live pulse 1; a pre-existing condition opens with "since at least <first look>" 1; paused pulse in a distinct colour with a title suffix 1) | miner-community-lead (community owner) | every Discord reader, which on launch day is every miner | `check` prints three "set"; one live pulse in #numbers; a fixture where the pause predates the first tick opens an incident; the paused pulse renders amber with "(finality paused)" in the title |
+| 1 | Q1 | The pause has no cause anywhere. The node reports `finality_reason` (`active`, `window filling, N of M`, `paused`) but not the frozen-table share that held tonight's pause; the observer drops even the reason; the API has no reason field; `/live` computes "N% of weight silent" from the sliding table, which read 11 percent silent at 20:05Z while finality was paused (held by the table frozen at lock 6842, 57.3 percent signing). Add `finality_reason`, `held_by` (frozen index, its signing share, its expiry DAA) and lane 3's `finality_provisional` end to end | `vendor/igneum-node-0310/consensus/src/processes/finality.rs:1794-1807` (reason exists, no frozen share), `tools/observer/observer.mjs:720` (copies `finalityActive` only), `site/api/live.mjs:114-122` (no reason), `site/live.html:520` (the silent percentage) | the project lead-visible | 4 (node 1.5, observer and API 1, `/live` and `/api/stats` copy 1, spec 3.9 row 0.5) | consensus-engineer (node), site owner (observer, API, page) | holder, exchange: the one line that says whether a pause is a silent third, a split, or a table waiting to expire; miner: nothing lost, but the app can finally explain itself; operator: a pause with a cause and an end time | A forced pause on Devnet 2 (one slice over a third stopped): `/api/live.finality` carries `reason`, `held_by`, `provisional`; `/live` reads "finality paused since 18:40Z: 89% of the sliding weight is signing, held by the table frozen at lock 6842 (57% signing) until DAA 216,402 (about 20:40Z)"; the exchange guidance in spec 3.9 carries the provisional row (lane 3 proposal 4) |
+| 2 | Q2 | Ember never says "paused". The engine keeps only `last_lock`, `last_lock_at`, `age_s`, `votes`; the node line showed "#6842 · 1 h ago" under "a point the miners agreed can never be undone" for the whole two-hour pause. No `finality_active` anywhere in the app | `app/igneum-app/src/state.rs:247-248`, `src/engine.rs:3495-3497, 3896-3902` (lock parsed from the miner's `LOCK checkpoint` line only), `ui/app.js:1350-1351` | the project lead-visible | 3 | app owner (engine reads `getFinalityCheckpoints` or the miner's `FINALITY` line, spec 3.9 row; UI state and view test) | home miner and rig: the app tells them finality is paused and why, instead of a lock age that climbs; pool user: the same on the pool page later | Mock state with `finality_active:false, reason:"paused"` renders "Finality paused since 18:40Z, 89% of the 30-day weight signing, held by the frozen table until about 20:40Z" on the node line and in the pill; `view.test.mjs` case; seen on the Devnet 2 forced pause |
+| 3 | Q3 | A fresh machine's first 60 seconds start with a warning. macOS: ad hoc signature, no Developer ID, no notarisation; the engine strips `com.apple.quarantine` from its own bundle on start; the README's "Right-click > Open" bypass is gone on macOS 15 (approximate). Windows: installer and exes unsigned, SmartScreen "Windows protected your PC", then a UAC prompt for the firewall rule 20 to 50 s in before any screen explains it | `packaging/mac/build-dmg.sh:118-122`, `packaging/mac/README.md:51-53`, `app/igneum-app/src/main.rs:78`, `packaging/windows/README.md:76, 111`, `packaging/windows/build-installer.ps1:188`, `app/igneum-app/src/ota.rs:981-1015` | the project lead-visible | 6 (Developer ID signing plus `notarytool` and stapling in `build-dmg.sh` 3; Authenticode `signtool` step in `windows.yml` and `build-installer.ps1` 2; firewall step after `setup_done` with a sentence on the Cards screen 1), plus the project lead: an Apple Developer account and an OV or EV code-signing certificate (purchases, hours of the project lead's time, approximate) | app owner; the project lead (the certificates) | every new miner on every tier, Windows and macOS: Signal's and Tailscale's installers open with no warning (approximate); today ours open with two | Fresh macOS 15 VM: the DMG's app opens on double-click, `spctl -a -vv` says accepted and notarised; fresh Windows 11 VM: no SmartScreen interstitial, `signtool verify /pa` passes; the first UAC prompt appears after the Cards screen names it |
+| 4 | Q4 | Every update is "urgent" once an activation height is behind the node: `fork_is_close(Some(198000), 209000)` is true, so the manifest's stale `activation 198000` turned the 0.3.14 update into "the node is 0 blocks away. Installing now", stripped Later and skipped every safe-moment guard (the PC 1 install under a measurement job at 17:52:54Z). The same path has no finality input: an update applies through a pause | `app/igneum-app/src/manifest.rs:350-355` (`daa + 1800 >= h`), `:322-347` (`safe_to_apply`, no finality), `src/ota.rs:484`, `ui/app.js:217`, `docs/plans/release-0.3.14.md:79`, `release-0.3.15.md` section 6 | the project lead-visible | 3 (close means within 1,800 blocks ahead and not behind 1; the publisher drops a passed `activation_height` 0.5; `Moment.finality_paused` holds a non-urgent update 1.5) | app owner | home miner, rig: no surprise restart mid-measurement or mid-pause; operator: an activation that has passed is not an emergency | Unit tests: behind by any amount is not close; `publish-manifest.sh` refuses a passed height; a paused mock holds the update with the words "finality is paused; installing when it resumes"; the 0.3.16 manifest carries no stale height |
+| 5 | Q5 | The homepage says "final" while finality is paused, in a 90-word hero, under a share card that renders as a thumbnail. The chain scene takes `src.locked` and draws the dashed line labelled "final" at the newest locked block with no `finality.active` check (R4.6.3 was fixed on `/live` only); the hero is one 90-word paragraph with two bench deep links and "ships when the packaging row lands"; the miner section still says "a 24 GB NVIDIA card proves as well" while the hero and litepaper say 8 GB; home, litepaper, live and explorer share a 256 px `og-small.png` with `summary` cards | `site/index.html:810, 838` (final label), `:345` (hero), `:494` and `site/miner.html:7, 13, 21, 265, 382` (24 GB), `site/index.html:15-19` (OG) | the project lead-visible | 3 (final label 0.5, hero 1, 24 GB sentence 0.5, four 1200x630 cards 1) | site owner | every visitor; a holder or exchange reading "final" during a pause is the worst of them | No "final" label while `finality.active` is false (the `/live` rule); hero under 40 words with one link; one proving-tier sentence on every page; every page's shared card is 1200x630 |
+| 6 | Q6 | The hub shows stale data as live, said "active" for the first 20 unlocked checkpoints, says "paused" with no since or cause, and buried the pause under 401 miner_quiet and miner_back events. After the first load an API failure only changes the header to "offline: ..."; tiles, cards and "Refreshed" keep the old values. `finality_active` flips only after `presence_window` (20 on the devnet) indices without a lock, so 18:42 to 18:50Z read "active" in white with no lock forming. No `finality_paused` or `finality_resumed` event exists; `live_events` between 18:25Z and 21:30Z holds 203 `miner_quiet`, 198 `miner_back`, 55 `difficulty`, 30 `checkpoint_locked` (the last at 18:42:10Z) and no pause row. The checkpoint table also showed "% of active" above 100 (102.4 to 113.4 percent on indices 6900 to 6930) | `relay/ui.html:564` (stale), `:367-368` (tile), `relay/api/console.mjs:214`, `vendor/igneum-node-0310/consensus/src/processes/finality.rs:1794` and `vendor/igneum-node/consensus/core/src/finality.rs:63, 75` (`presence_window` 240 mainnet, 20 devnet), `tools/observer/observer.mjs:652` (the only finality event), `live_checkpoints.fraction_active` rows 6900 to 6930 | the project lead-visible | 4 (dim every panel with "last data N min ago" 1; amber on the first under-2/3 checkpoint 0.5; `finality_paused` and `finality_resumed` events, and collapse quiet/back pairs under 5 min 1.5; clamp or explain the active fraction 1) | fleet agent (hub), consensus-engineer (observer events, the fraction) | operator: the hub is the project lead's first screen; a holder reading the public API gets the same events | Cut the network: every hub panel dims within 15 s; a forced Devnet 2 pause turns the tile amber on the first checkpoint under two thirds, posts one `finality_paused` event with the cause and one `finality_resumed` with the duration; no fraction above 100 percent on any row for 24 h |
+| 7 | Q7 | Discord said nothing. The bot has no credentials file and its timer is not installed, so tonight's pause produced zero posts; had it been live, a condition already firing at the watcher's first look is marked `preexisting` and never opens an incident; the pulse hides the pause in its description with no colour or title change | `docs/community/discord-hooks.md:81-82`, `tools/community/discord-hooks.mjs:481-485`, `:252-255`, `:158`, `infra/build-server/discord-hooks/install.sh` | the project lead-visible | 3 (install and one live pulse 1; a pre-existing condition opens with "since at least <first look>" 1; paused pulse in a distinct colour with a title suffix 1) | miner-community-lead (community owner) | every Discord reader, which on launch day is every miner | `check` prints three "set"; one live pulse in #numbers; a fixture where the pause predates the first tick opens an incident; the paused pulse renders amber with "(finality paused)" in the title |
 | 8 | Q8 | The relay's security fixes are not on master. Commit 28c028b (X23 to X28: `relay/lib/guard.mjs`, `handler.mjs`, run signatures, retention) is on `fud-close` and the `ledger-*` branches only; `git merge-base --is-ancestor 28c028b master` is false. On this tree any of the three intake keys (one ships in every miner app) can post, sync and delete console items, read the whole feed, and every client puts the token in the URL path | `relay/api/console.mjs:249, 283-301`, `relay/lib/relay.mjs:34-46`, `relay/clients/agent.sh:10`, `igneum-agent.ps1:13, 72, 154`, `tools/relay.mjs:24` | operator-visible (security) | 2 (merge or cherry-pick with the 47 relay tests 1; handler test that an intake key gets 403 on post, sync, delete 1) | fleet agent (relay owner) | operator: the console is the control plane for every PC and the fleet; a miner app's intake key is in every install | `28c028b` is an ancestor of the deploying branch; 47 relay tests pass; the handler test above passes; `relay/README.md` names the deployed commit |
-| 9 | Q86 | The fleet page is blind to the standing fleet, to death and to finality. `page.py:43-47` publishes `standing` and `devnet2` and the page references neither (grep 0); a dead box reads "running" for up to 20 minutes because state comes from `boxes.json` and `standing.jsonl` is never read; no fleet or console script reads `finality_active`, so tonight's pause was found by hand. The night the founder ruled that 22 boxes stay up permanently, the page that shows them cannot show them | `igneum-wt-gpu-fleet/tools/fleet/page.py:38-47`, dlsite `index.html:243`, `lib/standing.py:54-56`, `tools/console.mjs:124` | the founder-visible | 6 (standing block with USD per day and the Devnet 2 gate line 2; "unreachable since HH:MM" within 2 minutes 2; finality on the page and in `console.mjs chain` 2) | fleet agent | operator (the founder reads this page every evening); every tier indirectly: a dead standing box is weight that left silently, the class of tonight's pause | the page shows the standing count and spend; a box killed by hand reads "unreachable since" within 2 minutes; a forced Devnet 2 pause reads on the page and in the console |
-| 10 | Q9 | The wallet page describes 0.1.4 while UI 3 (five state words, light mode, pounds line) sits unmerged on `wallet-ui-3`; the MetaMask guide's testnet RPC is still labelled a placeholder, its devnet RPC port is the miner's node (26790) while a wallet-only Mac runs 26800, and `wallet_addEthereumChain` carries `blockExplorerUrls: []` and no `iconUrls`, so MetaMask shows no explorer link and a blank icon | `site/wallet.html:261-266, 312`, `igneum-wt-wallet-ui/docs/plans/wallet-ui-3.md:93, 112`, `site/metamask.html:197, 225, 233, 285-286`, `igneum-wt-wallet/app/igneum-wallet/src/node.rs:24-26` | the founder-visible | 6 (wallet 0.1.5 with UI 3 published and the page rewritten 4; guide: both ports, the placeholder line removed, explorer URL and icon in the request 2) | app owner (wallet), site owner (guide) | holder: the first non-miner product; a wrong port or a placeholder RPC is a dead end at the first step | `downloads.json` wallet-mac 0.1.5; the page names pending, included, executed, proven, finalised; `eth_chainId` returns 0x116e from the guide's URL; MetaMask shows the explorer link after the add-chain button |
+| 9 | Q86 | The fleet page is blind to the standing fleet, to death and to finality. `page.py:43-47` publishes `standing` and `devnet2` and the page references neither (grep 0); a dead box reads "running" for up to 20 minutes because state comes from `boxes.json` and `standing.jsonl` is never read; no fleet or console script reads `finality_active`, so tonight's pause was found by hand. The night the project lead ruled that 22 boxes stay up permanently, the page that shows them cannot show them | `igneum-wt-gpu-fleet/tools/fleet/page.py:38-47`, dlsite `index.html:243`, `lib/standing.py:54-56`, `tools/console.mjs:124` | the project lead-visible | 6 (standing block with USD per day and the Devnet 2 gate line 2; "unreachable since HH:MM" within 2 minutes 2; finality on the page and in `console.mjs chain` 2) | fleet agent | operator (the project lead reads this page every evening); every tier indirectly: a dead standing box is weight that left silently, the class of tonight's pause | the page shows the standing count and spend; a box killed by hand reads "unreachable since" within 2 minutes; a forced Devnet 2 pause reads on the page and in the console |
+| 10 | Q9 | The wallet page describes 0.1.4 while UI 3 (five state words, light mode, pounds line) sits unmerged on `wallet-ui-3`; the MetaMask guide's testnet RPC is still labelled a placeholder, its devnet RPC port is the miner's node (26790) while a wallet-only Mac runs 26800, and `wallet_addEthereumChain` carries `blockExplorerUrls: []` and no `iconUrls`, so MetaMask shows no explorer link and a blank icon | `site/wallet.html:261-266, 312`, `igneum-wt-wallet-ui/docs/plans/wallet-ui-3.md:93, 112`, `site/metamask.html:197, 225, 233, 285-286`, `igneum-wt-wallet/app/igneum-wallet/src/node.rs:24-26` | the project lead-visible | 6 (wallet 0.1.5 with UI 3 published and the page rewritten 4; guide: both ports, the placeholder line removed, explorer URL and icon in the request 2) | app owner (wallet), site owner (guide) | holder: the first non-miner product; a wrong port or a placeholder RPC is a dead end at the first step | `downloads.json` wallet-mac 0.1.5; the page names pending, included, executed, proven, finalised; `eth_chainId` returns 0x116e from the guide's URL; MetaMask shows the explorer link after the add-chain button |
 
 Next in line, outside the ten: Q10 (the explorer knows nothing about finality and swallows failures after first load, 3 hours), Q80 (the Windows installer pipeline is dead on GitHub billing) and Q12 (Ember's light mode fails contrast on the private key and every live state).
 
-Hours for the ten: 40 agent hours, plus the founder's certificate purchases for Q3.
+Hours for the ten: 40 agent hours, plus the project lead's certificate purchases for Q3.
 
-## 2. Tonight's pause on every surface (the ledger row the founder asked for)
+## 2. Tonight's pause on every surface (the ledger row the project lead asked for)
 
 Times UTC. The chain-side facts are lane 3's (`finality-and-weight.md` 3.1) and the observer's own rows, read tonight: last lock 6842 at about 18:39:40Z; 6843 proposed at 53.1 percent of total; `finality_active` false from about 18:50Z (index 6862, twenty indices without a lock, `presence_window` 20); no lock after 6842 as of 20:05:03Z (`live_state.updated_at`), `total_weight` 7,167, `active_weight` 6,346 (88.5 percent signing on the sliding table), `voters` 85, and no `finality_reason` key in the stored JSON. Sampled `live_checkpoints` rows:
 
@@ -82,20 +82,20 @@ The row for the ledger: **Q1 plus Q2, Q5, Q6, Q7, Q10**: every public and operat
 
 | Id | Row | File or screen | Severity | Hours | Owner | Gate |
 |---|---|---|---|---|---|---|
-| Q2 | Finality pause invisible (section 1) | `state.rs:247`, `engine.rs:3495`, `app.js:1350` | the founder-visible | 3 | app owner | section 1 |
-| Q4 | Every update urgent once the activation is behind; no finality hold (section 1) | `manifest.rs:322-355` | the founder-visible | 3 | app owner | section 1 |
+| Q2 | Finality pause invisible (section 1) | `state.rs:247`, `engine.rs:3495`, `app.js:1350` | the project lead-visible | 3 | app owner | section 1 |
+| Q4 | Every update urgent once the activation is behind; no finality hold (section 1) | `manifest.rs:322-355` | the project lead-visible | 3 | app owner | section 1 |
 | Q11 | Offline start says "The update failed." A check error with no held manifest calls `set_error`; the cached manifest is loaded for the floor but never into `self.manifest`; the notice offers "Try again", which POSTs install | `ota.rs:649-654, 195-200`, `app.js:29, 1198` | user-visible | 1 | app owner | notices test: a check-class error renders "Could not check for updates" with no install action |
 | Q12 | Light mode fails contrast on every live text: molten `#B8731F` on white 3.81:1, on bone 3.38:1; ember `#E04A14` on bone 3.61:1; molten carries the private key, the address and the live states. `miner-ui-3.md` section 9 claims 4.5:1 everywhere | `app.css:29, 263, 338, 431` | user-visible | 1 | app owner | a node script over the token pairs asserts 4.5:1 for every text token in both schemes; CI runs it |
-| Q13 | Per-card rejects and faults never reach the row (the lolMiner line) | `app.js:291-309, 1290` | the founder-visible on PC 1 | 2 | miner-community-lead | row meta "N rejected · M faults" when nonzero; view test |
+| Q13 | Per-card rejects and faults never reach the row (the lolMiner line) | `app.js:291-309, 1290` | the project lead-visible on PC 1 | 2 | miner-community-lead | row meta "N rejected · M faults" when nonzero; view test |
 | Q14 | Windows first run raises a UAC prompt (firewall rule) before any screen explains it (part of Q3) | `ota.rs:981-1015`, `index.html:71-99` | user-visible | 1 | app owner | the firewall step runs after `setup_done`; the Cards screen names it |
-| Q15 | Mac first-run instruction stale: "Right-click > Open" (part of Q3) | `packaging/mac/README.md:51`, `site/miner.html` download copy | the founder-visible on a fresh Mac | 1 | app owner | the download page and README name the Privacy and Security step until the certificate lands |
+| Q15 | Mac first-run instruction stale: "Right-click > Open" (part of Q3) | `packaging/mac/README.md:51`, `site/miner.html` download copy | the project lead-visible on a fresh Mac | 1 | app owner | the download page and README name the Privacy and Security step until the certificate lands |
 | Q16 | No rate history: a 10-minute strip against HiveOS's hours | `app.js:1052-1127` | user-visible | 4 | app owner | one-hour per-card sparkline from an engine ring buffer; view test |
 | Q17 | Hill climb hidden until `tune_climb` is on the state | `index.html:341`, `app.js:1407` | operator-visible | 1 | app owner | the row shows whenever the engine answers `tune/goal` |
 | Q18 | Earnings never shows mined IGN; "£0.00 earned" is the first number on the tab | `index.html:250`, `app.js:1364` | user-visible | 2 | miner-community-lead | the tab shows blocks mined and the subsidy they earned in IGN, with the devnet line under it |
 | Q19 | 10 px type in five places, 9 px ruler | `app.css:196, 271, 272, 302, 491, 531` | cosmetic | 1 | app owner | no `font-size` under 11 px except the ruler |
 | Q20 | Design screens in `docs/design/app-screens/*.png` are a UI 1 app (v0.3.0 tiles, a Finality card the shipped UI lacks) | `docs/design/app-screens/` | cosmetic | 1 | app owner | screens regenerated from `?screen=` on the current build |
 | Q21 | AMD step line prints a percent as watts ("owed: a unit word for AMD") | `ember-tune.md:278` | operator-visible | 1 | miner-community-lead | the line reads "70% (an offset)"; unit test |
-| Q22 | A code comment naming the founder ships in the UI bundle (`// The list is ordered by performance (the founder, 6 October 2026)`), and the ui bundle is outside every forbidden-string check | `app/igneum-app/ui/app.js:270`, `tools/ci/identity-check.sh` | cosmetic (identity rule) | 0.5 | app owner | `tools/ci` forbidden-string check covers `app/igneum-app/ui/`; the comment reads "(ruling of 6 October 2026)" |
+| Q22 | A code comment naming the founder ships in the UI bundle (`// The list is ordered by performance (the project lead, 6 October 2026)`), and the ui bundle is outside every forbidden-string check | `app/igneum-app/ui/app.js:270`, `tools/ci/identity-check.sh` | cosmetic (identity rule) | 0.5 | app owner | `tools/ci` forbidden-string check covers `app/igneum-app/ui/`; the comment reads "(ruling of 6 October 2026)" |
 | Q23 | Two copy-law slips: "Votes lock the chain; leave it on." (aphorism), "The window can close. The miner keeps going" (two-beat) | `index.html:404, 81` | cosmetic | 0.5 | app owner | reworded; the grep below stays at 0 em dashes |
 
 **Error states, exact strings.** Engine down (four failed polls): pill "engine away" (`app.js:1437`); node line "Node: no answer", sub "the engine is not answering; the window reconnects by itself"; Mac host "The engine stopped. Quit and open Igneum Miner again." (`IgneumMiner.swift:233`); Windows "The engine stopped. Close this window and open Igneum Miner again." (`host.cpp:301`). Node down: "the node could not start" or the engine message, "the node is not running", "the external node went away" (`app.js:452-453`, `engine.rs:3163`); pill "node failed" (`app.js:1428`); digest box "the node is not running" (`app.js:1341`); canvas "waiting for the node to sync" (`app.js:1099`). Finality paused: nothing (Q2). Update server unreachable: "The update failed. Manifest signature: <curl error>." (`app.js:1360`, Q11). GPU lost: "Card removed: <name>. Its worker stopped." (`app.js:95`), row word "removed", sub "unplugged; its worker stopped. The row goes in five minutes." (`app.js:303`); Code 43: "<name>: not usable (Code 43). No worker runs on it." with "reboot with the card attached; if it persists, reinstall the driver with the card attached" (`app.js:100`, `detect.rs:55`).
@@ -123,10 +123,10 @@ The row for the ledger: **Q1 plus Q2, Q5, Q6, Q7, Q10**: every public and operat
 
 | Id | Row | File or screen | Severity | Hours | Owner | Gate |
 |---|---|---|---|---|---|---|
-| Q9 | Page vs UI 3; guide placeholders; empty explorer URL (section 1) | `site/wallet.html`, `site/metamask.html` | the founder-visible | 6 | app owner, site owner | section 1 |
+| Q9 | Page vs UI 3; guide placeholders; empty explorer URL (section 1) | `site/wallet.html`, `site/metamask.html` | the project lead-visible | 6 | app owner, site owner | section 1 |
 | Q30 | Private key export copies to the clipboard with no clear and no timer | `igneum-wt-wallet/.../ui/app.js:129, 463` | user-visible | 2 | app owner | clipboard cleared after 60 s by the host; unit test on the timer |
 | Q31 | Wallet OTA trusts one key; no `revoked_keys`, unlike the miner's updater | `docs/plans/consequences-2026-10-05.md:36`, `updater.rs:7, 729` | operator-visible | 3 | app owner | updater carries `OTA_PUBLIC_KEYS [K1, K2]` and honours `revoked_keys`; the three-key test of the rig installer |
-| Q32 | No hardware wallet path despite spec 8.5 "MUST offer" | `docs/spec/08-client-security.md:36` | the founder-visible | 24, or 0.5 to relabel | app owner (cryptographer reviews) | a Ledger signs one devnet transfer through the Ethereum app at chain id 4463; or the spec row reads "Designed, not shipped" |
+| Q32 | No hardware wallet path despite spec 8.5 "MUST offer" | `docs/spec/08-client-security.md:36` | the project lead-visible | 24, or 0.5 to relabel | app owner (cryptographer reviews) | a Ledger signs one devnet transfer through the Ethereum app at chain id 4463; or the spec row reads "Designed, not shipped" |
 | Q33 | Single account, no second address, no address book | `engine.rs:343`, `ui/index.html:177` | user-visible | 6 | app owner | two derived accounts, a saved recipient reused in Send |
 | Q34 | `confirm()` on Remove wallet never renders in the Mac host | `app.js:598`, `wallet-ui-3-audit.md:189` | user-visible | 1 | app owner | in-page two-step card; snapshot test |
 | Q35 | Finality pause: node card "paused" or "not checkpoint-checkable without a node", rows stay "in block N"; public-RPC mode never says what to do | wallet `app.js:185, 321, 340` | user-visible | 2 | app owner | the row reads "in block N; finality is paused on the network" and the public-RPC line names the fix with a button |
@@ -157,11 +157,11 @@ The row for the ledger: **Q1 plus Q2, Q5, Q6, Q7, Q10**: every public and operat
 
 | Id | Row | File or screen | Severity | Hours | Owner | Gate |
 |---|---|---|---|---|---|---|
-| Q6 | Stale shown as live; "active" for 20 unlocked indices; "paused" with no since or cause; event flood (section 1) | `relay/ui.html:564, 367-368` | the founder-visible | 4 | fleet agent, consensus-engineer | section 1 |
+| Q6 | Stale shown as live; "active" for 20 unlocked indices; "paused" with no since or cause; event flood (section 1) | `relay/ui.html:564, 367-368` | the project lead-visible | 4 | fleet agent, consensus-engineer | section 1 |
 | Q8 | X23 to X28 fixes off master; intake key can write and delete; token in URL (section 1) | `relay/api/console.mjs:249`, `relay/lib/relay.mjs:44` | operator-visible | 2 | fleet agent | section 1 |
-| Q40 | A hung job reads "running" forever: no elapsed time, no timeout, no "last line N min ago" | `relay/api/console.mjs:182-187`, `relay/ui.html:317` | the founder-visible | 2 | fleet agent | a killed job reads "no report for 12 min" in red within one refresh |
+| Q40 | A hung job reads "running" forever: no elapsed time, no timeout, no "last line N min ago" | `relay/api/console.mjs:182-187`, `relay/ui.html:317` | the project lead-visible | 2 | fleet agent | a killed job reads "no report for 12 min" in red within one refresh |
 | Q41 | Jobs tab trusts the unsigned `igneum-jobs.json` while the apps verify the signed file | `relay/api/console.mjs:170` vs `tools/jobs.mjs:57-60` | operator-visible | 1.5 | fleet agent | the tab shows the envelope's signature state per file |
-| Q42 | Job result modal: no error lines first, no duration, no anchors (the Actions view) | `relay/ui.html:319`, `console.mjs:184-187` | the founder-visible | 3 | fleet agent | a failed run opens with its five error lines and its duration first |
+| Q42 | Job result modal: no error lines first, no duration, no anchors (the Actions view) | `relay/ui.html:319`, `console.mjs:184-187` | the project lead-visible | 3 | fleet agent | a failed run opens with its five error lines and its duration first |
 | Q43 | Machines: no per-machine key state, no revoke, roles never enforced (the Tailscale view) | `relay/lib/relay.mjs:14`, `relay/api/relay.mjs:191-195` | operator-visible | 3 (after Q8) | fleet agent | a revoked PC's register is 403 and its card says "key revoked" |
 | Q44 | Builds: no rollback, no manifest history (the Vercel view) | `relay/ui.html:328-341` | operator-visible | 4 | fleet agent | one tap republishes the previous manifest and the fleet's OTA state shows it |
 | Q45 | "live feed unreachable: live feed unreachable" doubled; the whole Chain tab empties, losing Events and the infra card | `relay/api/console.mjs:210`, `relay/ui.html:357` | cosmetic | 0.5 | fleet agent | live feed down: tiles grey, Events and infra card still render |
@@ -200,7 +200,7 @@ The row for the ledger: **Q1 plus Q2, Q5, Q6, Q7, Q10**: every public and operat
 
 | Id | Row | File or screen | Severity | Hours | Owner | Gate |
 |---|---|---|---|---|---|---|
-| Q5 | "final" during a pause; 90-word hero; 24 GB contradiction; thumbnail OG (section 1) | `index.html:345, 494, 810, 838, 15-19` | the founder-visible | 3 | site owner | section 1 |
+| Q5 | "final" during a pause; 90-word hero; 24 GB contradiction; thumbnail OG (section 1) | `index.html:345, 494, 810, 838, 15-19` | the project lead-visible | 3 | site owner | section 1 |
 | Q50 | No downloads page: hashes only for HiveOS, no signing key, no verify line, the Linux button goes to an anchor | `index.html:363-365, 516`, `miner.html:549-558` | user-visible | 2 | site owner | `/download` lists every artefact with version, size, sha256, the OTA key fingerprint and a verify command per OS; the Linux button links the file |
 | Q51 | `/miners` has 6 rows, two card models, "not measured" MH/W on every row; the eleven-card fleet table is not ingested | `miners.html:183`, `miner-bench.json` | user-visible | 2 | miner-community-lead | rows carry W and MH/W for every measured card |
 | Q52 | `dl\.igneum` in `forbidden-strings.txt` matches the public download host on three built pages; the scrub guards only bench and miners | `forbidden-strings.txt:25`, `build.mjs:171, 401` | operator-visible | 0.5 | site owner | the pattern becomes `dl\.igneum\.network/dl/(?!public/)` or `/dl/[0-9a-f]{12,}`, and the check runs on every built page |
@@ -210,10 +210,10 @@ The row for the ledger: **Q1 plus Q2, Q5, Q6, Q7, Q10**: every public and operat
 | Q56 | Light-section contrast fails (3.08:1 links, 3.97:1 eyebrow) | `index.html:119-120, 130` | cosmetic | 0.5 | site owner | AA on every token pair; the same node script as Q12 |
 | Q57 | "devnet v0" eyebrow on the live page; the chain is v4 | `live.html:219` | cosmetic | 0.1 | site owner | matches the app's network word |
 | Q58 | Heading order (h3 before the first h2) | `index.html:359` | cosmetic | 0.2 | site owner | h2 or a styled div |
-| Q59 | No team, custody or key-powers page (Reddit round 4 artefact 8); "0 admin keys in consensus" tile unchanged | `index.html:611`; no file | user-visible | 1 (plus the founder's policy call) | site owner | the key-powers table published; the tile links it |
-| Q60 | Roadmap dates versus the testnet: the journey says "Public testnet, Aug to Oct 2027" and the litepaper "Pools and the public testnet are August 2027", while `docs/plans/testnet-go.md` has `igneum-testnet-1` seeds up and a go checklist dated 5 October 2026 | `index.html:679`, `litepaper.html:719`, `docs/plans/testnet-go.md:1-4` | the founder-visible | 0.5 (after the founder decides which is true) | site owner | one date for the public testnet on the journey, the litepaper and the download notice |
+| Q59 | No team, custody or key-powers page (Reddit round 4 artefact 8); "0 admin keys in consensus" tile unchanged | `index.html:611`; no file | user-visible | 1 (plus the project lead's policy call) | site owner | the key-powers table published; the tile links it |
+| Q60 | Roadmap dates versus the testnet: the journey says "Public testnet, Aug to Oct 2027" and the litepaper "Pools and the public testnet are August 2027", while `docs/plans/testnet-go.md` has `igneum-testnet-1` seeds up and a go checklist dated 5 October 2026 | `index.html:679`, `litepaper.html:719`, `docs/plans/testnet-go.md:1-4` | the project lead-visible | 0.5 (after the project lead decides which is true) | site owner | one date for the public testnet on the journey, the litepaper and the download notice |
 | Q61 | No Content-Security-Policy header on the site (the relay has none either); inline scripts throughout, two pinned CDN modules on the homepage | `site/vercel.json:7`, `relay/vercel.json:31-43`, `verify/verify.js:5-6` | operator-visible (security) | 2 | site owner | a CSP with hashes or nonces for the inline scripts and `script-src` limited to self and cdn.jsdelivr; every page renders with no console violation |
-| Q62 | Copy-law borderline headlines: "Mined by GPUs. Proven by fire." (the brand line, the founder's call), "GPUs are back · for good", "Last hour's chip is already obsolete.", "Your coins. Final means final.", "Dates slip. Gates do not.", "Install. Start. The card mines and proves.", "Nothing is mined here." | `index.html:343, 344, 424`, `wallet.html` h1, `litepaper.html:678`, `miner.html` h1, `404.html` h1 | cosmetic | 1 | site owner (the founder rules on the brand line) | each either kept by the founder's word or reworded |
+| Q62 | Copy-law borderline headlines: "Mined by GPUs. Proven by fire." (the brand line, the project lead's call), "GPUs are back · for good", "Last hour's chip is already obsolete.", "Your coins. Final means final.", "Dates slip. Gates do not.", "Install. Start. The card mines and proves.", "Nothing is mined here." | `index.html:343, 344, 424`, `wallet.html` h1, `litepaper.html:678`, `miner.html` h1, `404.html` h1 | cosmetic | 1 | site owner (the project lead rules on the brand line) | each either kept by the project lead's word or reworded |
 
 **Reddit round 4, still open in the HTML.** Finding 6 (24 GB): half fixed (Q5). Finding 7 (eleven-card table): open (Q51). Finding 8 (admin keys): sentence added to the litepaper (`:659`), tile unchanged, no table (Q59). Finding 15 ("Monero's idea, finished for GPUs"): open (`index.html:444`, `litepaper.html:429`). Finding 16 ("devnet v0"): open (Q57). Finding 22: `/ledger` present, no nav item. Findings 2, 3, 5, 9, 10, 12, 13, 17, 19: fixed in the current files. "0% anyone else in the protocol" legend still live (`index.html:604`).
 
@@ -266,8 +266,8 @@ The row for the ledger: **Q1 plus Q2, Q5, Q6, Q7, Q10**: every public and operat
 | Id | Row | File or screen | Severity | Hours | Owner | Gate |
 |---|---|---|---|---|---|---|
 | Q67 | Member transport is plaintext TCP against spec 9.3's TLS 1.3 with session binding; `binding` ignored | `server.rs:1-2, 115`, `protocol.rs:58-60` | user-visible (hijack risk) | 8 | consensus-engineer | rustls listener; a replayed `authorize` on a second connection is refused (O-9.7) |
-| Q68 | Node down shows "difficulty 0, DAA 0" and a ramp-day-0 reward; no "node unreachable" state | `node.rs:350-368`, `web/index.html:163-164` | the founder-visible (once deployed) | 2 | miner-community-lead | the page renders "Node unreachable since <time>" against a stopped node |
-| Q69 | Raw integers (DAA, block count, shares) with no separators; difficulty uses `toLocaleString()` with no locale, so it varies by browser; hash rate 2 decimals against the site's 1 | `web/index.html:152, 163, 172, 190` | the founder-visible | 1 | miner-community-lead | every number formatted as section 4.3 says |
+| Q68 | Node down shows "difficulty 0, DAA 0" and a ramp-day-0 reward; no "node unreachable" state | `node.rs:350-368`, `web/index.html:163-164` | the project lead-visible (once deployed) | 2 | miner-community-lead | the page renders "Node unreachable since <time>" against a stopped node |
+| Q69 | Raw integers (DAA, block count, shares) with no separators; difficulty uses `toLocaleString()` with no locale, so it varies by browser; hash rate 2 decimals against the site's 1 | `web/index.html:152, 163, 172, 190` | the project lead-visible | 1 | miner-community-lead | every number formatted as section 4.3 says |
 | Q70 | Ledger is a JSON file rewritten every 15 s; hash-rate samples and check cost not persisted, so a restart zeroes every rate tile and the 24-hour luck | `state.rs:704-710`, `main.rs:131-144` | user-visible | 4 | miner-community-lead | restart test: tiles recover within one sample window; README names the loss window |
 | Q71 | Address lookup never shows the payment history the API returns | `api.rs:148`, `web/index.html:181-194` | user-visible | 1 | miner-community-lead | payments table under the lookup |
 | Q72 | No per-miner history, no charts, no worker-offline notice, no `/metrics`; `/health` always ok | `state.rs:779-781`, `web/index.html:187`, `main.rs:152-174`, `api.rs:195` | user-visible, operator-visible | 4 + 4 + 2 + 1 | miner-community-lead | hourly buckets per address kept 7 days with a sparkline; opt-in webhook after 10 min silence; Prometheus text endpoint; health reflects `net.synced` and template age |
@@ -292,7 +292,7 @@ The row for the ledger: **Q1 plus Q2, Q5, Q6, Q7, Q10**: every public and operat
 
 | Id | Row | File or screen | Severity | Hours | Owner | Gate |
 |---|---|---|---|---|---|---|
-| Q7 | Bot not live; pre-existing never opens; pulse hides the pause (section 1) | `discord-hooks.mjs:481-485, 252-255, 158` | the founder-visible | 3 | miner-community-lead | section 1 |
+| Q7 | Bot not live; pre-existing never opens; pulse hides the pause (section 1) | `discord-hooks.mjs:481-485, 252-255, 158` | the project lead-visible | 3 | miner-community-lead | section 1 |
 | Q74 | No block-production stall condition, the actual first signal of tonight's 18:30Z gap | `:437-472`, `fixtures/discord/live.json` | user-visible | 2 | miner-community-lead | `blocks_stalled` condition, 3 minutes, fixture test |
 | Q75 | Resolve posts a new message instead of editing the open one | `:706-712` | cosmetic | 2 | miner-community-lead | PATCH `/messages/<id>` with the resolve fields |
 | Q76 | Embeds link only `/live` and `/miner`; the last lock could link `/block/<hash>` | `:271, 297, 350` | cosmetic | 1 | miner-community-lead | last lock links its block page |
@@ -318,9 +318,9 @@ The row for the ledger: **Q1 plus Q2, Q5, Q6, Q7, Q10**: every public and operat
 
 | Id | Row | File or screen | Severity | Hours | Owner | Gate |
 |---|---|---|---|---|---|---|
-| Q86 | The fleet page is blind to the standing fleet, to death and to finality. `page.py:43-47` publishes `standing` and `devnet2`, and the page's `index.html` references neither (grep 0; it reads boxes, results, phases, night, log, `:243`); a dead box reads "running" for up to 20 minutes because state comes from `boxes.json` (`page.py:38`) and `standing.jsonl` is never read; no fleet or console script reads `finality_active` (only `bps-collect.py:30` tails "Finality:" log lines), so tonight's pause was found by hand (`CLAUDE.md`, the standing-fleet rule) | `page.py:38-47`, dlsite `index.html:243`, `lib/standing.py`, `tools/console.mjs:124` | the founder-visible | 6 (standing block, USD per day, Devnet 2 height and last gate line 2; "unreachable since HH:MM" from `standing.jsonl` within 2 minutes 2; `getFinalityCheckpoints` in the standing check and "finality paused since, reason" on the page and the console 2) | fleet agent | the page shows the standing count and spend; a box killed by hand reads "unreachable since" within 2 minutes; a forced Devnet 2 pause reads on the page and in `console.mjs chain` |
-| Q87 | `rerent` does not set up or supervise the new box: the docstring promises both (`lib/standing.py:14-16`), the code rents and patches rows (`:78-91`); a re-rented card bills idle | `lib/standing.py:78-91` | the founder-visible (spend) | 2 | fleet agent | the new label shows synced and mining on the page within the install time |
-| Q88 | One-shot boxes have no autostop; `cap_vast 1000` and `cap_runpod 500` enforce nothing (`page.py:45`; `vast.py:61-72` has no cap check) | `page.py:45`, `vast.py:61-72`, `autorun.py` | the founder-visible (spend) | 1.5 | fleet agent | `autorun` destroys a one-shot box N minutes after its done line; `rent` refuses above the cap |
+| Q86 | The fleet page is blind to the standing fleet, to death and to finality. `page.py:43-47` publishes `standing` and `devnet2`, and the page's `index.html` references neither (grep 0; it reads boxes, results, phases, night, log, `:243`); a dead box reads "running" for up to 20 minutes because state comes from `boxes.json` (`page.py:38`) and `standing.jsonl` is never read; no fleet or console script reads `finality_active` (only `bps-collect.py:30` tails "Finality:" log lines), so tonight's pause was found by hand (`CLAUDE.md`, the standing-fleet rule) | `page.py:38-47`, dlsite `index.html:243`, `lib/standing.py`, `tools/console.mjs:124` | the project lead-visible | 6 (standing block, USD per day, Devnet 2 height and last gate line 2; "unreachable since HH:MM" from `standing.jsonl` within 2 minutes 2; `getFinalityCheckpoints` in the standing check and "finality paused since, reason" on the page and the console 2) | fleet agent | the page shows the standing count and spend; a box killed by hand reads "unreachable since" within 2 minutes; a forced Devnet 2 pause reads on the page and in `console.mjs chain` |
+| Q87 | `rerent` does not set up or supervise the new box: the docstring promises both (`lib/standing.py:14-16`), the code rents and patches rows (`:78-91`); a re-rented card bills idle | `lib/standing.py:78-91` | the project lead-visible (spend) | 2 | fleet agent | the new label shows synced and mining on the page within the install time |
+| Q88 | One-shot boxes have no autostop; `cap_vast 1000` and `cap_runpod 500` enforce nothing (`page.py:45`; `vast.py:61-72` has no cap check) | `page.py:45`, `vast.py:61-72`, `autorun.py` | the project lead-visible (spend) | 1.5 | fleet agent | `autorun` destroys a one-shot box N minutes after its done line; `rent` refuses above the cap |
 | Q89 | Supervisor restart loop without backoff or a failure line | `box-standing.sh:46-49` | operator-visible | 1.5 | fleet agent | after N failures a `standing_node_failed` line and a page flag |
 | Q90 | Dropped miner and GPU facts: `standing.py:56` strips `miner=`; `gpu=` never parsed | `lib/standing.py:56`, `box-standing.sh:64` | operator-visible | 1 | fleet agent | MH/s, accepted and rejected, watts per box on the page (the HiveOS card) |
 | Q91 | A transient ssh drop counts as death: `Box.run` returns 124 on timeout (`lib/box.py:49`), `check_one` marks dead on any rc (`standing.py:54`), the loop never asks the provider (`fleet.py:48-60` `refresh_ssh` unused); Vast proxy drops are known (`canary.sh:41`) | `lib/box.py:49`, `lib/standing.py:54` | operator-visible | 1 | fleet agent | provider status consulted before a dead check counts |
@@ -355,7 +355,7 @@ The row for the ledger: **Q1 plus Q2, Q5, Q6, Q7, Q10**: every public and operat
 | Id | Row | File or screen | Severity | Hours | Owner | Gate |
 |---|---|---|---|---|---|---|
 | Q96 | No log line on a finality flip: an operator tailing the log never sees the pause begin or end | `consensus/src/processes/finality.rs` (no pause line) | operator-visible | 1.5 | consensus-engineer | fast-time simnet prints `Finality: paused (<reason>)` and `Finality: resumed at index N`, one line per flip |
-| Q97 | `finality_reason` says `paused` and nothing else: no share that left, no frozen-table hold, no expiry, no conflict reason (O-3.17) (the node half of Q1) | `finality.rs:1794-1807` | the founder-visible (through every surface) | 1.5 (counted in Q1) | consensus-engineer | tonight's pause reads "paused: 42.7 percent of weight left the window; held by the table frozen at lock 6842 until DAA 216,402" |
+| Q97 | `finality_reason` says `paused` and nothing else: no share that left, no frozen-table hold, no expiry, no conflict reason (O-3.17) (the node half of Q1) | `finality.rs:1794-1807` | the project lead-visible (through every surface) | 1.5 (counted in Q1) | consensus-engineer | tonight's pause reads "paused: 42.7 percent of weight left the window; held by the table frozen at lock 6842 until DAA 216,402" |
 | Q98 | No `/metrics`: finality_active, latest lock, exec tip, blocked, paid segments, peers, DAA as Prometheus gauges (the axum listener exists) | `igneum/exec/src/rpc.rs` | operator-visible | 3 | execution-engineer | `curl :26790/metrics` scraped by a Grafana dashboard committed under `infra/` |
 | Q99 | Log level is start-only; no runtime change (monerod `set_log`, reth env filter) | `kaspad/src/args.rs:262-271` | operator-visible | 2 | consensus-engineer | an RPC or SIGHUP changes the level without a restart |
 | Q100 | Clock-skew field in `getBlockDagInfo` and the local-ahead mirror case still owed after X19 | `docs/plans/node-changes.md:18-19` | operator-visible | 2 (after the `ledger-fixes-0311` merge) | consensus-engineer | `faketime -60s` gives one WARN and the field |
@@ -395,8 +395,8 @@ So the trust today is one key, one builder (the box and the Mac, both the projec
 
 | Id | Row | File or screen | Severity | Hours | Owner | Gate |
 |---|---|---|---|---|---|---|
-| Q3 | Signing and notarisation; first-run prompts (section 1) | `build-dmg.sh:118-122`, `windows.yml` | the founder-visible | 6 plus certificates | app owner, the founder | section 1 |
-| Q80 | The Windows installer pipeline is dead: every GitHub-hosted job fails at start on billing; the installer and payload zip have no other builder, so 0.3.15 and every hotfix are Mac and HiveOS only until the founder fixes Billing & plans, or the installer step moves to igneum-build-1 (Inno Setup under Wine, or a self-hosted Windows runner on PC 1) | `release-0.3.15.md` 6a, `.github/workflows/windows.yml`, `packaging/windows/build-installer.ps1` | the founder-visible | 0 (the founder: billing) or 4 (installer step on the box or PC 1 as a signed job) | app owner; the founder | a green `windows.yml` run, or `tools/ship-app.mjs --dry-run` showing the fetch step satisfied from the new builder |
+| Q3 | Signing and notarisation; first-run prompts (section 1) | `build-dmg.sh:118-122`, `windows.yml` | the project lead-visible | 6 plus certificates | app owner, the project lead | section 1 |
+| Q80 | The Windows installer pipeline is dead: every GitHub-hosted job fails at start on billing; the installer and payload zip have no other builder, so 0.3.15 and every hotfix are Mac and HiveOS only until the project lead fixes Billing & plans, or the installer step moves to igneum-build-1 (Inno Setup under Wine, or a self-hosted Windows runner on PC 1) | `release-0.3.15.md` 6a, `.github/workflows/windows.yml`, `packaging/windows/build-installer.ps1` | the project lead-visible | 0 (the project lead: billing) or 4 (installer step on the box or PC 1 as a signed job) | app owner; the project lead | a green `windows.yml` run, or `tools/ship-app.mjs --dry-run` showing the fetch step satisfied from the new builder |
 | Q81 | The ship tool pushes master whatever `--branch` says (the 19:30Z push of the release tree to master) | `tools/ship-app.mjs` commit step | operator-visible | 1 | app owner | `--branch X` pushes X; a test on a scratch repo |
 | Q82 | The download page shows no hash for Windows and Mac, no OTA key fingerprint, no verify command; the stable aliases are not explained (Q50 covers the page; this row is the artefact side) | `miner.html:549-558`, `packaging/ota/publish-public.sh` | user-visible | 1 | site owner | `igneum-downloads.json` carries the fingerprint; the page prints it with `shasum -a 256` and `certutil -hashfile` lines |
 | Q83 | The update key is one software key on one Mac, not in hardware, against G7's "held in hardware and its policy published" | `packaging/ota/README.md` "Keys", `docs/fud-ledger.md` G7 | operator-visible (security) | 3 (a YubiKey or Secure Enclave signer behind `igneum-ota-sign`, the policy page) | cryptographer, app owner | a release signed with the hardware key installs; the key policy is a public page; the software seed is retired |
@@ -429,7 +429,7 @@ Forbidden strings (`site/forbidden-strings.txt`, 25 patterns) per shipped file,
 | `site/wallet.html` | `dl\.igneum` | 1 | the wallet alias (`:371`) |
 | `site/downloads.json` | `dl\.igneum` | 1 | the `base` field |
 | `relay/ui.html` | `Hetzner` | 1 | the "Hetzner network" card title (`:377`); private console, rule does not apply, but one word |
-| `app/igneum-app/ui/app.js` | `the founder` | 1 | a code comment (`:270`); the ui bundle is outside every check (Q22) |
+| `app/igneum-app/ui/app.js` | `the project lead` | 1 | a code comment (`:270`); the ui bundle is outside every check (Q22) |
 | `tools/community/discord-hooks.mjs` | `MacBook`, `\+0100`, `tailscale`, `ts\.net`, `dl\.igneum` | 1, 1, 1, 1, 2 | the guard's own regexes (`:51, 59, 61`), the read-only fleet URL (`:31`), and `ts\.net` matching "stats.net" in a template (`:255`): false positives, none posted |
 | `pool/README.md` | `Hetzner`, `/opt/igneum`, `CLAUDE\.md` | 5, 2, 1 | the deploy section; not a site page, but it would fail the scrub if copied |
 
@@ -448,7 +448,7 @@ Every other pattern is 0 on every file. Two-beat antithesis and aphorisms in shi
 | Price | none anywhere; "pounds a day" once (`index.html:510`); Ember has a `priceNow()` with a devnet zero | | | | | | |
 | Finality | "#N" or "paused" (`index.html:879`) | "#N, 3 min ago" plus the bar (`live.html:404, 512`) | none | "#N · 1 h ago" (`app.js:1350`) | "active" or "paused" | "checkpoint 6,842 at 55.x% of weight, 1 h ago, 93 voters" | none |
 
-Row **Q85** (cross-cutting, 2 hours, site owner with the app owner): one shared formatter module (`site/lib/format.mjs`) for hash rate (1 decimal, unit ladder kH to PH), counts (`en-GB` separators, never `compact()` for the same quantity shown in full elsewhere), blocks per second (2 decimals, never inverted), difficulty (one spelling), IGN (4 decimals on tiles, 6 in tables), and one word for a vote identity ("vote key" on every surface); the app, hub, Discord and pool copy the same table as a Rust and a JS constant, with a test that renders the fixture values identically. Gate: the fixture renders byte-identical on all seven surfaces. Severity: the founder-visible (he reads three of these side by side every evening).
+Row **Q85** (cross-cutting, 2 hours, site owner with the app owner): one shared formatter module (`site/lib/format.mjs`) for hash rate (1 decimal, unit ladder kH to PH), counts (`en-GB` separators, never `compact()` for the same quantity shown in full elsewhere), blocks per second (2 decimals, never inverted), difficulty (one spelling), IGN (4 decimals on tiles, 6 in tables), and one word for a vote identity ("vote key" on every surface); the app, hub, Discord and pool copy the same table as a Rust and a JS constant, with a test that renders the fixture values identically. Gate: the fixture renders byte-identical on all seven surfaces. Severity: the project lead-visible (he reads three of these side by side every evening).
 
 ### 4.4 Error states, one table
 
@@ -484,7 +484,7 @@ Section 3.10 carries both in full. The two facts to carry forward: a fresh machi
 - Lighthouse numbers are estimates from source; no browser run was allowed. The gate for every site row is a real run.
 - The comparator claims are from memory; where a repository or page is named it is cited, otherwise approximate. The Stratum v2 reference was not cloned.
 - The fleet and node sections depend on the gpu-fleet worktree and the vendor forks, read tonight; the fleet's own page was not opened.
-- Hours are agent hours (the founder's rule); Q3 and Q80 also need the founder (certificates, GitHub billing).
+- Hours are agent hours (the project lead's rule); Q3 and Q80 also need the project lead (certificates, GitHub billing).
 
 ## 7. Summary for the coordinator
 

docs/analysis/income-tiers.md

@@ -1,94 +0,0 @@
-# Mining income per tier on igneum-testnet-1
-
-Generated by `tools/launch/income-tiers.mjs` from `tools/launch/income-tiers.json` (mission item 10, the consequences rule). Do not edit by hand: `node tools/launch/income-tiers.mjs` rewrites it and `--check` fails CI when the two disagree. Every rate and watt figure is a measurement with its source in the first table; nothing is estimated. Testnet coins have no value and the figures below say nothing about any price: the dollar columns are electricity, a cost the reader computes from a measured watt figure and a tariff they choose.
-
-## The schedule the figures use
-
-`EmissionSchedule::TESTNET_1` (the testnet genesis, decided 7 October 2026): 100 IGN a block at one block a second, a 90-day ramp from 10 percent, a monthly glide with a two-year half-life (each month pays 2^(-1/24) of the month before), then 1 percent of supply a year from about year 11.4. Of each block, 80 percent goes to the miner who found it and 20 percent to the proving pool. A miner whose key signs its checkpoints keeps the full 80 percent; an unsigned key gives a tenth of it to the proving pool.
-
-| Moment | IGN a block to the miner | Of the launch figure |
-|---|---|---|
-| day 1 | 8.00 | 10.0% |
-| day 30 | 32.00 | 40.0% |
-| day 90 (ramp over) | 75.51 | 94.4% |
-| month 12 | 58.23 | 72.8% |
-| year 2 | 41.17 | 51.5% |
-
-A solo card's expected income is its share of network hash times 86,400 blocks a day times the figure above. The tables use day 90, when the ramp is over. Before that, multiply by the ramp row; after that, by the glide row. A pool user gets the same expected amount minus the pool's fee (pool-0: 1 percent) with the variance taken out; the reference pool holds no balance and pays from the coinbase split.
-
-## The cards, measured
-
-6 October 2026, rented single-card Linux boxes (docs/analysis/prover-tiers-real-cards.md, bench log 'Prover tiers on real cards: the rented fleet, 6 October 2026'): the 0.3.12 miner on the ten-field override, the miner alone on the card, nvidia-smi power at the same second. The RX 9070 XT row is the telemetry run of 5 October 2026 on a Windows rig (bench log 'Power, heat, fans and clocks, measured'); the Apple row is the Metal bench of 4 October 2026 (site/miner-bench.json, class v4). The class v4 rates on the live devnet run lower than the ten-field rates on the same card (RTX 5090: 124.2 MH/s class v4 against 98.5 on the rented box under a different driver and container, docs/bench-log.md); the table is re-generated at the testnet cut from that class.
-
-| Tier | Card | MH/s | W | MH/W | Source |
-|---|---|---|---|---|---|
-| 8 GB | NVIDIA RTX 4060 Ti 8 GB | 19.07 | 72.6 | 0.263 | docs/analysis/prover-tiers-real-cards.md, RTX 4060 Ti 8 GB row |
-| 8 GB | NVIDIA RTX 4060 | 17.07 | owed | owed | docs/analysis/prover-tiers-real-cards.md, RTX 4060 row (the sampler read 0.0 W on that host: power OWED) |
-| 12 GB | NVIDIA RTX 3060 | 23.78 | 103.7 | 0.229 | docs/analysis/prover-tiers-real-cards.md, RTX 3060 row |
-| 12 GB | NVIDIA RTX 4070 | 24.99 | 91.1 | 0.274 | docs/analysis/prover-tiers-real-cards.md, RTX 4070 row |
-| 12 GB | NVIDIA RTX 5070 | 41.89 | 137.0 | 0.306 | docs/analysis/prover-tiers-real-cards.md, RTX 5070 row |
-| 16 GB | NVIDIA RTX 4060 Ti 16 GB | 17.58 | 72.3 | 0.243 | docs/analysis/prover-tiers-real-cards.md, RTX 4060 Ti 16 GB row |
-| 16 GB | AMD RX 9070 XT | 18.60 | 199.0 | 0.093 | docs/bench-log.md, 'Power, heat, fans and clocks, measured' (5 October 2026): 18.6 to 19.2 MH/s, 199 W read by the ADLX helper at 100 percent busy |
-| 24 GB | NVIDIA RTX 3090 | 37.79 | 228.8 | 0.165 | docs/analysis/prover-tiers-real-cards.md, RTX 3090 row |
-| 24 GB | NVIDIA RTX 4090 | 52.25 | 183.1 | 0.285 | docs/analysis/prover-tiers-real-cards.md, RTX 4090 row |
-| 32 GB | NVIDIA RTX 5090 | 98.48 | 258.2 | 0.381 | docs/analysis/prover-tiers-real-cards.md, RTX 5090 row (the rented box; 124.2 MH/s class v4 on a desktop, site/miner-bench.json) |
-| Apple | Apple M5 Max (40 GPU cores) | 26.70 | owed | owed | site/miner-bench.json, Apple M5 Max class v4 row, 4 October 2026 (no power reading: OWED) |
-
-## IGN a day per card, solo, after the ramp (day 90)
-
-Three network sizes, because income is a share of the network and nobody knows the network before it exists. 1 GH/s, 10 GH/s, 100 GH/s are reference sizes, not forecasts. The live network's estimate is on /live; divide by it.
-
-| Tier | Card | at 1 GH/s | at 10 GH/s | at 100 GH/s |
-|---|---|---|---|---|
-| 8 GB | NVIDIA RTX 4060 Ti 8 GB | 124,414 | 12,441 | 1,244.1 |
-| 8 GB | NVIDIA RTX 4060 | 111,366 | 11,137 | 1,113.7 |
-| 12 GB | NVIDIA RTX 3060 | 155,142 | 15,514 | 1,551.4 |
-| 12 GB | NVIDIA RTX 4070 | 163,036 | 16,304 | 1,630.4 |
-| 12 GB | NVIDIA RTX 5070 | 273,293 | 27,329 | 2,732.9 |
-| 16 GB | NVIDIA RTX 4060 Ti 16 GB | 114,693 | 11,469 | 1,146.9 |
-| 16 GB | AMD RX 9070 XT | 121,348 | 12,135 | 1,213.5 |
-| 24 GB | NVIDIA RTX 3090 | 246,544 | 24,654 | 2,465.4 |
-| 24 GB | NVIDIA RTX 4090 | 340,882 | 34,088 | 3,408.8 |
-| 32 GB | NVIDIA RTX 5090 | 642,489 | 64,249 | 6,424.9 |
-| Apple | Apple M5 Max (40 GPU cores) | 174,192 | 17,419 | 1,741.9 |
-| Rig | 6 x NVIDIA RTX 4070 | 978,217 | 97,822 | 9,782.2 |
-
-## Electricity a day, and the electricity cost of one mined IGN
-
-Electricity a day = measured watts x 24 h x the tariff. The cost of one IGN divides that by the day-90 figure at 10 GH/s; at another network size it scales with the network (ten times the network, ten times the cost per coin). The three tariffs: USD 0.05 a kWh is cheap industrial power, USD 0.10 is a US retail rate, USD 0.25 is a UK retail rate at today's level (each approximate; tariffs move, the watt figures do not).
-
-| Tier | Card | USD/day at 0.05/kWh | USD/day at 0.1/kWh | USD/day at 0.25/kWh | USD per IGN at 0.05/kWh | USD per IGN at 0.1/kWh | USD per IGN at 0.25/kWh |
-|---|---|---|---|---|---|---|---|
-| 8 GB | NVIDIA RTX 4060 Ti 8 GB | 0.087 | 0.174 | 0.436 | 0.000007 | 0.000014 | 0.000035 |
-| 8 GB | NVIDIA RTX 4060 | owed | owed | owed | owed | owed | owed |
-| 12 GB | NVIDIA RTX 3060 | 0.124 | 0.249 | 0.622 | 0.00000802 | 0.000016 | 0.0000401 |
-| 12 GB | NVIDIA RTX 4070 | 0.109 | 0.219 | 0.547 | 0.00000671 | 0.0000134 | 0.0000335 |
-| 12 GB | NVIDIA RTX 5070 | 0.164 | 0.329 | 0.822 | 0.00000602 | 0.000012 | 0.0000301 |
-| 16 GB | NVIDIA RTX 4060 Ti 16 GB | 0.087 | 0.174 | 0.434 | 0.00000756 | 0.0000151 | 0.0000378 |
-| 16 GB | AMD RX 9070 XT | 0.239 | 0.478 | 1.19 | 0.0000197 | 0.0000394 | 0.0000984 |
-| 24 GB | NVIDIA RTX 3090 | 0.275 | 0.549 | 1.37 | 0.0000111 | 0.0000223 | 0.0000557 |
-| 24 GB | NVIDIA RTX 4090 | 0.220 | 0.439 | 1.10 | 0.00000645 | 0.0000129 | 0.0000322 |
-| 32 GB | NVIDIA RTX 5090 | 0.310 | 0.620 | 1.55 | 0.00000482 | 0.00000964 | 0.0000241 |
-| Apple | Apple M5 Max (40 GPU cores) | owed | owed | owed | owed | owed | owed |
-| Rig | 6 x NVIDIA RTX 4070 (a six-card rig of the 12 GB card, the rig's own power is six times the card's plus the host (the host is not measured here)) | 0.656 | 1.31 | 3.28 | 0.00000671 | 0.0000134 | 0.0000335 |
-
-## What it means per tier, and what is being done
-
-- **One 8 GB card.** NVIDIA RTX 4060 Ti 8 GB: 19.1 MH/s at 73 W, 12,441 IGN a day at 10 GH/s after the ramp, electricity 0.174 a day at USD 0.10 a kWh. Mines; proves only core-only shards (docs/analysis/prover-tiers-real-cards.md). The record says this tier is first under power in every exit (docs/analysis/mission/past.md section 3): the glide never halves it overnight, and the card games when the income goes. Being done: the Cards screen shows the expected MH/s, W and blocks a day before the first share (mission item 6).
-- **One 12 GB card.** NVIDIA RTX 5070: 41.9 MH/s at 137 W, 27,329 IGN a day at 10 GH/s after the ramp, electricity 0.329 a day at USD 0.10 a kWh. Mines and proves beside the miner on the patched server. Being done: the same Cards line; the proving tier sentence names the shard size the card takes.
-- **One 16 GB card.** NVIDIA RTX 4060 Ti 16 GB: 17.6 MH/s at 72 W, 11,469 IGN a day at 10 GH/s after the ramp, electricity 0.174 a day at USD 0.10 a kWh. Mines and proves; the AMD row is the measured 9070 XT, 199 W for 18.6 MH/s, so per watt it is about a fifth of the NVIDIA cards of its tier and the electricity cost per coin is the highest in the table. Being done: the AMD read-width experiment (docs/plans/read-width.md); until it lands the AMD tier is told its per-watt figure before it buys.
-- **One 24 or 32 GB card.** NVIDIA RTX 5090: 98.5 MH/s at 258 W, 64,249 IGN a day at 10 GH/s after the ramp, electricity 0.620 a day at USD 0.10 a kWh. The last GPU standing in every exit on record, and the only tier that proves the full shard beside the miner. Being done: the proving pool is the second income for this tier and the Earnings screen shows shards and IGN beside blocks.
-- **A rig.** 6 x NVIDIA RTX 4070: cards times the card figure; the host's own draw is not measured and is owed. Rigs followed income across chains inside days on every chain in the record; Igneum expects no loyalty and pays staying keys a vote (30 days of blocks).
-- **A pool user.** The same expected IGN minus the pool's fee, variance removed; pool-0 holds no balance and the member's own key is in every block it finds, so a pool's vote is the member's weight. Being done: the pool finished (mission item 11).
-- **Windows, Linux, macOS.** The rates above are Linux containers (NVIDIA) and Windows (AMD); the Mac row is Metal on Apple silicon with no power reading. The same card on another operating system is within the driver's margin, not measured here: owed per platform at the testnet cut.
-
-## Owed
-
-- Intel discrete (Arc): no measurement; the tier is listed with no number until one exists
-- RTX 4060 and Apple M5 Max wall power: the rows carry the rate and no electricity column
-- every row at class v4 on the testnet cut: the rates above are the ten-field class of 6 October 2026 on rented boxes
-- a rig host's own draw: a rig row is cards times the card figure, host excluded
-
-## Check
-
-`node tools/launch/income-tiers.mjs --check` (in `tools/ci/pre-push.sh`): the file equals the generator's output. `node --test tools/launch/income-tiers.test.mjs`: the schedule arithmetic against the fork's constants (100 MH/s on 100 GH/s after the ramp = 6,912 IGN a day, the figure in docs/analysis/horizon-2026-10.md; day 1 pays 10 percent; one month step pays 97.153 percent of the one before).

docs/analysis/latency-shadow-2026-10-06.md

@@ -111,13 +111,13 @@ The brief's `-pl` rows: the 5 October sweep on this card (`docs/plans/counter-as
 | 65% | 400 (the floor) | 310.6 | 114.46 | 0.369 | 3,051 |
 | 50% | 400 (clamped) | 302.4 | 109.20 | 0.361 | 3,050 |
 
-`power.min_limit` is 400 W (read again by this job: min 400, max 600), so `-pl 200` and `-pl 250` cannot be set on a 5090; those rows are re-used, not re-run, and the ladder above adds what the cap does once the program carries work. Ember Tune's own 5090 steps did not run (its second engine never mined; re-run pending the founder); its idle readbacks on PC 1: 90.6 W idle, 2,505 MHz core, 14,001 MHz memory, limit 450 of 575 W.
+`power.min_limit` is 400 W (read again by this job: min 400, max 600), so `-pl 200` and `-pl 250` cannot be set on a 5090; those rows are re-used, not re-run, and the ladder above adds what the cap does once the program carries work. Ember Tune's own 5090 steps did not run (its second engine never mined; re-run pending the project lead); its idle readbacks on PC 1: 90.6 W idle, 2,505 MHz core, 14,001 MHz memory, limit 450 of 575 W.
 
 The item 1 denominator moves: at the hash alone the 5090 is 290 W in the app (p95 290, max 295 W at 124 MH/s, the 5 October record on branch miner-eff: 2.34 microjoules) and 342 to 357 W in this bench (132 MH/s: 2.65 microjoules), not 326 W at 136.1 (2.40). The `f = 1` rows of chip-model-v3.md section 5.4 therefore read 5.0x (app) to 5.7x (bench) on GDDR7 against 5.1x, 7.3x to 8.3x on one HBM3 stack against 7.5x, 8.9x to 10.1x on eight against 9.2x: a move of 2 to 11 percent, inside the model's own margin.
 
 ## 6. The chip side, re-evaluated (approximate)
 
-The `f = 1` chip of chip-model-v3.md section 5.4, at the memory's activate ceiling: GDDR7 (16 devices) 166.4 MH/s at 0.466 microjoules per hash, one HBM3 stack 83.6 MH/s at 0.321, eight stacks 0.262; those are memory, static and controller only. With the shadow the chip adds a core that runs the per-epoch random block at `k` times a GPU's marginal energy per op. The unit is now measured: 11 pJ per counted op, the 5090's marginal at its shipping clock (10.2 to 13.2 pJ on the three rungs under the cap, section 5); the model's 5.5 pJ (section 5.7, from TGP minus 326 W over the whole budget) is half that and is kept as the `k = 0.5` column, which is also about the M5 Max's 6.9 pJ. Four columns: `k = 1` (a chip core as good as the 5090's ALU on a random program: RandomX's argument and the founder's test), `k = 1.5` (1.5x worse), `k = 0.5` (as good as the M5 Max's ALU, or the model's old unit), and `k = 0.3` (a wide-SIMD fixed-datapath array at N5: the int32 datapath energy of section 5.1, 0.06 pJ per add and 0.52 per multiply at the op mix's 29 percent multiplies is 0.19 pJ, with a 2x pipeline overhead and about 8x for the register file, operand wires and the shared instruction fetch over a wide SIMD row, approximate; the floor a chip maker would claim). Section 5.7's "k = 1.5" column was computed as the chip being 1.5x BETTER (0.83 at N = 100,000 is 0.466 + 0.55 / 1.5); the columns below compute `k` as written. Energy per hash = memory + N x 11 pJ x k; N in counted ops.
+The `f = 1` chip of chip-model-v3.md section 5.4, at the memory's activate ceiling: GDDR7 (16 devices) 166.4 MH/s at 0.466 microjoules per hash, one HBM3 stack 83.6 MH/s at 0.321, eight stacks 0.262; those are memory, static and controller only. With the shadow the chip adds a core that runs the per-epoch random block at `k` times a GPU's marginal energy per op. The unit is now measured: 11 pJ per counted op, the 5090's marginal at its shipping clock (10.2 to 13.2 pJ on the three rungs under the cap, section 5); the model's 5.5 pJ (section 5.7, from TGP minus 326 W over the whole budget) is half that and is kept as the `k = 0.5` column, which is also about the M5 Max's 6.9 pJ. Four columns: `k = 1` (a chip core as good as the 5090's ALU on a random program: RandomX's argument and the project lead's test), `k = 1.5` (1.5x worse), `k = 0.5` (as good as the M5 Max's ALU, or the model's old unit), and `k = 0.3` (a wide-SIMD fixed-datapath array at N5: the int32 datapath energy of section 5.1, 0.06 pJ per add and 0.52 per multiply at the op mix's 29 percent multiplies is 0.19 pJ, with a 2x pipeline overhead and about 8x for the register file, operand wires and the shared instruction fetch over a wide SIMD row, approximate; the floor a chip maker would claim). Section 5.7's "k = 1.5" column was computed as the chip being 1.5x BETTER (0.83 at N = 100,000 is 0.466 + 0.55 / 1.5); the columns below compute `k` as written. Energy per hash = memory + N x 11 pJ x k; N in counted ops.
 
 ALU silicon for the core, at the 5090's 45.2 T op/s (what N = 330,700 at 136.1 MH/s needs): 22,600 32-bit lanes at 2.0 GHz. At N5 an int32 multiply-add lane with its register-file slice is about 0.002 mm^2 (approximate: 3,000 to 6,000 gates at about 0.3 square microns per NAND2-equivalent plus registers), so about 45 mm^2 of datapath, 60 to 100 mm^2 with SIMD control and operand networks, $25 to $40 of silicon at the sram-mirror.md yield model ($20,000 wafer, about $0.36 per mm^2 on a 128 mm^2 die; section 5 of that file); at 28 nm the same lanes are about 8x the area, 360 mm^2 of datapath and 500 mm^2 or more with control, a reticle-class die that a $5M to $30M controller project does not carry. Watts for the core at N = 330,700 and 136 MH/s: at `k = 1` 11 pJ x 45.2 T = 497 W (more than the whole 5090 draws for the same work, which is what `k = 1` means), at `k = 0.5` 249 W, at `k = 0.3` 149 W. At N = 100,000 the array is a third of that: 14,000 lanes, about 30 mm^2 at N5, 150 W at `k = 1`, 45 W at `k = 0.3`.
 

docs/analysis/m16-recompute-attacker-2026-10-05.md

@@ -111,5 +111,5 @@ prototype values of spec 1.16, fixed at gate 1.
    the 1,170 directly.
 4. Monero's seven years do not price this device (ledger C13).
 
-Decision at gate 1 (owner: the founder): the cache size rule "exceeds what one die can hold, and grows", and the mixer
+Decision at gate 1 (owner: the project lead): the cache size rule "exceeds what one die can hold, and grows", and the mixer
 cost multiplier, against the CPU verify gate.

docs/analysis/mission/future.md

@@ -1,566 +0,0 @@
-# The last mission, lane 3: the far future, 2030 to 2036
-
-Written 7 October 2026 by the future lane. Scope: the ten-year axes Horizon lane 7 did not cover, and the years 2030 to 2036 on the axes it did. Lane 7's rows to 2030 (`docs/analysis/horizon/frontier.md` 2.1 to 2.6) are taken as given and not repeated; where this lane disagrees, the row is named and the reason sourced. Every figure from memory is labelled approximate. Every figure from a source names it, with a URL in the sources list and the access date (all accessed 7 October 2026 unless stated). Times are UK. The arithmetic behind sections 2, 3, 4, 6 and 7 is `model.py` in this lane's scratch directory (`scratchpad/mission-future/`), reproduced in the tables.
-
-The design this lane tests (horizon-2026-10.md section 1): an hourly random GPU program, a 256 MiB cache over a daily multi-GB dataset (2 GiB at genesis, doubling at years 4, 12, 28), latency-shadow work in a six-rung N ladder stepped by 90 percent miner signal, class v5 (dataset from chain state) as a candidate, miner-only finality with BLS vote keys weighted by 30 days of blocks, SP1 zkEVM proving by miners (the 20 percent pool), 100 IGN a block gliding to a 1 percent tail, no stake, no dev fund, no other chain in consensus.
-
-## 0. Progress
-
-| Time (UK) | State |
-|---|---|
-| 08:2x | Brief read: CLAUDE.md, frontier.md 2 and 6, algorithm.md 5, chip-model-v3.md 5, horizon-2026-10.md 1, finality-in-proof.md 4, 51-percent.md, bench-log rental entry |
-| 08:3x to 08:5x | 50 web searches (the session's search budget ran out at 50; the rest went by direct fetch), 27 primary fetches |
-| 08:5x | Model run (`model.py`): emission by year, chip thresholds, rental curve, heat credit, PQ bytes, wallet battery |
-| 08:5x to 09:00 | Sections 1 to 11 written, 566 lines, copy-law check clean (no em or en dashes, ASCII only) |
-| 09:00 | DONE. File handed to the coordinator. Nothing committed; nothing on the devnet touched; no build or measurement run |
-
-The tiers, used in every row: home miner with one 8, 12, 16, 24 or 32 GB card; a rig; a pool user; on Windows, Linux, macOS; NVIDIA, AMD, Apple.
-
-## 1. GPU and memory roadmaps, 2027 to 2036
-
-### 1.1 The roadmap, sourced
-
-| Item | What is announced or reported | Source | Label |
-|---|---|---|---|
-| HBM4 | Mass production at Samsung and SK hynix from February 2026; 2,048-bit interface, 8 Gbps a pin, about 2 TB/s a stack; 12-high 36 GB; SK hynix 16-high 48 GB from Q3 2026; Micron samples over 11 Gbps, 2.8 TB/s | TrendForce 9 Jan 2026; EE Times CES 2026; Astute Group | cited |
-| HBM4 price | About USD 550 a 36 GB stack, USD 15.3 per GB (factory gate) | siliconanalysts.com/tools/hbm-analysis | approximate (the site cites no primary) |
-| HBM4E | Late 2027 to 2028; 14 to 16 Gbps a pin, 3.6 to 4.0 TB/s a stack; 16-high; custom base dies on TSMC N3 (the GUC and TSMC "C-HBM4E" line, 12.8 GT/s by 2027); Samsung HBM4E samples May 2026 at 3.6 TB/s | TrendForce 23 Dec 2024; Tom's Hardware (TSMC/GUC); TechTimes 30 May 2026 | cited |
-| HBM on a consumer card | None announced. The Feynman datacentre architecture (2028) "supports HBM"; no consumer HBM part from NVIDIA, AMD or Intel on any roadmap found | Wikipedia Feynman page; the 2027 to 2028 rumour set | cited (absence) |
-| GDDR8 | No JEDEC standard. SK hynix's roadmap to 2031 lists "GDDR7-Next" for 2029 to 2031 | Tom's Hardware (SK hynix roadmap); TechSpot | cited |
-| GDDR7 devices | 2 GB ended at Micron (Sep 2026); 3 GB shipping at USD 60 to 70; 4 GB and 6 GB devices reported for 2027 to 2028 | chip-model-v3 5.1; wccftech; club386 | 3 GB cited, 4 and 6 GB rumour |
-| RTX 60 (Rubin GR20x) | Late 2027 slipped to 2028; GDDR7; the 6090 reported at 512-bit with 32 GB or 48 GB | TweakTown; wccftech; BigGo | rumour |
-| AMD RDNA 5 / UDNA | Mid-2027 to 2028; GDDR7 at 36 Gbps; flagship "AT0" 154 CUs, 36 GB on 384-bit, 1.7 TB/s, 380 W; shares a chiplet design with the next Xbox; GDDR7 support landed in the Linux driver | TweakTown; TechPowerUp; Tom's Hardware driver note | rumour, driver patch cited |
-| NVIDIA consumer chiplets | Nothing reported; Rubin consumer parts described as monolithic | the same rumour set | approximate |
-| Strix Halo class | Strix Halo: 256-bit LPDDR5X-8000, 256 GB/s. Medusa Halo (2027 to 2028): LPDDR6 on 256-bit (461 GB/s) or 384-bit (691 GB/s) | VideoCardz; hardware-corner.net | rumour |
-| Apple | M5 Max: up to 128 GB unified, 614 GB/s (40-core GPU), 460 GB/s (32-core); M5 Ultra Mac Studio August 2026 | Apple newsroom 3 Mar 2026 and Aug 2026 | cited |
-| LPDDR6 | JESD209-6 published July 2025; 2 sub-channels a die, 12 DQ each, 4 CA each; activate timings not public | JEDEC press release | cited; timings unknown |
-| DDR5 | 32 banks in 8 groups of 4 (x4/x8); JESD79-5D Nov 2025; tFAW a four-activate window | JEDEC; DDR5 core datasheet | cited |
-| The latency floor | "The latencies of three fundamental DRAM operations have not improved significantly in the past 18 years"; improvements "relatively stagnant for the last two decades" | Lee et al. (arXiv 1604.08041); Chang et al. (arXiv 1805.03154) | cited |
-
-### 1.2 What it means for the memory-latency-bound hash
-
-The hash advances one dependent 4-byte read per memory latency; the rate is activates per tFAW window times channels, and energy is per activate (chip-model-v3 5.3). Pin speed does not move it. So the ten-year question is only: do channels per watt per dollar move, and does tRC or tFAW move. The sources say tRC has been flat for about twenty years, and no DRAM roadmap to 2031 (SK hynix) names a row-cycle improvement. HBM4 doubles channels per stack (lane 7, 2.3). HBM4E adds pin speed and a custom base die, not channels. GDDR7-Next is 2029 to 2031 and unspecified. Consumer HBM does not exist on any roadmap to 2028.
-
-| Year | Flagship consumer memory (projected) | Random reads per second, flagship (approximate) | Mid-tier card (12 to 16 GB) | Tier that wins or loses against 2026 |
-|---|---|---|---|---|
-| 2026 | 32 GB GDDR7, 512-bit, 16 devices | 17.5 G measured (5090) | 12 GB, 192-bit, 6 devices: about 6.5 G | baseline |
-| 2028 | 36 to 48 GB GDDR7, 384 to 512-bit (RDNA 5 rumour, RTX 60 rumour) | 16 to 21 G: the same, capacity adds no channels | 16 to 18 GB on the same channel count (3 GB devices): the same rate | nobody: a 2026 card keeps its rate against a 2028 card |
-| 2031 | 48 to 64 GB GDDR7-Next (SK hynix window) | unknown; if channels per device rise to 8 (approximate guess), 1.5 to 2x | 24 GB mid-tier on the same count | the 2026 owner falls to 0.5 to 0.7x of the new card, the normal GPU cadence |
-| 2036 | 64 to 96 GB (extrapolation of lane 7's 1.167 a year); HBM on a halo consumer part possible but unannounced | 2 to 4x of 2026 if a consumer HBM4-class part ships; otherwise 1.5 to 2x | 32 GB mid-tier | the 8 and 12 GB tiers are gone from the installed base (Steam trend, algorithm.md 5.6), not from the hash |
-
-Apple and APUs: the M5 Max's 614 GB/s is a 512-bit LPDDR5X bus (approximate); LPDDR activates are the same DRAM physics, so the Apple tier stays "0.78 uJ per hash, 21 W" class (algorithm.md 5.3a), the best per joule and the worst per dollar (USD 129 per MH/s). Medusa Halo on 384-bit LPDDR6 would be a 24 to 36 channel part (approximate: 2 sub-channels a die): a mid-tier card's read rate at laptop watts. Consequence per tier: Apple and APU miners stay the per-joule leaders and never the per-dollar ones; nothing in the hash changes that in ten years.
-
-### 1.3 The cache, the dataset schedule and the ladder, re-read against the roadmap
-
-| Design item | Roadmap fact | Verdict | Recommendation |
-|---|---|---|---|
-| 256 MiB cache "above every GPU's on-die cache" (the spec's rule) | 5090 L2 96 MB, GB202 128 MB; MI300X carries 256 MB Infinity Cache (datacentre, approximate from memory); RDNA 3's 7900 XTX 96 MB; no consumer part at 256 MB announced | Safe to 2028. At risk from 2029 to 2031 if a consumer part ships a 256 MB last-level cache, which the datacentre already does | Add a cache-size rung to the era-draw ladder beside N (256 to 512 MiB), stepped by the same 90 percent signal, in place of the fixed year-4 doubling alone; the trigger is a shipped consumer part with LLC at or over the cache size |
-| Dataset 2 GiB, doubling at years 4, 12, 28 | Card memory 32 GB now, 48 to 64 GB by 2030 (lane 7); one HBM3 stack holds 24 GB | Right. The dataset is not a lever against the stored-dataset chip (chip-model-v3 5.7) and never binds a tier before year 12 (algorithm.md 5.6) | Hold the schedule; the public card-lifetime sentence should carry the prover footprint, not the dataset (algorithm.md 5.6's one change) |
-| N ladder rungs measured on 2026 cards | The honest card's bind point moves with each generation: a 2028 card with the same read rate and 1.5x the ALUs binds at a higher N; HBM4 doubles the chip's rate per stack | Rungs are a 2026 measurement. They are the right shape and the wrong numbers for 2029 | Re-measure the rungs per card generation (the Steam top-10 cards each era) and publish the bind points; the signal mechanism already lets miners refuse a rung their cards cannot hold, so no genesis change, only a measurement duty written into the era-draw docs |
-| C-HBM4E custom base die (2027 to 2028) | The base die under the stack becomes a logic die on N3 that a customer designs (TSMC and GUC) | This is the f = 1 chip's controller moved under the memory: the chip-model's "controller and PHY die beside it, 10 W, USD 50, plus a USD 200 one-stack interposer" row (5.3) collapses into the base die. Lane 7's 2.3 did not price it | Disagreement with lane 7 row 2.3 "HBM4 one stack (2028)": the controller and interposer lines fall toward zero, so the HBM4 chip's dollars per MH/s fall below the USD 2.8 GDDR7 figure by 2028, approximate. The answer is unchanged in kind (N, the price per joule) and larger in degree; section 2 carries it |
-
-Per tier, section 1 in one line each: 8 GB (mines to year 12, never proves beside its miner); 12 GB (mines to year 28, loses mine-and-prove at year 4); 16 GB (mines and proves to year 12); 24 and 32 GB (unconstrained to 2036 on every roadmap found); rig (the rate per card is flat through 2028, so a 2026 rig is a 2028 rig); pool user (the pool's share tracks the installed base, which loses the 8 GB tier by 2030); Windows and Linux (no change); macOS (per-joule best, per-dollar worst, both for ten years); NVIDIA (channel count flat to 2028); AMD (RDNA 5 brings GDDR7, a 36 GB flagship: AMD's first competitive random-read part since the 9070 XT's 2.4 to 2.7 G); Apple (as macOS).
-
-## 2. The ASIC maker's economics, 2026 to 2036
-
-### 2.1 Inputs
-
-| Input | Value | Source |
-|---|---|---|
-| Mask set, total NRE: TSMC 28 nm | USD 1 M, 1.8 M | siliconanalysts.com/data/wafer-pricing (Sep 2026) |
-| 16 nm | 1.8 M, 3.2 M | same |
-| 7 nm | 3.5 M, 5.5 M | same |
-| 5 nm | 6.5 M, 10 M | same |
-| 3 nm | 15 M, 22 M; design cost of a 3 nm chip USD 400 to 600 M all-in | same; siliconanalysts tsmc-3nm-cost |
-| 2 nm | masks USD 15 to 30 M; design cost quoted at USD 724 M | semiwiki thread; siliconanalysts | approximate |
-| A16, A14 | no mask quote found; "capex per 1,000 wafers at A14 higher than N2" | semiwiki A14 thread | approximate |
-| Wafer, 300 mm | 28 nm 3,000; 16 nm 5,500; 7 nm 9,500; 5 nm 20,000; 3 nm 20,000 (range to 27,000) | siliconanalysts wafer-pricing | cited |
-| Leading-edge tapeout, all-in | USD 30 M to 100 M+ at 3 to 5 nm; 5 to 30 M at 7 to 28 nm | siliconanalysts tapeout guide, 1 Mar 2026 | cited |
-| The f = 1 chip | 166 MH/s, 78 W bare, 228 W with a 150 W shadow core at k = 1; USD 470 of memory, controller and board; USD 2.8 per MH/s | chip-model-v3 5.4, lane 7 2.3 | model |
-| The honest card | 5090 at class v4: 3.27 uJ, 431 W cap, 132 MH/s; USD 1,999 MSRP | algorithm.md 5.3a | measured |
-| Emission (model) | 100 IGN a block, 90-day ramp from 10 percent, monthly glide at 2.9 percent, tail 1 percent a year from year 11.4 | tail-emission.md | model |
-| Rental equilibrium | hash joins until rent equals subsidy: 39, 156, 780 GH/s at USD 0.005, 0.02, 0.10 per IGN | security-budget.md via 51-percent.md | model |
-
-Emission by year from the model (IGN, approximate): year 1 2.32 B, year 2 1.87 B, year 3 1.31 B, year 4 0.92 B, year 5 0.65 B, year 6 0.46 B, year 7 0.32 B, year 8 0.23 B, year 9 0.16 B, year 10 0.11 B; supply 4.18 B at the end of year 2, 7.07 B at year 5, 8.33 B at year 10.
-
-### 2.2 The decision tree, written out
-
-The maker chooses a target share s of the hash and a node. Revenue over the chip's two-year life is s x E2 x p, where E2 is the two-year emission and p the IGN price. The fleet needed is s/(1 - s) x H(p), and at the rental equilibrium H(p) = 7.8 M MH/s per USD of price, so the fleet's cost is also linear in p: 0.43 x 7.8 M x USD 4.64 per MH/s (the chip's two-year cost per MH/s with power at USD 0.05 per kWh, model) against two-year revenue per MH/s of 0.0117 x 17,520 = USD 205. The fleet term is 2 percent of revenue and drops out. The project pays when p is over p* = C_proj / (s x E2), and the market cap at which it pays is p* x supply. At s = 0.30 (an economic miner just under the veto third):
-
-| Node (project all-in) | Years 1 to 2 (E2 = 4.18 B) | Years 3 to 4 (2.24 B) | Years 5 to 6 (1.10 B) | Years 7 to 8 (0.55 B) | Years 9 to 10 (0.27 B) |
-|---|---|---|---|---|---|
-| 28 nm controller only, no shadow core (USD 5 M) | p* 0.0040, cap USD 17 M | 0.0075, 48 M | 0.0151, 114 M | 0.0306, 247 M | 0.0620, 517 M |
-| 28 nm controller + N5 shadow core (USD 30 M) | 0.0239, 100 M | 0.0447, 287 M | 0.0906, 682 M | 0.1836, 1,481 M | 0.3718, 3,099 M |
-| N3 single die, controller + shadow + lanes (USD 60 M) | 0.0478, 200 M | 0.0895, 574 M | 0.1813, 1,363 M | 0.3672, 2,961 M | 0.7437, 6,198 M |
-| N2 (USD 150 M, 2026 quotes) | 0.1195, 500 M | 0.2237, 1,436 M | 0.4532, 3,408 M | 0.9179, 7,403 M | 1.8592, 15,495 M |
-| A16 / A14 (USD 250 M, extrapolated) | 0.1992, 833 M | 0.3729, 2,393 M | 0.7553, 5,680 M | 1.5298, 12,339 M | 3.0987, 25,825 M |
-
-Reading. The stored-dataset chip without a shadow core pays at a USD 17 M market cap in the first two years, because its project is a 28 nm controller (chip-model-v3 5.6) and the chip's hour costs 56x less than rented hash. The class v4 shadow core forces an N5-class die (30 mm^2 at N = 100,000, lane 7) and lifts the bar 6x to USD 100 M. The glide lifts every bar about 2.3x per two years, so by years 9 to 10 the same N5 chip needs a USD 3.1 B cap. Nothing here needs N2 or A16: the chip is memory, and a leading node buys it nothing. So the "ASIC maker's economics at every node" collapses to two nodes, 28 nm and N5, and the N ladder is what moves between them.
-
-Minimum volume to break even against buying cards (saving USD 2,131 a chip over two years against 5090s at the same hash, model): 28 nm bare 2,346 chips (0.39 TH/s); 28 nm + N5 shadow 14,077 chips (2.34 TH/s); N3 28,155 (4.67 TH/s); N2 70,387 (11.7 TH/s); A14 117,312 (19.5 TH/s). Against the rental-equilibrium hash (39 to 780 GH/s at today's three price inputs) the 2.34 TH/s break-even fleet is 3x to 60x the whole network: the chip only pays once the price is high enough for the network to be a few TH/s, which is the p* column above said another way.
-
-### 2.3 The memory-controller chip against HBM4, per joule and per dollar, 2026 to 2036
-
-| Year | Memory the chip buys | Chip uJ per hash at N = 100,000, k = 1 (approximate) | Honest 5090-class uJ | Edge per joule | Chip USD per MH/s | What moves it |
-|---|---|---|---|---|---|---|
-| 2026 | GDDR7, 16 x 2 GB | 1.37 | 3.27 | 2.4x | 2.8 | the measured row (algorithm.md 5.3a: 2.1x at the 5090's 431 W cap) |
-| 2028 | HBM4, one stack 36 GB, C-HBM4E base die as the controller | 1.33 (algorithm lane's correction of lane 7's 1.11) | 3.3 (a 2028 card at the same read rate) | 2.5x | 2.0 to 2.5 (the interposer and controller rows fall into the base die; approximate) | HBM4 price USD 550 a stack falls as HBM4E takes the premium (approximate) |
-| 2031 | HBM4E or HBM5 (SK hynix lists HBM5 on the 2029 to 2031 window) | 1.2 to 1.3 at the same N; 0.9 at N = 100,000 if activates per channel double again | 3.0 to 3.3 | 2.5x to 3.5x | 1.5 to 2.0 | activate parallelism per stack; unsourced beyond HBM4 |
-| 2036 | the same class | the per-joule edge is bounded below by N x 11 pJ x k, so at N = 330,000 and k = 1 the chip pays 3.6 uJ of program work whatever its memory | 5.0 at 330,000 (the 5090 is compute-bound there) | 1.3x | 1.5 | N and k only |
-
-Does the chip get cheaper or dearer per joule as HBM prices fall: dearer in dollars relative to the GPU through 2027 (lane 7 2.2, memory is 70 percent of its bill), cheaper from 2028 when the base die absorbs the controller, and flat per joule, because per joule is set by activates and by N. Per tier: the home 5090 owner stays inside 2.1x to 2.5x of the chip at N = 100,000 through 2031 and inside 1.3x at N = 330,000; the 4070-class 12 GB owner the same within 10 percent; the AMD 9070 XT owner sits at 5x to 8x behind the chip at every rung (its measured 10.6 uJ) and is the first tier a chip displaces; the Apple tier sits under the chip's per-joule line at every rung. The rig owner is a 5090 owner times eight. The pool user inherits the pool's card mix.
-
-### 2.4 The FPGA route
-
-AWS F2 (f2.6xlarge, VU47P, 16 GB HBM2, USD 1.98 an hour on demand, USD 0.66 spot) is the measurement the algorithm lane planned (algorithm.md 5.1); nothing has run. The tightened range stands: 2.3 to 2.9 G reads a second a card, 0.30x to 0.47x of the 5090 per watt, at USD 4,000 to 5,000 a card (approximate). Versal HBM and Agilex 7 M-series carry HBM2e (faster pins, the same tFAW), so they sit in the same row. An HBM4-based FPGA (none announced) would carry HBM4's channel count and the 0.3x to 0.5x row would become 0.6x to 1.0x (approximate, derived). Verdict: no FPGA displaces any tier to 2031; the F2 hour should still run, because the per-stack activate rate it measures is the input every row above rests on.
-
-Recommendation for section 2: (1) the N ladder at genesis, as lane 2 and lane 7 said, with the bind-point re-measurement duty of 1.3; (2) write the p* table into the public threat model with the sentence "a stored-dataset chip pays at about USD 100 M of market cap in year 1 and about USD 700 M in year 5 (model, approximate)"; (3) no genesis parameter changes for N2 or A16, because the chip never needs them.
-
-## 3. AI compute demand and the GPU supply
-
-### 3.1 The numbers
-
-| Row | Value | Source | Label |
-|---|---|---|---|
-| Datacentre GPUs shipped 2023 | 3.85 M units (NVIDIA 3.76 M, AMD 0.5 M, Intel 0.4 M) | TechInsights via HPCwire, 10 Jun 2024 | cited |
-| Datacentre GPUs 2024, 2025 | USD 123 B of GPUs and accelerators in 2024, USD 207 B in 2025 (Omdia); NVIDIA estimated 5.2 M Blackwell GPUs in 2025; GB200 cabinet forecasts cut to 25,000 to 35,000 (2.5 M GPUs) | Omdia Aug 2025; Tom's Hardware | cited, unit counts secondary |
-| Installed datacentre fleet by end-2026 | 15 to 20 M Hopper and Blackwell class units (sum of the rows above) | arithmetic | approximate |
-| Consumer AIB shipments | Q2 2026 12.5 M units, +10 percent QoQ, +6.6 percent YoY; H1 2026 24.3 M; NVIDIA about 90 percent | Jon Peddie Research Q2 2026 | cited |
-| Used H100 | USD 18,000 to 22,000 in 2026; residual 40 to 75 percent at 36 months, 25 to 35 percent at 60+ months; A100 80 GB USD 12,000 to 18,000 | mercatus-ai.com (verified 23 Jun 2026); intuitionlabs | cited, secondary |
-| H100 rental | USD 1.49 (Vast.ai hosts) to 6.98 an hour; was over USD 7 in early 2024; spot about USD 1.00 | cloudzero; spheron; shattered.io (2026) | cited |
-| Consumer card rental | 5090 USD 0.21 to 0.44 an hour (Vast.ai, 6 Oct 2026); 4090 0.28 to 0.60 | lane 7 2.4 | cited |
-| Igneum hash rental | USD 0.0117 per MH/s-hour (RunPod community pods, 38 pods, 1,748 MH/s for USD 20.44 an hour); 8x 4090 rig USD 0.0129; a 5090 pod 98 to 128 MH/s for USD 0.41 to 0.74 | bench-log, 6 Oct 2026 | measured |
-
-### 3.2 The used-GPU flood, 2027 to 2030
-
-Hopper fleets bought in 2023 to 2024 reach the 36-month residual cliff in 2026 to 2027 and the 60-month floor in 2028 to 2029. Can they mine Igneum: the hash is memory-latency-bound, so an H100 is its five HBM3 stacks (80 GB) and an A100 its five HBM2e stacks. At chip-model-v3's unmeasured HBM3 ceiling (10.7 G reads a second a stack) an H100 reads 53 G, 3x a 5090; at the JEDEC tFAW ceiling (2.3 G a stack) 11.5 G, 0.65x. Nobody has measured it; the fleet measured A4000, A5000, L4, 3090 and 4090 (prover-tiers-real-cards.md), not an HBM part. The honest statement: an H100 mines Igneum at 0.65x to 3x of a 5090 at 700 W, which is 0.3x to 1.4x per watt (approximate, both ends unmeasured).
-
-| Scenario | Hash it adds | Against the rental equilibrium (39 to 780 GH/s) | What the ladder does |
-|---|---|---|---|
-| 1 percent of a 1 M retired H100 fleet (10,000 cards) at 1x a 5090 | 1.3 TH/s | 2x to 35x the whole network | nothing: the shadow binds compute, and an H100 has 4x a 5090's ALUs per read; it holds every rung |
-| 10 percent | 13 TH/s | 17x to 330x | the same |
-| Rental at USD 1.49 an hour for 0.65x to 3x of a 5090 | USD 0.0045 to 0.021 per MH/s-hour | at or above today's 0.0117: no cheaper than consumer pods at list price | n/a |
-| Idle-time rental (the owner's marginal cost is power) | USD 0.00016 to 0.0007 per MH/s-hour at USD 0.05 per kWh | 17x to 70x under today's rent | n/a |
-
-The ladder is a joule argument against a fixed-datapath chip; against a GPU with more ALUs it is silent. The used-fleet question is a price question only.
-
-### 3.3 The ten-year rental curve and the 51 percent table
-
-The H100 rate fell about 45 percent a year from early 2024 to 2026 (USD 7+ to about 2); consumer-card rent fell as purchase prices rose (lane 7 2.4). Three curves for USD per MH/s-hour from today's 0.0117 (model):
-
-| Year | At -20 percent a year | At -30 percent a year | At -45 percent a year |
-|---|---|---|---|
-| 2028 | 0.0075 | 0.0057 | 0.0035 |
-| 2031 | 0.0038 | 0.0020 | 0.0006 |
-| 2036 | 0.0013 | 0.0003 | 0.00003 |
-
-What it does to `51-percent.md`: nothing to the dollar cost of any attack, because every row there is priced at the rental equilibrium, where rent equals subsidy. A cheaper rent means more hash joins until rent equals subsidy again: at 2036's -30 percent curve the equilibrium hash is 35x today's at the same IGN price, and the attack costs the same twelve days of emission. What the curve changes is the home card's share of the subsidy, which falls 35x with the hash, and the supply ceiling of the rental market, which stays the real limit (the market gave zero pods when asked for twenty, bench-log). Update the 51-percent price basis each year from a measured rental, not from a curve.
-
-### 3.4 Per tier: does a home card stay competitive against an idle datacentre card
-
-Cost per MH/s-hour, electricity only, a 5090-class card at 3.27 uJ (model):
-
-| Owner and power price | USD per MH/s-hour | Margin under today's 0.0117 rent | Margin if idle datacentre hash sets the rent (0.00016) |
-|---|---|---|---|
-| UK home, 26.32 p (Ofgem cap, Q4 2026) | 0.00114 | 10x | loses 7x |
-| Germany home, EUR 0.387 | 0.00137 | 9x | loses 9x |
-| US home, 17.7 c (EIA, H2 2025) | 0.00058 | 20x | loses 4x |
-| Texas industrial, 5 c (approximate) | 0.00016 | 72x | break-even |
-| Paraguay, 4.4 to 6 c (ANDE crypto tariff, Decree 7824/2022, contracts end 31 Dec 2027) | 0.00016 | 72x | break-even |
-| Iran, licensed, about 1 c | 0.00003 | 358x | wins |
-
-The home card is competitive while the marginal supplier of hash is a rented consumer pod at list price (today). It is not competitive the day the marginal supplier is an idle datacentre card on industrial power, and the used-fleet flood of 3.2 makes that day a price event, not a technology event. Per tier: 8 and 12 GB home cards lose first (their uJ is 1.3 to 1.7x worse than the 5090's); 24 and 32 GB cards last; a rig is a home card eight times, on the same power price; a pool user's payout tracks the pool's share, which falls with the home share; Windows and Linux are the same; macOS at 0.78 uJ (M5 Max) holds a 4x power edge over the 5090 and loses last of all the home tiers; NVIDIA and AMD as their uJ rows (algorithm.md 5.3a); Apple as macOS.
-
-What Igneum should do: the reward rule that prices rented hash out (lane 7's 3.1, weight-aged keys paid more) is the only lever in the protocol; the earnings page should show the miner's own cost per MH/s-hour against the network's implied rent, so a UK miner sees the day the line crosses; and the H100 and A100 random-read rate should be measured on one rented card this month (two hours, under the measure lock), because every row of 3.2 rests on it.
-
-## 4. Energy, heat and the home
-
-### 4.1 Prices and forecasts
-
-| Region | Household price 2026 | Ten-year direction | Source |
-|---|---|---|---|
-| UK | 26.11 p per kWh (Jul to Sep 2026 cap), 26.32 p (Oct to Dec 2026) | Cornwall Insight's wholesale path falls to GBP 83 per MWh by 2029 ("over GBP 40 above historic"); retail scenarios 22 to 42 p by 2030 | Ofgem; Cornwall Insight (Jan 2024); solarpanelsforfactories (secondary) |
-| EU | EUR 28.96 per 100 kWh average H2 2025; Ireland 40.42, Germany 38.69, Belgium 34.99; Hungary 10.82, Malta 12.82, Bulgaria 13.55 | The Commission's Electrification Action Plan (17 Jul 2026) targets electricity at most 2.5x gas for households by 2030 | Eurostat 5 May 2026; Commission |
-| US | 17.7 c average H2 2025; "continue steady increase" | AEO2025 reference: 13 c (2024, a different basis) to over 20 c by 2050 | EIA |
-| Cheapest mining regions | Iran about 1 c (licensed); Ethiopia 2 to 5.3 c; Paraguay 4.4 to 6 c; Kazakhstan about 4 c; Nigeria 4.8 c hosted | spark.money; oneminers; hashrateindex Paraguay (4 May 2026) | secondary |
-
-### 4.2 Home mining as heating
-
-| Product or trial | Facts | Source |
-|---|---|---|
-| Heatbit Trio, Maxi, Maxi Pro | USD 849 (10 TH/s, 400 W mining + 1,100 W resistive) to USD 1,499 (60 TH/s, 1,500 W); seasonal BTC USD 300 to 420 (Heatbit's own figure); Wired's review: mining covers 30 to 40 percent of electricity at 12 to 15 c per kWh | miningboard.com; techbuzz (5 Apr 2026) |
-| 21energy, MintGreen, HotMine | convector radiators 250 to 2,700 W; hydronic boilers for radiators and hot water | miningboard.com |
-| Qarnot "radiateur numerique" | 100 RIVP social-housing flats in Paris 15e heated by compute radiators from 2013; Qarnot moved to boilers; the model is "the building pays the capital, heat is free" | fr.wikipedia Qarnot; maisonapart |
-
-The economics per kWh (model): a 5090 at the 431 W cap is a 0.43 kW heater. Credit the heat at the gas price delivered through a 90 percent boiler, or at a heat pump's electricity (COP 3):
-
-| Region | Electricity | Heat credit, gas | Heat credit, heat pump | Effective price in the heating season |
-|---|---|---|---|---|
-| UK | 26.3 p | 7.0 p (27 percent) | 8.8 p (33 percent) | 17.5 to 19.3 p |
-| Germany | 38.7 c | 13.3 c (34 percent) | 12.9 c (33 percent) | 25.4 to 25.8 c |
-| US | 17.7 c | 5.6 c (31 percent) | 5.9 c (33 percent) | 11.8 to 12.1 c |
-
-A third off the power bill for the 1,500 to 2,000 heating hours a year (approximate), everywhere. It moves a UK home miner from 7x to 5x the Texas industrial price, not to parity. Consequence per tier: it matters most to the tiers with the worst uJ (8 and 12 GB, AMD) and least to Apple (21 W is not a heater). Recommendation: a heat mode in Ember (run the miner only while a room thermostat or schedule calls, power cap set to the room's load, the hourly program unchanged), which costs nothing in protocol and is the one feature home-mining heaters ship.
-
-### 4.3 Grid balancing
-
-ERCOT paid Riot USD 31.7 M in August 2023 (24.2 M curtailment credits plus 7.4 M demand response) and Riot booked USD 30.6 M of power-curtailment credits in Q3 2025, up 147 percent on the year (ABC13; Riot releases). The programmes name "large flexible customers"; a home GPU is not one. Home aggregators exist (the UK's supplier demand-flexibility sessions, US utility programmes; approximate, from memory) and pay per kWh shed against a baseline. A fleet of Ember miners is a shed-able load only if a signal reaches it. Recommendation: a curtailment input in Ember (a webhook, a schedule, a price threshold from a public spot feed) that pauses the miner and resumes it; the protocol sees a key that stops voting for an hour, which the LEAVE item of 0.3.16 already prices as nothing (vote-or-burn.md: no burn). Per tier: a pool user's pool must pass the signal down; a rig is the only home tier big enough to enrol directly.
-
-### 4.4 The rules by region
-
-| Region | Rule | Source | What it means for an Igneum home miner | What Igneum builds |
-|---|---|---|---|---|
-| EU, MiCA | White papers must state the consensus mechanism's climate impacts; CASPs must publish the sustainability indicators per asset (Delegated Regulation (EU) 2025/422; mandatory kWh a year, more above 500,000 kWh); Article 142 report on environmental impact and "minimum sustainability standards"; the 2022 Parliament vote dropped a PoW ban; the 2026 MiCA review consultation (reply by 31 Aug 2026) asks only how appropriate the disclosure regime is (Q53) and nothing on PoW | MiCA; 2025/422; the consultation PDF (fetched) | nothing on the miner; the exchanges that list IGN need the kWh figure | publish Igneum's own 2025/422-format indicators from the hash-rate and the measured uJ, updated each era |
-| Norway | ban on new PoW mining data centres from autumn 2025; data-centre registry; existing sites run | CoinDesk 23 Jun 2025 | home mining untouched; no new hosting | nothing |
-| Sweden | data-centre electricity tax relief removed July 2023 (SEK 0.006 to 0.36 per kWh); SEK 500 M of back-tax on nine firms 2024 to 2026 | CoinDesk 14 Apr 2023; crypto.news | home miners already paid full tax; hosting is dead | nothing |
-| Russia | mining banned in 10 regions 1 Jan 2025 to 15 Mar 2031; Moscow region from 15 Aug 2026 to 2032; seasonal bans in Irkutsk, Buryatia, Zabaikalsky; no new regions in 2026 | TASS; Cryptopolitan | a region check at install; the 2024 law's 6,000 kWh a month household allowance (approximate, from memory) covers one card | a region prompt in Ember with the banned list |
-| Kazakhstan | mining legal outside the AIFC (Nov 2025 law); "strategic mining" rules from 1 Aug 2026 with a share to the national reserve | Caspian News; KuCoin | licensed industrial; a home card is below any threshold found | nothing |
-| Paraguay | ANDE crypto tariff USD 44.33 per MWh (Decree 7824/2022), lifted toward 5.1 to 6 c; every crypto contract ends 31 Dec 2027 | hashrateindex 4 May 2026 | the cheapest hydro region closes to new load in 2028 | nothing |
-| Iran | licensed mining at a mining tariff; seasonal shutdowns in power shortages (approximate) | ainfp.org; MEXC | the cheapest power on earth and the least reliable | nothing |
-| China | illegal; joint Notice 6 Feb 2026 reaffirmed; one report of Sichuan, Inner Mongolia, Xinjiang reopening from 1 Jan 2026 is uncorroborated | lightspark; egw.news (single source) | a Chinese home miner runs at legal risk | the region prompt |
-| US, federal | SEC staff statement 20 Mar 2025: PoW mining, solo and pooled, is not a securities offering; DAME 30 percent excise proposed 2023, 2024, 2025 budgets, never enacted; EIA's emergency survey (Jan 2024) blocked in court (Mar 2024); CLARITY failed cloture 49 to 50 on 15 Sep 2026; GENIUS Act (stablecoins) 2025 | Dechert; Blockworks; Fortune; Orrick 2 Oct 2026 | nothing on the miner | nothing |
-| US, states | Texas, Kentucky, Wyoming pro; New York's fossil-PoW moratorium (2022, approximate); California's DFAL licensing from 1 Jul 2026 reaches crypto businesses, not a home card | sazmining; crypto.news | a home miner is not a licensee anywhere found | the region prompt |
-
-Per-region electricity-price prompt: the earnings page should default the price per kWh from a public table by country (the Eurostat, Ofgem and EIA rows above), let the miner edit it, and show the miner's own break-even hash share, because the number that ends a home miner is the bill, not the regulation.
-
-## 5. Zero-knowledge proving cost, 2026 to 2036
-
-### 5.1 The numbers today
-
-| Row | Value | Source | Label |
-|---|---|---|---|
-| EF real-time proving target (10 Jul 2025) | P99 under 10 s, capex under USD 100 K, under 10 kW, open source, 128 bits (100 accepted at first), proof under 300 KiB, no trusted setup; written for solo stakers "from home" on a 10 kW supply | blog.ethereum.org | cited |
-| Ethproofs 2025 review (6 Dec 2025) | USD 1.69 to under a penny a proof in nine months; 7 zkVMs, 15 provers, about 200,000 blocks; four teams at sub-10 s P99; single-GPU proving from 16 min to under 60 s; 2026 target sub-8 s P99 and kWh a proof as the metric | hackmd willcorcoran | cited |
-| SP1 Hypercube | 99.7 percent of blocks under 12 s on 16 x RTX 5090, cluster under USD 100 K; about USD 0.02 a block single-node | Succinct blog; The Block | cited |
-| Pico Prism | 99.9 percent under 12 s on 64 x 5090 | Brevis | cited |
-| Cysic Venus | 7.4 s a block on 24 GPUs (type unstated); ZK ASIC claims (1.33 M Keccak a second, 50x energy) with no shipping date | bex.co 17 Apr 2026 | cited, ASIC unverified |
-| ZisK | p99 9.62 s on 4 x 5090 | GitHub comparative analysis, Sep 2026 | secondary |
-| Airbender | 51 s average on one RTX 4090, under a cent | bex.co Jan 2026 | secondary |
-| RISC Zero | R0VM 2.0: 35 min to 44 s a block (Dec 2025) | wavect; RISC Zero blog | secondary |
-| Jolt | Lattice Jolt (9 Sep 2026): 2 to 3x faster, 65 to 80 KB proofs, 2 M cycles a second CPU, over 10 M with a GPU, post-quantum | cryptobriefing | cited |
-| Cost a block on the tracker | about USD 0.005 (Sep 2026) | lane 7 2.6 | secondary |
-| Hardware provers | Cysic (C1, ZK-Air, ZK-Pro), Fabric (VPU), Ingonyama (ICICLE; Accseal Leo ASIC in ICICLE v3), Irreducible (FPGA clusters, Binius), Supranational; "10 to 100x on MSM and NTT" claims | h33.ai survey; Ingonyama; Cysic docs | claims, no shipped benchmark on a zkVM block |
-| Igneum's own | 11 rented cards: shard beside the miner 10.7 s (5090) to 37.5 s (3060); alone 4.8 to 18.4 s; SP1 compressed verify 0.032 s on a Mac core | prover-tiers-real-cards.md; bench-log 5 Oct | measured |
-
-### 5.2 The trend line to 2036 and the 20 percent pool
-
-Lane 7's 33x a year is software catching hardware and cannot hold. Hardware alone is 1.5x a year. The EF's own 2026 metric is kWh a proof, which is the right axis for a miner-prover: a shard that costs a joule of GPU time is paid from the pool and competes with the same joule in the lottery.
-
-| Year | Block proof cost on the open market (USD, approximate) | Hardware that proves an Ethereum block in real time | What proves an Igneum shard (4.7 M cycles) under 10 s | Does a home 12 GB card have a place |
-|---|---|---|---|---|
-| 2026 | 0.005 to 0.02 | 16 x 5090 (SP1), 4 x 5090 (ZisK) | 5090 beside its miner (10.7 s), every card alone | yes, alone or hand-off (prover-tiers-real-cards.md) |
-| 2028 | 0.001 to 0.005 | 1 to 4 consumer cards; first ASIC or VPU boards if any ship (none has) | every card from the 3060 at 3x a year (lane 7's table); 12 GB beside the miner at 3x, not at 1.5x | yes alone; beside the miner only under 3x |
-| 2031 | 0.0003 to 0.001 | one consumer card, or a prover ASIC at 10 to 50x per joule if the claims land | a 12 GB card in 1 to 3 s | yes, but a prover ASIC would take the external job market first (dollar-priced jobs go to the cheapest joule), and the pool second only if shards are open to anyone |
-| 2036 | under 0.0001 | commodity | any card | the pool's economics are the lottery's: whoever holds vote weight is drawn (sortition by weight), so the home card keeps its share of the pool whatever an ASIC does to the open market |
-
-The design's defence is already in place: the pool is drawn by vote weight (sortition), and vote weight is 30 days of blocks, which a prover ASIC does not have. A prover ASIC centralises the external job market, not the pool. What it would do to the pool is set the shard deadline: if the chain tightens the deadline toward ASIC times, home cards miss it. So the shard deadline must be a function of the measured fleet median (lane 7's rule), re-read each era, and the shard size must stay at a size a 12 GB card proves alone inside it (today 4.8 to 14.4 s). "Verified proving as the reward" (horizon-2026-10 item 1: the proof verified in consensus) is the piece that makes the pool unforgeable, and its activation is the decision owed.
-
-Per tier: 8 GB (proves alone, never beside its miner; keeps its pool share by weight); 12 GB (the swing tier; the hand-off profile is the product); 16 GB and up (unconstrained); rig (proves beside mining on every card from 2028 at 1.5x); pool user (the pool operator's prover does it); Windows, Linux (the same); macOS (an M5 Max proves a shard, unmeasured against the rented table; Metal lane open); NVIDIA (every measurement is NVIDIA); AMD (no measured shard time; the 9070 XT has no SP1 GPU backend measured here, so the AMD tier proves on CPU or not at all until it is measured, which is the first owed number); Apple (as macOS).
-
-### 5.3 Proof-system risk and the swap interface
-
-| Event | Date | What a malicious prover could do | Source |
-|---|---|---|---|
-| SP1 v3.4.0 (LambdaClass, 3MI, Aligned) | disclosed 26 Jan 2025 | "generate valid SP1 proofs of incorrect execution of an arbitrary program": universal forgery, from two bugs plus a Plonky3 evaluation gap | LambdaClass blog; Blockworks |
-| RISC Zero zkVM 2.0.0 to 2.0.2 | 15 May 2025 | a missing constraint in the rv32im circuit let any 3-register instruction be proven wrong; on-chain verifiers stopped by estop | HackenProof |
-| SP1 Hypercube JALR | 20 May 2026 | a completeness bug (prover crash), not soundness; the EF's audit found only 51 of 62 opcodes fully proven, four load instructions proven against wrong specifications | zkevm.ethereum.foundation |
-
-Three soundness-class events in 18 months across the two leading zkVMs. On Igneum today a soundness bug is a light-client problem (spec 10.1; finality-in-proof.md 4.4): every full node executes natively and vetoes a record whose statement differs. It becomes a chain failure the day any of three things is true: (1) proof verification in consensus pays a shard on the proof alone (the 0.3.16 switch) and a forged proof carries a correct statement, which earns the pool and nothing else; (2) finality is carried inside the proof (lane 7's 3.3) and a forged proof carries a forged weight table, which a full node still vetoes, so the failure is confined to proof-only clients; (3) the chain ever lets a proof replace execution for full nodes, which the design forbids. So the chain-failure case is (3), and the rule is: never. The swap interface needs: a pinned verifier key per proof system with a version in the record; two independent zkVMs accepted in parallel (the EF's own "multiple provers" lesson), with a record valid only if its system is on the active list; a 95 percent class-change signal to retire a system, and a stop switch (RISC Zero's estop pattern) that any 1/3 of weight can flip to "execution only" inside an hour. Per tier: nothing a miner does; a pool's prover must build for two systems; the cost is two guest builds and two verifier keys.
-
-## 6. Light clients on phones, 2026 to 2036
-
-### 6.1 The state of the art
-
-| Client | What it verifies | Bytes and time | Source |
-|---|---|---|---|
-| Ethereum sync-committee clients (Helios, Kevlar) | 512-validator sync committee signatures; syncs in about 2 s, no storage; "lightweight enough to run on mobile" | about 25 KB per two days (24,576 bytes of keys plus the signature, header and branch) | a16z Helios; annotated spec |
-| Mina | a recursive SNARK of the whole chain | a 22 KB chain; "a few milliseconds of processing" | Mina docs via gate.com, iq.wiki |
-| Celestia Lumina | data-availability sampling in a browser or phone (Wasm, Rust) | random shares a block; bandwidth not published for 2026 (approximate: tens of MB a day) | celestiaorg/lumina; Eiger |
-| Bitcoin BIP-157/158 (Neutrino: Breez, Blixt) | compact block filters served by full nodes | headers and filters in under 5 minutes | Blixt; Lightning Labs |
-| StarkWare's Bitcoin header proof | every header since genesis in one STARK | 1 MB, under 100 ms on a phone | cryptotimes 11 Sep 2025 |
-| Zcash (Zashi/Zodl SDKs, lightwalletd; Tachyon-Lite) | shielded sync through servers | server-dependent (the anti-pattern) | Zcash forum, GitHub |
-| Kaspa wallets (Kaspium, kaspa-core) | none: wallets talk to public nodes over wRPC | n/a (approximate) | coincodex; Zelcore |
-| Phone verify times | Groth16 about 5 ms; a Keccak circuit's verify 0.12 s on an iPhone 15 Pro (Mopro); a 45 KB STARK in 16 ms (laptop, approximate); Groth16 proving 2.9 to 3.1 s on a Galaxy S25 and iPhone 17 Pro | Mopro benchmarks; provebench; shattered.io | cited, mixed devices |
-| WebGPU | in Chrome 113, Edge 113, Safari 18, Firefox 141 | n/a | Wikipedia WebGPU |
-
-### 6.2 What Igneum's finality-in-proof needs from the phone
-
-The client holds one proof and fetches the newest segment proof from any node (finality-in-proof.md 4.2); SP1's compressed verify is 0.032 s on a Mac core (bench-log 5 Oct), a Groth16 or Plonk wrapper is unmeasured. Model (a wallet updating every 10 minutes, 144 times a day, a phone big core at 3 W, LTE at about 1.5 J a MB, an 18 Wh battery):
-
-| Form the wallet verifies | Bytes a day | CPU | Radio | Battery a day |
-|---|---|---|---|---|
-| Groth16 or Plonk wrapper (about 1 KB with public values) at about 10 ms on a phone (approximate, 3x the Mac core) | 0.14 MB | 4 J | under 1 J | 0.007 percent |
-| Compressed STARK at the EF's 300 KiB ceiling, about 100 ms on a phone | 42 MB | 43 J | 63 J | 0.16 percent |
-
-Either is nothing. The choice is the EF's: no trusted setup and under 300 KiB, which is the STARK row, and by 2030 a WASM-SIMD or WebGPU verifier on a phone should put the STARK verify under 30 ms (approximate projection from the 294x STARK-verifier speedup reported in 2026 and the WebGPU adoption row). The 2026 answer is the Plonk wrapper (no trusted setup, small) for the phone and the compressed STARK for nodes. Bytes a day are set by update frequency, and a wallet that updates on open rather than on a timer is under 1 MB a day in either form.
-
-"Every miner is also a light-client server" has prior art: Bitcoin full nodes serving BIP-157 filters under the NODE_COMPACT_FILTERS service bit (every full node that opts in serves every light client), and Ethereum's Portal Network (every node serves a slice; "without having to trust or put extra strain on full nodes"). The anti-pattern is Zcash's lightwalletd, a few servers everyone trusts. Recommendation: the node serves `igneum_getSegmentProofBytes` over p2p and a rate-limited HTTP path, on by default in Ember, so the serving set is the miner set; the phone client dials three miners and takes the longest valid chain of proofs. Per tier: no cost a miner notices (one proof of a few hundred KB served on request); the pool node serves for its members; Windows, Linux, macOS, every vendor the same.
-
-## 7. Post-quantum signatures and a proof-of-work chain
-
-### 7.1 The standards and sizes
-
-| Scheme | Standard | Public key | Signature | Status | Source |
-|---|---|---|---|---|---|
-| ML-DSA-44 | FIPS 204 | 1,312 B | 2,420 B | final (Aug 2024) | Cloudflare 9 Jul 2026; FIPS 204 |
-| ML-DSA-65 | FIPS 204 | 1,952 B | 3,309 B | final | encryptionconsulting |
-| ML-DSA-87 | FIPS 204 | 2,592 B | 4,627 B | final | same |
-| SLH-DSA-SHA2-128s / 128f | FIPS 205 | 32 B | 7,856 B / 17,088 B | final | Cloudflare |
-| FN-DSA-512 (Falcon) | FIPS 206 | 897 B | 666 B | draft; final expected late 2026 to early 2027; floating-point signing is "difficult to implement securely" | encryptionconsulting; Cloudflare |
-| ML-KEM | FIPS 203 | n/a | n/a | final | NIST |
-| BLS12-381 (today) | n/a | 48 B | 48 B aggregate for 8,192 voters | quantum-broken by Shor on the curve's discrete log | ethereum.org PQ page |
-
-Timelines: NIST IR 8547 deprecates ECDSA, EdDSA, RSA and EC Diffie-Hellman after 2030 and disallows them after 2035 (final version confirmed). The Global Risk Institute's 2025 survey (26 experts, report page dated 9 Mar 2026): a cryptographically relevant quantum computer "quite possible (28 to 49 percent)" within 10 years and "likely (51 to 70 percent)" within 15. Resource estimates: ECC-256 at 1,200 to 1,450 logical qubits and 70 to 90 M Toffoli (Google, 2026), about 500,000 physical qubits against about 1 M for RSA-2048 (Gidney, May 2025); 835 logical qubits with 2^30.6 Toffoli (Luo et al., arXiv 2607.13816, Jul 2026). Bitcoin: BIP-360 merged into the BIPs repository 11 Feb 2026 as a draft (P2MR, formerly P2QRH), a companion BIP for ML-DSA and SLH-DSA, a testnet implementation March 2026, no activation. Ethereum: a PQ team formed January 2026; BLS to be replaced by leanXMSS (hash-based) with leanVM aggregating "3,000 bytes" of signature against BLS's 96 by "250x"; core PQ infrastructure targeted "by approximately 2029"; EIP-8141 account abstraction for user migration.
-
-### 7.2 What quantum does to Igneum
-
-| Component | Break | Consequence | Size of the fix |
-|---|---|---|---|
-| BLS vote keys (in every header) | Shor on BLS12-381's G1 discrete log (a 255-bit subgroup over a 381-bit field; wider than secp256k1, so a later break by a year or two, approximate) | every vote key is public; a CRQC forges two thirds of weight and certifies any chain. Catastrophic | the migration below |
-| Hash-to-curve | none; it is a hash | nothing | nothing |
-| ECDSA accounts in the EVM | as Ethereum: exposed public keys after a first spend | user funds; the same exposure as Ethereum's "0.1 percent dormant" row, smaller | account abstraction with an ML-DSA verify precompile from genesis |
-| The VRF (aggregator pick) | if EC-based, forgeable; aggregation is not safety (every voter signs) | liveness nuisance | the same key succession |
-| The class-group VDF (epoch seed, era draw) | Shor computes the class-group order, which removes the sequentiality assumption of a Wesolowski-style VDF (approximate; from memory of the class-group VDF literature) | an attacker with a CRQC grinds the hourly program seed | a hash-chain fallback behind the same version byte; flagged, not sized |
-| SP1 (STARK core, Groth16/Plonk wrapper) | the STARK is hash-based and stands; the pairing wrapper falls | the on-chain and phone verifier moves to the compressed STARK | the wrapper choice of section 6 |
-
-### 7.3 The cost in bytes, 8,192 voters, every voter signing every 30-second checkpoint (model)
-
-| Scheme | Per checkpoint | Per day (2,880 checkpoints) | Averaged per block at 1 block/s | Key in the header |
-|---|---|---|---|---|
-| BLS aggregate (today) | 1.0 KB (48 B + a 1,024 B bitmap) | 2.9 MB | 34 B | 48 B |
-| ML-DSA-44 | 19,361 KB | 57.1 GB | 645 KB | 1,312 B |
-| ML-DSA-65 | 26,473 KB | 78.1 GB | 882 KB | 1,952 B |
-| FN-DSA-512 | 5,329 KB | 15.7 GB | 178 KB | 897 B |
-| SLH-DSA-128s | 62,849 KB | 185 GB | 2,095 KB | 32 B |
-| SLH-DSA-128f | 136,705 KB | 403 GB | 4,557 KB | 32 B |
-| ML-DSA-44 aggregated by a SNARK at the EF's 250x | 77 KB | 223 MB | 2.6 KB | 1,312 B, or a 32 B hash of it |
-
-A naive ML-DSA swap costs 57 GB a day of votes against a block stream of about 100 MB a day (approximate), 500x. It is not shippable without aggregation. The aggregator already exists in the design (VRF picks 8 aggregators a checkpoint): the migration is "aggregators carry a STARK of N verified PQ signatures", which is Ethereum's leanVM shape, and the per-checkpoint cost falls to the order of 100 KB.
-
-### 7.4 The plan to pre-commit at genesis
-
-1. A `sig_scheme` version byte in the vote item and in the vote-key registration; genesis value 0 = BLS12-381.
-2. Key succession at registration: every vote key registers with a 32-byte hash of a successor public key (any scheme). A `succeed` item signed by the old key and the new key moves the 30-day weight to the successor without a reset. Miners generate the successor at first run; Ember stores it offline.
-3. A PQ verify precompile (ML-DSA-44 first, FN-DSA when FIPS 206 is final) in the EVM from genesis, so account abstraction can migrate users before 2030.
-4. The flip is a class change: 95 percent signal with a floor height, as the P2 mechanism; the aggregated-vote format ships first, the scheme flip second.
-5. The VDF carries the same version byte with a hash-chain fallback.
-6. The public sentence: "Igneum's vote keys and accounts can move to NIST post-quantum signatures by miner signal; the key succession is in every key from genesis."
-
-Per tier at migration: a home miner on any card runs the updater and signs one `succeed` item from Ember; ML-DSA-44 signing is well under a millisecond on any CPU (approximate), every 30 s; the bandwidth cost is the aggregated form's, about 100 KB a checkpoint, which an 8 GB card's host handles; a rig's one key succeeds once; a pool's key is the operator's, and pool members do nothing; Windows, Linux, macOS, NVIDIA, AMD, Apple: nothing hardware-specific, since the signature runs on the CPU.
-
-## 8. Regulation of mining and of coins with no issuer, 2026 to 2036
-
-### 8.1 The texts
-
-| Regime | What it says | Source |
-|---|---|---|
-| MiCA Article 4(3) | Title II (offers and white papers) does not apply where the crypto-asset is "automatically created as a reward for the maintenance of the distributed ledger or the validation of transactions" (point (b)); where there is no identifiable issuer "the obligation to produce a white paper does not apply to an issuer, as none exists"; a CASP that plays an active or promotional role may have to draw up one (Article 5 and the trading-platform duty under Title V) | Osborne Clarke (4 Oct 2023); Conventus Law; Squire Patton Boggs |
-| MiCA sustainability | Article 66 and Delegated Regulation 2025/422: CASPs publish the consensus mechanism's energy (kWh a year mandatory; more above 500,000 kWh); the Commission's Article 142 report may propose "minimum sustainability standards"; the 2026 review consultation (reply by 31 Aug 2026) asks only how appropriate the regime is (Q53) | the consultation PDF; carbon-ratings; Latham tracker |
-| MiCA transition | over on 1 Jul 2026; unlicensed service to EU clients is a breach | ESMA statement Apr 2026 |
-| UK | The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026: regulated activities from 25 Oct 2027 (issuing qualifying stablecoins, safeguarding, operating a qualifying cryptoasset trading platform, dealing, arranging, arranging staking); gateway and savings window 30 Sep 2026 to 28 Feb 2027; a "qualifying cryptoasset" is the FCA perimeter term (the formal definition sits in the Regulations and was not retrievable here); mining and validating are not in the activity list found; the 2023 financial-promotions regime already covers promotions of qualifying cryptoassets to UK consumers | FCA policy statements page; Lewis Silkin 30 Sep 2026; Skadden Jul 2026 |
-| US | SEC Corporation Finance staff statement 20 Mar 2025: PoW mining, solo or pooled, is not an offer of securities (non-binding, facts and circumstances); CLARITY (CFTC over digital commodities) failed cloture 49 to 50 on 15 Sep 2026, a motion to reconsider preserved; GENIUS Act 2025 covers payment stablecoins; DAME 30 percent excise proposed three times, never enacted | Dechert; Orrick 2 Oct 2026; Cointelegraph |
-| FATF | Recommendation 16 revised June 2025; implementation by end-2030; unhosted wallets still treated differently by country | FATF best practices Jun 2025; Sumsub |
-| DIFC (Igneum Labs LTD's seat) | DFSA crypto-token regime amended 12 Jan 2026: firm-led suitability, no more Recognised Crypto Tokens list, controller approval at 30 and 50 percent; applies to firms providing financial services in crypto tokens; nothing on mining or software | Dechert 13 Jan 2026; Arabian Business |
-| Dubai outside DIFC | VARA rulebook v2.1 (2026): exchange services, disclosures, token issuance; a federal licensing decision Feb 2026 | TradingView/Coinpedia; Dechert |
-
-### 8.2 What it means for each actor
-
-| Actor | EU | UK | US | DIFC | FATF |
-|---|---|---|---|---|---|
-| A pool operator paying members | not a CASP for mining; a CASP if it holds members' coins or exchanges them (custody, exchange); the energy figure is the CASPs' duty, not the pool's | not an activity listed, unless it safeguards or deals; from 25 Oct 2027 a pool that holds balances looks like safeguarding | SEC: pooled mining not a security; FinCEN money-transmitter guidance on pools is the open point (approximate) | not a financial service unless it custodies | a pool that holds and sends on behalf of members is a VASP-shaped entity by end-2030 |
-| A home miner selling coins | a seller, not an offeror; taxed as income then gains (country rules) | the same; promotions rules do not reach a private sale | income at receipt (IRS), then gains | n/a | the exchange it sells on carries the travel rule |
-| The entity publishing the software (Igneum Labs LTD) | no issuer under 4(3); the white paper is nobody's duty; publishing the 2025/422 indicators voluntarily lets CASPs list | not an activity; public text must not be a financial promotion of a qualifying cryptoasset to UK consumers (the 2023 regime), which rules out "buy", "invest" and price talk | the SEC statement covers mining, not the publisher; CLARITY's "mature blockchain" test is the thing to watch if it passes | a software company in the DIFC with no financial service and no token sale sits outside the DFSA token regime on its face | n/a |
-| The testnet with no value | nothing; no asset | nothing | nothing | nothing | nothing |
-| The external proving market paid in dollars | a job is a service; settlement in IGN on-chain with no operator custody is not a CASP activity; an operator that converts dollars to IGN is an exchange | the same; dealing or arranging if an operator sits between | money transmission if an operator holds funds | a dollar-settled service is a financial service only if the entity holds or exchanges | the same |
-
-### 8.3 What Igneum writes into its genesis and public text now (not legal advice)
-
-1. No issuer, no offeror, no sale: every coin is created as a block reward (MiCA Article 4(3)(b) language, verbatim in the litepaper).
-2. The 2025/422 sustainability indicators (kWh a year from hash rate and measured uJ, intensity per transaction, mix by region when known) published by the project each era, so an EU CASP can list without asking.
-3. No financial promotion: no price, no "buy", no "invest", no return language anywhere the UK can read it; the earnings page shows hash and IGN, not sterling.
-4. The pool reference implementation never holds a member's balance: payouts are direct from the coinbase split (the pool is a coordinator, not a custodian), which keeps pools out of CASP, safeguarding and VASP shapes in every regime above.
-5. The job market is peer-to-peer settled on-chain; no operator account, no dollar leg in the protocol; the dollar price is a quote, the settlement is IGN.
-6. The software is published under an open licence by a company that holds no coins by right (no dev fund, already decided) and runs no service the chain depends on.
-7. The region prompt and the banned-region list in Ember (Russia's ten regions and Moscow from 15 Aug 2026, China) with the sentence "mining may be restricted where you are; you are responsible for checking".
-8. A genesis "no privileged key" statement: no key can mint, pause or upgrade (true by design; say it because the regulators' tests turn on it).
-
-## 9. Ten-year scenario table
-
-| Year | Scenario A: GPUs stay general and cheap | Scenario B: HBM-only high end, APU-only low end | Scenario C: proving ASICs win |
-|---|---|---|---|
-| 2028 | 48 GB flagship on GDDR7 (lane 7); used H100s at USD 7,500 to 10,500 flood rentals; hash at the rental equilibrium, home share falling with the rent curve. Igneum: the N ladder's first rung by signal; home miners inside 2.5x of the chip per joule; the chip pays at USD 100 M of cap. Alive. The parameter: N stepped by signal | HBM4 only on datacentre parts; consumer GDDR7 unchanged; APUs (Medusa Halo, M6) take the laptop tier. Igneum: nothing changes for the hash; the Apple and APU tiers grow. Alive. The parameter: the cache rung, in case an APU's LLC reaches 256 MB | First VPU or C1 boards ship at 10 to 50x per joule on MSM and NTT; the external job market goes to them within a year. Igneum: the 20 percent pool is sortition by weight, so home cards keep it; the dollar market is lost to ASICs. Alive, with the external income line (already "never the main income" by 2030, lane 7 3.11) gone sooner. The switch: the shard deadline as a function of the fleet median |
-| 2031 | GDDR7-Next; 64 GB flagship; rental at 0.002 to 0.004 per MH/s-hour; hash 3 to 6x today's at the same price. The chip bar is USD 1.4 B at N5. Home miners on retail power are marginal unless the heat mode and the price prompt keep the UK and EU tiers on in winter. Alive; the home share is 10 to 20 percent (approximate). The parameter: the weight-aged reward rule (lane 7 3.1) | A consumer HBM4-class halo card appears (unannounced today): 2 to 4x the read rate of a 2026 card; the home 2026 cards fall to 0.25 to 0.5x of a new card, the GPU cadence twice over. The chip's stack-level edge is the same as the card's, so the per-joule gap closes to about 1.5x. Alive; the installed base shifts to the new card. The parameter: the N bind-point re-measurement per generation | Prover ASICs at 100x; the EF's L1 zkEVM runs on them; SP1-class software moves to ASIC backends. Igneum: proving in consensus verified, home cards prove shards inside the deadline because the deadline is the fleet's; the pool's 20 percent stays with weight. Alive. The risk: if a soundness bug in the ASIC's backend lands, the stop switch of 5.3 is the defence |
-| 2036 | 96 GB cards; rent at 0.0003 to 0.0013; hash 10 to 35x; the emission at the 1 percent tail (86 M IGN a year). Security is 1 percent of market cap a year (tail-emission.md). Igneum lives if the cap is over about USD 50 M (a 24-hour attack at 0.032 percent of cap is USD 16,000 against a rental market that can supply it); dies below that only in the sense every PoW chain does: cheap to attack, nothing to steal. The parameter: the tail | HBM everywhere above the laptop; the f = 1 chip and the halo card are the same memory; the ASIC question is closed by parity and the ladder's N is the remaining difference. Alive. The parameter: N at the verifier's 10 ms ceiling | Every proof is an ASIC proof; the pool pays miners for shards an ASIC proves 100x cheaper; miners buy ASIC prover boards the way they buy cards (USD 500 to 2,000 boards, approximate guess). Igneum: proving is a second card, not a second income. Alive. The parameter: the shard deadline rule |
-
-Where Igneum dies, honestly:
-
-| Death | Scenario | What would be needed to survive it |
-|---|---|---|
-| The stored-dataset chip at N5 is built at a USD 100 M cap in year 1 and holds over a third of hash by year 2 | A, 2028, if the N ladder is not at genesis or the signal never steps it | the N ladder at genesis with its first rung live; the weight-aged reward; the honest sentence that the chip's bar is USD 100 M, so the cap passes it fast or not at all |
-| Idle datacentre hash sets the rent and the home tier leaves; weight concentrates in three hosting firms; a hosting failure is a 30-day finality pause | A, 2031 | the LEAVE item (shipped), the reward rule that pays aged keys, the heat mode and price prompt that keep winter home miners on, and a public "weight by hosting provider" chart so the concentration is seen |
-| A CRQC in 2033 to 2036 (28 to 49 percent inside ten years, GRI) before the key succession has flipped | any, 2033+ | the genesis key succession and the aggregated-vote format shipped by 2030, the flip signalled the year NIST deprecates (2030), not the year a machine appears |
-| A soundness bug in the one proof system while the pool pays on the proof alone | C, any year | two zkVMs on the active list and the 1/3-weight stop switch |
-| The cap never passes USD 20 M: the tail's 1 percent is USD 200,000 a year of security, a day's rental | all, any year | nothing in the protocol; it is the market's verdict, and the design should say so rather than promise a floor |
-
-## 10. Verdict table
-
-| Axis | Finding | Source | Per-tier consequence | Recommendation |
-|---|---|---|---|---|
-| Memory roadmap | tRC flat for about 20 years; HBM4 doubles channels a stack (2026); HBM4E adds pins and a custom base die (2027 to 2028); no consumer HBM, no GDDR8 before 2029 to 2031 | JEDEC, SK hynix roadmap, Lee et al. | a 2026 card keeps its read rate against a 2028 card; 8 and 12 GB leave the installed base by 2030, not the hash | nothing at genesis; re-measure the N rungs per generation (text, a measurement duty) |
-| The cache | consumer LLC 96 to 128 MB; datacentre 256 MB today | chip-model-v3, MI300X (approximate) | an LLC at the cache size gives that card's owners a 2 to 3x shortcut | a cache-size rung on the signal ladder (genesis parameter) |
-| The dataset | 2 GiB to 16 GiB over 28 years is under every card and never binds before year 12 | algorithm.md 5.6 | the prover footprint binds first | nothing; fix the public card-lifetime sentence (text) |
-| The chip's bar | pays at USD 17 M of cap bare, USD 100 M with the N5 shadow core in years 1 to 2, 2.3x higher every two years with the glide; never needs N2 or A16 | model, siliconanalysts mask costs | the 9070 XT tier is displaced first, Apple never per joule, the 5090 inside 2.5x | the N ladder at genesis (parameter); the p* sentence in the threat model (text) |
-| C-HBM4E | the memory controller moves under the stack from 2027 to 2028 | TSMC/GUC via Tom's | the chip's dollars per MH/s fall under USD 2.8 by 2028 (approximate) | disagreement with lane 7 row 2.3 recorded; no new parameter, N covers it |
-| Used-GPU flood | 15 to 20 M datacentre GPUs installed by end-2026; residual 25 to 35 percent at 60 months; an H100 mines at 0.65x to 3x a 5090, unmeasured | TechInsights, Omdia, mercatus | 1 percent of a retired fleet is 2 to 35x the equilibrium hash | measure an H100 and an A100 this month (measurement); the reward rule (parameter, lane 7 3.1) |
-| Rental curve | 0.0117 to 0.0003 to 0.0013 per MH/s-hour by 2036 | model on cloudzero's H100 history | attack dollars unchanged at equilibrium; home share falls 10 to 35x | re-price 51-percent.md from a measured rental yearly (text); the cost-vs-rent line on the earnings page (software) |
-| Energy | UK 26.3 p, EU 29 c average, US 17.7 c; heat credit is a third off in the heating season; ERCOT pays industrial curtailment, not homes | Ofgem, Eurostat, EIA, ABC13 | retail-power tiers (UK, DE) are 5 to 9x the industrial price even with heat credited | heat mode, curtailment input, per-region price prompt (software); 2025/422 indicators published (text) |
-| Mining rules | Norway (new sites), Sweden (tax), Russia (regions and Moscow), China (illegal), Kazakhstan and Paraguay (licensed, tariffed); US SEC: mining is not a securities offer | the table in 4.4 | a home miner's risk is regional | the region prompt and banned list in Ember (software) |
-| Proving cost | USD 1.69 to about 0.005 a block in 20 months; four teams at sub-10 s; EF's 2026 metric is kWh a proof; no prover ASIC has shipped a block benchmark | ethproofs, EF, Cysic | a 12 GB card proves alone under 10 s at every rate; beside its miner only at 3x a year | the shard deadline as a function of the measured fleet median (parameter); two zkVMs and the 1/3 stop switch (switch) |
-| Proof-system risk | three soundness-class events in 18 months across SP1 and RISC Zero | LambdaClass, HackenProof, EF | none for miners today; a chain failure only if a proof ever replaces execution for full nodes | never let it (text in spec 10.1); the active-list and stop switch (switch) |
-| Light clients | 25 KB per two days (Ethereum), 22 KB (Mina), a 1 MB STARK in under 100 ms on a phone (StarkWare); a verifying Igneum wallet costs under 0.2 percent of a day's battery | a16z, Mina, cryptotimes, model | nothing a miner notices; every miner serves proofs | serve the segment proof from every node by default (software); the Plonk wrapper for phones, the STARK for nodes (parameter) |
-| Post-quantum | ML-DSA-44 2,420 B signatures; 57 GB a day of naive votes at 8,192 voters, 223 MB with 250x aggregation; CRQC 28 to 49 percent within ten years; NIST deprecates 2030 | FIPS 204, Cloudflare, GRI, NIST IR 8547, model | a miner signs one succession item at migration; nothing hardware-specific | the sig_scheme byte, the key succession, the PQ precompile, the VDF fallback at genesis (parameters); the aggregated-vote format by 2030 (switch) |
-| Regulation of a no-issuer coin | MiCA 4(3)(b) exempts block-reward assets; UK regulates platforms, dealing, custody, staking from 25 Oct 2027, not mining; SEC mining statement; CLARITY stalled; FATF by 2030 | the texts in 8.1 | a pool must not custody; a miner selling is a seller; the publisher is nobody's issuer | the eight-item list of 8.3 (text); the non-custodial pool reference (software) |
-| Scenarios | alive in every 2028 and 2031 cell with one parameter each; dies on an unstepped N ladder, on concentration after the home tier leaves, on a late PQ flip, on a single proof system, or on a cap under about USD 20 M | section 9 | the home tiers are the ones each death removes first | the five "needed to survive" rows of section 9 |
-
-## 11. Three headline findings for the coordinator
-
-1. A stored-dataset chip with the class v4 shadow core pays for itself at about USD 100 M of market cap in Igneum's first two years and about USD 700 M in years 5 to 6 (30 percent share, USD 30 M project, model), and it never needs a node below 28 nm plus N5, so the N ladder at genesis is the only lever and C-HBM4E (2027 to 2028) moves the chip's controller under the memory and cuts its dollar cost further.
-2. Ten years of rental deflation (USD 0.0117 to 0.0003 to 0.0013 per MH/s-hour by 2036) leaves every 51-percent dollar figure unchanged at the equilibrium and cuts the home card's share of the subsidy 10 to 35x; the day an idle datacentre card on 5 c power sets the rent, a UK home miner at 26.3 p loses 7x on electricity, and the heat mode buys back a third, not the gap.
-3. A post-quantum vote at 8,192 voters costs 57 GB a day in naive ML-DSA-44 (19.4 MB a checkpoint) and about 223 MB a day with 250x SNARK aggregation, against a 28 to 49 percent chance of a cryptographically relevant quantum computer inside ten years (GRI 2025) and NIST deprecation after 2030, so the key-succession item, the scheme byte and the aggregated-vote format belong at genesis and the flip belongs in 2030.
-
-File: `/Users/joshm/Projects/igneum-wt-mission/docs/analysis/mission/future.md`.
-
-## Sources (accessed 7 October 2026 unless dated otherwise)
-
-Lane and repository inputs: `docs/analysis/horizon/frontier.md` (lane 7), `docs/analysis/horizon/algorithm.md` (lane 2), `docs/analysis/chip-model-v3.md`, `docs/analysis/51-percent.md`, `docs/bench-log.md` ("Rental cost of hash, 6 October 2026"), `horizon-2026-10.md`, `finality-in-proof.md`, `tail-emission.md`, `vote-or-burn.md`, `prover-tiers-real-cards.md`.
-
-Memory and GPUs:
-- TrendForce, NVIDIA fuels HBM4 race, 9 Jan 2026: https://www.trendforce.com/news/2026/01/09/news-nvidia-demand-fuels-hbm4-race-12-layer-ramps-16-layer-push-by-sk-hynix-samsung-and-micron/
-- EE Times, The state of HBM4 at CES 2026: https://www.eetimes.com/the-state-of-hbm4-chronicled-at-ces-2026/
-- Astute Group, SK hynix 62 percent of HBM: https://www.astutegroup.com/news/general/sk-hynix-holds-62-of-hbm-micron-overtakes-samsung-2026-battle-pivots-to-hbm4/
-- siliconanalysts HBM pricing: https://siliconanalysts.com/tools/hbm-analysis
-- TrendForce, Micron HBM4E 2027 to 2028, 23 Dec 2024: https://www.trendforce.com/news/2024/12/23/news-micron-plans-hbm4-mass-production-in-2026-customized-hbm4e-to-launch-in-2027-2028/
-- Tom's Hardware, TSMC and GUC HBM4E and C-HBM4E: https://www.tomshardware.com/pc-components/dram/hbm-undergoes-major-architectural-shakeup-as-tsmc-and-guc-detail-hbm4-hbm4e-and-c-hbm4e-3nm-base-dies-to-enable-2-5x-performance-boost-with-speeds-of-up-to-12-8gt-s-by-2027
-- TechTimes, Samsung HBM4E samples, 30 May 2026: https://www.techtimes.com/articles/317400/20260530/samsung-ships-industry-first-hbm4e-samples-36-tb-s-bandwidth-beats-sk-hynix-six-months.htm
-- Tom's Hardware, SK hynix roadmap to 2031: https://www.tomshardware.com/pc-components/dram/sk-hynix-reveals-dram-development-roadmap-through-2031-ddr6-gddr8-lpddr6-and-3d-dram-incoming
-- TechSpot, GDDR7 successor after 2028: https://www.techspot.com/news/110151-sk-hynix-expects-launch-ddr6-gddr7-successor-after.html
-- TweakTown, RTX 60 Rubin GR20x: https://www.tweaktown.com/news/109619/next-gen-geforce-rtx-60-gpus-rumored-to-use-rubin-gr20x-family-gearing-up-for-2027-release/index.html
-- wccftech, RTX 60 2028 launch rumour: https://wccftech.com/nvidia-rtx-60-2028-launch-rumor/
-- wccftech, 4 GB and 6 GB GDDR7: https://wccftech.com/4-gb-and-6-gb-gddr7-memory-chips-will-be-rolled-out-in-the-next-two-years/
-- TechPowerUp, UDNA 96 CUs: https://www.techpowerup.com/339101/amds-upcoming-udna-rdna-5-gpu-could-feature-96-cus-and-384-bit-memory-bus
-- TweakTown, RDNA 5 mid-2027: https://www.tweaktown.com/news/112289/amds-rdna-5-radeon-gpus-will-launch-in-mid-2027-per-new-leak/index.html
-- Tom's Hardware, AMD GDDR7 driver support: https://www.tomshardware.com/pc-components/gpus/amd-begins-to-add-gddr7-support-to-its-linux-gpu-drivers-changes-could-herald-use-of-advanced-memory-standard-with-next-gen-radeon-gpus
-- VideoCardz, Medusa Halo LPDDR6: https://videocardz.com/newz/amd-ryzen-max-500-medusa-halo-rumored-to-support-lpddr6-memory
-- Apple, M5 Pro and M5 Max, 3 Mar 2026: https://www.apple.com/newsroom/2026/03/apple-debuts-m5-pro-and-m5-max-to-supercharge-the-most-demanding-pro-workflows/
-- Apple, Mac Studio M5 Max and M5 Ultra, Aug 2026: https://www.apple.com/newsroom/2026/08/apple-introduces-new-mac-studio-with-m5-max-and-m5-ultra/
-- JEDEC LPDDR6 press release: https://www.jedec.org/news/pressreleases/jedec%C2%AE-releases-new-lpddr6-standard-enhance-mobile-and-ai-memory-performance
-- JEDEC DDR5 JESD79-5D: https://www.jedec.org/standards-documents/docs/jesd79-5d
-- Lee et al., Reducing DRAM latency at low cost (latency stagnation): https://arxiv.org/pdf/1604.08041
-- Chang et al., Flexible-latency DRAM: https://arxiv.org/pdf/1805.03154
-- Wikipedia, Feynman microarchitecture: https://en.wikipedia.org/wiki/Feynman_(microarchitecture)
-
-Chip costs:
-- siliconanalysts wafer and mask pricing (Sep 2026): https://siliconanalysts.com/data/wafer-pricing
-- siliconanalysts tapeout cost guide, 1 Mar 2026: https://siliconanalysts.com/analysis/fabless-startup-tapeout-cost-guide
-- siliconanalysts TSMC 3 nm cost: https://siliconanalysts.com/guide/tsmc-3nm-cost
-- SemiWiki, TSMC A14: https://semiwiki.com/forum/threads/tsmc-a14-at-2026-dec-iedm.25920/
-
-GPU supply and rental:
-- HPCwire, TechInsights 3.76 M datacentre GPUs 2023, 10 Jun 2024: https://www.hpcwire.com/2024/06/10/nvidia-shipped-3-76-million-data-center-gpus-in-2023-according-to-study/
-- Omdia, AI data centre chip market, Aug 2025: https://omdia.tech.informa.com/pr/2025/aug/ai-data-center-chip-market-to-hit-286bn-growth-likely-peaking-as-custom-asics-gain-ground
-- Tom's Hardware, Blackwell cabinet forecasts halved: https://www.tomshardware.com/tech-industry/artificial-intelligence/analysts-halve-nvidia-gb200-blackwell-shipment-forecasts-for-2025-prediction-contrasts-ai-boom
-- Jon Peddie Research, Q2 2026 AIB shipments: https://www.jonpeddie.com/news/q226-pc-graphics-aib-shipments-increased-10-from-last-quarter-to-12-million-units/
-- mercatus-ai, H100 resale value (23 Jun 2026): https://www.mercatus-ai.com/blog/h100-resale-value
-- intuitionlabs, used AI GPU prices 2026: https://intuitionlabs.ai/articles/used-ai-gpu-prices-resale-trends
-- cloudzero, H100 price 2026: https://www.cloudzero.com/blog/h100-gpu-cost/
-- spheron, GPU cloud pricing 2026: https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/
-
-Energy, heat, mining rules:
-- Ofgem price cap: https://www.ofgem.gov.uk/your-energy-supply/your-energy-bill/energy-price-cap-unit-rates-and-standing-charges
-- Eurostat, household electricity prices H2 2025, 5 May 2026: https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20260505-1
-- EIA, US electricity prices: https://www.eia.gov/todayinenergy/detail.php?id=65284
-- EIA AEO2025 via The Energy Coop: https://theenergy.coop/blog/unpacking-2025-aeo/
-- Cornwall Insight via Solar Power Portal, 10 Jan 2024: https://www.solarpowerportal.co.uk/energy-policy/cornwall-insight-forecasts-lower-gb-power-prices-on-the-long-road-to-truly-affordable-energy-
-- spark.money, mining profitability by country: https://www.spark.money/tools/bitcoin-mining-profitability-by-country
-- Hashrate Index, Paraguay 2026 (4 May 2026): https://hashrateindex.com/blog/the-state-of-bitcoin-mining-in-paraguay-2026-2/
-- miningboard, bitcoin heaters 2026: https://miningboard.com/guides/bitcoin-heaters
-- techbuzz on Wired's Heatbit review, 5 Apr 2026: https://www.techbuzz.ai/articles/heatbit-s-bitcoin-mining-heater-fails-the-math-test
-- Qarnot (French Wikipedia): https://fr.wikipedia.org/wiki/Qarnot
-- ABC13, ERCOT paid Riot USD 31.7 M: https://abc13.com/post/ercot-texas-power-grid-riot-bitcoin-miners/13753300/
-- Riot June 2025 update: https://www.globenewswire.com/news-release/2025/07/03/3109856/0/en/Riot-Announces-June-2025-Production-and-Operations-Updates.html
-- CoinDesk, Norway ban, 23 Jun 2025: https://www.coindesk.com/tech/2025/06/23/norway-plans-ban-on-new-crypto-mining-data-centers-to-preserve-power
-- CoinDesk, Sweden tax, 14 Apr 2023: https://www.coindesk.com/policy/2023/04/14/sweden-drives-final-nail-into-its-bitcoin-mining-industry-with-tax-hike
-- crypto.news, Sweden back-tax: https://crypto.news/sweden-orders-six-crypto-firms-to-pay-56m-in-additional-taxes/
-- TASS, Moscow mining ban: https://tass.com/politics/2152151
-- Cryptopolitan, Russia regions: https://www.cryptopolitan.com/russia-regional-crypto-mining-ban-2025/
-- Caspian News, Kazakhstan lifts restrictions, 17 Nov 2025: https://caspiannews.com/news-detail/kazakhstan-lifts-restrictions-on-cryptocurrency-mining-trading-2025-11-17-36/
-- KuCoin, Kazakhstan strategic mining from 1 Aug 2026: https://www.kucoin.com/news/flash/kazakhstan-to-enforce-strategic-crypto-mining-rules-from-august-1
-- Lightspark, China 2026: https://www.lightspark.com/knowledge/is-crypto-legal-in-china
-- egw.news, China provinces (uncorroborated): https://egw.news/crypto/news/30440/china-officially-brings-back-mining-sichuan-inner--NnyU95QrT
-- ainfp, Iran mining 2026: https://ainfp.org/mining-crypto-in-iran-legal-status-restrictions-risks
-- Dechert, SEC PoW mining statement, Mar 2025: https://www.dechert.com/knowledge/onpoint/2025/3/sec-staff-issues-statement-on-proof-of-work-crypto-mining-activi.html
-- Fortune, EIA survey backlash, 1 Mar 2024: https://fortune.com/crypto/2024/03/01/department-energy-survey-bitcoin-miners-legal-backlash/
-- Cointelegraph, DAME tax revived: https://cointelegraph.com/news/crypto-mining-tax-united-states-budget
-- sazmining, US state mining laws 2026: https://www.sazmining.com/blog/us-crypto-mining-rules-review
-
-Proving:
-- EF, Realtime proving, 10 Jul 2025: https://blog.ethereum.org/2025/07/10/realtime-proving
-- Ethproofs 2025 review, 6 Dec 2025: https://hackmd.io/@willcorcoran/S1A840ZMZg
-- Succinct, SP1 Hypercube on mainnet: https://blog.succinct.xyz/sp1-hypercube-is-now-live-on-mainnet/
-- bex.co, Cysic Venus, 17 Apr 2026: https://bex.co/blog/2026/04/17/cysic-venus-multi-gpu-zk-proving-real-time-verification-bottleneck
-- bex.co, Airbender, 30 Jan 2026: https://bex.co/blog/2026/01/30/zksync-airbender-fastest-risc-v-zkvm-ethereum-proving
-- GitHub comparative analysis, Sep 2026: https://github.com/Ricosworks1/blockchain-payment-flow-analysis/releases/tag/comparative-analysis-ethereum-zk-proving-race-sept-2026
-- cryptobriefing, Lattice Jolt, 9 Sep 2026: https://cryptobriefing.com/lattice-jolt-post-quantum-zkvm/
-- RISC Zero, R0VM 2.0: https://risczero.com/blog/introducing-R0VM-2.0
-- h33.ai, ZK proof companies 2026: https://h33.ai/blog/zk-companies/
-- Cysic ZK ASIC docs: https://docs.cysic.xyz/hardware-products/zk-asic-products/
-- Ingonyama and Accseal: https://www.ingonyama.com/oldblogs/partnership-announcement-accseal-x-ingonyama
-- LambdaClass, SP1 exploit disclosure, 26 Jan 2025: https://blog.lambdaclass.com/responsible-disclosure-of-an-exploit-in-succincts-sp1-zkvm-found-in-partnership-with-3mi-labs-and-aligned-which-arises-from-the-interaction-of-two-distinct-security-vulnerabilities/
-- Blockworks, SP1 bug: https://blockworks.co/news/succinct-sp1-bug
-- HackenProof, RISC Zero missing constraint, May 2025: https://hackenproof.com/blog/for-hackers/risc-zero-zkvm-missing-constraint-vulnerability
-- EF, On formal verification and a bug in SP1 Hypercube, 20 May 2026: https://zkevm.ethereum.foundation/blog/sp1-fv
-
-Light clients:
-- a16z Helios: https://github.com/a16z/helios and https://a16zcrypto.com/posts/article/building-helios-ethereum-light-client/
-- Ethereum annotated spec, sync protocol: https://github.com/ethereum/annotated-spec/blob/master/altair/sync-protocol.md
-- Portal Network: https://ethportal.net/overview
-- Mina 22 KB: https://www.gate.com/learn/articles/what-is-mina-protocol/4814
-- Celestia Lumina: https://github.com/celestiaorg/lumina
-- Lightning Labs Neutrino: https://github.com/lightninglabs/neutrino
-- Blixt features: https://blixtwallet.github.io/features
-- StarkWare 1 MB Bitcoin verifier, 11 Sep 2025: https://www.cryptotimes.io/2025/09/11/starkware-unveils-1mb-bitcoin-verifier-for-mobile-devices/
-- Mopro benchmarks: https://zkmopro.org/docs/0.2/performance/ and https://hackmd.io/@vivi432/mopro-benchmark
-- provebench: https://github.com/agnij-dutta/provebench
-- shattered.io, STARK 45 KB verify: https://shattered.io/bulletproofs-vs-zk-starks-2026/
-- Wikipedia WebGPU: https://en.wikipedia.org/wiki/WebGPU
-- Zcash Tachyon-Lite grant: https://forum.zcashcommunity.com/t/grant-proposal-tachyon-lite-light-client-sdk-and-sync-proof-server-for-zcash/55671
-
-Post-quantum:
-- Cloudflare, ML-DSA will have to do, 9 Jul 2026: https://blog.cloudflare.com/ml-dsa-will-have-to-do/
-- encryptionconsulting, FN-DSA FIPS 206: https://www.encryptionconsulting.com/education-center/fn-dsa-fips-206/
-- encryptionconsulting, NIST IR 8547 deadlines: https://www.encryptionconsulting.com/nist-ir-8547-2030-2035-action-plan/
-- NIST PQC standardisation: https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization
-- Global Risk Institute, Quantum Threat Timeline Report 2025: https://globalriskinstitute.org/publication/quantum-threat-timeline-report-2025b/
-- postquantum.com, Google ECDLP resources: https://postquantum.com/security-pqc/google-quantum-bitcoin-ecdlp/
-- postquantum.com, 835 logical qubits (arXiv 2607.13816): https://postquantum.com/security-pqc/ecc-secp256k1-835-logical-qubits/
-- arXiv, Brace for impact (ECDLP challenges): https://arxiv.org/pdf/2508.14011
-- ethereum.org, post-quantum cryptography: https://ethereum.org/roadmap/security/quantum-resistance/
-- The Quantum Insider, EF PQ team, 26 Jan 2026: https://thequantuminsider.com/2026/01/26/ethereum-foundation-elevates-post-quantum-security-to-top-strategic-priority/
-- The Quantum Insider, BIP-360 testnet, 20 Mar 2026: https://thequantuminsider.com/2026/03/20/btq-technologies-implements-bip-360-quantum-resistant-bitcoin-transactions-testnet/
-- qsha256, BIP-360 and BIP-361: https://qsha256.com/blog/bitcoin-pq-migration
-
-Regulation:
-- Osborne Clarke, MiCAR white papers and Bitcoin, 4 Oct 2023: https://www.osborneclarke.com/insights/what-are-eus-white-paper-requirements-micar-and-do-they-apply-bitcoin
-- Conventus Law, crypto-assets without an identifiable issuer: https://conventuslaw.com/report/crypto-assets-without-an-identifiable-issuer-regulatory-reality-two-years-post-micar-application-date/
-- Latham, MiCA white paper and sustainability disclosures: https://www.lw.com/en/markets-in-crypto-assets-regulation-tracker/mica-white-paper-sustainability-disclosures
-- carbon-ratings, MiCA sustainability indicator methods: https://carbon-ratings.com/dl/whitepaper-mica-methods-2024
-- European Commission, 2026 MiCA review targeted consultation (reply by 31 Aug 2026): https://finance.ec.europa.eu/document/download/62be7015-f066-4fac-b74e-71bacdbcc9f5_en?filename=2026-mica-review-targeted-consultation-document_en.pdf
-- ESMA, end of MiCA transitional periods, Apr 2026: https://www.esma.europa.eu/sites/default/files/2026-04/ESMA75-113276571-1679_Statement_on_the_end_of_transitional_periods_under_MiCA.pdf
-- FCA, cryptoasset regime policy statements: https://www.fca.org.uk/publications/policy-statements/cryptoasset-regime
-- Lewis Silkin, UK draft Regulations and perimeter guidance, 30 Sep 2026: https://www.lewissilkin.com/insights/2026/09/30/uk-cryptoasset-regime-draft-regulations-and-fca-perimeter-guidance-provide-furth-102o3vf
-- Skadden, FCA finalises core rules, Jul 2026: https://www.skadden.com/insights/publications/2026/07/fca-finalises-core-rules-for-the-uk-cryptoasset-regime
-- Orrick, CLARITY stalls, 2 Oct 2026: https://www.orrick.com/en/Insights/2026/10/The-CLARITY-Act-Stalls-in-the-Senate-Whats-Next-for-Digital-Asset-Regulation
-- FATF, travel rule supervision best practices, Jun 2025: https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/Best-Practices-Travel-Rule-Supervision.pdf
-- Sumsub, FATF Recommendation 16 revision: https://sumsub.com/media/spotlight/same-rule-same-problems-will-fatf-travel-rule-fix-the-divide/
-- Dechert, DFSA crypto token regime, 13 Jan 2026: https://www.dechert.com/knowledge/onpoint/2026/1/dubai-updates-crypto-token-regulatory-framework.html
-- TradingView/Coinpedia, UAE and VARA 2026: https://www.tradingview.com/news/coinpedia:681009ff8094b:0-crypto-regulations-in-uae-dubai-in-2026/

docs/analysis/mission/invent.md

@@ -1,528 +0,0 @@
-# The last mission, lane 4: what can be invented, judged hard
-
-7 October 2026, morning UK. Lane 4 of the final research programme ("the last mission"), worktree `igneum-wt-mission`. The question: given everything Igneum already has (the horizon one page, the frontier lane's sixteen ideas, the new-PoW lane's three schemes, class v5, finality in the proof, work-stake, the tail, vote-or-burn, the ladder, the pool design, the light client, the phone app), what is the NEXT genuinely new thing a GPU chain could do that none has. Every candidate here was checked against prior art by name and year, run through its own game theory with a model this lane ran (`invent_model.py`, section 0), reviewed in the Monero or Kaspa developer's voice, priced in agent hours with a first gate, and given its per-tier consequence and four persona verdicts. Nothing here touches the devnet. No em dashes. Figures from memory say approximate; figures from a source name it.
-
-The founder's rulings are applied as a filter before any idea is scored: miners are the security always; no stake and no coin bond; no holder penalised; no device bounty; no fixed-height activations; no calendar dates; no reliance on another chain; no dev fund; no privacy; nothing that becomes a token sale; the lottery and the proving stay separate; emission carries security with no end date. An idea that needs one of these is marked dead in one line.
-
-## 0. Progress, method and the four voices
-
-| Time (UK) | State |
-|---|---|
-| 08:05 | Lane started; read CLAUDE.md, the horizon one page (sections 1 to 3), frontier.md (sections 0 and 3, all sixteen), new-pow.md (3, 4, 6, 7), class-v5-stored-state.md, finality-in-proof.md, work-stake.md, tail-emission.md (one page), vote-or-burn.md, latency-ladder.md, 51-percent.md, pool.md, spec 09, spec 10, phone-app.md, the four persona files, bench-log (rental cost, warp verify, aggregation, 5090 rows) |
-| 08:35 | Prior art checked by WebFetch on primary pages (the session's WebSearch budget was already spent; every page that answered is in the sources list; four pages 404'd and those items are labelled approximate) |
-| 08:51 | `invent_model.py` written and run in the lane's scratch (`mission-invent/out.md`); every table below marked "model" is printed by it |
-| 08:59 | This file written (528 lines, 0 em dashes, not staged); final message to the coordinator |
-
-**Method.** Three passes per candidate. (1) Prior art: the paper, project or repository that did it, with the year, and the one sentence of what differs. (2) Game theory: who gains from cheating, the attack, its cost, the bound; a short numeric model actually run. (3) The hostile review in the Monero or Kaspa developer's voice, then the prototype cost in agent hours, the first measurable gate, the per-tier consequence (home miner 8 / 12 / 16 / 24 to 32 GB, rig, pool user; Windows, Linux, macOS; NVIDIA, AMD, Apple) and four persona verdicts: do now, prototype, watch, never.
-
-**The four voices.** The cryptographer, the consensus engineer and the miner (the miner-community lead) are the persona files in `.claude/agents/`. The fourth, the economist, is defined here from the economy lane's method (`docs/analysis/horizon/economy-and-utility.md`, `tail-emission.md`): every number is priced in rented hash at the measured USD 0.0117 per MH/s-hour (bench-log, "Rental cost of hash", 6 October 2026); an IGN price is an input never a prediction, shown at USD 0.005, 0.02 and 0.10; fees are never assumed to be the security budget; a mechanism that moves income is judged by who pays, who is paid, and whether the payer would rather leave; the per-tier consequence is stated before anyone asks.
-
-**Price basis used throughout.** Subsidy 100 IGN a block at one block a second (the tail-emission recommendation; today's code pays 31.688). Rented hash USD 11.7 per GH/s-hour. CPU verify of one 32-lane unit: 0.441 ms class v3 steady (bench-log line 170), 5.06 ms class v4 cold on the box's core (horizon L2), 1.35 ms per pool share check in isolation (pool.md section 5); the gate is 10 ms. Header 400 B working figure (spec 10.9). Snapshot 114.8 MB (horizon rank 22). Groth16 proof 260 B (SP1 docs), public values with the finality extension 494 B (finality-in-proof section 1).
-
-**What the measurement budget did not allow.** Nothing in this lane needed the box or a GPU pod to reach a verdict; where a first gate needs one, the gate names the command and the expected number and the final message lists it for the coordinator.
-
----
-
-## 1. Hashing useful to the chain itself, without reopening the useful-work trap
-
-The trap, restated from new-pow section 3.1 and frontier 3.10: a lottery needs a sampleable puzzle with a cheap verifier; any coupling of the puzzle to a scarce skill hands the lottery to the best at that skill (Aleo). The four variants below avoid the trap by keeping the hash kernel byte for byte as shipped and changing only what a miner must HOLD or must have DONE to build the dataset or to be paid. That is class v5's shape (new-pow scheme C: hash rate 63.083 against 63.088 MH/s on the 4090, build +1.4 ms, verifier +0.11 to 0.21 ms per unit), so the question for each is only: what does it add to class v5 that is measurable, and does the addition survive its own game.
-
-### 1.1 What class v5 already delivers, so nothing below re-invents it
-
-| Property | Delivered by class v5 | Where |
-|---|---|---|
-| Every mining operation holds the day's execution state | yes, by construction: `leaf(t) = D[t mod n]` keys every item; a stateless hasher is wrong on every item (the known-failed case) | class-v5 section 3, 4 |
-| Every block names 128 random state leaves per lane any full node can open against `R_d` | yes; the opening RPC is new-pow rank 6 (4 hours, not built) | new-pow 3.3, 7 |
-| The miner must know the chain to within the epoch lead | yes, already since class v3: the program is the 10-minute VDF of a certified checkpoint 20 minutes before the epoch (spec 04 4.3); a miner without the last hour of chain has the wrong program and every hash is wrong | spec 04 |
-| The f = 0 recompute chip must hold the state | yes | new-pow 6 |
-| The pool caveat | stated: a pool ships `D` once a day (6 KB today, 1 to 2 GiB on a used chain) | class-v5 section 3 |
-
-### 1.2 (a) Proof of following: the day's leaves include the last N blocks
-
-**The idea.** Widen class v5 so that the dataset derives from the state AND from the chain's recent blocks: the day's leaf array gains the hashes or receipts of the last N chain blocks before the cut, so a miner proves it relayed or held recent blocks, not only the state.
-
-**Prior art.** Verthash (Vertcoin, January 2021, approximate: the vertcoin.org page 404'd this morning): a 1.2 GB dataset built from the chain's own block headers, random reads per hash. Ethash (2015): dataset from the epoch seed. Class v5 (this project, 7 October 2026): dataset from the execution state. Permacoin (Miller, Juels, Shi, Parno, Katz, IEEE S&P 2014): proof of retrievability of a dealer's file. The combination "state plus recent headers" is new in form; Verthash is the nearest in substance.
-
-**Mechanism.**
-
-| Item | Rule |
-|---|---|
-| Extra leaves | after the state records, one record per chain block in `(daa(C_d) - N, daa(C_d)]`: `0x04 ‖ block_hash ‖ state_root ‖ receipts_root` |
-| Keyed by | `R_d` as every other leaf; the day's cut `C_d` is one hour before the day (class-v5 section 2) |
-| What it forces | a builder must hold the last N headers and receipt roots before the cut |
-| What class v5 forces already | the whole state after `C_d`, which commits to every one of those blocks through `R_d` |
-
-**Game theory.** Nobody gains from cheating because there is nothing to cheat: the state root already commits to the chain. The only question is what a miner must HOLD. Under class v5 a miner holds `D` (the state sample); under 1.2 it also holds N header records it can fetch from any peer in one round trip. Model (section A of `invent_model.py`, the outsourcing row): a key with nothing answers a fetch in about 108 ms over a 100 ms link. The addition forces no holding that a pool's daily delivery does not already satisfy, and the "following" it proves is the following the epoch seed proves every hour at zero cost.
-
-**What is measurable.** Nothing new per block. The receipts are a function of the state transition every executing node already computed; the day's cut already requires the chain to within an hour; the epoch seed requires it to within 80 minutes. The one measurable thing would be a per-block dataset change, and a per-block build is 32 ms on a 4090 (class-v5 section 2) against a 1,000 ms block: a 3.2 percent hash loss on every card every second for a property the program swap gives every hour for free.
-
-**Hostile review (Kaspa voice).** "You have a dataset keyed by a state root that is itself a function of every block in the chain's past. Adding the last N block hashes as leaves adds information the root already carries. If you want 'following', the program swap is your following: a miner that is an hour behind has the wrong kernel. Do not add bytes to a build that already proves the thing."
-
-**Cost and gate.** 0 hours: not built. If someone insists: the gate is the fast-time harness showing a stateful miner with stale headers is refused, which the state root already does.
-
-**Per tier.** No change for any card, rig or pool user; the verifier's RAM unchanged.
-
-**Verdicts.** Cryptographer: never (the root commits to the chain; redundant). Consensus engineer: never (bytes for nothing). The miner: never (nothing to see). Economist: never (no income moves). Verdict: never, with the sentence "proof of following is the epoch seed plus class v5" written into class-v5's litepaper paragraph.
-
-### 1.3 (b) Proof of serving: a reward component for serving headers, snapshots and proofs
-
-**The idea.** A slice of the producer's 80 points is paid only to keys that served data to peers in the window, verified by challenge-response sampled into blocks.
-
-**Prior art.** Filecoin WindowPoSt (2020; spec.filecoin.io: 48 deadlines of 30 minutes a day, randomness from a beacon 20 epochs before the deadline, fee debt on a missed proof); Arweave SPoRA (version 2.4, February 2021, approximate: the docs page 404'd; mining reward requires random access to stored chunks); Sia storage proofs (2015, approximate) and Storj audits (2018, approximate); Celestia data availability sampling (2023, approximate); EigenDA (2024, approximate); Ethereum PeerDAS (EIP-7594, 2024: custody by node id, cell KZG proofs, and the EIP states no reward or penalty for serving); Kaspa archival nodes (a flag on kaspad, unrewarded; the README fetched this morning does not document it, approximate). What differs here: the data served is the chain's own state, the challenger is the next block producer and the randomness is the chain's, and the reward is a slice of the block subsidy to a miner key, not a storage market.
-
-**Mechanism.**
-
-| Item | Rule |
-|---|---|
-| Challenge | block B's producer draws `c` keys from the weight table at the last certified checkpoint in B's past, by weight, seeded by B's prehash; for each, 8 leaf indices of the day's `D` |
-| Answer | the challenged key signs `(B, leaves, openings against R_d)` and any producer carries it within `T` blocks |
-| Failure | no answer carried in `T` blocks after B |
-| Reward | x of the 80 producer points conditional: a key with an unanswered challenge in the window is paid 80 - x on its next blocks until it answers one |
-| Bytes | 8 leaves x (64 + 25 x 32) + 96 B signature = 6.8 KB per answer; 1 challenge per block = 0.61 GB a day on every node (model, table A2) |
-
-**Game theory (model, section A).**
-
-| Attack | Cost | Bound |
-|---|---|---|
-| Serve yourself from your own nodes | zero; the challenged key answers its own challenge from the state it already holds to mine under class v5 | the proof reduces to "I hold what class v5 already makes me hold" |
-| Outsource the answer to a peer that holds the state | one fetch, about 108 ms on a 100 ms link; any deadline over one block (1,000 ms) admits it | the proof becomes "someone with the state answered"; Filecoin's answer is sealing (replicas slower to fetch than to read), which costs hours of CPU per sector and does not fit a daily dataset |
-| Producer griefing: refuse to carry answers | an answer gossips to every producer; withholding for T blocks needs a majority of producers for T seconds | the same bound finality lives with |
-| Sybil the draw | the draw is by weight; a dust key is never drawn; splitting a key splits its draws and its loss | nothing to gain |
-| Loss to a key that never serves at x = 8 | 0.1 percent key: 691 IGN a day (USD 3.5 at 0.005); 10 percent key: 69,120 IGN a day | the price of not running a node, which a miner under class v5 must run anyway |
-
-**Load per key.** At 10,000 keys and one challenge per block a key's share of challenges is its weight share: 8.64 a day for a mean key, 0.06 MB of upload a day, 0.006 kbit/s. At 128 leaves per challenge and 8 per block, 7.6 MB a day. Every home connection carries it (table A1). The cost is on the chain, not the key: 0.61 to 76.5 GB a day of answers on every node depending on the two parameters.
-
-**Hostile review (Monero voice).** "You pay a miner for proving it holds the thing your own lottery forces it to hold. The challenge adds 0.6 GB a day to every node to learn nothing, and the fetch bound makes it 'someone served', which is what gossip already guarantees. Filecoin pays for storage because storage is the product; your product is blocks. The one honest version is unpaid: a light-client spot check of availability, which is your rank 6 RPC."
-
-**Cost and gate.** 0 hours as a reward; 4 hours as new-pow rank 6 (the opening RPC, unpaid), whose gate is 128 openings verifying against `R_d` on the fast-time network.
-
-**Per tier.** As a reward: every tier pays bytes (0.61 GB a day of chain) to prove what class v5 proves. As the unpaid RPC: a node serves 102 KB per request on demand; a light client gains a daily availability spot check; no card changes.
-
-**Verdicts.** Cryptographer: never as a reward, do the RPC (the outsourcing bound makes the proof vacuous). Consensus engineer: never (0.61 to 76 GB a day for no new property). The miner: never (a line item nobody understands). Economist: never (it moves x points for a service already compelled). Verdict: never as protocol; new-pow rank 6 stands.
-
-### 1.4 (c) Proof of propagation: signed receipts from peers in the next block
-
-**The idea.** A block carries receipts, signed by peers' vote keys, that they received the previous block within t seconds; the producer is paid a slice for fast propagation.
-
-**Prior art.** Bitcoin's Relay Network and FIBRE (Matt Corallo, 2016; bitcoinfibre.org: UDP, forward error correction, compact blocks; no protocol payment to relays). Kaspa's relay is the ordinary p2p flow with no receipts (approximate). "Proof of relay" papers: this lane found none that shipped; the arXiv search for "proof of latency" returned five unrelated papers (section 7.11). GHOSTDAG itself: a slow block is red and its subsidy goes to its merger (spec 02 2.5), which is the propagation reward the DAG already pays.
-
-**Mechanism and why it dies.**
-
-| Item | Problem |
-|---|---|
-| The time field | no consensus clock finer than Kaspa's timestamp window (a header at most 10 s ahead of the clock, spec 02; the DAG tolerance 132 s in frontier 3.1); a receipt's "within t seconds" is the signer's word |
-| Sybil receipts | peers are keys; weight-drawn receipts cost the attacker nothing because its own keys sign its own receipts |
-| Bytes | 8 receipts x 136 B = 1,088 B per block, 94 MB a day; 32 receipts 376 MB a day (model, section H) |
-| What the DAG already does | at 1 block/s on Devnet 2 run B the red rate was under 2 percent from minute six (bench-log, "Block rate on Devnet 2"); a block that propagates slowly is red and its subsidy moves to its merger: the propagation reward exists and is measured in blue blocks, which are also the vote weight |
-
-**Hostile review (Kaspa voice).** "GHOSTDAG is a proof of propagation. Blue means it arrived in time; red means it did not; the k parameter is the clock. Receipts signed by the people who benefit from them prove nothing and cost 94 MB a day."
-
-**Verdicts.** All four: never. Cost 0.
-
-### 1.5 (d) Proof of state availability with block-derived challenges and the producer's own next block
-
-**The idea.** As 1.3 but the challenge is issued by the producer's own next block (so no trusted party), answered on demand, and the reward slice is paid only to keys that answered.
-
-This is 1.3 with the challenger named. The trap the brief names ("who issues challenges without a trusted party") is answered correctly by block-derived randomness and the producer's next block, and the answer does not rescue the idea: the outsourcing bound (a fetch in 108 ms) and the self-serving bound (the key answers from the state class v5 makes it hold) are unchanged. The one new element, "the producer's own next block" as the carrier, makes the producer the judge of its own challenge and needs a second producer to carry the answer for fairness, which is 1.3's `T` blocks.
-
-**Verdicts.** All four: never as a reward; the unpaid availability spot check (new-pow rank 6) is the whole of what survives. Cost 4 hours for the RPC.
-
-### 1.6 Section 1 in one table
-
-| Variant | Prior art | New? | Survives its game? | Cost | Verdict |
-|---|---|---|---|---|---|
-| (a) proof of following | Verthash 2021; class v5 2026 | in form only | yes, because it does nothing | 0 | never: the epoch seed and the state root already prove following |
-| (b) proof of serving | Filecoin PoSt 2020; Arweave SPoRA 2021; PeerDAS 2024 (unrewarded) | the reward to a miner key is new | no: outsourced in 108 ms; self-answered under class v5 | 0 (4 for the unpaid RPC) | never as a reward |
-| (c) proof of propagation | FIBRE 2016 (unpaid); GHOSTDAG's reds | no | no: time is unverifiable; receipts are Sybil-free | 0 | never |
-| (d) state availability by the producer's next block | same as (b) | the challenger rule is new | no, same bounds as (b) | 4 (RPC) | never as a reward |
-
----
-
-## 2. A block reward that pays for availability of the chain's state
-
-**The exact split proposal, as asked.** Of the 80 producer points, x are conditional on the key having served state in the window, verified as in 1.5; the rest unconditional. The candidate x: 2, 4 or 8 (8 would mirror the signing bonus of vote-or-burn, which pays 8 of the 80 for signing).
-
-**The attack: serve yourself.** The challenged key answers from the state it holds; the challenge is drawn by weight, so the key's own weight is the only thing that decides how often it is asked. A key that runs a node (every class v5 miner) passes every challenge at zero marginal cost. A key that runs no node and proxies to a pool passes every challenge at one fetch. Nobody fails except a key whose node is down, which is the signing bonus's case already (vote-or-burn section 1: the honest-silence classes), so the conditional slice is a second liveness bonus on the same event.
-
-**The Sybil bound.** Vote-key weight as the challenge draw: a dust key is never drawn, a split key is drawn in proportion, so splitting gains nothing. Correct, and it also means the mechanism measures the keys that already mine, who already hold the state.
-
-**Per-tier cost (model, table A1).** At 10,000 keys, one challenge per block, 8 leaves: a mean key uploads 0.06 MB a day; at 8 per block and 128 leaves, 7.6 MB a day, 0.7 kbit/s. Any home connection on any OS carries it. The chain pays 0.61 to 76.5 GB a day of answer bytes on every node for the two parameter corners.
-
-**What it costs a key that never serves (model, table A3).** At x = 8: 0.01 percent key 69 IGN a day, 0.1 percent 691, 1 percent 6,912, 10 percent 69,120 (USD 0.3 to 346 at 0.005). The same shape as the signing bonus and for the same population.
-
-**Hostile review (Monero voice).** "Two liveness bonuses on one event is one bonus with worse accounting. Your signing bonus already pays 8 points for 'my node is up and following'; this pays x more for 'my node is up and holds the state', which under class v5 is the same node. Merge them or drop this."
-
-**The economist.** No payer wants it: the slice comes from the same producer share, so it is a transfer from keys whose nodes are down to keys whose nodes are up, which the signing bonus already does; the chain pays gigabytes a day for the second accounting.
-
-**Verdicts.** Cryptographer: never (vacuous under the outsourcing bound). Consensus engineer: never (bytes). The miner: never (a second deduction line is read as a second fine; vote-or-burn's 93 to 97 percent respect for one bonus at genesis would not survive two). Economist: never. Cost 0.
-
----
-
-## 3. Mining that is also a light-client service
-
-**The idea.** Every miner's node serves finality-in-proof public values (494 B) and certificate bitmaps to phones; a reward slice or a fee market pays for it.
-
-**Prior art.** Ethereum Portal Network (2021 to 2026; ethportal.net: history, state and beacon networks; clients Trin, Nimbus Portal (Fluffy), Ultralight, Shisui; the site states no reward for nodes). Helios (a16z, 2022, approximate for the year; github: weak-subjectivity checkpoints as the root of trust, sync-committee verification). Mina's snarkers (2021, approximate): a fee market for SNARK work inside the protocol. Celestia light nodes and bridges (2023, approximate). What Igneum has that none of these had: the serving node is a miner with a funded key, and the object served (494 B of public values plus a 260 B Groth16 proof, once the wrapper lands) is tiny and self-certifying.
-
-**Whether it is a protocol item.** No. The object is public values a node already holds; serving it is one HTTP or wss endpoint (spec 10.7's read-only table); the phone app already reads nodes it pins (phone-app section 5). A fee market for 786 bytes is a transaction per fetch at 0.0051 IGN (frontier 3.13's transfer floor), which no phone will pay per refresh and no node needs. A reward slice is 1.3's reward with a different payload and the same vacuity.
-
-**What it is: an Ember feature.** Ember in verify mode is frontier 3.8 (do now, 20 hours). The light-client serving side is a line in the node's RPC: `igneum_getLatestWrappedProof`, served to any client, rate-limited per IP, with the phone app pinning the user's own node by its card (phone-app section 5) or the seed list. Bytes per day per phone: 786 B per refresh, 2,880 refreshes a day if it polls every checkpoint = 2.3 MB (spec 10.5's phase-two figure, 2.30 MB, matches).
-
-**Game theory.** A node that lies serves a proof that does not verify, which the phone refuses; a node that withholds is replaced by the next pinned node. No payment, so no cheating for pay. The one attack is topology: a phone pinned to one node is eclipsed by that node, which spec 10.6's N of M seed agreement bounds.
-
-**Hostile review (Kaspa voice).** "Serving 786 bytes is not a service you price. It is a feature of a node. Put it in the app."
-
-**Cost and gate.** 4 hours (the RPC and the rate limit) on top of frontier 3.8's 20; gate: a phone on cellular shows "locked, voter set verified in the proof" from a miner's Ember node with no other node asked, bytes counted on the Verify screen.
-
-**Per tier.** Every miner's Ember serves phones by default behind a per-IP limit (a home upload of 786 B per request is nothing); a holder's phone gets its proof from any miner; a pool user's member process is the same Ember; no card or OS difference.
-
-**Verdicts.** Cryptographer: do now (as the Ember line). Consensus engineer: do now, not a protocol item. The miner: do now ("my node serves my phone" is a sentence miners like). Economist: do now, unpaid; a fee market here would price a service below its transaction cost.
-
----
-
-## 4. A decentralised pool in the protocol
-
-### 4.1 The design, as asked
-
-| Item | Rule |
-|---|---|
-| A share | a block header at a low difficulty, signed by the miner's own payout key, referencing the round `r` |
-| The round | the window of blocks between two chain-block boundaries, e.g. 600 chain blocks (the record window of spec 7.8) |
-| Carriage | any block carries shares it has seen; a share is valid if its header's PoW passes the share target and its parents are in the carrier's past |
-| Payout | a coinbase rule every node computes: the producer share of blocks in round r is split by share weight (`2^-s`) over the shares carried in round r's blocks, PPLNS style, minus nothing (no operator, no fee) |
-| Variance reduction | a miner is paid by its shares whether or not it found a block |
-
-### 4.2 Prior art
-
-| Name | Year | What it did | What differs |
-|---|---|---|---|
-| P2Pool (Bitcoin) | 2011 (Forrest Voight, approximate) | a sidechain of shares at a 10-s target; payouts in the coinbase of found blocks; no operator | the shares were off the main chain; nodes did not verify them |
-| FruitChains | Pass and Shi, 2016 (eprint 2016/916) | "fruits" as low-difficulty PoW objects carried in blocks, rewarded fairly: any honest set with phi of the hash gets at least (1 - delta) phi of the reward | the exact in-protocol shape asked for here, published nine years ago; never shipped on a major chain |
-| SmartPool | Luu, Velner, Teutsch, Saxena, 2017 (eprint 2017/019) | shares committed by Merkle root to an Ethereum contract, verified by sampling; miners paid 0.6 percent of block rewards in transaction fees | a contract, not a coinbase rule; the operator is the contract |
-| Monero P2Pool | SChernykh, 2021 (github SChernykh/p2pool) | a 10-s share sidechain merge-mined with Monero, PPLNS over 2,160 shares (6 hours), no operator, payouts as coinbase outputs | off the main chain; Monero nodes do not verify shares |
-| Stratum V2 job negotiation | Braiins, 2019 onward (approximate) | the miner builds its own template; the pool must pay shares on it | an operator remains; the vote and template are the miner's (spec 09 already takes this) |
-| Ocean (Bitcoin) | 2023 (approximate) | an operator pool with on-chain payouts per block (TIDES) | an operator remains |
-| Braidpool | 2021 onward (github braidpool/braidpool: in development, not production) | a DAG ("braid") of shares; miners build their own blocks; constant-size payouts | not shipped |
-| Kaspa "SPECTRE shares" | none found | | Kaspa pools are Stratum bridges with operators (approximate) |
-
-So the in-protocol pool is FruitChains (2016) with Igneum's payout key and round. It is not new.
-
-### 4.3 The bytes and the verifier (model, section B)
-
-| Miners | Share interval | Shares per block | Bytes per block (compact 169 B) | Per day on every node | Verifier cores at 1.35 / 5.06 / 10 ms per share |
-|---|---|---|---|---|---|
-| 1,000 | 10 s | 100 | 16.5 KB | 1.5 GB | 0.14 / 0.51 / 1.0 |
-| 10,000 | 10 s | 1,000 | 165 KB | 14.6 GB | 1.35 / 5.06 / 10.0 |
-| 100,000 | 10 s | 10,000 | 1,650 KB | 146 GB | 13.5 / 50.6 / 100 |
-| 100,000 | 100 s | 1,000 | 165 KB | 14.6 GB | 1.35 / 5.06 / 10.0 |
-| 100,000 | 1,000 s | 100 | 16.5 KB | 1.5 GB | 0.14 / 0.51 / 1.0 |
-
-The full-header form (496 B) is 2.9x the bytes. The verifier at the class v4 cold figure (5.06 ms) needs 50 cores per node at 100,000 miners and a 10-s share interval, which no home node has; at a 1,000-s interval it fits one core and 1.5 GB a day, but then the variance reduction is the thing being bought and it has gone:
-
-| Income source | Paying events per day | CV of a day's income | CV of a month |
-|---|---|---|---|
-| solo 17 MH/s at 1 TH/s | 1.5 | 82.5 percent | 15.1 percent |
-| shares at 1 per 1,000 s | 86 | 10.8 percent | 2.0 percent |
-| shares at 1 per 100 s | 864 | 3.4 percent | 0.6 percent |
-| shares at 1 per 10 s | 8,640 | 1.1 percent | 0.2 percent |
-
-At 100,000 miners the chain can afford one share per 1,000 s per miner (1.5 GB a day, one core), which gives a small card a 10.8 percent daily CV: a real improvement on 82.5 percent, at the cost of 1.5 GB a day on every node including every phone-class light client that would want to verify the coinbase. At 10,000 miners and 100 s the same bytes buy 3.4 percent.
-
-### 4.4 Does the vote key and sortition machinery give a round for free?
-
-Yes for the ROUND, no for the SHARES. W2 already counts blue blocks per key over 30 days, and the shard sortition already draws by that count (spec 7.2). A "round" and a per-key tally exist in every node. What does not exist is a sub-block unit of work, and that is the whole cost: every share is a PoW object every node verifies. The free version is to pay by BLOCKS over a window, which the protocol already does (every block pays its producer), so the free "pool" is the chain itself, and its variance is the solo row above.
-
-### 4.5 The attacks
-
-| Attack | Effect | Bound |
-|---|---|---|
-| Share withholding (find a block, publish only shares) | in an operator pool the withholder is paid shares and the pool loses the block; here the round's payout IS the blocks found, so a withheld block shrinks everyone's payout including the withholder's own share of it: the withholder loses `(1 - its share) x 80` points and gains nothing | self-defeating; FruitChains' fairness bound is the formal version |
-| Share stuffing | every share is PoW at the share target, so a fake share costs its hash; stuffing is mining | none needed |
-| Share grinding on the round boundary | a share's round is fixed by its parents; a share straddling a boundary is a DAG event nodes already order | none needed |
-| A majority refusing to carry others' shares | it earns the majority a larger split of the round; this is red-flooding by another name, 26 to 28 percent of honest income at 51 percent (51-percent.md section 1) | the same bound as today's reds |
-| Verifier DoS | a flood of invalid shares costs a node 5 ms each before rejection | the per-peer rate limits of the p2p layer; the ban score |
-
-### 4.6 The honest verdict against docs/plans/pool.md
-
-The shipped pool v0 (5 October 2026, rebased 6 October) already removes the two things an in-protocol pool is for: the operator holds no key and no vote (members sign their own votes through their own verifiers, spec 9.7), and the share rule is fixed by spec 9.8 so the member keeps its own ledger. The measured operator cost is 1.35 ms per share check (4,800 to 22,700 members per core) and 1 percent fee by default. What the operator still controls: transaction choice for mode A members who do not check (mode C fixes it), and the payout ledger's honesty (the member's own ledger plus the chain's blocks under its key bound it).
-
-The finished form is therefore the pool design plus one addition the brief names: **a verifiable payout contract**, which is SmartPool (2017) on Igneum's EVM: the operator posts the round's share Merkle root and the payout list; any member can prove under-payment with its own share log against the root; the contract pays from the pool address. Cost 16 hours (contract 6, operator posting 4, member proof and the Ember line 6). Gate: a member whose share is dropped from the root proves it on the fast-time network and is paid; an honest round costs the operator one transaction. Bytes on chain: 32 B per round per pool. Verifier cost on nodes: nothing per share.
-
-**Hostile review (Monero voice).** "P2Pool exists because we did not want shares on the main chain; your numbers say why: 14.6 to 146 GB a day. Our P2Pool is a sidechain nobody but miners runs. Build that if you want no operator; it costs your chain nothing." Answer: a Monero-style P2Pool sidechain for Igneum is an app a pool operator could ship (the share chain's only chain-side object is the coinbase payout list), and it is the same code as the pool v0 member minus the server; the lane recommends the contract first because it keeps every existing pool (HiveOS, WhatToMine listings) and makes them verifiable.
-
-**Per tier.** Home miner on any card: nothing changes in the worker; under the contract a member can prove under-payment from its own log. Rig: one key per rig as today. Pool user: the pool's round is public. Node operator: 32 B per round per pool instead of 1.5 to 146 GB a day. Light clients: unchanged.
-
-**Verdicts.** Cryptographer: never in protocol (FruitChains is the prior art and the bytes are the reason it never shipped); prototype the contract. Consensus engineer: never in protocol (50 cores per node at 100,000 miners on a 10-s share); the contract 16 hours. The miner: never in protocol (a chain that grows 14.6 GB a day from shares is the first thing a reviewer attacks); the contract is what listings want. Economist: the operator's 1 percent is already below SmartPool's 0.6 percent plus gas (approximate); the contract makes the 1 percent honest. Verdict: never in protocol; prototype the verifiable payout contract, 16 hours.
-
----
-
-## 5. Heat as product
-
-**The idea.** Ember's "heat mode" targets a room temperature or a schedule: the card mines when the room wants heat and idles when it does not; the chain does nothing.
-
-**Prior art.** Heatbit (2022 launch, approximate; heatbit.com this morning lists Bitair at 25 W, 1.2 TH/s, USD 179 to 249, and names earlier Maxi and Trio models), 21energy (Austria; Ofen 3 heaters EUR 1,658 to 3,325, "7 to 10 kW" central-heating models coming, 21energy.com), Qarnot (France, founded 2010, approximate, the Wikipedia page 404'd; QRad computing heater 2013, approximate; sells HPC and heats buildings), MintGreen in North Vancouver (2021, approximate), the Finnish and French district-heat trials (approximate; no page fetched). Every one is an ASIC or HPC box sold as a heater. None is a GPU chain's own client with a thermostat. Ember's version is new as a client feature and nothing else.
-
-**Numbers (model, section C).** A 300 W card delivers 300 W of heat at the card's electricity price. The competition is a gas boiler at 90 percent or a heat pump at COP 3.
-
-| Region | Card per hour | Gas boiler, same 300 W | Heat pump COP 3 | Resistive electric | Card must earn per hour to match boiler / heat pump |
-|---|---|---|---|---|---|
-| UK (Ofgem, 1 Oct to 31 Dec 2026: 26.32 p electricity, 7.97 p gas) | 7.90 p | 2.66 p | 2.63 p | 7.90 p | 5.24 p / 5.26 p |
-| EU (Eurostat H2 2025: EUR 0.2896; gas EUR 0.11 approximate) | 8.69 c | 3.67 c | 2.90 c | 8.69 c | 5.02 c / 5.79 c |
-| US (EIA July 2026: 18.31 c; gas 5 c approximate) | 5.49 c | 1.67 c | 1.83 c | 5.49 c | 3.83 c / 3.66 c |
-
-Against a resistive heater (a bedroom panel, a US baseboard) the mining heat is free and every IGN earned is profit. Against a boiler or a heat pump the card must earn about 5.3 p an hour in the UK.
-
-| Network hash | IGN per hour, 100 MH/s card at 100 IGN a block | at USD 0.005 | at 0.02 | at 0.10 |
-|---|---|---|---|---|
-| 100 GH/s | 360 | USD 1.80 | 7.20 | 36.00 |
-| 1 TH/s | 36 | 0.18 | 0.72 | 3.60 |
-| 10 TH/s | 3.6 | 0.018 | 0.072 | 0.36 |
-
-So at 1 TH/s and USD 0.02 a 5090-class card earns 72 US cents (about 55 p) an hour and heats for 7.9 p: a heater that pays. At 10 TH/s and USD 0.005 it earns 1.8 cents and the heat costs 5.3 p more than gas: a heater that costs 3.9 p an hour net, which is still under the resistive panel it replaces in a room without a radiator. The honest sentence for the app: "In heat mode your card is an electric heater that also earns; whether it beats your boiler depends on the network and the price, shown live."
-
-**Game theory.** None on the chain: a heat-mode miner is a miner with a schedule. One effect to name: seasonal hash. If heat mode becomes a large share of hash, winter hash rises and summer hash falls in the northern hemisphere; the DAA absorbs it, and the 30-day weight window means a summer departure of heat miners is a slow slide, not a departure event (the 10 percent per hour rule is not touched by a thermostat that ramps over weeks).
-
-**Hostile review (Monero voice).** "A thermostat in a miner is a feature every miner GUI has had since 2014 (approximate: temperature targets in miner software). Call it heat mode if it sells; it changes nothing about the chain." Correct.
-
-**Cost and gate.** App feature, 6 hours: a target-temperature input, the schedule, a sensor source (the OS's, or the card's own temperature as a proxy with a stated error), the live "earns X, heats Y, your boiler would cost Z" line from the tariff the user enters (phone-app 4.1 already has the tariff field). Gate: a room sensor loop on PC 1 holds a set temperature within 1 degree over four hours while the hash rate follows the duty cycle, logged.
-
-**Per tier.** An 8 GB card at 150 W is a 150 W heater (the small-room case); a 5090 at 326 to 575 W (the ladder page's TGP range) is a large-room heater; a rig is a space heater that should not be in a bedroom; a pool user's duty cycle shows as a share-rate pattern the pool sees; macOS: the M5 Max at low watts is a poor heater; Windows and Linux alike.
-
-**Verdicts.** Cryptographer: do now (no protocol content). Consensus engineer: do now, 6 hours. The miner: do now (the one feature a home miner in a cold flat asks for first; the number line must show when it loses to gas). Economist: do now, with the tariff line mandatory so nobody reads "free heat".
-
----
-
-## 6. Phone-verifiable everything
-
-**What remains after finality-in-proof and the WASM verifier (horizon rank 19).** Finality-in-proof gives 494 B of public values that say "locked at checkpoint i by x of y weight" under one proof; rank 19 gives the Groth16 or Plonk wrapper verified in a tab. What is left is the last mile: carrying that object with no network, and a "verify this block" link on the explorer.
-
-**Prior art.** Mina (2021, approximate): a constant-size recursive proof of the whole chain, verified on a phone, with proof-of-stake under it. zkSync's block proofs on Ethereum (2023, approximate): verified by a contract, not a phone. Helios (a16z, 2022): a light client in WASM, trust rooted in a weak-subjectivity checkpoint. No proof-of-work chain has a phone-verifiable finality object; after finality-in-proof Igneum does, and the QR is only packaging.
-
-**The object (model, section D).** Groth16 proof 260 B (SP1 docs) + public values 494 B + verifying-key id 32 B = 786 B. A version 40 QR at level L holds 2,953 B; a version 25 at level M about 1,000 B (approximate). So one QR carries the proof with room for a block hash and a receipt path of up to about 2 KB, and a phone with the pinned verifying key verifies it with no network: one bn254 multi-pairing, of the order of 2 to 5 ms native on a phone (approximate; Helios and the xycloo WASM demos are the order-of-magnitude anchors, 10 to 50 ms in WASM, frontier 3.4). The URL form is the same bytes base64 in a fragment, 1,048 characters, under every browser's limit.
-
-**What the phone learns with no network.** That some chain with this chain id, under this aggregator program, had checkpoint i locked by x of y weight, with state root R and history root H, and (with the receipt path) that transaction T is in a block at or below the lock. What it cannot learn offline: that this is the LATEST lock (staleness: the `lock_daa` field lets it show the age against its own clock, labelled "age by your clock").
-
-**The wrapper's cost on a 5090.** SP1's docs give PLONK as about 1 min 30 s longer than a compressed proof and Groth16 as the recommended on-chain form at 260 B; the wrap runs on the CPU in gnark whatever the GPU (approximate, from memory of SP1's wrapper architecture). So the wrap is not per segment (8 s): one wrapper machine wraps one proof per 90 s, and the chain's "latest wrapped proof" is 38 segments behind the tip at a 300-s cadence or 8 behind at 60 s with two wrapper machines (model, table D). The measurement the design needs is the one frontier 3.4 names (R4): wrap the pinned aggregator proof on a 24 GB fleet card and the box's CPU, record seconds and RAM. Expected, approximate: 60 to 180 s and 16 to 32 GB of RAM.
-
-**The explorer link.** "Verify this block" on the explorer renders the QR and the URL for the newest wrapped proof whose history covers the block, plus the block's MMR path; the tab verifies it with rank 19's WASM verifier and shows the milliseconds. 4 hours once rank 19 lands.
-
-**Game theory.** A forged QR fails verification; a stale QR shows its age; a QR from another chain id is refused. A soundness bug in SP1 forges a lock on the phone and not on the chain (full nodes verify the BLS certificate natively, finality-in-proof 5.1), which is the stated light-client row.
-
-**Hostile review (Kaspa voice).** "A QR that says 'locked' with no network says 'locked as of when the QR was made'. Say the age in big letters or you will have people paying against last week's lock." Correct; the age line is in the design.
-
-**Cost and gate.** 8 hours (QR and URL packing 2, the phone verify call on the shared `igneum-light` engine 4, the explorer link 2) plus rank 19's 16. Gate: a phone in airplane mode scans a QR printed from the explorer and shows "locked at checkpoint i, x percent of weight, age 4 minutes by your clock, verified in N ms"; a QR with one byte changed is refused.
-
-**Per tier.** Holders: a proof in their pocket. Miners: their node serves the wrapped proof (section 3). Rollup customers: the same 786 B is what their bridge verifies. Node operators: one wrapper machine per network at a 300-s cadence (a box, not a card).
-
-**Verdicts.** Cryptographer: do now after rank 19 (the first offline-verifiable PoW finality). Consensus engineer: do now (nothing in consensus). The miner: prototype (nice, not what miners ask for). Economist: do now (the cheapest public proof of the phase-two claim; the wrapper machine is one box).
-
----
-
-## 7. More candidates, generated and judged
-
-Twelve more. The first four are this lane's own (7.1 to 7.4); the rest are the brief's list, judged.
-
-### 7.1 A weight-backed peer directory in the coinbase (this lane's candidate)
-
-**The idea.** A block producer may opt in to carry its node's reachable address (IPv6 plus port, 18 B) in its coinbase extra data, signed by the vote key the header already names. The chain becomes its own seed list: a fresh client draws its outbound peers from the last 30 days of carried addresses, weighted by the carrying keys' W2 weight. No DNS seed, no shipped seed list beyond genesis peers, no operator.
-
-**Prior art.** Bitcoin's DNS seeds and `addr` gossip (2011 onward, approximate); Ethereum's ENR and discv5 (2019, approximate); Kaspa's dnsseeder (approximate); the eclipse attack paper (Heilman, Kendler, Zohar, Goldberg, USENIX Security 2015) and its address-bucket fixes. No chain this lane knows writes reachable addresses into blocks under the producer's key with weight-weighted draws. New in form; the pieces (addr gossip, weighted sampling) are old.
-
-**Mechanism.**
-
-| Item | Rule |
-|---|---|
-| Object | `IGNA`-style section: `0x05 ‖ ip16 ‖ port2`, opt-in, at most one per block, signed by the header's vote key (the key reveal already proves possession) |
-| Directory | every node keeps the last window's entries keyed by vote key hash (one address per key, newest wins) |
-| Draw | a client picks outbound peers by the key's W2 weight; keys under dust are not drawn |
-| Bytes | 18 B per block = 1.56 MB a day on every node (model, section E); 30 days at most 2.6 M entries, far fewer after de-duplication by key |
-
-**Game theory (model, table E).** An attacker with share a of the 30-day weight lists share a of the directory. With 8 outbound peers drawn by weight, the probability every peer is the attacker's is a^8: 2.6e-6 at 20 percent, 1.8e-4 at 34 percent, 4.6e-3 at 51 percent; with 16 peers 6.6e-12, 3.2e-8, 2.1e-5. Against this, a DNS seed is one operator and a shipped list is one release key. The attack that remains: listing honeypot addresses under honest-looking keys costs the attacker 30 days of mining per key, the same bound as every other weight-backed thing on this chain. Griefing: a producer lists a victim's address to draw traffic to it; bounded by one address per key per block and the signed key, so the lister is named on chain.
-
-**Hostile review (Kaspa voice).** "Your reachable miners are the rigs and the seeds; home miners are behind NAT and will list nothing or list a dead address. The directory is a list of rigs weighted by rigs, which is the thing you said you wanted to avoid (frontier 3.8's Kaspa attack). Also a 30-day-old address is a dead address." Answer: the client draws from the newest entries first with the weight as the tie-break, a liveness probe before use is the ordinary `version` handshake, and the rigs-weighted list is still a list of parties that mined 30 days of public blocks rather than one DNS operator. The NAT point stands and is the measurement.
-
-**Cost and gate.** 10 hours: the coinbase section and signature check (3), the directory and the weighted draw in the node (4), the client's use in Ember verify mode and the phone (3). Gate: a fresh node with no seed list and genesis peers only reaches 8 outbound peers from the directory on the fast-time network; an eclipse harness with a 34 percent attacker listing 34 percent of addresses eclipses the fresh node in under 0.1 percent of 1,000 starts (expected 1.8e-4 at 8 peers).
-
-**Per tier.** Home miner: opt-in, off by default (NAT); a rig and a seed node opt in; a pool node opts in; the phone and Ember verify mode gain a seed list with no DNS; no card, OS or vendor difference; node operators store 1.56 MB a day.
-
-**Verdicts.** Cryptographer: prototype (a weight-backed seed list is the right shape; measure the NAT fraction). Consensus engineer: prototype (10 hours, nothing in fork choice). The miner: watch (home miners will not opt in; rigs will; fine). Economist: prototype (removes one operator from the trust row for 1.56 MB a day).
-
-### 7.2 Sign-in with Igneum: 30 days of public work as a login (this lane's candidate)
-
-**The idea.** A vote key signs a challenge to prove its W2 weight to a third party: a rental marketplace, a forum, a faucet, an airdrop-free allowlist. The verifier reads the weight from any node or the finality-in-proof public values. Sybil cost is 30 days of mining per identity.
-
-**Prior art.** Hashcash (Back, 1997): proof of work as an anti-spam stamp. Sign-In with Ethereum (EIP-4361, 2021): a signed message as a login. Proof-of-humanity and Gitcoin Passport (2021 onward, approximate): social Sybil resistance. No chain has a non-transferable, work-earned weight per key to sign with; Igneum does.
-
-**Game theory.** A key's weight is worth its 30 days of pool income (work-stake section 5: 2,793 IGN for an 8 GB card at 100 GH/s), so lending it to a login is lending a reputation that cannot be split without halving each half. A marketplace that gates on weight gets a Sybil cost it cannot buy elsewhere. The attack: a key used as a login is a key whose secret is on a machine that talks to websites; the pool spec's one-signer rule (9.6 item 3) and the equivocation strip mean a stolen key is burned by its thief in one double vote. The login must therefore be a delegated session key signed once by the vote key, never the vote key online.
-
-**Hostile review (Monero voice).** "You are building an identity out of a mining key. Miners do not want identities; that is why they mine." Answer: opt-in, delegated, and the first customer is the rental escrow of frontier 3.13, which already needs the key.
-
-**Cost and gate.** 6 hours (the delegation message, the verifier library in `igneum-light`, an Ember button). Gate: a web page verifies a delegated signature against a node's weight for one key and refuses a key under dust.
-
-**Per tier.** Any key above dust (100 blocks a window; 3.86 MH/s at 100 GH/s) can sign in; an 8 GB card qualifies at every network size up to about 440 GH/s (where 17 MH/s falls under dust, arithmetic on work-stake section 5); below that, nothing.
-
-**Verdicts.** Cryptographer: watch (the delegation design is the whole risk). Consensus engineer: watch (not consensus). The miner: watch. Economist: prototype only with the rental escrow as the first user.
-
-### 7.3 Public timestamping on the proof chain (this lane's candidate)
-
-**The idea.** Any hash posted in an Igneum transaction is, 60 to 93 s later, inside a certified checkpoint and, after the segment proof, inside a 786 B offline-verifiable object (section 6). OpenTimestamps (Todd, 2016, approximate) does this on Bitcoin with hours of latency and a Merkle aggregator; Igneum does it with the lock latency and a proof a phone verifies.
-
-**Game theory.** None: a transaction with a hash. The base fee burns; the priority fee pays. The product is the receipt path in the QR.
-
-**Cost and gate.** 4 hours (a contract that emits the hash in a log, the receipt path in the explorer link of section 6). Gate: a timestamp verified offline on a phone from a QR.
-
-**Verdicts.** All four: do now once section 6 lands; it is section 6's first use. The economist: a product with a fee a user pays, which is the kind the utility lane wants.
-
-### 7.4 Hash-rate futures as an app (this lane's candidate, judged against ruling)
-
-**The idea.** Braidpool's stated purpose: a miner sells its future shares forward for cash now. On Igneum a miner could sell its next window's pool income (the work-stake bond) forward.
-
-**Why it dies.** A forward needs a counterparty and collateral; the collateral is a coin balance posted by the seller or buyer, which is a coin bond, which is refused by ruling for anything the protocol touches. As an app between consenting parties with their own escrow it is allowed and the chain is indifferent. Prior art: Braidpool (in development), NiceHash (2014, an operator market). Verdict: never in protocol; watch as a third-party app. 0 hours.
-
-### 7.5 Finality as a service for other PoW chains
-
-**The idea.** Another PoW chain posts its block hashes into Igneum and treats the Igneum lock as a checkpoint; its clients refuse reorgs below the last anchored, locked hash. Igneum relies on nothing; others relying on Igneum is allowed by ruling.
-
-**Prior art.** Komodo dPoW (2018, approximate; the academy page 404'd): notary nodes write a chain's block hash into Bitcoin every 10 minutes (approximate) and protected chains refuse reorgs below it; VeriBlock Proof-of-Proof (2019, approximate; veriblock.org: "securing 1 chain", market cap USD 9 M); Babylon (Tas, Tse, Gai, Kannan, Maddah-Ali, Yu, 2022, IEEE S&P 2023: PoS chains checkpoint to Bitcoin; stake withdrawal from weeks to under 5 hours). Igneum's difference: the anchored chain gets a 90-s lock instead of Bitcoin's hour, and an offline-verifiable proof instead of an SPV path.
-
-**Game theory.** For Igneum: none; an anchor is a transaction. For the anchored chain: its safety becomes Igneum's finality, which pauses whenever under two thirds of weight signs (spec 03 3.7); an anchored chain must fall back to its own PoW during a pause and say so, which Babylon's design also requires of its consumers. A hostile Igneum majority cannot forge an anchor (it would need two thirds of weight to lock a false chain) but a third of weight can pause anchoring. Market (model, section G): at Komodo's cadence (144 anchors a day) the fee is 0.73 IGN a day, under one cent at any listed price. Revenue to Igneum: nothing material; standing: a product no PoW chain offers with proof-carrying finality.
-
-**Hostile review (Kaspa voice).** "Who are the customers? Komodo's dPoW protected a handful of Komodo-family chains and VeriBlock secures one chain worth USD 9 M. Small PoW chains that fear 51 percent (ETC, BTG, VTC in 2018 to 2020) chose checkpoints from their own developers over paying anyone." Correct; the demand is the gate.
-
-**Cost and gate.** 16 hours: an anchor contract (4), a client library that reads the lock and the proof for an anchored hash (8), a reference patch for one open-source PoW node (4). Gate: one outside chain's testnet runs the patch for a week and refuses a staged deep reorg below an anchored lock.
-
-**Per tier.** Nothing changes for any Igneum miner or holder; an anchored chain's miners get a 90-s checkpoint they did not vote for, which their community must accept (the Komodo precedent: accepted by chains that chose it).
-
-**Verdicts.** Cryptographer: prototype (sound, and the first external use of the lock). Consensus engineer: watch (demand first). The miner: watch (no miner cares). Economist: watch (USD 0.004 a day per customer at the floor is standing, not income).
-
-### 7.6 The hourly program as a standing public hardware benchmark with a leaderboard
-
-Frontier 3.16 (do now, 10 hours) publishes the corpus; the leaderboard is the product on top: per card model, per vendor, per driver, the median rate and joules per hash across the hour's variants, from the fleet library and opt-in Ember submissions, with the bit-exact fingerprint per entry. Prior art: Geekbench (2007, approximate), hashrate.no and WhatToMine (2018 onward, approximate) as operator tables; none continuous on a random kernel stream. New as a continuous random-kernel benchmark. Game theory: a submitter lies about its rate; the fingerprint proves bit-exactness not speed, so self-reported rates are labelled and the fleet's measured rows are the reference tier. Cost 8 hours on top of 3.16. Gate: a public page with the eleven measured cards (prover-tiers-real-cards.md) as the reference tier and opt-in rows beneath. Verdicts: do now (all four; the miner: "a leaderboard is the first thing a mining YouTuber screenshots").
-
-### 7.7 Proof of unique card: count machines, not keys
-
-Dead, and the reason is the design's own: nothing in consensus counts nodes, keys or cards (spec 3.1 W6, ledger F17), so a count of machines would be a Sybil surface the design removed on purpose; and a chip emulates any fingerprint it has been shown (frontier 4.3's Monero attack). What the design does count is blocks, and a card's blocks are its weight. Verdict: never. 0 hours.
-
-### 7.8 Shard proving as the on-ramp: a proving-only key earning pool income without a card
-
-Dead by the sortition rule: shard assignees are drawn by W2 weight (spec 7.2 step 2); a key with no blocks has no weight and is never drawn. What a proving-only key can do today: claim shards after the exclusive window (spec 7.2 item 4) and prove external jobs under the pool protocol's bonded key route (work-stake section 5, the prover row). That is the on-ramp and it exists. Verdict: never as a rule change; the two existing routes stand. 0 hours.
-
-### 7.9 Miner-signed release: 95 percent of weight signs the release hash
-
-Compare horizon rank 13 (reproducible-build attestations, N of M builders, 12 hours). A weight signature says "we RUN this hash", not "we BUILT it", and running is what the 95 percent class signal already measures (the object byte in the header version). So the idea is the P2 signal applied to a binary hash instead of a class byte: a header bit per release. Prior art: BIP9's version bits (2015) for rules, not binaries; no chain signals binary hashes (approximate). What it adds: a chain-readable "share of weight on release X" that Ember can show beside rank 13's "N builders reproduced X". Cost 4 hours (a release-hash field in the coinbase, tallied by the explorer, no consensus effect). Game theory: lying costs nothing and buys nothing; it is a statistic. Verdict: watch, fold into rank 13's display. Cryptographer: watch. Consensus engineer: do as a coinbase field, 4 hours. The miner: watch. Economist: watch.
-
-### 7.10 An energy-price oracle from miners' own signals
-
-**The idea.** Each producer carries its electricity price in its coinbase; the window's weighted median is the chain's energy price, free of any oracle operator.
-
-**Prior art.** Chainlink and the oracle networks (2017 onward, approximate); frontier 3.5's miner-voted dials (Ethereum's gas-limit vote, geth `VerifyGaslimit`); no PoW chain carries a price field (approximate).
-
-**Game theory.** A field nobody is paid for and nobody is punished for lying in is noise; a field that feeds a price (the job reserve of horizon rank 7, "measured proving electricity per pgas at the published settlement rate") is a field miners overstate, bounded only by the customer's bid, which rank 7 already makes the price. So the oracle is either noise or a lever on the job price that the bid neutralises. The honest use is statistical: the miner community lead's hardware-economics model wants real tariffs, and Ember's opt-in telemetry (the tariff field of phone-app 4.1) gives them off-chain with no consensus bytes.
-
-**Verdict.** Never in consensus; an opt-in Ember statistic. 2 hours for the telemetry line. All four personas: never in protocol.
-
-### 7.11 A first-block bonus per new key, Sybil-bounded by dust
-
-**The idea.** A key's first block above dust pays a bonus B, to welcome newcomers; the signing bonus of vote-or-burn exists, so this would be the second bonus.
-
-**Game theory (model, section F).** Dust is 100 blocks a window. A 10 percent miner makes 259,200 blocks a window and can keep 2,592 keys above dust, each collecting B once: at B = 100 IGN that is 259,200 IGN a window, 1 percent of its subsidy, for free (weight and sortition are per block, so the split costs it nothing but its own vote's convenience; the pool spec's one-key rule is a client default, not a consensus rule). A bonus large enough to matter to a newcomer (10 blocks, 1,000 IGN) is a 10 percent raise for every miner willing to run 2,592 keys. The dust bound makes the Sybil expensive in KEYS and free in HASH, and keys are free. Verdict: never. 0 hours. The miner: "an instamine with extra steps".
-
-### 7.12 A cross-vendor parity bounty
-
-Dead by ruling (no device bounty): a payment conditioned on a card model is a device bounty whatever it is called. What the design does instead is measure (the eleven rented cards, the ladder's per-rung 5 percent rule) and publish. Verdict: never. 0 hours.
-
-### 7.13 In-protocol insurance against reorgs for exchanges
-
-**The idea.** An exchange that credited a deposit later reversed by a reorg is made whole from a protocol pool.
-
-**Prior art.** None shipped in any protocol (this lane found no primary page; approximate). Off-chain: exchange confirmation policies; Nexus Mutual-style cover for contracts (2019, approximate), not for reorgs.
-
-**Why it dies.** Who pays? A protocol pool is either emission (a transfer from miners to exchanges, which the miner persona rejects on the Decred and Ethereum precedents in vote-or-burn section 2) or the proving pool (a transfer from provers, who did nothing wrong). The design's own answer is stronger than insurance: a certified checkpoint cannot be reversed (51-percent.md section 2), the four-state rule credits on "finalised" (ledger P17), and the exchange guidance says confirm at the lock or at 12 hours during a pause (horizon rank 16). Insurance is only wanted where finality is paused, and during a pause the only reorg-capable party is a hash majority with no slashable bond, by ruling. Verdict: never; the guidance is the product. 0 hours.
-
-### 7.14 Pause insurance from the proving pool
-
-Dead: it pays the wrong people or nobody. During a pause the silent third earns its subsidy (51-percent.md: "free to hold while silent"); redirecting pool income to the signing keys is the signing bonus's job (8 of 80 points) and to holders is impossible (no mechanism pays holders). Vote-or-burn priced the pause at 3,103 to 6,206 IGN an hour at 34 percent silent and found a deposit worth attacking covers either; LEAVE and weight-gated fork choice close the line. Verdict: never. 0 hours.
-
-### 7.15 Proof of latency: rewarding low-latency relays
-
-The arXiv search for "proof of latency" this morning returned five unrelated papers and none on relay rewards; FIBRE (2016) relays unpaid. Timing is unverifiable in consensus (section 1.4) and the DAG already pays for latency in blue blocks (under 2 percent red at 1 block/s, run B). A relay reward would need a clock and a Sybil-proof receipt, and it has neither. Verdict: never. 0 hours.
-
----
-
-## 8. Verdict table
-
-Ranked. At most three "do now" and three "prototype"; the rest "watch" or "never" with the line that killed them. Persona order: cryptographer / consensus engineer / the miner / economist.
-
-| Rank | Candidate | Prior art (name, year) | New? | Survives its game (bound) | Hostile review verdict | Hours | First gate | Four verdicts | Recommendation |
-|---|---|---|---|---|---|---|---|---|---|
-| 1 | 6 Phone-verifiable proof in a QR or URL, offline, plus the explorer link | Mina 2021 (approx.), Helios 2022, zkSync block proofs 2023 (approx.) | the offline PoW finality object is new | yes (a forged QR fails; staleness shown by `lock_daa`) | "show the age in big letters": accepted | 8 (+16 rank 19) | phone in airplane mode verifies a printed QR, refuses a one-byte change | do now / do now / prototype / do now | **do now** |
-| 2 | 5 Heat mode in Ember | Heatbit 2022, 21energy (Austria), Qarnot 2010 (approx.) | new only as a chain client feature | yes (a schedule is a schedule; seasonal hash absorbed by the DAA and the 30-day window) | "every miner GUI has a thermostat": accepted | 6 | set temperature held within 1 degree for 4 h on PC 1 while hash follows the duty cycle | do now x4 | **do now** (UK break-even 5.3 p an hour against gas or a heat pump; free against a resistive panel) |
-| 3 | 3 Miners' nodes serve the 786 B proof to phones (Ember line, unpaid) | Portal Network 2021 to 2026 (unrewarded), Helios 2022, Mina snarkers 2021 (approx.) | no | yes (a lie fails verification; eclipse bounded by N of M pins) | "not a service you price": accepted | 4 (+20 frontier 3.8) | a phone on cellular shows "locked, voter set verified" from a miner's node | do now x4 | **do now** |
-| 4 | 7.1 Weight-backed peer directory in the coinbase | DNS seeds 2011, discv5 2019, Heilman 2015 (approx.) | new in form | yes: eclipse at 34 percent of weight 1.8e-4 with 8 peers, 3.2e-8 with 16 (model E) | "a list of rigs weighted by rigs; NAT": partly accepted, the NAT fraction is the measurement | 10 | fresh node with genesis peers only reaches 8 outbound from the directory; 34 percent attacker eclipses under 0.1 percent of 1,000 starts | prototype / prototype / watch / prototype | **prototype** |
-| 5 | 4 Verifiable payout contract for existing pools (SmartPool shape) | SmartPool 2017; Ocean 2023 (approx.) | no | yes (a dropped share is provable from the member's log) | "P2Pool sidechain if you want no operator": accepted as the alternative | 16 | a member proves a dropped share on the fast-time network and is paid; 32 B per round on chain | prototype x4 | **prototype** |
-| 6 | 7.5 Finality as a service for other PoW chains | Komodo dPoW 2018 (approx.), VeriBlock PoP 2019 (approx.), Babylon 2022 | the 90-s proof-carrying anchor is new | yes for Igneum (an anchor is a transaction); the anchored chain inherits Igneum's pauses | "who are the customers": demand is the gate | 16 | one outside testnet refuses a staged deep reorg below an anchored lock for a week | prototype / watch / watch / watch | **prototype** (demand-gated) |
-| 7 | 7.6 Hardware leaderboard on the program corpus | Geekbench 2007, WhatToMine 2018 (approx.); frontier 3.16 | new as a continuous random-kernel benchmark | yes (self-reported rates labelled; the fleet's rows are the reference tier) | none | 8 (+10) | public page with the eleven measured cards as the reference tier | do now x4 | watch (frontier 3.16 is already "do now"; this is its page; the cap of three "do now" is spent) |
-| 8 | 7.3 Public timestamping on the proof chain | OpenTimestamps 2016 (approx.) | the offline-verifiable receipt is new | yes | none | 4 | a timestamp verified offline from a QR | do now x4 | watch until rank 1 lands, then 4 hours |
-| 9 | 7.2 Sign-in with Igneum (delegated weight as a login) | Hashcash 1997, EIP-4361 2021 | new (work-earned, non-transferable weight) | yes if delegated (a vote key online is a key a thief burns) | "miners do not want identities": opt-in | 6 | a page verifies a delegated signature against a node's weight; dust refused | watch / watch / watch / prototype | watch (first user: the rental escrow) |
-| 10 | 7.9 Miner-signed release hash in the coinbase | BIP9 2015; horizon rank 13 | no | yes (a statistic) | fold into rank 13 | 4 | the explorer shows share of weight per release hash | watch / do / watch / watch | watch |
-| 11 | 1.3 and 1.5 Proof of serving or state availability as a reward slice | Filecoin PoSt 2020, Arweave SPoRA 2021 (approx.), PeerDAS 2024 | the miner-key reward is new | no: outsourced in 108 ms; self-answered under class v5 | "pays for what the lottery compels" | 0 (4 for the unpaid RPC) | | never x4 | never: the unpaid RPC (new-pow rank 6) is all that survives |
-| 12 | 2 x of 80 points conditional on serving | as 11 | no | no (same bounds; a second liveness bonus on the signing bonus's event) | "merge or drop" | 0 | | never x4 | never |
-| 13 | 4 In-protocol pool (shares in blocks) | FruitChains 2016, P2Pool 2011, Monero P2Pool 2021, Braidpool (in development) | no | yes on incentives (withholding self-defeating), no on cost: 14.6 to 146 GB a day and 5 to 50 cores per node at 10,000 to 100,000 miners on a 10-s share | "we built a sidechain for this reason" | 0 | | never x4 | never in protocol |
-| 14 | 1.2 Proof of following | Verthash 2021 (approx.), class v5 2026 | in form only | yes, by doing nothing new | "the root already commits to the chain" | 0 | | never x4 | never: the epoch seed plus class v5 is proof of following |
-| 15 | 1.4 Proof of propagation receipts | FIBRE 2016 (unpaid) | no | no (time unverifiable; receipts Sybil-free; 94 to 376 MB a day) | "GHOSTDAG is a proof of propagation" | 0 | | never x4 | never |
-| 16 | 7.10 Energy-price oracle from miners | Chainlink 2017, frontier 3.5 | no | no (noise, or a lever the bid neutralises) | | 2 (Ember telemetry) | | never x4 (in protocol) | never; opt-in statistic |
-| 17 | 7.11 First-block bonus per key | the signing bonus (vote-or-burn) | no | no: a 10 percent miner collects it 2,592 times a window (model F) | "an instamine with extra steps" | 0 | | never x4 | never |
-| 18 | 7.13 Reorg insurance for exchanges | none shipped (approx.) | yes | no (no slashable payer by ruling; the lock is the product) | | 0 | | never x4 | never |
-| 19 | 7.14 Pause insurance from the proving pool | vote-or-burn's pricing | no | no (pays the wrong people) | | 0 | | never x4 | never |
-| 20 | 7.15 Proof of latency | none found (arXiv, 7 Oct 2026) | yes | no (no consensus clock) | | 0 | | never x4 | never |
-| 21 | 7.7 Proof of unique card | frontier 4.3 | no | no (nothing counts cards by design; a chip emulates a fingerprint) | | 0 | | never x4 | never |
-| 22 | 7.8 Proving-only key earning pool income | spec 7.2 | no | dead by the sortition rule; open claims and the pool route exist | | 0 | | never x4 | never |
-| 23 | 7.12 Cross-vendor parity bounty | | | dead by ruling (device bounty) | | 0 | | never x4 | never |
-| 24 | 7.4 Hash-rate futures | Braidpool, NiceHash 2014 (approx.) | no | needs a coin bond: dead in protocol | | 0 | | never (protocol) x4 | never in protocol; a third-party app is the chain's indifference |
-
-Three "do now": ranks 1, 2, 3 (34 hours in all, plus the 36 of rank 19 and frontier 3.8 they sit on). Three "prototype": ranks 4, 5, 6 (42 hours). Everything the brief hoped was a protocol invention in sections 1, 2 and 4 is dead on a number this lane ran: 108 ms (the outsourcing fetch), 0.61 to 76.5 GB a day (challenge answers), 14.6 to 146 GB a day and 5 to 50 cores (in-protocol shares).
-
----
-
-## 9. The honest answer
-
-Igneum's revolution is the combination already built, not any one new item. The pieces that exist in code or on a branch today and that no shipped proof-of-work chain has together: a random-program GPU hash whose dataset is the chain's own state (class v5, hash rate unchanged at 63.08 MH/s, verifier +0.11 to 0.21 ms), miner-only finality by 30 days of blue blocks with no stake (a lock 63 to 93 s after a checkpoint; 51 percent never reaches two thirds while honest miners mine), that finality carried inside the execution proof as 494 bytes a phone verifies (finality-in-proof), a bond for proving jobs made of 30 days of public work and no coin (work-stake: 2,793 IGN at risk for an 8 GB card at 100 GH/s against a 0.0015 IGN coin bond), a tail that keeps a 24-hour attack at about twelve days of emission in every year, and a pool protocol in which the operator holds no key and no vote.
-
-This lane tested fourteen candidates for the next thing and found two small ones worth building now (the offline proof in a QR, 8 hours, and heat mode, 6 hours), one Ember line (miners' nodes serve the proof, 4 hours), and three prototypes (a weight-backed peer directory that bounds an eclipse at 1.8e-4 for a 34 percent attacker, a verifiable payout contract for pools, and finality as a service for other chains). Every candidate that would have changed consensus died on a measured number: proof of serving on a 108 ms fetch, in-protocol shares on 14.6 GB a day, propagation receipts on the absence of a clock. The next genuinely new thing is the first offline-verifiable proof-of-work finality object in a user's pocket, and it is packaging on what is already built.
-
----
-
-## 10. Three headline findings for the coordinator
-
-1. Every "hashing useful to the chain" variant beyond class v5 is dead on one number: a key with no state answers an availability challenge in about 108 ms over a 100 ms link, so any deadline over one block makes the proof "someone served", and the reward slice it would gate (2 to 8 of the 80 points, 17 to 69,120 IGN a day by key size) pays for what the lottery already compels.
-2. An in-protocol pool is FruitChains (2016) and it costs every node 14.6 GB a day and 5 cores at 10,000 miners on a 10-s share (146 GB and 50 cores at 100,000), so the finished form is the shipped pool v0 plus a verifiable payout contract (SmartPool 2017 shape, 16 hours, 32 B per round on chain).
-3. The three things worth doing now total 18 hours and change no consensus rule: an offline-verifiable 786 B finality object in a QR (260 B Groth16 + 494 B public values + 32 B key id, under a version-40 QR's 2,953 B), Ember heat mode (a 300 W card breaks even against a UK gas boiler or COP-3 heat pump at 5.3 p an hour earned, and is free against a resistive heater), and every miner's node serving that proof to phones.
-
----
-
-## Sources (accessed 7 October 2026 unless stated)
-
-Project files: `docs/analysis/horizon-2026-10.md`; `docs/analysis/horizon/frontier.md`; `docs/analysis/horizon/new-pow.md`; `docs/analysis/class-v5-stored-state.md` (branch class-v5); `docs/analysis/finality-in-proof.md` (branch fin-proof); `docs/analysis/work-stake.md` (branch work-stake); `docs/analysis/tail-emission.md`; `docs/analysis/vote-or-burn.md`; `docs/design/latency-ladder.md`; `docs/analysis/51-percent.md`; `docs/plans/pool.md`; `docs/spec/09-pool-protocol.md`; `docs/spec/10-light-client.md`; `docs/design/phone-app.md`; `docs/bench-log.md` (lines 170, 230, 685, 873 to 877, 1934, 2582 to 2635); `.claude/agents/*.md`. Model: `/private/tmp/claude-501/-Users-joshm/cd75457f-4858-4f86-9634-7481ee056b7b/scratchpad/mission-invent/invent_model.py` and `out.md`.
-
-Primary pages fetched (WebFetch; the session's WebSearch budget was spent before this lane started, so every check is a direct fetch of a known primary page):
-
-- FruitChains: A Fair Blockchain, Pass and Shi, 2016: https://eprint.iacr.org/2016/916
-- SmartPool: Practical Decentralized Pooled Mining, Luu, Velner, Teutsch, Saxena, 2017: https://eprint.iacr.org/2017/019
-- Monero P2Pool (SChernykh): https://github.com/SChernykh/p2pool
-- Braidpool: https://github.com/braidpool/braidpool
-- EIP-7594 PeerDAS (2024): https://eips.ethereum.org/EIPS/eip-7594
-- Portal Network: https://ethportal.net/
-- FIBRE: https://bitcoinfibre.org/
-- Helios: https://github.com/a16z/helios
-- Heatbit: https://www.heatbit.com/
-- 21energy: https://21energy.com/
-- Filecoin storage mining and WindowPoSt: https://spec.filecoin.io/systems/filecoin_mining/storage_mining/
-- SP1 proof types (Groth16 about 260 B, PLONK about 1 min 30 s longer than compressed): https://docs.succinct.xyz/docs/sp1/generating-proofs/proof-types
-- Ofgem energy price cap unit rates, 1 October to 31 December 2026 (26.32 p electricity, 7.97 p gas, direct debit, national average): https://www.ofgem.gov.uk/your-energy-supply/your-energy-bill/energy-price-cap-unit-rates-and-standing-charges
-- EIA, average residential electricity price, July 2026 (18.31 cents per kWh): https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a
-- Eurostat, electricity price statistics, H2 2025 (EUR 0.2896 per kWh household): https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Electricity_price_statistics
-- Babylon: Bitcoin-Enhanced Proof-of-Stake Security, Tas, Tse, Gai, Kannan, Maddah-Ali, Yu, 2022: https://arxiv.org/abs/2207.08392
-- VeriBlock Proof-of-Proof: https://www.veriblock.org/
-- arXiv search "proof of latency" (no relevant paper): https://arxiv.org/search/?query=%22proof+of+latency%22&searchtype=all
-
-Pages that returned 404 this morning, so the item is labelled approximate in the text: Arweave yellow paper and mining guide (SPoRA), vertcoin.org Verthash page, Komodo dPoW academy page, Qarnot's Wikipedia page, Ofgem's cap-levels page (the unit-rates page above answered instead). Figures from memory are labelled approximate where they appear: Heatbit's 2022 launch, Qarnot's 2010 founding and 2013 QRad, Komodo's 2018 dPoW and its 10-minute cadence, VeriBlock's 2019 launch, Verthash's January 2021 activation, Mina's 2021 phone verification, EU and US gas prices, phone-side pairing times, SP1's Groth16 wrap time and RAM, Geekbench and WhatToMine years, the Heilman 2015 eclipse paper's venue.

docs/analysis/mission/mission.md

@@ -1,186 +0,0 @@
-# The Igneum Mission
-
-Written 7 October 2026, morning UK, by the mission coordinator (branch `mission`, worktree `igneum-wt-mission`) on the founder's order of the same morning, verbatim: "i dont want to get stuck in a loop here where we keep finding and adding features and security so im going to give you one last mission, deep deep dive into the past and look far into the future, what has been done, what hasnt been done, what has been started but not finished, what can we invent and what can we reinvent to honestly make the perfect gpu network that will be noticed as the revolution that everyone is waiting for."
-
-This is the last research round. Its output is the closed list in section 2. After it the project stops researching and ships. Five lanes ran in parallel and each has its own file with sources and a verdict table: `past.md` (lane 1), `unfinished.md` (lane 2), `future.md` (lane 3), `invent.md` (lane 4), `reinvent.md` (lane 5). Every number below names its lane; the lane file names the source or the model. Hours are agent hours. Nothing on the live devnet was touched and no build or hash measurement was run for this document.
-
-## 1. One page for the founder
-
-**What has been done.** Of 31 GPU-mined chains since 2011, 8 lost the GPU lane to a chip, 7 closed it by choice, 10 died on price or a rental attack; the 6 still GPU-only pay USD 0.22 to 0.71 a day per RTX 3080 (lane 1). In 20 miner posts the wants were hardware that keeps its value, income without a cliff, a fair supply. Igneum answers the supply in full (no premine, no fund, no fee to any team), the hardware with a measured 2.1x chip bound and the N ladder, the cliff with a monthly glide and a 1 percent tail. Finality by 30 days of blocks, proving as the reward, the leave item and the signing bonus are built or approved for the testnet genesis.
-
-**What has not been done.** Nobody on those forums asked for finality, a DAG or proofs; they asked for a card that keeps its value, a bill that gets paid and a coin that sells. The front page leads with the hash, the earnings page shows £0.00, a fresh install opens with two operating-system warnings and ends its first hour without one number the miner came for, and no proving customer has signed, so the coin has Ergo's 2023 exposure: a thin market. These gaps are hours, not protocol.
-
-**Started and not finished.** Three designs sit on branches: class v5 (the dataset is the chain's own state), finality inside the segment proof, work-stake (a bond of 30 days of work, no coin). Across the industry (lane 2), every useful-work scheme that passed cheap-verify did so by making the work useless, no pool without an operator exists on any chain but Monero, and every proof-of-work finality that held was a second validator set bought with coins. Lane 4 tested whether anything new in consensus beats these; each died on a number: proof of serving on a 108 ms fetch, in-protocol pool shares on 14.6 GB a day per node at 10,000 miners, propagation receipts on the absence of a clock, proof of following because the epoch seed plus class v5 already is one.
-
-**What we invent.** One thing, and it is packaging on what is built: the first offline-verifiable proof-of-work finality object: 786 bytes in a QR a phone verifies in airplane mode, served by every miner's node. No PoW chain has put finality in a user's pocket. Beside it, two genesis bytes the future demands (lane 3): a signature-scheme byte with a key-succession slot, because a post-quantum vote at 8,192 voters costs 57 GB a day unaggregated and the flip must be signalled before a machine exists; and a cache-size rung on the ladder, because a 256 MB consumer cache is a 2 to 3x shortcut.
-
-**What we reinvent.** The miner's first month. The 30-day vote window is a level system no chain has, and it is free: first block, 100 blocks for a vote, a signature in a checkpoint, 30 of 30 days, rank by weight, a signing streak. Every rung is a chain fact from one RPC; a renter cannot top it inside 30 days; no fund pays for it. Lane 5 priced the first month at about 35 hours: the Poisson count-up before the first block (an 8 GB card at 100 GH/s waits 1.6 hours expected), the block card, earnings in IGN first, the weight leaderboard, the hardware census. In a 105-post Reddit sample the miner's own posts rise highest ("my card paid for itself" at 777 times the room median against 66 for the network's milestone), so every shareable surface carries the miner's card, rank and days, never the project's number.
-
-**The honest answer.** Igneum's revolution is the combination already built plus two new things: the finality object in the pocket, and the ladder shown everywhere. No shipped chain has the combination: a random-program GPU hash whose dataset is the chain, miner-only finality with no stake that 51 percent never reaches, that finality inside the execution proof, a work bond with no coin, a tail that holds a 24-hour attack at twelve days of emission in every year. Twelve items, about 290 agent hours, no new consensus rule beyond the three cut branches.
-
-### Decisions owed from the founder
-
-The cryptanalysis entity and prize; the signing certificates (lane 5); the signed proving customer as a mainnet gate (lane 1); the H100 and A100 hash measurement on rented pods (lane 3).
-
-## 2. The closed list
-
-Twelve items, in build order. "In flight" names the lane or branch that holds it. Hours are the remaining agent hours; a gate is what must be true before the item is called done. Nothing is added to this list without removing something.
-
-| # | Item | State | Hours | Gate |
-|---|---|---|---|---|
-| 1 | The testnet genesis re-cut as approved | in flight (ship lane) | 0 new | the go checklist |
-| 2 | Finality in the pocket: finality in the proof, the 786 B object, every node serves it, the browser verifier | in flight (fin-proof) plus new | 68 | a phone in airplane mode verifies a printed QR and refuses a one-byte change |
-| 3 | Class v5, the dataset is the chain, and nothing wider | in flight (class-v5) | 16 | the fast-time harness across a day boundary; Devnet 2 across a real day |
-| 4 | Weight-gated deep fork choice before mainnet | in flight (horizon rank 4) | 16 | a 51 percent fresh-key fork from 15 min back refused by every honest node |
-| 5 | Work-stake: the job bond made of 30 days of work | in flight (work-stake) | 24 | 1,000 posted jobs, every injected miss forfeits, zero honest forfeits |
-| 6 | The ladder shown everywhere: the miner's first month | new (lane 5) | 35 | a Devnet 2 key walks every rung on screen; first share within 10 minutes in 9 of 10 fresh Windows installs |
-| 7 | Heat mode, the region and price prompt, the cost-against-rent line | new (lanes 3, 4) | 10 | a set temperature held within 1 degree for 4 h on PC 1 while hash follows the duty cycle |
-| 8 | Genesis forward-compatibility: the scheme byte, key succession, the cache rung | new (lane 3) | 10 | the digest test; a vote item with scheme 1 refused by every node until the signal |
-| 9 | A second proof system on the active list and the one-third stop switch | new (frontier I4, lane 3) | 24 | 1,000 segments agree across both systems; one injected bad proof disagrees and pays nothing |
-| 10 | The launch pack: gates and text, no protocol | new (lanes 1, 3, 5) | 15 | every gate line in testnet-go.md with its check |
-| 11 | The pool finished: pool-0 with member keys at 1 percent, TLS, the share sidechain with no operator | new (lanes 2, 4, 5) | 60 | 100 members on the fast-time network paid by the coinbase rule from a share chain with no operator key; the first on a DAG chain |
-| 12 | The weight-backed peer directory | new (lane 4, prototype) | 10 | a 34 percent attacker eclipses under 0.1 percent of 1,000 fresh starts |
-
-### 2.1 The testnet genesis re-cut as approved (in flight, ship lane)
-
-What it is: one cut with 18 decimals, `EmissionSchedule::TESTNET_1` (100 IGN a block, a monthly glide with a two-year half-life, a 90-day ramp from 10 percent, a 1 percent tail from year 11.4), and the switches on from genesis: proof verification in consensus, the leave item, the signing bonus at 1,000 bps, finality v3, the latency ladder at rung 0. The founder approved it on 7 October 2026, 09:3x UK (ledger-decisions.md).
-Why it is right: lane 1's verdict rows 4 and 5 (the cliff and the premine) are answered by it in full; lane 3's tail row holds to year 200.
-Evidence: tail-emission.md one page; vote-or-burn.md section 5; ledger-decisions.md 7 October.
-Cost: 0 new hours; the ship lane's own plan.
-Gate: the go checklist (`docs/plans/testnet-go.md`); nothing mines until the word.
-Order: first; every later item lands on this genesis.
-
-### 2.2 Finality in the pocket (in flight on `fin-proof`, plus three new parts)
-
-What it is: the weight table carried inside the recursive segment proof (W2 updated one mergeset per segment, the BLS certificate verified in the guest, 494 B of public values), then three parts this mission adds: a Groth16-wrapped proof as a 786 B object (260 B proof, 494 B public values, 32 B key id) in a QR or URL that a phone verifies offline; every miner's node serving the latest object by default (an Ember line, unpaid); and the WebAssembly verifier in the tab (horizon rank 19).
-Why it is new: no proof-of-work chain has an offline-verifiable finality object; the closest shipped forms are Mina's recursive state proof (2021) and Helios's committee light client (2022), both online and neither over proof of work. Lane 4 section 6 and 3, persona verdicts do now, do now, prototype, do now.
-Evidence: finality-in-proof.md sections 1 to 5 (level 1 of the blue-set check designed, level 0 in the prototype); the certificate half verifies in 58 to 68 ms warm in a browser (bench-log round 6); SP1 light verifier 0.032 s on a Mac core; a version-40 QR holds 2,953 B.
-Cost: 40 for the fin-proof remainder (level 1 of 5.2, the cycle counts of section 6.1 on the box, the 5090 prover time on a pod), 8 for the QR object, 4 for the Ember line, 16 for the WASM verifier. 68.
-Gate: a phone in airplane mode verifies a printed QR and refuses a one-byte change; "locked, voter set verified" on cellular from a miner's node; a block proof verifies in the tab under 500 ms on a laptop.
-Order: second; it is the one invention and it needs the genesis of item 1 for the pinned aggregator id.
-
-### 2.3 Class v5, the dataset is the chain, and nothing wider (in flight on `class-v5`)
-
-What it is: each day's dataset built from the execution state at a reference block an hour before the day; a card without the state builds every item wrong. The branch widened it to a per-window refresh (section 2a of its page). This mission's ruling: no further widening. Lane 4 tested proof of following, serving, propagation and state availability as additions and found each dead on a number: a key with no state answers an availability challenge in about 108 ms over a 100 ms link, so any deadline over one block proves only that someone served; propagation receipts need a clock the DAG does not have; the epoch seed plus the state root already commit to the chain's recent blocks, so proof of following is class v5 by another name.
-Why it is right: hash rate and watts unchanged within noise (63.083 against 63.088 MH/s, 205 to 208 W on a 4090), build +1.4 ms, verifier +0.11 to 0.21 ms per unit; it removes the f = 0 recompute chip as a category and the stateless pool miner.
-Evidence: class-v5-stored-state.md; new-pow.md 5.2 and 6; invent.md sections 1 and 8 rows 11 to 15.
-Cost: 16 (the 4090 rows owed in section 7, the exec snapshot wire version 2, the GPU hosts' leaf buffer, the spec text).
-Gate: the fast-time harness crosses a day boundary with the roots agreeing on every node and the stateless node's miner at 0 accepted blocks; Devnet 2 across a real day boundary; then the 95 percent signal with a floor.
-Order: third; it rides the class-signal machinery item 1 ships.
-
-### 2.4 Weight-gated deep fork choice before mainnet (in flight, horizon rank 4)
-
-What it is: a tip whose fork point is older than D (10 min of past-median time) is a fork-choice candidate only if the keys that built it hold at least a third of the weight table at the fork point.
-Why it is right: lane 1's verdict row 6: rented hash reorganised Bitcoin Gold, Vertcoin and Musicoin for USD 70 k to 18 M; Igneum's finality bounds this after day 20 and not before, and the first 20 days are when a new chain is watched. The 51 percent paper prices a 12-hour double spend during a pause at USD 146 at 1 GH/s today.
-Evidence: 51-percent.md section 5 rank 2; horizon rank 4; past.md section 4 row 6.
-Cost: 10 to 16.
-Gate: fast-time: a 51 percent fresh-key fork from 15 min back is refused by every honest node; a one-third-weight fork is accepted; partition heal unchanged.
-Order: fourth; before the public testnet opens, because the testnet is the first chain outsiders can rent against.
-
-### 2.5 Work-stake (in flight on `work-stake`)
-
-What it is: a vote key may claim an external proving job only if its next window of pool income covers the job's value; a miss, refusal or forgery forfeits that income for one window, the buyer's fee refunded first, the rest to the pool. No balance moves; no coin is posted. The spec sentence lands first: "no coin stake; the only thing at stake is 30 days of public work."
-Why it is right: a bond nobody can buy (2,793 IGN at risk for an 8 GB card at 100 GH/s against a 0.0015 IGN coin bond); every attack in its section 6 fails on the window arithmetic.
-Evidence: work-stake.md sections 3 to 7; frontier 3.2 and 4.1.
-Cost: 24 (orders carried in blocks, the term unwound on reorg, the finality report wired to `judge_at`, the snapshot field, the deadline floor).
-Gate: Devnet 2: 1,000 posted jobs with 10 percent injected misses, every injected fault forfeits, zero honest keys forfeit; a 60 s partition across 100 deadlines forfeits nothing.
-Order: fifth; it needs the job market of spec 5.4, which the first customer (item 10) needs.
-
-### 2.6 The ladder shown everywhere: the miner's first month (new, lane 5)
-
-What it is: the 30-day vote window as the status ladder on every surface, and the first month's moments built around it. The rungs: first block; 100 blocks and "your key has a vote"; "your signature is in checkpoint K"; 30 of 30 days, full weight; rank by weight; the signing streak; "your card proved shard N of block M". The parts: the Poisson count-up before the first block ("a card like yours finds a block about every 1.6 hours on today's network; chance so far 31 percent"); the block card with a locally drawn PNG and the explorer link; Earnings in IGN first (6,912 IGN a day for a 100 MH/s card at 100 GH/s at the full rate) with a typed price never fetched; the weight leaderboard on `/live` (weight, never hashrate, so a renter sits at the bottom for 30 days); the public address profile behind an opt-in; the hardware census on `/miners` from the hourly program's per-card timings (frontier 4.3); #first-blocks and the Voter and Window roles granted from `getFinalityWeights`.
-Why it is the right reinvention: lane 5's archive sample shows the joy posts are the first block, the first payout and the rig photo In a 105-post sample the miner's own posts rise highest: "my card paid for itself" at 777 times the room median against 66 for the network's milestone.; Helium, Chia, Ethereum 2017 and Kaspa 2022 each had a hook, a daily ritual and a status surface, and each status surface was a company number or a hashrate a renter could top. Igneum's is a consensus fact. Nobody has it.
-Evidence: reinvent.md sections 1, 2, 3.2 to 3.7, 7; the solo-block expectations per tier at 100 GH/s and 1 TH/s (an 8 GB card: 1.6 h and 16 h; it never reaches the vote line at 1 TH/s, which is why the pool is item 11; the 100-block dust line means an 8 GB card never votes past about 500 GH/s, a question for the finality lane and a watch item, not a list item).
-Cost: 35 (Poisson line 2, block card 4.5, earnings 6.5, ladder 6, leaderboard 3, profile 3, census 4, Discord 5, the first-hour timeline on `/miner` 2).
-Gate: a Devnet 2 key walks every rung on screen in a view test; every number on the tab names its RPC field on hover; "first share within 10 minutes of download in 9 of 10 fresh Windows installs" published on `/evidence`.
-Order: sixth; it is the first thing the first outside miner sees.
-
-### 2.7 Heat mode, the region and price prompt, the cost-against-rent line (new, lanes 3 and 4)
-
-What it is: Ember holds a room temperature or a schedule and the hash follows the duty cycle; a per-region electricity-price prompt with a banned-region line ("mining may be restricted where you are; you are responsible for checking"); the Earnings tab's cost line against the measured rental rate so a miner sees when rented hash undercuts their card.
-Why it is right: a 300 W card as a heater breaks even against a UK gas boiler or a COP-3 heat pump at 5.3 p an hour earned and is free against a resistive panel (lane 4 section 5); the heating season credits about a third of a UK or EU miner's bill (lane 3 section 4); lane 3's 2031 row says retail-power tiers leave first when idle datacentre hash sets the rent, and the heat mode keeps winter home miners on. Prior art is Heatbit (2022), 21energy and Qarnot; new only as a chain client's feature, which is the point.
-Evidence: invent.md section 5 and rank 2; future.md sections 3, 4 and 10.
-Cost: 6 heat mode, 2 region prompt, 2 the rent line. 10.
-Gate: a set temperature held within 1 degree for 4 h on PC 1 while hash follows the duty cycle; the prompt shows the right banned list for a Russian region; the rent line reads the bench-log rate.
-Order: seventh; app only, no digest, ships in any cut.
-
-### 2.8 Genesis forward-compatibility: the scheme byte, key succession, the cache rung (new, lane 3)
-
-What it is: three genesis fields. A `sig_scheme` byte in the vote item and the key reveal (0 = BLS12-381 today), so a post-quantum scheme flips by the 95 percent signal and not by a fork. The key-succession item (W5, unimplemented on the node) so a key can hand its weight and its forfeit term to a successor once, which is the migration path. A cache-size rung on the signal ladder beside N, because a consumer last-level cache at the cache size (256 MiB) gives that card's owners a 2 to 3x shortcut (chip-model-v3; consumer LLC is 96 to 128 MB today, datacentre 256 MB). The class-group VDF's quantum fallback is flagged, not sized.
-Why it is right: naive ML-DSA-44 votes at 8,192 voters cost 19.4 MB a checkpoint and 57 GB a day; with 250x SNARK aggregation about 223 MB a day; a cryptographically relevant quantum computer is "quite possible (28 to 49 percent)" within ten years (Global Risk Institute 2025) and NIST deprecates ECDSA and EdDSA after 2030. The flip is signalled the year of deprecation, not the year a machine appears; the byte costs nothing now and a fork later.
-Evidence: future.md section 7 and 10; finality-in-proof.md 7 (W5 absent).
-Cost: 10 (the byte and the digest test 4, the W5 item 6, the rung 1 inside the ladder code, the spec text).
-Gate: the digest test; a vote item with scheme 1 refused by every node until the signal; a succession carried once and refused twice in the fast-time harness.
-Order: eighth; genesis fields must land before item 1's final cut, so this is scheduled with it and listed here for its own gate.
-
-### 2.9 A second proof system on the active list and the one-third stop switch (new, frontier I4 and lane 3)
-
-What it is: a second zkVM behind the `ProofSystem` trait (RISC Zero or OpenVM) proving the same segments on one fleet box as a shadow; a disagreement between the two on any segment is a public alert and the pool stops paying on proofs until 1/3 of weight signals which system to trust. Full nodes keep the native-execution veto whatever happens.
-Why it is right: three soundness-class events across SP1 and RISC Zero in 18 months (lane 3 section 5); the veto protects full nodes and nothing protects a light client or the proving pool; lane 3's death row 4 is this.
-Evidence: future.md sections 5 and 9; frontier I4; ledger P7 and D6.
-Cost: 24.
-Gate: 1,000 segments agree across both systems; one injected bad proof disagrees, pays nothing and raises the alert.
-Order: ninth; before any phone trusts item 2's object.
-
-### 2.10 The launch pack: gates and text, no protocol (new, lanes 1, 3 and 5)
-
-What it is: lines added to `docs/plans/testnet-go.md` and the litepaper, each with its check. Gates: a signed proving customer before mainnet, with the weight of the Devnet 2 gate; per-tier income published at three prices (USD 0.005, 0.02, 0.10) before the testnet, per the consequences rule; the launch-week hash-origin report (key counts, pool shares, fleet shares) from the observer, daily for the first 90 days; the first 100 keys, the first 1,000 independent keys (the X5 definition), the first pool not run by the project, the first outside-reproduced benchmark, the first block from a card the project does not own; signed and notarised installers (Developer ID, Authenticode) with the measured first-share time per release. Text: the three wants on the front page and finality on page two; "a block pays its miner whether or not anyone buys a proof that day"; the eight regulatory sentences of lane 3 section 8.3 (no issuer, no sale; the sustainability indicators per era; no price language; the pool holds no balance; no privileged key), labelled "not legal advice; counsel is engaged".
-Why it is right: lane 1's shape (income halves 60 to 120 days after a peak, under USD 0.10 per kWh within 6 to 18 months, 50 to 100 percent of hash gone in 90 days) and its rows 2, 4, 7 and 9; lane 5's install findings (SmartScreen warns on any file without reputation); lane 3's regulation rows (MiCA 4(3)(b) exempts block-reward assets; the UK regime from 25 October 2027 covers platforms and custody, not mining).
-Evidence: past.md sections 3 and 4; future.md section 8; reinvent.md 3.1 and 4.1.
-Cost: 15, plus the founder's certificates and the customer's signature.
-Gate: every gate line in testnet-go.md with its check; the forbidden-strings check passes on the new text; the hash-origin report posts on Devnet 2 for seven days before the testnet go.
-Order: tenth; text and gates can land any hour, and the customer gate is the one that takes longest.
-
-### 2.11 The pool finished (new, lanes 2, 4 and 5)
-
-What it is: pool-0 run by the project at the testnet go with the member's vote key in every header (the pool holds no weight and no vote), a 1 percent fee published beside the dev fee, PPLNS with a round every 60 s; TLS before the public testnet (spec 9.3) and the pool page rows Q69 to Q73; then the pool without an operator: a P2Pool-style share sidechain in the pool crate, shares forming a 10-second chain committed in the coinbase extra data, the window's payout computed by every node from consensus data as the 20 percent already is, no balance and no operator key, every member running the node the design already assumes. Lane 2's verdict: the finished form is Monero P2Pool's, not SmartPool's (SmartPool's on-chain claims died on gas, and at 1.35 ms per share verification a sampled contract would still need the zkEVM to re-derive a warp unit per sampled share); lane 4's in-protocol pool (shares inside blocks, every node verifying every share) stays refused at 14.6 GB a day per node.
-Why it is right: no pool without an operator exists on any chain but Monero (P2Pool at 7.7 percent of hash, 3,520 miners, 0 percent fee; Ocean 2.05 percent of blocks with 85 percent through DATUM; Stratum V2 job declaration at 1 block in 52,297); Igneum already holds the three objects that make one cheap (the vote key in the header, the 20 percent paid by sortition, the coinbase extra data), and nobody has built one on a DAG chain. An 8 GB card at 1 TH/s finds a solo block every 16 hours and 23 percent of its days have none, so the first-month ladder of item 6 depends on a pool from about 1 TH/s.
-Evidence: unfinished.md section 5 (5.2, 5.3) and headline 2; invent.md section 4 and rank 13; reinvent.md 3.5 and 1.4; pool.md; spec 09.
-Cost: 60 (TLS 8, the pool page rows about 12, the share sidechain about 40).
-Gate: 100 members on the fast-time network paid by the coinbase rule from a share chain with no operator key, a withheld share earning nothing, a member's dropped share provable from its own log; the first payout inside two minutes of the first share for an 8 GB card on Devnet 2.
-Order: eleventh; pool-0 and TLS before the testnet go, the share sidechain before the network passes about 1 TH/s.
-
-### 2.12 The weight-backed peer directory (new, lane 4, prototype)
-
-What it is: a coinbase section where a key above dust may publish its node's address; a fresh node dials from that list weighted by 30-day weight, beside the DNS seeds.
-Why it is right: lane 4's model E bounds an eclipse by a 34 percent attacker at 1.8e-4 with 8 outbound peers and 3.2e-8 with 16; prior art (DNS seeds 2011, discv5 2019, Heilman's eclipse paper 2015) weights nothing by work; lane 3's 2031 death row (weight concentrating in hosting firms) is first seen through such a list.
-Evidence: invent.md section 7.1 and rank 4; horizon rank 9 (the peer floor it extends).
-Cost: 10.
-Gate: a fresh node with genesis peers only reaches 8 outbound from the directory; a 34 percent attacker eclipses under 0.1 percent of 1,000 fresh starts; the NAT fraction measured on the fleet.
-Order: last; a prototype, dropped if the NAT fraction makes the list useless.
-
-## 3. Rejected, with the one line that killed each
-
-| Idea | The line |
-|---|---|
-| A pool inside the protocol (shares in blocks, no operator) | FruitChains (2016): 14.6 GB a day and 5 cores per node at 10,000 miners on a 10 s share; 146 GB and 50 cores at 100,000 |
-| A reward slice for serving state or data | a key with no state answers in 108 ms over a 100 ms link; it pays for what the lottery already compels |
-| Proof of propagation receipts | no consensus clock; 94 to 376 MB a day of receipts; GHOSTDAG already is a proof of propagation |
-| Proof of following beyond class v5 | the epoch seed and the state root already commit to the recent chain |
-| A first-block bonus per key | a 10 percent miner collects it 2,592 times a window: an instamine with extra steps |
-| Reorg insurance for exchanges, pause insurance from the pool | no slashable payer by ruling; the lock is the product; the pool pays the wrong people |
-| Proof of latency, proof of unique card, an energy-price oracle, hash-rate futures in protocol | no clock; nothing counts cards by design; a lever the bid neutralises; needs a coin bond |
-| Finality as a service for other chains | kept as a demand-gated prototype only; no customer named, so not on the list |
-| The weight-aged reward rule (pay per block falls when hash arrives faster than the weight) | a 30-day income ramp on every honest newcomer, which the first-month ladder cannot afford; revisit only if weight by hosting provider passes a third |
-| Mining is proving; useful work in the hash | 2.9 MB of openings per block, a 32 to 40 ms verify against the 10 ms gate; Aleo's fastest-prover-wins |
-| Proving others' chains as the main income | all of Ethereum L1's proving is about USD 36 a day against USD 13,700 of year-1 emission |
-| Vote-or-burn | 70 to 80 percent respect against the 95 percent test; the signing bonus is on at genesis instead |
-| Dormant-coin rent, any holder penalty, a device bounty, a coin stake, Bitcoin anchoring, privacy | refused by ruling |
-| A hardware wallet verifying proofs on the secure element | a bn254 pairing on a Cortex-M class element is seconds to minutes; the companion verifies |
-| A compute market for unverifiable work | an escrow without a verifier is a trust-me payment with lower fees |
-| Merged mining, multi-algo, an auxiliary chain | A child inherits its parent's pool concentration and loses its say in rules; a second hash lane splits the weight table and the DAA (Myriad, Verge, DigiByte); the one merged-mining shape with value is the share sidechain of item 11 |
-| Gamification paid from a fund, referral in coins, an airdrop for anything, NFT badges, off-chain points, a rank-by-hashrate board, a top-earners board in fiat, streaks that demote | there is no fund; nothing is for sale; the rung is a chain fact; a renter tops hashrate on day one; the burn was refused |
-| Any number that needs a company server to be trusted | every number shown is reproducible from a node, or it is not shown |
-
-## 4. What this round did not run
-
-| Item | Why | Where it sits now |
-|---|---|---|
-| The H100 and A100 hash rate on rented pods | no pod rented for this round | item 10's measurement line; lane 3 section 3 |
-| The in-guest BLS and colouring cycle counts (fin-proof 6.1) | no box slot taken for this document | item 2's cost |
-| The 4090 rows for class v5 (section 7 of its page) | the pod window was the class-v5 lane's | item 3's cost |
-| Reddit, bitcointalk and the Wayback Machine | refused this environment's fetches; quotes came through search snippets and project forums | past.md section 2, reinvent.md section 1, each labelled |
-
-## 5. The closing line
-
-Nothing is added to this list without removing something. Signed, the mission programme, 7 October 2026.

docs/analysis/mission/past.md

@@ -1,304 +0,0 @@
-# The past, honestly: every GPU-mined chain since 2011 and what GPU miners want
-
-Lane 1 of the last mission. Written 7 October 2026 by the past lane for the mission coordinator. Scope: the history of every chain that mattered to GPU miners, what each promised, what each paid, when the GPU miners left, and what the record says Igneum should change. The ASIC side of this history (which hash fell to which chip and how fast) is already in `docs/analysis/asic-resistance-history.md` and is not repeated; this file cites it where a chip is the reason a chain died for GPUs. The emission and governance comparison against Kaspa, Monero, Ethereum and the rollups is in the Horizon economy lane (section 4.6) and is not repeated either.
-
-Every figure from a source carries a URL and the access date in section 6. Every figure from memory is labelled approximate. Reddit, bitcointalk and the Wayback Machine refuse this environment's fetches (sections 2 and 6 say which quotes came through search snippets instead). Times are UK time.
-
-## 0. Progress
-
-| Time (UK, 7 Oct 2026) | State |
-|---|---|
-| 08:05 | Read CLAUDE.md, asic-resistance-history.md, horizon-2026-10.md section 1, economy-and-utility.md 4.6 |
-| 08:10 to 08:45 | 75 web searches and 60 fetches across project blogs, pool blogs, forums, press (search budget exhausted at 08:40) |
-| 08:49 | Writing; sections 1 to 6 landed in one pass |
-| 08:53 | Length check (258 lines, under the 300 floor); added 1a (the Merge week) and 1b (promised against delivered), split the grouped chain paragraphs, reconciled headline 1's counts against the table |
-| 08:58 | Done. File complete, reported to the coordinator |
-
-## 1. One row per chain
-
-Income columns are USD per card per day before electricity unless stated. "Exit" is when the median GPU miner stopped earning more than electricity at USD 0.10 per kWh, or when the lane closed outright. State is October 2026.
-
-| Chain (hash) | Launch | What it promised GPU miners | Peak GPU income (card, date) | Exit income (card, date) | GPU miners left | What killed the GPU lane, or state today |
-|---|---|---|---|---|---|---|
-| Litecoin (scrypt) | 13 Oct 2011 (approximate) | Memory-hard hash mineable on CPUs and consumer GPUs; no ASIC existed (litecoin.watch) | 200 to 800 kH/s per Radeon, 2012 to 2013; USD per card approximate 1 to 5 | 2014, under power for any GPU once Zeus 28 MH/s at 800 W shipped | Mid 2014 | Scrypt ASIC (Gridseed Jan 2014, Zeus mid 2014, Antminer L3 2017). Today an ASIC chain merged with Dogecoin |
-| Dogecoin (scrypt, AuxPoW) | 6 Dec 2013 | A fun scrypt coin for the same GPUs as Litecoin | Approximate USD 1 to 3 per card, Jan to Feb 2014 | Aug 2014 | Aug to Sep 2014 | Merged mining under Litecoin from block 371,337 (28 Aug 2014); hashrate +1,500 percent in a month (Binance Research). GPUs never came back |
-| Ethereum (Ethash) | 30 Jul 2015 | GPU-friendly memory-hard hash with a promise to leave for proof of stake | USD 0.233 per MH per day, Jan 2018 (so USD 23 per 100 MH); USD 6.35 to 9.15 per RTX 3080, early 2021 (Minerstat via Wccftech); May 2021 approximate USD 12 to 15 per 3080 | USD 1 to 2 per 3080 on 14 Sep 2022 (approximate) | 15 Sep 2022, all at once | The Merge. About 900 TH/s and about 20 million GPUs (Tom's Hardware estimate) lost 94 percent of GPU income in one block (2Miners: USD 24 M a day to USD 1.2 M) |
-| Ethereum Classic (Etchash) | Jul 2016 fork | A home for Ethash GPUs after the Merge | 70.5 to 158 TH/s in 7 hours on 15 Sep 2022 (CoinDesk), 296 to 312 TH/s inside a day | Under electricity for most GPUs within weeks; hashrate -48 percent in four days (AMBCrypto) | Sep to Dec 2022, then again as E9 Pro and Jasminer ASICs took the chain | Today 130 to 186 TH/s, ASIC-dominated; best ASIC nets USD 3.64 a day at USD 0.10 (asicminervalue) |
-| Monero (CryptoNight to RandomX) | 18 Apr 2014 | CPU and GPU mining, fork away any ASIC | Vega 56 era 2017 to 2018, approximate USD 2 to 4 per card | 30 Nov 2019: GPU performance "gets a tiny boost or degrades" (MinerUpdate) | 30 Nov 2019: 75 percent of GPU miners offline (MinerUpdate) | RandomX moved it to CPU on purpose; hashrate 300 MH/s to 800 MH/s in weeks. Qubic's rented-CPU campaign claimed 51 percent on 11 Aug 2025 with a 6-block reorg (The Block); the AFT 2026 paper finds no sustained majority and no reward edge |
-| Zcash (Equihash 200,9) | 28 Oct 2016 | "Universal accessibility" in mining (forum users' reading of the project) | USD 8 per GTX 1080 Ti, Jul 2017 (WhatToMine via 2Miners) | USD 2.63 per 1080 Ti, 6 May 2018 (2Miners) | Jun to Sep 2018 | Antminer Z9 mini announced 3 May 2018; the company stayed neutral; no fork. ASIC chain since; proof-of-stake migration under discussion (approximate) |
-| Ravencoin (X16R, KAWPOW) | 3 Jan 2018 | GPU-only by design; three hash changes to keep it so | Approximate USD 6 to 8 per 3080, Feb to Apr 2021 (RVN peak USD 0.2857) | 3080 loses USD 0.13 to 0.31 a day, 2026 (WhatToMine) | Gradual through 2023 to 2025 | KAWPOW (6 May 2020) cut hashrate 10x as FPGAs left and held off chips for six years; the Merge doubled it (8.9 to 15.9 TH/s). On 7 Aug 2026 a header-validation flaw let blocks carry "no genuine ProgPoW work" and split the chain; RVN -19 percent (crypto.news) |
-| Ergo (Autolykos v2) | 1 Jul 2019 (approximate) | Memory-hard, ASIC-resistant, GPU-only (minerstat FAQ) | Approximate USD 3 to 4 per 3080, Sep to Nov 2021 (ERG near USD 15) | USD 0.22 per 3080 before power, Oct 2026 (hashrate.no) | Late 2022 onward | The Merge pushed it from 22 to 155 TH/s in a day (Decrypt); difficulty ate the income within weeks. Still GPU, no chip, income under power |
-| Kaspa (kHeavyHash) | 7 Nov 2021 | "GPU PoW", fair launch, no premine (bitcointalk ANN title) | Approximate USD 2 to 3 per 3080, Feb to Mar 2023 | 3070 at USD 1.21 a day, 14 Apr 2023 (2Miners) while a KS2 made USD 361 | Apr to Oct 2023 | IceRiver KS0/KS1/KS2 (Apr to Jul 2023), Bitmain KS3 (May 2023). KS0 earned USD 25 a day in Jul 2023. Today 347 PH/s (hashrate.no), KS7 at USD 1,899, GPUs effectively zero |
-| Grin (Cuckaroo29, Cuckatoo31+) | 15 Jan 2019 | 90 percent of blocks for the GPU hash at launch, falling to zero over two years (Grin forum) | Approximate USD 1 to 2 per card, Jan 2019 | 2020 | 2019 to 2020, by schedule | The schedule itself. Today Cuckatoo32 ASIC only, GRIN at USD 0.035, USD 16 k daily volume (minerstat, approximate) |
-| Beam (BeamHash III) | 3 Jan 2019 | GPU-friendly Equihash 150,5 | Approximate USD 1 to 2 per card, Jan 2019 | 2020 onward | Most by 2021 | Never an ASIC; the price went. Still GPU-mined, sixth hard fork July 2026, negligible income |
-| Conflux (Octopus) | Oct 2020 (approximate) | GPU-only, no FPGA or ASIC | Approximate USD 2 to 3 per 3080, 2021 | USD 0.71 per 3080 before power, Oct 2026 (hashrate.no) | Ongoing | Still GPU at 3.9 TH/s. No chip in six years; income under power for most cards |
-| Alephium (Blake3) | Nov 2021 (approximate) | GPU-mineable sharded chain | Approximate USD 1 to 2 per 3080, 2023 | 2024 | May to Oct 2024 | Goldshell AL-Box 360 GH/s at 180 W (May 2024), AL-Box III 1.25 TH/s (Oct 2024). GPUs out in five months; even the ASICs now lose USD 3.44 a day at USD 0.10 (asicminervalue) |
-| Nexa (NexaPow) | 21 Jun 2022 | CPU first, then GPU, "scale to global capacity" | Top of the GPU tables Jul 2023 (2Miners) | 2024 (approximate) | 2024 (approximate) | Price. Approximate: down over 99 percent from its 2023 high; hashrate a fraction of 2023 |
-| Aleo (PoSW) | 18 Sep 2024 | Proving as mining on GPUs | USD 13.50 per RTX 4090 at ALEO USD 9, Sep 2024 (PANews via AiCoin) | Under USD 5 per 4090 at USD 3.40, late 2024 (same source) | Q4 2024 to 2025 | Price and allocation: a one-year lock on early rewards, validators seeded with 270 k to 1.1 M tokens, 10 M stake to validate; f2pool holds 28.9 percent of proving (hashrate.no). "Difficulty plummeted ... as miners exited" |
-| Iron Fish (Blake3, FishHash) | 20 Apr 2023 | GPU mining of a private chain | Approximate USD 1 to 2 per 3080, Apr 2023 | USD 0.48 per 3080 before power, Oct 2026 (hashrate.no) | 2023 to 2024 | Blocks of "unknown origin and hash power" within weeks (FPGA suspected); FishHash fork 2 Apr 2024 kept it GPU; the price did the rest |
-| Flux (ZelHash) | 2018 as Zel | GPU-only Equihash 125,4 | USD 50 k a day across the chain, Sep 2022 (2Miners) | Late 2025 | Late 2025 | Proof of Useful Work v2 (RunOnFlux, 23 Oct 2025): FluxNodes produce all blocks; "GPUs stopped having any relevance to FLUX rewards" |
-| Firo (MTP, FiroPoW) | 2016 as Zcoin | GPU-only ProgPoW variant since 26 Oct 2021 | 4x hashrate after the Merge | USD 0.56 per 3080 before power, Oct 2026 (hashrate.no) | Ongoing | No chip in five years. Still GPU, 13 to 54 GH/s, small |
-| Vertcoin (Lyra2RE, Verthash) | 8 Jan 2014 | "The people's coin", fork away every ASIC | Approximate USD 1 to 2 per card, Dec 2017 | 2019 | 2018 to 2019 | Two rental 51 percent attacks (Dec 2018: 300-block reorg, about USD 100 k; 1 Dec 2019: 603 blocks replaced, NiceHash). Verthash (Jan 2021) kept GPUs; nobody came back |
-| Bitcoin Gold (Equihash-BTG) | Oct 2017 | "Make Bitcoin decentralized again" on GPUs | USD 474 a coin, Dec 2017 | 2018 | 2018 to 2020 | 51 percent attacks: May 2018 (388,000 BTG, up to USD 18 M), Jan 2020 (29 blocks, USD 70 k). Delisted by Binance 1 Sep 2024 and Upbit 23 Jan 2025; "under 100 actively reachable nodes" (Decrypt) |
-| EthereumPoW (Ethash) | 16 Sep 2022 | Ethereum mining continues | Above USD 140 a coin at launch | 2022 to 2023; profitability -85 percent from peak | Within months | Price: USD 1.70 by mid 2025 (99 percent down); pools left for ETC |
-| Nervos CKB (Eaglesong) | 16 Nov 2019 | GPU-mineable launch | 300 GTX 1070 Ti earned USD 410 a day, 19 Nov 2019 (2Miners) | The same rig earned USD 4.46 a day, 21 Mar 2020 | Mar 2020 | Hashrate 198 TH/s to 1.99 PH/s in 16 days before any chip was sold (secret ASICs); Antminer K5 Apr 2020 at USD 22 then 11 a day |
-| Radiant (SHA512/256d) | 2022 (approximate) | "GPU/ASIC mining" in the ANN title | Approximate USD 1 per 3080, 2023 | Sep 2024 | Sep 2024 | IceRiver RX0 and DragonBall A11 ASICs, Sep 2024. Designed to go to ASIC |
-| Karlsen, Pyrin, Nomura (kHeavyHash forks) | Nov to Dec 2023 | "We will ensure long-term GPU-friendly mining" (Karlsen README) | Approximate USD 0.5 to 1 per 3080, Dec 2023 | 2024 | 2024 | Karlsen moved to FishHash (KarlsenHashv2, 12 Sep 2024) as kHeavyHash chips arrived; Pyrin was called "another pre-mine scam" on bitcointalk (five days of private mining before the announced start) |
-| Dynex (DynexSolve) | Sep 2022 | Proof of useful work, "the most GPU mined coin" (22 percent of Hive OS, Oct 2023) | Approximate USD 2 to 4 per 3080, mid 2023 | 2024 | 2024 | Price: 99.9 percent below its USD 1.39 high (CoinGecko). The useful-work marketplace never paid the miners |
-| Qubic (uPoW) | 2022 (approximate) | AI training as mining, CPU first | By 2025 about 90 percent of its compute was GPU rigs (Qubic blog) | n/a | Rotating | Pivoted to CPU incentives, then rented its idle fleet to Monero (May to Aug 2025, 27,000 blocks, USD 3.5 M), then to Dogecoin ASIC mining (1 Apr 2026). A hashrate broker, not a GPU chain |
-| Clore (Kawpow) | 2022 | GPU coin paid for GPU rental | ATH USD 0.45, 17 Mar 2024 | Dec 2025 | Dec 2025 | Proof of work "ended" at block 1,584,180 (Clore changelog, Dec 2025): "miner sell pressure fully removed". A 4090 rents for USD 1.18 to 2.45 a day there |
-| TurtleCoin (CryptoNight Turtle) | Dec 2017 | A friendly CPU/GPU coin | Negligible | Mar 2023 | 15 Mar 2023 | Halted at block 5,500,000; token moved to Fantom (TurtleCoin v2 FAQ). Dead as a chain |
-| Musicoin (Ethash) | 2017 | Ethash side income | Negligible | 2019 | Jul 2019 | Repeated 51 percent attacks, Bittrex delisting, 2Miners delisting (31 Jul 2019: "Musicoin is dead") |
-| Akroma (Ethash) | 2018 | Ethash side income with masternodes | Negligible | 2019 | Jul 2019 | Developers left; USD 92 daily volume; delisted by 2Miners |
-| Callisto (Ethash) | 2018 | Ethereum Classic airdrop chain | Negligible | 2024 | 2024 | Team liquidity crisis and "civil war" in 2024 (Callisto history page). Dead |
-
-### 1a. The Merge week, the one migration with hour-level data
-
-| When (UK) | What happened | Source |
-|---|---|---|
-| 15 Sep 2022, 07:43 | The Merge; Ethereum's last proof-of-work block; about 900 TH/s of GPU hash loses its income | Tom's Hardware |
-| 15 Sep 2022, 07:00 to 14:00 | ETC from 70.5 to 158.3 TH/s; RVN from 8.9 to 15.9 TH/s; ERG from 22 to about 70 TH/s | CoinDesk, Decrypt |
-| 15 to 16 Sep 2022 | ETC peaks at 296 to 312 TH/s (about a third of Ethereum's hash); ERG peaks at 155 TH/s (7x) | AMBCrypto, crypto.news, Decrypt |
-| 16 Sep 2022 | ETHW mainnet; the fork trades above USD 140 and falls for three years | KuCoin price history |
-| 19 Sep 2022 | ETC hashrate down 48 percent from its peak in four days | AMBCrypto |
-| Sep 2022 | Hiveon pool: 16 percent of its miners to ETC, 7 percent to RVN, the rest spread or gone | Hiveon |
-| 12 Sep 2022 (before) | 2Miners' arithmetic: USD 24 M a day of GPU income, 94 percent of it Ethereum; USD 1.2 M a day left for all GPU coins after | 2Miners, The Block |
-
-The arithmetic is the whole story: the receiving chains had one twentieth of the income and received, for a day, one third of the hash. Difficulty did the rest. The 2Miners advice of the day was to pick ETC, RVN or ERG "at least for the first days", and the first days were all there were.
-
-### 1b. Promised against delivered
-
-| Chain | The launch text (quoted or paraphrased) | What GPU miners got | Months of GPU income |
-|---|---|---|---|
-| Grin | 90 percent of blocks to the GPU hash at launch, falling to zero over two years (forum, Aug 2018) | Exactly that | About 18 |
-| Ravencoin | GPU-only, fork away FPGAs (KAWPOW, May 2020) | GPU-only for six years; a header bug, not a chip, split the chain in 2026 | 100 and counting, under power since about 2023 |
-| Kaspa | "GPU PoW", fair launch (bitcointalk ANN title) | 17 months, then chips at 20x and more per joule | 17 |
-| Karlsen | "We will ensure long-term GPU-friendly mining" (README) | A second hash in nine months to keep the promise; income under power either way | 10 |
-| Iron Fish | A GPU-mined private chain | Unknown hardware inside weeks; a GPU hash a year later | 12, then under power |
-| Aleo | Proving as mining on GPUs | USD 13.50 a day per 4090 for a few weeks, then price and pools | 3 |
-| Flux | GPU-only, "resistance to concentrated specialized-hardware advantages" | Seven years, then block production moved to nodes | 84, then closed |
-| Clore | Mine the coin that pays for GPU rental | Proof of work ended in December 2025; rental stayed | 36 |
-| Nervos | GPU-mineable launch | 16 days of 10x hashrate growth from secret chips four months in | 4 |
-
-What the table says, chain by chain, in one short paragraph each.
-
-**Litecoin.** The first GPU coin and the first proof that a memory-hard hash on paper is a compute-bound hash in a fab. Scrypt with a 128 kB scratchpad fit on a chip in 27 months. GPU miners did not vote or fork; they sold the cards. Lesson for Igneum: the dataset has to be bigger than any die the chip can afford, and the lane's own history (asic-resistance-history.md rows Scrypt) already prices this.
-
-**Dogecoin.** The only chain on the list whose GPU exit was a decision, not a defeat. Merged mining handed security to Litecoin's ASICs and the hashrate rose 15x in a month. Lesson: a small chain that shares hardware with a big one is mined by the big one's miners whenever the big one's miners choose; Igneum's hash has no big sibling, which is a feature and a cost.
-
-**Ethereum.** Seven years of GPU income, three cycles, one exit that was announced for five years and still removed 94 percent of all GPU mining income in one block. The money went to ETC, RVN and ERG for days and then to the shelf. Lesson: miners follow income, not loyalty, and an exit that is scheduled is still an exit.
-
-**Ethereum Classic.** The refugee chain. It absorbed a quarter of Ethereum's hashrate within hours and lost half of that within four days, then went to ASICs. Lesson: a chain that receives a migration gets a difficulty shock, not a community.
-
-**Monero.** Four hash forks in 20 months kept chips off and cost 85 percent of hashrate each time (asic-resistance-history.md). RandomX then chose CPUs on purpose and three quarters of the GPU miners left in a day. In 2025 a rented CPU fleet (Qubic) claimed a majority and produced a 6-block reorg; the peer-reviewed analysis finds no sustained majority and no profit. Lesson: ASIC resistance by hand is a treadmill; a majority that cannot profit still frightens exchanges.
-
-**Zcash.** The clearest record of a project refusing to fork for its GPU miners. The forum poll ran in February 2018, the Z9 shipped in May, the company stayed neutral, the GPUs left by autumn. Income per 1080 Ti fell from USD 8 to USD 2.63 before the chip arrived, because the price fell first. Lesson: the price kills before the chip does.
-
-**Ravencoin.** The one chain that forked three times and kept the GPUs for six years. KAWPOW cut hashrate 10x on fork day because the FPGAs left. Then in August 2026 a validation bug (not a chip) split the chain. Lesson: random-program hashes work; the client is the next weak point, and Igneum has one client.
-
-**Ergo.** A GPU-only hash that never saw a chip and still pays USD 0.22 a day per 3080. The Merge gave it 7x the hashrate in a day and the difficulty took the income back in weeks. Lesson: the hash is not the income.
-
-**Kaspa.** The template Igneum forked. A fair launch, a compute-bound hash, 17 months of GPU income, then IceRiver and Bitmain in the same quarter. In April 2023 a 3070 made USD 1.21 a day beside a KS2 making USD 361. The GPU share went to nothing by the end of the year while the chain prospered. Lesson: the chain can win while its GPU miners lose; Igneum's whole bet is that these two must not separate.
-
-**Grin and Beam.** Both launched in January 2019 into a bear market. Grin scheduled its own GPU lane to die over two years and it did. Beam never had a chip and still lost its miners to the price. Lesson: a launch into a falling market with a thin order book does not get a second chance; the ramp must survive a bad first year.
-
-**Conflux, Firo, Iron Fish.** Three GPU-only hashes with no chip after five to six years, each paying under a dollar a day per card. Lesson: resisting the chip buys the right to be small.
-
-**Alephium.** A sharded chain with a plain Blake3 hash, GPU-mined for about 30 months, then Goldshell shipped a 180 W box in May 2024 and a 1.25 TH/s box five months later. The GPUs were out by autumn and by 2026 the boxes themselves lose money at USD 0.10. Lesson: a chip on a small chain eats the GPUs and then eats itself; the chain gets neither back.
-
-**Nervos.** The extreme case of private hardware. Hashrate rose 10x in 16 days in March 2020, four months after launch and a month before the first ASIC was on sale; a 300-card GPU farm went from USD 410 a day to USD 4.46. Lesson: the first ASIC is always private, and the launch ramp has to assume one.
-
-**Radiant.** Said "GPU/ASIC" in its own announcement title and went to ASIC on schedule in September 2024. Lesson: a chain that invites the chip gets the chip; honest, and not Igneum's path.
-
-**EthereumPoW.** The fork that promised Ethereum mining would continue. The coin traded above USD 140 for a day and under USD 2 by 2025; the pools left for Ethereum Classic within months. Lesson: a fork keeps the code and loses the market; the market is what paid the miners.
-
-**Karlsen, Pyrin, Nomura.** Three kHeavyHash forks launched into the gap the Kaspa chips opened. Karlsen kept its README promise by changing its hash within a year; Pyrin was called a premine scam on launch day; Nomura is a title. Lesson: "the GPU version of X" is a business model with a nine-month half-life.
-
-**Nexa.** Fair launch, CPU first, the top of the profitability tables for a summer, then price. Lesson: being the most profitable coin on WhatToMine for a month is a sell signal, not a community.
-
-**Aleo.** The one chain where mining was proving. The fastest provers took the reward, the pools took the rest, the price fell from USD 9 to USD 3.40 and the GPUs left; the record also shows what miners say when insiders hold the supply. Lesson: Igneum's separation of lottery and proving is the right answer to the first half; the allocation half is answered by having no allocation.
-
-**Flux, Clore, Dynex, Qubic.** Four projects that stopped paying GPUs for hashing and told miners to rent, host or train instead. Flux moved block production to nodes, Clore ended proof of work and pays for rental, Dynex's marketplace never paid, Qubic became a hashrate broker for Monero and then Dogecoin. Lesson: "useful work" projects abandon the miner the day the useful work does not pay; Igneum's proving must be priced to clear (Horizon rank 7) or it is Dynex.
-
-**Vertcoin, Bitcoin Gold, Musicoin.** The three small chains 51 percent attacked by rented hash, between USD 70 k and USD 18 M a time. Each was GPU-only and each was attacked because it was. Lesson: a GPU chain is rentable by definition; finality has to be something hash cannot buy.
-
-**EthereumPoW, TurtleCoin, Akroma, Callisto.** Dead by price, by halt, by abandonment, by a team's money running out. Lesson: a chain with no market is a chain with no miners within a year.
-
-## 2. What GPU miners say they want
-
-Twenty posts and articles read in full or in snippet, 2018 to 2026. Each quote is under 15 words. Reddit threads could not be fetched from this environment, so the miner voice here comes from project forums, pool blogs, bitcointalk snippets and press that quoted miners by name.
-
-| # | Date | Forum or source | Quote | URL |
-|---|---|---|---|---|
-| 1 | 25 Feb 2018 | Zcash forum, user vgm | "Centralized ASIC mining will destroy hobby mining along with any organic user growth potential." | forum.zcashcommunity.com/t/lets-talk-about-asic-mining/27353 |
-| 2 | 25 Feb 2018 | Zcash forum, user JKDC | "Decentralization is as important as privacy." | same thread |
-| 3 | 26 Feb 2018 | Zcash forum, user aoeu | "I'd rather have GPUs for general computation, not silicon trash." | same thread |
-| 4 | 25 Feb 2018 | Zcash forum, user Autotunafish | "Zcash is about universal accessibility, not a select few" | same thread |
-| 5 | 27 Aug 2018 | Grin forum, igno.peverell (launch text) | "A healthy and grassroot GPU mining community at launch is highly desirable." | forum.grin.mw/t/proof-of-work-update/713 |
-| 6 | 30 Nov 2019 | MinerUpdate (RandomX day) | "Honest miners will be fighting an uphill battle against botnets" | minerupdate.com (section 6) |
-| 7 | 21 Mar 2020 | 2Miners blog (Nervos) | "ASICs or FPGA's are to blame for a sudden increase in the hash rate." | 2miners.com/blog/nervos-ckb-network-hashrate-increased-asics-are-the-cause/ |
-| 8 | 9 Apr 2020 | VoskCoinTalk, user Rocky_Bro | "Those 3000watt beasts just eat slower devices for breakfast." | voskcointalk.com/t/.../172 |
-| 9 | 12 Sep 2022 | The Block, Ethan Vera (Luxor) | "You have to have sub $0.03 per kilowatt hour and new generation GPUs." | theblock.co (section 6) |
-| 10 | 12 Sep 2022 | The Block, Mark D'Aria (Bitpro) | "Ethereum is 95% of the total income. Everything else will get crushed." | same article |
-| 11 | 12 Sep 2022 | 2Miners blog, Confessions of a Miner 2 | "When mining makes you lose the money you stop mining." | 2miners.com/blog/confessions-of-a-miner-2-is-this-the-end-of-gpu-mining/ |
-| 12 | Sep 2022 | Hiveon pool, year review | "16% moving to ETC, 7% going to RVN" | hiveon.com/news/reflection-and-forecast-... |
-| 13 | 2023 (approximate) | bitcointalk, "Kaspa asics" thread (snippet) | "Specialized mining equipment optimized for corporate industry raping" | bitcointalk.org/index.php?topic=5449022.0 |
-| 14 | Dec 2023 | bitcointalk, Pyrin ANN thread (snippet) | "another pre-mine scam" | bitcointalk.org/index.php?topic=5476198.0 |
-| 15 | 2023 | bitcointalk thread title | "Why most premined coins (>90% of all altcoins) will eventually fail" | bitcointalk.org/index.php?topic=5457833.0 |
-| 16 | 14 May 2024 | Iron Fish blog (on its own launch) | "unknown origin and hash power" | ironfish.network/learn/blog/2024-05-14-fish-hash-audit |
-| 17 | 2024 | Karlsen README (launch text) | "We will ensure long-term GPU-friendly mining." | github.com/karlsen-network/karlsend |
-| 18 | Sep 2024 | PANews via AiCoin, Aleo community user | "When you don't know where the liquidity comes from, you are the liquidity." | aicoin.com/en/article/419859 |
-| 19 | 31 Jul 2019 | 2Miners blog (delisting) | "Musicoin is dead, Akroma is irrelevant." | 2miners.com/blog/akroma-and-musicoin-delisting/ |
-| 20 | 10 Feb 2026 | Clore blog | "losing money mining with most mid-range GPUs at average electricity rates" | blog.clore.ai/gpu-mining-is-dead-... |
-
-### The three wants, with counts
-
-| Want | Posts asking for it (of 20) | Evidence rows |
-|---|---|---|
-| 1. Hardware that stays useful: no chip, no FPGA, a card that games or computes when the coin dies | 10 | 1, 2, 3, 4, 5, 7, 8, 13, 16, 17 |
-| 2. Income above electricity that does not fall off a cliff | 6 | 9, 10, 11, 12, 19, 20 |
-| 3. A fair supply: no premine, no insider allocation, a coin somebody will buy | 4 | 14, 15, 18, 19 |
-
-### The three hates, with counts
-
-| Hate | Posts (of 20) | Evidence rows |
-|---|---|---|
-| A. Secret hardware on the chain before anyone can buy it | 5 | 7, 8, 13, 16, and Nervos (section 1) |
-| B. Premine, VC allocation, locked airdrops | 3 | 14, 15, 18 |
-| C. The income cliff and the dead market (an exit, a delisting, a 99 percent drawdown) | 5 | 10, 11, 12, 19, 20 |
-
-### Mapped to Igneum's design (horizon-2026-10.md section 1 and the litepaper)
-
-| Want or hate | Status | Mechanism, and the honest gap |
-|---|---|---|
-| Want 1, hardware stays useful | Partly answered | Random-program hash with hourly swaps, 256 MB dataset with 8 dependent reads, era draws from chain state, no scheduled fork (CLAUDE.md design paragraph). The chip model says 2.1x per joule at class v4 and the N ladder is a decision owed (Horizon item 4 and rank 10). Kaspa's chip was 20x to 1,200x; 2.1x is a different world, but a 2.1x chip at scale still ends home mining on power price alone. The gap is the ladder decision and a public chip model per era |
-| Want 2, income without a cliff | Partly answered | 100 IGN a block gliding 2.9 percent a month, no halving day, a 1 percent tail (tail-emission.md). No chain on this list ever had a cliff-free schedule, so this is new. The gap: every exit in section 1 came from price, not schedule, and no protocol sets price. What Igneum can do is publish the per-tier income at three prices before launch (the consequences rule) so nobody buys a card on a number that was never promised |
-| Want 3, fair supply | Answered | No premine, no dev fund, no fee to any team, 90-day ramp from 10 percent (CLAUDE.md, tail-emission.md). Aleo and Pyrin are the counter-examples and Igneum has nothing they had |
-| Hate A, secret hardware at launch | Partly answered | The ramp from 10 percent makes the first 90 days worth less to a private farm; the correlated-group detector and `security_alert` (Horizon rank 16) show it; the hourly program swap means a private FPGA bitstream has to be re-made every hour. Not answered: a private rented GPU fleet is not hardware and is allowed; Nervos's 16-day 10x rise would look the same on Igneum's charts. The gap is a published launch-week hash-origin report (pools, key counts, fleet shares) so the community sees it the day it happens |
-| Hate B, premine and allocations | Answered | As Want 3 |
-| Hate C, the cliff and the dead market | Not answered by protocol | The glide removes the schedule cliff and the proving market gives the coin a buyer other than an exchange (Horizon 4.1a), but a rollup customer paying in dollars is a contract not yet signed (Taiko is the first named customer). Until a customer pays, Igneum has the same exposure as Ergo in 2023: a good hash, a thin market |
-
-One more thing the posts do not say and the record does: nobody on these forums asked for finality, for a DAG, or for proving. They asked for a card that keeps its value, a bill that gets paid, and a coin that sells. Igneum's technical answers are to questions miners did not ask; the mission should put the three wants on the front page and the finality on page two.
-
-## 3. The earnings curve as a pattern
-
-USD per card per day before electricity. A 3080 draws about 220 W, so electricity at USD 0.10 per kWh is USD 0.53 a day; a 4090 at 400 W is USD 0.96. Where a figure is approximate it says so.
-
-| Chain | Launch | Peak month | Peak income (per 100 MH Ethash or per 3080 equivalent) | Month income fell under power at USD 0.10 | Hashrate that left in the next 90 days |
-|---|---|---|---|---|---|
-| Ethereum | Jul 2015 | Jan 2018, then May 2021 | USD 23 per 100 MH (Jan 2018, USD 0.233 per MH); approximate USD 12 to 15 per 3080 in May 2021 | Never for a 3080 before the Merge (approximate USD 1 to 2 a day in Sep 2022, over power); the lane closed 15 Sep 2022 | 100 percent of Ethereum's 900 TH/s; of the GPUs, about a quarter tried ETC and half of those left inside four days (CoinDesk, AMBCrypto); approximate 80 percent of the cards were off within 90 days |
-| Kaspa | Nov 2021 | Feb to Mar 2023 (approximate) | Approximate USD 2 to 3 per 3080 | Approximate Sep to Oct 2023 (a 3070 was at USD 1.21 in Apr 2023 as the first ASICs landed) | GPU share from near 100 percent to under 10 percent by Dec 2023 (approximate); the network's total hashrate rose the whole time |
-| Ergo | Jul 2019 | Sep to Nov 2021 | Approximate USD 3 to 4 per 3080 | Approximate Nov to Dec 2022 (the Merge took hashrate from 22 to 155 TH/s in a day) | Approximate 50 to 70 percent of the post-Merge peak within 90 days |
-| Ravencoin | Jan 2018 | Feb to Apr 2021 | Approximate USD 6 to 8 per 3080 | Approximate Nov 2022 (the FTX month); a 3080 now loses USD 0.13 to 0.31 a day | Approximate 40 percent of the post-Merge peak (15.9 TH/s) within 90 days |
-| Aleo | Sep 2024 | Sep 2024 | USD 13.50 per 4090 at USD 9 (PANews) | Approximate Q1 2025 as the price reached USD 3.40 and difficulty followed the pools | "Difficulty plummeted ... as miners exited" (PANews); approximate over 50 percent of GPU provers within 90 days of the token-economics reveal |
-
-What the curve means per tier (the consequences rule), using the record's ratios rather than a price nobody can promise:
-
-| Tier | What the record says happens to them | What Igneum should tell them before launch |
-|---|---|---|
-| Home miner, one 8 or 12 GB card | First under power in every exit (the 3060 lost money on Clore's 2026 table while the 4090 still cleared) | Income per card at three prices, and that the glide never halves it overnight; the card keeps gaming when the income goes |
-| Home miner, one 16 to 32 GB card | Last GPU standing; still under power 6 to 18 months after a peak on every chain in the table | The proving pool is the second income for this tier only; say so, with the measured 15.6 GB profile |
-| Rig (6 to 12 cards) | Followed income across chains inside days (Hiveon: 16 percent to ETC, 7 percent to RVN) and shut down inside 90 days | Rig income at three prices; no loyalty expected, none needed, the 30-day weight pays staying miners a vote |
-| Pool user | Took the pool's choice of chain and the pool's fee; pools held 29 percent of Aleo proving at launch | Which pools carry the finality signer, and that a pool's vote is the user's weight (ledger G8) |
-
-The common shape, in numbers: income peaks inside one to six months of a price run or a migration, halves within 60 to 120 days as difficulty catches the price, and falls under power within six to eighteen months of the peak; when it does, 50 to 100 percent of the GPU hashrate leaves inside 90 days. The trigger was a chip twice (Kaspa, and ETC's second decline), a scheduled exit once (Ethereum), and the price three times (Ergo, Ravencoin, Aleo). In no case did a GPU lane recover its peak income after the exit.
-
-## 4. Verdict table
-
-| # | Lesson | Evidence (chain, year) | What Igneum does today | Gap | What the mission should add or change |
-|---|---|---|---|---|---|
-| 1 | A compute-bound hash goes to a chip in 16 to 37 months, and the first chip is private | Litecoin 2014, Zcash 2018, Nervos 2020, Kaspa 2023, Alephium 2024 | Random-program hash, 256 MB dataset, latency shadow, era draws; chip model 2.1x at class v4 (Horizon item 4) | Small | Decide the N ladder at genesis and publish the chip model with every era draw; nothing else |
-| 2 | Secret hardware or fleets show up as an unexplained hashrate step in the first weeks | Nervos 2020 (10x in 16 days), Iron Fish 2023, Kaspa 2023 | 90-day ramp from 10 percent; correlated-group detector and `security_alert` (Horizon rank 16) | Small | A public launch-week hash-origin report (key counts, pool shares, fleet shares) from the observer, daily for the first 90 days |
-| 3 | Hash forks by hand lose miners and add bugs; the client is the next failure | Monero 2018 to 2019 (85 percent gone per fork), Vertcoin 2018 to 2019, Ravencoin Aug 2026 (header flaw) | No scheduled human fork; era draws from chain state; 95 percent signalling with a floor; Devnet 2 gate | Large on the client | The second independent client is the item; until then a fuzz gate on header and PoW validation paths equal to the sync-request fuzz (Horizon rank 9) |
-| 4 | Income cliffs empty a chain in days; miners follow income with no loyalty | Ethereum Sep 2022 (94 percent of income gone), ETC -48 percent in four days, Aleo Q4 2024 | Monthly glide, no halving day, 1 percent tail (tail-emission.md) | Small on schedule, large on price | Publish per-tier income at three prices (USD 0.005, 0.02, 0.10) in the litepaper before the testnet, per the consequences rule; nothing in protocol |
-| 5 | Premine and insider allocation drive GPU miners out faster than any chip | Aleo 2024, Pyrin 2023 | No premine, no dev fund, no fee to any team | None | Nothing |
-| 6 | A GPU chain is rentable; rented hash reorganised three of them for USD 70 k to USD 18 M | Bitcoin Gold 2018 and 2020, Vertcoin 2018 and 2019, Musicoin 2019 | Miner-only finality on 30 days of blocks; 20 days of 100 percent hash to reach 2/3 (CLAUDE.md) | Small after day 20, large before | Weight-gated deep fork choice (Horizon rank 4) covers the first 20 days; ship it before mainnet, not after |
-| 7 | A coin with no market dies within a year whatever the hash does | Musicoin 2019, Akroma 2019, TurtleCoin 2023, Grin (USD 16 k daily volume), Nexa | Proving sold in dollars, settled in IGN (litepaper); Taiko named as first customer | Large until a customer pays | A signed proving customer before mainnet is a launch gate, with the same weight as the Devnet 2 gate; decouple the job price from `f_p` (Horizon rank 7) so the first job can clear |
-| 8 | Useful-work projects drop the miner the day the work does not pay | Dynex 2024, Flux 2025, Clore 2025, Qubic 2025 to 2026 | The lottery pays 80 percent of every block whatever the proving market does; proving is the second income, never the only one | None by design | Write the sentence into the litepaper: "A block pays its miner whether or not anyone buys a proof that day" |
-| 9 | Random-program hashes keep GPUs for five years and more, and still pay under a dollar a card | Ravencoin 2020 to 2026, Firo, Conflux, Iron Fish | The hash is Igneum's strongest answer | None on the hash | Stop presenting the hash as the reason to mine; present income, fairness and the second income (section 2's three wants) first |
-
-## 5. Headline findings for the coordinator
-
-1. Of the 31 rows (33 chains) that paid GPU miners since 2011, 8 lost the GPU lane to a chip, 7 closed it by their own choice (Dogecoin, Ethereum, Monero, Grin, Flux, Clore, Qubic), 10 died or went dormant on price, rental attacks or abandonment, and the 6 still GPU-only (Ravencoin, Ergo, Firo, Conflux, Iron Fish, Beam) pay USD 0.22 to 0.71 a day per RTX 3080 before power, so the hash keeps the miner and not the income.
-2. In 20 miner posts and launch texts read, 10 asked for hardware that keeps its value, 6 for income above electricity without a cliff and 4 for a fair supply; Igneum answers the fair supply in full, the hardware in part (a 2.1x chip model with the N ladder still owed), and the income only on schedule, since every GPU exit in the record except two came from price.
-3. The earnings curve has one shape across Ethereum, Kaspa, Ergo, Ravencoin and Aleo: income halves within 60 to 120 days of the peak, falls under USD 0.10 per kWh within 6 to 18 months, and 50 to 100 percent of GPU hashrate leaves inside 90 days of that, so the launch plan needs a signed proving customer and published per-tier income at three prices before the first miner buys a card.
-
-## 6. Sources (all accessed 7 October 2026 unless noted)
-
-Project and pool sources
-- Zcash forum, "Let's talk about ASIC mining", Feb 2018: https://forum.zcashcommunity.com/t/lets-talk-about-asic-mining/27353
-- Grin forum, "Proof of work update", 27 Aug 2018: https://forum.grin.mw/t/proof-of-work-update/713
-- 2Miners, Nervos hashrate and ASICs, 21 Mar 2020: https://2miners.com/blog/nervos-ckb-network-hashrate-increased-asics-are-the-cause/
-- 2Miners, Akroma and Musicoin delisting, 31 Jul 2019: https://2miners.com/blog/akroma-and-musicoin-delisting/
-- 2Miners, End of Ethereum mining, 30 Aug 2022: https://2miners.com/blog/end-of-the-ethereum-mining-when-what-to-mine-next-with-gpu-transition-to-pos-explained/
-- 2Miners, Confessions of a Miner 2, 12 Sep 2022: https://2miners.com/blog/confessions-of-a-miner-2-is-this-the-end-of-gpu-mining/
-- 2Miners, How to mine Kaspa with ASIC and GPU, 14 Apr 2023: https://2miners.com/blog/how-to-mine-kaspa-with-asic-and-gpu-settings-extra-rewards-dual-mining/
-- 2Miners, July 2023 report (Nexa, Kaspa KS0 port): https://2miners.com/blog/july-2023-work-progress-report-new-coin-nexa-kaspa-geo-servers/
-- 2Miners, KawPoW fork, May 2020: https://2miners.com/blog/kawpow-new-ravencoin-mining-algorithm/
-- Hiveon, PoW to PoS notes, 24 Aug 2022: https://hiveon.com/news/the-pow-and-pos-transition-important-notes/
-- Hiveon, 2022 review (16 percent ETC, 7 percent RVN): https://hiveon.com/news/reflection-and-forecast-reviewing-the-events-of-2022-and-anticipating-the-year-ahead/
-- VoskCoinTalk, Antminer K5 impressions, 9 Apr 2020: https://voskcointalk.com/t/initial-impressions-of-the-bitmain-antminer-k5-nervos-ckb-eaglesong-asic-miner-mining-22-a-day/172
-- Iron Fish, FishHash audit and the reason for the switch, 14 May 2024: https://ironfish.network/learn/blog/2024-05-14-fish-hash-audit
-- Iron Fish, hard fork 1 activation, 2 Apr 2024: https://ironfish.network/learn/blog/2024-02-26-mainnet-hardfork
-- Karlsen README: https://github.com/karlsen-network/karlsend
-- hashrate.no, Karlsen and Pyrin algorithm change, 13 Sep 2024: https://www.hashrate.no/c/Algorithm_change_for_Karlsen_and_Pyrin
-- hashrate.no, RTX 3080 today (top coins and USD per day): https://hashrate.no/gpus/3080
-- hashrate.no, Kaspa network (347 PH/s): https://www.hashrate.no/coins/KAS
-- hashrate.no, Aleo pools (f2pool 28.9 percent): https://www.hashrate.no/coins/ALEO/pools
-- RunOnFlux, Proof of Useful Work v2, 23 Oct 2025: https://runonflux.com/forking-flux-proof-of-useful-work-v2/
-- Clore changelog (PoW end, Dec 2025): https://clore.ai/changelog
-- Clore blog, GPU mining is dead, 10 Feb 2026: https://blog.clore.ai/gpu-mining-is-dead-gpu-hosting-is-the-future-heres-how-to-earn-500month/
-- Qubic blog, mining evolution, 30 Jun 2025: https://qubic.org/blog-detail/qubic-mining-evolution-from-cpu-roots-to-gpu-dominance-and-back-again
-- Qubic blog, Dogecoin mining on Qubic: https://qubic.org/blog-detail/qubic-dogecoin-mining-how-it-works
-- TurtleCoin v2 FAQ (halt at block 5,500,000, 15 Mar 2023): https://hackmd.io/@iburnmycd/rJzyWD3-_
-- Callisto history (2024 collapse): https://www.callisto-pirl.com/history
-- bitcointalk, Kaspa ANN: https://bitcointalk.org/index.php?topic=5373286.0 (403 on fetch; title and snippet via search)
-- bitcointalk, "Kaspa asics": https://bitcointalk.org/index.php?topic=5449022.0 (snippet only)
-- bitcointalk, Pyrin ANN: https://bitcointalk.org/index.php?topic=5476198.0 (snippet only)
-- bitcointalk, Karlsen ANN: https://bitcointalk.org/index.php?topic=5475216.0 (snippet only)
-- bitcointalk, "Why most premined coins will eventually fail": https://bitcointalk.org/index.php?topic=5457833.0 (title only)
-- asicminervalue, Antminer KS7: https://www.asicminervalue.com/miners/bitmain/antminer-ks7-40th
-- asicminervalue, Goldshell E-AL1M (negative at USD 0.10): https://www.asicminervalue.com/miners/goldshell/e-al1m
-- asicminervalue, Ethereum Classic: https://www.asicminervalue.com/coins/etc-ethereum-classic
-- minerstat, Grin: https://minerstat.com/coin/grin_cuckatoo32
-- WhatToMine, Ravencoin on RTX 3080 LHR: https://whattomine.com/coins/234-rvn-kawpow/gpus/63-nvidia-geforce-rtx-3080-lhr
-- Binance Research, merged mining case study: https://www.binance.com/en/research/analysis/merged-mining
-- litecoin.watch, scrypt history: https://litecoin.watch/articles/understanding-the-scrypt-mining-algorithm
-
-Press and papers
-- CoinDesk, ETC and RVN hashrate after the Merge, 15 Sep 2022: https://www.coindesk.com/tech/2022/09/15/ethereum-classic-and-ravencoins-hashrate-nearly-doubles-after-merge
-- AMBCrypto, ETC post-Merge high wearing off, 19 Sep 2022: https://ambcrypto.com/why-ethereum-classics-etc-post-merge-high-is-wearing-off/
-- crypto.news, ETC hashrate +280 percent: https://crypto.news/ethereum-classic-hashrate-jumped-280-post-merge/
-- Decrypt, ETC, RVN and ERG hashrate soar, Sep 2022: https://decrypt.co/109803/ethereum-classic-ravencoin-ergo-hash-rate-soar-post-merge
-- The Block, what is left for GPU miners, 12 Sep 2022: https://www.theblock.co/news/ecosystems/2022-09-12-whats-left-for-ethereum-gpu-miners-after-the-merge-168380
-- Tom's Hardware, GPU mining unprofitable after the Merge (900 TH/s, about 20 million GPUs): https://www.tomshardware.com/news/gpu-mining-is-now-unprofitable
-- Wccftech (Minerstat figures, RTX 3080 USD 6.35 to 9.15 a day, early 2021): https://wccftech.com/rgb-lit-bitcoin-mining-rig-78-geforce-rtx-3080-graphics-cards-comes-operational/
-- FXStreet, Ethereum miners in the red (USD 0.233 per MH per day in Jan 2018), 29 Mar 2018: https://www.fxstreet.com/amp/cryptocurrencies/news/ethereum-price-analysis-eth-usd-eyes-40000-amid-cryptocurrency-sell-off-miners-are-deep-in-red-201803290719
-- MinerUpdate, CPU mining dominates Monero since RandomX, 30 Nov 2019: https://www.minerupdate.com/news/miner-insights/cpu-mining-dominates-monero-since-randomx-upgrade
-- Bitcoin Magazine, Antminer Z9 mini, May 2018: https://bitcoinmagazine.com/business/bitmains-antminer-z9-mini-designed-mine-zcash-threatens-asic-resistance
-- 2Miners, Zcash mining and profitability (1080 Ti at USD 8 in Jul 2017, USD 2.63 on 6 May 2018): https://2miners.com/blog/how-to-mine-zcash-zec-mining-and-profitability/
-- Medium (Blockwise), the end of GPU mining (Monero April 2018 fork halved hashrate): https://medium.com/blockwise/the-end-of-gpu-mining-a702921fc1e1
-- crypto.news, Ravencoin consensus flaw, 11 Aug 2026: https://crypto.news/ravencoin-falls-as-consensus-flaw-splits-network/
-- Decrypt, the long collapse of Bitcoin Gold: https://decrypt.co/47381/the-long-collapse-of-bitcoin-gold
-- metalicjames gist, Bitcoin Gold Jan 2020 attack: https://gist.github.com/metalicjames/71321570a105940529e709651d0a9765
-- metalicjames gist, Vertcoin Dec 2018 attack: https://gist.github.com/metalicjames/f2acdb9ef448ec5298173b36c7c54133
-- news.bitcoin.com, Vertcoin second attack, Dec 2019: https://news.bitcoin.com/vertcoin-network-sabotaged-by-another-51-attack/
-- Binance Square, BTG delisting 1 Sep 2024: https://www.binance.com/en/square/post/12128321695753
-- AiCoin (PANews), Aleo mainnet, miners cry foul, Sep 2024: https://www.aicoin.com/en/article/419859
-- Aleo, mainnet announcement, 18 Sep 2024: https://aleo.org/post/announcing-aleo-mainnet/
-- The Block, Monero reorg fears after Qubic's 51 percent claim, 12 Aug 2025: https://www.theblock.co/post/366535/monero-faces-chain-reorganization-fears-after-qubic-says-it-controls-51-of-hashrate
-- Lee and Kim, Inside Qubic's selfish mining campaign on Monero, arXiv 2512.01437, AFT 2026: https://arxiv.org/abs/2512.01437
-- Decrypt, Qubic mining Dogecoin, Apr 2026: https://decrypt.co/363018/qubic-the-network-that-captured-51-of-monero-is-now-mining-dogecoin-on-its-ai-compute-infrastructure-live
-- CoinGecko, Dynex (99.9 percent below ATH): https://www.coingecko.com/en/coins/dynex
-- Medium (crypto-blog), Dynex the most GPU mined coin, Oct 2023: https://medium.com/crypto-blog/dynex-dnx-seems-to-be-the-most-gpu-mined-coin-at-the-moment-cdf7d30c433a
-- KuCoin, ETHW price history: https://www.kucoin.com/price/ETHW
-- Kryptex, IceRiver KS series: https://pool.kryptex.com/articles/iceriver-ks0-ks1-ks2-ks3-ks3l-en
-- Medium (VoskCoin), Was Kaspa mining worth it (KS0 USD 25 a day, Jul 2023): https://medium.com/voskcoin/was-kaspa-mining-worth-it-ca3ac9ff7566 (403 on fetch; figures via search snippet)
-
-Internal
-- `docs/analysis/asic-resistance-history.md` (5 Oct 2026)
-- `docs/analysis/horizon-2026-10.md` section 1 and ranks 4, 7, 9, 10, 16 (6 to 7 Oct 2026)
-- `docs/analysis/horizon/economy-and-utility.md` section 4.6
-- `docs/analysis/tail-emission.md`, `docs/analysis/vote-or-burn.md`
-
-Not reachable from this environment (recorded so the coordinator can fetch by hand): reddit.com (all subreddits), bitcointalk.org thread bodies, web.archive.org, the Springer paper "The PoW Landscape in the Aftermath of The Merge" (login wall), statista's Ethereum profitability series (paywall), bitinfocharts chart values (rendered client-side).

docs/analysis/mission/reinvent.md

@@ -1,446 +0,0 @@
-# Mission lane 5: what can be reinvented. The miner's experience
-
-Date: 7 October 2026, UK time. Lane 5 of the last mission. Written in the mission worktree; this file is the only output. Nothing was built, measured, posted or started; the live devnet was not touched.
-
-The founder's words that this lane holds: "revolutionise the mining itself"; "dopamine for GPU miners everywhere, a structure that makes the mining commodity fall in love with the project"; "the perfect gpu network that will be noticed as the revolution that everyone is waiting for". Bounds that this lane obeys: no premine, no dev fund, no treasury, no token sale, no airdrop, no referral paid in coins; every coin is mined under the rules that exist (the 80/20 split, the signing bonus of 8 of the 80 producer points, the proving pool); no stake; no device bounty; the three signalling thresholds (60, 90, 95); miners are the security always; gates, not dates; hours are agent hours.
-
-## 0. Progress
-
-| Time (UK) | State |
-|---|---|
-| 08:46 | Rules read: CLAUDE.md, polish.md sections 1, 3.1, 3.2, 3.4, 3.6, 3.7, 3.10, 4.5; litepaper miner sections; vote-or-burn section 5; tail-emission one page; horizon one page; ledger decisions 3, standing, 6 and 7 October; pool.md; miner-ui-3 and its audit; testnet-go; the dev fee; the Discord kit; the Reddit kit (branch reddit-kit); journey.json |
-| 09:05 | Three research sub-lanes launched: Reddit post sample, chain histories, pool and install facts. The third refused by the concurrency limit; its topics done by hand with WebFetch. The session's WebSearch budget was already spent by other lanes, so every outside fact below comes from a fetched page or is labelled approximate |
-| 08:52 | Igneum maths computed (scratch `mission-reinvent/igneum-maths.txt`, `tiers.txt`): solo block expectations per tier at 100 GH/s and 1 TH/s, the vote dust line, the signing bonus per day |
-| 09:04 | Sections 3 to 8 drafted; 1.1 and 2 waiting on the sub-lanes |
-| 09:10 | Section 1.1 and headline 3 written from `reddit-sample.md` (105 posts, 69 with a room median) |
-| 09:13 | Section 2 and the sources written from `chains.md` (seven chains, hashrates derived from explorer APIs at dated heights) |
-| 09:15 | Done: 0 em dashes by grep, no placeholders, 446 lines; the three findings sent to the coordinator |
-
-## 1. The dopamine loop of a GPU miner, from data
-
-### 1.1 What the archives say
-
-Method (the sub-lane's file, scratch `mission-reinvent/reddit-sample.md`): 105 posts picked by hand from the top-of-all-time listings of r/EtherMining, r/gpumining, r/chia, r/ravencoin, r/MoneroMining, r/Monero, r/HeliumNetwork (2021 to 2022), r/kaspa and r/erg_miners (r/ErgoMining is an empty shell whose top post points to r/erg_miners), plus six bitcointalk "first block" posts from 2011 to 2017 through the ninjastic archive. Each post's score is the value Reddit served on 7 October 2026. The subreddit median for the post's year is estimated from three half-month samples of the Arctic Shift archive (approximate; the typical post in these rooms scores 1 to 4 points, so the ratios are large and describe how far the best joy posts rise above an ordinary post). 69 of the 105 rows have a ratio; r/MoneroMining and r/erg_miners have no archive sample.
-
-| Post type | Rows with a ratio | Median score | Median ratio to the room's typical post | Range | Best example (score, date, URL) |
-|---|---|---|---|---|---|
-| f. "My card paid for itself" (ROI, break-even) | 6 | 777 | 777x | 493x to 1,367x | solar panels paid for by mining, 1,367 points, 16 May 2021, https://www.reddit.com/r/gpumining/comments/ndduuu/ |
-| g. The community meme | 11 | 710 | 739x | 81x to 2,054x | "New miners be like...", 2,054 points, 19 Apr 2021, https://www.reddit.com/r/EtherMining/comments/mu3jgh/ |
-| c. The rig photo | 13 | 361 | 417x | 48x to 2,923x | "Rate my new build", 2,923 points, 3 Mar 2021, https://www.reddit.com/r/EtherMining/comments/lwpudz/ |
-| d. The hashrate milestone | 7 | 324 | 409x | 95x to 672x | "What 1GH looks like", 672 points, 8 Apr 2021, https://www.reddit.com/r/EtherMining/comments/mmybn2/ |
-| e. The profit screenshot, "X per day" | 7 | 234 | 234x | 48x to 593x | "I finally mined a full Ethereum today", 593 points, 21 Jul 2021, https://www.reddit.com/r/EtherMining/comments/ootl28/ |
-| a. First block found solo | 8 (plus 6 bitcointalk rows with no score) | 233 | 119x | 46x to 762x | "Tried Solo Mining ETH as an Experiment, Ended up Hitting a Block", 762 points, 3 Jun 2021, https://www.reddit.com/r/EtherMining/comments/nr13be/ |
-| h. "We did it", the network milestone (ATH, listing, hotspot count, halving) | 12 | 214 | 66x | 12x to 305x | Helium's first telecom deal, 305 points, 26 Oct 2021, https://www.reddit.com/r/HeliumNetwork/comments/qg9o6g/ |
-| b. First payout | 5 | 173 | 56x | 43x to 478x | "I made my first bitcoin penny", 478 points, 8 Mar 2021, https://www.reddit.com/r/gpumining/comments/m0emml/ |
-| all | 69 | 256 | 297x | 12x to 2,923x | |
-
-What the ranking says. The posts that rise highest are about the miner, not the network: the card that paid for itself (777x), the rig in a photo (417x), the personal hashrate milestone (409x). The network's own milestone, the thing a project would post, sits near the bottom (66x). The first solo block is the strongest single feeling in the quotes and a middling score (119x), because it is rare; the first payout is the lowest (56x), because on a pool it is routine. Chia's first-block posts are the exception that proves it: on a chain where the first win took weeks of plotting, "It finally happened! I never thought this day would come" scored 615 (19 May 2021, https://www.reddit.com/r/chia/comments/ngevxy/), 308x its room's median. The Monero room shows the same feeling at every size of CPU: "After 271 days and 101 Billion Hashes, I Finally Mined my First Monero" (128 points, 20 Nov 2020, https://www.reddit.com/r/MoneroMining/comments/jxxwzo/).
-
-Quotes (verbatim, with the sub-lane's dates and URLs; all accessed 7 October 2026):
-
-| Quote | Where | Date |
-|---|---|---|
-| "GUYZ! I DID IT! I FINALLY WON!!" | r/chia title, https://www.reddit.com/r/chia/comments/myaizh/ | 25 Apr 2021 |
-| "cries in 17TiB with 0 xch" | top comment on the same post | 25 Apr 2021 |
-| "380 MH/s, about 24 hours total time mining. Very, very lucky." | r/ravencoin, https://www.reddit.com/r/ravencoin/comments/pnfl4y/ | 13 Sep 2021 |
-| "That's crazy. Now all of us pool miners are going to think hmm." | r/EtherMining, https://www.reddit.com/r/EtherMining/comments/nr13be/ | 3 Jun 2021 |
-| "1 GH/s and disappointed parents achieved!" | r/gpumining title, https://www.reddit.com/r/gpumining/comments/okexp4/ | 14 Jul 2021 |
-| "Love solo mining its the best." | r/MoneroMining, https://www.reddit.com/r/MoneroMining/comments/1uexakh/ | 25 Jun 2026 |
-| "I just solo mined my first block ever! :3 Feels good." | bitcointalk, https://bitcointalk.org/index.php?topic=619210.msg6866375#msg6866375 | 22 May 2014 |
-| "Mind blown." | bitcointalk, first reply to "just found my first block", https://bitcointalk.org/index.php?topic=338903.0 | 19 Nov 2013 |
-
-Consequence for Igneum, by surface: the shareable thing must be the miner's own object (the block card with the card's name on it, the rig's row on the census, the weight rank), never the project's milestone; the ROI post cannot exist without a price, so its stand-in at the testnet is the line "N IGN per kWh" and the days-mined ring; and the solo first block must stay reachable for the common tier, which is the reason the Poisson line and the pool switch sit on the same screen (section 3.2).
-
-### 1.2 Time to the first hit on each chain
-
-| Chain, year | First hit | Measured or estimated time from install | Source |
-|---|---|---|---|
-| Ethereum 2017, pool (Ethermine, Nanopool) | first share accepted, worker on the dashboard | share within seconds of the first job; worker visible in 1 to 10 minutes; first payout at 0.05 ETH took one GTX 1070 about 2 to 3 weeks in mid 2017 (approximate) | approximate, from memory of the pool pages |
-| Ethereum 2017, solo | first block | a 30 MH/s card against 60 TH/s: one block in about 2 million blocks, 1 year or more; nobody did it (approximate) | approximate |
-| Kaspa, launch day 8 Nov 2021, solo | first block | the network was 3.4 MH/s on 8 Nov 2021 (derived from the header bits, `chains.md`), so one 2021 card found blocks within minutes; at 2.86 TH/s six months later the same card needed a pool | https://api.kaspa.org/blocks-from-bluescore?blueScore=100000 (7 Oct 2026) |
-| Kaspa 2022, pool (2miners) | first share; payout at 50 KAS every 2 hours | share in seconds; payout the same day for a 1 GH/s card in 2022 (approximate); 2miners: "Payouts are processed automatically every 2 hours", minimum 50 KAS | https://2miners.com/faq and https://kas.2miners.com/ (7 Oct 2026) |
-| Monero 2019, p2pool (from 2021) | a share in the PPLNS window, paid at the next pool block | p2pool: "It can take several days to a week to find a share if your hashrate is low"; min payout 0.00027 XMR | https://p2pool.io/ (7 Oct 2026) |
-| Chia 2021 | the first plot finished (the hit was the plot, not the coin) | 6 to 12 hours a plot on a consumer SSD; the expected solo win on 10 TB at 5 EiB netspace was months (approximate) | r/chia posts of May 2021 (section 1.1); approximate |
-| Helium 2021 | the hotspot on the map, the first beacon, "HNT per day" in the app | hours after power-on, days to weeks of waiting for the device itself (the r/HeliumNetwork top post of 2021 is a photo of a miner six months after ordering, section 1.1) | section 1.1 |
-| Ravencoin 2018, solo | first block, 5,000 RVN | on launch day any card found blocks in minutes (approximate) | approximate |
-| Igneum devnet, 2026 | first accepted block, shown in the app's event feed | an Apple silicon laptop through the DMG: first block "within the first minutes", 33 accepted blocks in 7 minutes; an RTX 5090 through the Windows installer: 34 accepted blocks in the first minute once the clock was right | `docs/bench-log.md` 4 October 2026 (the first outside machine; the three-card rig) |
-
-### 1.3 The loop
-
-| Stage | What it is for a miner | Evidence |
-|---|---|---|
-| Trigger | a number moved: a block, a payout, a hashrate tick, a chart on the explorer, a post in the feed | the post types that score highest are all "a number moved and here is the screenshot" (section 1.1) |
-| Action | open the app, the pool page, the explorer, the Discord; refresh | the daily ritual on every chain in section 2 |
-| Variable reward | blocks are a Poisson draw; the payout varies; the post's upvotes vary; luck is the word every pool shows | 2miners shows "luck 441%" and "last block 2 minutes ago" on the pool's front page (https://kas.2miners.com/, 7 Oct 2026) |
-| Investment | a rig built, plots made, a key aged, a reputation in the room, a name on a board | Chia's plots, Helium's named hotspot on the map, the EtherMining rig-photo post (section 1.1) |
-
-Igneum has one investment no other chain has: the vote key's 30-day window. A key that mined for 30 days weighs more than the same hashrate that appeared yesterday, and that weight signs finality. That is a level system written into consensus, and section 3.7 builds the ladder on it.
-
-### 1.4 The five moments on Igneum, and the time to each today
-
-Computed at 1 block a second, the producer share of 80 points, 100 IGN a block at full rate. The network size is the variable: the first 1,000 miners at the measured median card (about 25 MH/s, section 3.8) are about 25 GH/s; 100 GH/s is the litepaper's example; 1 TH/s is where the loop breaks for solo cards. Full tables per tier: section 3.8 and scratch `tiers.txt`.
-
-| Moment | Solo, 100 MH/s on 100 GH/s | Solo, 17 MH/s (8 GB) on 100 GH/s | Pool member, any card | Where it is shown today | Where it should be shown |
-|---|---|---|---|---|---|
-| 1. First share or first block | first block: expected gap 16.7 min, 97 percent within the first hour | 1.6 h expected, 46 percent within the first hour | first share: vardiff starts at one share per 10 s and the first correction is sized from the measured rate (`pool.md` section 2), so under a minute after the first job; before that the node sync and the dataset build (measured: the devnet laptop's first block "within the first minutes") | the event feed and the blocks strip (`app.js:1052-1127`) | the block card of section 3.3 |
-| 2. First payout | the coinbase of the first block, credited by the execution layer when the block is blue; so the payout is the block, seconds later | the same | PPLNS credit on blue confirmation; a payout round every 60 s (`pool/src/config.rs:61`), minimum 1 IGN; an 8 GB member at 100 GH/s earns 1 IGN in about 73 s, so the first payout lands inside two minutes of the first share | Earnings reads "£0.00 earned" and never shows mined IGN (Q18) | Earnings as section 3.4 |
-| 3. First proof shard paid | shards are assigned by lot to eight provers for ten seconds; 388 shards and 446.13 IGN paid on 5 October (the Discord kit's start-here text); on a 24 GB NVIDIA card today, 12 GB cards with the patched prover measured not shipped | not available on 8 GB today (core-only proving measured, `prover-tiers-real-cards.md` rows 4060) | proving income never passes through the pool (C6) | Prove tab state line "0 proven · 0 paid" | "your card proved shard N of block M" as a card, section 3.7 |
-| 4. First vote (the key above dust, 100 blocks in the 30-day window) | 1.2 days | 6.8 days | the member's own blocks carry its key (`pool.md` section 2, Votes), so the same days as solo for the same card; a member without a node has no vote (spec 09 9.7) | nothing: the app never says whether the key votes | "your key has a vote" card, the ladder rung 1 |
-| 5. First signature in a certified checkpoint, then the full window | the first checkpoint after the key enters the table (one checkpoint is 30 s; a young key counts as present); the full window at day 30 | the same; full window at day 30 | the same | nothing | "your signature is in checkpoint K" and "30 of 30 days" |
-
-The consequence of the dust line, per tier (the standing rule of 5 October): at 100 GH/s every tier reaches a vote inside a week; at 1 TH/s a single 8 GB card finds 44 blocks in 30 days and never reaches 100, so it never votes, and the pool does not help because weight follows the member's own found blocks. The 12 GB RTX 4070 reaches 65, also under. The RTX 5090 reaches 255. So past about 500 GH/s the "your key has a vote" rung is out of reach for the cards most of the first 1,000 miners own, and the X5 gate (1,000 independent keys above dust) gets harder as the network grows. This lane does not touch the constant; it hands the finality lane the question in section 8 and keeps the ladder's first rungs (first block, first payout, first shard, 30 days mined) reachable for every tier at any network size.
-
-## 2. The product structures that made miners fall in love
-
-Method (the sub-lane's file, scratch `mission-reinvent/chains.md`): hashrates derived from block difficulty at dated heights through each chain's public explorer API (Ergo, Monero, Ravencoin, Kaspa) or Etherscan's daily CSV (Ethereum); Helium and Chia from their own HIPs, blog posts and release notes; prices from CoinGecko. Every URL opened on 7 October 2026. "Approximate" marks a figure from memory. Hash units differ across forks and are not compared across them.
-
-### 2.1 The hook, the ritual, the proof, the ladder, the story
-
-| Chain | Hook | Daily ritual | Social-proof surface | Status ladder | The story a miner told |
-|---|---|---|---|---|---|
-| Helium 2019 to 2021 | a USD 500 box on the windowsill mines by giving radio coverage | the app or explorer.helium.com: the hotspot's 24-hour HNT, witnesses, "relayed" | the explorer hex map; every hotspot a dot with a three-word name; "the map was the product" | none formal: "first in my city" on the map, maker badges in Discord, validators from 2021 (approximate) | HIP 10's own example: a hotspot "which has earned approximately $21,000 worth of HNT by purchasing $145 worth of DC" (https://github.com/helium/HIP/blob/main/0010-usage-based-data-transfer-rewards.md) |
-| Chia 2021 | farm on drives you already own; "green Bitcoin" from the BitTorrent inventor | the GUI's netspace and "estimated time to win"; plots finishing; then the pool page | the netspace chart (chiaexplorer, xchscan); the pool leaderboard | plot count and TiB; "OG plots" against portable plots (approximate beyond that) | "It finally happened! I never thought this day would come" (section 1.1); the other side: "cries in 17TiB with 0 xch" |
-| Ethereum 2017 | the gaming PC prints money while you sleep | WhatToMine with your card list, the pool's unpaid balance and graph, the overclock | the pool's worker list and "estimated earnings"; YouTube rig builds; the GPU price chart | rig size (6, 8, 12 cards), hashrate, the "paid off" post (approximate) | "In Feb this subreddit told me it was too late and I'd never ROI" (893 points, 1 Aug 2021, https://www.reddit.com/r/EtherMining/comments/ovvaah/) |
-| Kaspa 2022 | "No premine. No hidden allocation. Fair launch." (https://kaspa.org/) | miningpoolstats.stream, the pool dashboard, Discord #mining | the miningpoolstats hashrate chart and pool count | Discord roles for early miners and pool operators (not verified, approximate) | "I mined six figures of KAS on two GPUs at a tenth of a cent" (approximate, the room's tone) |
-| Monero RandomX 2019 | any CPU, even a laptop, mines again; RandomX "optimized for CPUs" (https://www.getmonero.org/resources/moneropedia/randomx.html) | the xmrig console, the pool page, the electricity maths | the RandomX README benchmark table (i9-9900K 5,770 H/s, Ryzen 7 1700 4,100, i3-3220 510, Raspberry Pi 3 20; https://github.com/tevador/RandomX) and the pool's miner count | none formal; hashes per watt bragging | "After 271 days and 101 Billion Hashes, I Finally Mined my First Monero" (section 1.1) |
-| Ravencoin 2018 | Bitcoin's fair launch replayed for GPUs; "no private, public, founder, or developer allocation" (https://ravencoin.org/assets/documents/Ravencoin.pdf) | the pool dashboard, the WhatToMine line, Discord #mining, "is that hashrate jump an FPGA?" | the pool ranking and the explorer difficulty chart | none formal | "380 MH/s, about 24 hours total time mining. Very, very lucky." (section 1.1) |
-| Ergo 2019 | the ETH miners' second home: GPU-only Autolykos, a 2 GB table, "hardcoded no-premine proof" (https://github.com/ergoplatform/ergo/releases/tag/v3.0.0) | the pool dashboard, the explorer, WhatToMine, Discord #mining | the hashrate chart and the pool list | none formal | "My first payout. All mined with my humble GTX 1060 at 50MH/s." (section 1.1) |
-
-What the seven have in common: the daily ritual is a number read off a page the project does not control (a pool, miningpoolstats, WhatToMine); the social proof is a chart or a map; the ladder is informal everywhere. Helium is the one chain whose product was the proof surface itself (the map), and it is the one whose miners posted photos of the device six months after ordering (section 1.1). No chain had a ladder the chain itself computed.
-
-### 2.2 The numbers at 3, 6 and 12 months
-
-| Chain, launch | 3 months | 6 months | 12 months | Peak | Source |
-|---|---|---|---|---|---|
-| Helium, 1 Aug 2019 | about 1,500 hotspots (approximate) | about 3,000 (approximate) | about 7,500 (approximate) | "500,000+ Hotspots" (HIP 54, 2 Feb 2022); "close to 1 million" (HIP 70, 30 Aug 2022) | https://raw.githubusercontent.com/helium/HIP/main/0054-h3dex-targeting.md ; https://github.com/helium/HIP/blob/main/0070-scaling-helium.md |
-| Chia, 19 Mar 2021 (transactions 3 May) | "over 30 exabytes" (7 Jul 2021) from "about 100 pebibytes" at launch | 32 EiB (3 Aug 2021) | 28 EiB (19 Mar 2022); "over 400,000 nodes" | about 35 to 40 EiB late 2021 (approximate); 17.3 EiB on 7 Oct 2026 | https://www.chia.net/2021/07/07/official-pooling-protocol-launched/ ; https://www.chia.net/2022/03/19/chia-mainnet-year-one/ ; https://alltheblocks.net/chia |
-| Ethereum GPU, from 1 Jan 2017 (6.0 TH/s) | 17.3 TH/s (1 Apr 2017) | 37.2 TH/s (1 Jun 2017) | 159.4 TH/s (1 Jan 2018) | 1,126.7 TH/s (13 May 2022); 871.0 TH/s on 14 Sep 2022, zero from 16 Sep | https://etherscan.io/chart/hashrate?output=csv |
-| Kaspa, 7 Nov 2021 (3.4 MH/s on 8 Nov) | about 1 TH/s (approximate; 0.3 TH/s on 19 Dec 2021) | 2.86 TH/s (28 May 2022) | 431.8 TH/s (26 Nov 2022) | 210.7 PH/s (12 Apr 2024, derived); about 344 PH/s on 7 Oct 2026 | https://api.kaspa.org/blocks-from-bluescore?blueScore=15800001&includeTransactions=false ; https://api.kaspa.org/info/hashrate?stringOnly=false |
-| Monero RandomX, 30 Nov 2019 (307 MH/s CryptoNightR before, 686 MH/s RandomX on 1 Dec) | 1,338 MH/s (29 Feb 2020) | 1,372 MH/s (30 May 2020) | 1,695 MH/s (29 Nov 2020) | 7.54 GH/s (16 Jan 2026) | https://xmr-node.cakewallet.com:18081/json_rpc (get_block_header_by_height) ; https://www.coinwarz.com/mining/monero/hashrate-chart |
-| Ravencoin, 3 Jan 2018 | 0.89 TH/s (19 Mar 2018) | 1.31 TH/s (17 Jun 2018) | 3.51 TH/s (7 Jan 2019) | X16R 22.5 TH/s (29 Sep 2019); KAWPOW 18.76 TH/s (20 Sep 2022); 0.61 TH/s on 7 Oct 2026 | https://blockbook.ravencoin.org/api/v2/block/130000 (and later heights) ; https://rvn.2miners.com/api/stats |
-| Ergo, 1 Jul 2019 | 1.06 TH/s (1 Oct 2019) | 1.29 TH/s (31 Dec 2019) | 7.89 TH/s (30 Jun 2020) | 180.6 TH/s (17 Sep 2022); 0.47 TH/s on 7 Oct 2026 | https://api.ergoplatform.com/api/v1/blocks?limit=1&offset=66000&sortBy=height&sortDirection=asc (and other offsets) ; https://erg.2miners.com/api/stats |
-
-Discord member counts were not found in any source opened for any of the seven; the one community-size number in the sample is r/erg_miners passing 5,000 subscribers on 6 Jan 2022 (section 1.1, row 104).
-
-What the first year looked like from a card: Kaspa went from 3.4 MH/s on its first day to 2.86 TH/s at six months, a million-fold, and then 150x more in the next six (the post-Merge fleet); Chia's netspace rose about 300x in under four months, so a fixed farm's share fell 300x; Ethereum rose 26x across 2017. A miner who joined on day one of any of them watched their share fall by two or three orders of magnitude inside a year. Igneum's 30-day window gives that miner something the hashrate curve took away: weight that the newcomers cannot buy for 30 days.
-
-### 2.3 The failure modes
-
-| Chain | What broke | The number | Source |
-|---|---|---|---|
-| Helium, 2022 | dilution then gaming then a pivot: emission halved to 2,500,000 HNT a month (1 Aug 2021, HIP 20) while hotspots went past "close to 1 million", so under 0.1 HNT a day per hotspot against about 5 to 10 in 2020 (approximate); a denylist run by the company from about 14 Jan 2022 whose method is not published; subDAO tokens with a "50B pre-mine" of MOBILE (HIP 53); the move to Solana (April 2023); the SEC complaint of 17 Jan 2025 over claims about Lime, Nestlé and Salesforce, settled for USD 200,000 | HNT ATH USD 54.88 to ATL 0.1132; "almost 38% of all HNT is staked in Validators" (HIP 70) | https://raw.githubusercontent.com/helium/HIP/main/0020-hnt-max-supply.md ; https://github.com/helium/denylist ; https://raw.githubusercontent.com/helium/HIP/main/0053-mobile-dao.md ; https://www.sec.gov/enforcement-litigation/litigation-releases/lr-26229 ; https://www.coingecko.com/en/coins/helium |
-| Chia, 2021 | the SSD burn (about 1.3 TiB of writes per plot, Chia's own figure; consumer drives killed in weeks, the press figure approximate), the pool protocol eight months after the pools promise (11 Nov 2020 to 8 Jul 2021) with "OG plots" shut out of it, a closed pool at a third of netspace, 300x dilution in four months, then consolidation and a price fall of 99.9 percent | hpool "hovering at around 33% of netspace" (15 Jun 2021); XCH ATH USD 1,645.12 to ATL 1.14 | https://www.chia.net/2021/05/24/chia-and-ssd-endurance/ ; https://www.chia.net/2021/06/15/common-misconceptions-vol-1/ ; https://github.com/Chia-Network/chia-blockchain/releases/tag/1.2.0 ; https://www.coingecko.com/en/coins/chia |
-| Ethereum, 15 Sep 2022 | the Merge switched 871 TH/s off in a day; ETC absorbed at most 236.6 TH/s; Ergo rose 11x in 48 hours (16.1 to 180.6 TH/s) and Ravencoin 7x (2.70 to 18.76 TH/s), so every existing Ergo rig lost about 91 percent of its share inside a week; both fell back by Christmas (32.6 and 9.19 TH/s) | the bagpipes post: "Powering down last ETH mining rig the only proper way", 2,277 points, 15 Sep 2022, https://reddit.com/r/EtherMining/comments/xek7wq | https://etherscan.io/chart/hashrate?output=csv ; https://bitinfocharts.com/comparison/hashrate-eth-etc.html ; https://decrypt.co/109713/ethereum-classic-hashrate-soars-merge-nears-miners |
-| Kaspa, 2023 | the ASIC turn: IceRiver KS0 to KS3 listed for "Sep 2023", Bitmain KS3 "Oct 2023"; network hashrate 2.67 PH/s (28 Jul 2023) to 115.7 PH/s (19 Dec 2023), 43x in under five months; one KS1 at 1 TH/s equals about 2,000 RTX 3070-class cards (approximate), so the GPU share went to a rounding error | 43x | https://www.asicminervalue.com/miners/iceriver ; https://api.kaspa.org/blocks-from-bluescore (derived) |
-| Monero, 2019 onward | nothing broke on chain; two slow failures: botnet mining ("Monero's popularity among malware-based non-consensual miners", Wikipedia), and a 4x hashrate rise to the 2026 peak against the 0.6 XMR tail | 686 MH/s (1 Dec 2019) to 7.54 GH/s (16 Jan 2026) | https://en.wikipedia.org/wiki/Monero ; https://www.coinwarz.com/mining/monero/hashrate-chart |
-| Ravencoin, 2019 to 2020, then 2022 | the FPGA and ASIC surge: 10.0 to 22.5 TH/s between 22 Aug and 29 Sep 2019 with no price move; two algorithm forks (X16Rv2, 1 Oct 2019, "ASIC shmasic"; KAWPOW, May 2020, hashrate 29.4 to 3.39 TH/s overnight); then the economic break after the Merge, 18.76 TH/s to 0.61 TH/s today, and a "consensus flaw in KAWPOW header validation" rescued by a pool in Aug 2026 | hashrate down 97 percent from the 2022 peak; RVN down 99.2 percent | https://github.com/RavenProject/Ravencoin/releases?page=2 ; https://github.com/RavenProject/Ravencoin/releases/tag/v4.1.0 ; https://2miners.com/blog/august-2026-work-progress-ravencoin-chain-rescue-pearl-hard-fork-and-kaspa-reward-cut/ |
-| Ergo, 2022 | the overflow pipe: 16.1 TH/s (3 Sep 2022) to 180.6 (17 Sep), back to 36.8 by 3 Oct; 0.47 TH/s today, under 3 percent of the peak | 11x up and 80 percent down in a month | https://api.ergoplatform.com/api/v1/blocks (derived) ; https://erg.2miners.com/api/stats |
-
-What Igneum takes from each: from Helium, a proof surface the miner owns (the map) and a warning that a company-run denylist with an unpublished method ends the love (section 6, "a number a company server has to be trusted for"); from Chia, that the ritual (plotting) must not destroy the hardware, and that a pool that arrives eight months late with the early miners shut out is remembered (pool-0 is at the go, section 3.5); from Ethereum, that the shareable post is the rig and the ROI, and that a chain can end mining by decree (Igneum's miners are the security always, so there is no Merge to decree); from Kaspa, that a fair launch holds a community for two years and an ASIC takes it in five months (the hourly program and the census, 4.4); from Monero, that "anyone's CPU" is a narrative that survives seven years when the hash keeps its promise; from Ravencoin, that two algorithm forks by human release are what Igneum's automatic schedule replaces; from Ergo, that a hashrate wave arriving from a dead chain dilutes the faithful 11x in two days, which is exactly what the 30-day weight window was built to keep from the vote.
-
-## 3. The miner's experience on Igneum, reinvented
-
-### 3.1 Install: the two warnings before the first screen
-
-What happens today (polish.md 3.10): Windows, SmartScreen "Windows protected your PC" (More info, Run anyway), per-user install, then a UAC prompt for the firewall rule 20 to 50 s in, on top of whatever screen is up. Mac, an ad hoc signature, Gatekeeper refuses, the user must find Privacy and Security, Open Anyway; the app strips its own quarantine on start. The Windows installer cannot be rebuilt tonight (Q80, GitHub billing).
-
-What the comparators do: SmartScreen warns on any file that is not "well known and downloaded frequently" and on any certificate without reputation; "If a URL, a file, an app, or a certificate has an established reputation, users don't see any warnings" (https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/, page dated 23 April 2026, read 7 Oct 2026). SSL.com's code-signing page says Microsoft "moved away from automatic instant reputation", so OV and EV build reputation through use (https://www.ssl.com/code-signing/, 7 Oct 2026). Apple: USD 99 a year, notarisation included (https://developer.apple.com/programs/, 7 Oct 2026); on macOS the unidentified-developer path is System Settings, Privacy and Security, Open Anyway (https://support.apple.com/en-us/102445, 7 Oct 2026). Certum sells an open-source code-signing certificate "from €49.00" (https://shop.certum.eu/open-source-code-signing-on-simplysign.html, 7 Oct 2026; out of stock on the day). Azure Trusted Signing: Basic tier 5,000 signatures a month, one certificate profile of each type; price not shown on the page (https://azure.microsoft.com/en-us/pricing/details/trusted-signing/, 7 Oct 2026; from memory about USD 10 a month, approximate). GPU miners trip antivirus even when signed: T-Rex's README says some engines detect signatures "similar to those that real viruses protected by the same packer have" (https://github.com/trexminer/T-Rex, 7 Oct 2026).
-
-| Step | Today | Proposal | Hours | Gate |
-|---|---|---|---|---|
-| Mac signature | ad hoc, quarantine strip | Developer ID plus notarisation and stapling in `build-dmg.sh`; the quarantine strip removed | 3 plus the founder's USD 99 | a fresh macOS 26 machine opens the DMG's app with no Privacy and Security visit |
-| Windows signature | none | Authenticode through Trusted Signing or an OV certificate, signed on the box as a job step; the sha256 and the signer's name on the download page (Q50, Q82) | 3 plus the founder's purchase | a fresh Windows 11 machine runs the installer with no SmartScreen interstitial by the 1,000-download mark (reputation is use; before that the page shows the exact interstitial text and the two clicks) |
-| Firewall prompt | UAC 20 to 50 s in, unexplained | the Cards screen names it and the step runs after `setup_done` (Q14) | 1 | the prompt never appears before a screen that says it will |
-| Antivirus | nothing | a "What your antivirus may say" line on `/miner#get` with the engine names and the exact action, and the submission to Microsoft's SmartScreen review on every release (the Learn page's submission route) | 1 | the line is on the page; every release's binaries are submitted the day they ship |
-| Time to the first share | not measured end to end on a fresh machine | measured on a fresh Windows 11 VM and a fresh Mac for every release by the Devnet 2 gate: download to first accepted share or block, with the clock, the sync and the dataset build as three timed steps | 2 | "first share within 10 minutes of download in 9 of 10 fresh Windows installs", published on `/evidence` |
-
-### 3.2 First run: what the first hour should feel like
-
-Today's three screens (Welcome, Cards, Address, the key sheet) are rated 7 to 8 of 10 by the UI 3 audit; the audit's own finding is that the one question a home miner has, "is this worth running", is not answered until the third screen, and the Cards row does not say what the card is expected to make although `site/miner-priors.json` knows the model (`miner-ui-3-audit.md` 2.1, 2.2).
-
-| Screen | Add | Hours | Gate |
-|---|---|---|---|
-| Cards | under each known model: "about 25 MH/s at 91 W; on today's network that is about N blocks a day" from the prior and the live network rate | 1 | the row shows a number for every model in the priors file |
-| Cards | the tier sentence in plain words: "8 GB: mines; proves small shards", "24 GB: mines and proves" (from `prover-tiers-real-cards.md`) | 0.5 | every memory size has a sentence |
-| Address | "Start mining" starts mining; the key sheet comes before the button (the audit: "the button lies once") | 1 | view test |
-| Mine, first ten minutes | a "waiting for your first block" line with the live expectation: "a card like yours finds a block about every 1.6 hours on today's network; chance so far: 31 percent" (a Poisson line from the card's own rate and `/api/stats` network rate; the pool mode shows "first share in N s" instead) | 2 | the line is on screen from the first job until the first block, then is replaced by the block card |
-
-The Poisson line is the piece no miner app has. 2miners shows luck for the pool; nothing shows a solo miner's own running chance. It turns the dead first hour into a count-up, and it is honest: it says 46 percent for an 8 GB card at 100 GH/s, which is why the pool switch sits one line below it.
-
-### 3.3 The first block: the card, the sound, the link
-
-Today: an event line in the feed and the blocks strip. Nothing is shareable, nothing is kept.
-
-Proposal, the block card (Ember, Mine page, in place, no dialog):
-
-```
-Block 1,284,117 is yours.                                 12:27:53 UK
-RTX 4070 · 25.0 MH/s · 0.025% of the network
-80.00 IGN to 0xdd44…86E8 (72 producer points, 8 for signing)
-Hash 9f3a…c21e   [Open in the explorer]   [Save the card]   [Copy the link]
-```
-
-| Element | Rule | Hours | Gate |
-|---|---|---|---|
-| The card | shown on the first block of every key, then on every 100th, 1,000th and 10,000th, and on the first block of every new card; stays until dismissed; the rest are feed lines | 2 | view test on the four thresholds |
-| Sound | off by default; one short tone on a block when on; honours reduced motion and the OS mute (`app.css` already honours reduced motion everywhere) | 0.5 | the tone never plays when the switch is off |
-| Save the card | a 1200x630 PNG drawn locally from the same data (the rig-photo post without the rig; the dark scheme, the brand mark, the card name, the hash, the explorer link as a QR) | 2 | the PNG opens; no network call is made to make it |
-| The link | `/block/<hash>` (exists: parents, children, mergeset, shards, checkpoint fractions, `block.html:285-325`) | 0 | |
-| What is not on it | no fiat, no price, no "worth": there is no market and the copy law forbids the aphorism | | |
-
-The pool user gets the same card for the first share ("Share accepted by pool-0 · 0.0012 of a block") and the first credited block ("pool-0 found block N; your share 0.41 IGN"), from the `share_result` and the PPLNS credit lines the pool already sends.
-
-### 3.4 The app: Earnings
-
-Today (`miner-ui-3.md` section 5, polish Q18): the first number on the tab is "£0.00 earned: nothing is bought or sold on devnet"; mined IGN is never shown, only proving `paid_wei`; the electricity line is real and shown as a cost.
-
-| Line | Today | Should read | Source of the number | Hours |
-|---|---|---|---|---|
-| 1 | £0.00 earned | **6,912 IGN a day** at your last hour's rate (86 blocks) | the node's own block count for the key times the subsidy at the block's DAA; the projection from the 1-h rate and `/api/stats` network rate | 2 |
-| 2 | 0.0000 IGN from 0 proofs | 2,592 blocks in 30 days, 207,360 IGN; 14 shards, 16.1 IGN | the node and the execution layer (the balance is in the wallet; the app reads the coinbase credits per key) | 1 |
-| 3 | none | about £N a day at a price you type (no exchange lists IGN; a typed price, remembered, never fetched) | the user's field; the engine's `price_gbp_per_ign` when a market exists, as the UI 3 plan already owes | 1 |
-| 4 | none | your card is 0.100 percent of the network; weight rank 41 of 1,204 keys; 30 of 30 days | `/api/live` miners and the finality weights RPC (`getFinalityWeights`, spec 3.10) | 2 |
-| 5 | £1.95 a day electricity | unchanged, and the line under it: "N IGN per kWh" | the existing watt reading | 0.5 |
-| 6 | dev fee line | unchanged (1 in 100, the switch) | | 0 |
-
-A rule for every number on the tab: it comes from the node this machine runs, or from the public API with the field named on hover (polish 4.3, one formatter table). The typed price is the only number the user supplies and the tab says so.
-
-### 3.5 The pool
-
-Decision for the launch pool, with reasons:
-
-| Question | Decision | Why |
-|---|---|---|
-| Who runs it | the project runs pool-0 at the testnet go and at mainnet genesis, on the written systemd unit (`pool/README.md`), with the member's vote key in every header as built | nobody else can on day 1; the member-key design means the project's pool never holds vote weight, which is the thing a project pool is normally criticised for |
-| Fee | 1 percent, the same as the solo dev fee, published in `welcome`, on the page and on `/miner` | a 0 percent project pool makes every outside pool unviable, and the first outside pool is a launch gate (section 4.1); 1 percent is what miners accept everywhere (2miners 1.0 percent, https://kas.2miners.com/, 7 Oct 2026; Ethermine 1 percent, approximate); fee-neutral between solo (dev fee 1 in 100) and pool, so the choice is about variance only |
-| Where the fee goes | the same software address as the dev fee; it is a software fee, documented as such (`miner-dev-fee.md`), never a protocol fee | no dev fund, no treasury; the protocol carries no fee to anyone |
-| Mode | PPLNS, window 2 blocks of weight, payout rounds every 60 s, minimum 1 IGN (as built) | the first payout inside two minutes of the first share for an 8 GB card at 100 GH/s (section 1.4) |
-| Default in the app | solo under 500 GH/s network, the app suggests the pool above it, per card: "a card like yours finds a block about every 16 hours on today's network; pool-0 pays every minute" | the Poisson line of 3.2 decides; the user chooses |
-| What the pool page shows | the connect card, the lookup, the blocks and the payments table (Q71 owed), luck in MiningPoolStats' convention (Q69, Q72), "payouts follow blue confirmation, not finality" (Q73), and the finality state | the comparator rows in polish 3.6 |
-| TLS | before the public testnet (Q67, 8 hours, consensus-engineer) | spec 9.3 |
-
-The variance arithmetic that makes the pool required, computed: a single 8 GB card at 17 MH/s finds a solo block every 1.6 hours at 100 GH/s, every 16 hours at 1 TH/s (23 percent of days with no block), every 6.8 days at 10 TH/s (36 percent of weeks with no block), every 68 days at 100 TH/s. The pool is optional at launch size and required from about 1 TH/s. The pool's own payout latency: credit on blue confirmation (seconds), a round every 60 s, so under two minutes end to end once the member's balance passes 1 IGN.
-
-### 3.6 Community: the Discord, the live page, the leaderboard, the miners page, the explorer
-
-What exists: the Discord kit (roles Founder, Core, Prover, Miner, Bot; channels INFO, CHAIN, LEDGER, TALK; the bot posts a pulse four times a day, a daily digest, weekly numbers, releases, incidents; nothing live yet, Q7); `/live` with a Miners lane list of vote keys with a block in the last 10 minutes; `/miners` the bench table (six rows, Q51); the explorer with Miner as the payout address per block; `/address` (noindex) with balance and blocks mined.
-
-| Surface | Add | Rule that keeps it honest | Hours | Gate |
-|---|---|---|---|---|
-| Discord #first-blocks | the bot posts every first block of a new key (short key id, the block link, the card model if the miner opted in through the app's "show my card" switch) | from the public API only; the forbidden-string guard; no name, no machine id | 2 | ten first blocks posted on Devnet 2 with the right links |
-| Discord roles | Voter (the key is above dust, verified by a message signed with the vote key against `getFinalityWeights`), Window (30 of 30 days), Prover (as built) | chain-side facts, anyone can check the same RPC | 3 | a role granted and revoked by the chain's numbers in a test |
-| `/live` Miners | a leaderboard by 30-day weight: rank, short key id, blocks in window, days mined, signing presence, last block; a toggle to the 10-minute view that exists | weight, never hashrate; a renter who arrived today is at the bottom whatever they rent | 3 | the page shows the top 100 by weight with days-mined; a key that stops mining falls one place a day |
-| `/address/<key or address>` | the public profile: blocks in 30 days, weight rank, vote state, checkpoints signed, shards proven, first block date, the block cards | noindex stays until the owner opts in from the app ("make my page public") | 3 | the page renders for every key in the window |
-| `/miners` | the hardware census (section 4.4): one row per card model from the hourly program's per-card timings, MH/s, W, MH/W, count of keys on that model, median first-block time | measured, scrubbed, no machine names (the bench-table rule) | 4 | eleven rows today, every model with three or more keys after the testnet go |
-| Explorer block page | "found by key id N, rank 41, day 23 of 30" under Miner | from the same weights | 1 | the line on every block |
-
-### 3.7 Why I stay: the ladder written into consensus
-
-The thing no other chain has: vote weight is 30 days of blocks per key (rule v2). A level system with no points server, no badge contract and no company database: the chain computes it, the node reports it (`getFinalityWeights`), the wallet verifies the certificates it signs.
-
-| Rung | Name on screen | Rule | Time for a 100 MH/s card at 100 GH/s | Time for an 8 GB card at 100 GH/s | Where shown |
-|---|---|---|---|---|---|
-| 0 | First block | one blue block with your key | 16.7 min expected | 1.6 h | the block card; #first-blocks |
-| 1 | Your key has a vote | 100 blocks in the window (the dust line) | 1.2 days | 6.8 days | Mine hero, address page, Discord Voter |
-| 2 | Your signature is in checkpoint K | the first certified checkpoint carrying the key's vote | the next 30-s checkpoint after rung 1 | the same | the finality line in Mine, the block page of the lock |
-| 3 | Full window | 30 of 30 days with blocks | day 30 | day 30 | the days ring in the hero; Discord Window |
-| 4 | Rank | position by weight among all keys | continuous | continuous | `/live` leaderboard, Earnings line 4 |
-| 5 | Signing streak | days since the key last missed the presence window (the 8 points never lost) | continuous | continuous | Earnings: "signing 8 of 80 points, 41 days unbroken" |
-| P | Your card proved shard N of block M | a paid shard record | hours on a 24 GB card; not yet on 8 GB | not yet | the Prove tab card, Discord Prover |
-
-The exact lines, in copy law: "Your key has a vote." "Your signature is in checkpoint 184,220." "Your card proved shard 3 of block 1,284,117." "30 of 30 days. Full weight." "Rank 41 of 1,204 keys." Each line names the chain fact behind it on hover (the RPC field), the same rule as every number on the site.
-
-What the rungs pay, so the ladder is not decoration: rung 1 is the vote itself; rung 2 starts the 8-point signing line (the public sentence: miss two hours of signing and the next blocks pay 72 until you sign again); rung 3 is maximum weight; rung P is the proving income (20 points of every block, split by shard). Nothing is paid from a fund; the ladder only names what the rules already pay.
-
-### 3.8 Per tier: the first hour and the first month
-
-Cards at the measured untuned rates of `docs/analysis/prover-tiers-real-cards.md` (rented, 6 October 2026) and the bench table; expectations at 1 block a second; the first month at full rate (100 IGN a block) and at the 90-day ramp approved for the testnet genesis on 7 October (10 percent on day 1, so divide the IGN column by 10 on launch day; CLAUDE.md's 30-day ramp is the earlier text).
-
-Network 100 GH/s:
-
-| Tier | Gap to a solo block | Block in the first hour | Blocks a day | IGN a day (80 points) | Days to a vote | First month: blocks, and what the key is |
-|---|---|---|---|---|---|---|
-| 8 GB, RTX 4060 (17.07 MH/s) | 1.6 h | 46 percent | 14.7 | 1,180 | 6.8 | 442 blocks; a voter from day 7; full window day 30; proves core-only shards (`prover-tiers` row 4060) |
-| 8 GB, RX 9070 XT (17.9) | 1.6 h | 48 percent | 15.5 | 1,237 | 6.5 | 464; a voter from day 7; no proving (CUDA only today) |
-| 12 GB, RTX 4070 (24.99) | 1.1 h | 59 percent | 21.6 | 1,727 | 4.6 | 648; a voter from day 5; mines and proves on the patched prover when shipped |
-| 12 GB, RTX 5070 (41.89) | 40 min | 78 percent | 36.2 | 2,895 | 2.8 | 1,086; a voter from day 3 |
-| 16 GB, RTX 4060 Ti (17.58) | 1.6 h | 47 percent | 15.2 | 1,215 | 6.6 | 456; a voter from day 7; mines and proves |
-| 24 GB, RTX 4090 (52.25) | 32 min | 85 percent | 45.1 | 3,612 | 2.2 | 1,354; a voter from day 3; mines and proves today |
-| 32 GB, RTX 5090 (98.48 rented; 122 on PC 1) | 17 min | 97 percent | 85.1 | 6,807 | 1.2 | 2,553; a voter from day 2; proves beside the miner |
-| Apple M5 Max, Metal (26.7) | 1.0 h | 62 percent | 23.1 | 1,846 | 4.3 | 692; a voter from day 5; proves on the CPU, slowly |
-| Rig, 6 x RTX 4090 (313.5) | 5.3 min | 100 percent | 271 | 21,669 | 0.4 | 8,126 (one key per machine, the 6 October default) |
-| Pool member, any of the above | first share under a minute; first credit under two minutes | 100 percent | the same blocks on average, paid every minute | the same minus 1 percent | the same days (weight follows the member's own blocks) | the same |
-
-Network 1 TH/s (the same cards):
-
-| Tier | Gap to a solo block | Block in the first hour | Blocks a day | IGN a day | Days to a vote | 30-day blocks |
-|---|---|---|---|---|---|---|
-| 8 GB, 17.07 MH/s | 16.3 h | 6 percent | 1.5 | 118 | 68 (never inside the window) | 44 |
-| 12 GB, 24.99 | 11.1 h | 9 percent | 2.2 | 173 | 46 (never) | 65 |
-| 12 GB, 41.89 | 6.6 h | 14 percent | 3.6 | 290 | 28 | 109 |
-| 24 GB, 52.25 | 5.3 h | 17 percent | 4.5 | 361 | 22 | 135 |
-| 32 GB, 98.48 | 2.8 h | 30 percent | 8.5 | 681 | 12 | 255 |
-| Apple M5 Max | 10.4 h | 9 percent | 2.3 | 185 | 43 (never) | 69 |
-| Rig, 6 x 4090 | 53 min | 68 percent | 27.1 | 2,167 | 3.7 | 813 |
-
-Per OS and vendor, what differs in the first hour: Windows, two prompts (section 3.1) and NVIDIA through the driver, AMD and Intel through OpenCL; macOS, one prompt, Apple silicon through Metal, no watt reading so no pounds line; Linux and HiveOS, no prompt, the Flight Sheet fields, Hive itself untested on a real rig (`/miner`). AMD cannot prove today (CUDA only). The 12 GB tier cannot mine and prove at once on the shipped build (peak 15.6 GB measured, bench log 5 October); the patched prover's 10.1 GB peak beside the miner on the 4070 is measured and not shipped.
-
-### 3.9 The first withdrawal, and the first "I own something"
-
-No exchange at the testnet, none arranged or sought at mainnet (journey phase 6). So the first ownership moment is not a withdrawal. It is:
-
-| Moment | Today | Proposal | Hours |
-|---|---|---|---|
-| The balance | in the wallet ("the balance is in the wallet", Earnings); the address page shows balance and blocks | the Earnings tab shows the balance read from this machine's node, with "verified by this node" on hover | 1 |
-| The proof | the wallet verifies finality certificates with the node's own code (`finality.rs:101-121`) | the first block card carries "final under checkpoint K, certificate verified by this machine" once the lock lands, and the address page shows the latest locked checkpoint (Q37) | 1 |
-| The QR | the wallet draws the `ethereum:` URI locally (`server.rs:140`) | the saved block card carries the explorer link as a QR; the address page's QR under "make my page public" | 0.5 |
-| The send | EIP-1559 value transfers in the wallet | a first-transfer card in the wallet: "sent 10 IGN to 0x…, in block N, final under checkpoint K" with the state words pending, included, executed, proven, finalised (UI 3) | 0 beyond Q9 |
-
-"I own something" on Igneum is "a block with my key is final under a certificate my own machine verified". No other chain's miner app says that sentence.
-
-## 4. The exact structure for Igneum
-
-### 4.1 The launch sequence as gates
-
-The go checklist (`docs/plans/testnet-go.md`) has eleven steps, from the seeds at height 0 to the first miner's block 1. These are the community gates that follow it; none has a date.
-
-| Gate | Definition | How it is measured | What opens when it passes |
-|---|---|---|---|
-| G-C1 First 100 keys | 100 distinct vote keys with a block in the last 24 h | `/api/live` miners over a day | the #first-blocks channel goes live; the leaderboard shows ranks |
-| G-C2 First block by a card the project does not own | a block whose key is not in the project's fleet list | the observer's key list against the fleet file (the Discord guard already reads it) | the "first outside block" post, with the owner's permission |
-| G-C3 First outside-reproduced benchmark | a card row on `/miners` measured by someone outside the project, with driver, OS and version (Discord rule 6) | the bench-table ingest with `by: reported by a miner` | the census starts (4.4) |
-| G-C4 First pool not run by the project | a pool at an address the project does not control with 10 percent of blocks for 7 days, the member key in its headers | the explorer's payout-address share | pool-0 stays at 1 percent; the app's pool list gains a second entry |
-| G-C5 First 1,000 independent keys | X5 as decided on 6 October: 1,000 keys above dust over 30 days, independent in autonomous system, machine fingerprint and pool attestation, top-10 share of window weight under 50 percent; a silent key counts only if its AS is its own | the observer's AS and fingerprint columns (owed, one app-owner item) | journey phase 5 closes; mainnet genesis is the next gate |
-| G-C6 First outside proving customer | one rollup's job proven and paid on its own chain | the job market's payout contract | phase 4's second half |
-
-### 4.2 The first 1,000 miners: where they come from
-
-The no-airdrop constraint shapes every row: nothing is offered for joining; the only pay is mined emission; the message is the number and the file. Costs are agent hours for the content and the answering; the expected counts are this lane's estimates and labelled so.
-
-| Channel | Expected keys (approximate) | Hours | The message | Rule |
-|---|---|---|---|---|
-| r/gpumining (the Reddit kit's day-7 post: eleven cards, MH/s, W, MH/W) | 150 to 300 | 6 (post, 48 h of answers) | the card table; "devnet coins have no value; nothing is for sale"; the ledger | rule 2.10 (no referral or promo links); the founder reads the Expanded Rules first |
-| r/EtherMining (the Merge story, under rule 7's disclosure) | 100 to 200 | 4 | four years after the Merge, what runs and the command to check it | one linked post per seven days; nobody sent to Discord |
-| HiveOS forum and the custom-miner listing | 100 to 250 (rigs, so more hashrate than keys) | 4 plus the first real Hive run | the HiveOS card verbatim, "Hive itself is untested so far; report what breaks" | the first reported rig run gets a bench row and the Miner flair |
-| Bitcointalk ANN | 50 to 150 | 3 plus daily answers for a week | the ANN format: no premine, no sale, the dev fee, the card table | no bounty, no signature campaign |
-| Miner Discords (lolMiner, BzMiner, Hive, the Kaspa and Ergo mining rooms) | 100 to 200 | 3 | two sentences, the card table, the ledger, "nothing is for sale" | one message per server in its projects channel |
-| The miner-software authors (lolMiner, BzMiner, Team Red, Rigel) | 0 to 300 keys on the day one of them ships Igneum | 8 (the worker protocol document, the vectors, the dev-fee template mechanism explained so their fee works in solo mode) | "a fee template is 1 in 100 by a counter; your fee rides the same mechanism" | their fee is theirs; the protocol carries none |
-| r/CryptoTechnology, r/zkproofs, r/Monero (the design rooms) | 30 to 80 | 4 | the prover, the verify command, the vs RandomX table | comments only where the rules say so |
-| The hardware census itself (4.4), once G-C3 passes | 100 to 300 over the first months (people come to get their card measured on a public board) | 0 beyond the board | "your card's row, measured by the chain, not by us" | scrubbed, no machine names |
-| Total | 630 to 1,780 keys, median about 1,000 | 32 | | |
-
-Every row is the Reddit kit's existing text or an extension of it; the only new content is the census board and the worker-protocol document for the miner authors.
-
-### 4.3 The pool at launch
-
-Decided in 3.5: project-run pool-0 at 1 percent, member keys in headers, PPLNS, 60-s rounds, the dev fee off in pool mode because the pool fee is the same 1 percent to the same software address. The outside pool is a gate (G-C4), not a hope: the pool crate is public with its README, and the app's pool field takes any host.
-
-### 4.4 The leaderboard and the census
-
-| Board | Ranks | Never ranks | Source | Why |
-|---|---|---|---|---|
-| Keys (`/live`, the address page, Earnings line 4) | 30-day weight (blue blocks per key in the window), with days mined and signing presence | hashrate | `getFinalityWeights` | a renter who arrives today has no weight; a laptop that mined for 30 days outranks a rented rig's first week; the board is the chain's own security table, so it cannot lie without the chain lying |
-| Cards (`/miners`, the census) | efficiency per card model: MH/s, W, MH/W, and the per-program timing spread from the hourly swap (the frontier lane's "8,760-question hardware census", `frontier.md` 4.3) | people | the hourly program's per-card timings, the bench-table ingest, scrubbed | the public benchmark the litepaper promises, made continuous; a chip that does better than the GPU curve shows up on this board first |
-
-The census is new: RandomX programs are per hash and no pool sees their timing; Igneum's hourly program with per-card racing produces the census as a by-product (`frontier.md` 4.3). It is the one leaderboard a miner wants that no chain has, and it doubles as the chip alarm.
-
-### 4.5 The story each miner tells
-
-Written in copy law (short sentences, no antithesis, no aphorism).
-
-| When | The three sentences |
-|---|---|
-| First week | "I installed it in five minutes and the first block was mine inside the hour. Every block pays my address straight away. My 4070 is on a public board with its watts." |
-| First month | "My key has a vote now. It signs finality every 30 seconds and I can see the checkpoint it is in. After 30 days my weight is full, and the rented farms that showed up last week sit under me." |
-| First year | "The program has changed 8,760 times and my card still mines it. My card has proved 400 shards for a rollup I have never heard of. Nothing was sold and nothing was given away: every coin I hold was mined." |
-
-## 5. The surfaces to change
-
-| Surface | Today (polish.md) | Should show | Hours | Gate |
-|---|---|---|---|---|
-| Ember, Cards | card name, switch, "worker Metal, 40 GPU cores" (audit 2.2) | expected MH/s and W from the priors, "about N blocks a day on today's network", the proving tier sentence | 1.5 | every model in the priors shows a number |
-| Ember, Mine (before the first block) | the blocks strip, 10 minutes (`app.js:1052-1127`) | the Poisson count-up line; the pool suggestion when the gap passes 8 h | 2 | the line shows from the first job to the first block |
-| Ember, Mine (the block card) | an event line | the block card of 3.3, saved PNG, the explorer link | 4.5 | the four thresholds; the PNG with no network call |
-| Ember, Earnings | "£0.00 earned", mined IGN never shown (Q18) | IGN a day, blocks and IGN in 30 days, shards and IGN, a typed price, share of network, weight rank, days, signing streak | 6.5 | every line names its RPC field on hover; a view test per line |
-| Ember, Prove | state line "0 assigned · 0 proven · 0 paid" | the shard card "your card proved shard N of block M, 1.15 IGN" | 1 | a card on the first paid record on Devnet 2 |
-| Ember, Settings | pool field designed, not built (`pool.md` section 7) | the pool field, the terms box from `welcome`, the dev-fee line reading "off in pool mode: the pool's 1 percent is the same fee" | 3 | a member connects from the app and shows the terms |
-| Ember, first run | two prompts, one unexplained (Q3, Q14) | signed and notarised; the firewall step named on the Cards screen | 7 plus the founder's certificates | 3.1 gates |
-| Wallet | one account, no finality state on the address page (Q33, Q37) | the first-transfer card with the five state words; the address page with the latest lock | 3 (plus Q9's 6) | a devnet transfer walks the five words on screen |
-| Site `/miner` | "Install. Start. The card mines and proves." plus feature lines | the first-hour timeline (download, the one prompt, first share, first block, first payout) with the measured times from the Devnet 2 gate | 2 | the times on the page equal the gate's log |
-| Site `/live` | miners with a block in 10 minutes | the weight leaderboard with days mined and signing presence; the 10-minute view as a toggle | 3 | top 100 by weight; a stopped key falls one place a day |
-| Site `/miners` | six rows, two models, "not measured" MH/W (Q51) | the census: one row per model, MH/s, W, MH/W, keys on that model, median first-block time | 4 | every model with three or more keys |
-| Site `/address` | balance, blocks, noindex | the public profile of 3.6 behind the app's opt-in | 3 | renders for every key in the window |
-| Explorer block page | Miner = payout address | "found by key id N, rank 41, day 23 of 30" | 1 | on every block |
-| Pool page | stat strip, connect, lookup, blocks, no payments table (Q71) | payments, luck in the standard convention, "payouts follow blue confirmation, not finality", finality state | 3 | the comparator rows in polish 3.6 |
-| Discord | nothing live (Q7); roles Miner and Prover by hand | the bot live; #first-blocks; Voter and Window roles from chain facts | 8 | ten first blocks on Devnet 2 posted; a role granted by a signed message |
-| Total | | | 52.5 plus the certificates | |
-
-## 6. What not to build
-
-| Idea | The line that kills it |
-|---|---|
-| Gamification paid from a fund (a weekly prize, a "block of the day" bonus) | there is no fund; every coin is mined under the 80/20 rule and the signing bonus, and a prize paid by the project is a premine by another name |
-| Referral in coins | no referral paid in coins from a fund: there is no fund; and r/gpumining rule 2.10 bans referral codes outright |
-| An airdrop for installing, posting or reproducing a benchmark | an airdrop in exchange for anything is a sale by another name; the rule is "nothing is for sale" on every surface |
-| NFT badges for the rungs | the rung is a chain fact already (weight, days, signatures); a token for it adds a contract, a market and a price to a thing that must stay a number |
-| An off-chain points system | a number a company server has to be trusted for; the ladder's rule is that every number is a chain fact anyone can read from an RPC |
-| A rank-by-hashrate board | a renter tops it on the first day; the only board is weight, which takes 30 days |
-| A "top earners" board in fiat | there is no price; a typed price is the user's and stays on their machine |
-| A Discord level bot (MEE6-style XP for messages) | a number a server owner sets; it rewards talking, not mining |
-| A bounty for the first ASIC, or a device bounty | ruled out (M1, M22); a device bounty is a sale of the chip |
-| Streaks that penalise a miss (lost rungs, demotion) | the signing bonus already prices a miss (72 until you sign again) and nothing is burned; a second penalty on top is the burn the owner refused |
-| Any surface whose number needs a company server to be trusted | the observer, the API and the Discord bot are conveniences; every number they show must be reproducible from a node, or it is not shown |
-
-## 7. Verdict table
-
-| Proposal | Evidence (chain, year, number) | Newness | Hours | Gate | Recommend |
-|---|---|---|---|---|---|
-| Signed and notarised installers | SmartScreen warns on any file without reputation (Microsoft Learn, 2026); polish Q3 | everyone has it; we lack it | 7 plus certificates | no interstitial on a fresh Mac; the Windows one gone by 1,000 downloads | do now |
-| The Poisson count-up before the first block | 2miners shows pool luck (kas.2miners.com, 2026); no app shows a solo miner's own running chance | nobody has it | 2 | the line shows until the first block | do now |
-| The block card with a saved PNG | EtherMining's rig photo 2,528 points in 2021 (section 1.1); the Helium miner photo 860 in 2021 | nobody has it in a miner app (approximate) | 4.5 | PNG with no network call | do now |
-| Earnings in IGN first, a typed price second | NiceHash shows fiat first (polish 3.1, approximate); Q18 | someone has fiat; nobody has "typed price, never fetched" | 6.5 | every line names its field | do now |
-| The weight ladder: vote, signature, full window, rank, streak | rule v2 (Igneum, 2026): weight is 30 days of blocks per key | nobody has it | 6 (across Ember, address page, Discord) | a Devnet 2 key walks every rung on screen | do now |
-| The weight leaderboard on `/live` | Kaspa pools rank workers by hashrate (approximate); Helium ranked hotspots by HNT (section 2) | nobody ranks by consensus weight | 3 | top 100 by weight | do now |
-| The hardware census on `/miners` | frontier 4.3; the litepaper's promised benchmark | nobody has it | 4 | every model with three keys | do now |
-| Pool-0 at 1 percent, member keys | 2miners 1.0 percent fee (2026); spec 09 member votes | the member-key pool is new; the fee is standard | 0 beyond Q67 to Q73 (about 20) | G-C4 | do now |
-| #first-blocks and the Voter and Window roles | Discord kit roles (2026); chain-side facts | nobody grants a role from consensus weight (approximate) | 5 | roles from a signed message | do now |
-| The public address profile behind an opt-in | Helium's explorer hotspot page (2021), section 2 | someone has it (Helium); ours adds the vote and the signatures | 3 | renders for every key | prototype |
-| The first-hour timeline on `/miner` with measured times | the devnet laptop's 7 minutes and the 5090's first minute (bench log, 4 Oct 2026) | ethereum.org and kaspa.org have no measured install time (approximate) | 2 | the page equals the gate's log | prototype |
-| The worker-protocol document for miner authors | lolMiner 0.75 percent Kaspa fee, T-Rex 1 percent (their READMEs, 2026) | standard | 8 | one outside miner ships Igneum | prototype |
-| A dust line that scales with the network | section 1.4: an 8 GB card never votes past about 500 GH/s | a finality-lane question | 0 here | the finality lane's answer | watch |
-| Sound on a block | every pool page has a block sound option (approximate) | standard | 0.5 | off by default | watch |
-| Anything in section 6 | | | | | never |
-
-## 8. Three headline findings for the coordinator
-
-1. At the litepaper's 100 GH/s network a solo 8 GB card finds its first block in 1.6 hours expected and 46 percent of them see no block in the first hour, so the first-hour dopamine for the most common tier is the Poisson count-up line and the pool's first share under a minute, not the block; at 1 TH/s that card finds a block every 16 hours and never reaches the 100-block vote line (44 blocks in 30 days), which the finality lane must weigh against the 1,000-independent-keys gate.
-
-2. Igneum's 30-day vote window is a level system no other chain has, and it is free: the rungs (first block, 100 blocks for a vote, a signature in a checkpoint, 30 of 30 days, rank by weight, a signing streak) are chain facts from `getFinalityWeights`, cost about 6 agent hours to show across Ember, the address page and Discord, and cannot be topped by a renter inside 30 days.
-
-3. In a 105-post sample of miner joy on Reddit (69 with a room median), the posts that rise highest are the miner's own: "my card paid for itself" at 777 times the room's typical score, the rig photo at 417, the hashrate milestone at 409, against 66 for the network's own milestone and 56 for the first pool payout; so every shareable surface Igneum builds carries the miner's card, rank and days, not the project's number, and the saved block card (4.5 hours) is the first of them.
-
-## Sources
-
-Repository files (the mission worktree, read 7 October 2026): `CLAUDE.md`; `docs/analysis/horizon/polish.md` (sections 1, 3.1, 3.2, 3.4, 3.6, 3.7, 3.10, 4.5); `docs/analysis/vote-or-burn.md` section 5; `docs/analysis/tail-emission.md`; `docs/analysis/horizon-2026-10.md` section 1; `docs/plans/ledger-decisions.md` (item 3, the standing decisions, the 6 and 7 October decisions); `docs/plans/pool.md`; `pool/src/config.rs`; `docs/spec/09-pool-protocol.md`; `docs/plans/miner-ui-3.md` and `miner-ui-3-audit.md`; `docs/plans/testnet-go.md`; `docs/design/miner-dev-fee.md`; `docs/community/discord-hooks.md`; `docs/analysis/prover-tiers-real-cards.md`; `docs/analysis/horizon/frontier.md` 4.3; `docs/bench-log.md` (4 and 5 October 2026 entries); `site/journey.json`, `site/live.html`, `site/explorer.html`, `site/miner.html`, `site/miner-bench.json`; the litepaper text; the Reddit kit on branch `reddit-kit` (`docs/community/reddit/outreach.md`, `outreach-week-1.md`, `discord.md`).
-
-Fetched by this lane (all 7 October 2026):
-- https://2miners.com/faq (payouts every 2 hours; thresholds per coin page)
-- https://kas.2miners.com/ (1.0 percent fee, 50 KAS minimum, 771 miners, luck 441 percent, last block 2 minutes ago)
-- https://solo-kas.2miners.com/ (SOLO fee 1.5 percent, 99 miners)
-- https://p2pool.io/ (min payout 0.00027 XMR; "several days to a week to find a share")
-- https://github.com/Lolliedieb/lolMiner-releases (Kaspa fee 0.75 percent, Autolykos 1.5 percent)
-- https://github.com/trexminer/T-Rex (1 percent, 2 percent on Octopus and Autolykos2; the antivirus note)
-- https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/ (page dated 23 April 2026)
-- https://www.ssl.com/code-signing/ (reputation through use for OV and EV)
-- https://support.apple.com/en-us/102445 (Open Anyway)
-- https://developer.apple.com/programs/ (USD 99 a year) and https://developer.apple.com/support/compare-memberships/ (notarisation included)
-- https://shop.certum.eu/open-source-code-signing-on-simplysign.html (from EUR 49, out of stock)
-- https://azure.microsoft.com/en-us/pricing/details/trusted-signing/ (Basic 5,000 signatures a month; price not shown)
-- https://en.wikipedia.org/wiki/Helium_Network and https://en.wikipedia.org/wiki/Chia_(cryptocurrency)
-- https://api.pullpush.io/reddit/search/submission/ (r/EtherMining, r/chia, r/HeliumNetwork, r/kaspa listings used as a cross-check of the sub-lane's sample)
-
-Fetched by the Reddit sub-lane (scratch `mission-reinvent/reddit-sample.md`, 105 posts, every URL in its table 1 and quotes in table 3; the Arctic Shift archive for medians; the ninjastic archive for bitcointalk). The URLs cited in sections 1.1 and 2 above are from that file.
-
-Fetched by the chains sub-lane (scratch `mission-reinvent/chains.md`, 96 URLs in its sources list): the Helium HIPs 10, 15, 17, 20, 25, 51, 53, 54, 70 and the denylist repository; the Chia blog posts of 11 Nov 2020, 23 Feb, 17 Mar, 24 May, 13 Jun, 15 Jun, 30 Jun, 7 Jul, 3 Aug 2021 and 19 Mar 2022 and releases 1.0.0, 1.1.0, 1.2.0; Etherscan's hashrate CSV; bitinfocharts ETH and ETC; Decrypt on ETC; api.kaspa.org; the BzMiner, lolMiner and Team Red release pages; asicminervalue; the Monero node RPC, xmrchain, the RandomX repository and getmonero.org; the Ravencoin whitepapers, releases and blockbook; the Ergo releases, docs and explorer API; the 2miners stats APIs and blog; CoinGecko for every price. Pages that refused the fetch (Mashable, The Verge, Bloomberg, Forbes, CNBC, Polygon, PCMag) are cited through Wikipedia and marked so in that file.
-
-Figures labelled approximate come from memory and were not pinned to a page today.

docs/analysis/mission/unfinished.md

@@ -1,371 +0,0 @@
-# The last mission, lane 2: started and not finished, across the industry
-
-7 October 2026. Lane 2 of the final research programme. What the industry started and did not finish, group by group, with one verdict per row: Igneum already has the finished version, Igneum could finish it in hours, or Igneum should leave it. Every figure from a source carries its URL and access date in section 9; every figure from memory is labelled approximate. Hours are agent hours (the founder's rule: Claude-side work takes hours, never weeks). Nothing here is a token sale.
-
-What this file does not repeat: the ASIC chip history (`docs/analysis/asic-resistance-history.md`), the useful-work verdict and the stored-state candidate (`new-pow.md` sections 3, 6, 7), the ranked frontier ideas (`frontier.md` section 0, 3.10, 3.11), and Igneum's own pool design (`docs/plans/pool.md`, `docs/spec/09-pool-protocol.md`). Those are cited, not restated.
-
-## 0. Progress (UK time)
-
-| Time | State |
-|---|---|
-| 08:1x (approximate) | Context read: CLAUDE.md, asic-resistance-history.md, new-pow.md 3, 6, 7, frontier.md 0, 3.10, 3.11, horizon-2026-10.md 1, pool.md, spec 09, polish.md 3.1, 3.6, 3.10 |
-| 08:2x (approximate) | Four research lanes launched (A, B, C with D, E). Lane F was refused by the concurrency cap and was researched by this lane directly |
-| 08:3x (approximate) | The session's WebSearch budget ran out (200 of 200). Every later fact came from WebFetch of a primary page or is labelled approximate |
-| 08:49 | Lane F notes saved (scratch `mission-unfinished/F-notes.md`, file time) |
-| 08:50 | Igneum-side pool and Ember comparison drafted (scratch `igneum-side-draft.md`) |
-| 08:53 to 08:59 | Lanes A, E, B, C with D landed (scratch file times) |
-| 09:09 | All notes read; assembly of this file started |
-| 09:17 | File complete: 371 lines, em-dash grep at zero, nothing staged |
-
-Limits of this research: p2pool.observer answered 502 all morning (Monero P2Pool share taken from the miningpoolstats data file instead); Bob Rao's ProgPoW PDF would not extract (his 1.1x to 1.2x figure is cited to EIP-1057); Bitmain's own X9 page was unreachable (the X9 is reported as announced per resellers, unconfirmed shipping); NiceHash's fee and repayment pages are gone (those figures are approximate); Salad's take rate is not published anywhere fetched.
-
-## 1. Group A: proof of useful work
-
-The one question per row: can the useful work be verified cheaper than it is done, and is it sampleable (a nonce picks a random instance the miner cannot steer, with tunable hardness)? The third column the rows keep answering by themselves is whether anyone wanted the output.
-
-### 1.1 The rows
-
-| # | Programme | Attempted, by whom, when | Achieved (numbers) | Left undone | Why it stopped | Verified cheaper than done | Sampleable |
-|---|---|---|---|---|---|---|---|
-| 1 | Primecoin | Sunny King, 7 Jul 2013: header hash is the origin of a Cunningham or bi-twin prime chain | 13-prime 94-digit chain 10 Sep 2013; first length-15 twin chain 30 Mar 2018; height 7,038,822 today | Any use of the primes; GPU resistance (GPU miners by 2014, approximate) | Nobody needed the output; price USD 0.034, "stopped trading on all exchanges"; last release 26 Jan 2021 | Yes, but polynomial: 10 to 15 modexps to verify against millions of sieve steps (approximate) | Yes: the hash fixes the origin, chain length plus fractional remainder tunes hardness |
-| 2 | Gridcoin | Rob Halford, "Proof of Research" live 11 Oct 2014 on BOINC credit | 17 whitelisted projects, 3 greylisted; release 5.5.0.0 on 3 Apr 2026 (78 PRs, 11 contributors) | A verifiable work primitive; consensus moved to pure PoS 2014 to 2015 | Scraper nodes read credit from project servers and sign a superblock; the chain never checks a work unit | Only by trust (an oracle reads a website) | No: the miner picks the project and the unit; the project sets hardness |
-| 3 | Curecoin, FoldingCoin | 2014, Folding@home points paid daily (CURE) or monthly (FLDC on Counterparty) | 1 trillion F@h points by 28 Jul 2019, over 10,000 team members | Verification by anyone but Stanford's servers; Curecoin 2.0 roadmap undated; FoldingCoin asset archived, site gone | Tip jar on a centralised stats feed; token value fell under the electricity (approximate) | Only by trusting F@h | No: F@h assigns the work |
-| 4 | Aleo PoSW to synthesis puzzle | Proof of Necessary Work (Kattis, Bonneau, 2020/190); testnet 3 coinbase puzzle 2023; mainnet 17 Sep 2024 on AleoBFT with the puzzle outside consensus; ARC-41 synthesis puzzle | 750 M proofs per second and over 44,000 provers on testnet 3 (Messari excerpt); 2/3 of coinbase to provers; about 16 pools took close to 90 percent of puzzle rewards; ARC-46 (31 Jul 2025) demands 100,000 ALEO staked per solution, 2,500,000 by 2027 | The original promise: energy that produces proofs of real state. The puzzle proves nothing the network uses | A BFT validator set gives finality; the puzzle survives only to pay hardware and keep a prover fleet warm; proving centralised on the same path as mining | Yes (SNARK verify in milliseconds) | Yes (epoch hash plus nonce, target tunable). Useful: no |
-| 5 | Ofelimos | Fitzi, Kiayias, Panagiotakos, Russell, eprint 2021/1379, CRYPTO 2022: doubly parallel local search, every step a hashed PoW unit | A security proof in the backbone model; WalkSAT variant "competitive with vanilla WalkSAT" | Any deployment; who submits problems and pays; the search's own efficiency (FRLS follow-up 14 Nov 2025 calls DPLS "particularly wasteful") | Economics and operations, not the proof | Yes (each step is a cheap check) | Partly: the step is nonce-bound, the instance comes from a client pool, so hardness is tuned on the hash part |
-| 6 | PoW from worst-case assumptions | Ball, Rosen, Sabin, Vasudevan, eprint 2017/203 and 2018/559: Orthogonal Vectors, 3SUM, APSP with a delegation verifier | The conditions: worst-case to average-case reduction, non-amortisability, fast verification | Any implementation or benchmark; a buyer for random OV instances | The instances must be drawn from a distribution no real problem has; polynomial blow-ups | Yes (near-linear verify against quadratic solve) | Yes by construction. Useful: no in practice |
-| 7 | Filecoin PoRep and PoSt | Protocol Labs, mainnet Oct 2020: seal a 32 GiB sector (hours of CPU plus 20 to 30 min GPU SNARK, 128 to 256 GiB RAM), then daily WindowPoSt | Utilisation 29 percent (Q1 2025), 36 percent (Q3 2025), 1,110 PiB of real data on 3.0 EiB committed; raw byte power 3.01 EiB (29 Sep 2025) to 1.35 EiB (14 Sep 2026), down 55 percent; 99.5 percent of Q3 2025 fees were penalties | Paid demand; two thirds of proved bytes were zero-filled capacity; the chain now pivots to PDP hot storage (May 2025) that earns no consensus power | Sealing cost was paid by emission, not customers; when rewards fell providers left | Yes (one seal, then a sub-second daily proof) | Yes (random leaf challenges per deadline). The only row that held both for a real good, at hours per 32 GiB |
-| 8 | Chia proof of space | Chia Network, mainnet May 2021: plots of random tables, challenge per signage point | 1.5 EiB to 15 EiB in May 2021 alone, peak 36.5 EiB Jul 2021; a k32 plot needs 1.3 TiB of SSD writes; pooling Jul 2021; compression Jan 2023; under 4 EiB effective and under 3 EiB raw in Sep 2026 (about 10 percent of peak); XCH USD 1.36 against a USD 1,934.51 peak; Chia 3.0 (27 Feb 2026) resets plots to 1 GiB k28 with a 256-day phase-out | Anything stored; the space holds nothing | Price down 99.9 percent, reward per TB collapsed, no use for the plots | Yes (a few hashes) | Yes (challenge, plot filter, k). Useful: no |
-| 9 | Flux, Akash | Compute markets beside a coin: Flux (2018 as ZelCash, 7,015 nodes on 5 Oct 2026 against a 14,000 peak, no published revenue in six years, "PoUW v2" Oct 2025 = hardware benchmarking); Akash (Q1 2026 lease revenue USD 253,250, 58 providers, 84 GPUs in use of 334) | Node counts, not verified work | A chain that checks the compute; InFlux Technologies entered administration 4 Sep 2026 | Block rewards pay for idle capacity; demand is two to three orders under the subsidy | No (reputation and benchmarks) | No (customers pick the job) |
-| 10 | Dynex | 2022 to 2026, "neuromorphic quantum computing cloud", DynexSolve | A WIPO patent (14 Nov 2024); market cap USD 119,386, down 99.9 percent; a "phase-out of the utility token" toward a securities structure | A checkable claim: no public code shows the chain checking that a QUBO instance was solved | The useful-work claim was never made verifiable | Unknown, treat as not verified | Not sampleable |
-| 11 | Qubic | 2024 to 2025 "useful PoW" (Aigarth training); from Jun 2025 the work was Monero RandomX hashing sold for QUBIC buybacks | Under 2 percent of Monero in May 2025, over 25 percent by late Jul, 51 percent claimed 11 to 12 Aug 2025; 63 of 122 blocks (3,475,729 to 3,475,850); 6-block reorg 12 Aug (about 60 orphans); 18-block reorg 15 Sep 2025 (117 transactions, past Monero's 10-block lock) | Any verification of the AI claim; no Monero consensus change by Sep 2025; miners moved to P2Pool, exchanges raised confirmations | The "useful" work was a token buyback funded by attacking another chain | The RandomX part: yes, and useless by design. The AI part: no | The AI part: no |
-| 12 | Bittensor subnets | 2023 onward, validators score miners off-chain, Yuma consensus; dTAO 13 Feb 2025 | Over 120 subnets (Mar 2026); 24 with commercial income, USD 28 M to 35 M ARR estimated (Sep 2026); validator reward correlates with stake at 0.80 to 0.95, miner reward with performance at 0.10 to 0.30 (64 subnets, 6.66 M events); weight copying fixed by commit-reveal (May 2024); Quasar (SN24) collapsed Aug 2026 on a plagiarised model | Proof of anything; usefulness is judged, not proved | By design: a stake-weighted reputation market with emission attached | No (judged) | Partly (validators pick queries, no nonce, no hardness knob) |
-| 13 | Proof of inference, 2024 to 2026 | Gensyn Verde (refereed delegation, about 60 percent overhead on Llama-3.1-1B, needs one honest provider); Hyperbolic proof of sampling (re-execute a fraction, slash); Ambient proof of logits (claimed 0.1 percent overhead, testnet still pending Apr 2026); Inference Labs (self-reported 950 M proofs); zkML (hundreds of seconds per query for billion-parameter models); Boundless PoVW (pays ZKC per proved cycle, a sample proof 2 to 5 min at USD 0.04 to 0.17); Succinct (over 6 M proofs in 2025, 25 provers) | Proving networks exist and are run by a few dozen operators | A job that is both random and wanted; a verifier cheaper than a referee, a chip or a slashing game | zk proving costs 10^3 to 10^4 times the inference; the cheaper schemes trust something | zk: yes at 10^3 to 10^4 overhead. The rest: only by trust | zk: yes if nonce-bound. Nobody has made the job random and wanted |
-
-The 2025 to 2026 literature says the same thing from three sides. The SoK (eprint 2025/1814, over 50 constructions): "PoUW is actually not as useful as expected, since the economic and societal utility do not contribute to the security budget". Pass (arXiv 2606.06700): a majority attack still costs the block reward. Basu (arXiv 2606.04819): Pearl's 24 EH/s network of about 320,000 GPU-equivalents at about 112 MW "produces zero useful AI computation".
-
-### 1.2 The pattern, and what Igneum finishes
-
-Every programme that passed both tests (cheap verify, sampleable with tunable hardness) did so by making the work useless: Primecoin chains, Chia tables, Aleo's synthesis puzzle, Filecoin's capacity sectors, Boundless cycles. Every programme that kept the work useful gave up verification: Gridcoin, Curecoin, Bittensor, Flux, Akash, Qubic, Dynex. Filecoin alone held both for a real good and paid with hours of sealing per 32 GiB and a network two thirds filler.
-
-**What Igneum already finishes (two rows).**
-
-| Row | The unfinished promise | Igneum's finished form | Evidence in the repo |
-|---|---|---|---|
-| 4, Aleo PoSW and Proof of Necessary Work | Energy that produces succinct proofs of real state, paid from issuance | Every block is proven by miners in chunks and aggregated 20 to 60 s behind the tip; the provers are paid 20 percent of emission by sortition by weight; the proof is of the chain's own execution, not a synthetic circuit | CLAUDE.md design paragraph; lane 4's finding 1: the proof verified in consensus is the fix for the one line where a majority earned more than it spent (11,636 IGN an hour at 51 percent of blocks); switch `proving_consensus_verify_daa` ships off by default in 0.3.16, activation a decision owed |
-| 13, Boundless PoVW and Succinct | Pay per verified unit of proving, meter the cycles, let a market set the price | pgas cycle metering through the proving share; external jobs 90/10 provers and burn, priced in dollars, settled in the token | frontier.md 3.10 "PoVW-like cycle metering through pgas"; CLAUDE.md fee lines |
-
-**Why the split is the finished form.** The bound from `new-pow.md` 3.1 is the reason nobody closed the loop: the useful fraction of a proving-as-lottery scheme is (proving work per segment) over (network hashes per segment), 8 percent at 1 GH/s and 0.08 percent at 100 GH/s, because gas sets one and the security budget sets the other. Aleo found the same wall and decoupled on 17 Sep 2024 ("provers do not participate in consensus or produce blocks"), then had to add a stake gate in 2025 because the puzzle centralised on the fastest prover. Igneum's split carries no stake and no coupling: the lottery is a Poisson process on a random program (the Kaspa developer's objection in frontier 3.10 stays satisfied), the proving is paid by sortition by weight, and the one line where the split was NOT yet finished (a majority prover pool earning more than it spent) is closed by verifying the proof in consensus. Until that switch is on, Igneum's split is Aleo's 2024 form; with it on, it is the form Aleo could not reach without a validator set.
-
-**What Igneum should leave.** Rows 1 to 3, 5, 6, 9 to 12: 0 hours. The only adjacent idea with value was taken by lane 8 as scheme C (the dataset is the keyed execution state, the class v5 candidate), which answers rows 7 and 8 by making the stored thing the chain itself, at an unchanged hash rate; it is already judged and not repeated here.
-
-## 2. Group B: memory-hard and ASIC-resistance programmes that stalled
-
-The chip history is done in `asic-resistance-history.md`. This section covers only what was started and abandoned, and ends each row with what Igneum's hourly random program, latency shadow and class ladder already encode, and what they do not.
-
-### 2.1 The rows
-
-| # | Programme | What was planned | What shipped | What was left on the table | Why it stopped |
-|---|---|---|---|---|---|
-| 1 | Ethash successors | EIP-969 (David Stanfill, 3 Apr 2018): five FNV primes of Hamming weight 7 to 8 against the Antminer E3, fork at block 5,550,000 with 30 days' notice; ProgPoW as "Ethash 2" | Nothing on Ethereum. ETC's Etchash (ECIP-1099, Thanos, block 11,700,000, Dec 2020) halved DAG growth to keep 3 to 6 GB cards | The FNV tweak (Stagnant), the DATASET_PARENTS increase Least Authority asked for, any epoch recalibration on mainnet | No client team adopted EIP-969 for a chip expected to be short-lived; attention moved to ProgPoW; PoW ended at the Merge 15 Sep 2022 |
-| 2 | ProgPoW, EIP-1057 | Hold the chip gain to 1.1x to 1.2x by saturating the whole GPU datapath (random math, 16 KB cache, DAG loads, keccak-f800) | Two audits (Least Authority 9 Sep 2019: accurate to design, five suggestions, the light-evaluation attack named; Bob Rao: 100 MB on-die SRAM "possible", DRAM 3 pJ per bit against 0.3 on chip); KawPow (6 May 2020), FiroPoW (26 Oct 2021), Zano, Sero, Quai (29 Jan 2025) | Activation on Ethereum: tentatively accepted 4 Jan 2019, "accepted and final" 21 Feb 2020, petition EIP-2538 27 Feb, kik's 64-bit-seed exploit about 4 Mar, off the fork schedule 6 Mar 2020; authors reposted it 11 May 2020 saying "we do not recommend" deployment | Governance (a revival read as stealth), the PoS roadmap, a bug two weeks after "final", the authorship conflict (Core Scientific, Linzhi's 3x to 8x claim with no evidence) |
-| 3 | RandomX v2 | A tweak after seven years: program 256 to 384 instructions, 16 AES mixes in place of XOR, dataset prefetch 2 iterations ahead; work per hash up 52.9 percent (4,456,448 to 6,815,744 ops) to re-match CPU to memory latency | Library PR 317 merged 17 Feb 2026 (SChernykh); commitments PR 265 merged 8 Sep 2023 | Activation: Monero PR 10038 (v17) open since 14 Aug 2025, pending review 19 Sep 2026, no date | The chip came first: Antminer X5 Sep 2023 (212 kH/s, 1,350 W); X9 1 MH/s at 2,472 W listed as "August 2026, delayed" per resellers, unconfirmed shipping; the Qubic episode used plain CPUs so it forced no algorithm change |
-| 4 | Kaspa kHeavyHash | A hash for optical hardware (Dubrovsky, Ball, Penkovsky, arXiv 1911.05193): shift cost from OPEX to CAPEX; GPU resistance never a goal; chosen by community vote one day before launch | IceRiver KS0 (100 GH/s at 65 W, 2023), then 15 to 21 TH/s boxes; GPUs at 2.2 GH/s left | A GPU lane (never planned); optical mining (no shipping hardware, approximate) | By design. The GPU fleet forked away: Karlsen (FishHash, 4 GB DAG), Spectre (CPU), Pyrin |
-| 5 | Autolykos v2 | Keep the 2 GB table, grow it 5 percent per 51,200 blocks from block 614,400, cap at block 4,198,400 (2,143,944,600 elements) | EIP-0009 at block 417,792 (Feb 2021 approximate); non-outsourceability removed because contract pools bypassed it (Chepurnoy and Saxena, eprint 2020/044) and small miners did not want it | A successor to pool resistance; an answer to HBM FPGAs ("HBM FPGA friendly", Osprey listed ERGO); the growth stops at the cap | Small prize, no chip, the table cap is a policy choice |
-| 6 | Grin's two lanes | Cuckaroo29 for GPUs (90 percent of reward falling to 0 over two years, tweaked every six months), Cuckatoo31+ for chips (10 percent rising to 100) | Four hard forks on schedule; HF4 (about 15 Jan 2021) ended the GPU lane; one chip shipped (iPollo G1, 36 GPS at 2,800 W, Dec 2020) | Obelisk GRN1 cancelled 19 Jul 2019 ("lack of interest and funding", full refunds); Innosilicon G32 announced, never documented shipping; the lean-solver memory claim: Tromp's USD 10,000 linear TMTO bounty claimed 11 Apr 2025 (about half an order of magnitude, not tenfold) | The schedule forced chip makers to choose between a single-use C31 chip and a late C32 chip at a USD 2 coin; network today 3.40 KGps on GPUs |
-| 7 | Equihash parameter programmes | Zcash: a parameter change "ideally deployed by late 2018"; a 2020 PoW migration (ballot 3 Jul 2018: 38 of 64 for migration by 31 Dec 2020). Beam: forks at 6 and 12 months then an "affordable ASIC" (BeamHash III, 28 Jun 2020). BTG: Zhash 144,5 after the May 2018 51 percent attack (388,000 BTG) | Zcash stayed on 200,9 with chips (2019: BCTV14 forced the choice of Sapling over ASIC work); Beam stayed on BeamHash III with GPUs only; BTG forked and was hit again in Jan 2020 | Zcash's migration; Beam's affordable chip; BTG's real problem (rented hash on a small chain) | Governance by poll chose "reduce chokepoints" over resistance; parameter forks do not fix a rentable chain |
-| 8 | Octopus to Ethash | CIP-102 (Chenxing Li, 5 Aug 2022): switch to Ethash "to make it easier for Ethereum miners to switch to Conflux" | Nothing; the CIP has "TBA" for specification and rationale and never left Draft | The AMD support and DAG shrink the forum asked for instead | The community called Ethash "not ASIC resistant" and Octopus "the trademark" |
-| 9 | Blake3 on Alephium | ASIC friendly by design, "just like Bitcoin" | Goldshell AL-BOX (360 GH/s, May 2024 per the aggregator), Antminer AL1 (15.6 TH/s, Jul 2024); the project's own gpu-miner and fpga-miner repos stopped mattering | Nothing, by the project's own view | By design |
-| 10 | Tensor PoW | Komargodski and Weinstein, eprint 2025/685: PoUW from arbitrary matrix multiplication at 1+o(1) overhead; "this blockchain is currently under construction" | A paper (15 Apr 2025, revised 8 Dec 2025). ethresear.ch has no topic matching "tensor core proof of work" | A chain; a measurement of what tensor work costs the honest card against a chip | Nobody measured it before writing it |
-
-### 2.2 The FPGA question, one line per row
-
-| Row | Was the FPGA the first adversary | What stopped it |
-|---|---|---|
-| Lyra2REv2 (Vertcoin) | Yes: a Zynq UltraScale+ at 31.25 MH/s and 24.93 W, 4.3x a Titan Xp per joule (arXiv 1905.08792) | A fork to Lyra2REv3 |
-| X16R (Ravencoin) | Yes: all 16 hashes on one UltraScale+, about 5x a 1080 Ti per joule at 3 to 4x the price | X16Rv2 then KawPow |
-| Equihash 144,5 and 200,9 | Promised in 2018 (a vendor asked a USD 1,000,000 minimum order), no hashrate ever posted | The 2.5 GB table; HBM boards matched GPUs per dollar at best (approximate) |
-| Ethash and ProgPoW | HBM boards existed in 2019; Least Authority: a 10-block period makes "building and loading a bitstream in such a short period (about 2 minutes) impractical" | DRAM latency on cheap boards, HBM cost on fast ones, bitstream churn |
-| Autolykos v2 | Osprey listed ERGO on an 8 GB HBM board; no share figure published | Nothing stopped it; nothing measured it |
-| kHeavyHash | Osprey E300, 14 GH/s at 250 to 500 W, USD 4,999, three VU35P with HBM2, announced 13 Dec 2022 | Overtaken within months by 100 GH/s to 1 TH/s ASICs |
-| RandomX, Cuckoo | No FPGA product ever shipped | A CPU-like core with 2 MB per thread; 512 MB to 1 GB of fast memory per graph |
-
-### 2.3 What Igneum already encodes, and what it does not
-
-| Row | Encoded in Igneum (where) | Not encoded (the gap) |
-|---|---|---|
-| 1 Ethash successors | A dataset that grows on a genesis-fixed schedule with the cache doubling (256 MiB, 512 MiB year 4, 1 GiB year 12); the 4 GB cliff lesson lives in the tier rule ("every number carries its consequences", 8 GB to 32 GB cards); EIP-969's human tweak against a chip is replaced by automatic era draws | The DATASET_PARENTS idea is Igneum's mixer x8 (8 dependent reads per item), which has the fixed shape the chip history calls the 3x factor; the random item derivation (asic-history addition 2) is still open |
-| 2 ProgPoW | The governance death is designed out: every layer is a genesis rule or a reserve, no adoption vote (asic-history lesson 7); the 64-bit-seed class: Igneum's seed is 256 bits and the program is the epoch's; the light-evaluation attack is priced (chip-model-v3, 0.31x bare, 0.92x with the 3x factor); the datapath target is the whole GPU | ProgPoW's 2-minute period was its FPGA defence; Igneum's epoch is 1 h, so a soft-overlay bitstream within the hour is the open lane (asic-history addition 5, the 10 min to 2 h epoch reserve, design on `ca2-epoch`) |
-| 3 RandomX v2 | The lesson is that a tweak after seven years arrives after the chip. Igneum draws era parameters every 6 months from chain state and unlocks families by height, with no human release; the class ladder (95 percent with a floor height, P2) is the only human path and it is for new code, not for parameters | Per-hash program entropy (RandomX's 25x GPU cost, refused on purpose); the random superscalar item derivation; four external audits before launch (RandomX paid USD 141,000; Igneum's cryptanalysis spend of USD 80,000 to 160,000 is a decision owed) |
-| 4 kHeavyHash | The loss of the GPU fleet is the metric: hashrate share by card model from the observer and the January 2027 benchmark (asic-history addition 4) | A published vendor-share number does not exist yet |
-| 5 Autolykos v2 | Pools are wanted (spec 09), so non-outsourceability is nowhere by choice; the dataset grows by rule | Whether Igneum's growth schedule ever caps is a spec 1.13.3 question this lane did not reopen |
-| 6 Grin | Scheduled change without a vote is the shared idea; Igneum's draws are automatic, Grin's were forks | The lean-solver lesson (a memory claim weakened six years later by a bounty) is the reason the mixer and chained cache need cryptanalysis (ledger M7) |
-| 7 Equihash | The rented-hash problem is answered by the 30-day weight finality, not by the hash (section 4) | Nothing |
-| 8, 9 Octopus, Blake3 | Nothing to take | Nothing |
-| 10 Tensor PoW | Measured and retired: scheme B's mm8 shadow costs the honest card 0.056 to 0.70 pJ per multiply-add and moves the chip's edge only from 6.9x to 4.9x, so it is reserve R8 with the two-output correction (new-pow.md 6) | Nothing; Igneum did the measurement the 2025 paper has not |
-| FPGA, all rows | Bitstream churn is encoded as the hourly program; the HBM board is the f = 1 stored-dataset chip in the model (5.1x on GDDR7, 7.5x to 9.2x on HBM3) | The soft-overlay FPGA miner with HBM is unmeasured (addition 5); no row in the chip model for a partial-store chip (addition 1) |
-
-Verdict for the group: nothing in B is a programme Igneum should restart. The three unfinished items that do matter are Igneum's own open rows (random item derivation, external cryptanalysis, the epoch-length and FPGA-overlay measurement) and they are already ranked in `asic-resistance-history.md` 4.3.
-
-## 3. Group C: merged mining and multi-algo
-
-### 3.1 The rows
-
-| # | Programme | When, by whom | What it bought (numbers) | The attacks and the costs | Left undone |
-|---|---|---|---|---|---|
-| 1 | Namecoin AuxPoW | Block 19,200, Oct 2011 (vinced; Mike Hearn's outline) | Bitcoin's hashrate for free: about 95 percent of Bitcoin on 12 Jan 2020, about 69 percent (732 EH/s) in Sep 2026; nine pools find blocks (AntPool 34.78 percent, F2Pool 19.99, ViaBTC 19.69, 14-day window to 20 Nov 2025) | One pool (F2Pool) above 50 percent of Namecoin for most of late 2014 to 2016 (approximate; Judmayer et al.: pools "operated at the edge of, and even beyond, the security guarantees" of Nakamoto consensus); the spec's nonce-clash flaw is documented and a replacement BIP never came | Independence: the child's rules are signalled by the parent's pools; Foundry, the largest Bitcoin pool, does not merge-mine it; the name market never grew |
-| 2 | Dogecoin on Litecoin | Hard fork at block 371,337, Sep 2014, after Charlie Lee's Apr 2014 proposal; Dogecoin's own words: "our hashrate has been on a decline" | Hashrate up over 1,500 percent in Sep 2014; DOGE and LTC hashrates correlate at 0.95; about 90 percent of DOGE hashrate from Litecoin pools by 2019; DOGE's share of pool revenue "has long surpassed" Litecoin's (F2Pool data, 7 Apr 2026) | A pool above 50 percent of Litecoin is above 50 percent of Dogecoin by construction | A miner base of its own; any say in the parent's rules |
-| 3 | Myriadcoin and Verge multi-algo | Myriad 23 Feb 2014 (five algos, per-algo floating difficulty, 20 percent of blocks each); Verge (five algos) | Hardware diversity | Verge, Apr 2018: timestamps spoofed about an hour back on the Scrypt lane, per-lane difficulty collapsed, blocks seconds apart, 250,000 to about 20 M XVG (reports conflict); 22 May 2018: Scrypt and Lyra2re both at near-zero difficulty, about 25 blocks a minute, 35 M XVG (about USD 1.8 M); the hard fork between them did not remove the bug; a 560,000-block reorg in Feb 2021 (headline only) | Five lanes made the surface five times wider; each lane is cheaper to rent than the whole |
-| 4 | DigiByte MultiShield, Odocrypt | DigiShield Feb 2014 (block 67,200), MultiAlgo Sep 2014 (145,000), MultiShield Dec 2014 (400,000), Odocrypt Jul 2019 (9,112,320): per-block retarget on all five lanes from a 10-block average, clamps 16 percent down and 8 percent up; Odocrypt rewrites itself every ten days for FPGAs | DigiShield was adopted by Dogecoin (1.6, Mar 2014) and Zcash (v3 variant, approximate); the "93 percent on one algo and 51 percent on the other four" claim is a model, not a measurement | 28 Jun 2026: a dropped validation rule on the Groestl lane let about 1,356 blocks (about 351,000 DGB) be mined, no double spend | A lane with little hashrate still mints one block in five; the ten-day rewrite assumes FPGA owners re-flash and does nothing against a party with many FPGAs |
-| 5 | Elastos, RSK | Elastos with Bitmain 28 Aug 2018 (AntPool, BTC.com); RSK since Jan 2018 (approximate) | Elastos "over 50 percent" of Bitcoin's work (13 Mar 2024); RSK 62.46 percent (Q1 2024), 54.58 (Q3), 56.40 (Q4 2024, AntPool 38.6, ViaBTC 24.3, F2Pool 16.9); Foundry joined | RSK's Armadillo (RSKIP110): detects forks up to about 448 blocks when the attacker has under 9 percent of Bitcoin; "cannot stop a miner creating a blockchain from a past point"; the PowPeg is a federation with HSMs | The attacker rents or bribes three pools, not hardware; Armadillo alerts, it does not finalise; usage stayed small so fees stayed small |
-| 6 | The paper | Judmayer, Zamyatin, Stifter, Voyiatzis, Weippl, "Merged Mining: Curse or Cure?", eprint 2017/791 | One line: merge-mined chains concentrate in fewer pools than the parent, with single pools above 50 percent for months in Namecoin, Huntercoin and Myriad (approximate for the per-coin detail) | | |
-
-### 3.2 Verdict: does Igneum want any of it
-
-No, with four reasons. Igneum's ruling is already "no reliance on another chain"; the question left is whether an Igneum-side auxiliary chain or an "algo slot" has value, and it does not.
-
-| Option | What it would buy | Why not | Hours |
-|---|---|---|---|
-| Igneum as a merge-mined child of another chain | Borrowed hashrate | Ruled out (CLAUDE.md: no other chain in consensus); and the rows show the child inherits the parent's pool concentration and loses its say in rules | 0 |
-| Igneum as a parent for other chains | Nothing for Igneum; a coinbase commitment slot for others | The hash is a new program every hour, so a child cannot verify Igneum work without Igneum's program pipeline, VDF seed and dataset; the vote key per operator would not carry to the child; the only cost is a header field nobody asked for | 0 until asked |
-| An algo slot (a second hash lane) | Hardware diversity | Myriad, Verge and DigiByte show each lane is a separate difficulty controller and a separate rentable surface; Igneum's 30-day vote weight is counted in blue blocks of ONE work unit, so a second lane splits the weight table and the DAA; GHOSTDAG's k is derived from one block rate on one hash | 0 |
-| A share sidechain merge-mined through the coinbase | A pool without an operator | This is the one merged-mining shape with value, and it belongs to section 5 (it is how Monero P2Pool works) | see 5.3 |
-
-## 4. Group D: GPU-friendly finality attempts
-
-The one axis asked: can a renter buy or break finality in a day? Igneum's rule for comparison (CLAUDE.md, finality rule v2): vote weight = blue blocks per vote key over a flat 30-day window, lock at 2/3 of all 30-day weight, so 10 days of 100 percent hashrate reach 1/3 of weight and 20 days reach 2/3; 51 percent never reaches 2/3 while honest miners stay.
-
-### 4.1 The rows
-
-| # | Programme | Attempted | Finished | Left undone | Renter buys finality in a day? |
-|---|---|---|---|---|---|
-| 1 | Decred hybrid | Feb 2016: tickets vote on every block, 3 of 5 called tickets must sign; 40,960 ticket pool, 28-day average wait | A PoS veto on every block, stakeholder-voted forks, a treasury; stake locked rose from 50 percent (Dec 2019) to 64 percent (Dec 2022) while hashrate fell about 6x; DCP-0011 (BLAKE3 and ASERT) and DCP-0012 (PoW to 1 percent of subsidy) active at block 794,368 (Aug 2023) because PoW was "used to maliciously manipulate Decred markets" | No finality gadget; PoW is a 1 percent stipend | No for reorgs (needs about half the live ticket pool, roughly 30 percent of DCR bought over 28-day cycles, approximate); yes for withholding and censorship, since the hash layer is thin |
-| 2 | Horizen delayed-block penalty | After the 2 Jun 2018 51 percent attack (over USD 500,000, 36 fake blocks): a block n late owes about n(n-1)/2 extra blocks (approximate formula); shipped in ZEN 2.0.16, late 2018 | A reorg tax on hidden chains | Partition safety: the smaller honest side looks like a hidden chain; Horizen now calls itself an L3 on Base and the PoW mainchain is winding down (approximate) | Yes under 5 blocks and for public mining; a deep secret reorg costs quadratically more. A tax, not finality |
-| 3 | Kaspa merge depth and finality depth | MERGE_DEPTH_DURATION 3,600 s, FINALITY_DURATION 43,200 s, PRUNING 108,000 s in rusty-kaspa constants; at 10 BPS since Crescendo (about 5 May 2025): merge depth 36,000 blocks, finality depth 432,000 | Online nodes refuse a reorg deeper than 12 hours; a block cannot merge a side chain older than an hour | Both rules are local and subjective; a node syncing later follows the heaviest DAG; DAGKnight (eprint 2022/1494) is in PRs (1104, 1124, 1132) and not on mainnet | Partly: under 12 hours yes with over 50 percent of an ASIC-only hash (thin rental supply); over 12 hours the attacker splits the network instead |
-| 4 | Conflux Tree-Graph, GHAST, PoS votes | GHAST (arXiv 2006.01072): confirmation in O(d log 1/epsilon), about 3d against about 360d for six Bitcoin blocks; adaptive weight switches to a conservative mode under a liveness attack | CIP-43 (Hydra, about 28 Feb 2022): a PoS chain of staked CFX (1,000 CFX per vote) votes on pivot blocks "to protect against 51 percent attacks from PoW" | GHAST alone is probabilistic; the PoS committee is the finality | No for finalised pivot blocks; yes inside the trailing minutes |
-| 5 | Ethereum Casper FFG over PoW | EIP-1011 (20 Apr 2018): 1,500 ETH minimum deposit, 50-block epochs, "never revert finalised blocks"; testnet 31 Dec 2017 | Nothing on mainnet; the Berlin Eth2 workshop (Jun 2018) discarded hybrid Casper for the beacon chain | The hybrid itself | Under the design: no for finalised checkpoints (slashing two thirds of deposits), yes inside an epoch. Dropped because "the limited bandwidth of the EVM constrained the size of the validator set", forcing whale-sized deposits |
-| 6 | Bitcoin Cash Avalanche pre-consensus | Sechet, Sep 2018 (approximate) | On BCH: nothing. On eCash (XEC): post-consensus finality 14 Sep 2022, staking rewards 15 Nov 2023, pre-consensus 15 Nov 2025 at block 923,347 ("finalise transactions in under 3 seconds"); staked XEC 69.4 B to 242 B in the year to Jul 2024, 350 B+ by Jul 2026; 33 to 94 nodes; 100 M XEC minimum per stake UTXO with 2,016 confirmations | BCH never got it; no slashing (approximate); on quorum loss the chain falls back to heaviest work | No while the quorum holds; yes if the attacker knocks the about 94 Avalanche nodes offline |
-| 7 | Ethereum Classic MESS | ECIP-1100, active at block 11,380,000 (Oct 2020) after three Aug 2020 reorgs (3,594, 4,446 and 7,278 blocks; 807,000 and 465,444 ETC double spent): a capped polynomial, up to 31x the local chain's difficulty for a segment older than about 7 hours | No deep reorg on ETC after Oct 2020 (approximate) | Deactivated by ECIP-1110 at block 19,250,000 (Spiral, Jan 2024) because "the costs now outweigh the risks"; Core-Geth v1.13.0 (15 Sep 2026) re-enabled it with 96 unreviewed commits, miners rolled back the same day, PR 53 (merged 6 Oct 2026) restored the deactivation | With MESS on: no for reorgs older than 7 h, yes for short ones, and an eclipse strands a victim. Off today: yes, plain PoW |
-| 8 | Zcash trailing finality layer, Crosslink | ECC's TFL book (2023, Wilcox and Hopwood); Shielded Labs builds zebra-crosslink, "a proposed upgrade"; BFT PoS finalises a trailing prefix, PoW continues if BFT stalls | An incentivised feature net; milestone 4 of 5 in early 2026 (search summaries) | Mainnet: nothing by 7 Oct 2026 | Today: yes (plain Equihash, rentable, approximate). Under Crosslink: no for finalised blocks, yes inside the trailing window |
-| 9 | Nervos CKB | NC-Max (eprint 2020/1101): two-step confirmation, 3.0 to 6.6 times shorter latency; Eaglesong "ASIC neutral", first chip four months after launch | NC-Max runs since launch | No finality layer; no hybrid plan | Yes in principle; ASIC-only supply is thin |
-| 10 | Dash ChainLocks, Syscoin, Komodo | Dash DIP-0008 since block 1,088,640 (Jun 2019): an LLMQ of 300 to 400 masternodes signs the first block seen, 240 signatures lock it; Syscoin copied it over Bitcoin merged mining (4.2.0, block 1,004,200, 30 Apr 2021); Komodo notarises to Bitcoin then Litecoin every 10 to 25 minutes through 64 elected notaries | Finality in about one block (Dash) | A second validator set bought with coins (1,000 DASH per masternode, approximate) or elected (Komodo's 64) | No for locked blocks |
-
-### 4.2 The comparison on the one axis
-
-Every finality on a PoW chain that holds in practice is a second validator set paid in coins: Decred tickets, Dash and Syscoin masternodes, eCash stake, Conflux PoS, Komodo notaries, Casper FFG's 1,500 ETH deposits. Every rule that only reweights work (Horizen's penalty, MESS, Kaspa's 12-hour depth) is subjective and partition-sensitive, and two of the three have been switched off or are winding down.
-
-Igneum is the only design in the table whose second set is the miners themselves, weighted by past blocks, with no coins staked. On the one axis:
-
-| Attacker | Decred | Kaspa | MESS (on) | eCash | Igneum |
-|---|---|---|---|---|---|
-| Rents 100 percent of hashrate for one day | Withholds, cannot reorg | Reorgs up to 12 h | Reorgs up to about 7 h | Nothing while the quorum holds | Reorders inside the 90-second window (horizon 1, finding 3), nothing past a certificate; has 1/30 of a window's weight at the end of the day, needs 2/3 |
-| Rents 100 percent for 20 days | Same | Splits the network | Same as above | Same | Reaches 2/3 of weight only if every honest miner has left; with honest miners staying, 51 percent never reaches 2/3 |
-| Buys coins | Buys tickets over 28-day cycles | n/a | n/a | Buys stake | Nothing; weight is not for sale |
-
-What is unfinished in Igneum's own finality is Igneum's, not the industry's: the signed LEAVE item (0.3.16) after the 6 October pause (42.7 percent of the frozen voter table left in three minutes and the pause held a window), the 10-percent-per-hour removal rule, weight-gated deep fork choice and vote-or-burn (horizon 1, findings 2 and 3). The one lesson this group adds: every subjective reweighting rule was eventually turned off by its own chain (MESS twice), so the "no hidden-block n^2 penalty" removal in Igneum's rule v2 was the right side of the history.
-
-## 5. Group E: decentralised pools
-
-### 5.1 The rows
-
-| # | Programme | When, by whom | Design | What it achieved (numbers) | Why it stalled or died | Left undone |
-|---|---|---|---|---|---|---|
-| 1 | Bitcoin P2Pool | Forrest Voight, 2011 | A share chain with a 30-second share period; window = shares worth 3 blocks of work or 8,640 shares (72 hours), whichever is smaller; the generation transaction pays the window; 0.5 percent to the finder, no operator | 350 GH/s in Apr 2012 (about 2 to 3 percent of Bitcoin, approximate); 1.4 TH/s by Jul 2013; today 915 TH/s on 14 payout addresses (about 0.0001 percent of about 950 EH/s, my division); last commit 19 Sep 2018 | Variance for small miners (a small miner rarely lands a share in the window), dust (one output per miner per block), a 20x faster chain so stales are "common and expected", a 2012 orphan flaw, a Python 2 node on a full bitcoind | Payout aggregation, per-miner vardiff inside the chain, a maintained node (c2pool's C++ rewrite says "v37 is design-stage, do not run in production") |
-| 2 | Monero P2Pool | SChernykh, Aug 2021 | A sidechain merge-mined with Monero: 10-second blocks, PPLNS up to 2,160 blocks (6 hours), uncles at 20 percent less, payouts in the Monero coinbase, 0 percent fee, about 0.00027 XMR minimum, every miner runs monerod; three chains (main, mini, nano since v4.7, 30 May 2025); Tari merge mining since the 12 Oct 2024 fork | Today: main 441 MH/s and 561 miners, mini 25.3 MH/s and 1,997, nano 4.8 MH/s and 962; 471 MH/s and 3,520 miners in all, 7.7 percent of 6.13 GH/s (my division); against SupportXMR at 2.35 GH/s (38 percent) and HashVault at 672 MH/s (11 percent); the Monero GUI bundles it | A local node is mandatory; below about 15 MH/s of pool hashrate "not all shares will result in payouts"; three chains fragment the hashrate; share has fallen from double digits (approximate) to 7.7 percent | A light mode; cross-chain vardiff; payout smoothing for mini and nano miners |
-| 3 | Stratum V2 | Braiins (Moravec, Capek) with Matt Corallo, 2019, from Corallo's BetterHash draft (12 Mar 2018, never past specification) | Binary, Noise-encrypted; Mining, Job Declaration (renamed from Job Negotiation) and Template Distribution sub-protocols; the SRI translation proxy | SRI v1.0.0 tag 23 May 2023, v1.12.0 17 Sep 2025; native V2 pools: Braiins (JD "since about 2020"), DEMAND (public Nov 2025), ckpool (31 Jul 2026); firmware: Braiins OS, Bitaxe ESP-Miner v2.14.0 (Jun 2026), Auradine; stock Antminer and WhatsMiner are V1 only; the first known Job Declaration block is 955,318 on 25 Jun 2026 (DMND, GoMining's template); seven pools holding about 75 percent of hashrate joined the working group on 7 May 2026 "still in testing" | No primary number for SV2 hashrate; the two V2-native pools mined 753 and 1 of 52,297 blocks in the last year, so under 2 percent on SV2 at all and far under 0.1 percent on JD (approximate conclusion) | Stock firmware, JD at any top-five pool, Windows template building ("not yet supported"), a payout scheme that rewards miner-built templates, any measurement of adoption |
-| 4 | Braiins Pool | Slush Pool, Nov 2010; the first anti-hopping score (Rosenfeld 2011, section 3.1) | FPPS "0 percent fees with Braiins OS", 2 percent otherwise; on-chain or Lightning payouts | 13.91 EH/s, 177,359 workers, 13,112 users today; 753 of 52,297 blocks (1.44 percent) in the last year | The oldest pool and the SV2 author holds 1.4 percent | SV2 adoption did not become hashrate |
-| 5 | Ocean | Luke Dashjr, 28 Nov 2023, USD 6.2 M seed led by Jack Dorsey | TIDES: a share log eight times the difficulty deep, each share rewarded about eight times, 99.9665 percent chance of at least once, paid in the coinbase itself; DATUM (29 Sep 2024): the miner runs a gateway and a full node and builds its own template, 50 percent fee discount (2 percent, 1 percent with DATUM) | First block's coinbase came from a test server and paid nobody (4 Dec 2023 post-mortem); today 28.97 EH/s, 2,522 users, 1,553 blocks of which 1,316 DATUM (85 percent, my division), 1,073 of 52,297 blocks (2.05 percent) in the last year; Tether committed hashrate Apr 2025 | The template fight: Bitcoin Knots filtered inscriptions and Samourai transactions at launch; Dashjr resigned 29 Aug 2026 after the "mining divide" | A single operator still runs TIDES accounting, share verification and the generation transaction; non-DATUM miners get the pool's policy |
-| 6 | DEMAND | Guru Protocol Ltd (company 15235937), Alejandro De La Torre; launched Mar 2025 on the SRI, public Nov 2025 | "The world's first Stratum V2 mining pool"; SLICE pays subsidy by hashrate and fees "by the value you built"; Rootstock merge mining | 1 block in 19 months | Scale | SLICE at size |
-| 7 | Kaspa pools | Today: 334.9 PH/s; F2Pool 98.14 PH/s (29.3 percent), HumPool 92.95 (27.8), ViaBTC 37.89 (11.3), K1Pool 16.74 (5.0), WhalePool 13.67 (4.1); top two hold 57 percent | All PPLNS or PPS+ with 0.5 to 4 percent fees | No non-custodial or P2Pool-style pool; solo bridges only (K1Pool Solo, Kaspa-Pool SOLO, HeroMiners SOLO); no pool page explains which DAG blocks pay (approximate: blue blocks in the mergeset, red blocks earn nothing) | n/a | A decentralised pool on a DAG chain has never been built |
-| 8 | SmartPool | Luu, Velner, Teutsch, Saxena, eprint 2017/019, USENIX Security 2017 | Shares in batches ("1 transaction can claim 1 million shares") in an augmented Merkle tree; the contract samples k random paths; a caught cheater is paid nothing | ETC first ("over 30 blocks"), Ethereum closed beta Jun 2017; 105 blocks across both, peak 30 GH/s from 2 miners (about 0.05 percent of Ethereum, approximate); cost 0.6 percent of block rewards in transaction fees | Gas prices rose about ten-fold in 2017 and the claim cost passed the fee it was meant to beat; the beta never opened; the team founded Kyber; PoS removed the target (all approximate: smartpool.io is dead) | Any successor with hashrate; the opposite approach (Autolykos v1's non-outsourceable puzzles) was bypassed with collateralised contracts (eprint 2020/044) and removed |
-| 9 | Non-custodial on GPU chains, 2024 to 2026 | Ravencoin: 2Miners 292.67 GH/s with "51 percent of recent blocks", Hiveon 621 GH/s, no P2Pool; Ergo: 2Miners 303.14 of 491.76 GH/s (61.6 percent), no P2Pool; SoloPool.org sells solo mining at 1.5 to 2 percent "no pool wallet, no balances" | | Outside Monero every "non-custodial" offer is solo with a stratum bridge, not pooled variance reduction | | |
-
-Share verification cost, from the sources: a Scrypt proxypool spends "around 50 percent of the server's CPU time" checking shares; RandomX light mode on an i9-9900K verifies 1,160 H/s on 16 threads, so a core checks about 70 shares a second (fast mode about 700); Bitcoin SHA256d is microseconds per share (approximate, 10^5 to 10^6 per core). Igneum's pool v0 checks every share on the CPU warp verifier at 1.35 ms isolated and 2.1 ms under load, 480 to 740 per core (`pool.md` section 5), which is RandomX-fast-mode class, 1,000x a SHA256 share.
-
-The payout pattern: FPPS won on Bitcoin because large pools carry variance and sell certainty (Foundry about 30 percent, AntPool about 19, ViaBTC 14, F2Pool 10, d-central 2026); every non-custodial design (P2Pool, Eligius CPPSRB, TIDES, SLICE) is PPLNS-shaped because a coinbase cannot pay a debt. That is the structural reason non-custodial pools stay small, and it is the reason Igneum's pool is PPLNS.
-
-### 5.2 What Igneum's pool lacks against the best of these
-
-Igneum's pool v0 (`docs/plans/pool.md`, spec 09): newline JSON over plain TCP, mode A templates, every share CPU-verified, PPLNS over 2 blocks of weight, 1 percent fee, payouts by EIP-1559 transfer from the pool's coinbase key after blue confirmation, `state.json` every 15 s, the member's vote key in every header it hashes, the pool holds no key, the member checks seeds, class and era against its own node.
-
-| Axis | Best in the field | Igneum v0 | The gap |
-|---|---|---|---|
-| Operator trust for payout | Monero P2Pool and TIDES pay in the coinbase itself; nobody holds a balance | The operator holds the 80 percent in its coinbase address and pays by transfer at most 16 per round; a crash loses up to 15 s of shares; a dishonest operator can misaccount or withhold | The whole of the trust. Mode C (declared templates) and vote carriage are designed, not built; neither removes the operator from payout |
-| Operator trust for template and vote | DATUM and SV2 Job Declaration let the miner build the template; neither touches governance | The member's vote key rides in every header (no Stratum pool does this); mode C is designed, not built | Transaction choice is the pool's in mode A; the vote is already the member's |
-| Variance | P2Pool main: 6-hour window, 561 miners; Ocean: a window 8 difficulties deep | PPLNS over 2 blocks of weight at 1 block a second: a 2-second window of work. Each share is 2^-s of a block, so a 100 MH/s card at one share per 10 s is paid on every block it has a share in | The window is short because blocks are frequent; variance is a block-time question, not a pool question, and v0 has no number for the income variance of a 100 MH/s member at devnet scale |
-| Share verification | Full recompute everywhere; sampling at high difficulty (spec 9.8 item 5, allowed above shift 8, not built) | 1.35 to 2.1 ms per share, one core per 480 to 740 shares a second, no sampling | One template fetch per member per second is the real limit: 1,000 members is 1,000 `getBlockTemplate` calls a second and 10 MB/s (pool.md section 3) |
-| Transport | SV2 Noise encryption, binary framing | Plain TCP, `binding` sent empty, against spec 9.3's TLS 1.3 | Q67 (polish 3.6): 8 hours |
-| Stats and alerts | 2miners charts, offline alerts, luck | 15-minute samples not persisted, no `/metrics`, no payout history on the page, luck defined inverted | Q68 to Q73: about 17 hours |
-| Finality | No pool in the field has a finality concept | Pays on blueness, says nothing during a pause | Q73: 1 hour |
-
-### 5.3 "Shares as first-class protocol objects, no operator": already in Igneum, partly
-
-| Piece | In Igneum already | Where | What is new |
-|---|---|---|---|
-| Governance weight follows the hasher, not the pool | Yes: the vote key per operator in the header (spec 9.6), pool concentration is not vote concentration | spec 2.2 fork point a5, spec 9.6 | Nothing; this is further than SV2 or DATUM went |
-| An operator-less payout by weight | Yes for the 20 percent: the proving share is paid by sortition by weight from consensus data, no operator | CLAUDE.md, `executor.rs` (pool.md "The 20%") | Nothing for provers |
-| A share the chain can see | No: a share is a pool message, verified by the pool, paid by the pool | spec 9.8 | This is the new thing |
-
-The finished form is Monero P2Pool's, not SmartPool's. SmartPool's on-chain claims died on gas at Ethereum's share rate; at Igneum's 1.35 ms per share verification, a contract that samples k paths per million-share claim would still need the zkEVM to re-derive the program's warp unit per sampled share, which is the one cost the design keeps off the chain. A share sidechain merge-mined through the coinbase extra data is the shape that works: Igneum's coinbase already carries the member's key reveal and the pool's address (pool.md section 2), so the commitment slot exists.
-
-| Finish | What it is | Hours (agent) | Gate |
-|---|---|---|---|
-| A P2Pool-style share sidechain in the pool crate | Shares form a 10-second chain committed in the coinbase extra data; the window's payout is the block's own coinbase split (the execution layer already credits by rule from consensus data for the 20 percent, so the 80 percent split follows the same path); no balance, no operator key; every member runs a node (the design already assumes one, spec 9.1) | about 40 (sidechain 16, coinbase split in the executor 8, member client 8, Devnet 2 crossing 8) | a 3-node fast-time network pays a window with no operator; an operator that drops every share from one member cannot stop that member's payout |
-| Mode C declared templates | The miner builds the block (DATUM, SV2 JD) | 6 (O-9.4 RPC 2, messages 4) | a declared template is paid like any other |
-| TLS and the `binding` field | spec 9.3 | 8 (Q67) | a replayed `authorize` on a second connection is refused |
-
-The verdict for the group: finish the share sidechain, because it is the one unfinished thing in the field that Igneum's existing objects (vote key in the header, coinbase extra data, execution-layer credit by rule, a node per member) make cheap, and nobody has built one on a DAG chain.
-
-## 6. Group F: mining app UX and the "one click" promise
-
-### 6.1 The rows
-
-Minutes to first share are approximate unless a source is named; they count from the download to the first accepted share on a fresh machine with a driver installed.
-
-| # | Product | Install to first share (min, approximate) | Custody | Fee | What it did that nobody else has | What it left undone | State 2026 |
-|---|---|---|---|---|---|---|---|
-| 1 | NiceHash (2014; QuickMiner 2020, approximate) | 5 to 10 | NiceHash wallet, BTC only; 2.5 M users (infobox) | Seller 2 percent, buyer 3 percent (approximate); BTC deposits at or above 0.00005 BTC free, Lightning free above 0.0000001 | A hashpower marketplace: the miner never picks a coin | Custody: 6 Dec 2017 spear-phishing hack, about 4,700 BTC (USD 64 M), Lazarus indicted 17 Feb 2021; repayment completed Dec 2020 (approximate); no node, no wallet of the user's own | Alive |
-| 2 | HiveOS (2017) | 20 to 40 (flash an image on a second machine or drive, make a web account) | Hiveon pool pays the user's wallet | 2 workers free (3 days of stats); USD 0.50 per card per month to USD 3.00 at 6 or more cards; ASIC USD 2 or free with Hiveon firmware; 10 to 50 percent off at 50 to 1,000 workers | Farm-scale remote management, charts over hours, Telegram and Discord alerts, per-GPU clocks | A second machine or a flash drive; a web account; no local-only mode, no wallet, no node | Alive |
-| 3 | Minerstat, Awesome Miner | 15 to 30 | User's pool and wallet | minerstat free to 2 rigs, about USD 1.46 per rig per month on larger plans (approximate); Awesome Miner free to 2 miners, paid from about USD 4 per month (approximate) | Awesome Miner: "up to 200,000 ASIC and 25,000 GPU miners" from one Windows console | Management only; no node, no wallet, no pool | Alive |
-| 4 | Salad (2018) | 5 | Salad Balance, redeemable for PayPal, gift cards, games | Not published | Gaming-PC "earn while idle"; 450,000+ GPUs since 2018; 16,000+ daily active GPUs in 190+ countries today | Mining itself: the site no longer mentions crypto; SaladCloud sells GPU-hours from USD 0.015; the user's take rate is not disclosed; payout in gift cards for years | Pivoted to a compute marketplace |
-| 5 | Honeyminer (2018) | 3 to 5 | Honeyminer balance, paid in BTC | 8 percent for one GPU, 2.5 percent for two or more (approximate) | The first "download, sign in, earn" miner with no settings | Everything else; the site refuses connections on 7 Oct 2026 | Dead (about 2020 to 2021, approximate) |
-| 6 | Cudo Miner (2017) | 5 to 10 | Cudo balance | 1.5 to 3 percent by tier (approximate) | Profit switching on Windows, macOS, Linux | The pivot to Cudo Compute (cloud GPU); docs host unresolvable on 7 Oct 2026 | Pivoted |
-| 7 | Kryptex | 5 ("Download, Launch, Earn"; first payout 1 to 8 hours) | Kryptex balance; withdraw BTC, USDT, ETH, USDC, LTC, BNB, TRX, Volet, Amazon gift cards; 0.00025 BTC minimum | "A small pool fee", unstated | "153,000 GPU and ASIC miners", "10 million+ downloads"; the pool: BTC 4,945 miners at 6.63 EH/s, XMR 37,576 miners at 1.08 GH/s; PPS+ | A balance, not a wallet | Alive |
-| 8 | unMineable | 5 to 10 | unMineable balance, paid in 80+ assets | 1 percent, 0.75 with a referral code (approximate) | Mine any algorithm, be paid in any coin | A balance; conversion risk; no node | Alive |
-| 9 | Bitcoin Core "generate" (2009 to 2016) | 0 (one setting) | The user's own wallet, in the node | None | Node, wallet and miner in one process, the only time it has shipped at scale | Removed in 0.13 (2016) once GPUs and chips made it pointless | Dead |
-| 10 | Monero GUI mining | 0 after sync (Advanced, Mining, Start mining; thread count; local node required) | The user's wallet | None | A wallet with the daemon's CPU miner, and P2Pool bundled and updated per release (nano sidechain 26 Aug 2023, P2Pool 4.18.1 on 6 Oct 2024); the nearest shipped "node plus wallet plus miner" | The GPU (RandomX is CPU work); no tuning, no alerts; the sync wait | Alive |
-| 11 | Kaspa community miners, the big three | 5 to 15 (a command line, a pool, an address) | The pool's | lolMiner 0.75 percent kHeavyHash, 1.0 Karlsen, 0.7 Ethash, 1.5 Autolykos (v1.96a); BzMiner 1 percent most algorithms, 0.5 ETC, 2 on Pearl and Quantus (v100.45, Windows, Linux, macOS arm64, Docker); GMiner 1 percent kHeavyHash, 2 Ethash and KawPoW, 5 Cortex, "charged continuously"; T-Rex 1 percent (2 on Octopus and Autolykos), 730 open issues, no release date shown; NBMiner 1 to 3 percent, last release 42.3 on 2 Sep 2022 | The per-GPU accepted, rejected, invalid and fault line; kernel speed | No node, no wallet, no tuning against a goal, no signed updates; two of the big three stopped in 2022 (approximate for T-Rex) | lolMiner, BzMiner, GMiner alive; T-Rex and NBMiner stale |
-
-Nobody in the table ships a miner that is also a verifying node and a wallet with a GPU worker: Bitcoin Core did it for CPUs in 2009 and removed it in 2016; the Monero GUI does it for CPUs with P2Pool bundled; every GPU miner is a kernel plus a pool address, and every "one click" app is a custodial balance.
-
-### 6.2 Ember against the field
-
-Ember's state is from `polish.md` 3.1 and 3.10: a Rust engine runs `igneumd` and one GPU worker per card, serves a tokenised local dashboard, Welcome, Cards, Address, the one-time key sheet, Start mining; Ember Tune measured 37 to 41 percent more hashes per watt on PC 1; signed, hash-checked, rolled-back updates with a safe-moment rule; no dev fee in pool mode, a 1-in-100 template solo; pool mode is design only (pool.md section 7).
-
-| Axis | The field's best | Ember today | Past or behind |
-|---|---|---|---|
-| Node, wallet and miner in one process, GPU | Nobody (Monero GUI for CPU) | Yes: `igneumd`, the worker, the key and the address in one app | Past |
-| Custody | Direct-to-wallet only at P2Pool and HiveOS; every one-click app holds a balance | The coinbase pays the user's own address; the vote key never leaves the machine | Past |
-| Governance | Nobody | The vote key in every header the card hashes | Past |
-| Updates | Unsigned zips (the kernel miners); NiceHash and HiveOS auto-update inside an account | Ed25519-signed manifests, sha256, staged, rolled back after 90 unhealthy seconds, a safe-moment rule | Past |
-| Tuning | HiveOS per-GPU clocks by hand; Nanominer's watchdog | A goal with the money consequence on screen, hill climb, 37 to 41 percent per watt | Past |
-| Fee | 0.5 to 3 percent dev fees; 1 to 8 percent custodial takes | 1 percent template dev fee solo, 0 in pool mode | Past |
-| Install to first share | NiceHash, Honeyminer, Kryptex: about 5 minutes with one interstitial | Windows: SmartScreen interstitial, per-user install, a firewall UAC prompt 20 to 50 s in; Mac: an ad hoc signature that macOS 15 refuses without Privacy and Security, Open Anyway (Q3, Q14, Q15); the Windows installer pipeline is dead on GitHub billing (Q80) | Behind: three prompts against one, and no Windows build until Q80 |
-| Earnings | NiceHash's fiat per day on the main screen | "£0.00 earned" first; mined IGN never shown (Q18) | Behind, 2 hours |
-| History and alerts | HiveOS hours of charts and Telegram alerts | A 10-minute strip; no outbound alert (Q16) | Behind, 4 hours plus an alert hook |
-| Per-card faults | lolMiner's status line | "N blocks" per card; `mismatched=` and `faults=` never reach the row (Q13) | Behind, 2 hours |
-| Remote view | HiveOS, NiceHash Rig Manager | None for the owner (the console is the operator's) | Behind; not ranked here |
-| Pool mode | Every miner | Design only | Behind; the share sidechain of 5.3 is the finish |
-| Finality on the surface | Nobody | Nothing during a pause (Q2) | Behind, 3 hours, and nobody else has the concept |
-
-The honest line: Ember is the first app to ship the thing the table says nobody shipped (node, wallet, GPU miner, own key, signed updates, no custody), and it loses to a 2018 Honeyminer on the sixty seconds between download and first share. The first-run fixes are one Developer ID and one Authenticode certificate (Q3, a the founder decision) plus the Q80 installer builder; the rest of the behind rows are 11 hours.
-
-## 7. Verdict table
-
-| Group | Unfinished item | Who could finish it | Igneum has it | Hours on Igneum | Recommend |
-|---|---|---|---|---|---|
-| A | Energy that produces proofs of real state, paid from issuance (Aleo's 2019 promise) | A chain with a prover network and no validator set | Yes once the proof is verified in consensus (`proving_consensus_verify_daa`, 0.3.16, off by default) | 0 beyond the activation decision | Already done; activate |
-| A | Pay per verified unit of proving at a market price (PoVW) | Boundless, Succinct, Igneum | Yes (pgas metering, 90/10 external jobs) | 0 | Already done |
-| A | Useful work verified cheaper than done AND sampleable AND wanted | Nobody in 13 years | No, and the bound says why (0.08 percent useful at 100 GH/s) | 0.5 (the ledger row beside F13, new-pow.md rank 8) | Skip |
-| A | Stored data as the work (Filecoin, Chia) without filler | Lane 8's scheme C | Partly (class v5 candidate, judged) | per new-pow.md rank 1 (16) | Not this lane's call; already ranked |
-| B | A tweak that lands before the chip (RandomX v2 merged, unscheduled; ProgPoW dead on governance) | A chain whose parameters move without a vote | Yes (era draws every 6 months, families by height, the class ladder) | 0 | Already done |
-| B | The random item derivation and external cryptanalysis of the mixer | Igneum | No | per asic-history 4.3 additions 2 and 3; the spend (USD 80,000 to 160,000) is a decision owed | Finish, through the existing ranking |
-| B | The FPGA overlay measurement and the epoch-length reserve | Igneum | Partly (reserve designed on `ca2-epoch`) | per asic-history addition 5 | Finish, through the existing ranking |
-| B | Tensor-core PoW measured against a chip | Igneum did it (scheme B) | Yes, retired to reserve R8 with the two-output correction | 1 (new-pow.md rank 5) | Already done |
-| C | A merged-mining BIP that replaces the 2011 spec; any child chain with a say in its parent | Namecoin, RSK | n/a (ruled out) | 0 | Skip |
-| C | An algo slot or an Igneum-side auxiliary chain | Nobody should | No | 0 | Skip, with the reasons in 3.2 |
-| D | Finality on PoW without a coin-bought validator set | Zcash Crosslink (not shipped), Kaspa DAGKnight (PRs) | Yes: miner-only 30-day weight, 20 days at 100 percent hashrate for 2/3 | 0 beyond Igneum's own open rows (LEAVE item, 10 percent rule, weight-gated deep fork choice, vote-or-burn: 0.3.16 and horizon 1) | Already done; finish the own rows |
-| D | A subjective reweighting rule that survives its own chain (Horizen, MESS) | Nobody | Removed on purpose (no hidden-block n^2 penalty) | 0 | Skip |
-| E | A pool with no operator on a DAG chain | Nobody has; Monero P2Pool is the finished form on a chain | Partly (vote key in the header, the 20 percent paid by sortition, coinbase extra data) | about 40 (section 5.3) | Finish |
-| E | Miner-built templates (DATUM, SV2 JD: one block in 52,297) | Igneum's mode C | Designed, not built | 6 | Finish after the sidechain |
-| E | Encrypted member transport | SV2 Noise | No (plain TCP, Q67) | 8 | Finish |
-| E | A pool-as-contract with sampled share verification (SmartPool) | Nobody since 2017 | No | 0 | Skip (1.35 ms per share makes it worse than it was for Ethereum) |
-| F | Node, wallet and GPU miner in one app, own key, signed updates | Nobody; Ember | Yes | 0 | Already done |
-| F | Sixty seconds from download to first share | Honeyminer did it in 2018 | No (three prompts, no Windows build) | 6 plus certificates (Q3); 0 or 4 (Q80) | Finish; the certificates are the founder's |
-| F | Earnings in IGN, per-card faults, an hour of history, a finality notice | HiveOS, lolMiner | No (Q18, Q13, Q16, Q2) | 11 | Finish |
-| F | Payout in something a gamer can spend (Salad's gift cards) | Salad | No, and the chain says "nothing is bought or sold on devnet" | 0 | Skip until there is a market |
-
-## 8. Three headline findings for the coordinator
-
-1. Every proof-of-useful-work programme that passed both tests (cheap verify, sampleable) did so by making the work useless, and the one exception, Filecoin, ran at 29 to 36 percent utilisation and lost 55 percent of its raw byte power in the year to 14 Sep 2026; Igneum's split already finishes Aleo's 2019 promise, and the only unfinished line (a majority prover pool earning 11,636 IGN an hour at 51 percent) closes when `proving_consensus_verify_daa` is switched on.
-
-2. No pool without an operator exists on any chain but Monero (P2Pool at 7.7 percent, 3,520 miners, 0 percent fee; Ocean at 2.05 percent of blocks with 85 percent of them from DATUM; Stratum V2 job declaration at 1 block in 52,297), and Igneum already holds the three objects that make one cheap (the vote key in the header, the 20 percent paid by sortition, the coinbase extra data), so a share sidechain is about 40 agent hours and would be the first on a DAG chain.
-
-3. Every finality on a PoW chain that held in practice is a second validator set bought with coins (Decred 64 percent of supply staked, eCash 350 B XEC, Dash 1,000 DASH per masternode), and every rule that only reweights work has been switched off by its own chain (MESS twice, Horizen winding down, Kaspa's 12-hour depth subjective); Igneum's work-weighted set needs 20 days of 100 percent hashrate to reach 2/3, so no renter buys it in a day, and the unfinished items are Igneum's own (the LEAVE item and the 10 percent rule), not the industry's.
-
-## 9. Sources
-
-All accessed 7 October 2026 unless stated. Lane notes with the full per-item citations sit in the scratchpad under `mission-unfinished/` (A-notes, B-notes, CD-notes, E-notes, F-notes).
-
-Group A
-- https://en.wikipedia.org/wiki/Primecoin ; https://www.johndcook.com/blog/2026/01/10/primecoin-primality-test/ ; https://github.com/primecoin/primecoin/wiki/Primecoin-Reaches-13-primes-Milestone ; https://primecoin.io/ ; https://chainz.cryptoid.info/xpm/ ; https://www.coingecko.com/en/coins/primecoin ; https://bitinfocharts.com/primecoin/
-- https://github.com/gridcoin-community/Gridcoin-Wiki/wiki/zArchive~Proof-of-Research ; https://gridcoin.us/assets/docs/scraper-summary.pdf ; https://gridcoin.us/guides/whitelist.htm ; https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/5.5.0.0
-- https://curecoin.net/knowledge-base/folding-for-curecoin/how-do-i-start-folding-for-curecoin-quick/ ; https://curecoin.net/news/curecoin-team-reaches-1-trillion-ppd-on-foldinghome/ ; https://curecoin.net/curecoin-roadmap/ ; https://tokenmarket.net/blockchain/counterparty/assets/foldingcoin/
-- https://eprint.iacr.org/2020/190 ; https://aleo.org/post/aleo-mainnet-faq/ ; https://docs.aleo.org/participate/run-a-node/prover ; https://github.com/ProvableHQ/ARCs/discussions/97 ; https://provable.com/blog/introducing-arc-0046 ; https://aleo.org/post/announcing-snarkos-v4.0.0/ ; https://messari.io/report/state-of-aleo-q2-2025 (search excerpt; direct fetch 429) ; https://followin.io/en/feed/11596817
-- https://eprint.iacr.org/2021/1379 ; https://eprint.iacr.org/2025/2091 ; https://eprint.iacr.org/2017/203 ; https://eprint.iacr.org/2018/559
-- https://filecoin.io/blog/posts/a-guide-to-filecoin-storage-mining ; https://lotus.filecoin.io/storage-providers/get-started/hardware-requirements/ ; https://lotus.filecoin.io/storage-providers/operate/benchmarks/ ; https://filecointldr.io/article/key-trends-and-takeaways-from-filecoin-q1-2025 ; https://www.kucoin.com/news/flash/filecoin-q3-2025-report-capacity-drops-10-network-utilization-rises-to-36 ; https://thetradersspread.com/crypto/filecoin-rose-24-percent-ahead-of-75-percent-supply-cut ; https://github.com/filecoin-project/FIPs/discussions/1009 ; https://filecoin.io/blog/posts/introducing-proof-of-data-possession-pdp-verifiable-hot-storage-on-filecoin/
-- https://www.chia.net/2022/03/19/chia-mainnet-year-one/ ; https://www.chia.net/2021/05/24/chia-and-ssd-endurance/ ; https://www.chia.net/2021/08/03/chia-and-ssd-endurance-big-progress-less-waste/ ; https://www.chia.net/2023/01/21/plotting-chias-future/ ; https://www.chia.net/2026/02/27/changes-coming-to-3-0/ ; https://lowendbox.com/blog/the-crypto-that-ate-all-the-hard-drives-whatever-happened-to-chia/ ; https://xch.today/2026/02/09/top-10-chia-predictions-for-2026/ ; https://en.wikipedia.org/wiki/Chia_Network
-- https://ownyourmind.ai/projects/flux/ ; https://runonflux.com/ ; https://messari.io/report/state-of-akash-q1-2026-final (search excerpt) ; https://akash.network/blog/akash-network-q1-2026-report/
-- https://github.com/dynexcoin/Dynex ; https://www.coingecko.com/en/coins/dynex ; https://www.coinlore.com/coin/dynex/news
-- https://qubic.org/blog-detail/qubic-s-useful-proof-of-work-the-future-of-ai-compute ; https://qubic.org/blog-detail/the-next-evolution-of-useful-proof-of-work-(upow) ; https://www.halborn.com/blog/post/explained-the-monero-51-percent-attack-august-2025 ; https://www.theblock.co/post/366535/monero-faces-chain-reorganization-fears-after-qubic-says-it-controls-51-of-hashrate ; https://cointelegraph.com/news/monero-qubic-selfish-mining-51-percent-attack ; https://www.bitget.com/news/detail/12560604967511 ; https://wublock.substack.com/p/monero-hit-by-a-51-hashrate-attack
-- https://arxiv.org/html/2507.02951v1 ; https://www.theblock.co/news/web3/2026-03-05-dcg-yuma-bittensor-report-392351 ; https://abittensorjourney.com/p/navigating-bittensor-september-2026 ; https://beincrypto.com/bittensor-subnets-reach-ath-in-may/
-- https://arxiv.org/abs/2502.19405 ; https://www.gensyn.ai/research/verde-verification-system-in-production ; https://arxiv.org/abs/2405.00295 ; https://blockeden.xyz/blog/2026/04/01/ambient-ai-l1-proof-of-logits-pow-blockchain-decentralized-inference/ ; https://inferencelabs.com/ ; https://arxiv.org/abs/2603.19025 ; https://arxiv.org/pdf/2512.20176 ; https://blockeden.xyz/blog/2026/01/14/boundless-risc-zero-decentralized-proof-market-zk/ ; https://blog.succinct.xyz/succinct-2025-recap/
-- https://arxiv.org/abs/2209.03865 ; https://eprint.iacr.org/2025/1814 ; https://arxiv.org/abs/2606.06700 ; https://arxiv.org/abs/2606.04819 ; https://arxiv.org/abs/2510.09729
-
-Group B
-- https://eips.ethereum.org/EIPS/eip-969 ; https://eips.ethereum.org/EIPS/eip-1057 ; https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining-algorithms/ethash/ ; https://github.com/eth-classic/etchash ; https://2miners.com/blog/how-to-mine-ethereum-and-ethereum-classic-on-4gb-gpus/
-- https://leastauthority.com/static/publications/LeastAuthority-ProgPow-Algorithm-Final-Audit-Report.pdf ; https://github.com/ethcatherders/progpow-audit (PDF text not extractable) ; https://github.com/kik/progpow-exploit ; https://github.com/ethereum/EIPs/issues/2640 ; https://hudsonjameson.com/posts/2020-03-02-progpow-the-ethereum-community-speaks/ ; https://cointelegraph.com/news/the-history-of-the-bitter-debate-over-ethereums-progpow ; https://www.theblock.co/linked/57061/ethereum-community-members-submit-dissenting-progpow-petition ; https://www.coindesk.com/tech/2020/03/05/ethereums-progpow-debate-is-about-much-more-than-mining ; https://www.coindesk.com/tech/2020/03/06/ethereums-progpow-call-features-frustration-but-little-progress ; https://github.com/Souptacular/linzhi ; https://linzhi.io/docs/LWP15-Posts-Against-ProgPoW-05092019.pdf ; https://cryptoslate.com/progpow-authors-steps-down-core-scientific-ethereum/ ; https://ecips.ethereumclassic.org/ECIPs/ecip-1070 ; https://2miners.com/blog/kawpow-new-ravencoin-mining-algorithm/ ; https://en.wikipedia.org/wiki/Firo_(cryptocurrency) ; https://www.qu.ai/blog/quai-network-mainnet-launching-january-29th
-- https://github.com/tevador/RandomX ; https://github.com/tevador/RandomX/pull/265 ; https://github.com/tevador/RandomX/pull/317 ; https://github.com/monero-project/monero/pull/10038 ; https://github.com/monero-project/research-lab/issues/136 ; https://xmrig.com/docs/algorithms ; https://github.com/xmrig/xmrig-cuda/issues/67 ; https://www.asicminervalue.com/miners/bitmain/antminer-x5 ; https://www.asicminervalue.com/miners/bitmain/antminer-x9 ; https://millionminer.com/news/monero-mining-guide-2026-antminer-x5-x9-pinecone-r1x-randomx (reseller, unverified) ; https://www.coindesk.com/business/2025/08/12/monero-s-51-attack-problem-inside-qubic-s-controversial-network-takeover
-- https://arxiv.org/abs/1911.05193 ; https://kaspa-lens.com/kaspa-wiki/kaspa-technology-and-features/kheavyhash-proof-of-work-algorithm/ ; https://kaspa-lens.com/kaspa-wiki/getting-started-with-kaspa/mining-kaspa/ ; https://www.asicminervalue.com/miners/iceriver/ks0 ; https://github.com/karlsen-network/karlsend ; https://github.com/spectre-project/rusty-spectre ; https://github.com/Pyrinpyi/pyipad
-- https://docs.ergoplatform.com/mining/autolykos/ ; https://www.ergoforum.org/t/autolykos-v-2-details/480 ; https://github.com/ergoplatform/eips/blob/master/eip-0027.md ; https://eprint.iacr.org/2020/044 ; https://x.com/RedPandaMining/status/1697408861014196711 ; https://cryptoage.com/en/3019-osprey-e300-fpga-miner-for-kaspa-cryptocurrency.html
-- https://github.com/mimblewimble/grin/blob/master/doc/pow/pow.md ; https://docs.grin.mw/about-grin/proof-of-work/ ; https://forum.grin.mw/t/grin-v5-0-0-network-upgrade-hard-fork-4-january-2021/7895 ; https://2miners.com/blog/grin-version-4-hard-fork-what-will-change-and-how-to-get-ready/ ; https://forum.grin.mw/t/grn1-cancellation-announcement/5624 ; https://voskcointalk.com/t/new-grin-miner-coming-out/6373 ; https://www.asicminervalue.com/miners/innosilicon/g32-500 ; https://www.asicminervalue.com/miners/ipollo/g1 ; https://2cryptocalc.com/cuckatoo32-algorithm ; https://github.com/tromp/cuckoo
-- https://coinbureau.com/mining/battle-against-asics-antminer-z9-zcash ; https://github.com/ZcashFoundation/zfnd/blob/master/_posts/blog/2018-05-08-statement-on-asics.md ; https://raw.githubusercontent.com/ZcashFoundation/zfnd/master/_posts/blog/2018-06-07-asic-equihash-study.md ; https://raw.githubusercontent.com/ZcashFoundation/zfnd/master/_posts/blog/2018-07-03-governance-results.md ; https://forum.zcashcommunity.com/t/will-zcash-fork-to-be-asic-resistant/30829 ; https://crypto.news/zcash-doubles-efforts-on-investigating-asic-resistance/ ; https://github.com/BeamMW/beam/wiki/BEAM-Mining ; https://www.minerupdate.com/news/trending-news/beam-hard-fork-executes-to-deter-asic-miners ; https://u.today/privacy-coin-beam-introduces-new-proof-of-work-algorithm ; https://cryptoage.com/en/2095-beam-cryptocurrency-hard-fork-new-beamhash3-mining-algorithm.html ; https://en.wikipedia.org/wiki/Bitcoin_Gold ; https://www.tweaktown.com/news/62048/bitcoin-gold-hit-51-attack-up-18-million-gone/index.html
-- https://github.com/Conflux-Chain/CIPs/blob/master/CIPs/cip-102.md ; https://forum.conflux.fun/t/cip-102-change-pow-mining-algorithm/16068 ; https://f2pool.io/mining/guides/how-to-mine-conflux/ ; https://www.asicminervalue.com/coins/conflux-cfx
-- https://docs.alephium.org/frequently-asked-questions/ ; https://docs.alephium.org/mining/ ; https://www.asicminervalue.com/miners/goldshell/al-box ; https://www.asicminervalue.com/miners/bitmain/antminer-al1
-- https://eprint.iacr.org/2025/685 ; https://ethresear.ch/search.json?q=tensor%20core%20proof%20of%20work
-- https://arxiv.org/abs/1905.08792 ; https://medium.com/@dave_46855/altered-silicon-x16r-mining-on-the-xilinx-fpga-dbc290c56909 (search excerpt; fetch 403) ; https://forum.zcashcommunity.com/t/equihash-mining-in-fpga/31054 ; https://cryptoage.com/en/3195-all-hashaltcoin-fpgas-get-support-for-the-kheavyhash-algorithm.html
-
-Group C
-- https://github.com/namecoin/wiki/blob/master/Merged-Mining.mediawiki ; https://www.namecoin.org/docs/faq/ ; https://en.bitcoin.it/wiki/Merged_mining_specification ; https://metrics.namecoin.org/namecoin/period-timestamps-14-days/pool/charts/latest.txt ; https://forum.namecoin.org/viewtopic.php?f=6&t=2421 (search excerpt; fetch 500) ; https://cryptorank.io/news/feed/7620f-while-bitcoins-hashrate-remains-sky-high-merge-mined-crypto-asset-networks-benefit (search excerpt; fetch 403) ; https://eprint.iacr.org/2017/791
-- https://www.coindesk.com/markets/2014/08/04/dogecoin-to-allow-litecoin-merge-mining-in-network-security-bid ; https://www.binance.com/en/research/analysis/merged-mining (search excerpt) ; https://www.bitdeer.com/learn/dogecoin-the-logic-of-auxpow-and-stable-profits ; https://www.mexc.com/learn/article/dogecoin-mining-2025-how-doge-is-mined-merge-mining-and-miner-economics/1
-- https://myriadteam.github.io/ ; https://www.pxdojo.net/2017/04/myriadcoin-untold-story-of-invincible.html ; https://thenextweb.com/news/hackers-verge-blockchain-steal-1-7m ; https://bitcoinist.com/verge-xvg-hacked-35-million-xvg-tokens-reportedly-generated-hacker/ ; https://en.wikipedia.org/wiki/Verge_(cryptocurrency) ; https://cryptonary.com/verge-suffers-reorg-attack-200-days-of-transactions-wiped-away/ (headline only)
-- https://solofury.com/blog/digibyte-dgb-explained-for-miners/ ; https://www.gemini.com/cryptopedia/digibyte-mining-digibyte-coin-dgb-coin
-- https://cryptobriefing.com/elastos-bitmain-merged-mining/ ; https://blog.elastos.net/news/ela-queen-of-bitcoin/ ; https://rootstock.io/blog/merged-mining-insights-report-q1-2024/ ; https://rootstock.io/blog/rootstock-x-bitcoin-merged-mining-insights-report-q4-2024/ ; https://rootstock.io/blog/the-security-architecture-of-rootstock-and-the-principle-of-defense/ ; https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP110.md
-
-Group D
-- https://docs.decred.org/proof-of-stake/overview/ ; https://docs.decred.org/research/hybrid-design/ ; https://github.com/decred/dcps/blob/master/dcp-0011/dcp-0011.mediawiki ; https://github.com/decred/dcps/blob/master/dcp-0012/dcp-0012.mediawiki ; https://xaur.github.io/decred-news/journal/201912 ; https://xaur.github.io/decred-news/journal/202012 ; https://xaur.github.io/decred-news/journal/202112 ; https://xaur.github.io/decred-news/journal/202212
-- https://www.coindesk.com/tech/2018/10/10/a-solution-to-cryptos-51-attack-fine-miners-before-it-happens ; https://blog.horizen.io/horizens-51-attack-solution/ (search excerpt; fetch 403) ; https://www.horizen.io/ ; https://docs.horizen.io/
-- https://raw.githubusercontent.com/kaspanet/rusty-kaspa/master/consensus/core/src/config/constants.rs ; https://raw.githubusercontent.com/kaspanet/rusty-kaspa/master/consensus/core/src/config/bps.rs ; https://raw.githubusercontent.com/kaspanet/rusty-kaspa/master/consensus/core/src/config/params.rs ; https://eprint.iacr.org/2022/1494 ; https://github.com/kaspanet/rusty-kaspa/pull/1104 (search excerpt)
-- https://arxiv.org/abs/2006.01072 ; https://www.usenix.org/conference/atc20/presentation/li-chenxing ; https://doc.confluxnetwork.org/docs/general/hardforks/v2.0 ; https://doc.confluxnetwork.org/docs/general/conflux-basics/consensus-mechanisms/proof-of-stake/pos_overview
-- https://arxiv.org/abs/1710.09437 ; https://eips.ethereum.org/EIPS/eip-1011 ; https://eth2book.info/latest/part2/consensus/overview/ ; https://hackmd.io/@tvanepps/Beacon-Book ; https://ethresear.ch/t/convenience-link-to-casper-sharding-chain-v2-1-spec/2332 ; https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2041.md
-- https://e.cash/blog/ecash-day-2024-celebrating-three-years-of-ecash-xec ; https://e.cash/blog/eCash-day-2026 ; https://e.cash/blog/preconsensus-launch ; https://e.cash/blog/staking-guide ; https://e.cash/blog/avalanche-faq
-- https://meowsbits.github.io/51-percent-docs/ ; https://ecips.ethereumclassic.org/ECIPs/ecip-1100 ; https://ecips.ethereumclassic.org/ECIPs/ecip-1110 ; https://www.kucoin.com/news/flash/etc-miners-revert-to-argos-after-core-geth-v1-13-0-controversy ; https://github.com/ethereumclassic/core-geth/issues/44 ; https://github.com/ethereumclassic/core-geth/pull/53
-- https://electric-coin-company.github.io/tfl-book/design/crosslink.html ; https://shieldedlabs.net/crosslink/ ; https://zechub.substack.com/p/arborist-call-88-r-and-d-updates
-- https://eprint.iacr.org/2020/1101 ; https://www.nervos.org/mining (search excerpt; fetch 429)
-- https://docs.dash.org/projects/core/en/21.0.0/docs/guide/dash-features-chainlocks.html ; https://syscoincore.org/en/releases/4.2.0/ ; https://komodoplatform.com/en/docs/start-here/core-technology-discussions/delayed-proof-of-work/
-
-Group E
-- https://en.bitcoin.it/wiki/P2Pool ; https://github.com/p2pool/p2pool ; https://github.com/p2pool/p2pool/commits/master ; https://github.com/treib-holdings/p2pool.org/issues/1 ; https://github.com/frstrtr/c2pool
-- https://github.com/SChernykh/p2pool ; https://github.com/SChernykh/p2pool/blob/master/README.md ; https://github.com/SChernykh/p2pool/releases ; https://monero.observer/schernykh-releases-p2pool-v4.7-support-nano-sidechain/ ; https://www.getmonero.org/resources/moneropedia/p2pool.html ; https://data.miningpoolstats.stream/data/monero.js?t=1791359405 ; https://xmrchain.net/api/networkinfo ; https://supportxmr.com/api/pool/stats ; https://api.hashvault.pro/v3/monero/pool/stats ; https://p2pool.observer/ (502 on every try)
-- https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki ; https://github.com/stratum-mining/sv2-spec ; https://github.com/stratum-mining/stratum/releases ; https://stratumprotocol.org/ ; https://braiins.com/stratum-v2 ; https://braiins.com/pool ; https://d-central.tech/data/stratum-protocol-matrix/ ; https://d-central.tech/bitcoin-mining-pool-comparison-2026/ ; https://www.spark.money/research/bitcoin-stratum-v2-mining-decentralization ; https://cryptobriefing.com/demand-pool-first-stratum-v2-block/ ; https://www.tftc.io/stratum-v2-job-declaration-first-block-dmnd-gomining/ ; https://www.dmnd.work/ ; https://mempool.space/api/v1/mining/pools/1w ; https://mempool.space/api/v1/mining/pools/1y
-- https://ocean.xyz/docs/tides ; https://ocean.xyz/docs/datum ; https://ocean.xyz/dashboard ; https://bitcoinmagazine.com/technical/an-ocean-launch-post-mortem ; https://crypto.news/bitcoin-mining-divide-pushes-luke-dashjr-out-of-ocean/
-- https://data.miningpoolstats.stream/data/kaspa.js?t=1791359405 ; https://2miners.com/kas-mining-pool ; https://woolypooly.com/en/coin/kas ; https://f2pool.io/mining/guides/how-to-mine-kaspa/ ; https://kaspa.herominers.com/?lang=en ; https://solopool.org/
-- https://eprint.iacr.org/2017/019 ; https://blog.acolyer.org/2017/09/07/smartpool-practical-decentralized-mining/ ; https://eprint.iacr.org/2020/044
-- https://miningpoolstats.net/coins/ravencoin/ ; https://2miners.com/erg-mining-pool
-- https://github.com/dogestreet/proxypool ; https://arxiv.org/pdf/1112.4980 ; https://arxiv.org/pdf/1402.1718 ; https://arxiv.org/abs/1411.7099 ; https://eprint.iacr.org/2015/155 ; https://en.bitcoin.it/wiki/Eligius
-
-Group F
-- https://en.wikipedia.org/wiki/NiceHash ; https://www.nicehash.com/support/general-help/nicehash-service/fees-and-pricing (deposit fees only; the seller and buyer fee pages returned 404)
-- https://hiveon.com/pricing/
-- https://www.awesomeminer.com/ ; https://minerstat.com/ (no pricing on either page fetched)
-- https://salad.com/ ; https://support.salad.com/article/213-how-much-can-i-earn-with-salad (no take rate published)
-- https://www.kryptex.com/ ; https://pool.kryptex.com/
-- https://unmineable.com/
-- https://www.getmonero.org/resources/user-guides/solo_mine_GUI.html ; https://github.com/monero-project/monero-gui/releases
-- https://github.com/Lolliedieb/lolMiner-releases ; https://github.com/bzminer/bzminer ; https://github.com/develsoftware/GMinerRelease ; https://github.com/trexminer/T-Rex ; https://github.com/NebuTech/NBMiner
-- Unreachable on 7 Oct 2026: honeyminer.com (connection refused), docs.cudominer.com (no DNS), cudominer.com (429), web.archive.org (blocked for this tool)
-
-Igneum documents cited
-- `CLAUDE.md` (the design paragraph, finality rule v2, the fee lines, the 6 October 2026 rules)
-- `docs/analysis/asic-resistance-history.md` (rows 3, 17 to 25, 30; lessons 5 to 9; sections 4.1 to 4.3)
-- `docs/plans/pool.md` sections 2, 3, 5, 7; `docs/spec/09-pool-protocol.md` sections 9.1 to 9.8
-- Scratch inputs: `mission-inputs/horizon/new-pow.md` sections 3.1, 3.3, 6, 7; `mission-inputs/horizon/frontier.md` sections 0, 3.10, 3.11; `mission-inputs/horizon-2026-10.md` section 1; `mission-inputs/horizon/polish.md` sections 3.1, 3.6, 3.10

docs/analysis/prover-floor.md

@@ -1,6 +1,6 @@
 # The prover floor: why a 12 GB card cannot prove on SP1 6.8.1's GPU server, and the patch
 
-5 October 2026, 22:00 UTC on (the founder: "execute if it will solve the issue"). Branch `prover-floor`
+5 October 2026, 22:00 UTC on (the project lead: "execute if it will solve the issue"). Branch `prover-floor`
 (worktree `igneum-wt-prover-floor`). The measured facts this starts from: `docs/plans/proving-v1.md` and the
 bench-log entry "proving v1" (branch proving-v1): the GPU server holds 13.9 GB for an empty shard, 20.4 GB at the
 adopted v1 shard, 28.3 GB flat from 20 M to 60 M cycles, and no environment knob moved the floor. Every figure

docs/analysis/prover-tiers-real-cards.md

@@ -1,6 +1,6 @@
 # Prover tiers on real cards: the memory matrix of the patched SP1 GPU server, measured on rented GPUs
 
-6 October 2026, from 11:50 UTC (the founder: "rent all you need, absolute overkill", "get as many GPUs as you need to properly
+6 October 2026, from 11:50 UTC (the project lead: "rent all you need, absolute overkill", "get as many GPUs as you need to properly
 test everything swiftly"). Branch `gpu-fleet`, tools in `tools/fleet/`, raw logs per instance under
 `~/Desktop/fleet/<instance>/` (the sampler csv, every point's host log and results JSON, the miner log). This file
 replaces the 5090-allocation rows of `docs/analysis/prover-floor.md` with the cards themselves. A row that is not here

docs/analysis/proving-methods.md

@@ -1,11 +1,11 @@
 # Proving methods: why the prover needs 14 GB, what else exists, and how a 12 GB card gets to prove
 
-5 October 2026, from the founder at 22:05 UTC: "if this doesn't enable 12 GB cards, then do a full deep research task on proving
+5 October 2026, from the project lead at 22:05 UTC: "if this doesn't enable 12 GB cards, then do a full deep research task on proving
 and see if there are different methods." "This" is the prover-floor agent's patch of SP1's GPU server (branch
 `prover-floor`), running tonight. This document is research and reading, not measurement: every number of ours is from
 `docs/bench-log.md` with its entry named; every claim about another system cites its repository file, its documentation
 page or its paper, or is labelled approximate. Status words follow `docs/spec/00-overview.md` 0.2. Day estimates follow
-The founder's rule of 3 October 2026: hours of agent time, never weeks.
+the project lead's rule of 3 October 2026: hours of agent time, never weeks.
 
 The facts this starts from (bench-log, "proving v1", 5 October 2026; `docs/plans/proving-v1.md`; `docs/analysis/amd-proving.md`):
 
@@ -351,7 +351,7 @@ the tier it moves, in one sentence, the day it is taken.
 
 | Consequence | Action | Owner |
 |---|---|---|
-| The gate card has never run a prover here | get a 4070 or 3060 into the measurement loop this week; until then every 12 GB figure stays approximate | coordinator; the founder for the card |
+| The gate card has never run a prover here | get a 4070 or 3060 into the measurement loop this week; until then every 12 GB figure stays approximate | coordinator; the project lead for the card |
 | Route A's gate | the prover-floor agent's rows (asked for by message tonight); if under 11 GB, `provedefault.rs` gains the 12 GB prove-only and 16 GB mine-and-prove tiers and the rig installer one server per card | prover-floor agent, then the proving engineer |
 | Route D's measurement | RISC Zero 3.0.6 at po2 19 and 20 on PC 2 (CUDA) and on this Mac (Metal), the same shard statement run natively: memory, time per segment, lift and join, receipt size | prover-floor agent (PC 2); a Mac measure job for Metal |
 | The two-family node items (record version selects the verifier, fresh chain at a version change, one family per block) | spec 7.8 gains the three rules when route D starts; nothing changes before | execution engineer |

docs/analysis/scratch-soundness.md

@@ -402,7 +402,7 @@ prove nothing. The static check is the guard, as it is for the dataset mask.
 4. The lever that moves the named chip is the M16 mixer multiplier: x2 to 1.2x, x4 to 0.6x against the measured
    5090 rate, at 0.8 to 4.8 ms of verification per warp against the 10 ms gate. Decision 2 should price that
    against the gate on the 2019-class core (O-1.14) rather than layer 3.
-5. If the founder keeps layer 3 for a reason outside this analysis: ship the host contract in the pack, add the four
+5. If the project lead keeps layer 3 for a reason outside this analysis: ship the host contract in the pack, add the four
    vector items of section 6 (consecutive units with a forced collision, the wrap launch, the warp-count-independent
    fingerprint, the contract text), and run the CUDA and OpenCL twins of section 7.2 on the PCs before the class
    becomes a genesis rule.

docs/analysis/sram-mirror.md

@@ -229,7 +229,7 @@ Option E is the only one that makes the mirror a multi-die part and it costs eve
 genesis (at the headline density; the lower-bound density would ask for 4 GiB and 3.2 s), which fails the spirit of
 the 10 ms verify gate (the fill is once a day, but a light node joining pays it on every day it syncs across).
 
-Decision for the founder, at gate 1: A, B, C, D or E above, together with M16's mixer multiplier. Nothing here changes a
+Decision for the project lead, at gate 1: A, B, C, D or E above, together with M16's mixer multiplier. Nothing here changes a
 vector today: the cache size is a prototype value of spec 1.16 and the growth rule would be a new sentence in 1.13.3.
 
 ## 8. Why the latency bound is the property to lean on (citations behind the plan's rule)

docs/bench-log.md

@@ -250,7 +250,7 @@ Attack, before and after (ignored test `measure_m15_attack_before_and_after`, re
 - Before (the pre-fix order, replayed by calling the engine with the header's own unvalidated day seed): 50 cold 256 MiB builds, 10,595 ms, and the honest day's entry is evicted (`KEEP` was 3).
 - After (the new order): 0 builds, all 50 rejected (`TimeTooOld` or `UnexpectedHeaderDaaScore`) in 14 ms total. The live day stays resident.
 Tests: kaspa-pow `--features igneum-pow` 8 pass (engine smoke, `one_build_per_seed_pair_under_contention`, `live_days_survive_off_day_builds`, `build_queue_is_bounded`, index and live-day helpers, shared-engine, stub); kaspa-consensus header_processor `cheap_checks_run_before_the_pow_engine` pass; kaspa-p2p-flows `pow_guard` 2 pass; the full kaspa-consensus release suite otherwise unchanged.
-M16 Metal note (R3.5, cheap reconfirmation only): the Mac `--inline-dataset` shortcut at the 256 MiB cache, 256 MiB dataset, under the same heavy load, ran honest 91.7 Mhash/s against inline 5.29 Mhash/s (inline about 17x slower); this is noisier and slower than the idle-machine figures already in `proto-metal/MEMHARD.md` (10x slower at a 256 MiB dataset, 4.8x at 1 GiB), because the inline kernel is compute-bound and the machine was loaded. The 64 MiB on-die-SRAM emulation M16 wants (inline kernel with a 64 MiB cache, `cacheLog2Words = 24` in `proto-metal/main.swift`) is the RTX 5090 run reserved for the founder's PC, as R3.5 states; it is not done here and the Mac number above does not price a die.
+M16 Metal note (R3.5, cheap reconfirmation only): the Mac `--inline-dataset` shortcut at the 256 MiB cache, 256 MiB dataset, under the same heavy load, ran honest 91.7 Mhash/s against inline 5.29 Mhash/s (inline about 17x slower); this is noisier and slower than the idle-machine figures already in `proto-metal/MEMHARD.md` (10x slower at a 256 MiB dataset, 4.8x at 1 GiB), because the inline kernel is compute-bound and the machine was loaded. The 64 MiB on-die-SRAM emulation M16 wants (inline kernel with a 64 MiB cache, `cacheLog2Words = 24` in `proto-metal/main.swift`) is the RTX 5090 run reserved for the project lead's PC, as R3.5 states; it is not done here and the Mac number above does not price a die.
 Not done: the real-engine daemon RPC run (honest blocks need GPU-mined pow, so the measurement used the equivalent validate path with `skip_proof_of_work`); the 64 MiB-cache inline kernel on the 5090; the chain-derived day seed by DAA score (spec 01 section 1.12, still the timestamp-day devnet rule); the VDF epoch seed and finality.
 
 ## 3 October 2026, difficulty controller: devnet record, simulator, Igneum dual-lane rule, 3-node CPU test network (consensus-engineer)
@@ -418,7 +418,7 @@ Not changed: the pgas table magnitudes (prototype), `B_p` = 30 M (prototype). Op
 
 Machine for the reproduction: Apple M5 Max, 64 GiB, Darwin 25.6.0, load average 2 to 147 (other agents' builds and, during R1, another agent's Metal worker on the same GPU); everything at `nice -n 19`. Binaries: HEAD `proto-metal/main.swift` built with `swiftc -O` into the scratchpad (465,529 bytes, the same size as `proto-metal/igneum-bench`), `vendor/igneum-node-diff/target/release/igneumd` and `igneum-miner` (22:38 and 22:17 BST, the `difficulty` worktree pair; the miner's `Seeder` and worker protocol are the same code as HEAD and as the Windows build 745d41ef). Private networks on 127.0.0.1 ports 27500 to 27562, appdirs under `/tmp/igneum-decay-test`, all stopped afterwards. Full write-up: `docs/analysis/hashrate-decay-2026-10-03.md`; proposed fix: `docs/analysis/hashrate-decay-2026-10-03.patch` (not applied; `git apply --check` passes against `vendor/igneum-node`).
 PC data (`node tools/logs.mjs <run_id> --all`, STATUS lines deduplicated by timestamp, per-interval rates from consecutive cumulative figures): segment 22:57 to 23:04 UTC, nvidia-1: 40 jobs in the first 30 s then exactly 32 per 30 s for 12 intervals at 17.5 to 18.4 MH/s wall while the printed cumulative figure fell 22.18 to 18.13; nvidia-8 (started 4.7 s later) printed a rising 16.80 to 17.71. Segment 22:23 to 22:57 UTC (epoch 2, DAA 8,474 to 10,513): per-identity gap between jobs 0.098 s to 0.330 s per 0.68 to 0.81 s job, inside-jobs rate rising 28.7 to 34.7 MH/s, wall falling 24.6 to 20.6 MH/s, card total 197 to about 165 MH/s; at the 22:57 epoch boundary the gap returned to 2% and the difficulty held (84.5M to 83.0M).
-Code audit: nothing allocated per job survives the job in `proto-cuda/host.cu`, `proto-opencl/host.c` or `proto-metal/main.swift` serve loops (tables in the analysis); the miner's only per-job growth is time in `Seeder::seeds_for` (memo keyed by `(epoch, sink)`, one `getBlock` RPC per block from the sink to the epoch start on every miss, 1,274 to 3,313 calls on the PC). `cudaDeviceSynchronize` at the default schedule spins one thread per worker (the founder's 6.2% per process); the hot-swap working tree sets `cudaDeviceScheduleBlockingSync` and swaps `clFinish` for `clWaitForEvents`.
+Code audit: nothing allocated per job survives the job in `proto-cuda/host.cu`, `proto-opencl/host.c` or `proto-metal/main.swift` serve loops (tables in the analysis); the miner's only per-job growth is time in `Seeder::seeds_for` (memo keyed by `(epoch, sink)`, one `getBlock` RPC per block from the sink to the epoch start on every miss, 1,274 to 3,313 calls on the PC). `cudaDeviceSynchronize` at the default schedule spins one thread per worker (the project lead's 6.2% per process); the hot-swap working tree sets `cudaDeviceScheduleBlockingSync` and swaps `clFinish` for `clWaitForEvents`.
 Metal runs (STATUS every 30 s; "gap" = 1 minus wall over inside, per interval): R1 control, epoch 0, genesis bits 0x1d100000, 308 s (cut by the 22:21:37 UTC SIGTERM of every process of this session): first interval 25.18 MH/s alone on the GPU, then 14.0 to 14.4 MH/s in every interval after another agent's worker joined at 25 s, gap 0 to 2%, worker RSS 56.8 MiB flat. R2 walk reproduction, 900 s: `skip_proof_of_work` node pumped to DAA 4,000 (one-second timestamps, difficulty held at 76.8M), one identity, pumped blocks at 1/s for 300 s, none for 300 s, 1/s for 300 s: inside 27.0 to 27.7 MH/s in all 29 intervals; wall 22.3 to 24.3 (gap 12 to 18%, walk 400 to 700), 25.9 to 27.3 (gap 0 to 4%), 18.0 to 21.0 (gap 25 to 35%, walk 700 to 1,000); miner CPU 0 to 1% in the quiet phase, 11 to 21% in the last. R3 one worker at difficulty 2^25 (Kaspa sampled rule, genesis bits held), 600 s: 30.51 wall / 30.72 inside, 1,091 jobs, 224 blocks, 53 to 56 jobs per 30 s throughout. R4 eight workers at 2^25: 29.38 / 29.45 summed (3.32 to 4.38 each), 1,053 jobs, 242 blocks, 7 jobs per 100 s per identity in every interval, worker CPU 0.0 to 0.6%, RSS 46 to 57 MiB. R5 one worker at 2^31: 37.01 / 37.75, 1,324 jobs, 4 blocks, flat. R6 eight workers at 2^31: 36.67 / 36.75 summed (4.29 to 5.55 each), 1,314 jobs, 5 blocks, flat. (R5 and R6 ran a different epoch-0 program from R3 and R4, 112 loads per hash, hence 37 against 30.5 MH/s.)
 Side findings: the `difficulty` worktree's node panics at `consensus/src/processes/difficulty.rs:431` ("Work should not exceed 2**192") when fed 85 blocks/s with wall-clock timestamps under the Igneum dual rule (a pump artefact, logged for the consensus-engineer); `skip_proof_of_work` nodes still log "PoW rejected ... by igneum-lottery-v1-bound" for every block they accept. Not done: the fix applied and measured on the PC (the acceptance figure is a flat gap at DAA 10,800 with eight identities); the OpenCL event wait checked on the AMD driver; a unit test of `seeds_for` (the client is concrete).
 
@@ -526,7 +526,7 @@ Binaries: `target-integration/release/{igneumd 40,463,680 B, igneum-miner 7,916,
 
 ## 4 October 2026, generator version 2 adopted: exact load count, fresh-source loads, program acceptance; every vector re-cut, three workers re-checked, 20,000-program census, devnet-v4 binaries rebuilt (cryptographer)
 
-Machine: Apple M5 Max, idle at the start (load 3), rustc 1.99.0 (rustup), Swift 5.8.1, builds at nice 10. Decision (the founder, this morning): adopt the census's generator rule before any public vector ships. Rule as implemented (`igneum-pow/src/generator.rs`, `src/accept.rs`, spec 01 sections 1.4.2, 1.4.3 and 1.4.6; mirrored in `proto-metal/main.swift` as `generateProgramV2` and `acceptProgram` because the Metal worker derives its program from the seed itself): G1 exactly 16 load slots, a uniform subset of instructions 1..63 drawn first by partial Fisher-Yates, the other 48 ops from the ten non-load weights (sum 75); G2 a load's source is drawn from the registers other than `dst` written by an earlier instruction and not read by a load since; R (a) no cyclically stale load source, (b) every register has an injecting write, (c) 64 units at base nonces from `SplitMix64(FNV-1a-64("igneum-accept/" || seed words LE))` on the seed-keyed closed-form dataset at 2^28 words with init words = seed words: no constant register bit, no lane-constant load site in any unit, fewer than 164 saturated final values, every output bit within 136 of 1,024, distinct addresses above 245,760 over the 2,048 hashes; a rejected candidate is replaced by `seed_words_from_bytes(seed || k_le32)`, `k = 1, 2, ...`, 32 consecutive rejections a consensus fault. Every pack carries `generator 2`, the attempt and the program id `FNV-1a-64("igneum-program/" || 2_le32 || seed words LE || attempt_le32)`; `igneum-pow` is 0.2.0 and the node's engine reports `igneum-lottery-v2-bound`. The crate is now the pack source (`igneum-pow export`); the Swift exporter is the Metal cross-check. Version 1 stays as `generate_v1` for the census and MEMHARD.md levers; its vectors are retired.
+Machine: Apple M5 Max, idle at the start (load 3), rustc 1.99.0 (rustup), Swift 5.8.1, builds at nice 10. Decision (the project lead, this morning): adopt the census's generator rule before any public vector ships. Rule as implemented (`igneum-pow/src/generator.rs`, `src/accept.rs`, spec 01 sections 1.4.2, 1.4.3 and 1.4.6; mirrored in `proto-metal/main.swift` as `generateProgramV2` and `acceptProgram` because the Metal worker derives its program from the seed itself): G1 exactly 16 load slots, a uniform subset of instructions 1..63 drawn first by partial Fisher-Yates, the other 48 ops from the ten non-load weights (sum 75); G2 a load's source is drawn from the registers other than `dst` written by an earlier instruction and not read by a load since; R (a) no cyclically stale load source, (b) every register has an injecting write, (c) 64 units at base nonces from `SplitMix64(FNV-1a-64("igneum-accept/" || seed words LE))` on the seed-keyed closed-form dataset at 2^28 words with init words = seed words: no constant register bit, no lane-constant load site in any unit, fewer than 164 saturated final values, every output bit within 136 of 1,024, distinct addresses above 245,760 over the 2,048 hashes; a rejected candidate is replaced by `seed_words_from_bytes(seed || k_le32)`, `k = 1, 2, ...`, 32 consecutive rejections a consensus fault. Every pack carries `generator 2`, the attempt and the program id `FNV-1a-64("igneum-program/" || 2_le32 || seed words LE || attempt_le32)`; `igneum-pow` is 0.2.0 and the node's engine reports `igneum-lottery-v2-bound`. The crate is now the pack source (`igneum-pow export`); the Swift exporter is the Metal cross-check. Version 1 stays as `generate_v1` for the census and MEMHARD.md levers; its vectors are retired.
 
 Packs regenerated (`proto-cuda/packs/`): `igneum-genesis` and `igneum-hourly` (closed form), `igneum-genesis-mh` (memory-hard, day 2026-10-03, cache FNV unchanged `48c4f5bf24166b2e`), and new `igneum-devnet-v4-epoch0` (epoch seed = devnet genesis hash `edc4fa84...fb07`, day bytes `igneum-day/20730`, cache FNV `448274a57f508cbc`). `igneum-genesis` attempt 0, program id `bcc1248b10cc90f2`, op mix `load=16 add=8 shfl=8 xor=6 mad=5 mul=5 mulhi=5 sub=4 rotl=3 rotr=3 or=1`, lane 0 at base 0 `42246ba99fc58e4f`, lane 31 `b08446b1f2de7793`; devnet pack id `4be132dd1f2ff270`, lane 0 `285a83011e7ac3fc`. Bound vectors re-cut (`igneum-pow/README.md`: H zero, nonce 0 gives `746c567b090acf6a`). `cargo test --release`: 39 of 39 (28 unit, 11 pack).
 
@@ -545,7 +545,7 @@ Not done: no NVIDIA or AMD hardware has run a version 2 pack (the RTX 5090's 192
 
 ## 2026-10-04  finality floor 2/3: the total-weight floor raised from 17/30 to two thirds, simulator A to L re-run, attack scenarios 6A and 6B on a three-node, six-voter network (cryptographer)
 
-Decision of 4 October 2026 (the founder, O-3.15): a lock needs two thirds of all 30-day weight, and finality pauses whenever less than two thirds of that weight is connected and signing; the chain continues on proof of work meanwhile and the node reports it. Spec 3.3, 3.3.1, 3.7, 3.9, 3.11 rewritten; litepaper Finality and "What Igneum does not claim" updated; ledger F2, F9, F16, F18 restated and F21 added (the window bound of attack scenario 6A).
+Decision of 4 October 2026 (the project lead, O-3.15): a lock needs two thirds of all 30-day weight, and finality pauses whenever less than two thirds of that weight is connected and signing; the chain continues on proof of work meanwhile and the node reports it. Spec 3.3, 3.3.1, 3.7, 3.9, 3.11 rewritten; litepaper Finality and "What Igneum does not claim" updated; ledger F2, F9, F16, F18 restated and F21 added (the window bound of attack scenario 6A).
 
 Node. Branch `devnet-v4` of `vendor/igneum-node` (worktree `vendor/igneum-node-v4`, from `dc749905`), commit `6457ca95`, two files: `consensus/core/src/finality.rs` (`FLOOR_NUM / FLOOR_DEN` 2/3, was 17/30; the Q3 arithmetic as `FinalityParams::{quorum_met, floor_met, locks}`, both comparisons inclusive) and `consensus/src/processes/finality.rs` (`lock_test` calls it). Build `CARGO_TARGET_DIR=target-integration nice -n 10 cargo build --release -j 6 -p kaspad --features kaspad/igneum-pow`, 3 min 17 s on a machine at load 3 to 13 (another agent's igneum-pow rebuild and the live devnet running). Tests `cargo test --release -j 6 -p kaspa-consensus-core -p kaspa-consensus -- finality`: 7 of 7 in consensus-core including the new `floor_is_two_thirds_of_total_and_inclusive` (4 of 6 locks, 3 of 6 does not, 2 of 3 locks, 67 of 100 locks, 66 does not, 57 does not; the total test implies the active test at every participation; a 3/3 side never locks whatever the other side's participation decays to), 2 of 2 in consensus (`no_certificate_while_the_window_is_filling` unchanged). The live devnet (26610, 26611, 26640, 26641, 28640, the seed relay on 26680 and `observer.mjs`) was never touched.
 
@@ -577,7 +577,7 @@ Notes. (1) The v4 node logged "PoW rejected ... by igneum-lottery-v1-bound" abou
 
 ## 4 October 2026, proving v0 on the RTX 5090: first GPU proof of an Igneum block (WSL2, SP1 6.8.1 cuda)
 
-Machine: the founder's Windows 11 PC, RTX 5090 (32,607 MiB, driver 617.14), 16 cores and 45 GB visible to WSL2 Ubuntu 24.04, mining
+Machine: the project lead's Windows 11 PC, RTX 5090 (32,607 MiB, driver 617.14), 16 cores and 45 GB visible to WSL2 Ubuntu 24.04, mining
 paused. Package `proving/windows-wsl2` (SETUP-PROVER then PROVE-BLOCK), host `igneum-prove-host` built with the `cuda` feature,
 `SP1_PROVER=cuda`, sp1-gpu-server 6.8.1 on device 0. Fixture `block-78-increment` (chain 4463, 2 transactions, 10 accounts).
 Run id `prove-<pc>-20261004-084838`, log intake id 10154.
@@ -773,7 +773,7 @@ button and the held miner all showed; with the real clock the HTTPS source read
 
 ## 4 October 2026, first machine on the Igneum Miner app: PC 2's RTX 5090 at 118 MH/s, via Setup.exe
 
-The founder's second PC (a clone of the first; the app's per-install machine id `1ccfe586` keeps its keys apart), installed from the
+the project lead's second PC (a clone of the first; the app's per-install machine id `1ccfe586` keeps its keys apart), installed from the
 runner-built `Igneum-Miner-Setup-0.3.0.exe` (unsigned, SmartScreen "run anyway"), the one-click package: prebuilt NVRTC
 worker, no toolchain on the machine. First attempt sat at "waiting for peer": the PC's clock was 62 s slow after a power cut
 and `igneumd` rejected every relayed block ("the block timestamp is too far into the future"; the 10-s skew bound from the
@@ -794,7 +794,7 @@ Candidates on the live replay (join window, 3 seeds, std of log difficulty / lan
 Cost (synthetic set seed 7, v1 / v2): x50 settled 61.7 / 65.5 s (standard under 90), /50 628 / 753 s (worst gap 32 / 62 s), epoch +-30% settled 144 / 143 s, hop10 211 / 200 s, polluted overshoot 0.180 / 0.089, warm-ups equal, steady std 0.038 / 0.049 with blocks-per-minute CV 0.135 / 0.130. Attacks (seeds 7 to 9, v1 / v2): greedy hopper at most +1.5% / +2.5%, with a 60 s dwell -4.0% / -1.5% at 100%; pulsed rental -96.4% / -96.3% with weight per hash 0.262 / 0.262; forger drift +0.4 to +1.1% / -0.8 to +0.5% (worst seed 2.7% / 1.5%); short-lane oscillation gain 3.75 / 3.29; epoch games 0.0 to +0.7% / 0.0 to +0.4%; polluted window settled 287 to 329 s / 288 to 331 s; base profiles 3-seed up50 154 / 150 s, down50 762 / 822 s, epoch30 88 / 88 s, hop10 245 / 233 s, polluted 75 / 76 s, steady std 0.042 / 0.053.
 Implementation (devnet-v4): `difficulty_v2_activation_daa` in `Params` (every network `u64::MAX`), `OverrideParams`, `override_params`, the daemon's file parser (prints the height), `SampledDifficultyManager` (new field, `reference_window(daa_score, epoch_blocks, activation)`), `REF_WINDOW_V2 = 600`, `IgneumInputs.k_ref`; `infra/fast-time/override-60x.json` carries the field as never. `cargo test --release -p kaspa-consensus --lib difficulty`: 15 pass (12 of 3 and 4 October plus `reference_window_switches_at_the_activation_height`, `v2_reference_window_follows_a_step_inside_the_epoch_where_v1_eases_into_it`, `v1_and_v2_agree_in_a_steady_epoch`); `-p kaspa-consensus-core --lib params`: 7 pass (`override_params_carry_the_difficulty_v2_activation`, the fast-time file test extended). Build 2 min incremental for `igneumd` and `igneum-miner`.
 Test network (`sim/difficulty/testnet_v2.py`, 3 nodes on 29600 to 29622, the 60x file with the devnet epoch, genesis bits 2^16, activation 900 on nodes 1 and 2, node 3 without it; CPU miners A from 0, B from minute 4, off at 19, back at 23): node 1 reached DAA 900 at 1,022 s; node 3 rejected the first v2 block ("difficulty of 520437997 is not the expected value of 520406991"), banned its peer and stayed at DAA 900 (901 headers, a prefix of node 1's 1,472); nodes 1 and 2 agreed on every header and the sink. Under v2 the leave eased 6,589 to 5,972 over 180 s (std 0.036, no peak), the rejoin hardened 6,154 to 8,312 within 60 s and held within 3%. The v1 phase is not readable: the load swung the CPU miners' delivered hash rate 2x on its own (difficulty fell 40% after B joined). Record `records/testnet-v2-2026-10-04.csv`. Repeat on a quiet machine, 30 minutes.
-Rollout: only `igneumd` changes (the Mac build, `infra/cross/build-linux.sh` for the seed and the Hetzner nodes, the Windows package for PC 1's node); every node of a chain needs the same `"difficulty_v2_activation_daa": N` in its override file before the height or it forks off there. First the 12 Hetzner nodes on their own chain (N = current DAA + 1,800, restart one by one, a miner joins inside an epoch, no flips after the height), then the devnet with N about two hours ahead: observer node, seed, Mac node 1, PC 1's node, in that order, by the founder. A new network sets 0.
+Rollout: only `igneumd` changes (the Mac build, `infra/cross/build-linux.sh` for the seed and the Hetzner nodes, the Windows package for PC 1's node); every node of a chain needs the same `"difficulty_v2_activation_daa": N` in its override file before the height or it forks off there. First the 12 Hetzner nodes on their own chain (N = current DAA + 1,800, restart one by one, a miner joins inside an epoch, no flips after the height), then the devnet with N about two hours ahead: observer node, seed, Mac node 1, PC 1's node, in that order, by the project lead. A new network sets 0.
 Not done: a quiet-machine test-network run; the DAG model's red blocks and the Mac's log series; v2 with +-500 ms stamp jitter.
 
 ## 4 October 2026, the observer stored nothing for 78 minutes, then 7,022 blocks in two minutes
@@ -856,7 +856,7 @@ first mismatch and are not a rate.
 
 ## 4 October 2026, shard proving on the RTX 5090: a full shard compressed in 10.9 s, a two-shard block aggregated in 2.2 s, all verified
 
-Machine: the founder's PC 2 (RTX 5090, 32,607 MiB; WSL2 Ubuntu 24.04, SP1 v6.8.1 with the cuda feature, the toolchain of the
+Machine: the project lead's PC 2 (RTX 5090, 32,607 MiB; WSL2 Ubuntu 24.04, SP1 v6.8.1 with the cuda feature, the toolchain of the
 4 October morning run in `~/igneum-prove`), the Igneum Miner app (machine id 1ccfe586) stopping its miners for the
 run. Delivered as the signed job `shard-benchmark` (`app/igneum-app/src/jobrun.rs`, `packaging/ota/publish-jobs.sh`),
 which runs `prove-shard.sh block-338-shard1 "block-341-shards2 block-344-shards4"` and reports every RESULT line to the
@@ -1067,7 +1067,7 @@ first four minutes; the identity's votes on checkpoints 1202 and 1203 were accep
 discrete card takes part in finality. Machine id 37ba0461 in the console; app log run `win-37ba0461-20261004-185342`.
 ## 4 October 2026 (evening), finality rule v3: the frozen weight table (F21) and the certificate fold (F22), simulator, unit tests, fast-time 3-node network with 300-ms links (finality engineer)
 
-The founder, 4 October 2026 evening: "we need to fix these serious issues before making things public". Both fixes sit behind one height switch, `finality_v3_activation_daa` (default never on every network, set by the override file like `difficulty_v2_activation_daa`), on branch `finality-fixes` of the node (worktree `vendor/igneum-node-finality`, from the proving head `8c0cff15`). Spec 03 Q4 (fold) and Q5 (frozen table), 3.3.1, 3.7 items 2 and 9, 3.10, 3.11; ledger F21 and F22 "Fix built, pending rollout"; the devnet plan in `docs/plans/finality-v3-rollout-devnet.md`. The live devnet was never touched; every network below ran on ports 29700 to 29799, suffix 970.
+the project lead, 4 October 2026 evening: "we need to fix these serious issues before making things public". Both fixes sit behind one height switch, `finality_v3_activation_daa` (default never on every network, set by the override file like `difficulty_v2_activation_daa`), on branch `finality-fixes` of the node (worktree `vendor/igneum-node-finality`, from the proving head `8c0cff15`). Spec 03 Q4 (fold) and Q5 (frozen table), 3.3.1, 3.7 items 2 and 9, 3.10, 3.11; ledger F21 and F22 "Fix built, pending rollout"; the devnet plan in `docs/plans/finality-v3-rollout-devnet.md`. The live devnet was never touched; every network below ran on ports 29700 to 29799, suffix 970.
 
 **F22, what was wrong.** The cloud logs of the healthy stretch 11:45 to 14:00 UTC (212 indices, 12 miners; `tools/finality-attacks/vote-timing.py`, output in `infra/cloud-devnet/results/2026-10-04/f22-vote-timing.md`): the node builds a certificate the instant the votes it holds meet Q3, median 1.24 s (p99 1.71 s) after the first node determined the checkpoint, with 7 to 10 of 12 signers (mean 8.27); 10.24 votes had been issued by then on average (two in flight: the miner's 1-s poll, the 250-ms gossip pump per hop, up to 289 ms RTT) and the last of the 12 was issued median 1.45 s, p90 2.36 s after the first determination. A 1-s hold after the first build would have carried all 12 votes at 192 of 212 indices; the other 20 are miners 01, 06 and 11 down together for 10 minutes (indices 377 to 396, the hop.sh restarts), an outage, not lag. There is no cut-off to lengthen: the fix is a second round. Presence needs nothing, since the block reading of Q2 credits a late vote once any block carries it.
 
@@ -1094,7 +1094,7 @@ The founder, 4 October 2026 evening: "we need to fix these serious issues before
 | split50, v3: the same cut | neither side locks during the split; heal; locking resumes on one chain; 0 conflicting certificates | 0 / 0 / 0 new locks during the 150 s (the v2 control locked at 126 s, so the frozen table held side B for the checkpoints of the last 24 s; the frozen table would have expired at 240 s); n0 redialled 72 s after the gate reopened; all three nodes resumed at index 7 and reached 13 inside the heal window; 0 conflicting certificates; 0 disagreeing locked indices; every post-heal LOCKED line names the frozen lock and its fraction (81 to 94% of the frozen table) | PASS |
 | split70, v3: 4/2 keys, the 4 side at 70% of weight (shares 0.175 x 4 against 0.15 x 2), 150 s | the 4 side locks during the split, the 2 side does not; 0 conflicts | 4 side: 4 new locks, the first 30 s after the cut; 2 side: 0; heal: all three at 17; 0 conflicting certificates; 0 disagreeing indices | PASS (6B at 70/30; exactly 4/6 is a knife edge under both rules, simulator row above) |
 
-**What remains uncertain.** (1) The v3 split's hold was observed over the last 24 s of a 150-s split (the control crossed at 126 s); a longer split under the 240-s expiry (say 200 s) would show more held checkpoints, and the "held by the frozen table" line is logged at debug, which the runs did not enable. (2) No cloud rehearsal: the 12-node Hetzner network was destroyed at 15:30 UTC, so the 95% target is shown on three nodes with emulated 300-ms links and on the cloud logs' arithmetic, not on the cloud topology itself; the rollout plan names the re-creation and the partition experiment to run first. (3) The frozen reference is the node's own highest lock on the chain, not the certificate carried in C_i's past, so two honest nodes can test one checkpoint against tables 30 s apart; in a connected network those tables differ by a minute of blocks, under a partition both are pre-split, and no run showed a disagreement, but it is a property argued, not proved. (4) The price: a sudden departure of a third or more now pauses finality for a full window (30 days on mainnet) instead of 1.4 to 10 days; a gradual one costs nothing. The founder asked for the pause over the fork; the number is stated in spec 3.7 item 2. (5) The fold clock is in memory: a restarted node folds from `daa(C_i) + depth`, a few seconds late at worst. (6) Binaries, all from `finality-fixes` 6aa69a45, hashes and checks in the rollout plan's section 2: Mac native `fe982a1d...` (verified running), Linux `7c100fc2...` (cargo-zigbuild, 34 min, not run on a Linux host), Windows `cc1d1001...` (mingw, 12 min 28 s, the v2 exe's DLL set, cannot run here); the Windows payload inputs were staged with `push-inputs.sh --no-deploy` into a scratch folder and NOT deployed (plan 7a).
+**What remains uncertain.** (1) The v3 split's hold was observed over the last 24 s of a 150-s split (the control crossed at 126 s); a longer split under the 240-s expiry (say 200 s) would show more held checkpoints, and the "held by the frozen table" line is logged at debug, which the runs did not enable. (2) No cloud rehearsal: the 12-node Hetzner network was destroyed at 15:30 UTC, so the 95% target is shown on three nodes with emulated 300-ms links and on the cloud logs' arithmetic, not on the cloud topology itself; the rollout plan names the re-creation and the partition experiment to run first. (3) The frozen reference is the node's own highest lock on the chain, not the certificate carried in C_i's past, so two honest nodes can test one checkpoint against tables 30 s apart; in a connected network those tables differ by a minute of blocks, under a partition both are pre-split, and no run showed a disagreement, but it is a property argued, not proved. (4) The price: a sudden departure of a third or more now pauses finality for a full window (30 days on mainnet) instead of 1.4 to 10 days; a gradual one costs nothing. the project lead asked for the pause over the fork; the number is stated in spec 3.7 item 2. (5) The fold clock is in memory: a restarted node folds from `daa(C_i) + depth`, a few seconds late at worst. (6) Binaries, all from `finality-fixes` 6aa69a45, hashes and checks in the rollout plan's section 2: Mac native `fe982a1d...` (verified running), Linux `7c100fc2...` (cargo-zigbuild, 34 min, not run on a Linux host), Windows `cc1d1001...` (mingw, 12 min 28 s, the v2 exe's DLL set, cannot run here); the Windows payload inputs were staged with `push-inputs.sh --no-deploy` into a scratch folder and NOT deployed (plan 7a).
 
 ## 4 October 2026, miner performance: variant racing (Metal worker on the M5 Max; the RTX 5090 job is ready, not run)
 
@@ -1553,7 +1553,7 @@ Reading (the NEW finding, ledger C4). With the module off GHOSTDAG alone converg
 
 ## 5 October 2026 (evening), the 9070 XT on the eGPU: why 17.9 MH/s, and what moved
 
-PC 1 (ae432dc7, Windows 11, Ryzen 7 9800X3D with its gfx1036, RTX 5090 on CUDA), an AMD Radeon RX 9070 XT (gfx1201, RDNA 4) in a Sonnet Breakaway Box 850T5 over USB4, Adrenalin 26.9.2 (OpenCL driver string `3683.0 (PAL,LC)`, platform `OpenCL 2.1 AMD-APP (3683.0)`). Branch `opencl-rdna4`. The founder: "the hashrate is low" (17.9 MH/s with one worker; two workers on the card earlier gave 8.9 and 9.4).
+PC 1 (ae432dc7, Windows 11, Ryzen 7 9800X3D with its gfx1036, RTX 5090 on CUDA), an AMD Radeon RX 9070 XT (gfx1201, RDNA 4) in a Sonnet Breakaway Box 850T5 over USB4, Adrenalin 26.9.2 (OpenCL driver string `3683.0 (PAL,LC)`, platform `OpenCL 2.1 AMD-APP (3683.0)`). Branch `opencl-rdna4`. the project lead: "the hashrate is low" (17.9 MH/s with one worker; two workers on the card earlier gave 8.9 and 9.4).
 
 **Before, from PC 1's own app log** (`node tools/logs.mjs win-ae432dc7-20261005-181046`, the miner's STATUS line for the card `amd:1:gfx1201`, 2^21-nonce jobs): `hash=17.82 MH/s wall (17.83 MH/s inside jobs) ... idle=0.3%`. Wall equals inside, so the host loop (template fetch, job line, read-back, scan) costs nothing measurable; the dispatch itself is slow. The worker's `ready` line: `exchange 0` (local memory: AMD lists `cl_khr_subgroups` and no shuffle extension), `batch 4194304`, `dataset-log2 28` (1 GiB), device `[1] gfx1201` on the 3683.0 platform, `AMD wavefront width 32`. The same card was listed again as `[3] gfx1201` on the older platform `3652.0` (the 32.0.21042 driver's OpenCL registration is still present after the update): that is the two-worker run.
 
@@ -1589,12 +1589,12 @@ Reading: at the dataset size the card delivers about 2.5 G random 4-byte reads p
 | Card | 1024 MiB chase at 4,096 lanes | 1024 MiB chase ceiling | indep x8 ceiling | ceiling / 128 = hash ceiling | measured hash rate |
 |---|---|---|---|---|---|
 | RX 9070 XT, eGPU over USB4 | 2.64 G/s, 1,552 ns | 2.42 to 2.68 G/s | 2.42 G/s | 18.9 to 20.9 MH/s | 18.0 to 18.1 MH/s (bench), 17.8 (app) |
-| RTX 5090, PCIe 5 x16, contended | 9.09 G/s, 451 ns | 16.4 to 18.0 G/s | 16.2 to 16.7 G/s | 128 to 141 MH/s | 127 MH/s (app, the founder), 139.7 alone (M11) |
+| RTX 5090, PCIe 5 x16, contended | 9.09 G/s, 451 ns | 16.4 to 18.0 G/s | 16.2 to 16.7 G/s | 128 to 141 MH/s | 127 MH/s (app, the project lead), 139.7 alone (M11) |
 | Apple M5 Max, Apple OpenCL | 2.10 G/s, 1,949 ns | 3.41 to 3.49 G/s | 3.45 to 3.47 G/s | 26.6 to 27.3 MH/s | 27.9 Mhash/s (README, Apple OpenCL) |
 
 Reading: on all three cards the hash runs within a few percent of 1/128 of the card's dependent random-read ceiling, which is what a 128-load program should do; the probe is a good model of the hash. The 5090 does 6.6x the random reads of the 9070 XT for 2.8x the rated bandwidth (1,792 against 640 GB/s, vendor figures): the rest is access granularity and DRAM behaviour on random 4-byte reads, which the kernel cannot change.
 
-**Power, heat, fans and clocks, measured** (branch `opencl-rdna4-telemetry`; the founder watched the 9070 XT at 90% usage with its fans barely turning and the app had no AMD reading, the MH/W line came from nvidia-smi only; a new helper `proto-opencl/gpu-telemetry.c` reads ADLX on Windows and the amdgpu sysfs on Linux. Job `tele-measure-1`, 20:27:45 to 20:29:41 UTC, both cards mining in the app, nothing touched: `igneum-gpu-telemetry -l 5` (sha256 `703cf69c…a9c69b`) and `nvidia-smi --query-gpu=index,name,power.draw,temperature.gpu,fan.speed,clocks.mem,clocks.gr,utilization.gpu -l 5` side by side, the app's `hash_now` every 5 s; `node tools/jobs.mjs tele-measure-1`):
+**Power, heat, fans and clocks, measured** (branch `opencl-rdna4-telemetry`; the project lead watched the 9070 XT at 90% usage with its fans barely turning and the app had no AMD reading, the MH/W line came from nvidia-smi only; a new helper `proto-opencl/gpu-telemetry.c` reads ADLX on Windows and the amdgpu sysfs on Linux. Job `tele-measure-1`, 20:27:45 to 20:29:41 UTC, both cards mining in the app, nothing touched: `igneum-gpu-telemetry -l 5` (sha256 `703cf69c…a9c69b`) and `nvidia-smi --query-gpu=index,name,power.draw,temperature.gpu,fan.speed,clocks.mem,clocks.gr,utilization.gpu -l 5` side by side, the app's `hash_now` every 5 s; `node tools/jobs.mjs tele-measure-1`):
 
 | Card | Samples | Watts (mean, min to max) | Temperature | Fan | Memory clock | Shader clock | Busy | Hash (mean of 24) | MH/W, measured |
 |---|---|---|---|---|---|---|---|---|---|
@@ -1632,7 +1632,7 @@ Reading: the kernel is the same 116.0 ms on both paths (18.08 MH/s pure kernel,
 
 **A second defect found on the way: the pack export race.** PC 1's app log since its 19:02 UTC restart (`node tools/logs.mjs win-ae432dc7-20261005-190232`): `worker error: error 0 pack packs\devnet: the epoch seed bytes do not give the pack's IGNEUM_SEEDW_INIT` at 19:07:03, 19:07:19 and 19:08:07, so the 9070 XT was not mining at all in the app while this entry was written (my job `rdna4-serve-1` at 18:43 hit the same folder in the same state). Cause, from `app/igneum-app/src/engine.rs` `prepare_worker`: one thread per card, each running `igneum-miner export-pack` into the one folder `packs\devnet`; across an epoch change the two exports interleave and the folder keeps one epoch's `program.h` with the other's `seeds.txt` until the next export. Fix on this branch: a process-wide mutex around both export sites (`EXPORT_LOCK`); the second export rewrites the same pack. Not measured in the app yet: it ships with the branch.
 
-**Answer to the founder.** The 9070 XT does 2.5 G random 4-byte reads per second from its memory for this access pattern, and the hash needs 128 of them, so about 19 MH/s is this card's ceiling for the current program class, on any slot; it was running at 92% of that. The eGPU link cost 6% per job through the read-back, now removed (17.87 against 16.88 MH/s inside jobs standalone). The duplicate platform that halved it to 8.9 + 9.4 is folded away. The pack race that stopped it is serialised. Nothing else in the worker's control moves the number: the next step for this card is the program class itself (fewer, wider loads per hash would favour AMD's 64-byte lines), which is a consensus question, not a worker one.
+**Answer to the project lead.** The 9070 XT does 2.5 G random 4-byte reads per second from its memory for this access pattern, and the hash needs 128 of them, so about 19 MH/s is this card's ceiling for the current program class, on any slot; it was running at 92% of that. The eGPU link cost 6% per job through the read-back, now removed (17.87 against 16.88 MH/s inside jobs standalone). The duplicate platform that halved it to 8.9 + 9.4 is folded away. The pack race that stopped it is serialised. Nothing else in the worker's control moves the number: the next step for this card is the program class itself (fewer, wider loads per hash would favour AMD's 64-byte lines), which is a consensus question, not a worker one.
 
 ## 5 October 2026 (night), Ember Tune: the two-knob efficiency tune, the fleet prior, and what PC 1 could measure tonight (miner-community-lead)
 
@@ -1658,7 +1658,7 @@ Branch `ember-tune` (54ff1bc), docs/plans/ember-tune.md. Every card tuned for MH
 | RX 9070 XT (bus 98, present again) | `tune 1 ... gmax 0 gmax_range -500 1000 plimit 0 plimit_range -30 10 factory 1 ok` | the helper's clock range is an OFFSET from stock in MHz, not a ceiling: a probe reading it as a 1,000 MHz maximum would have asked for `--set-gmax 900`, an overclock. Fixed at 054e041: an offset range closes the clock knob (until the stock clock is known) and the power ladder runs on the percent scale bounded by the range, so the 9070 XT's plan is 100, 90, 80, 70% (the -30 floor), 4 steps |
 | Radeon(TM) Graphics (integrated) | `tune 0 ... gmax - ... factory 0 ok` | no manual tuning: measure only, and it is off by default anyway |
 
-**Run 2, 6 October 2026, 07:21 to 07:56Z (job ember-tune-pc1-2, elevated on the founder's word, engine 25113f52..., PC 1 on 0.3.11):** the founder answered the one prompt; the installed app stopped its miners at 07:21:16Z; the second engine ran for the whole 35-minute budget at "waiting, 0.00 MH/s" and no step ran. Cause: the playbook wrote the engine's copy of settings.json with PowerShell 5.1's `Set-Content -Encoding utf8`, which adds a UTF-8 BOM; the engine's JSON parser refuses it, `Settings::load` fell back to defaults (no payout address, no cards), the engine logged `[error] no payout address` and never started a miner. Run 1's scratch log carried the same line the night before. Readbacks, idle both times: the 5090 at 90.6 W before and 69.9 W after (2,505 then 2,407 MHz core, 14,001 MHz memory, limit 450 W of 575), the 9070 XT at factory (`gmax 0`, `plimit 0`). Nothing set on either card. The installed app's runner released the miners-stopped hold by itself on the failed exit (`job finished; the miners restart` at 07:56:50Z, both miners up by 07:57:04Z, `mining` at 07:57:29Z): mining paused 36 min 13 s. Fix 8273494: the copy is written without a BOM, the address is read back and the job fails within seconds if it is empty (`RESULT TUNE scratch settings: address ..., cards N, first bytes ...`), and the CI check fails any playbook writing JSON with `Set-Content -Encoding utf8`. The re-run needs one more click on the prompt.
+**Run 2, 6 October 2026, 07:21 to 07:56Z (job ember-tune-pc1-2, elevated on the project lead's word, engine 25113f52..., PC 1 on 0.3.11):** the project lead answered the one prompt; the installed app stopped its miners at 07:21:16Z; the second engine ran for the whole 35-minute budget at "waiting, 0.00 MH/s" and no step ran. Cause: the playbook wrote the engine's copy of settings.json with PowerShell 5.1's `Set-Content -Encoding utf8`, which adds a UTF-8 BOM; the engine's JSON parser refuses it, `Settings::load` fell back to defaults (no payout address, no cards), the engine logged `[error] no payout address` and never started a miner. Run 1's scratch log carried the same line the night before. Readbacks, idle both times: the 5090 at 90.6 W before and 69.9 W after (2,505 then 2,407 MHz core, 14,001 MHz memory, limit 450 W of 575), the 9070 XT at factory (`gmax 0`, `plimit 0`). Nothing set on either card. The installed app's runner released the miners-stopped hold by itself on the failed exit (`job finished; the miners restart` at 07:56:50Z, both miners up by 07:57:04Z, `mining` at 07:57:29Z): mining paused 36 min 13 s. Fix 8273494: the copy is written without a BOM, the address is read back and the job fails within seconds if it is empty (`RESULT TUNE scratch settings: address ..., cards N, first bytes ...`), and the CI check fails any playbook writing JSON with `Set-Content -Encoding utf8`. The re-run needs one more click on the prompt.
 
 **Dry run 3, 6 October 2026, 14:56 to 15:02Z (job ember-dryrun-pc1-3, unelevated, no prompt, measure only; engine from ember-tune 07d5a72, kit sha256 36b522c9...):** the first measurement engine on PC 1 that mined. Both cards, one 60 s row each at the installed app's 80% cap, clocks unlocked, rate = the worker's STATUS wall rate, draw = nvidia-smi every 5 s:
 
@@ -1669,7 +1669,7 @@ Branch `ember-tune` (54ff1bc), docs/plans/ember-tune.md. Every card tuned for MH
 
 Nothing set; the installed app's miners back after 350 s. Why every earlier run (5 and 6 October, runs 1 to 4 and dry runs 1 and 2) read its copied settings as defaults, measured on PC 1 (collect ember-acl-2): the engine's own start locks its app folder with `icacls /inheritance:r /grant:r <user>:F`; cutting the folder's inheritance propagates down, the non-inheritable grant gives the children nothing, so a file COPIED in before the start (settings.json, machine-id, wallet.json) is left with no access entry and its owner cannot read it (`ReadAllText`: access denied), while the engine's own files written after the lock inherit fine, which hid it for a day. A first fix with `(OI)(CI)F /T` left the file empty too: `/T` re-applies `/inheritance:r` to each file after the propagation and an `(OI)(CI)` entry on a file is inherit-only. The right form is the inheritable grant without `/T` (07d5a72). Consequence for every tier on Windows: nothing changes for the installed app (its files were always its own); any tool that drops files into the app folder before the app starts (an installer's seed, a migration, a support script) was unreadable to the app until now and is readable from 0.3.13 on.
 
-**Run 5, 6 October 2026, 15:28 to 15:39Z (job ember-tune-pc1-5, elevated on the founder's click, PC 1 on 0.3.13, the tune engine = kit ember-kit-5 from 07d5a72, mode=direct):** the first run that set limits. The 5090's power ladder, 75 s a step, the clock unlocked (2,850 MHz core, 13,801 MHz memory), the rate = the worker's STATUS wall rate, the draw = nvidia-smi every 5 s:
+**Run 5, 6 October 2026, 15:28 to 15:39Z (job ember-tune-pc1-5, elevated on the project lead's click, PC 1 on 0.3.13, the tune engine = kit ember-kit-5 from 07d5a72, mode=direct):** the first run that set limits. The 5090's power ladder, 75 s a step, the clock unlocked (2,850 MHz core, 13,801 MHz memory), the rate = the worker's STATUS wall rate, the draw = nvidia-smi every 5 s:
 
 | Cap | Limit | MH/s | W | MH/W | GPU C |
 |---|---|---|---|---|---|
@@ -1679,12 +1679,12 @@ Nothing set; the installed app's miners back after 350 s. Why every earlier run
 | 70% | 403 W | 127.38 | 310.9 | 0.410 | 65 |
 | 60% (floor 400 W) | 400 W | 127.38 | 311.3 | 0.409 | 65 |
 
-Reading: the cap does not bind on this hash (310 to 314 W under every limit, as the 4 October stability line said), so the power knob is flat at 0.41 MH/W on the 5090 and the saving must come from the clocks; the 90% and 80% rows' rate dips at the same draw are stalls inside those holds (a worker restart or a template wait), not the cap. The clock ladder's first step (2,781 MHz at 575 W) was requested at 15:37:47Z and never measured: the playbook's own watchdog killed the live engine at 15:39:03Z (all three cards mining at 177 MH/s) because its idle clause sampled one log line and read "idle" from a missing match; the 4070's and the 9070 XT's plans never ran. Consequences: the 5090 is probably left with its core clock locked at 2,781 MHz (an `-lgc` lock persists until `-rgc` or a reboot) under the 575 W cap, which costs little rate; freeing it needs administrator rights; and the Power Helper was NOT registered by this run (the registration lived only in the installed app's cap path, which a `--sweep` engine skips). Fixed the same hour: the watchdog's idle rule (three consecutive status lines reading 0.00 MH/s and 300 s, never a missing match), the `after` snapshot and the engine-log dump on every exit, and an elevated tune engine registering the task itself before its first step. The decided way out: the founder switches Power control ON in the 0.3.13 app (its one prompt registers the task from the install folder), a job frees the clock through the task (`rgc`), the tune runs unelevated through the task.
+Reading: the cap does not bind on this hash (310 to 314 W under every limit, as the 4 October stability line said), so the power knob is flat at 0.41 MH/W on the 5090 and the saving must come from the clocks; the 90% and 80% rows' rate dips at the same draw are stalls inside those holds (a worker restart or a template wait), not the cap. The clock ladder's first step (2,781 MHz at 575 W) was requested at 15:37:47Z and never measured: the playbook's own watchdog killed the live engine at 15:39:03Z (all three cards mining at 177 MH/s) because its idle clause sampled one log line and read "idle" from a missing match; the 4070's and the 9070 XT's plans never ran. Consequences: the 5090 is probably left with its core clock locked at 2,781 MHz (an `-lgc` lock persists until `-rgc` or a reboot) under the 575 W cap, which costs little rate; freeing it needs administrator rights; and the Power Helper was NOT registered by this run (the registration lived only in the installed app's cap path, which a `--sweep` engine skips). Fixed the same hour: the watchdog's idle rule (three consecutive status lines reading 0.00 MH/s and 300 s, never a missing match), the `after` snapshot and the engine-log dump on every exit, and an elevated tune engine registering the task itself before its first step. The decided way out: the project lead switches Power control ON in the 0.3.13 app (its one prompt registers the task from the install folder), a job frees the clock through the task (`rgc`), the tune runs unelevated through the task.
 
 Consequence for the tiers: an AMD card is tuned on its power limit alone until its stock core clock is read (a 9070 XT at -30% is the floor the driver allows, 4 steps, 5 minutes); every NVIDIA card's two-knob plan waits on the user's one click on Power control; the re-run on PC 1 is held until the quit's source is named (the event-log collect) and follows the 0.3.11 rollout (the update clears the jobs folder, so the engine and the helper are fetched again), with the scheduler's slot.
 ## 5 October 2026 (night), read width of the lottery hash: 4, 16 and 64-byte loads, a per-load mix, a written scratch; three cards (gate 1 experiment, cryptographer)
 
-Branch `readwidth` (commits 019b014, b970dda, 4badcee, a9e002c, d0018cf and the entry commit); plan and recommendation in `docs/plans/read-width.md`. Nothing here changes consensus: every class sits behind `igneum-pow --class` and the default class is generator version 2 byte for byte (`igneum-pow/tests/packs.rs` passes on the four pinned packs after every commit). Question (the founder, after "the 9070 XT on the eGPU" above): would wider reads keep the latency-bound random-access property while closing the vendor gap. Additions from the coordinator: a per-load width drawn from an era-fixed mix, and a written per-warp scratch (measurement only, no soundness claim).
+Branch `readwidth` (commits 019b014, b970dda, 4badcee, a9e002c, d0018cf and the entry commit); plan and recommendation in `docs/plans/read-width.md`. Nothing here changes consensus: every class sits behind `igneum-pow --class` and the default class is generator version 2 byte for byte (`igneum-pow/tests/packs.rs` passes on the four pinned packs after every commit). Question (the project lead, after "the 9070 XT on the eGPU" above): would wider reads keep the latency-bound random-access property while closing the vendor gap. Additions from the coordinator: a per-load width drawn from an era-fixed mix, and a written per-warp scratch (measurement only, no soundness claim).
 
 **What a class does** (`igneum-pow/src/generator.rs` `LoadClass`, `verify::fold_words`, the three emitters): a load of W words reads the W-word-aligned address `(src AND MASK) AND NOT (W - 1)` and folds every word into `dst` (`x = dst ^ w0; x = (rotl(x, 11) * 0x9e3779b1) ^ w[j]`); W = 1 is the lottery hash exactly (`w4` = pack `bcc1248b10cc90f2`). A mix class draws W per load with one extra `below(100)` roll per instruction. A scratch class `scr<k>k<kb>` turns `k` of the 16 memory slots into read-modify-writes of a 16-byte slot of the lane's share of a `kb` KiB per-warp scratch (kernels run persistent warps, one per block or work-group; a slot reads as a seed-and-base fill until the unit writes it, behind a per-unit tag). Program ids carry the class. Dependent chain and 32-lane unit unchanged.
 
@@ -1862,7 +1862,7 @@ Commands: `IGNEUMD=vendor/igneum-node/target-txgossip/release/igneumd IGNEUM_MIN
 
 ## 5 October 2026 (night), the SP1 CPU prover on PC 1 beside the miners, and the backend survey: no zkVM proves on AMD (amd-prove agent)
 
-The founder, 22:50 BST: "test proving on the amd card?" and "can we test proving on mac?". The analysis with the backend table and the tier consequences: `docs/analysis/amd-proving.md`. The survey (SP1 v6.8.1 and `dev` 318dd530 of 28 Sep 2026, RISC Zero, Jolt, OpenVM, ICICLE, sppark; every claim cites a file or page there): on 5 October 2026 no zkVM proves on an AMD GPU; Apple silicon has RISC Zero's shipped Metal prover and ICICLE's Metal backend; SP1, the prover here, is CPU-only off NVIDIA.
+the project lead, 22:50 BST: "test proving on the amd card?" and "can we test proving on mac?". The analysis with the backend table and the tier consequences: `docs/analysis/amd-proving.md`. The survey (SP1 v6.8.1 and `dev` 318dd530 of 28 Sep 2026, RISC Zero, Jolt, OpenVM, ICICLE, sppark; every claim cites a file or page there): on 5 October 2026 no zkVM proves on an AMD GPU; Apple silicon has RISC Zero's shipped Metal prover and ICICLE's Metal backend; SP1, the prover here, is CPU-only off NVIDIA.
 
 Machine: PC 1 (machine ae432dc7), Windows 11, WSL2 Ubuntu 24.04 as root, 16 cores and 46,994 MB visible to the VM, the Igneum Miner app 0.3.9 mining on the RTX 5090 and the RX 9070 XT throughout (the 5090 at 89% mean utilisation, 59 to 70% minimum, from a 1-s `nvidia-smi` sampler under the run: the job never touched a card). Signed `run` job `cpu-prove-pc1-small2` (`tools/amd-prove/pc1-cpu-prove.ps1`), 20:49:00Z to 20:59:49Z: the hosted package `igneum-prove-wsl2-pv1b.zip` (sha256 df50dee5...) built WITHOUT the `cuda` feature (6 s warm; the first job `cpu-prove-pc1-small` built it cold in 126 s), `--mode id` the pinned pair (shard `0x2b1a81cb...`, aggregator `0x474678f3...`, pinned 2026-10-05T16:20:38Z), `SP1_PROVER=cpu`, `--mode shard --shard 0` under `/usr/bin/time -v`. Log: `node tools/jobs.mjs cpu-prove-pc1-small2 --all`.
 
@@ -1878,7 +1878,7 @@ Reading, and the consequences (CLAUDE.md, every number). Doubling the cycles add
 
 ## Counter ASIC 2.0, the numbers
 
-5 October 2026 (night). The chip-resistance layers measured on the three cards we own (Apple M5 Max, RTX 5090 on PC 1 and PC 2, RX 9070 XT on PC 1's eGPU), the decisions taken under the founder's delegated rules for the devnet, and the chip model before and after. Every number is from an entry above or from the plan documents named; approximate is marked. Levels: `docs/plans/counter-asic-2-public.md`.
+5 October 2026 (night). The chip-resistance layers measured on the three cards we own (Apple M5 Max, RTX 5090 on PC 1 and PC 2, RX 9070 XT on PC 1's eGPU), the decisions taken under the project lead's delegated rules for the devnet, and the chip model before and after. Every number is from an entry above or from the plan documents named; approximate is marked. Levels: `docs/plans/counter-asic-2-public.md`.
 
 **Program class v3 (the devnet, activation by height switch `program_class_v3_activation_daa`)** = class v2's 128 x 4-byte loads, the era draw of the table layout and the working-set windows (layers 4 and 8), the cache growth rule (layer 6, option C: the cache doubles when the dataset doubles), the mixer at x8 (M16's multiplier), reserve family R1 (integer matrix, switched off) and the epoch length as a signalled reserve parameter (layer 9, 3,600 DAA s until a 90% signal). Not adopted on the measurements: wider reads (layer 1), the per-load width mix (layer 2), the per-warp write scratch (layer 3), the hot table (layer 5).
 
@@ -1963,7 +1963,7 @@ Inputs, all RTX 5090 (PC 2), SP1 6.8.1 cuda: a full shard at the provisional `S_
 
 Reading. The card count is the sum of card-seconds of work per block-second, rounded up, with no slack for the exclusive window, the relay or a card's idle gaps; the devnet's own numbers tonight (one card, 1.4 to 1.6 shards a minute, 2.4 to 4.7% of blocks) are the first row. Two levers, both measured tonight: the loop (a shard's carriage through export, cut and a 12-s key setup is 25 s on top of a 7-s proof; the host's `--mode aggregate` and `--mode chain` hold one key setup per process and the prover loop should do the same, the 0.3.11 item in the plan) and the card's other job (a mining card proves 3 to 4x slower than an idle one, `chain-pc2-pv1c` against 4 October; the prover's cost to mining is 4%). A fleet of 18 mining 5090s, or 6 proving-only ones, covers an empty-block chain at 1 block/s through the chain mode; the mandatory rule waits for the measured share to reach one, not for these rows.
 
-### The 12 GB requirement (the founder, 20:1xZ: "make sure we can prove on 12gb cards"): the GPU memory peak against SP1's knobs
+### The 12 GB requirement (the project lead, 20:1xZ: "make sure we can prove on 12gb cards"): the GPU memory peak against SP1's knobs
 
 Job `memsweep-pc2-pv1` (`tools/proving-v1/pc2-memory-sweep.ps1`), PC 2's RTX 5090 (32,607 MiB), the miners STOPPED by the job and the live prover switched off (its `sp1-gpu-server` would otherwise be the one the client connects to), every row: the server killed first, a 1-s `nvidia-smi memory.used` sampler, one `--mode compressed --shard 0` run of the pv1 host (`/opt/igneum-pv1`, SP1 6.8.1 cuda, `sp1-gpu-server` 6.8.1), 20:19 to 20:25Z. The knobs are the environment the GPU server inherits from the host process (`sp1-core-executor-6.8.1/src/opts.rs`: `SHARD_SIZE`, `ELEMENT_THRESHOLD`, `HEIGHT_THRESHOLD`, `MINIMAL_TRACE_CHUNK_THRESHOLD`, `TRACE_CHUNK_SLOTS`; `sp1-prover-6.8.1/src/worker/config.rs`: the `SP1_WORKER_NUM_*` and `*_BUFFER_SIZE` counts, defaults 4 core workers, 8 recursion prover workers). Idle card before the sweep: 1,732 MiB.
 
@@ -2069,7 +2069,7 @@ Totals: 228 of 228 PASS where expected, 3 of 3 FAIL where built in. Reading: the
 
 ## 5 October 2026 (night), epoch length as an era parameter (Counter ASIC 2.0, layer 9): the Mac's compile-ahead per program
 
-Branch `ca2-epoch`, worker "ca2-epoch"; design and the per-card table in `docs/plans/epoch-length.md`. Question (the founder: "what about faster program changes?"): what a card spends per epoch between receiving the next seed and swapping, which sets the floor of the epoch-length ladder (600 to 7,200 DAA s). Machine: Apple M5 Max (Darwin 25.6.0, 64 GiB), 21:18 UTC, load average 11 to 14 from other agents' builds and runs; the measure lock held for the 3-s run (`tools/lock/with-lock.sh measure bash scratchpad/epoch-measure.sh`). `proto-metal/igneum-bench` built from this branch with `swiftc -O -target arm64-apple-macos11 -o igneum-bench main.swift -framework Metal` under a build slot.
+Branch `ca2-epoch`, worker "ca2-epoch"; design and the per-card table in `docs/plans/epoch-length.md`. Question (the project lead: "what about faster program changes?"): what a card spends per epoch between receiving the next seed and swapping, which sets the floor of the epoch-length ladder (600 to 7,200 DAA s). Machine: Apple M5 Max (Darwin 25.6.0, 64 GiB), 21:18 UTC, load average 11 to 14 from other agents' builds and runs; the measure lock held for the 3-s run (`tools/lock/with-lock.sh measure bash scratchpad/epoch-measure.sh`). `proto-metal/igneum-bench` built from this branch with `swiftc -O -target arm64-apple-macos11 -o igneum-bench main.swift -framework Metal` under a build slot.
 
 Ten distinct programs (seed strings `igneum-devnet-v4-epoch0`, `/epoch1` .. `/epoch9`; version 2 generator, 128 loads per hash), each generated and compiled at run time (`makeLibrary` from source plus `makeComputePipelineState`), dataset 2^28 words, one 2^20 batch and one verify warp per program:
 
@@ -2158,7 +2158,7 @@ cautious 1.5x 0.43x, at the old 3x 0.86x; equal silicon 0.29x / 0.36x. dr368: 0.
 11 cores against 4.5), IBD over 108,000 headers is 8.8 min on one core (x8: 3.7); on a 2019-class laptop core
 (2.5x, approximate, O-1.14 unmeasured) 736 reads about 12 ms, over the gate, and 368 about 6.7 ms, under it. The
 build: the Mac pays 7 ms more per day (29 against 22 ms), nothing to any tier; the 5090 is the PC 2 job below;
-the 9070 XT is OWED (PC 1 is the founder's desk today; its x8 build was 72 to 77 ms); the integrated gfx1036 tier
+the 9070 XT is OWED (PC 1 is the project lead's desk today; its x8 build was 72 to 77 ms); the integrated gfx1036 tier
 already misses the per-prepare rule at x8 (epoch-length.md 6.1: 6.9 / 9.4 / 11.7 s prepares at x1, about 55 to
 94 s at x8, approximate) and the day program leaves that need (per-day dataset reuse in the workers, 0.3.12) the
 same in kind. The compile: the Metal item library is 0.75 to 0.8 s cold once a day and 1 ms from the shader cache;
@@ -2232,7 +2232,7 @@ Reading: the M5 Max stays latency-bound to about 100,000 ops per hash and its 5
 
 Reading: the 5090 holds to 150,800 ops (-0.3 percent) and loses 2.7 percent at 199,600, under a 431 W cap that the control never reaches (342 to 357 W) and that binds from 102,100 ops up: the SM clock falls from 3,037 to 1,834 MHz and at 330,700 ops the card is compute-bound at the capped clock (28.6 T counted op/s, the 45.2 T budget scaled by the clock). The 5 percent point at 431 W is about 210,000 ops. The marginal ALU energy at the shipping clock, read on the three rungs under the cap: 10.2 to 13.2 pJ per counted op, twice the 5.5 pJ the chip model assumed. The 64-instruction block runs 3.5 percent above the control here too. Clock rows (`-lgc`): OWED, nvidia-smi refused the lock without administrator rights and the job did not ask for them. Power-cap rows: the 5 October sweep's (floor 400 W, so `-pl 200` and `250` cannot be set; the cap never binds at the control).
 
-**RX 9070 XT (PC 1, ae432dc7)**: OWED (PC 1 is the founder's desk and not released today); the OpenCL kernels are in every pack.
+**RX 9070 XT (PC 1, ae432dc7)**: OWED (PC 1 is the project lead's desk and not released today); the OpenCL kernels are in every pack.
 
 Consequences per tier (the file's section 8 in short): at the recommended N = 100,000 ops per hash (`sh256x27`) the Apple card loses 1.5 percent of its rate and pays 16 W more (income per watt 0.56x, per pound unchanged), the 5090 holds its rate at its 431 W cap (350 W at the control: per watt 0.81x, measured), the 9070 XT holds by its budget (owed), a rig pays about 30 percent more electricity for the same hash, a pool user sees nothing, and the `f = 1` chip's edge per joule falls from 1.6x to 0.9x against the M5 Max and from 5.6x to 2.1x against the 5090 at `k = 1`, where `k` is the chip core's energy per op over the 5090's measured 11 pJ: the number that decides the item. Verdict: GO as a class v4 candidate at N = 100,000 (`mx8+sh256x27`), subject to the 9070 XT row and the gates; NO-GO above 130,000 or with a block over 256 instructions. No card we own may lose more than 5 percent (the 2.0 rule): the M5 Max caps N at 130,000.
 ## 6 October 2026, Counter ASIC 3.0 item 6: the reserve families' step costs
@@ -2283,7 +2283,7 @@ Reading of the Mac rows. The run-to-run spread is under 4% on every row. The dot
 
 Reading of the 5090 rows. Every row is bit-exact, `mm8` included, so the m8n8k16 fragment layout of the CPU reference (PTX ISA 9.4 section 9.7.16.5.3) is the layout the hardware uses. The `alu` chain reads 7,941 G steps/s here against 8,754 through OpenCL event time on 5 October: a CUDA event pair around a 0.54 ms kernel carries about 0.05 ms of launch, which also compresses every ratio toward 1 (approximate: the ratios are the card's at the 2% level, not better). On this card every candidate costs more than the reference chain, unlike Apple: the 5090 runs the two-register add-xor-rotate chain at one IMAD and one funnel shift per step, and the three-register candidate chains pay their glue. Against the live `rotr` (1.32), the candidates read: `andn` 0.95x, `shl` 0.96x, `shr` 0.97x, `perm` 0.98x, `sel` 1.00x, `popc` 1.14x, `shfla` 1.16x (the same as the live xor shuffle, 1.49: the indexed shuffle costs NVIDIA nothing extra), `bfe` 1.17x, `clz` 1.23x. `bfe.u32` and the C form cost the same to the nanosecond (0.835 ms), so the compiler emits the same code for both and no single-instruction bit-field extract is in play on this architecture (not checked by cuobjdump; the equal times are the evidence). `dp4a` reads 1.16x (1.17x on 5 October). `mm8` is the most expensive row on NVIDIA too (2.43x the reference: one tensor-core mma per warp per dependent step, latency-bound), which supports its place at the end of the reserve on the honest-card side as well as on the chip side.
 
-**RX 9070 XT (PC 1, ae432dc7), OpenCL**: OWED. PC 1 is the founder's desk and not released today (the brief's rule); the OpenCL twin of the probe (`__builtin_amdgcn_*` paths for `v_bfe_u32`, `v_perm_b32`, `v_bcnt_u32_b32`, `v_cndmask_b32`, `ds_bpermute_b32`) is the next job on that card.
+**RX 9070 XT (PC 1, ae432dc7), OpenCL**: OWED. PC 1 is the project lead's desk and not released today (the brief's rule); the OpenCL twin of the probe (`__builtin_amdgcn_*` paths for `v_bfe_u32`, `v_perm_b32`, `v_bcnt_u32_b32`, `v_cndmask_b32`, `ds_bpermute_b32`) is the next job on that card.
 
 Consequences per tier, Mac rows (the hash is latency-bound by 128 dependent DRAM reads; a family at `W_new` = 4 points is about 4% of the 64 instructions, so these per-op costs bound a family's hash-rate cost and are not hash rates; the 5% rule of 1.13.2 is argued from them, not measured, until a family is live):
 
@@ -2348,7 +2348,7 @@ Cause: `ProvingState.paid_wei: u128` and serde_json `to_value` (1.0.151, `value/
 
 ## 5 October 2026 (night), aggregation cost on the RTX 5090: what a per-block aggregation spends and what each lever gives (proving engineer, agg-cost)
 
-The founder, 5 October 2026: "fix everything else in the numbers tonight". The number under test: the chained segment aggregation cost 9.6 to 9.7 s a block on PC 2's 5090 while the card mined (`chain-pc2-pv1c`, the entry above), 2.2 s on 4 October with the card to itself. Target: under 3 s a block, the miner's slowdown of the prover under 1.5x, the proof statement unchanged. Branch `agg-cost` (worktree `igneum-wt-agg-cost`, from `proving-v1` 219517f). Host changes (statement untouched, `elf/` untouched): the aggregation's stdin build timed apart from the prove call, the deferred-proof count and the SP1 knobs in the RESULT lines, `--mode chain --save-shards` (every shard's compressed proof written next to the results, so `--mode aggregate` re-runs the same proofs under other settings). Jobs: `agg-cost-pc2-1` (21:01:20Z to 21:25:11Z, `tools/proving-v1/pc2-agg-cost.ps1`, the package `igneum-prove-wsl2-aggcost.zip` fetched by `fetch-prove-aggcost` 20:55:39Z, built in WSL2 against the live target dir in 5 s, installed to `/opt/igneum-aggcost`, the live `/opt/igneum` untouched, `--mode id` the pinned pair) and `agg-cost-pc2-2` (21:34:00Z, the same script). The live prover was switched OFF for the runs (its sp1-gpu-server would otherwise be shared through `/tmp/sp1-cuda-0.sock` and carry its own environment; `gpu_server_before running=0`) and ON again at the end. Fixtures: four consecutive live blocks cut from PC 2's own node (86165..86168 at tip 86195, one empty shard each, every one MATCHES natively), the same four for every phase of job 1. App 0.3.9 on PC 2 throughout.
+the project lead, 5 October 2026: "fix everything else in the numbers tonight". The number under test: the chained segment aggregation cost 9.6 to 9.7 s a block on PC 2's 5090 while the card mined (`chain-pc2-pv1c`, the entry above), 2.2 s on 4 October with the card to itself. Target: under 3 s a block, the miner's slowdown of the prover under 1.5x, the proof statement unchanged. Branch `agg-cost` (worktree `igneum-wt-agg-cost`, from `proving-v1` 219517f). Host changes (statement untouched, `elf/` untouched): the aggregation's stdin build timed apart from the prove call, the deferred-proof count and the SP1 knobs in the RESULT lines, `--mode chain --save-shards` (every shard's compressed proof written next to the results, so `--mode aggregate` re-runs the same proofs under other settings). Jobs: `agg-cost-pc2-1` (21:01:20Z to 21:25:11Z, `tools/proving-v1/pc2-agg-cost.ps1`, the package `igneum-prove-wsl2-aggcost.zip` fetched by `fetch-prove-aggcost` 20:55:39Z, built in WSL2 against the live target dir in 5 s, installed to `/opt/igneum-aggcost`, the live `/opt/igneum` untouched, `--mode id` the pinned pair) and `agg-cost-pc2-2` (21:34:00Z, the same script). The live prover was switched OFF for the runs (its sp1-gpu-server would otherwise be shared through `/tmp/sp1-cuda-0.sock` and carry its own environment; `gpu_server_before running=0`) and ON again at the end. Fixtures: four consecutive live blocks cut from PC 2's own node (86165..86168 at tip 86195, one empty shard each, every one MATCHES natively), the same four for every phase of job 1. App 0.3.9 on PC 2 throughout.
 
 Known-finished case of the host changes before the GPU (this Mac, CPU, run lock, 20:41Z to 20:44Z): `--mode chain` over `fixtures/chain/block-81046.json` with `--save-shards` (shard 38.5 s, aggregate 43.4 s, the proof file written), then `--mode aggregate` over that saved shard proof with `SP1_WORKER_VERIFY_INTERMEDIATES=false` (46.6 s, the same statement `0x3dedb8ea...`), `--mode verify-segment` VERIFIED in 0.027 s; known-failed: a wrong statement NOT VERIFIED in 0.027 s. Unit tests: `cargo test --release -p igneum-prove-core -p igneum-prove-host`: core 8 passed, host 9 passed and 1 ignored (build lock, 20:53Z).
 
@@ -2521,25 +2521,6 @@ same once; a pool user nothing; a fleet operator gets a node that keeps its only
 every peer (13,354 lines of work it did not need in seven minutes). Owed: the fleet agent's synced-node reading; a receiver-side limit on
 certificates per index per minute as a second belt once the seed is fixed; the formatter's reflow of `finality.rs` (taken out of the commit).
 
-## 6 October 2026, Counter ASIC 3.0: the class v4 rehearsal
-
-A fleet of real GPU boxes ran a fleet-only chain from the devnet's genesis state and crossed a class v4 activation by miner signal, in the shape the live devnet will see. Numbers only; the per-box record is `docs/plans/counter-asic-3-gate/class-v4-20261006-rehearsal-PASS.json`.
-
-| Number | Value |
-|---|---|
-| Nodes on the chain | 16 (15 mining, 1 seed) plus 37 more miners joining after the flip; 1 box left on the old binary as the stale case |
-| Object | 17 fields, epochs of 600 DAA, the signal window 600 DAA, the threshold 9,500 bps, the floor at DAA 2,400; one consensus digest on every node |
-| First block | 18:41:10 UTC |
-| The flip | DAA 1,202, 19:00:5x UTC, by miner signal at epoch 2: 10,000 bps over the window, 599 of 599 blue blocks, the identical line on all 52 signalling nodes |
-| Program ids | one id per epoch on every box for epochs 2, 3 and 4, each equal to the CPU verifier's class v4 id for that seed and era and different from the class v3 id of the same seed; the pre-flip epoch's id is a class v3 id |
-| Blocks rejected for proof of work | 0 on every node over the whole run; every miner's CPU re-check mismatched 0 |
-| The old-binary box | refused at every connect by consensus digest (11 refusals, 22 mismatch lines), never a peer; given the full object it exits at parse |
-| The floor | crossed at DAA 2,400 with v4 already in force; the chain mined through it at about 1.6 blocks/s; one chain, no fork at the 19:34:54 UTC sweep (heights 2,502 to 2,509, blue 2,432 to 2,440) |
-| Verifier against the GPU on the first v4 pack | 1,024 of 1,024 nonces at target ff..ff found by the GPU worker and re-derived by the CPU verifier, one digest on both sides |
-| The stall | 90 s at the flip and then a stop: the shipped worker of the previous release refuses a generator-4 pack by design; the fleet resumed on the release tree's generator-4 worker 15 minutes later |
-
-What it means per tier: a class change on this chain is decided by the miners' own signal and lands at an epoch boundary with no human release; an old node cannot join the new chain and an old worker cannot mine the new class, so a home miner, a rig and a pool update the node and the worker together before the signal window closes, which the one-click app does in one update; a chip built for the old class mines nothing from the flip. The live cut carries the one lesson: the new object is published only once every node and every worker runs the release that reads it.
-
 ## 6 October 2026, 16:01Z: Ember run 6 on PC 1 (ember-tune-pc1-6, 0.3.13 + kit-6 = 564bdea, elevated, one click)
 
 The helper registered inside the run but on the scratch copy (fixed: task_exe, the `reregister` verb; see the plan's
@@ -2616,85 +2597,3 @@ USD 20 an hour on community pods, against a devnet of 1.16 GH/s.
 Consequence: the devnet's hash is rentable for the price of a dinner, so nothing on it is a security result; the counter-ASIC and
 finality work is tested there for correctness, not for cost. The cost argument only starts at the TH/s scale, where the rental
 market's supply (not its price) is the limit, and that number belongs in the litepaper with this caveat.
-
-## Block rate on Devnet 2, 6 October 2026 (branch gpu-fleet): 10 blocks per second against 1 on 42 rented cards
-
-Run A (10 blocks/s profile, star topology, 65 min): 4.87 DAG blocks/s, 1.09 blue blocks/s, 77.6 percent red, tips 250 to 660,
-max reorg 55, difficulty easing all hour (6,719 to 1,307), the exec follower at 0.05 blocks/s (lag 18,901 at the end). Run B
-(1 block/s, same boxes, 30 min): 1.41 blocks/s over the window with the join burst, 1.0 blocks/s and under 2 percent red from
-minute six, tips 1 to 3, difficulty settled in six minutes (453 to 482 M), the exec follower at 0.46 blocks/s. The network
-lane's read: run A's reds came from node throughput (61 to 345 ms CPU per accepted block at mergeset 8 to 200), not from the
-star. Per tier the blue rate decides the payout interval (1.09 against 1.19 blue/s: a 4070 at 10 TH/s waits about three days
-for a paying block either way), so the higher rate buys the solo miner nothing until the node processes a block in under 50 ms
-at mergeset 248. Recommendation (the lane's): 1 block/s for the testnet and the launch, 10 behind three measured gates.
-Full tables and sources: `docs/analysis/block-rate-devnet2.md`, rows in `~/Desktop/fleet/bps/{A,B}.jsonl`.
-
-## The rented fleet is the devnet's finality, 6 October 2026 (branch gpu-fleet)
-
-Measured at 21:57Z from the hub's last 2,000 blocks: the 38 wave pods held 77.8 percent of the voter weight (mean 2.05 percent
-a pod), the 14 standing boxes most of the rest, the hands and the hub the remainder; the last lock signed 93.5 percent of the
-active voters and 89.9 percent of the frozen table (53 of 84 voters on the first certificate). Earlier the same evening the
-fleet removed 13 miners' GPUs inside three minutes and finality paused for two hours five minutes (18:39:36Z to 20:44:44Z,
-42.7 percent of the table gone with earlier leavers; rule v3 holds a full window). From that came the 10 percent rule (never
-remove more than 10 percent of the live devnet's weight in an hour, `tools/fleet/lib/standing.py weight_check`) and the wave's
-wind-down by hourly slices (`tools/fleet/winddown.py`: slice 1 at 21:58Z took 12 pods and the 8x rig at 8.6 percent of weight).
-
-When the wave is gone the 14 standing boxes hold about 95 percent of the weight, so from then until public hash arrives the
-fleet alone is the devnet's finality: a home miner's lock lands only while the fleet is up. What holds it up: every standing
-box runs under `box-standing.sh`, which restarts a dead node within one of its 60-second passes (the hub's three deaths
-tonight: 63 s, 41 s and 56 s to the restart line), restarts the miner with the node, prunes the prover's exports and trims
-the node log, and runs the exec recovery recipe when the state layer reads zero; `lib/standing.py loop` re-rents a dead host
-in the same shape and reports a box behind its wanted binary.
-
-| Tier | What it means |
-|---|---|
-| Home miner | your lock depends on 14 rented cards staying up and mining; a finality pause is not your node's fault and nothing you can fix; the rule above is what keeps it from recurring on the fleet's side |
-| Rig | the same, and a rig that leaves is itself a weight removal: at 459 MH/s on tonight's devnet it is about 20 percent of the weight, over the hour's budget by itself |
-| Pool | a pool node is one voter carrying its members' whole weight; a pool restart is the largest single removal on the network and must be sliced like the fleet's |
-| The network | finality by miner weight is only as steady as the miners' uptime; until public hash dwarfs the fleet, the fleet's supervisor is a consensus component |
-
-## 7 October 2026, the first 16 GB card: an RTX 5060 Ti in a Thunderbolt enclosure on PC 2 (branch bench-5060ti)
-
-Machine: PC 2 (`1ccfe586`, Windows 11), an ASUS Dual GeForce RTX 5060 Ti (16 GB GDDR7, Blackwell sm_120, PnP `PCI\VEN_10DE&DEV_2D04&SUBSYS_8A111043`) in a Razer Core X V2 Thunderbolt enclosure ("USB4 Router (2.0), Razer - Core X V2", bus `0B:00.0`), beside the RTX 5090 on its own supply; NVIDIA driver 610.47 (WDDM 32.0.16.1047, the 5090's driver, nothing installed for the new card); the installed app 0.3.19 and its own `igneum-worker-cuda.exe` (NVRTC 12.8). Jobs `fetch-5060ti-packs-20261007` (the kit: `tools/bench-5060ti/make-kit.sh`, the class v4 pack at sub-version 1 and the v3 control, sha256 `fd8393ed...`, 105,892 bytes) and `run-5060ti-bench-20261007-b` (`tools/bench-5060ti/pc2-5060ti-bench.ps1`, 14:44:19Z, ran 14:45:05 to 14:58:11Z, exit 0; the 5060 Ti alone through the runner's `--cards-off`, the 5090 mining throughout; run `-a` died in 1 s on an argument-binding fault in the nvidia-smi query and is void). PC 2 lost power twice that day, so the job WRITES NO POWER LIMIT: it reads `power.limit` against `power.default_limit` (180 W = 180 W, range 150 to 198 W) and the row says `limit_is_stock=yes`. Read back with `node tools/jobs.mjs run-5060ti-bench-20261007-b`.
-
-**Detection** (the app's first poll after the restart, run `win-1ccfe586-20261007-143611`, 14:36:16Z): `GPUs: NVIDIA GeForce RTX 5090 (CUDA); NVIDIA GeForce RTX 5060 Ti (CUDA); AMD Radeon(TM) Graphics (OpenCL, gfx1036)` and `cards: NVIDIA GeForce RTX 5090 [discrete, off] | NVIDIA GeForce RTX 5060 Ti [discrete, off] | ...`; the app started a miner on it by itself (`nvidia-1ccfe586-2`, `--device 1`, 8 identities, the default). The kind reads `discrete`, not `external`: the app does not know it is an eGPU. nvidia-smi in the job: index 1, 16,311 MiB, PCIe link gen 4 x4 current against gen 4 x16 maximum (the Thunderbolt link: a quarter of the slot's lanes), 43 C idle. The freeze lane's cause class for the 15:10 UK hang on the first boot with the card: not the card (no TDR, no Thunderbolt or PCIe link event; Kernel-Power 41 + 6008, no bugcheck, the power shape again).
-
-**G1 and the window** (the installed CUDA worker, `--bench --batch-log2 24 --block-warps 1`, the card alone, `CUDA_VISIBLE_DEVICES` on its UUID so every row names the device; nvidia-smi every 2 s on the card, the loaded samples at utilisation 90 percent and over):
-
-| Pack | Dispatches of 2^24 | Self-test | Fingerprint 2^24 at base 0 | MH/s |
-|---|---|---|---|---|
-| mx8-devnet-epoch0 (the class v3 control) | 5 | PASS | 90f794dd556f7a3b (= the control everywhere) | 30.895 |
-| v4-devnet-epoch0 (class v4, sub-version 1, program id 1a4230699a6b9c60) | 5 | PASS | 867dbc45cfb36b4d (= Metal, Apple OpenCL, the RTX 5090) | 30.879 |
-| v4-devnet-epoch0, the 10-minute window at the stock limit | 1,105 (602 s) | PASS | 867dbc45cfb36b4d | 30.882 |
-
-| Row | Value |
-|---|---|
-| NVIDIA RTX 5060 Ti 16 GB, class v4, CUDA (NVRTC), driver 610.47, PCIe 4.0 x4 through the enclosure | 30.9 MH/s over 10 minutes on the card alone |
-| Watts at the stock limit (180 W default, unchanged) | 114.8 W mean, 115 W p50 over the window; 0.269 MH/W; SM 2,753 MHz, memory 13,801 MHz, 60 C maximum |
-| The class v4 shadow against the control | 0.1 percent (the 5090 paid 0.2, the 9070 XT 3, the B580 0.1) |
-| The efficient point | OWED to the app's Ember Tune: nothing set by the job; PC 2's Power Helper refused every request since the restart ("the helper did not run sequence 0 within 15 s", 14:39Z), so no ladder ran on either card |
-| Prove beside the miner (16 GB tier) | BLOCKED, not measured: the shipped WSL2 host (sha `71bc2438...`) carries no `IGNEUM_CUDA_DEVICE` selector, so aimed at anything it proves on CUDA device 0 (the 5090) through the app's own socket `/tmp/sp1-cuda-0.sock`; the selector lives in the prover-floor host (`proof_system.rs`, branch prover-floor) and is the owed cut. The job's inventory: the floor server IS on PC 2 (`/opt/igneum-floor/bin/sp1-gpu-server`, 6.8.1 build `e911facb...`, 166,665,880 bytes) beside the stock one (`~/.sp1/bin`, `c2642ad1...`), WSL sees the card as CUDA device 1 |
-| Card-picker entry (`site/yourcard.js`) | `['NVIDIA RTX 5060 Ti', 30.9]`, added; the public table row in `site/miner-bench.json` |
-
-Against the 5090 on the same PC (122 MH/s at 308 W, 0.396 MH/W): 25.3 percent of its hash at 37 percent of its draw, 68 percent of its hash per watt. The dependent-read ceiling was not probed (the memprobe step is not in this job); at 128 loads a hash 30.9 MH/s is 3.95 G dependent reads a second, between the 9070 XT (2.4 to 2.7 G) and the 5090 (16 to 18 G).
-
-Consequences per tier (the rule of 5 October 2026): a 5060 Ti owner (16 GB, Windows) mines at 30.9 MH/s and 115 W from the box with nothing to set: about 5,100 blocks a day at the 522 MH/s the devnet showed at 14:44Z (one every 17 s, approximate: the network rate moves), about a quarter of a 5090 owner's 20,200, for 2.76 kWh a day (£0.79 at 28.5 p against the 5090's £2.11); through a Thunderbolt enclosure the x4 link costs nothing measurable (the hash is bound by the card's own memory latency, not the link; the 5090's PCIe-slot rows are the comparison), so a laptop with a Thunderbolt 4 port and this enclosure is a 31 MH/s miner. The 8 GB 5060 Ti: the same hash is the expectation (the 1 GiB dataset fits), a line owed. Proving on the 16 GB tier: the fleet's 4060 Ti 16 GB row (9.0 GB peak beside the miner on the patched server) says this card would mine and prove with about 7 GB spare, approximate until the host with the device selector ships; today the app's prover default leaves it off ("a full shard needs a 24 GB card") and the measured read is owed to the prover-floor host cut. Linux and HiveOS take the same CUDA worker (owed a line). What the lane does next: the prover-floor host's selector into the shipped WSL2 bundle, then the prove-beside read on this card; the Power Helper fault on PC 2 to the Ember lane (no efficient point on any PC 2 card until it answers).
-
-Found on the way: inside a PowerShell `@( ... )` the comma binds before `+`, so `'--query-gpu=' + $f, '--format=csv'` is one argument (run a, void in 1 s; the query string is built first now); a bare string inside a function that also returns a value is swallowed into the caller's variable (the sampler line; `[Console]::Out.WriteLine` now); the app's `kind` for a Thunderbolt card reads `discrete` (a word for the Cards page to earn: `external`, which the state already names).
-## O-1.14: the CPU verifier on a 2019-class core (attack pass F6, 7 October 2026, 09:49 UK)
-
-Rented Vast instance 54613164, Intel Core i7-9700K at 4,170 MHz as read, one core, the box-built Linux `igneum-pow`
-(sha256 6d286783...), `bench --seed igneum-genesis --day 2026-10-03 --warps 50`. Ms per warp, cold max / average of 50:
-v2 1.582 / 1.280; mx8 5.394 / 5.267; mx8+sh256x27 (class v4) 6.334 / 6.006; dr368 5.540 / 5.426; dr736 10.290 / 10.042
-(fails the 10 ms gate, the known-fail). Cache fill 276 ms. Log `docs/analysis/attack-pass/o114-i7-9700K-2026-10-07.log`;
-record `docs/analysis/attack-pass-2026-10.md` row F6. Class v4 passes a real 2019-class core with 3.7 ms to spare; the
-half-core proxy (8.23 ms) stays the standing pessimistic rule for the ladder's ceiling.
-
-## F6: the verifier's worst case over 10^5 class v4 programs (attack pass, 7 October 2026, 13:5x UTC)
-
-igneum-build-1, cores 40 (one-core proxy) and 88 (the half-core proxy, both SMT siblings busy) under the per-core lease,
-core 40 at a median 3,799.9 MHz. 100,000 programs ranked by exact op counts; 50,000 timed cold on core 40 (min / median /
-p99 / max 4.610 / 4.948 / 5.606 / 6.194 ms per warp); the worst 200 re-timed at 10 cold reps on both proxies and the worst
-1,000 on the half-core at 2 reps, the worst 10 at 20: worst half-core cold max 8.708 ms (`attack-f6/87142`), then 8.629
-(`attack-f6/88521`), 8.414 (`attack-f6/15781`); the genesis program 8.624. Gate 10 ms: PASS by 1.29 ms. Record
-`docs/analysis/attack-pass/f6-verifier.md`; logs `/srv/builds/igneum-wt-attack/target-attack-f6/phase2b.log`, `phase2c.log`.

docs/benchmarks/night/2026-10-06-dryrun.md

@@ -0,0 +1,22 @@
+# Night battery 2026-10-06 (dry run, subset)
+
+igneum-build-1, 3 min 54 s wall, one build slot (CARGO_BUILD_JOBS 45), repo master 3b2c840, fork release-0.3.15-node 713ef876. 10 pass, 1 FAIL, 1 skip. Logs on the box: `/srv/builds/_night/logs/20261006T194555Z`. Written by `infra/build-server/night/night-battery.sh`.
+
+| Stage | What | Result | Time | Detail |
+|---|---|---|---|---|
+| checkout | repo master 3b2c840, fork release-0.3.15-node 713ef876 | pass | 2 s | /srv/builds/_night/igneum; jobs 45; subset 1 |
+| suite | igneum-pow | pass | 51 s | 99 passed, 0 failed |
+| suite | fork/kaspa-pow | pass | 1 min 04 s | 7 passed, 0 failed |
+| suite | fork/igneum-miner | pass | 49 s | 18 passed, 0 failed |
+| fuzz | igneum-pow mixer+scratch x200 | pass | 11 s | fuzz: 200 mx8 programs, 800 units on the CPU, 200 units in the top 256 nonces;fuzz: 200 programs, 800 units on the CPU, 200 units in the top 256 nonces, classes [("scr2k128", 32), ("scr2k32", 29), ("s |
+| sim | finality_sim.py | pass | 3 s | 249 table lines |
+| sim | finality_v2.py --quick | pass | 41 s | 117 table lines |
+| sim | difficulty/sim.py --quick | pass | 5 s | 8 table lines |
+| harness | all | skip | 0 s | subset |
+| clippy | igneum-pow | pass | 3 s | 28 warnings |
+| audit | igneum-pow | pass | 3 s | 0 vulnerabilities, 0 warnings |
+| audit | vendor/igneum-node | **FAIL** | 2 s | rc 1: 22 vulnerabilities (crossbeam-epoch,0.9.18,h2,0.4.6,quinn-proto,0.11.14,ruint,1.17.2,rustls,0.23.39,tracing-subscriber,0.2.25,async-std,1.13), 17 warnings |
+
+## New since last night
+
+No earlier report to compare with: this is the first night.

docs/benchmarks/night/2026-10-07.md

@@ -0,0 +1,105 @@
+# Night battery 2026-10-07
+
+igneum-build-1, 72 min 28 s wall, one build slot (CARGO_BUILD_JOBS 90), repo master 83977817, fork release-0.3.17-node b49c58c1. 76 pass, 19 FAIL, 0 skip. Logs on the box: `/srv/builds/_night/logs/20261007T010001Z`. Written by `infra/build-server/night/night-battery.sh`.
+
+| Stage | What | Result | Time | Detail |
+|---|---|---|---|---|
+| checkout | repo master 83977817, fork release-0.3.17-node b49c58c1 | pass | 4 s | /srv/builds/_night/igneum; jobs 90; subset 0 |
+| suite | igneum-pow | pass | 59 s | 99 passed, 0 failed |
+| suite | igneum-census | pass | 12 s | 0 passed, 0 failed |
+| suite | pool | **FAIL** | 2 min 39 s | did not compile: error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `Epoch` in the current sc |
+| suite | proto-vdf | **FAIL** | 3 s | did not compile: error: failed to run custom build command for `gmp-mpfr-sys v1.5.3` |
+| suite | app/igneum-app | pass | 27 s | 189 passed, 0 failed |
+| suite | fork/igneum-evm-types | pass | 51 s | 3 passed, 0 failed |
+| suite | fork/igneum-exec | pass | 4 min 59 s | 24 passed, 0 failed |
+| suite | fork/igneum-harness-sim | pass | 1 min 35 s | 0 passed, 0 failed |
+| suite | fork/igneum-miner | **FAIL** | 43 s | did not compile: error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `Epoch` in the current sc |
+| suite | fork/igneum-p2p-probe | pass | 50 s | 0 passed, 0 failed |
+| suite | fork/kaspa-addresses | pass | 33 s | 3 passed, 0 failed |
+| suite | fork/kaspa-addressmanager | pass | 49 s | 1 passed, 0 failed |
+| suite | fork/kaspa-alloc | pass | 8 s | 0 passed, 0 failed |
+| suite | fork/kaspa-bip32 | pass | 29 s | 6 passed, 0 failed |
+| suite | fork/kaspa-build-info | pass | 6 s | 1 passed, 0 failed |
+| suite | fork/kaspa-cli | pass | 3 min 35 s | 0 passed, 0 failed |
+| suite | fork/kaspa-connectionmanager | pass | 36 s | 0 passed, 0 failed |
+| suite | fork/kaspa-consensus | pass | 26 s | 108 passed, 0 failed |
+| suite | fork/kaspa-consensus-client | pass | 31 s | 0 passed, 0 failed |
+| suite | fork/kaspa-consensus-core | **FAIL** | 20 s | 128 passed, 1 failed; failed: config::params::tests::fast_time_60x_file_is_the_devnet_at_60x  |
+| suite | fork/kaspa-consensus-notify | pass | 24 s | 0 passed, 0 failed |
+| suite | fork/kaspa-consensusmanager | pass | 24 s | 0 passed, 0 failed |
+| suite | fork/kaspa-core | pass | 19 s | 0 passed, 0 failed |
+| suite | fork/kaspa-daemon | pass | 1 min 40 s | 0 passed, 0 failed |
+| suite | fork/kaspa-database | pass | 31 s | 22 passed, 0 failed |
+| suite | fork/kaspa-grpc-client | pass | 41 s | 2 passed, 0 failed |
+| suite | fork/kaspa-grpc-core | pass | 14 s | 9 passed, 0 failed |
+| suite | fork/kaspa-grpc-server | **FAIL** | 1 min 10 s | did not compile: error[E0046]: not all trait items implemented, missing: `get_finality_weights_call`, `get_finality_checkpoints_call`, `s |
+| suite | fork/kaspa-grpc-simple-client-example | pass | 4 s | 0 passed, 0 failed |
+| suite | fork/kaspa-hashes | pass | 12 s | 5 passed, 0 failed |
+| suite | fork/kaspa-index-core | pass | 5 s | 8 passed, 0 failed |
+| suite | fork/kaspa-index-processor | pass | 1 min 02 s | 2 passed, 0 failed |
+| suite | fork/kaspa-math | pass | 11 s | 7 passed, 0 failed |
+| suite | fork/kaspa-merkle | pass | 13 s | 13 passed, 0 failed |
+| suite | fork/kaspa-metrics-core | pass | 32 s | 0 passed, 0 failed |
+| suite | fork/kaspa-mining | pass | 33 s | 52 passed, 0 failed |
+| suite | fork/kaspa-mining-errors | pass | 4 s | 0 passed, 0 failed |
+| suite | fork/kaspa-muhash | pass | 7 s | 18 passed, 0 failed |
+| suite | fork/kaspa-notify | pass | 12 s | 20 passed, 0 failed |
+| suite | fork/kaspa-p2p-flows | pass | 46 s | 34 passed, 0 failed |
+| suite | fork/kaspa-p2p-lib | pass | 30 s | 19 passed, 0 failed |
+| suite | fork/kaspa-p2p-mining | pass | 26 s | 5 passed, 0 failed |
+| suite | fork/kaspa-perf-monitor | pass | 19 s | 1 passed, 0 failed |
+| suite | fork/kaspa-pow | pass | 20 s | 7 passed, 0 failed |
+| suite | fork/kaspa-rocknroll | **FAIL** | 1 min 55 s | did not compile: error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `Epoch` in the current sc |
+| suite | fork/kaspa-rpc-core | pass | 11 s | 131 passed, 0 failed |
+| suite | fork/kaspa-rpc-macros | pass | 1 s | 0 passed, 0 failed |
+| suite | fork/kaspa-rpc-service | pass | 38 s | 0 passed, 0 failed |
+| suite | fork/kaspa-seq-commit | pass | 10 s | 41 passed, 0 failed |
+| suite | fork/kaspa-smt | pass | 11 s | 119 passed, 0 failed |
+| suite | fork/kaspa-smt-store | pass | 20 s | 95 passed, 0 failed |
+| suite | fork/kaspa-stratum-bridge | **FAIL** | 56 s | did not compile: error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `Epoch` in the current sc |
+| suite | fork/kaspa-system-info | pass | 15 s | 0 passed, 0 failed |
+| suite | fork/kaspa-testing-integration | **FAIL** | 2 min 51 s | did not compile: error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `Epoch` in the current sc |
+| suite | fork/kaspa-txscript | pass | 1 min 08 s | 156 passed, 0 failed |
+| suite | fork/kaspa-txscript-errors | pass | 13 s | 0 passed, 0 failed |
+| suite | fork/kaspa-txscript-zk-sdk | pass | 2 min 12 s | 17 passed, 0 failed |
+| suite | fork/kaspa-utils | pass | 31 s | 17 passed, 0 failed |
+| suite | fork/kaspa-utils-tower | pass | 14 s | 0 passed, 0 failed |
+| suite | fork/kaspa-utxoindex | pass | 40 s | 1 passed, 0 failed |
+| suite | fork/kaspa-wallet | pass | 1 min 13 s | 0 passed, 0 failed |
+| suite | fork/kaspa-wallet-core | **FAIL** | 1 min 33 s | did not compile: error[E0046]: not all trait items implemented, missing: `get_finality_weights_call`, `get_finality_checkpoints_call`, `s |
+| suite | fork/kaspa-wallet-keys | **FAIL** | 43 s | 2 passed, 7 failed; failed: derivation::gen0::hd::tests::generate_addresses_by_range derivation::gen0::hd::tests::generate_kaspatest_addresses derivation::gen0::hd::tests::hd_wallet_gen0  |
+| suite | fork/kaspa-wallet-macros | pass | 1 s | 0 passed, 0 failed |
+| suite | fork/kaspa-wallet-pskt | pass | 38 s | 5 passed, 0 failed |
+| suite | fork/kaspa-wrpc-client | pass | 52 s | 24 passed, 0 failed |
+| suite | fork/kaspa-wrpc-example-subscriber | pass | 5 s | 0 passed, 0 failed |
+| suite | fork/kaspa-wrpc-proxy | pass | 1 min 30 s | 0 passed, 0 failed |
+| suite | fork/kaspa-wrpc-server | pass | 7 s | 1 passed, 0 failed |
+| suite | fork/kaspa-wrpc-simple-client-example | pass | 4 s | 0 passed, 0 failed |
+| suite | fork/kaspa-wrpc-vcc-v2 | pass | 5 s | 0 passed, 0 failed |
+| suite | fork/kaspad | **FAIL** | 20 s | did not compile: error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `Epoch` in the current sc |
+| suite | fork/rocks-probe | pass | 4 s | 0 passed, 0 failed |
+| suite | fork/rothschild | pass | 1 min 00 s | 0 passed, 0 failed |
+| suite | fork/simpa | **FAIL** | 10 s | did not compile: error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `Epoch` in the current sc |
+| fuzz | igneum-pow mixer+scratch x2000 | pass | 2 min 59 s | fuzz: 2000 mx8 programs, 8000 units on the CPU, 2000 units in the top 256 nonces, seeds 0..2000;fuzz: 2000 programs, 8000 units on the CPU, 2000 units in the top 256 nonces, classes [("scr2k128", 330) |
+| sim | finality_sim.py | pass | 3 s | 249 table lines |
+| sim | finality_v2.py  | pass | 7 min 03 s | 177 table lines |
+| sim | difficulty/sim.py  | pass | 54 s | 72 table lines |
+| harness | build | **FAIL** | 5 min 02 s | error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `Epoch` in the current scope |
+| clippy | igneum-pow | pass | 1 s | 28 warnings |
+| clippy | igneum-census | pass | 1 s | 11 warnings |
+| clippy | pool | **FAIL** | 1 min 07 s | rc 101, 3 errors, 3 warnings: error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `Epoch` in the current sc |
+| clippy | proto-vdf | **FAIL** | 2 s | rc 101, 1 errors, 1 warnings: error: failed to run custom build command for `gmp-mpfr-sys v1.5.3` |
+| clippy | app/igneum-app | pass | 10 s | 81 warnings |
+| clippy | proving/igneum-prove | **FAIL** | 0 s | rc 101, 1 errors, 0 warnings: error: failed to load manifest for workspace member `/srv/builds/_night/igneum/proving/igneum-prove/core` |
+| clippy | vendor/igneum-node | **FAIL** | 2 min 11 s | rc 101, 4 errors, 75 warnings: error[E0599]: no associated function or constant named `chain_program_shadow` found for struct `igneum_pow::Epoch` in th |
+| audit | igneum-pow | pass | 0 s | 0 vulnerabilities, 0 warnings |
+| audit | proving/igneum-prove | pass | 2 s | 9 vulnerabilities, 10 warnings |
+| audit | app/igneum-app | pass | 1 s | 0 vulnerabilities, 0 warnings |
+| audit | igneum-census | pass | 0 s | 0 vulnerabilities, 0 warnings |
+| audit | proto-vdf | pass | 2 s | 0 vulnerabilities, 0 warnings |
+| audit | pool | **FAIL** | 2 s | rc 1: 15 vulnerabilities (crossbeam-epoch,0.9.18,h2,0.4.6,ruint,1.17.2,rustls,0.23.39,async-std,1.13.0,atty,0.2.14,derivative,2.2.0,instant,0.1.13), 12 warnings |
+| audit | vendor/igneum-node | **FAIL** | 2 s | rc 1: 27 vulnerabilities (crossbeam-epoch,0.9.18,h2,0.4.6,quinn-proto,0.11.14,ruint,1.17.2,rustls,0.23.39,tracing-subscriber,0.2.25,ansi_term,0.12), 22 warnings |
+
+## New since last night
+
+No earlier report to compare with: this is the first night.

docs/benchmarks/repro.md

@@ -204,7 +204,7 @@ key of 8.1 is the operator's own step, on the file.
 | PC 2's 5090 rows | the card-off step could not confirm a stopped worker (`api/state` answered `{}`), and the numbers are half the card's | the morning's 5090-only run on PC 2 with the compute-apps confirmation; until then the rows are "beside the live miner" |
 | PC 2's result files | `repro.ps1`'s close threw `System.OutOfMemoryException` in ConvertTo-Json and gave Set-Content an empty path: PowerShell variable names are case-insensitive, the result table `$Cpu` held `$cpu` (its own name string) and so contained itself, and the markdown lines `$md` wiped the markdown path `$Md`. Fixed (distinct names; `bench/jobs/ps-case-check.sh` fails CI on any case-only pair, shown to fire on a bad file); the RESULT lines in the intake and the three transcript logs are the record | the morning's run writes the files |
 | The prover on PC 2 | the first script read the prover's state from `api/state` too, saw nothing, and left the live prover off from 00:49 to the restore job (run-prover-on-pc2-20261006); the script now reads settings.json and restores unconditionally | done tonight; the rule in the job |
-| The reward | the amount and payer are `docs/plans/funding.md`, not funded; the terms are quoted unchanged | the founder's decision |
+| The reward | the amount and payer are `docs/plans/funding.md`, not funded; the terms are quoted unchanged | the project lead's decision |
 
 ## 8. The vendor-share metric (Counter ASIC 3.0 item 7)
 
@@ -221,7 +221,7 @@ Today's devnet, read-only from the live tables (dry mode, 07:36 UTC, 6 October 2
 
 | Vendor | fleet-reported MH/s (workers) | chain-attributed share of blue blocks (10 min) | chain-attributed MH/s at the 135.8 MH/s estimate | Note |
 |---|---|---|---|---|
-| NVIDIA | 120.61 (1: PC 2's RTX 5090, with the prover on the card) | 0.986 (552 of 560) | 133.86 | PC 1's RTX 5090 was off the network at the reading (the founder's desk) |
+| NVIDIA | 120.61 (1: PC 2's RTX 5090, with the prover on the card) | 0.986 (552 of 560) | 133.86 | PC 1's RTX 5090 was off the network at the reading (the project lead's desk) |
 | AMD | 0 (0) | 0 | 0 | the RX 9070 XT is on PC 1, off at the reading |
 | Apple | 0 (0) | 0 | 0 | the M5 Max is paused for measurements |
 | Intel | 1.69 (1: the Windows laptop's UHD Graphics) | 0.014 (8 of 560) | 1.94 | the first outside machine, which carries the intake key |

docs/bugs.md

@@ -7,13 +7,13 @@ shard run reported as exit 0, 7a7e873).
 | Date | Symptom | Cause | Fix | Proven by |
 |---|---|---|---|---|
 | 4 Oct 2026 | Every `ci` run on master red since 67bf226 (eleven pushes), unnoticed | `sim/difficulty/records/testnet-v2-2026-10-04.schedule.log` carried a home path; `.log` was outside the identity scrub's extension list in `tools/ci/identity-check.sh` (and in the mirror's `tools/sync.sh`) | 2996cca: `.log` scrubbed like the other text files; the record rewritten with `~`; the same list in igneum-public `tools/sync.sh` (local commit e18256d, not pushed) | `bash tools/ci/identity-check.sh` 0 hits locally; run 37226816xxx on master green |
-| 5 Oct 2026 | PC 1 (Windows 11 Pro 26200, default terminal Windows Terminal 1.24): "Windows Command Processor" windows whenever a remote job runs (the founder) | measured, not guessed: `tools/windows/console-watch.ps1` (job run-20261005-182528) started every candidate child from the app's job runner, whose console is headless (`conhost.exe 0x4`, hwnd 0), with a user32 EnumWindows sampler every 30 ms: powershell, cmd, query, curl, nvidia-smi, wsl --status, a distro, interop cmd and powershell, `powershell -WindowStyle Hidden`, `Start-Process -WindowStyle Hidden`: 0 windows each; `Start-Process cmd` in a new console: a Terminal window and a cmd PseudoConsoleWindow (the known-failed case fires). The 25-minute background watcher (console-watch-bg.ps1, run-20261005-184330, 18:44 to 19:09 UTC, every 200 ms) across an app restart, a build job, two run jobs, two collect jobs and the sweep helper's elevated launch at 19:04:43: 0 console or Terminal windows, 69 conhost starts (every one `conhost.exe 0x4`, headless, under curl, wsl, wslhost, powershell), 1 cmd.exe (under wslhost, WSL interop, no window). The one road that creates a console of its own is the elevated launch (`Start-Process -Verb RunAs`, the AppInfo service: the power cap, the sweep helper, the clock sync, an elevated job); it carried `-WindowStyle Hidden` in four copies, and "Windows Command Processor" is also the name on the UAC prompt the engine raises for cmd.exe (the sweep helper prompted at 17:00, 17:30 and 18:12 UTC, the power cap at every start; the elevated watcher's own prompt, run-20261005-184610, timed out unanswered at 122 s) | `platform::elevated_ps_line` + `elevated_command`: one builder for every elevated launch, hidden by construction, exit 251 when the prompt is refused; the elevated job wrapper reports its own console (`elevated console: hwnd N visible False`) on every elevated job; `tools/ci/windows-spawn-check.mjs` fails CI on a Command::new without the quiet flag, a creation_flags other than CREATE_NO_WINDOW, a Start-Process without -WindowStyle Hidden/-NoNewWindow, or a host.cpp spawn without CREATE_NO_WINDOW / SW_HIDE | the watcher's known-failed case (2 windows) and known-finished case (0); the CI check's self-test (9 cases) and the tree (0 hits); the igneum-app test suite on PC 1 |
+| 5 Oct 2026 | PC 1 (Windows 11 Pro 26200, default terminal Windows Terminal 1.24): "Windows Command Processor" windows whenever a remote job runs (the project lead) | measured, not guessed: `tools/windows/console-watch.ps1` (job run-20261005-182528) started every candidate child from the app's job runner, whose console is headless (`conhost.exe 0x4`, hwnd 0), with a user32 EnumWindows sampler every 30 ms: powershell, cmd, query, curl, nvidia-smi, wsl --status, a distro, interop cmd and powershell, `powershell -WindowStyle Hidden`, `Start-Process -WindowStyle Hidden`: 0 windows each; `Start-Process cmd` in a new console: a Terminal window and a cmd PseudoConsoleWindow (the known-failed case fires). The 25-minute background watcher (console-watch-bg.ps1, run-20261005-184330, 18:44 to 19:09 UTC, every 200 ms) across an app restart, a build job, two run jobs, two collect jobs and the sweep helper's elevated launch at 19:04:43: 0 console or Terminal windows, 69 conhost starts (every one `conhost.exe 0x4`, headless, under curl, wsl, wslhost, powershell), 1 cmd.exe (under wslhost, WSL interop, no window). The one road that creates a console of its own is the elevated launch (`Start-Process -Verb RunAs`, the AppInfo service: the power cap, the sweep helper, the clock sync, an elevated job); it carried `-WindowStyle Hidden` in four copies, and "Windows Command Processor" is also the name on the UAC prompt the engine raises for cmd.exe (the sweep helper prompted at 17:00, 17:30 and 18:12 UTC, the power cap at every start; the elevated watcher's own prompt, run-20261005-184610, timed out unanswered at 122 s) | `platform::elevated_ps_line` + `elevated_command`: one builder for every elevated launch, hidden by construction, exit 251 when the prompt is refused; the elevated job wrapper reports its own console (`elevated console: hwnd N visible False`) on every elevated job; `tools/ci/windows-spawn-check.mjs` fails CI on a Command::new without the quiet flag, a creation_flags other than CREATE_NO_WINDOW, a Start-Process without -WindowStyle Hidden/-NoNewWindow, or a host.cpp spawn without CREATE_NO_WINDOW / SW_HIDE | the watcher's known-failed case (2 windows) and known-finished case (0); the CI check's self-test (9 cases) and the tree (0 hits); the igneum-app test suite on PC 1 |
 | 4 Oct 2026 | `collect-pc1-board3` printed PowerShell parse errors (`.Name`, `.AdapterRAM`) | the publishing shell expanded `$_` inside double quotes to nothing before the command reached the jobs file; nothing to do with Format-List or Out-String (board2 and board4 printed their values) | publish-jobs.sh refuses a collect command that pipes into a script block without `$_` or `$PSItem` | the eaten form refused with the reason, the single-quoted form published to a test folder |
 | 4 Oct 2026 | the same job reported `done (exit 0)` over `command exit Some(1)` | `run_collect` in `app/igneum-app/src/jobrun.rs` builds `Done` from the upload count only; the command's exit code is logged and dropped | branch `bugfix-collect-exit`, 35ccdc8 rebased on c257444 (app engine; merge by the main session) | `cargo test --bin igneum-app`: all 28 tests pass on the rebased branch; the new one covers the board3 shape (`Some(1)` is failed exit 1), `Some(0)` done, the cap as timeout, failed uploads still failing |
 | 4 Oct 2026 | `publish-jobs.sh --deploy` said "not reachable, differs from the local one, or does not verify yet" after a deploy that had succeeded | one check the instant the CLI returned, while the edge still served the previous file; the deploy's own exit status was hidden by `\|\| true` | `verify_live`: up to `--tries` (12) checks 5 s apart, each failure names its condition; `publish-jobs.sh verify` re-checks on its own; a failed deploy stops before the check | finished: `verify --tries 2` against the live file (try 1 of 2); failed: a local server with an older file ("differs", both publish stamps named) and a closed port ("is not reachable") |
 | 4 Oct 2026 | console Machines: PC 37ba0461 showed 0.0 MH/s and 0 accepted while its log held an accepted block at 1 MH/s | `parseLabel` in the console API knew nvidia, amd, mac, metal and opencl; the OpenCL fallback on an iGPU is labelled `other-<id8>-n` and the card was dropped | parsers moved to `relay/lib/parse.mjs`, vendors `other` and `intel` added, `node --test relay/test/parse.test.mjs` in CI | the test; the live console after the deploy shows the card |
 | 4 Oct 2026 | console Machines: a card said "117.2 MH/s now" while its "status" column said 4 m ago (PC 2 during shard run 3: the prover held the GPU and the worker's STATUS line stopped) | the card's hash came from the last STATUS line in the tail with no age check; the machine total summed it | `markStale`: a card whose STATUS line is older than 120 s is `stale`, shown as "last N MH/s" with a red "stale" mark, and left out of the machine total (API, page and `tools/console.mjs`) | the test (58 s fresh, 240 s stale, none stale); the live console after the deploy |
-| 4 Oct 2026 | `vercel env add` from `site/` fails with "Could not retrieve Project Settings" | `site/.vercel/project.json` links the other business's team's `igneum` project; the live site (igneum.network, igneum.com, the GitHub integration) is the `igneum` team's project of the same name, which the igneum login reads and the the other business link does not | documented in `packaging/README-ship.md` (link, env ls, env add, deploy); no env set | `env ls` from a scratch link to the igneum-team project lists the two names; a branch push produced `igneum-git-<branch>` |
+| 4 Oct 2026 | `vercel env add` from `site/` fails with "Could not retrieve Project Settings" | `site/.vercel/project.json` links the [other-business] team's `igneum` project; the live site (igneum.network, igneum.com, the GitHub integration) is the `igneum` team's project of the same name, which the igneum login reads and the [other-business] link does not | documented in `packaging/README-ship.md` (link, env ls, env add, deploy); no env set | `env ls` from a scratch link to the igneum-team project lists the two names; a branch push produced `igneum-git-<branch>` |
 | 4 Oct 2026 | `tools/jobs.mjs` and `publish-jobs.sh` print the downloads-folder token inside URLs on every run (X24 pattern) | the tokened base URL is echoed as is | the token masked as `<token>` in every printed URL | by eye, this log's own transcript |
 | 4 Oct 2026 | round 4 X28 and X24, the parts under an hour: `===` on secrets, no HSTS on the relay, the relay token printed by `tools/relay.mjs list` and `watch` | as the review said | c1f59fb: `sameSecret` (timingSafeEqual, `relay/lib/auth.mjs`, test in CI), `Strict-Transport-Security` in `relay/vercel.json`, `/r/<token>` printed (only `url` prints the real one) | relay deployed: key auth 200, wrong key and token 401, token path 200, HSTS header present |
 | 4 Oct 2026 | the live feed showed two "checkpoint N locked" events 30 ms apart (1122, 1172, 1230, 1258, 1259 in 400 observer lines), and 708 of 764 locked checkpoints in `live_checkpoints` had `votes_seen` 0 | `finalityTick` read the state, awaited two SQL writes, then set the map; the `finalityLockNotification` handler checked the same map synchronously in between and recorded the lock too; a lock claimed by the notification was never upserted again, so the poll's `votes_seen` never landed | 7de1bdb: the poll claims the state before its first await; a `checkpointDetailed` set makes the poll fill `votes_seen` once | before: 5 duplicates in 400 lines; after the 19:50:33 UTC restart: 21 locks (1297 to 1317), 0 duplicates, 0 write failures; 1300 was notification-first and the poll filled it to 17 votes. The zeros that remain are the node's own count (`finality.rs:770`, its vote map for that hash, empty when the lock came by certificate), not the observer's. Index 1296 appears twice on the feed: it locked inside the restart window, one write per process, a restart-boundary one-off At the 20:15:58 restart index 1319 (locked 14 min before) was recorded again: open, the seed should have held it locked; f22870a logs the seeded states and the earlier state on such a record. The 20:24:46 restart seeded 'proposed 500, locked 864' and re-recorded nothing (11 locks, 0 duplicates) |

docs/community/discord-hooks.md

@@ -14,7 +14,6 @@ eight fields, UK time in the footer with UTC in brackets, never a mention, never
 | Weekly numbers | #numbers | Monday 09:00 | the reddit kit's template (docs/community/reddit/posts/02-weekly-numbers-template.md) as six fields with the last-week column, a link to the ledger |
 | Release | #announcements | on a publish, by the shipper | version, three download links with full sha256, node commit, consensus digest, up to five "what changed" lines read from the release plan |
 | Incident open / resolve | #incidents | by hand, or by the watcher | UTC time, what happened, who is affected per tier, what is being done; then cause, the rule or fix, duration |
-| Network feed | #network-feed | every hour, when `DISCORD_WEBHOOK_FEED` is set | height and blocks/s over the hour, hash rate and difficulty, keys active and voters, the last lock; the daily hash-origin field once per report date from `/api/live state.hash_origin`; milestones once each (every 100,000 blocks, 10,000 locks, 10,000 paid shards; the first crossing of a vote-key count and of a hash-rate step). Added 7 October 2026; docs/community/discord/structure.md section 4.1 |
 
 Every number comes from the public API (`/api/stats`, `/api/live?window=300`, `/api/supply`; docs/api/public-stats.md). The
 Devnet 2 line reads the fleet file and uses its numbers and the gate word only; the seed address and the state text never pass.
@@ -36,7 +35,6 @@ The watcher's texts are fixed sentences in the script, each a stated rule, and a
 
 ```
 node tools/community/discord-hooks.mjs pulse | digest | weekly [--live] [--force]
-node tools/community/discord-hooks.mjs feed [--live] [--via updates]        the hourly feed; --via updates posts it through DISCORD_WEBHOOK_UPDATES until #network-feed has a webhook
 node tools/community/discord-hooks.mjs release 0.3.14 --windows <url> --windows-sha <hex> --mac <url> --mac-sha <hex> --hive <url> --hive-sha <hex> \
      --node-commit 4c6b129d --digest "b18ed271 (thirteen fields, unchanged)" --plan docs/plans/release-0.3.14.md --section "1. Why" [--changed "line"]... [--live]
 node tools/community/discord-hooks.mjs incident open --what "..." --affected "..." --doing "..." [--at 2026-10-06T15:44:00Z] [--id inc-...] [--live]
@@ -67,9 +65,7 @@ parenthetical dropped, 160 characters at most; a line that trips the guard is dr
 ## Credentials and deployment
 
 `~/.config/igneum/discord`, mode 600, KEY=VALUE lines: `DISCORD_WEBHOOK_NUMBERS`, `DISCORD_WEBHOOK_ANNOUNCEMENTS`,
-`DISCORD_WEBHOOK_INCIDENTS`; optional `DISCORD_WEBHOOK_FEED` (no key, no feed, one "feed off" note per tick) and
-`DISCORD_WEBHOOK_UPDATES` (the hidden updates channel, the `--via updates` route). Never in the repository, never printed;
-`check` prints which keys are set.
+`DISCORD_WEBHOOK_INCIDENTS`. Never in the repository, never printed; `check` prints which keys are set.
 
 The scheduler runs on igneum-build-1 because the Mac sleeps: `infra/build-server/discord-hooks/{igneum-discord-hooks.service,
 igneum-discord-hooks.timer, install.sh}`, a tick every minute. `install.sh` copies the script to `/srv/discord-hooks/bin`, the
@@ -87,4 +83,4 @@ file yet), the install on the box.
 
 ## The server invite
 
-The standing invite is https://discord.gg/igneum (created 6 October 2026, main; the vanity names discord.gg/igneum and discord.gg/igneumnetwork were free on 3 October and are not yet claimed). The home page's join line and any public text use this URL; nobody asks for it again.
+The standing invite is https://discord.gg/beCy8G5ZR (created 6 October 2026, main; the vanity names discord.gg/igneum and discord.gg/igneumnetwork were free on 3 October and are not yet claimed). The home page's join line and any public text use this URL; nobody asks for it again.

docs/community/discord/README.md

@@ -1,68 +0,0 @@
-# Discord server assets and boost perks
-
-Server: Igneum (id 1557085229330464808), vanity https://discord.gg/igneum, boosted to level 3 on 7 October 2026 (20 boosts: 14 on the three levels, 3 on the Server Tag add-on, 3 on the Enhanced Role Styles add-on; 0 spare).
-
-Every file in `assets/` is built from the brand in this repo: the ember mark from `site/index.html`, the colour tokens from `site/site.css` (obsidian #0C0C0E, ember #F2541B, ember-hi #FF6A2B, molten #FFB35C, bone #F4F1EC, ink-2 #C9C7C2, ash #9A9A9E), the fonts in `site/fonts/` (Unbounded for the wordmark, IBM Plex Sans and Mono for the rest) and the DAG step recording `docs/plans/site-ui-3-shots/after-v2/home-steps-1440-dark.webm`.
-
-Rebuild everything from the repo root:
-
-```
-python3 docs/community/discord/make-assets.py [path to a frame of the recording for the invite backdrop]
-sh docs/community/discord/make-banner-gif.sh
-```
-
-The guide banner (1920x480) was rendered with the same helpers; see the commit that added it for the snippet.
-
-## Files
-
-| File | Size | Purpose | Where it is set |
-| --- | --- | --- | --- |
-| `server-banner-960x540.gif` | 5.9 MB | Animated server banner: nine seconds of the live DAG scene between two dark bands that carry the lockup and the tagline (level 3 perk, limit 10 MB) | Server Settings, Boost Perks, Server Banner Background |
-| `server-banner-960x540.png` | 42 KB | Static fallback for the same slot | Not uploaded (the GIF is live) |
-| `banner-overlay-960x540.png` | 16 KB | Transparent overlay ffmpeg composites onto the recording for the GIF | Build input only |
-| `invite-background-1920x1080.png` | 368 KB | Invite embed and invite page background: lockup and tagline over a blurred, darkened DAG frame | Server Settings, Boost Perks, Server Invite Background |
-| `guide-banner-1920x480.png` | 69 KB | Server Guide header (4:1) | Server Settings, Onboarding, Server Guide, Server Guide Banner |
-| `role-*.png` | 2 to 5 KB each, 64x64 | Role icons, one mark variant per role (limit 256 KB) | Server Settings, Roles, each role's Display tab |
-| `emoji-*.png` | 2 to 8 KB each, 128x128 | The ten custom emoji | Server Settings, Emoji |
-| `sticker-*.png` | 9 to 24 KB each, 320x320 | The three stickers (limit 512 KB) | Server Settings, Stickers |
-| `make-assets.py` | | Generator for every PNG above | |
-| `make-banner-gif.sh` | | ffmpeg recipe for the animated banner | |
-
-## Role ladder (7 October 2026)
-
-| Role | Colour | Style | Icon | Hoisted | Permissions |
-| --- | --- | --- | --- | --- | --- |
-| Founder | unchanged | solid | `role-founder.png` (molten mark on obsidian) | unchanged | untouched |
-| Core | unchanged | solid | `role-core.png` (ember-hi mark on obsidian) | unchanged | untouched |
-| Pool operator | #FF6A2B | gradient ember to molten | `role-pool-operator.png` (mark in a molten ring) | yes | none |
-| Node runner | #F4F1EC | gradient ember to molten | `role-node-runner.png` (bone mark) | yes | none |
-| Verified miner | #F2541B | gradient ember to molten | `role-verified-miner.png` (ember mark with a tick) | yes | none |
-| Miner | #F2541B | gradient ember to molten | `role-miner.png` (ember mark) | yes | unchanged |
-| Early miner | #FFB35C | solid | `role-early-miner.png` (obsidian mark on molten) | no | none |
-| Prover | #FFB35C | gradient ember to molten | `role-prover.png` (molten mark) | no | unchanged |
-| Builder | #E8E4DC | solid | `role-builder.png` (bone mark on graphite) | no | Embed Links, Attach Files |
-| Researcher | #9A9A9E | solid | `role-researcher.png` (ash mark) | no | Embed Links, Attach Files |
-| Community | #C9C7C2 | solid | `role-community.png` (outlined mark) | no | none |
-| Bot | #9A9A9E | solid | `role-bot.png` (ash mark on row) | no | unchanged |
-
-"None" means the role grants nothing of its own; members fall back to @everyone. Early miner is for the first 1,000 miners. Gradient roles use the Enhanced Role Styles add-on with start #F2541B and end #FFB35C. Holographic was tried on Founder and left off: it is a fixed pink and blue shimmer with no colour control and does not read as the brand.
-
-List order (set by drag on 7 October 2026): Founder, Core, Pool operator, Node runner, Verified miner, Prover, Miner, Early miner, Builder, Researcher, Community, Bot, Server Booster.
-
-## Emoji and stickers
-
-Emoji names: `ign_ember`, `ign_block`, `ign_shard`, `ign_lock`, `ign_gpu`, `ign_proven`, `ign_hash`, `ign_letter`, `ign_flame`, `ign_ladder`.
-
-Stickers: Ember (related emoji fire), Proven (white_check_mark), GPU (desktop_computer). Three of the five free slots are used.
-
-## Onboarding
-
-Server Guide: welcome sign plus five to-dos (start-here, mining, ledger, announcements, read the rules) and the guide banner. Pre-join question "What do you mine with?" with five answers: NVIDIA, AMD and Apple grant Miner and #mining; "I run a node" grants Node runner and #devnet; "I build" grants Builder and #proving. Multiple answers allowed, not required.
-
-## Server Tag
-
-IGNM, enabled 7 October 2026 on the 3-boost add-on. Badge: Fire (Discord offers only its own pixel-art badge set, no custom upload, so the ember mark cannot be the badge; Fire is the nearest). Badge colour: custom, primary #F2541B. Members adopt the tag from Server Settings, Server Tag ("Adopt Tag") or from their own profile; the founder's account has not adopted it yet.
-
-## Not set, and why
-
-- Server Profile banner: that field only offers colour presets; it stays on "Server Icon Colour", which derives from the ember icon.

docs/community/discord/announcement-01.md

@@ -1,16 +0,0 @@
-# #announcements, post 1 (posted on the 0.3.15 live line through the Igneum webhook)
-
-Welcome to Igneum.
-
-Igneum is a proof-of-work chain built for graphics cards. The miners also prove every block with zero-knowledge proofs and are paid for it from the block. No premine, no stake, no fee to any team in the protocol. One founder, pseudonymous, building with AI systems; every criticism we know of is logged at igneum.network/ledger.
-
-**What is running today**
-The devnet has mined since 3 October 2026. Igneum Miner 0.3.15 is the current app for Windows, macOS and Linux (HiveOS package included): download at igneum.network/miner. Coins on the devnet have no value and the chain may be reset. Nothing is for sale.
-
-**0.3.15**
-A new app: an Overview page with the live chain and your own blocks lit, a Cards page with Ember Tune woven into every card, and plain words everywhere. Under it, the first consensus change made by miner signal: when 95% of mining weight runs the new program, class v4 switches on by itself. It costs an RTX 5090 about 80 W for 0.2% of its rate, costs a 4070 and a 9070 XT nothing, and in our public model it cuts the strongest chip's edge from about 5.6x to about 2x per joule. The rehearsal on 52 rented nodes flipped together tonight with zero rejected blocks.
-
-**How this channel works**
-Releases and chain events only. Numbers every six hours in #numbers from the labelled bot. Incidents, with cause and fix, in #incidents. Questions in #ask, criticism in #ledger, where it gets a ledger id and a date.
-
-igneum.network · /litepaper · /live · /miners · /ledger · /evidence