Tools/Explorers

Bitcoin Wallet Interoperability: BIP Standards Compared

Compare wallet interoperability across Bitcoin wallets: derivation paths, descriptor support, PSBT handling, and migration compatibility.

Spark Team

Wallet Interoperability Standards Overview

Moving bitcoin between wallets should be straightforward: enter your seed phrase, see your balance. In practice, differences in derivation path defaults, descriptor support, PSBT versions, and seed format handling cause funds to appear missing, change outputs to vanish, and multisig configurations to break during migration. Understanding which standards each wallet implements is essential before moving funds or setting up collaborative custody.

This reference compares how major Bitcoin wallets handle the four pillars of interoperability: derivation paths (BIP44/49/84/86), output descriptors (BIP380/381), PSBT compatibility (BIP174/BIP370), and seed phrase format support (BIP39 vs SLIP39).

Derivation Path Support by Wallet

Every HD wallet derives addresses from a master seed using a hierarchical path. The "purpose" level of this path determines the address type generated. BIP44 produces legacy P2PKH addresses (starting with 1), BIP49 produces wrapped SegWit P2SH-P2WPKH (starting with 3), BIP84 produces native SegWit P2WPKH (starting with bc1q), and BIP86 produces Taproot P2TR (starting with bc1p).

Nearly all modern wallets default to BIP84 native SegWit. Taproot (BIP86) is supported broadly but no wallet defaults to it yet. Electrum is the notable outlier: it uses its own derivation scheme for natively generated seeds.

WalletDefault PathBIP44 (Legacy)BIP49 (Wrapped)BIP84 (SegWit)BIP86 (Taproot)
Bitcoin Corem/84'/0'/0'YesYesYesYes
Sparrowm/84'/0'/0'YesYesYesYes
ElectrumOwn formatImport onlyImport onlyImport onlyImport only
Coldcardm/84'/0'/0'YesYesYesYes
Ledger Livem/84'/0'/0'YesYesYesYes
Trezor Suitem/84'/0'/0'YesYesYesYes
BlueWalletm/84'/0'/0'YesYesYesYes
Specter Desktopm/84'/0'/0'YesYesYesYes
Nunchukm/84'/0'/0'YesYesYesYes
Wasabim/84'/0'/0'NoNoYesNo
Blockstream Greenm/84'/0'/0'YesYesYesSend only

For a deeper look at how each path maps to script types, see the Bitcoin wallet standards reference and our guide to Bitcoin address types.

Output Descriptor Support

