Name Transfers¶
Introduction¶
A .dot name is owned by an account on Asset Hub, and that ownership is transferable. A transfer changes who controls the name's record — who can update where it points (its contenthash), sell it on, or set administrative fields — without changing the name itself or what it currently resolves to.
This page documents the conceptual transfer flow and the rules dotNS enforces on it.
Provisional
The exact dispatch path for a name transfer (which contract, which signed extrinsic, the precise parameter shape), the supported acceptance / rejection mechanics on the receiving side, and any time-locked or escrow variants of transfer are still being finalized. This page documents the conceptual model; the operational reference will be added once confirmed.
What Changes on Transfer¶
A transfer modifies one field of the name's record: the owner. Specifically:
- The new owner becomes the account that can sign updates to the name's record (changing the
contenthash, transferring again, setting fields). - The name itself — the dotted string the user sees — does not change.
- The currently-attached
contenthashdoes not change. Users navigating to the name continue to see the same Product bundle they saw before, unless and until the new owner updates it. - The PoP tier the original owner used to qualify for the name (Full or Lite tier eligibility) does not transfer with the name. The new owner inherits the name regardless of their own PoP tier, but any future renewal-time or PopRules-evaluated operations are checked against the new owner's status.
When the Tier Lock Matters¶
The "PopRules-checked operations" caveat above matters most for Lite-to-Full migration reservations. If a PoP Lite holder registered alice01.dot and consequently has alice.dot reserved for 12 weeks, that reservation is tied to the original account, not to the name's record. Transferring alice01.dot to another account does not transfer the reserved alice.dot claim. Reservations are not transferable; the original holder either claims or forfeits the reservation themselves.
What a Product Should Know¶
A Product reading a name's record from chain state should treat the owner field as mutable. A name pointing at the Product today may be transferred to a new owner tomorrow; the new owner may update the contenthash to a different Product. Products that depend on a specific name (linking to it, referencing it from on-chain state) should verify the contenthash at use, not cache the assumption that "name X points at this Product forever."
Where to Go Next¶
| Created: June 16, 2026