Acquiring

Due diligence before you acquire an onchain TLD

What to verify before committing: the record, what has been issued under the TLD, its history, the transfer path and your own readiness to hold it.

Due diligence before you acquire an onchain TLD

Acquiring an onchain top-level domain is unlike acquiring most digital assets because the chain of title is public from the moment the token was created. Every transfer and the wallet address of the current holder are written to a public ledger and readable by anyone. That transparency removes one traditional diligence problem, proving who owns what, but it creates a different one: the record shows you the skeleton of the asset, not its full history of commitments, disputes or obligations.

This article is structured as a diligence memo. It walks through each check in the order a careful adviser would perform it, and it flags which findings are fatal to a transaction, which can be negotiated around, and which are noise. By the end you will have a framework you can hand to a client or use to brief a counterpart, with the questions to ask before any terms are agreed.

The scope is the acquisition of an onchain TLD on the Freename registry. The principles apply, with adjustments, to TLDs on other onchain registries. Nothing here is legal or tax advice; your own counsel decides how the findings translate into terms and structure.

One tokenrecords a Freename TLD onchain: the wallet that holds it is the ownership record
No renewal feeon a Freename TLD: there is no annual payment to keep it
Up to halfof each registration fee for names under the TLD is the advertised share of the holder in Freename's royalty program, subject to current terms and activation conditions

Freename's registry terms and its published description of the royalty program.

Why the public record changes diligence

With a traditional domain name, confirming ownership usually means relying on records kept by a registrar, which are largely private. With an onchain TLD, the registry writes the token to a public blockchain, a shared ledger kept by many independent computers, where past entries cannot be quietly rewritten. Anyone can read the wallet address of the current holder and the full transfer history without asking the seller for anything.

This has a practical consequence: most of what you need to verify is available before you approach the holder, before an NDA is signed, and before any terms are floated. You can complete the factual record checks independently. What the record cannot tell you (side agreements, promises made to third parties, disputes conducted in correspondence) is precisely where your representations and warranties must work hardest.

The public record also makes inaccurate accounts easy to catch. A holder who says the TLD has never been transferred can be checked immediately. A holder who describes the namespace as unused can be tested against the names that have been issued. Diligence is therefore faster here than in most private-asset acquisitions, but it is not complete without the layer that sits outside the record, described later in this article.

It also changes the order of work. In most acquisitions the buyer’s team waits for a data room and reads what the seller chooses to put in it. Here the first pass belongs to you, and the seller’s disclosure is read against facts you already hold. That is a stronger position, provided you resist the temptation to treat a clean record as a clean asset.

For advisers who want to see how an onchain TLD differs from a top-level domain delegated by ICANN before they begin, the comparison of a dotBrand and an onchain TLD sets out the structural differences in a single reference.

The TLD itself: string, registry and token

Start with the asset you are actually buying. An onchain TLD has three components that must each be verified and must all be consistent with each other.

The string. The string is the label that appears after the dot: .yourbrand, for example. Confirm the exact spelling, how the registry treats upper and lower case, how the string is encoded if it contains characters outside the basic Latin alphabet, and whether any visually similar strings exist on the same registry. Two strings that look identical on screen can be encoded differently and correspond to two different tokens. Verify the string at the registry level, not from a screenshot or a sales description.

The registry. Identify which registry issued the TLD and on which blockchain the token is recorded. The registry determines the rules that govern transfers, the issuing of names and the royalty program, so its current terms are a diligence document in their own right. If you are told that the token has ever been moved from one blockchain to another, confirm with the registry which token is the authoritative one. A token the registry no longer recognizes is not title.

The token. Confirm the address of the token contract (the smart contract, a program stored on the blockchain, that keeps the registry’s tokens), the identifier of the token within it, and the wallet address of the current holder. These three facts together constitute the ownership record. They are readable on a block explorer, a public website that displays the contents of a blockchain, without any cooperation from the seller. Compare what the registry itself shows for the TLD with what the block explorer shows. If they differ, treat the discrepancy as a priority finding before proceeding.

