# How a brand gets impersonated onchain: five vectors
> Payment names, wallet names, websites, agent identities and lookalike strings: how a name under your mark can be used, and what to watch.
Source: https://hush.partners/onchain-brand-impersonation-vectors
Category: Brand protection
Published by Hush Partners.
---
A brand team that monitors domain registrations in the ICANN DNS has an established workflow: watch for new registrations in the major generic and country-code TLDs, file disputes under the UDRP where warranted, and engage a registrar directly when speed matters. That workflow does not transfer cleanly to onchain TLDs, because the architecture is different in one important respect. The entire namespace beneath an onchain TLD, meaning every name that could ever exist under it, is controlled by whoever holds the TLD token. The enforcement path is not the same, the places where names resolve are not the same, and the customer-facing uses are not the same either.
This article describes five distinct ways a name under a TLD that matches your brand could mislead a customer or misdirect a payment. Each is described from the customer's point of view: what they see, why it looks credible, and what your team can do to recognize it and respond. The five vectors are not equally mature, and their reach depends heavily on which wallets and browsers a customer uses. That context is given for each one. The article describes what is possible, not what has happened: it makes no claim about how often any of these uses occurs.
After reading, a brand protection or security lead should be able to name each vector, judge which ones are relevant to their own customer base, and have a basis for deciding what to monitor and how often.
## Why control of the TLD is the source of the exposure
On Freename, one of the registries where onchain TLDs are recorded, a TLD exists as a token held in a wallet. That token's registry record is public, so a brand team, like anyone, can check it on a block explorer. What flows from holding that token is the exclusive right to issue names beneath the TLD. Only the holder can create `pay.yourbrand` or `support.yourbrand`. The holder may issue many names, a few, or none at all.
This is structurally different from the situation brand teams know in the ICANN DNS, where an unrelated party registers a confusing name under a shared TLD that is open to public registration and that no single registrant controls. With an onchain TLD, the question is not whether someone registered one confusing name. It is who holds the TLD itself. If `.yourbrand` is held by a party with no connection to the brand, that party administers the entire namespace. Every name issued, every website published and every payment name configured under it flows from that single point of control.
Two consequences follow. The first is that a finding is rarely isolated: one name under the TLD tells you that the holder is issuing names, and others may follow from the same source. The second is that the conversation that settles the matter is usually with one party, the holder of the TLD, and not with a series of separate registrants.
None of this means that a holder of a matching string has done anything improper. Many strings are ordinary words, surnames or acronyms shared by unrelated organizations, and a holder may have a legitimate use of their own. The point is narrower: until your organization holds `.yourbrand`, it has no technical authority over the names issued beneath it. The [Namespace Exposure Score](/namespace-exposure-score) is a free tool that scores how exposed a brand is onchain, and it is a reasonable first measurement before deciding how much attention the subject deserves.
## Vector 1: payment names that look like your brand
The most immediate commercial exposure is a payment name: a string such as `pay.yourbrand` or `invoices.yourbrand` that a payer sees in a wallet or in a payment link and takes to mean the funds will reach your organization.
The reason is simple. A readable name replaces a raw wallet address in the payment flow. A raw address is a long string of characters that most payers neither read nor compare. A name is legible and memorable, and a payer applies to it the same trust they apply to a domain name in a web address. They see the brand, and they proceed.
Payment tooling makes names more prominent, which is useful when the name is yours and a concern when it is not. One example is [shaka](https://shaka.deal), an onchain payment router in which a payment link can pay out to a name instead of a raw address, with the split between parties agreed and signed onchain before funds move. It routes funds and does not hold them. In an interface of this kind, the payer reads a name and confirms. If a name under `.yourbrand` was not issued by your organization, nothing in the name itself tells the payer so.
The names to recognize are those that pair the TLD with a word a customer associates with paying you: `pay`, `invoice`, `billing`, `checkout`, `treasury`. The organizational control that matters most sits outside the namespace: your invoices, your website and your customer communications should state plainly which payment destinations are yours, so that a customer has an official reference to compare against. The page on [payments to a name](/onchain-tld-payments) describes how payment names work for a legitimate holder.
## Vector 2: wallet names and everyday address resolution
Outside a structured payment flow, onchain names also resolve directly in wallets that support them. A customer who enters `treasury.yourbrand` in the send field of a supporting wallet triggers a lookup: the wallet retrieves the address mapped to that name and fills in the destination. The customer sees the name first and the address second, if they look at it at all.
Resolution is not universal. Onchain names resolve outside the ICANN DNS root, so software has to add support for them. For a customer of yours, the software that does support Freename names is Bitcoin.com Wallet, MetaMask by way of Freename's resolver, and desktop browsers fitted with the Freename Web3 extension. Coverage is partial and it changes. Many of your customers will be using a wallet in which a name under `.yourbrand` resolves to nothing, and for them this vector does not exist.
Partial coverage is still coverage. The customers most likely to use a wallet with name resolution are also the customers most likely to pay onchain, so the exposed group and the group for whom a misdirected transfer matters are largely the same people. An onchain transfer is also generally final once confirmed, which means the organization usually learns of a problem from a customer who has already paid.
What the customer cannot do is tell an official wallet name from an unofficial one by reading it. A name such as `custody.yourbrand` in a payment instruction looks the same whoever issued it. The page on [names that resolve in wallets](/onchain-tld-wallets) explains where resolution works and under what conditions.
## Vector 3: websites published under the TLD
Onchain TLDs are not limited to wallets. A holder can publish a website to IPFS, a decentralized storage network in which content is addressed by its hash and not by a server location, and attach it to a name under the TLD. The pages themselves can be built and published to IPFS by the holder with Freename's website builder. The site is then reached through the holder's onchain name in browsers that support it.
From the visitor's side, a page at `support.yourbrand` in a supporting browser carries your brand in the address bar. Customers have been taught for years to read the address bar as the test of authenticity, and here the address reads correctly. If the page presents itself as your organization, the visitor has little reason to doubt it, and whatever they submit there goes to the party behind the page.
The limit is real and should be stated honestly: an ordinary browser does not open an onchain name without support, so the audience for such a page is narrow. For a brand whose customers have no reason to use that software, the practical exposure is low, and the DNS remains where your customers actually find you. The exposure is concentrated in communities where supporting browsers and extensions are already common. If your customers include that group, a website under the TLD deserves the same attention as a payment name.
There is a second, quieter consequence. A site under a matching TLD does not need to imitate you to matter. A page that only uses the name for unrelated content can still confuse customers, partners or journalists about whether it is an official property. That is a reputation question more than a security one, and it is handled by the same monitoring. The page on [websites published on an onchain TLD](/onchain-tld-websites) describes how publication works and where such sites can be opened.
## Vector 4: agent identities that carry your brand name
This vector is the newest and the least mature. AI agents, meaning autonomous programs that place orders, submit forms or negotiate on someone's behalf, need a way to identify themselves to counterparties. ERC-8004, "Trustless Agents", is a draft Ethereum standard that defines three registries for this purpose: identity, in which each agent is an ERC-721 token pointing to its agent card; reputation, which holds feedback from those the agent worked with; and validation, which holds independent checks of its work. Being a draft, the standard may change, and the way naming registries plug into it is still evolving.
What matters for brand protection is the identity layer. If agents come to be identified by names issued under a TLD, an agent presented as `assistant.yourbrand` or `procurement.yourbrand` shows that string to every counterparty it deals with. A supplier or customer who receives a request from such an agent may reasonably assume it acts with your authority.
The exposure differs from the payment vectors in kind. The counterparty is not only sending funds to an unintended address. They may be sharing information, accepting terms or granting access to an agent they believe is yours. The harm is harder to see, because it can arrive without any payment at all.
Because the standards are unsettled, the proportionate response is to follow the subject, not to build a program around it. Note which names under your TLD suggest an automated role, and decide in advance how your organization will state which agents speak for it. The page on [identities for AI agents under a TLD](/onchain-tld-ai-agents) covers how these identities are structured for a legitimate issuer.
## Vector 5: lookalike strings at TLD level
The four vectors above assume that someone holds exactly `.yourbrand`. The fifth concerns TLDs that are near matches. Each near match is a complete namespace of its own, so every use described above applies to it in full: a payment name, a wallet name, a website or an agent identity can exist under the variant exactly as under the exact string.
The variants a brand team should recognize fall into a few families:
- Plurals and possessive forms, such as `.yourbrands`
- Hyphenated forms, such as `.your-brand`
- The brand with a corporate word attached: group, global, official, corp
- Single-character misspellings and common typing errors
- The name of the parent or group entity where it differs from the operating brand
- Product and division names that customers know as well as the house brand
Not every variant deserves the same attention. Rank them by how likely a customer is to accept the string as yours without a second look. The group name and the plural usually come first, because customers already see them in your own communications. Distant misspellings come last. A short, ranked list that is actually reviewed is worth more than a long one that is not.
The free [Trademark Name Check](/trademark-tlds#check) is the form on this site for checking a mark against onchain TLDs, and the page that holds it explains what a trademark TLD is.
## The five vectors ranked by exposure and visibility
The table compares the vectors on the same criteria: who is exposed, how visible the name is to that person in a normal interaction, and what software has to be present for the use to reach them.
| Vector | Who is exposed | Visibility of the name | Software required |
| --- | --- | --- | --- |
| Payment name | Payers sending funds | High: shown at confirmation | Supporting wallet or payment tool |
| Wallet name | Customers sending onchain | Medium: shown where it resolves | Wallet with resolution |
| Website on a name | Visitors following a link | High: shown in the address bar | Supporting browser or extension |
| Agent identity | Counterparties of an agent | Medium: shown in the agent's identity | Platform that reads agent identities |
| Lookalike TLD | Anyone exposed to the above | Depends on the use | Same as the use concerned |
The last column is a variable, not a reassurance. Software support for onchain names changes in both directions, and the reach of a name under any onchain TLD changes with it. An assessment of exposure is therefore valid for the coverage it was made against, and it should be dated and revisited.
### Judging which vectors matter for your organization
Three questions sort the vectors for a given brand. The first is whether your customers pay you, or expect to be paid by you, onchain. If they do, the payment and wallet vectors come first, because the loss is direct and a confirmed transfer is hard to reverse. If they do not, those vectors are largely theoretical for your customer base.
The second is whether your customers take instructions under your name: account notices, support requests, changes of payment details. If so, the website vector matters even where no payment is involved, because the cost is a customer who acted on a message they believed came from you.
The third is how much of your customer base uses software that resolves onchain names. For a consumer brand with a mainstream audience, the answer is often very little, and a light routine is proportionate. For an exchange, a fintech, a game publisher or any organization whose customers hold wallets as a matter of course, the answer is different, and the routine below should be run in full.
## What to monitor and how often
Monitoring onchain names is not the same as monitoring DNS registrations. The registry is onchain, software support changes independently of the registry, and a name can be issued and put to use without any notice reaching you. A practical routine has six parts.
A repeatable monitoring routine for onchain brand exposure
Set the baselineList your primary mark, your product names, your group entity name and the ranked lookalikes. For each string, note whether a matching onchain TLD exists and keep a copy of its public registry record.
Fix a review cadenceCompare the baseline with the registry at a set interval: weekly where customers routinely pay onchain, monthly where onchain payments are a small share of activity. Write the interval down and name an owner.
Watch for names, not only TLDsA TLD with no names under it can have names issued at any time. Check whether names are being issued under each TLD on your list and, where a name resolves, what it resolves to.
Review software coverageEach quarter, review which wallets and browsers resolve onchain names. A name that could not reach your customers at the last review may reach them at the next, and the reverse.
Record every findingEach name, each resolved address and each capture goes into a dated log before anyone acts on it. Your counsel will need that record if a dispute follows.
Triage by activityA name that resolves to an active address, opens a live page or appears in a payment request is a higher priority than a name that exists with nothing configured. Rank by use, not by existence.
The routine is light for most organizations: once the baseline exists, a review is a comparison, not a new investigation. Teams that prefer not to run it in-house can use [Namespace Watch](/namespace-watch), the service of the desk for monitoring the names of a brand onchain.
Monitoring also has an internal side. Tell the teams who hear from customers first, such as support, finance and security operations, what an onchain name looks like and where to send a report. A customer's question about an unfamiliar payment name is often the earliest signal you will get.
## Response options once something appears
Finding a name is not the same as having a clear path to its removal. The options depend on what the name is doing, who holds the TLD, and which platform displays it. No single route applies in every case, and the right sequence is a question for your legal team. What follows describes the options and is not a recommendation.
### Contact the platform
If the name is displayed in a specific wallet, payment tool or marketplace, that platform may have a policy for names that conflict with trademark rights. Do not assume the DNS procedure applies. The UDRP is the dispute policy that registrants of names in ICANN's generic TLDs accept through their registration agreements. Onchain registries operate outside the ICANN DNS root and are not bound by it, so each registry or platform has its own process, or none. Read the published terms of the registry and the platform before assuming a removal route exists, and expect that a platform can at most stop displaying a name in its own product.
### Approach the holder of the TLD
If the holder of the TLD is willing to talk, it may be possible to acquire the TLD or to reach an agreement about the names under it. This route can be quieter than a formal dispute, and it addresses the source of the exposure instead of a single name. The tone of the approach matters: a holder who has done nothing improper will respond better to a commercial proposal than to an accusation, and an approach that reveals too much can affect the price. A brand that would rather not make that approach itself can mandate Hush Partners, which acts for organizations to find and approach a holder. A standard mutual NDA then covers every exchange, and the closing goes through onchain escrow on an aftermarket. The page on [buy-side acquisition](/buy-side-acquisition) describes that service.
### Take legal advice
Trademark law does not stop at the edge of the DNS, but the practical enforcement path depends on the country, the registry's terms, and whether the use amounts to infringement or a related claim in your markets. The rules vary by jurisdiction and the analysis turns on the facts. This article is information and not legal advice. Your own counsel decides.
These options are not exclusive. A common sequence is to document, take advice, and then choose between the platform and the holder according to what the name is being used for.
## What holding the TLD changes
Every vector above assumes the brand does not hold its own onchain TLD. When your organization holds `.yourbrand`, it decides which names exist beneath it and what they resolve to. The payment names, wallet names, websites and agent identities under the exact string become yours to issue, and your communications can point customers to them as official.
Holding the TLD does not remove all exposure. Lookalike TLDs remain separate namespaces, and customers can still be misled by channels that have nothing to do with naming. It also brings work of its own: a namespace that your organization holds has to be governed, with a decision on who may issue names and a record of which names are official.
Whether acquisition is proportionate depends on the judgment made earlier about which vectors matter for you. For some organizations, monitoring and clear customer communication are enough. For those that conclude the matching TLD should be in their own hands, [brand namespace recovery](/brand-namespace-recovery) is the service of the desk for acquiring the onchain TLD that matches a brand.
The concrete next step is small. Write the list from the first step of the routine: your primary mark, your group name, your main product names and the two or three lookalikes a customer would most readily accept. Check each against the registry, date the result, and decide with your counsel which of the five vectors applies to your customers. That single page is the basis for everything else.
## Questions people ask
### Does holding a trademark give automatic rights over the matching onchain TLD?
No. A trademark protects a mark in the countries where it is registered or recognized, for the goods and services it covers. It does not make its owner the holder of a matching onchain TLD, because onchain registries operate outside the ICANN DNS and its policies. A trademark carries weight in a negotiation or a dispute, but it is not a title to the name. Your counsel can advise on the remedies available where you operate.
### Can a customer tell whether an onchain name was issued by the brand or by someone else?
Not from the name. `pay.yourbrand` carries no indication of who issued it. The address it resolves to is visible in the wallet, but few payers compare an address against an official reference. This is why publishing your official payment destinations, and telling customers where to find them, is the most useful control available to an organization that does not hold the TLD.
### How does an onchain TLD differ from a dotBrand in the ICANN DNS?
A dotBrand is a TLD that an organization applies for in an ICANN application round and operates under an agreement with ICANN. It sits in the ICANN DNS root and opens in every browser. An onchain TLD sits outside the ICANN DNS, is not subject to ICANN policy, and does not open in an ordinary browser without support. For reach among ordinary internet users, the DNS is simply better. The two are not substitutes, and an organization can hold both.
### What if the holder of the TLD cannot be identified?
The registry record is public and shows the wallet that holds the TLD token, but a wallet address is not a name or a contact. An organization in that position can keep monitoring, raise specific uses with the platforms that display them, and take advice on its legal options. It can also mandate an intermediary to find and approach the holder on its behalf, with every exchange covered by a mutual NDA.