Interoperability between naming systems: why it is hard

The internet runs on one naming convention: a string, a dot, another string. That simplicity hides a political fact. The convention works only because one organization, ICANN, coordinates the list of strings that are recognized at the top of the Domain Name System (DNS). Almost every device that connects to the internet relies on that list. Onchain naming systems, which are registries that record name ownership as tokens on a blockchain, do not use that list. They operate in parallel, with their own records of who holds what.

Two systems can each assign the string .yourbrand to different parties, and both assignments can be valid within their own rules. No overriding mechanism resolves that conflict. Interoperability, in the sense that both systems agree on what a name means and where it points, does not exist by design. It is approached, incompletely, through software choices made at the browser, the wallet, and the resolver.

This article explains the structural reasons why full interoperability is hard, describes the visible symptoms and the partial approaches that have emerged, and gives you a framework for planning around the resulting coexistence.

What interoperability would actually require

Interoperability between naming systems would require three things to align: a shared namespace (agreement on which strings are valid and who holds them), a shared resolution path (agreement on how a query is answered), and a shared governance process (authority to adjudicate disputes and update the rules).

Each of these is separately hard. A shared namespace means that two independent registries, one keeping its records in DNS zone files under ICANN’s coordination and one keeping its records in a smart contract on a blockchain, would need to consult each other before assigning a string. Neither system was designed to consult the other. A shared resolution path means that software across a very large number of devices would need to know which registry to query first, and what to do when both return a result. A shared governance process means some body would need the authority to say whose record prevails when they conflict.

The DNS has all three, within its own scope, because ICANN was set up to provide them. Onchain systems have internal governance (the smart contract, a program that runs on the blockchain, is the rule), but that governance does not extend to the DNS, and ICANN’s remit does not extend to a blockchain. The gap is not technical in origin. It is a matter of who has authority over what, and authority is not fixed by a software update.

It helps to separate interoperability from two weaker things that are often given the same name. The first is bridging: one piece of software that can read two registries and show the user a result from either. The second is mirroring: the same party holding the same string in two systems and keeping the records aligned by hand. Both exist, and both are useful. Neither makes the systems agree. A bridge reflects the choices of whoever wrote it, and a mirror works only when one party happens to hold the string on both sides.

The glossary defines TLD, smart contract, resolver, and the other terms used throughout this article.

Why no common authority exists to impose a solution

ICANN is a non-profit organization that coordinates the DNS through a multi-stakeholder process. Its practical authority rests on the fact that internet service providers, registrars, and browser makers all choose to start from the ICANN root. That choice is not technically mandated. It is a convention sustained by network effects and by the absence of a credible alternative for the traditional web.

Onchain systems derive their authority from a different source: the consensus of a blockchain network. A name registered on such a system is held by whoever controls the wallet that holds the token. The record is public, anyone can check it on a block explorer, and it does not require ICANN’s permission to exist. The rule of the registry is its smart contract, and how that contract can be changed depends on how each registry is built.

No treaty, no inter-governmental agreement, and no technical standards body has authority over both systems at once. The DNS community has studied name collisions for a long time, but mostly in an older form: strings used inside private corporate networks that leaked into public DNS queries. That kind of collision can be measured, because the stray queries reach DNS servers and can be counted. Onchain names present a different and harder problem. They resolve through smart contracts, browser extensions, or wallet software, and they may never generate a DNS query at all. A use that leaves no trace in the DNS is hard to assess with tools built around the DNS.

The bodies that write technical standards for the internet publish guidance on DNS architecture, but they have no mandate over onchain systems. Standards bodies can recommend. They cannot compel an onchain registry to change how it assigns names, and they cannot compel a wallet maker to prefer one registry over another.

The technical side: who answers for a name

When a user types a name into a browser, the browser sends a query to a resolver, the service that looks names up and is typically provided by an internet service provider or a public DNS service. The resolver walks the DNS hierarchy. It starts at the DNS root, which directs it to the authoritative nameserver for the TLD, which in turn points to the record for the name under it. The entire chain depends on the ICANN root being the starting point.

Onchain names fall outside that chain at the first step. An ordinary resolver does not know how to query a blockchain registry. It will either return a negative result (the name does not exist in the DNS) or, if the same string exists in the DNS, return the DNS record of whoever holds it there.

Resolution of onchain names therefore requires additional software. That software can take several forms: a browser extension that recognizes known onchain TLDs and routes those queries to a blockchain resolver; a resolver configured to handle certain TLD strings through an onchain lookup; or a wallet application with resolution built in. Each of these works only for the user who has installed or is using that software.

One documented technical response to the collision problem is a scoring approach. U.S. patent US 12,401,618 B1, held by Freename AG, filed on February 23, 2024 and granted on August 26, 2025, covers rules-based resolution of names that collide: competing names are scored, and the result decides which one resolves. Anyone who wants to read the scoring rules for themselves will find the text of the patent on Google Patents, and the grant was reported by Domain Name Wire. It is a method. It is not a standard, it is not a court ruling, and it does not bind ICANN or any other registry.

In practice, names on the Freename registry are supported in Bitcoin.com Wallet, in MetaMask through Freename’s resolver, and in desktop browsers through the Freename Web3 extension. Coverage is partial and changes as software is updated. The page on what is live tracks which capabilities work in which environments, with sources.

The result is a landscape where the answer to “where does this name point?” depends on which software the user is running. Two users entering the same string may reach different destinations, or one may reach a destination and the other may receive an error.

What this means for the question you ask a vendor

The useful technical question is therefore never “does this name resolve?” It is “in which software, for which users, and who decided that?” Every answer has an owner: the maker of a wallet, the publisher of an extension, the operator of a resolver. That owner can change the answer in a later release without consulting the registry or the holder. When you evaluate a naming system, map the resolution path the same way you would map a supply chain: each link, who controls it, and what happens to your use case if that link changes.

The incentive side: why systems are built differently

Each naming system reflects the goals of the people who built it and the people who use it. The DNS was built to sustain a globally unique, stable, and interoperable public network. Stability and uniqueness are structural goals: a name must mean the same thing everywhere, or commerce and communication fail. ICANN’s governance is multi-stakeholder, deliberate, and consensus-based, and it exists to protect that stability.

Onchain naming systems were built with different goals: registration without a gatekeeper, and ownership that sits directly with the holder. On an onchain registry, control of a name follows control of the wallet that holds the token, not a registrar’s account system. That property is valuable to certain users and certain use cases. It comes at the price of the DNS coordination layer, because that layer depends on a single coordinated list, which is precisely what onchain systems set out to do without.

These are not engineering choices made carelessly. They are design trade-offs made deliberately. A system optimized for holder control will, by construction, resist centralized coordination. A system optimized for universal interoperability will, by construction, depend on a central coordinator. The gap between the DNS and onchain naming is not a defect waiting for a fix. It is the consequence of different goals, each pursued successfully.

This is also why the gap persists commercially. Onchain registries compete for users, and what they offer is the set of properties that makes interoperability hard. Giving up holder control in exchange for DNS compatibility would undermine the reason many holders chose an onchain TLD in the first place. The DNS, for its part, is simply better at what it was built for: one answer, everywhere, in every ordinary browser. Neither side has a strong incentive to absorb the other’s model.

The same logic applies between onchain systems. Two onchain registries that both issue TLDs are competitors as well as neighbors. Each has holders who paid for their names and expect them to keep working. An agreement that one registry yields a string to another would mean telling some holders that their record no longer resolves. No registry volunteers for that conversation, which is why agreement between onchain systems is no easier than agreement with the DNS.

If you are evaluating which kind of TLD fits your needs, the comparison between a dotBrand and an onchain TLD sets out the trade-offs in detail.

Collisions as the visible symptom

A collision occurs when the same TLD string is delegated in the ICANN DNS and registered in an onchain system, or when two onchain systems both record the same string. If an onchain registry has issued a TLD string and ICANN delegates the same string to a DNS registry, two separate authorities stand behind the same string.

This is a documented concern and not a thought experiment. The Freename patent names new ICANN TLDs colliding with established web3 namespaces as a problem it addresses. ICANN opened a new application round for generic top-level domains in 2026, the first in more than a decade, and every new delegation is a string that may already exist somewhere onchain.

