Skip to content
Financial Context Wiki

Cold Wallets: Offline Signing, Recovery, and Operational Controls

Learn how to design and verify cold-wallet custody across key generation, wallet identity, backups, transaction review, offline signing, multisig, recovery, and incident response.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A cold wallet is a custody system that keeps secret signing material and the decisive approval step outside the normal exposure of internet-connected software. The assets remain on the blockchain; the system controls the keys or other authority that can authorize state changes. “Cold wallet” is an operational label, not one protocol-defined device class, and coldness is a property of the complete workflow rather than a brand or connection type.

A hardware signer can support cold storage while connected by USB because the private key may remain isolated, yet the workflow is unsafe if the user signs an unverified destination or opaque contract call. Conversely, an air-gapped computer is not safe merely because it lacks a network interface: compromised entropy, installation media, transaction parsers, removable media, backups, or displays can still defeat the boundary. Cold storage reduces remote key-extraction exposure; it does not prove transaction intent, software correctness, recovery, privacy, or finality.

The recovery copy is not “just a backup.” A mnemonic, raw seed, extended private key, or equivalent recovery share may recreate spending authority and therefore needs protection comparable to a signer. A passphrase, derivation path, network, script type, wallet descriptor, key order, and threshold policy can also be necessary to recover the expected addresses. A public watch-only wallet cannot normally sign, but an xpub or descriptor can reveal address relationships and transaction history, and BIP-32 gives extended public keys stronger security implications than ordinary public keys.

cold wallet
0 / 5
0 items reviewed; 5 items still unresolved

Completing this review does not prove an asset, transaction, or system is safe.

How to design and verify cold storage

1. Define the authority and threat model

Record the exact network, asset, account or output policy, owners, beneficiaries, recovery authority, expected transaction frequency, and maximum operational exposure. Identify remote malware, malicious applications, supply-chain compromise, insider collusion, physical theft, coercion, fire, flood, loss, incapacity, and inheritance as separate threats. Decide what must remain cold: a single private key, all keys in a threshold, a quorum of signers, an EIP-712 authorization key, or an administrator capable of changing wallet code.

2. Initialize trusted entropy and software

Obtain devices and software through authenticated channels, inspect initialization state, verify releases where supported, and reject any pre-generated mnemonic or secret supplied in packaging or by a helper. Generate entropy in a controlled environment and record which standard and implementation created it. BIP-39 encodes 128 to 256 bits of entropy as a mnemonic and derives a 512-bit seed from the mnemonic plus an optional passphrase; it is not a standard for turning a memorable sentence into a secure wallet.

3. Bind the reproducible wallet identity

Before substantial funding, record the network, master fingerprint, derivation standard and full path, account index, address or script type, and first verified receive addresses. For Bitcoin policies, preserve the output descriptor, checksum, key origins, threshold, signer count, key order, and change branches. For each signer, independently confirm that its key and the displayed policy are the intended ones. Treat an xpub as sensitive metadata: it can derive non-hardened public descendants, damage privacy, and, together with a corresponding non-hardened child private key, expose the parent extended private key under BIP-32.

4. Back up and test recovery

Protect every required recovery input, including the mnemonic or shares, optional passphrase, descriptor or smart-account configuration, derivation path, and recovery instructions. Do not invent a scheme by splitting mnemonic words into ad hoc fragments; use a specified threshold or multisig design when no single copy should suffice. Place copies in genuinely independent failure domains and track access without exposing their contents. On a trusted spare or reinitialized signer, rehearse restoration and compare the expected fingerprint, policy, and receive address before wiping the test environment.

5. Construct and verify the complete intent

An online coordinator may obtain chain state and build an unsigned request, but it is untrusted. For a Bitcoin PSBT, verify the network, every input and UTXO amount, recipient output, amount, fee, fee rate, locktime, sighash policy, and whether every other output is authenticated change. For an EVM transaction, verify chainId, nonce, to, value, gas limit, fee caps, and decoded data; for EIP-712, verify the domain, chainId, verifyingContract, message fields, nonce, and deadline where applicable. EIP-712 structures data and separates domains, but the standard explicitly does not provide replay protection by itself.

6. Sign across a controlled transfer boundary

Move only the required unsigned or partially signed payload through the approved QR, card, cable, or other channel. Air gaps and QR codes do not make parsers or media trustworthy: the signer must parse the payload, authenticate policy and change, display material consequences, and refuse unsupported fields. In multisig, keep signers, operators, locations, vendors, and recovery paths independent enough to match the threat model; treat the coordinator as replaceable and unable to change the policy unnoticed. Compare the signed transaction or operation with the approved intent before broadcast.

7. Reconcile, maintain, and prepare migration

After broadcast, match the transaction identifier, included transaction, outputs or logs, actual fee, change, account nonce, allowances, and resulting balances against the signed intent, then wait for the finality appropriate to the chain and use case. Maintain compatible software, verified firmware paths, readable backups, documented descriptors, and periodic recovery exercises without entering production secrets into an online device. If any signing or recovery secret may be exposed, a plain single-key account cannot revoke that key: establish fresh authority, migrate assets and roles, invalidate remaining permissions where the protocol allows, and preserve an incident record.

Worked examples

Staged allocation and funding

