Preparing an onchain TLD for sale

A TLD that looks attractive from the outside can stall or collapse in review because of something the holder never thought to address. The string is clean, the buyer is willing, and then the conversation turns to names already issued beneath it, or to a wallet controlled by someone who has since left the business, and the deal slows to a halt while everyone waits for answers.

This article walks through the review a serious buyer runs on an onchain TLD, in the order they typically run it, and pairs each stage with what a holder can do before a conversation starts. The goal is not to preempt every question but to arrive at the table with honest, organized answers rather than improvised ones. By the end, you will have a preparation sequence, a clear view of which problems can be resolved before sale and which must simply be disclosed, and a sense of when to start.

The same discipline that makes a TLD easy to sell also makes it easier to value. If you want a first read on where your TLD stands before you go further, the free TLD Readiness Score scores how ready a TLD is to be sold.

What a buyer looks at first: the string and the public record

The first thing a buyer looks at is the string itself: the characters that form the TLD, read in isolation. Before any financial conversation, a buyer will ask whether the string works as an identifier. Can it be said aloud and spelled without help? Does it correspond to a word, a category, a brand segment or an industry? A string that could serve several industries is more flexible than one that was coined for a purpose that no longer exists.

You cannot change the string, so preparation here is about describing it accurately. Write down what the string means, in which languages, and which kinds of organization could plausibly use it. If it has a second meaning that is unflattering or sensitive in a major language, say so yourself. A buyer’s team will find it anyway, and it is better that they find it in your file than in their own search.

The second check is trademark exposure. A TLD whose string is identical or confusingly similar to a trademark held by a third party carries a structural risk. That third party cannot force a transfer through the UDRP, the dispute policy that binds registrants of domain names in the ICANN system through their registration agreements, because that policy does not reach onchain TLDs. Trademark law may offer other routes, the rules vary by country, and the possibility of a claim cools a buyer’s interest whatever its legal merit. A buyer’s counsel will run a search. If you have not already run one, the free Trademark Name Check is a starting point, and your own counsel decides what the result means.

The third check is the public record. On Freename, a TLD exists as a token on a blockchain, and that token sits in a wallet. Anyone can read the record on a block explorer, a public tool that displays the history of a blockchain address or token. The buyer’s technical team will look at the token representing the TLD, note the wallet that holds it, and read the full transfer history. This part of the review takes minutes. What takes longer is interpreting what it shows.

One item is absent from this first pass, and it is worth understanding why. In the DNS, a buyer checks when a domain name expires and what it costs to keep each year. A Freename TLD carries no yearly renewal charge, so there is no expiry date to verify and no lapsed payment to worry about. The buyer’s attention moves instead to the three things the rest of this article covers: what has been issued under the TLD, how it reached its present wallet, and who can move it.

The namespace beneath the TLD: the main source of complications

A TLD is not just a string. On Freename, issuing names under a TLD, such as name.yoursector under .yoursector, is reserved to whoever holds that TLD. Once issued, those names are tokens in their own right, held in the wallets of whoever registered them. A sale of the TLD moves the TLD token and nothing else: the names already issued stay where they are.

This is the main source of complications in a TLD sale, and it deserves more attention than most sellers give it.

A buyer acquiring .yourbrand is acquiring the ability to issue new names and, under Freename’s royalty program, the holder’s share of the registration fee on names registered beneath the TLD. The registry advertises that share at up to half, and it depends on the registry’s terms in force and on its activation conditions. What the buyer does not acquire is the names already in other wallets. The names a third party has bought remain that party’s. The names you hold yourself under the TLD are a separate matter: they can pass to the buyer together with the TLD if you and the buyer agree on it, and the sale file should say which ones are concerned. A buyer should plan on the basis that those names continue to exist whoever holds the TLD, and should read the registry’s terms for anything that says otherwise.

The questions a buyer will ask about the namespace are systematic:

• How many names have been issued?
• To whom were they issued, and when?
• Were any issued at no charge, and if so under what arrangement?
• Are any names held in wallets connected to the seller’s own organization?
• Do any names correspond to other companies’ trademarks?

A namespace with no names issued is the simplest starting position for a buyer. Every name beneath the TLD is still available to be issued and managed by the incoming holder, and there is nobody else whose expectations have to be understood.

