MPC vs Multisig vs Threshold Signatures: Bitcoin Custody Showdown

Securing Bitcoin is fundamentally a key management problem. Whether you hold 0.01 BTC or 10,000 BTC, the same question applies: who controls the keys, and what happens when something goes wrong? Three distinct architectures have emerged to answer this question: traditional multisig, MPC key sharding, and threshold signatures like FROST. Each makes different tradeoffs across security, privacy, transaction cost, and operational complexity.

This article provides a deep technical comparison of all three approaches: how they work at the protocol level, what they reveal on-chain, how they handle key rotation and failure, and which use cases each one fits best.

How Traditional Multisig Works

Bitcoin's native OP_CHECKMULTISIG opcode (available since 2012) creates m-of-n spending conditions directly in Bitcoin Script. A 2-of-3 multisig, for example, requires any two of three designated keys to sign before funds can move. The spending policy is enforced on-chain by every full node: no trust in any external party is required.

Three address formats support multisig, each with different on-chain characteristics:

• P2SH (Pay-to-Script-Hash): the legacy format, available since 2012. The redeem script is hashed in the output and revealed in full at spend time.
• P2WSH (Pay-to-Witness-Script-Hash): the SegWit format, activated in 2017. Moves script and signatures to the witness, reducing fees by roughly 40% compared to P2SH through the witness discount.
• P2TR script-path: uses Taproot's Merkle tree of scripts. Only the executed branch is revealed at spend time, hiding unused spending conditions.

The OP_CHECKMULTISIG bug: Due to an off-by-one error in Satoshi's original implementation, OP_CHECKMULTISIG consumes one extra stack element that it never uses. Every multisig transaction must include a dummy OP_0 element to compensate. Since BIP 147 (enforced with SegWit), this dummy must be exactly OP_0 to prevent malleability. Tapscript (BIP 342) eliminated this bug entirely by replacing OP_CHECKMULTISIG with OP_CHECKSIGADD.

What multisig reveals on-chain

The critical privacy limitation of traditional multisig: when spending from a P2SH or P2WSH output, the transaction permanently exposes the m-of-n threshold, all public keys in the script, and which keys actually signed. Chain analysis firms use these fingerprints to identify custody providers, cluster addresses, and estimate wallet balances. Unchained, Casa, and BitGo wallets are all identifiable through their distinctive multisig configurations.

P2TR script-path spends improve on this by revealing only the executed script leaf and its Merkle proof, hiding other spending conditions. But the fact that a script-path (rather than key-path) was taken is itself visible, signaling that the cooperative spending path was unavailable.

How MPC Wallets Work

Multi-Party Computation (MPC) takes a fundamentally different approach. Instead of encoding the spending policy in Bitcoin Script, MPC operates at the cryptographic layer: multiple parties jointly compute a single ECDSA signature without ever assembling the complete private key. The on-chain result is indistinguishable from a standard single-sig transaction.

MPC-TSS (Threshold Signature Schemes) should not be confused with Shamir Secret Sharing. In Shamir's scheme, shares must be recombined on a single device to reconstruct the private key, creating a vulnerability at the moment of reconstruction. In MPC-TSS, the full key never exists anywhere: each party uses their share to compute a partial result, and the partial results combine into a valid signature through cryptographic protocols involving Paillier homomorphic encryption and zero-knowledge proofs.

MPC protocol evolution

The field has progressed through several generations, each fixing vulnerabilities in the previous one:

GG18 and GG20 share a critical vulnerability: they lack zero-knowledge range proofs on the Multiplicative-to-Additive (MtA) sub-protocol parameters. This gap led to CVE-2023-33241 (BitForge), where a corrupted party could construct a malicious Paillier modulus composed of small primes and extract the full signing key in as few as 16 signatures. Over 15 wallet providers were affected, including implementations used by Binance and BitGo. CGGMP21 addresses this with comprehensive zero-knowledge proofs, making it the only protocol in this lineage with no known vulnerabilities as of mid-2026.

Who uses what

ZenGo uses a 2-of-2 scheme based on the Lindell17 two-party protocol, with one share on the user's device and one on ZenGo's servers. Fireblocks serves over 2,400 institutional clients using their MPC-CMP protocol in 3-of-3 or 2-of-3 configurations. Coinbase's Wallet-as-a-Service (WaaS) also uses Lindell17 for 2-party embedded wallets. Each produces standard ECDSA signatures that look identical to single-sig transactions on-chain.

