# Name collisions: when a DNS TLD meets an onchain TLD > The same string can exist as a TLD in the DNS and onchain. What a collision is, who it affects, and why being first is treated as relevant. Source: https://hush.partners/name-collisions-dns-and-onchain Category: Market & ICANN Published by Hush Partners. --- The Domain Name System is hierarchical and centrally coordinated. ICANN delegates TLDs, registries operate them, and registrars sell names under them. The chain of authority is clear. Onchain naming works differently: a registry is a smart contract on a public blockchain, a TLD is a token held in a wallet, and no single body sits above both systems. That structural difference matters little when the two systems use different strings. It matters a great deal when they share one. The collision question became concrete in 2026, when ICANN opened a new application round for generic top-level domains, its first in more than a decade. With 1,616 applications going forward, an applied-for string may already exist as an onchain TLD, recorded before the application was filed. The holder of that TLD may have built something on it, or intend to. The applicant for the same string faced an expected evaluation fee of USD 227,000, before advisers and registry operations, and expects its TLD to be the one that browsers and wallets resolve. This article explains what a collision is at the level of software that has to make a choice, where that conflict is felt in practice, and how the question of priority is being approached. After reading it, you should be able to explain the problem clearly to a colleague or a client, identify which position your organization occupies, and understand what each party can do about it.
1,616applications going forward in the 2026 ICANN round
USD 227,000evaluation fee each applicant expected to pay, with advisers and registry operations on top
Noneannual renewal fee on a Freename onchain TLD

Sources: trade press reports for the number of applications, ICANN's new gTLD program pages for the evaluation fee, the Freename registry for the renewal fee.

