# Does the UDRP apply to onchain TLDs?
> Why the UDRP does not reach an onchain TLD, what a trademark owner can still rely on, and how the realistic options compare.
Source: https://hush.partners/does-udrp-apply-to-onchain-tlds
Category: Brand protection
Published by Hush Partners.
---
A trademark lawyer reviewing brand exposure across the internet will, sooner or later, find that the brand's name exists as an onchain top-level domain: a TLD recorded on a blockchain and held in a private wallet, not delegated through ICANN. The first instinct is to open a UDRP proceeding. That instinct runs into a structural wall.
The UDRP is a contractual mechanism. It binds the parties it reaches through a chain of agreements. An onchain TLD sits outside that chain, not because the policy is ambiguous, but because the chain itself does not extend to a blockchain registry. Understanding exactly where and why it stops determines which options remain, and those options call for different skills, timelines and expectations.
This article works through the architecture of the UDRP, identifies the precise points at which an onchain TLD falls outside it, runs the same analysis briefly for the URS and the Trademark Clearinghouse, and then maps the routes that do remain: court action, the policies of registries and platforms, negotiated acquisition, and monitoring. After reading, you can explain to a client or an in-house team why the usual administrative route is not available and how to weigh the others.
## How the UDRP works and what makes it binding
The Uniform Domain-Name Dispute-Resolution Policy (UDRP) is the procedure ICANN adopted for disputes over the registration of domain names that conflict with trademarks. A trademark owner files a complaint with an approved dispute resolution provider, a panel decides on written submissions, and the remedy is the transfer or cancellation of the name. Its reach is defined entirely by contract, and that contract runs through three tiers.
At the top, ICANN signs registry agreements with the operators of generic top-level domains. Those registry operators must have names under their TLD registered through registrars that ICANN has accredited. Every accredited registrar, as a condition of its accreditation agreement with ICANN, undertakes to follow the UDRP for the names it registers.
The obligation then flows down to the registrant. The accreditation agreement requires each registrar to write certain provisions into the registration agreement it concludes with every customer. One of them is acceptance of the UDRP. A person who registers a name through an accredited registrar has therefore agreed, by contract, to submit to the procedure if a trademark owner brings a complaint, for as long as the registration lasts.
When a complainant prevails, the registrar is the party that carries out the decision: it transfers or cancels the name in its own systems. The losing registrant does not need to cooperate. That is the feature that makes the UDRP work in practice. The decision is executed by an intermediary that is bound by contract to execute it and that has technical control over the registration.
Each of the three tiers matters. Remove any one of them and the procedure has nothing to hold on to. That is exactly what happens with an onchain TLD.
## Where the contract chain breaks for an onchain TLD
An onchain TLD is recorded on a blockchain as a token held in a wallet. That is how it works on the Freename registry, for example. The holder controls the token through the wallet's private key, and only the holder of a TLD can issue names under it. The record does not sit in a database that an ICANN-accredited registrar administers.
That architecture produces three specific gaps in the contract chain.
### No accredited registrar
An onchain TLD is not registered through an ICANN-accredited registrar. The record is created by a smart contract, which is a program that runs on a blockchain and executes the same way for everyone. The registry that operates it has signed no accreditation agreement with ICANN in respect of these names. The intermediary that the UDRP relies on is absent.
### No registration agreement incorporating the policy
In the DNS, the registrant's consent to the UDRP comes from the registration agreement. A person who acquires an onchain TLD accepts the terms of the onchain registry, whatever they provide, and those terms are not required by anyone to incorporate the UDRP. The holder has not agreed to submit to the procedure. A panel's authority over a registrant rests on that agreement, and here there is none.
### No party obliged to implement a decision
Suppose a decision existed all the same. In the DNS, a registrar that fails to implement a UDRP decision answers to ICANN under its accreditation. No comparable obligation rests on an onchain registry, and ICANN has no contract through which to require anything of it. The token stays in the holder's wallet unless the holder moves it, or unless the registry's own terms and its own technical design allow it to act, which is a separate matter discussed below.
The conclusion, as things stand, is that the UDRP does not apply to an onchain TLD. This is not an open question waiting for a panel to settle it. It is a matter of who has signed what. The statement is also limited to the present: if the contracts changed, the analysis would change with them.
One further point is easy to miss. The UDRP was written for names registered under a TLD, the level at which registrants and registrars meet. Here the disputed object is the TLD itself. Even inside the ICANN system, a conflict over a top-level string is handled through the application process for new TLDs and its own objection procedures, not through the UDRP. So the lawyer looking at `.yourbrand` held onchain faces two mismatches at once: the wrong contractual system and the wrong level of the hierarchy. Names issued under that TLD, such as `pay.yourbrand`, are at the familiar level, but they sit in the same registry and outside the same contracts.
## The URS and the Trademark Clearinghouse: same analysis, same result
Two related ICANN mechanisms deserve brief treatment, because a client briefing will ask about them.
The Uniform Rapid Suspension system (URS) is a faster and narrower administrative procedure created for the new generic TLDs. It is intended for clear-cut cases and its remedy is the suspension of the name, not its transfer. Like the UDRP, it binds through the agreements ICANN signs with registry operators and through the registration agreements below them. An onchain TLD has no registry agreement with ICANN, so the URS does not reach it.
The Trademark Clearinghouse is a database of verified trademark records that ICANN set up to support the launch of new generic TLDs. It feeds two services: a sunrise period, in which mark owners can register matching names before the public, and a claims service, which notifies applicants and mark owners when a registration matches a recorded mark. It works at the level of names under a TLD, and only registry operators under contract with ICANN are required to use it. An onchain registry has no such obligation. A record in the Clearinghouse remains useful evidence of your rights, but it gives no procedural hold over an onchain TLD or the names under it.
| Mechanism | What it rests on in the DNS | Remedy in the DNS | For an onchain TLD |
| --- | --- | --- | --- |
| UDRP | Accreditation and registration agreements | Transfer or cancellation | Not available |
| URS | Registry agreements for new generic TLDs | Suspension | Not available |
| Trademark Clearinghouse | Registry launch obligations | Sunrise and claims notices | No obligation to use it |
| Registry's own policy | The registry's terms | As the terms provide | Depends on the registry |
| Court action | Trademark law | Injunction, damages, transfer order | Available, harder to enforce |
The first three rows share a cause: each mechanism draws its force from contracts with ICANN. The last two rows do not depend on ICANN at all, and they are where the rest of the analysis takes place.
## What trademark law itself can still do
Trademark law does not come from ICANN contracts. A registered mark gives its owner rights that courts enforce against infringing use, whether the use occurs in the DNS, on a blockchain or anywhere else. Nothing in the architecture described above removes those rights. What changes is the practical path from a right to a result. Four steps each become harder.
### The cause of action
The UDRP asks a narrow question about registration and use in bad faith. A court asks the questions of the applicable trademark law, which in most systems turn on use in the course of trade and on a likelihood of confusion or harm to a mark with a reputation. Holding a token is not the same thing as using a sign in commerce. A TLD that sits unused in a wallet presents a weaker set of facts than one under which names are issued, sold or used to receive payments in a way that suggests a link with your client. The tests and their thresholds vary by country, and some countries have specific rules on bad faith registration of domain names whose application to a token outside the DNS is not something this article can predict.
### Jurisdiction
A blockchain has no location. The registry is a company established somewhere, the holder lives somewhere else or nowhere you can tell, and the names may be reachable by users in many countries. You need a court that will accept jurisdiction over the defendant or over the harm, and whose decision can be recognized where it has to take effect. In the DNS, the UDRP avoids all of this by contract. Here, ordinary private international law applies, with its usual costs.
### Identifying the defendant
The registry record is public and anyone can check it on a block explorer, a website that displays the contents of a blockchain. The record shows the wallet address that holds the token. It does not show a name, a company or a country. An address is a pseudonym. Linking it to a legal person may be possible through information the holder has published, through the registry or a platform if a court orders disclosure, or through other investigation. It may also fail. Procedures against unidentified defendants exist in some jurisdictions and not in others.
### Enforcing a judgment against a token in a wallet
This is the hardest step. A court can order a defendant to transfer a token. If the defendant complies, the transfer is recorded onchain and the matter ends. If the defendant does not comply, there is no registrar to carry out the order in the defendant's place. A token in a wallet that the holder alone controls moves only with the holder's key. The court's ordinary tools still exist (penalties for non-compliance, enforcement against other assets, orders addressed to intermediaries within its reach), but none of them moves the token directly. Whether the registry could or would act on a court order depends on its terms, its technical design and where it is established.
Court action is a real route, and in a case of active, harmful use it may be the necessary one. It is slower and more expensive than the administrative procedure it replaces, it is public, and its result is less predictable.
## Non-judicial levers: registry policies, marketplaces, wallets and resolvers
Between doing nothing and going to court, there are the policies of the organizations that make an onchain name usable. They are worth understanding for what they can do and, just as much, for what they cannot.
### The registry's own policies
An onchain registry operates under its own terms. Those terms may contain rules on intellectual property and acceptable use, and a procedure for complaints. Whether they do, what they allow the registry to do, and whether the registry's technical design lets it do anything to a token already in a holder's wallet differ from one registry to another and change over time. Read the current terms when a specific matter arises, and do not assume they resemble the UDRP. The essential difference is this: under the UDRP you have a defined procedure, a neutral panel and a remedy that follows from the decision. Under a registry policy you have a request addressed to a private operator, decided at its discretion and under its terms.
### Marketplaces
Onchain TLDs can change hands on marketplaces for tokens, and those marketplaces have terms of their own, usually with a channel for intellectual property notices. A notice that succeeds affects what that marketplace displays or allows on its own platform. It does not move the token, and it does not stop the holder from transferring it elsewhere. It is a narrow lever with a narrow effect, and it is public to the extent that the holder is told of it.
### Wallets and browser extensions
An onchain name is useful where software resolves it, which means translating the name into a wallet address or a website. Because that translation happens outside the ICANN DNS root, an ordinary browser needs added support before it opens an onchain name. For Freename names, the software that provides it is Bitcoin.com Wallet, MetaMask by way of Freename's resolver, and desktop browsers by way of the Freename Web3 extension. Coverage is partial and changes.
Each of those software providers has terms and, in some cases, a way to report misleading or harmful content. A provider can decide what its own software resolves or displays. It cannot change the registry record, and a decision by one provider does not bind the others. For a brand owner, the more useful point is diagnostic: where a name resolves tells you how visible it is to real users, and that is a measure of actual exposure.
### What these levers add up to
None of them is an adjudication. Each is a request under someone else's terms, with an outcome limited to that organization's own service. They are appropriate where there is concrete, harmful use to report, such as content that misleads users about its source. They are not a substitute for a remedy over the TLD itself, and using them as a negotiating device, where no real infringement is being reported, is neither their purpose nor good practice.
## Negotiated acquisition: when it is the rational choice
Where the administrative route is closed and the judicial route is long, buying the TLD from its holder is often the proportionate answer. It is a commercial decision, not a concession on the legal position, and it should be assessed as one.
Acquisition tends to be rational in four situations. First, the TLD is unused or lightly used, so the facts for an infringement claim are thin. Second, the foreseeable cost and duration of court action exceed what the organization would reasonably pay to hold the name. Third, discretion matters, because a public dispute would draw attention to a name that few people have noticed. Fourth, the organization has a use for the namespace itself: names for payments, for wallets or for the identities of software agents, as defined in the [glossary](/glossary). In the fourth case the organization is not only removing a risk. It is acquiring an asset it intends to operate, which changes how the price should be judged.
Acquisition is less suitable where the holder cannot be reached, where the price asked bears no relation to any reasonable value, or where active misuse calls for an immediate judicial response. It can also run in parallel with preparation for court action, provided counsel coordinates the two.
What it requires is straightforward to list and less straightforward to do. Someone must find a way to reach a holder who is known only as a wallet address. The approach must be made without revealing more than the organization intends at that stage, since the identity of the interested party affects the conversation. A price and terms must be agreed. The transfer must then be completed in a way that protects both sides. Because the token moves only when the holder moves it, no route to acquisition bypasses the holder's agreement.
This is the work that [brand namespace recovery](/brand-namespace-recovery) at Hush Partners covers: an organization mandates the desk to find and approach the holder, every exchange is covered by a standard mutual NDA, one named partner follows the file from first note to closing, and closing runs through onchain escrow on an aftermarket. The desk charges a fixed fee to the client who mandates it, never a percentage.
## Monitoring as a route when no action is justified yet
Not every appearance of a brand name onchain calls for action. The TLD may be held and unused. The term may be a common word that others have a legitimate interest in. The organization may not yet have decided what it wants from onchain names. In those cases, the reasoned decision is to watch and to record.
Monitoring means following two levels: the TLD that matches the mark, and the names issued under it or under other TLDs that contain the mark. It means noting changes: names being issued, names starting to resolve in wallets, content being published, a transfer of the token to another wallet. And it means keeping a dated record of each observation, because the facts that matter to a court or a counterparty are facts about use over time.
The value of monitoring is that it turns a vague concern into criteria. You can decide in advance which change would move the file from watching to acting: for instance, the first name under the TLD that imitates one of your client's services, or the first use in payments. That decision is easier to defend internally than either inaction without a reason or action without a trigger.
Two resources on this site relate to it. For the watching described here, the desk offers [Namespace Watch](/namespace-watch), its service for monitoring the names of a brand onchain. The [Namespace Exposure Score](/namespace-exposure-score) is a free tool that scores how exposed a brand is onchain, which helps to set priorities before any budget is committed.
## How the routes compare
The table compares the routes on speed and cost, certainty and publicity. Cost is described in relative terms only, since it varies with the jurisdiction, the complexity of the facts and the counterparty. Certainty means how predictable the outcome is for an owner with a strong mark.
| Route | Speed and cost | Certainty | Publicity |
| --- | --- | --- | --- |
| UDRP or URS (DNS only) | Fast, low to moderate cost | High within their scope | Decisions are published |
| Court action | Slow, high cost | Depends on facts, forum and enforcement | Public |
| Registry complaint | Variable speed, low cost | Low, depends on the terms | Usually private |
| Platform notice | Often fast, low cost | Limited to that platform | Known to the holder |
| Negotiated acquisition | Depends on the holder, moderate cost plus price | High once the holder agrees | Private |
| Monitoring | Continuous, low cost | Does not resolve anything | Private |
The first row is there for reference only. The UDRP and the URS remain the standard instruments in the DNS, and this is one of the areas where the DNS is simply better equipped: it offers a rights holder a predictable, inexpensive procedure that the onchain world does not have.
For an onchain TLD, the choice in practice is between court action and negotiated acquisition, with monitoring as the position to hold while neither is justified. Registry complaints and platform notices address specific harmful uses and rarely settle the question of who holds the TLD. The routes are not exclusive. A common sequence is to monitor, then to approach the holder, and to keep court action in reserve for the case where use becomes harmful and agreement proves impossible.
## What to document now, whatever route you choose
Each route draws on the same file of evidence. Assembling it is inexpensive, and it is worth doing when the TLD is first identified, because a record made at the time carries more weight than one reconstructed later.
What to put in the file
Registry recordSave the onchain record from a block explorer: the registry, the token, the wallet address that holds it and the date it was created. The record is public and anyone can check it.
State of useRecord whether names are issued under the TLD, whether any of them resolve to a wallet or to content, and in which wallets or browsers. Keep dated captures.
Your rightsList the marks concerned, with their registration details, territories, classes and dates of first use. Check that ownership records are up to date.
Commercial contextNote any offer to sell the TLD or names under it, any use in payments, and any content that refers to the brand. Record facts, not interpretations.
Decisions and contactsKeep a log of who decided what, on which date, and of any contact with the holder, the registry or a platform. Apply privilege rules as your jurisdiction provides.
Two cautions belong with this list. Do not contact the holder informally before the file exists and the strategy is agreed, since a first message cannot be withdrawn and it reveals who is interested. And check your own position before forming a view of the holder's: the free Trademark Name Check on the [trademark TLDs](/trademark-tlds) page is one way to see how a name stands as a trademark TLD.
## A practical next step for counsel
Start with one decision: does the present state of use call for action, or for monitoring with defined triggers? If the TLD is unused and no names are issued under it, monitoring is proportionate. If names are issued in a way that trades on the mark, or the TLD is used to receive payments under your client's name, the file should move.
If it moves, put the two main routes side by side for the client in the terms of the comparison above, with your own estimate of cost and time for the jurisdictions involved. Where acquisition is preferred, decide who makes the approach and under which confidentiality terms before anything is sent.
Three pages on this site correspond to three situations. If you advise a brand and want to see how a mandate to find and approach a holder is structured, read the page for [brands and legal teams](/brands-and-legal-teams). If you are outside counsel and would refer such a file, the page for [lawyers and advisers](/for-advisors) is written for you. If your organization has received a note from Hush Partners, the page for [organizations that received a note](/received-a-note) explains what it is. In each of the three situations, the contact form on the site is how the desk is reached.
## Questions people ask
### What happens if a UDRP complaint is filed against an onchain TLD anyway?
The procedure needs a registrar that is bound to implement the decision, and the complaint must name it. For an onchain TLD there is none. Whatever a provider did with such a filing, no party would be obliged to carry out a transfer, so the filing would not produce the remedy the UDRP exists to deliver.
### Does it matter whether the onchain TLD was acquired in bad faith?
Bad faith is one of the elements a complainant must show under the UDRP, but it goes to the merits. It does not create a procedure where the contractual basis is missing. In court, the holder's intent and conduct may be relevant under the applicable law, to the claim and to the remedy. That is one reason to record facts about use carefully.
### If an onchain registry entered into a contract with ICANN, would the UDRP then apply?
It would depend on what the contract covered. The UDRP binds a registrant through a registration agreement that incorporates it. Tokens already held by people who never accepted such an agreement would raise a separate question, and the answer would lie in the terms of that arrangement. This is why the accurate statement is that the UDRP does not apply as things stand.
### Can the brand obtain its own onchain TLD as a protective measure?
If the matching TLD has not been registered on a given registry, the organization can register it there and hold the token itself. That secures the name on that registry only, and it does not displace a token that someone else already holds. The comparison of an [ICANN dotBrand and an onchain TLD](/dotbrand-vs-onchain-tld) sets out how the two forms of control differ.
### How enforceable is an agreement reached with a holder?
It is a contract, and its enforceability follows the law that governs it. The strongest element is the transfer itself: once the token has moved to the buyer's wallet, the result is recorded onchain and no longer depends on the other party's future cooperation. That is why closing through escrow, where payment and token are exchanged under the same mechanism, matters more here than the promises in the document.