How to acquire an onchain TLD, from first check to transfer

Acquiring an onchain TLD is not like renewing a domain name. There is no registrar waiting for your credit card, no annual fee that reopens the question every year, and no administrative panel you can petition if the holder does not want to sell. The TLD is a token in a wallet. The holder controls it entirely, and you can only acquire it if they agree to transfer it.

That fact changes how you prepare. Most of the work in a successful acquisition happens before any conversation with a holder begins: understanding what you are actually looking at, building an internal mandate, and deciding who speaks, on what terms, and up to what limit. An organization that does this work arrives at closing without surprises. One that does not tends to stall on its own internal friction, or to negotiate from a weaker position because the other side can see that nobody has authority to decide.

This article follows the acquisition in chronological order, from the first registry check through the first days after transfer. It tells you what is decided at each stage, who needs to be involved inside your organization, and where the process most commonly stalls. By the end, you will have a complete map of the path and a clear sense of what your team needs to prepare before you start.

1. Establish what existsCheck the public registry record, confirm that the TLD exists and what kind of wallet holds it, and look for names already issued under it. This stage ends with a written brief for the decision-makers.
2. Decide internallyThe organization agrees on its rationale, assigns a mandate owner, and sets a ceiling known only to the people who need to know it. Nothing goes to the holder until this stage is complete.
3. Make the approachEither a named person at the organization or an intermediary contacts the holder. The choice of who approaches, and how, shapes every conversation that follows.
4. Agree terms in writingPrice, payment currency, transfer mechanics, confidentiality, and a validity date are set out in a written term sheet or heads of agreement. Nothing is verbal at this stage.
5. Close in onchain escrowThe parties close through onchain escrow on an aftermarket. The token reaches the buyer's wallet against payment, and the result is visible on a block explorer.
6. First days after transferThe organization secures the wallet, verifies the registry record, decides whether names will be issued, and briefs the teams that will use the TLD.

What the registry record actually tells you

Before any internal discussion, someone needs to pull the registry record. The TLD you are looking at exists on Freename as a token recorded onchain and held in a wallet, and that record is public: anyone can check it on a block explorer, a website that displays the contents of a blockchain. The record tells you whether the TLD exists, which wallet holds it, and when the token was created. It does not tell you the identity of the holder.

Four questions shape your brief at this stage. First, does the TLD exist? Not every name has been registered. If yours has not, registering it with the registry directly is simpler than an acquisition, and the rest of this article does not apply. Second, is the token in an ordinary wallet, in a multisignature wallet (a wallet that requires more than one private key to authorize a transaction), or in a smart contract that suggests an escrow or lending arrangement? Each of those states has a different implication for how quickly and cleanly a transfer can close. Third, is there any public activity under the TLD: names issued, a page offering names, signs of an active namespace? Activity usually means the holder has a commercial interest in the asset, which affects valuation. Fourth, has the TLD been the subject of any public dispute or intellectual property filing that you can find?

The record also has limits you should state in the brief. It shows a wallet, not a person or a company. It shows that a token moved, not why, and not whether a third party has a claim on it that sits outside the chain. Those gaps are filled later, by the representations the holder makes in the term sheet, and the brief should say plainly which facts are verified and which are assumed.

If the TLD matches a mark your organization has registered, the page on trademark TLDs explains what that situation is and holds a free Trademark Name Check form. It is a sensible companion to the registry check, because the trademark position will shape both the rationale and the conversation with the holder.

Compile the answers into a written brief: one page that a general counsel and a chief financial officer can read in a few minutes. This brief is the input to the internal decision stage. Do not skip it. An acquisition that starts with a conversation instead of a brief tends to drift, because the decision-makers are working from different assumptions.

Building the internal mandate before anyone approaches the holder

The internal decision stage has one non-negotiable output: a mandate with a ceiling. The mandate names the person who owns the file, defines what the organization is willing to pay and in what circumstances, and sets the limit above which the acquisition does not proceed. That ceiling is the most commercially sensitive number in the entire process.

