Architecture¶

Introduction¶

dotNS is implemented as a set of cooperating contracts on Asset Hub, not as a single monolithic registrar. The split exists because the responsibilities are genuinely different — managing name records, enforcing PopRules pricing, and handling transfers are separate jobs — and contract boundaries map cleanly onto those slices.

This page documents what each contract is responsible for at a conceptual level, so a Product developer building against the dotNS surface knows which contract handles which interaction.

Conceptual Responsibilities¶

The contract set covers nine slices of the registry's job, grouped into three families:

• Registry core: The contracts that hold the name records themselves:

  • A registry contract holding the (namehash → record) mapping and gating who can write to each record.
  • A resolver contract responding to queries — read-side surface for "what record does this namehash currently have?"
  • A records contract or substructure storing the contenthash, owner, and other per-name fields a resolver returns.

• Registration and pricing: The contracts that gate who can register what:

  • A PopRules contract that evaluates a proposed registration against the pricing ladder (name length × PoP tier × suffix → free or deposit).
  • A registrar contract that orchestrates the full registration flow: PopRules check, fee collection if applicable, write to the registry.
  • A deposit/treasury contract managing the deposits paid by open-tier registrations.

• Lifecycle: The contracts that handle changes after registration:

  • A transfer contract handling owner-changes for an existing name. See Name Transfers.
  • A renewal contract (or sub-mechanism) handling annual or per-period renewals where applicable.
  • An admin/governance contract for operations that need to be governance-routed (reserved-name allocations, dispute resolution, contract upgrades).

A Product developer rarely interacts with the contracts directly — the CLI and the higher-level Register and Publish flow wrap the registration interactions. A Product reading name resolution data does so through the standard chain-client surface, calling into the resolver contract via the typed PAPI descriptor for Asset Hub.

Where to Go Next¶