Onchain TLDs and crypto exchanges: what to check

An exchange’s name sits in an unusually exposed position. It is the thing users type when they want to move money, the string they search when a transfer goes wrong, and the brand they expect to see when a support message arrives. Most organizations can absorb a degree of onchain namespace confusion as a reputational irritant. For a custodian or trading venue, the same confusion sits one paste error away from a misdirected transfer that cannot be recalled.

This guide is written for the general counsel or head of security who wants to know what is specific to the sector. The background fits in a few lines. An onchain top-level domain (TLD) is a name ending such as .yourbrand, recorded on a blockchain instead of in the ICANN DNS root. On Freename, the registry used as the reference here, a TLD is a token held in a wallet, it carries no annual renewal fee, and only its holder can issue names under it, such as pay.yourbrand.

The first section sets out why the exposure here differs from that of a generic brand. The rest works through the points where it shows, the functions that own them, and a checklist that can be handed to a team the same day. It closes with what holding the TLD would open, beyond the defensive case.

Why crypto exchanges sit in a different risk category

Most brands meet onchain namespace risk as a question about the future. The concern is that user behavior might shift, that a third party might build something confusing, or that a gap in resolution might one day matter. For an exchange, each of those conditions is already present and already has consequences.

Your users are onchain every day. They hold wallets, they read addresses, they paste strings of characters into interfaces where a single wrong character sends funds to the wrong place. They are not browsing, they are transacting. The distance between “a confusing name exists” and “a user acts on it” is much shorter here than for a brand whose customers have never opened a wallet.

The second distinguishing feature is that your organization’s name is associated, in the public mind, with the safekeeping of assets. Users extend an implicit guarantee to anything that looks like your brand. A name under .yourbrand carries that implied endorsement without any effort from whoever issued it. A user who sees support.yourbrand in a chat message does not stop to ask who holds the TLD. They assume you do, because your brand means custody.

Third, the sector depends on strings that users and counterparties must read and trust: deposit addresses, withdrawal destinations, notices about a token listing. Anything that makes that text more readable also makes an unofficial version of it more plausible.

Fourth, the facts about the registry concentrate the question on one party. Because only the holder of a TLD can issue names under it, every name ending in .yourbrand exists by the decision of whoever holds the TLD. And because there is no annual renewal fee, the position does not lapse on its own. Waiting for it to expire is not a plan.

Finally, there is an asymmetry in how the story is told. If a name under the TLD is used to defraud a user, nobody describes it as a problem with an unfamiliar naming system. It is described as a user defrauded in your name. The fact that you neither issued nor controlled the name does not reach most users before the damage is done.

What a readable name changes for users who paste addresses every day

Wallet addresses are long, carry no meaning and are easy to corrupt. A single transposition is invisible to the eye and can redirect a transfer permanently. The practical response is a name: a short, readable string that resolves to a wallet address, so that the sender types or selects a word instead of copying a string.

Payments to a name work at this level. A name such as deposits.yourbrand can be set to resolve to a wallet address, so that someone who trusts your brand sends to a name and not to a raw string. Where the wallet in use supports that resolution, the user may never look at the raw address at all. Coverage is partial and changes, so it has to be confirmed for each wallet.

That is the benefit, and the exposure is its mirror image. Your users are exactly the population for whom a readable name is a relief. They have learned to distrust long strings and to welcome anything that spares them the copy and paste. A name such as refund.yourbrand or withdraw.yourbrand does not have to defeat any system. It only has to look like something your organization would plausibly have set up, in front of a person who would rather not check forty characters by eye.

A name also behaves differently from an address in one respect that security teams should note. An address is fixed. A name is a pointer, and whoever controls the name controls where it points. A user who checked a name once and saved it has checked the label, not the destination behind it on the day of the next transfer. Your own address book and allowlist controls are built around addresses for that reason. A name you do not control sits outside them.

None of this waits for your organization to adopt names for payments. The exposure exists as soon as names are issued under the TLD matching your brand by someone other than you, whether or not you ever planned to use the TLD yourself, because those names borrow the association with your brand in the eyes of the users who meet them.

Deposit addresses and the irreversibility problem

An onchain transfer that reaches the wrong address has no recall mechanism. There is no chargeback, no dispute window, no intermediary holding the funds while the error is investigated. Finality is the feature, and it applies equally to mistakes and to fraud.

