Who governs onchain names

The DNS has a single coordinating body at its apex. ICANN oversees the global Domain Name System and is responsible for keeping it stable, secure and interoperable. That role is backed by contracts, accreditation requirements, a dispute-resolution framework and a long record of coordinated policy. When a brand lawyer asks who controls a .com name, the answer is a chain of accountable parties ending at ICANN.

Onchain naming has no such apex. Authority is distributed across at least four layers: the registry that mints a TLD, the chain the record sits on, the software that resolves it, and the marketplaces where it trades. Around them sit a diffuse community of standards writers and, unusually, the TLD holders themselves. None of these layers fully controls the others, and there is no body that can overrule all of them at once.

That is not the same as no rules. Each layer has its own rules, enforced by its own mechanisms. A general counsel or brand protection team that treats onchain naming as ungoverned will misread both the risks and the remedies. This article maps each layer, names the authority that operates there, and draws out what follows for a holder and for a brand owner. The table sets each layer beside its nearest DNS counterpart.

Governance in the DNS, in outline

The DNS distributes technical work but concentrates policy authority. ICANN does not sell domain names to end users. It operates through a system of registries and accredited registrars. A registry manages one TLD and maintains the database of the names registered in it. Registrars sell names to businesses and individuals and deal with the registries to register and manage those names.

ICANN’s authority is limited to the technical coordination of the internet’s naming and numbering systems. Within that remit it sets policy for domain name management, accredits registrars and can withdraw that accreditation, approves new TLDs, and coordinates changes to the DNS root zone, the list of TLDs that the whole DNS relies on.

Running through this structure is a dispute-resolution framework. The UDRP is an administrative procedure for disputes between the registrant of a domain name and a trademark owner who says the name was registered and used abusively. It applies in generic TLDs, and in the country-code TLDs that have chosen to adopt it, because accredited registrars are bound to it and bind their customers to it in the registration agreement. A panel decides three things: whether the domain name is identical or confusingly similar to a trademark in which the complainant has rights, whether the registrant lacks rights or legitimate interests in the name, and whether the name was registered and is being used in bad faith.

The UDRP is a policy instrument, not a court. Its decisions can be challenged in national courts, and it reaches only as far as the contracts that carry it. That boundary matters a great deal once you move onchain. How a UDRP decision interacts with the courts of a particular country is a question for your own counsel.

The governance of the DNS is described as multistakeholder: governments, businesses, technical bodies and civil society all take part in making policy, and the process is public. The result is a recognizable hierarchy, in which each party can point to the contract that binds it and to the body above it. Onchain naming has produced something structurally different: overlapping authority, specific to each layer, with nothing above the layers.

Layer one: the registry and its rules

In onchain naming, the registry is the foundational layer. It is the entity that mints TLD tokens, records ownership on a blockchain, and sets the terms under which names can be issued beneath a TLD. Freename is one such registry: a TLD there exists as a token on a blockchain, and that token sits in the holder’s wallet. Because the record is public, anyone can look it up on a block explorer, a website that displays the contents of a chain.

The registry’s authority is technical and contractual. It is technical because the smart contract (a program stored on the chain that runs as written) encodes the rules of minting and transfer directly: what the contract permits, the holder can do, and what it does not permit cannot be done. It is contractual because the registry’s terms of service add obligations on top of the onchain mechanics, including the conditions under which royalties are paid and names can be issued.

Issuance shows how the two combine. Under a Freename TLD, names can be issued by the holder of that TLD and by nobody else. No regulator imposed that rule and no policy process debated it. It is how the registry built its system. The same registry operates a royalty program: when a name is registered under a TLD, part of the registration fee goes to that TLD’s holder. The advertised share is up to half, and it depends on the registry’s terms in force and on its activation conditions. Freename charges no annual renewal fee on a TLD, which is again a choice of the registry and not a rule of the wider system. Taking part in the royalty program is a separate matter: it carries an annual cost that the registry sets, except that some TLDs were registered under earlier terms that include the program for life, and whether those terms follow the TLD to a new holder is to be confirmed with the registry before a sale closes.

Compared with the DNS, the registry layer leaves more in the holder’s hands. A DNS registry operator sets the rules for the names registered in its TLD, and an ordinary domain holder has no power to change them. The holder of an onchain TLD controls the issuance of names beneath it directly. That shift of power over the second level is one of the structurally significant differences, and the comparison of a dotBrand and an onchain TLD covers it in more depth.

The registry’s authority stops at the edge of its own namespace. It cannot force another registry to recognize its names, cannot compel a wallet to resolve them, and is not a party to the contracts that carry the UDRP. For a reader mapping authority, this is the first point to retain: the registry is the strongest single rule-maker in onchain naming, and its rules still bind only those who deal with it.

