Bitcoin Seed Phrase Formats Compared: BIP39, SLIP39, Aezeed, and More

Seed Phrase Format Overview

Bitcoin wallets use seed phrases (also called mnemonic phrases or recovery phrases) as the human-readable backup for private keys. While BIP39 is the dominant standard, several competing formats exist: SLIP39 for Shamir secret sharing, Aezeed for Lightning wallets, Electrum's versioned seed system, and Codex32 for manual verification. Each format makes different tradeoffs between compatibility, security, and functionality.

Format fragmentation creates real problems. A seed phrase generated by one wallet often cannot be imported into another, even when both use the same wordlist. Users who lose access to their original wallet software may find recovery difficult or impossible without understanding which format their backup uses. The following table summarizes the key differences.

BIP39: The Universal Standard

BIP39, proposed in 2013 by Marek Palatinus, Pavol Rusnak, Aaron Voisine, and Sean Bowe, defines the mnemonic seed phrase format used by the vast majority of Bitcoin wallets. It converts random entropy into a sequence of 12 or 24 English words drawn from a fixed 2048-word list, where the first four letters of each word are unique to prevent ambiguity during manual entry.

The encoding works as follows: random entropy (128 bits for 12 words, 256 bits for 24 words) is hashed with SHA-256, and the first few bits of that hash are appended as a checksum. The combined bit string is split into 11-bit groups, each mapping to a word. To derive the master seed, PBKDF2-HMAC-SHA512 stretches the mnemonic (with an optional passphrase as salt) into a 512-bit value used as input to BIP32 hierarchical deterministic key derivation.

BIP39's ubiquity is its greatest strength and a source of its weaknesses. Because the format includes no version information, wallets cannot determine the derivation path from the seed alone. A user recovering a BIP39 seed must know whether their wallet used BIP44, BIP49, BIP84, or BIP86 paths, or try each one. The format also lacks a wallet birthday field, so recovery requires scanning the entire blockchain from the genesis block. These limitations motivated every alternative format discussed below.

SLIP39: Shamir Secret Sharing for Seed Backups

SLIP39, developed by SatoshiLabs (the Trezor team), applies Shamir's Secret Sharing to seed phrase backups. Instead of producing a single 12 or 24-word phrase, SLIP39 splits the secret into multiple shares with a configurable threshold: for example, any 2 of 3 shares can reconstruct the seed, but a single share reveals nothing.

SLIP39 uses its own 1024-word list (distinct from BIP39). Each share is 20 words for 128-bit entropy or 33 words for 256-bit entropy. The format includes a 30-bit RS1024 checksum that provides stronger error detection than BIP39's 4-8 bit SHA-256 checksum. SLIP39 also supports two-level "Super Shamir" grouping, where shares are organized into groups with independent thresholds: useful for organizations that need department-level access policies.

Hardware wallet support for SLIP39 remains limited. The Trezor Model T, Safe 3, Safe 5, and Safe 7 support it natively. Software wallets including Electrum and Sparrow can import SLIP39 shares. However, Ledger, Coldcard, BitBox02, and Foundation Passport do not support SLIP39. Critically, SLIP39 and BIP39 are not interconvertible: you cannot take a BIP39 seed and split it into SLIP39 shares, or combine SLIP39 shares into a BIP39 mnemonic.

Aezeed: Lightning-Native with Versioning

Aezeed was created by Lightning Labs specifically for LND to address BIP39's lack of versioning and birthday information. The internal structure packs 1 byte for an internal version, 2 bytes for a wallet birthday timestamp, and 16 bytes of entropy into a 24-word mnemonic using the standard BIP39 wordlist.

The birthday field encodes the number of days since Bitcoin's genesis block (January 3, 2009). During recovery, the wallet uses this timestamp to skip scanning blocks created before the wallet existed, dramatically reducing initial sync time. The version byte allows future cipher upgrades without breaking backward compatibility.

Aezeed also uses scrypt (n=32768, r=8, p=1) for key derivation instead of BIP39's PBKDF2, providing significantly stronger resistance to brute-force attacks. Unlike BIP39, the passphrase can be changed without generating a new seed: the wallet deciphers with the old passphrase and re-enciphers with the new one. Despite using the same wordlist as BIP39, Aezeed mnemonics are not compatible with BIP39 wallets. Entering an Aezeed phrase into a BIP39 wallet will derive completely different keys.

Electrum Seed Format

Electrum, one of the oldest Bitcoin wallets (first released in 2011), introduced its own seed format in version 2.0 (2014). Rather than using BIP39's checksum approach, Electrum generates seeds where the HMAC-SHA512 hash of the mnemonic begins with a specific version prefix. These prefixes encode the wallet type directly: 01 for standard wallets, 100 for SegWit, and 101 for two-factor authentication wallets.

