Losing access to a TLD: prevention and real recovery

A TLD on a registry such as Freename exists as a token recorded onchain, and that token sits in a wallet. Whoever controls the wallet’s private key controls the TLD: the right to issue names under it, to transfer it, to receive whatever share of registration fees the registry’s royalty program provides under its terms, and to configure the records it carries. No registry customer-service team can reset that key, and there is no password-recovery flow. If the key is gone for good, the TLD stays where it is, visible on the blockchain to anyone and out of reach of everyone.

This article is for the people responsible for making sure that does not happen. It maps the realistic scenarios through which access is lost, explains what recovery means in each case, and lays out the organizational and individual measures that reduce the risk to a manageable level. It also covers succession, rehearsal, and what to do in the first hours of a suspected loss. After reading it, you will be able to walk into a board-level conversation about key custody with something concrete to say.

One preliminary note on language: a “private key” is the cryptographic secret that authorizes transactions from a wallet. In most consumer wallets it is represented as a seed phrase, a sequence of ordinary words generated when the wallet is created. Anyone who holds the seed phrase holds the key. The two terms are used interchangeably below.

Why this is not a forgotten password

A forgotten password is an identity problem. The service that issued the account can verify your identity through other channels and issue a new credential. The credential itself is stored on the service’s servers; you were never the only copy of it.

A lost private key is a possession problem. The key is not held anywhere except where you chose to store it. There is no server-side copy. The blockchain records what the key authorizes, not who is entitled to hold it, so it offers no mechanism to reissue a key to the person who lost it. Proving who you are, however convincingly, changes nothing: the network checks a key, not an identity.

The practical consequence for a TLD holder is plain. Open a block explorer and the registry record is there, public and checkable by anyone, locked out or not. That record will show your TLD, the wallet that holds it, and the names issued under it. None of that information helps you move or use the TLD if you no longer control the wallet. The asset is not destroyed; it is frozen. If the seed phrase is lost and no device holds a usable copy of the key, the token remains at its address indefinitely.

For an organization, this is also a business-continuity problem, not merely a technical one. A TLD that cannot be operated issues no names, earns nothing, and cannot be transferred or sold. Any activation work that depends on the holder’s wallet, such as issuing names or updating the records they carry, stops at the point where control over the wallet lapses. Names already issued may keep working as configured, but nobody can change them or add to them. The glossary defines the key terms if any of the concepts above are unfamiliar.

The four scenarios that produce a loss

Most losses share a common shape: an organizational failure that precedes, and causes, a technical one. Knowing which scenario you are in determines what, if anything, can be done.

Scenario one: the person leaves. A developer, an IT manager, or a founder held the wallet in personal custody. They leave the organization, voluntarily or not, and either take the seed phrase with them, fail to hand it over, or never documented where it was kept. The wallet still exists. The TLD still exists. Nobody in the organization can sign a transaction.

Scenario two: the device fails. The seed phrase was never written down separately from the device that generated it. The device is lost, stolen, wiped by an IT policy, or fails without a backup. Hardware wallets can fail physically like any other device; if the seed phrase existed only there, the failure of the device is the loss of the key.

Scenario three: the backup is unreadable. A seed phrase was written down, but the paper deteriorated, the safe was damaged, the password manager account is itself locked out, or the document is in a format nobody can open. A variant is the backup that is intact but unreachable: a card in a physical safe is durable, but only if someone still knows where the safe is and how to open it after a key person departs.

Scenario four: a dispute among signers. In a multisignature wallet, one that requires approval from more than one key before any transaction can proceed, a deadlock occurs when signers disagree or when too many of them become unavailable. Consider a fictional two-of-three arrangement in which one signer has died and a second is in litigation with the organization. The third signer alone cannot act, and the TLD is frozen until the human dispute is resolved.

The table below maps each scenario to its primary prevention measure.

What recovery means in practice

The word “recovery” covers three distinct situations, and they should not be confused.

The first is restoring from a backup: the seed phrase still exists somewhere, even if nobody has used it for a long time. The wallet can be restored from the seed phrase in a compatible wallet application. The token never left the blockchain; what was missing was access to the key. This is the most benign form of “loss”, because access returns without any change to the onchain record. A harder variant is the key that exists only on a damaged drive or a laptop that no longer starts. A data-recovery specialist may or may not be able to retrieve it, and nothing about the outcome can be assumed in advance.

