Registry risk: what a TLD holder depends on

Holding the token that represents an onchain TLD is a real and verifiable fact. The token sits in a wallet you control, the registry record is public, and anyone can confirm it on a block explorer. That part does not depend on anyone’s goodwill.

The usefulness of that token is a different matter. Whether names issued under the TLD open in a browser, whether the royalty program pays what you expected, whether the terms that govern issuance stay as you found them: each of these depends on parties other than you. A serious holder, a buyer doing diligence, or a lawyer advising either of them needs to be able to name those dependencies, assess what could change, and decide whether the risk is acceptable given the purpose of the holding.

This article maps the dependencies of an onchain TLD, with Freename as the registry in view. It does not argue that the risks are large or small. It argues that you should be able to state them precisely, because a risk you cannot name is one you cannot monitor or mitigate.

The one thing that is certain: the token record

The token is the first thing to understand clearly, because it is the one element that sits with the holder. A Freename TLD exists as a token recorded onchain, and that token is held in a wallet. The registry record is public and can be checked at any time on a block explorer, a public website that displays what a blockchain has recorded. Moving the token ordinarily requires the private key that controls the wallet, which is why custody is the holder’s own business.

This matters for diligence. When a buyer or an adviser asks who holds the TLD, the answer does not rest on anyone’s statement. It can be checked in a few minutes. The public record shows when the token was created, which wallet holds it, and the transfers it has gone through. It does not carry promises about what the TLD will do. Those promises, to whatever extent they exist, come from a layer above the token: the registry’s terms, the resolution infrastructure, and the third-party software that implements it.

The record is also silent on rights that exist outside the chain. It does not tell you whether a trademark owner has a claim on the string, and it does not settle how a court in a given country would treat the holding. Those questions belong to trademark law and to the reader’s own counsel, and the answers vary by country. A clean record is necessary for a sound holding. It is not the whole of one.

The distinction between the token record and its operational usefulness is not a weakness of the onchain model. It is simply the structure. Knowing where certainty ends and dependence begins is the foundation of any honest risk assessment. The glossary defines the terms used here for readers who want precise language before going further.

Dependence on the registry’s operation and terms

The registry, which in this article is Freename, is the party that defines the namespace and operates the services around it. The token shows that you hold the TLD. What you can do with it depends on what the registry enables and permits.

Several concrete dependencies follow from this.

Issuance. Names under a TLD can be issued by its holder and by nobody else. That exclusivity is the commercial core of the holding. In practice, a holder issues names with the tools the registry provides, and to the extent that you rely on those tools, your ability to issue depends on their being available. A holder who plans to operate a live namespace should ask the registry how issuance works, what support exists, and what happens to issuance during an interruption of service.

Royalties. Freename operates a royalty program. Under it, when a name is registered under a TLD, part of the registration fee goes to the holder of that TLD. The advertised share is up to half, and it applies under the registry’s current terms and once the activation conditions are met. Each element of that sentence is a term: the share, the conditions, the way payment is made. Terms can be revised. A holder whose financial case rests on royalty income should treat it as income under a program, not as a fixed entitlement attached to the token. Taking part in the program also carries an annual cost set by the registry, to be deducted from that income. Lifetime inclusion in the program is written into the earlier terms under which some TLDs were registered; a buyer of such a TLD should ask the registry, before closing, whether those terms transfer with it. That distinction matters when a price is discussed, and the valuation page describes how a TLD valuation is built.

Terms of service. A registry’s terms are the document that says what a holder may do with a TLD and under which conditions its programs apply. A change of terms can affect the value of a holding without touching the token. Do not rely on a summary, this one included. Read the terms in force, keep a copy, and read them again when they are updated.

No renewal fee. A Freename TLD carries no annual renewal fee. That removes one familiar way of losing a name in the DNS, where a registration that is not renewed on time can lapse. It does not remove the other dependencies described here, and it says nothing about what the registry’s services will look like in the future.

None of this is a criticism of the registry. A namespace needs someone to define it and to run its services, and a party that does so must be able to revise its terms. The point for a holder is narrower: know which parts of your plan rest on the token and which rest on the terms. The holders page is written for people in that position.

Dependence on resolution by third-party software

A token in a wallet shows who holds the TLD. For a name under that TLD to resolve, meaning for a browser or a wallet to translate pay.yourbrand into an address or a resource, the software in the user’s hands must support it. This dependence is easy to overlook, because much of it sits outside the holder’s control.

