Shamir, SLIP-39 & splitting schemes

A single seed phrase is a single point of failure: one copy lost is a disaster, one copy found is a theft. Splitting schemes trade simplicity for resilience. Here is every mainstream option, how it actually works, and where people get burnt.

Last fact-checked 25 October 2026 (time-sensitive claims re-checked against the linked sources).

Which standard is my backup? Beginner

Before you split, convert or inherit a backup, find out which format it is. The same English words can belong to several incompatible schemes.

At a glance

Shamir's Secret Sharing — the idea Intermediate

Invented by Adi Shamir in 1979. A secret is encoded as a point on a random polynomial; each share is another point. Any M points reconstruct the polynomial (and secret); fewer than M reveal nothing at all about it — unlike cutting words, where each piece leaks information.

SLIP-39 (Trezor "Shamir Backup" / "Multi-share Backup") Intermediate

SLIP-39 is SatoshiLabs' open standard for Shamir shares written as words. Key facts:

• Good randomness is needed twice: for the master secret and for the share values when it is split (see SLIP-39 randomness).
• Shares are 20 words (128-bit secret) or 33 words (256-bit) from a separate 1,024-word list where every word has a unique four-letter prefix and words were chosen to be hard to confuse.
• Up to 16 shares with any threshold (e.g. 2-of-3, 3-of-5). A strong RS1024 checksum (3 words) catches typos far better than BIP39.
• Trezor Safe 3, Safe 5, Safe 7 and Model T (firmware 2.7.2+) support Multi-share; a 20-word single-share backup created on firmware 2.7.2 or later (June 2024 onwards) can be upgraded to multi-share without moving funds. Older 20-word SLIP-39 backups and 12- or 24-word BIP39 backups cannot be upgraded; you must create a new wallet and move the funds (Trezor SLIP39 FAQ, Trezor: upgrading to Multi-share). Trezor lists multi-share support in Rabby, Electrum, Sparrow, BlueWallet, Wasabi and NuFi software wallets and in OneKey and Keystone hardware wallets; check the exact version before relying on it.
• A SLIP-39 secret is not interchangeable with a BIP39 phrase: you cannot type SLIP-39 shares into a BIP39-only wallet (Ledger, BitBox02, etc.).

Groups (advanced) Expert

SLIP-39 supports two levels: e.g. "2 of these 3 groups", where group A is "1-of-1 (you)", group B is "2-of-3 (family)", group C is "1-of-2 (lawyers)". Powerful for estates, but every extra layer is something your heirs must understand.

Multisig (multi-signature) Intermediate

Instead of splitting one secret, multisig uses several independent keys, each with its own seed, on separate devices. The blockchain itself enforces "M of N signatures required". Typical personal setup: 2-of-3; high-value: 3-of-5.

Shamir vs multisig — head to head

Multisig recovery: what you need, and what happens without the descriptor Expert

A multisig address commits to every participant's public key, not just the ones that sign. To spend, a wallet must rebuild the full script, so a 2-of-3 recovery needs two signing keys and all three public keys (Unchained: wallet configurations, Bitcoin Stack Exchange).

If the descriptor is lost

• All N xpubs are needed. With M seeds you can re-derive those M xpubs, but not the others. Unchained: "all of the xpubs are required to access the funds"; if any key is lost and the configuration is missing, "a subset of the remaining keys will not be enough to recover the funds" (Unchained). So a lost descriptor turns "any 2 of 3" into "all 3, or nothing".
• Then everything else must be guessed. Threshold, script type (nested or native SegWit, Taproot), each key's derivation path (BIP48's default for native SegWit multisig is m/48'/0'/0'/2'; BIP48) and key order. Descriptors distinguish multi(), which keeps keys in the order listed, from sortedmulti(), which sorts them; the two give different addresses (BIP383).
• Where a copy may survive. Coordinator software on an old computer may still hold the configuration; a collaborative custody provider normally has one; a signing device on which the wallet was registered may be able to show or export it (check its manual). Look for these first, but don't plan on them.