The second is signer replacement in a multisignature wallet. Recovery here is a process, not a single event: the loss is detected, a new signer is proposed, the required approvals are collected, and the change is finalized with an onchain transaction. If the wallet was set up with a recovery mechanism in advance, such as a separate recovery key that can act only after a delay, that path may be available. If it was not, the remaining signers must together meet the signing threshold, remove the lost key, and add a replacement. If the remaining signers cannot meet the threshold, the wallet is locked.

The third is total loss: the seed phrase is gone, there is no multisignature arrangement, no recovery mechanism was configured, and no copy of the key survives on any device. A private key cannot be regenerated by anyone. No registry and no court order changes this, because there is nothing for either to act on. The TLD remains at the wallet address.

The three situations differ in one respect that matters more than any other: when the decisive work was done. In the first two, somebody prepared before the loss, by keeping a backup or by configuring a wallet that tolerates a missing signer. In the third, nobody did, and nothing done afterward can substitute for it.

Organizational prevention: structure, documentation, and governance

An organization holding a TLD should treat wallet custody the way it treats any other high-value credential: with clear ownership, documented procedure, and tested controls.

Multiple signers. The most effective structural control is a multisignature wallet. It is a smart contract, a program recorded onchain, that holds the asset and releases it only when a set number of designated keys approve. A single lost key no longer means a lost asset. A two-of-three or three-of-five arrangement is a common choice: enough signers that one departure or device failure does not block operations, but not so many that routine transactions become difficult to execute. The design depends as much on recovery planning and signer policy as on the choice of software.

Signers should be chosen by role, not by person. The role of “TLD signer” should be assigned to a position (the head of infrastructure, the general counsel, a designated board member) so that when the individual changes, the handover protocol is already written.

Documented procedure. Write a one-page custody document that states the wallet type and address, the identity of each signer and their signing device, where each signer’s backup seed phrase is stored, the signing threshold, and who is authorized to initiate a signer change. The document records where backups are kept, never the seed phrases themselves. It should be stored in a location that survives the departure of any single employee, not in a personal drive or a password manager account held by one person.

Handover protocol. Every time a signer leaves the organization, the handover should be a formal step with a checklist: confirm the departing signer’s key is removed from the wallet, confirm a replacement signer is added and their key is backed up, and confirm the remaining set can still meet the signing threshold. This step is as important as returning an access badge. It is also the step most easily skipped, because on the day someone leaves the wallet still works and nothing appears to be wrong.

Separation of backup storage. Seed phrase backups for different signers should be stored in different physical locations. Sound cryptography does not protect a multisignature wallet whose backups all sit in the same drawer: one fire, one flood or one break-in then removes several signers at once.

For organizations that have acquired a TLD and are building out operations, custody belongs at the top of the plan, before any names are issued. The activation roadmap tool builds a launch roadmap for a newly acquired TLD, and post-transfer activation is the service that covers putting a TLD to work once the transfer is complete.

A rehearsal that tests the recovery chain

A documented procedure that has never been tested is an assumption. A custody rehearsal on a regular cycle, once a year for example, turns it into a known quantity. The goal is not to simulate a full loss, but to verify that every step in the recovery chain works when a person other than its author follows it.

1. Locate every backupConfirm that each signer's seed-phrase backup can be physically retrieved. Note any backup that cannot be located within a defined time window and treat it as a gap to close.
2. Restore one wallet in isolationUsing a test wallet that holds no live assets, have one signer restore access from a seed-phrase backup alone, on a clean device. Confirm the wallet application shows the expected address.
3. Execute a test transactionPropose a transaction of negligible value from a test multisignature wallet and collect the required approvals from different signers, using their normal signing devices. Confirm the transaction succeeds.
4. Simulate one signer being unavailableRepeat the test transaction with one signer excluded. Confirm that the remaining signers can still meet the threshold. If they cannot, the threshold or the number of signers needs adjustment.
5. Review and update the custody documentUpdate the custody document to reflect any change in signer identity, device, or backup location. Have the responsible officer approve it, and store the updated version in the designated location.

