1. Home
  2. / Blog
  3. / BIP Standards
  4. / SLIP-39 vs BIP39: Shamir Backup Explained
BIP Standards Published

SLIP-39 vs BIP39: Shamir Backup Explained

#slip39#shamir backup#bip39#trezor#seed phrase
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.

FeatureBIP39SLIP-39
Word list2,048 words, 10 official languages1,024 words, English only
Bits per word1110
Length12, 15, 18, 21 or 24 words20 words (128-bit secret) or 33 words (256-bit) per share, the two lengths the spec requires every wallet to support
Checksum4 to 8 bits inside the last wordThe last 3 words (RS1024)
SplittingNone: one phraseUp to 16 groups of up to 16 shares, each with a threshold
Wallet seedPBKDF2-HMAC-SHA512 of the words, 2,048 iterations: 64 bytesThe master secret itself: 16 or 32 bytes
PassphraseAny Unicode textPrintable ASCII only
Wallet supportMost walletsTrezor 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:

WordsContent
1–2Random 15-bit identifier, extendable-backup flag, iteration exponent
3–4Group index, group threshold, group count, member index, member threshold
5–17The share value: 128 bits plus 2 padding bits
18–20RS1024 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

WalletTypeSLIP-39 support
Trezor Safe 3, Safe 5, Safe 7, Model THardwareCreates and restores single-share and multi-share backups
ElectrumDesktopRestores with the SLIP39 seed type since 4.1.5, extendable shares since 4.5.5 (release notes); not in the Android app
SparrowDesktopRestores through Mnemonic Shares (SLIP39) since 2.0.0
BlueWalletMobileImports shares pasted one per line (source code)
WasabiDesktopCreates and restores multi-share backups since 2.6.0
RabbyBrowser extension, EVMImports SLIP 39 shares, with or without a password (source code)
Keystone 3 ProHardwareCreates shares and imports 20- or 33-word shares
OneKey ProHardwareCreates 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:

ModelDefault backupSLIP-39
Model OneBIP39, 24 wordsNot supported
Model TBIP39, 12 wordsOptional
Safe 3, set up before June 2024BIP39, 12 wordsOptional
Safe 3, set up from June 2024SLIP-39 single-share, 20 wordsDefault
Safe 5, Safe 7SLIP-39 single-share, 20 wordsDefault

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.

AspectWords split by handSLIP-39 multi-shareMultisig, e.g. 2-of-3
One stolen partNarrows the searchReveals nothingCannot spend alone
One device can spendYesYesNo
Extra things to back upNothingNothingThe wallet descriptor: threshold and every cosigner’s public key
Restores inAny BIP39 walletSLIP-39 walletsMultisig-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.