# Pool v0: what it does, what it does not, what was measured, and the listing checklist

5 October 2026, branch `pool-v0` (main worktree `../igneum-wt-pool`, fork worktree `vendor/igneum-node-pool` on the
fork's `pool-v0` from `release-0.3.6` a24ab01a). REBASED 6 October 2026 (section 9): branch `pool-v0-rebase` on master, fork
branch `pool-v0-rebase` on `release-0.3.14-node` 4c6b129d (worktree `../igneum-wt-pool-rebase`, fork worktree
`vendor/igneum-node-pr`); the share re-check hashes the template's program class, never a fixed one. The founder's ask: a public mining pool with the stats API WhatToMine and
HiveOS read, "the biggest step toward being listable". Built against `docs/spec/09-pool-protocol.md`, the miner's
template subscription and worker protocol (`igneum/miner/src/main.rs`), the Hive package's `local` mode
(`packaging/hive`), ledger F10 and G6 (pools and votes), and `docs/plans/explorer.md` section 6. Nothing is deployed.

## 1. Rust, and why

Spec 9.3 fixes the member protocol as newline-delimited JSON over TLS, not the node's gRPC. The miner is Rust and
talks gRPC to its node; the pool must verify every share on the CPU warp verifier (spec 9.8 item 5), which is the
node's own `IgneumEngine` in `consensus/pow/src/igneum.rs` (same program, cache and init words as block validation),
and it must build templates and submit blocks over the node's gRPC. Both are Rust crates by path. A Node service
would have had to reimplement the verifier or shell out per share; the Rust pool calls it in process at 0.44 ms per
share (measured, section 5). JSON lines are three serde derives. So: Rust, `pool/`, its own Cargo workspace reading
the fork by path. The miner side is a module in the fork (`igneum/miner/src/pool.rs`), because the identity, voter,
template and worker code it reuses lives there.

## 2. What v0 does

| Area | v0 | Spec section |
|---|---|---|
| Transport | newline JSON over plain TCP on 4463 (devnet), 4462, 4461; one object per line, `"t"` names the type, unknown fields ignored, 4 MiB line cap | 9.3, 9.5 |
| Session | `hello` / `welcome` (version, chain id, pool address, modes, `vote_mode: member`, `share_scheme` with fee, window and min payout), `authorize` with the member's BLS pubkey and proof of possession (verified with `verify_pop`), payout address and worker name / `authorized` | 9.3, 9.5 |
| Templates | mode A, one template per member per tip (NewBlockTemplate subscription, 1 s refresh, on demand): the member's `vote_key_hash` in the header, its key reveal and the pool's `IGNA` payout address in the coinbase extra data; sent as the node's `RpcRawBlock` JSON so a member with a node can submit it there | 9.4, 9.4.1 items 1 and 2, 9.6 item 2 |
| Seeds | `seeds` on connection and on every change, from the template's `pow_epoch` (current and next epoch seed, boundary DAA, day, the schedule; since 6 October 2026 also `program_class`, `next_program_class`, `era_seed`, `era_index`, `genesis_day_index`, `genesis_dataset_log2`, `program_class_v3_activation_daa`, so a member without a node builds the same program and day cache as the pool's node) | 9.9 |
| Jobs | `job` with prehash, `target64`, `share_target64`, a random 2^32 nonce space, the seed pair, `program_class` and `era_seed` (6 October 2026: the member refuses a job without a class, code `seeds`, and never hashes a guessed one), `clean` on a tip change | 9.5 |
| Shares | `share` = a lane hash at or below `share_target64`; the pool evaluates the lane on the CPU and answers `share_result` with `ok`, `stale` (superseded job past the 2,000 ms grace), `duplicate`, `above_target`, `wrong_hash`, `unknown_job`; a share at or below `target64` is a block, submitted to every node | 9.8 items 1, 5, 7 |
| Vardiff | per member, one share per 10 s, shift `s` with `share_target = target64 << s` never saturated; first correction sized from the measured rate (up to 8 steps), then one step per 30 s at most; idle members eased one step per 3 intervals | 9.8 items 2 and 4 (one deviation: the sized first step, below) |
| Weight | `2^-s` of a block per share | 9.8 item 3 |
| Payment | PPLNS over a window of N blocks of weight (default 2); the split is snapshotted when a block is found and credited when it is confirmed blue (a chain block or in a chain block's mergeset blues, the set the execution layer pays); orphans pay nobody; fee (default 1%) off the top | 9.8 item 8 |
| Payouts | EIP-1559 transfers from the pool's coinbase address through the node's eth_ JSON-RPC, one per payee at or above the minimum, at most 16 per round, receipts checked, a failed receipt re-credits; `--dry-run` records and sends nothing | design 1.1 (execution layer rewards) |
| The 20% | untouched: the execution layer credits the proving escrow by rule from consensus data (`executor.rs`); the pool's templates name only its own address and receive the 80% | 2.5, 5.3 |
| Votes | the member votes through its own node with its own key, as in solo mode; the pool holds no key and names each member's key in its header | 9.6, 9.7 items 1 and 2 |
| Member checks | own key in the header, the pool's address and own key reveal in the coinbase (refused with `vote_key`, `payout`, `reveal`); the pool's epoch seed, program class and era seed against the member's node (`seeds`; the class and era joined the check on 6 October 2026); a custodial pool (`vote_mode` not `member`) refused by default | 9.4.1 items 1 and 2, 9.9 item 2, 9.6 item 5 |
| Found blocks | the member submits to its own node and sends `solution`; the pool submits to every node | 9.2 |
| API | `/api/stats`, `/api/blocks`, `/api/miners/<address>`, `/api/payments`, `/api/pool-stats` (Hive-style flat object); field contracts in `pool/src/api.rs`, fixtures from the measured run | explorer.md section 6 |
| Page | `pool/web/index.html` under the site's tokens: tiles, connect card with the exact miner flags, address lookup, blocks, payments | |
| Persistence | `state.json` snapshot every 15 s and at shutdown (balances, blocks, payments, PPLNS window, lifetime counters) | |
| Miner | `igneum-miner mine <grpc url|none> <threads> <secs> <label> --pool <host:port> --evm-address <0x..> --worker-name <s> [--proving] [--worker <exe>]`: CPU threads or a GPU worker fed the share target; the CPU re-check of every GPU `found` before it is sent; STATUS lines with the Hive tokens (`accepted=`, `rejected=`, `now=<MH/s>`) | 9.8 item 6 |
| HiveOS | Flight Sheet pool URL `pool://host:4463`, `NODE=local` or `NODE=grpc://...` for a verifier node, `h-run.sh` passes `--pool` and `--worker-name` | packaging/hive |
| Dev fee | none in pool mode: the pool issues the templates, so the 1-in-100 template mechanism does not exist; the pool's fee is the only fee and is in `welcome`, on the page and in the Hive README (consequence C6, 5 October 2026) | |
| Proving | the member's `stats` line carries `proving: true` when it also proves (`--proving`; the app sets it when its prover runs); the pool shows it per worker and the page says a proving worker gives about 4% of its rate to the prover (bench-log "proving v1") and that proving income never passes through the pool (C6) | 9.8 item 8 |

## 3. What v0 does not

| Gap | Why | What closes it |
|---|---|---|
| TLS on the member port | spec 9.3 requires TLS 1.3 because a hijacked line could feed a member a checkpoint hash to sign. v0 relays no votes and the member signs nothing it got from the pool (votes go through its own node), so the hijack has nothing to feed; the gap is confidentiality of shares and the `binding` field. Plain TCP tonight; `rustls` is in the fork's dependency tree | a `--tls-cert/--tls-key` pair and the TLS exporter binding in `authorize` |
| Mode B (commitment) and mode C (declared templates) | the spec requires A and C of a conforming pool; C needs the member to build its own template with the pool's tag, and a node RPC that validates a template without submitting it (O-9.4) | O-9.4 first, then `declare_template` / `template_ack` / `template_refused` |
| Vote relay and carriage by the pool | 9.7 items 3 to 6; v0 members vote through their own node (road three of the three roads), so a member without a node does not vote | `vote` / `vote_ack` / `votes_carried`, aggregation per index (O-3.12), the carriage ratio on the page |
| Stratum compatibility | none, and the spec is not stratum-like: Stratum V1 is JSON-RPC with `mining.subscribe`, `mining.notify`, `mining.submit` over plain TCP and a job that carries a coinbase split and merkle branches; Igneum's protocol carries a full block, a 64-bit lane target and a BLS key, and its share is a lane of a 32-nonce group. A Stratum V1 bridge would have to hide the vote key, which is the thing 9.6 keeps with the member, so none is planned. Mining operating systems add custom miners by command line (Hive's custom-miner contract, `packaging/hive`), which is how this ships | |
| Sample verification at high shifts | spec 9.8 item 5 allows sampling above `sample_shift` 8; v0 verifies every share (2,270 per second per core keeps it cheap at any member count the first pool will see) | a sampling switch when a core is short |
| One template fetch per member per second | at 1,000 members that is 1,000 `getBlockTemplate` calls a second on the pool's node and 10 MB/s of mode A templates | a template RPC that takes a list of keys, or mode B |
| A database | `state.json` and an in-memory ledger; a crash between snapshots loses up to 15 s of shares | SQLite or Postgres when the first real pool runs |
| Custodial mode | `vote_mode: pool` is not offered (allowed by 9.6 item 5, refused by members by default) | not planned |
| Vardiff first step | the spec moves the shift one step per `set_target`; v0's first correction after 8 shares or one interval moves up to 8 steps from the measured rate, because a 100 MH/s card at the initial 2^20-hash share target sends 100 shares a second and one step per 30 s would take 5 minutes to reach one per 10 s | spec 9.10 row "Vardiff step" to say "after the first correction" |
| Luck | `luck_24h` is blocks found over block-weights of shares in the day; MiningPoolStats reads luck as expected over actual, and the field says which in the API source line | |
| App setting | design only (section 7) | |

