Seed Phrase Recovery Guide: BIP39 Wallet Compatibility, Passphrases, Derivation Paths and Missing Accounts

A recovery phrase can be perfectly written and still open an empty or unfamiliar wallet. That does not necessarily mean the funds are gone. The restored software may be using a different backup standard, passphrase, derivation path, address type, network or account index. This guide explains how those layers fit together and provides a cautious recovery workflow that keeps the secret offline while you identify the intended accounts.

Last reviewed: October 14, 2026. Wallet interfaces, supported networks and recovery procedures can change. Confirm the current process in the official documentation for the exact wallet and firmware you use. This independent guide is educational only, not financial, legal or professional security advice. Never enter a real recovery phrase into a website, search box, chat, cloud document, AI tool or unsolicited support form.

1. Recovery is a compatibility process, not a word-entry screen

A seed phrase is one input in a larger wallet-reconstruction process. The words may encode entropy correctly, yet a wallet can display different accounts if it interprets that input with different rules. The wallet also needs to know how keys were derived, which network to scan, which account branch to open and whether an additional passphrase changed the underlying seed.

This distinction prevents a common panic response: repeatedly importing the phrase into random apps until a balance appears. Every extra import increases exposure without proving compatibility. A better process begins with information that is safe to collect: the original wallet name, approximate creation date, word count, known public addresses, networks used and whether an optional passphrase or multisignature setup existed.

2. Mnemonic, seed, private key and address are different

People often call all of these a “seed,” but recovery becomes easier when the terms stay separate. A phrase does not store a list of balances. It deterministically recreates key material; the wallet then derives addresses and searches the relevant networks for activity.

3. First identify what kind of backup you have

Do not assume every group of words is BIP39. A backup may be a 12-, 15-, 18-, 21- or 24-word BIP39 mnemonic, a 20- or 33-word SLIP39 share, a wallet-specific legacy phrase, a multisignature component, or a vendor-specific export. Similar-looking words can follow incompatible recovery procedures.

Record the word count without copying the words into a digital note. Look for non-secret evidence: the wallet brand, setup guide, packaging, purchase record, old watch-only wallet or a dated note saying which backup method was selected. If the backup consists of several numbered shares, do not concatenate them as if they were one mnemonic. Follow the scheme’s official reconstruction rules.

4. How BIP39 turns words into a wallet seed

BIP39 converts entropy plus a checksum into a mnemonic sentence drawn from an ordered 2,048-word list. The specification then uses the mnemonic and the string “mnemonic” plus an optional user passphrase in a key-stretching function to produce a 512-bit seed. That seed can become the root of a BIP32 hierarchical deterministic wallet.

The checksum helps detect some invalid word combinations, but it is not proof that a phrase belongs to the wallet you want. Another valid phrase can pass the checksum. A correct phrase paired with the wrong passphrase also produces valid seed material. Meaningful verification therefore requires a known address, wallet fingerprint, transaction or other non-secret reference from the intended wallet.

5. Word count, spelling, language and order all matter

A BIP39 phrase is ordered. Swapping two words changes the encoded value, and one wrong word can make the checksum fail or lead to different valid material. Use the original language list; do not translate words. Preserve the exact sequence and check handwriting carefully for similar words.

Do not paste the words into an online checksum checker. If a genuine wallet reports that the phrase is invalid, pause and inspect the physical backup in private. Compare only against the official BIP39 word list in a trusted offline process when necessary. Avoid automated “recovery services” that ask you to upload the full phrase.

6. BIP39 and SLIP39 are not interchangeable

BIP39 commonly represents one mnemonic backup. SLIP39 defines Shamir-based shares with a threshold: a specified number of valid shares must be combined to recover the secret. A single SLIP39 share is not a partial BIP39 phrase, and placing several share word lists together does not create a valid BIP39 backup.

Compatibility varies by wallet. A device may support BIP39 restoration but not SLIP39, or may support particular SLIP39 group structures only. Identify the scheme before buying or resetting recovery hardware. For share-based recovery, preserve identifiers, thresholds and complete share words exactly as the original wallet requires.