For a holder of an onchain TLD, a collision has three consequences. First, a DNS registry holding the same string can issue names under it that open in standard browsers, without any action by the onchain holder. Second, users typing the string into an ordinary browser reach the DNS side, not the onchain holder, and may never know a different record exists. Third, the two sides sit under different dispute mechanisms. A party operating in the DNS is within reach of the Uniform Domain-Name Dispute-Resolution Policy (UDRP), while an onchain record sits outside it, so a trademark owner faces two different sets of tools for what looks like one string.

Where several naming systems coexist without coordination, each new string issued anywhere adds to the number of possible overlaps. The namespace as users experience it becomes fragmented, and compatibility with the DNS becomes harder to reason about.

Collisions also run in the other direction. An organization that applies for a dotBrand TLD through ICANN, at an expected evaluation fee of USD 227,000 per application before advisers and registry operations according to ICANN’s new gTLD program pages, may find that the same string is already registered on one or more onchain systems. The ICANN delegation creates authority in the DNS, but it does not extinguish the onchain record. Both records coexist, in separate resolution paths, until software or legal process intervenes.

Collision risk is therefore not something that begins at a future date. It is a standing condition for any organization whose name is a plausible TLD string.

Approaches to resolving collisions

No universally accepted resolution mechanism exists. The approaches that have emerged operate at different layers and carry different limitations.

Priority by registration date is the principle that whichever system recorded the string first should prevail. It is intuitive, and it resembles the priority reasoning found in parts of trademark law, where the rules vary by country. But it depends on both systems recognizing each other’s timestamps, which they do not. The Freename patent describes “first registration”, the earliest date of creation, as one of the weighted criteria in its scoring. That criterion applies where the method is implemented, for the users and software that rely on it. It does not compel a DNS resolver to yield to an earlier onchain record.

Software-layer routing is the approach where a browser extension, a configured resolver, or a wallet routes queries for certain TLD strings to specific registries. This works within the user base of the software. It is not a global solution. It is a local one, applied one installation at a time. Coverage is uneven and changes when software is updated or discontinued.

Legal remedies are available in the DNS through the UDRP, which binds registrants through the contracts of ICANN-accredited registrars, and through national courts applying trademark law. The UDRP has no direct reach into onchain registries, where there is no accredited registrar to receive a complaint. National courts can reach parties over whom they have jurisdiction, but giving effect to a decision against an onchain record, whose holder may be known only by a wallet address, is difficult in practice. This is information, not advice, and the position differs from one country to the next.

Negotiated transfer or coexistence is the outcome in many commercial situations. A party that holds an onchain TLD matching a brand string and a party with trademark rights may reach a transfer agreement, a coexistence arrangement, or a license. That outcome requires reaching the holder, agreeing on terms, and executing the transfer through the registry’s own mechanism.

The table below takes the obstacles one level up from individual collisions and sets each against what it would take to remove it.

None of the items in the right-hand column is impossible in principle. Each one asks some party to give up something it was built to keep, which is why progress comes through narrower arrangements between specific pieces of software.

Coexistence as the practical state

The condition you can actually plan for is not interoperability. It is coexistence: several systems operating in parallel, each authoritative within its own resolution path, each largely invisible to the other.

That coexistence is functional for some purposes. An organization that holds a TLD onchain and uses it for names that resolve in wallets, issuing names like pay.yourbrand that point to payment addresses, is operating entirely within the onchain resolution path. Its users are wallet users. They do not need an ordinary browser to resolve the name, because payment is the function. A DNS record for the same string has little bearing on that use case, as long as the user population uses wallet software that supports the name.

Coexistence becomes operationally difficult when a use case needs both audiences: the same name has to reach a user with an ordinary browser and a user with onchain resolution. At that point, the organization must choose. It can publish in the DNS, publish onchain, or maintain records in both systems with the management overhead that implies. None of these is a clean technical solution. All require deliberate decisions about which audience gets priority and which use cases are supported.

A practical way to frame that decision is by function, not by system. Public websites, email, and anything a stranger must be able to open without preparation belong in the DNS, where resolution is universal. Functions that already take place inside wallet software, such as receiving a payment at a readable name or identifying a counterparty, can live onchain without loss. Functions that straddle the two need an explicit rule about which record is the reference when they disagree.

