Recovery methodsTechnicalUpdated October 12, 2026 · Data Recovery Cases Editorial Team

Wallet Seeds, Derivation Paths and Account Reconstruction

A recovered seed phrase and a recovered wallet are not the same thing. Which account a valid backup reproduces depends on its format, any BIP39 passphrase, the derivation convention, the account and address range — and some accounts were never derived from the seed at all. Only a match against known public data confirms the right account.

In short

A valid seed restores the root of a key tree; the account shown depends on convention, account, passphrase and script type.
A checksum-valid BIP39 phrase does not prove it is the original wallet, the right passphrase or a balance.
SLIP39 shares are a threshold backup of one secret, not multisig, and not interchangeable with BIP39 words.
An empty-looking restore can mean wrong network, path, account, passphrase or scan range, or imported accounts, not lost funds.
Check candidates offline; never put seeds or keys into websites, screenshots or support tickets, and treat xpubs as private.

A seed is the root of a tree, not an address

Modern wallets are usually hierarchical deterministic (HD) wallets. BIP32 defines how a seed produces a master key and how a whole tree of child keys is derived from that root; a child index at or above 2³¹ is a hardened key, written with an H suffix in BIP32 and with an apostrophe in BIP44. Knowing the seed identifies the root of that tree. It does not by itself say which branch the original wallet actually used, and a different branch produces different, equally valid addresses with no error at any point.

The familiar five-level path m / purpose’ / coin_type’ / account’ / change / address_index is the BIP44 account convention, not part of the BIP32 tree definition itself — BIP32 describes only a default layout of accounts, an external and an internal chain, and states that this layout is a default. In the BIP44 scheme the first three levels are hardened, change is 0 for the external (receiving) chain and 1 for the internal (change) chain, and coin_type 0’ is Bitcoin mainnet while 1’ is testnet. So, read with that scope, m/84’/0’/0’/0/0 means: BIP84 convention, Bitcoin mainnet, first account, receiving chain, first address. Other coins use other registered coin types, and some wallets use their own conventions outside these BIPs.

BIP39 mnemonics and the passphrase that is not a password

BIP39 encodes entropy plus a short checksum as a mnemonic of 12 to 24 words from a 2048-word list, then turns the mnemonic into a seed through a one-way derivation that also accepts an optional passphrase. That passphrase is not a password wrapped around an already-fixed seed; it participates in creating the seed itself, so a different passphrase produces a different wallet, and an empty string is used whenever none is supplied. BIP39 notes that every passphrase generates a valid seed. A wallet password, by contrast, usually just encrypts a locally stored copy of key material and does not change the underlying deterministic wallet — recovering one is not a substitute for the other.

This is why a checksum-valid mnemonic proves less than it seems. The checksum is short — BIP39 itself says it misses some random errors — and even a correct checksum says nothing about whether this is the original wallet’s phrase, whether a passphrase was used, or whether any balance exists. Recovery is confirmed by correspondence with known public data, not by the absence of an error message.

Password vs. passphrase

A wallet password usually decrypts stored data. A BIP39 passphrase changes the deterministic wallet derived from the seed. A wrong passphrase commonly produces a valid but empty-looking wallet instead of an error.

Electrum, SLIP39 and other formats are not BIP39

A phrase built from familiar English words is not automatically a BIP39 mnemonic. Electrum seeds carry a version number, derived from a hash of the phrase, that tells the software which derivation to follow; Electrum states that it does not generate BIP39 seeds. SLIP39 splits one master secret into mnemonic shares, optionally in two levels (groups of member shares), each with its own threshold. It is a backup scheme for a single secret, not multisig, and its shares are not interchangeable BIP39 cards: SLIP39 describes the two as mostly incompatible. Each share carries a set identifier and the threshold values, so a compatible implementation can check whether shares belong together — “I still have two seed cards” means little until that check has been made.

Scroll horizontally to see the full table →

Backup format, what else it needs, and what validating it does not prove.
Backup format	What is needed besides it	What successful validation does not prove
BIP39 mnemonic	Any BIP39 passphrase; the derivation convention, account and script type the wallet used	That this is the original wallet’s phrase, that the passphrase is right, or that funds exist — a valid checksum only rules out some typing errors
Electrum seed	Software that understands Electrum’s seed versions, which tell it the derivation to follow	That the phrase is BIP39; a phrase rejected as BIP39 may still be a valid Electrum seed
SLIP39 shares	Enough shares from the same set to meet its member and group thresholds; any SLIP39 passphrase	Which shares belong together or what the threshold is, judged by counting cards; SLIP39 also offers no way to verify that the passphrase was correct
Imported key, keystore or wallet file	The key or container itself and, if encrypted, its password; see Recovering Encrypted Wallet Files and Keystores	Anything about accounts derived from a main seed — an imported key is outside that tree
Multisig policy	Enough cosigner keys to meet the threshold plus the policy describing how they combine; see Multisig Wallet Recovery and Descriptors	That one restored cosigner seed reproduces the wallet’s addresses or can spend on its own

Bitcoin path conventions decide which addresses appear

For Bitcoin, BIP44, BIP49, BIP84 and BIP86 are separate conventions. BIP44 sets the account and path structure; BIP49, BIP84 and BIP86 each define their own purpose value for a specific single-key script type and reuse the BIP44 meaning for the remaining levels. Restoring the same seed under a different convention gives a different, valid set of addresses.

