TL;DR
Taproot can make a multisig look like an ordinary single-sig wallet on the blockchain, and spend for about the same fee. MuSig2 does that for n-of-n; a 2-of-3 needs extra script paths, or FROST, which isn’t a finished standard yet. As of October 2026, Sparrow can’t create a taproot multisig and Trezor’s firmware doesn’t list it, so the setup guide stays on Native SegWit (P2WSH) sortedmulti. I’ll revisit when all my tools support it.
Taproot has been part of Bitcoin for years, and people keep asking whether a new multisig should use it. The short answer is: not yet, for this setup. Here’s what taproot multisig actually is, what it would improve, and where support stands.
What taproot changes
A taproot output (address type P2TR, starting with bc1p) can be spent in two ways:
- Key path: one public key, one signature. On the blockchain it looks like any other single-sig taproot payment.
- Script path: a tree of hidden alternative scripts. Only the one you actually use is revealed when you spend.
There are three ways to build a multisig on top of that.
1. Script-path multisig (multi_a)
A normal multisig script, written for taproot, goes in a leaf of the script tree. The descriptor uses sortedmulti_a instead of sortedmulti (BIP387). It works and it’s simple, but when you spend, everyone can see it was a multisig, just like today. The fee is in the same range as P2WSH, because two signatures and the script still go on-chain.
2. MuSig2 (BIP327)
MuSig2 lets several keys combine into one public key and produce one joint signature. The result is indistinguishable from a single-signer taproot payment, and it’s the smallest possible spend. The catch is in the standard itself: MuSig2 is n-of-n, not a threshold scheme. Every key in the group has to sign.
For a 2-of-3 you need a combination: put one pair of keys (say A+B) on the key path as a MuSig2 key, and the other pairs (A+C, B+C) in the script tree. Spending with your usual pair is private and cheap; spending with another pair reveals that leaf. Nunchuk built its taproot multisig this way. Signing takes two rounds of communication between the devices instead of one, which makes it slower to coordinate.
3. FROST
FROST is a threshold signature scheme: any 2 of 3 keys could produce one ordinary-looking signature. It’s the closest thing to the ideal, but as of October 2026 there’s no FROST standard in the official list of Bitcoin BIPs, and none of the wallets or devices in this guide support it. Key creation is also interactive: the devices have to work together to make the keys, which changes how backups work.
What you’d gain
- Privacy: a key-path spend doesn’t reveal that your coins sit in a multisig. Today a P2WSH spend does, which tells observers there may be more.
- Fees: one 64-byte signature instead of two signatures plus a script with three public keys. For savings you move a few times a year, the current extra cost is already modest, so this matters less than privacy.
Support as of October 2026
| Tool | Taproot multisig (script path) | MuSig2 |
|---|---|---|
| Sparrow 2.5.5 | No: taproot is single-sig only | No |
| Ledger Bitcoin app | Yes, since 2.1.2 (2023) | Yes, since 2.4.0 (March 2025) |
| BitBox02 | Yes, taproot wallet policies since firmware 9.21.0 | Not in the firmware changelog |
| Trezor | Not in the firmware changelog | Not in the firmware changelog |
| Nunchuk | Yes, as a beta (December 2024) | Yes, beta; software keys only at launch |
I checked Sparrow’s source code and release notes: its taproot script type only allows single-sig wallets, and version 2.5.5 (September 17, 2026) rejects taproot descriptors that contain a script tree. For Trezor I went through the firmware changelog up to 2.12.5 (September 16, 2026) and found taproot single-sig, but no taproot multisig or MuSig2. Nunchuk announced its taproot multisig as a beta, recommended small amounts only, and didn’t support hardware wallets for it at launch. I couldn’t confirm whether that has changed since.
Why the setup guide still uses P2WSH sortedmulti
- It works with all three devices and Sparrow, today. The BitBox02 and the Ledger register the multisig and show the full address; the Trezor signs what Sparrow sends.
- It’s been the standard multisig for years. Many wallets can open a
wsh(sortedmulti(…))descriptor, so a recovery doesn’t depend on one app. - MuSig2 descriptors (
musig(), BIP390) are still a draft standard, and fewer tools can recover such a wallet. - The gain is mainly privacy, and the price is newer, less tested code in exactly the place where a bug costs the most.
For three different brands, which is the whole point of this setup, all three have to support the same taproot multisig. That isn’t the case yet.
If you want to switch later
You can’t convert an existing multisig to taproot. Like changing the quorum, it means building a new wallet with a new descriptor, testing it, and moving the coins over. The addresses and the descriptor backup all change. When support is there across the board, I’ll say so on this page.
Common mistakes
- Assuming a bc1p address in Sparrow is a multisig. In Sparrow it’s always single-sig.
- Moving savings into a beta taproot multisig because it’s cheaper. The fee difference is small; the risk isn’t.
- Forgetting the descriptor. With taproot and MuSig2 it’s even more essential, because the script tree can’t be guessed.