Building the evidence file when your name appears onchain

A paralegal or brand protection analyst who finds an onchain TLD that matches a protected brand faces a task that has no established playbook. The registry record is lasting, because it lives on a blockchain, but what sits beneath that TLD can change without notice and without leaving a conventional audit trail: the names issued under it, the wallet a name points to, the site a user might reach. By the time a lawyer needs the facts, the most useful evidence may already look different.

This article walks through how to build a file that a lawyer, a platform, a negotiator, or an internal decision-maker can use without redoing the work. It is organized around what to capture, why each item matters, and how to store what you collect. It is information, not legal advice. The standards that apply to evidence differ by country and by the route you eventually take, and your own counsel decides how the file is used.

The file described here is deliberately over-inclusive. At the moment of collection you do not yet know which facts will matter most. A negotiated acquisition, a platform complaint, a letter from counsel, and a formal dispute procedure each pull on different parts of the record. Capture everything once and let counsel sort it later.

Why you build the file before any decision is made

The temptation when you first spot a conflicting onchain TLD is to wait and see. If no action is planned, the time can look wasted. It is not, because the public record does not wait for you.

An onchain TLD on a registry such as Freename is recorded as a token held in a wallet. The creation of that token is a permanent event: it happened in a specific block, at a specific time, and that entry stays in the chain’s history. The data that hangs from the token is another matter. The names registered beneath it, the addresses those names point to, and any website content published at those names can all be changed by whoever controls them, and a change can be made quickly.

There is a second reason to start at once: establishing a timeline. In almost every route (negotiation, acquisition, or a formal dispute) the sequence of events matters. When did you first become aware? When was the TLD created relative to your earliest trademark filing? When did a particular name under the TLD first appear? These points are much easier to settle if you recorded dates as you went than if you reconstruct them months later from partial memory and scattered screenshots.

Building the file also forces a structured look at the exposure. You may discover that the situation is narrower than it first appeared, or considerably wider. Either finding changes what a proportionate response looks like. The free Namespace Exposure Score on this site scores how exposed a brand is onchain, and it is a useful first frame before you start collecting.

The public record: registry data and the block explorer

The starting point is the registry record itself. On Freename, every TLD is recorded onchain. The record is public, and anyone can check it on a block explorer, a read-only website that shows the transaction history of a token or a smart contract. The glossary defines the terms used in this section if any of them are new to you.

Capture the following from the record:

• The full TLD string.
• The wallet address that holds the token at the time of capture.
• The contract address and the chain (which blockchain the token lives on).
• The block number and timestamp of the transaction that created the token.
• The full transaction hash for that creation event.
• If the token has been transferred since it was created, the full history of those transfers, including the wallet addresses involved and the block timestamps.

For each of these items, save the raw data, not just a screenshot. Copy the transaction hash and the wallet address as text. A screenshot of a block explorer page is useful as a visual record, but a screenshot alone can be questioned. The raw hash can be checked independently by anyone with access to the same chain.

How to date a capture

Two dates attach to every item, and the file must keep them apart. The first is the date of the event: the block timestamp of a creation or a transfer. The second is the date of your capture: the moment you looked. The first comes from the chain and never changes. The second exists only if you record it.

The simplest method is to capture the whole screen, including the system clock, and to keep the original image file with its metadata untouched. Add a line to a capture log at the same moment: what was captured, when, how, and by whom. A log written at the time is far more convincing than one rebuilt afterwards, and it lets a colleague repeat your steps and reach the same result.

What the record does not show

The registry record will not tell you who controls the wallet in the sense of a legal person or an organization. It shows a wallet address. Connecting that address to a named party is a separate question, which may need legal process, and it is not part of the evidence file. Note the address precisely. Do not speculate in the file about who sits behind it.

Use beneath the TLD: names issued, sites and payment names

A TLD by itself may be inert. Its significance in a brand protection matter often comes from what has been issued beneath it and what those names do. On Freename, only the holder of a TLD can issue names under it, so every name you find there traces back to a decision by the holder.

