Who holds the keys: custody of an onchain TLD

An onchain TLD is not an entry in a registrar account that an administrator can reset with a support ticket. It is a token held in a wallet, and whoever can operate that wallet can move the token. Once a transfer is confirmed, the token sits at the new address, and a blockchain transaction cannot be reversed by the party who sent it. An organization should plan as if there were no help desk behind the asset.

That fact changes how an organization should prepare before it closes an acquisition. The legal work (due diligence, trademark clearance, contract drafting) is necessary, but it does not answer the question that closing day will ask: which address receives the token, and who controls that address? An acquisition that leaves this open has left its most important decision to chance.

This article helps you choose a custody model, assign the right people to the right roles, separate the power to hold the TLD from the power to decide which names exist under it, define what needs one approval and what needs several, and write the short internal policy that keeps the arrangement working after the deal closes. The technology is a means to an end. The governance comes first.

Why custody is the real ownership question

In the traditional domain system, control lives in a registrar account. Losing the password is inconvenient, not catastrophic: the registrar can usually verify identity and restore access. An onchain TLD works the other way around. In Freename’s registry, the TLD exists as a token recorded onchain, and that token sits in a wallet. The address shown in the registry record is the holder, and the record is public: anyone can look it up on a block explorer, a public index of blockchain activity.

Two consequences follow. A contract, a board resolution or a court decision may establish who is entitled to the TLD in the eyes of the law, but none of them moves the token. Only a transaction approved from the holding wallet does that. And the reverse also holds: a transaction approved from the holding wallet moves the token whether or not anyone inside the organization authorized it.

Custody is therefore not an IT task to complete after closing. It is the governance question the acquisition raises, and it needs an answer before the transfer instruction is given. Whoever controls the wallet controls the namespace: the ability to issue names under it, any royalty the registry’s terms attach to it, and the capacity to transfer it again. Everything else depends on that.

There is one more reason to treat custody as ownership. A Freename TLD carries no annual renewal fee, so no yearly invoice will remind the organization that it holds the asset. A domain portfolio is revisited at every renewal cycle. An onchain TLD can sit untouched for years, which is convenient, and which also means that nobody will notice a custody arrangement that has quietly stopped working until the day it is needed.

Three custody models and what each implies

An organization that holds an onchain TLD is using one of three approaches: a single-key wallet, a multisignature wallet, or a custodian. Each distributes control, resilience and effort differently.

A single-key wallet is controlled by one private key, the secret that authorizes transactions, held by one person or on one device. It is the simplest arrangement and the fastest to act on, but it concentrates everything in one place. If the key is lost, if the keyholder leaves, or if the device fails, the organization may lose access to the asset. It is also the model that fits least well with ordinary internal control, which rests on no single person being able to dispose of a significant asset alone.

A multisignature wallet (multisig) executes a transaction only after a set number of approvals from a set group of keyholders. A common arrangement is two of three: any two of the three designated signers must approve before the token moves. Control is shared, and the loss of one key or the absence of one person does not stop the organization from acting. The price is coordination, and the need to keep the group of signers up to date as people change roles.

A custodian is a third party that holds or co-holds the key material on the organization’s behalf, under contract. The organization remains the owner in law while the provider carries key operations and recovery. The price is dependency on that provider, and the selection work that comes with it: what the contract says about ownership, what happens if the provider stops operating, whether it supports the blockchain and the type of token concerned, and how regulation treats such providers, which varies by country.

Most organizations that hold a TLD as a brand or strategic asset will find a multisig the sensible primary model, sometimes with a custodian as one of the signers. A single-key wallet suits a test or a very short holding period before any name exists under the TLD, and little else.

The choice also determines what you can later show an auditor. A single-key wallet shows that a transaction happened, and nothing about who decided it. A multisig shows which signer addresses approved each transaction. A custodian adds its own reporting. None of the three records why a decision was taken, which is the job of the internal log described further down.

Who should be a signer, and who should not

Choosing signers is a governance decision that looks like a technical one. A good signer meets three conditions at once: authority to act for the organization, the practical ability to approve a blockchain transaction without error, and availability when a decision cannot wait.

For most organizations, the group is two or three people from functions with a direct interest in the TLD, typically legal or brand protection, treasury and a senior technology role. A custodian may be added as one signer for continuity. This is the familiar principle of dual control, applied to a new kind of asset: the people who can dispose of it are few, named, senior, and never one alone.