7. SeedQR and encoded backups still need format context

Some backups encode mnemonic information in a QR-style representation or another machine-readable format. The visual encoding is only a transport layer; it does not make every receiving wallet compatible. A scanner must understand the exact encoding and the underlying mnemonic standard.

Treat any QR containing recovery material as the secret itself. Do not photograph it with a normal phone, upload it to a decoder or send it to support. Use only a trusted offline workflow specifically documented by the wallet that created or supports that format.

8. A BIP39 passphrase creates an entirely different wallet

The optional BIP39 passphrase is sometimes called a “25th word,” but that label is misleading. It can contain multiple words, spaces, punctuation and capitalization, and it is not appended to the mnemonic. The same recovery words combined with two different passphrases produce two unrelated wallet seeds.

BIP39 does not provide a “wrong passphrase” warning. Every passphrase generates valid-looking output, so a typo often opens an empty wallet. Reproduce the exact characters, case and spacing used at setup. An empty passphrase is also a valid choice and opens the standard wallet derived from the words alone.

9. A device PIN is not the BIP39 passphrase

A PIN normally protects access to one physical device. It is not portable recovery material and does not change the wallet derived from the phrase. By contrast, a BIP39 passphrase participates in seed generation and must be available after the original device is lost.

Wallets may also use app passwords, cloud-backup passwords or local encryption codes. Label the role of each credential in non-secret recovery documentation. During restoration, never substitute a remembered PIN for an optional passphrase merely because both were entered on the old device.

10. BIP32 creates a tree, not one account

BIP32 describes hierarchical deterministic wallets: one master seed can derive a tree of child keys. Wallet applications select branches of that tree according to conventions. This permits separate coins, accounts, receiving addresses and change addresses without storing a new backup for every transaction.

The consequence is that correct seed material can still show the wrong branch. If the restoring wallet starts at a different derivation path, it may display valid addresses that have no history. Recovery is not complete merely because an app accepts the phrase.

11. What a derivation path means

A path is commonly written in a form such as m / purpose' / coin_type' / account' / change / address_index. The apostrophe marks hardened derivation. Each component selects a level in the BIP32 tree. BIP44 formalized this multi-account structure, while other proposals use different purpose values for different Bitcoin script types.

12. BIP44, BIP49 and BIP84 can lead to different Bitcoin addresses

Bitcoin wallets have used several common derivation purposes and script formats. BIP44 is associated with a legacy pay-to-public-key-hash structure, BIP49 describes a compatibility approach for nested SegWit, and BIP84 describes native SegWit derivation. The same BIP39 seed produces different address sets under these paths.

Start with the address type used by the original wallet. A known receiving address is far more useful than guessing paths. Its prefix and the original app’s documentation may narrow the possibilities, but do not change advanced path settings randomly while a working device remains available.

13. Coin type and network selection are separate checks

A multi-coin wallet may derive keys for Bitcoin, Ethereum and many other networks from one root, but each ecosystem uses its own conventions. Restoring in a Bitcoin-only wallet will not show an Ethereum balance. Within account-based ecosystems, an interface may also need the correct network or RPC configuration to display tokens and activity.

Distinguish “the key exists” from “this interface currently shows the asset.” Confirm the chain where the transaction occurred using a known public address and a reputable block explorer. Never search a seed phrase or private key. For tokens, verify the correct network and legitimate token contract rather than adding an asset by name alone.

14. Account index can explain an apparently empty recovery

Many wallets begin with account 0 and allow additional accounts to be created later. Those later accounts are separate branches. A restored interface may initially recreate only the first account, leaving account 1, account 2 or later accounts undisplayed until they are added again.

Add accounts in the same order and according to the original wallet’s official procedure. Some applications will not reveal a later empty account until an earlier one has activity. Keep a non-secret record of how many accounts existed and their purposes, without recording recovery words or private keys.

15. Receiving and change branches both matter

UTXO-based wallets often derive public receiving addresses on one branch and internal change addresses on another. After a payment, the unspent remainder may return to a newly derived change address rather than the visible address that received the original funds.

