# Succession planning for holders of onchain TLDs

> A TLD held in a wallet only you can open disappears with you. What a holder should arrange so that heirs or partners can act.

Source: https://hush.partners/succession-planning-for-tld-holders
Category: Selling
Published by Hush Partners.

---
A TLD held in a self-custody wallet is, in functional terms, a bearer instrument. Whoever controls the wallet controls the asset. There is no registrar to call, no account-recovery form, no customer service department that can read a death certificate and release access to the next person in line. Access is cryptographic, not institutional. For most purposes, that frictionless sovereignty is a feature. In the context of succession, it is the central problem.

The result is that a meaningful portfolio of onchain TLDs can stop existing, from a practical standpoint, the moment the holder becomes incapacitated or dies. The names under each TLD, any royalty income those names generate, and whatever commercial value the TLD itself carries all become unreachable. Nothing was destroyed. Simply, no one else is able to move it.

This article is for the holder who wants to prevent that outcome. It is also for the family adviser sitting across the table from that holder. It covers the practical preparation: what to document, how to structure access without creating new security risks in the meantime, what instructions to leave, which people to involve, and how to keep the plan current. The legal instruments that give those preparations force are left to your own counsel, because they depend on the jurisdiction and the structure of your estate.

## Why onchain TLDs disappear at death or incapacity

An onchain TLD on a registry such as Freename exists as a token recorded on a blockchain. The token is held in a wallet, and the wallet is controlled by whoever holds the corresponding private key: a long cryptographic string, usually backed up as a seed phrase, a short list of ordinary words from which the key can be rebuilt. There is no annual renewal fee on a Freename TLD, so there is no billing relationship that would alert a third party to the holder's absence. There is no username or password that a platform could be asked to reset.

The family is not shut out of the registry record itself: it is public, and a block explorer, a website showing what a blockchain has recorded, lets anyone check it. An heir can therefore confirm that the TLD exists and that it sits at a particular wallet address. What the heir cannot do, without the private key or seed phrase, is approve a transaction that moves the token or issues names under it. Confirmation of existence is not the same as ability to act.

Unlike a forgotten bank PIN, a lost seed phrase cannot be recovered by any third party. There is no override and no appeal. Incapacity compounds the problem. A holder who can no longer manage their affairs is still alive, so whatever process applies to an estate has not started, and nobody has yet been appointed to act. The gap between incapacity and death is precisely when a business partner or family member most needs to be able to act, and it is the period that plans most often leave uncovered.

The holder of a TLD that also issues names to third parties has an additional responsibility. Those registrants, the people or organizations who registered `pay.yourbrand` or `name.yoursector`, depend on the TLD's continued operation. Only the holder of a TLD can issue names under it, so a TLD whose wallet nobody can open is a namespace that nobody can run. The effect reaches beyond the holder's estate to every name issued under the TLD. That downstream consequence is one reason succession planning for a [TLD holder](/holders) carries more weight than it does for the owner of a single collectible token.

## The inventory: knowing what exists and where it lives

Before any other step, the holder needs a single written document that lists every onchain TLD in the portfolio. The inventory is not a secret document; it is a finding document. Its purpose is to allow someone who has never heard of onchain TLDs to understand what they are looking at and know where to go next.

Each entry in the inventory should record: the TLD string itself; the registry on which it was created; the wallet address where the token is held; the wallet type (hardware device, software wallet, or other); where that wallet or its associated device is physically located; whether the TLD has any active names issued under it; and whether it is enrolled in any royalty or revenue-sharing program. A note on approximate value, or a pointer to a [private valuation](/private-valuation) that has already been obtained, helps the executor understand whether the portfolio is material to the estate.

The inventory should also flag any TLD that is being offered for sale or that is subject to a [sell-side mandate](/sell-side-mandates). Those files may be at a stage where a counterparty is already in dialogue, and a long silence on the holder's side could affect the outcome.

Keep the inventory separate from the access credentials. The inventory tells an heir what exists; it does not tell them how to unlock it. Mixing the two in a single document stored in an obvious place creates a single point of failure. The underlying difficulty is that the information has to be both secure and discoverable, and those two qualities pull in opposite directions. Splitting the material resolves it: the inventory can be easy to find because it unlocks nothing, and the credentials can be hard to reach because the inventory explains that they exist and under whose control they sit.

