Fixed DFT deployment
The parameters a fixed decentralised deployment sets, what they bound, and what a client must check before treating one as valid.
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/fixed-dft - Normative authority
- Atomicals reference implementation
- Networks
- mainnet
- Documentation version
- 2026.08
- Activation boundary
- Mint count limits have legacy and later density variants. The applicable limit depends on the active rule set.
- Audience
- creator, developer
- Owner
- bitcoin-universe-docs
- Sources
-
- Atomicals ElectrumX
at
v1.5.2.0 - Atomicals ElectrumX
at
v1.5.2.0 - Atomicals JavaScript CLI
at
1333565efbfe
- Atomicals ElectrumX
at
- Known limitations
-
- Do not present a fixed deployment as valid without checking the target network's active rules.
此内容尚不支持你的语言。
A fixed DFT deployment is the dft operation. It does not create units. It publishes the rules
that later dmt claims must satisfy.
The reference command
Section titled “The reference command”yarn cli init-dft <ticker> <mint_amount> <max_mints> <mint_height> <file> <mintbitworkc>There is also init-dft-fixed. See the CLI reference.
Deployment parameters at the pinned revision
Section titled “Deployment parameters at the pinned revision”| Field | Meaning | Pinned behavior |
|---|---|---|
request_ticker |
The ticker requested | Validated by the active ticker rule |
mint_height |
Earliest block height for claims | Integer from 0 through 10 000 000 |
mint_amount |
Satoshis each valid claim places in output zero | 546 through 100 000 000 |
max_mints |
Number of valid fixed mode claims | At least 1. The maximum is activation dependent |
mint_bitworkc |
Optional commit Bitwork for claimants | Evaluated by the active implementation |
mint_bitworkr |
Optional reveal Bitwork for claimants | Evaluated by the active implementation |
Nominal maximum issuance
Section titled “Nominal maximum issuance”maximum issuance = mint_amount * max_mintsThis is a ceiling on what claims can produce. It is not a promise the ceiling is reached, and it is not a circulating supply figure. Report actual issuance from claim records, never from the deployment parameters alone.
What a client must check before showing a deployment as valid
Section titled “What a client must check before showing a deployment as valid”- The ticker resolved to a verified winner, not just a request.
mint_heightis within the accepted range for the active rules.mint_amountis within the accepted range for the active rules.max_mintsis within the limit active on that network at that height.- Any Bitwork requirement is read from the deployment, not assumed.
- The active rule set is the one your target validator runs.
Skipping step four is the common failure. The pinned source has legacy and density-activation mint count limits, and a deployment valid under one is not valid under the other.
Displaying progress
Section titled “Displaying progress”| Figure | Where it comes from |
|---|---|
| Maximum issuance | mint_amount * max_mints |
| Claims made | Counted valid dmt claims |
| Circulating | Sum of coloured value actually held, after burns |
| Remaining | max_mints minus claims made |
Circulating is not claims multiplied by mint amount, because units can burn after they are minted.