Layer two: the chain the record sits on

Every onchain TLD exists as a record on a specific blockchain, a shared ledger maintained by a set of validators or nodes that agree on its state through a consensus protocol. The chain is the substrate. It determines what the record says, who can update it, and whether the transaction that transferred a TLD was valid.

The chain is governed by its own protocol rules. Those rules are set and amended through the governance process of that chain, and the process varies. Some chains have formal onchain governance in which token holders vote. Others rely on agreement reached offchain among core developers and node operators. Either way, a protocol upgrade that changes how assets are recorded or transferred can affect every TLD recorded on that chain, whatever the registry’s terms say.

The nearest DNS counterpart is the DNS root zone: a foundational record that everything above it depends on, maintained through its own process. The difference lies in oversight. The root zone is maintained under ICANN’s coordination, within the multistakeholder model described above. A blockchain answers to no naming body at all. The rights of its token holders, validators and developers are defined in that chain’s own documentation, and the people who exercise them are usually not thinking about names when they do.

That last point deserves a moment. A registry chooses a chain, but it does not govern it. A decision taken for reasons that have nothing to do with naming, such as a change in transaction costs or in a token standard, still reaches the TLD records that sit on the chain. The DNS has no close parallel, because the bodies that maintain its foundational records exist for the purpose of naming.

A holder whose TLD sits on a given chain therefore takes on that chain’s governance risk. Protocol forks (a split of a chain into two versions), chain migrations and changes to smart contract standards are all plausible events that a holder’s legal and technical advisers should understand. This is practical due diligence, not speculation.

Layer three: software that resolves names

A name that exists onchain as a token is not useful until something resolves it, meaning that software translates the name into a usable record such as a wallet address, a content identifier or an IP address. That translation happens in a resolver: a piece of software built into a wallet, a browser or a browser extension.

Resolvers decide what a user actually sees. Onchain names are not part of the ICANN DNS root, which is why a standard browser will not open one unless support has been added. Support exists in specific products. For Freename names, that means Bitcoin.com Wallet, MetaMask by way of Freename’s resolver, and desktop browsers equipped with the Freename Web3 extension. This coverage is partial and it changes, so whether a given wallet or browser resolves a given TLD is a point to check against the product’s documentation, never to assume. The page on what is live gathers the capabilities that work, with their sources.

The resolver layer is where the contrast with the DNS is sharpest. In the DNS, any recursive resolver (the service that looks up a name on the user’s behalf) that follows the standard protocol reaches the same answer, because all of them start from the same root zone. In onchain naming, each resolver makes its own integration choices. It can support one registry and not another, one chain and not another. No body accredits resolvers or requires them to cover a minimum set of names.

That selectivity cuts both ways. A registry that invests in integrations extends the reach of its namespace. A holder whose TLD is supported in only one or two products depends on those integrations remaining in place. Neither the registry nor the holder can order a wallet to add or keep support. The software publisher decides, on its own product priorities.

Collisions and the Freename patent

The same string can be created as a TLD in more than one naming system, and a string that exists onchain can also be applied for in the ICANN DNS. When that happens, software that meets both names has to pick one. No authority tells it which.

One documented attempt to give that choice a rule is a patent. Freename AG holds U.S. patent US 12,401,618 B1, filed on February 23, 2024 and granted on August 26, 2025. It covers a rules-based way of resolving names that collide: the competing names are each given a score, and the score determines which of them resolves. Several criteria are weighted in that score, and one is “first registration”, meaning the earliest creation date. Among the problems the patent says it addresses is the collision of new ICANN TLDs with established web3 namespaces. The sources are the patent text on Google Patents and Domain Name Wire’s report on the grant.

For a map of authority, what the patent is not matters as much as what it is. It describes a method. It is not a court ruling, it does not bind ICANN, and it governs only the software that implements it.

Layer four: marketplaces

Onchain TLDs change hands on aftermarkets, platforms on which a sale closes through onchain escrow. An escrow of this kind is a smart contract that holds the asset and the payment and releases each to the other party when both are in place. These platforms are the nearest thing to a registrar in the onchain stack, with important differences.

An ICANN-accredited registrar must comply with ICANN’s policies, including the UDRP and the rules on transfers between registrars. A marketplace that handles onchain TLDs holds no ICANN accreditation, because it is not part of that system. Its rules on which assets it accepts, how a transfer is structured and what checks it performs are set by the platform operator, within the limits of the chain’s smart contracts and of the law that applies to the platform.

In practice, the rules for buying or selling a TLD vary by platform. A buyer who acquires a TLD through onchain escrow receives the token that the registry treats as the TLD, and that transfer is as public and verifiable as any other blockchain transaction. What the transfer does not carry is any assurance about the commercial value of the name, the absence of third-party claims, or the behavior of any wallet or browser. Those sit at other layers, and the buyer assesses them separately.

