Wallets, recovery material and signing systems

A wallet is the software and, sometimes, hardware used to discover positions, construct transactions and arrange signing. Assets remain represented in the network's state; they are not files stored inside the wallet application. Some wallets contain private keys, while others observe balances or coordinate external signers.¹

A hierarchical deterministic wallet derives a family of keys from common starting material. BIP 32 defines one widely used derivation scheme. A single wallet can therefore manage many addresses without independently backing up a new random key for each one.²

A recovery phrase, often called a seed phrase, is a way to represent recovery material. Under BIP 39, mnemonic words and an optional passphrase are used to derive a seed. The phrase, passphrase and a device's local unlock PIN serve different purposes.³

A backup is not complete merely because someone has written down words. Recovery depends on the wallet's actual design and on retaining the additional information that design requires.

Separate observation, construction and authorisation

An institutional design can separate three functions:

In practice, an online operations system can construct a proposed transaction and pass it to a separate signing device or approval team. Bitcoin's PSBT format is one way to coordinate that process. It carries transaction information between participants; it does not certify that the payment is commercially correct.⁴

An observation system can also derive addresses without holding equivalent signing authority. That is useful for reconciliation, but the information can reveal linked activity and must still be protected. Recovery can require more than one key: the team may also need the wallet's derivation rules, scripts, other signers and the policy describing how they combine.²⁵

A recovery test succeeds only when the authorised team can reconstruct control of the intended assets under the intended policy. Seeing an empty wallet after entering apparently valid recovery words may mean that a passphrase, derivation path or other required information is missing.³

The practical question is: can an authorised recovery team reconstruct the ability to spend the intended assets under the intended policy? Restoring the same software interface is not the objective.

Follow one wallet from setup through recovery

Suppose Maya creates a new wallet on a clean device. The wallet generates recovery material, derives signing keys and presents a receiving address. Maya stores the recovery material separately and sends a small test amount to the address. The network records the resulting transaction and output or account balance; it does not record “Maya's phone owns this asset.”

Maya later pays a supplier. Her wallet constructs the instruction, the relevant derived key signs it, and the network assigns transaction status to the submitted transaction. Six months later the phone fails.

If Maya still has the complete recovery material and knows the required wallet design, passphrase and derivation information, she can install compatible software on another device, reconstruct the same signing authority and rediscover the recorded assets. Restoration does not transfer the assets. It recreates the ability to observe and authorise changes to the positions already recorded by the network.

If the recovery material is incomplete and no other authorised signer exists, installing the application again cannot recreate the missing secret. The wallet interface is replaceable; required signing authority may not be. A successful recovery test therefore ends with a controlled test transaction under the intended policy, not merely with an application displaying a familiar account name.