A compatible wallet normally scans both branches automatically. If it does not, an incomplete scan can understate the balance. This is one reason a single remembered receiving address is a checkpoint, not a complete balance calculation. Preserve transaction IDs or a watch-only history if available so the recovery can be compared against more than one address.

16. Gap limits can stop discovery too early

Address-discovery systems often stop after a defined number of consecutive unused addresses. If someone generated many addresses without using them, imported data unusually or used software with a different scanning policy, activity beyond the gap may not appear automatically.

Use the restoring wallet’s documented rescan or account-discovery process. Do not increase arbitrary parameters without understanding them, and do not assume the blockchain lost funds because a local interface stopped scanning. A known later address or transaction ID helps demonstrate that the scan needs to continue.

17. Wallet compatibility has several layers

Marketing phrases such as “supports 24 words” address only one layer. Before restoring into a different product, check its official compatibility documentation and understand whether it will derive the same wallet structure.

18. Prefer the original wallet family when possible

Recovery in the same current, genuine wallet family often reduces ambiguity because its defaults are more likely to match the original setup. This is not an absolute rule: products can be discontinued, standards can evolve, and an older wallet may have used a legacy scheme. Still, same-family recovery is usually the first documented route to investigate.

Obtain hardware and software through official channels, verify the website address independently and update firmware only according to official instructions. A sealed-looking package or sponsored search result is not proof of authenticity.

19. Recovering on another hardware wallet

A compatible hardware wallet can keep recovery entry off a general-purpose computer, but “hardware wallet” does not guarantee format compatibility. Confirm word count, standard, passphrase handling, supported networks and derivation paths before entering the phrase.

Whenever the device supports on-device entry, avoid typing words into the computer. Read every device prompt, confirm that the recovery operation was initiated by you and verify a known public address on the trusted display after restoration. Do not approve transactions merely to test whether the wallet “works.”

20. Why importing a hardware-wallet seed into software is risky

A phrase generated and kept within hardware-wallet boundaries loses that protection when typed into a phone or computer. Malware, clipboard monitoring, screen capture, malicious extensions or a compromised operating system could record it. Even legitimate software may create logs, backups or memory exposure outside the original security model.

Software import should not be the casual first troubleshooting step. Prefer a genuine compatible device. If an emergency forces exposure of a previously hardware-only seed, treat the old seed as potentially compromised afterward and migrate assets to a new wallet created with fresh secret material in a trusted environment.

21. Prepare a safe recovery environment

1. Stop and verify that recovery is actually necessary; preserve any working wallet unchanged.
2. Remove cameras, voice assistants and unrelated people from the workspace.
3. Use genuine hardware or official software obtained through an independently verified source.
4. Disconnect unnecessary networked devices and close screen-sharing, cloud notes and messaging apps.
5. Have non-secret references ready: known addresses, transaction IDs, wallet model, account count and networks used.
6. Enter the phrase only through the wallet’s documented recovery interface, preferably on-device.
7. After restoration, verify addresses before considering any transfer.

“Offline” is not a magic guarantee. A compromised computer can store data and transmit it later. The goal is to minimize handling and keep secret entry inside a trusted system designed for recovery.

22. A step-by-step recovery workflow

Step 1: preserve the evidence

Do not erase the original device or edit the physical backup. Record the wallet name, model, approximate setup date, word count, networks, account names and public references. If the original wallet still opens, export only safe watch-only information when supported and confirm the backup using its built-in check.

Step 2: classify the backup

Determine whether it is BIP39, SLIP39, multisignature material or a wallet-specific format. Confirm whether an optional passphrase existed. Do not infer the format solely from the number of words.

Step 3: choose a documented compatible destination

Prefer the original wallet family or a destination whose official documentation explicitly supports the format and networks. Understand the effect of importing a hardware seed into software before proceeding.

Step 4: restore without improvisation

Follow the device-specific instructions exactly. Preserve order, language and passphrase characters. Never accept remote assistance that asks to view, type or “validate” the secret.

Step 5: compare a known address

Before judging the result by the displayed balance, reproduce a known address or wallet fingerprint. If it does not match, stop. Review passphrase and derivation assumptions rather than sending funds.

