1. Order created
The action becomes an exact inscription payload. A unique commit address, minimum amount, receiver, and payment window are shown. For a mint, the anchor hash is captured here from the current chain tip and never refreshed.
Lifecycle
Two lifecycles, one inscription
A BLOCK-20 operation passes through a writer lifecycle that ends when the reveal is mined, and a reader lifecycle that decides whether it ever meant anything. They fail for different reasons, so understanding both is how you tell "my payment failed" apart from "my mint was rejected".
Writer lifecycle
From order to reveal
Creating an order puts nothing on Bitcoin. The Bitcoin payment is what starts the commit and reveal sequence.
2. Details reviewed
You compare the payload and destination against your intent, then save the order information. See the review checklist.
3. Commit funded
You send one dedicated Bitcoin output to the displayed address, at or above the minimum. Smaller outputs are not combined.
4. Payment detected
The monitor polls pending orders every 10 seconds. It accepts one eligible output at the commit address worth at least the required amount, prefers a confirmed output, and otherwise takes the largest eligible unconfirmed one.
5. Reveal mined
The commit output is spent into the reveal transaction, which sends the inscription to the selected receiver. The inscription now exists on Bitcoin regardless of whether it is valid BLOCK-20.
6. Result verified
You inspect the reveal on Bitcoin and check the token effect in a reader. This is where a mint's anchor is finally tested.
Order statuses
Reading the status without guessing
Keep the order record after payment. Some stages need time to reach the next Bitcoin transaction.
| Status | What it means | What to do |
|---|---|---|
| Awaiting payment | No eligible commit payment has been used yet. | Confirm your wallet transaction and wait for detection. Do not send a second payment. |
| Revealed | A reveal transaction exists and its ID is available. | Open it and compare the inscription with your saved preview. |
| Reveal retrying | Signing or broadcast did not succeed on the first attempt. The monitor retries up to five times. | Keep the order record. Do not pay again. |
| Needs help | Retries were exhausted and the order could not complete automatically. | Preserve the order, the commit transaction ID, and the payload, then contact the service you used. |
| Expired | The initial payment window, one hour from creation, passed with no eligible payment detected. | Do not fund an expired order casually. Expiry is a monitor behavior, not a hard gate, so a late payment can still be revealed and a late mint reveal can fail the freshness rule. |
Do not pay twice. A slow status update is not a new payment request. Check your wallet transaction and the order details first. If the order needs help, preserve the evidence rather than sending more Bitcoin.
Payment safety
Keep the commit address single purpose
Send one output at or above the displayed minimum. Do not split the amount, add unrelated funds, reuse an old commit address, or change the receiver after the order is created. If anything is wrong before payment, create a fresh order.
Save before sending
Keep the payload, receiver, order identity, commit address, minimum amount, expiry, and fee together. A public order read later will not return all of it.
Save after sending
Keep the wallet transaction ID, then add the commit output index and the reveal transaction ID when they appear.
An omitted or empty receiver address makes the reveal output return to the writer's own generated commit address, which is controlled by server-held key material. Always supply a Bitcoin address you control.
Reader lifecycle
What happens after the reveal is mined
The writer's job ends when the reveal exists. The reader's job starts there, and its verdict is what changes a balance.
- An inscription that fails any rule produces no event at all. Do not expect an error record to appear anywhere on chain.
- An accepted operation becomes a confirmed event with complete block placement and a confirmation count of
tip height - block height + 1. - Once the event's height drops below the finalized height, which defaults to six confirmations behind the tip, it can no longer be reverted by the reader.
- Above that line, a reorganization can revert it. Reverting reverses the exact recorded deltas, restores or removes transfer reservations, and then the replacement branch is replayed.
- For a mint, replay re-resolves the anchor against the new history. A mint whose anchor block was orphaned does not come back.
Practical rule: a BLOCK-20 mint is settled when its reveal is at least six blocks deep and its anchor block is also still on the active chain. Until then, treat the balance as provisional. The verifier lets you check the anchor at any time.