An onchain name is not part of the ICANN DNS root. An ordinary browser therefore has no way to open it unless support has been added. That support takes one of three forms: a browser extension that looks up the onchain record, a wallet that reads the namespace itself, or an integration built by a software provider.

For Freename names, three routes exist. Bitcoin.com Wallet supports them. MetaMask does so through Freename’s resolver. On the desktop, the Freename Web3 extension adds support to a browser. That coverage is partial, and it changes over time.

The effective reach of a TLD, meaning how many people can actually use a name issued under it, is therefore shaped by decisions made by software providers who have no agreement with the holder. A wallet can add support. It can also remove it, change how it displays a name, or alter the conditions under which a name is read. An extension reaches only the people who install it.

Resolution raises a second question: what happens when the same string exists in more than one naming system. Freename AG holds U.S. patent US 12,401,618 B1 on this subject, filed on February 23, 2024 and granted on August 26, 2025. The patent covers a rules-based way of resolving names that collide. Competing names receive a score, and the score decides which of them resolves. One weighted criterion in the scoring is “first registration”, which the patent uses for the earliest creation date. The text names the collision of new ICANN TLDs with established web3 namespaces as one of the problems it addresses. The patent can be read on Google Patents, and its grant was reported by Domain Name Wire.

Read the patent for what it is. It describes a method. It is not a court ruling, and it does not bind ICANN. It tells you nothing about what a given browser or wallet will do with a name. What it does show is that the collision question has been set out in detail, with first registration among the factors.

For a holder considering an operational deployment, such as a namespace for payments, for wallet identities, or for websites, resolution is the dependency to investigate most carefully before committing resources. The page on what is live lists the capabilities of onchain TLDs that work, with sources, and is the right place to check coverage before making a decision.

Dependence on the underlying network

The token exists on a blockchain. That blockchain is a network maintained by participants who do not work for the registry and who act on their own incentives. This creates dependencies that sit deeper than the relationship with the registry but are still worth naming.

A blockchain can go through a protocol upgrade, a governance dispute, or a fork, which is a split of the network into two versions that continue separately. In most cases these events leave token holdings untouched. They can affect the tools used to reach the chain, such as wallets, block explorers and the services that relay requests to the network. In rare cases they raise the question of which version of the record is the reference. A holder should know which chain the TLD is on and have a view of how that chain is governed.

Smart contracts, the programs that record tokens and apply the rules attached to them, can contain errors, and some are built so that they can be upgraded. Where a contract can be upgraded, the logic that governs what a holder can do may change without the token moving. Where it cannot, the logic is fixed, but so is any flaw in it. Neither design is simply better. They are different risk profiles, and the useful question is which one applies to the contracts behind your TLD.

Network fees, the amounts paid to have a transaction recorded, affect the cost of issuing names, transferring the TLD and updating records, wherever those actions are onchain transactions. These fees are set by the network, not by the registry, and they can move materially. For a holder running a high-volume namespace, they are an operating cost to model.

None of these network-level risks is specific to Freename. They apply to any token on any public blockchain. The dependency exists, and a holder who has not thought about it has not finished the diligence.

The dependency map in one place

The table below gathers the dependencies by layer. Read it as a list of questions to answer for your own TLD, not as a forecast.

What could change, and in which direction

Every dependency in the table can move in either direction. This section is not a prediction. It is a map of the axes along which change can occur.

Registry terms can become more favorable to holders or less. Commercial conditions, regulation and the registry’s own priorities all bear on them, and none of these can be read from the token. A holder cannot know which way the terms will move. What a holder can do is keep a record of the terms as they stood at acquisition, follow the updates, and ask counsel what recourse exists if a material change occurs.

Resolution coverage can widen or narrow. More wallets and browsers can add support, and any single provider can remove it. Coverage is never certain to reach a particular population of users. A use that needs every browser to open a name without any added software is not what the onchain model offers, and a plan should not assume it.

The DNS itself changes. ICANN adds TLDs to the DNS through application rounds, and a string delegated there can be the same as the string of an existing onchain TLD. The Freename patent addresses that scenario in the terms set out above. A method is not an outcome, though. Its effect depends on the software that applies it, and no holder should assume that every resolver will treat a collision in the same way.

