Containers
A named collection identity that items can prove membership in, and what it takes to make that proof meaningful.
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/overview - 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
-
- No Universe read projection exposes Containers or DMINT items today. This section documents protocol behavior only.
Esta página aún no está disponible en tu idioma.
A Container is an Atomical that represents a collection. It has a globally allocated name, and it is the anchor that items prove membership against.
Container, sealed manifest, and verified items
A Container is a named Atomical that anchors a collection. Its owner builds a manifest describing every allowed item, attaches it, and then seals it so it can never be edited. Claimants mint items against the sealed manifest, and a validator checks each claim against it. Verification is only meaningful because the manifest was sealed before minting opened. An item that merely claims membership in its metadata proves nothing.
The lifecycle
Section titled “The lifecycle”| Stage | Operation | What exists afterwards |
|---|---|---|
| Mint the Container | nft with a container request |
A named collection identity, as a candidate |
| Resolve the name | Rules | A verified Container name |
| Prepare the manifest | Off chain, then mod |
The item rules, still editable |
| Seal the manifest | sl |
Rules that can never change |
| Claim items | dmt item claims |
Verified items, bounded by the manifest |
Sealing before item minting is what makes the collection meaningful. An unsealed manifest can be rewritten while people mint against it.
Reference commands
Section titled “Reference commands”| Command | Use |
|---|---|
mint-container <container> |
Mint the Container |
prepare-dmint <folder> <mintHeight> <bitworkc> |
Build a manifest from a folder of items |
prepare-dmint-items |
Prepare the item files |
enable-dmint <container> <jsonFilename> |
Attach the manifest to the Container |
mint-item <container> <itemId> <manifestFile> |
Claim one item |
validate-container-item |
Check an item against the manifest |
set-container-data |
Write Container data |
seal |
Seal, permanently |
get-container, get-container-item, get-container-items |
Read |
find-containers, summary-containers |
Discover |
Exact signatures are in the generated CLI reference.
Name allocation
Section titled “Name allocation”A Container name is a globally allocated name and follows the same candidate model as tickers and Realms. A request is not a name until the rules resolve it. See candidates and winners.
What a consumer should check
Section titled “What a consumer should check”- The Container’s Atomical ID, not its name.
- Whether the manifest is sealed, and at what height.
- Whether each item was verified against the manifest or merely claims membership in metadata.
- The verified item count against the manifest total.
Universe status
Section titled “Universe status”Containers and DMINT items are excluded from the Universe NFT and Realm read projection by declaration. Asking that index about a Container is out of scope, not a failure. See status and known limitations.