Update the inventory every time the portfolio changes: a new acquisition, a transfer to a different wallet, a change in the wallet hardware. A plan built on a stale inventory sends your successors looking for assets that have moved and leaves out the ones you added.

## Access: enabling a successor without weakening security in the meantime

The hardest problem in succession planning for self-custodied assets is the access paradox. Good wallet security means that only one person, or a very small and defined group, can approve transactions. Good succession planning means that at least one other person can act if the holder cannot. These two requirements seem to contradict each other, but they do not have to.

### Shared control through a multisignature wallet

The most robust technical arrangement for a portfolio of meaningful size is a multisignature wallet, often shortened to multisig. The wallet is configured so that a transaction requires a defined number of approvals from a defined set of keyholders. As an illustration, take a wallet that needs two keys out of three. The holder retains one key. A second key goes to a trusted person (the technical helper, discussed below). A third key is held by a professional custodian or kept in secure offline storage that the executor can retrieve. No single key, standing alone, gives anyone unilateral access. The holder's day-to-day security is not weakened, because the other keyholders cannot act alone. If the holder becomes unable to approve a transaction, the two remaining keyholders can reach the threshold without them.

The arrangement has its own demands. Each keyholder must look after a key properly for years, and the loss of two keys in a two-of-three wallet is as final as the loss of a single seed phrase. Moving the TLDs into the new wallet is itself a transfer that must be done carefully. A multisig trades one risk, a single person who cannot be replaced, for a need for coordination. For a portfolio of real value that trade is usually worth making; for a single TLD of modest value it may not be.

### A sealed credential held by a trusted person

A simpler but less robust approach is a sealed envelope or encrypted file containing the seed phrase or private key, held by a trusted adviser under instructions not to open it except in defined circumstances. This works, but it places significant trust in a single person and a single physical location. It also creates a period of delay, since the envelope must be located, verified and opened, during which the portfolio is still inaccessible. And it needs maintenance: if the holder moves the TLDs to a new wallet, the sealed credential opens an empty one.

### Rehearsing before you rely on it

Whatever access method is chosen, it must be tested before the plan is finalized. A succession plan that has never been rehearsed is a hypothesis, not a plan. At minimum, the technical helper should confirm that they can find the materials, understand them, and use them to complete a test transaction on a wallet that holds nothing of value.

<aside class="callout">
<span class="callout-label">For legal teams</span>
<h4>Access credentials do not belong in the will itself</h4>
<p>In many countries a will can become a public document once the estate is administered. Ask your adviser how the legal instrument can grant authority while the technical credentials are held separately, under appropriate confidentiality controls.</p>
</aside>

## Instructions: telling the right people what you want done

Access to the wallet is a necessary condition for acting on the portfolio. It is not sufficient. A successor who can open the wallet still needs to know what to do with what is inside. "Do with it as you see fit" is not a useful instruction when the asset is an onchain TLD with active names issued under it, a pending sale negotiation, and a royalty stream.

A letter of wishes, separate from the will and addressed to whoever takes over the portfolio, should cover at minimum four things. First, whether each TLD is to be held, sold, or transferred to a named person or organization. Second, what to do with any active names issued under the TLD: whether registrants should be given notice, whether the names should be honored, whether the TLD should be wound down gracefully. Third, how to handle any sale process that is already underway. Fourth, whom to contact for assistance with the commercial side of a disposal. Whether such a letter binds anyone, or only guides them, is a question for your adviser.

On the question of disposal, the letter should note that the sale of an onchain TLD closes through onchain escrow, and that this is not the same as transferring a conventional domain name through a registrar. An heir who has never handled a wallet should not be expected to manage a closing alone. The letter can say so, name the technical helper, and point the estate's professionals toward the page [for lawyers and advisers who refer a file](/for-advisors) if a buyer needs to be found or a transaction structured.

