The Transaction

A settlement transaction follows from its proof. Nothing in it is chosen by whoever sends it. That is what lets every node build the same bytes, and what makes “who posts the settlement” a non-role.

Shape

inputs
  0  the pool coin              script path: the settle leaf for this shape
  1  the deposit inbox          when deposits are waiting
     or the exit inbox          at a drain (every 6th settlement)
  2  the deposit inbox          at a drain, when deposits are waiting (since 2026-11-06)

outputs
  0  the new pool coin          same script, value V'
  1  the caboose                330 sat: OP_RETURN of the new state hash, inside P2WSH
  2  the vault                  Σ payouts, only when there are payouts
  3  the anchor                 240 sat, pay-to-anchor (P2A), for fee bumping
     a drain adds a fresh exit inbox and its caboose

There is no funding input and no fee output. The miner’s fee is inputs minus outputs. The value rule makes that Σfee − Σsats − 570: the fees the contributions paid inside their proofs, less the provers’ pay (Σsats, see paying the provers), less the caboose and the anchor (330 + 240 sat). A drain pays two cabooses and the anchor, 900 sat.

Fee bumping

The miner fee is fixed when the proof is made, about an hour before the transaction can be sent. If fees have risen meanwhile, anyone who wants the settlement mined sooner spends the 240-sat anchor in a child transaction that pays more (child-pays-for-parent). A wallet waiting for its payment, a prover waiting for its pay, the next settlement’s builders: each has a reason to, and none has to be trusted to. Measured on a node, a 99,894 vB settlement plus a 137 vB child fits under the 101 kvB cluster limit.

Standard, always

Settlements are standard transactions under Bitcoin Core’s default relay policy: under 100 kvB, witness items within the limits, minimal pushes, on a 0xc2 leaf the node has activated. The design rule is that the pool never relies on sending a transaction to a miner by any other route. That is why the 100 kvB standard limit, not the block size, caps a settlement.

How a leaf checks its own transaction

Bitcoin script cannot read the transaction it is in. GSR’s restored OP_CAT makes a trick possible. The leaf builds the transaction’s signature message from pieces in the witness, computes a Schnorr signature for a fixed key whose nonce and public key are both the generator G (so the signature is a hash the script can compute itself), and checks it with OP_CHECKSIG. If any output differed, the message would differ and the check would fail.

The same trick rebuilds the previous transaction from hints and checks it against the outpoint being spent. That is how the leaf reads the old state from the caboose and checks lineage back to the genesis. Each rebuilt previous transaction is kept under 520 bytes of non-witness data by design, so the rebuild stays cheap.

The trick needs one ground value: a sequence number tried until the signature hash ends in the right byte. The rule is “the first counter that works”, so everyone finds the same one (about a second for a three-input drain, on a 14-core Mac).

Why one transaction

An earlier Cheshire, on a signet with only OP_CAT, spread one settlement over about 156 transactions (about 1.87 MvB), and could not tie the published records to the proof at all. GSR’s larger stack and item limits let the whole verifier run in one input, so that path was removed on 2026-11-03. The git history keeps it, as evidence that a pool with OP_CAT alone is possible; the design described here is the one-transaction one, and it needs GSR.