Steps for an heir or executor

1. Gather the descriptor and the letter of instruction; confirm the threshold (for example 2-of-3) and which keys are where.
2. Install a coordinator from its official site and import the descriptor (file, QR or text). Check that the checksum is accepted and the first receive address matches the one recorded.
3. Connect M signing devices, or restore M seeds onto hardware wallets, never by typing words into the computer.
4. Send a small test transaction first, then the rest. If a key was lost or exposed, move everything to a new multisig with fresh backups.

Our printable multisig configuration record has space for the threshold, every fingerprint and path, and where each descriptor copy is kept, and no secrets. See also descriptor backups and multisig across vendors.

Codex32 (BIP-93) Expert

BIP-93, by Leon Olsson Curr, Pearlwort Sneed and Andrew Poelstra (status: Draft), encodes a BIP32 master seed in a bech32-like alphabet with strong error correction, and supports Shamir sharing that you can compute entirely by hand using paper volvelles (rotating wheels) and worksheets (secretcodex32.com).

Wallet support, October 2026. COLDCARD firmware 5.6.3 (Mk4/Mk5) and 1.5.3Q (Q), released on 1 October 2026, can generate 128- or 256-bit codex32 wallets, import a complete secret, split the active wallet into 2–9 shares and recover from a threshold of shares (Coinkite, COLDCARD docs). Bitcoin Knots accepts codex32 secrets or threshold shares through importdescriptors (Knots notes). Sparrow 2.4.0 (February 2026) imports the complete secret (share s) only; share recovery and generation are not yet supported (release notes). The project website's note that no wallets support codex32 dates from September 2022.

Seed XOR Expert

Created by Coinkite for COLDCARD (seedxor.com). A BIP39 seed is split into 2 or more parts that are each themselves valid BIP39 seeds; XOR-ing all parts together gives the real seed. All parts are required (N-of-N).

Seed in one place, passphrase in another Intermediate

The simplest split: the words are in location A, the passphrase in location B. A thief needs both. But it is 2-of-2 — lose either and the funds are gone — so each piece usually needs its own duplicate, ending up with 4 items in at least 2–3 places.

Why you must not cut a BIP39 phrase in half Beginner

Do instead: use SLIP-39, multisig, or seed + passphrase.

The numbers: naive splitting versus SLIP-39 Intermediate Expert

Each BIP39 word carries 11 bits. A 24-word phrase is 256 bits of randomness plus an 8-bit checksum; a 12-word phrase is 128 bits plus 4 (BIP39). So someone who finds part of a phrase only has to search the missing words, and the checksum lets them discard most wrong guesses cheaply. The figures below are our own arithmetic from those numbers (missing words × 11, less the checksum bits).

• Reading the table. 2¹²⁴ is still far beyond brute force today, but the margin is gone for no benefit: you still need both halves. 2⁴⁰ is small enough that a determined attacker with ordinary hardware could plausibly search it, even though each guess costs 2,048 rounds of PBKDF2 (BIP39). We have not costed attacks in money or time, because that depends on hardware and on how many address types an attacker checks.
• The 16-of-24 case matches the 80-bit figure in Andreas Antonopoulos's worked example on the comparison page.
• Why SLIP-39 differs. Shamir's scheme makes every combination of fewer than the threshold equally consistent with every possible secret, so a share on its own is worthless to a thief (information-theoretic security). It also keeps recovery tolerance: in 2-of-3 any one share can be lost. A passphrase on top still protects you if a threshold of shares is ever gathered by the wrong person.
• Telling sets apart. Every share in a SLIP-39 set carries the same random 15-bit identifier, which is why shares of one set begin with the same two words and shares of one group with the same three (SLIP-39). Shares from different sets cannot be mixed, even with the same threshold.

