A wallet does not contain coins. It manages the secrets that authorize changes to a blockchain ledger. That distinction matters because every storage decision is really a decision about who can sign, how they recover access, and which failures they can survive.
Key, address, seed phrase: three different things
- A private key signs transactions. Anyone who obtains it can normally spend the assets it controls.
- A public address is safe to share for receiving funds. It does not grant spending authority.
- A recovery phrase is a human-readable backup from which a wallet derives many keys and addresses. It is usually more powerful than any one private key.
A hardware wallet keeps signing material inside a dedicated device, but it does not make a bad transaction safe. If the screen shows the attacker’s address and you approve it, the device has correctly signed the wrong intent. Security therefore includes transaction review, device integrity and recovery—not only key storage.
Four custody models and their failure modes
| Model | Best fit | Main failure | Control that matters |
|---|---|---|---|
| Exchange custody | Active trading capital | Insolvency, freeze, account takeover | Small working balance, strong account and withdrawal controls |
| Software wallet | Small operational balance | Malware, phishing, malicious approval | Dedicated profile/device and strict transaction review |
| Hardware wallet | Long-term individual storage | Seed theft, bad backup, supply-chain or user error | Offline backup plus tested recovery |
| Multisignature | Material treasury or shared control | Bad signer policy or coordinated loss | Independent devices, locations and recovery procedure |
Choose from a threat model, not a slogan
Write down what you are protecting against before choosing a wallet:
- Amount and time horizon. A week of trading collateral and a five-year reserve should not share a custody policy.
- Required access. Frequent signing increases exposure; rare access increases the chance that recovery is neglected.
- Likely adversary. Phishing, device theft, coercion, fire and operator error require different controls.
- Recovery owner. Decide who can recover access if you are unavailable, and what evidence they need.
“Not your keys” describes counterparty risk, not a complete security plan. Self-custody swaps institutional risk for operational risk. The right question is which risk you can understand, monitor and recover from.
A backup that can actually be restored
- Generate the wallet on a trusted device and verify the receive address on the signing device.
- Record the recovery phrase offline. Do not photograph it, email it, paste it into cloud notes or type it into a website.
- Store backup and device separately so one theft, flood or fire does not remove both.
- For an additional passphrase, document the policy separately; losing it can make the seed backup useless.
- Perform a recovery rehearsal with a fresh wallet and a trivial balance before relying on the setup.
Confirm the asset, network, destination and memo/tag if required. Send a small test, wait for final credit, then send the remainder. Re-check a destination after copy/paste: clipboard malware specifically replaces addresses. Treat a new network or bridge as a separate risk decision.
Exchange and API keys are custody controls too
Use phishing-resistant two-factor authentication where available, a unique password, withdrawal address allowlists and separate API keys per bot. A trading key normally does not need withdrawal permission. Restrict IPs where operationally possible and define how keys are revoked after an incident. The smallest useful permission set limits the blast radius of a leak.
Primary references
The Bitcoin developer guide to wallets explains networked, signing-only and hardware-wallet roles. The Ethereum accounts documentation distinguishes user-controlled keys from contract accounts. Use protocol documentation to understand mechanics; use your own threat model to choose controls.