Finally, settle the vocabulary before you draft. Terms such as “resolver” and “activation” have precise meanings that affect what you are acquiring, and the glossary defines the terms used on this site.

Names issued under the TLD: number, nature and reliance

A TLD is not just a string. It is a namespace: the set of all names that have been, or could be, issued under it. On Freename, only the holder of a TLD can issue names under it, so the number and character of the names that exist reflect the holder’s own decisions, including those taken at the request of an operator it works with: the registry has no delegated management to another address, so every name was issued from the holder’s wallet.

Establish which names have been issued under the TLD, from the public record and, where the record is not enough, from the registry and the seller. Note:

  • Volume. How many names have been issued? A TLD with several hundred names carries a larger reliance footprint than one under which nothing has been issued.
  • Nature. Are the names generic labels held by the seller, or do they appear to have been issued to identifiable users for payments, wallets or websites? A name used to receive payments, for example pay.yourbrand pointing to a wallet address, may represent a real financial dependency for the person who uses it.
  • Active resolution. Does any name resolve, meaning that it points to a wallet address, to content on IPFS (a distributed file storage network) or to a website? Resolution indicates active use, which in turn means third parties may be relying on continuity. An acquirer who disrupts active resolution creates reputational exposure and, in some jurisdictions, potential legal exposure.
  • Who issued them. If the TLD has been run as a namespace by a third party under a commercial arrangement, that operator may have made commitments to the users of those names that do not appear onchain. This is covered in the section on what the record cannot show.

A worked example. Assume a TLD under which 200 names have been issued, of which 40 resolve to wallet addresses and 10 point to websites published on IPFS. Assume further that 100 new names are registered under it each year, that the registration fee is USD 20 per name, and that the holder’s royalty share is at the advertised ceiling of half. Registration fees then total USD 2,000 a year, and the holder’s share is USD 1,000 a year. Against that, the 40 and the 10 make 50 names in active use, each a potential reliance relationship. On these assumptions the income is modest, and the reputational cost of disrupting 50 active users is out of proportion to it. The numbers are illustrative only, and the royalty share depends on the registry’s current terms and activation conditions. They also leave out the annual cost of taking part in the royalty program, which the registry sets and which must be deducted from the holder’s share. One item for the diligence list follows from this: some TLDs carry earlier registration terms in which the program is included for life, and the registry should confirm, before closing, whether those terms pass to a buyer.

The conclusion to draw is about attention, not price: in a lightly used namespace, the names already in use deserve more diligence time than the income they produce would suggest. To put your own assumptions on volume and fees in front of the client, the free Subname Revenue Calculator on the Hush Partners site estimates revenue from names issued under a TLD.

History: transfers and what an unusual pattern means

The transfer history of a TLD token is public. Read it in full before agreeing to terms. You are not looking for complexity as such, since assets change hands legitimately, but for patterns that call for an explanation.

Clean history. A token that was created once and then moved once or twice, between wallets of the same legal entity or in a straightforward arm’s-length sale, is the simplest pattern to read.

Rapid cycling. A token that has moved between several wallets in a short period, particularly if the movements became more frequent toward the end of the history, may indicate a dispute being settled privately, a reorganization of the holder’s wallets, or a holder whose legal ownership is less settled than the record suggests. None of these is automatically fatal, but each requires explanation.

Dormancy followed by sudden activity. A TLD that sat unused for an extended period and then suddenly acquired names or changed hands warrants a question about what triggered the change. If the answer involves a third party who funded or carried out the activation, that third party may assert an interest in the asset.

Wallet concentration. If the wallet of the current holder also holds a large number of other TLD tokens, you are probably dealing with an experienced holder or an operator. That is not a problem, but it changes the negotiation: the holder is likely to have its own standard representations and a process. It also means the holder has a public record of how it manages its other TLDs, which you should read.

Discrepancies with the seller’s account. If the seller’s description of the history does not match the blockchain record on any material point, treat that as a serious finding. The record is the authoritative source for what happened to the token.

