Bitcoin Threshold Signatures: FROST vs ROAST vs MuSig2

Threshold Signature Schemes for Bitcoin

Bitcoin's Taproot upgrade activated Schnorr signatures on the base layer, unlocking a new generation of threshold signature schemes that produce outputs indistinguishable from single-key spends. Three schemes dominate the landscape: FROST (flexible t-of-n threshold), ROAST (a robustness wrapper around FROST), and MuSig2 (n-of-n multi-signature). Each targets different trust models, custody architectures, and fault tolerance requirements.

The following table provides a high-level comparison across the dimensions that matter most when choosing a scheme for wallets, Layer 2 protocols, or institutional custody.

For a broader overview of Bitcoin signature schemes including legacy ECDSA and script-based multisig, see the Bitcoin signature schemes comparison.

FROST: Flexible Round-Optimized Schnorr Threshold Signatures

FROST was introduced by Chelsea Komlo and Ian Goldberg at SAC 2020 and published as RFC 9591 in June 2024. It is a true t-of-n threshold signature scheme: any t participants out of n total can produce a valid Schnorr signature without revealing the aggregate private key to any individual signer.

Signing requires two broadcast rounds (commit, then sign), reducible to one round when nonce commitments are pre-shared. Security is proven under the One-More Discrete Logarithm (OMDL) assumption in the Random Oracle Model. FROST provides identifiable aborts: if a participant submits an invalid partial signature, other signers can detect and exclude them. However, FROST alone does not guarantee that honest signers will always succeed when malicious participants actively disrupt sessions in asynchronous networks.

FROST requires an interactive distributed key generation (DKG) ceremony to establish key shares without any single party learning the full private key. The Bitcoin-specific proposal is BIP-445 (Draft, authored by Blockstream in 2026), paired with ChillDKG, a companion DKG protocol also in Draft status. The Zcash Foundation's frost Rust crate reached v1.0.0 with a full audit, making it the most mature reference implementation.

ROAST: Robust Asynchronous Schnorr Threshold Signatures

ROAST was published by Tim Ruffing and collaborators at ACM CCS 2022. It is not a new signature scheme: it is a coordination wrapper around FROST (or any semi-interactive threshold scheme with identifiable aborts). ROAST solves the robustness gap that FROST leaves open.

In FROST, a malicious signer can deliberately sabotage a signing session by sending invalid contributions or going silent mid-round. The session fails and must restart with a different signer subset. In a large federation (e.g., 67-of-100), an adversary controlling 33 signers could continuously disrupt sessions. ROAST addresses this by running multiple FROST sessions in parallel, managed by a coordinator. Each disruptive signer can block at most one session. The protocol guarantees that t honest signers will always produce a valid signature, regardless of adversarial behavior, even under fully asynchronous network conditions.

Blockstream's research prototype demonstrated ROAST completing signatures within seconds under a 67-of-100 threshold with 33 actively malicious signers distributed across continents. The primary target deployment is the Liquid Network federation, which currently uses an 11-of-15 multisig and could scale to larger federations with ROAST. As of mid-2026, ROAST remains at the research prototype stage with no widely-deployed production implementation.

MuSig2: Two-Round Multi-Signatures

MuSig2 was published by Jonas Nick, Tim Ruffing, and Yannick Seurin at CRYPTO 2021 and formalized as BIP-327, which has reached "Deployed" status. Unlike FROST, MuSig2 is strictly an n-of-n scheme: all n signers must participate in every signing session. There is no threshold flexibility.

MuSig2 requires two broadcast rounds (exchange nonces, then exchange partial signatures). Its key advantage is simplicity: key aggregation is deterministic and non-interactive, requiring no DKG ceremony. Each signer generates their own key pair independently, and the aggregate public key is computed from the set of individual public keys. This makes MuSig2 significantly easier to implement and deploy than FROST.

Security is proven under the Algebraic One-More Discrete Logarithm (AOMDL) assumption, a stronger assumption than FROST's OMDL. The tradeoff: this stronger assumption is the cost of eliminating a third round compared to earlier MuSig variants.