A custody plan limits the online interaction wallet to 5% of 100,000 units of asset value: 100,000 × 5% = 5,000 units hot and 95,000 units cold. The cold destination first receives a 100-unit test, and the remaining transfer is 95,000 - 100 = 94,900 units. After both transfers, the cold balance target is 100 + 94,900 = 95,000 units; the small test limits one setup error but does not validate future signatures or backup recovery.

Bitcoin PSBT fee and change

A PSBT spends inputs of 0.80 BTC and 0.35 BTC, totaling 1.15 BTC. It pays 1.00 BTC to the recipient and estimates 250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC. The authenticated change must therefore be 1.15 - 1.00 - 0.000020 = 0.149980 BTC. If the signer cannot identify that change output from its recorded policy, it should not sign even when the total arithmetic balances.

EVM maximum budget versus actual fee

An EVM account begins with 5 ETH and approves a transfer of 1.2 ETH. A 30,000 gas limit and 50 gwei maximum fee imply a fee budget of 30,000 × 50 gwei = 0.001500 ETH. If the transaction uses 21,000 gas at an effective price of 25 gwei, the actual fee is 21,000 × 25 gwei = 0.000525 ETH, leaving 5 - 1.2 - 0.000525 = 3.799475 ETH. The signer must review the fee caps and data, not assume that the maximum budget will be charged or that an empty-looking interface proves an ordinary transfer.

Two-of-three signer resilience

A 2-of-3 policy with signers A, B, and C has 3 valid signing pairs: AB, AC, and BC. If one signer is unavailable, exactly 1 pair remains; if one signer is compromised, that signer alone controls 0 valid pairs; if two signers are compromised, they control 1 valid pair and can spend. The design therefore tolerates one loss or one isolated compromise, not two, and recovery still requires the correct descriptor, derivation data, and key order.

Risks and review failures

  • Wrong network or policy: a valid key restored under the wrong chain, address type, script, account, or smart-account policy can show different or unusable addresses.
  • Weak entropy: predictable randomness, a brainwallet, or a compromised generator can make an offline key guessable.
  • Supplied secret: a preprinted, imported, photographed, or helper-provided mnemonic may already be controlled by an attacker.
  • Backup exposure: paper, metal, cloud copies, printers, cameras, couriers, or estate records can leak complete spending authority.
  • Passphrase failure: a lost or mistyped BIP-39 passphrase derives a different wallet without necessarily producing an error.
  • Derivation mismatch: missing paths, coin types, account indexes, or wallet-specific conventions can hide otherwise recoverable assets.
  • Configuration loss: multisig keys without the descriptor, threshold, script type, key origins, and order may not reproduce the funded wallet.
  • Public-metadata leak: an xpub, descriptor, address inventory, or coordinator database can expose balances, relationships, and future addresses.
  • Supply-chain compromise: altered hardware, firmware, software, packaging, or update channels can substitute entropy, addresses, or signatures.
  • Host substitution: an online coordinator can replace the recipient, amount, fee, change, calldata, typed message, or unsigned payload.
  • Display limitation: truncation, blind signing, unsupported scripts, and incomplete decoding can hide material authorization.
  • Change-address attack: a Bitcoin transaction can send apparent change to an attacker unless the signer authenticates it against the policy.
  • Fee or nonce error: excessive fees, stale EVM nonces, wrong locktimes, or unintended sighash modes can delay, replace, or distort execution.
  • Persistent contract authority: token approvals, permits, modules, delegates, and administrator calls can outlive the visible transaction.
  • Transfer-channel attack: QR, USB, memory cards, cables, and parser formats can carry malicious payloads or exfiltrate metadata.
  • Correlated quorum: colocated signers, shared seeds, one vendor, one operator, or one recovery site can defeat threshold independence.
  • Physical attack: theft, coercion, surveillance, tamper attempts, and secret discovery remain possible without network access.
  • Environmental loss: fire, flood, corrosion, media decay, inaccessible vaults, death, or incapacity can make every correct secret unavailable.
  • Compatibility decay: obsolete firmware, unsupported derivation or script types, and undocumented migrations can break future recovery or signing.
  • Incomplete incident response: checking a balance without migrating keys, roles, approvals, and recovery authority can leave the original compromise active.

Common misconceptions

Does a cold wallet have to remain physically disconnected forever?

No. The security property is that secret authority remains isolated and signing occurs through a controlled, verifiable boundary. A cable-connected hardware signer may preserve that property; an air-gapped computer with compromised setup or payload review may not.

Are coins stored inside the hardware device?

No. Blockchain state records the assets. The device protects or uses authority that can sign transactions, and compatible recovery material may reproduce that authority on another implementation.

Is a mnemonic backup less sensitive than the signing device?

No. A complete mnemonic and required passphrase can recreate the wallet. A backup is normally dormant, but its compromise can be as decisive as extraction of the live signing key.

Does multisig remove the need for backups and configuration records?

No. Thresholds reduce selected single points of failure, but each key needs a recovery plan and the wallet policy or descriptor must be reproducible. Too few surviving keys or a lost configuration can still lock funds.

Does a successful test transfer prove the cold-storage system is safe?

No. It confirms a limited path at one time. It does not prove entropy quality, backup secrecy, restoration, future transaction decoding, quorum independence, software updates, contract safety, or incident recovery.

Sources

Navigation

Search the wiki...