Radix Namespace

Overview

A brand-new, open-source and decentralized name service namespace for Radix is available on Stokenet as a launchpad for the community to adopt. This is not a continuation of any existing name service in terms of both legal structure and functionality, it's a separate namespace intended to be operated independently and facilitated by the community in a "code-fork and migrate" like fashion as and when additional features are added in due course.

Importantly, it was designed to be taken on and instantiated for mainnet by another community member or ecosystem project. The intention is a clear separation of stewardship and operation: the next operator becomes the instantiator and steward of the mainnet deployment and go-live process.

Current Stokenet deployment:

Package: package_tdx_2_1pkq94qsyttgk89fe4suh3xsq24adfeypd9s6pd0zramlt8cew4ctty

Component: component_tdx_2_1cq3hzzgwypv3494aprg76c3pvxwpxmwalm7ld257pudj8urzc6l5ap

Initial Code Org (not the active repo, but the genesis to be forked): https://github.com/radix-namespace

Community-ready tooling (deployment is trivial - no build tools required)

To make adoption as easy as possible, Wylie has built the tooling so deployment is essentially "turnkey." The handoff is designed so the next community operator can fork the repos, instantiate and configure the system with just a github account, very little dev knowledge, and without needing build tools, custom pipelines or a complex setup. The same goes for any future forks that may occur, due to several reasons. This effectively allows the namespace to live into perpetuity and opens up many options to enable the community to decide what features, styles of stewardship and mechanisms serves them best (at any time).

Included tooling:

- A management client that handles instantiation, configuration (including reserving ecosystem domains), inspection, and component verification.

- A TypeScript SDK (plus docs) that makes it easy for others to build UIs and platform integrations.

- GitHub repos with workflows designed to support a facilitator/project lead.

The goal is simple: pick it up, run the management tooling, and deploy - the heavy lifting has already been done to make this repeatable and low-friction.

Compatibility with existing name services

While this is a new namespace, the mainnet instantiator can choose to mark existing domain NFT resources as "importable." This enables current holders to prove ownership and receive the equivalent domain within the new namespace. This also applies to future namespace migrations (during forks etc).

Key features

- Register human-readable Radix domains backed by bonds (stablecoins are the intended use case)

- Create/edit/delete subdomains under any registered domain

- Store arbitrary data records (wallet addresses, social links, metadata)

- Reverse resolution by linking an account address to a primary domain

- Domain import compatibility via approved domain NFT resources (prove ownership → receive equivalent namespace domain)

- Third-party registrars can sign up, set a fee percentage, and earn fees per facilitated registration

- Bond model (rebond/unbond): bonds aren’t burned; owners can swap token backing or return the domain to reclaim the bond

- Admin can pre-allocate domains to specific accounts before the system goes live; anyone can pay on behalf of eligible claimants

- Go-live is fully permissionless: admin badge is burned, permanently removing admin access

- Each domain gets an isolated subregistry component and a dApp definition account for wallet recognition

- Each domain NFT includes an on-ledger generated QR code SVG (no IPFS dependency)

- Subregistries can update their associated domain resource address to support migration between providers