Bitcoin Wallet Recovery & Derivation-Path Matrix: Why Your Restored Seed Shows an Empty Wallet
Before you do anything: never type a live seed phrase into a website, a browser extension, a search box, or any "wallet recovery service." Every legitimate step below can be done offline with open-source software on a machine you control. If you are diagnosing an empty wallet, derive candidate addresses first and check them against a block explorer — looking up an address is safe, and you never need to expose key material to find out where your coins are.
Quick answer
A seed phrase is only half of a Bitcoin wallet. The other half is the derivation path — the route through the key tree that decides which addresses your seed produces. BIP44, BIP49, BIP84 and BIP86 derive completely separate, non-overlapping address sets from the same words, so restoring a correct seed into software that defaults to a different standard shows an empty wallet with no error message at all. That silence is the whole problem: there is no checksum for "right seed, wrong branch." This matrix records the default path, supported paths, seed standard, passphrase behaviour, gap limit and descriptor export for 35 wallets and signing devices, so you can find the branch your coins are actually on.
Start from an address you know received funds — its prefix names the branch (1 = BIP44, 3 = BIP49, bc1q = BIP84, bc1p = BIP86). Restore into Electrum or Sparrow, which scan several formats at once, and raise the gap limit above the default 20 before concluding anything is missing. Back up an output descriptor alongside every seed: it records the path and script type that the words alone leave unstated.
"I restored my seed and the wallet is empty" — and other recoverable panics
Most reports of lost Bitcoin are not lost coins. They are coins sitting on a branch nothing has scanned yet. Find your symptom, then work the fix.
“I restored my seed phrase and the wallet is empty”
What is actually happening: The seed is only half the wallet. The purpose' level selects the address family, and BIP44/49/84/86 derive completely separate, non-overlapping sets of addresses from the same seed. A wallet defaulting to BIP84 shows nothing when the coins sit on BIP44 legacy addresses. The failure is silent — no checksum, no warning.
How to recover: Find one address you know received funds. Its prefix names the branch: 1 = BIP44, 3 = BIP49, bc1q = BIP84, bc1p = BIP86. Restore into Electrum or Sparrow, which scan multiple formats. If that fails, iterate purpose', then account' 0,1,2..., checking candidate addresses on an explorer before importing anything.
“My old transactions are there but a recent deposit is missing”
What is actually happening: BIP44 sets the address gap limit at 20: after 20 unused addresses in a row, the wallet assumes there is nothing beyond and stops searching. Generate 20+ addresses without receiving, then get paid at a later index, and the wallet never derives that key. The UTXO is confirmed on-chain and fully spendable.
How to recover: Raise the gap limit and rescan. Sparrow: Settings > Advanced (default 20, 40 for postmix). Electrum: pre-generate with wallet.create_new_address(False). Bitcoin Core: importdescriptors with a wide explicit range such as [0,5000] and an early timestamp, then rescanblockchain. Then sweep funds back to low indices.
“I typed all 24 words correctly and it still shows zero”
What is actually happening: A BIP39 passphrase is salt in the key derivation, not a password on a wallet. Every passphrase produces a valid wallet, so there is no such thing as a wrong-passphrase error — a mistyped one silently opens a different, empty wallet. A device PIN is local to that hardware and plays no part in derivation.
How to recover: Restore with no passphrase first; many people who think they set one did not. Then test exact variants offline: case, leading or trailing space, curly vs straight quotes, keyboard layout, Unicode normalization. Check only the first receive address of each candidate against an explorer — no full sync needed.
“I have 2 of my 3 multisig seeds and I still cannot find the coins”
What is actually happening: Multisig coins are locked to a script, not a key. Reproducing that script needs every cosigner xpub with its key origin, the M-of-N quorum, the script type, and the key ordering. Your seeds supply signatures only, and a missing public key cannot be derived from other people's private keys.
How to recover: Pull the missing xpub from any surviving cosigner device — hardware signers export xpubs without exposing the seed. If the coordinator software still runs anywhere, export the output descriptor immediately. Rebuild in Sparrow, Specter, or Core importdescriptors, trying BIP48 script_type 1' and 2' against the explorer.
“My node died, I restored the seed, on-chain came back but every channel balance is zero”
What is actually happening: A Lightning channel balance is your side of a 2-of-2 funding output, defined by the latest commitment transaction — mutable state that changes with every payment. A static seed cannot encode a value that changes thousands of times a day, so no seed of any format reconstructs channel state.
How to recover: Restore the most recent channel.backup and let the node ask former peers to force-close; funds return on-chain after timelocks. Wait a day or two for offline peers. Never restore a stale SCB — lnd warns that peers can invalidate your commitment transactions and you lose the channel funds outright.
“My wallet says invalid mnemonic or checksum failed — did I write a word down wrong?”
What is actually happening: Not every 12 or 24 word phrase is BIP39. Electrum's native seeds carry an HMAC-SHA512 version number instead of a BIP39 checksum. lnd's aezeed is 24-word ciphertext. SLIP39 shares are 20 or 33 words. A loud rejection is the safe outcome; the dangerous case is a phrase that passes a checksum it was never designed for.
How to recover: Match the phrase to its origin software: Electrum seeds go in Electrum, an lnd/Umbrel/RaspiBlitz phrase is aezeed and goes in lnd, Trezor Shamir shares need the SLIP39 threshold. Never edit words to force a checksum to pass — that generates a different wallet and destroys the diagnostic signal.
“I restored my Ledger seed into a Bitcoin-only wallet and one balance is gone”
What is actually happening: coin_type' is hardened, so each coin sits in a disjoint subtree. A Bitcoin-only wallet scans coin_type 0 only, and that is correct behaviour. BTC sent to an address a multicoin device generated under Bitcoin Cash (145), Bitcoin Gold (156), or testnet (1) is a real Bitcoin UTXO on a branch nothing will scan.
How to recover: Derive candidates at m/44'/145'/0'/0/x, m/44'/156'/0'/0/x, m/44'/2'/0'/0/x and m/44'/3'/0'/0/x, checking each against a Bitcoin explorer. Check coin_type 1' if the wallet was ever in test mode. When you find the UTXO, export that key as WIF and sweep it into a Bitcoin wallet. Do all of it offline.
“I imported my zpub and the wallet shows no history”
What is actually happening: BIP49 and BIP84 did not change the extended-key version bytes, so SLIP-132 added ypub/zpub — plus Ypub/Zpub for multisig and upub/vpub/Upub/Vpub for testnet — to signal script type. Adoption is inconsistent (HWI returns xpub regardless of path), so the importing software assumes the wrong script type.
How to recover: Convert the version bytes with offline tooling, or set the script type explicitly in the importing wallet, or sidestep it entirely by importing a full output descriptor, which states script type and path and makes the prefix irrelevant.
“Bitcoin Core says my keys are imported but there are no transactions”
What is actually happening: Core's own docs warn that during a rescan other RPC calls may report the imported keys, addresses or scripts exist while related transactions are still missing. With an early timestamp the rescan can take over an hour, so checking early produces a false negative and a second round of panic.
How to recover: Let rescanblockchain finish before judging the result. Do not re-import, re-derive, or start editing paths mid-rescan. Confirm the balance only once the scan has completed.
Signing devices — recovery & derivation reference
What each device actually derives, what its seed really is, and what you must know to restore it somewhere else. Confidence reflects how firmly the value is documented; "unverified" means we could not source it and refused to guess.
| Name | Seed standard | Default path | Paths supported | Passphrase | Gap limit | Descriptor export | Restore risk |
|---|---|---|---|---|---|---|---|
| BitBoxApp / BitBox02 medium confidence |
BIP39 generated on-device, 12 or 24 words (restore also accepts 18), plus optional microSD backup. The discontinued BitBox01 is NOT standard BIP39 — modified PBKDF2, 22,528 rounds — and needs BitBox01-specific tooling. | No single default. One BitBoxApp Bitcoin account spans m/49'/0'/0', m/84'/0'/0' and m/86'/0'/0' simultaneously, each with its own xpub; m/84'/0'/0' is only the native-segwit component. | BIP49 m/49'/0'/0', BIP84 m/84'/0'/0', BIP86 m/86'/0'/0', plus BIP48 m/48'/0'/0'/2' multisig via Electrum/Sparrow. No BIP44 legacy for Bitcoin — the device never derives m/44'/0'/0'. Account index increments from 0'. | Optional BIP39 passphrase, enabled on-device. Standard BIP39 semantics, so a wrong passphrase yields a valid, empty wallet with no warning. | 20, applied to both receive and change chains. Resets to 20 each time the app is closed, and can be raised manually in the BitBoxApp — documented specifically for recovery when a balance looks short. | Partial. The app shows wrapped-segwit and native-segwit xpubs but deliberately hides the taproot xpub. Use third-party descriptor software for taproot (Sparrow; Liana 8.0 with BitBox02 firmware 9.21.0+). | High |
| Restoring elsewhere: One BitBox account can hold coins on three derivation paths at once, so a seed restored into any wallet that scans only m/84'/0'/0' will hide funds sitting on m/49'/0'/0' (3... addresses) or m/86'/0'/0' (bc1p... addresses). Restore into another BitBox, or add all three accounts (49'/84'/86') as separate wallets in Sparrow or Electrum and raise the gap limit above 20 if the balance still looks short; never search m/44'/0'/0'. A BitBox01 backup must be recovered with the Shiftcrypto backup-center key generator or the community BitBox01-Recovery tool — standard BIP39 tools derive a valid but wrong, empty wallet from correct BitBox01 words. | |||||||
| Coldcard Mk4 high confidence |
BIP39 only, 12 or 24 words. No SLIP39/Shamir. Bitcoin-only, so coin type is always 0' (1' testnet). BIP85 child seeds, Seed XOR splits and duress seeds are themselves BIP39 mnemonics. | m/84'/0'/0' (BIP84 native segwit, account 0; the coordinator picks which exported xpub is actually used) | BIP44 m/44'/0'/{acct}', BIP49 m/49'/0'/{acct}', BIP84 m/84'/0'/{acct}', BIP45 m/45', BIP48 multisig (/1' and /2'), arbitrary custom paths and non-zero hardened accounts. No BIP86 Taproot in stable firmware. | Yes — BIP39 passphrase (25th word). Each passphrase yields a separate, independent wallet, and the passphrase itself is never stored on the device. Lost passphrase = lost funds, with no recovery path. | N/A at the device level — Coldcard never scans the chain. Discovery is the coordinator's job; BIP44 convention is 20. Addresses generated far past that in Address Explorer may need the coordinator's gap limit raised. | Yes — output descriptors, a generic multi-xpub JSON export, and multisig config files via microSD, USB, or NFC. Store this alongside the seed; it is the single best recovery artifact. | High |
| Restoring elsewhere: Restoring elsewhere needs four things: the 12/24-word BIP39 mnemonic, the passphrase if used, the script type/path the coordinator was actually on (BIP84 is the safe first guess), and the account number if non-zero — storing the exported output descriptor with the seed pins down the last two unambiguously. Four non-standard paths hide funds from a normal restore: the legacy duress wallet at m/2147431408h/0h/0h; BIP85 duress children at index 1001/1002/1003 (24-word master) or 2001/2002/2003 (12-word master), which must be regenerated as their own mnemonic rather than reached by restoring the master; any other BIP85 child, whose index (0–9999 by default), seed type and word length you must record; and Address Explorer's Whirlpool accounts at m/84'/0'/2147483646' (post-mix) and m/84'/0'/2147483645' (pre-mix). Seed XOR splits one seed into 2–4 parts that are each a valid BIP39 mnemonic, so a partial reconstruction gives a real but empty wallet — record the part count yourself since the device does not know it, keep all parts the same length, note your original final word because the XOR skips the checksum bits, and remember that Taproot m/86' exists only on experimental edge firmware. | |||||||
| Coldcard Q high confidence |
BIP39 only, 12 or 24 words. No SLIP39/Shamir. Bitcoin-only (coin type 0', 1' testnet). Shares the Mk4 firmware codebase, so BIP85, Seed XOR, temporary seeds and duress wallets behave identically. | m/84'/0'/0' (BIP84 native segwit, account 0; the coordinator selects which exported xpub is used) | Identical to Mk4: BIP44, BIP49, BIP84, BIP48 multisig (/1' P2SH-P2WSH and /2' P2WSH), arbitrary custom paths and hardened account numbers. Taproot/BIP86, Miniscript and Tapscript are edge-firmware only. | Yes — full BIP39 passphrase. The QWERTY keyboard makes long passphrases materially easier to enter correctly than on the Mk4, which reduces but does not eliminate typo risk. Never stored; losing it loses the wallet. | N/A at the device level — the Q never scans the chain and has no gap-limit setting. Discovery belongs entirely to the coordinator; BIP44 convention is 20. | Yes — output descriptors, generic multi-xpub JSON, and multisig config via microSD, NFC, USB, or QR code (QR export is Q-specific and absent on the Mk4). | High |
| Restoring elsewhere: Recovery is functionally identical to the Mk4: you need the BIP39 mnemonic, the passphrase if used, the script type/path the coordinator used, and the account number — export and store the output descriptor, which records the last two for you. The same landmines apply: the legacy duress wallet at m/2147431408h/0h/0h, BIP85 duress children at index 1001/1002/1003 (24-word master) or 2001/2002/2003 (12-word master) that must be regenerated rather than reached from the master, and Seed XOR parts that are each individually valid BIP39 seeds under all-parts reconstruction — record the part count separately, because the device cannot report it. Stable firmware (Mk 5.5.1 / Q 1.4.1Q) can display and send to bc1p destinations but cannot sign for them, so do not plan a Taproot or Miniscript vault around a stable-firmware Q; and because QR pairing makes it easy to attach several coordinators, write down which path each one used. | |||||||
| SeedSigner high confidence |
BIP39 (12 or 24 words), plus partial support for Electrum Segwit seed phrases. No SLIP39/Shamir. Stateless — seeds are held in memory only while powered and wiped on power-off. BIP85 supported, disabled by default. | m/84'/0'/0' (BIP84 native segwit, single-sig mainnet — the de facto default from firmware settings; the docs' path table designates no default) | Single-sig m/84'/0'/0' (zpub), m/49'/0'/0' (ypub), m/86'/0'/0' Taproot (xpub), legacy p2pkh; multisig m/48'/0'/0'/2' (Zpub) and m/48'/0'/0'/1' (Ypub). Custom paths supported. Testnet changes both path and encoding. | Yes — BIP39 passphrase (13th/25th word). Stateless, so it must be re-entered every session, with no on-device record that one was used. Use ASCII only; some forks add non-ASCII entry that risks normalization mismatch. | N/A at the device level — air-gapped and never scans the chain. Discovery is handled entirely by the coordinator (Sparrow, Nunchuk, Specter, Blue Wallet); BIP44 convention is 20. | Partial — exports single-sig and multisig xpubs by QR, enough for watch-only, but no full output descriptor. Preserve multisig descriptors from the coordinator side. | High |
| Restoring elsewhere: The device stores nothing, so the mnemonic, the passphrase if used, and the script type must all come from you. Taproot is enabled by default alongside native and nested segwit, so an empty balance is far more often a script-type mismatch than a loss — rescan the same seed across m/84'/0'/0', m/86'/0'/0', m/49'/0'/0' and legacy m/44'/0'/0' before concluding anything is gone, and note that custom paths are also possible on this device. Multisig cannot be recovered from seed words alone: back up the coordinator's descriptor (quorum, every co-signer xpub, and the m/48'/0'/0'/2' or /1' path), since seed words plus a lost descriptor means permanently unspendable funds; SeedQR/CompactSeedQR is the same entropy in QR form, a convenience and not a second factor. | |||||||
| Krux high confidence |
BIP39 (12 or 24 words). No SLIP39/Shamir. Open-source firmware for Kendryte K210 boards (M5StickV, Maix Amigo). Optional encrypted mnemonic storage on device/SD, but the secret is always a standard BIP39 mnemonic. | m/84h/0h/0h (BIP84 native segwit, single-sig — the documented default) | Legacy m/44h/0h/0h, Nested Segwit m/49h/0h/0h, Native Segwit m/84h/0h/0h (default), Taproot m/86h/0h/0h, Multisig m/48h/0h/0h/2h. Policies: single-sig, multisig, Miniscript, TR Miniscript; Miniscript allows custom paths. | Yes, typed on screen or by QR. Krux cannot perform NFKD normalization internally, so a non-ASCII passphrase can derive a different wallet than on normalizing software. Use ASCII-only or pre-normalized input. | N/A at the device level — Krux is an airgapped signer and does not scan the blockchain. Address discovery belongs to the coordinator; BIP44 convention is 20. | Yes — handles descriptor-based single-sig, multisig and Miniscript policies, with export by QR or SD card to a coordinator such as Sparrow or Nunchuk. | High |
| Restoring elsewhere: Script type, policy type, network and account are all adjustable at mnemonic-load time, so the same 12/24 words can produce at least five different wallets — start at m/84h/0h/0h and walk m/44h, m/49h, m/86h and m/48h before concluding funds are lost. The sharpest Krux-specific trap is passphrase normalization: the firmware does not apply NFKD, so an accented, emoji or otherwise non-ASCII passphrase silently derives a valid but empty wallet on other software — use ASCII only. Miniscript, TR Miniscript and multisig use custom paths and cannot be recovered from seed words alone, so back up the descriptor (and for multisig the quorum and every co-signer xpub); the on-device encrypted mnemonic store is a convenience, never your only backup. | |||||||
| Trezor Safe 5 high confidence |
SLIP39 (Shamir) 20-word single-share BY DEFAULT, not BIP39. Multi-share SLIP39 (up to 16 shares, e.g. 2-of-3) requires firmware 2.7.2+. BIP39 12/24 words is selectable at setup. Multicoin; Bitcoin is coin type 0'. | m/84'/0'/0' (BIP84 native SegWit, bc1q — Trezor Suite's default Bitcoin account type; account #2 is m/84'/0'/1') | BIP44 m/44'/0'/{acct}', BIP49 m/49'/0'/{acct}', BIP84 m/84'/0'/{acct}' (default), BIP86 Taproot m/86'/0'/{acct}', and BIP48 multisig. Custom paths only via third-party software such as Electrum or Sparrow. | Yes — creates independent hidden wallets. On a SLIP39 backup the passphrase decrypts the master secret, a different layer from BIP39's mnemonic-to-seed step, and does not transfer cleanly between formats. Never stored. | 20 by default (BIP44 convention). Trezor Suite's long-standing request for a configurable per-coin gap limit (trezor-suite issue #3504) was closed via PR #26790; we could not confirm the exact Suite version or menu path, so treat in-app configurability as version-dependent. The reliable route is importing the xpub into Electrum or Sparrow and raising the gap limit there before concluding funds are missing. | Partial — Suite exports per-account xpubs, sufficient for watch-only in third-party software, but there is no native output descriptor export. Capture multisig descriptors from your coordinator instead. | High |
| Restoring elsewhere: The seed standard, not the path, is the fund-loss risk here: a default Safe 5 backup is 20 SLIP39 words, which is not a valid BIP39 length and uses a different wordlist, so BIP39-only tools (Coldcard, Ledger, most software wallets) will reject it — choose BIP39 at setup if you want maximum cross-wallet portability. Trezor lists Electrum, Sparrow, Rabby, BlueWallet and Keystone as able to import SLIP39 backups; treat that as vendor-claimed and test-restore with a small amount first, and note that converting an existing BIP39 wallet to SLIP39 produces 59-word shares. With multi-share you must record the threshold and keep enough shares — holding 1 of a 2-of-3 gets you nothing and shares from different Shamir sets never combine; once the standard is sorted, try m/84'/0'/0' and then m/44', m/49', m/86'. | |||||||
| Trezor Safe 3 high confidence |
BIP39 12-word if initialized before June 2024; SLIP39 20-word single-share if initialized from June 2024 onward. Both overridable at setup (BIP39 12/24-word, SLIP39 single/multi-share; multi-share needs firmware 2.7.2+). | m/84'/0'/0' (BIP84 Native SegWit) — Trezor Suite default Bitcoin account type | m/44'/0'/{acct}', m/49'/0'/{acct}', m/84'/0'/{acct}' (default), m/86'/0'/{acct}' Taproot (firmware 2.4.3+, key-path spend only), BIP48 multisig. Coin type 0'. Custom paths via Electrum or Sparrow. | Yes — creates fully independent hidden wallets. On a SLIP39 backup it decrypts the encrypted master secret, not a BIP39 PBKDF2 salt. Never stored, and unverifiable: every passphrase yields a valid-looking wallet. | 20 by default (BIP44 convention). Trezor Suite's long-standing request for a configurable per-coin gap limit (trezor-suite issue #3504) was closed via PR #26790; we could not confirm the exact Suite version or menu path, so treat in-app configurability as version-dependent. The reliable route is importing the xpub into Electrum or Sparrow and raising the gap limit there before concluding funds are missing. | partial — per-account xpub export via Trezor Suite; no native output descriptor export. Preserve multisig descriptors from the coordinator separately. | High |
| Restoring elsewhere: Count the backup words before anything else: 12 or 24 means BIP39 and restores broadly, 20 means SLIP39 — which BIP39-only wallets (Coldcard, Ledger, most mobile wallets) will reject outright, so the same model name carries two incompatible defaults depending on setup date. Trezor names Electrum, Rabby, Sparrow and BlueWallet as software able to import SLIP39; treat that as a vendor claim and prove it with a small test restore before moving real funds. If a restore shows zero, check m/44'/0'/0', m/49'/0'/0' and m/86'/0'/0' before panicking, and never mix shares from different Shamir sets — they will not combine. | |||||||
| Trezor Model T medium confidence |
BIP39 12-word by default; 18- and 24-word BIP39 also generated and accepted. SLIP39/Shamir is supported but opt-in (multi-share needs firmware 2.7.2+), so a backup may be 12/18/24 words (BIP39) or 20/33 (SLIP39). | m/84'/0'/0' (BIP84 Native SegWit) — Trezor Suite default; units set up in the pre-SegWit era may hold funds on m/44'/0'/0' or m/49'/0'/0' | m/44'/0'/{acct}', m/49'/0'/{acct}', m/84'/0'/{acct}' (default), BIP48 multisig, m/86'/0'/{acct}' Taproot from firmware 2.4.3+ (2.4.2 and older refuse Taproot). Coin type 0'. Custom paths via Electrum or Sparrow. | Yes — on-device or host entry, creating fully independent hidden wallets; never stored and unrecoverable if lost. With a SLIP39 backup it decrypts the encrypted master secret rather than acting as a BIP39 PBKDF2 salt. | 20 by default (BIP44 convention). Trezor Suite's long-standing request for a configurable per-coin gap limit (trezor-suite issue #3504) was closed via PR #26790; we could not confirm the exact Suite version or menu path, so treat in-app configurability as version-dependent. The reliable route is importing the xpub into Electrum or Sparrow and raising the gap limit there before concluding funds are missing. | partial — per-account xpub export via Trezor Suite; no native output descriptor export. | High |
| Restoring elsewhere: Count the words first: 12, 18 or 24 means BIP39 and restores broadly, while 20 or 33 means SLIP39 (1024-word list, not BIP39's 2048) and will be rejected by BIP39-only wallets such as Coldcard, Ledger and most mobile wallets — an 18-word backup is a valid BIP39 seed, not a damaged SLIP39 share. Because the Model T spans many years of firmware defaults, check m/49'/0'/0' and m/44'/0'/0' before concluding that an m/84'/0'/0' restore is genuinely empty, and raise the gap limit in Electrum or Sparrow if addresses were used heavily. Multi-share holders must record the threshold and keep one coherent share set; the device is discontinued, so plan a migration to a current signer. | |||||||
| Trezor Safe 7 medium confidence |
SLIP39 (Shamir) 20-word single-share by default, NOT BIP39 — same default as the Safe 5 and post-June-2024 Safe 3. BIP39 12/24-word stays selectable via the Backup format dropdown. Multi-share SLIP39 available. | m/84'/0'/0' (BIP84 Native SegWit) — Trezor Suite default, P2WPKH encoded as Bech32 (bc1q) | m/44'/0'/{acct}', m/49'/0'/{acct}', m/84'/0'/{acct}' (default) and BIP48 multisig per trezor-firmware docs; m/86'/0'/{acct}' Taproot (bc1p) via Trezor Suite. Coin type 0'. The Bitcoin-only Edition uses the same paths. | Yes — Passphrase Protection is listed on the official product page. With a SLIP39 backup it decrypts the encrypted master secret rather than acting as a BIP39 25th word, so it does not carry over to a BIP39 wallet. | 20 by default (BIP44 convention). Trezor Suite's long-standing request for a configurable per-coin gap limit (trezor-suite issue #3504) was closed via PR #26790; we could not confirm the exact Suite version or menu path, so treat in-app configurability as version-dependent. The reliable route is importing the xpub into Electrum or Sparrow and raising the gap limit there before concluding funds are missing. | partial — per-account xpub export via Trezor Suite; no native output descriptor export recorded for Trezor devices. Preserve multisig descriptors from the coordinator separately. | High |
| Restoring elsewhere: A default Safe 7 backup is 20 words of SLIP39: it is not BIP39, it uses a different wordlist, and BIP39-only wallets (Coldcard, Ledger, most mobile wallets) will reject it — Trezor's own guidance is to recover on a SLIP39-compatible device first, then move the funds to a new BIP39 wallet. If cross-wallet portability matters more to you than Shamir's benefits, deliberately select the BIP39 12- or 24-word option at setup. Trezor names Electrum, Rabby, Sparrow, BlueWallet and the Keystone hardware wallet as able to import SLIP39; prove that with a small test restore before committing real funds, and multi-share users must record the threshold and keep one coherent share set. | |||||||
| Ledger Nano S Plus high confidence |
BIP39. The device generates 24 words and restores 12/18/24-word phrases. The optional paid Ledger Recover service shards the seed to third-party custodians; it is opt-in and does not change the BIP39 seed or its derivation. | m/84'/0'/0' (Native SegWit, bc1q) — the account type Ledger Live creates by default | m/44'/0'/0' (1…), m/49'/0'/0' (3…), m/84'/0'/0' (bc1q), m/86'/0'/0' (bc1p); non-defaults need 'Show all address types'. BIP-44/48/49/84/86/87 standard on-device; wallet policies since app 2.0.0, MuSig2 from 2.4.0. | Yes — standard BIP39 passphrase, up to 100 characters, case- and symbol-sensitive, in 'attached to a secondary PIN' or 'temporary' mode. The secondary PIN is Ledger-local convenience only and is not part of the secret. | 20 unused addresses on the external receive chain (BIP44 convention, per Ledger's Address gap limit article). Not a device property — the signer derives on request, and Ledger Live exposes no adjustable setting. | partial — Ledger Live exports per-account xpubs only, never output descriptors. Descriptors and BIP388 wallet-policy registration come via HWI, Sparrow or Specter; non-standard paths need on-device confirmation. | High |
| Restoring elsewhere: The 24 words restore everything only if you also know the account structure: every 'account' added in Ledger Live is a separate hardened index — m/84'/0'/0', then m/84'/0'/1', then m/84'/0'/2' — and other wallets typically scan account 0 only, so a user with four accounts sees roughly a quarter of their money and wrongly concludes the rest is lost. Coins received into Legacy, SegWit or Taproot accounts sit at 44'/49'/86', so a BIP84-only restore shows zero; restore into descriptor-capable software and sweep all four purposes across account indices 0, 1, 2… until several consecutive accounts come back empty. Coin type 0' covers Bitcoin only, and if a passphrase was used the words alone yield a real but empty wallet — the most misdiagnosed outcome of all. | |||||||
| Ledger Nano X high confidence |
BIP39, 24 words generated (12/18/24 restorable). Same BOLOS OS and Ledger Bitcoin app as the Nano S Plus, so key derivation is identical. The optional Ledger Recover service applies here too and does not change the seed. | m/84'/0'/0' (Native SegWit, bc1q) — Ledger Live default account type | Same as the Nano S Plus: m/44'/0'/0', m/49'/0'/0', m/84'/0'/0', m/86'/0'/0'; BIP48 multisig and custom paths via HWI/Sparrow/Specter; wallet policies since app 2.0.0, MuSig2 from 2.4.0. Derivation follows the app, not the model. | Yes — standard BIP39 passphrase in secondary-PIN or temporary mode. Fully portable to any BIP39 wallet; the secondary PIN is device-local only and is not part of the secret. | 20 unused addresses (BIP44 convention). Not a device property — address discovery belongs to the companion software, and Ledger Live exposes no adjustable setting. | partial — no output-descriptor export from Ledger Live, per-account xpub only. Descriptors and wallet-policy registration are available via HWI, Sparrow or Specter. | High |
| Restoring elsewhere: Same two traps as the Nano S Plus: each Ledger Live account maps to an incrementing hardened index (m/84'/0'/0', m/84'/0'/1', …), and mixed address types scatter funds across 44'/49'/84'/86', so restore the 24 words into descriptor-capable software and sweep all four purposes across account indices 0..n before concluding anything is lost. Bluetooth is a transport detail and is irrelevant to recovery — the seed is a standard BIP39 seed. Coin type 0' is Bitcoin only, and a passphrase-protected wallet restores as an empty-looking wallet without the passphrase. | |||||||
| Ledger Stax medium confidence |
BIP39 — 24 words generated, 12/18/24 accepted on restore. Runs the same BOLOS OS and Bitcoin app as Nano S Plus / Nano X, so derivation is identical. Ledger Recover optionally available. | m/84'/0'/0' (Ledger Live creates Bitcoin Native SegWit accounts by default) | BIP44 m/44'/0'/0', BIP49 m/49'/0'/0', BIP84 m/84'/0'/0', BIP86 m/86'/0'/0'; BIP48 multisig and custom paths via third-party hosts; BIP388 wallet policies (Bitcoin app 2.1.0+), MuSig2 (2.4.0+). | Yes — standard BIP39 passphrase, PIN-attached or temporary. Fully portable; the secondary PIN is not part of the secret. | unverified — a companion-software setting, not a device property. BIP44 convention is 20; no published Ledger Live figure. | Partial — Ledger Live exports an xpub per account but no output descriptors. Descriptors and wallet policies are obtained via HWI, Sparrow or Specter. | High |
| Restoring elsewhere: Each Ledger Live account sits at its own hardened account index, so a naive restore that only checks account 0 shows an empty or partial wallet. After restoring the 24 words plus any passphrase, sweep m/84'/0'/i', m/86'/0'/i', m/49'/0'/i' and m/44'/0'/i'; the Bitcoin app caps the account level at 100 and the address index at 50000, so the search terminates. Behaviour is identical to the Nano S Plus and Nano X — the touchscreen changes nothing about key derivation. | |||||||
| BitBox02 medium confidence |
BIP39 — the device generates 24 words; 12, 18 or 24 are accepted on restore. Primary backup medium is a microSD card in a BitBox-specific but open-source format; the BIP39 words can be displayed on demand. | m/84'/0'/0' (BitBoxApp defaults to Native SegWit, zpub) | BIP49 m/49'/0'/0', BIP84 m/84'/0'/0', BIP86 m/86'/0'/0' (Taproot); multisig is BIP48 P2WSH only at m/48'/0'/account'/2'. No BIP44 legacy for Bitcoin — the firmware does not derive or sign P2PKH. | Yes — optional BIP39 passphrase, standard and portable. | unverified — set by BitBoxApp or the companion wallet, not by the device. BIP44 convention is 20; no published BitBoxApp figure and no documented user-adjustable setting. | Yes — BitBoxApp shows the xpub and exact keypath per account. Taproot and multisig descriptors come from third-party software connected to the device (Sparrow, HWI, Electrum). | High |
| Restoring elsewhere: A microSD-only backup is NOT device-locked: BitBox publishes an official offline, open-source tool that extracts the BIP-39 words from the backup file in a browser with no BitBox02 present, so a lost or dead device does not strand those coins — run it on an air-gapped machine and sweep to a fresh wallet afterward, because the seed is exposed to a computer in the process. BitBoxApp uses unified accounts spanning wrapped SegWit, native SegWit and Taproot at once, so restore the words plus any passphrase and scan m/84'/0'/0', then m/49'/0'/0' and m/86'/0'/0', before concluding a wallet is empty. Multisig needs the full output descriptor with every cosigner xpub backed up separately, and legacy m/44' funds from an imported seed will never appear on the device. | |||||||
| BitBox02 Nova low confidence |
BIP39, 12 or 24 words, plus the same microSD backup as the BitBox02 (BitBox-specific format, open-source and extractable without the device). Bitcoin-only edition available; EAL6+ Optiga Trust M V3 secure chip. | m/84'/0'/0' (Native SegWit default in BitBoxApp; inherited from shared BitBox02 firmware, no Nova-specific document) | BIP49 m/49'/0'/0', BIP84 m/84'/0'/0', BIP86 m/86'/0'/0' (Taproot); multisig is BIP48 P2WSH only at m/48'/0'/account'/2'. BIP44 legacy is not documented for Bitcoin. Inherited from BitBox02 firmware. | Yes — optional BIP39 passphrase, standard and portable. | unverified — set by companion software, not by the device. BIP44 convention is 20. | Yes, delivered through companion software (BitBoxApp, Sparrow, Electrum) rather than as a standalone device function. | High |
| Restoring elsewhere: The 12/24 BIP39 words plus any passphrase restore anywhere — scan m/84'/0'/0' first, then m/49'/0'/0' and m/86'/0'/0'. A microSD-only backup is NOT a dead end: BitBox's official open-source offline tool extracts the BIP-39 words from the backup file with no BitBox hardware present, but it exposes the seed to a computer, so run it fully offline and sweep to a fresh wallet afterward. A Bitcoin-only Nova derives Bitcoin coin types only, so altcoins on a multicoin seed will not appear — those funds are not lost and remain reachable by restoring the same seed on other hardware or software. | |||||||
| Foundation Passport (Passport Core) medium confidence |
BIP39, 12 or 24 words (12-word support added in firmware v2.3.0). Foundation documents that Passport abides by the BIP39 standard and that accounts follow BIP-32, so the seed is usable in any compatible wallet. | m/84'/0'/0' (BIP84 Native SegWit) | Default BIP84 m/84'/0'/0'; also BIP86 m/86', plus BIP44 m/44' and BIP49 m/49' (derived and signable); multisig m/48'/0'/acct'/1' and /2' and legacy m/45'; Postmix m/84'/0'/2147483646'. | Yes — Settings > Advanced > Passphrase. Standard BIP39 passphrase, never stored on the device, cleared at power-off, with an optional prompt on every boot. Fully portable. | unverified — Passport is airgapped and does no chain scanning, so the gap limit is whatever the paired coordinator (Sparrow, Nunchuk, Envoy) uses. BIP44 convention is 20. | Yes — the Bitcoin Core export emits canonical checksummed descriptors, e.g. wpkh([xfp/84h/0h/0h]xpub/0/*)#checksum, plus wallet-config files by QR or microSD for Sparrow, Specter and Nunchuk. | High |
| Restoring elsewhere: Single-sig funds restore anywhere from the 12/24 words at m/84'/0'/0', and legacy or wrapped-SegWit accounts are fully visible and signable — export to Sparrow and select the m/44' or m/49' account. The real trap is Postmix: coins from Whirlpool postmix sit at m/84'/0'/2147483646' (account index 2^31-2), which no default discovery and no standard account sweep will ever reach, so that exact index must be entered by hand. Multisig quorums cannot be rebuilt from the seed alone — back up the full output descriptor with every cosigner xpub. | |||||||
| Foundation Passport Prime low confidence |
BIP39-compatible master key, but the default backup is Magic Backup — a 2-of-3 Shamir split across two NFC KeyCards and an Envoy share. A 12/24-word BIP39 phrase exists only if you ran the optional manual export (KeyOS 1.2.1+). | No single default — KeyOS derives six descriptor sets per account and the preferred address type is a per-account setting; m/84'/0'/0' is only the fallback. | Per account index i: m/44'/0'/i', m/49'/0'/i', m/84'/0'/i', m/86'/0'/i', m/48'/0'/i'/1' and m/48'/0'/i'/2', each with external and internal keychains (coin type 1' on testnet). No Postmix account — that is Passport Core only. | Yes — standard BIP39 passphrase. Never stored on the device or in any encrypted backup, so a Magic Backup restores only the empty-passphrase wallet; back the passphrase up separately. | unverified — not a device property; set by your coordinator. BIP44 convention is 20; raise it if addresses were skipped. | Yes — full xpub, fingerprint and keypath export with SLIP-132 encoding (zpub, ypub) plus coordinator-specific exports for Sparrow, Electrum and BTCPay. | High |
| Restoring elsewhere: Restore the exported BIP39 words or your Magic Backup shares plus any passphrase, then scan all six paths at account indices 0, 1, 2… and confirm the keypath shown in the device's Account Details rather than assuming m/84'/0'/0'. If you onboarded the default way and never performed the word export, you hold KeyCards and not a seed phrase — do the export if you want vendor-independent recovery, and back up multisig descriptors separately. The other apps' keys are derived from the master seed and survive a restore, but their metadata (FIDO relying-party info, counters, derivation indices) and Files app contents are not in the seed; Prime is newly released and much of this is documented only in the KeyOS source, so verify on-device before relying on it. | |||||||
| Blockstream Jade high confidence |
BIP39, 12 or 24 words, optional BIP39 passphrase. Supports SeedQR and dice entropy. PIN uses an open-source 'blind oracle' server rather than a secure element, which affects device unlock, not seed portability. | m/84'/0'/0' (Blockstream Green singlesig; Green 2FA Protected accounts, formerly branded Multisig Shield, use a Green-specific 2-of-2 or 2-of-3 construction with no portable single path) | m/49'/0'/0', m/84'/0'/0', m/86'/0'/0' (taproot xpub export added in firmware 1.0.34), BIP48 multisig m/48'/0'/0'/1', custom paths, Miniscript, plus Green 2-of-2, 2-of-3 and 2-of-2+CSV policies. | Yes — optional BIP39 passphrase; different passphrases produce entirely separate wallets, which is the decoy mechanism. Jade's duress PIN erases the on-device wallet rather than revealing a decoy. | unverified — not a device property; set by Green or the paired coordinator. BIP44 convention is 20. | Yes on current firmware — wallet descriptor export to USB shipped in 1.0.31, with registered-descriptor APIs from 1.0.30. BIP174 PSBT signing supported. walletsrecovery.org still records 'No'. | High |
| Restoring elsewhere: Establish the Green account type before promising a seed-only restore: singlesig wallets restore in any BIP39 wallet — scan m/84'/0'/0', then m/49'/0'/0', then m/86'/0'/0' — but 2FA Protected (Multisig Shield) accounts cannot be imported into other wallet apps, and Blockstream warns the phrase entered elsewhere "may be accepted by the app, but it will generate an empty single-signature wallet". Those coins recover through Blockstream's open-source garecovery tool once the CSV/2FA timelock expires (default 360 days); coins received after 25 January 2021 need only the mnemonic, while older nLockTime-era coins also require the nlocktimes.zip backup and 2-of-3 additionally requires the recovery xpub. Never tell a Jade owner their 24 words are all they need without first confirming which account type was used. | |||||||
| Blockstream Jade Plus medium confidence |
BIP39, 12 or 24 words (firmware 1.0.40 rejects other lengths), optional BIP39 passphrase. Green singlesig wallets import into any BIP39 wallet using BIP44/49/84. Blind-oracle PIN model, no secure element. | m/84'/0'/0' (Native SegWit singlesig — the documented default xpub export for Jade Plus) | m/84'/0'/0' (default), m/49'/0'/0', multisig m/48'/0'/0'/2' and m/48'/0'/0'/1', taproot m/86'/0'/0' (firmware 1.0.34), custom paths, Miniscript, plus Green 2-of-2, 2-of-3 and 2-of-2+CSV policies. | Yes — optional BIP39 passphrase; a different passphrase yields an entirely separate wallet, which is the decoy mechanism. The duress PIN is a wallet-erase PIN and does not reveal a decoy. | unverified — not a device property; set by the companion wallet. BIP44 convention is 20. | Yes — wallet descriptor export to USB (firmware 1.0.31) plus registered-descriptor APIs (1.0.30) covering multisig and Miniscript wallets. BIP174 PSBT signing supported. | High |
| Restoring elsewhere: A plain singlesig Jade Plus restores normally from its 12 or 24 words at m/84'/0'/0', but Green 2FA Protected (Multisig Shield) accounts cannot be imported into any other wallet app and must be recovered through Blockstream's own tooling. For Miniscript or multisig vaults the seed alone reconstructs no spending policy, so back up the full output descriptor alongside the words and confirm it restores in software supporting that policy. A duress-PIN wipe is survivable only if the recovery words are already stored offline. | |||||||
| Keystone 3 Pro medium confidence |
BIP39 (12 or 24 words) and SLIP39 Shamir backup with configurable share count and threshold. Stores up to three independent seed phrases on one device, each an entirely separate wallet requiring its own backup. | m/84'/0'/0' (Native SegWit — Keystone's documented default BTC address format) | BIP44 m/44'/0'/0', BIP49 m/49'/0'/0', BIP84 m/84'/0'/0', BIP86 m/86'/0'/0', BIP48 multisig (walletsrecovery.org, verified 2026-06-02). On-device docs cover 44/49/84; taproot and BIP48 run via coordinators. | Yes — optional BIP39 passphrase ('25th word'), standard and portable. SLIP39 has its own separate passphrase/extension mechanism; the two are not interchangeable. | unverified — not a device property; the airgapped signer does no chain scanning, so the paired coordinator sets it. BIP44 convention is 20. | Partial — walletsrecovery.org records output_descriptor 'No', but xpub and multi-account wallet exports by QR to Sparrow, Specter, Nunchuk and BlueWallet are sufficient to build watch-only wallets. | High |
| Restoring elsewhere: The Keystone-specific trap is seed-standard confusion: SLIP39 shares are not BIP39 words, a BIP39 field rejects them on wordlist, length and checksum, and the owner must know which standard was used plus the share count and threshold. Second trap: the device holds up to three separate seeds, so someone who backed up "the Keystone seed" may hold only one of three wallets. For a standard BIP39 restore, scan m/84'/0'/0' first, then m/86'/0'/0', m/49'/0'/0' and m/44'/0'/0'; multisig quorums still require the full descriptor with every cosigner xpub. | |||||||
| Coinkite TAPSIGNER high confidence |
Not BIP39 — no mnemonic, no word list, and no way to display words. The card generates a raw BIP32 master key on-device from its internal TRNG combined with a 32-byte chain_code supplied by the app at setup. | m/84h/0h/0h (documented default; the path is app-controlled and may be changed at will, so read the in-use path off the card rather than assuming it) | Arbitrary hardened BIP32 paths up to 8 levels deep; unhardened components are rejected. m/44'/0'/0', m/49'/0'/0', m/84'/0'/0' and m/86'/0'/0' are all reachable, bounded in practice by the companion app. | No — there is no BIP39 seed, so no BIP39 passphrase and no '25th word'. Protection is the CVC/PIN printed on the card (changeable by the user) plus physical NFC possession. | unverified — not a device property; the card performs no chain scanning, so discovery is entirely the companion wallet's job. BIP44 convention is 20. | Partial — the card exposes its xpub over NFC to the companion app, and the encrypted backup file carries the master XPRV plus the current derivation path. It emits no output descriptors itself. | High |
| Restoring elsewhere: The only backup is the 'backup' command output: a file encrypted with AES-128-CTR using a zero IV, holding two lines — the master XPRV in Base58 and the current derivation path — whose 16-byte hex decryption key is factory-printed on the back of the card, so the file must be stored separately from the card or it is not a backup and a lost card makes any stored backup permanently undecryptable. There is no restore command; recovery means decrypting the file externally (openssl aes-128-ctr -iv 0 -K <hex-key>) and importing the XPRV into wallet software. Use the path on the file's second line, not the m/84h/0h/0h default, because the owner may have changed it. | |||||||
| Bitkey (Block) medium confidence |
No seed phrase by design — no BIP39 mnemonic. A 2-of-3 multisig: App Key (mobile), Hardware Key (device), Server Key (Block-operated); any two can sign. walletsrecovery.org notes 'Proprietary schema, dangerous recovery'. | m/84'/0'/0' per key, but funds live in a 2-of-3 descriptor — wsh(sortedmulti(2,<app>,<hardware>,<server>)) with per-key origin [fp/84h/0h/0h]xpub/... — never a single-sig account path | walletsrecovery.org records BIP49, BIP84 and BIP48 as true, BIP44 and BIP86 false, with no custom-path support. In practice the live wallet is a BIP84-path 2-of-3 wsh(sortedmulti(...)). | No — not supported; there is no BIP39 seed for a passphrase to extend. Access control is device fingerprint plus the mobile app, with a 7-day security waiting period on certain recovery flows. | unverified — not a device property and not user-exposed; discovery is handled by the Bitkey app and Emergency Exit Kit tooling. BIP44 convention is 20. | Yes — the app's Exports screen offers 'Current wallet descriptor / Export XPUB bundle', emitting external and change watch-only descriptors. PSBT is not supported, so signing stays inside Bitkey's own flow. | High |
| Restoring elsewhere: There are no words to restore: normal recovery replaces a lost key using the surviving two (lost phone = hardware + server key; lost hardware = app + server key, then order replacement hardware), with a 7-day wait on some flows and a 6-month contest window on inheritance claims. The only Block-independent path is the Emergency Exit Kit, an encrypted PDF in the owner's own cloud holding an App Key copy that only their hardware device can decrypt, so it must be generated in advance and still requires physical possession of the device — losing the hardware while Block is unavailable is not survivable. The exported descriptor is watch-only: it allows independent balance verification in Sparrow or Bitcoin Core but confers no spending ability. | |||||||
Wallet software — recovery & derivation reference
| Name | Seed standard | Default path | Paths supported | Passphrase | Gap limit | Descriptor export | Restore risk |
|---|---|---|---|---|---|---|---|
| Bitcoin Core (wallet) medium confidence |
No mnemonic — Core implements neither BIP39 nor SLIP39. Descriptor wallets derive from an internal BIP32 master key in wallet.dat. The only backups are the wallet.dat file or `listdescriptors true` output, which contains the xprv. | m/84'/0'/0' (default bech32 receive). A new descriptor wallet creates four pairs at once: m/44'/0'/0' pkh, m/49'/0'/0' sh(wpkh), m/84'/0'/0' wpkh, m/86'/0'/0' tr. | BIP44/49/84/86 all created by default; BIP48 and arbitrary custom paths importable via `importdescriptors`. Pre-v23 legacy HD wallets used m/0'/0'/i' receive and m/0'/1'/i' change — all-hardened, no account xpub. | No BIP39 passphrase. `encryptwallet` / `walletpassphrase` only encrypts private keys at rest in wallet.dat — it is not a 25th word and does not change key derivation. | No BIP44-style gap limit. Keypool default 1000 (descriptor range 0–999), set via the `keypool` option or an explicit `range` in `importdescriptors`. Rescan is birthdate/timestamp-driven. | yes — `listdescriptors` (public) and `listdescriptors true` (includes xprv). Core is the reference implementation of output descriptors. | High |
| Restoring elsewhere: There is no seed phrase to restore: back up wallet.dat, or store `listdescriptors true` output as securely as a seed since it holds the xprv, and give a descriptor restored elsewhere an explicit wider `range` if the wallet used many addresses. Legacy pre-descriptor wallets can no longer be loaded at all from Bitcoin Core 30.0, and dumpwallet, dumpprivkey, importprivkey, importwallet and sethdseed were removed, so their non-BIP44 m/0'/0'/i' coins are invisible to third-party path scans and `migratewallet` is the only route. WARNING: migrating on 30.0 or 30.1 can in rare cases delete every wallet file on the node (those binaries were pulled; the fix ships in 30.2) — copy wallet.dat to verified offline media first, then migrate on 29.x or wait for 30.2. | |||||||
| Specter Desktop medium confidence |
None of its own — a watch-only coordinator; keys stay on the hardware signer, in practice BIP39. Exception: the Bitcoin Core backend hot-wallet feature generates a BIP39 phrase and loads the xprv into Core. | m/84'/0'/0' (native segwit single-sig, mainnet; m/84'/1'/0' on testnet). Hardcoded in Specter's device template alongside m/49'/0'/0'. | BIP49 (m/49'/0'/0') and BIP84 (m/84'/0'/0') single-sig; BIP44 legacy; BIP48 multisig m/48'/0'/0'/1' (P2SH-P2WSH) and /2' (P2WSH). Custom paths typable; taproot depends on the device and Core version. | Pass-through only — applied on the signing device (BitBox02, Coldcard, Specter DIY); Specter never manages BIP39 passphrases and sees only the resulting xpub. | 20 by default — "By default only 20 addresses are watched." Raise the address count in wallet settings and rescan if a restore looks short; more addresses means longer sync. | yes — wallet settings export a JSON file with all the public-key information needed; the underlying wallets are native output descriptors because Specter drives Bitcoin Core. | High |
| Restoring elsewhere: Specter stores no keys, so you restore the DEVICE seed plus the DESCRIPTOR, not Specter itself; single-sig (BIP39 words + m/84'/0'/0') restores anywhere. For multisig the seeds alone are not enough — without every cosigner xpub the redeem script cannot be rebuilt and the funds are unspendable, so keep the exported wallet JSON with every seed backup, off the node machine. If a restored wallet shows a zero or short balance, the coins are most likely past address index 20: raise the address count in wallet settings and rescan before concluding anything is lost. | |||||||
| Sparrow Wallet high confidence |
BIP39 (12 or 24 words) with optional passphrase. Sparrow imports Electrum wallet FILES but has no manual Electrum seed-word entry. Watch-only via xpub or output descriptor is also supported. | m/84'/0'/0' (new-wallet default is single-sig Native Segwit / P2WPKH; the path is shown and editable at creation). | BIP44 (m/44'/0'/0'), BIP49 (m/49'/0'/0'), BIP84 (m/84'/0'/0'), BIP86 (m/86'/0'/0'), plus BIP48 multisig m/48'/0'/0'/1' (P2SH-P2WSH) and /2' (P2WSH). Fully custom paths can be typed in. | Yes, full BIP39. Per Sparrow's FAQ, "Sparrow stores nothing in your wallet file that is derived from your passphrase" — so a mistyped passphrase silently opens a different, valid, empty wallet with no error. | 20 by default for normal wallets, 40 for Postmix wallets. User-adjustable: Settings tab → Advanced → increase gap limit → Close → Apply. | yes — full output descriptors and xpubs, with an xpub/ypub/zpub (SLIP-132) toggle for the chosen script type. Best-in-class descriptor tooling alongside Bitcoin Core. | Medium |
| Restoring elsewhere: A default Sparrow wallet is plain BIP39 + m/84'/0'/0' and restores into Electrum, BlueWallet, Core or a hardware wallet without surprises. Always verify the first receive address matches after a restore, because a wrong passphrase fails silently, and record any custom path you typed at creation alongside the seed. A wallet imported from an Electrum seed is NOT BIP39 — Electrum's seed-to-master-key algorithm differs, so no derivation path will recover it in a BIP39-only wallet (an empty balance there does not mean the coins are gone); restore it in Electrum, and for multisig store the descriptor as well as the seeds. | |||||||
| Liana medium confidence |
BIP39 for the optional built-in hot signer, whose mnemonics are stored in clear on your drive. Designed for external signers (Ledger, Coldcard, Specter DIY, BitBox02, Jade). The mnemonic alone is never a sufficient backup. | m/48'/0'/0'/2' on mainnet (m/48'/1'/0'/2' on all test networks). Unchanged for Taproot; additional keys from the same device increment the account index. | Descriptor-defined rather than menu-selected: BIP48 script-type-2' is the base for both wsh() and tr() policies. From v2.0 one xpub can serve several spending paths via different unhardened indexes. Multipath: /<0;1>/*. | Device-dependent — BIP39 passphrase support comes from whichever signing device you use; it is not a Liana-level feature. Do not rely on the hot signer's handling given its plaintext mnemonic storage. | No BIP44-style gap limit. Recovery runs through a Bitcoin Core descriptor import: RECOVER.md instructs range [0,10000] and lianad uses 1,000 at initial import. Rescan is driven by the wallet birthdate. | yes, and mandatory rather than optional. v10.0 added a full wallet backup covering descriptors, labels, transactions, aliases and the last derivation index — everything except the keys. | High |
| Restoring elsewhere: SEED WORDS ALONE CAN NEVER RESTORE A LIANA WALLET: the miniscript descriptor encodes the entire spending policy — the timelock, every cosigner xpub and the derivation indexes — and Liana's docs state that "without the descriptor you won't be able to recover from your backup." The descriptor is not secret-equivalent (a thief learns your balance but cannot spend), so keep more copies of it than of your seed; to recover, importdescriptors BOTH the receive and change descriptors into a watch-only Bitcoin Core wallet with the birthdate timestamp, then sign with the relevant device. The recovery path is a RELATIVE timelock (OP_CSV) measured in blocks of coin age, and the timer resets every time a coin is moved or refreshed. | |||||||
| Wasabi Wallet medium confidence |
BIP39 (12 words), with SLIP39 also listed as supported. Wasabi's supported-BIPs page lists BIP32, BIP39, BIP44, BIP84, BIP86, BIP174 (PSBT), BIP341 and BIP352. | m/84'/0'/0' for segwit; taproot accounts use m/86'/0'/0'. Testnet uses the standard BIP84 coin type 1' (not Wasabi-documented). | BIP84 (m/84'/0'/0') and BIP86 (m/86'/0'/0') are what Wasabi actually derives. BIP44 is listed as a structural standard only — no legacy P2PKH receive addresses, no BIP49 nested segwit, no custom path entry. | Yes, and presented as the wallet password: it encrypts the private key inside the wallet file (BIP38) AND doubles as the BIP39 passphrase, a 13th word. Without it you cannot spend, and Wasabi cannot check it at recovery. | MinGapLimit default 21, auto-increased as needed and manually editable in the wallet file. Wasabi documents raising it to roughly 100 when restoring elsewhere or in BTCPay. | partial — no output-descriptor or xpub export through the GUI (still an open request). The xpub is present in the wallet file, and a watch-only wallet can be constructed from it manually. | High |
| Restoring elsewhere: A Wasabi 2.2+ wallet can hold coins on BOTH m/84'/0'/0' and m/86'/0'/0', so scan both paths — restoring only BIP84 silently misses every taproot (bc1p...) coin; Wasabi points taproot restores at Sparrow, while segwit-only restores work in Sparrow, Electrum, Specter, BlueWallet or BTCPay. Coinjoin generates far more addresses than ordinary use, so raise the receiving wallet's gap limit to 100+ before concluding funds are missing. The wallet password IS the BIP39 passphrase and cannot be validated at recovery: a wrong one silently opens a different, valid, empty wallet. | |||||||
| Electrum high confidence |
Electrum's own format, not BIP39. Same 2048-word English list, but different checksum and KDF salt ("electrum" vs BIP39's "mnemonic"). Version prefixes: 0x01 legacy, 0x100 segwit, 0x101 2FA, 0x102 2FA segwit. | m/0' (native-segwit single-sig Electrum seed). Also m/1' for segwit multisig, and bare m/ (the BIP32 root) for legacy 'standard' seeds. Not m/84'/0'/0'. | Native Electrum seeds: m/, m/0', m/1' only — no purpose/coin-type/account levels. BIP39 imports and hardware wallets get full BIP44/49/84/86 (m/purpose'/coin'/account') plus an arbitrary custom path field. | Yes, as a "seed extension" on Electrum's own algorithm — not interchangeable with a BIP39 passphrase, and not reproducible in any BIP39 wallet. Honoured normally for imported BIP39 seeds. Pre-2.0 'old' seeds cannot take one. | 20 for receiving addresses. Change gap limit rose from 6 to 10 in 2020 and is resolved at runtime in current builds, so check your version. Adjustable from the console (wallet.change_gap_limit(n)); hundreds is normal for recovery. | Partial. Reliably exports master public keys (xpub/ypub/zpub per script type) for watch-only use, but output-descriptor tooling is thinner than Bitcoin Core, Sparrow or Specter — do not expect a clean round-trip. | High |
| Restoring elsewhere: An Electrum-native seed entered into a BIP39 wallet either fails the checksum or silently derives a different, valid, EMPTY wallet — the coins are untouched on-chain, the software is just looking at the wrong keys; restore in Electrum, or in Sparrow by importing the Electrum wallet FILE (pasted Electrum words return "Invalid checksum"). The mirror mistake is equally common: a BIP39 seed pasted into Electrum's normal restore box gets Electrum's m/0' and shows zero, so you must tick Options → BIP39 and then choose the correct script type (m/84'/0'/0' for native segwit). Never tell an Electrum user their wallet is BIP84 — if a restore shows zero, first establish which of the two seed formats you hold, then widen the gap limit, before concluding loss. | |||||||
| Nunchuk medium confidence |
BIP39 (12 or 24 words). TAPSIGNER and other hardware signers are supported as key sources. No SLIP39 or Aezeed. | unverified — Nunchuk publishes no single-sig derivation path, and its wallet-creation docs show neither a path nor a script-type selector. Read the actual path from your exported descriptor or BSMS file. | Multisig uses BIP48, in two variants (see recovery note). Single-sig script types and BIP86 taproot support are unverified. Custom paths for hardware devices remain an open request (libnunchuk issue #7, open since Feb 2021). | Supported and recovery-critical: Nunchuk states any key that has a passphrase must be recovered using both the seed phrase and the passphrase. A passphrase-at-creation flow is undocumented. | unverified — Nunchuk publishes no figure. Its Bitcoin Core recovery guide imports descriptors with "range": 1000, which is a scan range, not a gap limit; do not report 1000 as Nunchuk's gap limit. | Yes — exports wallet configuration as BSMS (BIP129) natively and in COLDCARD/Sparrow-readable format. The descriptor is the documented recovery vehicle and the authoritative record of your real derivation paths. | High |
| Restoring elsewhere: The seed alone is never enough for a Nunchuk multisig: you also need the wallet configuration file / output descriptor plus enough seeds to meet quorum, because keeping every seed without the config still leaves you unable to reconstruct the script. Nunchuk uses two different multisig paths — keys created in common hardware signers use m/48h/0h/0h/2h, but keys created inside Nunchuk, including TAPSIGNER, use m/48h/0h/0h with no script-type suffix, so any tool that assumes BIP48's /2h derives the wrong xpub and shows a zero balance. Wallets created before 26 July 2023 predate Nunchuk's BIP48/BIP129 alignment, so check your export's vintage. | |||||||
| BlueWallet high confidence |
BIP39 primarily, but the same import box also reads SLIP39, Aezeed (LND cipher seed), Electrum-native and Breadwallet-style seeds. Multiple seed standards under one import box. | m/84'/0'/0' — the official wiki states verbatim: "By default, BlueWallet creates BIP84 (account zero)." | BIP44/49/84 (m/44'|49'|84'/0'/0'); multisig m/48'/0'/0'/2' and m/48'/0'/0'/1', legacy m/45'; Breadwallet m/0'; bare m/ Electrum-style; custom path on import; watch-only xpub/ypub/zpub; WIF. No taproot/BIP86. | Yes on import — the wiki documents BIP39 passphrase support, plus passphrases for SLIP39, Aezeed and Electrum seeds. walletsrecovery.org records "N/A", so treat passphrase-at-creation as unverified. | unverified — neither the docs nor the 17-page wiki publish one. Do not assert 20; that is a BIP44 convention, not a sourced BlueWallet value. | Partial — walletsrecovery.org marks output descriptors "WIP". Multisig wallets export a coordination/config file and xpubs, and PSBT (BIP174) is fully supported, but expect no clean descriptor string for single-sig. | High |
| Restoring elsewhere: Single-sig on-chain restores easily — 12 BIP39 words at m/84'/0'/0' into Electrum, Sparrow or Core — but if the wallet was created as BIP49 wrapped, m/45' multisig or Breadwallet m/0', scan 44'/49'/84' before concluding funds are gone. The real trap is the seed standard: BlueWallet also ingests SLIP39 and Aezeed, which a BIP39-only wallet usually rejects on wordlist or checksum and occasionally imports as a different, empty wallet, so establish which standard your words belong to first. Lightning balances were historically custodial LNDhub, tied to an lndhub:// string that is not derived from the BIP39 seed and not recoverable from the 12 words — back that credential up separately. | |||||||
| Blockstream Green medium confidence |
BIP39 — 12 words by default, 24 also supported; a 12-word Green phrase is complete, not a truncated 24-word backup. The mnemonic is BIP39 in both modes, but the script is not always standard. | Mode-dependent. Singlesig: BIP44/49/84 standard paths (m/84'/0'/0' for native segwit). Multisig Shield: a custom 2-of-2 (or 2-of-3) script with a Blockstream-held key, not expressible as a single-sig path. Verify in-app. | Singlesig m/44'/0'/0', m/49'/0'/0', m/84'/0'/0'. Multisig Shield: custom 2-of-2 script. No BIP48, no BIP86/taproot. Liquid (L-BTC) accounts are a separate chain entirely. | Partial — "Optional (on restore)" per walletsrecovery.org. A BIP39 passphrase is supported, but the UX historically surfaces it at restore time rather than as a headline creation option. | unverified — Blockstream publishes no figure for either mode. Largely moot for Multisig Shield, where external gap-limit scanning cannot reconstruct the script anyway. | No — output descriptors: No, PSBT: No (walletsrecovery.org). Singlesig accounts can be re-derived from the seed by any BIP39/BIP84 wallet, but Green does not hand you a descriptor. | High |
| Restoring elsewhere: Establish whether the account was Singlesig or Multisig Shield before restoring: a Multisig Shield phrase entered into another BIP39 wallet will be accepted and will generate an empty single-signature wallet, which looks exactly like theft but is not — the coins sit in a script that requires Blockstream's co-signing key. Recover Multisig Shield with Blockstream's garecovery tool, which for 2-of-2 needs your mnemonic plus the nlocktimes.zip file and for 2-of-3 needs your mnemonic, the 2-of-3 recovery mnemonic and its xpub, so retain the Green nLockTime/recovery emails and files (pre-signed nLockTime transactions become spendable unilaterally after 90 days by default). Singlesig accounts are fully portable (BIP39 + BIP44/49/84) and restore cleanly in Electrum, and L-BTC held in Liquid accounts will never appear in a Bitcoin-only wallet. | |||||||
| ZEUS medium confidence |
Backend-dependent: legacy Embedded LND uses a 24-word aezeed cipher seed (NOT BIP39); v13.0.0+ defaults to LDK Node with a 12-word seed; in remote-node mode ZEUS holds no seed at all. | No single default. Legacy Embedded LND (aezeed root) derives m/49'/0'/0', m/84'/0'/0' and m/86'/0'/0'. LDK Node (v13+) uses BIP84 and BIP86; its account-level path is unverified. | Legacy Embedded LND derives three scopes: BIP49 nested segwit (3-prefix), BIP84 (bc1q), BIP86 taproot (bc1p). LDK Node: BIP84 and BIP86 only. No BIP44, no BIP48. | No BIP39 passphrase. LND's aezeed has its own optional cipher-seed passphrase — a different mechanism, not interchangeable with a BIP39 25th word. | unverified — not published. The birth date embedded in aezeed is a rescan optimization, not a gap limit. | no — no output descriptor export and no PSBT support. | High |
| Restoring elsewhere: First establish which mode applies: legacy Embedded LND (aezeed), LDK Node 12-word (v13+), or remote node, where ZEUS holds nothing and the funds belong to that node. Aezeed's 24 English words are not BIP39 — entering them into Sparrow, Electrum or a hardware wallet produces an unrelated, empty wallet, so decode the aezeed first (Blixt, Blue Wallet and Breez should be compatible) and then scan m/49', m/84' and m/86' before concluding funds are missing. Lightning balances live in channel state rather than at derived addresses, so the seed alone does not restore channels. | |||||||
| Envoy (by Foundation) medium confidence |
BIP39. Two distinct keys: the Envoy mobile hot-wallet key generated on the phone, and the Passport hardware seed Envoy watches. 'Magic Backups' is the default backup scheme for both, with different internals. | m/84'/0'/0' (native segwit) for standard Passport Core/Envoy accounts; since Envoy 2.0.1 a single account tile carries both m/84' and m/86'. The Envoy standalone hot-wallet account default is unverified. | BIP84 m/84'/0'/0', BIP48 multisig, BIP86 taproot (Passport Core firmware v2.3.0+). Not BIP44, not BIP49. Non-standard Post Mix account: m/84'/0'/2147483646'. | Optional on Passport Core, documented as an advanced feature to consider carefully. Passphrase support for the Envoy mobile hot wallet is unverified. | unverified — not published by Foundation. | Partial — Envoy 2.0 lets you choose the script type when exporting a descriptor and exports labels in BIP-329, but walletsrecovery.org records no descriptor export for Passport Core or Prime. Verify in your app version. | High |
| Restoring elsewhere: Never import a Passport seed into Envoy — Envoy is a hot wallet and seeds entered there are stored on the phone. Under default Automatic Setup the Envoy mobile key is only backed up via Magic Backups to iCloud Keychain or Android Auto-Backup, so open the Envoy menu, choose Backups, tap 'View Envoy Seed' and write the words on paper; the Envoy Backup File holds settings and labels, not seed words. Post Mix coins at m/84'/0'/2147483646' are invisible to a default m/84'/0'/0' restore, and Passport Prime's 2-of-3 Shamir backup keeps its third share in the phone's cloud keychain, so store the two Keycards in separate locations. | |||||||
| Bull Bitcoin Wallet medium confidence |
BIP39, 12 words. A single mnemonic backs both wallets the app creates. BIP85 is used for deterministic child secrets, including the RecoverBull backup encryption key. | m/84'/0'/0' (native segwit, bech32) for the Secure Bitcoin Wallet; the Instant Payments Wallet is Liquid at m/84'/1776'/0'. | BIP44 m/44'/0'/0', BIP49 m/49'/0'/0', BIP84 m/84'/0'/0'. No BIP48, no BIP86. Liquid uses coin type 1776 with a SLIP-77 confidential descriptor. BIP85 child-seed derivation is user-facing. | yes, optional — an optional parameter at seed creation. | unverified — not published. | Partial/no — no clean descriptor export and no PSBT support, though the app is descriptor-based internally (BDK/LWK) and can import watch-only descriptors. | High |
| Restoring elsewhere: One seed, two chains: restoring the mnemonic into Sparrow, Electrum or a hardware wallet recovers only the Bitcoin mainnet side at m/84'/0'/0', while L-BTC — where Lightning receipts land, since Bull routes Lightning through Boltz swaps into Liquid — needs a wallet supporting confidential/blinded descriptors at m/84'/1776'/0'. RecoverBull derives its vault key via BIP85 and depends on an anonymous key server, so treat it as a convenience layer, never a substitute for writing down the 12 words. Any BIP85 child seeds you created are invisible to a plain parent-seed restore, so record their index and path separately. | |||||||
| Phoenix (ACINQ) medium confidence |
BIP39, 12 words. The seed is not the whole backup — Phoenix is Lightning-native and should not be modelled as an on-chain HD wallet. | No single default, because most value sits in Lightning channel state. Closed-channel outputs land at m/84'/0'/0'; swap-in refund keys derive from the non-standard m/52'/0'/2'/0. | BIP84 m/84'/0'/0' for channel-close outputs, plus non-standard m/52'/0'/2'/0 for swap-in refund keys (purpose 52' appears in no BIP). Swap-in outputs are P2TR 2-of-2 musig2 with ACINQ. No BIP44/49/48. | Not offered — ACINQ documents no BIP39 25th-word passphrase in the creation or restore flow; restore is 12 words plus a 'BIP39 seed' checkbox. | Not applicable — swap-in recovery imports a wildcard-range descriptor into Bitcoin Core rather than performing a gap-limit scan. | Partial — the swap-in descriptor tr(<xpub>,and_v(v:pk(<refund_key>/<path>),older(<delay>))) is shown in Wallet Info and requires Bitcoin Core 26.0+ to import. No general-purpose account descriptor export. | High |
| Restoring elsewhere: Encrypted channel state is backed up to ACINQ's infrastructure, so reinstalling Phoenix and entering the same 12 words restores channels and balance — but only inside Phoenix; those same words in Sparrow, Electrum or a hardware wallet show a near-empty m/84'/0'/0' wallet even when a large Lightning balance exists, and the funds are fine. If channels close or force-close, the outputs land on-chain at m/84'/0'/0' and any BIP39+BIP84 wallet can sweep them once the CSV delay of 2,016 blocks (about two weeks) expires, so an empty balance during that window is expected. If Phoenix is unusable and ACINQ unreachable, swap-in funds require deriving the refund key at m/52'/0'/2'/0, importing the descriptor into Bitcoin Core 26.0+, and waiting out the separate 25,920-block refund delay (roughly six months). | |||||||
| Ashigaru (Wallet + Whirlpool) medium confidence |
BIP39, 12 words plus a passphrase that is mandatory by design (inherited from Samourai) and functions as a 13th word. Also writes an encrypted wallet backup text file; exact filename unverified. | m/84'/0'/0' (Deposit account, native segwit). | Deposit m/44'|49'|84'/0'/0'; BIP47 PayNym m/47'/0'/0'. Whirlpool: Pre-Mix m/84'/0'/2147483645', Post-Mix m/84'/0'/2147483646', Bad Bank m/84'/0'/2147483644', Ricochet m/44'|49'|84'/0'/2147483647'. | Required, not optional — tied to the private keys and also used to encrypt the wallet backup file. Must be entered exactly, including whitespace and special characters, and cannot be reset or recovered. | The default of 20 is insufficient for Whirlpool post-mix accounts; raise it iteratively until the balance stops growing. No official figure is published. Deposit accounts are fine at normal limits. | Partial — no native descriptor export. Import seed + passphrase into Sparrow, which ships 'Samourai Postmix', 'Samourai Premix', 'Samourai Bad Bank' and 'Samourai Ricochet' presets and can then produce descriptors. | High |
| Restoring elsewhere: The passphrase is not optional: without it a correct mnemonic unlocks nothing, and because the same passphrase decrypts the backup file, losing it kills both recovery routes at once — store it separately from the seed, but store it. A default restore scans only m/84'/0'/0', so mixed coins in the four Whirlpool accounts stay invisible; add each account separately in Sparrow using its preset and raise the gap limit until balances stabilize. These paths come from the upstream Samourai repository and community guides, as Ashigaru publishes no derivation or recovery reference, so verify against a live wallet before a large recovery. | |||||||
Anatomy of a derivation path
An HD wallet is a tree: the seed is the root, every address is a leaf. The path is the route from root to leaf, and each level is a fork the software has to take correctly. Get one level wrong and you derive a different, legitimately empty wallet from the same seed. The apostrophe means hardened: m/84'/0'/0'/0/0 and m/84/0/0/0/0 are different keys.
| Level | What it selects |
|---|---|
m | The master node, derived from the seed via HMAC-SHA512 with the key "Bitcoin seed". Everything else descends from here. |
purpose' | Which standard the tree follows, and therefore what address type comes out: 44', 49', 84', 86', or 48' for multisig. Always hardened. |
coin_type' | Which coin, per the SLIP-0044 registry. 0' is Bitcoin mainnet, 1' is testnet. Always hardened, so coins occupy disjoint subtrees. |
account' | User-facing account separation, starting at 0'. Always hardened, so accounts are cryptographically isolated from each other. |
change | 0 is the external chain (addresses you hand out to receive), 1 is the internal chain (change coming back to you). Not hardened. |
address_index | Sequential address number starting at 0. Not hardened, which is what lets a watch-only wallet generate receive addresses from an xpub alone. |
Which standard produces which address
The fastest diagnostic you have: read the prefix of an address you know received funds, and you know which branch to restore.
| Standard | Account path | Address type | Starts with | Notes |
|---|---|---|---|---|
| BIP44 | m/44'/0'/0' |
Legacy P2PKH | 1... |
Extended keys serialize as xpub/xprv. Older wallets default here, so a seed restored into a modern BIP84 wallet correctly shows nothing. |
| BIP49 | m/49'/0'/0' |
P2WPKH nested in P2SH | 3... |
ypub/yprv. The BIP's own example path is m/49'/1'/0'/0/0 — that 1' is testnet; substitute 0' for mainnet. |
| BIP84 | m/84'/0'/0' |
P2WPKH native segwit | bc1q... |
zpub/zprv. Spec test vector: m/84'/0'/0'/0/0 derives bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu. Check a tool against it before trusting it with funds. |
| BIP86 | m/86'/0'/0' |
P2TR taproot | bc1p... |
The internal key is tweaked per BIP341, so a tool that derives BIP32 correctly but skips the tweak produces wrong bc1p addresses. Test vector: m/86'/0'/0'/0/0 derives bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr. |
| BIP48 | m/48'/0'/0'/2' |
Multisig P2WSH (script_type 2') or P2SH-P2WSH (script_type 1') | 3... for P2SH-P2WSH (script_type 1') |
Inserts a script_type' level: m/purpose'/coin_type'/account'/script_type'/change/address_index. P2WSH is the recommended default. The path alone will not recover a multisig — you also need every cosigner xpub, the quorum, and key ordering. |
Seed formats are not interchangeable
Twelve or twenty-four words does not mean BIP39. Word count and origin software tell you which format you are holding — and a format mismatch is why a phrase gets rejected as invalid.
BIP39
Entropy encoded as 12/15/18/21/24 words, stretched into a 512-bit seed with PBKDF2-HMAC-SHA512 at 2048 iterations. Salt is the string "mnemonic" plus your passphrase, both UTF-8 NFKD.
Restores into: Any BIP32 wallet, but only on the branch you point it at — BIP39 says nothing at all about derivation paths.
Trap: The words alone are an incomplete description of a wallet. Without the path and script type, a correct seed can restore into an empty branch with no error shown.
SLIP39
Shamir secret sharing with a two-level group/member threshold scheme. Shares are 20 words for a 128-bit secret or 33 words for 256-bit, from a 1024-word list, with a Feistel construction over PBKDF2-HMAC-SHA256.
Restores into: SLIP39-aware wallets holding the required threshold of shares. The spec states flatly that SLIP39 and BIP39 are not compatible.
Trap: A single share is not a seed and will never restore anywhere as a mnemonic. Word count is the tell: 20 or 33 is SLIP39, 59 is a BIP39 seed wrapped in SLIP39, 12/15/18/21/24 is BIP39.
Electrum native
Electrum's own format since 2.0. Same wordlist as BIP39, but validity comes from a version number computed as hmac_sha_512("Seed version", normalized phrase) — 0x01 standard, 0x100 segwit, 0x101 2FA — so the seed declares its own derivation method.
Restores into: Electrum. Electrum can import BIP39 seeds, but the reverse generally does not hold — "Electrum does not generate BIP39 seeds."
Trap: It carries no BIP39 checksum, so a BIP39-only wallet usually rejects it as invalid. Electrum's own standard wallets also historically derive at non-standard roots like m/0', so even a correct restore can look empty in a third-party BIP84 wallet.
Aezeed
lnd's cipher seed, built on AEZ. Plaintext is 1 byte version, 2 byte timestamp, 16 bytes entropy, with the timestamp in Bitcoin Days Genesis so a restoring node knows how far back to scan. Stretched with scrypt n=32768, r=8, p=1.
Restores into: lnd and lnd-based nodes (Umbrel, RaspiBlitz, Voltage). It is 24 words and looks exactly like BIP39 to a user.
Trap: Different KDF, different construction, no shared format with BIP39 — an aezeed phrase is not recoverable by a BIP39 wallet. It also restores the on-chain wallet only, never channel state.
Bitcoin Core descriptor (no mnemonic)
Core recovers from an output descriptor, not a phrase. BIP380 descriptors encode script type, exact derivation path, key origin as [fingerprint/path]key, and any subscripts, with an 8-character BCH checksum that catches transcription errors.
Restores into: Bitcoin Core via importdescriptors (default key range 0-999) plus rescanblockchain, and any other descriptor-aware wallet.
Trap: There are no words to write on steel, so the descriptor itself is the backup. It holds no private keys but does expose your full history and future addresses — sensitive, but not catastrophic to store redundantly.
Back up what the words leave out
Every failure mode above is prevented by one of these. Do them now, while nothing is wrong.
- Back up the output descriptor — or at minimum the account xpub with its key origin path — alongside every seed.
- Record whether a BIP39 passphrase is in use, and store the exact passphrase separately from the words.
- Write down the derivation path and script type; the words alone do not describe a wallet.
- For multisig, store the full config — all cosigner xpubs, fingerprints, quorum, script type, paths — with every seed copy.
- Note the seed format (BIP39, SLIP39, Electrum native, aezeed) and the software it was generated in.
- Consolidate funds into low-index addresses so a default gap limit of 20 finds them on the next restore.
- Automate off-device Lightning channel.backup on every channel state change, and never keep a stale copy.
- Test a full restore onto different software, offline, before the wallet holds meaningful value.
Method, limits & credits
Every row was researched against primary sources — official wallet and vendor documentation, the BIP and SLIP specifications, and the community reference at walletsrecovery.org — and then handed to an independent reviewer whose job was to refute it. Corrections were merged into the published values, and confidence was only ever lowered, never raised. We stand on the shoulders of walletsrecovery.org, whose years of community work on derivation paths made this dataset possible.
Limits worth stating plainly: wallet defaults change between software versions and device firmware, so a value correct today can be wrong after an update — always confirm against your own installation. Values we could not source are published as unverified rather than filled with a plausible guess, because a wrong derivation path costs a reader real money. This is a research reference, not a guarantee about your specific setup.
Related: wallet sovereignty matrix · signing devices reference · inheritance planner · sovereign self-hosting catalog · UTXO consolidation calculator
Open data (CC BY 4.0): CSV · JSON · API: /wp-json/dc/v1/wallet-recovery
Related products, repair, and setup paths
- immersion cooling hub
- home immersion cooling guide
- ASIC miners for immersion planning
- ASIC cooling parts
- airflow shroud before immersion
- compare miner specs in the database
- ASIC repair support
Last reviewed July 20, 2026.