Smart contracts and platforms can be upgraded. An upgrade can add functions, correct an error, or change what a holder is able to do. A holder who understands who can upgrade the contracts behind a TLD, and by what process, is better placed to follow a change than one who learns of it afterward.

None of these observations supports the conclusion that an onchain TLD is uniquely risky. They support a plainer one: a holding of this kind calls for active monitoring, not for reliance on the conditions that existed on the day of acquisition.

How this compares with the DNS

It is easy to treat the DNS as the baseline of stability and onchain TLDs as a departure from it. The comparison is more accurate when the DNS’s own dependencies are stated plainly.

Take a registration under a generic TLD in the DNS. It depends on ICANN coordinating the DNS root. It depends on the registry operator keeping its agreement with ICANN, and on the registrar keeping its accreditation. It depends on the registrant paying for renewal. It also depends on the name surviving a complaint, since a registrant who loses a UDRP proceeding or a court action can see the name transferred to the complainant. A failure at any of these points can end the registration or move it to someone else.

In the onchain model, the holding does not pass through a registrar and there is no renewal date to miss. In exchange, the holder relies on resolution software that has made no commitment to support the namespace, and on registry terms that the holder does not negotiate.

On one point the DNS is simply better: reach. A DNS name opens in every browser and works with every mail system without anyone installing anything. The DNS also comes with long-established procedures for disputes and for the failure of an operator, which give lawyers a familiar path. An onchain TLD does not offer either of these, and a comparison that leaves them out is not honest.

Pricing is a dependency on both sides. In the DNS, what a registrant pays at renewal is set by registries and registrars within their agreements, and it can change. Onchain, the equivalent exposure is to the conditions of the registry’s programs. The form differs. The existence of the dependency does not.

The practical question for a holder is therefore not which model is safer in the abstract but which risks apply to the intended use. An organization that wants names for payments between wallets needs resolution in the wallets its counterparties use, and browser reach in the DNS is not the relevant comparison. An organization that wants a website the general public can open needs to weigh browser coverage honestly. The page comparing an ICANN dotBrand with an onchain TLD sets the two side by side.

What a holder can check and monitor

Naming the dependencies is useful only if it leads to concrete checks. The routine below does not remove the risks described above. It means that a holder learns promptly when something changes.

1. Check the token record on a block explorerConfirm that the token is in the expected wallet and that the record shows no transfer you did not initiate. Do this at acquisition and after any wallet activity.
2. Read and save the registry termsKeep a dated copy of the terms of service and of the royalty program conditions as they stood at acquisition. When the registry publishes an update, compare it with your copy and note any change to the royalty conditions, the rules of use or the way names are issued.
3. Check resolution coverage before any operational commitmentBefore building a payment flow, a website or any product for users on the TLD, check which wallets and browsers support the names at that moment. Do not rely on the coverage you noted at acquisition if time has passed.
4. Know which blockchain the token is onIdentify the chain, follow its governance announcements and note planned protocol upgrades. If the registry announces a change of chain or of contract version, find out whether your token is carried over without action on your part or whether you must act.
5. Watch for the same string in the DNSIf your TLD is a common word or a plausible brand, check whether the same string has been applied for or delegated at ICANN. A collision does not decide by itself which name a given piece of software opens, but it is a fact that a buyer will ask about.
6. Maintain custody disciplineThe token is only as safe as the wallet that holds it. A hardware wallet, a documented backup of the recovery phrase and, for an organization, a multisignature wallet that requires several approvals are standard precautions. As a rule, nobody can restore a lost key for you.

A routine of this kind also has a second use. A holder who can show dated copies of the terms, a clean record and a note on resolution coverage answers most of a buyer’s diligence questions before they are asked. For holders who want to see how ready a TLD is to be sold, the TLD Readiness Score is a free tool on the site that scores it.

Weighing the risk in a decision

A dependency is not automatically a problem. It becomes one when it goes unacknowledged, when the intended use is highly sensitive to a specific failure, or when there is no plan for what to do if it changes. Every holding of this kind has dependencies. What a holder or buyer has to judge is whether these ones are acceptable given what the TLD is for.

Four questions help structure that judgment.

