Crypto custody & compliance · engineering reference
Recovery is constraint engineering. First prove the wallet is not merely scanning the wrong path; then divide the remaining candidate space by a measured guess rate and accept the answer.
Most lost wallets are not cryptographically lost. They are looking in the wrong place, or missing a piece the owner still half-remembers. This sheet is about working out which case you are in before spending money on cracking.
Usually not. A wallet derives its addresses from a path, and a different wallet or a different account setting derives different addresses from the same seed. Ruling out a wrong derivation path resolves a large share of cases before any cracking starts.
It depends entirely on how much you still know, and the range spans about twelve orders of magnitude. One missing word in a known position is a couple of thousand candidates. A forgotten passphrase of four random words is beyond any hardware. To the person asking, both feel like the same problem.
Arithmetic. Constrain the candidate space with everything you remember, benchmark real guesses per second on named hardware, and divide. If the answer is longer than a human lifetime, that is the answer, and no tool changes it.
No. Nobody can guarantee an outcome that depends on a search space they have not measured. Upfront fees, guarantees, and any request to send the wallet file or the seed phrase are the standard shape of the scam.
If you remember one lineDo the feasibility arithmetic first. Preserve a verified copy of the media before anything is allowed to touch it.
Recovery is constraint engineering. Every number below is an input to one division that decides whether to start at all.
candidate space ÷ measured guesses per second = wall-clock seconds
Work on verified copies; stop destructive retries.
Format, wallet version, chain, script, path.
Rule out wrong path/account/passphrase state.
Write exact token/mask/position assumptions.
Exact KDF on named hardware.
Reject runs whose cost exceeds rational value.
No secret, no exploit, no recovery. Blockchain transparency does not let anyone derive an unconstrained private key.
The gap between a tractable search and an impossible one is not a matter of effort. It is visible the moment the space is plotted on a log axis.
The third step resolves most cases. Cracking is the last resort, not the first move.
Never type a seed into a website. Work on copies, isolate secrets, record every transformation, and move recovered funds to a newly generated wallet after verification. Case-by-case ratings behind these verdicts: recovery odds by scenario.
| Case | Secret exposure | Constraint | First safe action | Verdict |
|---|---|---|---|---|
| Valid seed, wrong path | None | Known wallet/era/address | Offline path + script matrix scan | LIKELY |
| One missing 12-word position | Seed candidates | 11 known words + checksum | Enumerate 2,048 words; checksum prunes | TRACTABLE |
| One missing word, unknown position | Seed candidates | 11 words + 12 positions | Enumerate positions × wordlist; checksum | TRACTABLE |
| Two missing words | Seed candidates | 10 known + positions | Compute exact combinations before hardware | MEASURE |
| Remembered password structure | Encrypted wallet copy | Mask/token grammar | Benchmark KDF on copy; checkpoint | DEPENDS |
| Unknown BIP39 passphrase | Seed remains valid | No length/word constraints | Build honest candidate model | OFTEN INFEASIBLE |
| Lost seed + intact unlocked device | Live device | Export/transfer window | Isolate and move using native UI | TIME CRITICAL |
| Lost seed + locked/wiped hardware | Device | PIN retry/chip model | Stop attempts; document device/version | SPECIALIST / NO |
| Deleted wallet file | Disk image | Blocks not overwritten | Power down; forensic image; carve copy | UNCERTAIN |
| No key, seed, file, device or constraints | None | Unconstrained key space | Do not pay anyone | IMPOSSIBLE |
A restore that shows a zero balance is usually a lookup failure, not a loss. Worked diagnosis: seed phrase restored an empty wallet.
The same seed creates different accounts under different purpose, coin, account, change, and index values.
Concrete use: Scan m/44'/0'/0', m/49'/0'/0', m/84'/0'/0', and m/86'/0'/0' only in an offline, systematic plan.
Failure mode: Random path guessing loses coverage and evidence.
Legacy, wrapped SegWit, native SegWit, and Taproot encode different output scripts and addresses.
Concrete use: Match a known historical receive address before scanning balances.
Failure mode: A valid seed can show zero when the wallet defaults to the wrong script family.
Every passphrase—including empty—derives a valid but unrelated wallet.
Concrete use: Test remembered spelling, normalization, spaces, case and language from a constrained list.
Failure mode: There is no checksum that tells you the passphrase is “close.”
Funds can sit beyond a wallet's default account or lookahead range.
Concrete use: Persist last-used indexes and scan beyond known activity only with a bounded range.
Failure mode: An unused gap can make later addresses invisible.
Shared curve/address formats do not imply shared derivation or asset state.
Concrete use: Identify wallet software/version and the actual chain transaction history first.
Failure mode: Importing into a lookalike chain can expose keys without finding funds.
BIP39: entropy is 128–256 bits, words index a 2,048-word list, checksum length is ENT/32, and seed derivation uses PBKDF2-HMAC-SHA512 with 2,048 iterations. Checksum pruning is not password security.
| Known information | Raw candidates | Checksum effect | Operational reading |
|---|---|---|---|
| 12 words, one unknown at known position | 2,048 | 12-word checksum accepts ~1/16 | ~128 valid mnemonics before address check |
| 12 words, one unknown position | 12 × 2,048 = 24,576 | Many duplicates/invalid; verify systematically | Small |
| 12 words, two known positions missing | 2,048² = 4,194,304 | Checksum reduces valid mnemonics ~16× | Benchmark; often tractable |
| 12 known words, order unknown | 12! = 479,001,600 | Checksum ~16× pruning | Large but constrain with remembered positions |
| 24 words, one unknown at known position | 2,048 | 24-word checksum accepts ~1/256 | ~8 valid mnemonics before address check |
| 8-char lowercase password | 26⁸ = 208,827,064,576 | No mnemonic checksum | KDF speed decides; don't assume feasible |
| 4 Diceware-like unknown words from 7,776 list | 7,776⁴ ≈ 3.66×10¹⁵ | No helpful checksum | Infeasible at most wallet KDF rates |
Benchmark your exact extracted hash/KDF on named hardware. The governing equation is candidates ÷ measured guesses/second = seconds; compare cost and time with value at stake. Per-format walkthroughs with real file layouts and measured rates: Bitcoin Core wallet.dat, Blockchain.com backups, MultiBit locations and paths, Electrum files that will not open.
| Format/problem | Cost function | Tool class | Required input | Gotcha |
|---|---|---|---|---|
| BIP39 mnemonic/passphrase | PBKDF2-HMAC-SHA512 × 2,048 | btcrecover / custom offline verifier | Known address/xpub + constraints | Every passphrase yields a wallet |
| Bitcoin Core wallet encryption | Version/wallet dependent | bitcoin2john + hashcat/John; source-specific | Copy of wallet file | Do not benchmark an unknown format guess |
| Ethereum keystore | scrypt or PBKDF2 parameters embedded in JSON | hashcat/John modes | Keystore copy + exact KDF params | Memory cost limits parallelism |
| Browser-extension vault | Version-dependent PBKDF2/other KDF | Format extractor + cracker | Vault + creating version | Iteration counts change across versions |
| Wrong HD path | Derivation + address lookup | Electrum/descriptor/xpub scanner | Seed/xpub + known address | Never upload xpub for sensitive wallet privacy |
| Deleted file | Storage forensics | Read-only disk image + carving | Image, filesystem, time line | Continued use overwrites evidence |
Each of these has a first action that is easy to get wrong under pressure. Longer treatments: Trezor with a lost PIN or broken screen, pulling a seed off an iPhone, deleted wallet files, estate recovery.
The seed/descriptor is the wallet; replace the device and verify derived address before moving.
Concrete use: Restore on a trusted spare, confirm a historical receive address, then migrate to fresh backup material.
Failure mode: Device brand does not bind funds if the interoperable backup is complete.
Retry counters and secure elements can turn experimentation into permanent wipe.
Concrete use: Stop, photograph model/firmware/condition, and obtain a specialist feasibility opinion before another attempt.
Failure mode: Online videos for another revision can destroy the only remaining state.
BIP39 wordlist, prefix uniqueness, position and checksum provide reconstruction constraints.
Concrete use: Transcribe every plausible character/word from high-resolution images of the copy, not the original under repeated handling.
Failure mode: Cleaning chemicals and heat can erase remaining evidence.
Legal authority and technical key access are independent requirements.
Concrete use: Keep a sealed locator/instruction record outside the will; use distributed key arrangements and annual restore drills.
Failure mode: Publishing a seed in a probate document destroys secrecy.
Second-loss fraud is the most common outcome after a first loss. Longer checklist: telling a legitimate service from a scam, and an offline recovery scam checker that scores an approach against these signals without sending anything anywhere.
Reply bots and impersonators target public loss reports.
Concrete use: Independently locate official contact channels; do not continue in direct messages.
Failure mode: Claimed law-enforcement affiliation is not verification.
A fake platform displays a balance then demands payment to release it.
Concrete use: Do not pay; preserve messages, wallet addresses, domains and transaction evidence for reporting.
Failure mode: Additional payment compounds the loss and does not unlock a blockchain transfer.
The tool exfiltrates the only secret required to steal funds.
Concrete use: Use reviewed open-source tools offline on an isolated system and a copy.
Failure mode: A professional-looking domain and TLS do not make seed entry safe.
No one can recover a mathematically unconstrained private key.
Concrete use: Require a written feasibility model: candidate count, measured rate, time, cost and stop condition.
Failure mode: Confidence without constraints is sales fraud, not forensics.
Victim lists are resold; a new actor claims to recover the first loss.
Concrete use: Assume anyone citing private details may have bought them; verify independently and report.
Failure mode: Prior victimization increases targeting, not legitimacy.
The annual restore drill is the only evidence that a backup, passphrase, derivation metadata, and procedure form a real recovery system.
Failures that pass a vendor demo. Expand each for the control and the reason it fails.
A repair, parser or password attempt can corrupt the remaining evidence.
Concrete use: Image first; hash source and working copy.
Failure mode: Recovery cannot be repeated without provenance.
The seed may be correct under another path, script, account or passphrase state.
Concrete use: Run the derivation matrix first.
Failure mode: Hardware spend cannot fix a wrong model.
The attempt discloses spend authority.
Concrete use: Use reviewed tools offline and move recovered funds.
Failure mode: A checker can steal later, not immediately.
Search expands indefinitely as memories become guesses.
Concrete use: Precommit space, budget, benchmark and checkpoint.
Failure mode: Sunk cost is not new evidence.
This sheet compresses paid recovery work done at WalletRecovery.info. The write-ups below carry the per-format detail the tables leave out: actual file layouts, measured guess rates, and the cases that correctly end in a documented no.
Operational and volatile claims were checked against these first-party documents on 2026-08-31. Examples are illustrative controls, not legal, investment, or vendor-selection advice.