The rehearsal should leave a brief written record: who participated, what was tested, what gaps were found, and what was done to close them. That record is useful for internal governance and for any due-diligence review if the TLD is later sold or transferred. A counterparty preparing for escrow and transfer will want confidence that the seller’s control over the wallet is real and exercised, not theoretical.

Two points make the rehearsal worth its time. First, run it on test wallets wherever possible, so that the wallet holding the TLD is touched only when the procedure requires it. Second, rotate who performs each step. A rehearsal that always relies on the same person tests that person’s memory and tells you nothing about the scenario in which that person is the one who has left.

Prevention for the individual holder

An individual holding a TLD in personal custody faces a different set of risks. There is no organization to share the burden of key custody, but there is also less complexity. The failure modes are simpler and so are the controls.

Write the seed phrase down. Not only in a password manager, not in a document on the same device as the wallet, not in a photograph on a phone. On paper or on a durable medium such as a metal backup plate, kept in a physically secure location. A single copy is not enough: keep at least two, in different locations.

Use a hardware wallet for any TLD worth protecting. A hardware wallet keeps the private key on a separate physical device and signs transactions without exposing the key to the computer or the network it is connected to. The device can be lost or damaged; the seed phrase backup restores access. A hardware wallet combined with a durable offline backup of the seed phrase is the baseline for serious individual custody.

Tell someone where it is. A backup that is secure but known to nobody fails the moment you cannot retrieve it yourself. At minimum, one trusted person should know that a TLD exists, that it has value, that a backup is stored somewhere, and roughly where. They do not need to know the seed phrase itself; they need to know enough to find it if something happens to you.

Consider a personal multisignature wallet. For an individual whose TLD carries significant value, a two-of-three arrangement with keys spread across a personal hardware wallet, a second device kept off-site, and a trusted third party offers the same structural protection as an organizational setup. The price is added complexity, and complexity is itself a risk for a person acting alone: an arrangement you do not fully understand is easier to lock yourself out of than a single well-kept key.

If the value of the TLD is the open question behind your custody decisions, the private valuation form is a starting point.

Succession and incapacity

Succession planning for a digital asset is ordinary practice for any asset of value. A TLD held in personal custody presents a particular difficulty: an executor has no account statement to find and no institution to write to, and the means of access, the seed phrase, does not pass by legal instrument alone. A will can state who is entitled to the TLD. It cannot give that person the ability to move it.

Include the TLD in your estate plan. Your legal counsel should know the TLD exists and should have a way to locate the seed-phrase backup after your death or incapacity. This does not mean giving a lawyer the seed phrase; it means making sure the executor or a designated trusted person can find it. A letter of instruction kept with your will, stating the location of the backup and the steps needed to use it, is a practical solution. The rules on digital assets in an estate vary by country, and your own counsel decides what fits your situation.

Consider a delayed recovery mechanism. Some smart-contract wallets allow a separate key, held by a trusted person or institution, to replace a signer after a defined waiting period. The delay is the safeguard: it gives the primary holder time to cancel a replacement that should not happen. Configured in advance, this can serve as an incapacity measure. Its availability and behavior depend on the wallet, and it should be included in the rehearsal like any other part of the arrangement.

Multisignature as a succession tool. Adding a trusted family member, a business partner, or an adviser as a co-signer on a two-of-three arrangement in which you hold two of the keys is a form of succession planning. They cannot act alone, and you keep full operational control while you are able to use your keys. If you become incapacitated, the co-signer and whoever is entitled to your second key can, with the documented procedure in hand, manage or transfer the asset. For funds and family offices that hold TLDs as part of a broader portfolio of digital assets, this structure should be reviewed alongside the rest of the custody framework.

What to do in the first hours of a suspected loss

Suspecting a loss is not the same as confirming one. The first priority is a rapid, methodical check before treating the situation as a confirmed loss.

Check the documented locations first: the password manager, any note-taking application, the drawer or safe where physical backups were supposed to be kept. A suspected loss is sometimes no more than a backup stored somewhere inconvenient and not found on the first look.

Check the device. If the device that held the wallet still works, even partially, the wallet application may still be installed and usable. Treat a device in that state with care: do not reset it, update it or reinstall anything until the key has been backed up or the search has ended. A wallet application that shows the address but cannot sign does not restore access by itself, but it confirms which wallet is concerned and narrows the search to the seed phrase.

