Cryptocurrency Wallet Recovery Workflow
Wallet recovery fails less often from a missing secret than from working the stages out of order — unlocking before preserving a copy, or reconstructing before identifying the actual seed format.
Seven stages, in order
Wallet recovery goes wrong less often because a secret is truly gone than because the steps get worked out of sequence — unlocking a container before making a copy of it, or trying to reconstruct a wallet before confirming what seed format it actually is. The useful order is preserve, identify, acquire, unlock, reconstruct, verify, secure. Each stage assumes the ones before it are already done.
Preserve every surviving secret source
Before anything else, copy and set aside every wallet file, browser profile, exported key, seed fragment, paper or metal backup, old phone or computer, hardware device and password hint that might be relevant — including ones that seem redundant or outdated. It is far easier to discard something irrelevant later than to recreate a source that got overwritten during troubleshooting.
Identify the wallet family before interpreting anything
A seed phrase, a wallet password and a device PIN are not interchangeable, and neither are BIP39, Electrum and SLIP39 backups. Establish which wallet software or device created the material, what blockchain and account type it covers, and whether it is deterministic, imported or part of a multisig setup, before treating any of it as evidence about what the wallet should contain. See Wallet Seeds, Derivation Paths and Account Reconstruction.
Recover the storage layer only if a container is actually missing
If the wallet file, keystore or app data still exists somewhere — deleted, on a failing drive, in an old backup — that is ordinary data recovery, and the same imaging-first discipline as the rest of this catalog applies before anything wallet-specific happens. Skip this stage entirely when the container is already in hand.
Unlock strictly from copies
Password or passphrase recovery against an encrypted container should run against a duplicate, never the only surviving copy of the file. See Recovery Copies for why, and Recovering Encrypted Wallet Files and Keystores for the container-versus-credential distinction this stage depends on.
Reconstruct the wallet, not just the seed
A correct seed is not the end of the process. The derivation path, account index, address type, optional passphrase, and any imported or multisig accounts all have to match what the original wallet actually used, or the reconstruction will look empty even though nothing is technically wrong.
Verify against public evidence before trusting the result
Compare a derived candidate against something already known — a receiving address, a transaction ID, an extended public key — before treating a recovery as successful or exposing the secret material any further. “The wallet software opened” is not the same thing as “this is the right wallet.”
Secure the outcome
If the recovered seed or key may have passed through an unfamiliar tool, computer or service at any point, treat it as potentially exposed: generate a new wallet in a trusted environment and move the funds, rather than continuing to use the recovered credential indefinitely.
Do not let a later stage alter the only surviving source needed for an earlier one.
Related: Recovery Copies · Data Recovery Workflow · Validating Recovered Data · Wallet Seeds, Derivation Paths and Account Reconstruction · Recovering Encrypted Wallet Files and Keystores · Cryptocurrency Wallet Recovery