MuSig2 vs FROST: Bitcoin Threshold Signature Comparison

MuSig2 vs FROST Overview

MuSig2 and FROST are Schnorr-based signing protocols that let multiple parties cooperatively produce a single signature indistinguishable from an ordinary Taproot spend on the Bitcoin blockchain. Both eliminate the on-chain footprint of traditional multisig, where each signer and threshold is exposed in the transaction script. The protocols differ in one fundamental way: MuSig2 is an n-of-n key aggregation scheme requiring every signer to participate, while FROST is a threshold signature scheme where any t-of-n signers can produce a valid signature.

This distinction drives nearly every other tradeoff between the two protocols: key generation complexity, fault tolerance, signer privacy, and implementation maturity. The following table summarizes the core differences.

For a broader comparison that includes ROAST and legacy ECDSA multisig, see our Bitcoin threshold signature comparison.

How MuSig2 Works

MuSig2 was designed by Jonas Nick, Tim Ruffing, and Elliott Jin as a two-round multi-signature protocol for BIP-340 Schnorr signatures. It replaced the original MuSig protocol, which required three rounds due to a commit-then-reveal nonce exchange. MuSig2 eliminates the commitment round by having each signer generate two independent nonces, combined in a way that prevents rogue-key attacks without the extra round.

Key aggregation in MuSig2 is non-interactive: given a set of public keys, any party can compute the aggregate public key deterministically. Each signer's key is multiplied by a coefficient derived from the hash of all participants' keys. This step happens once per signer set and produces the single public key that appears on-chain.

The signing protocol proceeds in two rounds. In the first round, each signer generates nonces and broadcasts their public nonce values. In the second round, each signer computes a partial signature using their private key, the aggregated nonce, and the message. Partial signatures are then combined into a final 64-byte Schnorr signature that is valid under the aggregated public key, indistinguishable from any other Taproot key-path spend.

How FROST Works

FROST (Flexible Round-Optimized Schnorr Threshold signatures) was originally described by Chelsea Komlo and Ian Goldberg. The protocol enables t-of-n signing: any subset of t signers from a group of n total participants can produce a valid Schnorr signature. The IETF published FROST as RFC 9591 in June 2024, defining ciphersuites for secp256k1, Ed25519, ristretto255, Ed448, and P-256.

Unlike MuSig2's simple key aggregation, FROST requires a key generation phase where participants jointly create key shares using Shamir's Secret Sharing. This can happen through a Distributed Key Generation (DKG) ceremony where no single party ever holds the complete private key, or through a trusted dealer who generates the secret and distributes shares. The DKG approach is strictly stronger: it eliminates the single point of compromise that a dealer introduces.

FROST signing itself uses two communication rounds. In round one, each participating signer generates a nonce pair and broadcasts commitments. In round two, signers produce partial signature shares that are aggregated into the final signature. With nonce preprocessing, where signers pre-generate and store batches of nonce commitments, signing can be optimized to a single round at the cost of state management.

Key Generation: The Critical Difference

The most significant practical difference between MuSig2 and FROST is key generation. MuSig2 requires each signer to have an independent key pair. Aggregating these keys into a joint public key is deterministic and non-interactive. A signer can be added to a quorum without any ceremony, since all that is needed is their public key.

FROST's DKG is a multi-step interactive protocol. For Bitcoin specifically, the ChillDKG specification (authored by Tim Ruffing and Jonas Nick) layers three protocols: SimplPedPop provides the base Pedersen-style secret sharing, EncPedPop adds ECDH encryption for secret share transport, and ChillDKG wraps both with secure communication and agreement mechanisms. The result is a self-contained protocol that produces Taproot-compatible key shares without requiring external secure channels.

ChillDKG also addresses recoverability: each participant can reconstruct their key share from a seed backup and per-session recovery data, similar to how descriptor wallets work today. This DKG specification is still in draft status, which is one reason FROST adoption on Bitcoin trails MuSig2.

FROST Variants: Trusted Dealer vs DKG

RFC 9591 intentionally leaves key generation out of scope, providing only a trusted-dealer appendix for reference. This means FROST implementations must choose between two key generation models, each with distinct security properties.