## Two naming systems with no common authority The DNS is an authoritative hierarchy. ICANN coordinates the DNS root zone, the list of TLDs at the top of the hierarchy. A new TLD enters the DNS root only after ICANN has evaluated the application, dealt with any objections, and signed a registry agreement. From that point forward, the TLD resolves globally because the resolvers of the public internet defer to the same DNS root. Onchain naming does not defer to that authority. A TLD on an onchain registry is recorded as a token on a public ledger. The token sits in a wallet, and whoever controls the wallet holds the TLD. There is no application to a coordinating body, no objection period, and no registry agreement with ICANN. The registry record is public and anyone can check it on a block explorer, but the registry that issued the token has no relationship with the ICANN root and does not need one to function. This means the two systems can independently assign the same string as a TLD. Neither assignment invalidates the other. There is no treaty, no shared database, and no escalation path that runs between them. When a string exists in both, the conflict is not a dispute before a single forum. It is a fork that each piece of software must settle on its own. ## What a collision is, concretely: software that has to choose In the DNS world, a name collision originally described something narrower: a private network using a string internally that later became a delegated public TLD. Queries that had only ever been answered by the local network then had a competing answer in the public DNS. The same structural problem applies between the DNS and onchain systems, but the mechanics differ. Consider a worked example with invented parties. Assume an organization holds `.yourbrand` as an onchain TLD on Freename. Users of a compatible wallet resolve `pay.yourbrand` to a wallet address. Later, a different organization applies to ICANN for `.yourbrand` as a generic TLD and, after evaluation, the string is delegated into the DNS root. Two authoritative answers now exist for any query that ends in `.yourbrand`. A piece of software that understands only the DNS returns the delegated version. A piece of software that understands only the onchain registry returns the onchain version. A piece of software that understands both has to choose, and that choice is a matter of policy, not a technical inevitability. The designer of such software has a small number of options. It can always prefer the DNS answer. It can always prefer the onchain answer. It can ask the user, or let the user set a preference once. Or it can apply a rule that compares the two candidates and returns the one that scores higher. Each option is defensible, and each produces a different result for the same string. Nothing obliges two tools to pick the same option. The collision does not break either system on its own. Both continue to function. What breaks is consistency: the same string produces different answers depending on who is asking and what software they use. ## Where the collision is felt: wallets, browsers and extensions The conflict surfaces at the resolution layer, the point where a string typed by a user is turned into an address or a resource. Different tools handle this differently, and coverage of onchain TLDs is partial. On the onchain side of a collision, two wallets support Freename names: Bitcoin.com Wallet, and MetaMask through Freename's resolver. In desktop browsers, they open through the Freename Web3 extension. Outside these environments, an ordinary browser does not open an onchain name without support. That limit is real and should be stated honestly to anyone who asks: [wallets that resolve onchain names](/onchain-tld-wallets) and browser extensions mark the perimeter of resolution, and that perimeter changes as support is added or withdrawn. When an ICANN-delegated TLD exists for the same string, mainstream browsers resolve the DNS version without any extension, because they query the public DNS by default. A user without a supporting extension or a compatible wallet reaches the resource of the DNS operator. A user whose extension or wallet prefers onchain resolution may reach the resource of the onchain holder. The same string, typed by two users on two machines, can lead to two different destinations. The place where this matters most is not the web page. It is the payment. A name typed into a wallet stands in for an address, and funds follow whatever the wallet resolves. A wallet that supports the onchain registry and has no reason to consult the DNS will keep returning the onchain answer after the DNS delegation. For the people involved, the question is therefore less "which site opens" than "which record does this tool trust". | Who is affected | What they experience | Nature of the exposure | | --- | --- | --- | | DNS applicant or operator | Some users reach the onchain namespace under the same string | Reputational and operational | | Onchain TLD holder | Mainstream browsers default to the DNS version | Commercial and usage | | End user | The same string resolves differently depending on software | Trust and reliability | | Wallet or extension developer | Must set a preference for colliding strings | Technical policy decision | ## The term "name collision" in the DNS world The term comes from the DNS community and predates the onchain question. When ICANN prepared an earlier expansion of the DNS, a concern emerged: companies and institutions had long used strings on their internal networks that were not delegated in the public DNS, on the assumption that they never would be. Once such a string was proposed as a new TLD, queries that had always been answered internally could reach the public DNS instead, with results ranging from user confusion to security exposure. In outline, the response of ICANN and its advisory bodies was to study how often such queries leaked, to treat strings differently according to the risk they carried, to hold back some strings, and to ask operators of newly delegated TLDs to take mitigation measures. Technical guidance was published so that network administrators could identify and reduce their own exposure. That history established a principle: the DNS community accepts that a collision between a newly delegated TLD and an existing use of the same string is a real problem that deserves a defined response. But that work addressed the collision between the DNS and private networks. It was not designed for a collision between the DNS and a separate public naming system with its own registry and its own users. The differences are worth spelling out. A private network is a closed environment whose administrator can rename an internal string once warned. An onchain TLD is a public asset with a holder, and possibly with names issued under it to third parties who rely on them. The private use was never a claim to the string. The onchain record is one, at least within its own system. And the earlier problem lived inside the DNS, where ICANN could set conditions on delegation. The onchain side sits outside its reach. The earlier approach therefore does not carry over without change, and this article does not predict how the matter will be handled. ## Priority: why first registration is treated as a relevant criterion When two claims to the same string exist, any system that must choose between them needs a criterion. The idea that the earlier claim deserves weight is old and familiar. Trademark systems give weight to who used or registered a sign first, with rules that vary by country. The DNS itself allocates names under a TLD largely to whoever registers first. Being first is not always decisive, but it is rarely irrelevant. One published method takes this idea into collision handling. U.S. patent US 12,401,618 B1, held by Freename AG, was filed on February 23, 2024 and granted on August 26, 2025. As reported by Domain Name Wire and set out in the patent text on Google Patents, it covers rules-based resolution of names that collide: competing names are scored, and the result decides which one resolves. In that scoring of colliding names, the earliest date of creation counts: the patent lists it, under the label "first registration", among the criteria that carry weight. The problems the patent says it addresses include the very case discussed here, new ICANN TLDs colliding with established web3 namespaces. The reasoning behind the criterion is straightforward. A date of creation is a fact, not an opinion. On a public blockchain it is recorded at the moment the token is created and can be read by anyone afterward. That makes it cheap to verify and hard to dispute, two qualities a rule applied by software needs. A criterion such as "which name is better known" would require judgment. A date requires only a lookup. Two limits apply. First, the date of creation is one weighted criterion among others in the method. It is not a rule that the earliest name always resolves. Second, an earlier date carries no weight in ICANN's process. ICANN evaluates applications under its own rules, and the patent does not bind it. Temporal priority is relevant where a resolution layer chooses to apply a method that counts it, and nowhere else by default. ## The position of an applicant in the round An organization that applied to ICANN for a string committed to an expected evaluation fee of USD 227,000. It may also have engaged a registry operator, legal counsel and consultants, which brings the total higher. Its expectation is that, if the application succeeds, it will operate the authoritative registry for that string in the DNS, with global resolution in all mainstream browsers. On the DNS side, that expectation is sound. The DNS is simply the stronger system for reach: no extension, no special wallet, no configuration. If an onchain TLD with the same string already exists, the applicant faces split resolution from the first day of delegation. Users with a supporting extension or a compatible wallet may reach a different destination. The applicant has no mechanism within ICANN's framework to require the onchain holder to give up or transfer the token. ICANN's authority runs to the DNS root. It does not reach onchain registries. The practical consequences depend on how far the onchain TLD has been put to work. An onchain TLD with no names under it presents a limited conflict in practice. One with names in use, resolving in wallets and receiving payments, presents a more significant one. The applicant should assess the state of the onchain namespace before assuming that delegation alone settles the matter. A separate consideration is whether the applied-for string is also a registered trademark. A trademark registration does not automatically produce a remedy against the holder of an onchain TLD. Trademark law operates through national courts and offices. For domain names it also operates through the UDRP, which binds registrars accredited by ICANN but does not bind onchain registries. The page that explains [what a trademark TLD is](/trademark-tlds) covers the trademark side, and the [comparison of a dotBrand and an onchain TLD](/dotbrand-vs-onchain-tld) sets the two models side by side. One path removes the conflict entirely: acquiring the onchain TLD and holding both sides. It is discussed further down. ## The position of the holder of the onchain TLD A holder whose TLD was created before the application has a timestamp on a public blockchain. Anyone can check it. It is the one piece of evidence the holder never has to argue about. What the holder does not have is a mechanism to stop ICANN from delegating the same string into the DNS. ICANN's process provides its own grounds for objection, and an onchain record is not, in itself, a recognized basis for rights in that process. A holder who also owns a registered trademark in the string stands on different ground, because the trademark, not the token, would carry the argument. Whether any objection is available and merited depends on the facts and on the rules of the process. This article is information, not advice, and your counsel assesses the merits. The holder's more durable position sits at the resolution layer. If names have been issued under the TLD and resolve in supporting wallets and browsers, the people who use them have an established relationship with that namespace, and it does not disappear when a DNS TLD is delegated. A TLD that exists only as a token, with no names under it, has little practical foothold. A TLD with names in daily use has a material one. Two features of the registry shape the holder's options. On Freename, there is no annual renewal fee on a TLD, so the holder is not forced to decide by a billing date: the token stays in the wallet until the holder moves it. And only the holder of a TLD can issue names under it, which means the holder alone decides whether the namespace grows, stays dormant, or is transferred whole. A holder weighing those options will find the considerations for [TLD holders](/holders) set out on the site. ## What a collision resolution method is, and what it is not A method for resolving collisions is something a resolution layer (a browser, a wallet, an extension, a resolver) can apply when two competing answers exist for one string. The patented method described above scores each candidate against weighted criteria and returns the one that scores higher. Its merit, for the developer, is that the answer is deterministic: the same inputs give the same output, and the reasoning can be written down. The distinction in the callout matters because technical priority is easily mistaken for legal ownership. A court is the forum for a dispute over ownership, and the applicable law depends on the jurisdiction, the nature of the claim, and whether trademark rights are involved. A resolution method serves software that needs an answer in milliseconds. It is not a substitute for legal proceedings, and it binds no court or administrative body. A method also applies only where it is implemented. A tool that does not use it is unaffected by it. For that reason, neither side should read a favorable score as a settled outcome, and neither should read an unfavorable one as a loss of rights. What a scoring method does offer both sides is a shared way to describe their positions. Each can state its date of creation and compare. That comparison is useful when deciding whether a conversation between the two parties is a better course than leaving every tool to choose for itself. ## What an organization in either position can do The options are not symmetric, but both sides have real choices. The sequence below applies to an applicant, to a brand owner and to a holder, with the fourth and fifth steps depending on which side you are on.
Assessing and managing a collision
  1. Identify the collisionCheck whether the string of your DNS application, or of your brand, exists as an onchain TLD. A block explorer is enough for this, since the registry record is public and open to anyone who looks. Do this as early as you can.
  2. Assess the state of the onchain namespaceA token with no names under it is a different matter from a TLD with names in use. Look at whether names have been issued and whether they resolve in supporting wallets and browsers.
  3. Establish the dates on both sidesNote the date of creation of the onchain TLD and the date of the application. Have your own counsel assess any trademark rights in the string, which are a separate question from the dates.
  4. If you are the applicant, consider acquisitionHolding the onchain TLD as well removes the collision for that string. If you choose this path, make the approach discreetly and courteously, under a confidentiality agreement, and expect that the holder is free to decline.
  5. If you are the holder, decide what you want from the TLDOperating the namespace, keeping it, and selling it are all legitimate choices. Record your date of creation and the names in use, and take advice before answering an approach.