A mandate is not the same as approval to proceed. It is approval to proceed up to a defined point, with a defined process for going back to the decision-makers if something material changes. The mandate document does not need to be long. It should record why the organization wants this specific TLD (not onchain TLDs in general), what the TLD will be used for after acquisition, the payment ceiling and the currency in which payment will be made, who has authority to agree terms, and what approvals are needed before the closing is instructed.

How a ceiling is reasoned

A ceiling is not a guess at what the holder will accept. It is the answer to a question about your own organization: what is this TLD worth to you, given what you will do with it and what it costs you to leave it where it is? Three inputs usually carry the reasoning. The first is use: a TLD you intend to operate, with names such as pay.yourbrand issued to your own teams or partners, supports a different figure from one you intend to hold and leave unused. The second is the alternative: if the acquisition does not happen, what you would do instead, and what that would cost in money and in attention. The third is the cost of holding: on Freename there is no annual renewal fee on a TLD, so the price is paid once and the ongoing cost is the cost of keeping the wallet secure, plus the royalty program’s annual cost if you take part.

Write the reasoning down next to the number. A ceiling with its reasoning attached survives a change of personnel and a difficult week in the negotiation. A ceiling that is only a number gets renegotiated internally each time the holder pushes back.

The ceiling stays inside a small group, for reasons covered in the section on confidentiality below. The practical point here is that the mandate stage is where organizations most often spend too little time. A holder who senses that the buyer has no limit, or that an internal champion will carry the deal through at any price, has every reason to hold out.

If the acquisition is run through an intermediary, for example under a buy-side mandate given to a desk, the mandate document also defines what the intermediary is authorized to say and, equally importantly, what it is not authorized to say. The intermediary works within the mandate, not around it.

The approach: direct or through an intermediary

There are two ways to make first contact. Your organization approaches the holder directly, or you mandate an intermediary to do it. The choice is not mainly about cost. It is about what information you reveal, to whom, and at what moment.

A direct approach identifies your organization immediately. That is fine if your rationale is simple, your trademark position is clear, and you are comfortable with the holder knowing from the first message who is interested. It can work against you if the holder, on learning who wants to buy, revises their expectations upward, brings in advisers in a way that lengthens the process, or stops answering because the contact felt like pressure from a larger party.

An approach through an intermediary changes who writes and what the first message contains. The intermediary describes the interest, establishes whether the holder is willing to discuss terms at all, and carries the exchange from there. What it may disclose about the organization it acts for, and at what point, is something you settle in the mandate before the first note is sent. It is a decision, not a default, and it should be made by the same small group that sets the ceiling.

There is a second difference that organizations notice only later. A direct approach uses your own people: someone has to find a route to a holder who is known only as a wallet, write, follow up, and keep the file moving alongside their other work. An intermediary takes that work on, and brings the habit of running a negotiation that neither side wishes to conduct in public. On a file run by Hush Partners, every exchange is covered by a standard mutual NDA and one named partner follows it from first note to closing. The page on how a file works sets out the stages from mandate to transfer.

One more situation deserves a mention. If your organization has itself received a note about a TLD, the first move has already been made and the question is how to answer. The page for organizations that have received a note from the desk covers that case. The discipline is the same as for an outbound approach: no reply goes out before the internal mandate exists.

What the term sheet must contain

When a holder signals genuine willingness to discuss a sale, the conversation needs to move to writing. A verbal price is not a price. A message saying “I’d consider an offer” is not an agreement. The term sheet, or heads of agreement, is the document that converts a conversation into a transaction in progress.

A well-drafted term sheet for an onchain TLD acquisition covers six things:

• Price and currency. The amount, the currency (conventional currency or a crypto asset, and if the latter, which asset and on which chain), and whether payment is made at once or in stages.
• Transfer mechanics. Which aftermarket will be used for closing, which wallet will receive the token, and who gives the instruction to close.
• Royalty position. On Freename, the holder of a TLD can take part in a royalty program and receive a share of each registration fee for names registered under that TLD, advertised at up to half, subject to the registry’s current terms and activation conditions. Taking part carries an annual cost set by the registry, although some TLDs were registered under earlier terms that include the program for life. The parties should record whether the program is active for this TLD, what the registry requires of a new holder, and whether any earlier terms pass to the buyer, confirmed with the registry before closing.
• Representations. The holder confirms that the token is unencumbered, that they have sole authority to transfer it, that they have disclosed the names already issued under it, and that they are not aware of any dispute affecting the TLD.
• Confidentiality. Neither party discloses the existence or terms of the transaction to anyone other than their own advisers, who are bound by equivalent duties.
• Validity date. The term sheet expires at a stated date and time.

The validity date is the item buyers most often leave out, and it matters more than it looks. Without an expiry, a term sheet is an open offer that either side can leave on the table while testing other options. With one, both sides have to decide whether they are actually in a deal. The validity date is a tool for clarity, not a pressure tactic. Set it far enough out that your internal approvals can complete, and near enough that the terms still reflect what both sides meant when they agreed them.

Whether a term sheet is binding, and in which of its clauses, depends on how it is drafted and on the law that governs it, which varies by country. This is information, not advice: your own counsel decides the form of the document and the governing law.

Closing in onchain escrow

Onchain closing is structurally different from a conventional domain transfer. In a conventional transfer, the parties typically use an escrow agent who holds the funds while the domain is moved between registrar accounts, with an authorization code and a manual release at the end. The process depends on several people acting in sequence.

In an onchain escrow, a smart contract (a program that runs on a blockchain and executes as written) takes the place of that manual sequence. The delivery of the token and the payment are tied together by the contract, so the buyer does not have to pay and then wait for the seller to deliver. This removes much of the counterparty risk that conventional escrow exists to manage. It does not remove the need for care: a transfer to the wrong address is not reversed by a help desk.

Closing runs through onchain escrow on an aftermarket: Freename’s aftermarket by default on a file handled by the desk, or another marketplace such as OpenSea if the client prefers. Before the closing is instructed, three things need to be confirmed.

First, the buyer’s wallet is ready to receive the token. This sounds obvious, but it is the step most likely to cause a last-minute delay: the wallet needs to be set up, tested, and controlled by the right people inside the organization before closing, not after.

Second, both parties have agreed which wallet address the buyer will use, and that address has been confirmed in writing through the channel the term sheet names, not copied from a message at the moment of transfer.

Third, the holder has confirmed that the token sits in the wallet they intend to transfer from, and that it is not committed elsewhere or encumbered in a way that would cause the closing to fail. You can check the first half of that statement yourself on the block explorer.

Once those conditions are met, the closing is instructed and the trade executes. The buyer checks on the block explorer that the token now appears in the correct wallet. That check, saved to the file, is the close.

The first days after transfer

Transfer is not the end of the file. It is the beginning of the operational phase, and the first days matter more than most organizations expect.

The first action is wallet security. The wallet holding the TLD token should be a multisignature wallet, or a wallet whose key is kept on a dedicated hardware device, under the control of more than one person inside the organization. A TLD held in an everyday wallet controlled by a single employee is exposed to that person’s mistakes, departure, or absence. Everything that comes after the transfer rests on this, so it should be planned before closing, not improvised afterwards.

The second action is registry verification. Pull the block explorer record again and confirm that the token is in the wallet your organization controls. Keep a copy of this verification in the acquisition file, next to the term sheet.

