v2 release checklist (the first public release)

[defenwycke]

Tracking issue for the first public release: node + mining + dashboard, multi-operator.
Wallet and Pay are not in this release (see the note at the end).

Rewritten 2026-08-19; section A, Sequence and the naming decision refreshed 2026-08-23. The public release is v2. Everything below was verified against f3736bc33 and the live fleet on
that date. The previous body was substantially wrong — six of its sections described work that is
already done or decisions that the design had already answered. The corrections are kept at the
bottom so the stale items are not re-raised.

---

What this release is

You already publish signed releases — v1.11.21 is current and SHA256SUMS.txt.asc verifies.
This is not the first artefact. It is the first release where a stranger can run the 9th node.

That is not a feature goal. It is the only path to a pool that ever pays:

pool          100.1 TH/s      (sum of own-received share work, 1h, 2026-08-19)
network       912.5 EH/s      (difficulty 127,479,855,693,691 at h963,154)
pool share    0.0000110%
expected      0.0058 blocks/year  ->  ~173 years to ONE block

shard_settled_blocks = 0, winning_miner on zero rounds. No software change moves this number.
More operators is the mechanism, so the release is scoped around admitting them safely.

The scope rule

One rule decides what is in: anything that is currently safe only because we own all 8 nodes
becomes a blocker the moment someone else runs one. Everything else is deferred.

How admission already works (this was an open question; it is not)

Admission is designed and built, not pending a decision:

Elder = MPC contributor (position 1-101 in the ceremony)      main.rs:2880
Any node can contribute - first 101 become elders             main.rs:6549
MPC ceremony is ossified (101 contributors reached)           main.rs:6573

mpc_contributions is keyed by elder_position INTEGER PRIMARY KEY. Live on vm1: 8 contributions
— our own nodes, holding 8 of 101 slots. Ossification caps the elder set, not participation:
node 102 joins normally, it simply does not get the elder share. Node reward weight is:

Capability	Shares	Proven today?
Archive	5	NO — claimed
GhostPay	4	NO — claimed
PublicMining	3	NO — claimed
Reaper	2	yes
Elder	1	yes

Archive(5) + GhostPay(4) + PublicMining(3) + Reaper(2) + Elder(1) = 15 (payout.rs:4644).
Non-elders also vote: widen_voter_set returns the active set whenever active is a superset of
elders, falling back to elders only otherwise.

---

A. Trust boundary — the actual release blockers

Refreshed 2026-08-23 (second pass). One issue remains open, and what is left on it is ARMING,
not building.

• H-7: challenger /24 subnets are self-reported, so the diversity floor is fabricable (was: capability proofs do not prove the capability) #605 — capability proofs do not prove the capability; 12 of 15 shares are unearned.
  The only open item in this section. Capability qualification gates the active voter set
  (main.rs:3780) as well as reward, so a node claiming Archive + GhostPay + PublicMining takes
  12/15 of node-reward weight and a seat, repeatably, at no cost. Bounded today only because
  all eight qualified nodes are ours.
  What is left is two arming decisions. Both gates are built and dormant:
  - ADDRESS_PROOF_HEIGHT (H-7) — basis measured twice, holds. 24h to 2026-08-23 across three
  nodes: 3,739 passes / 61 failures, 61 of 61 Unreachable, zero cryptographic failures.
  Only a cryptographic failure votes FAIL, so arming cannot strip an honest node's subnet.
  - ARCHIVE_TX_PROOF_HEIGHT (H-6) — free to arm. Measured 2026-08-23: archive_mode=false
  on all eight, so no node claims Archive and none collects the +5. Arming changes the
  qualified set by nothing today and is load-bearing the moment slot nine is a stranger.
  ⛔ GhostPay's +4 must NOT be built — Ghost Pay is replaced by Ghost Wallet and the +4 moves to
  running a Wraith coordinator (L2 removal: capability reweight, the CapabilityType wire hazard, and what it reclaims #736).
• Mesh hardening: replayable envelopes and no per-IP inbound cap (audit H-11, H-12) #604 — mesh hardening. BUILT. Both halves on main: H-12's per-IP cap
  (MAX_INBOUND_PER_IP = 8) and H-11's v2 envelope (mesh: bind timestamp and message type into the envelope signature, and persist per-sender replay floors (H-11) #740). ⚠ MESH_ENVELOPE_V2_HEIGHT = u64::MAX
  — dormant. v1.11.27 (deployed fleet-wide 2026-08-23) is what makes every node able to
  VERIFY a v2 envelope; arming is a separate, later change.

Closed since the 08-19 rewrite: #589 (Stage 6 Release B — the shard settles from the chain on
every node), #603 (#742), #625, #647 (#741). #411 retitled and deferred — its premise was wrong,
allocation precedes identity; the DoS found while scoping it became #744 → #746.

