Settlements
A settlement is the one thing the pool coin does. It takes a batch of contributions, proves them all at once, and spends the pool coin into a new one, in one standard Bitcoin transaction.
inputs pool coin (+ the deposit inbox, when deposits are waiting) (+ the exit inbox, at a drain: every 6th settlement)outputs pool coin' V' = V + deposits − payouts − fees caboose 330 sat, carries the new state hash vault Σ payouts, only if someone withdrew anchor 240 sat, so anyone can bump the feewitness the final proof, the records, the previous transactionWhat the pool’s script checks
Section titled “What the pool’s script checks”In order:
- State. Rebuild the previous transaction from the witness, check it against the coin being spent, and read the old state hash, value and epoch. The new epoch is one more. At a drain epoch, the exit inbox must be an input.
- Statement. Read the proof’s public statement: the old and new roots, the deposit, payout and fee totals, and fingerprints of the records and the payouts. The old roots must hash to the old state.
- Verifier. Run the STARK verifier on the final proof, inline, against that statement. This is about 44 kvB of script, the fixed cost of every settlement.
- Records. Check that the published records are exactly the ones the proof covers, using the fingerprint (see records).
- Payouts. Check the payout list the same way, and commit to it in the caboose for the vault.
- Value.
V' = V + deposits − payouts − fees. - Transaction. Rebuild this transaction from the outputs it requires, and check it with a signature the script computes itself, so no output can differ.
Nobody chooses anything
Section titled “Nobody chooses anything”There is nothing in a settlement a builder chooses. The proof fixes the statement. The statement and the records fix the outputs. The one free value (a counter ground for the signature trick) is “the first one that works”. So every honest node builds the same transaction, with the same txid. Broadcasting it is not a race and earns nothing.
| part | size |
|---|---|
| verifier and fixed script | ~44 kvB (the verifier alone 43,565 vB, 2026-11-07) |
| each record | 29 vB |
| a 7-contribution settlement (10 records), measured | 44,200 vB (2026-11-04) |
| records in a standard 100 kvB transaction | about 1,930 |
| vault fan-out | 424 vB + 109 vB per payout |
A settlement with 10 contributions costs almost as much as one with 1,900. At 1 sat/vB that is about 44,000 sat shared by however many paid in. This is the honest weak point against Zcash at low volume: a lone payment in a quiet hour pays for the whole verifier, or waits for company. Fees says how wallets and nodes handle it.
How many records a settlement can carry is also set by the pool: its leaves are built for a record bound fixed when it is made. The default is 1,750, the most the prover can carry (the recursion takes up to 2,500 contributions and 1,750 records; a standard transaction would fit about 1,930), so the bound itself never limits a pool.
Proving is the slow part. On one Mac (14 cores), a whole settlement takes about an hour and ~9 GB of memory. With many provers the jobs run in parallel; the last steps (the top of the tree and the final proof) still take tens of minutes.
The share chain can start proving the next settlement as soon as the current one is proved, before it confirms. Then the two are chained in the mempool and can be mined in the same block. That makes one settlement per block possible in principle. It has run once with real proofs, with a pair; several settlements proving at once has not been run.
The three pages that follow cover the records, the proof and the transaction.