Skip to content

Settlement lifecycle

Source and verification
Owning repository
bitcoinuniverseio/stampdex (private application source)
Source path
settlement worker, reorg watch, confirmation constants
Applicable release
continuous deployment, verify with GET /api/version
Chain and network
bitcoin / mainnet
Lifecycle
stable
Last verified
2026-09-01
This page
Edit on GitHub · Bitcoin Universe platform

Settlement is the part of a trade nobody signs. It runs after the buyer’s payment confirms, and its job is to decide whether the trade is safe to complete.

What settlement checks before it releases funds A left to right pipeline of five steps. The buyer signs the payment. Check one asks whether the payment confirmed on Bitcoin; a payment that never confirms leaves the order Expired with nothing moved. Check two asks whether the expected token balance is verified on the index; if it is not, the order becomes Failed and the buyer BTC is held in the listing escrow rather than released. Only when both checks pass is the token transfer broadcast, and two confirmations later the order is Filled with both sides paid. broadcast yes yes 2 confirmations no: never confirmed EXPIRED nothing moved no: balance unverified FAILED BTC held in escrow PAYMENT SIGNED by the buyer CHECK 1 payment confirmed? CHECK 2 balance verified? TRANSFER SENT broadcast to Bitcoin FILLED both sides paid
Both branches downward end somewhere named. Neither ends in silence. The second branch is the one worth remembering: settlement would rather stop with your BTC in a known escrow address than release it against a balance it could not verify.

Check one: did the payment confirm? A payment that is broadcast but never confirms leaves the order where it was. Nothing was released, and nothing was taken.

Check two: did the tokens actually arrive in escrow? A confirmed Bitcoin transaction does not prove that the SRC-20 transfer inside it was valid. The seller’s balance could have moved between listing and payment. So settlement reads the index and looks for the expected balance in the escrow address.

If that balance does not appear within the grace period, the order becomes Failed and the token transfer is not broadcast. The buyer’s BTC stays in the escrow address. That is the whole reason the check exists.

WaitLengthWhat it governs
Unsigned draft30 minutesA prepared listing nobody signed expires, and its escrow keys are discarded
Buyer lock30 minutesA locked listing returns to the book
Index grace period30 minutesHow long settlement waits for the expected balance before marking the order Failed
Payment claim lease10 minutesMakes a repeated payment confirmation safe rather than duplicating work
Settlement claim lease10 minutesStops two workers settling the same order
Confirmation depth2 blocksHow deep the settlement transaction must be before the order reads Filled
Reorg watch window24 hoursHow far back settled trades are re-checked

Background passes run on their own schedule: expired locks are released about every minute, stale drafts about every minute, settlement about every two minutes, and the reorg watch about every ten.

An order does not read Filled at the first confirmation. It waits for two blocks of depth. An unknown chain tip counts as not settled, never as settled: if StampDEX cannot read the chain, it does not assume the best case.

Bitcoin can reorganise. StampDEX records the block hash and height at which a trade settled, and re-checks trades settled in the last 24 hours. If the settlement transaction has left the chain or moved to a different block, the order returns to awaiting confirmation and the normal settlement pass drives it again.

An unreadable chain reverses nothing. Failing to read a block is not treated as evidence that the block is gone.

Two honest limits on this:

  • The ecosystem registry records that Universe has no local rollback worker for either protocol and relies on StampDEX and Counterparty state. reconcile is recorded as an unsupported marketplace action for both.
  • The reorg path is covered by unit tests but has not been exercised end to end against a real reorg. See Release evidence.

Confirming a payment twice with the same transaction id returns the answer already recorded rather than building or broadcasting anything a second time. Confirming with a different transaction id on the same order is refused outright. Reads and cancels are safe to retry.