Several kinds of person should not be signers. A staff member with no authority over the asset creates a mismatch: the wallet will accept the approval, but the organization never sanctioned it. Outside counsel should not be a signer unless the organization has delegated that authority in writing and counsel has accepted it knowing what it involves in practice. People who pass through roles quickly, such as secondees and contractors, bring turnover that weakens continuity. Auditors should stay outside the signer group so that they can review it independently.

Two signers who report to each other are, in practice, close to one. So are two signers who keep their keys in the same office or travel together. The purpose of several approvals is independence, and independence has to be real: different reporting lines, different places, different devices.

The threshold matters more than the number of signers. Two of three tolerates one unavailable signer and keeps coordination light. Three of five suits an organization that wants stronger separation of authority or that operates across several countries. Whatever the threshold, write it down, have it approved at the right level of authority, and review it once a year.

The legal entity behind the signers

A wallet has no legal personality. It is an instrument, and the entity whose officers control it is the one that holds the TLD in practice. In a group of companies, that entity should be chosen deliberately, and the choice should match the purchase agreement.

The natural candidate is usually the entity that already owns the trademarks and the domain portfolio, because the TLD will be managed alongside them and by the same people. A different choice is possible, for instance an operating company that will run the namespace commercially, but it should be made on purpose and recorded.

The entity’s own rules on delegated authority then apply to the wallet. If two officers must approve the disposal of an asset above a certain value, the signer threshold should not be lower than that. If a board resolution is required to acquire the asset, the same resolution can name the holding wallet and the first signers. How a token of this kind is classified for accounting and tax purposes varies by country, and your own counsel and auditors decide. The custody policy only needs to say which entity holds the TLD and under which internal authority.

Separating the right to hold from the right to issue names

The wallet that holds the TLD token is the final control point of the namespace. On Freename, the power to issue names under a TLD belongs to its holder and to nobody else. Technically, then, holding and issuing sit in the same place. The separation an organization needs is one of roles: who decides that pay.yourbrand should exist is a different question from who can move .yourbrand itself.

Deciding which names are issued, to whom and on what conditions is a business function. It belongs to a brand manager or a product owner, working within a naming plan that has been approved. Executing that decision is an act of the holding wallet, and so it passes through the signers. The business owner requests, the signers check the request against the plan and execute it. Neither role can do the other’s work, which is the purpose of the arrangement.

This division does three things. It limits the consequences of a mistake: an error in the naming plan can produce a wrong name, but it cannot move the TLD. It lets the organization give day-to-day responsibility for the namespace to a product team, an agency or a namespace operator without giving any of them the power to transfer the TLD token. And it produces a cleaner record, because every issuance has a request on one side and an execution on the other.

Do not design around a second wallet with narrower permissions to which issuance could be delegated. On Freename, only the holder of a TLD manages it, and management cannot be handed to another address. An AI assistant connected through MCP is no exception: it acts as the holder, so connecting one is a decision about the holding wallet and belongs with the signers. The request-and-execute procedure above is therefore the control.

The same reasoning applies to royalty. Freename runs a royalty program under which a TLD’s holder is paid a portion of the registration fee each time a name is registered under that TLD, advertised at up to half, and dependent on the registry’s current terms and on activation conditions. Who activates the program, where the proceeds are received and who reconciles them are decisions for the policy, not habits to form afterwards. So is who budgets for it: although the TLD itself has no renewal fee, taking part in the program carries an annual cost set by the registry. A custody policy written for an acquired TLD should also record one check made with the registry before closing: certain TLDs were registered under earlier terms in which the program is included for life, and it has to be confirmed whether such terms pass to a buyer. For brand protection and legal teams, the mapping onto existing practice is direct: the holding role resembles the registrant of a domain, and the naming role resembles its technical contact.

Approvals: what needs one person and what needs several

Not every action on a TLD deserves the same level of authorization. Tiers designed in advance prevent both paralysis and action by one person alone.

A workable framework has three tiers. The first covers reading: checking the registry record on a block explorer, reviewing how names are configured, producing reports. It needs no approval, because it creates no transaction.

The second covers routine operation inside an approved plan: issuing a name that the naming plan already provides for, or updating the records of an existing name. One named role, typically the brand or namespace manager, can approve the request. Where the action has to be executed from the holding wallet, the signers execute it on the strength of that approval and confirm only that it falls within the plan. Their task at this tier is verification, not a second business decision.

