# When leaving an onchain TLD alone is the right decision
> Not every name deserves action. The conditions under which doing nothing is a defensible, documented choice.
Source: https://hush.partners/when-to-leave-an-onchain-tld-alone
Category: Brand protection
Published by Hush Partners.
---
Your brand protection team flags a finding: `.yourbrand` exists as an onchain TLD, a top-level domain recorded as a token on a public blockchain, outside the ICANN DNS root. The question lands on your desk. Should the organization acquire it, challenge it, or ignore it?
The instinct in most legal teams is to act. Acquisition feels prudent. Inaction feels like negligence. But this instinct is wrong often enough to warrant a serious examination of the alternative. Doing nothing is a legitimate choice, and in many cases it is the right one, provided it is made deliberately, recorded properly, and reopened when the facts change.
This article sets out the conditions that make inaction reasonable, the conditions that rule it out, how to document the decision so it survives a challenge, and which events should reopen the file. It is not an argument for passivity. It is an argument for precision.
## Why the reflex to acquire everything fails
The case for acquiring every onchain TLD that resembles a brand looks obvious until you examine it. The argument runs: the name exists, it could be misused, acquisition eliminates that possibility, therefore acquire it. Each step is plausible. The conclusion is still wrong.
The first problem is scope. Onchain TLDs can be created on more than one registry, and a Freename TLD carries no yearly renewal charge, so nothing pushes a holder to drop a name that is not in use. The universe of possible lookalikes (abbreviations, sector words, phonetic variants, regional spellings) is large. No organization can acquire all of them, and a policy that implies it will either exhaust the budget or collapse under its own inconsistency.
The second problem is that acquisition creates costs that are not always visible at the point of decision. A TLD that a brand organization holds must be governed. Someone must decide whether to issue names under it, and on what terms. Someone must answer questions about what `pay.yourbrand` or `id.yourbrand` means and whether the organization stands behind it. Holding a TLD without activating it is not neutral: it is a position that needs to be maintained, explained, and periodically justified. The [Namespace Exposure Score](/namespace-exposure-score) can help calibrate how exposed a brand actually is before a team reaches that point.
The third problem is that acquiring a distant or harmless TLD can signal to other holders that the brand is a willing buyer. A disciplined policy of non-acquisition for genuinely low-risk names preserves negotiating position on the names that matter.
### Answering the colleague who wants everything bought
The pressure to act rarely comes as an argument. It comes as a question asked in a meeting: "Why have we not dealt with this?" The question assumes that an unowned match is an open problem, and that the only way to close a problem is to buy it.
The useful reply is not "it does not matter". It is a short statement of what was checked, what was found, and what would change the answer. A colleague who hears that the TLD has no names under it, that your customers have no way to reach it, and that the file reopens the day either of those facts changes is hearing a decision. That is a different thing from hearing a shrug, and most of the pressure comes from not being able to tell the two apart.
## The conditions that make inaction reasonable
No single factor decides the question. The analysis is a combination of several conditions. When most of them point toward low risk, inaction is defensible.
**No plausible customer path.** Onchain names do not open in an ordinary browser without support. A user needs a wallet that resolves them, a browser extension, or specific configuration to reach anything published under an onchain TLD. That [coverage is partial and changes over time](/whats-live). If your customers are ordinary consumers who use a standard browser and have no exposure to onchain infrastructure, the probability that a name under `.yourbrand` leads a customer anywhere is low. That does not make the risk zero, but it reduces it substantially.
**No evidence of active use.** The registry record of an onchain TLD is public, and anyone can check it on a block explorer, a website that displays what is recorded on a blockchain. You can see whether names have been issued under the TLD. If the TLD is held but no names exist under it, and no payments or website content are configured, the token is inert. An inert token presents a different risk profile from an active one.
**No payment or commerce function.** One concrete use of an onchain name is as a readable alias for a wallet address, so that a sender can pay `pay.yourbrand` rather than a long string of characters. If nothing shows that the TLD or any name under it has been set up to receive payments, the financial-harm pathway is not open.
**The variant is genuinely distant.** A TLD that shares a word with a brand but takes several steps of interpretation to arrive at the brand is not the same risk as an exact match. A sector word that happens to overlap with one element of a brand name, with no names issued, is a different matter from the brand name itself held by an unknown party with payment routing active.
**The audience does not overlap.** If the brand operates in a market with essentially no intersection with onchain infrastructure (regulated financial products sold to institutional buyers through relationship channels, for example), the potential for customer confusion from an onchain name is structurally limited.
Each of these is an observation about the present state of things, not a forecast. That is their strength and their limit. You are not asked to predict what a holder will do. You are asked to record what is true on the day you looked, and to arrange to be told when it stops being true. A decision built on observations can be checked by someone else. A decision built on a guess about intentions cannot.
## The conditions that rule inaction out
The table below sets the conditions side by side. Where a finding lands predominantly in the right column, inaction becomes difficult to justify.
| Factor | Inaction is supportable | Inaction is hard to support |
|---|---|---|
| Customer exposure | Customers do not use onchain infrastructure | Customers hold wallets or pay through onchain channels |
| TLD match | Abbreviated, variant, or sector word | Exact brand name or well-known product name |
| Names issued | None issued under the TLD | One or more names issued, especially payment names |
| Configuration | No payment routing, no content | Payment alias or website content live under a name |
| Holder conduct | No contact with the brand, no offer to sell | Holder has contacted the brand or offers the TLD for sale |
| Brand strength | Descriptive or sector term | Inherently distinctive mark, registered where it trades |
The most important single factor is whether names are being issued and used. A held-but-dormant TLD is a watch item. A TLD under which `pay.yourbrand` routes payments to an unknown wallet is not, because [payments to a name](/onchain-tld-payments) work now, and they are the capability that connects most directly to harm for a customer who believes the brand is on the other end.
Holder conduct deserves a word of its own. A holder who writes to the brand, or who puts the TLD up for sale, has not necessarily done anything wrong. Many holders registered a word in good faith and are simply open to a conversation. But contact changes the file in a practical way: the organization now knows that a transaction is possible, and a decision to ignore the approach is a decision someone should make and record, not a message left unanswered.
The right column does not always mean buying. Ruling out inaction means the finding needs a response, and the response can be an enquiry, a conversation between counsel, closer monitoring, or an acquisition. Where acquisition is the answer, [brand namespace recovery](/brand-namespace-recovery) is the service built for a TLD that matches the brand. The point of the table is to separate the findings that need a response from those that need a record, not to push every flagged name toward a purchase.
## Documenting the decision
A decision not to act is as important to record as a decision to act. If the question is ever reopened by a colleague, a regulator, an insurer, or a board, the organization needs to show that it analyzed the situation, applied a standard, and reached a reasoned conclusion. "We did not get around to it" is not the same as "we assessed it and decided not to."
How to document a decision not to act
Record the findingNote the TLD identified, the date of the finding, the source (monitoring alert, ad hoc search, inbound note), and who raised it.
Capture the state of the TLDCheck the public registry record on a block explorer. Note whether names have been issued and whether any name is set up for payments or website content. Attach a dated screenshot or export.
Apply the assessment criteriaWork through each factor in the conditions table: customer exposure, exact match or variant, names issued, configuration, holder conduct, and brand strength. Write one sentence on each. It does not need to be long; it needs to be honest.
State the conclusion and the reasonRecord that the decision is to take no action for now, and which factors drove it. Name the person responsible for the decision and their role.
Set the review date and tripwiresRecord when the decision will be revisited whatever happens, and the specific events that would reopen the file at once.
File it somewhere findableA successor or an auditor should be able to locate the record without asking the person who made the decision. A matter management system, a shared IP register, or a dated memorandum in a named file all work. An email thread does not.
The standard to aim for is this: a competent colleague, reading the record long after the people involved have moved on, can understand exactly what was known, what was decided, and why.
## The events that reopen the file
Inaction is a position, not a permanent disposition. Certain events change the risk analysis and require the file to be picked up again, whenever the next review was scheduled.
The tripwires fall into two groups. The first is holder activity: the holder takes a step that moves the TLD from dormant to live. The second is brand-side change: the organization itself changes in a way that makes the onchain space newly relevant. Both matter. A TLD that was low-risk while `.yoursector` had no active names and the brand's customers never touched a wallet can become a material concern if the brand launches a wallet product and starts directing customers to onchain payment channels.
Brand-side tripwires are the ones most often missed, because they are triggered by another department. The legal team hears about the holder's activity from its monitoring, but it may hear about a new payment option from a press release. It helps to tell the product and marketing teams that an onchain launch is a legal trigger, in the same way a new market entry triggers a trademark clearance.
A third group is market change. Support for resolving onchain names continues to develop. If a widely used browser or operating system were to resolve them natively, the customer path assumption behind many inaction decisions would need to be reassessed across the whole portfolio, not one file at a time.
## Inaction with monitoring against inaction without
There is a real difference between a decision not to acquire a TLD and a decision not to watch it. The first is a choice about where to spend resources. The second leaves the organization without information.
An organization that decides not to acquire `.yourbrand` but keeps a watch on it retains the option to respond quickly if circumstances change. An organization that neither acquires nor watches is making a different and weaker claim: that nothing that happens next could matter. That is a harder position to hold if something does happen next.
[Namespace monitoring](/namespace-watch) is not acquisition. It does not require the organization to hold a position or govern a TLD. It produces information (names issued, configuration changes, holder activity) that either confirms the original decision or fires a tripwire. It asks far less of the organization than holding a TLD does.
This distinction matters most if the decision is examined later. Asked why it did not act on a known onchain TLD, an organization that can say "we watched it, and the conditions that would have required action were never met" gives a stronger answer than one that can only say "we noted the finding and moved on." Both are inaction. The first is much easier to explain.
Inaction without monitoring is not always wrong. For a distant variant of a descriptive term, with no names issued and no customer path, a dated record and a scheduled review may be all the file deserves. The honest test is whether the tripwires you wrote down could fire without your noticing. If they could, and the match is close, the decision rests on a hope that someone will tell you.
## The cost of being wrong, in both directions
Decisions carry error costs. The decision not to act on an onchain TLD can be wrong in two directions, and both deserve honest assessment.
**The cost of wrongly doing nothing** is that a TLD that looked dormant becomes active and harmful. The most acute version is a payment name that diverts funds from customers who believe they are paying the brand. In the ICANN DNS, a registrar can be contacted and a UDRP proceeding can sometimes be brought, because registrants accept that procedure when they register a domain. The UDRP does not reach onchain TLDs. What remains depends on the registry's own terms and on the courts, and it varies by country, which is a matter for your own counsel. The TLD can be acquired if the holder will sell it, but the negotiation happens on the holder's terms and the brand does not control the timeline. In the worst case, the cost includes both the harm to customers and the price of acquiring under pressure what could have been acquired calmly earlier.
One habit from the DNS does not carry over. With an ordinary domain, a team can sometimes wait for an unused name to lapse when its registrant stops renewing it. A Freename TLD has no renewal to miss, so waiting for the name to fall free is not a plan. If the organization wants the TLD one day, that day involves a conversation with whoever holds it.
**The cost of wrongly doing something** is real and underweighted in most legal team discussions. Acquiring a TLD that presented no genuine risk consumes budget. It creates governance obligations, because someone must decide what to do with `.yourbrand` once the organization holds it. It can set a precedent that the organization acquires everything that matches, which makes it harder to justify not acquiring the next one. And if the acquisition becomes known, it may attract attention from holders of other variants who had not considered their TLDs relevant to the brand.
The two errors are not symmetrical in kind. Wrongly doing nothing is rare but can be severe, and it is felt by customers. Wrongly doing something is common and mild each time, and it is felt in budget and attention, which are then missing for the finding that deserved them. A team that only counts the first kind of error will buy too much. A team that only counts the second will miss the one file that mattered.
A calibrated policy names both costs explicitly. That is what the conditions table is for. The goal is neither to eliminate action nor to mandate it, but to apply the same standard every time so that decisions are consistent and explainable.
## How to review the decision
The decision should be revisited on a fixed schedule whether or not a tripwire fires. The review does not repeat the full analysis from scratch. It checks whether any of the inputs have changed.
The review checklist is short:
- Has the holder issued any names under the TLD since the last review?
- Has any name been configured for payment routing or website content?
- Has the brand launched any product or service that brings customers into onchain infrastructure?
- Has resolution support for onchain TLDs expanded materially in the period?
- Has the holder made any contact with the brand, or offered the TLD for sale?
If the answer to every question is no, the decision stands and the record is updated with the review date and the reviewer. If the answer to any question is yes, the relevant part of the analysis is reopened.
The interval between scheduled reviews is a judgment call. An exact-match TLD held dormant deserves a shorter interval than a distant variant with no names issued. State the interval in the original record, and do not let it run longer than the organization's standard IP review cycle.
Two things keep a review honest. The first is a named reviewer who is not relying on memory: the review reads the record, checks the registry again, and compares the two. The second is permission to change the answer in either direction. A review that finds names issued under the TLD should reopen the file without anyone treating the earlier decision as a mistake. It was right on the facts it had. Equally, a review of a TLD that the organization has watched closely for a long time with nothing happening may conclude that lighter attention is enough. A record that only ever escalates will teach colleagues to stop writing things down.
## Your next step after the assessment
If the analysis produces a clear answer, the next step follows directly. If inaction is the decision, document it as described and set the tripwires. If the finding needs a response, the file opens differently depending on what the organization wants: the TLD itself, a first conversation with its holder, or simply a clearer picture of its onchain exposure before deciding.
For a team that has not yet mapped how far its brand extends onchain, the exposure score mentioned earlier is a structured place to start, and the page for [brands and legal teams](/brands-and-legal-teams) gathers what is relevant to general counsel and brand protection. For an organization that has concluded that acquisition is right, Hush Partners can be mandated to [find and approach the holder](/buy-side-acquisition) on its behalf. Every exchange with the desk takes place under a [standard mutual NDA](/nda), and the desk is reached through the contact form on the site.
Nothing on this site will tell you the decision is obvious. For most onchain TLD findings, it is not. What the analysis should give you is the structure to make the decision once, record it properly, and revisit it when the facts warrant, without relitigating it every time someone raises the question in a meeting.
## Questions people ask
### Does a registered trademark mean the brand automatically wins a dispute over an onchain TLD?
No. The UDRP applies within the ICANN DNS. Onchain TLDs sit outside the ICANN root and are not subject to that procedure. A trademark registration is relevant context for any negotiation or legal action, but it does not provide an automatic procedural remedy. The options depend on the registry, the country, and the conduct of the holder. Your own counsel decides what is available in a given situation.
### Can the organization acquire the TLD later if circumstances change?
Later acquisition is possible but not guaranteed. If the holder activates the TLD, the negotiating position changes. If the holder becomes aware of the brand's interest, the price may reflect it. Whether a later acquisition is reasonable depends heavily on what the holder has built on the TLD in the meantime. This is the argument for keeping a watch even when the decision not to act is correct.
### What if the organization has no internal process for reviewing these decisions?
Start with the documentation steps in this article. A dated memo, a named decision-maker, a stated set of tripwires, and a fixed review date make a minimal but real process. It is far better than no record, and it can be folded into an existing trademark watch routine instead of standing alone.
### Does it matter that the TLD matches a registered mark exactly?
It places the finding in the exact-match row of the table, and it does not settle the question. A [trademark TLD](/trademark-tlds) is an onchain TLD that corresponds to a registered mark. The same conditions apply to it: whether names are issued, whether anything is configured, whether your customers could reach it. What the exact match changes is the margin for error, because the distance between dormant and harmful is one configuration step. That argues for a shorter review interval and active monitoring, not automatically for a purchase. The free Trademark Name Check on that page is a quick way to see where a mark stands.