For TLDs that are sector words or that carry an active namespace business, where the TLD functions as a market and third parties have registered names under it, the instructions should address continuity. Someone inheriting a running namespace needs to know the technical configuration, the royalty arrangement, and any commercial commitments the holder made to registrants. Where the portfolio sits inside a family structure and is managed alongside other assets, the instructions should also say who decides, since [a family office or a fund](/funds-and-family-offices) will usually have its own governance for a sale.

Write the instructions for the reader who will actually hold them. An executor reading the letter may be meeting the vocabulary for the first time. State each wish in a plain sentence, give the reason where it would help someone exercise judgment, and say what should happen if the wish turns out to be impractical. Instructions that explain their purpose survive changes of circumstance better than instructions that only give orders.

## The two people you need

A succession plan for an onchain portfolio requires at least two people who are not the holder: a technical helper and a legal one. These roles are distinct. Combining them in a single person, typically the estate lawyer, usually means neither role is well served.

**The technical helper** is someone who understands how wallets work, how a blockchain transaction is approved, how to check a TLD on a block explorer, and how a transfer is completed. They do not need to be a blockchain developer; they need to be technically literate enough to follow written instructions without improvising. This person may be a family member, a trusted colleague, or a professional who specializes in the custody and transfer of digital assets. Their job is to ensure that when the moment comes, the physical and cryptographic steps can be completed correctly.

The technical helper should receive: a copy of the inventory (not the access credentials); a written explanation of what an onchain TLD is and how a transfer works; the contact details of the desk or adviser the holder uses for commercial matters; and a clear statement of their role and its limits. They act on the executor's or trustee's instructions, and they do not make commercial decisions on their own.

**The legal helper** is the estate lawyer or adviser who makes sure that your legal instruments give someone the authority to deal with digital assets at all. Whether general wording is enough, or whether the power to access, hold, transfer and sell such assets has to be spelled out, depends on where you live and how your estate is structured. That is the legal helper's question to answer. They do not need to understand the technical mechanics of a wallet. They need to ensure that the authority exists on paper and that the right person has it.

Both helpers should know each other. A technical helper who has no idea who the lawyer is, and a lawyer who has no idea who the technical helper is, will lose time coordinating at the worst possible moment. A brief introduction, by message or in a joint meeting with the holder, costs very little and removes that delay.

## Legal instruments: questions for your adviser

The instruments that give a succession plan legal force vary significantly from one country to another. What follows is a list of questions to bring to your own counsel, not answers.

Does your will identify the TLD portfolio explicitly as a class of digital asset? Does it give the executor the authority to access, hold, transfer and sell blockchain-based tokens? Does it direct the executor to the inventory and explain where the access credentials are held, without containing them?

If you use a trust structure, does the trust document authorize the trustee to manage digital assets? Does it address wallets and private keys specifically, or does it rely on general language that may not be read to cover them? Does it distinguish the physical device that holds a key from the asset the key controls?

If you become incapacitated rather than dying, does your power of attorney, or its local equivalent, give the agent authority over digital assets? Standard forms were often drafted without these assets in mind and may not cover them without amendment.

Does your jurisdiction have specific rules on a fiduciary's access to digital assets? Some do and some do not, and where rules exist they differ. Your adviser will know what applies in your case.

Finally, if the portfolio includes TLDs held by a company rather than by you personally, the succession question is partly a corporate one: who controls the company, and does that control give the successor the practical ability to operate the wallet? Corporate and personal succession need to be planned together.

<aside class="callout">
<span class="callout-label">Note to advisers</span>
<h4>The legal side of this plan is entirely for your own counsel</h4>
<p>Nothing in this article is legal or tax advice. The instruments, the rules of each jurisdiction and the tax treatment of a TLD portfolio within an estate are matters for a qualified adviser who knows the holder's full circumstances.</p>
</aside>

## Preparing the plan: what to do and in what order

The order matters more than the speed. Each step below produces something the next one needs: the legal adviser cannot draft around an access structure that has not been chosen, and the letter of wishes cannot refer to an inventory that does not exist.