Names issued under the TLD

Look up the names registered under the TLD. For each one, record:

• The full name string (for example, pay.yourbrand or login.yourbrand).
• The wallet address holding the name.
• The block timestamp of its registration.
• Whether the name points to a wallet address (used for payments), to content, or to nothing.

Pay particular attention to names that suggest a transactional function, such as pay.yourbrand, send.yourbrand or checkout.yourbrand. A name of this kind may be in use as a payment identifier, which makes the potential for customer confusion concrete and documentable. The page on payments to a name explains what such a name can do, which helps you describe it accurately.

Also note how many names have been issued. A TLD with no names beneath it is a different fact pattern from one with dozens of registrations. The count is evidence of activity, and it belongs in the file as a number with a date, not as an impression.

Website content

Registry data shows structure. You also need a record of function: what a person actually meets when they use a name under the TLD.

Because an onchain name resolves outside the ICANN DNS root, the ordinary browser on your desk will not open the site you want to capture unless support is added. Freename names can be reached in desktop browsers through the Freename Web3 extension, and they are supported in some wallets. Coverage is partial and changes, so state in the file which environment you used. If you can reach a site, capture the full page: a scrolling screenshot, the address as displayed, the page source if accessible, and the time. Do this for every name under the TLD that leads to content, not just the first one you find.

Note what the site shows. Does it use your organization’s name, logo, colors, or product descriptions? Does it present itself as affiliated with your organization? Does it ask visitors to connect a wallet or enter credentials? Each of these observations is a separate factual note in the file, not an inference. You are recording what is there, not arguing what it means.

Payment names

If a name points to a wallet address for payments, record the full address it points to, the chain, and the method you used to see it. A name that reads like your brand and routes funds to a wallet your organization does not control is a risk to customers that counsel will want described exactly. Do not send a test payment. That point is covered below.

How the name appears to a customer in a wallet or a browser

The preceding section captures the technical reality. This one captures the customer’s experience, which is a distinct point.

The file should let a reader see what a member of the public who met this name would have in front of them. That is not a legal conclusion. It is an observation about presentation, and you can document it without making the argument.

Some wallets display a name instead of a raw address on their send or receive screen. For this capture, the wallets that support Freename names are Bitcoin.com Wallet and, by way of Freename’s resolver, MetaMask. If you have access to a supported wallet, record how the name appears there, without sending anything. A screenshot showing pay.yourbrand on a send screen is a clear record of what a customer sees. Note the wallet application, its version, and the date.

Then capture the name on every other surface you can find:

• On any website reached through a supported browser or extension.
• On any marketplace page, forum post, or public communication that refers to the name (address and screenshot, with date).
• In any public profile that uses the name as an identifier.

For each capture, record the platform or context, the exact string displayed, the date, and what action a user would be prompted to take. The combination of a brand string and a transactional prompt, for example pay.yourbrand next to a “Send” button, tells counsel more than either element alone.

Where the name does not appear matters as well. If an ordinary browser returns nothing and only one environment displays the name, write that down. An honest record of limited reach helps counsel judge proportion, and it protects the credibility of the rest of the file.

A brand protection team knows which touchpoints carry the most risk for its own customers. Apply that knowledge here and start with the surfaces your customers actually use.

Your organization’s own rights: the registrations that matter

The file is incomplete without an equally disciplined record of your own position. The onchain name only matters to the extent that your organization holds rights it could affect. Document those rights with the same precision you apply to the external evidence.

Collect the following for each relevant right:

For trademark registrations, do not rely on memory or summaries. Pull the certificates or the official register extracts. In many countries these are available from the public database of the trademark office. The page on trademark TLDs explains what a trademark TLD is and holds the free Trademark Name Check.

Note the exact string registered. A word mark for YOURBRAND may cover different ground than a stylized version, and counsel will need to know which you hold. Also note any disclaimers or limitations in the registration, and how unregistered use is treated, which varies by country.