For the first step, a brand owner can use the [Namespace Exposure Score](/namespace-exposure-score), a free tool that scores how exposed a brand is onchain. For the second, the page on [what works with onchain TLDs](/whats-live) lists each capability with its sources, which helps separate a namespace that is in use from one that is only recorded. One point of conduct applies to both sides. A collision is not a lever. An applicant who treats the holder as an obstacle, or a holder who treats the applicant as a target, turns a manageable technical overlap into a dispute. The parties who settle these situations well tend to be the ones who state their positions plainly and let the other side take its time. ## Why holding both sides removes the question The cleanest outcome of a collision is that one party holds the same string in both systems. An applicant who also acquires the onchain TLD becomes the operator in the DNS and the holder of the token. For that string there is no competing answer and no resolution policy to work around, and users are not sent to two destinations. The two namespaces can then be run separately, run in parallel with matching names, or one can be left dormant. Holding both sides does not change what each system can do. The onchain TLD still resolves only where it is supported, and the DNS TLD still depends on ICANN's process and its ongoing obligations. What changes is that the choice made by each piece of software no longer matters to the organization: whichever answer a tool returns, it leads to the same party. For an applicant, this means finding out whether a holder exists and, if so, opening a conversation at a moment of its own choosing. For a holder, the mirror reasoning applies. If a DNS TLD is delegated for the same string, mainstream browsers will default to the DNS version, and the reach of the onchain namespace will depend on the wallets and extensions that support it, which is partial and subject to change. A transfer to the applicant may be a better outcome than running a namespace alongside a DNS TLD of the same name. It may not be. The answer depends on what the holder has built and intends to build. This is the situation in which a private desk is used. Hush Partners acts for organizations that mandate it to find and approach a holder, and for holders who mandate it to find a buyer. An organization whose brand matches an onchain TLD can read how [brand namespace recovery](/brand-namespace-recovery) works. On either side of a collision, a standard mutual NDA covers every exchange, and the closing runs through onchain escrow on an aftermarket. The [glossary](/glossary) defines the terms used in both systems, and the desk is reached through the [contact form](/contact). ## Questions people ask ### Does an ICANN objection process cover onchain TLD holders? Not as such. ICANN's process sets out its own grounds for objection, and holding an onchain TLD is not, in itself, one of the recognized bases for rights. A holder who also owns a registered trademark covering the string may have an argument based on that trademark, but the onchain record would not be what carries it. Counsel familiar with both trademark law and ICANN's procedures should advise on whether a filing is available and merited. ### Can the UDRP be used to challenge an onchain TLD? The UDRP (the Uniform Domain-Name Dispute-Resolution Policy) binds registrars accredited by ICANN and applies to domain names registered under ICANN-delegated TLDs. It does not apply to onchain registries, which are not parties to it. A trademark owner who wants to challenge the use of a name in an onchain namespace would need to look at other legal avenues, which vary by country and by the facts. ### If the onchain TLD was created after the ICANN application was filed, does the applicant have priority? Under a criterion of first registration, the earlier date counts in favor of the name that carries it. But the comparison is not as simple as it looks. The date of an application is not the date of delegation into the DNS root, which follows evaluation and takes time. Which dates are compared, and under which framework, decides the answer. In the patented method the date is one weighted criterion among others, and in ICANN's process an onchain date has no role. This is a fact-specific question for counsel. ### Does holding an onchain TLD give the holder trademark rights? No. An onchain record is not a trademark registration. Trademark rights arise from use in commerce, from registration with a national or regional office, or from both, depending on the country. Holding the token establishes that you hold the TLD under the registry's terms. It does not, by itself, create intellectual property rights in the string. ### What happens to the onchain TLD if the DNS TLD is delegated and widely adopted? The onchain TLD continues to exist. It is a token in a wallet, and the delegation of a DNS TLD does not delete or alter it. What changes is the default behavior of mainstream browsers, which open the DNS version without any extension. The onchain namespace remains reachable for users of supporting wallets and browsers, and its practical reach depends on how widely those tools are used. The holder keeps the token and can continue to issue names, operate the namespace, or agree to a transfer.