One caution on reading history: a transfer on the record shows that the token moved, not why. A sale, a gift, an internal reorganization and a change of custody arrangement can all look the same. Record each movement, ask the seller to explain each one in writing, and attach the explanation to the representations rather than relying on your own inference.

What the record cannot show

The blockchain record is authoritative about where the token is and how it got there. It says nothing about the following.

Side agreements with operators. A holder may have contracted with a third party to run the TLD as a commercial namespace: selling names, marketing the TLD, looking after resolution. That agreement may grant the operator rights that are drafted to survive a transfer of the token, such as a right to continue operating, a right to a share of royalties, or a right of first refusal on a sale. None of this appears onchain, because the registry lets only the holder manage a TLD: an operator works through the holder, under a contract, and never from an address of its own.

Promises to users of names. The holder or the operator may have made statements to individual users about continuity of service, pricing or resolution. In some jurisdictions, such statements may give rise to contractual or consumer protection claims even if they were informal.

Disputes and letters before action. A trademark owner may have written to the holder asserting that the string conflicts with its mark. That correspondence exists only in the parties’ files. An acquirer who takes the token without asking the question may inherit the exposure. The position is different where the string matches your own client’s mark: acquiring the TLD is then the purpose of the file, which is the subject of brand namespace recovery.

Tax and regulatory position. Depending on the jurisdiction, the holder may have tax obligations arising from royalty income received before the sale. Whether and how those obligations affect the acquirer, the seller’s ability to close cleanly, or the structure of the transaction is a matter for your own counsel and tax adviser; this article notes the question only.

Intellectual property claims. A string that matches a trademark, a trade name or a personal name may attract claims under applicable law. Onchain TLDs sit outside the ICANN system, and the UDRP (the Uniform Domain-Name Dispute-Resolution Policy, which binds registrants of names in ICANN’s generic top-level domains through their registration agreements) does not reach them. Trademark law and related claims may still apply, depending on how the TLD is used and where. The rules vary by country. The page on trademark TLDs covers the subject and holds a free Trademark Name Check.

The practical tool for this layer is a written disclosure request, sent once the NDA is in place. Ask each question separately, ask for documents rather than summaries, and ask the seller to state expressly where there is nothing to disclose. A seller who answers “none” to a precise question has given you something a representation can be built on. A seller who declines to answer has given you a finding.

Representations to ask for in the terms

Having identified what the record cannot show, the representations in the acquisition agreement should address each gap directly. Generic asset-purchase representations are not sufficient. The following are the ones that matter for this kind of asset.

Title and authority. The seller is the sole legal and beneficial owner of the token and has full authority to transfer it. No third party holds any interest, security interest or option over the TLD.

Operator arrangements. There is no agreement in force under which any third party has the right to operate, manage or derive income from the TLD, other than as disclosed in writing before signing.

Commitments to users of names. No statement has been made to the users of names under the TLD, in writing or orally, that would bind the acquirer after transfer, including statements about pricing, continuity of service or resolution.

No pending disputes. No claim, demand, letter before action or dispute has been received or is pending in relation to the TLD, its string or any name issued under it.

Royalty status. The seller states whether the royalty program has been activated for the TLD, and confirms that no amounts are owed to the registry or to any third party in connection with it.

Registry standing. The TLD is in good standing under the registry’s current terms, and no notice of suspension, cancellation or breach has been received.

Tax. All taxes arising from the seller’s ownership and operation of the TLD up to closing have been or will be discharged by the seller.

These representations should be supported by indemnities and by a survival period that your counsel judges right for the jurisdiction and the risk profile of the transaction. They are only as good as the party giving them, so establish who the seller is as a legal person, and whether an indemnity against that person would be worth pursuing, before you rely on any of the above.

The transfer path and protecting each side at closing

An onchain transfer cannot be reversed once it is confirmed. That creates a plain closing risk: the party that moves first takes the loss if the other party defaults. Onchain escrow is the answer to it. The exchange of the token for the funds is carried out by a smart contract rather than on trust, so neither side has to perform first.

