You applied for a dotBrand: deciding on the onchain twin
For organizations in the application round: how to decide whether to acquire, watch or leave the onchain TLD that carries the same string.
Your organization has filed an application for a dotBrand generic top-level domain. The application covers a string in the ICANN Domain Name System. It does not touch anything outside that system. On an onchain registry such as Freename, the same string can exist as a separate TLD, recorded as a token in a wallet, governed by different rules, and held by a party with no connection to your organization.
That fact does not require alarm, and it does not require immediate action. What it requires is a structured decision, taken by the right people, documented, and scheduled for review. This article gives you that structure. By the end of it, you will be able to run a one-meeting decision process, weigh three options against five criteria relevant to your organization, and produce a defensible record of whichever path you choose.
The decision is one of proportion and probability, not of principle. For some applicants the onchain question will be a small matter that deserves a short record and a review date. For others it will be material. The framework below tells you which you are dealing with.
Application count as reported by the trade press; evaluation fee from ICANN's new gTLD program pages; absence of a renewal fee from the Freename registry.
Why every applicant faces this question
The ICANN Domain Name System and onchain naming registries operate in parallel. ICANN delegates a string within the DNS root. An onchain registry records a string as a token on a blockchain. Neither system recognizes the other’s authority, and neither gives the other’s holder any automatic right to the string.
An onchain registry does not ask whether a string is the subject of an ICANN application, and ICANN’s evaluation does not look at onchain registries. The two records are created independently, on different timelines. So the string in your application may have an onchain counterpart that is older than the application itself, which is why this article calls it the older twin. Whether it exists in your case is a matter of fact that you can check, because the registry record is public.
The collision between the two systems is recognized by the registries themselves. Freename AG holds a U.S. patent, US 12,401,618 B1, on a rules-based way of resolving names that collide. Competing names receive a score, and the score decides which one resolves. The earliest date of creation, called “first registration”, is one of the weighted criteria, and the patent text cites new ICANN TLDs meeting established web3 namespaces as one of the problems it addresses. Your team can read the text on Google Patents, and the grant was covered by Domain Name Wire. Read it for what it is: a description of a method. It is not a court ruling, it does not bind ICANN, and it does not establish rights under trademark law.
The UDRP, the Uniform Domain-Name Dispute-Resolution Policy, is the procedure trademark owners use against abusive registrations in the DNS. It binds registrants through the contracts of ICANN-accredited registrars. An onchain registry sits outside that contractual chain, so the procedure your team knows well does not reach an onchain TLD. Your trademark gives you strong tools inside the DNS. Outside it, the practical choices are different: acquisition, monitoring, or a considered decision to leave the matter alone.
What you already committed, as context for proportion
Before assessing the onchain question, it helps to recall what the application itself represents. ICANN’s new gTLD program pages put the expected evaluation fee at USD 227,000 per application. That is the ICANN fee alone. Adviser costs, the registry operator agreement, internal preparation and the continuing cost of running a registry after delegation all come on top of it.
Against that baseline, the onchain question is a secondary matter. It is not trivial, and the sections below explain when it is significant, but it should be assessed in proportion. An organization that has committed the resources and governance needed to operate a TLD in the DNS has the institutional capacity to address a parallel onchain asset if the facts justify it.
Proportion cuts both ways. A program of this size deserves an hour of structured attention on the one asset that carries the same string outside the system the program covers. It does not deserve a second program. The onchain TLD has no application process, no evaluation and, on Freename, no annual renewal fee, so the continuing cost of holding one is mostly a matter of custody and governance. The real question is not whether your organization can afford to look at it. The question is whether the string has, or will have, any working role onchain for the people you deal with.
The application also tells you that your organization has a declared interest in the string at the brand level. That is the starting point for the onchain analysis, not an assumed conclusion. Whether that declared interest extends to the onchain context depends on the five criteria discussed later in this article. If your team first wants the two kinds of asset set side by side, the page comparing a dotBrand and an onchain TLD does that; this article deals only with the decision.
Option one: acquire the onchain TLD
Acquisition means your organization obtains the onchain TLD token by purchasing it from its holder. After the transfer, your organization alone can issue names under the TLD, because on Freename that power belongs to the holder and to nobody else. It may also receive the share of registration fees that the registry’s royalty program pays to holders, advertised at up to half and subject to the registry’s current terms and activation conditions. That income is not free of cost: taking part in the program carries an annual cost set by the registry, even though the TLD itself has no annual renewal fee. A dotbrand applicant buying the twin should ask the registry, before closing, whether it inherits the seller’s terms, since a number of TLDs were registered under earlier terms that include the program for life. And it can put the TLD to work for the functions that operate onchain: names that resolve in supporting wallets, payments to a name, identities under the TLD.
Acquisition is the right option when the five criteria point to material exposure or real utility. It is not the right option simply because the string matches your brand. Holding an onchain TLD you have no plan for adds a custody and governance obligation without adding value, unless the defensive position is itself the value you want, in which case say so in the record.
What acquisition requires in practice:
A willing counterparty. The holder must be willing to sell. There is no compulsory transfer mechanism for onchain TLDs equivalent to a UDRP proceeding. If the holder does not respond or asks for a price the organization will not pay, acquisition is not available at that moment. Monitoring then becomes the default, and the organization can revisit acquisition later. A service built for this situation, acquiring the onchain TLD that matches a brand, exists because the approach is a negotiation and not a filing.
A transfer process that protects both parties. An onchain transfer of a TLD token cannot be undone by a registrar or a help desk. For that reason a closing normally runs through onchain escrow on an aftermarket, so that neither side has to perform first on trust. The page on escrow and transfer covers that stage.
A plan for what comes next. Decide before closing which wallet will hold the token, who controls it, and whether any names will be issued. A multisignature wallet, one that needs several approvals before it acts, is the usual answer to the custody question for an organization. A post-transfer activation plan, however minimal, should be in place before closing. At minimum, the organization should decide whether to issue any names under the TLD or hold it as a defensive position.
Internal authorization. A TLD token is a digital asset. Depending on your jurisdiction and internal policies, acquisition may require sign-off from finance, treasury and legal counsel in addition to the brand or digital team. Your own counsel decides the classification and approval requirements; this article does not.
Option two: watch the onchain TLD
Watching means taking no immediate action while maintaining visibility over what happens to the onchain TLD. This is not the same as ignoring the matter. Structured monitoring produces an evidence record, triggers a review when conditions change, and keeps acquisition available if the situation develops.
Monitoring involves a short list of observations, repeated at a fixed interval. Is the TLD recorded on the registry, and in which wallet? Has that wallet changed? Have names been issued under it, and do any of them reproduce your product names or resemble a channel your customers would trust? Does a name under the TLD open in the wallets and browsers that support the registry? All of this can be read from public records, which is what makes watching a realistic option for a small team. A namespace watch is the service that monitors the names of a brand onchain when you would rather not do that reading yourselves.
None of these signals is automatically a concern. Each one feeds a criterion. A change of wallet bears on attention on the name. Names that look like payment or support channels bear on customer exposure. Wider support in wallets bears on both.
The evidence record matters for two reasons. First, if the organization later decides to acquire, it will enter the conversation knowing the history of the asset instead of learning it during the negotiation. Second, if activity under the onchain TLD ever reaches your customers or operations, a dated watch record shows that the organization identified the issue and responded proportionately.
Monitoring asks far less of the organization than acquisition does: no counterparty, no asset to hold, no approval from treasury. For many applicants, watching is a sound first step even when acquisition is the eventual destination, because it lets the organization understand the asset before committing to buy it.
Option three: leave it alone
Leaving the onchain TLD alone is a defensible choice when the five criteria come out low and the organization has no realistic plan to use the string onchain. It is not a failure of diligence. It is a proportionate allocation of attention.
The conditions under which leaving it is clearly the right answer are these: the people you deal with do not meet your brand in wallets, no payment use exists or is planned for the string, nothing is happening under the onchain TLD, and the internal team has no capacity to hold or govern a second TLD outside the DNS.
There is also an honest technical reason. Onchain names resolve outside the ICANN DNS root, which means an ordinary browser will not open them unless support has been added. For reaching the general public, the DNS is simply better, and your dotBrand is the asset built for that job. An organization whose audience lives entirely in ordinary browsers and email can reasonably conclude that the onchain twin has no route to that audience.
One practical constraint: leaving it alone should be a documented decision, not an oversight. The difference matters if the question is later revisited, or if activity under the onchain TLD begins to affect the brand. A one-paragraph record stating the criteria considered, the score on each, and the conclusion is sufficient.
The decision to leave it alone is also reversible. If the situation changes, for example because names that affect your customers appear under the onchain TLD, or because your organization launches a payments product where the string becomes relevant, you can return to the acquire or watch options. What the record should say plainly is the one thing this option does not secure: the holder’s willingness to sell at a later date. That is a cost of the option, and for a low-scoring organization it is usually an acceptable one.
Five criteria for scoring the options
These five criteria determine which option is proportionate for your organization. Score each on a three-point scale: low, medium or high.
| Criterion | What low looks like | What high looks like |
|---|---|---|
| Customer exposure | Customers never meet the brand in a wallet | Customers use wallets and would look up the brand string there |
| Payment use | No roadmap item involves wallet-based payments | A payment product under the brand string is planned or operating |
| AI agents | No agent is planned under the brand | Agents are being deployed and need an onchain identity under the brand |
| Attention on the name | Nothing issued, nothing changing | Names issued, wallet changes, wider support |
| Internal capacity | No team or budget for a second TLD | A digital assets team with budget and governance |
Customer exposure
Ask where your customers, suppliers and counterparties would encounter the string outside the DNS. If they hold wallets and pay or sign with them, a name under a TLD that matches your brand could appear in front of them. If they are procurement departments paying invoices by bank transfer, it could not. Score on evidence from sales and support, not on a general sense that the sector is moving.
Payment use
A payment to a name replaces a long wallet address with something a person can read and check. If any product on your roadmap would have counterparties pay to a name such as pay.yourbrand, the party able to issue that name is the holder of the TLD, and nobody else. This criterion is therefore close to binary: a real payment plan under the string scores high, and its absence scores low.
AI agents
Software agents that act for an organization need an identity other systems can check. Standards for agent identity onchain are still being drafted, and how naming registries fit into them is not settled. Score high only if your organization is deploying agents that will transact with outside parties under the brand. Curiosity about the subject is a low.
Attention on the name
This is the only criterion about the asset and not about you. It covers what the public record shows: names issued under the TLD, changes of wallet, and whether names under it open in the wallets and browsers that support the registry. On Freename, the places to test are few: its names are supported in Bitcoin.com Wallet, in MetaMask through Freename’s resolver, and in desktop browsers through the Freename Web3 extension. That support is incomplete and shifts over time, so score what you can observe on the day and note the date.
Internal capacity
An option your organization cannot carry out is not an option. Acquisition needs someone to hold keys, someone to approve the purchase of a digital asset, and someone to answer for the names issued. Watching needs an owner and a calendar. If nobody can be named for either, the score is low, and the record should say that capacity, not indifference, shaped the outcome.
Reading the scores together
The table below maps the pattern of scores to an option. It is a guide to proportion, not a formula.
| Pattern of scores | Option that fits | What the record needs |
|---|---|---|
| All or nearly all low | Leave it | Scores, reasoning, review date |
| Mix of low and medium | Watch | The above, plus what is observed and how often |
| Medium to high on three or more | Acquire | The above, plus budget, custody and approvals |
Two criteria carry more weight than the others. An organization that scores high on payment use or on AI agents intends to operate under the string onchain, and it cannot do that under a TLD it does not hold. For that organization the question stops being one of reputation and becomes one of operations, and a single high score there can justify moving up one option. The free Namespace Exposure Score on this site scores how exposed a brand is onchain and can serve as a pre-read for the people who will do the scoring.
A worked decision for a fictional applicant
This is a worked example with an invented organization. Consider a mid-sized manufacturer, called the applicant here, that has applied for its brand string as a dotBrand. The assumptions are these. The applicant sells physical goods. Its customers are procurement teams at other businesses, not individual consumers. It has no wallet-based payment product; a stablecoin pilot was discussed in the past and shelved. It deploys no externally facing AI agents. Its digital team has four people, responsible for the dotBrand program and all other digital infrastructure. The public registry record shows that the matching onchain TLD exists and that twelve names have been issued under it, none resembling the applicant’s products.
The applicant scores the five criteria:
Customer exposure: low. Its procurement customers do not use wallets to deal with the brand. No customer-facing onchain touchpoint exists or is planned.
Payment use: low. The applicant has a conventional payment stack, and nothing on the product roadmap uses the brand string as a payment address.
AI agents: low. The applicant uses AI tools internally only. No agent identity under the brand string is planned.
Attention on the name: medium. Twelve names issued is modest activity, but it is not zero, and the team could open one of them in a desktop browser with the registry’s extension installed.
Internal capacity: low. The four-person team is fully occupied with the application and the registry operator contract. Nobody is available to govern a second TLD.
The result is four low and one medium. The applicant concludes that it will leave the onchain TLD alone, with a documented rationale and a routine review twelve months after the meeting. It also defines three events that prompt an earlier review: the onchain TLD moves to another wallet, the number of names issued under it passes fifty, or the applicant launches any product that involves wallets.
The applicant documents this in a one-page internal record attached to its dotBrand program file. The matter is not closed. It is parked with a clear condition for reopening it.
Now change two assumptions and keep the rest. The applicant has signed an agreement with a payment processor to offer stablecoin settlement to its ten largest customers, with pay.yourbrand as the intended payment address, and its digital team has grown from four to five with an engineer dedicated to wallet infrastructure. Payment use moves from low to high, and internal capacity from low to medium. The scores are now two low, two medium and one high.
Read against the table, a mix of low and medium points to watching. The high score on payment use is the weighted criterion, so the applicant moves up one step in intent: it starts watching at once and gives itself six months to decide on acquisition, because the product it has just signed cannot use pay.yourbrand unless the applicant holds the TLD. If acquisition proves unavailable, the fallback is recorded too: the payment product launches under a different address.
The example shows that the framework is not mechanical. A single change on a weighted criterion altered the outcome, while the facts about the onchain TLD itself, the twelve names, did not change at all. That is why the criteria are assessed together and the record explains the reasoning, not just the scores.
Who decides and how to record it
The onchain TLD question sits where brand protection, digital assets and operational planning meet. No single function owns it, which is the usual reason it goes undecided.
In most organizations, the decision is made by the dotBrand program lead in consultation with general counsel and the head of digital or technology. Finance should be involved if the acquire option is on the table, because a TLD token is an asset that may need accounting treatment under your internal policies and the standards that apply to you. Your own counsel and finance team determine the correct classification; this article describes the process, not the accounting. The meeting itself can follow a fixed order.
- Assemble the right roomBring general counsel or brand protection counsel, the dotBrand program lead, and whoever owns the budget for digital assets or wallet infrastructure. If nobody owns that budget, the absence is itself evidence for the internal capacity criterion. Ninety minutes is enough.
- Read the public record firstBefore the meeting, look up the onchain TLD that matches your string. Anyone can inspect the registry's record on a block explorer. Note whether names have been issued under it and whether it has moved between wallets.
- Score each criterionWork through the five criteria in order: customer exposure, payment use, AI agents, attention on the name, internal capacity. Assign low, medium or high to each and write down the reason. Disagreement on a score is useful information; note it.
- Select the optionMap the pattern of scores to leave, watch or acquire. If the result sits between watch and acquire, choose watch with a defined trigger for escalation. Do not choose acquire because it feels more decisive.
- Define the review triggerState at least one specific event that reopens the decision: a change of wallet for the onchain TLD, a product launch that affects the payment use criterion, or a defined increase in the names issued under it. Set a calendar date for a routine review whether or not a trigger fires.
- Document and circulateProduce a one-page decision record with the participants, the scores and reasons, the option chosen, the trigger and the review date. Attach it to the dotBrand program file and route it to general counsel for sign-off.
The decision record should be brief. It does not need to anticipate every future development. It needs to be honest about what was known when the meeting was held and clear about the reasoning. A decision that turns out to be wrong is far more defensible when a reasoned record exists than when none does. The audience page for brands and legal teams is written for the counsel who will sign that record.
Revisiting the decision later
The decision is not permanent, and it should not be treated as one. Support for onchain names in wallets and browsers is uneven and it moves, so the practical reach of a TLD with no activity under it can differ from one review to the next.
Two types of event should reopen the decision. The first is an external change: the onchain TLD moves to another wallet, which may mean a new holder with different intentions; the number of names issued under it grows substantially; or a wallet or browser your customers use adds support for the registry, so that names under your string open in more places than they did.
The second type is an internal change: your organization launches a payment product, an agent project, or a customer-facing application that makes the onchain string operationally relevant. The worked example showed how one product decision moved two scores and changed the option.
For organizations that chose to watch, the monitoring itself produces the signal that feeds these reviews. For organizations that chose to leave it alone, the routine review date in the decision record is the mechanism. Set it and keep it. A review that finds nothing changed takes a few minutes and adds one dated line to the record, which is exactly what a later reader will want to see.
If a later review moves the decision to acquire, your organization does not have to make the approach itself. Under a buy-side acquisition mandate, the desk is instructed to find the holder and approach them on your behalf.
The next step your organization can take
The practical next step is to schedule the meeting and run the five-criterion scoring. Nothing in the framework depends on the stage your application has reached, and the record it produces is in place whenever the situation changes.
Start with the public registry record and the exposure score, then score the criteria with the three or four people named above. If the outcome is to watch or to acquire and you want that work handled by Hush Partners, reach the desk through the contact form, which is the only way in. One named partner follows a file from the first note to closing, and a standard mutual NDA applies to every exchange. The desk charges a fixed fee, never a percentage, and only to the client who gives it a mandate.
If the outcome is to leave the onchain TLD alone, document that conclusion, set a review date, and return to your application. That is a complete and defensible response.
Questions people ask
Does the ICANN application give us any rights over the onchain TLD?
No. The application is a request for delegation of the string within the DNS root. It has no effect on onchain registries, which operate outside the DNS. A holder of the onchain TLD has no obligation to transfer it or stop using it because of your application. Your trademark rights are a separate matter, and how far they reach onchain depends on the law that applies to you; your counsel advises on this specifically.
If we acquire the onchain TLD, do we need to operate it actively?
Not necessarily. The most minimal posture after acquisition is to hold the TLD and issue nothing. Because only the holder can issue names under a Freename TLD, holding it is enough to ensure that no one else does. That is a legitimate defensive position, though it produces no return. The absence of an annual renewal fee on a Freename TLD means the position does not lapse for want of a payment, but the wallet that holds it still needs an owner inside your organization.
Can the holder of the onchain TLD assert rights against us once we are delegated in the DNS?
This is an unsettled area. The onchain record is public and carries a date of creation. Whether that record supports any legal claim against the operator of a DNS TLD depends on the applicable law, the facts, and the use each party makes of the string. This article describes the landscape; your counsel advises on the risk specific to your organization and country.
What if the same string exists on more than one onchain registry?
Each onchain registry is a separate system with its own record, and each would need to be assessed separately. In practice, the material question is where a name under the string would actually open in a wallet or browser that your customers or counterparties use. Support differs from one registry to another and changes over time. Score the attention criterion registry by registry, and let the highest score stand for the criterion as a whole.
Is first registration on an onchain registry legally significant?
It can be one factor in how a collision is handled technically. In the method described in Freename’s patent, the earliest date of creation is one weighted criterion among several in the score that decides which of two colliding names resolves. That is a technical mechanism. It is not a legal determination of ownership, and it binds neither courts nor ICANN. Whether early registration onchain creates any enforceable legal position is a question for your counsel, not a conclusion this article draws.
