← Back to the catalog

Cryptocurrency Wallet Recovery

Recover a cryptocurrency wallet after file damage, password loss, device failure or an incomplete seed restore. Learn which recovery path fits each failure.

Recovery decision

Wallet inaccessible: what should you do next?

Answer one question about the current state. The result suggests the safer next step rather than diagnosing the failure.

Typical source stabilityEvidence-dependent
Default action riskCritical
Default first actionPreserve secrets

This guide classifies the next recovery action from observable information. It does not diagnose hardware condition or estimate a percentage chance of recovery.

What's actually happening

Wallet state may live in a standalone wallet file, a browser or profile database, mobile application storage, a hardware wallet, exported key material, or a recoverable deterministic backup — the storage object and the signing authority are not always the same thing. A hardware wallet is a physical device that can fail, get damaged, or simply die of old age. Underneath any of these are the credentials that control the assets: private keys, or in many modern wallets a recovery seed from which keys are derived. A seed phrase may itself exist in wallet data or backups, but if every usable copy of the required secret is lost, the blockchain cannot recreate it for the owner.

How recoverable this really is

If the seed phrase itself is safe and what's actually broken is the wallet file or the hardware device, this is a genuinely good situation: a damaged wallet file behaves like ordinary file or device recovery. If the complete deterministic backup and any required passphrase or policy information survive, a failed hardware device often does not require chip-level data recovery either — the signing wallet can usually be reconstructed on compatible trusted hardware or software. But verify the derivation path, account and policy (multisig cosigners and script policy especially) before assuming the restored wallet is complete; a seed alone, without an optional BIP39 passphrase, the correct derivation path, multisig policy or cosigner information, or imported keys that were never derived from the seed, will not necessarily reproduce the expected funds. If all copies of a properly generated recovery seed or private key are lost, there is normally no cryptographic recovery path — a completely unknown, properly generated 12- or 24-word seed is not a realistic brute-force target for anyone, regardless of what a "recovery service" claims. A partially known seed, a weak user-chosen password or passphrase, or a damaged private key with a small corrupted region is a different, much narrower search problem, and tools built for exactly that — purpose-built candidate-testing software rather than anything that "cracks" a blockchain — can make it tractable.

Security matters as much as recovery

Recovered secret material is useful only if it reconstructs enough of the required signing authority for the actual wallet policy — a single-key wallet needs the one correct key, while a multisig wallet needs enough cosigners to meet its threshold plus the policy that describes it. Treat recovered credentials as secrets: avoid web forms, screenshots, cloud notes and untrusted recovery utilities, and move funds to a newly secured wallet if credential exposure is suspected.

What to preserve before experimenting

Make copies of every wallet file, device image, exported key, seed fragment, configuration file and known password variant. Record the wallet software and approximate version, any known public addresses or extended public keys (xpubs), and how the wallet was originally created or backed up — including whether a passphrase, imported key or multisig setup was involved. Do not “test” uncertain recovery material by importing it into random online services. A public address or transaction ID can verify expected blockchain history without exposing a private key or seed.

Four different recovery problems, not one

“Wallet recovery” collapses several unrelated situations into one phrase. A wallet container can go missing — a deleted wallet.dat file, a corrupted Electrum wallet, a damaged browser profile — which is ordinary storage recovery until the container itself is back. An intact container can be locked behind a forgotten password, which is a credential problem, not a file-recovery one. A known seed can fail to reproduce the expected wallet, which is a reconstruction problem covered below. And a partially remembered word, password or key is a bounded search problem, different again from any of the other three. Preserving evidence for one of these can look identical to preserving evidence for another, but the recovery path — and who's qualified to do it — is not the same.

A correct seed can still restore an apparently empty wallet

