# The first ninety days after acquiring an onchain TLD
> Securing the TLD, deciding who may issue names, publishing a first presence and putting payments and agents under the name, in a sensible order.
Source: https://hush.partners/first-90-days-after-acquiring-a-tld
Category: Acquiring
Published by Hush Partners.
---
You have just acquired an onchain TLD. The token is in your wallet, the registry record is public, and a small group of people inside your organization is asking what happens next. The answer matters more than it might first appear: an onchain TLD that sits unused protects the name and nothing else. Without decisions about issuance, governance and presence, the namespace stays in its least useful state, an empty shell with your brand on it.
This article gives you a phased plan for the first ninety days. It is organized as three blocks of thirty days, each with a single governing goal, a manageable list of actions and a short check before you move on. Some decisions in the first block are irreversible or expensive to undo, and they deserve more care than the later ones. Other decisions can wait, and knowing which ones can wait is as useful as knowing what to do first.
The plan works regardless of which use you have in mind: internal infrastructure, customer-facing names, payment addresses, AI agent identities or all of the above. It scales down to a two-person team and scales up to a group that operates in several countries with external counsel involved.
## The three-phase plan at a glance
The table below is the whole quarter on one page. Each phase has one goal, and the check at the end of a phase is the condition for starting the next one. If a check fails, stay in the phase. Nothing in the later phases is worth doing on top of an asset that is not yet securely held and governed.
| Phase | Goal | Core actions | End check |
| --- | --- | --- | --- |
| Days 1-30 | Secure and govern | Wallet security, internal record, governance model, issuance register, reserved list | Wallet is properly held; governance is written and signed off; no name has been issued without a record |
| Days 31-60 | First presence and first working names | Publish a minimal website; issue the first functional names; connect payment routing | At least one name resolves in a supported wallet; the issuance register has its first entries |
| Days 61-90 | Extend to agents, subsidiaries and partners | Issue names for AI agents; coordinate with subsidiaries and partners; set measurement baseline | Every issued name has a documented purpose and owner; measurement is running |
Each phase also needs one accountable owner, a person and not a committee. The first phase is mostly about custody and authority, so it usually sits with whoever answers for the organization's digital assets, working with legal. The second phase is operational and suits the team that runs your web and payment infrastructure, with the brand team approving what is published. The third phase involves other parties, so it goes back to the function that signs agreements with subsidiaries and partners. Write the three names next to the three phases before the quarter starts. A phase without an owner tends to end without its check being run.
## Days one to thirty: secure, record and decide the rules
The first priority is not publishing anything. It is making sure the asset is properly held and that the people responsible for it have agreed on who controls it and how.
**Confirm wallet security first.** On Freename, a TLD is recorded onchain as a token held in a wallet. The wallet that holds that token controls the TLD. If the wallet is a personal wallet used for other purposes, move the TLD to a dedicated wallet, ideally one governed by a multisignature arrangement, meaning that more than one key-holder must approve any transaction before it executes. The number of required signers and who holds the keys is a governance decision. Make it explicitly, write it down and store it alongside your other corporate records. Losing control of the wallet is equivalent to losing the TLD.
**Record ownership in the right place.** The registry record is public and anyone can check it on a block explorer. That public record is authoritative for onchain purposes. Internally, the TLD should also appear in your IP register or digital asset schedule, with the date of acquisition, the address of the wallet where it is held, the name of the person or team responsible for it and the names of the signers. If your organization has a custody policy for digital assets, this TLD falls under it.
**Establish legal standing.** Your own counsel decides how the acquisition interacts with any existing trademark registrations, pending applications or coexistence agreements. If your brand name is already protected in the relevant classes and countries, the onchain TLD is a complementary asset. It operates outside the ICANN DNS and is not a domain name in the traditional sense, so the two need not conflict, but the relationship is worth documenting. Counsel should also confirm whether the TLD needs to appear in any regulatory filings or group-level IP disclosures. The rules vary by country, and nothing here is legal advice.
**Decide the governance model before you issue a single name.** Only the holder of a TLD can issue names under it. That means the first governance question is who inside your organization may authorize a new issuance. For a TLD that matches a brand, the answer is usually a small group (legal, IT and the brand team acting jointly), and it needs to be on paper before anyone asks for a name. Undocumented authority tends to create a dispute later.
The [activation roadmap](/activation-roadmap) tool can help you structure these decisions before the first team meeting.
## The issuance register: who holds what and why
Once governance is agreed, you need a register. This is not a technical system. For a small operation it can be a maintained spreadsheet. What matters is that it is kept current and that it is the single source of truth.
Setting up the issuance register
Create the register before the first issuanceDo this on the day the governance model is agreed, not after the first name has been issued. Retroactive documentation is harder and less reliable.
Record every name, its purpose and its holderEach row shows the name issued, the date, the wallet it was issued to, the business purpose (for example a payment name for the accounts receivable team, a website for a product line, an identity for a procurement agent) and the person who requested it.
Record who approved itLog the name of the approver and the date of approval. If approval required sign-off from several functions, note each one. This record becomes evidence if a name is later disputed inside or outside the organization.
Assign a review cycleEach entry carries a next-review date. A name that is no longer in active use is flagged for a decision: keep it, repoint it or retire it, within what the registry's terms allow.
Reconcile with your IP scheduleAt each quarterly review, compare the issuance register with your broader IP or digital asset schedule, so that the names under the TLD are visible to the people responsible for the overall portfolio.
The register also serves a practical function when a counterparty asks whether a name was really issued by you. Every issuance is recorded onchain, so the public record shows that the name exists and where it points. The register gives your own team the internal audit trail that corresponds to that public record: the reason for the name, the request and the approval.
A register is only as good as its discipline at the edges. Decide in advance what happens to a request that arrives outside the process, for example a team that asks an engineer directly for a name. The simplest rule is that no name is issued until its row exists, with the approval filled in. That rule costs a few minutes per name and removes the need to reconstruct history later.
## Reserved names that should never be issued without senior sign-off
Not all names under your TLD are equivalent. Some carry enough legal, reputational or operational weight that their issuance should require a higher threshold of approval than the ordinary governance process.
Reserved names typically fall into a few categories. Positional names such as `ceo.yourbrand`, `legal.yourbrand` and `ir.yourbrand` carry implicit authority and could mislead counterparties if issued without care. Names that correspond to regulated functions, such as compliance or treasury, may have specific obligations attached in some countries. Names that mirror subsidiaries or partners need careful coordination to avoid implying an authority that has not been granted. And names that are near-matches for your core brand or product names should sit on the reserved list even if you do not intend to issue them, because issuing one unintentionally is easy once issuance has become a routine task for the people who operate the holder's wallet.
The reserved list does not need to be long. The goal is not to freeze the namespace but to ensure that the names with the highest stakes require a deliberate decision and not a routine one.
Sign-off for a reserved name should also be more than a formality. Ask the requester to state who will control the wallet the name points to, what a counterparty is expected to conclude on seeing the name, and what the organization would do if the person or team behind it changed. If those three answers are not clear, the name stays reserved.
## Days thirty to sixty: a first public presence and the first working names
With governance in place, you can issue the first names. Start with the names your organization will actually use in the next quarter, not with a comprehensive namespace plan. Two or three well-chosen names with clear purposes are more useful than thirty names issued to placeholders.
### A minimal website
Freename's website builder lets a holder build pages and publish them to IPFS, a distributed file storage system in which content is addressed by its own cryptographic hash and not by a server location. The site is then reached through your onchain name in browsers that support it. Support is partial. Onchain names resolve outside the ICANN DNS root, so an ordinary browser does not open them without help. A Freename name under your TLD can be reached in Bitcoin.com Wallet, in MetaMask by way of Freename's resolver, and in a desktop browser once the Freename Web3 extension is installed. Coverage changes as wallets and browsers add support, so do not promise universal resolution to counterparties, and do not remove your conventional web presence. The onchain site is an addition, not a replacement. The page on [what is live](/whats-live) lists the supported environments with their sources.
A minimal site at this stage might carry the organization's name, a brief description of what the TLD is for and a pointer to your main website. It does not need to be elaborate. Its job is to show that the TLD is active and purposeful, not to serve as a primary web property.
### The first functional names
[Onchain names can resolve in wallets](/onchain-tld-wallets), which makes them useful as human-readable identifiers for payment addresses. Instead of sharing a raw wallet address, which is a long string of hexadecimal characters, you give a counterparty `pay.yourbrand` or `treasury.yourbrand`. A name is easier to communicate and to check by eye, and it reduces the risk of an error when an address is copied.
### Payments to a name, and how counterparties verify them
Routing a payment to a name instead of a raw address is one of the most immediately practical uses of an onchain TLD. The mechanics are worth understanding before you ask a counterparty to use a name.
When a name is issued and configured to point to a wallet address, anyone with a compatible wallet can resolve that name to the underlying address before sending funds. A counterparty who wants to verify that `pay.yourbrand` points to the address your finance team gave them can do so independently, without asking you: the registry record is public and anyone can check it on a block explorer.
That check works best when it has something to be compared with. For a first payment, give the counterparty both the name and the address through a channel they already trust, such as the contract itself or an existing supplier portal, and ask them to confirm that the name resolves to that address. From then on, the name is the reference. On your side, treat any change to where a payment name points as a controlled change: it goes through the same approval as an issuance, it is recorded in the register, and the counterparties who use the name are told before it takes effect and not after.
[shaka](https://shaka.deal) is an onchain payment router that takes this one step further: a payment link can pay out to a name instead of a raw address, and the split between parties is agreed and signed onchain before funds move. It routes funds and does not hold them.
Before asking any counterparty to pay to a name, confirm that their wallet resolves Freename names. Coverage is partial and you should not assume it. Test the flow end to end with a small amount before relying on it for material transactions. The page on [payments to a name](/onchain-tld-payments) goes further.
## Days sixty to ninety: agents, subsidiaries and partners
By the end of the second phase, you have a working governance model, a populated issuance register and at least one name in active use. The third phase extends the namespace to other actors: AI agents that operate on the organization's behalf, subsidiaries that need identities under the parent's TLD, and partners who are granted a name as part of a commercial relationship.
### AI agents
ERC-8004, titled "Trustless Agents", is a draft Ethereum standard. It defines three registries: an identity registry in which each agent is an ERC-721 token pointing to its agent card, a reputation registry holding feedback from those it worked with, and a validation registry holding independent checks of its work. For a ninety-day plan the caveat is simple: the text is a draft that may change, and the way naming registries plug into it is still evolving. What is already useful is the principle. An AI agent that carries a name under your TLD, say `procurement.yourbrand`, can be identified as operating under your organization's namespace, and since only the holder of the TLD can issue names under it, that is a meaningful signal to counterparties before any standard is final. The page on [identities for AI agents](/onchain-tld-ai-agents) follows the subject.
For the first quarter, keep agent names few and specific. Give each one a register entry that names the human owner of the agent, the task it performs and the limit of what it may commit the organization to. A name tells a counterparty whose agent it is. It does not tell them what the agent is authorized to do, and your agreements should not let anyone assume otherwise.
### Subsidiaries
If your organization has subsidiaries or operating divisions, the third month is a good point at which to decide whether they receive names under the parent's TLD or whether one of them needs its own. The practical answer depends on how distinct the subsidiary's brand is from the parent's. A wholly owned subsidiary that shares the branding can receive a name under the parent's TLD with modest governance overhead. A subsidiary with a distinct brand or a different regulatory context may warrant its own TLD and its own governance. That is a decision for your counsel and your brand team.
### Partners
Issuing a name to a partner is an act of delegation. The partner will use that name to identify itself or to receive payments, and counterparties will associate it with your namespace. Before issuing, confirm in writing what the name may and may not be used for, how long the arrangement is intended to run, and what happens to the name if the commercial relationship ends. Add those terms to the issuance register alongside the name itself.
The end of the relationship is the part to settle first. What you can do with a name once it has been issued depends on the registry's terms and on which wallet holds the name, so check both before you issue and do not rely on being able to take a name back. Where the purpose allows it, a name that stays in a wallet your organization controls and merely points to the partner's address is easier to unwind than a name handed over outright. Either way, the agreement and not the technology is what decides the question.
## Announcing, or not
You do not have to announce that you have acquired a TLD, and for many organizations the right answer in the first ninety days is not to. An announcement invites questions from journalists, brand-monitoring services and competitors that you may not be ready to answer.
The more useful question is what your first public presence signals, and to whom. If the TLD is internal infrastructure (identities for systems and agents, payment routing between entities of the same group), there may be no reason to announce it externally at all. If the TLD will eventually be customer-facing, a quiet start with a small group of chosen counterparties is a better first step than a press release.
If you do choose to communicate, the most defensible position is a factual one: you hold the TLD, names under it identify your systems and teams, and you are building out its use progressively. That is accurate, modest and hard to challenge. The [namespace watch](/namespace-watch) service monitors the names of a brand onchain. It is worth having that running before any external communication, so that you know what else is visible alongside your TLD.
Not announcing is different from concealing. The registry record is public, so anyone who looks can see that the TLD exists and which names have been issued under it. Prepare a short holding statement in the first month, agreed by legal and communications, for the case where someone asks before you are ready. It should say what the TLD is for in one sentence and say nothing about plans that are not yet decided.
## What to measure, and what to leave for later
At ninety days, the measures that matter are simple. They are not traffic or commercial measures, which come later. They are governance measures.
The questions to answer at the end of the first quarter are these. Is every issued name in the register? Does every entry have a named owner and a documented purpose? Has any name been issued outside the governance process? Is the reserved list up to date? Is the wallet security model still correct?
If those questions have clean answers, the namespace is under control. That is the goal for the first quarter.
A few operational figures are worth starting to collect at the same time, because a baseline taken now makes later decisions easier. Count the names issued and the names refused, and note the reasons for refusal. Record how long a request takes from being raised to being approved, since a slow process is the usual reason people go around it. Keep the result of each resolution test: which name, in which wallet or browser, on which date, and whether it worked. And count the payments received to a name against those received to a raw address for the same purpose. None of these needs a target yet. They need a starting point.
Leave for later: royalty activation, pricing for any names you might open to third parties, integration with customer-facing systems, and any expansion of the namespace beyond the names you are actively using. If you later open `.yourbrand` to outside registrants, Freename's royalty program pays you, as holder of the TLD, a share of each registration fee for the names registered under it; that share is advertised at up to half and is subject to the registry's current terms and activation conditions. The TLD has no annual renewal fee, but taking part in the program carries an annual cost set by the registry, so the income is not free of charge. It is worth understanding before you need it, but it has no bearing on the first quarter if third-party registration is not yet part of your plan. The [subname revenue calculator](/subname-revenue-calculator) lets you test assumptions about issuance when you are ready to think about it.
How to build a longer activation schedule from that baseline is the subject of the [post-transfer activation](/post-transfer-activation) service.
## Common mistakes in the first quarter
**Issuing names before governance is documented.** The first request for a name under the new TLD often arrives early, sometimes before the internal record is complete. Without a documented process, the decision about who can approve it defaults to whoever is asked first, which is rarely the right person.
**Conflating the TLD with a conventional domain.** An onchain TLD does not work in every browser, it does not carry the same legal treatment as a domain name in the DNS in every country, and it is not a substitute for your existing web presence. Organizations that treat it as a drop-in replacement find that resolution gaps create confusion quickly. State the limits honestly to internal stakeholders from the start, including the plain fact that for reaching the general public through a browser, the DNS is simply better.
**Issuing without a register.** Some teams issue five or six names informally in the first weeks, on the assumption that they will document them afterward. The documentation rarely catches up, and the result is a namespace that no one can fully account for. The register is not bureaucracy. It is the mechanism that makes the asset manageable.
**Giving wallet access too broadly.** Because the wallet that holds the token controls the TLD, wallet access is a control question and not a convenience question. Every additional person with access is an additional point of exposure. Limit access to the people who have a defined operational need for it, and review the list of signers when someone changes role or leaves.
**Treating the first ninety days as a full deployment.** The first quarter is a foundation phase. Its output is a secure asset, a working governance model and a small number of names in active use. Organizations that try to build a complete namespace strategy, launch a customer-facing service, integrate several partners and announce publicly within the same ninety days tend to end up with none of those things done well. Sequence matters.
**Skipping the reserved list.** It is easy to overlook until a name that implies authority has been issued in error. The list costs almost nothing to maintain, and it is much harder to write after the fact.
## Starting the next phase
At the end of ninety days you should have a TLD that is securely held, governed by a written policy, documented in a register and in active use for one or two working purposes. That is a complete first phase.
The next step is concrete: hold a review on day ninety with the three phase owners, run the five governance questions against the register, and decide which single extension comes next. The candidates are customer-facing names, more websites, more agent identities or opening registration to third parties. They have different questions and a different pace, and choosing one is better than starting all four.
Putting a TLD to work after the transfer is part of what Hush Partners does, as a private desk for onchain TLDs. If you want a second reading of your governance model or your plan for the following quarter, the desk is reached through the contact form on the site. If your acquisition has not closed yet, the plan above starts on the day the token arrives in your wallet, and the first thirty days can be prepared before then.
## Questions people ask
### Do I need to activate the royalty program immediately?
No. The program only matters once third parties register names under your TLD. For a TLD used for internal infrastructure or for names you issue yourself, activation can wait until you have an issuance policy. When you reach that point, read the registry's current terms and activation conditions first, because they are what determines what you receive, and ask what the annual cost of taking part is. Some TLDs were registered under earlier terms that include the program for life. If you acquired such a TLD, confirm with the registry whether those terms passed to you, ideally before the acquisition closes.
### Can the TLD be held by a company and not by an individual?
Yes, and for most organizations it should be. The token sits in a wallet, and that wallet can be controlled by the company under whatever signing policy it applies to its digital assets. How the holding is documented for corporate, accounting and tax purposes varies by country. Your custody policy and your counsel determine the right structure.
### What happens to issued names if the TLD is later transferred or sold?
Names already issued remain recorded onchain. What a new holder of the TLD can and cannot change about them depends on the registry's rules, so do not assume either answer. This matters when you acquire a TLD that already has names under it, and it matters when you plan your own issuance: names granted to partners or outside parties are commitments that a future holder would have to honor or renegotiate. Keep the terms of each one in the register so that they can be disclosed in a later transaction.
### Is an onchain TLD the same as an ICANN dotBrand?
No. An ICANN dotBrand is a top-level domain applied for through ICANN's formal process and delegated in the DNS, so it resolves in every standard browser. An onchain TLD resolves outside the ICANN DNS root, and only in environments that support it: specific wallets, browser extensions and compatible resolvers. The two have different costs, timelines, governance obligations and resolution coverage. The [dotBrand and onchain TLD comparison](/dotbrand-vs-onchain-tld) sets them side by side.