A namespace with names already issued requires more explanation. That is not a deal-stopper, but you should be ready with a clear account of every name: which wallet holds it, on what terms it was issued, and whether the person behind it expects anything about what the TLD will or will not do in the future. If names were issued to customers or community members with commitments attached, even informal ones, those commitments are part of the asset’s profile and must be disclosed.

Why issued names weigh so much in a review

The weight comes from the kind of buyer, not from the number of names. An organization that wants .yourbrand as its own namespace wants to be the only source of names under it. A name such as pay.yourbrand already sitting in an unknown wallet is, from that buyer’s point of view, a name its customers could mistake for an official one. A single name of that kind can matter more than a hundred names issued to a known community under clear terms.

A buyer who intends to run .yoursector as an open namespace reads the same list differently. Existing registrants can be evidence that people want names under the TLD. The same buyer will still ask whether the best names, the short and obvious ones, are already gone, because those are the names an operator expects to issue itself.

Names that correspond to well-known brands are the harder problem. They slow any buyer whose own customers or counsel will ask about them. You cannot undo them by yourself. You can document them accurately, explain how they came to be issued, and let the buyer assess the risk with full information.

Names held in wallets connected to you are the one part of the namespace you fully control. Decide before the review whether they go to the buyer with the TLD, stay with you, or are dealt with in some other way, and say which in the file. A buyer who finds them unaided will assume the worst reading.

Issue nothing while a sale is being considered

The reasoning behind the rule is about what the buyer is pricing. A buyer forms a view of the TLD from the namespace as it stands when the review starts. If the namespace changes during the review, the thing being priced has changed, and the buyer has to start that part of the work again. Because issuance is recorded onchain, the change will be seen.

There is also a question of good faith. Issuing an attractive name to yourself or to an associate while a buyer is studying the TLD looks like keeping the best part of the asset back. Issuing names to strangers looks like trying to show demand that was not there before. Neither reading may be true, but you will spend negotiation time arguing against both.

The rule has one honest exception. A holder who operates the TLD commercially may have standing commitments to issue names to customers. If that is your case, disclose it at the start of any buyer conversation, and agree with the buyer whether issuance continues during the process and on what terms. Continuing in the open, under an agreed rule, is very different from continuing unannounced.

If there is no operational reason to issue names, the TLD should be quiet from the moment sale becomes a possibility. A buyer who discovers that names were issued during negotiations, even to unrelated parties, will want to understand why, and that question seldom has a good answer.

Onchain history: what a simple transfer record is worth

Every transaction involving the TLD token is recorded and publicly readable. A buyer’s team will read the record in full. What they hope to see is simple: the TLD was created, it has been held by one wallet or very few, and it is now held by the wallet the seller controls. That is a clean history, and it requires no explanation.

A more complex history raises questions the buyer needs answered before proceeding: several transfers, short holding periods, a wallet that appears in the record but whose controller can no longer be identified. Each transfer is an event that calls for an explanation. Who held the TLD at that point, why did it move, and is there any remaining arrangement with a prior holder?

The value of a simple history is not cosmetic. The onchain record shows that a token moved. It does not show why, or on what terms. A transfer may have been a sale, a gift, a move between two wallets of the same person, a contribution to a company, or the settlement of a debt. Only the first few of these are harmless by default. A buyer cannot assume that prior holders have no claims or expectations, and can only be satisfied by what the seller says and can document.

This is why a simple history is worth something in a negotiation. It removes a whole category of review work, it shortens the time between interest and commitment, and it leaves fewer points on which the buyer’s counsel will ask for written assurances. A complicated history does not make a TLD unsellable. It makes the sale depend on the quality of your explanation.

Preparation therefore means writing a clear account of each transfer before the buyer asks, instead of reconstructing it under pressure during a review. For each one, note the date, the two wallets, the role of each party (a founder, a company, a previous holder) and the reason. Where you hold a document that supports the account, such as a purchase agreement or a company resolution, note that it exists. Where you do not know the reason for a transfer that happened before your time, write that down too. An honest gap is easier for a buyer to live with than a confident story that later turns out to be wrong.

Custody: who can act, and whether that person will be available

