DMINT
Decentralised item minting against a sealed manifest, how verification works, and every failure state a claimant can hit.
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/containers/dmint - Normative authority
- Atomicals reference implementation
- Networks
- mainnet
- Documentation version
- 2026.08
- Audience
- creator, developer
- Owner
- bitcoin-universe-docs
- Sources
-
- Atomicals ElectrumX
at
v1.5.2.0 - Atomicals JavaScript CLI
at
1333565efbfe
- Atomicals ElectrumX
at
- Known limitations
-
- Manifest structure and rule evaluation are implementation specific. Build manifests with the reference tooling rather than by hand.
此内容尚不支持你的语言。
DMINT lets anyone mint an item into a Container, while the Container owner keeps control of what a valid item is. The control comes from a manifest that is sealed before minting starts.
The manifest
Section titled “The manifest”The manifest declares, per item, what a valid claim looks like. It is built from a folder of item
files with prepare-dmint, attached with enable-dmint, and then sealed.
What a manifest typically constrains:
| Constraint | Effect |
|---|---|
| The set of item identifiers | Only listed items can be claimed |
| A digest per item | The claimed content must match exactly |
| A mint height | Claims before it are invalid |
| A Bitwork requirement | Claimants must grind |
| Rules per item | Additional conditions, including payment |
Why sealing comes first
Section titled “Why sealing comes first”An unsealed manifest can be edited. If items are minted against an editable manifest, the owner can change what counts as valid after the fact. Verification then proves nothing.
Seal, publish the sealed manifest, then open minting. In that order.
Claiming an item
Section titled “Claiming an item”yarn cli mint-item <container> <itemId> <manifestFile>The claimant supplies the item identifier and the manifest entry. A validator checks the claim against the sealed manifest.
Verification with validate-container-item checks an item without minting. See the
CLI reference.
Payments
Section titled “Payments”An item rule can require a payment. The payment is made in the same transaction, to the output the rule specifies, and is checked as part of validity. A payment marker output identifies which claim the payment belongs to.
A claim that meets every other condition but misses the payment is invalid, and the Bitcoin transaction still confirmed and cost a fee.
Failure states
Section titled “Failure states”| State | Cause | What a claimant sees |
|---|---|---|
| Item not in the manifest | Wrong identifier | Confirmed transaction, invalid claim |
| Digest mismatch | Content differs from the manifest entry | Confirmed transaction, invalid claim |
| Before mint height | Claimed too early | Confirmed transaction, invalid claim |
| Bitwork not satisfied | Grinding incomplete or wrong target | Confirmed transaction, invalid claim |
| Payment missing or wrong | Rule not satisfied | Confirmed transaction, invalid claim |
| Already claimed | Someone else won the race | Confirmed transaction, invalid claim |
| Manifest not sealed | The collection is not trustworthy | Claim may succeed but proves little |
Every row costs a Bitcoin fee. Check before broadcasting, not after.
For consumers
Section titled “For consumers”Do not display an item as a member of a collection unless it was verified against the sealed manifest. Show the Container Atomical ID, the sealed state, and the verification result per item.