跳转到内容

本页面的来源

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

atomicals-electrumx-1.5.2.0

Atomicals ElectrumX

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

打开固定路径: realmValidation

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.

universe-index-atomicals

Universe ARC-20 index and Marketplace v1 authority

修订 670030e50071

打开固定路径: electrumx/lib/atomicals_blueprint_builder.py

Universe ARC-20 token explorer feed and the durable Marketplace v1 protocol authority.

Subrealms

Raw

Child names claimed under a parent Realm's rules, how the parent controls them, and what a claimant must satisfy.

Protocol behavior Verified 2026-09-01 Metadata & Sources

Describes the Atomicals protocol itself at the pinned reference revision. It does not promise that any product exposes it.

Page ID
protocol/realms/subrealms
Normative authority
Atomicals reference implementation
Networks
mainnet
Documentation version
2026.08
Audience
everyone, creator, developer
Owner
bitcoin-universe-docs
Sources

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

A Subrealm is a name under a parent Realm. The parent defines the rules; anyone who satisfies them can claim a Subrealm.

Reference commands: enable-subrealms, disable-subrealms, pending-subrealms, mint-subrealm <realm>, summary-subrealms. See the CLI reference.

A parent can:

  • enable or disable Subrealm claiming;
  • define rules that a claim must satisfy;
  • require a payment to a specified output;
  • leave claiming open, subject only to name availability.
  1. Read the parent’s current rules, at a specific height.
  2. Build a claim that satisfies them, including any payment.
  3. Mint with mint-subrealm.
  4. Wait for confirmation, then for resolution.
  5. Confirm you are the verified winner, not a losing candidate.

A claim that misses a rule still produces a confirmed Bitcoin transaction and costs a fee.

Where a rule requires payment, the payment output and its marker are part of validity. A payment marker output identifies which claim the payment belongs to, so a validator can match them.

Paying the right amount to the wrong script, or omitting the marker, makes the claim invalid.

A payment is never satisfied in a split transaction

Section titled “A payment is never satisfied in a split transaction”

A payment carried in a transaction that also carries a split (y) operation is refused, even when the amount and the marker are both correct. The reason is that a split can reassign ARC-20 value inside the very transaction that is meant to pay, so the payment cannot be judged in isolation.

This is the indexer being conservative rather than a rule stated in the format, and it may refuse a payment another implementation would accept. Send the payment as its own transaction. Combining it with a token movement to save a fee costs the claim.

A parent can inspect outstanding claims with pending-subrealms. A product showing Subrealms should distinguish:

State Meaning
Pending A claim exists and has not resolved
Verified winner The rules awarded the name
Losing candidate Another claim won
Rejected A rule was not satisfied

Showing a pending claim as owned is the failure to avoid.

Subrealms can nest. A hierarchy read should return the root, the path, and the direct children, and should say when the child list was truncated rather than silently cutting it.

The Universe read model exposes hierarchy and direct Subrealm listing with an explicit truncation flag. See NFT and Realm API.