How Threshold Signatures Work

FROST (Flexible Round-Optimized Schnorr Threshold signatures), published by Chelsea Komlo and Ian Goldberg in 2020 and formalized as RFC 9591 in June 2024, represents a third approach. Like MPC, FROST enables t-of-n threshold signing where any t participants can produce a valid signature. Unlike MPC for ECDSA, FROST operates on Schnorr signatures, exploiting their algebraic linearity to produce dramatically simpler and more efficient protocols.

The signing protocol requires just two rounds. In Round 1 (commitment), each participant generates a random nonce pair and broadcasts commitments. In Round 2 (signing), each participant computes a partial signature using their key share, nonce, and the message. Partial signatures are aggregated via Lagrange interpolation into a single valid 64-byte BIP-340 Schnorr signature. The complete private key never exists in any single location.

Why Schnorr changes everything: ECDSA lacks algebraic linearity, which is why MPC protocols for ECDSA require complex sub-protocols involving Paillier encryption and multiple communication rounds. Schnorr's linearity means partial signatures can be combined through simple addition: the math is fundamentally simpler, the implementations are smaller, and the security proofs are stronger.

FROST vs MuSig2

MuSig2 (BIP-327, status "Deployed") is a closely related protocol, but it supports only n-of-n aggregation: all signers must participate in every signing session. FROST generalizes this to t-of-n, meaning n-t signers can be offline and signing still succeeds. Both produce standard 64-byte BIP-340 Schnorr signatures that are completely indistinguishable from single-sig transactions on-chain.

For Bitcoin specifically, FROST standardization is progressing through BIP-445 (draft, assigned January 2026), which specifies the FROST3 variant compatible with BIP-340 and BIP-341 Taproot key tweaking. A companion draft, ChillDKG by Blockstream Research, handles distributed key generation. Together, these two BIPs provide a complete standardized stack for FROST on Bitcoin.

On-Chain Footprint Comparison

Transaction size directly determines fees. The differences between these approaches are substantial, particularly for multisig configurations with higher thresholds. All figures below are per-input virtual bytes, verified against the Bitcoin Optech transaction size calculator and Murch's authoritative P2TR multisig analysis.

The gap widens dramatically with higher thresholds. A 3-of-5 P2WSH multisig spend requires roughly 350 vB per input. A 3-of-5 FROST spend via P2TR key-path still costs just 57.5 vB: a roughly 80% reduction in fees. Even a hypothetical 100-of-200 FROST threshold produces the same 57.5 vB input, because only the final aggregated signature appears on-chain.