For self-custodial Bitcoin applications, the DKG approach is essential. A trusted dealer model reintroduces the exact counterparty risk that threshold signatures are designed to eliminate. For a deeper look at how DKG works in practice, see our research on FROST threshold signatures.

Implementation Maturity

MuSig2 has a significant head start in production Bitcoin deployments. BIP-327 was merged into the Bitcoin BIPs repository in March 2023. The libsecp256k1 library, used by Bitcoin Core, merged its MuSig2 module in October 2024 (v0.6.0). Supporting standards followed: BIP-390 defines musig() descriptor key expressions, and BIP-373 specifies MuSig2 PSBT fields.

On the wallet side, BitGo deployed MuSig2 for Taproot hot wallets, achieving roughly 45% fee savings on 2-of-3 inputs compared to native SegWit (57.5 vB per MuSig key-path input vs. 104.5 vB for native SegWit). Ledger shipped MuSig2 support in Bitcoin App v2.4.0 in April 2025, becoming the first major hardware wallet to support the protocol.

FROST's Bitcoin-specific standardization is still in progress. RFC 9591 covers the signing protocol and secp256k1 ciphersuite, but its signature encoding is not directly compatible with BIP-340 due to Taproot key tweaking and x-only public key requirements. A Bitcoin-specific FROST BIP and the ChillDKG companion specification remain in draft. Implementations include ZF FROST (maintained by the Zcash Foundation), an experimental module in libsecp256k1-zkp (by Jesse Posner and Blockstream Research), and the audited implementation used by Spark.

Robustness and Identifiable Aborts

Neither MuSig2 nor FROST guarantees robustness on its own. In MuSig2, if any signer refuses to participate or goes offline, signing fails entirely and there is no way to identify the disruptive party beyond observing who did not respond.

FROST provides identifiable aborts: if a participant submits an invalid partial signature, other signers can cryptographically verify the misbehavior and exclude that participant. However, FROST alone does not prevent a malicious signer from repeatedly disrupting sessions in asynchronous networks by simply refusing to respond.

ROAST, published by Tim Ruffing and others at ACM CCS 2022, is a wrapper protocol that solves this problem. It runs multiple concurrent FROST sessions so that a quorum of honest signers can always complete a signature even if up to n−t signers actively disrupt the process. ROAST's motivating use case is large federations (such as Liquid's 11-of-15 setup), where the probability of at least one disruptive or offline participant grows with federation size. ROAST remains a research prototype and has not yet reached production deployment on Bitcoin.

Spark's Use of FROST

Spark, a Bitcoin Layer 2 built on statechains, uses FROST threshold signatures as a core part of its security model. Each virtual UTXO on Spark is locked in a 2-of-2 arrangement: the user holds one key share, and a federation of independent Spark Operators collectively holds the other via FROST. No single operator possesses the complete operator-side key at any point.

When a user transfers funds to a new recipient, the operators generate a new FROST key share for the recipient, adjust their own collective share so the on-chain public key remains unchanged, and delete the previous owner's key share. The sender's key material becomes cryptographically useless. Neither the user nor the operators can spend funds unilaterally: the user retains a pre-signed backup transaction for permissionless on-chain withdrawal if operators become unavailable.

FROST is well-suited to this architecture because it allows the operator federation to co-sign without ever reconstructing the full private key, and the threshold structure means the system remains operational even if individual operators go offline. For details on the trust assumptions behind this design, see the statechains deep dive.

When to Use MuSig2 vs FROST

The choice between MuSig2 and FROST depends on your signing requirements:

• Use MuSig2 when every participant must sign every transaction and you want the simplest possible setup: no DKG ceremony, mature tooling, and hardware wallet support (Ledger, BitGo)
• Use FROST when you need threshold flexibility (e.g., 3-of-5) so that lost keys or offline signers do not lock funds permanently
• MuSig2 can approximate t-of-n by placing each possible signer combination in a Taptree leaf, but this scales combinatorially: a 3-of-5 setup requires 10 leaves, and a 5-of-9 setup requires 126 leaves
• For federated protocols, statechains, and second-layer systems where operator availability varies, FROST (optionally with ROAST) provides a native threshold solution without Taptree complexity
• For Lightning channel co-signers where both channel partners must agree, MuSig2's 2-of-2 model is a natural fit and is already deployed in production