Output descriptors (BIP380/BIP381) encode the full information needed to reconstruct a wallet: the extended key, derivation path, script type, and optionally the checksum. A descriptor like wpkh([fingerprint/84h/0h/0h]xpub.../0/*)#checksum unambiguously defines which addresses a wallet controls. Without descriptors, restoring a seed requires guessing which derivation paths and script types were used.

Bitcoin Core made descriptor wallets the default in v23.0 (April 2022) and fully removed legacy wallet support in v30.0 (late 2025). Software coordinators like Sparrow, Specter Desktop, and Nunchuk treat descriptors as their canonical wallet format. Hardware wallets participate by exporting descriptors for use with coordinators, though their companion apps vary in native support.

WalletDescriptor ExportDescriptor ImportNative FormatNotes
Bitcoin CoreYesYesYesReference implementation; only format since v30.0
SparrowYesYesYesExports xpub-only descriptors; supports multipath
Specter DesktopYesYesYesDescriptors are the canonical wallet format
NunchukYesYesYesSupports Miniscript descriptors
ColdcardYesNoNoExports single-sig and multisig descriptors via SD/QR
Ledger LivePartialPartialNoWallet policies use descriptor-based format for multisig
Trezor SuiteNoNoNoWorks with descriptors via third-party coordinators
ElectrumNoNoNoUses its own wallet format; no descriptor support
BlueWalletNoYesNoCan import descriptor-defined wallets
WasabiNoNoNoExports zpub extended keys; not descriptor-native

The practical consequence: if you back up both your seed phrase and the wallet descriptor, you can restore in any descriptor-aware software without ambiguity. Without the descriptor, you depend on the restoring wallet to scan all possible derivation paths, which not all wallets do automatically. For a technical walkthrough, see our output descriptors reference.

PSBT Compatibility

Partially Signed Bitcoin Transactions (PSBTs) are the standard for coordinating transactions across multiple devices. A coordinator wallet creates the PSBT, one or more signing devices add their signatures, and the coordinator finalizes and broadcasts. This workflow is fundamental to multisig, air-gapped signing, and hardware wallet usage.

BIP174 (PSBT v0) is universally supported across modern wallets. BIP370 (PSBT v2) adds per-input/output fields that support incremental construction and Taproot-specific data. PSBT v2 adoption is growing but not yet required for standard workflows.

WalletPSBT v0 (BIP174)PSBT v2 (BIP370)RoleTransport
Bitcoin CoreFullFullCreate / Sign / FinalizeFile, RPC
SparrowFullYesCreate / Sign / FinalizeFile, QR, USB
ElectrumFullNoCreate / Sign / FinalizeFile, QR
ColdcardFullYesSign onlySD card, QR (BBQR)
LedgerFullYesSign onlyUSB, Bluetooth
TrezorFullNoSign onlyUSB
Specter DesktopFullNoCreate / FinalizeFile, QR, SD card
NunchukFullYesCreate / Sign / FinalizeFile, QR, NFC
BlueWalletFullNoCreate / FinalizeQR (BBQR)
WasabiFullNoCreate / Sign / FinalizeFile

For multisig setups, the coordinator wallet (Sparrow, Specter, Nunchuk) creates PSBTs that are passed to hardware signers via SD card, QR code, or USB. The key compatibility concern is ensuring all devices in a quorum support the same PSBT version and transport method. See our PSBT multisig workflow guide for step-by-step setup instructions.

Seed Phrase Format Compatibility

BIP39 is the dominant seed phrase standard, generating 12 or 24 words that encode entropy for key derivation. SLIP39 (Shamir's Secret Sharing) splits the seed into multiple shares where a configurable threshold is required for recovery. These two formats are incompatible: they use different key derivation parameters, so the same words produce different master keys.

WalletBIP39 GenerateBIP39 RestoreSLIP39 SupportNotes
Bitcoin CoreNoNoNoUses descriptor-based backups; no mnemonic seeds
SparrowYesYesImport onlyCan restore SLIP39 shares but does not generate them
ElectrumNoYesNoGenerates own versioned seed format; can restore BIP39
ColdcardYesYesNo12 or 24 word seeds; prefers SSKR over SLIP39
LedgerYesYesNo24-word seeds
Trezor Safe 3/5YesYesYes (default)Shamir is the default backup since 2024
Trezor Model TYesYesYes (optional)SLIP39 available but not default
BlueWalletYesYesNoStandard BIP39 only
NunchukYesYesNoStandard BIP39 only
WasabiYesYesNo12-word seeds

SLIP39 remains a Trezor-centric standard. If you use a Trezor Safe device with Shamir backup, your recovery shares can only be restored on another Trezor or in Sparrow (import only). Migrating to a Ledger or Coldcard requires first recovering on a Trezor and sweeping funds to a new BIP39-based wallet.

Wallet-to-Wallet Migration Matrix

The following matrix shows whether you can directly restore a seed from one wallet in another without losing access to funds. "Direct" means entering the same seed phrase and seeing your full balance. "Manual" means you need to adjust settings (derivation path, gap limit, passphrase). "Sweep" means the seed format is incompatible and you must send funds to a new wallet.

From / ToSparrowLedgerTrezorColdcardElectrumBlueWallet
Sparrow-DirectDirectDirectManualDirect
LedgerDirect-DirectDirectManualDirect
Trezor (BIP39)DirectDirect-DirectManualDirect
Trezor (SLIP39)ManualSweep-SweepSweepSweep
ColdcardDirectDirectDirect-ManualDirect
Electrum (native)SweepSweepSweepSweep-Sweep
BlueWalletDirectDirectDirectDirectManual-

The two incompatible outliers are Electrum (native seeds) and Trezor SLIP39 shares. Electrum uses a different salt ("electrum" instead of "mnemonic") in PBKDF2, so the same 12 words produce entirely different keys when entered into a BIP39 wallet. "Manual" entries require selecting the correct derivation path and potentially increasing the gap limit.

Common Migration Pitfalls

Most cases of "lost" bitcoin after a wallet migration are caused by one of the following issues. The funds are almost never actually lost: they exist on the blockchain but the new wallet is looking at the wrong addresses.

Derivation Path Mismatch

The most common cause of missing funds after migration. If you sent bitcoin to bech32 native SegWit addresses (bc1q) but the restoring wallet scans the legacy BIP44 path, it generates completely different addresses and shows a zero balance. Fix: ensure the restoring wallet uses the same purpose level (44'/49'/84'/86') as the original.

Gap Limit Discrepancies

The address gap limit defines how many consecutive unused addresses a wallet scans before stopping. Default values range from 5 (Electrum) to 21 (Wasabi), with most wallets at 20. If you generated many receiving addresses in one wallet (common for merchants or exchanges), a wallet with a lower gap limit will stop scanning before finding all your funds. Sparrow and Electrum allow manual gap limit adjustment; Ledger Live and Trezor Suite do not.

Missing Change Addresses

Bitcoin transactions send change to internal change addresses on the /1/ branch of the derivation path (e.g., m/84'/0'/0'/1/x). If the restoring wallet does not scan the change branch, or uses a different one, change outputs appear missing. Descriptor wallets solve this by encoding both external and internal paths explicitly.

BIP39 Passphrase Omission

A BIP39 passphrase (sometimes called the 25th word) modifies the seed derivation. Restoring without it produces a valid but entirely different wallet with zero balance. Some users forget they set a passphrase, especially if the original wallet set it during initial setup.

Electrum Seed Incompatibility

Electrum's native seed format is not BIP39. The same 12 words entered into a BIP39 wallet (Ledger, Trezor, Coldcard) produce different keys. Migration from Electrum always requires sweeping: send all funds from Electrum to a new address in the target wallet.

How Descriptors Improve Wallet Portability

Before descriptors, wallet portability depended on convention: all wallets agreeing to use the same derivation paths and script types. Descriptors make the convention explicit and machine-readable. A single descriptor string contains everything needed to reconstruct a wallet: the extended key, the full derivation path, the script template, and a verification checksum.

Bitcoin Core's full transition to descriptors (completed in v30.0) has accelerated ecosystem adoption. Sparrow, Specter, and Nunchuk now use descriptors as their primary backup format. For multisig setups, descriptors eliminate the ambiguity of cosigner configuration: a wsh(sortedmulti(2,...)) descriptor fully defines the quorum, all participating keys, and the script structure.

The emerging frontier is Miniscript inside Taproot descriptors. Bitcoin Core v26.0+ supports Miniscript in Taproot leaves, enabling complex spending policies (timelocks, multi-path recovery) that remain fully portable via a single descriptor string. Nunchuk has published documentation on recovering Miniscript wallets using Bitcoin Core, demonstrating practical cross-wallet recovery for advanced spending conditions.

Multisig Interoperability Challenges

While individual wallet migration between BIP39-compatible wallets is largely solved, multisig interoperability remains fragmented. The core problem: there is no universal standard for exchanging multisig configurations (cosigner xpubs, quorum requirements, derivation paths) between different vendors.

Each coordinator (Sparrow, Specter, Nunchuk) has its own export format for multisig wallet files. A 2-of-3 multisig created in Sparrow with Coldcard and Ledger signers cannot be trivially imported into Nunchuk without manual descriptor reconstruction. The BSMS (Bitcoin Secure Multisig Setup) standard attempted to address this, but adoption remains inconsistent.

For users setting up collaborative custody, PSBTs provide the transaction-level interoperability layer, while descriptors provide the wallet-level layer. Using both together (descriptor export + PSBT signing) is the most portable approach. Layer 2 solutions like Spark inherit Bitcoin's key management standards while adding instant settlement, meaning the same BIP32 key hierarchy can participate in both on-chain and off-chain transactions.

Frequently Asked Questions

Can I use my Ledger seed phrase in a Trezor?

Yes, if the Ledger was set up with a standard BIP39 seed (which is the default). Enter the 24-word recovery phrase into a Trezor device during setup and select the same account types (SegWit, Taproot). Your addresses and balances will match. If you used a BIP39 passphrase on the Ledger, you must also enter it on the Trezor. Note: Trezor Safe devices default to SLIP39 for new setups, so you would select "Recover wallet" and choose BIP39 format during restore.

Why does my wallet show zero balance after restoring a seed phrase?

The three most common causes are: wrong derivation path (the wallet is scanning legacy addresses when your funds are on SegWit addresses), missing BIP39 passphrase (you set a 25th word that the new wallet does not know about), or gap limit too low (the wallet stopped scanning before reaching your used addresses). Try selecting different address types in the restore flow, check for a passphrase, and if possible increase the gap limit to 100 or higher.

What is the difference between BIP39 and SLIP39?

BIP39 generates a single mnemonic (12 or 24 words) that encodes the full wallet seed. SLIP39 uses Shamir's Secret Sharing to split the seed into multiple shares (e.g., 3-of-5), where any threshold number of shares can reconstruct the seed. The two formats use different cryptographic parameters and produce different master keys from the same words. SLIP39 is currently only supported by Trezor devices natively and by Sparrow for import.

Do I need output descriptors to back up my wallet?

For a standard single-signature wallet using BIP84, your seed phrase alone is usually sufficient because most wallets default to the same derivation path. However, descriptors become essential for multisig wallets, Taproot wallets with custom scripts, or any setup using non-standard derivation paths. Best practice is to back up both the seed phrase and the wallet descriptor.

Can I migrate from Electrum to another wallet without sweeping?

Not if you used Electrum's native seed format. Electrum seeds use a different derivation algorithm than BIP39, so the same words produce different keys in other wallets. You must sweep: send all funds from Electrum to a new address generated by the target wallet. If you originally imported a BIP39 seed into Electrum (rather than letting Electrum generate one), you can restore that seed directly in another BIP39-compatible wallet.

What is PSBT v2 and do I need it?

PSBT v2 (BIP370) is an updated transaction format that replaces the global unsigned transaction with per-input and per-output fields. This enables incremental transaction construction and better Taproot support. For standard single-signature transactions, PSBT v0 (BIP174) is sufficient. PSBT v2 matters primarily for advanced workflows: Taproot multisig, interactive multi-party signing protocols like MuSig2, and applications requiring partial transaction modification.

Which wallets are most portable for long-term Bitcoin storage?

Wallets that use standard BIP39 seeds with default BIP84 derivation paths offer the broadest compatibility. Ledger, Trezor (BIP39 mode), Coldcard, Sparrow, and BlueWallet all use this combination and can restore each other's seeds directly. For maximum future-proofing, also export and back up your wallet's output descriptor. Avoid relying solely on Electrum native seeds or SLIP39 shares unless you accept the limited recovery options.

This tool is for informational purposes only and does not constitute financial advice. Wallet feature data is based on publicly available documentation and may change with firmware or software updates. Always verify current compatibility on the wallet vendor's official site before migrating funds.

Build with Spark

Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.

Read the docs →