Check with other signers. In a multisignature wallet, contact every other signer without delay. Establish who can still sign, confirm they have access to their keys and devices, and assess whether the threshold can still be met. If it can, the situation is operationally stable even if one signer is lost, and the replacement of that signer becomes a planned operation.

Check the block explorer. Loss and compromise are different problems. If the concern is that a key has been copied or stolen, not mislaid, look at the public record for any transaction you did not authorize. If the TLD has moved without your authorization, write down the transaction reference and the destination address; that is evidence, and your legal counsel should be informed before any further step is taken. If the TLD has not moved but a key may be exposed, the question for the remaining signers is whether to replace that key or move the asset to a wallet whose keys are not in doubt.

Be wary of unsolicited offers of help during these hours. A person who has just lost access is an obvious target for anyone claiming to be able to restore it, and no legitimate helper needs your seed phrase to tell you what your options are.

If the loss appears confirmed after these checks, the next steps depend on which scenario applies. Where a physical device is involved, a data-recovery specialist may be worth consulting, with no assurance of a result. For a dispute among signers, start the governance procedure documented in the wallet’s operating rules. For any TLD of material value, inform your legal counsel at this stage: the consequences of a confirmed loss may include notices to counterparties or a review of related commercial arrangements, and counsel decides what applies in your country.

Clean custody at the point of transfer, and a next step

If a TLD is to be sold or transferred, whether because an organization is rationalizing its holdings or an individual has accepted an offer, the custody question becomes a closing question. The registry record is public and anyone can check on a block explorer which wallet holds the TLD. What the record cannot show is whether the seller can still operate that wallet. A seller who cannot act when the time comes will face delays and may lose the transaction.

Closing through onchain escrow on an aftermarket assumes that the seller’s wallet works on the day. An organization that rehearses its custody and keeps its custody document up to date can proceed without surprises. One that does not may discover the gap at the least convenient moment. No closing process can substitute for custody controls that should have been in place from the start.

The concrete next step is small. Write the one-page custody document described above, even if what it reveals is uncomfortable: a single signer, one backup, nobody else informed. Then set a date for the first rehearsal. Every other measure in this article follows from those two actions.

Hush Partners is a private desk for onchain TLDs: it acts under mandate, and one named partner follows a file from first note to closing. The page for holders describes how the desk works with them, and the desk is reached through the contact form.

Questions people ask

Can a registry reverse a transfer or restore access on my behalf?

A registry does not hold your private key and cannot sign for you. A completed onchain transfer stands as recorded. Whether a registry has any administrative measure available in a case of theft depends on its own terms, and you should read them before you need them instead of counting on one. None of this is a criticism of registries: holding the token yourself, with no intermediary able to move it, is the property that makes the asset yours.

Is it safe to store the seed phrase in a password manager?

A password manager reduces the risk of forgetting where the seed phrase is, but it introduces a different one: the password manager account is itself a single point of failure. If the account is lost, compromised, or closed, the seed phrase goes with it. For a TLD of significant value, an offline backup on a durable medium lasts better. If a password manager is used at all, it should never hold the only copy.

What does a multisignature wallet cost in practice?

Setting one up involves a network fee for recording the smart contract onchain, which varies with the blockchain used and with how busy the network is. The ongoing cost is coordination: each transaction needs several signers to approve, which takes longer than a single-key wallet. A TLD is rarely moved, so the coordination falls mostly on the rehearsal and on signer changes. Whether that is proportionate is a judgment about the value you place on the TLD.

How should a TLD appear in a will or trust?

Control over the asset is cryptographic, not administrative, so naming a beneficiary does not by itself deliver the asset. The document that matters in practice is the letter of instruction described above, kept where the executor will find it and updated whenever the backup moves. In a trust or a company structure, the equivalent is the custody document, with trustees or officers as signers by role. Your own counsel advises on how this interacts with the rules of your country, which vary considerably.

What if a TLD was acquired but custody was never properly set up?

This happens after a quick acquisition or an internal project handover. The TLD sits at a wallet address, but the documentation is incomplete and nobody is sure who can sign. The first step is an internal audit: identify the wallet address from the public registry record, establish who created the wallet, and determine whether the seed phrase still exists and where. Once the current state is understood, a move to a properly governed multisignature wallet can be planned, and rehearsed on test wallets before the TLD itself is moved.