Acquiring a TLD ahead of a product launch

A product launch has a date that somebody senior has already promised. An acquisition has no date at all until two parties agree on one. When the launch plan includes a name under .yourbrand, for example pay.yourbrand on the checkout screen, you are joining a fixed calendar to an open one, and the open one belongs partly to a person you have not met.

This article is for the product or brand lead who owns the date. It works backward from launch day through testing, activation, closing, negotiation, approach and mandate, shows one worked calendar with stated assumptions, and says plainly when the right decision is to launch without the name.

Why a launch date changes how you acquire a TLD

An onchain TLD is a top-level name, such as .yourbrand, that lives in a registry on a blockchain instead of in the ICANN root. On Freename, the registry this article uses for its facts, the TLD is a token sitting in a wallet. Whoever controls that wallet is the holder, and the holder alone can create names beneath the TLD. Nobody pays a yearly renewal to keep a Freename TLD. The names resolve in software that supports them and not in an ordinary browser, a limit that matters for your launch and that a later section deals with.

For a launch team, three properties of that asset shape the calendar.

First, there is one of it. If the TLD that matches your product name is already held, there is exactly one counterparty, and no supplier down the road sells the same thing. You cannot run a tender.

Second, the counterparty owes you nothing. A holder may answer in a day, in a month or never. A holder may not want to sell. No procedure forces a reply, and a plan that assumes one is not a plan.

Third, the transfer itself is quick and everything around it is slow. Moving a token from one wallet to another takes one transaction. Getting your organization to the point where it can receive a token, pay for it and put it to work takes weeks of approvals, wallet setup and testing.

So you plan the acquisition the way you plan a regulatory approval or a hardware component with one supplier: from the launch backward, with a decision gate where the name either stays in the launch or leaves it.

Start from what the name does on launch day

How much time you need after closing depends entirely on the job the name has at launch. Decide that before anything else, because it sets the length of the last third of the calendar.

A name can do several distinct things, and each has a different preparation path. The page on what is live describes each capability with its sources. The table below turns them into launch questions.

A payment name is the shortest path technically and the longest internally. Setting an address on pay.yourbrand is minutes of work. Agreeing whose wallet that address belongs to, who can change it and who checks it before launch is where the weeks go.

A website on the TLD can be built with Freename AI, the registry’s site builder at builder.freename.com, which assembles pages or drafts them from a short brief and publishes them to IPFS, a network that stores content by its fingerprint and not by its location. The site is then reached through your name in browsers that support it. That last clause is the one your launch copy has to respect.

Agent identities are the least settled role. ERC-8004, the draft Ethereum standard known as “Trustless Agents”, describes registries for agent identity, reputation and validation, but it is a draft and may change, and the way naming registries connect to it is still evolving. A launch that depends on it should treat it as an experiment with its own caveat, not as a headline feature.

If your honest answer to “what does the name do on launch day” is “it appears on a slide”, you need far less time after closing, and you should also ask whether the launch needs the TLD at all. That question has a section of its own below.

The backward plan: six milestones before launch day

Plan from the end. Each milestone below is defined by what must be true when it is reached, because a milestone defined by activity (“negotiation under way”) cannot be missed and therefore cannot warn you.

1. Resolution testedEvery name the launch uses has been tried in each wallet, browser and device you intend to mention, by someone outside the project team. Failures are fixed or the wording is changed. This ends before the launch freeze, not during it.
2. Names issued and records setThe names exist under the TLD, point to the right addresses or content, and have been checked by a second person against an approved list. Nothing in the launch refers to a name that has not been issued.
3. Token in your custody walletThe TLD is in the wallet your organization chose for the long term, under the people and approvals your security team agreed. From here on, the name is yours to plan around.
4. Terms agreedPrice, what is included, and the closing mechanics are settled in writing with the holder. This is the decision gate: without it by the planned date, the launch proceeds on the fallback.
5. Approach madeThe holder has received a first note and the exchange is covered by a confidentiality agreement. The clock you do not control starts here.
6. Mandate and budget approvedYour organization has decided to try, set a ceiling, named one decision maker and chosen who makes the approach. Until this is done, none of the other dates are real.

Two of the six, the approach and the agreement on terms, depend on another party. The other four depend only on you, and they are where a launch team usually loses time it did not have to lose.

One practical rule follows. Start the internal work for the top three milestones while the bottom three are still in progress. Choosing the custody wallet, agreeing who holds its keys and writing the list of names to issue do not require the TLD. They require meetings. Holding those meetings during the negotiation costs nothing if the acquisition fails and saves weeks if it succeeds.

A worked example: a launch 20 weeks out

The following is an example, not a benchmark. Every duration is an assumption chosen to show how the arithmetic works. Real approaches and negotiations can be much shorter or much longer, and nothing here describes a typical file.