## 4. How it was measured

`pool/tools/measure.mjs` under the `run` lock: one `igneumd` 0.3.6 (`vendor/igneum-node-036/target-integration`,
needs no change for the pool) on ports 30400 to 30403 (gRPC, p2p, JSON, EVM), network id `igneum-devnet-3040`, the
60x fast-time profile (`infra/fast-time/override-60x.json`) with real proof of work and `genesis_bits 0x1e400000`
(2^18 expected hashes per block, the CPU devnet value of the bench log), the pool on 30463 (members) and 30480 (API),
and three CPU miners of different identities, payout addresses and thread counts (4, 2, 2) pointed at the pool with
the node as their verifier (seed checks, votes). Ten minutes in dry run, then the same pool restarted without
`--dry-run` and a 0.1 IGN minimum for the real payout, then 100 requests per second against the API for 30 s.

Commands (the main checkout's lock script, from the pool worktree):

```
tools/lock/with-lock.sh build nice -n 19 cargo build --release -j 4                          # pool/
tools/lock/with-lock.sh build nice -n 19 cargo build --release -j 4 -p igneum-miner          # vendor/igneum-node-pool
tools/lock/with-lock.sh build nice -n 19 cargo test --release -j 4                           # pool/ (unit tests)
tools/lock/with-lock.sh run node pool/tools/measure.mjs --secs 600 --payout-secs 240 --rps 100
```

## 5. Measured

Two runs, both 5 October 2026 on this Mac (M-series, 16 cores) while other agents' builds and test networks ran on
the same machine: every millisecond below is a number taken under load and says so. Counts, shares, blocks, payments
and balances are not disturbed by load. Summary JSON: `<scratch>/measure/summary.json` and `measure2/summary.json`.

Run 1: the pool was the whole network (three CPU miners, 8 threads in all, no other miner). Run 2: an 8-thread solo
CPU miner ("carrier") mined beside the pool so the pool held about half the hashrate and its blocks competed. Run 1
also found a bug: the member sends a `share` and then a `solution` for the same nonce (spec 9.5), and the pool counted
the solution as a duplicate share (604 "rejected" of 617 accepted, every one a solution); fixed before run 2 (a
solution whose nonce the share already credited is acknowledged, not counted), run 2 shows 0 rejected.

| Number | Run 1 (pool = network) | Run 2 (pool about half) | Source |
|---|---|---|---|
| Run length | 600 s dry run, 240 s real payout, 30 s API load | same | `measure.mjs` |
| Shares accepted / stale / rejected | 617 / 0 / 604 (the solution bug) | 317 / 0 / 0 | `/api/stats` pool.shares |
| Shares per minute, pool | 61.7 | 31.7 | accepted / 600 s |
| rig1 (4 threads): shares per minute, hashrate 10 min, final shift | 31.2, 86.9 kH/s, 0 | 15.8, 47.5 kH/s, 0 | `/api/miners/0x11..` |
| rig2 (2 threads) | 15.4, 40.9 kH/s, 0 | 7.8, 20.4 kH/s, 1 | `/api/miners/0x22..` |
| rig3 (2 threads) | 15.1, 40.3 kH/s, 0 | 8.1, 21.5 kH/s, 0 | `/api/miners/0x33..` |
| Vardiff changes over 10 min | 0 | 17 (rig3 to shift 1 at 25 s and back at 55 s; rig2 to 1 at 3 min; all at 0 at the end) | pool log `VARDIFF` lines |
| Share check cost, ms (mean / p50 / p99 / max) | 2.018 / 2.054 / 2.334 / 5.333 (n 617, under load) | 2.094 / 2.096 / 2.241 / 5.785 (n 317, under load) | `/api/stats` pool.share_check_ms, `Instant` around `hash_bound` |
| Share check cost in isolation, under the `measure` lock (every build and run slot held), 500 checks | 1.347 mean / 1.313 p50 / 2.074 p99 / 2.638 max ms | same binary | `cargo test --release share_check_cost_ms -- --nocapture` in `pool/`, `SHARE_CHECK_MS` line |
| Pool hashrate from shares | 168 kH/s | 89 kH/s (miners' own STATUS: 0.088 + 0.043 + 0.043 = 0.174 MH/s in run 1; 0.061 + 0.030 + 0.030 = 0.121 MH/s in run 2, which the carrier's 8 threads depressed) | `/api/stats`, miner STATUS `now=` |
| Blocks found / confirmed / orphaned | 604 / 604 / 0 | 289 / 288 / 0 (one pending at the end) | `/api/stats` pool.blocks_* |
| Orphan rate | 0 of 604 | 0 of 289 at 49.1% of the network's 589 blocks (the carrier found 288 in the same window, 444 over its run) | `ORPHAN` lines, `/api/blocks` |
| Pool's share of network blocks | 100% | 49.1% | pool.blocks_total / network.block_count |
| First block: found to confirmed | | 3.7 s (found 21:20:24.953, confirmed 21:20:28.678, daa 3, effort 1.00, one payee at fraction 1) | `/api/blocks` first_confirmed_block |
| Reward per block credited | 2.5351 IGN (80% of the ramp's 3.169 IGN at day 0) | same | `block_subsidy(daa, 1)` x 80% |
| PPLNS in dry run | 60 payment records computed, nothing sent, balances kept: 792.14 / 365.30 / 360.01 IGN after 600 s | 59 records; 389.16 / 164.54 / 169.85 IGN | `/api/payments` dry_run, `/api/miners` balance_ign |
| Pool fee kept | 15.33 IGN of 1,532.77 (1.00%) | 7.31 of 733.39 (1.00%) | pool.pool_fee_total_ign |
| Real payout, 240 s: transfers sent / confirmed / failed | 24 / 18 / 0 (6 sent, receipt not yet read at the end) | 24 / 18 / 0 | `/api/payments` status from `eth_getTransactionReceipt` |
| Pool EVM balance before / after | 1,532.77 / 180.18 IGN | 733.39 / 111.12 IGN | `eth_getBalance` on the private node |
| Miners' EVM balances received | 1,026.10 / 491.09 / 473.22 IGN | 481.99 / 208.06 / 252.36 IGN | `eth_getBalance` before and after |
| API at 100 requests per second for 30 s | 3,001 sent, 3,001 ok, 0 errors, p50 0.78 ms, p90 0.97, p99 1.17, max 5.69 | 3,001 / 3,001 / 0, p50 0.85, p90 1.05, p99 2.76, max 11.98 | `fetch()` from Node 22 on the same machine, four endpoints round-robin |
| Member checks | 0 jobs refused, 0 CPU mismatches, 16 epoch seed changes followed (60-DAA epochs) by every miner, seed check against its own node passed each time | same | miner logs `POOL SEEDS`, STATUS `refused=` |
| Votes | every miner voted through its own node as in solo mode (`VOTE` lines in the miner logs); the pool held no key | same | miner logs |

What is unusual about this network and why it does not change the reading: at `genesis_bits 0x1e400000` a block is
2^18 expected hashes, so a share worth 2^20 hashes (the vardiff's initial size) is harder than a block; the shift sat
at 0 and every share was a block. That is why blocks found equals shares accepted less the few found by two miners on
the same tip. Vardiff still ran (17 changes in run 2 when the carrier slowed the rigs) and the saturation cap held.
On a GPU network (devnet difficulty 0x1d100000, about 2^28 hashes a block, and more as cards join) shares sit far
below blocks and the shift moves into its working range; that run needs a GPU worker and is unverified (section 8).

Consequences, by tier (the standing rule of 5 October 2026):

| Tier | What the numbers mean | What is done about it |
|---|---|---|
| A pool operator on one Hetzner box (cx23 2 vCPU or cpx31 4 vCPU) | 1.35 ms per share check in isolation and 2.1 ms under load on an M-series core (the crate's tight-loop bench is 0.44 ms per warp; the check adds the init words and the engine's shared cache path) is one core for 480 to 740 shares a second, which at one share per 10 s per member is 4,800 to 22,700 members per core; the API at 100 rps costs under 3 ms p99, and WhatToMine polls once a minute. The cost that scales first is the template per member per second (section 3): at 1,000 members that is 1,000 `getBlockTemplate` calls a second on the box's node | `--verify-threads` sizes the check pool; the template RPC that takes a list of keys is the planned fix before a thousand members |
| A home miner on one card (8, 12, 16, 24 or 32 GB, NVIDIA, AMD or Apple, any OS) | pool mode changes nothing on the card: the same worker, the same 256 MiB cache plus program, the pool's share target in the job's target field. Income: 80% of each block over the PPLNS window less 1%, paid when the balance passes 1 IGN; at 2.5 IGN a block (ramp day 0) a miner holding 1% of a pool that finds a block a minute is paid about every 40 minutes, and a miner at 0.01% of a large pool every 3 days. A miner that also proves sends about 4% fewer shares and the page says so | the `--proving` flag and the Proving column; `--min-payout` is the operator's lever for small miners |
| A rig (several cards) | one `igneum-miner --pool` per card, one vote key per rig (`IDENTITIES` is ignored in pool mode), the worker name labels each card on the page | the Hive hooks' `pool://` mode |
| A pool user without a node of their own | hashes and is paid, does not vote and does not check the pool's seeds (spec 9.7 item 2); their finality weight still accrues to their own key through the blocks the pool finds under it | `NODE=local` in the Flight Sheet runs the bundled node as the verifier |
| The network | pool concentration does not become vote concentration: every block carried the finding member's key, 3 keys under one payout address in both runs (F10, O-9.1) | the explorer's keys-per-payout-address count is the public check |

Harness note: run 1's node "answered" nine minutes after it started because the harness waited for `igneum-miner watch 1`
with an 8 s timeout, and `watch 1` takes one sample, sleeps 10 s and then prints: every attempt was killed and the loop ran
out. Fixed in `measure.mjs` (15 s timeout). The same shape elsewhere: `packaging/hive/h-run.sh` runs `watch 1` with no
timeout (fine); no other script in `tools/` wraps `watch` in a timeout under 11 s (grep, 5 October 2026).

## 6. Listing checklist: WhatToMine's form against this pool

WhatToMine's "add a coin" form (as the founder read it on 5 October 2026 and `docs/plans/explorer.md` summarises: an
explorer or pool with an API, the block reward and block time sources, a source for total coins) and what
MiningPoolStats asks of a pool (hashrate, miners, workers, blocks with heights and times, fee, minimum payout, luck):

| They ask for | Where it is | State |
|---|---|---|
| Algorithm name | `igneum` (`/api/stats` pool.algorithm, network.name) | ready |
| Network hashrate and difficulty | `/api/stats` network.hashrate, network.difficulty; also the site's `/api/stats` | ready |
| Block reward and block time | `/api/stats` network.block_reward_ign, miner_reward_ign (80%), block_time_target_s 1; the site's `/api/stats` block_reward with the halving table | ready |
| Total and circulating supply | the site's `/api/supply` | ready (explorer branch) |
| An explorer | the site's `/explorer`, `/block/<hash>`, `/address/<addr>` | ready (explorer branch) |
| A pool with an API | this pool: `/api/stats`, `/api/blocks`, `/api/miners/<address>`, `/api/payments`, `/api/pool-stats` | ready, not deployed |
| Pool hashrate, miners, workers | `/api/stats` pool.hashrate (10 min), pool.miners, pool.workers | ready |
| Blocks found with heights and times | `/api/blocks`: DAA score, blue score, ISO time, status | ready |
| Fee, minimum payout, scheme | `/api/stats` pool.fee_percent, pool.min_payout_ign, pool.scheme PPLNS | ready |
| Luck | `/api/stats` pool.luck_24h, pool.effort_current | ready, definition in section 3 |
| A public pool address and page | `--public-url`, the page at `/` | needs a box and a hostname (pool.igneum.network is held) |
| Exchange or price | none; nothing here is a token sale | not applicable |
| Mining software | igneum-miner with `--pool`; HiveOS custom miner package with `pool://` | ready, HiveOS untested on a rig |

What is still missing for a listing: a deployed pool with a hostname and TLS on the page, a public testnet for it to
mine, and the explorer branch merged so `/api/supply` is live. In that order.

## 7. App: "Mine to a pool" (design only)

Settings, under the rewards address field (`app/igneum-app/ui/index.html`, the `#settings` panel), one new field:

```
<div class="field">
  <div class="k">mine to a pool</div>
  <label class="switch"><input type="checkbox" id="s-pool"><span class="track"></span><span>Mine to a pool instead of solo</span></label>
  <div class="row"><input type="text" class="addr-input mono" id="s-pool-url" placeholder="pool host:4463" spellcheck="false"><button class="btn small" id="s-pool-save">Apply</button></div>
  <p class="note" id="s-pool-note">Your vote key stays on this machine and the pool names it in every block you find. The pool pays your rewards address by its own rule and fee (shown here once connected). The software dev fee is off in pool mode. Your node keeps running as the verifier.</p>
  <div class="box mono" id="s-pool-terms" hidden></div>
</div>
```

Engine side (`config.rs` `Settings`): `pool_url: String` (empty = solo). `engine.rs` passes `--pool <url>
--worker-name <display_name>-gpuN [--proving]` to each card's miner instead of `--identities`/`--dev-fee`, keeps the
node as the first argument, and shows the pool's `welcome` terms (fee, scheme, minimum payout) in `#s-pool-terms`
from the miner's `POOL WELCOME` line. The dashboard's "found" counters become "shares accepted" and "blocks credited"
in pool mode. Not implemented tonight.

## 8. Unverified

- The GPU worker path in pool mode (`--worker`): written against the worker protocol and the solo miner's re-check,
  not run on a card tonight (the measurement used CPU threads). The CUDA and OpenCL workers take the share target in
  the job line's target field unchanged, so nothing on their side changes.
- HiveOS hooks in pool mode: `h-config.sh` exercised by hand in both modes (pool and solo), `h-run.sh` syntax-checked;
  never run on a Hive rig (the package as a whole is untested there, `packaging/hive/README.md`).
- Testnet and mainnet ports and chain ids: set from the design, not run.
- The Hetzner deploy in `pool/README.md`: written from the seed-node scripts, not executed.
- The exact reward per block the execution layer credits against the pool's expected figure: the pool computes
  `producer_share(block_subsidy(block daa))`; the executor uses the merging chain block's subsidy; equal on the
  private run (section 5), may differ by the ramp slope across a day on a live chain. The pool's EVM balance is the
  truth and the page shows both.

## 9. 6 October 2026: the rebase onto 0.3.14 and the program class

The fleet agent's load run (18:14Z to 18:24Z, ten GPU members, vardiff working): 0 shares accepted in ten minutes. Every
member's log: `WORKER MISMATCH nonce=... gpu=... cpu=...: share not sent`. The pool fork's miner re-checked every GPU
share with its own CPU hasher, and that hasher (`release-0.3.6`'s kaspa-pow) predates program class v3: it hashed a fixed
class v2 program while the 0.3.13 and 0.3.14 CUDA workers hashed the epoch's class v3 program, so the two never agreed and
the member refused every share before it left the machine. Everything else in the pool worked.

What changed (branch `pool-v0-rebase` on master, fork `pool-v0-rebase` on `release-0.3.14-node` 4c6b129d):

| Where | Change | Forced by the rebase? |
|---|---|---|
| Fork `igneum/miner/src/pool.rs` | `EpochSeeds` carries `class` and `era` on 0.3.14; the member builds them from the job's `program_class` and `era_seed` (`job_seeds`), refuses a job without a class or with one this fork does not know (`job_refused`, code `seeds`), checks class and era against its own node's template beside the epoch seed (`seeds_agree`, through `crate::template`, which installs the node's schedule, genesis day and class v3 activation), installs the same three from the pool's `seeds` line when it has no node (`install_from_pool_line`), and ends every worker `job` and `prepare` line with the class tokens (`class=v3 era=<hex>`); `prepare` writes a checked pack under `--prepare-packs` as the solo miner does; a worker `error ... program class mismatch` gets a fresh prepare | yes (the struct changed) and the fix itself |
| Fork `igneum/miner/src/main.rs` | `class_tokens`, `write_pack_checked`, `seeds_from_info` are `pub(crate)` | yes |
| Pool `node.rs` | seeds from the template with the class and the era; the node's genesis day, dataset size and class v3 activation installed beside the schedule; `seeds` and `job` carry the new fields | yes (the struct changed) |
| Pool `protocol.rs` | `Seeds` + 7 fields, `Job` + 2 fields (additive: a member ignores unknown fields, so the line still parses on the old build; the old build then hashes class v2 as before and keeps mismatching, so every member moves to this build) | yes |
| Pool `verify.rs` | the tests build seeds through `EpochSeeds::v2` | yes |
| Protocol, vardiff, PPLNS, stats API, page | unchanged | |
| `packaging/hive` | the pool:// mode merged with master's per-card `IDENTITIES=auto` and `OVERRIDE` handling; `selftest.sh` passes, the pool-mode config exercised by hand (NODE=local, OVERRIDE set) | merge only |

Tests (every suite on igneum-build-1, `IGNEUM_AGENT=pool`):

| Suite | Result | What it pins |
|---|---|---|
| `igneum-pow` `tests/recheck.rs` | 2 of 2 | class v3 (`packs-ca2-mixer/mx8-devnet-epoch0`) and class v4 (`packs-ca3-v4/v4-devnet-epoch0`): the pack's program (generator, id) reproduces the pack's 96 vectors (the worker's reference), the chain seam the engine calls (`Epoch::chain_program`, `chain_dataset_day`) builds the same program, and one known nonce (prehash 0x5a..., nonce 0x12345678_00000bb7) hashes equal through both paths for each class; v3 and v4 differ from each other and from the fixed-v2 program of the same seed (the fleet's mismatch); the v3 id 73bcbfe8ccf988f1 and v4 id c120d7963abdcd96 as pinned |
| fork `igneum-miner` | 21 of 21 | `pool::tests::cpu_recheck_equals_the_worker_reference_for_class_v3`: a job line of the pool's shape through `job_seeds`, then the real `IgneumEngine::epoch_for(seeds).hash_bound` against the pack's reference on the known nonce, the v2 re-check shown to disagree, the worker tokens checked; `a_class_v4_job_is_refused_until_the_fork_knows_class_v4`: this fork's `ProgramClass` has no V4, so a class 4 job is refused rather than hashed on a guess, and the test FAILS the day V4 lands (ca3-v4-node), which is when it becomes the v3 test's shape on the v4 pack; `pool_seeds_are_checked_against_the_verifier_class_and_era` |
| pool `igneum-pool` | 22 of 22 | unchanged suites on the new seeds |

Consequences per tier: a pool member on any card hashes the program its pool's node names, so the fix costs no hash rate
and no memory on any tier (the day cache size is the node's, 1 GiB on the devnet); a member without a verifier node now
gets the genesis day and dataset size from the pool's `seeds` line, which it had no source for before (it would have built
a wrong-size cache and mismatched silently); a pool on a class v4 network needs a fork with `ProgramClass::V4`
(0.3.15, ca3-v4-node); until then its members refuse class 4 jobs loudly (`JOB ... REFUSED (seeds)`), never hash on a guess.

Building the pool crate on igneum-build-1: the pool reads the fork through the `vendor/igneum-node` symlink; lib.sh syncs
the fork worktree it points at (`vendor/igneum-node-pr`) as a whole repository, and the symlink itself is created once on
the box by hand (`ln -s igneum-node-pr /srv/builds/<worktree>/vendor/igneum-node`), the one step the scripts do not do.

**Rule (7 October 2026, the Devnet 3 pair):** a pool daemon is built from the same repo tree as the chain's node, never a release behind; the 0.3.21-tree daemon hashed class v4 sub-version 2 against Devnet 3's re-pinned sub-version 3 and refused every share as WRONG HASH. The Devnet 3 pair runs the 0.3.22-tree daemon (c15b39b0, fork 69d1b56e).