# Registry, wallet and marketplace policies a brand can invoke

> Courts are slow and far away. The terms of the platforms that record, resolve and trade onchain names are closer. What they can and cannot do for a brand owner.

Source: https://hush.partners/platform-policies-as-a-lever-for-brand-owners
Category: Brand protection
Published by Hush Partners.

---
Finding a name onchain that mirrors your brand is not the same as finding one in the ICANN domain system. The familiar reflex, which is to file a UDRP complaint and ask for a transfer, does not apply. Onchain TLDs operate outside the ICANN DNS root, and the dispute policy that ICANN's contracts make mandatory for registrars does not reach them. What does exist is a set of private relationships: each platform that touches an onchain name has terms of service, and those terms give a brand owner something to point to when a name is used in a way that misleads people.

The first part of the work is therefore operational before it is legal. You need to know which kind of platform controls which aspect of a name's life, what each one is technically capable of doing, and how to frame a request so that it reaches the right team and asks for something that team is able to provide. This article follows the chain from registration to the customer's screen and asks, at each link, what the operator of that link can realistically do, and what it cannot do even if it wished to.

By the end, you will know whom to write to, what to put in a written request, why platforms treat a name in active use differently from a name that simply sits in a wallet, and how to keep a platform request and a private negotiation properly separate when both are open at once.

## The four kinds of platform, and what each one controls

The chain between a name and the person who encounters it passes through four kinds of platform. They overlap in practice, since one company may operate a registry, a resolver and an aftermarket at once, but the functions are distinct and so is the analysis of each.

| Platform type | What it controls | What it cannot do |
|---|---|---|
| Registry | Issuance of TLDs; the contracts that hold the record | Rewrite the record at will; decide what other platforms show |
| Resolver or wallet | The lookup that turns a name into an address, in its own interface | Change who holds the name; stop it resolving elsewhere |
| Browser extension | Whether a name opens as a site in the browser where it is installed | Change the record; remove the content the name points to |
| Marketplace | What is shown and traded on its own venue | Change the record; govern other venues or private transfers |

### The registry

The registry is where a TLD and the names under it first exist. On Freename, for instance, a TLD takes the form of a token recorded onchain and sitting in a wallet (a token being an entry on a shared ledger that one wallet controls), and nobody except the holder of that TLD is able to issue names under it. The registry operator writes the smart contracts, meaning the programs on the ledger that govern issuance and transfer, and it sets the terms of service that every registrant accepts. It may also run support, a website and offchain systems around those contracts.

What follows from this design matters for your request. Once a token is in a holder's wallet, moving it ordinarily takes a transaction from that wallet. Whether the registry keeps any administrative power over a token it has issued depends on how its contracts were written and on what its terms say, and you should not assume that such a power exists or that it would be used on a third party's request. Note also the split in control at the second level: names under a TLD are issued by the holder of that TLD, so a complaint about `pay.yourbrand` concerns a name issued by whoever holds `.yourbrand`.

### The resolver or wallet

A resolver is the service that answers the question "what does this name point to?". A wallet that supports onchain names sends that question to one or more resolvers and receives a wallet address or a content reference in return. The wallet operator decides which naming systems its software supports and how names are displayed to the person about to send funds.

Its control stops at its own interface. A wallet can decline to resolve a given name, or show a warning next to it, in its own software. It cannot change the record, and the name goes on resolving in every other interface that queries the same resolver. Support is also uneven, which narrows the list of operators worth writing to. Freename names, for example, can be used in Bitcoin.com Wallet and, by way of Freename's resolver, in MetaMask. Coverage of that kind is partial and it changes.

### The browser extension

Because onchain names sit outside the ICANN DNS root, an ordinary browser does not open them unaided. An extension fills that gap: once installed, it lets the browser reach a site published under an onchain name. On desktop browsers, Freename names open through the Freename Web3 extension. The operator of an extension controls what its own software opens, and nothing about the underlying record or the content, which is often stored on IPFS, a network that distributes files across many computers and has no single host. The page on [what works with onchain TLDs](/whats-live) keeps track of where names resolve, with sources.

### The marketplace

A marketplace is a venue where tokens, including those that represent names, change hands between parties. Its control is limited to its own venue: it decides what appears on its pages and which accounts may use them. It has no authority over the record, over other venues, or over a transfer that two parties arrange directly between themselves. A request to a marketplace can therefore affect what one venue displays, and nothing else.

## The legal character of a platform's terms

A brand owner who writes to a platform is not, in the first place, asserting trademark law against that platform. It is pointing to the platform's own rules. A person who opens an account with a registry, registers a name or uses a marketplace accepts terms of service, and such terms commonly prohibit conduct that infringes the intellectual property rights of third parties or that deceives other users. That prohibition is the basis of your request.

