Skip to content
Inscribe docs

The life of an order

Most creation flows in Inscribe use two transactions, not one. Knowing which is which explains almost everything else: why you sign once rather than twice, why the app keeps saying “in progress” after your transaction confirmed, and why closing the tab does not lose your money.

The path, end to end

Section titled “The path, end to end”
An Inscribe order from quote to wallet Six stages in order. First, Inscribe quotes the job and gives you one address to pay. Second, you pay that address, which is your only wallet signature for a typical order. Third, Universe watches the address and sees the payment, accepting it from the mempool without waiting for a confirmation. Fourth, Universe signs and broadcasts the reveal transaction using a key held only for this order. Fifth, a miner confirms the reveal. Sixth, the indexer and your wallet agree the asset exists, which is the only point Inscribe calls the order done. You act only in the first two stages. The status shown is Awaiting payment for stages one and two, Creation in progress for stages three to five, and Wallet visible at stage six. Commit and reveal: two transactions, one signature from you 1 Quote One address, one amount YOU 2 Pay the commit Your wallet opens once YOU SIGN 3 Payment seen Checked every 10 seconds UNIVERSE 4 Reveal sent Signed with this order's own key UNIVERSE 5 Confirmed A miner includes the reveal BITCOIN 6 Wallet visible Indexer and wallet both agree PROOF WHAT THE STATUS SAYS Awaiting payment Creation in progress waiting for chain, indexer, and wallet evidence Wallet visible CLOSING THE TAB AFTER STAGE 2 does not lose the order. Stages 3 to 6 run on Universe infrastructure whether or not your browser is open. Home lists the orders this browser started, and reopening one asks your wallet to prove it owns the order before any payment detail is shown. THE HOUR ON THE SCREEN is the life of the price, not the life of the order. Once it passes, the quote is no longer good and you should start a fresh one. A payment that arrives late is still detected and reconciled rather than discarded, and the order's signing key is kept, not erased.
You act in stages 1 and 2. Everything after that happens on Universe infrastructure and on Bitcoin, and continues whether or not your browser is open.

Commit and reveal, in plain terms

Section titled “Commit and reveal, in plain terms”

An inscription cannot be written in one transaction. The content is committed to in the first transaction and revealed by the second.

  1. Inscribe builds the script for what you are inscribing and works out how big the reveal transaction will be.
  2. It generates a fresh key for this order alone and derives one address from it, the commit address.
  3. You pay that address one amount, which covers the reveal’s network fee, the service fee, and the satoshi your inscription will sit on. That payment is the commit transaction, and it is yours: your wallet builds it and your wallet signs it.
  4. Universe spends the commit output in the reveal transaction, which is what actually carries your content onto the chain. It signs that with the order’s own key, which is why you are not asked a second time.

The reveal has your inscription as its first output, the service fee as its second, and a refund output as a third when you have overpaid.

What you sign, and how many times

Section titled “What you sign, and how many times”

One signature, for a typical order. That is the commit payment in stage 2. The reveal needs no signature from you.

Two flows ask for a second signature, and both have a good reason:

FlowWhy a second signature
Parent and childThe reveal has to spend the parent inscription you already own, and only your wallet can authorise that. The order waits for your signature, and the prepared transaction is good for 15 minutes
Bring your own satoshiYou fund two addresses, the commit address and a separate address holding the exact satoshi you want inscribed. The reveal waits for both

For the parent flow there is an extra check worth knowing about: before it accepts your parent, the server re-derives the parent’s output script and refuses it unless it matches what the chain indexer currently reports for that inscription. A parent that has moved since you loaded the page is rejected rather than spent.

How the payment is noticed

Section titled “How the payment is noticed”

Universe watches the commit address rather than waiting for you to tell it anything. A monitor checks waiting orders every ten seconds.

  • An unconfirmed payment is enough. As soon as the payment is visible in the mempool, the reveal can be built and broadcast. A standard single inscription needs zero confirmations to move forward.
  • The smallest sufficient payment is used. If several payments land on the address, Inscribe prefers one matching the quote exactly, then the smallest one that covers it. Taking the largest would swallow an accidental overpayment that belongs to you.

Bulk jobs are different, because they fan a payment out across many addresses first and a fan-out that gets reorganised would strand the whole job:

Batch sizeConfirmations required before the job proceeds
Up to 22 itemsNone. The payment is fanned out directly
23 to 500 items1
More than 500 items2

Batch reveals are also broadcast in chunks of no more than 24, because Bitcoin’s mempool refuses a chain of more than 25 related unconfirmed transactions.

Why “in progress” outlasts your confirmation

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

A reveal that confirmed is not the same thing as an asset you can see and use. The indexer still has to read the block and attribute the inscription, and your wallet still has to report it.

Inscribe treats broadcast, confirmed and even indexed as still in progress, and only says the order is done when the indexer and your wallet agree the asset exists. The status line says so in as many words:

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

This is deliberate. Claiming success at broadcast would be right most of the time and wrong in exactly the cases where being wrong costs you the most.

What the hour means

Section titled “What the hour means”

Most flows quote a price good for one hour. The gallery flow quotes for 24 hours.

The on-screen warning asks you to pay within the hour, and you should: after it passes, the fee rate you were quoted may no longer get your transaction mined, and the right move is to start a new order at a current price.

What the hour does not do is destroy the order:

  • The order does not move to a cancelled or expired state. No such state exists for inscribe orders.
  • The signing key is not erased. A key is only discarded after a confirmed successful spend, or after an explicit recovery that hands control somewhere else. It is never discarded because a data provider timed out, returned nothing, or hit a retry limit.
  • The address keeps being checked, on a slowing schedule, so a payment that arrives late is still found.

If you have already paid and the hour has passed, do not pay again. Go to recovery routes.

When a broadcast fails

Section titled “When a broadcast fails”

A reveal that fails to broadcast is retried, not abandoned. Before the first network call is made, the exact signed transaction is written down, so a retry can only ever send the same transaction rather than a new one. Retries back off from 30 seconds up to a cap.

This is what makes it safe for the system to try again without your involvement: there is no version of the retry that spends your money twice.

Section titled “Related”