Onchain TLD and DNS domain: twelve practical differences
Ownership, renewal, reach, disputes, transfer, what you can build beneath it: where an onchain TLD and a DNS domain part ways.
A domain portfolio manager who moves between brand registrations and new gTLD applications already carries a precise mental model: registrations expire, registrars can be changed, UDRP panels can order transfers, the registry is ultimately answerable to ICANN. That model works well inside the DNS. Applied to an onchain TLD, several of its assumptions are simply wrong, and a few of the things it treats as risks disappear entirely.
This article runs through twelve points where the two systems part ways. Each part describes one difference, explains the mechanism behind it, and ends with what the difference means for an owner making a practical decision. By the end, you should be able to pick up an onchain TLD question (a valuation, a dispute, a transfer, an activation) and reason about it from the mechanism rather than by analogy.
The comparison is deliberately neutral. Each system does some things better than the other, and those asymmetries are named plainly.
Evaluation fee from ICANN's new gTLD program pages; application count from trade press reporting of the 1,616 figure; renewal fee from Freename's published terms.
The table below is the map of the twelve points. The sections that follow take them in the same order, grouped where two points share a mechanism.
| Point | DNS domain | Onchain TLD |
|---|---|---|
| What you hold | A registration, a contractual right | A token held in a wallet |
| Level | One name under someone else’s TLD | The TLD itself |
| Renewal | Periodic fee, expiry if unpaid | No annual renewal fee on Freename |
| Who can take it away | Registrar, registry, panel, court | Set by registry terms; courts |
| Reach | Every browser and mail system | Supporting wallets and extensions |
| Disputes | UDRP and courts | Courts or negotiation, no UDRP |
| Transfer | Registrar process, authorization code | Token transfer, onchain escrow |
| Privacy | Registrant data often redacted | Record public, holder unnamed |
| Issuing beneath | Subdomains in a zone file | Names that are tokens themselves |
| Revenue beneath | None by default | Royalty share, on registry terms |
| Governance | ICANN contracts and policy process | Registry terms and contract code |
| Coexistence | Gives no claim onchain | Gives no claim in the DNS |
What you hold, and at what level
A registration against a token
A DNS domain name is a registration. The registrant’s name appears in a database maintained by a registrar, which is itself accredited and contractually bound to the relevant registry. You hold a right to use the name for the period you have paid for. The underlying record lives in infrastructure that a registrar and a registry operator maintain; the registrant’s claim is contractual, not possessory.
An onchain TLD on a registry such as Freename is recorded as a token, a unique entry on a blockchain, held in a wallet. A wallet is a software or hardware tool that manages the cryptographic keys that control an onchain asset. The registry record is public and anyone can check it on a block explorer, which is a public tool for reading a blockchain’s history. Whoever controls the wallet controls the TLD; no intermediary needs to confirm a change of holder.
The practical difference is in the nature of the claim. A DNS registrant can lose access through registrar failure, a suspension or a dispute decision, and can also call the registrar when a credential is lost. A token holder depends on no registrar to act on their behalf, and has no registrar to call either. That shifts risk from counterparty default to key management. Losing a private key with no backup means losing control of the asset. The wallet setup (a single key, a multisignature arrangement, or a custody provider) deserves a review before any acquisition closes. The page on onchain TLD wallets covers what wallets do with these names.
A second-level domain against a whole TLD
When you register a second-level domain, you hold one name under a TLD operated by someone else. You have no authority over that TLD, its pricing or its policy. You can create subdomains beneath your name, but you remain a tenant of the registry above you.
An onchain TLD is the extension itself. The holder of .yourbrand on Freename holds the TLD, not a name beneath one. Only the holder of the TLD can issue names under it: pay.yourbrand, id.yourbrand, team.yourbrand. The namespace is exclusively theirs.
This is the structural asymmetry that makes onchain TLDs relevant to brand and IP teams. A DNS domain gives you control of one node in a tree that someone else operates. An onchain TLD gives you the top of your own namespace. The closer comparison in the DNS is therefore not a domain at all but a TLD obtained from ICANN, and that comparison is set out in dotBrand against onchain TLD. The expected evaluation fee shown above gives the order of magnitude of the ICANN route before advisers and registry operations. The cost of an onchain TLD depends on the string and on whether it is acquired from the registry or from a holder, so no single figure can be set beside it.
In practice, value an onchain TLD as you would value an extension, not a domain. The questions are what can be issued beneath it and to whom, not what traffic one address receives.
Renewal: a recurring obligation against a standing record
Every DNS registration has an expiry date. Renewal fees must be paid to keep the registration alive. Miss the renewal and the name passes through grace and redemption periods, then becomes available for registration by anyone. For a portfolio of thousands of names, renewal management is a discipline in its own right, with its own calendar, budget and failure modes.
An onchain TLD on Freename carries no annual renewal fee. The token stays in the holder’s wallet until the holder transfers it. There is no renewal window to miss and no grace period to track.
This removes a category of operational risk. It also removes a budget line. For an organization that maintains a defensive DNS portfolio, the absence of renewal fees is a real factor when comparing the two asset types.
It also removes a discipline, and that cuts both ways. In the DNS, the renewal cycle forces a periodic decision: someone looks at each name and decides whether it is still worth its fee. An asset with no renewal is never reviewed by default. A TLD acquired by one team can sit in a wallet for years after that team has moved on, with nobody sure who holds the keys. The replacement for the renewal calendar is a custody review on a schedule you set yourself: who controls the wallet, where the backup is, and who inherits access when people leave.
The residual risk is technological. The token is meaningful as long as the blockchain that records it and the registry that interprets it continue to operate. No blockchain carries a guarantee of permanence, and a chain that loses its users loses the infrastructure around it. That risk is different in kind from a missed renewal, but it is not zero. Know which chain your TLD sits on and keep an eye on its continued support.
Who can take it away, and how disputes are settled
The parties with power over the asset
In the DNS, several parties can suspend, cancel or transfer a registration without the holder’s consent. A registrar can suspend a domain for breach of its terms. A registry can cancel registrations under its contracts. ICANN can act against a registry operator or a registrar. A UDRP panel can order the transfer of a name to a trademark owner, and a court can do the same.
For an onchain TLD, the set of parties who can act is smaller and defined differently. The registry (Freename, in the context used throughout this article) operates the platform and its smart contracts. A smart contract is a program that runs on a blockchain and executes as written; it governs what the registry can and cannot do to a token. The extent of any registry power over a TLD depends on how those contracts and the registry’s terms are written. A buyer should read, or have counsel read, the registry’s terms in force rather than assume they match DNS norms.
There is no ICANN oversight layer for onchain TLDs, because they sit outside the system ICANN coordinates. Courts remain. A court order addressed to a holder binds that holder like any other order, wherever the asset is recorded. What the court cannot do as easily is instruct a registrar to make the change for the losing party.
In practice, the list of who can remove a DNS name is long but well documented. The list for an onchain TLD is short, and you establish it by reading the registry’s terms.
Disputes and remedies
The DNS dispute landscape is well mapped. The UDRP, the Uniform Domain-Name Dispute-Resolution Policy, gives trademark owners an administrative remedy against names registered and used in bad faith. It binds registrants because every registrar accredited by ICANN writes it into its registration agreement. National courts hear trademark claims under their own law. The bodies, the stages and the likely effort of each route are reasonably predictable.
Onchain TLDs have no equivalent administrative layer. The UDRP does not apply to them, because no onchain holder has accepted it through a registrar contract. There is no panel procedure whose decisions the registry must implement. A disagreement goes to the ordinary courts, to the registry under whatever its terms provide, or to a direct conversation between the parties.
For a holder, the absence of an administrative layer removes one familiar way of losing a name. For a trademark owner with a well-founded objection, it means a less predictable path to a remedy. For both, a direct, private negotiation is often the most efficient way to settle the matter, and its terms can be shaped more freely than a panel decision, which can only transfer, cancel or deny.
The page on trademark TLDs explains what a TLD that matches a mark is, and holds the free Trademark Name Check form.
Reach: where a name resolves
A DNS domain resolves in every browser on every device, through the global DNS infrastructure. That infrastructure (the DNS root, recursive resolvers, authoritative name servers) is run by many parties but functions as one coherent system. A name registered in the DNS is reachable by default from any connected device, and mail addressed to it is delivered.
Onchain names resolve outside the ICANN DNS root. An ordinary browser does not open an onchain name without additional support. Where a DNS name needs nothing extra, a Freename name needs one of three supports: Bitcoin.com Wallet, MetaMask through Freename’s resolver, or a desktop browser with the Freename Web3 extension. Coverage is partial and the set of supporting applications changes. It should never be treated as equivalent to DNS reach.
The uses where onchain resolution matters are of a different kind: a payment sent to a name instead of a long address, an identity shown in a wallet, an address for a software agent. In those settings the application that resolves the name is the one the user is already in, so the reach that counts is the reach of that application. The page on what is live keeps the inventory of what works and where, with sources.
In practice, the DNS reflex “it resolves or it is broken” has no onchain equivalent. The onchain question is always “resolves where, and for which users”.
Transfer and settlement
Transferring a DNS domain involves a change of registrar or a push between accounts at the same registrar. The registrar’s systems mediate it, with an authorization code governing the process and, in many cases, a lock period after a registration or a previous transfer. In an acquisition, the payment and the name move through separate systems, which is why an escrow agent usually stands between the parties and why closing can take days.
Transferring an onchain TLD is a token transfer. The holder’s wallet sends the token to the receiving wallet and the blockchain records the change. There is no authorization code and no registrar process. Settlement can run through onchain escrow on an aftermarket, where the payment and the token are exchanged under the control of a smart contract. Because both assets live on the same kind of system, payment and delivery can be tied together much more tightly than in a DNS sale.
The practical risk moves accordingly. It no longer sits in the transfer process; it sits in the keys and in the destination address. A token sent to the wrong address is gone: there is no chargeback and no registrar to call. Before a transaction of any size, the receiving address is confirmed through a second channel, the public record is checked on a block explorer to confirm that the selling wallet holds the token, and the people who control the receiving wallet are identified inside the buying organization. How closing runs through onchain escrow is described on the escrow and transfer page.
One DNS habit to drop: there is no post-closing period in which a registrar can reverse a mistake. The checks happen before the transfer or not at all.
Privacy of the holder and transparency of the record
Public registration data in the DNS has changed a great deal. Under data protection law, many registrars redact registrant contact details by default and show only the registrar and the status of the name. A brand protection team that needs to identify a registrant often has to file a disclosure request or obtain an order first, and the rules differ by country and by registry.
Onchain records differ in both directions. The registry record is public: a block explorer shows the wallet address that holds a given token and every transfer in its history. Nothing is redacted. What the public record does not show is who controls the wallet. An address is a public identifier, and the natural person or legal entity behind it is not recorded on the blockchain.
The result is a different privacy profile: full transparency of movements, which are public and permanent, and no built-in link to a legal identity. You can see when a TLD was created, each time it changed hands and the wallet that holds it. You cannot read a name and an address from the record, and there is no disclosure procedure to request them from.
For a holder, this has a consequence that DNS habits do not prepare you for. Anything you do with the wallet that holds a TLD is visible to anyone who looks, including transfers between your own wallets. An organization that wants its holdings to be discreet plans its wallet structure before it acquires, not after. For a buyer, the consequence is the reverse: the history of the asset can be inspected in full before any conversation starts, which is more than DNS registration data usually allows.
What you can issue beneath it, and what it earns
Names beneath a TLD against subdomains
Beneath a DNS domain, the registrant can create subdomains, labels placed to the left of the registered name. Those subdomains are entries in a zone file. They are not separate assets, they cannot be held or transferred by someone else independently, and they exist only as long as the zone is maintained and the parent registration is renewed.
Beneath an onchain TLD, the holder can issue names that are tokens themselves. Each name, such as pay.yourbrand or id.yourbrand, can be held in a wallet, transferred, and used for the functions the registry supports: pointing to wallet addresses, to a website published on a network such as IPFS, or to other records. A name issued under an onchain TLD is an asset in its own right, not a line in a zone file.
This has structural consequences. An organization that holds .yourbrand can issue names to business units, partners or customers, and each recipient holds their name in their own wallet. Issuance stays with the holder of the TLD: on Freename, no one else can create a name under it. The decision that a DNS manager never faces is what happens to a name after it has been issued. A subdomain can be deleted from the zone in a minute. A name that sits in someone else’s wallet cannot simply be withdrawn, so the policy on who receives names, and on what terms, has to be settled before issuance starts. For operators who run a sector TLD such as .yoursector as a namespace, that issuance policy is the core of the business.
Revenue from names beneath it
A DNS registrant earns nothing from the mere existence of subdomains beneath a domain. In the DNS, registration revenue belongs to the registry level: the registry operator earns from second-level registrations, and the registrant earns from the business built on the domain.
The holder of an onchain TLD stands where the registry operator stands. Freename runs a royalty program in which the holder of a TLD receives a share of each registration fee for names registered under that TLD, advertised at up to half, subject to the registry’s terms in force and to activation conditions. Read those conditions before counting on the program, and do not assume it applies by default. Do not assume it is free to join either: the TLD has no annual renewal fee, but taking part in the royalty program carries an annual cost set by the registry. Some TLDs were registered under earlier terms that include the program for life, and a buyer should confirm with the registry, before closing, whether those terms pass to it.
The revenue depends entirely on demand for names under the specific TLD. A descriptive sector word that many businesses could use invites registrations from third parties. A TLD that matches a brand usually does not, and should not: a brand owner issues names under .yourbrand to control them, not to sell them to strangers. The two cases call for different reasoning, and only the first is a revenue question. If you are weighing it, the Subname Revenue Calculator lets you test assumptions about volume and price before you commit to an activation plan. Treat any output as a scenario built on your own assumptions, and confirm the program’s terms with the registry.
Governance and policy: ICANN contracts against registry terms
A TLD in the DNS operates under a registry agreement with ICANN. That agreement sets obligations on abuse handling, data escrow and continuity, and the conditions under which the agreement can end. The registry operator answers to ICANN, and ICANN answers to a multistakeholder community that develops policy through public processes. Policy moves slowly, and every contracted party must follow it. A registrant sits at the bottom of that chain and benefits from it without ever reading it: there are rules on transfers between registrars, on what happens when a registrar fails, and on how disputes are heard.
An onchain TLD operates under the terms of the registry on which it was created. Those terms are set by the registry operator and can change within whatever limits the terms themselves contain. There is no multistakeholder body and no public comment period before a change. The holder’s protections are of two kinds. Some are contractual: what the registry has undertaken in its terms. Some are technical: what the smart contracts allow anyone, the registry included, to do to a token. The second kind can be stronger than a contract, because code executes as written, but only an examination of the contracts tells you how far it goes.
For a legal team assessing an acquisition, this changes the reading list. In the DNS, you read the registrar agreement and rely on the policy framework above it. Onchain, you read the registry’s user terms, the terms of any program you intend to use, and, with technical help, what the token contract permits. You also ask a question that has a settled answer in the DNS and none here: what happens to the asset if the registry stops operating. The token would remain in the wallet. Whether anything would still resolve it is a separate matter.
Neither model is better in the abstract. The DNS offers a dense, predictable rulebook that you cannot negotiate. An onchain registry offers a thin rulebook, fewer parties who can interfere, and less recourse if the operator changes course.
Coexistence: holding both
An organization that wants universal reach and onchain functions does not have to choose. It can hold both: a DNS domain for the website, mail and marketing, and an onchain TLD for names in wallets, payments to a name, issuance to partners and the uses that are still taking shape around software agents.
The two assets are legally and technically independent. Holding the domain gives no claim to the matching onchain TLD, and holding the TLD gives no claim in the DNS. Neither registration history is recognized by the other system as a basis for priority. A trademark may support a legal claim in either, but it is enforced through different routes, as described above.
Independence has a management cost. The two assets will usually sit with different teams: the domain with IT or a corporate registrar, the TLD with whoever controls a wallet. A brand that appears in both systems needs one owner for the policy, even if the tools differ. Three points belong in that policy. First, who may issue names under the TLD and who may create subdomains, so that pay.yourbrand and its DNS counterpart do not end up pointing to different places. Second, how the two are presented to users, so that nobody is told an onchain name will open in an ordinary browser. Third, monitoring: a watch service that covers only the DNS sees nothing of what is issued onchain, and the reverse is equally true.
If you hold the domain and want the matching onchain TLD, the route depends on whether the string is still available from the registry. If it is, you register it. If it is already held, the only routes are the ones set out in the disputes section: a negotiated acquisition, or a legal claim where your counsel sees one.
Where to start with a specific TLD
Start by writing down which of the twelve points actually bears on your situation. A defensive question about a brand string turns on disputes, privacy and coexistence. A plan to run a namespace turns on issuance, revenue and governance. A purchase or a sale turns on what is held, on transfer and on settlement. Few situations involve all twelve, and the ones that do not apply can be set aside early.
Then check the two things that can be checked without talking to anyone: the public record of the TLD on a block explorer, and the registry’s terms in force. Those two sources settle most questions of fact. What they leave open is usually a question of law, which is for your own counsel, or a question of who to talk to and how.
That last question is where a desk comes in. Hush Partners is a private desk for onchain TLDs. A holder who wants a buyer found can give the desk a sell-side mandate. An organization that wants a holder found and approached on its behalf can use a buy-side acquisition mandate. Every exchange is covered by a standard mutual NDA, one named partner follows a file from first note to closing, and closing runs through onchain escrow on an aftermarket. Whichever of the twelve points brought you here, the contact form on the site is the way to reach the desk.
Questions people ask
Does holding an onchain TLD give me rights in an ICANN application for the same string?
No. The two systems are separate. Holding .yourbrand onchain gives you no standing in the ICANN process, and a TLD delegated by ICANN gives its operator no automatic claim to the matching onchain TLD. If the same string exists in both, the question of how applications resolve it is technical and unsettled, and worth raising with your advisers before you build on either.
Can a TLD be held so that more than one person must approve a transfer?
Yes. A multisignature wallet requires two or more keys to approve a transaction before it is executed, and a TLD token can be held in one. This is the onchain counterpart of requiring several officers to authorize a domain transfer, and it suits holdings that belong to an organization and not to an individual. The details depend on the wallet software and on how many approvals you require.
What happens to names issued under a TLD when the TLD is transferred?
Names issued under a TLD are separate tokens in the wallets of the people who hold them. A transfer of the TLD does not move them by itself. Names sitting in the seller’s own wallet can be handed over with the TLD if the two parties agree, while names sold to third parties stay with those third parties. What changes hands is control over future issuance and whatever settings the registry attaches to the TLD. A buyer of a TLD with names already issued under it should establish how many there are, who was meant to receive them, and what was promised to those holders, before closing.
Do trademark rights extend to names in an onchain namespace?
The law on onchain assets varies by country and is still developing in most of them. Whether a given trademark covers a use in an onchain namespace depends on the mark, the goods and services it is registered for, the use in question and the court that hears the matter. This is information and not legal advice: your own counsel, in the relevant jurisdiction, decides.
