Wallet Backup Standards: SLIP-39 and BIP-39

There are two standards for backing up a wallet, and either one can carry a passphrase. This guide is the doing: how to create each on a Trezor, how to add the passphrase that stacks on both, and — for experts — the command-line path to the 33-word shares that Trezor Suite doesn’t offer. Everything here is universal in principle; the click-paths are Trezor’s (the site’s recommended hardware), current as of mid-2026.

The Two Standards, in One Paragraph Each

24-word BIP-39 is one secret: 24 words, 256-bit strength, restorable on virtually every wallet ever made. Its weakness is that it is one secret — the copy lost to a fire was your only copy, and the copy a thief finds is the complete key. It suits a holder with a passphrase and two good storage locations.

SLIP-39 (Shamir) multi-share replaces the single secret with a threshold — say 2-of-3 shares in three places. No single fire, burglary, or seizure loses or leaks anything: below the threshold, a share reveals nothing. Its trade-offs: restores only on SLIP-39-capable wallets (Trezor Model T and Safe-series, Keystone, and select others), and Trezor Suite creates 20-word (128-bit) shares — the 33-word (256-bit) version is not offered by Trezor Suite (the expert path below uses trezorctl, Trezor’s command-line tool).

Same lock, different key-storage plans. Both standards accept a passphrase: an extra word or phrase that opens a separate, hidden wallet. The seed or shares alone open only the standard wallet.

Before You Start

Creating a backup from scratch creates a new wallet. A 12- or 24-word BIP-39 seed, or a 20-word SLIP-39 wallet made before June 2024, cannot be converted into shares: moving to shares takes a new wallet and a transfer of the funds into the new wallet. A 20-word Single-share Backup made since June 2024 (the Safe-series default) is the exception: Trezor Suite (Settings → Device → Multi-share Backup → Create) makes a Multi-share Backup of the same wallet, with the same addresses and no funds moved. The old single share still opens the wallet until the single share itself is destroyed; Trezor advises destroying the single share only after the new shares are verified to open the wallet and reach the funds. So this procedure belongs at one of three moments: a fresh device before first funding, a Single-share-to-Multi-share upgrade, or a deliberate migration. Not everything transfers in a migration: a native HEX stake is locked to the address that started it and cannot be sent, so it stays in the old wallet until it ends, and only the old seed (with its passphrase, if it has one) reaches it. A tokenized HSI moves as its NFT, sent like any token (an untokenized HSI is tokenized first, from the old wallet). A stake delegated to Actuator comes free only by retiring its HTTs first. Ending a stake before its end day in order to move the HEX costs the early-end penalty. Wiping or resetting a device that holds the only access to funds destroys that access.

Have ready: the Trezor, pen and paper (metal comes later), an hour of unhurried time, and your storage locations already decided.

Open Trezor Suite (official download: trezor.io/start; Trezor warns that phishing sites appear in web search results) and begin device setup on a new device. The Single-share-to-Multi-share upgrade involves no wipe and no setup: Settings → Device → Multi-share Backup → Create starts it, step 2’s drop-down does not appear, and steps 3–6 follow, with the same wallet and the same addresses. For a migration from a funded device, Trezor’s order is Check wallet backup on the old backup first, then Settings → Device → Danger area → Wipe device; after the wipe, the old backup is the only way back to the old wallet (see the warning above). With one Trezor, moving the funds means checking the new backup, noting the new wallet’s receiving addresses, wiping again, restoring the old backup, sending the funds to the new addresses, then wiping and restoring the new backup (Trezor’s Move crypto to a wallet with a new wallet backup).
Open the Wallet backup type drop-down and select Multi-share Backup. Suite preselects the 20-word Single-share Backup on Trezor Safe 3 (since June 2024), Safe 5 and Safe 7, so Multi-share has to be chosen. The Model One cannot make SLIP-39 backups.
Choose your scheme: how many shares exist, how many recover. 2-of-3 is the workhorse; 3-of-5 for more locations or people.
The device displays each share, one at a time — write each on its own sheet of paper. The words never touch the computer; only the device screen shows them.
Verify each share when the device prompts re-entry.
Distribute once the practice restore below has confirmed the shares: each share then goes to a different physical location, per the split-location rule. Two shares kept together are one find away from the threshold: in a 2-of-3, one drawer holding two shares is the single point of failure the scheme exists to remove.

Path B — 24-Word BIP-39 in Trezor Suite

