Acquiring several onchain TLDs in one conversation

A group that wants .yourbrand for its corporate identity, the TLD that matches one of its product brands and .yoursector for a market-facing namespace is running three separate acquisition objectives inside a single strategy. Each TLD is a token held in a wallet on a public blockchain, and the registry’s record of each one is public: a block explorer lets anyone check it. Each one therefore has its own counterpart, its own price and its own transfer. Yet the three names belong in one conversation, and treating them as three independent files usually costs more time, more money and more information than treating them as one coordinated program.

This article is for the team leading that program. It covers when to bundle, how to structure the terms, what to do when the names are held by different counterparts, how closing works for several transfers, and how to govern what you hold once the transfers are complete. It also covers the ways a bundle fails, so you can design around the risks before the first note goes out.

By the end, you will have a working frame for every stage of a multi-name acquisition, from the internal prioritization meeting to the first day you hold the full set.

When several names belong together

The clearest case is a corporate group name paired with its principal brand names. If an organization operates under one parent identity and two or three distinct brands, those TLDs form a natural set: they share a public-facing story, a legal owner after acquisition and a common governance model. Acquiring them separately, over a long period, is possible. It means reopening the work each time, accepting that prices may move in between and giving each later counterpart a chance to observe the pattern and price accordingly.

Product and sub-brand TLDs belong in the same file when the organization intends to activate them together. A namespace built around pay.yourbrand, press.yourbrand and id.yourbrand is a coherent infrastructure project, and the TLD of a product brand that will carry its own names is part of the same project. Acquiring the group TLD and leaving the product TLDs to a later program is rational only if budget or timeline force it. Otherwise you design the namespace twice: once for what you hold, and again when the rest arrives.

Sector TLDs, words that describe an industry rather than a brand, belong in a bundle when the organization has a credible operational reason to hold one. Acquiring .yoursector alongside .yourbrand in one file is quieter than a separate approach for the sector word, because a request for a sector word alone can look speculative. Inside a clear brand program the case for the acquisition is coherent, and the combined price can be presented for approval as a single infrastructure investment.

The bundle should not be forced. Five names with no shared activation plan are five separate files wearing the same cover sheet. The test is simple: will these names be governed, deployed and communicated as a set? If yes, acquire them as one. If the honest answer is that two of them will and three might, the program is the two, and the three are a list to revisit.

One more check belongs here, before any approach. A name that matches a registered trademark of your organization is a different kind of target from a sector word that nobody owns in the trademark sense. The page on trademark TLDs explains the distinction. In a mixed set, it affects both the tone of the approach and the order of priorities.

One counterpart or several

Freename records every TLD in your set onchain, as a token that a wallet holds. The registry record is public, so anyone can check on a block explorer which wallet holds each token. What the record does not tell you is who stands behind a wallet, or whether two wallets belong to the same person. Plan on the assumption that every name in your set has its own counterpart. That is the general case, and a plan built for it also works in the easier one.

With several counterparts, the bundle is a program on your side and a single sale on each of theirs. It cannot be presented as one deal to one party. Each holder receives a separate approach, and each approach concerns one name only. Coordinate the approaches in time, within a short window of each other, so that no conversation has run its full course before the others begin. A long gap between the first agreement and the last approach is where a program becomes visible.

The standard mutual NDA that covers every exchange applies to each conversation separately. Terms agreed with one holder are not disclosed to another to anchor expectations. Each conversation is confidential in its own right, and that confidentiality is also what keeps the size of your program out of every individual price.

If it emerges during the exchanges that one counterpart can deliver more than one of your names, combined terms in a single document become possible. This is cleaner and often faster: one process and one consideration for the holder, one closing for you. The risk is that one name becomes leverage for the other, with a lower-priority name priced high because the name you need most sits beside it. The protection is the same as in the general case: priorities and ceilings fixed internally before any approach goes out, and a willingness to take the names apart again if the combined price stops making sense.

Priorities inside the set: the names that must close

Every bundle has a hierarchy. Some names are must-haves: the acquisition fails its strategic purpose if those names do not transfer. Others are strong preferences. Others are opportunistic, worth acquiring if the price is sensible and not worth a premium.

