- Home
- / Blog
- / BIP Standards
- / SLIP-39 vs BIP39: Shamir Backup Explained
SLIP-39 vs BIP39: Shamir Backup Explained
SLIP-39 is SatoshiLabs’ standard for Shamir backup: instead of one recovery phrase, it can split a wallet’s master secret into several word lists, called shares, so that a set number of them, any 2 of 3 for example, restores the wallet while fewer reveal nothing. BIP39 writes the secret as one phrase of 12 to 24 words. The formats use different word lists, checksums and seed derivation, so a SLIP-39 backup restores only in wallets that support it and can never become a BIP39 phrase for the same wallet. This guide compares the two, explains what the words of a share mean, walks through a 2-of-3 example, lists the wallets that restore SLIP-39 and helps you choose. For the older standard, start with what BIP39 is.
SLIP-39 vs BIP39 at a Glance
Pavol Rusnak and Marek Palatinus of SatoshiLabs co-authored both BIP39, assigned in 2013, and SLIP-39, created in 2017 and now marked Final. SLIP-39 was meant to replace BIP39, and the two are largely incompatible.
| Feature | BIP39 | SLIP-39 |
|---|---|---|
| Word list | 2,048 words, 10 official languages | 1,024 words, English only |
| Bits per word | 11 | 10 |
| Length | 12, 15, 18, 21 or 24 words | 20 words (128-bit secret) or 33 words (256-bit) per share, the two lengths the spec requires every wallet to support |
| Checksum | 4 to 8 bits inside the last word | The last 3 words (RS1024) |
| Splitting | None: one phrase | Up to 16 groups of up to 16 shares, each with a threshold |
| Wallet seed | PBKDF2-HMAC-SHA512 of the words, 2,048 iterations: 64 bytes | The master secret itself: 16 or 32 bytes |
| Passphrase | Any Unicode text | Printable ASCII only |
| Wallet support | Most wallets | Trezor and a short list of others |
A random wrong word passes the BIP39 checksum about 1 time in 16 in a 12-word phrase (1 in 256 with 24 words), while SLIP-39’s three checksum words catch any error in up to three words and miss larger errors less than once in a billion. SLIP-39 words are 4 to 8 letters long, with unique 4-letter prefixes, and 553 of them also appear on the BIP39 English list, so at a glance a share looks like a BIP39 phrase. The word count gives it away, and so does academic, the third word of every single-group share, which is not a BIP39 word.
How SLIP-39 Works
Shares, Thresholds and Groups
Shamir’s Secret Sharing stores the secret as one value of a random polynomial and hands out other values as shares: any T of them recover the secret, and fewer reveal nothing. Our cold sharding guide covers the general idea; SLIP-39 fixes the details, down to the GF(256) arithmetic, so that shares made by one wallet restore in another. Every backup has two levels:
- Member shares. A T-of-N scheme, such as 2-of-3, inside a group. A basic T-of-N backup uses a single group, as the spec recommends.
- Groups. An optional group threshold on top. In the spec’s example, any 2 of 4 groups restore the wallet: the owner holds two single-share groups, while friends form a 3-of-5 group and relatives a 2-of-6 group.
The simplest case, a single share, is a 1-of-1 scheme in one group and is used like a single recovery phrase.
What the Words in a Share Mean
A share is a string of bits cut into 10-bit words. In a 20-word share:
| Words | Content |
|---|---|
| 1–2 | Random 15-bit identifier, extendable-backup flag, iteration exponent |
| 3–4 | Group index, group threshold, group count, member index, member threshold |
| 5–17 | The share value: 128 bits plus 2 padding bits |
| 18–20 | RS1024 checksum |
In a 33-word share, words 5 to 30 hold 256 bits plus 4 padding bits. Three checks work by eye:
- Words 1 and 2 match on every share of one backup. Shares that start differently cannot be combined.
- Word 3 also matches within a group.
- A single-share backup always has academic academic as words 3 and 4: every group and member field in them is zero, and academic is word 0 of the list. Trezor points to the same marker.
Passphrase and Encryption
Before splitting, SLIP-39 encrypts the master secret with your passphrase, or an empty one, in a four-round Feistel network built on PBKDF2-HMAC-SHA256. The iteration exponent e sets the work at 10,000 × 2^e iterations; Trezor’s firmware uses e = 1, so 20,000. As with a BIP39 passphrase, nothing checks it: every passphrase decrypts to a valid-looking secret, so a typo opens an empty wallet without an error. Only printable ASCII characters (codes 32 to 126) are allowed.
Extendable Backups
A May 2024 revision of the spec added the extendable-backup flag. When it is set, the identifier no longer salts the encryption, so the same master secret and passphrase can be split again into a new set with a new identifier. Trezor has used this since June 2024: from a single-share backup you can later make a multi-share backup of the same wallet, without moving funds. The old backup stays valid and can still restore the wallet on its own, so if you retire it, destroy it only after checking the new one. Shares from two sets never combine. Extendable shares compute their checksum with the string shamir_extendable instead of shamir, so software that predates the revision rejects them.
A 2-of-3 Example
Say any two of three places should be able to restore your wallet: a home safe, a bank deposit box and a relative’s house.
- Create. The hardware wallet generates a random 128-bit secret and splits it 2-of-3 in one group. You write each of the three 20-word shares on its own card.
- Recognize. All three cards start with the same two words. Word 3 is academic on each, because there is one group; word 4 differs, carrying the card’s member number and the threshold of 2.
- Distribute. One card goes to each place. A burglar who finds the home card can neither restore the wallet nor learn the secret from it.
- Lose one. If the house burns down, the other two cards restore the wallet, entered in any order: the device checks each checksum, rebuilds the encrypted secret, verifies a digest stored in the shares and decrypts it with your passphrase. Then make a fresh set. If a card was stolen rather than destroyed, moving the funds to a new wallet is the safer fix: a new set does not revoke old cards.
- Restore elsewhere. Without the hardware wallet, any wallet with SLIP-39 support does the same; see how to restore a wallet.
The official test vectors listed in the spec show the pattern. Vector 4, a public 2-of-3 set with the passphrase TREZOR, publishes shares 1 and 3:
share 1: shadow pistol academic acid actress prayer class unknown …
share 3: shadow pistol academic always adequate wildlife fancy gross …
Here acid encodes member 1 with a threshold of 2, and always encodes member 3; the unpublished share 2 would begin shadow pistol academic agency. Together the two shares give the 16-byte master secret b43ceb7e57a0ea8766221624d01b0864. These shares are public, so never use them for real funds.
Why a SLIP-39 Backup Cannot Become a BIP39 Phrase
The standards turn words into a wallet in opposite ways. In BIP39 the words are the input: the sentence and the passphrase go through PBKDF2-HMAC-SHA512 with 2,048 iterations, and the 64-byte output is the BIP32 seed. In SLIP-39 the master secret is the seed: the spec requires wallets to use it directly as the BIP32 master seed, 16 bytes behind 20-word shares and 32 bytes behind 33-word shares. The spec spells out what follows:
- SLIP-39 to BIP39 is impossible. A BIP39 phrase always yields a 64-byte seed through a one-way function, so no phrase can be worked out from a seed, and none yields the 16- or 32-byte seed behind 20- or 33-word shares.
- BIP39 to SLIP-39 means 59-word shares. The 512-bit BIP39 seed can be split, but each share then has 59 words and only one passphrase wallet carries over. The authors, and Trezor, advise moving the funds to a new SLIP-39 wallet instead.
Splitting a phrase’s entropy rather than its seed fails too: a SLIP-39 wallet uses those bytes as the seed itself and opens a different wallet. Here it is with the public test phrase; never send funds to either address.
abandon abandon … about (public BIP39 test phrase)
entropy 00000000000000000000000000000000 (16 bytes)
BIP39 seed 5eb00bbddcf069084889a8ab91555681… (64 bytes)
m/84'/0'/0'/0/0 bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu
the same 16 bytes as a SLIP-39 master secret, empty passphrase
m/84'/0'/0'/0/0 bc1qsqs4ja3sm84vhtc7k3palld0nwga7tf47azjsq
After the seed, both kinds of wallet derive keys the same way, with BIP32 along the usual derivation paths.
Which Wallets Restore SLIP-39
Each entry was checked against the project’s own guides, release notes or source code in October 2026. Use current versions: older releases reject the extendable shares Trezor has made since mid-2024.
| Wallet | Type | SLIP-39 support |
|---|---|---|
| Trezor Safe 3, Safe 5, Safe 7, Model T | Hardware | Creates and restores single-share and multi-share backups |
| Electrum | Desktop | Restores with the SLIP39 seed type since 4.1.5, extendable shares since 4.5.5 (release notes); not in the Android app |
| Sparrow | Desktop | Restores through Mnemonic Shares (SLIP39) since 2.0.0 |
| BlueWallet | Mobile | Imports shares pasted one per line (source code) |
| Wasabi | Desktop | Creates and restores multi-share backups since 2.6.0 |
| Rabby | Browser extension, EVM | Imports SLIP 39 shares, with or without a password (source code) |
| Keystone 3 Pro | Hardware | Creates shares and imports 20- or 33-word shares |
| OneKey Pro | Hardware | Creates and restores 20-word shares since version 4.15.0 |
A BIP39-only wallet cannot restore a share: 20 and 33 are not BIP39 lengths, and nearly half of the SLIP-39 words are not on its list. Trezor, Electrum, Sparrow and Rabby also accept a SLIP-39 passphrase.
Trezor Defaults by Model
The format a Trezor gave you depends on the model and on when it was set up, according to Trezor’s guide to its backups:
| Model | Default backup | SLIP-39 |
|---|---|---|
| Model One | BIP39, 24 words | Not supported |
| Model T | BIP39, 12 words | Optional |
| Safe 3, set up before June 2024 | BIP39, 12 words | Optional |
| Safe 3, set up from June 2024 | SLIP-39 single-share, 20 words | Default |
| Safe 5, Safe 7 | SLIP-39 single-share, 20 words | Default |
Trezor Suite offers other formats in a Backup format menu during setup, and its device settings can later add new single-share or multi-share backups to a SLIP-39 wallet. A wallet with a BIP39 backup, or with a SLIP-39 one from before June 2024, needs a new wallet and a transfer instead.
SLIP-39 vs Hand-Split Words vs Multisig
Cutting a BIP39 phrase into pieces is not a safe substitute: every piece holds real words. In one hand-made 2-of-3 layout, each of three sheets holds 8 of the 12 words, so a thief with one sheet faces about 2^40, roughly 1.1 trillion, candidate phrases instead of 2^128 (see how hard guessing a phrase is). With 24 words, a sheet of 16 words leaves 2^80. SLIP-39 shares below the threshold reveal nothing, as Trezor’s FAQ also points out.
Multisig splits something else: the power to spend, not the backup.
| Aspect | Words split by hand | SLIP-39 multi-share | Multisig, e.g. 2-of-3 |
|---|---|---|---|
| One stolen part | Narrows the search | Reveals nothing | Cannot spend alone |
| One device can spend | Yes | Yes | No |
| Extra things to back up | Nothing | Nothing | The wallet descriptor: threshold and every cosigner’s public key |
| Restores in | Any BIP39 wallet | SLIP-39 wallets | Multisig-capable wallets |
SLIP-39 protects the backup; multisig also protects spending. They combine, too: a SLIP-39 backup can secure one multisig key, as Trezor notes.
When to Choose Which
- BIP39 for the widest wallet support, when one phrase in one safe place is enough; add a passphrase in case someone finds the words. A working BIP39 wallet needs no migration unless you want shares.
- SLIP-39 single-share if your Trezor creates it by default. It backs up like one phrase, has the stronger checksum and can be re-split into shares later without moving funds, but fewer wallets restore it.
- SLIP-39 multi-share if no single place should be able to lose or leak the wallet, or for inheritance, where heirs together hold enough shares. Record the threshold and which wallet made the shares.
- Multisig for large holdings where no single device should be able to spend, if you can manage several devices and their backups.
- Never split a BIP39 phrase by hand.
Store each share like a seed phrase: offline, on paper or metal, never photographed or typed into a website; see how to store a seed phrase.
Frequently Asked Questions
Can I restore a Trezor 20-word backup in a BIP39 wallet?
No. A 20-word SLIP-39 share is not a BIP39 phrase and cannot be converted into one. Restore it on a Trezor or in another wallet from the table above.
Is a 20-word share more secure than a 12-word phrase?
It holds the same 128 bits of secret. The extra words carry the identifier, the share settings and a stronger checksum. A 33-word share holds 256 bits, like a 24-word phrase; see 12 vs 24 words for what the extra bits buy.
What if I lose more shares than the threshold allows?
The backup can no longer restore the wallet. If the device still works, move the funds to a new wallet with a new backup right away.
Does each share need its own passphrase?
No. The passphrase applies to the secret the shares rebuild, not to any single share, so one passphrase covers the whole set; a wrong one opens a different, empty wallet.