Step 6: discover accounts and networks

Add the expected accounts in sequence, enable the original address type and scan the networks actually used. Review change branches and gap-limit behavior where relevant.

Step 7: decide whether to keep or migrate

If the secret remained protected and recovery used a trusted device, continued use may be reasonable. If words were exposed, entered on an untrusted computer or shared, create a new wallet and migrate after verifying the new backup.

23. Verify a known public address before moving funds

A matching known address is strong evidence that the phrase, passphrase and derivation branch align with the intended wallet. Use an address from a trusted prior record: an exchange withdrawal history, transaction receipt, watch-only wallet or address previously verified on the original device.

Public addresses are not spending secrets, but they reveal financial activity and should still be handled privately. Compare the complete address, not only the first and last few characters. Address-poisoning attacks deliberately create look-alike strings.

24. Why you should not transact immediately after recovery

Seeing a familiar balance can create urgency, but first confirm the recovery is complete. Check more than one known address where possible, review networks and token contracts, verify the receiving destination on a trusted display and understand current fees. A rushed “test” can become an irreversible transaction to the wrong network or address.

If migration is required, send a small test transaction first when network economics allow, verify final receipt, then move the remaining assets deliberately. Do not announce the recovery or ask strangers for live help while the wallet is exposed.

25. Empty wallet after recovery: diagnostic table

26. Watch-only wallets can help without exposing secrets

A watch-only wallet tracks public addresses or extended public keys but cannot spend. It can provide known addresses, transaction history and account structure for comparison during recovery. That makes it valuable evidence when the original signing device is unavailable.

An extended public key is not equivalent to a seed, but it is privacy-sensitive because it may reveal many present and future addresses. Store and share it carefully. Do not confuse a successful watch-only import with recovery of signing capability.

27. Multisignature recovery needs the wallet policy

In a multisignature wallet, restoring one seed may recover only one signer. Spending can also require the threshold, cosigner public keys, key order, script type and derivation information. Depending on the setup, a wallet descriptor or configuration file may be essential even when all seed backups survive.

Do not convert a multisignature problem into random single-signature imports. Locate the non-secret policy documentation, identify the required number of signers and follow the original coordinator’s official recovery process. Test multisignature recovery before an emergency using a controlled setup and small values.

28. Smart accounts and social recovery may not use seed-only recovery

Some wallets use smart contracts, guardians, passkeys, cloud-assisted recovery or account-abstraction systems. A mnemonic may control one signer without fully describing the account’s recovery rules. Contract addresses, guardian configuration or provider-specific procedures can be necessary.

Determine the architecture from official documentation and prior records. Never assume that importing a phrase into a generic wallet reconstructs a smart-account interface or its policy. Confirm the on-chain account address and recovery mechanism before taking action.

29. Damaged or incomplete backups require restraint

If words are physically unreadable or a share is missing, preserve the original material. Do not repeatedly clean, heat, scratch or photograph it under uncontrolled conditions. Record which positions are uncertain without digitizing all readable words. Seek a reputable specialist only after understanding custody, confidentiality and technical risks.

This guide intentionally does not provide brute-force recipes. Guessing tools can expose the remaining secret, produce false matches and create legal or operational risks. If a working device still controls funds, the safer solution is often to create and verify a new wallet, then migrate, rather than attempt reconstruction of a damaged backup.

30. What to do if the phrase may be compromised

Assume anyone with the full phrase and required passphrase can recreate the wallet. Deleting a photo, recovering a stolen plate or changing the device PIN does not revoke copied seed material. A passphrase change also creates a different wallet; it does not remove an attacker’s access to funds still under the old one.

1. Use a clean trusted wallet to generate entirely new secret material.
2. Back up and verify the new wallet before sending assets.
3. Confirm the complete destination address on a trusted device display.
4. Use a small test transfer where practical, then migrate remaining assets.
5. Review tokens, NFTs, staked positions and smart-contract approvals that may require separate actions.
6. Retire the compromised wallet from future deposits and update saved withdrawal addresses.