The classification has direct consequences for how you structure terms. If .yourbrand is a must-have and .yoursector is opportunistic, the terms for the bundle need to allow .yoursector to fall away without unwinding the core acquisition. An all-or-nothing structure on a set that mixes must-haves and opportunistic names is a structural risk: one holder’s refusal to move on the price of an opportunistic name could block the names you actually need.

The classification also governs how much of the total budget can be allocated to each name. Take a worked example with invented figures. Assume a three-name bundle with a total authorized budget of USD 300,000. The team classifies .yourbrand as a must-have with a ceiling of USD 200,000, the product brand TLD as a strong preference with a ceiling of USD 70,000, and .yoursector as opportunistic with a ceiling of USD 30,000. The three ceilings add up to the budget, and each is set before any approach goes out. If the holder of .yoursector asks USD 60,000 and will not move, the team has a clear answer: walk away from that name and keep the USD 30,000 unspent rather than move it. The decision requires no further approval because it was made before the conversation began.

The example also shows what a ceiling is not. It is not a target and not an estimate of value. It is the point past which the name stops being worth it to this organization, given what the other names in the set are for. Two rules are worth writing down next to the ceilings. First, whether budget released by a name that falls away may be reallocated to a must-have, and who approves that. Second, whether a must-have that closes below its ceiling frees budget for the others. Teams that settle these two questions in advance negotiate calmly. Teams that do not tend to reopen the whole budget at the worst moment.

If you are uncertain about relative value before setting ceilings, start with how a TLD valuation is built. The factors that drive the value of a brand-matching name differ from those of a sector word, and a ceiling that ignores the difference is usually wrong in both directions.

Terms for a set: all or nothing, or name by name

The structural choice that most directly affects risk is whether the bundle is a single, indivisible transaction or a named set with individual closing conditions.

An all-or-nothing structure means that every name in the set must transfer for any consideration to move. It guarantees that you never end up with a partial set. It also creates a single point of failure: one holder who declines, one wallet access problem or one delay can block the entire program. And with several counterparts it asks each of them to accept that their sale depends on events they cannot see and do not control. Holders resist that kind of condition, and those who accept it tend to price it.

Name-by-name terms, with a separate purchase agreement for each TLD, remove the single point of failure. Each closing is independent. The risk is the opposite one: you close on the lower-priority names first and then find that the must-have cannot be acquired at an acceptable price. You then hold supporting names without the name they were meant to support.

The most workable structure for most multi-name programs is a conditional bundle with a defined core. The core names, the must-haves, are linked on your side: you commit to closing on all of the core or on none of it. The remaining names are agreed individually, each at its own price, with a defined period in which you may complete. This gives you protection on the names that matter, flexibility on the rest and a clean fallback if an opportunistic name fails.

A conditional core requires more precise drafting. Each purchase agreement must say what the buyer’s condition is, what counts as a failure of that condition and what happens to the optioned names if the core fails, all without disclosing to one holder who or what the other names are. Whether a right to complete later is enforceable, and in what form, varies by country. Your counsel drafts these documents and decides the form. This article describes the structure only.

Closing several transfers

Plan on each TLD moving as its own transfer: the token goes from the holder’s wallet to the destination wallet through the escrow of an aftermarket, and each transfer settles individually. Closing a multi-name set is therefore a sequence of closings and not one simultaneous exchange. The order of that sequence is a decision, and it follows from the priorities.

1. Confirm wallet readinessCheck that the receiving wallet for each TLD exists, is accessible and has its signers available before any consideration is committed. A multisignature wallet, one that requires more than one authorized signature to approve a transaction, is a common choice for institutional holdings.
2. Commit the core togetherHave the consideration for every must-have name ready and committed to escrow before the first core transfer executes, so that the core closes as a group.
3. Execute core transfersEach core TLD transfers through the aftermarket escrow. Confirm each transfer on a block explorer before proceeding to the next.
4. Complete the non-core namesOnce the core is confirmed onchain, complete the purchase of each non-core name within the agreed period. Fund and transfer each one individually.
5. Document the full setRecord the transaction reference of every transfer, the receiving wallet for each TLD and the date of each onchain confirmation. This is the internal ownership file for the program.

The sequencing of the core matters most when two must-have names come from different counterparts. If one core name transfers while the terms for the other are still open, you have paid for half of a core, which is the outcome the structure was meant to exclude. Having both sets of terms signed and both considerations committed before either transfer executes keeps the two closings as close to each other as the mechanics allow.