This creates a specific exposure at the moment a user is waiting for a deposit address. Consider a scenario with invented parties. A customer of a trading venue has opened a support request and expects to be told where to send funds. The TLD matching the venue’s name is held by a third party, and a name under it, deposits.yourbrand, resolves to a wallet the venue does not control. Someone posing as the support desk gives the customer that name. The customer recognizes the brand and sends. The transfer is final.

Nothing in this scenario touches your systems. It rests on two things only: the name exists, and the customer trusts the brand. The loss for the customer is complete, and the complaint arrives at your door whether or not you had any say over the name.

The standard guidance, “check the address against the one shown in your account”, helps less than it seems to. It asks the user to compare two things of different kinds: a string in the account and a word in a message. A user who believes that names are the new, safer way to send has no string to compare, and may read the absence of one as a sign of progress. A name that matches your brand exactly is more convincing than a copied page, because nothing about it looks forged.

For a custodian, the same logic runs in the other direction. Clients who withdraw to their own wallets, and counterparties who settle with you, ask where funds should go and who is asking. A name that carries your brand in a settlement instruction has weight with an operations desk on the other side. Your counterparties’ controls then become part of your exposure, and you do not run them.

Listing, support and recovery impersonation

The deposit address is the most direct path to a loss, but not the only one. Three further patterns are specific to this sector. They are described here so that your teams can recognize them.

Listing impersonation concerns the project teams that want a token admitted to trading on your venue. Names under the TLD matching your brand can be used to pose as your listing team in outreach to founders. A project team that sees what looks like an official onchain identity of your exchange is more inclined to engage. The usual signs are a request for a fee for a listing that never happens, or a request for credentials and documents.

Support impersonation concerns end users who are already in difficulty: an account locked, a withdrawal delayed, a transfer that seems lost. These users are actively looking for someone to talk to. A name under .yourbrand presented as a support channel reaches them when they are least skeptical. Being onchain adds apparent legitimacy: it looks like something your organization set up on purpose, not like a copied web page.

Recovery impersonation is the variant aimed at users who have already lost funds. It offers help with recovery in exchange for a fee, credentials or a further transfer. The state of mind of the person targeted does most of the work, and an authoritative-looking name does the rest.

The three have the same structure. Each depends on names under the TLD that you did not issue, none requires any access to your systems, and each produces an outcome that users and project teams attribute to your brand. They also land in three different inboxes: business development, the support queue and the incident team. Unless someone has told all three what a name ending in .yourbrand is, the reports are unlikely to be connected.

Why this sector is expected to have checked already

Exchanges and custodians operate inside expectations, from users, from institutional counterparties and from the market generally, that few consumer-facing brands share. You are trusted with custody. You are expected to know what is being done in your name. When a user is defrauded through something that looks like your infrastructure, the unspoken question from every counterparty is whether you knew it existed.

That question has a harder edge here. A consumer goods company that discovers an unofficial onchain presence can credibly say it had never looked at the namespace. An exchange, whose product is digital asset infrastructure, is expected to watch its own perimeter. “We did not know about onchain TLDs” is a difficult sentence for an organization that reads block explorers for a living.

The skills gap that excuses other sectors does not exist either. Reading a registry record, following a token to the wallet that holds it and checking whether a name resolves are routine tasks for your security and operations staff. An omission that would be understandable elsewhere looks, in your case, like a choice.

This is not a legal standard. Your own counsel decides what obligations apply in your jurisdiction, and the rules vary by country. It is a reputational and operational standard, applied by counterparties, auditors and institutional clients in due diligence whether or not any rule requires it. Being able to show that you checked, that you know the status of your name, and that you took a position on it is part of demonstrating operational competence.

The Namespace Exposure Score gives a structured starting point. It does not replace a full review, but it shows where the gaps are and gives the security or legal team a documented baseline.

Exposure by function inside the organization

The exposure does not sit in one team. It touches every function that deals with names, addresses or messages sent in your organization’s name.

Two things follow from the table. No single function sees the whole picture, so the review that follows involves at least three of these groups. And the functions most likely to meet a name first, support and business development, are the ones least likely to know what it is. A short internal note explaining the format of a name under .yourbrand, and where to report one, costs little and closes that gap.

Eight checks, with the function that owns each

The procedure below can be assigned as a unit. Each step names the function best placed to carry it out. Identify the owners at the start, and agree where the results are kept, so that the outcome is one file and not eight separate answers.

1. Check whether the TLD matching your name exists onchainLegal or security. Search the Freename registry, and any other onchain registry you consider relevant, for your exact brand name as a TLD. Record the result in the file. Everything else follows from it.
2. Read the public record of the TLDSecurity operations. Your analysts already have the tool for this: the registry record is public, and a block explorer shows it to anyone. Note the wallet that holds the token, whether names have been issued under the TLD, and whether any of them matches a function you perform: support, deposits, listings, refunds.
3. Run the Namespace Exposure ScoreLegal. Use the tool to produce a documented baseline of your brand's onchain exposure, and keep the output in the file.
4. Review your trademark coverageLegal. A trademark on the brand name does not by itself produce a remedy in an onchain namespace. Establish what your registrations cover and where they do not reach. Your own counsel decides what this means for enforcement.
5. Search your own records for names under the TLDCustomer support and security. Search the ticketing system and your brand monitoring for any mention of a name in the form anything.yourbrand. Treat a hit as an incident to investigate, not as background noise.
6. Map every point where a user receives an addressProduct and security. List each touchpoint where a user or counterparty is given an address or a name by your organization. For each, ask whether a name under .yourbrand could pass for a legitimate destination there, and document the answer.
7. Test whether issued names resolveSecurity and product. If names exist under the TLD, test whether they resolve in Bitcoin.com Wallet, in MetaMask through Freename's resolver, and in a desktop browser with the Freename Web3 extension. Coverage is partial and changes, so repeat the test at intervals.
8. Prepare the communications positionCommunications and legal. If the review finds names that present an impersonation risk, agree what users will be told and through which official channels before any finding leaves the review group.

The order matters less than the first two steps. If the TLD does not exist in the registry you check, steps five to seven shrink to a note in the file and the review becomes a question of monitoring. If it exists and no names have been issued under it, the exposure is latent and the decision is about timing. If names exist that mirror your own functions, the review has become an incident and the remaining steps run in parallel.

On the fourth step, the page on trademark TLDs explains how a TLD that matches a registered mark is treated, and carries a free check of the name.

Options and who should own the file

Once the review is complete, the organization has three realistic positions: monitor, acquire or enforce.

Monitor fits where the TLD exists, no harmful names have been issued and there is no sign that the name is being used against your users. A namespace watch keeps the name in view without forcing a decision before one is needed. The limit of this position is that it is reactive: you see activity after it starts, not before.

Acquire fits where the review finds meaningful risk, or where the organization wants to use the TLD and not only neutralize it. The holder may have no particular plan for the name, in which case the conversation is simple. The holder may have a use for it, in which case the approach needs more care. An organization can mandate Hush Partners to find and approach the holder through brand namespace recovery. The exchanges are 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.

Enforce is the narrowest option. The UDRP binds registrants in the ICANN namespace through their registration contracts, and it does not reach an onchain TLD. A complaint to a registry or a marketplace under its own terms, where such a process exists, does not by itself place the TLD in your hands. Your own counsel decides whether another route is available in your jurisdiction, and what it could achieve.

Who owns the file

The file should sit with legal, with security and product as contributors. The choice between the three positions is an organizational decision, not a technical one, and it should be recorded as such.

One point of ownership is specific to this sector and is best settled before an acquisition closes. A TLD is a token in a wallet, so once acquired it is an asset under key management, and your organization already has standards for that. Decide in advance which wallet receives it, whether that wallet is a multisignature wallet (one that needs several approvals before it acts), who the approvers are, and who is allowed to issue names under the TLD. A TLD held on one employee’s device would be an odd outcome for a custodian. Treat it as you would any other asset whose loss would be reported to the board.

What an exchange could build on its own TLD

The defensive case for holding .yourbrand follows from everything above: names under the TLD are then issued by you and by nobody else. But a TLD under your control is also a usable asset, and several of its uses are specific to this sector. The work of putting a TLD to use after the transfer is a project in its own right.

