A Multisig Nobody Can See: Taproot, MuSig2 and the Custody Trade-offs

Maciej Lewandowski · August 2026 · Field notes from custody & wallet infrastructure

Institutional Bitcoin custody runs on multisig, and multisig has a dirty secret: the moment you spend, the chain publishes your security architecture. Taproot changed that. An m-of-n can now spend looking exactly like a single key, at single-key cost, with the recovery paths tucked away where nobody sees them unless they fire. Whether you should want that is a genuinely interesting question, and the answer is not always yes.

What a classic P2WSH multisig confesses

A 2-of-3 wrapped in P2WSH keeps its script hidden exactly until the first spend. Then the witness lays it all out: the full redeem script, all three public keys, the threshold, the two signatures that satisfied it. Every future output paying the same script is now trivially recognizable, and even without address reuse the spend itself is a template.

Chain analytics firms live off this. The script structure, the key count, the threshold and the signature ordering form a fingerprint; combine it with timing and amount patterns and your "anonymous" treasury wallet is a labeled cluster in somebody's dashboard within a week of going live. Counterparties can watch your cold storage drain in real time. Competitors can estimate your flows. None of this requires breaking anything; you published it.

You also pay for the privilege. Every key in the script is bytes, every signature is bytes, and bytes are money at spend time. A 2-of-3 witness is several times the size of a single-sig witness, and a 3-of-5 is worse. Fees scale with the size of your quorum, which means your security posture has a per-transaction price tag.

Taproot and MuSig2: n keys, one signature

Taproot (BIP 341) plus Schnorr signatures (BIP 340) rebuilt the deal. Schnorr signatures are linear, which allows something ECDSA never could: key aggregation. With MuSig2 (BIP 327), n cosigners combine their public keys off-chain into a single aggregate key, and that one key is what goes on chain in a P2TR output. Nobody looking at the address can tell it is a multisig. Nobody looking at the spend can either.

Signing is a two-round interactive protocol: a nonce exchange round, then a partial signature round. The partial signatures combine into one ordinary 64-byte Schnorr signature. On chain it is indistinguishable from a hardware wallet in someone's desk drawer. It is also the cheapest possible spend: one key, one signature, regardless of whether two people or twelve stood behind it. The fee no longer depends on the size of your quorum. That sentence alone justifies the migration analysis.

The script tree is the other half of the design. A P2TR output commits to an optional tree of alternative spending scripts behind the aggregate key. This is where custody recovery paths live: a timelocked 2-of-3 with backup keys that activates after six months of inactivity, an emergency path to a disaster-recovery quorum, whatever your policy demands. In the happy path, none of it is ever revealed. Spend through the key path for years and the chain shows a boring single-sig wallet. Only if a fallback path actually fires does that one branch become public, and even then only that branch, not its siblings.

P2WSH publishes your entire security model on first spend. Taproot publishes nothing in the happy path and one branch in the unhappy one. Your on-chain footprint becomes proportional to how bad your day was.
on the wire what any observer learns P2WSH 2-of-3 spend script + 3 pubkeys + 2 sigs your quorum, your key count, your policy: all public forever Taproot key path one 64-byte signature one key spent one output: identical to any single-sig wallet

The fine print: MuSig2 in operations

Now the part the conference talks skim. MuSig2 is interactive, and both rounds need the signers. For a hot wallet with online HSMs that is a non-event. For cold storage it is a real architectural constraint: a key ceremony that used to be "carry a PSBT into the vault, sign, carry it out" becomes two round trips, or a session where the cold signer stays engaged across both rounds. Air-gapped workflows that were designed around one-shot signing need redesign, not adaptation.

Then there are the nonces. MuSig2 security leans hard on nonce discipline: a nonce must never be reused, and pre-generated nonces must never be copied, restored from backup, or replayed after a crash. Reuse can leak the private key, not weaken it, leak it. A signer that snapshots its state and restores it after a failure is a signer that can be tricked into signing twice with the same nonce. Nonce state must be treated like the key itself: generated fresh, used once, destroyed, with crash recovery that fails closed. This is solvable, but it is a new class of bug your old multisig simply did not have.

