HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Wallets & recovery

How should I plan wallet recovery?

3 min read

Recovery responsibilities and permitted procedures must be defined for your deployment. Do not assume that an Explorer record, a support request, or a generic recovery example can restore signing access. Required participants and authorization gates remain specific to the wallet.

Plan for specific problems

“Recovery” can mean several things: replacing a lost device, restoring access after a credential problem, handling an unavailable participant, or responding to a departed employee. These problems may need different procedures. List the situations your organization must handle and ask which are supported by the actual wallet arrangement. Avoid relying on an assumption that someone will be able to intervene later. A recovery promise is only useful when the prerequisites and responsible parties are clear.

Keep control and availability in balance

A recovery path should help legitimate users without quietly giving another party unrestricted spending authority. Ask who can initiate the procedure, which approvals it requires, and whether old credentials or participants remain valid afterward. Also ask what happens when one of the people needed for recovery is unavailable. These questions reveal whether the normal self-custody arrangement continues to hold during an exception, rather than only during an ordinary successful transaction.

Practice without exposing secrets

Agree a non-production exercise with the responsible team. Record the scenario, the approvals, the observed result, and any dependency that prevented completion. Keep ordinary operating instructions and escalation contacts available to the people who need them, while protecting actual recovery material through the authorized process. Never paste secret shares or recovery phrases into a ticket to make diagnosis easier. A public proof can help identify a wallet or historical event, but it is not a substitute for the supported recovery authority.

In plain language

Recovery is an authority decision, not just a backup

A backup helps preserve information; a recovery process determines how access or authority can be restored when something is lost or unavailable. Those are related but different jobs. For a business wallet, the plan should say who can start recovery, what evidence they must provide, who approves it, and what old access is removed afterward. It should also explain what happens if the usual person, device, or service cannot participate. A process that quietly lets one provider replace the customer’s authority may change the practical custody model, even if everyday signing uses several participants. Do not assume a support team can override the rules or retrieve lost signing material. Ask for the supported procedure for your exact deployment and rehearse it in an agreed safe environment. Record responsibilities and escalation contacts without storing secret recovery material in the same document as ordinary operating instructions.

In plain language

Share references, not secrets

A public reference helps someone locate a record without giving them control of it. Examples include an Explorer URL, a transaction hash, a record identifier, and the network name. A secret can provide access or signing power and must be handled differently. Passwords, access tokens, recovery material, and private signing shares do not belong in a support ticket, screenshot, chat message, or public log. Even public identifiers can reveal business activity when combined with other information, so share only what the recipient needs. Before sending a screenshot, check for account details, customer names, browser tokens, and unrelated transactions. A request to “verify your wallet” does not justify revealing recovery material. Use established contact channels and the authorized account workflow. Protecting private information is compatible with transparent evidence: the goal is to demonstrate the relevant fact without publishing everything that sits behind it.

What to do next

Agree the recovery and authority model before a pilot, and test it only through an authorized workflow. Never send secrets to support.

Wallet evaluation checklist ↗Discuss deployment requirements ↗