Bitcoin Wallet Backup Formats: BIP-39 vs Descriptors vs Shamir vs Codex32

Bitcoin Wallet Backup Formats Compared

Backing up a Bitcoin wallet means preserving enough information to recover your funds if the original device is lost, stolen, or destroyed. The backup format you choose determines how resilient that recovery process is, how many wallets can read it, and what happens when something goes wrong.

Four major formats dominate the landscape: BIP-39 seed phrases (the universal standard since 2013), output descriptors (which capture full wallet configuration), SLIP-39 Shamir backups (which split a secret across multiple shares), and Codex32 (BIP-93), a newer scheme that can be verified entirely by hand. Each makes different tradeoffs between interoperability, security, and usability.

BIP-39 Seed Phrases

BIP-39, introduced in 2013, encodes wallet entropy as a sequence of 12 or 24 English words drawn from a standardized 2,048-word list. A 12-word phrase carries 128 bits of entropy with a 4-bit checksum. A 24-word phrase carries 256 bits with an 8-bit checksum. The checksum is derived from SHA-256, so entering a word incorrectly will usually (though not always) produce an invalid phrase that the wallet rejects.

BIP-39 is the closest thing to a universal standard. Every major hardware wallet generates BIP-39 phrases: Ledger, Trezor, Coldcard, BitBox02, Foundation Passport, Keystone, and Blockstream Jade. Most software wallets (Sparrow, BlueWallet, Exodus, Trust Wallet) also use BIP-39. The notable exception is Bitcoin Core, which has never generated BIP-39 mnemonics and instead uses descriptor wallets. Electrum also uses its own versioned seed format, though it can import BIP-39 phrases.

The Derivation Path Problem

BIP-39's biggest weakness is what it does not encode. The 12 or 24 words contain only the raw entropy. They say nothing about which derivation path the wallet used, which script type it generated, or whether it was a multisig setup. Recovering a BIP-39 seed in a different wallet often means guessing which of several standard paths holds the funds:

