Shamir Secret Sharing (Adi Shamir, 1979) splits a secret into N shares such that any threshold M reconstructs it while fewer reveal nothing. SLIP-39 is the modern wallet-compatible standardization for Bitcoin seed phrases, supported most prominently by Trezor. The critical caveat: the threshold of shares must eventually be combined on one device to reconstruct the master seed, producing a recovery-time exposure window that multisig — where keys sign independently and are never combined — does not have. SLIP-39 excels as a backup scheme for deep-cold wallets touched rarely, with geographic distribution of shares; it is a poor fit for frequently-used operational wallets, where multisig dominates.
Why this note matters
SLIP-39 is the cryptographic primitive most often confused with multisig. The two share surface similarities — N pieces, M required — but differ structurally in ways that matter for security and inheritance. The note corrects the “SLIP-39 is multisig” confusion that leads holders to choose the wrong tool, surfaces the recovery-time exposure window that practitioners (Casa, Lopp, Unchained, Nunchuk) treat as the principal failure mode, and establishes where SLIP-39 genuinely shines — long-term cold storage with geographic distribution where reconstruction is rare and recovery-time discipline is manageable.
What this is
Shamir Secret Sharing (1979)
Adi Shamir’s scheme: a secret value can be encoded as a point in a coordinate system such that distributing N points and requiring M to reconstruct produces a system where:
- M points are sufficient to reconstruct the secret (using Lagrange interpolation)
- Fewer than M points reveal nothing about the secret (information-theoretically secure)
- N can be arbitrarily larger than M, providing redundancy
The 3-of-5 case is the most common: distribute 5 shares; any 3 reconstruct; up to 2 can be lost without compromising recovery; no information leaks from holding 1 or 2 shares.
SLIP-39
SLIP-39 (Shamir’s Secret-Sharing for Mnemonic Codes, Satoshi Labs, 2017) is the modern standardization of Shamir for BIP-32 wallet seeds. It defines:
- A wordlist of 1,024 words (different from BIP-39’s 2,048) used to encode shares
- A two-level structure: groups of shares (each with its own threshold) within an outer threshold
- A check-byte format that lets wallets detect transcription errors
- Hardware-wallet-friendly representations (a SLIP-39 share is 20 or 33 words, encoded similarly to a BIP-39 mnemonic)
The two-level structure allows configurations like “any 2 of 3 family groups, where each group is any 3 of 5 family members” — useful for institutional and family-office contexts.
For the operational individual holder, the simpler form is more common: a single group, N shares, threshold M. 3-of-5 is the canonical configuration.
The critical difference from multisig
Multisig uses multiple cryptographically independent keys, each signing transactions independently. The keys are never combined; signatures are aggregated at the transaction level. A 2-of-3 multisig wallet has three keys, each on its own hardware device, and any two of them can sign — without the third ever being involved.
SLIP-39 uses one cryptographic key (the master seed) split into shares for backup purposes. To sign transactions, the threshold of shares must be combined on one device, the master seed reconstructed from them, and the wallet operated as a standard single-sig wallet from that point.
The implication: SLIP-39 has a reconstruction-time exposure window that multisig does not. At the moment of reconstruction, the full seed exists on one device. Compromise of that device — supply-chain attack, observer, malware — exposes the entire wallet.
Multisig has no such window. A 2-of-3 multisig signs by passing a partial transaction (PSBT) between two devices, each adding its signature independently. Neither device ever holds the full spending capability.
This is what Casa means by “Shamir Secret Sharing Shortcomings”: the cryptography is fine, but the operational pattern requires the holder to bring the threshold of shares together physically, which creates a single point of exposure that the synthesis treats as substantially worse than multisig’s “two keys signing independently” model.
When to use this
SLIP-39 is appropriate when:
- The wallet is deep cold — touched rarely, perhaps annually or less often
- The holder wants geographic distribution of backups without the operational complexity of multisig
- The holder has the discipline to manage the recovery-time exposure window (a clean device, no observers, secure reconstruction environment)
- The wallet is a single-sig setup at heart that uses SLIP-39 for backup redundancy
SLIP-39 is not appropriate when:
- The wallet is frequently used — every spend reconstructs the seed, multiplying the exposure window
- The holder wants multisig’s “no key combination at any time” property — that is multisig’s defining feature; SLIP-39 explicitly does not provide it
- The holder is confused about the difference from multisig — adopt multisig instead, or do not adopt SLIP-39
- The holder lacks discipline for the recovery-time setup — a sloppy reconstruction defeats the geographic distribution
How it works in practice
Setup
A SLIP-39-supporting hardware wallet (Trezor is the canonical example; some others support it to varying degrees) generates the master seed and immediately splits it into N shares at threshold M. The operator records each share separately — typically on metal backups, geographically distributed.
The hardware wallet may or may not store the seed itself; some implementations regenerate it from a stored set of shares each time the device boots. The operator-facing experience: each share is 20 or 33 words, similar in appearance to a BIP-39 mnemonic but from the SLIP-39 wordlist.
Storage
Each share is treated as security-sensitive but individually insufficient. A share that is found alone reveals nothing. A share that is lost is recoverable (as long as the holder retains the threshold).
The geographic-distribution pattern: 5 shares, 3 needed. Locations: home safe, bank safe deposit box, parent’s home, attorney’s office, second property. Any 3 of these 5 can reconstruct; any single location’s compromise reveals nothing.
This is the structural redundancy SLIP-39 provides. It is genuine and useful — particularly for holders worried about a single location being compromised (fire, burglary, jurisdictional risk).
Recovery / spending
To recover the wallet or initiate a spend, the holder physically brings the threshold of shares to one location, enters each into a SLIP-39-compatible device (or a software tool — though hardware is strongly preferred), and the device reconstructs the master seed.
At that moment, the device holds the entire spending capability. The holder can then:
- Sign a transaction (the seed is used for signing)
- Wipe the device (the seed is no longer reconstructable until the next gathering)
- Continue using the device with the seed loaded (more convenient, but the exposure window stays open)
The choice of how long to leave the seed loaded is part of the SLIP-39 operational discipline. Long-term cold storage typically wipes immediately after the signing; frequently-used wallets keep the seed loaded, defeating much of the geographic-distribution benefit.
Inheritance
SLIP-39 has a structurally clean inheritance story when paired with documentation: heirs need to know where the shares are and what the threshold is. With M of N shares accessible and a SLIP-39-compatible device, recovery is straightforward.
The pitfalls:
- Heirs may not know which shares to combine, or in what order (SLIP-39 doesn’t require ordering, but heirs may not know that)
- The geographic distribution must be findable — locations must be documented
- The threshold must be documented — “you need 3 of these 5” is information the heir must have
- Compatibility considerations — if Trezor were to stop supporting SLIP-39, the wallet still recovers via open-source software, but heirs may not know how
The recommendation: document the shares’ locations, the threshold, and the recovery procedure as part of the broader inheritance plan.
Tradeoffs and considerations
Recovery-time exposure is the structural concern
Every major synthesis source identifies this as SLIP-39’s principal failure mode:
- Casa prefers multisig for this reason — multisig avoids the recovery-time exposure window entirely
- Lopp has written a dedicated piece, Shamir’s Secret Sharing Shortcomings, arguing that the recovery-time exposure makes SLIP-39 worse than multisig for most use cases
- Unchained calls SLIP-39 “single points of failure at certain instances during its lifecycle”
- Nunchuk does not recommend SLIP-39 for its operational wallets
The defence is operational: reconstruct shares only in clean environments, use SLIP-39 only for rarely-touched wallets, wipe immediately after reconstruction. The defence is real but requires discipline that the holder must sustain across years.
SLIP-39 is a backup scheme, not a custody scheme
The clearest mental model: SLIP-39 is a way to distribute backup of a single-sig wallet, with the bonus that no single share reveals anything. The wallet is operationally single-sig; the SLIP-39 split is backup redundancy.
This framing avoids the confusion with multisig. SLIP-39 is not multisig. It does not provide multisig’s “no key combined ever” property. It provides geographic-distribution-of-backup that ordinary copy-of-seed backup does not.
When SLIP-39 genuinely beats multisig
SLIP-39 wins over multisig in specific scenarios:
- Long-term cold storage with rare reconstruction — the recovery-time exposure window is small if it opens once a decade
- Single-sig wallet privacy — the on-chain footprint is single-sig, with multisig’s heuristics not applying
- Geographic distribution without coordination overhead — shares are passive; multisig keys require coordination at spending time
- Lower setup cost — one hardware wallet that supports SLIP-39 vs. three hardware wallets for multisig
For holders whose wallet is touched rarely and whose threat model is dominated by single-location risk (fire, burglary, jurisdictional), SLIP-39 is a legitimate choice. For holders whose wallet is touched often, multisig is structurally better.
Hardware-wallet support is uneven
Trezor is the canonical SLIP-39 implementation. Other hardware wallets support it inconsistently:
- Trezor: native, full implementation
- Coldcard: limited support; not the primary backup mode
- BitBox02: no native SLIP-39 support as of 2026-05-14
- Foundation Passport: no native SLIP-39
- Blockstream Jade: no SLIP-39
This matters for vendor-diversity considerations. A holder who wants vendor-diverse multisig + SLIP-39 backup has fewer options than for either feature alone.
Independent software (SLIP-39 reference implementations) provides a recovery path even if no hardware wallet supports SLIP-39 in the future. But the recovery experience is rougher, and the recovery-time exposure is potentially worse on a general-purpose computer than on a hardened hardware wallet.
Two-level structure for institutional use
The two-level SLIP-39 structure (groups of shares within an outer threshold) enables institutional configurations — “any 2 of 3 family branches, each requiring 3 of 5 family members” — that mirror corporate signing structures.
For individual holders, the two-level structure is over-engineered. The single-group form (N shares at threshold M) is sufficient and easier to operate.
Comparison with alternatives
| Approach | Backup distribution | Recovery exposure | Hardware vendor support | Operational complexity |
|---|---|---|---|---|
| Single seed, single backup | None | None (until backup is touched) | Universal | Lowest |
| Single seed, multiple copies | Geographic possible | Each copy is full seed (high exposure) | Universal | Low |
| SLIP-39 (3-of-5) | N shares, threshold M, full distribution | High at reconstruction time | Trezor; limited elsewhere | Medium |
| BIP-85 master + child wallets | Master backed up; children reproducible | Master compromise affects all | Coldcard, Trezor, BitBox | Medium |
| 2-of-3 multisig | Three independent keys, geographic | None — keys never combined | Universal | Medium-to-high |
| 2-of-3 collaborative multisig | Two keys at holder + one partner | None — keys never combined | Universal | Medium |
For a holder seeking geographic distribution of long-term cold storage, SLIP-39 is structurally cleaner than multiple copies of one seed (which exposes the full seed at each location) but worse than multisig (which never combines keys). For a frequently-used wallet, multisig dominates.
Tiered recommendations
Tier 0: Don’t use SLIP-39. The operational complexity is not justified.
Tier 1 (50K): Generally don’t use SLIP-39. A simple metal backup of the seed is sufficient at this tier. SLIP-39’s marginal benefit (geographic distribution of shares) is over-engineered against the realistic threat surface.
Tier 2 (1M+): Optional, as a backup scheme for a single-sig deep-cold wallet. Often dominated by multisig — if the operational complexity is justified, multisig is structurally better. A specific niche where SLIP-39 wins: holders who want single-sig privacy on-chain combined with geographic-distribution backup.
Tier 3 (>$1M): SLIP-39 has a place in some compound setups — e.g., a SLIP-39 split of a multisig key, or a SLIP-39 split of a BIP-85 master. As a standalone custody scheme at Tier 3, generally dominated by multisig configurations.
In all tiers: SLIP-39 is most defensible for deep-cold wallets that are touched rarely. The recovery-time exposure window is acceptable when it opens once a decade. It is unacceptable when it opens monthly.
Common pitfalls
Treating SLIP-39 as multisig. The most common conceptual mistake. SLIP-39 combines shares to reconstruct one seed; multisig combines signatures from independent keys without ever combining the keys. The exposure profiles differ structurally.
Reconstructing shares on a compromised device. The defining failure mode. If the device used for reconstruction is malware-infected, supply-chain-compromised, or observed, the full seed is exposed at the reconstruction moment.
Storing the threshold in only the holder’s head. Heirs need to know “you need 3 of these 5 shares” — without that, the recovery is a search problem (try all combinations). Document the threshold.
Mixing SLIP-39 shares from different wallets. Each wallet’s shares are independent; combining shares from different wallets produces nothing. Label shares clearly to avoid confusion.
Using software-only SLIP-39 for substantial holdings. The reference implementations work but use general-purpose computers. Hardware-wallet implementations are substantially more secure. Trezor is the canonical hardware option.
Keeping the seed loaded on the device after reconstruction. Defeats much of the geographic-distribution benefit. The seed should be wiped after each signing session for the SLIP-39 model to provide its intended security.
Adopting SLIP-39 because it sounds sophisticated. SLIP-39 is sometimes adopted by holders who want “more security than single-sig” without understanding what it actually provides. If the holder’s real concern is exposure of a single key, multisig is structurally better.
Combining SLIP-39 with a passphrase without understanding the interaction. A SLIP-39 split of a passphrase-protected wallet’s seed reconstructs only the seed; the passphrase must be separately reconstructed. This can be elegant (passphrase + SLIP-39 of seed, or seed + SLIP-39 of passphrase) but the holder must understand which artifact is being split.
Tooling and resources
The synthesis document (canonical for the section):
- Bitcoin Self-Custody & Security: A Synthesis of Contemporary Best Practices, LegacyCipher discussion, April 2026 — SLIP-39 treated as distinct from multisig with the recovery-time-exposure caveat called out repeatedly.
Underlying specifications:
- SLIP-39 — Shamir’s Secret-Sharing for Mnemonic Codes, Satoshi Labs (2017). The canonical specification.
- The original Shamir (1979) paper — How to Share a Secret, Communications of the ACM 22 (11): 612-613. For the cryptographic foundation.
Primary practitioner sources:
- Casa — Shamir Secret Sharing Shortcomings (the canonical critique). See Jameson Lopp for the author (Lopp was at Casa during this writing).
- Trezor — SLIP-39 support documentation; the canonical hardware implementation.
- Unchained — Multisig, Shamir’s secret sharing & MPC compared (substantive comparison).
- Lopp — Shamir’s Secret Sharing Shortcomings (the dedicated piece arguing against SLIP-39 for most use cases).
Software references:
- The SatoshiLabs SLIP-39 reference implementation (Python; for recovery-only use, run offline)
- Mnemonic-converter tools (run offline only)
As of 2026-05-14: SLIP-39 has not gained wide adoption beyond Trezor. Trezor remains the canonical hardware implementation. The cryptographic foundation is stable; the operational tooling is the slow-changing element.
Open questions for further development
- Casa and Lopp argue strongly against SLIP-39 for most use cases. Is the recovery-time exposure window genuinely as bad as they argue, or is it a manageable operational discipline for holders who treat it as such?
- The two-level SLIP-39 structure enables institutional configurations that mirror corporate signing structures. Is there a place for this in personal self-custody (e.g., family-branch configurations) that the current framing underweights?
- Hardware-wallet support for SLIP-39 is concentrated in Trezor. If Trezor were to stop supporting it (as Ledger has stopped supporting some legacy features), what is the realistic migration path for existing SLIP-39 wallets?
- The synthesis pairs SLIP-39 with passphrase patterns (passphrase + SLIP-39 split of the passphrase) as an inheritance solution. Is this pattern well-tested at scale, or is it primarily theoretical?
- The framework currently treats SLIP-39 as Configuration 3 on the configuration ladder. Given its structural distinctness (it is a backup scheme, not a custody scheme), should it be moved off the ladder and treated as an orthogonal layer alongside BIP-85?
Related notes
The framing lenses:
- Loss vs exposure failure modes — SLIP-39’s recovery-time exposure window is the central trade
- Threat modeling for self-custody — SLIP-39’s geographic-distribution benefit addresses single-location threats specifically
- Self-custody configuration ladder — SLIP-39 as Configuration 3
Other storage and key concept notes:
- Seed phrases and BIP-39 — the underlying seed SLIP-39 splits
- Passphrases and the 25th word — the passphrase + SLIP-39 combined pattern
- BIP-85 child seeds — the alternative deterministic-derivation layer
- Hot vs cold storage
- PSBT and wallet descriptors
Custody configurations:
- Multisig setups — the structurally distinct alternative
- Collaborative custody services
Hardware wallets supporting SLIP-39:
- Trezor — the canonical implementation
- Hardware wallets overview
Operational discipline:
- Backup strategies for seeds — SLIP-39 share storage discipline
- Recovery rehearsal practice — recovery-time discipline is central to SLIP-39’s safety
- Common failure modes in self-custody — SLIP-39-specific failure modes
Inheritance:
- Inheritance planning for bitcoin — SLIP-39’s structurally clean inheritance story
The principal practitioner:
- Jameson Lopp — author of the canonical critique
The sub-MOC home: