Cryptocurrency Wallet Recovery Workflow
This workflow helps choose which branch of work fits the wallet material you actually have, and what a result does and does not confirm. Preservation and identification come first, because acting without them can create an additional loss; after that, only the branches the case needs are worked, often in parallel.
- Preserve every wallet source and identify the wallet type first; acting before that can create an additional loss.
- The seven stages are a frame, not a mandatory sequence; a valid seed or a working wallet can make whole branches unnecessary.
- Container recovery and credential search often run in parallel after preservation.
- A seed-derived address match supports account correspondence; a balance lookup or watch-only view does not establish signing authority.
- If a secret may have been exposed, plan a move to a new trusted wallet after verifying access; a spend is not the first test.
Seven stages as a frame, not a checklist
Preserve, identify, acquire, unlock, reconstruct, verify and secure are useful names for the kinds of work a wallet case can involve. They are not seven operations every case has to pass through in order. Two of them do come first: preserving every surviving source and identifying what the material actually is. Working without them — unlocking the only copy of a container, migrating a wallet file in place, or entering a phrase into an unfamiliar tool — can create an additional loss on top of the original one.
After that, the case decides which branches apply. A surviving seed may allow reconstruction without ever recovering the old container. A wallet that still opens on its original device may allow an authorized export or backup without any password search. When a container is missing and its password is also uncertain, recovering the container and searching for the credential often run in parallel rather than one after the other.
Choose the branch from what you have
The useful question is what material survives and what is missing. The table is a starting point; real cases often combine rows, for example a seed of uncertain completeness alongside an encrypted file.
Scroll horizontally to see the full table →
| What you have | What is missing | Next branch | What confirms progress |
|---|---|---|---|
| A valid seed (and any passphrase it used) | The original container or device, and possibly the account and path details | Reconstruct on trusted, compatible software; container recovery becomes optional. See Wallet Seeds, Derivation Paths and Account Reconstruction | Derived addresses match a known address |
| An encrypted wallet file or keystore, no seed | The password or passphrase | Preserve the container, work on copies, and run a bounded credential search. See Recovering Encrypted Wallet Files and Keystores | The copy decrypts and its key derives a known address |
| The original device or app, still unlocked and working | An independent backup | Use the app’s own export or backup functions; avoid resets, reinstalls and updates first. Record the app version | The exported material restores the expected accounts elsewhere |
| A watch-only wallet, xpub or public descriptor | Any private key or signing seed | Look for the signing source (seed, key, hardware wallet); the public data only shows the account | Not spending authority — visibility only |
| A multisig policy with only some signers | Enough signers to meet the threshold, or parts of the policy | Confirm threshold and policy first. See Multisig Wallet Recovery and Descriptors | Policy reproduces known addresses; signers meet the threshold |
| Only an exchange or custodial login | Access to the provider account | The provider’s official account-recovery process; this is not seed recovery | The provider restores account access |
Preserve every source without multiplying secrets
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. Keep a protected master copy and controlled working copies, as in Recovery Copies, rather than scattering extra plaintext copies of secrets.
Do not upload a seed phrase or private key into web forms, chats or public diagnostics, and do not accept a request to share one “as an example”. Extended public keys and address history are less dangerous but not harmless: they do not normally allow signing, yet they reveal the wallet’s history to whoever receives them.
Identify the wallet before interpreting anything
Establish the wallet family and version, the chain and network, the seed format (BIP39, Electrum, SLIP39 or none), and whether each account is deterministic, imported, watch-only or part of a multisig setup. A seed phrase, a local wallet password, a BIP39 passphrase and a device PIN are four different things: under BIP39 the passphrase is an input to the seed itself, while a local password usually only encrypts stored data. Imported accounts matter here too — as a product-specific example, MetaMask’s help article says that restoring with the Secret Recovery Phrase brings back only accounts created from that phrase, while imported and hardware-wallet accounts have to be re-added separately. How to reproduce the right account from a seed is covered in Wallet Seeds, Derivation Paths and Account Reconstruction.
Acquire storage only when material is missing or inaccessible
If the wallet material is already in hand, skip acquisition. If a wallet file, keystore or app data exists only on deleted, failing or damaged storage, that is ordinary data recovery first: preserve an unstable device before any scan, as described in How to Image a Failing Drive Safely. On an encrypted phone, an ordinary raw image does not guarantee access to app secrets, which may be bound to that device’s secure hardware and state; see Mobile Device Recovery State and Board-Level Preservation.
Unlock and reconstruct are alternatives, often parallel
Password or passphrase recovery against an encrypted container runs on a duplicate, never on the only surviving copy; container formats, KDF cost and repair are covered in Recovering Encrypted Wallet Files and Keystores. Reconstruction from a seed is a different route to the same funds: the derivation convention, account, address type, any passphrase and any imported or multisig accounts all have to match, which Wallet Seeds, Derivation Paths and Account Reconstruction explains. Neither route has to wait for the other to finish, and one succeeding does not make the other’s material worthless until access has been verified.
Training scenario: password unknown, but a seed and a known address survive
An encrypted wallet file is intact, but its password is not known. The owner also has a written seed phrase and one known receiving address from the wallet’s history.
The seed is a possible alternative route that avoids a password search. Whether it reproduces this wallet’s account is not yet known — it might belong to another wallet, or need a passphrase or another derivation convention.
Keep the single container untouched, with hashed copies. Offline, in compatible software, reconstruct from the seed and check whether the known address appears. Continue any credential search on a copy only if the seed route does not match.
A match confirms that the seed reproduces that address, not that every account the old file held has been found. The container stays preserved until that is settled.
What a recovery result actually confirms
Separate four claims, because reaching one does not imply the next. A transaction ID or a balance confirms public context — that certain addresses hold or held funds — not possession of a private key. In Bitcoin Core’s descriptor language, a public key or xpub can stand where a private key would, so a descriptor can fully describe a wallet’s outputs while holding no signing material. A successful watch-only restore is therefore not spending recovery.
Scroll horizontally to see the full table →
| Level | What supports it | What it does not establish |
|---|---|---|
| Container preservation and structural checks | The working copy matches the preservation hash, so it is unchanged relative to that copy; a structural parse finds the format’s expected parts | That the original container was intact before acquisition, that a parse caught every kind of damage, or that the password is known and the keys inside are the expected ones |
| Credential correctness | The copy decrypts, or the wallet’s own check accepts the credential | That the decrypted key belongs to the expected account |
| Account and address correspondence | Keys or a seed derive a known, previously observed receiving or change address | Anything beyond the verified account and addresses: other accounts, imported keys, unscanned address ranges or, in multisig, the other required signers |
| Spending authority | The private key, or enough signers plus the policy for multisig, is held in a trusted signer and derives the matching keys | Not shown by a balance lookup, a transaction ID, or a watch-only import of an xpub or public descriptor |
Secure the outcome
If the recovered seed or key may have passed through an unfamiliar tool, computer or service, treat it as potentially exposed and plan a move to a new wallet created in a trusted environment. Plan it after access has been verified, with the destination, network and address type checked and fees considered; a spend is not the first test of a recovery. In a multisig wallet, confirm the threshold and policy before planning any movement. Transaction steps differ by chain and wallet, and this page does not give a universal procedure.
Do not let a later stage alter the only surviving source needed for an earlier one.
Technical references: BIP39 — mnemonic and passphrase produce the seed · Bitcoin Core: output descriptors — scripts and key origins, public or private keys · MetaMask Help: missing accounts after SRP restore — derived vs imported accounts. The MetaMask article is a product-specific example, and descriptor syntax is as implemented in Bitcoin Core; other wallets differ.
Related: Recovery Copies · Data Recovery Workflow · Validating Recovered Data · Wallet Seeds, Derivation Paths and Account Reconstruction · Recovering Encrypted Wallet Files and Keystores · Multisig Wallet Recovery and Descriptors · Mobile Device Recovery State and Board-Level Preservation · Cryptocurrency Wallet Recovery