# How wallets and browsers decide which names to support
> Whether a name works depends on decisions made by the teams behind wallets and browsers. What drives those decisions.
Source: https://hush.partners/how-software-decides-which-names-to-support
Category: Market & ICANN
Published by Hush Partners.
---
Onchain names resolve outside the ICANN DNS root. An ordinary browser or wallet does not know what to do with `pay.yourbrand` unless a product team somewhere decided to add that capability. That decision is voluntary, internal, and reversible. Nothing in the architecture of onchain naming compels any application to participate.
This creates a situation that surprises many holders and brand teams: a name can be perfectly valid on its registry, correctly linked to a wallet address, and still produce nothing when a user types it or pastes it into a payment field. The registry and the application are independent systems, and the bridge between them is built only when a product team decides to build it.
What follows explains the logic of those decisions: what a product team weighs, where the complications arise, and what a holder or organization can and cannot do about partial support. The goal is not to predict which applications will add support for any given TLD. It is to give you a framework for planning around the support that exists and the gaps that remain.
## Support is a product decision, not a protocol obligation
The ICANN DNS is authoritative by convention. Every browser, every operating system, every ISP resolver agrees to consult the same DNS root, so a domain registered there resolves everywhere. Onchain namespaces carry no equivalent convention. A wallet team chooses whether to query a particular registry's resolver, the component that turns a name into the record behind it (the [glossary](/glossary) defines the terms used here). A browser extension team chooses which TLDs to pass through its lookup layer. The DNS lookup built into an operating system does not know onchain names exist.
That means support is, in its nature, a product feature. A team scopes it, builds it, ships it, and can remove it. The holder of an onchain TLD is in the same position as the developer of any API integration: dependent on a third party's roadmap. This is not a defect in the system. It is how open infrastructure works when it sits outside a shared DNS root. Understanding it as a product decision rather than a technical default is the first step toward planning honestly.
### Support is not a single switch
"Supported" also covers several different things, and a team can ship one without the others. A wallet may accept a name in the recipient field and translate it to an address. It may or may not display a name in place of an address in the transaction history, which is the reverse lookup. It may or may not open a website published under the name. Each of these is a separate piece of work with its own interface, its own tests and its own failure modes.
So a statement such as "this wallet supports the names" needs unpacking before you rely on it. Ask which action is supported, on which version of the application, on mobile or desktop, and for which record types. Two people can both be right when one says a name works in an application and the other says it does not, because they tried different things.
The practical consequence for a holder is that the question "does my name work?" always has an implicit qualifier: in which application, and for which action. See [what is live](/whats-live) for an inventory of working capabilities with their sources, understanding that the inventory changes as integrations are added or updated.
## What a product team weighs
When a wallet or browser team considers adding support for an onchain namespace, the analysis looks broadly like any feature prioritization: expected benefit against expected cost and risk. The variables are not exotic, but their interaction produces outcomes that are easy to misread from the outside.
| Factor | What the team asks | Effect on priority |
|---|---|---|
| User demand | How many of our users hold or need these names? | Higher demand raises priority |
| Implementation effort | How complex is the resolver integration? | Higher effort lowers priority |
| Ongoing maintenance | Will the integration break as the registry evolves? | Higher fragility lowers priority |
| Security exposure | Could supporting this namespace add phishing or spoofing risk? | Higher risk may block integration |
| Collision risk | Does this TLD string overlap with an ICANN TLD or another namespace? | Overlap often leads to a hold |
| Commercial relationship | Is there a partnership behind the request? | An agreement can speed up integration |
Demand comes first because product teams allocate effort where users push. A namespace with a small base of names in active use will struggle to reach the threshold that starts a scoping conversation, regardless of how technically clean the integration would be. This is circular by nature: low support limits adoption, which limits the demand signal, which limits support. Breaking that loop requires either a large existing community of users or a partnership that substitutes for organic demand.
Effort is less about raw engineering hours and more about surface area. An integration that requires the team to maintain a separate resolver, handle update feeds, and manage versioning across mobile and desktop will sit lower on the list than one that uses a published API and a single endpoint. Registries that invest in clean, stable developer tooling make themselves easier to integrate.
Maintenance is the factor outsiders tend to forget. Shipping an integration is a one-time cost. Keeping it working is a permanent one. Every dependency a product takes on is something that can fail in a release, and the team that added it is the team that answers for the failure. A feature used by a small share of users and backed by an external service that changes often is a natural candidate for removal when the team simplifies its code. This is why an integration that exists is not an integration that is guaranteed.
### The asymmetry between a missing feature and a wrong answer
One more consideration shapes all the others. For a product team, the two possible errors do not cost the same. If a wallet does not support a name, the user is mildly inconvenienced and pastes an address instead. If a wallet supports a name and returns the wrong address, funds may go to the wrong party, and a transfer onchain is generally not reversible.
A team that reasons carefully will therefore accept a long period of "not supported" in preference to a short period of "supported, with occasional wrong answers". From the holder's side this can look like indifference. From the team's side it is ordinary prudence about a feature that touches payments.
## Security and abuse as reasons for caution
Security considerations do more than reduce priority. They can stop an integration outright. Wallet teams in particular are exposed to fraud: if a user sends funds to a name that resolves incorrectly, the team bears reputational damage even if the fault lies elsewhere in the chain of systems.
The categories of risk that product teams assess include:
- **Resolver integrity.** Can the resolution output be altered by anyone other than the holder? A resolver whose answers can change without the holder's knowledge is a liability for any application that depends on it.
- **Lookalike names.** A namespace that allows a broad range of Unicode characters, or that does not screen for confusable strings, can contain names that are visually hard to tell apart. An application that resolves those names inherits the risk of misleading its users.
- **Abuse signals.** If a namespace contains many names that mimic brand identifiers or financial institutions, the whole namespace acquires a reputation that makes cautious product teams hesitant.
- **Dispute mechanisms.** The DNS has the UDRP, a policy that lets trademark owners challenge registrations in the domains it covers. Onchain registries vary in what mechanisms exist for contesting an abusive registration. A team evaluating integration will ask what recourse exists if a harmful name is resolved through its product.
None of these risks is unique to onchain names. Phishing with conventional domain names is common. But onchain names lack the institutional infrastructure that the DNS has accumulated over decades, and that gap matters to a risk-conscious product team. This is one of the places where the DNS is simply better equipped. A registry that addresses these concerns directly, through abuse reporting, filtering and clear documentation, makes a different risk calculation possible.
For a brand team, this caution works in your favor as much as against you. The same care that delays support for a name you hold also limits how far a confusing name can travel in mainstream applications.
## Collisions between systems as a complicating layer
A TLD string that appears in one onchain registry may also appear in another, or it may match a string that ICANN has delegated or is evaluating. When a product team integrates a resolver, it must decide what happens when a user types a name that the resolver knows about and that the ICANN DNS also knows about under the same string.
The safe default, from the team's perspective, is to let the ICANN DNS win. Most users of a general-purpose wallet or browser reach the conventional web more often than they reach onchain destinations, and breaking a conventional web address to serve an onchain one would generate support requests and damage trust. A cautious integration therefore applies the onchain resolver only to strings that are not in the ICANN root, or only when the user explicitly signals intent.
This means that a TLD whose string is already delegated in the ICANN root may not resolve through the onchain path in such a product, or may resolve only after the user changes a setting. A TLD whose string does not collide with anything in the ICANN root is in a more straightforward position.
The collision problem also runs forward in time. ICANN opens application rounds for new TLDs, so a string that is clear at one moment may later match a delegated one. A product team aware of this may hold off on a namespace whose string is the subject of an ICANN application and wait for the outcome. The comparison between an ICANN dotBrand and an onchain TLD involves exactly this tension, and the [side-by-side comparison of the two](/dotbrand-vs-onchain-tld) works through it.
### Collisions between onchain registries
The second kind of collision involves no ICANN string at all. Onchain registries are independent of one another, so nothing prevents the same TLD string from existing in two of them, with two different holders. A product that integrates both registries has to choose: resolve one and ignore the other, ask the user, or apply a rule.
Each option has a cost. Picking one registry makes the product a judge between namespaces, a role most teams do not want. Asking the user adds a step to a payment flow, where every added step is weighed carefully. Applying a rule requires a rule the team can explain and defend.
One documented attempt at such a rule is U.S. patent US 12,401,618 B1, held by Freename AG, filed on February 23, 2024 and granted on August 26, 2025. It covers rules-based resolution of names that collide: competing names are scored and the result decides which one resolves. "First registration", the earliest date of creation, is one of the weighted criteria, and the patent names new ICANN TLDs colliding with established web3 namespaces as a problem it addresses. The grant was reported by Domain Name Wire, and the text can be read on Google Patents. The patent describes a method. It is not a court ruling, and it binds neither ICANN nor any application. It is relevant here because a stated scoring method is easier for a product team to evaluate than a choice with no stated basis.
## Partnerships and integrations as the faster path
Organic adoption, where a product team integrates a namespace because enough users asked, is slow. The faster path runs through a formal relationship between a registry and an application.
A partnership typically changes the calculus on two of the factors in the table above: demand and effort. On demand, a partnership substitutes a commitment between two organizations for the organic signal the team would otherwise wait for. On effort, the registry may build and maintain much of the integration itself, for example by publishing a resolver or an extension, so that the application team's engineering cost is much lower.
The trade-off is that partnerships create concentrated support. A namespace that is live in one wallet because of a direct relationship may not be live in any other wallet for a long time, because the relationship covers one application, not the market. From a holder's perspective, the relevant question is not just whether support exists somewhere, but whether it exists where the intended users of the names actually transact.
The shape of support for Freename names shows what this looks like in practice. They are supported in Bitcoin.com Wallet, in MetaMask through Freename's resolver, and in desktop browsers through the Freename Web3 extension. This is meaningful coverage, and it is partial, and it changes. Onchain names in general do not open in an ordinary browser without additional software. Any planning that assumes universal resolution is planning on a false premise.
Note what that list contains: one wallet with support, one wallet reached through a component the registry supplies, and one extension the user installs. These are three different integration models, and each puts the work, and the decision, in a different place. In the first, the application carries the feature. In the second and third, the user or the registry does part of the work, which lowers what is asked of the application team.
The page on [names that resolve in wallets](/onchain-tld-wallets) documents which wallet capabilities are live. If the question is whether a name can be used as a payment destination, see [payments to a name](/onchain-tld-payments). For sites, see [websites published on an onchain TLD](/onchain-tld-websites).
## Why coverage grows unevenly
Support does not roll out uniformly across applications. It accumulates in clusters, and understanding why helps you assess the landscape more accurately.
The first cluster forms around a registry's own relationships. A registry tends to begin with a small number of integrated wallets or tools, because those arrangements were part of its plan from the start. That cluster stays stable while the registry focuses on other priorities.
The second cluster forms when a namespace reaches sufficient scale to generate organic demand. Users begin asking wallets why their names do not resolve. If the volume is high enough, the wallet team responds. This phase is unpredictable in timing.
A third cluster can form when an aggregator or shared resolver layer adds support for several namespaces at once. A service that already supplies resolution data to several wallets can extend that coverage to a new namespace without requiring each wallet team to build independently. The effect is that support arrives in several applications together, and can also leave them together if the shared layer changes.
The result is that a holder looking at the support map for a TLD may see it integrated in a few specific wallets, reachable through an extension, and invisible in several other applications the holder considers important. That map is not random. It reflects the relationships and the scale of the registry. It also changes, which is why any assessment should record the date on which it was made and the application versions that were tested.
## What a holder or organization can and cannot influence
Holders and operators sometimes ask whether they can push a specific wallet or browser to add support for their TLD. The honest answer is: with difficulty, and rarely through direct pressure alone.
What you can influence:
- **Registry choice.** A TLD inherits the integrations of the registry it is recorded on. A registry that already has resolver access in several wallets makes the resolution question easier than one with no existing integrations.
- **Record configuration.** Support for a TLD does not make an unconfigured name work. A name with no address record set returns nothing even in an application that supports the TLD. Setting and checking records is entirely in the holder's hands, and it is part of [putting a TLD to work after the transfer](/post-transfer-activation).
- **Community requests.** If many users hold names under your TLD, their requests to a specific wallet are the demand signal described above. This works only when the user base is real and active.
- **Technical readiness.** Clear documentation of how names under the TLD are meant to be used, consistent records, and a channel for reporting abuse make the namespace easier for an application team to assess.
What you cannot influence:
- The internal roadmap priorities of any application team.
- The terms on which a registry and an application work together.
- Whether a registry's integration with a specific wallet continues. Integrations can be withdrawn.
- ICANN's delegation decisions, which affect whether your TLD string faces a collision in the ICANN root.
This boundary matters for how organizations structure their commitments. A brand team that issues names under `.yourbrand` to customers or partners can describe what those names do, in which applications, with which caveats. It cannot guarantee that the same applications will support the names later. Contracts and communications that treat resolution as a permanent entitlement rather than a present capability create exposure. How that exposure is handled in a given contract is a question for your own counsel, and the answer varies by country.
## Planning around partial support
Partial support is the baseline condition for onchain names. The question is not how to eliminate it but how to plan around it. A practical framework has four elements.
**First, document the support baseline at launch.** Before issuing names under a TLD, establish and record exactly where those names resolve and how: which wallets, which browser extensions, which conditions. This documentation serves two purposes. It sets accurate expectations for the people who receive names, and it creates a record against which changes can be measured. Published inventories are a useful starting reference, but your own testing of the specific TLD in the specific applications you care about is the reliable source.
**Second, design use cases around confirmed support.** If a name is intended to function as a payment destination, verify resolution in the wallets your counterparties actually use before making that the centerpiece of a product or service. If the use case is a website, test the path that visitors will need to follow, including any software they must install. Do not design around best-case coverage. Design around the coverage you can verify.
**Third, keep a path that works everywhere.** A name is a convenience layered over an address or a content location, and the underlying value still works where the name does not. Show the wallet address next to `pay.yourbrand` in any payment instruction, so that a counterparty whose wallet does not resolve the name can still pay, and can compare the two where it does. Keep a conventional DNS address for anything the general public must reach. The DNS remains the only naming system an ordinary browser opens without help, and a plan that accepts this is sturdier than one that argues with it.
**Fourth, communicate limits explicitly.** People who receive a name under your TLD will tend to assume it works everywhere names work. That assumption is wrong, and discovering it through a failed transaction is a worse outcome than setting the expectation correctly from the start. A short, plain statement of which applications are confirmed and which are not, included in onboarding materials, reduces the support burden and protects the standing of the namespace.
For an organization acquiring a TLD with the intention of using it, the distance between holding the TLD and having names that function for real users is not administrative. It is a matter of where the names resolve. The concrete next step is to write the support map down: list the applications your users rely on, test one name in each, note the action tested and the date, and sequence your launch around the result. The [launch roadmap tool](/activation-roadmap) builds a roadmap for a newly acquired TLD and is a reasonable place to put that sequence.
## Questions people ask
### If a TLD is supported in one wallet, does that guarantee it stays supported?
No. Wallet integrations are maintained by product teams, and they can be modified or removed. A resolver dependency that breaks in an update, or a relationship between two organizations that ends, can interrupt resolution without notice to the TLD holder. This is one reason to document the support baseline at launch and to retest it at regular intervals, in particular after a major release of an application you depend on.
### Does holding a TLD give you any claim against a wallet that does not support it?
In general, no. On Freename, a TLD is recorded onchain as a token held in a wallet, and only its holder can issue names under it. What the holder has is defined by the registry and its terms. None of it reaches an application that has not integrated the registry's resolver, because support decisions by wallets and browsers sit outside the registry relationship entirely. If this matters for the value of a TLD you are considering, examine where its names resolve before closing, alongside the other elements of [how a TLD valuation is built](/valuation). Your own counsel decides what rights apply in your situation.
### Can issuing a large number of names under a TLD accelerate wallet support?
Indirectly, perhaps. Scale is part of the demand signal that wallet teams assess. A TLD with many names in active use is more likely to generate the user requests that move a team than one with a handful. But scale alone does not guarantee support, and volume created for appearance, meaning names registered to suggest demand without real use, is unlikely to have the intended effect. What reaches a product team is users asking for something they need, and registration counts do not produce that by themselves.
### What is the difference between a name resolving in a wallet and a name resolving in a browser?
These are two distinct integration paths. Wallet resolution looks up the wallet address behind a name, which enables payments. Browser resolution looks up the content location behind a name, which enables websites. A name may resolve in one context and not the other, because the two integrations are built and maintained separately, often by different teams with different priorities. Treating them as the same integration is a common planning error.