The Electrum developers chose this design because BIP39 provides no way to determine the wallet type or derivation path from the seed alone. With Electrum's format, the version prefix tells the wallet exactly which address type to derive, eliminating guesswork during recovery. The format is also forward-compatible: new wallet types can be added by defining new prefixes without invalidating existing seeds.

The practical consequence is near-total incompatibility with BIP39. A valid Electrum seed is almost never a valid BIP39 seed and vice versa, even if both happen to use 12 English words. Users who create a wallet in Electrum and attempt to recover it in a BIP39-compatible wallet will find no funds, and no error message will explain why.

Codex32 (BIP93): Manual Verification and Error Correction

Codex32, assigned BIP93 and designed by Andrew Poelstra and Russell O'Connor, takes a fundamentally different approach. Instead of mnemonic words, it encodes BIP32 master seeds as checksummed Bech32 strings. The encoding uses a BCH error-correcting code that can detect up to 8 errors and locate up to 4 errors in a share, far exceeding BIP39's simple checksum.

Codex32's defining feature is that the entire process: generation, splitting into Shamir shares, verification, and reconstruction, can be performed by hand using paper, pen, and printed lookup tables. No electronic device is required at any step. This makes it suitable for high-security setups where users want to verify their backup without trusting any hardware or software. Codex32 supports up to 31 shares with thresholds from 2 to 9.

Seedless Approaches: MPC and Social Recovery

MPC (Multi-Party Computation) wallets eliminate seed phrases entirely. Instead of generating a single secret that must be backed up, distributed key generation creates key shares held by multiple parties. Signatures are produced cooperatively without ever assembling the full private key in one place.

Social recovery wallets allow designated guardians to help restore access if a device is lost. The user never handles a seed phrase directly. Implementations include ZenGo, Coinbase WaaS (Wallet as a Service), and various smart wallet designs.

The tradeoff is clear: seedless designs remove the backup burden but introduce server dependencies or trust assumptions. If the MPC provider goes offline or the social recovery guardians are unavailable, the user may lose access. For Bitcoin users who prioritize self-sovereignty, seed-based backups remain the standard.

Wallet Compatibility Matrix

Cross-wallet recovery is one of the most common failure modes in Bitcoin self-custody. The following table shows which backup formats each major wallet can create and restore.

For a broader look at wallet features beyond backup formats, see the Bitcoin wallet standards reference and wallet recovery options guide.

Security Comparison

Each format's security properties differ in ways that matter for long-term storage and inheritance planning.

BIP39's PBKDF2 with only 2,048 rounds is weak by modern standards. A well-funded attacker with specialized hardware can attempt billions of passphrase guesses per second against a known mnemonic. Aezeed's scrypt is significantly more resistant to both GPU and ASIC-based attacks. For users concerned about passphrase brute-forcing, choosing a long, high-entropy passphrase is critical regardless of format. See our seed phrase entropy and security analysis for a deeper examination of these tradeoffs.

Common Mistakes and Recovery Failures

Seed phrase recovery failures are overwhelmingly caused by user error rather than format limitations. The most frequent mistakes include:

• Transcription errors: writing down a wrong word or swapping word order, with no way to detect the mistake until recovery is attempted
• Forgotten passphrases: BIP39, SLIP39, and Aezeed all support optional passphrases that, if forgotten, make the seed irrecoverable
• Format confusion: entering an Aezeed or Electrum seed into a BIP39-compatible wallet, which silently derives the wrong keys
• Digital-only backups: storing seed phrases in password managers, cloud notes, or screenshots that are vulnerable to malware
• Never testing recovery: users who write down their seed phrase but never verify it works before loading significant funds
• Unknown derivation paths: recovering a BIP39 seed without knowing whether the original wallet used BIP44, BIP49, BIP84, or BIP86

The wallet backup process should always include a test recovery on a separate device before the wallet holds any meaningful value.

Why Format Fragmentation Matters

Bitcoin wallets are long-lived: users may create a backup today and not need it for years or decades. During that time, wallet vendors may shut down, change formats, or discontinue products. If a user's backup is in a proprietary or niche format, recovery options shrink over time.

BIP39's dominance provides a practical safety net: even if a specific wallet disappears, dozens of alternatives can import BIP39 seeds. Users of SLIP39, Aezeed, or Electrum seeds have far fewer recovery options. For inheritance planning, documenting the exact format, derivation path, and any passphrase alongside the seed phrase is essential. A 24-word backup without context may be useless to heirs who don't know which wallet or format was used.