MuSig2 is the most production-deployed scheme of the three. Thelibsecp256k1 C library (used by Bitcoin Core) merged its MuSig2 module in October 2024. LND graduated Simple Taproot Channels with MuSig2 to production in v0.21 (June 2026). BitGo deployed MuSig2 for Taproot multisig hot wallets, reporting roughly 30% fee savings per input. Ledger added MuSig2 support in Bitcoin app v2.4.0 (April 2025).

Key Generation and Setup Complexity

The setup process is where FROST and MuSig2 diverge most sharply. MuSig2 uses non-interactive key aggregation: each signer generates a standard key pair, publishes their public key, and the aggregate key is computed deterministically. No communication rounds are needed for setup beyond sharing public keys.

FROST requires an interactive DKG protocol where all n participants exchange commitments and verify shares using Feldman's Verifiable Secret Sharing with zero-knowledge proofs. If any participant drops offline during DKG, the ceremony must restart. The ChillDKG draft specification (companion to BIP-445) standardizes this process for Bitcoin, but DKG remains the most operationally complex part of deploying FROST.

ROAST inherits FROST's DKG requirements entirely. The robustness layer only applies to signing sessions, not to key generation.

Custody Architectures Enabled

Each scheme enables different custody models depending on its threshold structure, fault tolerance, and production maturity.

MuSig2 can simulate threshold behavior through Taproot's TapTree script paths: encode every possible t-of-n signer combination as a separate leaf. For a 2-of-3 setup, this means three leaves (AB, AC, BC) and remains practical. For larger thresholds like 5-of-9, the combinatorial blowup (126 leaves) makes this approach impractical, and FROST becomes the correct choice.

How Spark Uses FROST

Spark is a Bitcoin Layer 2 protocol built on statechains that uses FROST as its core signing primitive. The architecture employs a 2-of-2 model between the user and a collective of Spark operators (called the Spark Entity). The user holds one key, while the operators collectively hold the other key via FROST threshold signing. Within the operator set, no single operator possesses the complete key material.

When Alice transfers funds to Bob on Spark, the operators generate new FROST key shares for Bob and mathematically tweak their own key. Alice's old shares are destroyed, making her key material cryptographically useless. Bob's new key aligns with the operator's tweaked key. This entire process happens off-chain with no on-chain transaction, enabling instant, near-zero-fee transfers that are indistinguishable from ordinary Taproot spends when settled to L1.

FROST was chosen over MuSig2 because Spark requires threshold flexibility to distribute trust among operators. Unlike MuSig2's n-of-n constraint, FROST's t-of-n structure means the system remains secure as long as at least one operator behaves honestly. FROST was also preferred over ECDSA-based multi-party computation, which requires significantly more complex multi-round protocols. For a deeper technical treatment, see FROST threshold signatures explained and statechains: Bitcoin scaling deep dive.

If all operators go offline, users cannot make new Spark transfers but can still exit to Bitcoin L1 using pre-signed exit transactions. This hybrid model combines FROST's cooperative signing for the fast path with Taproot script-path timelocks as a safety fallback.

Implementation and Wallet Support

Production maturity varies significantly across the three schemes. MuSig2 leads in deployed implementations, FROST has audited libraries and protocol-level deployments, and ROAST remains research-grade.

MuSig2 implementations:

• libsecp256k1 (C): MuSig2 module merged October 2024 (v0.6.0)
• Bitcoin Core: MuSig2 descriptor parsing via BIP-390
• LND: Simple Taproot Channels graduated to production in v0.21 (June 2026)
• BitGo: Taproot multisig hot wallets with ~30% fee savings
• Ledger: Bitcoin app v2.4.0 support (April 2025)
• Lightning Loop: migrated to MuSig2 by default (February 2025)

FROST implementations:

• Zcash Foundation frost crate (Rust): v1.0.0, fully audited, RFC 9591 compliant
• frost-secp256k1: Bitcoin-compatible crate from the same suite
• Banca d'Italia secp256k1-frost: minimal-dependency RFC 9591 implementation with BIP-340 mode
• Spark: production deployment for statechain transfers
• BIP-445 + ChillDKG: Draft specifications for Bitcoin-native FROST