Because the TLD is a token in a wallet, the only party who can transfer it is the party who controls the wallet’s private key, the secret credential that authorizes transactions from that address. A multisignature wallet, one that requires approval from more than one key before a transaction can be sent, adds a layer of security but also a coordination requirement: every required key holder must be available and cooperative at the moment of transfer.

Custody questions are among the most practical in a TLD review, and they are among the ones sellers most often leave until too late.

Before entering a sale process, you should be able to answer four questions clearly:

• Which wallet holds the TLD token?
• Who controls that wallet’s key or keys?
• If the wallet is multisignature, how many approvals are required, and can every key holder still be reached?
• Has any other party, such as an employee, a contractor or a co-founder, ever had access to the wallet, so that their cooperation might be needed?

The answer to each question should be unambiguous. If the wallet is controlled by an individual who is no longer connected to the organization, the priority before a sale process is to move the TLD to a wallet whose custodian will be present and cooperative at closing. That move is itself a transaction visible on the block explorer, and a buyer who sees a transfer shortly before the sale will ask about it. The honest answer, that the TLD was consolidated into a wallet controlled by the right person, is a perfectly reasonable one and creates no problem.

There is a second custody question that the blockchain cannot answer: whether the person who controls the wallet is entitled to sell. A key gives the practical power to transfer. It says nothing about ownership between a company and its founder, between two partners, or between a client and the agency that registered the TLD for it. If the TLD belongs to a company, the buyer’s counsel will usually want to see that the person acting has the authority to sell it. What that takes depends on the country and on the company’s own rules, and it is a point for your counsel.

What creates a problem is discovering at closing that a required key holder is unavailable, or that access to the wallet has been lost. A closing in which the TLD passes through onchain escrow needs the token to move. If the token cannot be moved, nothing closes, whatever the parties have agreed on paper. Sorting out custody before the process begins is not optional.

What to assemble: a factual file on the TLD

A buyer who is seriously interested will want the answers above in one place. Assembling this file before the first conversation shows that you have done the work and have nothing to hide from scrutiny.

The file does not need to be long. Its job is to give the buyer’s team the inputs they need to run their review without having to ask the same question three times.

1. Confirm the registry recordLook up the TLD token on a block explorer and confirm that the wallet shown as its holder is the wallet you control. Note the token identifier and the chain it is recorded on.
2. Write out the transfer historySet down every transfer in the token's history: the date, the sending wallet, the receiving wallet and a one-line explanation. Identify every prior holder by role, not by name.
3. Document the namespaceDraw up a complete inventory of the names issued under the TLD. For each, record the wallet that holds it, the date of issuance, what was paid or why it was issued at no charge, and any commitment made to its holder.
4. Confirm custody and availabilityState who controls the wallet holding the TLD, confirm that every key holder of a multisignature wallet can be reached, and confirm that the controlling party will be available to carry out the transfer at closing.
5. Run the trademark checkEstablish whether the string or a close variant is a registered trademark in the countries that matter for likely buyers. Record the result, whichever way it falls.
6. Gather royalty and activation recordsIf the TLD has earned royalties under Freename's royalty program, record the amounts and periods. If the TLD has been put to use, for example with a published website or names set up to receive payments, record that too.
7. Prepare a disclosure noteIdentify every item above that a buyer might view as a complication. Write one paragraph on each, explaining what it is and what, if anything, has been done about it. This note goes to the buyer complete.

Keep the file factual. It is not a sales document, and it gains nothing from adjectives or from projections of what the TLD could earn. A statement in the file that proves inaccurate does more damage than a statement left out, because it gives the buyer a reason to doubt the rest. If you want to discuss potential, do it in conversation and label it as opinion.

Think also about when the file leaves your hands. It contains wallet addresses, the history of your holding and, in the disclosure note, the weakest points of the asset. That is information to share under a confidentiality agreement, not before. Where a sale runs through Hush Partners, a standard mutual NDA covers every exchange.

Problems that can be fixed, problems that can only be disclosed

Preparation does not mean making everything perfect. Some complications can be resolved before the sale. Others are permanent features of the asset that a buyer must accept or decline. Your job is to know which is which.

The distinction matters because it tells you where to spend time. A holder who spends weeks trying to resolve something that cannot be changed is using up the period in which fixable things could be fixed. Work through the fixable rows first. Then document the disclosure rows thoroughly and early.