Closing runs through onchain escrow on an aftermarket: Freename’s by default, or another marketplace such as OpenSea if the client prefers. Escrow holds the consideration until the transfer is confirmed, which protects both parties. Do not move consideration outside escrow on the basis of a verbal agreement or a draft document, however far the negotiation has progressed. In a program with several counterparts, an exception made for one closing is quickly expected in the others.

Custody for several TLDs

A single-name acquisition raises one custody question: where does this token live after transfer? A multi-name acquisition raises the same question for each name, and the answers need to be consistent with each other and with the organization’s wider governance of digital assets.

There are two basic models. In self-custody, the organization controls the private keys of the wallet directly. With a third-party custody provider, the custodian holds the keys under an agreed arrangement. The models differ in key management, access control, insurance coverage and audit. Which of them your organization may use is often already settled by an internal policy written for other digital assets, and that policy is the first document to read.

For a set of TLDs that will be governed and deployed together, a single wallet holding all of them simplifies administration: one access control policy, one signing process, one audit trail. The practical risk is concentration. If access to that wallet is lost or compromised, all the names are affected at the same time.

A multisignature wallet addresses part of that risk by requiring more than one authorized signature for any transaction. With an arrangement that requires, for example, two of three designated signers, no single individual can transfer a TLD alone, and the loss of one signer’s credentials does not lock the organization out of its assets. The right threshold, and who the signers are, is a governance decision for your security and legal teams. Signers should be roles with named deputies, so that a departure does not become a custody incident.

There is one fact that makes custody of a Freename TLD simpler than that of a DNS portfolio: there is no annual renewal fee on a Freename TLD. Nothing lapses because an invoice was missed. The risk is not expiry. It is access. That shifts the custody effort away from calendars and toward keys, signers and succession.

Activation depends on the custody model, because access to the wallet is what allows the holder to issue names and manage the TLD. A wallet that is safe but that the operating team cannot use in practice will stall the work. Plan the custody model before closing, not after.

After the transfer: one namespace policy or several

Once the set is in your hands, you face a governance question that a single-TLD acquisition does not raise. Do you govern .yourbrand and .yoursector under one namespace policy, or does each TLD have its own rules for which names can be issued under it, at what price and to whom?

The answer follows from the function of each TLD. A corporate identity TLD such as .yourbrand will almost certainly be closed: only the organization issues names under it, in a controlled way, for its own entities, products and authorized partners. There is no open registration and no public pricing, because the point of the TLD is exclusivity and not revenue. A product brand TLD normally follows the same policy, with its own short list of permitted names.

A sector TLD such as .yoursector may be intended as a market-facing namespace, where third parties register names such as name.yoursector. This TLD needs a different policy altogether: who may register, at what price, what restrictions apply and how a dispute over a name is handled. Issuing those names is reserved, on Freename, to whoever holds the TLD. Freename also runs a royalty program in which the holder of a TLD receives 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. Read those terms before any revenue assumption enters a business case, and count the cost side with them. The TLD has no annual renewal fee, but taking part in the royalty program has an annual cost that the registry sets. If the .yoursector you are acquiring was registered under earlier terms that include the program for life, confirm with the registry before closing whether those terms pass to you.

Running a closed TLD and an open TLD from the same organization requires separate policies, separate operational processes and possibly separate teams. The work for the open TLD is substantially larger. If your organization acquired .yoursector as a protective measure and not as an operational namespace, the simpler policy is to keep it closed: hold it, issue no names under it and review the decision at a fixed interval.

What can be shared across the set is the layer above the policies: one owner for the namespace inside the organization, one register of every name issued, one procedure for approving a new name and one custody standard. A workable pattern is a single short governance document for the set, with one annex per TLD that states whether it is closed or open and who decides.

Namespace monitoring also differs across the set. For a closed TLD, the question is whether the names issued match the internal register. For an open TLD, the question is whether infringing or abusive registrations appear among legitimate ones. Write the monitoring brief for each TLD separately, even if they sit in the same wallet.

Comparing a repeated single acquisition with a coordinated program

The differences between running three separate single-name acquisitions and running them as one coordinated program are large enough to affect how you structure the mandate.

