Confirmation and reorg policy
A transaction that has been broadcast cannot be recalled, and a chain that has confirmed a transaction can still reorganise. This page states what Core does about both, per protocol.
Confirmation depth
Section titled “Confirmation depth”Two questions, answered separately.
How deep must a listing’s backing output be? No protocol sets a minimum.
listingMinConfirmations is null for all 29. What replaces it is stricter in
practice: most in-app protocols require the output to be confirmed and
unspent at the moment of the mutation, rechecked each time, rather than buried
to a fixed depth.
How deep must a settlement be before Core records it? Sixteen protocols require one confirmation by default, and several registry entries note that an operator may configure a value between 1 and 100. The other thirteen record no depth, because no supported action reaches settlement for them.
One confirmation is a deliberate default, not a strong finality claim. It means Core has observed the exact expected spend in a block. It does not mean that block is safe from reorganisation. If you are settling a large amount, wait for more blocks yourself before treating the trade as final.
What settlement actually requires
Section titled “What settlement actually requires”Depth is the least interesting part. Every in-app protocol requires a set of exact facts to agree before it will record a settlement. Read one:
Settlement requires the exact confirmed Bitcoin transaction, the consumed transfer inscription, and the buyer indexed balance at stable checkpoints.
The pattern repeats. A confirmation alone never settles an order. What settles it is a confirmed transaction plus the protocol-level state transition that transaction was supposed to cause, observed at a stable index checkpoint. That is why a settlement can stay pending after a block: the chain agreed, and the index has not caught up yet.
Reorg reconciliation
Section titled “Reorg reconciliation”Sixteen of the 29 protocols reconcile automatically. Those keep a durable order journal and, on a reorg:
- append the reorg observation rather than overwriting history;
- reopen or invalidate affected orders deterministically;
- preserve funding, broadcast, settlement, and replacement lineage, so a rebroadcast can be traced to the order it belongs to.
Thirteen do not, and the reason is almost always the same: there is no local executable order state to roll back. A read-only protocol has no order to reopen. A protocol whose execution is delegated has an order book somewhere else, and the registry says so plainly rather than implying Core protects something it does not own.
Two entries deserve their own reading:
- Rare Sats: live checks fail closed when the index reports a reorg. There is no local production order state, because production trading is not implemented.
- Ordex: manual revalidation can change whether an order is actionable. There is no automatic reorg state transition. Refresh an Ordex order and review it immediately before settling.
Dropped and replaced transactions
Section titled “Dropped and replaced transactions”The protocols with automatic reconciliation treat a dropped or replaced transaction as a first-class outcome rather than an error. The order is reopened or invalidated deterministically, and the replacement is linked to the same order. For the generic order book, the registry names the evidence that drives that decision: authoritative chain evidence, not a timeout.
For a protocol without local reconciliation, a dropped transaction is a question you have to answer yourself, in your own wallet or a block explorer.
Every protocol
Section titled “Every protocol”| Protocol | Freshness enforced | Settlement confirmations | Automatic reorg reconciliation | Stated policy |
|---|---|---|---|---|
| Bitcoin Stamps | No | none | No | Universe relies on StampDEX/Counterparty state and has no local rollback worker. |
| SRC-20 | No | none | No | Universe retains broadcast receipts but delegates chain reconciliation to StampDEX. |
| Ordinals | No | 1 | Yes | Authoritative Esplora evidence drives deterministic dropped, replacement, conflict, and reorg reconciliation for generic orders. |
| Runes | No | none | No | Read state follows the authority; no executable order state exists to roll back. |
| Runes (Native) | No | none | No | Read state follows the authority; no executable order state exists to roll back. |
| BRC-20 | No | none | No | Universe has no local UniSat order rollback state. |
| ARC-20 | No | 1 | Yes | The ARC-20 journal retains signed listing proof and converges sold rows through authoritative outspend reconciliation. |
| Atomicals NFTs | No | 1 | Yes | The Atomicals journal retains signed listing proof and converges sold rows through authoritative outspend reconciliation. |
| Realms | No | 1 | Yes | Authoritative winner and outspend reconciliation preserve signed evidence across rollback. |
| Subrealms | No | 1 | Yes | Authoritative winner and outspend reconciliation preserve signed evidence across rollback. |
| Alkanes | No | none | No | Read state follows the authority; no executable order state exists to roll back. |
| Mezcal | No | none | No | Read state follows the authority; no executable order state exists to roll back. |
| TAP | No | 1 | Yes | The authority appends reorg observations, reopens or invalidates affected orders deterministically, and preserves funding, broadcast, settlement, and replacement lineage. |
| DMT | No | 1 | Yes | The authority appends reorg observations, reopens or invalidates affected orders deterministically, and preserves funding, broadcast, settlement, and replacement lineage. |
| TAP on Doge | No | 1 | Yes | The authority appends reorg observations, reopens or invalidates affected orders deterministically, and preserves funding, broadcast, and replacement lineage. |
| DUST-20 | No | none | No | Read-only catalog data follows its discovery source. |
| OP-20 | No | none | No | The read-only feed has no local lifecycle reconciliation. |
| OP Names | No | none | No | The read-only feed has no local lifecycle reconciliation. |
| OP Inscriptions | No | 1 | Yes | The OP Inscriptions reconciler reopens canonically unspent receipts and marks conflicting spends stale. |
| OP_DROP | No | 1 | Yes | Authoritative rollback removes block-bound settlement evidence, marks the intent reorged, and preserves deterministic recovery and rebroadcast lineage. |
| DROPS | No | 1 | Yes | Authoritative rollback removes block-bound settlement evidence, marks the intent reorged, and preserves deterministic rebroadcast lineage. |
| CAT-20 | Yes | none | No | Read state follows tracker/node responses; no local order lifecycle exists. |
| Bitmap | No | 1 | Yes | The authority appends reorg observations, reopens or invalidates affected orders deterministically, and preserves funding, broadcast, settlement, and replacement lineage. |
| UNAT | No | 1 | Yes | The authority appends reorg observations, reopens or invalidates affected orders deterministically, and preserves funding, broadcast, settlement, and replacement lineage. |
| Bitcoin Names | No | 1 | Yes | The authority continuously reconciles active broadcasts, appends reorg observations, invalidates affected orders deterministically, and preserves funding, broadcast, settlement, and replacement lineage. |
| Doginals | No | 1 | Yes | The authority appends reorg observations, reopens or invalidates affected orders deterministically, and preserves funding, broadcast, and replacement lineage. |
| DRC-20 | No | 1 | Yes | The authority appends reorg observations, reopens or invalidates affected orders deterministically, and preserves funding, broadcast, and replacement lineage. |
| Rare Sats | Yes | none | No | Live checks fail closed when ord reports a reorg; no local production order state exists to roll back. |
| Ordex | No | none | No | Manual revalidation can change actionability; no automatic reorg state transition exists. |
What to do about it
Section titled “What to do about it”- Before signing, read the protocol’s own page for its settlement policy.
- After signing, do not treat a single confirmation as final for an amount you would mind losing.
- If a settlement stays pending after several blocks, check
/indexer-healthfor that protocol before concluding anything. A settlement can be waiting on an index rather than on the chain. - Never repeat a transaction from stale market state. Refresh first.