Scroll horizontally to see the full table →

Bitcoin single-key derivation conventions: what each fixes and what it leaves to BIP44.
Convention	Purpose level	Output type	Network, account, change, address index	Restore caveat
BIP44	44’	Defines the levels themselves, not a script type; Bitcoin wallets commonly use it for legacy P2PKH	coin_type, account (hardened), change 0/1, address_index	Wallets that restore only newer script types may not show these addresses
BIP49	49’	P2WPKH nested in P2SH	As defined in BIP44	BIP49 defines “ypub” extended keys; a saved ypub suggests this convention
BIP84	84’	Native SegWit P2WPKH	As defined in BIP44 (or BIP49)	BIP84 defines “zpub” extended keys; a saved zpub suggests this convention
BIP86	86’	Single-key P2TR, with no script path	As defined in BIPs 44, 49 and 84	Taproot wallets that use script paths are outside BIP86 and need their own policy

Not every wallet’s discovery covers all of these conventions automatically, and custom paths exist. Descriptor-based wallets describe the scripts explicitly instead — in Bitcoin Core’s descriptor language a descriptor gives the script and key expressions and can optionally include key-origin information (a fingerprint and derivation path). Not every descriptor carries an origin, and one that lacks it is still valid, though it gives less of the derivation history. A surviving descriptor or wallet export is still stronger evidence of the original construction than any table of defaults.

When a correct-looking seed restores an empty wallet

“Empty after restore” can mean the wrong network, path convention, account or passphrase; an address range the software did not scan; a script type the software does not support; or accounts that were imported, watch-only or held on a hardware wallet rather than derived from this seed. How far a wallet looks is a property of the implementation. BIP44’s own account-discovery procedure, for example, scans accounts in order from index 0, stops at the first account with no transactions on its external chain, and uses an address gap limit of 20 on that chain; other wallets may use different limits or settings, so check the documentation of the software actually used. One consequence of the BIP44 procedure: an account used after an unused one may not be discovered automatically.

Rather than scanning every conceivable path blind, work through ordered checks using whatever wallet history is available:

The network and coin, and the backup format (BIP39, Electrum, SLIP39).
Whether a passphrase was ever set.
The original app and version, which usually implies its default convention and script type; the form of a known address or a saved ypub/zpub can corroborate it.
The account index, including accounts beyond an unused one.
The address range — known addresses used far beyond the software’s scan range, on the receiving or the change chain.
Accounts that were imported, watch-only or hardware-backed, which this seed will never reproduce.

Illustrative example: a known address does not appear with an empty passphrase

Observed

A BIP39 phrase with a valid checksum is restored offline under the BIP84 convention with an empty passphrase. A known receiving address (placeholder: bc1q…EXAMPLE) does not appear in the scanned range of the first account.

Interpretation

This is an unresolved candidate, not proof that the funds are gone or the phrase is wrong. A passphrase, another account, another script type, the change chain, or a wider address range are all still open.

Safer next step

Check records and the original app for passphrase use, account numbering and script type, then test only the alternatives that evidence supports, still offline and in compatible software.

Limit

A later match confirms the correspondence for that address. It does not show that every account or imported key has been found.

What counts as evidence of the right account

Useful evidence is public and specific: known receiving and change addresses, an extended public key or descriptor in a format the restoring software supports, the original app and version, and a known transaction on a known network. A transaction ID helps locate the public account context — which addresses received or spent — but on its own it does not prove that a given seed corresponds to those addresses or that anyone holds signing authority. Public visibility is not spending recovery either: an xpub or public descriptor imported as watch-only can show balances and history without any ability to sign.

Imported, hardware and watch-only accounts are not backed up by the seed

Many wallet applications mix accounts derived from the main seed with individually imported private keys or JSON keystores, accounts from a separate phrase, hardware-wallet accounts and watch-only addresses. A seed backup only restores the first category; each of the others depends on its own source — the original key or file, the hardware device or its own backup, or the public data a watch-only entry was built from. A backup of the main seed therefore does not guarantee a backup of every account shown in the interface.

As a product-specific example, MetaMask’s help article on restoring with a Secret Recovery Phrase says only accounts originally created from the same phrase are synchronized and added; imported accounts and hardware-wallet accounts have to be re-added the way they were first added, and missing derived accounts can be added back manually, in the order they were created. Other wallets behave differently. For an imported keystore or encrypted file, see Recovering Encrypted Wallet Files and Keystores.

Handling secrets while checking candidates

Run candidate checks offline, in trusted software compatible with the original wallet. Keep seeds and private keys out of screenshots, browser tools, cloud notes, chats and support attachments, and do not paste them into websites that offer to “check” a phrase. Extended public keys deserve care too: an xpub cannot sign, but it reveals the account’s whole address history to whoever receives it. A log of which conventions, accounts and passphrase candidates were tried is useful — written without the secrets themselves.

Technical references: BIP32 — HD key tree, hardened keys, default layout · BIP39 — mnemonic checksum, passphrase to seed · SLIP-0039 — shares, groups and thresholds · BIP44 — path levels and account discovery · Electrum: seed version system — versioned, non-BIP39 seeds. Discovery behaviour, scan ranges and supported conventions vary by wallet implementation and version; check the documentation of the software actually used.