Brand protection

Approached about your name onchain: an internal procedure

A note about an onchain TLD matching your name reaches someone in the organization. Who should handle it, what to verify, and how to answer.

Approached about your name onchain: an internal procedure

Someone in your organization receives an unexpected message. The text explains that an onchain top-level domain matching your brand name, something like .yourbrand, is held by a third party, and that the holder is open to a conversation. The message might arrive through a contact form, through a professional network, through a forwarded email chain that has already passed through two colleagues, or directly to general counsel. It may be polished or brief. What it is not, in most cases, is anything your organization has a documented procedure for.

That absence of procedure is the real problem. The message either stalls in uncertainty or prompts a reply that commits more than it should. A legal team that treats an onchain TLD approach the way it treats a domain name dispute, with a standard workflow and a known set of checks, is far less likely to make an error in either direction. This article builds that workflow, from the moment the message arrives to the moment a considered reply goes out.

By the end of it you will know how to verify that the underlying asset is real, how to assess the sender’s seriousness, who inside the organization needs to be involved, how to check the registry record yourself, which four responses are available, and what you should never send, however routine the situation appears.

Why notes like this arrive, and why most organizations have no procedure

Onchain TLDs exist outside the DNS managed under ICANN. On a registry such as Freename, a TLD is recorded onchain as a token held in a wallet, a wallet being the software or device that controls the keys to onchain assets. Whoever holds a Freename TLD such as .yourbrand pays no annual renewal fee on it. A conventional domain name is different on both counts: it sits in a registrar account and lapses if the renewal is not paid.

The consequence of that design is that a holder has no built-in reason to release a name. Nothing comes up for renewal. No reminder arrives. If a holder wants to find a buyer, the holder has to approach one, and the most obvious potential buyer for .yourbrand is the organization named in the string. So the holder, or an intermediary acting under the holder’s mandate, sends a note.

Most legal teams have no standing procedure for this because the category of asset is unfamiliar. The Uniform Domain-Name Dispute-Resolution Policy, the UDRP, is the principal mechanism by which trademark owners recover conventional domain names registered in bad faith. It binds registrants through the registration agreements of ICANN-accredited registrars. An onchain registry is not part of that system, so the UDRP does not apply to it. A legal team trained on enforcement inside the ICANN system has no direct equivalent to reach for, and so the note sits.

There is a second reason. The note rarely arrives where it should. It lands with whoever the sender could reach: a general inbox, a marketing manager, a subsidiary, an outside firm that once filed a trademark for you. None of these recipients knows whether the message is a legal matter, a sales pitch or a scam, and none has an instruction that says where to send it. Unsolicited messages about names are common, and most of them deserve to be ignored. The few that concern a real asset look, at first glance, much like the rest.

Leaving the note unanswered has a cost, though not a dramatic one. If the asset is real and the approach is genuine, your organization has been offered a private conversation and has let it lapse without deciding to. A decision not to engage is perfectly sound. A non-decision is not, because nobody can later say what was checked or why nothing was done. The procedure below exists to turn every such note into a recorded decision.

First checks: is the asset real, is the sender who they claim to be

Before any internal routing or substantive discussion, two questions need answers. They take minutes, not days.

Is the TLD recorded onchain?

A block explorer is a website that displays the contents of a blockchain, and because the registry record is public, anyone on your team can check it there. Look up the exact string the sender mentions on the registry the sender names. If a record exists, you will see the address of the wallet that holds the token and when the token was created. If no record exists, the approach concerns an asset that does not exist, a different registry than the one claimed, or a misrepresentation.

Keep two points in mind. First, onchain registries are independent of one another, so the same string can exist on more than one of them. A note that does not say which registry it concerns has not yet told you which asset it is about. Second, an approach about a TLD that nobody has registered is a different thing altogether. It is an invitation to buy something from a registry, not an approach about an existing asset, and it does not need this procedure.

Is the sender who they say they are?

A legitimate intermediary operates under a named entity and can be identified. Check the domain of the address the message came from, confirm that the website matches the claimed identity, and confirm that the entity has a public presence consistent with the role described. Reach that website by typing its address yourself, not by following a link in the message.

A professional desk publishes how it works, which gives you something to compare the note against. An approach made in the name of Hush Partners, for example, can be held against the public site: the rules the desk works by are published, and so is the standard mutual NDA that covers every exchange. If a note claims to come from a desk and behaves differently from what that desk publishes, treat the difference as a finding.

Do not reply to the sender at this stage. The first checks are internal.

What a serious approach looks like, and what a doubtful one looks like

