Subrealms
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
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
-
- Atomicals ElectrumX
at
v1.5.2.0 - Atomicals JavaScript CLI
at
1333565efbfe - Universe ARC-20 index and Marketplace v1 authority
at
670030e50071private repository
- Atomicals ElectrumX
at
Este conteúdo não está disponível em sua língua ainda.
A Subrealm is a name under a parent Realm. The parent defines the rules; anyone who satisfies them can claim a Subrealm.
The parent controls the rules
Section titled “The parent controls the rules”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.
Claiming
Section titled “Claiming”- Read the parent’s current rules, at a specific height.
- Build a claim that satisfies them, including any payment.
- Mint with
mint-subrealm. - Wait for confirmation, then for resolution.
- 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.
Payments
Section titled “Payments”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.
Pending claims
Section titled “Pending claims”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.
Hierarchy
Section titled “Hierarchy”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.