The table makes the efficiency case for a coordinated program. The counterargument is control. A single program that meets a problem on one name creates pressure across all of them, and a team that would have handled three small files comfortably can be stretched by one large one. The conditional core is designed to keep the efficiency while isolating the risk. Where even that is too much for the team available, two names now and a third later is a legitimate choice, provided it is a decision and not a drift.

What makes a bundle fail

Multi-name programs fail for a small number of recurring reasons. Each can be avoided with preparation.

Priorities that were never written down. The most common cause of failure is that the internal classification was never formalized. When a holder comes in above the ceiling on a must-have name, the team has no agreed answer and the negotiation stalls while internal alignment is rebuilt. A long silence at that point tells the counterpart more about your priorities than any document would.

Counterparts learning of each other. If two holders learn that they are both in conversation with the same buyer, each will reasonably reassess their price. This can happen through shared advisers, through professional networks or through a careless internal email that travels. Tight timing and compartmentalized conversations reduce the risk. The organization’s own team has to apply the same discipline as its intermediaries, including in board papers and budget requests, where the full list of names is most often written out.

Wallets that are not ready at closing. A transfer cannot complete if the receiving wallet is not set up or its signers are unavailable. In a multi-name closing, a wallet problem that surfaces in the middle of the sequence leaves committed consideration waiting while the issue is resolved, and a counterpart kept waiting may ask to revisit terms. Confirm every receiving wallet before any consideration is committed.

Governance designed after closing. Organizations that defer the namespace policy until the transfers complete often find that the operational requirements of an open TLD are larger than expected. If the budget and the team for activation were not part of the original brief, the TLD sits idle. That is not a harm in itself, since nothing lapses, but it is a cost without a return, and it invites the internal question of why the name was acquired.

All-or-nothing terms on a mixed-priority set. Applying an all-or-nothing condition to a set that includes opportunistic names gives the least important name the power to block the most important one. The conditional core avoids this. If you are instructing counsel to draft the agreements, make sure the structure reflects the internal classification exactly.

A sixth cause is less visible: a bundle that should never have been one. Names added to a program because they were available, and not because anyone will use them, consume budget, negotiating attention and governance effort. Removing a name from the set before the first approach costs nothing. Removing it afterwards costs a conversation.

Starting a multi-name program

The first practical step is an internal document that does not leave the team: a ranked list of target names, the priority tier and the ceiling for each, the roles that will sign for the destination wallet and the activation plan for each TLD after transfer. That document is the brief. Without it, no mandate can be carried out coherently.

With the brief in hand, an organization can mandate Hush Partners to find and approach the holders: that is a buy-side acquisition, and where the target is the TLD that matches your own brand, brand namespace recovery. Every exchange is covered by the standard mutual NDA, one named partner follows the file from the first note to closing, and closing runs through onchain escrow. The fee is a fixed amount, charged only to the organization that mandates the desk. A holder who answers a note pays no fee.

The contact form is the only route to the desk. Bring the brief, or as much of it as you have, and the first conversation can be about structure.

Questions people ask

Can a multi-name program be run quietly if one of the names is well known?

Yes, but it requires tighter discipline than a single-name file. The approach for the well-known name does not reference the other names in the program, and the approaches are kept close together in time. A holder who learns that the same organization is acquiring adjacent names may reassess their asking price, which is their right. Compartmentalization is what prevents the question from arising.

What happens if one core transfer fails after another has already closed?

This depends entirely on the terms of the purchase agreements. An onchain transfer that has completed is not reversed by the system, so any remedy is contractual: a period in which the failed closing can be cured, or a right agreed in advance with the counterpart concerned. Your counsel needs to specify this before signing, and the sequencing described above exists to make the situation unlikely.

Do all TLDs in a set need to go into the same wallet?

No. They need to go into wallets that the organization controls. Distributing them across two wallets, for example one for the corporate TLD and one for the market-facing namespace, is sensible if the governance models and the operating teams are different. What matters is that the custody and signing arrangements for each wallet are documented before closing, not improvised during it.

Is there a minimum set size that makes a program worthwhile?

Two names are enough if they share an activation plan. The benefit of coordination lies in timing and information management, not in the number of names. A two-name file with different counterparts and a shared closing window is already a program. A five-name file closed one name at a time over a long period is five separate acquisitions in a shared folder.