Because no common minimum standard spans marketplaces, buyers and sellers read the terms of the specific platform they use: how its escrow operates, how a disagreement between the parties is handled, and whether its terms affect the holder’s rights after the transfer. In a DNS transaction much of this is settled in advance by accreditation. Onchain, it is settled by the choice of platform, which makes that choice part of the deal and not a detail of execution.

Standards and those who write them

Between the registry layer and the applications sits a set of technical standards: the protocols and interface specifications that define how onchain names are structured, how records are formatted, and how registries interact with resolvers and wallets. These standards are written by communities of developers, typically through the open proposal process of an individual blockchain ecosystem.

On Ethereum, for example, standards are developed through public improvement proposals that anyone may draft and that are discussed in the open before they are finalized. Standards that touch naming and identity have direct implications for TLD holders. ERC-8004, “Trustless Agents”, is a draft Ethereum standard for AI agents. It defines three registries. The identity registry represents each agent as an ERC-721 token (the common standard for unique tokens) that points to the agent’s card. The reputation registry records feedback from those the agent worked with. The validation registry records independent checks of its work. ERC-8004 is a draft and may change, and how naming registries plug into it is still evolving. It is mentioned here because it shows a standard being written, in public, that may shape what a name under a TLD can identify. The page on names that resolve in wallets shows the more established use.

Standards writers hold a different kind of authority than ICANN. They do not accredit participants, cannot compel adoption, and do not administer a shared zone of names. A standard that gains adoption becomes de facto infrastructure. One that does not is simply left unused. The power here rests on reputation and on network effects, not on contract or regulation.

This matters for holders. A TLD built on a standard that loses momentum may become harder to resolve over time. No authority would have revoked it. The tools that resolve it would simply stop being maintained. It also matters for anyone who wants a say: participation in a proposal process is generally open, so an organization with a real interest in how names and identities are specified can follow the drafts and comment on them, which is more than most DNS registrants can do with ICANN policy without a considerable investment of time.

The holder’s own power over a TLD

In the DNS, a registrant who holds a name under .com has no governance power over .com itself. The registrant can use the name as the registry’s rules permit and can defend it in a UDRP proceeding, but cannot set the policies for registrations in the TLD, receives no share of registration fees, and cannot transfer the TLD as an asset.

The holder of an onchain TLD has a materially different set of powers. The holder has the token that represents the TLD, and that token can be transferred or kept in a multisignature wallet, a wallet that requires more than one private key to authorize a transaction. The holder decides whether names are issued beneath the TLD and to whom. On a registry with a royalty program, the holder receives a share of registration fees, subject to the registry’s terms and activation conditions. And the holder can sell the TLD to a new holder, with the transfer closing through onchain escrow.

These powers also carry responsibility. A holder who loses control of the wallet loses control of the TLD. A DNS registrant who loses access to an account can turn to the registrar, which knows its customer and has procedures for restoring access. A holder should not assume that anything comparable exists onchain, and should check what the registry’s terms say on the point. Custody arrangements therefore matter. A holder whose TLD has commercial value should take legal advice on custody and succession, as the holder of any significant digital asset would, since the rules on both vary by country. The page for holders sets out the commercial options.

The holder’s power also remains subject to the registry’s terms of service. Terms can change, and with them the conditions of a royalty program or the conduct the registry accepts in its namespace. The smart contract and the contractual terms are not the same thing, and both apply.

What nobody governs

Mapping authority by layer reveals gaps that no layer covers. These are not technical edge cases. They are structural features of onchain naming.

Collisions between registries. When two registries independently mint the same string as a TLD, there is no arbiter. Each registry’s records are valid within its own namespace. A resolver that encounters both must choose one, using whatever preference logic it implements. The Freename patent describes one technical approach at the resolver layer, and a method reaches only those who adopt it.

Trademark disputes. The UDRP does not apply to onchain names. A name issued by an onchain registry was not registered through an ICANN-accredited registrar, so no registration agreement brings the holder under that procedure. A trademark owner who finds a TLD matching its mark in someone else’s wallet has no UDRP complaint to file. National trademark law may still apply, depending on the country and on the use being made of the name, but the administrative fast track is absent. A TLD of that kind, one that matches a mark, is defined on the page about trademark TLDs.

Continuity of a registry. ICANN’s contracts contain arrangements meant to protect registrants when a registrar or a registry operator stops operating. Onchain naming has no common equivalent. If a registry operator ceased to operate, the onchain record would persist, but the services around it, such as resolution, royalties and issuance, might not. What persists depends on how much of the registry’s functionality is encoded in smart contracts that run without the operator and how much is delivered by hosted services.