Bitcoin Layer 2 protocols like Spark and Lightning add another dimension to backup complexity: channel state and off-chain balances require separate backup mechanisms beyond the seed phrase itself. Users operating on these layers should ensure their backup strategy covers both on-chain keys and protocol-specific state. For more on recovery strategies across wallet types, see the Bitcoin wallet recovery options comparison.

How to Choose a Seed Phrase Format

For most users, BIP39 with a 24-word mnemonic remains the safest choice due to its near-universal wallet support. If your primary concern is maximizing recovery options across vendors and over time, BIP39's ecosystem lock-in works in your favor.

If you need to distribute backup custody across multiple locations or trusted parties, SLIP39 or Codex32 offer native Shamir secret sharing. SLIP39 is the more practical option today given Trezor's native support, while Codex32 is ideal for users who want to verify shares without any electronic device.

If you are running an LND Lightning node, Aezeed is your only option. Its versioning and birthday features represent genuine improvements over BIP39 for this specific use case.

For multisig setups, BIP39 combined with output descriptors provides both broad compatibility and the metadata needed for reliable recovery. Whichever format you choose, document the format name, wallet software version, and derivation path alongside your seed phrase backup.

Frequently Asked Questions

Can I convert a BIP39 seed phrase to SLIP39 shares?

No. BIP39 and SLIP39 use fundamentally different derivation processes. You cannot split an existing BIP39 mnemonic into SLIP39 shares or reconstruct a BIP39 mnemonic from SLIP39 shares. If you want Shamir secret sharing, you must generate a new SLIP39 wallet from scratch and transfer your funds. Some third-party tools claim to offer conversion, but these typically split the raw entropy rather than following the SLIP39 specification, which introduces security risks.

Is a 12-word seed phrase less secure than a 24-word seed phrase?

A 12-word BIP39 phrase provides 128 bits of entropy, while a 24-word phrase provides 256 bits. Both are far beyond the threshold of brute-force attacks with current or foreseeable technology: 128 bits of entropy means roughly 2^128 possible combinations, which is computationally infeasible to search. The practical difference is that 256-bit seeds offer a larger margin against future advances in computing, including theoretical quantum computing threats. For most individuals, 12 words is sufficient. For institutional custody or long-term cold storage, 24 words is standard.

Why does entering my Electrum seed into another wallet show no funds?

Electrum uses a proprietary seed format with version prefixes that is incompatible with BIP39. Even if both wallets use 12 English words, the seed derivation process is entirely different. The other wallet will derive valid but incorrect keys, finding no transaction history. To migrate from Electrum to a BIP39 wallet, you must send your funds via an on-chain transaction rather than importing the seed.

What happens if I lose my passphrase but still have my seed phrase?

In BIP39, SLIP39, and Aezeed, the passphrase is combined with the mnemonic during key derivation. A missing or incorrect passphrase produces a completely different set of keys. There is no "forgot passphrase" recovery mechanism: the wallet simply derives a different (empty) wallet. If you used a passphrase, it must be backed up with the same care as the seed phrase itself. Without it, your funds are effectively lost unless you can brute-force the passphrase, which is only feasible for short or weak passphrases.

Which seed phrase format is best for Bitcoin inheritance?

BIP39 is the safest choice for inheritance because heirs are most likely to find compatible recovery software years or decades from now. However, the seed alone is not enough: you must also document the wallet software, derivation path (BIP44, BIP84, or BIP86), any passphrase, and the approximate date the wallet was created. SLIP39 is a strong option if you want to distribute shares among multiple heirs or trustees so that no single person can access the funds alone. See our Bitcoin inheritance planning guide for a complete walkthrough.

Are seedless wallets safer than seed phrase wallets?

Seedless wallets (MPC, social recovery) eliminate the risk of seed phrase theft or loss, but introduce different risks: dependency on third-party servers, trust in guardian availability, and potential vendor lock-in. For users who struggle with secure physical storage of seed phrases, seedless designs may reduce overall risk. For users who are comfortable with cold storage best practices, seed-based wallets offer stronger self-sovereignty guarantees with no external dependencies.

What is Codex32 and should I use it?

Codex32 (BIP93) is a seed backup format that encodes BIP32 master seeds as checksummed Bech32 strings with built-in Shamir secret sharing and error correction. Its unique property is that every step can be performed by hand without any electronic device: generation, share splitting, checksum verification, and reconstruction all use paper worksheets and lookup tables. This makes it ideal for users who want to verify their backup integrity without exposing the seed to any computer. It is supported by Coldcard and is gaining adoption among security-conscious Bitcoiners, but it requires more effort to set up than traditional word-based formats.

This tool is for informational purposes only and does not constitute financial advice. Data is approximate and based on publicly available specifications and documentation. Wallet compatibility may change with firmware or software updates. Always verify current support on the wallet vendor's website before making backup or migration decisions.