<figure class="fig">
<figcaption><b>Succession preparation for an onchain TLD portfolio</b></figcaption>
<ol class="fig-steps">
<li><b>Build the inventory</b>List every TLD, the registry, the wallet address, the wallet location, any active names, any revenue arrangements, and a pointer to any existing valuation. Store the inventory separately from the access credentials.</li>
<li><b>Decide on the access structure</b>Choose between a multisignature wallet, a sealed credential document, or a professional custodian arrangement. Document the structure clearly enough that someone unfamiliar with it can follow it without help.</li>
<li><b>Identify your technical helper</b>Choose someone technically literate, brief them on their role, give them the inventory and written instructions, and introduce them to the legal helper. Test the access process on a wallet that holds nothing.</li>
<li><b>Engage your legal adviser</b>Bring the inventory, the access structure, and the questions from the previous section. Ask whether your will, trust, and power of attorney cover digital assets with the specificity needed where you live.</li>
<li><b>Write the letter of wishes</b>For each TLD, state whether it should be held, sold, or transferred; what to do with active names; how to handle any pending sale; and whom to contact for commercial assistance. Keep it plain enough for a non-technical executor to act on it without guessing.</li>
<li><b>Tell the key people where everything is</b>The executor should know where the inventory is. The technical helper should know how to reach the legal helper. Neither should need to discover the plan under pressure.</li>
<li><b>Set a review date</b>Put a date in your calendar, no more than a year away, to review the plan against the current state of the portfolio.</li>
</ol>
</figure>

## Talking to the people who will need to act

Most succession plans fail not because the documents are wrong but because the people named in them have never spoken to each other and have no shared understanding of what is expected. A technical helper who first learns of their role when they are handed an envelope in a moment of grief is not well placed to act quickly or correctly.

The conversation does not need to be elaborate. It needs to cover three things. First, that the portfolio exists and that it has meaningful value, because successors who do not know this may not look for it. Second, that acting on it requires specific technical steps and that there is a named person to assist with those steps. Third, that there are written instructions, that they are in a specific place, and that they should be followed before anyone improvises.

The conversation with heirs who will ultimately benefit from the portfolio can be simpler still: the asset exists, it is being planned for, and here is the person to contact when the time comes. Heirs do not need to understand how a blockchain works. They need to know that someone does, and that this person is part of the plan.

For a portfolio that includes TLDs with operating namespaces, where third parties depend on the continuity of the TLD, it is worth having a brief conversation with any commercial partners or advisers who work with the namespace, so that they are aware a continuity plan exists. This is not a disclosure of the plan's details; it is a signal that the holder has thought about it.

### What they need to know, and what they must not hold yet

The table below separates the information that should be shared now, so that the plan can be carried out when needed, from the credentials that must remain under controlled access until the triggering event occurs. Sharing credentials too early creates a risk of theft or error, while withholding everything else leaves successors unable to act.

| Item | Share now with named people | Hold under controlled access |
|---|---|---|
| Existence of the portfolio | Yes: executor, legal helper, technical helper | Not applicable |
| Inventory of TLDs and wallet addresses | Yes: executor and technical helper | Not applicable |
| Commercial instructions and letter of wishes | Yes: executor and legal adviser | Not applicable |
| Contact for commercial assistance | Yes: technical helper and executor | Not applicable |
| Seed phrases and private keys | No | Released only on the triggering event set by the legal instrument |
| Location of a hardware wallet | Optionally, to the technical helper in confidence | Full access only on the triggering event |
| Multisig key held by the technical helper | The technical helper holds it now | Usable only in combination with another keyholder |

The logic of the table is simple: information needed to find the asset and understand the plan travels now; information needed to control the asset travels only when legal authority exists. This is the same discipline that separates knowing where a safe-deposit box is from having a key to it.

## Reviewing the plan as the portfolio changes

A succession plan describes a portfolio at the moment it was written. If the portfolio looks different three years later, the plan describes something that no longer exists. A holder who acquires new TLDs, moves existing ones to a different wallet structure, enters into a commercial arrangement with an operator, or starts a sale process needs to update the plan to reflect those changes.

The minimum review discipline is this: any material change to the portfolio triggers a review of the inventory and a check of whether the instructions in the letter of wishes still make sense. A scheduled annual review, independent of portfolio changes, catches the slow drift of a plan that was accurate once and has gradually fallen behind reality.