MPC wallets using ECDSA typically produce P2WPKH outputs (68 vB per input). With the shift toward Schnorr-compatible MPC protocols (like Coinbase's cb-mpc library, which includes BIP-340 Schnorr signing), MPC providers can also target P2TR key-path spends at 57.5 vB.

Privacy Analysis

On-chain privacy determines how much information an observer can learn about your custody setup by examining the blockchain.

Traditional multisig: transparent by design

When spending from P2SH or P2WSH multisig, the transaction permanently reveals the threshold configuration, all public keys, and which keys signed. Chain analysis firms use this data to fingerprint specific custody providers: a 2-of-3 P2WSH configuration where one key consistently appears across many wallets likely identifies a collaborative custody service. The common-input-ownership heuristic further strengthens clustering when multisig wallets consolidate UTXOs.

Additionally, sharing extended public keys (xpubs) with cosigners during setup enables those parties to derive all wallet addresses and scan the blockchain for the wallet's full transaction history. Block's Chain Code Delegation proposal addresses this by withholding chain codes and sharing only the minimal information necessary for each signing session.

MPC and FROST: privacy through indistinguishability

Both MPC (ECDSA) and FROST (Schnorr) produce single signatures that are indistinguishable from standard single-key transactions. No observer can determine whether a transaction was signed by one person or by fifty parties running a distributed protocol. This eliminates custody fingerprinting entirely: an exchange using 3-of-5 FROST looks identical on-chain to an individual spending from a personal wallet.

The difference between MPC and FROST here is minimal. MPC produces standard ECDSA signatures (P2WPKH or P2PKH), while FROST produces Schnorr signatures (P2TR). Both achieve the same privacy outcome. However, as Taproot adoption grows and P2TR becomes the dominant address type, FROST transactions will blend into a larger anonymity set than MPC's ECDSA-based transactions, since P2WPKH and P2TR are distinguishable address formats.

Key Rotation and Management

Key rotation is one of the starkest operational differences between these approaches. In Bitcoin's UTXO model, spending conditions are permanently committed into the scriptPubKey at the moment a UTXO is created. There is no mechanism to alter these conditions retroactively.

Multisig: expensive and visible

Rotating a key in traditional multisig requires creating an entirely new redeem script (which produces a new address) and sweeping all funds from the old address to the new one via an on-chain transaction. For a 2-of-3 setup, each input in the sweep requires two signatures from the current keyholders, adding roughly 104 vB per input in fees. The sweep also consolidates UTXOs, which can reveal total holdings and link previously separate addresses to the same entity.

Collaborative custody providers like Unchained recommend performing key rotations during low-fee periods to minimize costs. But the operational burden goes beyond fees: all required cosigners must coordinate, potentially across geographically distributed locations, and the process involves generating new keys on hardware wallets, testing with a small transaction, sweeping all funds, waiting for confirmations, and updating all documentation and exchange whitelists.

MPC and FROST: off-chain refresh

Both MPC and FROST support off-chain key share refresh through proactive secret sharing. Participants run a cryptographic protocol that generates entirely new key shares for the same underlying public key: no on-chain transaction, no fees, no address change. Old shares become mathematically useless after refresh, meaning an attacker who compromised a share before refresh and another share after refresh still cannot reconstruct the key.

FROST goes further: through resharing protocols, you can change the threshold (for example, from 2-of-3 to 3-of-5), add new participants, or remove departing ones, all without changing the group public key or requiring any on-chain activity. Frostsnap, the first FROST hardware wallet (shipping since 2025), specifically highlights this capability: users can add new signing devices and render stolen hardware wallets incompatible without on-chain transactions.

Failure Modes and Security

Each approach has different failure characteristics. Understanding these is critical for choosing the right architecture.

Traditional multisig failure modes

Multisig offers a straightforward redundancy model. In a 2-of-3 setup, losing one key still allows spending with the remaining two. Losing two keys means permanent fund loss: there is no recovery mechanism at the protocol level. The attack surface is also straightforward: an attacker must compromise m separate keys, which may be stored on different devices in different locations.

The primary weakness is not cryptographic but operational. Key management across multiple hardware wallets, multiple locations, and multiple backup procedures creates complexity that invites human error. However, the Bitcoin community has over a decade of operational experience with multisig, and the tooling (Caravan, Sparrow, Nunchuk, Electrum) is mature and well-understood.

MPC failure modes

MPC's failure modes are more subtle and have proven more dangerous in practice. The cryptographic protocols are significantly more complex than either multisig or FROST, and this complexity has repeatedly produced exploitable vulnerabilities:

• CVE-2023-33241 (BitForge): full key extraction from GG18/GG20 implementations in as few as 16 signatures, affecting over 15 providers.
• CVE-2023-33242: key extraction from Lindell17 implementations (ZenGo, Coinbase WaaS) via approximately 200 aborted signature attempts.
• TSSHOCK (August 2023): three independent attack vectors enabling key extraction in as few as 1 signature, affecting BNB Chain's tss-lib, THORChain, Axelar, and others. Verichains estimated $8 billion in total assets at risk.
• The Multichain bridge hack (July 2023): $126 million drained because all MPC key shares were controlled by a single CEO, demonstrating that MPC security guarantees are only as good as the operational separation of key shares.

Provider dependency is another concern. In 2-of-2 MPC schemes (like ZenGo), if the provider disappears, the user alone cannot sign. ZenGo mitigates this with a decentralized recovery mechanism involving an escrow provider and a law firm, but this adds additional trust assumptions. There is also no standardization across MPC implementations: each provider uses different protocols, making portability and independent verification difficult.

FROST failure modes

FROST inherits Schnorr's simpler cryptographic foundation, reducing the protocol surface area compared to ECDSA-based MPC. The primary failure modes are:

• Nonce reuse: if a signer reuses a nonce across signing sessions, their key share can be extracted. RFC 9591 and BIP-445 include safeguards, and deterministic nonce generation eliminates this risk entirely.
• Disruption attacks: standard FROST can be disrupted by malicious signers who abort during a signing session. ROAST (Robust Asynchronous Schnorr Threshold Signatures), published by Tim Ruffing at Blockstream in 2022, solves this by guaranteeing that t honest signers can always produce a valid signature even in the presence of malicious participants.
• Share loss below threshold: if more than n-t shares are lost, funds are inaccessible. However, FROST's proactive secret sharing mitigates slow attacks by invalidating compromised shares at each refresh epoch.

FROST is newer than both multisig and ECDSA-based MPC, with fewer years of production battle-testing. However, its simpler cryptographic foundations (Schnorr rather than ECDSA, no Paillier encryption) reduce the attack surface. The Zcash Foundation's FROST library (v3.0.0, April 2026) is considered stable and has been audited by NCC Group and Least Authority.

The Complete Comparison

The following table summarizes the key differences across all three approaches:

Decision Matrix by Use Case

The right custody approach depends on your specific requirements. Here is how each maps to common use cases:

Personal self-custody

For individuals securing their own Bitcoin, traditional 2-of-3 multisig remains the most proven option. The tooling is mature (Sparrow, Electrum, Nunchuk), hardware wallet support is excellent (Trezor, Ledger, Coldcard, BitBox), and the failure modes are well-understood. FROST hardware wallets like Frostsnap offer a compelling alternative with lower fees and better privacy, though the ecosystem is still young.

Institutional custody

Institutions face conflicting requirements: they need both privacy (to avoid painting a target) and auditability (for compliance). MPC has dominated this segment through providers like Fireblocks, which serves over 2,400 institutional clients. The tradeoff: vendor lock-in and reliance on complex, proprietary cryptographic protocols that have historically contained vulnerabilities. FROST offers a potential alternative with simpler cryptography and emerging standardization, though institutional tooling is still developing.

Exchange hot wallets

Exchanges need high signing throughput, low latency, and the flexibility to rotate keys without on-chain transactions. MPC-CMP (with 1-round signing after preprocessing) and FROST (with 2-round signing) both fit well. Traditional multisig is less suitable due to its higher on-chain costs at scale and the inability to rotate keys without sweeping funds.

Protocol-level key management

Layer 2 protocols, bridges, and decentralized systems need threshold signing that scales to many participants without proportional on-chain cost. FROST is the natural fit: a 11-of-15 FROST configuration produces the same 57.5 vB input as a single-sig spend. Spark, for example, uses FROST for its operator key management in a statechain model: the Spark Entity comprises multiple independent operators who collectively hold one side of a 2-of-2 signing arrangement via FROST threshold signing. Neither the user nor any single operator can spend funds alone, preserving self-custody while keeping on-chain footprint identical to single-sig.

The Convergence Trend

The boundaries between these three approaches are blurring. Several trends are driving convergence:

MPC providers are adding Schnorr support. Coinbase's open-source cb-mpc library includes both ECDSA and BIP-340 Schnorr signing. Fireblocks announced MPC-BAM in December 2024, optimized for embedded wallet use cases. As these providers adopt Schnorr, the distinction between "MPC wallet" and "threshold signature wallet" narrows: both will produce identical P2TR key-path spends.

Traditional multisig providers are moving toward key aggregation. Nunchuk launched Taproot multisig in beta using MuSig2 (BIP-327), making cooperative spends indistinguishable from single-sig. BitGo adopted MuSig2 for its Taproot multisig wallet, reporting roughly 30% lower transaction fees versus P2WSH multisig. Ledger added MuSig2 support in April 2025.

FROST standardization is maturing. BIP-445 reached v0.6.0 in June 2026 with expanded test vectors. ChillDKG provides the missing distributed key generation piece. The Zcash Foundation's FROST library hit stable v3.0.0 with a dedicated frost-secp256k1-tr crate for Bitcoin Taproot compatibility.

The likely endpoint: threshold Schnorr signatures (FROST) become the default for new Bitcoin custody implementations, while ECDSA-based MPC persists for multi-chain use cases where Schnorr is not available. Traditional script-based multisig will remain for users who value on-chain auditability and the simplicity of proven, battle-tested technology.

Getting Started

If you are evaluating custody approaches for a Bitcoin application, the choice depends on what you are building. For consumer wallets prioritizing simplicity and privacy, General Bread is an example of a Spark-powered wallet that uses FROST threshold signatures under the hood while presenting a simple self-custodial experience to users. For developers building on Spark, the Spark SDK documentation covers integration with the protocol's FROST-based signing infrastructure. For a deeper comparison of how different Bitcoin Layer 2s handle custody and trust models, see our Bitcoin L2 trust model comparison.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.