Begin device setup as above.
Open the Wallet backup type drop-down, expand Legacy wallet backup types and select 24-word wallet backup (Suite preselects the 20-word Single-share Backup on Safe 3, Safe 5 and Safe 7, so the selection has to be changed).
Write the 24 words on paper from the device screen, verify when prompted.
Once the practice restore below has confirmed the words, store per the Seed Phrase page’s methods — metal beats paper, and two locations beat one, but remember each full copy is a complete key.

Both Paths — Now the Passphrase

The backup protects the seed’s artifacts. The passphrase protects what no artifact contains — and it works identically on top of either standard:

In Trezor Suite: Settings → Device, under Passphrase, turn on Use Passphrase wallets (Suite mobile: Device settings → Wallet backup & passphrase).
In Trezor Suite, open the wallet menu (top left) and choose + Passphrase wallet, then New passphrase the first time or Open previously used after that (Suite mobile: Open passphrase), then enter the passphrase; a new passphrase is entered twice and confirmed on the Trezor each time, and entering one opens that passphrase’s wallet. Suite offers Enter passphrase on Trezor. Typed on the device (touchscreen on Safe 5, Safe 7 and Model T, buttons on Safe 3), the passphrase never passes through the computer. Typed on a computer or phone, it is readable by any malware on that machine, and a captured passphrase plus a found seed or share threshold opens the hidden wallet. The Model One has no on-device entry. The standard (no-passphrase) wallet stays as it was; the passphrase wallet is a separate wallet with its own addresses.
Typed into anything other than the Trezor itself or the wallet’s own passphrase prompt, the passphrase goes to whoever runs that page or program. Stored digitally, it sits on machines you don’t control. Written on paper, it is lost to a flood or fire; stamped on metal, it survives them. Kept in the same place as the seed backup, it opens the hidden wallet for whoever finds both. Forgotten, it takes the hidden wallet with it: the seed alone brings back only the standard wallet.
Send a small test amount of the network’s own coin (PLS on PulseChain, ETH on Ethereum) to the first address of the passphrase wallet’s Ethereum account (the same 0x address receives on PulseChain; Suite opens a new wallet on a Bitcoin account, whose addresses are a different format, and Settings → Networks turns Ethereum on if Suite shows no Ethereum account) from a source not linked to your standard wallet (any transfer between the two, in either direction, is public on-chain and ties them together, and the same holds for every later deposit). Trezor Suite does not list PulseChain, so PLS shows in a wallet app with the Trezor connected, such as Internet Money Wallet or MetaMask; in Suite, a passphrase wallet that holds only PulseChain funds reads as empty even when the passphrase is right. Then practice unlocking it from cold, twice. Ejecting both wallets in Suite (the eject icon on each wallet card in the wallet menu, top left) and reopening through + Passphrase wallet → Open previously used is what makes the passphrase get typed; the first receiving address shown on the Trezor screen (Receive → Verify) then matches the one shown before the eject. While a wallet stays open in the wallet menu, reopening it involves no passphrase at all.

Every different passphrase opens a different, equally valid wallet — there is no error message, and no way to prove a hidden wallet exists. That property is the entire duress and seizure defense, and it cuts the other way too: the passphrase is case-sensitive, so one changed capital or a misspelling opens a different, empty wallet, with no error message. Nobody can recover a forgotten passphrase, Trezor Support included; the funds behind a lost passphrase stay out of reach for good.

The Practice Restore

A backup that has never restored anything is a hope. Before funding for real: run Suite’s Check wallet backup (Settings → Device, under Wallet backup), which tests your shares or words without erasing anything; Trezor recommends the check before any wipe. Then, for the full rehearsal, note the first receiving address of the standard wallet and of the passphrase wallet (the passphrase-wallet address on that note records that a passphrase wallet exists, which the runbook rule below keeps out of home notes, so the note lasts only until the restored addresses are confirmed), wipe the device (or use a second device), restore from your shares or words, switch the passphrase feature back on (Settings → Device, under Passphrase, Use Passphrase wallets; a restored wallet starts with it off, so Suite offers no passphrase entry until it is on), enter the passphrase, and confirm both noted addresses reappear on the Trezor screen and the test amount reappears in the connected wallet app. One dry run converts the whole plan from theory to fact — while only the test amount is at risk.

Write Yourself the Runbook

The machine you just configured will not forget any of this. You will. Returning after a year or three to repeat a procedure is where people improvise, and improvisation is where self-custody losses live. Unlike AI, humans need notes — so write them, using the design rule that makes notes safe:

Separate the choreography from the secrets. Secrets live on metal (the seed or shares, and the passphrase if it is written down), because paper is lost to a flood or fire. Everything else about your setup is procedure, and procedure is safe to write down, because procedure is what a public security guide already is. This page describes the entire architecture to strangers and endangers no one.

The test for every line: would a burglar reading it learn anything a public guide wouldn’t teach?

Safe to write: which device and standard (“Trezor, SLIP-39 2-of-3”), menu paths, the restore procedure, which accounts exist and their 2FA types, the bookmark list, revocation steps, and a dated rehearsal log (“2026-07: practice restore OK, ~40 min”).
Kept out of the runbook and home notes: seed words, the passphrase, PINs, exact share locations in plain language (share locations go only in the closed appendix below) — and, the subtle one, the existence of your passphrase wallet in notes kept at home. The estate letter must say the passphrase wallet exists (or your heirs recover only the standard wallet) — but that letter lives with your estate documents, not in your desk. Home notes instead say “restore per this guide” — a public pointer that reminds you of everything and reveals nothing personal.

Two tiers, like everything else in this architecture:

The open runbook — procedures, settings, rehearsal log, pointers to public guides. No secrets, no treasure map: it can live on your everyday computer or printed in a drawer. This is the document that rescues you after the hiatus.
The closed appendix — share locations and scheme details. One sheet, stored with your estate documents, referenced from the open runbook only by where it lives.

Last: notes decay unless rehearsed. The yearly practice run keeps the runbook truthful, and the runbook keeps the practice run at forty minutes instead of a panicked weekend. They maintain each other — schedule them together (tax season pairs well, per the inheritance guide).

The Expert Path — 33-Word Shares via the Command Line

First, the rule that gates this section: security has to be executable in a sustainable way — by you, tired, under stress, years from now. Too complicated is less safe. Most self-custody losses are self-inflicted, and a setup you can’t confidently restore is a weaker one than a simpler setup done perfectly. If the standards above fit you, they are not the lesser choice — they are the sustainable one. This path pays off only when it is rehearsed like everything else.

Trezor Suite creates 20-word (128-bit) SLIP-39 shares only. The SLIP-39 standard also defines 33-word (256-bit) shares — multi-share and maximum entropy — and Trezor Safe 3, Safe 5, Safe 7 and Model T support creating them through trezorctl, Trezor’s official command-line tool (the Model One has no SLIP-39 support).

Honest context first: Trezor’s stated position is that the elliptic-curve cryptography securing most chains targets ~128-bit security, so longer backups add no practical strength — that’s why Suite doesn’t offer this. The case for 33 words is engineering margin, not necessity: maximum headroom in the one component you’ll never rotate. Decide which argument you find persuasive; both are honest.

The procedure (per Trezor’s own guidance, January 2026):

Install trezorctl using Trezor’s official guides: Windows (which lists Trezor Suite installed and running as a prerequisite) · macOS · Linux (packages on Trezor’s trezorctl commands page, plus udev rules).
Connect a new or wiped Trezor. A new Trezor ships with no firmware: let Trezor Suite (from trezor.io/start) install the firmware and run the authenticity check, then stop at the create-wallet step. reset-device refuses a device that already holds a wallet (“Device is initialized already”); the step that erases a wallet is the wipe (Suite’s Wipe device), and after a wipe only the backup can bring that wallet back.
Run:
```
trezorctl reset-device -b shamir -t 256 -p
```
-b shamir selects SLIP-39; -t 256 sets 256-bit strength → 33-word shares (-t 128 would give Suite’s standard 20-word shares); -p sets a PIN on the device during setup.
Follow the prompts: choose shares and threshold, and the device displays each 33-word share on its own screen — same write-verify-distribute discipline as Path A.
Open Trezor Suite normally and enable the passphrase exactly as above — it stacks on this backup the same way.
Do the practice restore before funding. Suite’s recovery flow accepts 33-word shares even though its creation flow doesn’t offer them.

Sources: Trezor’s trezorctl commands page (reset-device, -b shamir, -t 256 → 33-word shares) and Trezor forum guidance (January 2026). As with any expert path: verify it yourself, end to end, on a device holding nothing — an expert is someone who tests before trusting.

Everything on this page is universal — send anyone the link — pointing people to the source beats forwarding copies (a file passed around is exactly what this site warns about; the link stays canonical and current). For the curious: this site documents Actuator.Finance on PulseChain — the one-page version is How It Works, and Start Here picks your path.