Atomicals protocol
One page that puts every Atomicals primitive, operation, and validation boundary in relation to each other.
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/overview - Normative authority
- Atomicals reference implementation
- Networks
- mainnet
- Documentation version
- 2026.08
- Audience
- everyone, developer
- Owner
- bitcoin-universe-docs
- Sources
-
- Atomicals ElectrumX
at
v1.5.2.0 - Atomicals protocol guide
at
unversioned
- Atomicals ElectrumX
at
- Known limitations
-
- The Atomicals specification is defined in code. This page summarises one pinned revision and is not an independent consensus specification.
本頁內容尚未翻譯。
The Atomicals specification is defined in code. The official guide says so directly. Everything below describes what the pinned reference revision does, not what a standard document declares.
The Atomicals protocol family
Every Atomicals primitive starts from the same envelope written in a reveal transaction. The operation inside the envelope decides what is produced. The fungible branch produces direct FT issuance, fixed decentralised deployments, and their mint claims. The non-fungible branch produces plain NFTs, Containers with DMINT items, and the name primitives Realm, Subrealm, and Payname. The AVM is a separate beta layer that is not part of either branch today.
The pipeline every operation follows
Section titled “The pipeline every operation follows”- A builder constructs a commit transaction paying to a Taproot output that commits to a script containing the envelope.
- A reveal transaction spends that output and exposes the envelope in its witness.
- A validator reads
atom, the operation code, and the CBOR payload. - The validator checks the operation against the rules active at that block height on that network.
- On success it assigns the result, usually to output zero for a mint.
- Transfers of existing Atomicals are decided by allocation over the transaction’s inputs and outputs.
Where each rule lives
Section titled “Where each rule lives”| Question | Decided by | Read |
|---|---|---|
| Is this envelope well formed? | Mint parser | Envelope and operations |
| Is this ticker name legal? | Ticker rule at the active revision | Tickers and candidates |
| Does this claim satisfy Bitwork? | Bitwork check | Bitwork |
| Which output gets the value? | Blueprint builder allocation | Allocation |
| Did anything burn? | Allocation remainder handling | Burns |
| Can this create value from nothing? | No-inflation validation | Allocation |
| Is this rule active yet? | Per-network activation table | Activation boundaries |
Read next
Section titled “Read next”- ConceptsCore concepts
Identity, ownership, state, references, and the trust boundaries.
- FungibleARC-20
The fungible model, issuance, allocation, and safety.
- Non-fungibleAtomicals NFTs
Non-fungible objects, media, transfers, and collections.
- NamesRealms and names
Names, candidates, hierarchy, and confusable risk.
- CollectionsContainers and DMINT
Collections, sealed manifests, and item verification.
- BetaAVM
The beta script interpreter, carefully scoped.