The people in the plan change too. A technical helper may move away, lose interest, or fall out of touch; an adviser may retire. The review should confirm that each named person is still willing and still reachable, and that a keyholder in a multisignature wallet still has their key.

The access structure also needs reviewing as the technology around it changes. Wallet software, multisignature configurations and hardware devices all evolve. A technical helper who was competent with the access structure when it was set up may need a short update session if the structure has since been materially changed.

If the portfolio has grown to the point where a private valuation is warranted, that valuation should feed back into the estate plan. A portfolio that was immaterial when the plan was written may have become a significant estate asset. Executors and trustees who do not know the value of what they are managing cannot make good decisions about the timing and method of a disposal.

## Taking the first step

The preparation described in this article is not technically complex. The inventory, the access structure, the letter of wishes, and the two key relationships, with a technical helper and a legal adviser, are each manageable tasks. What makes them hard is that they have to be done before they are needed, when the need still feels abstract.

The concrete first step is to write the inventory. Pull together every TLD in the portfolio, the wallet where each one is held, and a note on what each one does. That document, even in rough form, is the foundation everything else builds on. Once it exists, the rest of the plan has a subject to work with.

If the portfolio includes TLDs that you already see as candidates for sale, or if you want to understand the value of what you are planning around, the private valuation form is the starting point. Where a sale is the right outcome, during your lifetime or for the estate, Hush Partners acts for the holder under mandate, and closing runs through [onchain escrow](/escrow-and-transfer) on an aftermarket. An adviser working with a client on this can reach the desk through the contact form on the site.

A TLD portfolio that has been built deliberately deserves to be handed on deliberately. The steps are within reach of any holder, and the first of them takes an afternoon.

## Questions people ask

### Can a TLD be transferred automatically to a named beneficiary at death, without anyone needing to act?

In principle, a smart contract, a program recorded on a blockchain that executes on its own terms, can be written to move a token when a defined condition is met. The difficulty is the condition. A blockchain has no knowledge of a death, so someone trusted still has to confirm it, and the arrangement then depends on that person and on the contract behaving as intended years later. Whether such a transfer would be recognized as a valid way to pass on an asset is also a legal question for your adviser. For most holders, the more reliable approach remains a human process: a legal instrument that grants authority, a technical helper who can carry out the transfer, and an inventory that tells them what to transfer.

### Does the holder of a TLD need to do anything differently if they hold it through a company rather than personally?

Yes. If the TLD token is held in a wallet controlled by a company, the succession question is partly about who controls the company after the holder's death or incapacity. The company's own governing documents and any agreement between its owners may need to be reviewed alongside the personal estate plan. The two need to be consistent: a personal plan that leaves the company to one person while the company's documents route control differently creates a conflict that takes time and money to resolve. Your legal adviser should review both.

### What happens to names already registered under a TLD if the TLD is sold as part of an estate disposal?

Two groups of names have to be told apart. Names the estate itself holds under the TLD can be transferred with it, if the estate and the buyer agree; names sold to third parties remain theirs. On Freename, only the holder of a TLD can issue names under it, and the royalty program pays the holder a share of registration fees, subject to the registry's current terms and activation conditions. Taking part in that program carries an annual cost set by the registry, even though the TLD itself has no annual renewal fee. Where the holder registered under earlier terms that include the program for life, the executor should confirm with the registry before closing whether those terms pass to a buyer. A buyer who acquires the TLD from an estate becomes the holder of the token, with those abilities. Whether existing registrations are honored, and on what terms, is a commercial question that the estate's instructions should address. The letter of wishes should state the holder's preference, and the disposal should be organized so that registrants are not left in uncertainty for an extended period.

### Where can an adviser who is new to onchain TLDs find the vocabulary?

The [glossary](/glossary) on the site defines the terms used across the desk's work, including the distinction between a TLD and a name, what onchain means in this context, and how holding an asset in a wallet differs from holding a domain through a registrar. Reading it before the first meeting with the holder makes the inventory far easier to follow.
