跳到內容

本頁面的來源

本頁面的每項論述都對應固定的修訂版本。開啟路徑即可檢視驗證所依據的確切來源。

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.