TL;DR
A hardware wallet only knows its own key. To check that a multisig address or a change output really belongs to your wallet, it needs all three keys and the 2-of-3 rule. Registering the multisig gives it that, once, after you confirm it on its screen. The BitBox02, Jade, Keystone and Coldcard store it; the Ledger approves it and Sparrow keeps the proof; the Trezor stores nothing and takes whatever Sparrow sends.
The first time you show an address on a BitBox02 or a Ledger, it asks you to register the multisig. It looks like a formality. It’s actually the step that lets the device protect you from a tampered computer. Here’s why it exists, how each device handles it, and what it means when you rebuild a wallet.
Why a device needs the whole multisig
A 2-of-3 address is built from three public keys plus the rule “two signatures needed”. Each hardware wallet holds one seed, so it only knows one of those keys. Without the other two it can’t calculate your address. It has to get them from somewhere, and in a normal session that somewhere is Sparrow, on a computer that could be compromised (see what is a wallet descriptor).
Two things depend on it:
- Receive addresses. A tampered computer could swap one of your keys for an attacker’s key. The address still contains your device’s key, so a device that doesn’t know the full setup would happily show it. Coins sent there might need the attacker’s key to move, or be spendable by the attacker alone if two keys were swapped.
- Change. When you send, the leftover usually goes back to a new address in your own wallet. The device only knows that output is really yours if it knows the full setup. Otherwise change could quietly go to a multisig with someone else’s keys in it.
Registration solves this. The device shows you the setup once: the wallet name, the 2-of-3 rule and the three keys with their fingerprints. You compare the fingerprints with your notes and approve. From then on, the device checks every address and every change output against that approved setup, not against whatever the computer says.
How each device handles it
| Device | Where the setup lives | Address check |
|---|---|---|
| BitBox02 | On the device, under the name you confirm. It shows “Multisig account registered” | Strong, against the stored setup |
| Ledger (Bitcoin app 2.1+) | Nowhere on the device. Sparrow keeps a 32-byte proof (HMAC) in the wallet file | Strong, once you approved the setup |
| Trezor | Nowhere. Sparrow sends the full setup with every request | Extra check only |
| Blockstream Jade | On the device, up to eight multisig setups | Strong; also checks change when signing |
| Keystone 3 Pro | On the device, after you import the setup from Sparrow | Strong, once imported |
| Coldcard | On the device, up to eight M-of-3 setups | Strong, once imported |
The guide uses a BitBox02, a Ledger Nano S Plus and a Trezor Safe 5. I haven’t used the Jade, the Keystone or the Coldcard in this setup myself: those rows follow the makers’ own documentation, checked October 2026. Details for each are on their own pages: Jade, Keystone, Coldcard. If you use a Coldcard, first read the July 30, 2026 weak-seed incident on security alerts: seeds made on affected firmware should be replaced.
The Ledger: a proof instead of a list
Ledger’s Bitcoin app is stateless: its own developer documentation says a registered policy is not stored on the device. When you approve a registration, the Ledger returns a 32-byte HMAC, a code calculated from your seed that covers that exact setup, name included. Sparrow saves it in the wallet file and sends it along with every later address or signing request. A setup with a swapped key doesn’t match the code, so the Ledger refuses it without a fresh approval on its screen. More in Ledger multisig with Sparrow.
Because the code is derived from the seed, a registration can’t be revoked on the device. It also means that a Ledger restored from the same seed still accepts the proof in your existing wallet file.
The Trezor: a fresh setup every time
Trezor’s communication protocol has a multisig field in every request to show an address or sign. Sparrow fills it each time and the Trezor uses what it receives. When signing, it treats an output as change only if it has the same multisig setup as the coins being spent, but that setup also came from the computer. So a matching address on the Trezor proves the address fits the setup it was sent, not that the setup is yours. That’s why the guide uses it as an extra check. Details in Trezor multisig with Sparrow.
What this means for a tampered computer
Once the BitBox02 and the Ledger know your setup, malware on the signing laptop can still show a false address in Sparrow, but it can’t make those two devices agree with it. That’s the whole idea behind step 8: check addresses on a registered device, every character. And whichever two devices you sign with, at least one is the BitBox02 or the Ledger, so change is checked too.
The one way around it is a new registration. Malware can ask a device to register a different setup. The device then shows that setup and waits for you. That screen is your defense, so treat it seriously.
Unexpected registration prompt? Stop
If a device asks to register a wallet when you haven’t built, rebuilt or renamed one, don’t approve it. Compare every fingerprint with your notes. A key you don’t recognize means the computer is sending a setup that isn’t yours. Follow signing laptop broken or infected.
Rebuilding a wallet
Sooner or later you’ll rebuild the wallet from your descriptor: on a new laptop, after a reinstall, or in the recovery rehearsal. What happens with each device:
- Ledger: the new wallet file has no proof, so you register again and check the three keys again. Renaming the wallet in Sparrow has the same effect, because the name is part of the proof.
- BitBox02, Jade, Keystone, Coldcard: the setup is on the device, so they recognize the same wallet. Wipe and restore one of them from its seed and you register or import again.
- Trezor: nothing changes. There was never anything to register.
A rebuilt wallet with a wrong path or script type is a different wallet. A registered device will show different addresses, which is exactly the warning you want. Don’t send anything until they match.
BSMS (BIP129) in brief
Registration is about the device. BIP129, Bitcoin Secure Multisig Setup or BSMS, is about getting the setup to every device safely in the first place. It was written by people from Nunchuk, Coinkite (Coldcard) and Shift Crypto (BitBox). A coordinator collects a signed key record from each signer and sends back a descriptor record with the full setup and the first address. Each signer checks that its own key is in it and stores it.
With Sparrow and three USB devices you don’t need it: registering on the BitBox02 and the Ledger does the job. Sparrow can export and import BSMS files, and Nunchuk saves your wallet as a BSMS file, which is handy when you recover in another app. A BSMS file describes the same wallet as your descriptor.
Common mistakes
- Approving a registration without comparing the three fingerprints with your notes.
- Treating a matching address on the Trezor as proof. It only matches what the computer sent.
- Deleting or losing the Sparrow wallet file and then being surprised the Ledger asks again. That’s normal; check the keys and approve.
- Skipping registration on the Ledger, then wondering why it refuses to sign (address doesn’t match the device covers the related problems).