# What makes a naming system last > Names are only worth holding if the system endures. The conditions that have made naming systems durable, and how to assess one. Source: https://hush.partners/what-makes-a-naming-system-last Category: Market & ICANN Published by Hush Partners. --- Every naming system in use was, at some point, a proposal that might not have worked. The Domain Name System came out of a period when the alternative, a single shared text file of host names, was collapsing under its own weight. Onchain naming systems started as experiments on public blockchains. Whether any system reaches the point where others depend on it, and stays there, is not a matter of enthusiasm at launch. It is a matter of structure. For a [long-term holder](/holders), a fund, or an institution committing capital to a TLD, the question of durability is not academic. If the system that records your ownership ceases to function, or ceases to be used, the asset does not transfer to something else. It simply stops being worth anything. The risks worth examining are therefore structural, not cosmetic. This article sets out a set of criteria for assessing durability, applies each criterion to the DNS and to onchain naming systems, and closes with the signals worth watching in place of forecasts. By the end, you should have a framework you can apply to any naming system without relying on the claims of anyone selling it. ## Why durability is the central question for a holder A name is a pointer. Its value comes from the confidence that the pointer will keep being honored by the system that honors it now: that `pay.yourbrand` will route to the same place next year, that `name.yoursector` will still be recognized by the software your counterparties use. That confidence rests entirely on the durability of the system beneath the name. For most assets, durability questions are moderated by the existence of a legal system that can enforce property rights even if the underlying market changes. A building still exists if its market softens. A naming system that stops being used or stops being operated takes the asset with it, and no court can reconstitute a registry that no longer runs. This is the structural difference between a name and most other assets: the asset and its infrastructure are inseparable. The implication for a [fund or family office](/funds-and-family-offices) is that due diligence on a TLD position must include due diligence on the system that records it, not just on the string itself. Durability criteria make that diligence systematic. There is a second reason to treat durability as the first question. Most of the other things a holder cares about are downstream of it. Liquidity depends on buyers believing the name will still work after they acquire it. Revenue from names issued under a TLD depends on registrants believing the same thing. A position in a system that passes the durability criteria can still be a poor position, because the string is weak or the price is wrong. A position in a system that fails them cannot be rescued by the quality of the string. ## Use: the function that gives a name its ground The most durable naming systems are the ones that solve a problem people encounter every day. The DNS survived because translating human-readable labels into IP addresses was a problem that grew with the internet, and no alternative mechanism displaced it. The earliest generic TLDs and the country-code TLDs accumulated weight precisely because the applications built on top of them, browsers, email clients, certificate authorities, created a dependency that compounded over time. For any naming system, the first durability question is: what does a name under this system actually do for the person who holds it or uses it? If the answer requires explaining the technical architecture before explaining the benefit, the use case is thin. If the answer is immediate, the ground is solid. Onchain names have a set of functions that can be verified. A name can point a wallet payment to a readable label instead of a long address. It can publish a website through decentralized storage. It can serve as the identity anchor for an AI agent operating under a TLD. The page on [what is live](/whats-live) lists each capability that works, with its source. The honest assessment is that these uses are real but narrower than those of the DNS. That gap is the gap in durability between the two systems, measured by use and not by promise. A useful test is to ask who would notice if the names stopped working. In the DNS, the answer is nearly everyone who uses a connected device. In an onchain naming system, the answer is the people who pay, publish or identify themselves through those names. The second group is smaller. What matters for durability is whether its members depend on the names for something they do repeatedly, because repeated dependence is what turns a feature into infrastructure. ## Resolution: where a name must be understood A name only functions if it resolves. Resolution means that the software a user runs can take the label, look it up, and get back a usable result. Without resolution, a name is a string stored somewhere. The DNS resolves everywhere because decades of deployment embedded resolvers into operating systems, network equipment and mobile devices. That ubiquity is the most formidable durability characteristic the DNS has. It is not a feature of the protocol so much as a consequence of accumulated installation. Onchain names face a partial resolution environment. They sit outside the DNS that ICANN coordinates, so an ordinary browser needs added support before it can open them. Names on Freename are understood by Bitcoin.com Wallet, by MetaMask when Freename's resolver is used, and by desktop browsers that have the Freename Web3 extension installed. That coverage is real, and it is the environment that matters for names used in wallets and for payments to a name. It does not cover a user opening an ordinary browser without any extension. That is a genuine limitation, and any assessment of an onchain TLD that does not acknowledge it is not accurate. Coverage is also not fixed. It changes, and monitoring it is more informative than assuming it will stay as it is or grow. The collision question is related. When the same string exists in more than one naming system, something has to decide which one a given piece of software resolves. Freename AG holds U.S. patent US 12,401,618 B1, filed on February 23, 2024 and granted on August 26, 2025, which addresses this with rules: the names in conflict are each given a score, and the outcome determines the one that resolves. One of the weighted criteria is "first registration", meaning the earliest date of creation. The patent itself cites new ICANN TLDs colliding with established web3 namespaces as a problem it sets out to handle. The text is available on Google Patents, and Domain Name Wire reported the grant. Keep the limits in view: a patent describes a method, it is not a court ruling, and it does not bind ICANN. For durability, its relevance is narrower. It shows that one registry has a defined approach to a question that would otherwise be left open. ## Incentives of those who run the system A naming system is operated by people and organizations with interests of their own. The system persists as long as those interests align with keeping it running and consistent. When they diverge, the system is at risk. The DNS is operated across a layered structure: ICANN sets policy and coordinates the top of the hierarchy, registry operators run individual TLDs, registrars sell names to end users, and a set of independent operators runs the servers that answer for the top of the hierarchy. Each layer has contractual obligations to the others and a financial interest in continued operation. The agreements between ICANN and the registries and registrars it accredits are public documents. The structure is not perfect, but the interlocking interests of many separate entities create a stability that no single party can dissolve unilaterally. For onchain naming, the incentive structure is different and worth examining carefully. On Freename, issuing names under a TLD is reserved to whoever holds that TLD. Freename also runs a royalty program: part of every registration fee paid for a name under a TLD goes to the holder of that TLD. The share is advertised at up to half and depends on the registry's current terms and on activation conditions, so read those terms before relying on it. The effect is to align the holder's interest with keeping the TLD active. The registry's own commercial interest also lies in names being registered and used. Whether these interests stay aligned over a long period depends on how the registry is governed and how it fares as a business, which brings the analysis to the next criterion. One point deserves attention in both systems. Incentives that depend on new registrations reward growth, and growth can slow. A durable system is one whose operators still have a reason to keep the existing names working when new registrations are few. In the DNS, renewal fees supply that reason. Where a TLD carries no annual renewal fee, as on Freename, the holder is spared a recurring cost on the TLD itself, though not on the royalty program: taking part in it carries an annual cost set by the registry, except for some TLDs registered under earlier terms that include the program for life, and whether those terms pass to a buyer is something to confirm with the registry before closing. Beyond that, the question of what funds long-term operation of the system moves to the registry's other sources of income. That is a question to put to the registry's published terms, not one this article can answer for you. ## Governance and the ability to change Every naming system that has lasted has had to change. The DNS added cryptographic signing of records, revised its dispute policies, expanded the set of TLDs, and updated its technical standards, none of which were possible without a governance mechanism capable of making collective decisions. The ability to change without destroying what already exists is as important as the stability of the current state. ICANN operates through a multistakeholder model: contracted parties, governments, civil society, and technical organizations each have defined roles in policy development. The process is slow and sometimes contested. But it is also transparent, documented, and capable of producing changes to the rules that contracted registry operators must follow. That combination of legitimacy and enforceability is the governance characteristic that has made the DNS changeable without being arbitrary. Onchain systems govern through smart contracts, which are programs that run on a blockchain, through the policies of the registry, and in some systems through votes by token holders. Smart contract governance can be fast and transparent: a proposed change can be visible to all participants before it executes. It can also be vulnerable to concentration of control if the power to change the contracts sits with a small number of parties, or to irreversibility if a change is made in error. The key question for any onchain naming system is: who can change the rules, under what conditions, and what can they not change? A system where the core rules are fixed in the contract and changes require broad agreement is more durable than one where a single key controls everything. Reading the contracts and the registry's terms, or having a technical adviser do so, is the appropriate due diligence step. Reading the project's marketing is not. ## Independence from any single party Independence asks: if the organization most central to this system disappeared, would the system continue? For the DNS, the answer is largely yes, at least in the medium term. The data at the top of the hierarchy is served from many locations by separate operators. The registries of the large generic TLDs are run by separate legal entities under long-term agreements. No single failure takes down the whole system. ICANN itself is an important coordinator, but the DNS would continue operating for a significant period even if ICANN ceased to function, because the data and the resolution infrastructure are distributed. For onchain naming, the independence question is more acute. The record of ownership lives on a public blockchain: on Freename, a TLD exists as a token recorded onchain and sitting in a wallet, and that record can be looked up by anyone on a block explorer. That much is independent of any single party, since the blockchain persists as long as the network that maintains it does. But the resolver, the interface between the name and the software that needs to use it, is often operated by the registry. If the registry stops operating the resolver, names stop resolving in the contexts that depend on that resolver. A TLD's durability therefore depends partly on how much of the resolution path is onchain and fixed, and how much depends on infrastructure outside the chain that a single organization maintains. The same reasoning applies to the holder's side. A token in a wallet is only as independent as the control of that wallet. An institution that holds a TLD through one person's keys has recreated a single point of failure on its own side of the table. A multisignature wallet, which requires several keys to approve a transfer, is the usual way to remove it. This is not an argument against onchain naming. It is the specific question worth asking of any system before committing a long-term position. Setting [an ICANN dotBrand beside an onchain TLD](/dotbrand-vs-onchain-tld) makes the dependencies of each visible. ## Legal recognition as a factor in durability Legal recognition does not make a naming system technically durable. But it matters for a holder in ways that are distinct from technical questions. A name registered in the DNS sits within a framework that courts in many countries understand. The UDRP, the Uniform Domain-Name Dispute-Resolution Policy, is an administrative procedure that binds registrants in generic TLDs through their registration agreements, and some country-code TLDs apply it or a variant of it. Trademark owners can use it to challenge registrations made in bad faith that conflict with their marks. Courts in a number of countries have also dealt with domain names as things that can be transferred or made subject to an order, although the treatment varies by country. That legal infrastructure exists not because it was designed in advance but because it accumulated as the DNS became important enough to litigate over. Onchain TLDs do not sit within a comparable framework. The UDRP does not reach them, because it binds through DNS registration agreements. In many places, courts and legislators have not settled what an onchain TLD is, whether it counts as property in the relevant legal sense, or how an order concerning one would be enforced. That is a genuine gap in durability from a legal perspective. It does not mean the law is absent: a trademark protects a sign in commerce whatever the system in which someone uses it, and the onchain record is public and dated, which gives counsel something concrete to refer to. Your own counsel decides how to characterize and protect any specific position under the law that applies to you. Nothing here is legal advice. The gap is also not static. Legal frameworks tend to follow value and disputes. Where onchain names are used and contested, courts and legislators have more reason to address them. Monitoring that development is more useful than either dismissing it or overstating existing protections. ## Applying the criteria: the DNS and onchain naming The criteria above can be applied side by side. The table below is a structured summary; the sections above carry the reasoning. | Criterion | The DNS | Onchain naming | | --- | --- | --- | | Use | Universal: browsing, email, certificates | Real but narrower: wallets, payments, websites, AI agent identity | | Resolution | Built into devices and networks | Partial: supporting wallets, resolvers and browser extensions | | Incentives | Layered commercial and contractual interests | Holder and registry both gain from registrations; more concentrated | | Governance | Multistakeholder; slow, transparent, binding on contracted parties | Smart contracts plus registry policy; faster, often more concentrated | | Independence | Distributed operators and registries; resilient | Ownership record independent; resolver layer varies | | Legal recognition | Established: UDRP and court practice, varying by country | Developing; trademark law still applies; specific doctrine largely unsettled | Neither column is uniformly stronger. The DNS has advantages that come from age and scale, and on resolution and legal recognition it is simply better. Onchain naming has advantages in the transparency of ownership, in the holder's direct control of the token, and, on Freename, in the absence of an annual renewal fee. The question for a holder is not which system wins in the abstract, but which criteria matter most for the specific position being considered. A holder who intends to issue names to a community that already works in wallets will weight resolution differently from an institution that needs a name to open in any browser on any device. The first can accept partial coverage, because its users are already inside it. The second cannot, and for that purpose a DNS name remains the right instrument. Many organizations will conclude that the two systems serve different functions and hold a position in each. A [TLD valuation](/valuation) is where these factors meet a specific string, a specific system and the uses the holder has or intends. That is where the abstract criteria become concrete. ## Signals worth monitoring Durability is not a state that can be confirmed once and then assumed. Systems can degrade or strengthen over time, and a holder's job is to track the right indicators, not to predict the trajectory of the market. The signals most worth watching for onchain naming systems are the following. **Resolver coverage.** The number and type of software environments that support resolution of a given namespace. Change here is the most direct signal of whether use is widening or narrowing. A namespace supported by a single wallet is more fragile than one supported by several independent pieces of software. **Governance changes.** Any modification to the smart contracts or terms that govern how names are issued, transferred, or resolved. These changes are material to holders. A well-governed system announces and documents changes before they take effect; an opaque system makes them without notice. **Collision treatment.** How the system handles strings that appear both in the onchain namespace and in the ICANN DNS. The existence of a defined method, such as the one described in US 12,401,618 B1, is itself worth tracking, as is how it is applied in practice. A system with no defined answer to collisions becomes less predictable as new ICANN TLDs are delegated. **Emerging use cases.** ERC-8004, "Trustless Agents", is a draft Ethereum standard, and as a draft it may change. It defines three registries: an identity registry in which each agent is an ERC-721 token pointing to its agent card, a reputation registry that collects feedback from those the agent worked with, and a validation registry for independent checks of its work. How naming registries connect to that identity layer is still evolving. A TLD used as the namespace for a category of agents would have a use that widens the places where its names need to resolve, which matters for durability. What onchain TLDs support for [AI agent identity](/onchain-tld-ai-agents) is one specific signal to follow. **Legal developments.** Court decisions and legislation that address onchain property. These move slowly but are structurally important. A country that has addressed how an onchain TLD is held and enforced presents a different risk environment from one that has not. **Registry health.** The financial and operational health of the entity that operates the registry. This is not always easy to assess from public information, but the indicators that are public, such as active development, responsive support, and governance documentation, are worth tracking systematically. For an organization whose concern is its own brand, [Namespace Watch](/namespace-watch) monitors the names of that brand onchain. It covers one part of this list, and the rest remains the holder's own discipline. ## What a holder does with this The criteria above are not a checklist that yields a binary verdict. They are a structure for honest thinking about a specific position in a specific naming system. A TLD that scores well on use and resolution but poorly on independence is a different risk profile from one with strong governance and incomplete resolution. The weighting depends on what the holder intends to do with the name. The concrete next step is to write the assessment down. Take one position, held or contemplated, and give each of the six criteria a short paragraph: what you know, how you know it, and what would change your view. Date the note for your own files and return to it at a fixed interval, with the signals from the previous section beside it. A position you cannot describe in those terms is one you hold on trust, and it is better to know that before committing than after. If you already hold a TLD and want an outside view of it, you can request a [private valuation](/private-valuation). The terms used throughout this article are defined in the [glossary](/glossary). Hush Partners is a private desk for onchain TLDs. It acts under mandate, either for a holder who wants a buyer or for an organization that wants a holder found and approached, and closing takes place through onchain escrow on an aftermarket. The assessment of whether a given TLD in a given system is durable enough to hold is your work and your advisers', and the structure above is meant to let you do it without relying on anyone else's conclusion. ## Questions people ask ### Does holding an onchain TLD give me any protection against ICANN delegating the same string? No. The two systems are separate, and holding a string in one creates no entitlement in the other. If you own a trademark in the string, the rights it gives you exist independently of both systems and are asserted through their own procedures, which vary by country. The method in Freename's patent describes how resolution between colliding names is decided in software; it is a method, not a legal right. Your counsel assesses the trademark position; the naming system is a separate question. ### If the registry that operates my onchain TLD ceases to operate, what happens to the TLD? The record of ownership remains on the blockchain regardless of the registry's operational status. What changes is resolution: if the registry was providing the resolver infrastructure, names under that TLD may stop resolving in environments that depended on it. The ownership record itself is not destroyed. A token that still exists but whose names resolve nowhere has kept its form and lost its function, which is why the independence criterion looks at the resolution path and not only at the record. ### How does legal recognition of onchain TLDs compare across jurisdictions? It varies considerably, and the field is developing. Some countries have addressed blockchain-based assets in general terms without specifically addressing naming systems. Others have not addressed them at all. The legal position in any specific country is a matter for qualified local counsel. ### Is a TLD with no annual renewal fee more durable than one that requires renewal? At the level of the individual holding, yes in one respect. With no annual renewal fee on a Freename TLD, one failure mode is removed: the holder cannot lose the TLD by missing a renewal. That does not address durability at the level of the system, which depends on the criteria above. Both things can be true: the individual holding is more secure, and the system-level questions still apply.