In substance, a well-founded complaint asks the platform to apply its own terms to one of its own users. The platform has reasons of its own to listen. A naming system is only useful if wallets, browsers and institutions are willing to support it, and that willingness depends on names not misleading the people who rely on them. A credible, documented report of deception serves the platform's interest as well as yours.

That is not a guarantee of action. The terms are a contract between the platform and its user, and you are a third party to it. Unless the platform has published a complaint procedure and committed to follow it, the terms give you an argument and a channel. They do not give you an enforceable right against the platform, and how far any legal duty to act on notice exists varies by country. Your own counsel decides what, if anything, can be asserted beyond the terms.

The practical consequence is one of tone. A request that reads as help in applying the platform's own rules is easier to act on than a demand that assumes an obligation the platform does not recognize.

<aside class="callout">
<span class="callout-label">For legal teams</span>
<h4>Read the terms in force before you write to any platform</h4>
<p>Platform terms are revised, and the version that applies is the one in force when you write. Read it at that time, keep a dated copy with your file, and cite the clause as it stands. A request built on a clause that is no longer there is easy to set aside.</p>
</aside>

## Use against mere holding: why platforms treat them differently

Platforms treat the active use of a name differently from the holding of it, and that difference should shape what you ask for.

A name that is registered and held, pointing at nothing, has misdirected no one. Nobody has paid the wrong party and nobody has been led to believe that the holder is connected with the brand. Holding a token is, on its face, a use of the registry that its terms permit. There are also many ordinary reasons for a name to match a mark. Trademark rights are territorial and tied to particular goods and services, so the same word can belong to different owners in different countries and trades, and many marks are also dictionary words, surnames or place names. A platform that reads a complaint about a held name sees one party asserting a right and another using the service as designed, with no harm to point to.

A name in active use is a different matter. If `pay.yourbrand` resolves to a wallet that receives payments from people who believe they are paying your company, or opens a site that presents itself as yours, there is a specific act, a specific person misled, and evidence that a reviewer can check without deciding any question of trademark law.

The reason platforms draw this line is the role it gives them. In the first case, the platform is asked to arbitrate between two claims to a word, which it is poorly placed to do and which courts in different countries would decide differently. In the second, it is asked to stop its own service from being used to deceive, which is squarely within its terms and its competence.

For your file, the consequence is practical. If what you have found is a name that is held and unused, a platform request is rarely the right instrument, and it should not be dressed up as a complaint about use. The options that fit are to keep the name under observation and, if your organization wants the name itself, to try to acquire it. A service such as [Namespace Watch](/namespace-watch) monitors the names of a brand onchain, so that a change from holding to use is seen when it happens.

## How to write a request that has a chance

A reviewer on a platform's legal or trust-and-safety team reads many reports and can act only on those that are specific. A request that identifies the relevant clause of the platform's terms, documents your rights and the precise use complained of, and asks for a measure the platform is able to take gives that reviewer what is needed to decide.

<figure class="fig">
<figcaption><b>Writing a request to a platform</b></figcaption>
<ol class="fig-steps">
<li><b>Identify yourself and your rights</b>State who you are, the mark or marks relied on, where each is registered, and the registration numbers. Attach the certificates or a link to the public register. If your rights come from use in a country that protects unregistered marks, describe that use and where it takes place.</li>
<li><b>Identify the name and the clause</b>Give the exact name, the TLD it sits under, and the clause of the platform's terms in force that you say applies. Quote the clause exactly and keep a dated copy of the page.</li>
<li><b>Describe the use complained of</b>Be precise about what the name does on this platform. If it resolves to a wallet in the platform's interface, say where and show what a user sees. If it opens a site, capture the content with the date and the software used. State facts you have observed and nothing you infer.</li>
<li><b>Ask for a measure this platform can take</b>Match the measure to the operator: a wallet or extension can stop resolving a name or warn its users, a marketplace decides what its own venue shows, a registry can review an account under its terms. Do not ask an operator for something outside its control, such as asking a wallet to transfer a name.</li>
<li><b>Give a contact and a statement of accuracy</b>Name the person who will answer questions, with a title and a way to reply. Add a statement that the information is accurate to the best of your knowledge and that you believe in good faith that the use described is not authorized.</li>
</ol>
</figure>

Keep the covering message short. The reviewer should be able to understand the rights, the use and the measure requested in one reading, with the evidence attached and not embedded in running text. Use the channel the platform has published for reports of this kind, in the form it asks for. A request sent elsewhere may never reach the team that could act on it.

Two cautions belong here. First, say only what you can support: an overstated complaint weakens the next one you send to the same platform. Second, write on the assumption that the holder may read your request. A platform may pass it on, in full or in summary, and nothing in it should be something you would not say to the holder directly.