Record the goods and services with care. A trademark protects a sign for particular goods and services, in particular territories. A registration that covers financial services sits differently next to a payment name than one that covers clothing only. You are not asked to draw the conclusion. You are asked to put the two facts side by side so that counsel can.

The aim is to hand a lawyer a document from which they can assess the strength and scope of your position without going back to primary sources for the basics.

Building the chronology

A chronology is not the same as a collection of dated screenshots. It is a single document that places every relevant event on one timeline, in order, with a source reference for each entry. It is the item a lawyer or a decision-maker will reach for first.

The chronology should include at minimum:

• Your organization’s earliest relevant trademark filing date (or first use date, if earlier and documented).
• The date the conflicting TLD was created onchain, taken from the block timestamp and not from a date displayed by a website.
• The date each name under the TLD was registered.
• The date your organization first became aware of the TLD.
• The date of each evidence capture in the file.
• Any date on which what a name pointed to, or what a site showed, visibly changed.

Two intervals in the chronology deserve an explicit note. The first is the interval between your earliest filing or first use and the creation of the TLD. If your rights came first, that sequence matters. If the TLD came first, that is equally important to state, because it changes the analysis your counsel will need to do.

The second is the interval between the creation of the TLD and your first awareness. If the TLD had existed for some time, with names registered under it, before your team spotted it, the chronology makes that visible. It is not necessarily harmful to your position, but it is a fact your counsel should know.

Keep the chronology as a separate document within the file so it can be updated as new captures are made. Every entry should point to the underlying item in the file. Do not put inferences or arguments in the chronology. It is a record of facts and dates only.

Storing the file and limiting who sees it

An evidence file that is poorly stored creates its own problems. The concerns are integrity, confidentiality, and access.

Integrity

The file’s value depends on the credibility of its dates and the authenticity of its contents. Store captures in an environment where changes are logged. If your organization has a document management system with an audit trail, use it. In a simpler environment, as a minimum: put the capture date in each file name, never overwrite an original, and keep a log of what was added and when.

The blockchain data itself (transaction hashes, wallet addresses, block numbers) can be checked by anyone who looks it up on a block explorer. Your capture is useful for convenience and for recording the state at a point in time, but the underlying entries do not depend on your copy. Say so in the file. It means the core of your record can be confirmed without relying on you.

Confidentiality

In some legal systems, material prepared for a lawyer or at a lawyer’s direction may be protected from disclosure. Whether that applies to your file depends on how it was created and on the rules of your country, and your own counsel decides. What you can do is keep the factual record (captures, transaction data, chronology) clearly separate from any legal analysis or strategic notes. That separation makes it easier for counsel to decide what can be shared and what cannot.

Access

Limit who can see the file. The appropriate group is usually the person building the file, the supervising lawyer or general counsel, and whoever owns the brand protection function. Do not circulate the file widely, discuss it on general communication channels, or share it with outside parties before counsel has reviewed it. One person should be designated as owner of the file, responsible for versions and for logging access.

What not to do while documenting

Three actions can compromise the file and, potentially, your organization’s position.

Do not contact the holder. The holder’s wallet address is in the registry record, and a site or a marketplace page may show a way to reach them. Do not use it. Even a neutral inquiry tells the holder that your organization is interested, can have legal consequences that vary by country, and can make a later negotiation harder. Whether and how to make contact is a decision for counsel, made with a strategy behind it. An organization that prefers not to appear at all can mandate Hush Partners to find and approach the holder, and every exchange is covered by a standard mutual NDA. The rules the desk works by are published on the site.

Do not send a test payment. It may seem like a clean way to confirm that a payment name works. It is not. Funds leave your organization, the transaction stays visible on the chain, and your organization has then dealt with the very name it is documenting. Counsel, and later anyone who reviews the matter, will have to account for that transaction. Record the address the name points to. Do not confirm it by sending funds.

Do not publish or share what you have found. Posting about the finding in a public forum, or describing it in a widely circulated internal message, can alert the holder, can affect the terms of a possible acquisition, and can complicate a formal dispute. Keep the file and the findings within the circle described in the preceding section until counsel has reviewed them and a course of action has been decided.