B. A stranger must be able to run it

• Prove all three mining modes end-to-end on a chain — solo, private pool, public pool.
  The code is in: Solo mining cannot produce an approved coinbase on mainnet; build_coinbase_solo_mode is unreachable #592 fixed solo coinbase, and f3736bc33 made private_pool approve its own
  payouts (single-operator modes skip BFT, keyed on declared mode, never on a live peer count).
  None of the three has been proven end-to-end on a chain. Regtest cluster is stopped but intact.
• Dashboard: warn that the node reward address must not be an address anyone mines to #588 — warn when the node reward address is one a miner could also use. This is what caused
  Every payout proposal rejected: vm1's node_payout_address is also a miner's address #587; surfacing it in the UI stops an operator recreating it.
• Operator onboarding docs. Config templates now exist and are test-gated
  (bins/ghost-pool/tests/shipped_config_templates.rs), including config/mainnet-private-pool.toml.
• feat(dashboard): build the real /api/v1/swarm/nodes/* fleet-control API #403 — swarm fleet-control API. The fake-success routes are gone (the config route now saves
  atomically, errors on failure and calls request_restart()); confirm the remaining routes and
  verify live auth + WS relay on a canary, which has never been done.

C. Unattended operation

• Storage grows unbounded on every axis — retention and compaction plan #585 storage grows unbounded on every axis (retention + compaction plan)
• Every database operation blocks a tokio worker on one global mutex — no spawn_blocking, one connection for the whole process #537 every database operation blocks a tokio worker on one global mutex
• ghost-pool API hangs on vm5/vm6: 2.66M-row ledger scan every 30s starves the async runtime #554 ghost-pool API hangs on vm5/vm6 on the periodic ledger scan
• vm5/vm6 are 4 GB nodes with a 2.5 GB database that only ever grows — working set no longer fits in RAM #556 vm5/vm6 are 4 GB nodes with a database that only grows
• ghost-pool logs retain only ~75 minutes: disk at 85-89% caps journald, and one WARN is 82% of volume #582 ghost-pool logs retain only ~75 minutes under disk pressure. Eased 2026-08-23: deploy
  .bak pruning reclaimed ~8.6 GB fleet-wide, and deleting the published UTXO snapshot took vm1
  from 90% to 73%. Not structurally fixed — nothing prunes the backups automatically.
• vm1/vm2/vm3 are at 100% inbound capacity again — maxconnections=125 is saturated three days after the 50->125 raise #572 / feat(dashboard): expose maxconnections as an adjustable node setting #499 / pool: the maxconnections ceiling is derived from instantaneous MemAvailable, so it refuses valid values and accepts unsurvivable ones #614 inbound capacity ceiling and maxconnections as a node setting
• Farm tier :4444 binds but never applies its difficulty floor — advertises the hobby value #611 farm tier :4444 binds but never applies its difficulty floor
• ci: the 18 integration_tests_sv2 targets compile but never run — they need process infrastructure and a triage pass #617 the 18 integration_tests_sv2 targets compile but never run. ⚠ related and worth
  reading first: five ghost-pool regtest tests were passing by skipping — hardcoded
  credentials matched no shipped config, and one could never have passed at all. Fixed in Make the regtest integration tests actually run instead of passing by skipping #743.
• CI is failing on main #685 CI fragility — CLOSED. It was the shared apt-get step hanging, not the builds;
  caching the .debs (ci: stop a hung apt-get from eating a job's entire timeout budget #693, ci(release): cache the .debs here too — #693 never reached release.yml #704) took 45-minute hangs to 1-20s. ⚠ a job that exceeds
  timeout-minutes reports as cancelled, not failure, which is why this read as flaky
  rather than slow.
• CI never runs 13 of 14 integration test targets — payout_ledger_e2e has been red on main unnoticed #580 / pool: build_webhook_user_identity splits on the first dot, extract_worker_name on the last — multi-dot workers collapse #481 closed.

D. Renames — pre-release, cheap now and expensive after

Mandated by the master spec §3.1. Doing this after a public release means breaking other people's
systemd units and documentation, so it belongs in this release or nowhere.

• ghost-pool -> ghost-mining — binary, systemd unit, installer and docs move together.
• Product naming: Ghost Core -> Node, Ghost Pool -> Mining, Ghost Pay -> Pay.
  Binaries ghostd and ghost-pay are unchanged.
• User-facing vocabulary is six words: Node, Mining, Pay, Vault, Ghost Mode, ghost ID.
  Reaper, Haze, Shroud, Exorcism and Glyphs become technical-docs trivia and stop being
  load-bearing in UI or marketing copy.

E. Not in this release

Wallet, Pay/ghost-mode protocol, #520 threshold-Schnorr SV2 identity, #542/#545 hazed restart and
reorg, and the page-weight items #686 / #687 / #688.

---

Sequence

Rewritten 2026-08-23 (second pass).

1. land the small branches; fix CI is failing on main #685 done.
2. Deploy. done — v1.11.27 on all eight nodes, both binaries, 2026-08-23.
3. Arm the dormant gates, one per height, spaced. ADDRESS_PROOF_HEIGHT →
   MESH_ENVELOPE_V2_HEIGHT → ARCHIVE_TX_PROOF_HEIGHT. ⛔ Nothing near
   PAYOUT_FROM_SHARD_HEIGHT = 964_100; that must be the only variable when it fires.
4. Merge Release B (Stage 6 Release B: delete the BFT payout vote and the GHOST-03 ledger sweep #750) once the payout gate has fired and the fleet is observed paying.
5. H-7: challenger /24 subnets are self-reported, so the diversity floor is fabricable (was: capability proofs do not prove the capability) #605 — the last section-A item, once its two gates are armed and observed.
6. Release must ship a canonical config set and a single binary version — deploys standardise neither today #759 — one version, one canonical config, and make deploy refuse on config drift. Do this
   BEFORE the public release: the moment a stranger runs node nine, "whatever that operator's file
   says" becomes the trust boundary.
7. Section C operational backlog, section D renames, operator docs, release.

⛔ Stage 6 deletion happens BEFORE the release, not after. docs/SHARE_SHARD_BUILD.md was
corrected 2026-08-22: shipping on a binary that still carries the BFT payout path ossifies it.
Release A (v1.11.26) armed the no-vote gate; Release B is #750, open as a draft, +322 /
−5,011, all six R-items complete.

Open decisions — operator only

1. Release version naming. DECIDED 2026-08-23: the public release is v2. The tag train
   is at v1.11.x, so "v1" collided. Pair the rename in section D with the v2 cut — if binaries are
   being renamed and re-versioned anyway, doing it once is far cheaper than twice, and Release must ship a canonical config set and a single binary version — deploys standardise neither today #759 wants a
   single version across every shipped binary in the same batch.
2. feat: arm decentralised mining discovery (signed node-list checkpoint + shim) + independent seeds #402 — arm decentralised mining discovery, or keep it dormant for this release.
3. result_large_err — unblocks 34 of ci: make clippy blocking (-D warnings) — 221 warnings to clear first #401's remaining lints.
4. pool: build_webhook_user_identity splits on the first dot, extract_worker_name on the last — multi-dot workers collapse #481 — does a multi-dot payout address count as INVALID?

---

Corrections to the previous body — do not re-raise these

Previous claim	Verified reality (2026-08-19)
§1 six payout blockers open	Five are closed — #587, #601, #606, #592, #584. Only #605 remains.
§2 two gates armed but not on the fleet	Both fired. SHARE_ADDR_BIND_HEIGHT = 961_100 and OBSERVED_SETTLEMENT_HEIGHT = 961_400; tip is 963,154 and the fleet is converged past both.
§4 three stale branches to rebase or abandon	Branches deleted; the repo went 69 -> 10 local branches.
§5 B3 fleet-control API returns fabricated success	Real code. The config route saves atomically, returns SAVE_FAILED on error, warns when no path is set, and calls request_restart(). The two remaining string matches are past-tense comments documenting the fix.
§6 #596 vm5-8 absent from pool.bitcoinghost.org	8 A records live. All eight nodes are in the mining DNS.
"The genesis signer set" listed as the longest-lead open decision	Answered by the design. Elders are the first 101 MPC ceremony contributors; participation beyond 101 is unlimited. See the admission section above.
§6 λ-sampling outstanding	On main.

Two of these were re-raised during triage on 2026-08-19 because the checklist was read as current.
That is the reason for this rewrite: an inaccurate checklist costs more than no checklist.

[defenwycke]

Progress 2026-08-03 — and corrections to this checklist

Two clean fleet-wide rolls today. Several items below were verified against the code and the running
nodes rather than the audit note, and a number turned out not to be what they claimed.

Landed and deployed to all 8

• H-13 byte order (50052bc30) — the PoW check I added rejected every locally-submitted share
  fleet-wide for ~30 minutes. pool_sv2 sends share_hash.to_string() (display order, reversed);
  verify_pow_preimage compares internal order. Fixed, and the decision extracted to a testable
  function because two earlier tests passed against the broken code.
• Deploy throughput gate (58c4acec0) — the outage passed every check deploy-node.sh made. The
  one functional check was explicitly skipped for ghost-pool, and the SV1 probe it skips never sends
  mining.submit. Now every binary gets a before/after share-throughput comparison and rolls back
  automatically. Its own self-test caught a real defect in the first version: [ "" -eq 0 ] is TRUE in
  bash, so an unreadable count would have rolled back a healthy binary.
• Every payout proposal rejected: vm1's node_payout_address is also a miner's address #587 (3ea506cb8) — the duplicate-address check spanned miner_payouts chained with
  node_payouts, and vm1's node_payout_address is also the rank-2 miner's. Every proposal was
  rejected 6-of-8, every round. Now per-list. No height gate needed: the check exists only in the
  voting path, so a partial roll costs at most quorum (the status quo) and block validation never
  consults it.
• Checkpoint tolerance lets a proposer skew every address and be ratified (audit H-5) #606 (e9ca0c446, armed at 961_700 in 3944f4af3) — report-and-median adoption. See below.
• Tip-change payout visibility (a0ee24219) — three of four outcomes logged at debug!, so only
  SUCCESS was visible. Now every non-arming outcome warns and says the miners get nothing for that
  block.

Corrections to this checklist

• B1 — RETRACTED, releases ARE signed. Already corrected above. v1.11.16/.18/.19/.21 all
  carry SHA256SUMS.txt.asc; v1.11.21 verifies (Good signature, EDDSA 852C2B3190F5B928).
• --ledger-export OOM-killed at 2.77M rows: the #558 reconciliation cannot be run #584 — CLOSED with measurement. 38 MB peak RSS exporting 3,011,866 rows in 18.5s under a
  hard 700 MB cap. The 1.57 GB OOM is long fixed.
• CI never runs 13 of 14 integration test targets — payout_ledger_e2e has been red on main unnoticed #580 — mostly stale. A dedicated integration-tests job already runs cargo test --tests
  workspace-wide, plus an mpc-tests job. Only the 18 integration_tests_sv2 targets remain
  excluded, which the workflow documents as separate work needing external services.
• ghost-pool logs retain only ~75 minutes: disk at 85-89% caps journald, and one WARN is 82% of volume #582 — partially stale. Log retention measured at 183-482 min across the fleet, not ~75.
• vm5/vm6 are 4 GB nodes with a 2.5 GB database that only ever grows — working set no longer fits in RAM #556 — partially resolved. vm5 is 59G at 46%; vm6/vm7 still 30G at 89%.
• B4 — DORMANT, not live. [registry] is in no node's pool.toml and there were zero
  registry/Cloudflare log mentions in 60 minutes. Real cleanup (3,467 lines, 6 reference sites) and
  a repo-level footgun, but not an active central dependency. The only part with design content is
  that --status reports via the registry and must be repointed at the mesh peer endpoint first.
• H-7: challenger /24 subnets are self-reported, so the diversity floor is fabricable (was: capability proofs do not prove the capability) #605 — the issue names the wrong function. probe_stratum_port (the "bare TCP connect") is not
  in the live path; its only callers are its own tests. The live check is verify_stratum, an HTTP
  GET asking the target whether it serves stratum (resp.success && resp.connected, both
  self-reported, URL carrying unsigned=true). So a node with no stratum port at all passes.
  Worse than the issue states, and the fix is larger than upgrading the probe.
• vm1/vm2/vm3 are at 100% inbound capacity again — maxconnections=125 is saturated three days after the 50->125 raise #572 — CONFIRMED still saturated. 128-131 established ghostd sockets against
  maxconnections=125 on all four production nodes. Caveat on the issue: the count includes
  localhost RPC/ZMQ so it is an upper bound on peers, but three nodes landing on exactly 128
  independently is the cap binding.
• ghost-pool API hangs on vm5/vm6: 2.66M-row ledger scan every 30s starves the async runtime #554 — REOPENED. It had been closed while the memoisation never landed, and the cost has grown
  ~6x: 3,012,606 rows, proxy scan 10.3s wall / 2.8s CPU vs the original 2.66M / 1.6s. The old
  "pure function of (cutoff_ts, height)" note was WRONG — it reads paid_in_proposal_hash IS NULL and joins mutable miners.payout_address, so naive memoisation serves a stale ledger after
  settlement and could re-pay already-paid shares. Design and correct invalidation now on the
  issue.
• Every database operation blocks a tokio worker on one global mutex — no spawn_blocking, one connection for the whole process #537 — CONFIRMED real. Every DB call takes one global mutex (inner.write_conn.lock(),
  database.rs:662) from synchronous functions in async contexts, with no spawn_blocking
  anywhere in ghost-storage. Compounds with ghost-pool API hangs on vm5/vm6: 2.66M-row ledger scan every 30s starves the async runtime #554: each multi-second scan blocks a tokio worker
  AND locks every other query out.

Payouts — corrected picture

The pool is arming approved payout outputs on every template (Built coinbase with approved payout outputs ... miners=6 nodes=8, six of eight nodes arming in a 90-minute window). What has not happened
is a block win — won_blocks has 0 rows. That is luck, not a defect.

I earlier reported "no payout proposals are being made at all" and that was wrong: I sampled 2 of 8
nodes over 25 minutes when only ONE node proposes per height (round-robin) at ~8-minute blocks, so zero
observations was the predicted result of a healthy fleet. Corrected, and the visibility fix above
exists so the ambiguity cannot recur.

So #587 is not the payout blocker it appeared to be. It was a real defect, worth fixing, and the
live rejection loop had already stopped.

Gates

gate	height	state
SHARE_ADDR_BIND_HEIGHT	961_100	armed, live on all 8
OBSERVED_SETTLEMENT_HEIGHT	961_400	armed, live on all 8
PAYOUT_MEDIAN_ADOPTION_HEIGHT	961_700	armed, rolling now

Both of the first two were briefly LOST — the H-13 rollback removed them from the fleet while they
remained armed in main, which is worse than unarmed because they look scheduled and will not fire. Both
restored and verified by marker in the deployed binary.

At 961_700, reporting and median adoption begin in the SAME block — reports are emitted only at/above
the gate, by the same predicate that switches adoption, so there is no ramp and the first real medians
are the live ones. Watch the first checkpoints for too few reports to take a median (fewer than 6
reporting; checkpoints will not finalise, deliberately, since falling back to the proposer's list is the
vulnerability) and for the proposer-skew warning.

At least 6 of 8 nodes must carry 3944f4af3 before 961_700. Two may lag; three cannot.

Genesis signer set — decided and implemented

Option D. config/genesis-signers.txt: 8 fleet nodes + 4 offline-only keys = 12 signers, threshold
ceil(12x67/100) = 9. The fleet's own 8 keys are BELOW the threshold, so compromising every production
node no longer yields control of miner discovery.

An earlier draft said to hold 3 of the 8 FLEET keys offline. That was wrong on its premise — those ids
are the nodes' operational identity keys, used at 32 signing sites; a node cannot run without its own.
Offline signers must be separate keypairs ADDED to the set, and adding them moves the threshold: 3
offline lands exactly on it and buys nothing; 4 is the minimum that works.

All 8 fleet ids were re-read from each node via --show-identity, the only trustworthy method. Two
earlier attempts were wrong (the peers table returns the most-recently-seen PEER; received_by misses
miner-less nodes entirely).

Freeze risk is explicit: 12 needing 9 means at most 3 may be lost.

[defenwycke]

B4 verified — and unlike three other items checked tonight, the description is ACCURATE

• bins/ghost-registry: 7 files, 3,467 lines ✓
• config/registry.toml: enabled = true, zone_id = "0d7a815b553e01be9a3dbee27fb0283b",
  api_token = "${CLOUDFLARE_API_TOKEN}" ✓ — a real Cloudflare zone id committed to a public repo. Not
  a credential, but it identifies the zone, and it is one uncommented block from a live central DNS
  dependency.
• --status genuinely depends on it: use ghost_pool::registry::NodeStatusResponse, requires
  config.registry, and queries {registry.url}/api/v1/nodes/{node_id}/status ✓
• ghost-web/docs/load-balancer.md:186 says the design "was abandoned" while the code still compiles
  and is wired in ✓
• Dormant on the fleet: [registry] present in 0 of 3 nodes checked, 0 registry/Cloudflare log
  lines in 60 minutes (measured earlier today)

Repointing --status: two of its fields cannot be reproduced, and that is the point

NodeStatusResponse carries registered, in_dns, healthy, accepting_miners,
excluded_for_load, load_percent, rank_in_region, total_in_region, healthy_in_region.

registered, rank_in_region and total_in_region are registry concepts — they only mean
something if a central service is ranking nodes and managing a DNS rotation. There is nothing to
repoint them at, because the thing they described no longer exists. Reproducing them would be
reimplementing the registry.

So the honest replacement reports what a node can establish for itself:

field	source after the deletion
healthy	its own /health on :8080
accepting_miners, load_percent, excluded_for_load	its own connection count vs maxconnections
fleet size / healthy peers	the mesh peer registry — replaces the *_in_region counts
registered, rank_in_region	dropped — no central authority to be registered with or ranked by

in_dns can be kept, and better than before. The node can resolve the mining DNS name itself and
check whether its own address is in the answer. That is a direct observation rather than a central
service's claim about it, and it would have surfaced #596 (vm5-8 absent from DNS for weeks) the first
time anyone ran --status on those nodes.

Sequence

1. Rewrite --status against local /health + mesh peers + a self-resolving in_dns check. Land and
   verify on its own — while the registry still exists, so there is a working comparison.
2. Then delete: the crate, the Cargo.toml member line, bins/ghost-pool/src/registry.rs, the 6
   RegistryClient sites in main.rs, config/registry.toml, and the systemd/installer references.
3. Rewrite load-balancer.md:186 so "abandoned" is true rather than aspirational.

Deliberately not done in one pass: a 3,500-line deletion that compiles but silently guts an
operator-facing command is exactly the failure this ordering avoids.

[defenwycke]

Re-verified against c49ed365b and the live fleet, 2026-08-05

This checklist was 2 days old and already wrong on several items. Re-checked every section against
the tree or the fleet rather than carrying the note forward. Corrections below; the sections not
mentioned still stand.

§1 Payouts — 3 of 6 now closed

• Every payout proposal rejected: vm1's node_payout_address is also a miner's address #587 CLOSED · Checkpoint tolerance lets a proposer skew every address and be ratified (audit H-5) #606 CLOSED · --ledger-export OOM-killed at 2.77M rows: the #558 reconciliation cannot be run #584 CLOSED
• The chain does not pay what the fleet ratified — settle from the mined coinbase (audit H-3) #601 open. OBSERVED_SETTLEMENT (961_400, ~36h out) partially addresses it, and that gate's
  own doc already records the gap as known at arming.
• Only the block-submitting node settles the ledger, so a win pays the same work twice #589 open, same gate.
• Solo mining cannot produce an approved coinbase on mainnet; build_coinbase_solo_mode is unreachable #592 open and CONFIRMED: build_coinbase_solo_mode has exactly one occurrence in the tree —
  its own definition at template.rs:1498. No call site.
• ⚠ Unchanged and worth restating: won_blocks is empty. The pool has never won a block on
  mainnet, so none of this section can be demonstrated live, only made correct and tested.

§2 Gates — the "not on the fleet" warning is resolved

All armed gates are in the binary all 8 nodes run. SHARE_ADDR_BIND fired 2026-08-05 and the
fleet held: 8/8 in lockstep at 961147, zero signature failures fleet-wide, shares flowing.
Remaining: OBSERVED_SETTLEMENT 961_400 (~36h), PAYOUT_MEDIAN 961_700 (~86h),
STRATUM_HANDSHAKE 962_000 (~136h).

MESH_NODE_LIST_CHECKPOINT is landed but dormant, held on #625.

§3 Release engineering

• CI never runs 13 of 14 integration test targets — payout_ledger_e2e has been red on main unnoticed #580 CLOSED.
• New: record-tests.sh is weaker than CI: local clippy runs without --all-features or -D warnings, so a green gate is not a green CI #626 — record-tests.sh runs clippy without --all-features or -D warnings, so a
  green local gate is not a green CI. It cost three CI rounds and two 60-minute canary soaks on
  feat(discovery): land the signed mesh node-list checkpoint + miner shim (#599) #624, and --all-targets later caught a #[cfg(test)] impl that cargo build passed clean.

§4 Branch hygiene — DONE

• B2 chore/cleanup-2026-07-23: superseded by chore: remove dead code and add two gates that keep it out #500 (122 files / −7,367 vs the branch's 129 /
  −7,529; ghost-template and ghost-registry already gone from main). Deleted.
• B9 feat/dashboard-next: all 5 commits landed via dashboard: land v0.2.4 onto main #451. Deleted.
• Land the decentralised mining-discovery shim — rebase pool-hardening (f75fb3279) onto main #599 DONE — shim landed as c49ed365b; 9 of pool-hardening's 10 unique commits were
  already on main via fix: share attribution credited the operator address instead of the miner #422/fix(tdp): run the Noise handshake off the accept loop; reconnect instead of exiting #423/fix(storage): stop rebuilding the whole database every hour #424/translator: open the channel on subscribe, and carry the full identity in the TLV #447. Deleted.
• All three archived as archive/<name> tags first; recovery verified by restoring one.

§5 Dashboard — the zero-tolerance item is resolved

• B3 — the fake success is GONE. Routes now call swarm_not_implemented(...) and the old
  behaviour is documented in the past tense. feat(dashboard): build the real /api/v1/swarm/nodes/* fleet-control API #403 remains open as a feature (the real API still
  does not exist) but is no longer a v1 blocker, which is the distinction this checklist needs.
• Dashboard: warn that the node reward address must not be an address anyone mines to #588, feat(dashboard): expose maxconnections as an adjustable node setting #499, B5, B8 unverified in this pass — still open as written.

§6 Fleet

• vm5-8 are absent from pool.bitcoinghost.org — half the fleet has never received a miner #596 CLOSED — dig pool.bitcoinghost.org now returns all eight IPs.
• ghost-pool logs retain only ~75 minutes: disk at 85-89% caps journald, and one WARN is 82% of volume #582 half-resolved: retention was "~75 minutes", now spans >24h after the journald flush fix.
  vm1 disk still 84%, so the disk half stands.
• vm1/vm2/vm3 are at 100% inbound capacity again — maxconnections=125 is saturated three days after the 50->125 raise #572 has MOVED and its text is now wrong: vm1-4 sit at 58-75% of inbound capacity, not 100%.
  vm5-8 are pegged at 39/39 with maxconnections=50. Held on pool: the maxconnections ceiling is derived from instantaneous MemAvailable, so it refuses valid values and accepts unsurvivable ones #614 (operator decision).
• Every database operation blocks a tokio worker on one global mutex — no spawn_blocking, one connection for the whole process #537 CONFIRMED open: zero spawn_blocking in ghost-storage, still Mutex<Connection>.
• ghost-pool API hangs on vm5/vm6: 2.66M-row ledger scan every 30s starves the async runtime #554 CONFIRMED live on vm6: /api/v1/mining/status timed out at 30s while the checkpoint
  route answered in 1.26s on the same process, seconds apart.

§7 Mining path

• translator: set_difficulty is never written straight to the wire — every change waits for the next mining.notify #455 CLOSED — verified on production vm1 with the issue's own probe: the pw-difficulty case
  recorded here as FAIL now passes at 1,000,000 on the first set_difficulty.
• H-7: challenger /24 subnets are self-reported, so the diversity floor is fabricable (was: capability proofs do not prove the capability) #605 RE-SCOPED — 3 of its 5 items were already built (Stratum handshake armed at 962_000;
  ArchiveTx path built but dormant; H-8 wired). The GhostPay claim does not hold against the live
  service: a fabricated epoch is rejected. What remains is H-7, the self-reported /24.
• Share webhook: loopback-only auth and no PoW verification at ingest (audit H-13) #603, Mesh hardening: replayable envelopes and no per-IP inbound cap (audit H-11, H-12) #604, pool_sv2: the extranonce is delivered only at channel open, which is gated on payout identity #411 unverified in this pass.

---

Net effect

Four items on this list were already done and the list did not know: #596, #599, #455, and B3's
zero-tolerance violation. That is the substance of "the backlog never shrinks" — throughput was
never the problem (20 issues closed in the 3 days to 2026-08-05, 30 open, none older than 11 days),
the map was.

Suggested rule going forward: anything discovered that does not block a line in §1, §2, §6 or
§7 gets a v2 label on sight. Only 3 of 30 open issues were marked v2, so everything competed for
attention equally.

[defenwycke]

Re-verified against the live fleet at tip 962,847 (2026-08-17)

This checklist was verified at tip 960,852. The chain has moved ~2,000 blocks since, so
the height-dependent items have resolved themselves and the payout items have not. Verified
on vm1 against the running process, not against the tree.

⚠ /usr/local/bin/ghost-pool on vm1 is dated March and is not what runs. The live binary
is /opt/ghost/bin/ghost-pool, deployed 2026-08-16 16:01, started 16:12. Check
/proc/<pid>/exe, not which.

Section 2 — gates: now moot, all three fired

The concern was that these were armed in main but absent from the fleet, so they would look
scheduled and never fire. They fired. vm1 has the era boundaries persisted:

Restored address-bind era boundary   activation_round=111556
Restored tier-commitment era boundary activation_round=121703
Derived PoW-header era boundary       activation_round=91999 gate_height=959030
Seeded chain height from Core before gate evaluation height=962754

OBSERVED_SETTLEMENT_HEIGHT = 961_400 is also live: the height is passed into
SettlementObserver, so the arm/dry-run decision is per block rather than latched at startup.
Nothing has settled because the pool has won no block, which is section 1's problem, not this one.

Minor defect found here: the startup banner prints
Settlement observer started (dry run below the activation height) unconditionally, so it
claims to be below the activation height while running 1,447 blocks above it. It cannot report
the state it exists to report.

Section 1 — payouts: still blocked, and now quantified

vm1, last 24 hours:

checkpoint votes	568
voting reject	333 (59%)
too few reports to take a median — not finalising (#606)	132
GHOST-02 split mismatches	105
BFT quorums reached	7

332 of the 333 rejects name one single address, with byte-identical numbers every time:

reason=address dc318440b6dd work 2503874639417892143104 vs 2671966068547118956544

That is a static 6.71% disagreement on one address's accumulated work — not drift, not a
tolerance that needs widening. The proposer credits that address ~6.7% more work than vm1
recomputes, the same amount on every attempt, so nearly every checkpoint is rejected and the
payout path never finalises. This one address is the practical blocker under this whole section.

The GHOST-02 rejections are consistent with it: 5 expected payout addresses vs 5 in proposal
— the address SET agrees, the amounts do not.

Investigation of that address is now the active thread.

[defenwycke]

Sequencing corrected: Stage 6 deletion happens BEFORE this release

The checklist's Sequence section said Stage 6 deletion comes after the release. SHARE_SHARD_BUILD.md said "first September release". The work has in fact been running before v1 since step 3 shipped. All three could not hold.

Ratified as "before v1", and SHARE_SHARD_BUILD.md has been updated to match.

Two reasons it is right rather than merely convenient:

• A public release should not carry a dead payout path plus a GHOST-03 sweep doing 3,392–6,507 writes per node per day into a 5.3 GB database, repairing a ledger nothing reads any more.
• This release exists so a stranger can run the ninth node. That person should never meet the legacy machinery — every piece left in is surface they can hit and we would have to explain.

Current state: step 3 shipped dark (#731), armed at 964,100 (#738), fires in ~68h. Release B is written and green on feat/stage6-release-b, and merges once the gate produces its evidence.

⚠ Two items in Section A of this checklist have also moved and are worth re-reading before anyone schedules from them: #589 is closed (superseded by the shard's maturity settlement), and #605's remaining work is arming two dark gates (ARCHIVE_TX_PROOF_HEIGHT and ADDRESS_PROOF_HEIGHT, both u64::MAX), not building proofs. Section A is smaller than it reads.

[defenwycke]

The remaining trust-boundary work is ARMING, not building

Audited every activation gate on 0abf2ea5a (2026-08-23). Four ship dormant at u64::MAX, and
three of them are the open items in section A. They are all already built.

gate	issue	what it turns on	arming basis
ADDRESS_PROOF_HEIGHT	#605 H-7	a challenger's /24 counts toward diversity only after a reachability probe at the claimed address	measured, holds
ARCHIVE_TX_PROOF_HEIGHT	#605 H-6	archive challenges demand tx-level data with merkle-branch verification	needs its own measurement
MESH_ENVELOPE_V2_HEIGHT	#604 H-11	envelope signature binds timestamp + message type; per-sender replay floors persist across restarts	needs a fleet on the v2-aware binary
MESH_NODE_LIST_CHECKPOINT_HEIGHT	#402	decentralised mining discovery	operator decision, not a blocker

So the shape of what is left changed: it is a deploy plus a sequence of arming releases, not a
redesign.

H-7's basis re-measured today, and it holds

24h to 2026-08-23, three nodes:

node	passed	failed	rate
vm1	1,231	15	1.2%
vm5	1,108	34	3.0%
vm8	1,400	12	0.9%

61 of 61 failures were Unreachable. No WrongSigner, no NonceMismatch, no BadSignature.
Only a cryptographic failure votes FAIL — Unreachable and NotSigned record nothing — so arming
cannot strip an honest node's subnet on a link hiccup. This reproduces the 08-22 measurement
(9,681/181) a day later on a different window.

Sequencing constraints — these cannot all land together

1. Nothing can be armed until the fleet is deployed. It is on 1.11.26; main is 7 commits
   ahead. MESH_ENVELOPE_V2_HEIGHT is the strict case — its own doc notes that arming it while any
   node is on an older binary "partitions the mesh completely".
2. One gate per height, spaced. The same reason PAYOUT_MEDIAN_ADOPTION_HEIGHT was put ~300
   blocks after OBSERVED_SETTLEMENT_HEIGHT: two behaviour changes on one block make a divergence
   unattributable to either.
3. Nothing near PAYOUT_FROM_SHARD_HEIGHT = 964_100 (~26 Aug). That gate takes the BFT vote out
   of the payout path, and it must be the only variable when it fires.
4. ⚠ Grep the ops and smoke scripts before arming anything that moves a value — arming a tier
   gate previously broke every deploy because deploy-node.sh's smoke test asserted the old one.

Proposed order

964_100 payout gate fires and is verified → Release B (#750) merges → ADDRESS_PROOF_HEIGHT
(basis already measured) → MESH_ENVELOPE_V2_HEIGHT → ARCHIVE_TX_PROOF_HEIGHT once its own
basis is measured.