# How to audit your brand's onchain namespace
> A working method for legal and brand teams: list the names, read the registry, classify what you find and decide what to do.
Source: https://hush.partners/onchain-namespace-audit
Category: Brand protection
Published by Hush Partners.
---
Many organizations learn about their onchain exposure by accident: a colleague notices a name in a wallet that looks like the company's, or a counterparty asks whether a TLD matching the brand was intentional. The audit described here replaces that accident with a method. It is not a large project. It can be completed in a few working sessions by a single person in a legal or brand protection team, and it ends with a document that decision-makers can read in a few minutes.
After reading this, you will be able to define the scope of your audit, gather the right inputs, read what a registry record actually tells you, look beneath each TLD at the names already issued under it, classify each finding by exposure, decide per name whether to acquire, watch, ignore or escalate, and produce a two-page memo with an accompanying register. The last part of the method covers how often to repeat the audit and who should own it.
One clarification before the method starts. An onchain TLD exists outside the ICANN Domain Name System. It is recorded on a blockchain as a token held in a wallet, and it is not delegated in the DNS root. The UDRP, the dispute policy that applies to domain names registered through ICANN-accredited registrars, therefore does not bind a registry that operates outside the ICANN DNS. Your organization's remedies differ, and the audit needs to reflect that. The [glossary](/glossary) defines the terms used throughout this article.
## Defining the scope before you start
An audit without a defined scope produces an unmanageable list. Before you open a single registry record, write down three boundaries.
**Which names are in scope.** Start with the organization's primary brand: the name it trades under in its most important markets. Add the legal entity name if it differs. Add any product or sub-brand names that carry independent trademark registrations or that are subject to pending applications. Omit internal project codenames, retired brands, and names the organization has already decided to abandon, unless a specific risk flag has been raised against one of them. The list should be short enough to handle carefully. It does not need to be exhaustive.
For each name, decide in advance which variants you will check. A reasonable rule is the exact string, the abbreviation the organization itself uses in public, and the spelling without spaces or hyphens for a mark made of two words. Write the rule down. Without it, the list of variants grows every time someone has an idea, and two auditors working from the same portfolio produce two different lists.
**Which registries are in scope.** Not every onchain namespace uses the same technical infrastructure, and each registry keeps its own records. For a first audit, focus on the registries where a name matching yours would be most visible to the people you deal with. Freename is a sensible starting point because it issues TLDs and records them onchain: the record is public and anyone can check it on a block explorer, without relying on a third party. Other namespaces, on other registries or other chains, can be added in later audit cycles once you have established a baseline. Document which registries you checked and which you did not. That documentation becomes part of the deliverable.
**What is deliberately excluded.** Traditional domain names in the ICANN DNS, under generic or country-code TLDs, are not in scope here. That monitoring belongs to the organization's domain program, which has its own tools and its own remedies. Social media handles are also out of scope, because they follow the rules of each platform. Keep the onchain audit as a separate workstream with its own register, so that a finding in one system is never read with the assumptions of another.
## Gathering the four inputs
The audit draws on four sources. Collect them before you start checking registries.
**The trademark portfolio.** Pull the live registration and application records for all marks you consider in scope. For each mark you want the exact textual string, the jurisdictions in which it is registered or applied for, the registration or filing date, and the classes of goods and services. The dates matter because they establish priority and affect any future dispute. The classes matter because the uses of an onchain TLD ([payments to a name](/onchain-tld-payments), website publication, wallet resolution) may or may not map to the classes in your registrations.
**The corporate structure.** A holding company, an operating subsidiary, and a regional entity may each carry rights to different marks. The audit should note which entity holds which right, because the entity that would need to act on a finding may not be the entity that commissioned the audit. This also surfaces sister-brand names that belong to affiliates and might be omitted from a list built from trademarks alone.
**Product and service names.** List the names attached to products, services, or platforms that are in active use but may not yet have standalone trademark registrations. In many countries an unregistered name can still be protected by unfair competition or similar rules, but the conditions and the remedies vary from one country to the next. Flag these names separately so that decision-makers can evaluate the risk honestly.
**The markets served.** Onchain names resolve outside the ICANN DNS, so an ordinary browser does not open them without support. Resolution is partial: Freename names are supported in Bitcoin.com Wallet, in MetaMask through Freename's resolver, and in desktop browsers through the Freename Web3 extension. Coverage is incomplete and changes as wallets and browsers add or drop support. The markets most relevant to the audit are those where your customers or counterparties use wallets and are therefore most likely to meet a name that looks like yours. This context shapes how you classify findings later.
## Reading a registry record
When you look up a TLD or a name on a registry, you see a public record. Understanding what that record does and does not tell you is central to the audit.
What you are reading, for a Freename TLD, is the onchain record of a token that sits in a wallet. A block explorer, a website that displays the contents of a public blockchain, shows that record to anyone: the token, the address of the wallet that holds it, and the history of its transfers from one address to another. That is the extent of what the record discloses about ownership.
**What the record tells you.** That the TLD exists is a fact. The address that holds it is a fact. A transfer between addresses, and when it took place, is a fact. Together with what you find beneath the TLD, these facts are sufficient to classify the finding and decide on a response.
**What the record does not tell you.** The record does not tell you who the person or organization behind the wallet is, where they are established, or why they hold the TLD. It does not tell you whether the TLD resolves in any environment your customers use, or whether the holder had ever heard of your brand. A word that is your trademark may be an ordinary word, a surname or a place name to someone else. Inferring intent from a record alone is unreliable and risks mischaracterizing a finding, so the register describes what was observed and leaves the interpretation to counsel.
**Why issuance matters.** If names have been issued under a TLD that matches your brand, for example `pay.yourbrand`, the exposure is materially different from that of a dormant TLD sitting unused in a wallet. Issued names are names that may resolve in some environments. The page on [what is live](/whats-live) documents which capabilities of onchain TLDs work, with sources. Consult it to assess whether a given configuration can actually be reached by the people you care about.
One practical point: record the date of every lookup. A registry record shows the state of a name at the moment you read it, and a token can move to another wallet the next day. A finding without a date cannot be compared with the next audit.
## Looking beneath the TLD at issued names and their uses
A TLD in isolation is a potential exposure. A TLD with names issued under it is an active namespace. The second layer of the audit examines what has been built beneath each TLD that matches your brand.
For the auditor, the useful rule is that Freename lets nobody but the holder of a TLD issue names under that TLD. If names exist under a matching TLD, they exist because the holder issued them or allowed them to be issued. That tells you the holder is engaged with the namespace and is doing more than keeping a token in a wallet. It still does not tell you why.
Record each issued name you find: the full name, what the name appears to be configured for if the record shows it, and whether there is any public evidence of it being used to receive payments, publish content, or identify an entity. Be precise about what is observed and what is inferred. A name that points to a wallet address means something different from a name that has never been pointed at anything.
Consider the combination. A TLD matching a core brand, with names under it that mirror the organization's own product structure, presents a very different picture from a single idle TLD with no issuance. The combination affects both the classification and the priority of a response. A set of names that corresponds to nothing in your business, such as first names or words from an unrelated sector, points the other way: the holder may be running a namespace for a community that has no connection with you.
Note also the inverse. If your organization already holds a TLD that matches its brand, this part of the audit applies to the names you have issued yourself. Check that each name is documented and that it corresponds to a product or service that still exists. Check who can act for the wallet that holds the TLD. A token in a wallet controlled by one employee is a custody risk in itself; a multisignature wallet, which requires several approvals before anything moves, is the usual answer for an asset of this kind. A namespace audit is not only about what others hold.
## Classifying each finding by exposure
Once you have a complete list of findings, assign each one a classification before making any decision. A consistent classification prevents overreaction to minor findings and underreaction to serious ones.
The table below gives a grid of four tiers. Apply it to each TLD or name on your list independently.
| Tier | Criteria | Typical characteristics |
| --- | --- | --- |
| Critical | Exact match to a primary mark; names issued; apparent commercial use | Identical TLD, names under it pointing at payments or content |
| Elevated | Exact or close match; TLD held; no names issued | Identical TLD recorded, no names found under it |
| Moderate | Close variant (abbreviation, misspelling, product name); dormant | Near-match TLD, no issuance, little resolution coverage |
| Low | Generic string that coincides with part of a mark; no apparent commercial relevance | Common-word TLD that happens to match a descriptive element |
"Close match" includes phonetic equivalents, abbreviations the organization uses publicly, and combined marks where the dominant element appears as the TLD. It does not include every string that contains a common word. When you hesitate between two tiers, assign the higher one and let the decision step bring it back down.
The tier measures exposure, not fault. A Critical finding says that a name identical to your mark is in use in a way your customers could meet. It says nothing about whether the holder has done anything wrong, and the memo should keep the two questions apart. The first is a matter of observation and belongs to the audit. The second is a matter of law and belongs to counsel.
## Deciding per name: acquire, watch, ignore, escalate
Each finding in your register gets one of four dispositions. The disposition follows from the classification, the trademark position, and the organization's appetite for onchain activity.
**Acquire.** The organization decides it wants to hold the TLD. This suits Critical and Elevated findings where the trademark position is clear, the name has real value to the organization, and holding it is preferable to leaving the exposure in place. The decision to acquire is separate from the decision on how to approach the holder. An organization can make the approach itself, or it can mandate a desk to find and approach the holder on its behalf, which is what a [buy-side acquisition](/buy-side-acquisition) mandate is. Either way, the memo should state who is authorized to commit the organization and within what budget, before anyone writes to anyone.
**Watch.** No immediate action, but the name enters a monitoring list. This suits Elevated findings where the trademark position is contested or where the organization has not yet decided whether to be active onchain, and Moderate findings that are close enough to warrant observation. Define what you are watching for: names issued under the TLD, a transfer of the TLD to another wallet, a change in what a name points to. A [namespace watch](/namespace-watch) is the service that monitors the names of a brand onchain between audits.
**Ignore.** The finding is in the Low tier and does not meet any threshold for action. Document the rationale briefly, so that a future auditor understands that the name was reviewed and set aside, not overlooked.
**Escalate.** The finding cannot be resolved within the audit team's authority. This covers names where counsel needs to assess the trademark position before a disposition is assigned, situations where the apparent use is deceptive (a name configured to receive payments intended for your organization), and cases where the onchain finding connects to a wider enforcement matter. The escalation note in the register should be specific: what question needs to be answered, by whom, and by when.
A disposition is a decision, not a permanent state. A finding moved to "watch" can be reclassified at the next audit cycle if the holder begins issuing names or if the organization's onchain plans develop. Build that flexibility into the register by keeping the previous disposition visible next to the new one.
## The deliverable: a two-page memo and a register
The audit produces two documents: a short memo and a register. Together they should be quick to read for a senior decision-maker and defensible in front of outside counsel if the findings are later acted on.
### The memo
The memo is two pages. It does not repeat every detail in the register. It summarizes the position, explains the method, and states what decisions are needed. Suggested headings, with the content of each:
**Purpose and date of audit.** One paragraph. What was checked, which registries were queried, and the date of the last lookup. This anchors the document in time: the register is a snapshot, not a continuous record.
**Scope.** The list of names checked, the rule used for variants, and any names that were considered but excluded, with a brief reason for each exclusion. A reader who later asks why a name was not audited should find the answer here.
**Summary of findings.** The number of findings in each tier, and a single sentence characterizing the overall exposure. No wallet addresses or details of holders in the body of the memo. Those belong in the register.
**Decisions required.** A numbered list of the findings that require a decision above the audit team's authority. For each: the name, the classification, the proposed disposition, and the specific question or approval needed.
**Recommended next actions.** What the team proposes to do with the Watch and Acquire dispositions, a suggested timeline, and who is responsible for each.
**Method note.** A brief statement that the audit was conducted by reading public registry records, that it covered the registries named, and that it involved no contact with any holder. This matters if the document is ever disclosed.
### The register
The register is a spreadsheet or table with one row per finding. Minimum columns:
| Column | Content |
| --- | --- |
| Name | The TLD or name as it appears in the registry |
| Registry | Which registry was queried |
| Status | Recorded, not found, or names issued |
| Tier | Critical, Elevated, Moderate or Low |
| Trademark basis | The marks and jurisdictions that are relevant |
| Disposition | Acquire, Watch, Ignore or Escalate |
| Notes | What the record showed; any observable use |
| Lookup and review dates | When it was checked and when it is due again |
Keep the register plain and factual. Opinions and legal assessments belong in the memo or in separate advice from counsel, not in individual cells. Ask counsel how the two documents should be marked and circulated, since the rules on confidentiality and privilege vary by country.
## The procedure from scope to sign-off
The steps below give the complete method as a single ordered procedure.
Onchain namespace audit, step by step
Fix the scopeWrite down which brand names and variants are in scope, which registries will be checked, and what is explicitly excluded. Get agreement from the person who commissioned the audit before looking anything up.
Collect inputsPull the live trademark records, the corporate structure showing which entity holds each mark, the product names in active use, and a summary of the markets that matter.
Read each registryFor every name in scope, check the record on each registry in scope. Note the result, the holding address if the TLD exists, and the date of the lookup.
Look beneath each TLD foundList the names issued under it. Note each name, its apparent configuration, and any observable use.
Apply the classification gridAssign each finding one of the four tiers, using the criteria of the grid.
Assign a dispositionAcquire, Watch, Ignore or Escalate. Flag every disposition that needs an authority the audit team does not have.
Build the registerEnter every finding, including the names that were looked up and not found, so the next audit can confirm they are still absent.
Draft the memoWrite the two pages under the six headings, with the decisions required as a numbered list.
Obtain sign-off and fileCirculate the memo for the decisions required. File the memo and the register with a version date. The register is the baseline for the next cycle.
## What an exposure score adds to the memo
Before you finalize the memo, consider running the brand through the [Namespace Exposure Score](/namespace-exposure-score), a free tool that scores how exposed a brand is onchain. It does not replace the judgment in your register. Its use is in communication: a decision-maker who does not work with trademarks often reads a single score more easily than a table of tiers.
A score also gives you a point of comparison. When you repeat the audit, you can show whether exposure has increased, decreased or remained stable. That trend is often more useful to management than the level itself. Keep the score in the memo's summary of findings and keep the reasoning in the register, so that nobody mistakes the figure for a legal assessment.
## How often to repeat the audit and who owns it
A namespace audit is not a one-time exercise. New TLDs are created, existing TLDs change hands, and issuance under an existing TLD can start at any moment. A finding that was in the Low tier when the audit ran may be Elevated by the next cycle if the holder begins building under it.
**A reasonable cadence.** For most organizations, a full audit once a year is a sensible minimum. Organizations with a large trademark portfolio, with onchain operations of their own, or with Critical or Elevated findings in the first audit have reason to review twice a year. Between cycles, a watch covers changes as they happen. That is a monitoring function, not an audit, and it does not replace the yearly review of scope and inputs.
**Who owns it.** Assign a named owner, not a team. The owner schedules the audit, maintains the register between cycles, and escalates findings that change tier between formal reviews. In practice this is often a brand protection manager or an IP paralegal, with oversight from the general counsel or the head of brand protection. If the work is given to outside counsel, the internal owner remains responsible for the decisions. That part cannot be delegated.
**Version control.** Each audit cycle produces a new version of the register and a new memo. Retain prior versions. If a finding is later acted on, the history of when it was first detected and how it was classified may be relevant to what follows. Keep the files somewhere with access controls that reflect their sensitivity.
**Integration with the wider IP program.** The onchain audit should feed the organization's domain and trademark monitoring, and receive information from it. A new trademark application should trigger a check of the onchain namespace for that string before the application is filed. A product launch should trigger a check before the name is announced. Building those triggers into the IP calendar prevents the audit from operating in isolation.
**Where to go from the first memo.** If the audit ends with an Acquire disposition on a TLD that matches a primary mark, [brand namespace recovery](/brand-namespace-recovery) describes how Hush Partners handles that kind of file, and the page for [brands and legal teams](/brands-and-legal-teams) sets out how the desk works with general counsel and brand protection teams. Every exchange with the desk is covered by a standard mutual NDA, and the desk is reached through the contact form on the site. If the audit ends with nothing to acquire, the next step is simpler: file the register, set the review date, and put the owner's name on it.
## Questions people ask
### Does a trademark registration give my organization rights over a matching onchain TLD?
Not automatically, and not in the way it operates within the ICANN DNS. A trademark registration gives your organization rights under the law of the countries in which it is registered, and those rights may support a claim depending on the facts, but the procedural route is not a UDRP complaint. The audit's job is to document the trademark position accurately. Your own counsel assesses what remedies are available for a specific finding.
### Does holding the TLD give the holder any right to my mark?
No. Holding a token gives control of a namespace on one registry: the ability to issue names under that TLD there. It does not create a trademark, and it does not change the rights your organization holds in the DNS or anywhere else. The practical consequence runs the other way: on that registry, your organization cannot issue `pay.yourbrand` while someone else holds `.yourbrand`.
### What if no matching TLD is found?
Enter the name in the register as not found, with the date of the lookup and a review date. Whether the organization then wants to hold the TLD that matches its mark is a business decision for the memo, not a finding. The page on [trademark TLDs](/trademark-tlds) explains what a TLD that matches a brand is, and holds the free Trademark Name Check.
### Is auditing the TLD different from auditing the names issued under it?
Yes, and both matter. The TLD level tells you which address controls the namespace. The name level tells you whether that control is being exercised in ways that could affect your brand's reputation or your customers' experience. An audit that stops at the TLD misses the second layer, which is often the one with more consequences.
### How long does the first audit take?
For an organization with a focused portfolio (one primary brand, a few product names and a handful of subsidiary marks), a few working sessions cover the lookups, the register and the memo. It takes longer if the portfolio is large or if questions about the corporate structure need input from other functions. Later audits, run against an established baseline, are faster.