The items in the file and the order to assemble them

The table below is a reference for what a complete file holds and what purpose each item serves.

The order of work matters as much as the contents. Start with what changes least and is easiest to verify, move to what can change at any moment, and finish with your own records, which will still be there tomorrow.

1. Record the registry entryOpen a block explorer for the relevant chain. Record the TLD token, the creation transaction hash, the block timestamp, the holder wallet address, and any transfer history. Save raw data, not screenshots alone.
2. List the names under the TLDFor each name, record the full string, the holder wallet, the registration timestamp, and whether the name points to a wallet address, to content, or to nothing.
3. Capture what each name leads toUsing a supported browser extension or wallet, screenshot every page reached, with the address, the environment used, and the time. For payment names, record the wallet address and chain without sending any payment.
4. Document the customer-facing presentationRecord how the names appear in wallets, on marketplace pages, in forums, or in any public communication. Note the platform, the exact string, and the action a user would be prompted to take.
5. Assemble your own rights recordPull certificates or official register extracts for every relevant trademark, domain name, and company name, with the exact string, dates, country, and goods or services.
6. Build the chronologyLay every event on a single timeline in date order, with the source for every entry.
7. Store and restrict accessPlace the complete file in a controlled location, send it to counsel for review, and name one owner responsible for versions and updates.

When the file is ready: the decisions it supports

The completed file does not make the decision for you. It means that every option in front of you (watch and wait, approach the holder, seek a formal remedy, acquire the TLD) can be weighed on facts and not on impressions.

For an organization considering an acquisition of the conflicting TLD, the chronology, the extent of use beneath the TLD, and the strength of its own rights all bear on whether acquisition makes sense and on what terms. Brand namespace recovery is the service through which the desk acquires the onchain TLD that matches a brand, and a file of this kind is a sound starting point for it.

An organization that wants the holder found and approached without appearing itself can do so through a buy-side acquisition mandate. A complete file means the mandate starts from documented facts.

If the decision is to wait, the file becomes a baseline. Namespace watch is the service that monitors the names of a brand onchain, and anything monitoring turns up is added to the file with the same discipline as the first capture.

What the file cannot do is replace legal advice on the merits. The route you take, the standards you will need to meet, and the risks of each option are questions for your counsel. The file’s job is to make sure counsel works from a complete and accurate record. The practical next step is simple: name the owner of the file, make the first dated capture of the registry record, and tell counsel that the file exists.

Questions people ask

Do I need to capture evidence again if nothing appears to have changed?

Yes, periodically. The creation of the TLD is fixed, but what a name points to can be updated by whoever controls it. A name that led nowhere at your last capture may lead to a site or a wallet address at the next one. Build a dated update into your schedule, even if the interval is quarterly. Each dated capture is an independent record, and a series of them shows consistency or change over time.

What if the TLD has no names under it and nothing resolves?

An inert TLD is still a fact worth documenting. Record the registry entry, the holder wallet, and the absence of registered names and of any content at the date of your capture. The absence of use bears on what response is proportionate, though it does not change the analysis of your rights, which is for counsel. Note the date of the capture precisely. If names are registered later, you will want the baseline.

Should the file reference the UDRP or any specific dispute procedure?

Not at the time of assembly. The file records facts and does not argue a case. The UDRP is the dispute policy that registrants of domain names in ICANN’s generic TLDs accept when they register, and onchain names sit outside the ICANN DNS root. Whether any dispute procedure applies to a given onchain registry depends on that registry’s own terms and on the country in which you would seek relief, and your counsel answers that. A procedure-neutral file is useful whichever route counsel recommends.

Can the file support a private negotiation as well as a formal complaint?

Yes. A private negotiation, whether conducted by counsel or through a mandated desk under NDA, moves faster when the organization’s position is documented, because nobody has to stop and establish the basic facts. If the negotiation ends without agreement and a formal route follows, nothing needs to be reconstructed.