What is the intended use? A TLD held as a namespace asset, with no immediate operational plan, has a risk profile dominated by the token record and by the registry’s continued operation. A TLD deployed as a live payment namespace has a risk profile dominated by resolution coverage and by the stability of the contracts. The same TLD can be appropriate for one purpose and premature for another.

What is the time horizon? A holder who plans to sell needs to be confident that the TLD remains transferable and that a buyer’s diligence will find it in order. A holder who plans to operate a namespace for many years needs to think about the governance of the network and the evolution of the terms over that horizon. Different horizons justify different depths of investigation.

What is the alternative? If the realistic alternative is a DNS registration, it comes with its own dependencies: renewal, the registrar relationship, exposure to ICANN policy. The comparison should be made honestly in both directions. If the realistic alternative is no namespace at all, the question is different again. For an organization that has decided a specific TLD matters, buy-side acquisition is the service in which it mandates the desk to find and approach the holder.

What is the cost of being wrong? An organization that builds a product for customers on a namespace and then finds that resolution stops working in a wallet its users rely on has a different problem from a holder who keeps the token and does nothing with it. Match the depth of your diligence to the cost of the failures you are assessing. The stage at which a TLD is put to work, post-transfer activation, is the point to test issuance and resolution in the conditions your users will meet.

How the dependencies bear on price

The same analysis applies when a price is discussed. A buyer and a seller who both understand the dependencies tend to separate three things. The first is the string and its record, which the buyer can check alone. The second is what works at the date of the discussion: where names resolve, and whether the conditions of the registry’s programs have been met for this TLD. The third is what would have to stay unchanged for the projected income to arrive.

The first two can be verified. The third is a judgment, and it is the one on which reasonable parties differ. A seller who presents projected royalty income as if it were attached to the token invites a discount, because a careful buyer will see that it rests on terms. A seller who presents it as income under a program, with the terms attached and the conditions documented, gives the buyer something to assess.

A concrete next step

Write the dependencies of your TLD on one page. For each layer of the table, note what you rely on, where you checked it, on which date, and what you would do if it changed. The page takes an hour to prepare and it changes the quality of every later conversation, with a buyer, with counsel or with a finance team.

Assessing the risk of an onchain TLD does not differ in kind from assessing any other infrastructure decision. Some of the dependencies are newer and less familiar to advisers. The discipline is the usual one: name the dependency, consider how it could change, measure your exposure, and monitor it.

If you hold a TLD and want a figure to set against that analysis before any decision, you can request a private valuation. The request goes to Hush Partners, a private desk for onchain TLDs, under the standard mutual NDA that covers every exchange with it.

Questions people ask

Is the token permanent if the registry shuts down?

The record of the token is kept by the blockchain, not by the registry’s own systems, so it does not depend on the registry continuing to operate. If a registry stopped operating, the record would still show the token in the holder’s wallet for as long as the network itself runs. What would be in question is everything above the record: the tools for issuing names, the royalty program, and the resolution support the registry provides. The record is durable. The services around it carry no such assurance, and the token promises nothing beyond its record. This distinction matters for how you hold the asset and for how you describe it to a counterparty.

Can a registry change terms retroactively?

That depends on what the terms say about their own amendment and on the law that governs them, which varies by country. The useful distinction is between the token and the conditions around it. A change of terms does not move a token out of a wallet. A change to the conditions of issuance or of the royalty program does affect the holder from the date it applies. Read the clauses on amendment, notice and dispute resolution in the terms in force, and ask your own counsel what recourse they leave you.

Does the Freename patent protect my TLD from a collision with an ICANN TLD?

No patent can promise that. The Freename patent sets out a scoring method for names that collide, in which the earliest date of creation counts among the criteria. It has no authority over ICANN, it is not a judicial decision, and it has effect only where software applies the method. A holder whose string may also appear in the DNS should treat this as an item to monitor, not as a guarantee.

Where does custody risk sit compared with registry risk?

Custody risk is the risk of losing the private key that controls the wallet holding the token, or of letting someone else obtain it. It is the holder’s responsibility entirely, and it has nothing to do with the registry’s services, with resolution or with a change of terms. It is also the failure with the least remedy: a lost key generally means a token that can no longer be moved. Registry risk, by contrast, affects what the token does and not whether you hold it. Both deserve attention, and they are managed differently. Registry risk is managed by monitoring and by knowing the terms. Custody risk is managed by wallet security, by backup procedures and, for organizations, by a multisignature wallet.