The third covers custody events: moving the TLD to another wallet, changing the signers or the threshold, selling or transferring the TLD, and any action that changes who controls the holding address. These need the full threshold, a written record of the business reason and, depending on internal rules, a countersignature from legal or treasury. No one should be able to start a third-tier action alone.

An approval inside a wallet shows that the required keys were used. It does not show that the organization agreed. The written policy is what connects the two: it states in plain language which approvals are legitimate, so that a transaction can later be compared with the decision that authorized it.

Continuity: departures, loss, succession

For a conventional asset, the departure of the person who managed it is an administrative matter. For an asset held in a wallet, it can decide whether the organization still has access. If the number of available signers falls below the threshold and nothing was planned, the organization may be unable to act on its own TLD.

A continuity plan covers three situations.

A planned departure

A signer announces that they are leaving or changing role. The organization has time to add a replacement, confirm the new signer group in the wallet, remove the outgoing signer and record the handover. The change is a third-tier action and is logged as one. It should be complete before the person’s last day, not after.

An unplanned absence

A signer becomes unavailable without warning, through illness, sudden resignation or a dispute. The remaining signers must still be able to reach the threshold without that person. This is the practical argument for keeping the threshold clearly below the number of signers, and for replacing an absent signer promptly so that the margin is restored.

Loss below the threshold

Enough signers become unavailable at once that the threshold cannot be met. The organization needs a procedure prepared in advance, known to a senior officer, that states what to do: who is informed, which backup arrangement exists, and who may invoke it. The design of that backup depends on the custody model and should be settled with the people who set up the wallet. What matters for governance is that it exists, that it has been approved, and that using it leaves a record.

Review the list of signers on a fixed schedule and after every reorganization. A plan that names people who left two reorganizations ago gives no protection.

Succession also covers corporate transactions. If the organization merges, is acquired or restructures, the TLD does not follow by itself. It stays at the address where the token is until a deliberate transaction moves it, so the transaction documents should name the TLD, the holding wallet and the steps for handing over control.

Records and audit: what to log

Onchain transactions are public, and the registry record can be checked on a block explorer at any time. That transparency is useful, but it covers only what happened onchain. The organization’s own records must hold the context that the blockchain does not.

A minimum internal log for a TLD contains:

• the address of the holding wallet and the day custody began;
• the legal entity that holds the TLD and the internal authority for it;
• the identity, role and contact details of each signer, and the threshold in force;
• each change of signer or threshold, with its date and who authorized it;
• each third-tier approval, with its business reason and the signers who approved;
• each name issued under the TLD, with the request that led to it;
• a reference to every legal document behind a change: purchase agreement, escrow record, board resolution.

A multisig leaves a trace of which signer addresses approved a transaction. The log ties each address to a person and each transaction to a decision. An auditor should be able to pick any transaction from the public record and find the matching entry, and to pick any entry and find the matching transaction. An entry with no transaction, or a transaction with no entry, is a finding.

Treat the log as a critical-asset record and keep it on the same retention schedule as trademark and domain registration records. The registry record shows the state of the TLD. The log explains why the state is what it is.

The policy document: one page, its headings

An organization that holds an onchain TLD needs a written custody policy, and it does not need to be long. One page, approved by the right authority (general counsel, the chief information security officer, the treasurer, or several of them together), gives the arrangement institutional standing and makes continuity possible when people change.

A workable one-page policy has seven headings, in roughly this order.

Asset identification. The TLD, the registry on which it is recorded, the legal entity that holds it, the address of the holding wallet and the day custody began.

Custody model. The model in use (multisig, custodian or a combination), the threshold, and the names and roles of the signers.

Approval tiers. A short table that maps types of action to the approvals they require. Three tiers are enough.

Names and royalty. Who decides which names are issued, under which naming plan, who executes the issuance, and who is responsible for the royalty program if it is activated.

Continuity and succession. The procedure for planned and unplanned signer changes, where the instruction for a loss below the threshold is kept, and the senior officer authorized to invoke it.

Audit and review. Where the log is kept, who maintains it and how often it is reviewed.

Amendment. Who must approve a change to the policy, and at what level of authority.

Update the policy whenever a signer changes, the threshold changes or the TLD is involved in a corporate transaction. A policy that describes an arrangement that no longer exists misleads the people who rely on it, which is worse than having none.

