Aller au contenu

Sources de cette page

Chaque assertion de cette page renvoie a des revisions fixees. Ouvrez le chemin pour lire la source exacte verifiee.

atomicals-electrumx-1.5.2.0

Atomicals ElectrumX

Revision v1.5.2.0 (2025-03-27)

Ouvrir le chemin fixe: mintParser

Version-sensitive ARC-20 and Atomicals validation behavior used as the pinned reference baseline.

atomicals-js-cli

Atomicals JavaScript CLI

Revision 1333565efbfe

Ouvrir le chemin fixe: commandIndex

Reference command surface used for the documented CLI inventory and the visual asset provenance.

DMINT

Raw

Decentralised item minting against a sealed manifest, how verification works, and every failure state a claimant can hit.

Protocol behavior Verified 2026-08-31 Metadata & Sources

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
Known limitations
  • Manifest structure and rule evaluation are implementation specific. Build manifests with the reference tooling rather than by hand.

Ce contenu n’est pas encore disponible dans votre langue.

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 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

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.

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.

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.

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.

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.