For a file handled through Hush Partners, closing runs through onchain escrow on an aftermarket: Freename’s by default, another marketplace such as OpenSea if the client prefers.

Escrow protects the exchange and nothing beyond it. If the seller’s representations prove false after closing, the token and the funds have already changed hands. The representations and indemnities are therefore the economic protection for everything escrow does not cover, not a second line behind it.

Practical points to settle before closing include:

  • Confirming with the registry, and against the public record, that nothing at the level of the token prevents its transfer.
  • Agreeing a specific closing date and time, because royalty income arising between signing and closing requires a clear cut-off rule.
  • Confirming the address of the receiving wallet in writing, through a channel separate from the transaction itself, to reduce the risk that a wrong address is used. A transfer to a wrong address is as irreversible as any other.
  • Confirming that the buyer’s wallet can hold the type of token the registry uses.

The desk’s own work at this stage is described on the page about escrow and transfer.

Your own side: who will hold the TLD and are they ready

Diligence runs in both directions. Before closing, the buyer’s team should confirm that the acquirer is operationally ready to hold and use the asset. A TLD whose token sits in a wallet that no one effectively controls is an asset at risk.

Wallet custody. The token will be held in a wallet. For an institutional acquirer, a multisignature wallet, one that requires approval from more than one key holder before a transaction is authorized, is a common approach. A wallet with a single key held by one employee creates a key-person risk that most general counsel will want addressed before the transfer is approved.

Working with the registry. Issuing names, activating the royalty program and managing resolution records are done by the holder, from the wallet that holds the token. Confirm with the registry what the new holder must set up to do these things, and whether it can be done before or immediately after closing. Delays here have a direct cost if the TLD is being acquired for active use.

Operational plan. What will the TLD do after the acquisition? A TLD acquired for brand protection, so that no third party can issue names under .yourbrand, has a different task list after the transfer than one acquired to run a live namespace for customers. Putting a TLD to work is a file of its own, covered under post-transfer activation, and the free Launch Roadmap tool on the site builds a launch roadmap for a newly acquired TLD.

Internal authorization. Confirm that whoever will sign the acquisition agreement and authorize the payment has the authority to do so under the acquirer’s own governance documents. For a corporate acquirer, this typically means a board resolution or a sign-off under delegated authority. The amount involved and any continuing financial obligations, such as an operator arrangement the acquirer intends to keep, should be covered by that authorization.

Trademark alignment. If the string corresponds to a trademark held by the acquirer, the trademark registration and the TLD should be held in a way that is consistent with the acquirer’s IP strategy. Whether that means the same entity holds both, or different group entities, is a question for your IP counsel.

Sorting findings: fatal, negotiable and noise

Not every finding from the checks above should block a transaction or change the price. The table below applies one framework to the findings you are most likely to meet.

Finding Category Consequence
Token not held by the party offering to sell Fatal Stop; only the actual holder can transfer
String matches a third party’s registered trademark Fatal until cleared Counsel assesses the exposure before any transfer
Operator agreement drafted to survive a transfer Fatal unless waived Written waiver from the operator before closing
Record and seller’s account do not match Fatal until explained Pause until reconciled
Names in active use by third parties, no operator agreement Negotiable Buyer assumes reliance risk; price and indemnity adjust
Royalty program activated, cut-off not agreed Negotiable Insert a clear cut-off in the terms
Rapid cycling of the token between wallets Negotiable Explanation and representation; longer survival period
No names issued and no active resolution Noise Clean starting position; standard representations
Seller’s wallet also holds other TLDs Noise Indicates an experienced holder; no effect on title
Seller holds the TLD in a single-key wallet Noise for the buyer Buyer sets its own custody before receiving

The table is a starting framework. Your own counsel applies it to the facts of the transaction and to the jurisdiction. Two rules of thumb help when a finding does not fit a row. A finding is fatal when it goes to whether the seller can deliver the asset free of someone else’s rights. It is negotiable when it can be priced, disclosed or covered by an indemnity that is worth something.