Proprietary "sharding" products Intermediate

Several products split backups in their own formats: Ledger Recover (encrypted shares with three companies), Foundation Passport Prime (2-of-3 KeyCards + phone share), Cypherock X1 (device + four cards), Tangem (duplicate cards), Bitkey (2-of-3 with phone and server). They can be excellent for usability, but recovery depends on that vendor's tools continuing to exist. Ask: "If this company vanished tomorrow, could my heirs still recover with open-source software?" See recovery services.

Compatibility at a glance Intermediate

"Supported" changes with firmware and app versions. This table lists only support confirmed in the linked documentation on 24 October 2026; absence from the table does not mean a wallet lacks support. Always test a restore on the wallet you plan to rely on.

Sources: Trezor SLIP-39 FAQ, SLIP-39, COLDCARD Codex32 docs, COLDCARD 5.6.3 release (1 October 2026), Sparrow 2.4.0, Bitcoin Knots codex32 notes, Electrum, aezeed, Moneropedia

Which wallets can restore SLIP-39 shares? Checked against each maker's own documentation Intermediate

Trezor lists Rabby, Electrum, Sparrow, BlueWallet, Wasabi and NuFi software wallets and OneKey and Keystone hardware wallets as supporting its Multi-share Backup (Trezor). We checked the makers' own documentation or release notes on 25 October 2026. "Not verified" means we did not find the maker's own statement; it does not mean the wallet lacks support.

Interoperability pitfalls Expert

• Converting between schemes. BIP-93 explains that turning BIP39 words into codex32 is one-way, because BIP39 hashes the words, and produces an unwieldy 512-bit seed. SLIP-39 shares cannot be converted into codex32 shares because the two use different mathematical fields. The BIP's authors do not recommend interconversion: generate a fresh seed and move the coins (BIP-93).
• Passphrase characters. BIP39 normalises passphrases to Unicode NFKD, while SLIP-39 allows only printable ASCII (codes 32–126). A passphrase with accents or emoji may not move between schemes or keyboards. Plain ASCII is the safest choice.
• Upgrading Trezor backups. Only 20-word single-share backups made on firmware 2.7.2 or later can become multi-share without moving funds. Older SLIP-39 and all BIP39 backups need a new wallet (Trezor).
• Look-alike phrases. Electrum and aezeed phrases use BIP39's English words. A BIP39-only wallet will reject them or open a different, empty wallet.
• Non-English wordlists. BIP39 strongly discourages them because most wallets support only English, and a translated phrase is a different wallet.
• Extended key prefixes. ypub and zpub (SLIP-132) are a convention, not part of BIP32. Descriptors state the script type explicitly and are the more portable record.

Descriptors and the BIP380 family Expert

An output descriptor is a short text that says exactly which scripts and keys a wallet uses, for example "native SegWit, this xpub, these paths". BIP380 defines the general syntax and an optional 8-character checksum after #. Related BIPs define the script types: 381 (non-SegWit), 382 (SegWit), 383 (multisig), 384 (combo), 385 (raw and addr), 386 (Taproot) and 387 (Taproot multisig). BIP389 (Draft) adds multipath expressions such as <0;1> so one descriptor covers receive and change. BIP388 (Complete) defines wallet policies, a compact descriptor form that signing devices can register and display.

Bitcoin Core has created descriptor wallets by default since version 23.0 (release notes); its descriptor documentation lists the supported expressions.

Primary sources for this page

• SLIP-39
• BIP-93 codex32
• BIP380 descriptors
• BIP389 multipath
• BIP388 wallet policies
• Bitcoin Core descriptors
• Trezor SLIP-39 FAQ
• COLDCARD Codex32
• Sparrow 2.4.0
• Bitcoin Knots codex32
• Electrum seeds
• LND aezeed
• Monero mnemonic

See also sources: core guides.

Last reviewed: 23 October 2026 · Educational information only — verify current details with official sources.