Universal resolution. No body can require a wallet, a browser or an internet service provider to resolve a particular onchain TLD. Resolution is voluntary at every point. The DNS is simply better on this count: a delegated TLD resolves everywhere by default, and an onchain TLD resolves where support has been built.

Consequences for a brand owner and for a holder

For a brand owner, the governance picture produces two distinct problems. The first is visibility. An onchain TLD matching a brand may exist without the organization knowing, and names under it, such as pay.yourbrand, may appear in wallets that resolve them without any process having notified the trademark owner. The DNS offers no notification as of right either, but its registrations sit in a small number of well-known systems. Onchain, the records are public but spread across registries and chains, so finding them takes systematic monitoring. Namespace watch is the service of ours that monitors the names of a brand onchain.

The second problem is remedy. If an organization finds an onchain TLD that matches its mark and wants to hold it, the path is negotiation, not administrative transfer. No panel adjudicates the claim, no registrar is bound to execute a transfer order, and no registry-level body hears trademark complaints across the system. The practical path is to find the holder, approach them and agree terms. Whether that succeeds, and at what price, depends on the two parties alone. Acquiring the onchain TLD that matches a brand is the object of brand namespace recovery.

For a holder, the picture is the inverse of what a DNS registrant experiences: more direct control, more custody responsibility, and less recourse if something goes wrong. A holder whose TLD has commercial value has three things to understand. The first is the registry’s terms, including the conditions under which royalties activate. The second is the chain the record sits on and how that chain is governed. The third is where the TLD resolves, since reach is decided by software publishers the holder does not control.

Both readers benefit from knowing at which layer a problem sits, because the remedy, where one exists, is specific to that layer. A dispute over custody is a matter of chain records and of law. A collision is settled, if at all, in resolver software. A trademark conflict is a legal matter and possibly a matter of registry terms. Pursuing a remedy at the wrong layer costs time and produces nothing: a registry cannot make a wallet stop resolving a name issued elsewhere, and a wallet cannot change who holds a token. The glossary defines the terms used across these layers.

A first review you can run on one name

The map becomes useful when you apply it to one string, either the TLD you hold or the one that matches your organization. Take the layers in order and write down, for each, who decides and where their rules are published.

At the registry layer, identify which registry or registries have issued the string, and read their terms. At the chain layer, note which chain carries each record and look up the record on a block explorer. At the resolver layer, list the wallets and browsers that resolve the name, from their own documentation. At the marketplace layer, read the terms of any platform you would use to buy or sell. Then note what falls into the gaps: a second registry with the same string, a trademark question that only national law can answer, a service that depends on one operator. The result is a one-page statement of who has authority over that name and what would have to change for your position to change. Your own counsel decides what to do with it.

If the review ends in a decision to acquire or to sell, Hush Partners is a private desk for onchain TLDs that acts under mandate, either for a holder who wants a buyer or for an organization that wants a holder found and approached. Whichever side the mandate comes from, a standard mutual NDA covers every exchange, and the sale closes at the marketplace layer mapped above: on an aftermarket, through onchain escrow. The page for brands and legal teams is the place to start for an organization.

Questions people ask

Can a holder lose a TLD without agreeing to it?

At the chain layer, a protocol change or a fork could in principle affect how a token is recorded or transferred. At the registry layer, a change of terms could affect the services attached to a TLD. In both cases the holder’s legal position depends on the registry’s terms and on the applicable law. The most direct operational risk is simpler: loss of the private key that controls the wallet. Custody and key management are best settled before a TLD is put to any material use.

Does holding an onchain TLD give any rights in the ICANN DNS?

No. Onchain TLDs sit outside the ICANN DNS. Holding one gives no rights in the ICANN namespace, does not prevent ICANN from delegating the same string as a generic TLD, and creates no claim against a DNS registrant who holds a matching name. The Freename patent describes a method for scoring competing names in resolution software. That is a technical approach to priority, not a legal right.

Does a trademark give its owner a claim to the matching onchain TLD?

Not automatically. A trademark protects a sign for particular goods and services in the countries where it is registered or otherwise protected. It does not reserve the string in every naming system. Whether the existence or the use of an onchain TLD infringes a mark depends on what is done with the name and on the law of the country concerned, which is why the question goes to your own counsel and not to a registry.

Could a single authority emerge for onchain names?

Nothing in the structure requires one, and nothing forbids one. A dominant registry, a widely adopted standard or a resolution method implemented by most wallets would each concentrate authority at one layer without creating an apex over the others. A reader planning for the long term is better served by tracking each layer separately than by waiting for a counterpart to ICANN.