Set out in order, the checks run as follows.

Order of checks for an onchain TLD acquisition
  1. Verify the tokenConfirm the token contract, the token identifier and the wallet of the current holder on a block explorer. Compare with what the registry shows for the TLD. Any discrepancy is a priority finding.
  2. Read the transfer historyRead the full onchain transfer history. Flag rapid cycling, long dormancy followed by sudden activity, and every movement the seller has not explained.
  3. Review the namespaceEstablish which names have been issued under the TLD, how many resolve, to what (wallet addresses, IPFS content, websites), and whether any appear to serve identifiable third parties.
  4. Check for trademark conflictSearch the relevant trademark registers for the string. Note any live registrations in jurisdictions where the acquirer or the TLD will operate. The free Trademark Name Check gives a quick first read.
  5. Request written disclosureAsk the seller in writing to disclose all operator agreements, commitments to users of names, disputes, and regulatory or tax matters. The NDA should already be in place at this stage.
  6. Draft targeted representationsUsing the findings from steps one to five, draft representations and indemnities that address each identified gap.
  7. Confirm buyer readinessVerify the buyer's custody structure, its readiness to work with the registry, and its internal authorization before agreeing a closing date.
  8. Close through escrowConfirm the receiving wallet address through a separate channel, then close through the agreed onchain escrow.

Your next step: fix the scope of the file

If you are at the beginning of a file, whether you represent a potential acquirer or have been asked to advise on a TLD that has been offered to your client, the most useful immediate step is to establish a clear scope. Is the TLD already identified, or does the work include finding and approaching a holder? Is the holder known to be willing, or does first contact need careful handling so that it reads as an inquiry and not as pressure?

Then run the first three checks yourself. They need nothing from the seller, they take little time, and they tell you whether the file deserves the cost of the remaining five.

Hush Partners is a private desk for onchain TLDs. It acts for holders who want a buyer, and for organizations that mandate it to find and approach a holder; the second kind of file is described under buy-side acquisition. There is also a page for lawyers and advisers who refer a file. Whether the file arrives from an acquirer or from its adviser, a single named partner follows it from first note to closing, with a standard mutual NDA covering every exchange.

If your client’s situation does not fit a clean pattern (a holder whose title is contested, a complex operator arrangement, a namespace in wide use), describe it through the contact form, which is the only way to reach the desk.

Questions people ask

What happens to royalty income arising between signing and closing?

This is a negotiating point, not a fixed rule. A workable approach is to agree a cut-off date and time: income arising before that point belongs to the seller, income arising after it belongs to the buyer. How and when the registry pays out is set by its current terms, and may not line up exactly with the contractual cut-off. Any gap should be addressed in the terms, with a simple settlement mechanism between the parties, to avoid a dispute after closing.

Can a TLD token be encumbered?

Not in the way a registered asset can carry a registered charge, as a general matter, but a token can be subject to rights that restrict what the holder may do with it. Some arise by contract, such as an option or a pledge agreed with a lender, and are invisible onchain. Others may arise from the way the token is held, for example in a wallet whose transactions require the approval of someone other than the seller. Ask about both, cover both in the title representation, and confirm before closing that the seller is in fact able to initiate the transfer.

What if the holder cannot be identified or does not respond?

This arises when an organization finds that the TLD matching its brand is recorded in a wallet whose holder it does not know. The public record shows the wallet address but not the legal identity behind it. An approach through an intermediary is often easier for both sides: the holder can respond to a neutral party without committing to anything, and the approach can be framed so that it carries no impression of pressure. Hush Partners never names the seller of a given TLD, so the same discretion applies in the other direction.

Is a Freename TLD the same asset as an ICANN dotBrand?

No. An ICANN dotBrand is a top-level domain delegated in the global Domain Name System under an agreement with ICANN, and it resolves in every ordinary browser. An onchain name resolves outside the ICANN DNS root, in the wallets, browsers and applications that support it. That coverage is partial and changes. The two assets serve different purposes, sit under different rules, and are not interchangeable.

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.