# Onchain domain names explained
An onchain domain name is a name recorded as a token in a smart contract, not in the DNS. How it differs, the three families, collisions and risks.
---
An onchain domain name is a name recorded as a token in a smart contract on a blockchain: whoever controls the wallet that holds the token controls the name, and the contract, not a registrar's database, is the record of who owns it. It looks like a DNS domain, with a label, a dot and a suffix, but it is issued by a different authority, held in a different way and resolved by different software, so it does not behave like a DNS domain unless something bridges the two.
That difference is the whole subject. A domain owner, an investor or a business buying a name needs to know what exactly is being bought: a registration in the global DNS that every browser and mail server understands, a token in a naming system that wallets understand, or a DNS registration that also carries a token. The three are sold with similar words and sometimes on the same page.
The kinds are described here on fixed criteria, without ranking them. DNS rules are quoted from ICANN, WIPO and the IETF; the rules of an onchain system are those of its contracts. This is general information, not legal advice.
30 daysredemption grace period after a gTLD name is deleted, under ICANN's expired registration policy
90 daysgrace period after expiry for a name under the Ethereum Name Service's own suffix
2 yearswindow in which a Handshake top-level name must be renewed before it can be auctioned again
Three expiry rules from three naming systems, each read in the system's own policy or protocol documentation. A one-time-purchase name has no such clock.
## What is an onchain domain name?
An onchain domain name is an entry in a smart contract that links a human-readable name to an owner address and to a set of records, and the entry is usually issued as a token that can be held and transferred like any other token. The contract is the registry: no separate company database has to agree for the ownership to change.
Three parts make up most onchain naming systems. A registry contract stores, for each name, which address owns it. A registrar contract sets the rules for creating a name: who may register, at what price, for how long. A resolver contract stores what the name points to: a wallet address on one or several networks, a content reference for a website, text records such as an avatar or a contact handle. Some systems merge these parts, others split them further, but the roles are the same.
The token is usually a non-fungible token under the ERC-721 standard or a close relative: one token, one name, one owner address at a time. That is why an onchain name sits in an ordinary wallet and follows the keys of that wallet and nothing else.
The word "domain" is borrowed. An onchain name has the syntax of a domain name, but being recorded on a blockchain does not place it in the Domain Name System. ICANN's Office of the Chief Technology Officer made that point in a 2022 paper on alternative name systems, which treats blockchain naming systems as namespaces separate from the DNS, each with its own rules.
## How does an onchain name differ from a DNS domain?
An onchain name differs from a DNS domain on eight criteria: the root authority, what the holder has, custody, the term, resolution, transfer, trademark disputes and lost access. The table sets the two side by side on those criteria; the sections after it develop the ones that change a buying decision.
| Criterion | DNS domain | Onchain name |
| --- | --- | --- |
| Root authority | One global root zone, coordinated through ICANN | The contract or chain of that naming system; no shared root between systems |
| What the holder has | A registration, held under contract through a registrar | A token, held by the address that controls it |
| Custody | Registrar account, with login and recovery | Wallet keys; self-custody unless a custodian is used |
| Term | Rented, usually by the year, renewable | Depends on the system: yearly rental, periodic renewal, or one-time purchase |
| Resolution | Native in browsers, email and operating systems | Native in many wallets; browsers need an extension, a gateway or special support |
| Transfer | Through registrars, under transfer policy and locks | A token transfer, final once confirmed |
| Trademark dispute | UDRP and courts; the registrar implements the decision | No UDRP; courts and platform policies only, with limited reach over the token |
| Lost access | Account recovery, registrar support | No recovery of lost keys by the system itself |
## Who is the root authority for each kind of name?
The DNS has one root, and each onchain naming system is its own root. In the DNS, the list of top-level domains lives in a single root zone coordinated through ICANN; a new suffix exists for the world only once it is added there. In an onchain system, the suffix exists because a contract or a chain says so, and only software that reads that contract or chain will see it.
The DNS chain of authority is contractual. ICANN's policies bind registries, which run a top-level domain, and accredited registrars, which sell registrations; a registrant holds a name through an agreement with a registrar, and transfer rules, expiry notices and dispute resolution come with it.
An onchain system replaces that chain with code and, often, with a governance body for the code. Changes to pricing or rules may be decided by token holders, by a foundation, by a company that controls the contracts, or by nobody at all if the contracts cannot be changed. Before buying, the question to ask of any system is plain: who can change the rules of this suffix, and by what process?
No coordination exists between these roots. The 2022 ICANN paper states that there is no coordination between the namespaces of the various alternative naming systems, that ICANN policies do not apply to them, and that name collisions must therefore be expected. Two unrelated systems can sell the same suffix, and the same string, to two different buyers, and both sales are valid inside their own system.
## What are the families of onchain names?
Onchain names fall into three families: names under a protocol's own suffix, onchain top-level names, and DNS names imported or tokenized onchain. They answer different needs, and the same buyer may hold one of each.
| Family | What is recorded onchain | Relationship to the DNS |
| --- | --- | --- |
| Names under a protocol's own suffix | A second-level name under a suffix the protocol runs | Outside the DNS root; reachable through wallets and bridges |
| Onchain top-level names | The suffix itself, owned by one holder who can issue names under it | An alternative root; outside the DNS root |
| DNS names imported or tokenized | A claim or token tied to an existing DNS registration | Inside the DNS; the registration still exists and must be kept alive |
**Names under a protocol's own suffix.** The protocol runs one or a few suffixes and anyone registers a name beneath them. The Ethereum Name Service is the reference case: names under its suffix are rented by the year, issued as tokens, renewable by anyone on the owner's behalf, and followed by a 90-day grace period after expiry before the name can be registered again, according to the protocol's documentation. Other systems in this family sell names once, with no renewal.
**Onchain top-level names.** Here the asset is the suffix. Handshake is the best-documented example: a blockchain whose purpose is to hold a root zone of its own. Its protocol documentation describes names allocated by a Vickrey auction, in which the highest bidder wins and pays the second-highest bid, with a bidding phase of about five days and a reveal phase of about ten, and a duty to renew within two years or see the name return to auction. The holder of such a name can then create names under it by its own rules.
**DNS names imported or tokenized onchain.** The name is a real DNS registration, and something onchain refers to it. In the import model, the DNS owner proves control from inside the DNS and gains the right to use the same name in an onchain system: the Ethereum Name Service does this by requiring DNSSEC and a specific text record on the domain, which its contracts verify. In the tokenized model, a registrar or a service working with one issues a token that stands for the registration, so that moving the token moves control of the domain under that provider's terms. In both models the DNS registration stays the foundation: it must still be renewed, it still falls under ICANN policy and dispute rules, and if it lapses the onchain layer has nothing left to stand on.
## Do you own an onchain name, or rent it?
It depends on the system: some onchain names are rented by the year like DNS domains, some must be renewed at long intervals, and some are bought once. What is constant is that control sits with the token holder for as long as the term runs, with no account between the holder and the record.
A DNS registration is always a rental. The registrant pays for a term, usually between one and ten years, and renews. ICANN's expired registration recovery policy requires registrars to send at least two reminders before expiry, about a month and about a week ahead, and a further notice after expiry if the name is not renewed; once a gTLD name is deleted, a 30-day redemption grace period lets the former registrant ask for it back.
An onchain rental has grace rules too, but they are whatever the contract says, and no one is obliged to email you. A one-time purchase removes the expiry risk and replaces it with a different question: with no renewal income, what funds the system and its resolution infrastructure in ten years?
Cost alone rarely decides, but it is worth seeing how the two models diverge. Take an illustrative name renewed at $10 a year, registration fee and network cost together, against an illustrative one-time purchase of $60 for a comparable name.
Cumulative cost of a name renewed yearly and a name bought onceIllustrative worked example in USD: $10 a year against $60 once
Renewed yearlyBought once
Illustrative figures, not market prices: real fees vary by system, by name length and with network costs. Purchase price on a secondary market is not included.
The two costs meet at year six. Before that, the rental is cheaper; after it, the one-time purchase is. For a rented name, the real cost of a missed renewal is the name itself, not the fee.
## How does an onchain name resolve in a wallet or a browser?
An onchain name resolves when software reads the naming contract instead of asking the DNS. Wallets and blockchain applications commonly do this natively; a standard browser does not, and needs a bridge.
What happens when a wallet resolves an onchain nameThe general sequence; details vary by naming system
The name is enteredA sender types the name in the recipient field of a wallet that supports the naming system concerned.
The wallet finds the resolverThe wallet asks the system's registry contract which resolver contract holds the records of that name.
The resolver returns a recordThe wallet asks the resolver for the address record matching the network of the payment, and receives an address, or nothing if no record is set for that network.
The sender checks the addressThe wallet shows the resolved address; the sender compares it with the address confirmed by the recipient through another channel before a first or large payment.
The payment goes to the addressThe transaction is sent to the address, not to the name; a later change of the name's records does not move a payment already made.
For websites, the ICANN paper of 2022 lists the bridges in use: web gateways that translate a request from the DNS world, browser extensions, dedicated browsers with built-in support, and modified resolvers on a device or a network. It notes that a gateway is a single point of failure and that an extension adds a dependency on a third party; a dedicated browser reaches only the people who install it.
The practical consequence was put bluntly in an ICANN blog post of November 2021, titled as a buyer-beware notice: a link to a non-DNS name, clicked in an ordinary environment, fails with an error saying the domain cannot be found. The post advises asking the seller, before obtaining a name, whether it will work in the DNS.
Email is the sharpest case. Mail delivery relies on DNS records, so a name outside the DNS root cannot carry a mailbox that the rest of the world can reach. A business that needs a website and email on a name needs a DNS registration, whatever else it holds.
## What is the name-collision question with the DNS root?
A name collision happens when the same string means two different things in two namespaces, and software or a user reaches the wrong one. Onchain suffixes are created without reference to the DNS root, so a suffix sold onchain can already exist in the DNS, or be delegated there later to an unrelated operator.
ICANN has published on this in several places, and the positions are consistent. The 2022 paper from its Office of the Chief Technology Officer observes that some blockchain naming systems reserved certain DNS names at launch, says that these reservations are not an ongoing coordination effort with the DNS, and concludes that name collisions with the DNS will necessarily occur; it adds that software defects and misconfigurations will leak names from one system into another. A report of ICANN's Security and Stability Advisory Committee, dated December 2023 and devoted to the evolution of name resolution, describes the same ambiguity, a name that exists in both the DNS and an alternative system, and recommends that ICANN keep monitoring alternative naming systems and report to its community.
The DNS has lived through collisions of another kind, which shows how ICANN treats the risk. Three strings applied for in the 2012 round of new top-level domains, .corp, .home and .mail, were already used widely inside private networks. They were classed as high-risk, deferred indefinitely, and in February 2018 the ICANN Board resolved that the applications should not proceed, with application fees refunded. Nothing published by ICANN says that an onchain suffix earns the same treatment, or any right in a later application round.
The IETF offered naming projects a way to avoid the question. A standards document of September 2023 reserves the .alt label as a pseudo-suffix for non-DNS naming systems, states that it will never exist in the global DNS root, and sets up no registry beneath it. Moving under it is recommended, not required, and the established onchain systems have kept their own suffixes.
## What are onchain names used for?
Onchain names are used for three things: as a readable label for a wallet address, as an identity across blockchain applications, and as the address of a website. The first is by far the most mature.
**A wallet address.** A name replaces a long string of characters with something a person can read and repeat. One name can hold a record for each network, so the same label can point to different addresses on different chains. The sender still pays an address: the name is a lookup, and its records can be changed by whoever controls the name at that moment.
**An identity.** Applications that read the naming system show the name in place of the address, along with records the owner chose to publish: an avatar, a profile, a contact handle. A reverse record, set by the address owner, links the address back to the name, which is what lets an application display the name with some confidence that the address claims it.
**A website.** A name can point to content held on a distributed storage network, and a visitor with the right browser, extension or gateway reaches it. Reach is limited to that audience; sites meant for the general public keep a DNS domain.
## What are the risks of holding an onchain name?
The main risks of an onchain name are loss of the keys, expiry, trademark exposure, and dependence on the system that issued it. None is exotic, and each has a control.
| Risk | What can happen | Control |
| --- | --- | --- |
| Lost or exposed keys | The name is unreachable, or moved by someone else; the system cannot restore it | Hardware wallet or multi-signature wallet; documented backup; separate owner and manager roles where the system offers them |
| Expiry | A rented name lapses, then becomes available to anyone | Long terms; calendar alerts well before the grace period; a second person responsible |
| Trademark | A claim from a mark owner; delisting by platforms; court action against the holder | Clearance search before buying; avoid names built on someone else's mark |
| System dependence | Rules change, resolution support fades, a provider stops operating | Read who controls the contracts; prefer names whose records you can manage without the seller |
| Stale records | Payments reach an old address after a wallet change or a sale | Review every record at each transfer and each wallet rotation |
Trademark law does not stop at the edge of the DNS. Inside the DNS, the Uniform Domain Name Dispute Resolution Policy gives a mark owner a defined route: according to WIPO, a complainant must prove three elements, that the name is identical or confusingly similar to its mark, that the registrant has no rights or legitimate interests in it, and that it was registered and is used in bad faith; the remedy is transfer or cancellation, never damages, and the registrar implements the decision. That policy binds registrars of gTLDs and of the country-code domains that adopted it. It does not reach a token in a contract.
For an onchain name, this cuts both ways. A holder cannot lose the token through that procedure, and a mark owner has no quick, low-cost route to obtain it. What remains is court action against an identifiable holder, and the policies of marketplaces and applications, which may delist a name or stop displaying it. A name that infringes can end up technically owned and practically unusable. A DNS name imported or tokenized onchain stays fully inside the DNS rules: a decision against the registration takes the onchain layer with it.
Recovery follows the same logic. Lost registrar credentials are resolved through identity checks and support staff; lost keys to a self-custodied name are final unless a backup or a multi-signature arrangement was prepared beforehand.
## What should you check before buying an onchain name?
Before buying an onchain name, identify its family, its term, who controls its contracts, where it resolves, and whether the string conflicts with a mark or a DNS suffix.
- **Family.** Is it a name under a protocol suffix, a top-level name in an alternative root, or a DNS registration with an onchain layer? Ask the seller in those words.
- **Term.** Rental or one-time? If rental, read the expiry date on the contract itself, not on a listing, and the length of the grace period. A name close to expiry is worth less than its listing suggests.
- **Control of the rules.** Who can change prices, upgrade contracts or revoke names? Is there a published governance process?
- **Resolution.** Which wallets and applications that your counterparties actually use support the system? For a website, through which bridge, run by whom?
- **Records.** After the transfer, which records still point to the seller's addresses? Reset them before using the name.
- **Collision.** Does the suffix exist in the DNS root, or in another onchain system? Does the label reproduce a registered mark in your markets?
- **Underlying registration.** For an imported or tokenized DNS name: who is the registrar, when does the registration expire, and what do the provider's terms say about moving the domain out?
On the secondary market, the transfer itself is a token transfer, confirmed in minutes and final once confirmed. Agree the price, the exact token and the receiving address in writing first, and verify the token against the official contract of the naming system, since an imitation contract can issue a token with the same visible name.
## Which kind of name suits which need?
The need decides the kind of name: a DNS domain for anything the general public must reach, an onchain name for anything wallets and blockchain applications must read, and an imported or tokenized DNS name when one string has to serve both. None replaces the others.
A business that wants a website, email and search visibility needs a DNS registration; an onchain name adds nothing to those three. A treasury or a freelancer who wants to be paid at a readable name is served by a name under a protocol suffix that the payers' wallets support. A brand that wants the same identity on the web and in wallets is the natural user of a DNS name with an onchain layer, and pays for both renewals.
Investors face a different question, which is liquidity inside each system. A DNS domain trades in a long-established market with brokers, marketplaces and a dispute policy every buyer understands. An onchain name trades as a token, with a buyer pool limited to people who use that system, and a top-level name in an alternative root depends on the future reach of that root. A portfolio that mixes them should value each on the rules of its own system.