Skip to content

Order states

An order shows you one of four states. They are deliberately coarse: the underlying machine has more steps, and most of them are not decisions you can act on.

StateWhat it coversDo you need to do anything?
Awaiting paymentThe order is quoted and waiting for the commit address to be fundedYes. Pay it, or the order sits here
Creation in progressPayment seen, reveal built, broadcast, confirmed, being indexedNo. This runs without you
Wallet visibleThe indexer and your wallet both agree the asset existsNo. This is done
FailedSomething needs attentionYes. See recovery routes

The full status line for the middle state says what it is waiting on:

Creation in progress, waiting for chain, indexer, and wallet evidence.

Why “in progress” outlasts your confirmation

Section titled “Why “in progress” outlasts your confirmation”

Broadcast, confirmed and indexed are all still Creation in progress. The order only reaches Wallet visible when the indexer and your wallet agree the asset exists.

Claiming success at broadcast would be right most of the time and wrong in exactly the cases where being wrong costs you the most. A transaction that confirmed but was not credited by a protocol index is the clearest example: the chain agrees, and you still do not have the token.

Inscribe orders do not have one.

The hour on the screen is the life of the price quote. When it passes, the quote is no longer good and you should start a fresh order at a current price. What does not happen:

  • the order is not deleted;
  • the signing key is not erased;
  • the commit address stops being checked.

The address keeps being checked on a slowing schedule, so a payment that arrives late is still detected and reconciled.

A signing key is discarded in only two situations: after a confirmed successful spend, or after an explicit recovery that hands control elsewhere. Never because a provider timed out, a lookup returned nothing, a retry limit was reached, or an hour passed.

PropertyValue
Check intervalEvery 10 seconds
Confirmations needed for a standard single inscriptionZero. An unconfirmed payment is enough
Which payment is used if several arriveThe one matching the quote exactly, then the smallest that covers it

Preferring the smallest sufficient payment is deliberate: taking the largest would swallow an accidental overpayment that belongs to you.

Bulk jobs fan a payment out across many addresses first, and a fan-out that gets reorganised would strand the whole job.

ItemsConfirmations before the job proceeds
Up to 22None
23 to 5001
More than 5002

Reveals are then broadcast in chunks of no more than 24, because Bitcoin mempool refuses a chain of more than 25 related unconfirmed transactions.

FlowQuote good for
Most flows1 hour
Gallery24 hours
A prepared parent-and-child reveal, waiting for your signature15 minutes

Underpaid. The order records it and keeps checking. Top the same address up to the quoted amount and the flow resumes.

Overpaid. The reveal adds an output returning the surplus to the funding address, where the surplus is large enough to cover the extra bytes and still clear the dust threshold. Where it is not, the surplus is added to your inscription output instead.

A reveal that fails to broadcast is retried with backoff, from 30 seconds upward.

The exact signed transaction is written down before the first network call is made, so a retry can only ever resend the same transaction. There is no version of the retry that spends your money twice.