Preparing custody before closing day

The custody arrangement must be ready before the transfer executes. Settling it on closing day, or afterwards, invites the improvised decision by one person that the policy is meant to prevent.

1. Decide the custody modelAgree on a multisig, a custodian or a combination, and on the legal entity that will hold the TLD. Record the decision and who made it. This belongs in due diligence, not after signing.
2. Name and confirm the signersName the signers, obtain each person's explicit agreement, and check that each one can approve a blockchain transaction in practice.
3. Establish the walletCreate the holding wallet with the agreed threshold. Test it with a transaction of negligible value on the same blockchain as the TLD before closing.
4. Settle who decides on namesName the role that will own the naming plan and write down how its requests reach the signers. Do not plan on a technical delegation to another address: on Freename, only the holder manages the TLD.
5. Approve the custody policyCirculate the one-page policy and obtain approval before the transfer date, so that the arrangement has standing from the first moment.
6. Confirm the destination addressGive the address of the holding wallet to the other side through the agreed channel, and have a second person compare it character by character before funds or instructions are released.
7. Verify receipt and open the logAfter the transfer, check on a block explorer that the token is at the right address. Make the first entry in the log: the day, the transaction reference and the signers in place.

Step six deserves its place. An address is a long string that people copy, paste and retype, and an error in one character sends the token somewhere else. The control is the ordinary four-eyes check: a second person, a second channel, and a last comparison immediately before the transfer executes.

How the closing itself runs is a separate matter from custody. The page on escrow and transfer describes that stage. Your part is to arrive with a destination address that the organization controls and a policy that says so.

Once the TLD is in the right wallet under the right governance, the next questions are configuration, resolution and what the namespace is for. The Launch Roadmap tool helps to order those decisions. They are distinct from custody, and they depend on custody being settled first.

Draft the policy before the transfer instruction

Write the custody policy now, even as a rough draft, and put it in front of the people who would approve it. A draft forces the decisions: which entity holds the TLD, who the signers are, what the threshold is, who owns the naming plan. Once those are made, the address that goes into the transfer instruction follows from them.

The timing depends on where you are. If your organization has not yet identified the holder of the TLD it wants, a buy-side mandate is the stage at which custody should enter the plan, alongside the legal and commercial preparation. If you have received a note from the desk about a TLD, the same holds before you answer on price. When a file runs through Hush Partners, one named partner follows it from the first note to closing, and closing runs through onchain escrow on an aftermarket. The destination address is yours to supply, and the custody behind it is yours to govern.

After the transfer, putting the TLD to work starts from the custody arrangement you have set up. The glossary defines the technical terms used here. Governance prepared before closing is a short piece of work for a few people. Reconstructed after a problem, it is longer, and in the worst case there is nothing left to reconstruct.

Questions people ask

Does the organization need to understand blockchain technology to hold a TLD?

Not as an institution. The policy and the approvals are organizational matters that need no technical expertise. Setting up the wallet and approving transactions do need someone who can do so without error. Those two functions can belong to different people, and it helps when they do.

Can the TLD be moved out of a multisig wallet if the organization changes its mind?

Yes. Moving the TLD to another address is itself a transaction that needs the threshold, so the governance that prevents an unauthorized transfer also governs an authorized one. The organization can restructure custody, including a move to a custodian, as long as enough signers are available to approve it.

What happens to royalty when the TLD sits in a multisig?

The royalty program belongs to the registry and follows its current terms and activation conditions, so how and where proceeds are received is a question to check with the registry’s documentation. From a governance point of view, the aim is that finance can account for the proceeds without needing the power to move the TLD. Decide this as part of activation planning, and record it in the policy.

Is a custody policy legally required?

That depends on the country, the sector and the frameworks your organization already works under, and your own counsel decides. The case for the policy does not rest on a legal requirement: it establishes authority, makes continuity possible and creates the record that an auditor or a successor will need.

What if the TLD arrived in the wrong wallet before custody was arranged?

If the wallet can still be operated, even when it is the personal wallet of an employee, the remedy is a deliberate transfer to the organization’s wallet, authorized in writing and logged. If access to the wallet has been lost, the options are few: the registry record remains public and can be checked on a block explorer, but the token does not move without the key. This is the reason custody is settled before the transfer and not after it.