When you move beyond a single seed phrase written on paper, two advanced backup methods dominate the conversation: Shamir Secret Sharing (SLIP39) and native Bitcoin multisig (BIP-48). Both let you distribute trust across multiple locations so that no single point of failure can compromise your bitcoin. But they work in fundamentally different ways, protect against different threats, and have very different operational tradeoffs.
This guide explains both methods from the ground up, compares them head to head, and helps you decide which one fits your security model.
How Shamir Secret Sharing Works
Shamir Secret Sharing is a cryptographic algorithm invented by Adi Shamir in 1979. In the Bitcoin context, it is implemented as SLIP39, a standard developed by SatoshiLabs (the company behind Trezor) that applies Shamir’s algorithm to seed phrase backups.
The Core Concept
Instead of a single 24-word seed phrase, Shamir backup splits your master secret into multiple shares. You choose a threshold (M) and a total number of shares (N). Any M shares out of N can reconstruct the original secret, but M-1 shares reveal absolutely nothing about it.
For example, in a 2-of-3 configuration:
- Three shares are generated, each a sequence of 20 or 33 words (depending on the entropy level)
- Any two shares can reconstruct your wallet
- A single share, by itself, provides zero information about your seed or your funds
- You store each share in a different geographic location
This is not simply splitting a seed phrase into three pieces (which would be insecure because each piece reveals partial information). Shamir’s algorithm uses polynomial interpolation so that, below the threshold, the shares are mathematically independent of the secret. A single SLIP39 share does show which share it is and how many are needed to recover, but it gives an attacker no information at all about the secret itself.
SLIP39 Specifics
The SLIP39 standard formalizes how Shamir Secret Sharing works for cryptocurrency wallets:
- Share format: Each share is encoded as a sequence of words from a dedicated SLIP39 wordlist (different from the standard BIP39 wordlist). Shares are typically 20 words for 128-bit entropy or 33 words for 256-bit entropy.
- Group support: SLIP39 supports multiple groups of shares, enabling complex configurations like “2-of-3 shares from Group A OR 3-of-5 shares from Group B” for tiered access control.
- Checksum: Each share includes a built-in checksum so you can verify the share is valid and undamaged before attempting recovery.
- Hardware support: Trezor is the main hardware wallet maker that supports SLIP39 natively (Safe 3, Safe 5, Safe 7 and Model T), and the Keystone 3 Pro can also create and restore SLIP39 backups. Wallets such as Sparrow and Electrum can restore them, and so can open-source tools like the python-shamir-mnemonic library.
How Recovery Works
When you need to recover your wallet, you gather the required number of shares (the threshold M) and enter them into a compatible device. The device reconstructs the master secret from the shares using polynomial interpolation, derives the private keys, and your wallet is restored.
The critical point: outside a device, the master secret never exists as a complete entity. Only the shares exist, distributed across your chosen locations. Inside a device it does: the hardware wallet that created the shares keeps the master secret, protected by your PIN, so it can sign, and a recovery rebuilds it in whichever device you use. That device is where the whole secret lives.
Operational Characteristics
- Day-to-day use: Your hardware wallet operates normally with a single device. You do not need multiple shares to sign transactions. The shares are only needed for backup and recovery.
- Signing transactions: Single-device, single-signature. Your Trezor signs transactions independently using the keys derived from the master secret it keeps on the device, protected by your PIN.
- Updating backups: On a Trezor wallet created since June 2024, you can generate a new set of shares at any time without moving funds or changing your wallet addresses (an older Shamir wallet can’t). The old shares stay valid until you destroy them. This is a significant operational advantage.
How Multisig Works
Native Bitcoin multisig creates a wallet that requires multiple independent keys to authorize a transaction. Unlike Shamir, which splits a single secret, multisig uses genuinely separate keys that never need to be in the same place.
The Core Concept
A multisig wallet is defined by an M-of-N quorum. For a 2-of-3 multisig, three separate private keys are generated on three separate hardware wallets. A transaction requires valid signatures from any two of the three keys. At no point do the keys need to be combined or brought together.
Each key in a multisig setup is an independent entity:
- Generated on its own hardware device
- Has its own seed phrase backup
- Can be stored in a separate geographic location
- Signs transactions independently on its own device
BIP-48 and Descriptor Wallets
BIP-48 defines the derivation path standard for multisig wallets, ensuring that different hardware wallets and software coordinators can work together. When you set up a multisig wallet using Sparrow Wallet or Nunchuk, the coordinator uses BIP-48 derivation paths by default to generate the correct addresses from each participant’s extended public key. Electrum does the same for hardware wallets and BIP39 seeds, but a key made from Electrum’s own SegWit seed uses m/1' instead, so write down the path used for each key.
The wallet configuration (which keys participate, the threshold, derivation paths) is captured in a wallet descriptor or a multisig configuration file. This configuration file is critical for recovery and must be backed up alongside the individual seed phrases. Losing the configuration file makes recovery significantly harder, though not impossible if you know the participating xpubs and the derivation paths used.
How Signing Works
Signing a multisig transaction requires coordination between devices:
- The wallet coordinator (Sparrow, Nunchuk, etc.) creates an unsigned transaction as a Partially Signed Bitcoin Transaction (PSBT).
- The PSBT is transferred to the first signing device (via USB, SD card, QR code, or air gap) for signing.
- The first device signs and returns the partially-signed PSBT.
- The PSBT is transferred to the second signing device for the second signature.
- Once the threshold of signatures is reached, the coordinator broadcasts the fully-signed transaction.
This process requires physical access to multiple devices for each transaction. This is both the strength and the inconvenience of multisig. For more detail on the operational aspects, see our comprehensive multisig guide from beginner to expert.
Operational Characteristics
- Day-to-day use: Every transaction requires coordinating multiple devices. This adds time and complexity to spending.
- Signing transactions: Multi-device, multi-signature. You need physical access to M devices out of N for each spend.
- Updating the setup: Changing a key (replacing a compromised device, for example) requires creating an entirely new multisig wallet and moving all funds to new addresses. This is an on-chain transaction with fees and a new wallet configuration.
Head-to-Head Comparison
| Factor | Shamir (SLIP39) | Multisig (BIP-48) |
|---|---|---|
| What is distributed | Shares of a single secret | Independent private keys |
| Signing requirement | Single device | Multiple devices (M of N) |
| Single point of failure at signing | Yes (the signing device) | No |
| Hardware wallet support | Trezor and Keystone | Most major wallets |
| On-chain footprint | Standard single-sig transactions | Larger transactions, higher fees |
| Backup rotation | Generate new shares, no fund movement (Trezor wallets made since June 2024) | New wallet + on-chain fund transfer |
| Vendor diversity | No (single device manufacturer) | Yes (different devices per key) |
| Setup complexity | Low (single device) | High (multiple devices + coordinator) |
| Spending convenience | High (single signature) | Low (multi-device coordination) |
| Recovery complexity | Moderate (gather M shares) | High (M seeds + wallet config) |
| Inheritance friendliness | Good | Complex |
| Bitcoin protocol native | No (application layer) | Yes (enforced by consensus) |
The Critical Security Difference
The most important distinction between Shamir and multisig is where the single point of failure exists during signing.
Shamir’s Weakness: The Signing Device
With Shamir, your backup is distributed, but your signing is not. When you use your Trezor to sign a transaction, the complete master secret exists inside that single device. If that device is compromised (malicious firmware, physical tampering, coercion), all funds can be stolen with a single signature.
Additionally, during recovery, the complete master secret must be reconstructed inside a single device. For the brief moment of recovery, all shares converge to recreate the seed in one place. If the recovery device is compromised, the attacker captures the full secret.
This is what Bitcoin security researchers mean when they say Shamir “reintroduces a single point of failure.” The shares are beautifully distributed, but the secret must eventually be reassembled in one location to be useful. That location becomes the vulnerability.
Multisig’s Strength: No Reconstruction Needed
With multisig, the individual private keys never need to be in the same place. Each key signs independently on its own device, and the signatures are combined in a way that never requires the keys themselves to combine. There is no moment of reconstruction. There is no single device that holds all the power.
An attacker who compromises one device in a 2-of-3 multisig gets one key. That key alone cannot move funds. They would need to independently compromise a second device in a different location. This is a fundamentally stronger security guarantee than Shamir provides.
Furthermore, multisig enables vendor diversity: each key can live on a device from a different maker. A popular mix is a Coldcard, a Trezor and a SeedSigner; our multisig in practice lesson compares devices that work well together. A firmware flaw in one maker’s devices then reaches only one key, because the other devices run completely different code. This is a real risk: in July 2026 a flaw in Coldcard firmware turned out to have made seeds generated on those devices far easier to guess, and thieves drained more than 5,200 addresses (see our Coldcard advisory). With Shamir, one device does all the signing, so one maker’s flaw can reach the whole wallet.
When to Use Shamir (SLIP39)
Despite its theoretical limitations compared to multisig, Shamir has legitimate use cases where it is the better practical choice.
Personal Backup Distribution
If you want to eliminate the single point of failure in your backup without the operational overhead of multisig, Shamir is ideal. A 2-of-3 Shamir configuration means you can store shares with trusted family members or in separate geographic locations, and no single share compromises your funds. If one share is lost or stolen, you still have two others for recovery.
Inheritance Planning
Shamir is significantly simpler for inheritance planning than multisig. You can distribute shares to family members and a lawyer, with instructions that any 2-of-3 shares can recover the wallet. The heirs do not need to understand multisig coordination, PSBT signing, or wallet descriptors. They just need to enter the word sequences into a compatible device, plus the passphrase if you set one, because the shares don’t contain it. For comprehensive inheritance strategies, see our multisig inheritance planning guide, which covers both approaches.
Users Who Need Simple Daily Operations
If you spend bitcoin regularly and want the convenience of single-device signing combined with a distributed backup, Shamir gives you both. You get the ease of a standard hardware wallet transaction with the safety net of geographically distributed recovery shares.
Users Committed to the Trezor Ecosystem
If you already use and trust Trezor devices, Shamir is close at hand. On a Trezor Safe, a new wallet’s default backup is already SLIP39: a 20-word Single-share Backup. Trezor Suite can later add a Multi-share Backup for the same wallet, but the original 20 words still restore it on their own, so check the new shares work, then destroy the 20 words or keep guarding them. A wallet made with a 12- or 24-word BIP39 phrase can’t do this: moving to shares means creating a new wallet and moving your funds to it. After setup, spending works exactly as it does with a standard seed phrase wallet. For background on the broader context of open-source wallets, see our article on why open source hardware wallets matter.
When to Use Multisig
Multisig is the stronger security model for the following scenarios.
High-Value Holdings
For significant amounts of bitcoin (the threshold varies by individual, but generally amounts where loss would be financially devastating), multisig’s elimination of the single-device signing vulnerability justifies the additional operational complexity. The security guarantee is enforced by the Bitcoin protocol itself, not by an application-layer algorithm.
Organizational or Shared Custody
When multiple people need to authorize transactions (business accounts, family funds, collaborative treasuries), multisig is the only option that provides genuine shared control. Each participant holds their own key, and a payment needs enough of them to sign, such as any two of three: no one can spend alone, and no one can block a payment alone. Shamir cannot provide this because it is a backup mechanism, not a signing mechanism.
Users Who Value Vendor Diversity
If you want protection against a catastrophic firmware vulnerability in a single manufacturer’s hardware wallet, multisig with devices from different vendors is the solution. A Trezor bug cannot compromise a Coldcard-held key. This protection is impossible with Shamir, which relies on a single signing device.
Maximum Security Without Trust in Any Single Entity
Multisig is the gold standard for trustless self-custody. No single manufacturer, no single device, and no single location can compromise your funds. This is the closest you can get to eliminating all single points of failure in Bitcoin self-custody. For a complete walkthrough, see our Sparrow Wallet multisig tutorial.
Can You Combine Both?
Yes, and some security-conscious Bitcoiners do exactly that. You can set up a multisig wallet where each key’s individual seed phrase is backed up using Shamir. This works only for keys held on devices that make SLIP39 backups, such as a Trezor or a Keystone 3 Pro. This gives you:
- Multi-device signing security (multisig protects the signing process)
- Distributed backup for each key (Shamir protects the individual recovery phrases)
The downside is complexity. You now have multiple Shamir share sets to manage across multiple locations, plus the multisig wallet configuration to back up. This level of security architecture is typically only justified for very high-value holdings or organizational custody where the stakes warrant the operational overhead.
A more common and practical middle ground: use multisig for signing security, and store each individual seed phrase on a metal backup in a separate geographic location. This provides multi-device security without the complexity of layering Shamir on top.
Practical Recommendations
For Most Individual Bitcoiners
Start with a standard seed phrase on a single hardware wallet with a metal backup. When your holdings grow to a level where loss would be seriously painful, graduate to either Shamir or multisig based on your priorities:
- Choose Shamir if you value simplicity, want easy inheritance planning, and are comfortable trusting a single signing device (especially if you also use a passphrase).
- Choose multisig if you want the strongest possible security model, value vendor diversity, and are willing to invest in the operational overhead of multi-device signing.
For Businesses and Organizations
Multisig is the clear choice. Shared custody requires independent keys held by independent parties. Shamir cannot replicate this because it produces a single signing authority. Use a 2-of-3 or 3-of-5 multisig with devices from different manufacturers and a wallet coordinator like Nunchuk that streamlines the multi-party signing workflow.
For Inheritance Focus
Shamir with a clear instruction document is the simpler path. Your heirs need to understand “gather 2 of these 3 sealed bags and enter the words into this device,” and, if you use a passphrase, where its separate backup is kept: the shares alone restore only the standard wallet, not the passphrase wallet holding your coins. If you also use a passphrase, the shares alone open a valid wallet, but not the one your passphrase protects, so leave your heirs a separate, secure way to get that exact passphrase. Multisig inheritance requires understanding wallet descriptors, PSBT coordination, and potentially multiple hardware wallet interfaces. Unless your heirs are technically sophisticated, Shamir’s simpler recovery process reduces the risk of human error during an already stressful time.
Frequently Asked Questions
Is Shamir Secret Sharing the same as splitting my seed phrase into parts?
No, and this is a critical distinction. Naive seed splitting (words 1-8 in one place, words 9-16 in another, words 17-24 in a third) is deeply insecure because each piece reveals partial information about your seed. An attacker with any one piece has a dramatically reduced search space. Shamir Secret Sharing uses polynomial mathematics to create shares where any single share reveals zero information about the original secret. They are fundamentally different approaches with completely different security properties.
Can I recover a SLIP39 Shamir backup without a Trezor?
Yes. SLIP39 is an open, documented standard. Besides Trezor, the Keystone 3 Pro hardware wallet can restore a SLIP39 backup, and so can software such as Sparrow and Electrum, or the open-source python-shamir-mnemonic library. Restore on a hardware wallet whenever you can: typing your shares into a computer hands the whole secret to whatever runs on it, so keep that route for an emergency and move your coins to a new wallet afterwards. Either way, you are not locked into Trezor’s ecosystem for recovery.
Does multisig cost more in transaction fees?
Yes. Multisig transactions are larger on-chain because they include multiple signatures and a more complex script. With native SegWit multisig (P2WSH), a typical 2-of-3 spend of one coin to one recipient plus change is about 190 virtual bytes, against about 141 for an ordinary single-key wallet: roughly 1.3 to 1.5 times the fee. The older P2SH format costs considerably more. With Taproot, key-path spends can look like regular single-sig transactions when the full quorum signs cooperatively, reducing the fee premium. But non-cooperative spends still require the larger script path.
What happens if I lose one Shamir share?
In a 2-of-3 configuration, losing one share is fine. You still have two shares, which is sufficient to reconstruct the master secret and generate a new set of three shares. On a Trezor wallet created since June 2024, Trezor Suite makes the new set for the same wallet, with the same addresses; an older Shamir wallet can’t make another set, so you create a new wallet and move your funds to it. After checking the new set, destroy the remaining old shares (they stay valid until you do) and distribute the new set. However, losing two shares in a 2-of-3 setup makes this backup useless. If your device still works, move your funds at once to a wallet with a new backup; if it doesn’t and you have no other valid backup, they are lost for good. Always monitor that you maintain at least M shares at all times.
What happens if one multisig key is compromised?
In a 2-of-3 multisig, a single compromised key cannot move funds. You should immediately create a new multisig wallet (replacing the compromised key with a new one) and transfer all funds from the old wallet to the new one. This requires an on-chain transaction and new wallet configuration, but your funds remain secure throughout the process as long as only one key is compromised.
Is MuSig2 a better alternative to either approach?
MuSig2 lets several keys produce one combined signature, so the spend looks like an ordinary single-key payment on the blockchain. That improves privacy and lowers fees compared with script-based multisig. On its own, though, MuSig2 is N-of-N: every key must sign, and the signers exchange two rounds of messages, which changes how you sign. To build a 2-of-3 with it, a wallet combines MuSig2 with Taproot’s alternative spending paths. Ledger’s Bitcoin app added MuSig2 in April 2025, but as of November 2026 it is not yet widely supported in hardware wallets. For now, traditional multisig (BIP-48) and Shamir (SLIP39) remain the practical choices for most users.