The third action is a decision on name issuance. Now that the token sits in your wallet, issuing names under the TLD is something Freename allows your organization alone, as holder, to do. Your organization needs to decide, before anyone asks, whether it will issue names under .yourbrand immediately, on a limited basis to approved parties, or not at all for now. If the royalty program is in the picture, review the registry’s current terms and decide whether it fits your intended use. A TLD kept strictly for internal names has no use for it. One opened to partners or customers might. These decisions have intellectual property and commercial implications that your legal team should confirm before any name is issued.

The fourth action is internal notification. The teams that will use the TLD need to know it has transferred and understand what they can and cannot do with it. Payments addressed to a name under the TLD, websites published there, or identities issued under it all follow from decisions made now. Be candid with those teams about limits: an onchain TLD sits outside the DNS, an ordinary browser does not open its names without added support, and it complements your domain names and does not replace them.

Who should be in the room at each stage

Acquisitions go wrong when the wrong people are involved at the wrong time. Too many people too early, and the ceiling leaks. Too few people too late, and the close is delayed because someone who should have been consulted weeks earlier raises a concern on the day of closing.

The table below maps the six stages to the internal roles that need to be active, advisory, or informed at each one.

A few notes on this table. IP counsel should be involved from the registry check because the trademark position shapes both the negotiation and the representations the holder will be asked to make. Finance needs to be active at closing, not just informed, because the payment comes from them, and because a payment in a crypto asset may be something the finance team has never executed before. How the acquired TLD is recorded in the accounts, and how the purchase is taxed, are questions for your own accountants and tax advisers under the rules of your country. Raise them at the mandate stage, when they can still influence the structure.

The keyholder named in the closing row is the specific individual, or better the small group, who will control the receiving wallet. That role needs to be identified, briefed, and equipped well before closing is instructed. Handing it to someone on the day is a common source of delay, and it is also a security weakness: a person who has never operated a wallet should not learn on the transaction that matters.

Legal, finance, and security are the three functions most often brought in late. Each of them has a legitimate veto at closing. A function with a veto that hears about the file at the last moment will use the time it needs, and that time comes out of the validity period of your term sheet.

What slows an acquisition, and what you control

Many of the delays in an onchain TLD acquisition originate inside the buying organization, not on the holder’s side. Once a holder has decided to sell, the pace is largely set by how quickly the buyer can produce a mandate, a response to the term sheet, a wallet address, and a payment.

Four internal delays recur. The approval chain for the mandate was not mapped before the approach, so the buyer has to go back to internal decision-makers in the middle of the negotiation. The term sheet requires sign-off from a legal team that was not briefed until the document arrived on its desk. The payment currency was not settled before the term sheet was drafted, which reopens terms both sides thought were agreed. And the receiving wallet was not set up until after terms were agreed, which adds time at the most sensitive moment in the process.

Holders can introduce delay too, for reasons that are usually legitimate. A holder who received the approach without prior context may need time to take their own advice. A holder whose token sits in a more complex arrangement (a multisignature wallet whose co-signers are in different time zones, for example) may take longer to complete the transfer than either party expected. These are good reasons to extend a validity date, and a carefully drafted term sheet includes a mechanism for a short extension by mutual consent.

What you do not control is whether the holder wants to sell. A holder who does not answer after first contact may be consulting advisers, weighing other options, or simply not ready. The token is theirs, and no procedure compels a reply. The reasonable response is a single courteous follow-up after a decent interval, then patience. Repeated messages, or a change of tone, turn a holder who was undecided into one who has decided against you. Your mandate should say in advance what happens in this case: how long the file stays open, and who decides to close it.

Confidentiality inside the organization

An acquisition file is at least as exposed to leaks inside the buying organization as outside it. The ceiling, anything learned about the holder, and the existence of the negotiation itself should be known only to the people who need them to do their part of the work.

The ceiling deserves special treatment. Once more than a handful of people know the maximum the organization is prepared to pay, the risk of that number traveling is real. It does not require bad faith: a casual conversation between a team member and an outside contact is enough. Treat the ceiling as you would any figure reserved for the board: shared on a strict need-to-know basis, with a record of who holds it, and never discussed in a channel that is not confidential by design.