The note itself carries signal. Neither a formal presentation nor a brief message is inherently trustworthy, but the content and conduct of a serious approach follow a recognizable pattern.

Dimension Serious approach Doubtful approach
Asset Names the registry and the exact TLD string; the record can be found on a block explorer Vague reference to “your name in Web3” with no registry or string
Identity Named entity with a verifiable public presence Anonymous sender, or an identity that matches no public record
Conduct No urgency; content to wait while you run your checks; confidentiality proposed before detail Countdowns, mentions of competing interest used as pressure, demand for a rapid reply
Commercial frame Says only that a conversation is possible Leads with a price, or attaches payment details

The table deliberately leaves out one thing: whether the sender tells you who the holder is. A holder may act through an intermediary precisely in order to stay unnamed, in the same way that your organization might prefer not to appear as a buyer. An intermediary that declines to name the party behind it is not, for that reason alone, doubtful. What matters is that the asset can be verified and that the intermediary itself can be identified.

A doubtful approach is not necessarily dishonest. It may come from a holder who has never written to a legal department and does not know what one expects. But an approach that shows more than one doubtful sign warrants additional scrutiny before any internal time is spent on it, and an approach that shows a payment request in the first message warrants none at all.

Routing: who needs to know, and who does not

Once the first checks are complete and the approach appears genuine, routing is the next decision. It can go wrong in two directions, too narrow or too broad.

Who is informed at this stage

The head of legal or general counsel, if they did not receive the note themselves. The brand protection lead, if that role exists separately. No one else at this point.

One of the two should be the named owner of the file. A note that two people have seen and neither owns is in no better position than a note nobody has seen.

Who is not informed yet

Commercial teams, marketing, IT, communications and senior management above general counsel. These groups will have views and may act on them. A well-meaning colleague who replies to the sender “to find out more” has answered on behalf of the organization without knowing it. The note describes a potential transaction in a specialist asset; it deserves the same discretion as any other sensitive intellectual property matter.

The business unit that uses the name

If the approach relates to a name with an obvious commercial owner inside the organization, such as a product division or a subsidiary, that unit’s leadership may need to be informed eventually, but not before legal has assessed the approach and decided whether to proceed. During the assessment, the questions are whether the asset exists and whether the sender is credible. The business unit cannot help with either.

The person who received the note

The original recipient needs two things: confirmation that legal has taken the matter, and a clear instruction not to reply, forward or discuss it. This is the step most often skipped, and it is the one that prevents a second, uncoordinated answer from leaving the building.

Internal confidentiality at this stage is not secrecy for its own sake. It lets a legal team assess a matter before positions harden. The page for general counsel and brand protection teams sets out how this kind of file looks from the desk’s side.

Verifying the registry record yourself before any reply

This section is about what you do before you type a single word in response to the sender.

The verification has three parts.

First, confirm that the TLD string is the one the sender describes, character for character. An onchain TLD is a single token. .yourbrand and a longer or hyphenated variant of it are different assets, possibly held by different parties. Record the exact string, including any character that could be mistaken for another.

Second, note the address of the wallet that holds the token. The record tells you that the asset exists and which wallet holds it. It does not tell you which person or legal entity controls that wallet, and you should not try to guess. Write the address down as it appears, with the date on which you looked. If the matter goes further, you will want to show that the record you checked at the start is the record you were dealing with at the end.

Third, check whether any names have been issued under the TLD. Under a Freename TLD such as .yourbrand, names can be issued by its holder and by nobody else. If names such as pay.yourbrand already exist under .yourbrand, that is material information for any later conversation about what a transfer would involve, and it belongs in the file.

What you are establishing at this stage is a factual baseline: the asset exists, it matches the claim, and you have recorded what the public record shows. You are not making a valuation judgment or a commercial decision. If you also need to know what such an asset can and cannot be used for, the page on what works on onchain TLDs lists each capability with its source, including the limits. Onchain names resolve outside the ICANN DNS root, so an ordinary browser does not open them without support, and that limit is part of any honest assessment of what is being offered.

The procedure from receipt to reply

The checks above only help if they happen in the same order every time, whoever is on duty when the note arrives. Written as a procedure, they fit on one page. The sequence matters more than the detail: verification comes before routing, routing comes before any contact with the sender, and confidentiality is in place before anything substantive is said.