ROAST implementations:

• Blockstream research prototype: demonstrated with 67-of-100 threshold
• No widely-deployed production library confirmed as of mid-2026

Scriptless Scripts and Adaptor Signatures

All three schemes are compatible with adaptor signatures, which enable scriptless scripts: conditional payment flows that leave no visible script on-chain. Adaptor signatures are critical for privacy-preserving atomic swaps, PTLCs in Lightning, and discreet log contracts.

FROST's threshold structure makes it particularly well-suited for adaptor-based protocols where the signing set is distributed. For technical details on how adaptor signatures compose with Schnorr-based schemes, see Bitcoin scriptless scripts and applications.

Frequently Asked Questions

What is the difference between FROST and MuSig2?

FROST is a t-of-n threshold scheme where any t signers out of n can produce a valid signature. MuSig2 is an n-of-n scheme where all signers must participate. FROST requires an interactive distributed key generation ceremony, while MuSig2 uses simple, non-interactive key aggregation. MuSig2 is more mature (BIP-327, Deployed status) and easier to implement, but FROST provides the threshold flexibility needed for distributed custody and Layer 2 protocols like Spark.

Is FROST production-ready for Bitcoin?

The core cryptographic protocol is production-ready: the Zcash Foundation's reference implementation reached v1.0.0 with a full security audit, and RFC 9591 was published in June 2024. The Bitcoin-specific standard (BIP-445 and ChillDKG) remains in Draft status as of 2026. Spark uses FROST in production for statechain transfers, making it the most prominent live Bitcoin deployment.

Can MuSig2 do threshold signatures like 2-of-3?

Not natively. MuSig2 is strictly n-of-n. However, you can simulate threshold behavior by encoding every possible signer combination as a separate Taproot script-path leaf. For 2-of-3, this means three leaves and works well. For larger thresholds (e.g., 5-of-9 = 126 combinations), the approach becomes impractical and FROST is the better choice.

What does ROAST add on top of FROST?

ROAST adds robustness: the guarantee that t honest signers will always produce a valid signature even when malicious participants actively disrupt sessions. FROST alone provides identifiable aborts (you can detect misbehavior) but not robustness (you may not get a signature). ROAST manages multiple parallel FROST sessions so that each malicious signer can block at most one attempt. This matters primarily for large federations (50+ signers) where adversarial disruption is likely.

Do threshold signatures look different on-chain compared to single-key spends?

No. All three schemes (FROST, ROAST, MuSig2) produce a standard BIP-340 Schnorr signature that is completely indistinguishable from a single-key Taproot spend on-chain. The aggregate public key appears as a standard 32-byte X-only public key, and the signature is a single 64-byte value. An observer cannot determine whether one signer or a hundred signers participated. This provides significant privacy and fee advantages over script-based multisig approaches like OP_CHECKMULTISIG.

Which scheme should I use for a Bitcoin custody solution?

For Lightning channels and situations where all parties are always online: MuSig2 is the proven choice, deployed in LND and multiple production wallets. For distributed custody where some signers may be offline (2-of-3, 3-of-5 vaults): FROST provides true threshold flexibility. For large federations (50+ signers) in adversarial environments: ROAST wrapping FROST offers the strongest robustness guarantees, though production tooling is limited.

How does FROST compare to ECDSA-based multi-party computation?

ECDSA-based MPC (used by some custody providers before Taproot) requires significantly more complex multi-round protocols because ECDSA's non-linear signing equation does not compose as cleanly as Schnorr's linear structure. FROST is simpler to implement, faster to sign, and produces standard Schnorr signatures compatible with Taproot. The main advantage of ECDSA MPC is compatibility with pre-Taproot outputs, which remains relevant for legacy UTXOs.

This tool is for informational purposes only and does not constitute financial or security advice. Cryptographic scheme details are based on published papers, RFCs, and BIPs as of mid-2026. Implementation status changes frequently. Always verify current BIP status and library versions before deploying threshold signatures in production.