## What a platform will usually not do

Knowing the limits of platform action saves time and prevents a false sense of progress.

A registry will not, in the ordinary course, move a token out of a third party's wallet because a complaint has been received. Control of the token by its holder is what the record means, and holders, wallets and buyers all rely on that. Whatever administrative powers a given registry's contracts and terms may contain, a transfer to the complainant is not an outcome to plan around.

A marketplace that removes an item from its venue has not given you the name. The record is unchanged and the holder still holds the token. The measure concerns one venue only. It can be the right measure where the venue's own pages carry a misleading presentation of your brand, but it should not be confused with recovery.

A wallet or resolver that stops resolving a name has not changed who holds it. The name stops working in that interface and continues to exist onchain, where other software that queries the same record can still resolve it. Where the harm is payments sent to the wrong party through a particular wallet, that is a real protection for users of that wallet. It is not a transfer.

A platform will not usually tell you who the holder is. The record shows a wallet, which anyone can look up on a block explorer, and a wallet is not a name and address. Platforms that hold account details are bound by their own privacy terms and by data protection law, and disclosure generally requires a legal process whose availability varies by country.

Finally, a platform will rarely decide a contested trademark question. Where the holder has a plausible reason to use the word, expect the platform to decline and to leave the matter to the parties or to a court.

## What each kind of request can realistically achieve

Within those limits, the value of a request differs by platform.

A request to a registry is most useful where the registry has published a policy on trademarks or on abuse of its namespace. Where such a policy exists, read it and follow its procedure exactly. The plausible results are a review of the account concerned and, depending on the policy, measures the registry applies within its own systems. It will not produce an automatic transfer of names already issued. For the relation between a mark and the TLD that matches it, see the page on [trademark TLDs](/trademark-tlds), which also holds a free Trademark Name Check.

A request to a wallet or resolver operator fits cases of active use that put users at risk, typically a name that resolves to a payment address presented as the brand's. If the operator acts, the effect is felt where the harm occurs, on the screen of the person about to pay. Before you write, establish in which wallets the name resolves at all, since support differs from one wallet to the next. The page on [names that resolve in wallets](/onchain-tld-wallets) explains how that support works.

A request to the operator of a browser extension works the same way one layer along. It is relevant where the use consists of a site, reachable through the extension, that presents misleading content under your name.

A request to a marketplace is relevant only to what that venue itself displays. If its pages present a name with your logo, or with a description that claims a connection to your company, the venue's terms on intellectual property are the natural basis for asking that the presentation be corrected or removed.

In every case the result is the platform's decision. Some requests are acted on, some are declined, and some receive no reply. None of those results changes your rights, and none of them should be reported internally as more than it is.

## Escalation and the patience required

Platforms do not process complaints on a common timetable, and few publish one. Operators differ in size, in where they are established and in how they are governed, and their procedures differ accordingly. Plan for an acknowledgment that may take time and for the possibility of none.

If a first request goes unanswered after a reasonable interval, send a follow-up that restates the request, refers to the original submission and its date, and adds anything new you have observed. If the platform publishes a dedicated legal or intellectual property contact, use it at this stage. One further reminder after that is reasonable. Beyond it, repeating the same message achieves little, and the question becomes whether another route fits the problem better.

Routes beyond the platform exist, but they are heavier. There is no body above an onchain registry that plays the role ICANN plays for accredited registrars, and no accreditation that a registry could lose. A court can in principle make orders concerning a platform or a holder, but identifying the proper defendant, establishing jurisdiction and enforcing an order across borders are real difficulties, and the answers vary by country. Whether litigation is proportionate to the harm is a decision for you and your counsel.

Patience has a practical value: the record you build. A dated sequence of requests, with the evidence attached to each, shows when the use was first observed, what was reported and to whom.

<aside class="callout">
<span class="callout-label">For legal teams</span>
<h4>Document every step, even when nothing happens</h4>
<p>A request that produces no action still records when you identified the use and what you did about it. Keep dated captures, submission confirmations and all correspondence in one file, so that counsel can rely on it later if needed.</p>
</aside>

## When a platform request and a negotiation run in parallel

A platform request and a negotiation answer different questions. The request concerns a use: something the name is doing that misleads people, which you ask an operator to stop on its own service. The negotiation concerns the name itself: your organization would like to hold it, and the present holder may or may not be willing to part with it. The two can be open at once, because a harmful use may need attention while a conversation about acquisition takes its own time.