31. Build a recovery record without recording the secret

A useful recovery record can include the wallet brand and model, backup standard, number of words or shares, whether a passphrase exists, networks used, approximate account count, address types, public wallet fingerprint, multisignature policy location and last verification date. It should point an authorized person toward official instructions.

Do not place the actual phrase, private keys, passphrase or a direct map to every secret component in that record. Keep it readable and update it after changing wallets, networks or recovery architecture. Technical precision is more durable than clues such as “use the usual password.”

32. Recovery checklist

• The established URL and wallet history are preserved; the working device has not been wiped.
• The backup standard, word or share count and original wallet family are identified.
• The existence of an optional passphrase is known, and it is not confused with a PIN.
• The destination supports the required format, networks and derivation conventions.
• Secret entry occurs only through a genuine documented recovery interface.
• A known complete public address is available for comparison.
• Account indexes, address types, change branches and gap-limit behavior are considered.
• Multisignature or smart-account configuration is reconstructed when applicable.
• No transaction is sent until the intended wallet has been verified.
• Any seed exposed to an untrusted environment is retired through a controlled migration.

Frequently asked questions

Why did my correct recovery phrase create an empty wallet?

The most common explanations are a missing or mistyped BIP39 passphrase, a different derivation path, the wrong account index, address type or network, or incomplete account discovery. Compare a known public address before concluding that the phrase is wrong.

Can support verify my phrase?

No legitimate support agent needs your complete recovery phrase or private key. Anyone who obtains it may control the wallet. Official support can explain procedures without receiving the secret.

Can I restore a 24-word phrase in any 24-word wallet?

No. Matching word count does not prove matching standard, passphrase behavior, derivation paths, networks or architecture. Confirm explicit compatibility in official documentation.

Does a valid checksum mean the funds should appear?

No. A checksum checks mnemonic structure, not ownership, passphrase, derivation path, account index or network selection.

Can I test recovery by resetting my only device?

Do not erase the only working signer to test a backup. Use the manufacturer’s built-in verification feature or a genuine compatible spare device while preserving the working wallet.

Is it safe to enter my seed on an offline laptop?

Disconnection alone does not prove the laptop is clean; malware can record data for later transmission. Prefer on-device recovery with genuine compatible hardware when that matches the original security model.

What if I remember several possible passphrases?

Work privately and methodically using the official device workflow and a known public address. Do not upload the phrase or possible passphrases to an online tool, and avoid uncontrolled automated guessing.

Should I move funds after a successful recovery?

If the phrase was exposed to software, another person or an untrusted environment, migration to a new verified wallet is prudent. If recovery stayed within a trusted compatible device and no exposure occurred, immediate migration may not be necessary.

Official references

The following primary and manufacturer resources explain the standards and recovery behaviors discussed above:

• BIP39 — Mnemonic code for generating deterministic keys — official specification for mnemonic construction, checksum, seed generation and optional passphrases.
• BIP32 — Hierarchical Deterministic Wallets — official specification for master and child key derivation.
• BIP44 — Multi-account hierarchy for deterministic wallets — the purpose, coin, account, change and address-index structure.
• BIP49 — Derivation scheme for nested SegWit accounts — a common Bitcoin derivation and address compatibility standard.
• BIP84 — Derivation scheme for native SegWit accounts — native SegWit key derivation and address discovery guidance.
• SLIP39 — Shamir’s Secret-Sharing for Mnemonic Codes — the official share-based recovery specification.
• Trezor Learn — Understanding 12-, 20- and 24-word wallet backups — official explanation of Trezor backup types and compatibility.
• Trezor Support — Troubleshoot wallet backup and recovery problems — official recovery troubleshooting for invalid or unexpected backups.
• Trezor Support — Fix passphrase wallet problems — explains why incorrect passphrase input opens a different wallet.
• Ledger Academy — What is a Secret Recovery Phrase? — official overview of phrase ownership, protection and recovery.

A successful recovery is not merely an accepted phrase or a visible balance. It is a controlled reconstruction of the intended wallet, confirmed through known public evidence and completed without unnecessarily exposing the secret.