The chain does not pay what the fleet ratified — settle from the mined coinbase (audit H-3)

[defenwycke]

template.rs mutates the approved proposal per node to match local template fees: surplus goes to treasury, shortfall comes out of treasury then node payouts largest-first. M-28 recomputes from the adjusted proposal, so each node is internally consistent — but the fleet is not, and the chain pays whatever the winner's mempool produced.

Consequences:

• settle_paid_block credits the ratified treasury amount, which was never paid on-chain
• dashboard and payout rows disagree with the chain
• BFT approval truthfully pins only the miner split; treasury and node amounts actually paid are the winner's
• a node can shrink on-chain treasury within the drift bound by aggressive template filtering
• post-gate fee increases are uncapped (the H-04 2x cap is pre-gate only)

Fix: settle and record from the actually-mined coinbase — the winner already parses it for M-28. Cap post-gate surplus/shortfall with a deterministic sink. Longer term the D12 payout-identity tag makes this a lookup.

Depends on / pairs with #589.

[defenwycke]

Confirmed against the tree and the fleet; fix in #645

The mechanism is exactly as filed, verified at afed3d9c1:

• build_coinbase_parts_with_payout_snapshot adjusts the ratified proposal per node (surplus → treasury; shortfall → treasury then node payouts largest-first) and computes the M-28 commitment from the adjusted proposal.
• Both settlement paths settled the ratified one: apply_settlement credited proposal.treasury_amount and recorded the ratified outputs hash. The observer's tag lookup lands on the stored proposal, and settlement.rs's own module doc concedes the mined coinbase "matches no stored proposal".

Live magnitude (vm5, 2026-08-11, times UTC): 221 Adjusted payout: fee drift absorbed by the treasury events in 24h, every one original_fees=0, available_fees≈3.8–4.3M sats. So this is not marginal drift — the ratified proposals carry tx_fees = 0, and the ENTIRE fee value of the block (~1.3% of the coinbase) lands on the treasury at build time. On the next win, chain-paid treasury exceeds every node's would-be credit by ~4M sats. settled_blocks and won_blocks are both empty fleet-wide, so nothing historical changes meaning.

Two adjacent findings:

1. The payout tag lied on a fallback coinbase. The builder stamped the tag from payout_snapshot even when the proposal fell back (stale subsidy, M-07, unabsorbable drift) and the outputs were the single fallback output. A won block like that would be false-settled by every observer — shares marked paid by a block that paid only the pool fallback address. Today M-28/H-11 stop such a submission, so it is a landmine rather than a live hole; defused in Settle from the mined coinbase, not the ratified proposal (#601) #645 (no proposal → no tag).
2. Why do ratified proposals carry tx_fees = 0 post-gate? The post-gate comment says fees "were already shared into the node reward pool when the mesh ratified this payout", yet the observed proposals set tx_fees = 0, which routes the whole live fee value to the treasury via the drift path on every template. Working as coded — the coinbase balances — but if the node pool's ratified amounts are ALSO derived from a checkpoint fee figure somewhere, fees may be counted in two places. Worth a separate look; deliberately not touched in Settle from the mined coinbase, not the ratified proposal (#601) #645.

The surplus/shortfall cap with a deterministic sink from this issue's fix sketch is NOT in #645 — it changes live coinbase construction and needs an operator decision on where capped value goes. With settlement now recording chain truth, the drift is at least visible and auditable per block.

Rehearsed on regtest against a real Ghost Core through the new path: settle → reorg → reverse → return → settle.

[defenwycke]

Investigated the tx_fees=0 question flagged during #645. It is not a fee double-count — it is a fee under-count at ratification, and the sign matters.

Root cause

The payout proposal is built at tip change (payout_for_tips.handle_block_found), reading get_current_block_info() at that instant. The template has just been reset for the new height and carries almost no mempool transactions, so the ratified proposal records tx_fees = 0.

Evidence (vm5, 24h)

• 197 of 243 Adjusted payout events have original_fees=0 exactly. The remaining 46 all share a single value (25462), consistent with the known re-propose loop resubmitting one proposal rather than mempool variance.
• Live template sampled mid-block: 4,834 txs, 4,605,029 sats in fees. The fees are real and substantial by the time a block could be won.

Consequence

miner_pool is documented (payout.rs) as having the 1% levied on subsidy + fees:

Post-gate the fees are already inside miner_pool (the 1% was levied on subsidy + fees)

With tx_fees=0 it is 99% of subsidy alone. The post-gate surplus branch then adds the whole real fee amount to treasury_amount. Net effect: roughly 1.5% of the coinbase moves from the 99/1 miner split into the treasury.

Unrealised so far — won_blocks=0 fleet-wide, so no miner has been shortchanged yet. It bites on the first won block.

Suggested fix

Narrow: the proposer samples fees at the single worst instant. Ratify from a filled template (or carry the last non-zero estimate) rather than the just-reset one. Determinism is unaffected — whatever the proposer records is BFT-ratified and every node then agrees — and it restores the treasury sink to absorbing genuine drift instead of 100% of fees.

Bearing on the cap + sink

Post-gate surplus is currently uncapped (saturating_add(extra) straight to treasury). The pre-gate H-04 "2x original" cap cannot be reused post-gate: with original_fees=0, 2x0 = 0 would cap away every legitimate sat.

Worth fixing the sampling before sizing a cap — otherwise the cap gets sized against a drift that is currently 100% of fees by accident.

[defenwycke]

Direction change on this issue, decided by the operator.

The sampling fix landed; the cap will not

#652 (merged, deployed) fixed the sampling: proposals were built from the coinbase-only template published on the new-block ZMQ event, so they ratified tx_fees=0 and the entire real fee drifted to the treasury. That is fixed — proposals now carry a real fee estimate.

PR #655 then implemented a cap and sink for the residual drift. It is now parked in draft and will most likely not be merged, because the residual drift is itself avoidable.

Why the cap is the wrong layer

The BFT checkpoint does not ratify satoshis. compute_ledger_root commits to miners: &[(String, u128)] (work) and nodes: &[(NodeId, i32)] (capability shares). Satoshis appear only afterwards, when PayoutEntry { amount: Satoshis } is built from an estimate, and adjust_proposal_for_available_fees patches them when reality differs.

Drift is therefore an artefact of converting work→sats too early, not a property of the system.

Derive late

Convert at coinbase-build time, from the ratified work and the fees actually in the template:

• miners receive 99% of (subsidy + real fees) split by work, always
• drift is zero by construction — no cap, no sink, no overflow ordering
• verification gets stronger: a validator recovers the fee total from the block (coinbase value − subsidy), so the block declares its own fees and no node has to agree with another about them

Measured sizing (vm5): subsidy 312,500,000 sats, fees 2,549,360 (0.81% of coinbase), typical drift ~1–1.5M sats/block.

This is also how docs/SHARE_BATCH_CHAIN.md already specifies it — "payout, coinbase and validation are all deterministic functions of the adopted batch" — so derive-late moves toward the target design instead of patching the path being replaced.

Next

Being sequenced into the SBC completion plan, which will state whether derive-late lands before the WP-6 cutover, is folded into it, or is subsumed by it. #655 stays open as a possible bounded fallback during migration.