Some items sit between the two categories, and it helps to be realistic about them. A prior holder may or may not answer a request for written confirmation. Holders of names issued informally may remember the terms differently from you. In these cases the fix is partial: you obtain what confirmation you can, and you disclose the remainder as it is. Do not present a partial fix as a complete one.

Disclosure also changes how a problem is treated in the negotiation. A complication the buyer learns about at the start is a fact to be priced, or to be covered by a term in the agreement. The same complication discovered late in the review becomes a question about what else has not been said. A buyer who feels surprised often walks away, even when the problem itself was one they could have accepted.

Timing: when to start preparing

The preparation described in this article takes time. The tasks are not difficult, but some of them involve contacting other parties, waiting for responses, and documenting things that exist only in people’s memories. Starting when a buyer is already asking questions is too late.

A useful working rule is to count in weeks, not days, between starting preparation and entering a buyer conversation, and to allow longer if the history or the namespace is complicated. That period has to accommodate the following without pressure:

• Reconstructing and documenting the transfer history
• Contacting holders of issued names and recording what they understand the terms to be
• Resolving custody questions and, if necessary, moving the TLD to the right wallet
• Running a trademark search and reading the results with counsel
• Assembling and reviewing the factual file

If the TLD is entirely clean, with no names issued, a single wallet, a simple transfer history and no trademark proximity, the preparation can be done in days. Do not assume that you are in that position before you have looked. Preparation often surfaces complications the holder did not know existed, and the earlier you start, the more time you have to address them.

Order matters as much as duration. Stop issuance first, because it costs nothing and prevents new complications while you work. Take custody next, because a move between wallets is best made well before a buyer reads the record. Leave the file to the end, when the facts it describes have stopped changing.

Requesting a private valuation before you begin formal preparation is also reasonable. An idea of what the TLD is likely to be worth helps you decide how much preparation effort is proportionate, and the same factors that drive a price tell you which items on the preparation sequence deserve the most attention.

If you hold a TLD and are considering a sale, the page on sell-side mandates describes the service in which a holder mandates Hush Partners to find a buyer. One named partner stays with the file from the first note until closing, and the TLD changes hands through onchain escrow on an aftermarket, as set out on the escrow and transfer page. A prepared file is what lets that last stage go ahead without new questions.

The page for holders gives a broader orientation, and how it works sets out the stages of a file from mandate to transfer. The practical next step is smaller than either: open a block explorer, read the record of your own TLD as a stranger would, and write down every question it leaves unanswered.

Questions people ask

What happens to the royalty stream at closing?

Under Freename’s royalty program, the share of registration fees goes to the holder of the TLD, on the registry’s terms. After a transfer, the new holder is the one in that position, so the buyer will want to check with the registry what, if anything, has to be done for the program to apply to them. The buyer should also know that the program is not free to take part in: a Freename TLD has no annual renewal fee, but participation in the royalty program carries an annual cost set by the registry. If your TLD was registered under earlier terms that include the program for life, say so in the file, and leave it to the buyer to confirm with the registry before closing whether those terms pass to a new holder. How royalties for the period around closing are divided between seller and buyer is a point for the sale agreement and for the parties’ advisers.

Does the TLD need to be activated or in use to sell?

No. A TLD that has never been put to use, with no names issued and no website published, is a simple asset, and some buyers prefer it in that state. The absence of activity does not reduce value in itself. What reduces value is uncertainty: a TLD whose history is unclear or whose namespace is complicated is harder to sell than one that has simply been held quietly. Putting the TLD to work is a separate subject, covered under post-transfer activation.

Is a legal agreement needed, or is the onchain transfer sufficient?

The onchain transfer moves the token, but it does not record the terms on which it moved. A buyer will usually want a written agreement that states the price, the condition of the asset at closing, any assurances the seller gives, and the basis on which disclosed complications were accepted. That agreement is separate from the onchain mechanics. Its form and content vary by country and are for the parties’ own counsel to decide.

What if the TLD was registered by someone else on the holder’s behalf?

This is a question of both custody and entitlement. If the token sits in a wallet controlled by someone other than the person or company it belongs to, the first step is to establish documented custody in the right wallet before a sale process begins. The nature of the original arrangement, whether a service relationship, a shared holding or something else, determines what paperwork is needed to show that the sale is authorized. Settle it with your own counsel before any buyer sees the TLD.