The assumptions: launch day falls at the end of week 20. The launch uses three names under .yourbrand, one for payments, one for a short website and one shown in wallets. The organization has never held an onchain asset. The TLD is held by a third party who is willing to talk.

The second half of the calendar is the part your own teams own. Activation takes an assumed four weeks, weeks 13 to 16, and covers issuing the three names, setting records and publishing the site. Resolution testing takes an assumed two weeks, weeks 17 and 18. Weeks 19 and 20 are held as buffer. The phases add up to 2 + 3 + 5 + 2 + 4 + 2 + 2, which is 20 weeks, with nothing left over.

Now count backward, which is how you would actually build it. Launch is the end of week 20. Take off two weeks of buffer and testing must be finished by the end of week 18. Take off two weeks of testing and activation must be finished by the end of week 16. Take off four weeks of activation and the token must be in your wallet by the end of week 12. Take off two weeks of closing and terms must be agreed by the end of week 10. That date, ten weeks before launch, is the decision gate.

Half of the calendar sits after the gate: the eight weeks of approach and negotiation are fewer than the ten weeks between agreed terms and launch.

Test the plan with one slip. Suppose the negotiation takes eight weeks instead of five. The phases now add up to 2 + 3 + 8 + 2 + 4 + 2, which is 21 weeks before any buffer, one week more than you have. The two weeks of buffer are gone and one further week has to come from somewhere. Activation can drop from four weeks to three only if the wallet decisions and the content were prepared in parallel during the negotiation. Testing should not be the phase that shrinks. If neither can give, the name leaves the launch.

The numbers matter less than the pattern: a three-week slip in the phase you do not control consumed the whole buffer and one week more, and the only cushion was work done early by your own teams.

Mandate and approach: the weeks you do not control

The first milestone is internal and it is the one that most often starts late. Before anyone writes to a holder, four things need an owner.

• A ceiling. The highest total your organization will pay, approved by whoever can approve it, so that an offer does not wait for a committee.
• One decision maker. A named person who can say yes inside the ceiling without convening anyone.
• A receiving plan. Which wallet will hold the TLD and who controls it, at least in outline.
• A channel. Whether your organization approaches the holder itself or mandates someone to do it.

The channel matters more with a launch than without one. An approach from a recognizable organization tells the holder who wants the name. An approach that also mentions a date tells the holder how badly. One answer is to have the approach made on your behalf, under a buy-side mandate, so that the first conversation is about the asset and not about the buyer. Confidentiality should be in place from the first substantive exchange; a standard mutual NDA does this without negotiation.

Before the approach, look the TLD up on a block explorer, where the registry’s public record is open to any reader. It tells you whether the TLD exists as a token and which wallet holds it. It does not tell you who the person is or whether they want to sell. If your product name is also a registered trademark, the page on trademark TLDs explains what that does and does not change in the conversation; in short, a trademark gives you arguments under the law of the countries where it is registered, not an automatic right to an onchain name, and your counsel should say how far those arguments go.

Then plan for silence. Decide in advance how many attempts you will make, over how long, and what the absence of an answer means for the gate. A holder who has not replied by an agreed date is, for launch purposes, the same as a holder who said no. That is not a judgment on the holder. It is a property of your calendar.

Negotiating when only one side has a deadline

A deadline is leverage for the other party. The honest way to handle that is not to hide the truth but to arrange things so the deadline does not decide the price.

Three practices help.

Keep the launch out of the conversation. Product launches are confidential in any case, and your team already limits who knows the date. Extend that discipline to the acquisition. The holder needs to know that a serious party wants the TLD and can close. The holder does not need your roadmap. Nothing here requires saying anything untrue; it requires not volunteering what you would not tell any other supplier before launch.

Make the fallback real before you negotiate. A buyer who can launch without the name negotiates differently from one who cannot, and holders can tell. If the fallback plan exists on paper, with copy and designs, your ceiling stays a ceiling. If it does not, the ceiling will move in week 15, under the worst possible conditions.

Separate the gate from the deal. Missing the gate takes the name out of this launch. It does not have to end the acquisition. A TLD acquired six weeks after launch can still carry the product for years. Saying this internally, early, removes most of the temptation to overpay for a date.

Be equally clear about what you owe the holder. A date on your side is not a reason to hurry someone else. Artificial deadlines, repeated chasing and hints about legal action to speed a reply are poor practice and usually slow things down. State what you offer, state how long the offer is open if it has a real limit, and accept the answer.

Agree early on what is included, because it affects activation. Ask whether the seller holds names under the TLD and whether those would come with it by agreement. Names that the seller sold to third parties stay with those third parties, and you need to know before launch whether one of them is a name you intended to use. Whether a name already issued can be withdrawn or changed is decided case by case, so do not build a launch on the assumption that it can.

Closing and custody before anything is printed

Closing is where the open calendar becomes a fixed one. Until the token is in a wallet your organization controls, the launch does not have the name.