What they must not become is a single instrument. A complaint is not a negotiating tool. Filing one without a well-founded grievance about use, in the hope that the holder will become more accommodating, misuses the platform's procedure. It also tends to fail on its own terms: the platform sees a complaint with no harm behind it, the holder sees an opening move made in bad faith, and both remember it. A holder who has done nothing but hold a token has broken no rule, and a conversation that starts from that recognition goes further than one that starts with an accusation.

Running both tracks properly comes down to a few disciplines:

- Keep the files separate. The request to the platform states the use and the measure sought, and says nothing about acquiring the name. The approach to the holder is an offer to discuss a purchase, and does not mention the complaint as a consideration.
- Keep the statements consistent. Anything you tell the platform may reach the holder, and anything you tell the holder may later be shown to a platform or a court. Say the same true things in both places.
- Do not make one conditional on the other. If the use stops, tell the platform so. If the holder declines to sell, the complaint about use stands or falls on its own evidence.
- Involve counsel on both. How a complaint and an offer interact in law varies by country, including the effect of correspondence marked as settlement discussion.

There is also the question of who makes the approach. An organization may write to a holder itself, or it may mandate an intermediary to find and approach the holder on its behalf. Either way, the approach should be one the holder can take at face value: a clear expression of interest, a reasonable time to answer and no pressure. The service page on [brand namespace recovery](/brand-namespace-recovery) covers the acquisition of the onchain TLD that matches a brand.

Where no use is at issue at all, there is only one track. A held name that you would like to hold yourself is a matter for an offer, and for accepting that the answer may be no.

## What to expect, and where to start

A well-prepared request, sent to the right platform, can end in several ways: no reply, a refusal, a review of an account, or a measure that stops a misleading use on that one service. No platform procedure for onchain names does what a UDRP decision does in the DNS, which is to order a transfer that the registrar must carry out. On this point the DNS is simply better equipped, and it is more accurate to say so than to present platform requests as an equivalent.

Their value lies elsewhere. They are inexpensive to prepare, they address harm at the point where a user meets it, and they do not require a court. Those are sufficient reasons to make them well when a use warrants one.

A concrete way to begin is to take one name and write down four things: what the name does at present, on which platforms that can be observed, which operator controls the thing you object to, and what that operator could do about it. If the first answer is "nothing", you have a monitoring matter and possibly an acquisition, and no complaint to file. If the name is in use, the remaining three answers tell you which operator to address and what to ask for. To see the wider picture before choosing which names deserve attention, the [Namespace Exposure Score](/namespace-exposure-score) is a free tool that scores how exposed a brand is onchain.

Where the conclusion is that your organization wants the name itself, that is the part of the problem a desk can take on. For a general counsel or a brand protection team in that position, Hush Partners works under a mandate from the organization, and the mandate is to find the holder of the name and approach that holder. A standard mutual NDA covers every exchange, one named partner follows the file from the first note to closing, and closing runs through onchain escrow on an aftermarket. The fee is a fixed amount and never a percentage, and only the organization that gives the mandate is charged it. The page for [brands and legal teams](/brands-and-legal-teams) is written for general counsel and brand protection teams weighing that route.

## Questions people ask

### Can a complaint make a registry transfer an onchain name to the brand owner?

It should not be expected to. In the DNS, a UDRP decision is carried out by a registrar that is contractually bound to do so. An onchain registry has no comparable obligation toward a complainant, and what it is able and willing to do depends on its own contracts and terms. Read the registry's published policy and ask for what that policy provides.

### Is a measure taken by a platform permanent?

Not necessarily. A measure applies on the platform that took it and for as long as that platform maintains it. The holder may answer the complaint, the platform may reconsider, and the name remains usable wherever other software supports it. Check periodically that the situation you documented is still the situation.

### Does filing a complaint affect a later conversation with the holder?

It can. The holder may learn of the complaint and will read any later approach in that light. That is one more reason to file only where a use justifies it, to state it accurately, and to keep it apart from any discussion of acquisition. A complaint that was fair and factual does not prevent a civil conversation afterwards.

### Do wallets and browser extensions have complaint procedures for names?

Some publish a form for reporting abuse or intellectual property concerns, and others offer only a general support channel. Few procedures are written specifically for onchain names. Where there is no dedicated route, the request has to be clear enough for a general reviewer: what the name is, what it does in that software, and what you are asking the operator to do. Check the operator's documentation before you send anything.

### Where does the UDRP apply, and where does it not?

The Uniform Domain Name Dispute Resolution Policy applies to domain names in the generic TLDs of the ICANN DNS, and to those country-code TLDs whose operators have chosen to adopt it. It binds registrants and registrars through their contracts. Onchain TLDs are recorded outside that system, so no such contract exists and a UDRP complaint cannot be brought against an onchain name. The [glossary](/glossary) defines the terms used for both systems.