Both protocols can be combined. A wallet might use MuSig2 for the Taproot key path (the expected co-signing case) and place FROST-based threshold branches in Tapscript leaves as a recovery fallback.

Frequently Asked Questions

What is the difference between MuSig2 and FROST?

MuSig2 is an n-of-n scheme where every signer must participate in every signing session. FROST is a t-of-n scheme where only a configurable threshold of signers is needed. Both produce standard 64-byte BIP-340 Schnorr signatures that look identical on-chain. The key tradeoff is that MuSig2 has simpler key setup (non-interactive aggregation) while FROST requires a DKG ceremony but provides fault tolerance and signer privacy.

Do MuSig2 and FROST signatures look different on the blockchain?

No. Both protocols produce a single 64-byte Schnorr signature that is indistinguishable from an ordinary single-signer Taproot key-path spend. An external observer cannot tell whether a transaction was signed by one person, an n-of-n MuSig2 group, or a t-of-n FROST threshold. This privacy property is a major advantage over traditional OP_CHECKMULTISIG scripts, which expose the number of signers and threshold on-chain.

How many signing rounds do MuSig2 and FROST require?

Both protocols require two communication rounds during signing: a nonce exchange round and a partial signature round. FROST can be optimized to a single signing round if nonce commitments are preprocessed and stored in advance, at the cost of managing nonce state and ensuring nonces are never reused. MuSig2 improved on the original MuSig protocol by eliminating a third (nonce commitment) round.

Does FROST require a trusted dealer?

Not necessarily. FROST supports two key generation modes: a trusted dealer who generates the secret and distributes shares, or a Distributed Key Generation (DKG) ceremony where participants jointly create key shares without any single party ever holding the complete secret. For production Bitcoin use cases, DKG is strongly preferred because a trusted dealer creates a single point of compromise during setup.

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

MuSig2 does not natively support threshold signing. It can approximate t-of-n by creating MuSig2 key aggregations for every possible t-sized subset and placing each in a Taptree leaf. For a 3-of-5 setup, this means 10 leaves. This approach works for small groups but becomes impractical as the number of participants grows, since the number of combinations is n-choose-t. FROST handles this natively without combinatorial overhead.

Is FROST standardized for Bitcoin?

The FROST signing protocol is standardized as IETF RFC 9591 (June 2024), which includes a secp256k1 ciphersuite. However, the RFC's signature encoding is not directly compatible with Bitcoin's Taproot requirements (x-only public keys and key tweaking). A Bitcoin-specific FROST BIP and the ChillDKG companion specification for key generation are both in draft status. For current progress, see the research article on FROST threshold signatures.

What is ROAST and how does it relate to FROST?

ROAST (Robust Asynchronous Schnorr Threshold signatures) is a wrapper protocol that adds robustness to FROST. While FROST provides identifiable aborts (you can detect a misbehaving signer), it does not guarantee that honest signers can always complete signing when disruptive participants refuse to cooperate. ROAST runs multiple concurrent FROST sessions to ensure a quorum of honest signers always succeeds. It is particularly relevant for large federations where individual participant availability cannot be guaranteed.

Which Bitcoin wallets support MuSig2 today?

BitGo deployed MuSig2 for Taproot hot wallets, using the key-path spend for their most common 2-of-3 signing quorum. Ledger shipped MuSig2 in Bitcoin App v2.4.0 (April 2025), supporting musig() wallet policies as defined in BIP-388. The libsecp256k1 library used by Bitcoin Core merged its MuSig2 module in October 2024. For a full list of wallet support, see our Taproot wallet support tracker.

This tool is for informational purposes only and does not constitute financial or security advice. Protocol specifications, BIP statuses, and implementation details change as development progresses. Always verify current information against primary sources such as the BIP repository, RFC documents, and project documentation before making custody or architecture decisions.