Three streams of work converge here, and each can be prepared in advance.

The receiving wallet. Decide whether the TLD will sit in a multisignature wallet, meaning one that needs several approvals for any action, and who the approvers are. The wallet that receives the token at closing should be the wallet that keeps it, or the move to the long-term wallet should be planned and tested. The address of that wallet will be visible on the public record after closing, which is worth knowing if the launch is still confidential.

The payment. An organization that has never paid for an onchain asset needs time to get funds to the right place with the right approvals. Finance and security should hear about this at the mandate stage, not when terms are agreed.

The mechanics. Closing runs through onchain escrow on an aftermarket, and the page on escrow and transfer describes that step. What matters for your calendar is that both parties are ready on the same day, which is a scheduling problem as much as a technical one.

The rule costs a second version of some artwork. It prevents the situation in which a launch date and a print run have been committed to a name that a third party still controls.

Activation and resolution tests in the final weeks

After closing, the work is yours and it is more ordinary than it sounds. Only the holder can issue names under the TLD, and there is no delegated management, so the people who control the custody wallet are the people who create pay.yourbrand. Plan who that is and when they are available. If your team uses an AI assistant connected to the registry through its MCP server, the assistant acts as the holder, with the holder’s access, and belongs under the same approvals.

Write the list of names before closing. Keep it short for launch. Each name needs an owner, a purpose and a record to point at. The launch roadmap tool turns a use case into a sequence of tasks, and the page on post-transfer activation describes the same work as a service.

Then test, with real devices and people who were not in the room when the names were set up. Support for Freename names exists in three places: Bitcoin.com Wallet, MetaMask by way of Freename’s resolver, and desktop browsers that have the Freename Web3 extension installed. That coverage is partial and it moves, so the test is not “does it work” but “where does it work, and does our wording say so”.

The fourth row is the one teams skip. An ordinary browser will not open the name without support, and a customer who tries may see a search page or an error. That is not a defect to fix. It is a behavior to anticipate in the copy and in what your support staff are told to say.

Here the DNS is simply better, and your launch should rely on it for what it does well. Your ordinary domain remains the address that works for everyone, in every browser, and it remains the address for email. The onchain name is an addition for the contexts where it resolves, such as names in wallets. Launch copy that presents it as a replacement for the web address will generate support tickets on day one.

Finally, freeze the records: a record changed after testing has, in effect, not been tested.

The fallback: launching without the name

The decision gate only works if what lies on the other side of it is acceptable. Write the fallback at the mandate stage and treat it as a deliverable.

There are two reasonable fallbacks, and they are not equally good. Moving the launch is not one of them: a name rarely justifies it.

Launch on the DNS alone. The product launches with its ordinary domain and its ordinary payment details. Nothing is lost that customers were promised. The onchain name is added later as a product update if the acquisition completes. For most launches this is the right fallback, because it involves no compromise on the brand.

Launch on a name under a shared suffix. Your organization registers a name under a TLD it does not hold, where one is open to registration. This is available quickly, but the name is under somebody else’s TLD, on their terms, and moving customers from it to .yourbrand later means changing a name people have already saved. Use it only when the onchain function is essential on day one.

There are also launches where the gate should be reached on purpose, early. If the name has no function on launch day, if your customers do not use the wallets where it resolves, or if the only argument for it is that it looks modern, the plan above is effort without return. Acquire the TLD on its own calendar, or leave it. A launch is a bad reason to rush a decision that has no deadline of its own.

Put the decision gate on your launch calendar

Take your launch plan and add six lines to it, one per milestone in the backward plan, each with a date and an owner. Start with the date by which the token must be in your custody wallet, and work back from there to the decision gate. If the gate falls in the past, you have your answer for this launch, and you can still pursue the TLD without the date attached.

Then ask your security and finance leads how long a custody wallet and an onchain payment would take to approve, and have the one-paragraph fallback agreed by whoever owns the launch.

If you want the approach made for you, this is work Hush Partners takes on under mandate: we find and approach the holder, the exchanges sit under a mutual NDA, and a single named partner stays with the file until the escrow closing. The page on brand namespace recovery describes that service, and the desk is reached through the contact form on the site.

Questions people ask

Can we announce the name before the TLD is transferred?

You can, but you would be announcing something a third party still controls. If the acquisition then fails or slips, you have a public promise and a counterparty who has read it. The safer order is custody first, announcement second.

What if the TLD we want turns out not to be registered at all?

Then there is no holder to approach, and the question becomes one of registering it with the registry on its published terms. The backward plan shortens considerably, since the approach and negotiation phases disappear, but custody, activation and testing take the same time as before.

Should the launch agency hold the TLD while the campaign runs?

No. The holder is whoever controls the wallet, and only the holder can issue names. An agency can prepare content and a list of names, but the token belongs in a wallet your organization controls, under your own approvals, from the day of closing.