Coexistence also requires monitoring. A string that is clear in the DNS at one point may not be clear after a later ICANN round. The holder of an onchain TLD whose string appears in an ICANN application faces a change in the operating environment without having taken any action. Awareness of both the DNS and the onchain namespace is an ongoing operational task, not a one-time assessment. Namespace Watch is the service that monitors the names of a brand onchain, for organizations that prefer a standing watch to periodic manual checks.

Planning for an organization

An organization that holds, is considering acquiring, or has trademark interests in a string that could appear in several naming systems needs a framework that holds across systems instead of optimizing for one.

The first step is a baseline mapping: which strings matter to the organization, whether those strings exist in the DNS, in onchain registries, or in both, and what the public record shows in each case. The Namespace Exposure Score is a free tool that scores how exposed a brand is onchain, and it gives a starting point for that mapping. For the strings that matter most, refresh the mapping after any major ICANN round, because new delegations change where overlaps can occur.

The second step is a legal assessment. Trademark registrations, their classes, and their territorial scope shape what remedies are available if a third party uses a matching string in a way that creates confusion. The assessment is not the same for DNS strings and onchain strings, and the available remedies differ. Your own counsel determines which registrations are relevant and what actions are proportionate.

The third step is an operational decision about which systems to hold positions in. Holding a position onchain does not substitute for a DNS registration, and holding a DNS registration does not neutralize an onchain record held by a third party. Where a string that matters to you is held by someone else, the options are the ones described above: legal process where it reaches, software-level outcomes you do not control, or a negotiated transfer.

The fourth step is governance of whatever position the organization holds. Know which wallet controls the TLD token. Make sure key management is sound: a TLD held in a single wallet controlled by one person is a single point of failure, and a multisignature wallet, which needs several approvals for a transfer, is the usual answer. Name an internal owner for the namespace, responsible for compliance and for the operational decisions about which names to issue and to whom.

Where a negotiated transfer is the route, this is the work Hush Partners does. An organization can mandate the desk to find and approach a holder, and the page for brands and legal teams describes how that starts. A holder can mandate the desk to find a buyer. Every exchange is covered by a standard mutual NDA, closing runs through onchain escrow on an aftermarket, and post-transfer activation covers putting the TLD to work afterwards.

Questions people ask

Does holding a trademark give rights against an onchain TLD holder?

Trademark rights give their owner grounds to challenge uses that create confusion in commerce, in the jurisdictions where the mark is protected. Whether those grounds translate into a practical remedy against the holder of an onchain TLD depends on whether a court has jurisdiction over the holder, whether the holder’s use is commercial and relates to the goods or services the mark covers, and whether a court is prepared to order relief that reaches an onchain record. The answers vary by country and by the specific facts. Your own counsel decides.

Can an onchain TLD be moved to the DNS?

Not directly. An onchain TLD and a DNS TLD are different objects in different registries with different technical and legal structures. An organization that wants a DNS TLD with the same string as an onchain TLD it holds must apply to ICANN separately, in an application round, with the fees and evaluation that the round involves. Holding the onchain TLD does not reserve the string in the DNS or create any right to an ICANN delegation.

If a string is registered onchain first, does that give priority?

Within a resolution system that applies a first-registration criterion, as the Freename patent describes, an earlier date of creation is one weighted factor among others. Outside such a system, no universal first-registration principle applies. The DNS assigns strings through its own procedures, ICANN evaluates applications under its own rules, and courts apply trademark priority rules that differ by country and do not turn on the date of a record in a technical system. An early position onchain is a fact you can point to. It is not a legal guarantee.

What happens to onchain TLD holders if ICANN delegates the same string?

The delegation creates authority over the string within the DNS resolution path. Users of standard browsers without additional software reach the DNS side. The onchain holder keeps the record and its validity within onchain resolution paths, but its practical reach to ordinary browser users is limited to those with supporting software. A holder in this position is well served by taking legal and technical advice on what the record still does and for whom.

Does resolution support change over time?

Yes, and it can change without notice to the holder. Wallet software is updated, browser extensions are revised, and resolver configurations change. A name that resolves in a given wallet may stop resolving after a later release if the resolver it depends on is removed or modified. This is a structural property of onchain resolution: it depends on software choices made by third parties, and those choices are not contractually owed to any TLD holder. Periodic testing in the software your users actually run is the reliable response.