In practice this means a few simple habits. Give the file a neutral project name that contains neither the TLD nor the word “acquisition”. Keep the mandate document in a location with restricted access, separate from the working file that advisers and operational teams see. Tell the people who join at later stages, such as the keyholder or the finance officer who executes the payment, what they need for their task and nothing about the limit.

On a file handled by Hush Partners, every exchange is covered by the standard mutual NDA published on this site. If your organization runs the acquisition without an intermediary, have equivalent documentation in place before any material is shared with the holder or their representatives.

Decide how you will run the file before the first check

Before your organization takes any action, including the registry check, it helps to know whether you are running this acquisition on your own or with a specialist desk alongside you. The answer shapes how you allocate internal resources, how you manage confidentiality, and how you structure the approach.

Hush Partners acts for organizations that mandate it to find and approach the holder of a specific onchain TLD. From first note to closing, which runs through onchain escrow on an aftermarket, the file stays with one named partner. For that work the mandating client, and nobody else, is charged a fee set as a fixed amount and never as a percentage. The holder who answers a note pays no fee, and neither does a party buying a TLD the desk offers: what that party pays is the price of the TLD.

If you are not yet at the point of a decision, two smaller steps are available. The Namespace Exposure Score is a free tool on this site that scores how exposed a brand is onchain, which is a useful input to the brief described in stage one. And if you are still weighing an onchain TLD against an ICANN dotBrand, settle that comparison first, since it determines whether there is an acquisition to run at all.

Whichever route you take, the first concrete task is the same and it is internal: name the mandate owner, write the one-page brief, and agree the ceiling in a small room. The desk is reached through the contact form on this site, and nowhere else.

Questions people ask

Can I acquire an onchain TLD that matches a trademark I hold?

Holding a trademark does not by itself give you a right to the corresponding onchain TLD. The Uniform Domain-Name Dispute-Resolution Policy (UDRP), the procedure that ICANN-accredited registrars apply to disputes over conventional domain names, does not reach onchain TLDs, because they sit outside the ICANN system. Your trademark establishes your legitimate interest in the name, and it is part of the rationale in your mandate. What rights it gives you against a holder depends on the law of the countries concerned, and whether and how to refer to it in an approach is a question for your IP counsel. The page on brand namespace recovery describes the service for acquiring the onchain TLD that matches a brand.

What happens to names already issued under the TLD before we acquire it?

Names issued under the TLD before the transfer continue to exist. The new holder does not start from a blank namespace: people who registered names such as pay.yourbrand or team.yourbrand under the previous holder still hold them, and those names remain theirs. Names the seller itself holds under the TLD can be transferred with it if the two parties agree. Whether and how the new holder can affect third-party registrations depends on the registry’s current rules. This is a question to resolve before closing, not after. Ask the holder for a full picture of what has been issued, check it against what is visible onchain, and make sure the representations in your term sheet cover it.

What does onchain escrow mean in practice for a buyer new to crypto transactions?

It means that a smart contract, not a person, ties the delivery of the token to the payment. For a buyer new to this, the preparation is practical: have the receiving wallet set up and tested, know who inside the organization controls it and will confirm the transfer, and have the payment ready in the agreed currency and on the agreed chain before closing is instructed.

Is there any ongoing fee once the TLD is in our wallet?

On Freename, there is no annual renewal fee on a TLD. The token stays in the wallet that controls it, and no payment to a registrar is needed to keep it there. The royalty program is the exception: taking part carries an annual cost set by the registry, unless the TLD was registered under earlier terms that include the program for life, and whether those pass to you is for the registry to confirm before closing. Without the program, the ongoing cost of holding a Freename TLD is the cost of keeping the wallet secure: the devices, the procedures, and the people trained to use them.