Stage 6 Release B: delete the BFT payout vote and the GHOST-03 ledger sweep

[defenwycke]

Stage 6, Release B: the deletion half. Removes the BFT vote from the payout path, makes the
share shard the only ledger a payout can be built from, and deletes the GHOST-03 unpaid-ledger
sweep. +730 / −5,042 across 18 files (measured against main after merging it in).

✅ The gate has fired and the precondition is met

PAYOUT_FROM_SHARD_HEIGHT = 964_100 fired at block 964,100, 2026-08-26 06:01:30 UTC, and the
fleet was observed paying from the shard for ~11 h before this was marked ready. Release A is
gate-reversible without a redeploy; this is not, because it deletes the machinery the gate falls
back to — so the three signals were measured before merging, on all 8 nodes.

Counts come from splitting journalctl -u ghost-pool at the gate timestamp — an 11 h
pre-window against the 10.8 h post-window. A 24 h count straddles the gate and averages the
transition into invisibility.

signal	pre-gate (11 h)	post-gate (10.8 h)
Payout consensus approved	42–47	0 on all 8	the vote this PR deletes has stopped
Paying from this node's own shard view (no vote	0	18–20 on all 8	the shard is paying
payout ledger checkpoint FINALISED	55–56	70–74	continued — the signal that matters

The last Payout consensus approved on vm1 was 05:51:59, 9.5 min before the gate; the first
post-gate FINALISED was 06:02:02, 32 s after it. Checkpoints carry approvals=6 needed=6
throughout, so the 18–21 Aug standoff has not recurred. Zero panics fleet-wide; all 8 on
ghost-pool 1.11.28.

⚠ The no vote rate is ~40–44/day, not the ~22/day this PR originally predicted. Present and
healthy on every node — the estimate was low, the behaviour is not wrong.

One unrelated defect this exposed, tracked separately

Splitting the fee-drift logs at the gate surfaced that payout_fee_estimate() is node-local and
has diverged 125x across the fleet (original_fees 25,030 on vm1 … 3,137,573 on vm6, while
available_fees is ~2.1–2.7M everywhere). Nodes that under-estimate route ~2–2.8M sats/block of
fees to the treasury and node pool instead of to miners; vm6 over-estimates and falls back to a
non-shard coinbase.

This is not caused by this PR and not fixed by it — it lives in template.rs, the gate merely
made the estimate node-local by removing the vote that used to collapse the fleet onto one value.
Worth stating here because a fix cannot rely on resurrecting the vote this PR deletes. Practical
impact is nil while the pool cannot win a block, but it must not ship public unfixed.

Why the vote goes

validate_proposal_split recomputed the miner split from the voter's own local_miner_work
and demanded exact equality. It never inspected a share. Its whole guarantee was "your arithmetic
matches mine", which is only as strong as the tables already agreeing — and when they did not,
that exactness converted divergence into a total payment halt.

Without it, divergence is benign: owed is signed and never clamped, so an over- or
under-payment leaves a residual the next block corrects (SHARE_SHARD.md §4.4, §4.6).
§8 settles the design question: "No consensus on the ledger. Each node pays from its own view."

Share validity is untouched. It is per-share and at receive time — GHOST-09 signature with
receiver and address binding, the PoW preimage check, the difficulty-tier commitment. Delete the
gate, keep the rule.

What is in it

commit	what
379ad92c5	rehome fetch_coinbase_parts into coinbase_verifier — the shard's maturity settlement needs it
ca09d1cd9	delete the legacy BFT e2e tests, now the shard has its own
463445765	remove the BFT vote from the payout path
6bfc3bbd5	make the shard the only ledger; delete the vote's GHOST-02 validator
3f2bc9891	delete the GHOST-03 unpaid-ledger sweep (−870)
3c334ad88	count a pool win on every node, not just the submitter
aadbc6537	delete tip-time settlement — the shard settles at maturity (−1,813)

The sweep was already dead

shard_owns_evidence is true on all eight nodes, so the sweep branch has continued on every
tick since migration v56 landed on 18 Aug. This deletes machinery that was already being skipped.
The round-in-flight repair is kept — one request per tick, scoped to the current round, and
not what flooded.

⚠ The LedgerRequest / LedgerResponse enum variants are kept, inert, for one release.
ConvergencePayload is serde_json externally-tagged, so removing a variant makes a message
from a pre-Stage-6 peer fail to decode as a whole envelope, not just that field. No node
emits them any more, but an operator on an older binary still could. Drop them when no fleet
binary can.

blocks_found had to be fixed here

won_blocks had one writer — settle_paid_block, which runs on the node that submitted the
block. Seven of eight nodes reported 0 for a block the pool genuinely won, and which node
reported 1 was an accident of timing.

The shard's maturity settlement now records it too. That path is chain-derived, so every node
reaches it from the same coinbase at the same depth, and it needs no reorg reversal — a block
COINBASE_MATURITY deep is not coming back. INSERT OR IGNORE keeps both writers idempotent
against each other. Cost is a ~16-hour lag, which is the honest number: it counts blocks whose
coins exist and are spendable.

This is a precondition for deleting settlement.rs, not a tidy-up — that file is the
chain-observed settler, the only path by which a non-submitting node learned of a win.

Tip-time settlement goes with it

SettlementObserver settled the legacy ledger from an observed coinbase at tip. It existed
because the seven non-winning nodes would otherwise still owe work the pool had paid and, being
the majority, would carry that into the next BFT proposal and pay it twice. No vote, no majority
view to poison — and ShareShard::settle_matured reaches the same conclusion from the same
evidence, on every node, at COINBASE_MATURITY instead of at tip.

That depth is why this is a deletion rather than a port: the tip-time settler needed
reverse_settlement and a deferred-settlement table because a reorg could undo what it booked.
A block 100 deep cannot be.

Deleting the observer while keeping settle_paid_block was not an option — the reverser
lived in the deleted file, so the pair would have left settlements a reorg could never undo plus
a won_blocks row inflating the public blocks_found. They go together or not at all.

Kept on purpose: proposal_sync (it answers peers, and a pre-Stage-6 node needs those
answers); settle_block_atomic / reverse_settlement / the deferred-settlement accessors and
their tests, because settled_blocks and deferred_settlements must stay replayable — the same
reasoning that retained the sbc_* tables; and OBSERVED_SETTLEMENT_HEIGHT as a tombstone, since
old logs and the #606 ordering are only interpretable with it.

⚠ crates/ghost-reconciliation/src/settlement.rs is an unrelated module (Ghost Pay L2) and is
not in scope for any of this.

Verification

No live block can validate this — the pool wins one roughly every 161 years. So:

• 485 unit tests pass; the whole suite is green after rebasing onto 0abf2ea5a
• the commitment built from a locally constructed proposal is byte-identical to the one the BFT
  path produced from the same BlockFoundData — this is the load-bearing test, because it proves
  the change is a route change, not an amount change
• set_local_payout_caches_the_proposal_it_publishes pins the settlement precondition:
  approved_payout is set and the proposal is retrievable, which is what makes
  payout_snapshot → settle_paid_block fire
• the new blocks_found test was mutation-checked — it reads 0 with the fix removed
• regtest e2e proves a shard-built, unvoted coinbase is accepted by real ghostd

Rollback

Once merged and deployed there is no gate to fall back to. The rollback is the .bak binary,
which is why this must not ride the same release as a cutover.