Handling an onchain TLD approach: internal procedure
  1. Log the noteRecord the date, the channel through which it arrived, the sender's stated identity and the TLD string mentioned. Do not reply.
  2. Check the registry recordLook up the string on a block explorer to confirm that the TLD exists onchain, and note the address of the wallet that holds it. If no record exists, note that too.
  3. Verify the senderConfirm that the sender's entity has a verifiable public presence consistent with the role claimed. Note any difference between what the note states and what the record shows.
  4. Assess the approachHold the note against the signs of a serious and of a doubtful approach. If it shows more than one doubtful sign, pause until the discrepancy is explained.
  5. Route internallyInform general counsel and the brand protection lead, and name the owner of the file. Brief them on the verified facts only. Tell the original recipient not to reply.
  6. Verify again before replyingRepeat the record check on the day of the reply, so that the answer rests on the current record.
  7. Choose and send the replyDecide which of the four answers applies and send it. Nothing about price, budget or the organization's level of interest is said before an NDA is in place.
  8. Open a matter fileWhether you proceed or decline, keep a record of the sender, the asset, the checks performed and the reply sent. It is useful if the same asset comes up again.

Two practical points make the procedure hold. The first is that everyone likely to receive such a note knows it exists. A one-paragraph instruction to the teams that run public inboxes, saying “messages about our name on a blockchain or in Web3 go to legal, unanswered”, does more than a detailed policy nobody outside legal has read.

The second is a default for the doubtful case. Where the approach fails the checks, the usual answer is no answer, with the note logged and the reasons recorded. Where it is ambiguous, a short reply that asks the sender to state the registry and the exact string commits the organization to nothing and often settles the question.

The reply: the four possible answers

Every genuine approach about an onchain TLD can be answered in one of four ways. The choice depends on what the organization wants, not on the framing of the note.

We are not interested

This is a complete and legitimate answer, and it needs no justification. A short note stating that the organization has reviewed the matter and does not wish to proceed is sufficient. A plainly worded decline says nothing about the organization’s rights or about how it views the TLD, and it does not prevent the organization from reconsidering later. Keep it brief, and have counsel approve the wording.

We want more information before deciding

This is appropriate when the first checks confirm that the asset is real but the organization needs to understand what is being offered before it can form a view. The reply asks for an NDA to be put in place first and states that the organization will then review the detail. It does not express interest in buying. It expresses interest in understanding the matter.

We are willing to talk

This reply confirms that the organization, having reviewed the note and run its checks, is willing to enter a structured conversation. An NDA comes first. The reply names no price, no budget and no timeline, and it says who on your side will handle the exchange. It opens a conversation and no more.

We want a desk to act for us

If the organization decides it wants professional representation, it can mandate a desk to act on its behalf. This is a different relationship from answering a note: the organization becomes a client and gives instructions. The brand namespace recovery service of Hush Partners covers this case, the acquisition of the onchain TLD that matches a brand, with one named partner following the file from first note to closing. It is the fitting answer when the legal team has established that the asset is real and concludes that the matter calls for experience it does not have in-house.

None of these answers is better than the others in the abstract. The organization’s own judgment determines which applies. The procedure ensures that the judgment rests on verified facts.

What never to send

Certain responses, however well intended, create problems that are difficult to reverse.

Do not send anything that states the TLD rightfully belongs to the organization. The organization may well have strong trademark rights. A trademark protects a sign used for particular goods and services, and how far that protection reaches a name on an onchain registry depends on the country and on the facts. Asserting the point informally, in a reply to an unsolicited note, opens a dispute that does not yet exist and may complicate a later negotiation. If the position is to be taken, counsel takes it deliberately.

Do not send a number. If you name a budget, a ceiling or a range, you have anchored the negotiation before understanding what is being offered. Price belongs inside an NDA, in the hands of whoever has the mandate to discuss it.

Do not send a threat. A message suggesting that the holder infringes the organization’s trademark and that legal action will follow does several things at once. It shows the holder how sensitive the organization is about the name. It may not be accurate, since the UDRP does not apply to onchain registries and other grounds vary by country. And it ends any prospect of a straightforward negotiation. If enforcement turns out to be the right route, that is a decision for your own counsel on the basis of a full analysis, not a reflex in reply to a note.

Do not send internal material. Forwarding the note back with the internal chain attached, or replying from a thread that contains colleagues’ comments, hands the sender your assessment. Write the reply as a new message.

Do not copy anyone outside the immediate legal team. Every additional recipient widens the circle, and an approach that becomes known across the organization tends to generate internal pressure to take a position before the facts are understood.

Do not send a reply that is neither yes nor no. “We’ll keep this on file” or “we may be in touch” signals interest without any of the protections that a deliberate reply, preceded by an NDA, would put in place. If the answer is not yet known, say that the organization will revert after an NDA is signed, or say nothing until it is known.

Keeping the matter confidential internally

