Decentralised mint claims
What makes a dmt claim valid, why a confirmed claim can still be worthless, and what a minter should check first.
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/arc20/decentralized-mint - Normative authority
- Atomicals reference implementation
- Networks
- mainnet
- Documentation version
- 2026.08
- Audience
- everyone, creator, developer
- Owner
- bitcoin-universe-docs
- Sources
-
- Atomicals ElectrumX
at
v1.5.2.0 - Atomicals JavaScript CLI
at
1333565efbfe
- Atomicals ElectrumX
at
- Known limitations
-
- Claim validity depends on the state of the deployment at the height of the claim. A claim built against stale deployment state can confirm and still be invalid.
本頁內容尚未翻譯。
A claim is the dmt operation. It mints exactly the deployment’s mint_amount into output zero,
if every condition is satisfied.
The reference command
Section titled “The reference command”yarn cli mint-dft <ticker>Options from the generated inventory include --current, --initialowner, --funding,
--satsbyte, --rbf, --disablechalk. See the CLI reference.
Conditions for a valid claim
Section titled “Conditions for a valid claim”- The claim occurs at or after the deployment’s
mint_height. - The relevant commit and activation constraints are satisfied.
- The configured mint quota is not already exhausted.
- Any
mint_bitworkcormint_bitworkrrequirement is met. - Output zero carries exactly
mint_amountsatoshis.
Condition five is exact. Not at least, not approximately. Exactly.
Why a confirmed claim can be worthless
Section titled “Why a confirmed claim can be worthless”Conditions one, three, and four are evaluated by the validator, not by Bitcoin. A claim that misses any of them still produces a confirmed Bitcoin transaction that cost a fee and minted nothing.
The most common case is condition three. In a contested mint, many claimants broadcast at once and the quota fills. Every claim after the last valid one is a confirmed transaction with no units.
What a minter should check first
Section titled “What a minter should check first”| Check | Why |
|---|---|
| The ticker resolves to a verified winner | Otherwise you are minting against a candidate |
| The deployment’s Atomical ID | Names can be confusable. IDs are not |
| Claims already made against the quota | To know whether any remain |
The exact mint_amount |
Your output zero must match it exactly |
| The Bitwork requirement | It comes from the deployment, not from you |
| Current fee rates | Contested mints get expensive |
What a product must display
Section titled “What a product must display”- The resolved Atomical ID next to the ticker.
- Claims made against the maximum, with the height the figure was computed at.
- The exact amount output zero will carry.
- The Bitwork requirement, if any.
- A clear statement that a confirmed transaction is not a successful mint.
After the claim
Section titled “After the claim”Wait for confirmation, then for the index to reach that height, then read the result. A claim that looks successful in a mempool view can still lose the quota race. See confirmation and reorgs.