Commit and reveal
The two transaction pattern every Atomicals operation uses, and what can go wrong between the two steps.
Protocol behavior Verified 2026-08-31
Describes the Atomicals protocol itself at the pinned reference revision. It does not promise that any product exposes it.
- Page ID
-
protocol/core/commit-and-reveal - Normative authority
- Atomicals reference implementation
- Networks
- mainnet
- Documentation version
- 2026.08
- Audience
- everyone, developer, creator
- Owner
- bitcoin-universe-docs
- Sources
-
- Atomicals protocol guide
at
unversioned - Atomicals ElectrumX
at
v1.5.2.0
- Atomicals protocol guide
at
- Known limitations
-
- Bitwork applies to the commit transaction id, the reveal transaction id, or both, depending on the operation and the deployment configuration.
このコンテンツはまだ日本語訳がありません。
Commit and reveal
An Atomicals operation is created in two Bitcoin transactions. The commit transaction pays to a Taproot output whose script contains the operation envelope. The reveal transaction spends that output and exposes the envelope in its witness. A validator reads the revealed envelope, applies the operation, and assigns the resulting Atomical to the reveal transaction's output zero.
Why two transactions
Section titled “Why two transactions”Bitcoin script cannot carry arbitrary data cheaply in a way that stays hidden until spend time. Taproot script path spending can. The commit transaction pays into an output that commits to a script without revealing it. The reveal transaction spends that output and publishes the script in the witness, where the envelope becomes visible.
The steps
Section titled “The steps”- Build the envelope: the
atommarker, the operation code, and the CBOR payload. - Derive a Taproot output that commits to a script containing that envelope.
- If the operation requires commit Bitwork, grind the commit transaction until its transaction id satisfies the requirement.
- Broadcast the commit transaction, funded well enough to cover the reveal.
- Build the reveal transaction spending that output, with the envelope in the witness.
- If the operation requires reveal Bitwork, grind the reveal transaction the same way.
- Broadcast the reveal transaction.
- Wait for confirmation, then for a validator to index that height.
What can go wrong between the steps
Section titled “What can go wrong between the steps”| Problem | Symptom | What to do |
|---|---|---|
| Commit funded, reveal never broadcast | Value sits in a Taproot output only your key material can spend | Rebuild and broadcast the reveal with the same key material |
| Reveal underfunded | Reveal rejected by mempool policy | Increase the commit amount and start again |
| Bitwork requirement misread | Reveal rejected by the validator, not by Bitcoin | Re-read the deployment and grind again |
| Race for a limited mint | Reveal confirms but the quota is already full | The mint is invalid. The Bitcoin transaction still cost a fee |
| Name already resolved | Reveal confirms as a losing candidate | See candidates and winners |
You pay two fees. The commit fee is ordinary. The reveal fee depends on witness size, which grows with your payload, so embedding a large file makes the reveal expensive. Estimate before you grind, not after.
The reference CLI accepts --satsbyte on the commands that build these transactions. See the
CLI reference.