跳转到内容

本页面的来源

本页面的每条论断都对应固定的修订版本。打开路径即可查看验证所依据的确切来源。

atomicals-electrumx-1.5.2.0

Atomicals ElectrumX

修订 v1.5.2.0 (2025-03-27)

打开固定路径: mintParser

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

atomicals-js-cli

Atomicals JavaScript CLI

修订 1333565efbfe

打开固定路径: commandIndex

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

Perpetual DFT

Raw

A separate activation gated mode with progressing Bitwork and an optional global cap, and why it is not fixed DFT with a large number.

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/arc20/perpetual-dft
Normative authority
Atomicals reference implementation
Networks
mainnet
Documentation version
2026.08
Activation boundary
Perpetual mode is activation gated. It is not available on every network at every height.
Audience
creator, developer
Owner
bitcoin-universe-docs
Sources
Known limitations
  • Do not display a fixed supply cap for a perpetual deployment unless the actual deployment and the active implementation establish one.

此内容尚不支持你的语言。

Perpetual DFT is not a fixed deployment with a very large max_mints. The pinned implementation treats it as a separate, activation gated mode with its own parameters.

Aspect Fixed DFT Perpetual DFT
Availability Generally available Activation gated
Bitwork Set once by the deployment Progresses through a vector over time
Mint count Bounded by max_mints Governed by progression parameters
Supply cap mint_amount * max_mints Optional global maximum, which may be absent
Display A cap can be shown A cap must not be invented
yarn cli init-dft-perpetual <ticker>

See the CLI reference.

A user interface that reads perpetual parameters and prints a supply cap computed as if the deployment were fixed will print a wrong number. It may print a number where none exists.

Read the actual deployment and the target implementation before calculating or displaying any cap. When no global maximum is configured, say that plainly instead of showing a figure.

The requirement changes as minting progresses, which means:

  • a claimant’s grinding cost is not constant;
  • a claim built against a stale requirement fails;
  • a product that caches the requirement will mislead its users.

Read the requirement at build time, for the height you are targeting. See Bitwork.

  1. That the deployment is perpetual, labelled as such.
  2. The current Bitwork requirement and when it was read.
  3. The global maximum if one is configured, and a clear “no configured maximum” if not.
  4. Issuance to date, computed from claim records.
  5. The activation state of perpetual mode on the target network.