This is an easy situation to misread as a failed recovery. A recovery seed is the root of a whole tree of keys, not one address — the wallet software still has to walk a specific branch of that tree (a derivation path, in standards like BIP44, BIP49, BIP84 or BIP86) to reach the addresses that were actually used, and a different account index, address type or optional BIP39 passphrase produces a different, equally valid wallet with no error message at all. Accounts imported from a separate private key, a different seed or a hardware wallet aren't backed up by the main seed either, so a missing one doesn't necessarily mean the seed recovery failed. Before concluding a seed is wrong or a wallet is empty, see Wallet Seeds, Derivation Paths and Account Reconstruction for how to check the branch, the account and the imported-key question systematically. It's also worth confirming the phrase's own format first: Electrum uses its own versioned seed scheme and SLIP39 (Shamir) backups split a secret into threshold shares — neither behaves like an ordinary BIP39 mnemonic. Similar-looking word backups can use incompatible formats.

Browser and phone wallets don't always have one recoverable file

A browser-extension wallet can store its encrypted vault inside the browser profile's own databases rather than a single obviously-named file, so preserving the whole profile — not just files that look wallet-related — matters more than it does for a standalone desktop wallet. On a phone, recovering the application's files is not the same as recovering the wallet: Android's Keystore and Apple's Secure Enclave can both bind key material to the physical device's secure hardware, so an image of the storage can be structurally complete and still be undecryptable without that device. An unlocked, working phone is frequently worth more here than a forensic copy of a dead one.

Multisig doesn't fail the same way as a single-key wallet

A multisig wallet (a "2-of-3" setup, for example) raises two separate questions instead of one: is there still enough signing material to meet the threshold, and is the wallet's construction — the cosigner public keys, derivation paths and script policy, often captured in a descriptor — still known well enough to rediscover the exact addresses it controls? Losing one cosigner's seed out of three doesn't necessarily mean losing the funds, but losing the coordinating wallet's configuration can make an otherwise-recoverable wallet expensive to rebuild even with enough keys in hand. See Multisig Wallet Recovery and Descriptors for how to treat these as the two distinct problems they are.

The general approach

Start from what was lost and what still exists. Preserve every surviving source first, and identify the wallet family and backup format before acting on any of it. Then pick the branch that fits: a complete seed (with any passphrase) can be reconstructed on trusted software without the old file or device; an intact but locked container is a credential problem; a missing container is a storage-recovery problem first; and container and credential work can run in parallel. A watch-only view or a balance lookup is not the same as regaining the ability to spend. Verify against a known public address before trusting the result, and move funds to a new wallet if the material may have been exposed. Which branch fits which combination of material, and what each result does and does not confirm, is set out in Cryptocurrency Wallet Recovery Workflow. For an intact but password-protected wallet file or keystore specifically, Recovering Encrypted Wallet Files and Keystores covers the container-versus-credential split in more depth than fits here.

The one thing not to do

Never type a seed phrase or private key into a website, a support chat, or any third-party app or service that asks for it to "recover" or "validate" a wallet. This space attracts an unusual number of scams built specifically around that request, and handing a real secret to an untrusted party is the one action that can turn a recoverable situation into a stolen one. A legitimate restore uses verified, trusted wallet software or hardware compatible with the backup format, in a controlled environment; it does not have to be the app that originally generated the seed, but an arbitrary "recovery app" does not qualify.

Related methods: Cryptocurrency Wallet Recovery Workflow · Wallet Seeds, Derivation Paths and Account Reconstruction · Recovering Encrypted Wallet Files and Keystores · Multisig Wallet Recovery and Descriptors · Cryptocurrency Wallet Recovery Tools. The "the key exists or it doesn't" logic here is the same one covered in Locked Out of an Encrypted Volume. For a wallet app's data on a damaged phone specifically, see Phone or Tablet Data Loss. Chip-level work on a physically damaged hardware wallet is the kind of job the labs in our provider directory are built for.

This page describes the general situation, not a guaranteed fix for your specific case. If you'd rather have someone experienced take a look before you try anything, see what a hands-on evaluation looks like.