• BIP-44 (m/44'/0'/0'): legacy P2PKH addresses starting with 1
• BIP-49 (m/49'/0'/0'): nested SegWit P2SH-P2WPKH addresses starting with 3
• BIP-84 (m/84'/0'/0'): native SegWit P2WPKH addresses starting with bc1q
• BIP-86 (m/86'/0'/0'): Taproot P2TR addresses starting with bc1p

A wallet that defaults to BIP-84 on import will show an empty balance if the original wallet used BIP-44. The funds are not lost, but finding them requires scanning multiple paths. Tools like Ian Coleman's BIP-39 tool and BTCRecover can brute-force path combinations, but this is a recovery headache that should not exist. For a deeper analysis of this problem, see our research on output descriptor wallet portability.

Output Descriptors

Output descriptors solve the derivation path problem by encoding the complete wallet configuration in a single text string. A descriptor specifies the script type, the key origin (master fingerprint and derivation path), the extended public key, and a checksum. For example, a native SegWit single-sig wallet produces a descriptor like: wpkh([fingerprint/84h/0h/0h]xpub.../0/*)#checksum.

Descriptors are defined across BIPs 380 through 389. BIP-380 establishes the framework. BIPs 381 through 386 cover specific script types: legacy (pkh), SegWit (wpkh, wsh), multisig (multi, sortedmulti), and Taproot (tr). BIP-388 introduces wallet policies for hardware wallets, and BIP-389 adds multipath key expressions that combine receive and change paths in a single string.

Bitcoin Core has used descriptor wallets by default since version 23.0 (April 2022), and removed legacy wallet support entirely in version 30.0 (late 2025). Sparrow, Specter Desktop, and Nunchuk treat descriptors as the canonical backup format. Coldcard can export descriptors for both single-sig and multisig setups. The 8-character BCH checksum catches transcription errors, making descriptors reliable for paper or digital backup.

The limitation is that descriptors contain only public information. They describe which addresses belong to a wallet but carry no private key material. A full backup requires both the BIP-39 seed (for the keys) and the descriptor (for the wallet configuration). This is especially critical for multisig wallets, where the descriptor holds every cosigner's xpub, the threshold, and the script type. Without it, having all the seeds is not enough to reconstruct the wallet.

SLIP-39 Shamir Backups

SLIP-39, developed by SatoshiLabs (the company behind Trezor), applies Shamir's Secret Sharing to wallet backups. Instead of writing down one set of words, the user creates multiple shares, any subset of which can reconstruct the original secret. A 2-of-3 scheme, for instance, generates three shares and requires any two to recover.

SLIP-39 uses a different 1,024-word list from BIP-39. Shares are 20 words each for 128-bit secrets and 33 words for 256-bit secrets. The scheme supports up to 16 shares with configurable thresholds and includes a two-level group structure: you can define groups (personal, family, lawyer) where each group has its own k-of-n threshold, and a top-level threshold determines how many groups are needed.

The tradeoff is narrow wallet support. Trezor Model T, Safe 3, Safe 5, and Safe 7 support SLIP-39 natively (Shamir has been the default backup type on the Safe family since June 2024). Keystone 3 Pro also supports it. But Ledger, Coldcard, BitBox02, Passport, and Jade do not. If your only hardware wallet breaks and the replacement is from a different manufacturer, you may need to use a software tool (such as the Trezor CLI or Electrum) to reconstruct the secret before importing it into the new device. The scheme is also incompatible with BIP-39: you cannot convert between the two formats without creating a new wallet and moving funds.

Codex32 (BIP-93)

Codex32, formally BIP-93, is the newest approach. Authored by Leon Olsson Curr, Pearlwort Sneed, and Andrew Poelstra (Blockstream Research), it encodes a BIP-32 master seed using the Bech32 character set (32 lowercase alphanumeric characters, excluding visually ambiguous letters like b, i, o, and 1). A 128-bit seed produces a 48-character string; a 256-bit seed produces a 74-character string.

Codex32's defining feature is hand-verifiability. The entire workflow, from seed generation to splitting to checksum verification to recovery, can be performed with printed paper worksheets and circular lookup tables (volvelles), with no electronic device. The BCH checksum detects up to 8 character errors and can correct up to 4 substitutions or 8 erasures, all verifiable by hand.

Like SLIP-39, Codex32 supports Shamir splitting, with thresholds from 2 to 9 and up to 31 shares. Unlike SLIP-39, it has no passphrase support and no multi-level group structure. Wallet support is currently limited to Coldcard (firmware 5.6.3 for Mk4/Mk5, 1.5.3Q for Q, released September 2026) and Sparrow (version 2.4.0). Bitcoin Core has open pull requests but no merged support. BIP-93 remains in Draft status.

Hardware Wallet Support Matrix

Which backup formats each hardware wallet supports determines your recovery options if the device is lost. The following table covers the major devices.

For a broader comparison of hardware wallet features, see our hardware wallet comparison tool.

Common Failure Modes

Understanding how each format fails helps you avoid the most common recovery disasters.

BIP-39 Failures

• Derivation path mismatch: the seed is correct, but the wallet imports it on a different path and shows a zero balance. This is the single most common "lost funds" panic, and it is almost always recoverable by scanning standard paths.
• Forgotten passphrase (25th word): BIP-39 allows an optional passphrase. Any passphrase produces a valid, different wallet with no error signal. A forgotten or mistyped passphrase results in permanent fund loss.
• Word confusion: similar BIP-39 words (trust/trash, angle/ankle) can be confused in handwriting. The checksum catches most errors, but not all.
• Electrum seed confusion: Electrum's own seed format is not BIP-39. Entering an Electrum seed into a BIP-39 wallet silently derives the wrong keys.

Output Descriptor Failures

• Descriptor neglect: users back up the seed phrase but forget to save the descriptor. For single-sig wallets, standard paths make recovery possible. For multisig, the descriptor is essential and its loss means the wallet cannot be reconstructed from seeds alone.
• Transcription errors: a single wrong character in a manually copied descriptor results in zero visible balance. The 8-character checksum detects errors but cannot correct them.

SLIP-39 Failures

• Share loss below threshold: losing more shares than the scheme allows means permanent, unrecoverable fund loss. A 3-of-5 scheme tolerates losing two shares but not three.
• Vendor lock-in: if the only wallet supporting your SLIP-39 shares discontinues support, recovery requires finding compatible software tooling.
• BIP-39 confusion: the two formats look similar (both are word lists) but are incompatible. Entering SLIP-39 shares into a BIP-39 wallet, or vice versa, will not work.

Codex32 Failures

• Limited wallet support: as of late 2026, only Coldcard and Sparrow support Codex32 import. Losing access to compatible software is a real risk during the early adoption phase.
• Hand computation errors: the pen-and-paper workflow takes 2 to 5 hours for initial setup. Mistakes during manual computation require starting over, and uncaught errors could corrupt the backup.
• No passphrase layer: unlike BIP-39 and SLIP-39, Codex32 has no passphrase. The physical backup is the only protection, making secure storage critical.

Metal Backup Compatibility

Metal backups (stainless steel plates, titanium capsules) protect against fire, water, and corrosion. Their suitability depends on the character set and length of the backup format.

BIP-39 is the best fit. The first 4 letters of every word in the 2,048-word list are unique, so most metal products store only 4-letter abbreviations. A 24-word phrase requires 96 characters. Products like Cryptotag Zeus, Blockplate, and Billfodl are specifically designed for this. Jameson Lopp's stress tests of 75 devices found that grid-based punch systems (Bitplate, Blockplate, CodlKeys) offer the best durability for the cost.

SLIP-39 shares work similarly, since each word also has a unique 4-letter prefix. The challenge is quantity: a 3-of-5 scheme with 20-word shares means stamping five separate plates (100 words total).

Codex32 strings use the Bech32 alphabet (all lowercase or all uppercase, no mixed case, no ambiguous characters). A 256-bit backup is 74 characters, which fits on a single plate. The built-in error correction (up to 4 substitutions) provides a safety net for stamping mistakes.

Output descriptors are a poor fit for metal. A single-sig descriptor runs 150 to 200 characters with mixed case, digits, and symbols like [ ] ( ) / #. A multisig descriptor can exceed 400 characters. Most metal products do not support this character set. Descriptors are better stored as paper copies, QR codes, or encrypted digital files.

For a detailed comparison of metal backup products, see our seed storage comparison tool. For recovery strategies across formats, see our research on Bitcoin wallet recovery methods.

Which Format Should You Use

The right format depends on your self-custody setup and threat model.

For most individual users with a single-sig cold storage setup: use a BIP-39 seed phrase stamped on metal, plus a descriptor backup stored separately. The seed provides the keys; the descriptor eliminates derivation path guesswork during recovery. This combination gives maximum interoperability with the strongest recovery guarantees.

For users who want geographic distribution of trust: SLIP-39 (if you use Trezor or Keystone) or Codex32 (if you use Coldcard) let you split your backup so that no single location holds enough information to spend your funds. SLIP-39 supports multi-level groups for complex custody arrangements. Codex32 offers hand-verifiable checksums for users who want to minimize trust in electronics.

For multisig setups: descriptor backups are not optional. The descriptor holds every cosigner's xpub, the threshold, and the script type. Back it up alongside every seed, and store a copy with every key holder. Some tools like joshdoman's multisig-backup project encrypt the descriptor so that any k seeds can decrypt it. For more on multisig planning, see our multisig planner tool.

Wallets on Spark and other Bitcoin Layer 2 networks still derive from BIP-32 HD wallet keys, so these backup formats apply to the underlying key material regardless of which layer you transact on.

Frequently Asked Questions

What is the difference between BIP-39 and SLIP-39?

BIP-39 encodes a wallet's entropy as 12 or 24 words from a 2,048-word list and produces a single backup. SLIP-39 uses a different 1,024-word list and splits the secret into multiple shares using Shamir's Secret Sharing. The two formats are incompatible: you cannot convert BIP-39 words into SLIP-39 shares or vice versa without creating a new wallet. BIP-39 is supported by nearly every wallet, while SLIP-39 is primarily supported by Trezor and Keystone.

Can I recover a BIP-39 wallet without knowing the derivation path?

Yes, but it requires scanning multiple standard paths (BIP-44, BIP-49, BIP-84, BIP-86) to find which one holds your funds. Tools like Ian Coleman's BIP-39 tool and BTCRecover automate this. The process is slow because each path requires rescanning the blockchain. This is the exact problem that output descriptors solve: they record the derivation path alongside the key, eliminating guesswork during recovery.

Do I need to back up output descriptors separately from my seed phrase?

For single-sig wallets using standard paths, you can usually recover without a descriptor by scanning common paths. For multisig wallets, descriptor backups are essential. The descriptor holds each cosigner's extended public key, the threshold, and the script type. Without it, having all the individual seeds is not enough to reconstruct the wallet. Best practice is to back up the descriptor for any wallet, regardless of type.

Is Codex32 better than SLIP-39 for Shamir backups?

They serve different priorities. Codex32 is designed for users who want to verify their backup without any electronic device: the entire workflow (generation, splitting, checksum verification) can be done with pen and paper. SLIP-39 supports passphrase protection and multi-level group structures that Codex32 does not. SLIP-39 has broader hardware wallet support (Trezor Safe family, Keystone), while Codex32 is currently limited to Coldcard and Sparrow.

Which Bitcoin hardware wallets support Shamir backup?

For SLIP-39: Trezor Model T, Safe 3, Safe 5, and Safe 7 (Shamir is the default backup on Safe devices since June 2024), plus Keystone 3 Pro. For Codex32 (BIP-93): Coldcard Mk4 and Q (firmware 5.6.3+ and 1.5.3Q+, released September 2026). Ledger, BitBox02, Foundation Passport, and Blockstream Jade do not support either Shamir format.

Can I stamp a Codex32 backup on a metal plate?

Yes. A 256-bit Codex32 backup is 74 characters using the Bech32 alphabet (lowercase letters and digits, with no ambiguous characters like b, i, o, or 1). This is shorter than a 24-word BIP-39 phrase abbreviated to 4-letter prefixes (96 characters). The built-in error correction (detecting up to 8 errors, correcting up to 4) provides an additional safety net for stamping mistakes that BIP-39's checksum does not offer.

What happens if I lose my BIP-39 passphrase?

The funds are permanently lost. BIP-39 treats any passphrase as valid and derives a different wallet for each one, with no error signal. A forgotten or mistyped passphrase produces a valid but empty wallet, and there is no way to brute-force it unless the passphrase was short and simple. Coldcard limits passphrases to 100 characters of ASCII only, but other wallets may accept Unicode, adding another compatibility variable.

This tool is for informational purposes only and does not constitute financial advice. Wallet support data is based on publicly available documentation and firmware release notes as of late 2026. Hardware and software wallet capabilities change with firmware updates. Always verify current format support on the manufacturer's website before relying on a specific backup strategy.