Payment names for customers. With the TLD in your hands, you can issue names to users, such as name.yourbrand, that resolve to their deposit addresses. A customer who needs to give a counterparty a destination gives a name, not a raw string. Because only the holder of the TLD can issue names under it, a name ending in .yourbrand then means one thing. Where the sender’s wallet supports resolution, this reduces paste errors. Check what is live before designing any integration, because coverage is partial and changes, and keep the raw address available wherever a name does not resolve.

A published list of official names. If you hold the TLD, you can state publicly which names you use and for what: one for support, one for the listing team, one for notices. Anyone can then compare a name they were given with that list, and with the public registry record. This does not replace your existing authentication. It gives users and project teams a simple rule: a name you did not publish is not yours.

Payment routing to a name. A payment link built on shaka, an onchain payment router, can pay out to a name instead of a raw address, and the split between parties is agreed and signed onchain before funds move. The router routes funds and does not hold them. For a venue that shares a payment with partners or referrers, the point is that the split is settled before the transfer and not reconstructed afterward.

Agent identities under your namespace. ERC-8004, “Trustless Agents”, is a draft Ethereum standard that defines three registries for AI agents: identity, where each agent is an ERC-721 token pointing to its agent card, reputation and validation. Being a draft, the text may change, and the way naming registries plug into it is still evolving. The relevance for this sector is plain. If your organization runs agents for customer interaction, screening or execution, the question of whose namespace they are named under is better answered before they are deployed. The page on identities for AI agents follows the state of that capability.

Names for listed projects. An exchange that issues names to the projects it lists creates a directory under its own namespace. A listed project could hold a name under .yourbrand as an identifier you issued. Its existence then says something, and so does its absence. That also makes issuance a decision with consequences: a name you issue is read as an endorsement, so the rules for granting and withdrawing one belong with the team that decides listings.

None of these uses is a reason to acquire a TLD by itself. The DNS remains the better tool for your website, your email and anything that must open in every browser. The uses above matter because they answer the specific weaknesses described earlier, in the place where your users already are.

Where to start, and when to bring in the desk

The checks can be delegated the same day. Assign the first two, whether the TLD exists and what its public record shows, to security or legal with a short deadline, and have the exposure score run in parallel. Keep the findings inside the review group until there is a position.

What comes next depends on the result. If the review finds names that present a risk, the next step is a confidential approach to the holder, and that is the case in which a mandate to the desk makes sense. If the TLD exists and nothing harmful has been issued, the decision is between monitoring and acquiring, and it is easier to take calmly than during an incident. If the TLD does not exist in the registry, the question is whether your organization wants to hold it, which your product and legal teams can settle without anyone else.

Whatever the finding, it is worth having on file before it is needed in an incident. For teams that want to read further before speaking to anyone, the page for general counsel and brand protection teams sets out how the desk works with them. When your team is ready to speak, the contact form on the site is the way to reach the desk.

Questions people ask

Does holding the TLD onchain affect our existing DNS setup?

No. An onchain TLD sits outside the ICANN DNS root. Holding .yourbrand onchain does not interfere with your DNS registrations, your website or your email. The two systems are independent. Users reach onchain names only through wallets or browsers that support the relevant resolver, and an ordinary browser opens your DNS domain as before.

Is a name under the TLD the same risk as a lookalike DNS domain?

It is a different risk. Its reach is narrower, because the name resolves only where a wallet or browser supports it. But it is an exact match of your brand, not a misspelling, and it appears in the one setting, the wallet, where your users move value. The takedown routines your team uses for DNS domains were not built for it, which is why it needs its own line in the review.

What does partial resolution mean in practice for our users?

It means that not every wallet or browser opens an onchain name without setup. For your users, support for Freename names comes from Bitcoin.com Wallet, from MetaMask when Freename’s resolver is used, and from desktop browsers running the Freename Web3 extension. A user without one of these does not resolve the name. Coverage is not universal and it changes, so any integration that relies on resolution has to verify support for the wallets your users hold, and be checked again when that software is updated.

Does legal need outside technical help to run the review?

Usually not, and that is particular to this sector. The technical steps, reading a registry record on a block explorer and testing resolution in a wallet, are within the daily work of your own security and operations staff. What legal brings is the trademark analysis, the confidentiality of the file and the decision record. Your own counsel decides the legal questions.