Confidentiality is not how organizations naturally handle unexpected correspondence. A message that arrives in someone’s inbox tends to get forwarded. A subject line such as “interesting: someone wants to sell us our name in Web3” is exactly the kind that spreads.

The procedure interrupts that pattern by routing the matter to general counsel and the brand protection lead before it acquires a wider audience. Beyond that, four practices help.

A matter reference, not a descriptive subject line

Once the note is logged, internal communication about it uses a matter reference instead of the name of the asset or of the sender. Anyone who sees the subject line without context learns nothing from it.

The discipline of a confidential transaction

An organization that acquires an onchain TLD acquires a digital asset through a private negotiation. The habits of any confidential acquisition apply: limited internal distribution, briefing on a need-to-know basis, and no speculation about value in writing. An NDA governs what passes between the parties. It does nothing about what your own colleagues say to each other, and that part is yours to organize.

Outcomes for senior management, not process

If general counsel decides to proceed, whoever has commercial responsibility for the brand needs to know that a transaction is being considered. They do not need an account of the approach, the sender’s identity or the registry details. A short brief on what would be acquired and why is sufficient.

A clean matter file

If the organization does not proceed, the file records that fact and is closed. If it proceeds to a transaction, the file holds every exchange under NDA, the verified registry record, the agreed terms and the closing documents. A well-kept file protects the organization if the matter is revisited, whether by a successor general counsel, an auditor or the same sender with a new note.

Engaging a desk to handle the file

If the assessment leads to the fourth answer, the organization mandates a desk to find and approach the holder on its behalf. Hush Partners acts for organizations on that basis. One named partner follows the file from first note to closing, every exchange is covered by the standard mutual NDA, and closing runs through onchain escrow on an aftermarket: Freename’s by default, or another marketplace such as OpenSea if the client prefers. The fee is a fixed amount, never a percentage, and it is charged only to the client who mandates the desk.

The other case is a note that came from Hush Partners in the first place. An organization that answers such a note, or buys a TLD offered through the desk, pays the price of the TLD and no fee. The page for organizations that received a note explains what the note means and how to respond. The desk never names the seller of a given TLD, and it is reached only through the contact form on the site.

If no note has arrived and you would prefer to know your position beforehand, the free Trademark Name Check on the trademark TLDs page is the place to start.

The concrete next step is modest. If a note is sitting in an inbox, log it and run the first two checks: the record on a block explorer, and the identity of the sender. If no note has arrived, write the one-paragraph instruction that tells colleagues where such a message goes, and name the person in legal who owns it. Either task fits in an afternoon, and everything else in this article follows from it.

Questions people ask

Does signing an NDA before any discussion commit us to anything?

A mutual NDA of the usual kind creates a confidential channel for the exchange of information and binds both sides equally. It is not, by its nature, an undertaking to buy or a statement about anyone’s rights. Read the document you are actually given, as you would any other, and let your own counsel confirm that it says no more than that.

If we hold a trademark registration for this name, can we simply demand the TLD?

Not through the UDRP, which applies to domain names in the ICANN system and not to onchain registries. Whether other legal grounds are available depends on the country, on the use made of the TLD and on the facts, and it is a question for your own counsel. Many organizations weigh that uncertain route against a negotiated acquisition, whose outcome and cost are known before they commit.

What if the sender says another party is interested and we need to decide quickly?

Pressure of this kind is a reason for more scrutiny, not less. A genuine holder with a genuine asset does not need your organization to abandon its procedure. Run the checks, route the matter and reply in the time the procedure requires. If another party does acquire the asset in the meantime, that was outside your control. A reply improvised under pressure is not.

Can the organization use an onchain TLD once it has acquired it?

Within limits, yes. On Freename, the holder of a TLD is the only one who can issue names under it, so the organization would decide which names exist under .yourbrand. Names resolve in some wallets and in browsers with the appropriate support. Coverage is partial and changes, and an ordinary browser does not open an onchain name unaided. For a public website, the DNS remains the simpler tool. What to do with the TLD after a transfer is a separate planning exercise.

What if the note arrived months ago and no one acted on it?

Log it as if it had just arrived. Check whether the TLD is still held by the same wallet and whether any names have been issued under it since. If nothing material has changed, the procedure applies as written. If the token has moved to another wallet, record that and reassess, since the sender of the original note may no longer speak for whoever holds it. A late start is still a start, and the file should say when it began and why.

The Hush Partners desk

Notes from the desk. Written by the people who run the files.

Tell us what you hold. Quietly.

One named partner reads every request. Holders start with a private valuation. Organizations start with a confidential brief.