It is worth knowing where MuSig2 stops. It is an n-of-n scheme: every aggregated key must sign. You build thresholds on top of it with the script tree, one leaf per acceptable quorum combination. FROST-style threshold schemes attack the problem differently, producing a true m-of-n under a single aggregate key, at the cost of a more involved key generation ceremony and a younger standardization story. The conceptual trade is maturity and simplicity versus native thresholds. Most custody designs today get comfortably far with MuSig2 for the primary quorum and tree leaves for the fallbacks.

MPC: the third door

Threshold MPC signing (TSS) reaches the same on-chain destination by a different road: the private key never exists anywhere in full, key shares jointly compute one ordinary signature, and the chain sees a plain single-sig spend. No Bitcoin script at all. The pitch is real: one signing stack across every chain you support, because the quorum logic lives in your protocol rather than in any chain's script system.

The trade-off deserves to be stated plainly. With script multisig, Bitcoin consensus enforces your quorum: a 2-of-3 spend with one signature is invalid on every node on the planet, and no bug in your infrastructure changes that. With MPC, the quorum is enforced by your protocol implementation and your operational controls. If the implementation has a flaw, the chain will happily accept the resulting signature, because to the chain it is just a signature. Auditors notice this immediately: the property "the chain itself enforces the quorum" is gone, replaced by "trust our cryptographers and our change management". That can be an acceptable trade. It is never a free one.

Coordination looks the same from the inside

Whatever the signature scheme, the plumbing barely changes. Descriptor wallets describe what you are watching: wsh(sortedmulti(2,keyA,keyB,keyC)) for the classic setup, tr(...) descriptors for Taproot. Descriptors make the wallet reproducible from configuration, which is exactly what a disaster-recovery runbook wants.

PSBT (BIP 174) remains the transport: one coordinator builds the proposal, signers attach partial signatures or MuSig2 protocol data, someone combines, finalizes, broadcasts. Proposal, partial signatures, combine, finalize, broadcast; the pipeline is the same whether the witness ends up as three signatures or one. If your custody stack already speaks PSBT well, most of a Taproot migration is key management and ceremony design, not plumbing.

Choosing: privacy, cost, auditability

  • P2WSH multisig when your auditor or regulator wants the quorum visible and consensus-enforced, and you will pay the fee and privacy cost for the strongest possible "the chain checks our policy" story.
  • Taproot with MuSig2 when privacy and fees matter, your signers can be online for two rounds, and you can hold the nonce discipline. Recovery paths in the tree, invisible until needed.
  • MPC when breadth across chains matters more than script-level enforcement, and you accept that the quorum lives in your implementation rather than in consensus.
Privacy, cost, auditability - pick the two that match your threat model. The third one is what you will be explaining in the design review.

Checklist before you migrate

  1. Write down who is allowed to learn your quorum structure from the chain. That single answer eliminates at least one of the three options.
  2. Model the fee difference at your real spend volume; quorum-sized witnesses versus one signature compounds fast.
  3. Test the two-round MuSig2 ceremony against your actual cold storage process, not the whiteboard version of it.
  4. Treat nonce state as key material: fresh, single-use, destroyed, crash recovery fails closed. Test the crash path deliberately.
  5. Put every recovery and fallback quorum in the script tree with explicit timelocks, and rehearse spending through one.
  6. Keep everything descriptor-defined and PSBT-transported so the wallet is reproducible from configuration alone.
  7. Brief the auditors before the migration, not after; "invisible multisig" is a feature to you and a finding to them until it is explained.

The chain used to force custody to choose between security and silence. Taproot means you can have both, if your operations are disciplined enough to hold the protocol's assumptions. The signature got smaller. The engineering did not.