FROST Threshold Signatures: Distributed Key Generation for Bitcoin

Bitcoin custody has long relied on a simple tradeoff: either trust a single key (and accept a single point of failure) or use on-chain multisig (and accept the privacy and cost overhead). FROST (Flexible Round-Optimized Schnorr Threshold signatures) eliminates this tradeoff. It allows a group of participants to collectively control a key, produce a single standard Schnorr signature when a threshold cooperates, and reveal nothing about the group structure on-chain.

The FROST paper was published by Chelsea Komlo and Ian Goldberg in 2020. Since then, the protocol has moved from academic research to production deployments, including an IETF standardization effort and integration into Bitcoin Layer 2 protocols. This article traces the progression from script-based multisig to MuSig to FROST, explains the cryptographic machinery that makes FROST work, and covers where the protocol is deployed today.

From Multisig to MuSig to FROST

Understanding FROST requires understanding what came before it. Bitcoin has supported multi-party authorization since 2012, but each generation of the technology has addressed limitations of the previous one.

Script-Based Multisig

Bitcoin's OP_CHECKMULTISIG opcode allows creating m-of-n spending conditions directly in Bitcoin Script. A 2-of-3 multisig address, for example, requires two of three designated keys to sign before funds can move. This approach is native to Bitcoin's consensus rules: every full node verifies the script, and the spending policy is enforced on-chain without trusting any external software.

The drawbacks are well-documented. When spending from a P2SH or P2WSH multisig address, the transaction reveals the complete redeem script: the number of signers, the threshold, and all public keys. Chain analysis firms can fingerprint specific multisig configurations. Transaction size grows linearly with the number of signatures, increasing fees. A 3-of-5 P2WSH spend requires roughly 350 virtual bytes compared to 110 vbytes for a single-key spend.

MuSig and MuSig2: n-of-n Aggregation

The Taproot upgrade activated Schnorr signatures on Bitcoin via BIP 340. Schnorr's key mathematical property is linearity: given valid signatures for public keys P1 and P2, you can add them to produce a valid signature for the combined key P1 + P2. This enables key aggregation protocols.

MuSig2 (BIP 327) is a two-round interactive signing protocol for n-of-n key aggregation. All participants combine their public keys into a single aggregate key, then cooperatively produce a single 64-byte Schnorr signature. On-chain, the result is indistinguishable from a single-signer Taproot spend. No script is revealed, no individual keys are exposed, and the transaction costs the same as any other single-key payment.

MuSig2 solves the privacy and cost problems of script-based multisig, but it has a critical limitation: it requires all n participants to cooperate. If even one signer is unavailable or unresponsive, the group cannot produce a signature. There is no threshold: it is all-or-nothing.

The threshold gap: MuSig2 gives you n-of-n signing with a single-sig on-chain footprint. But many real-world applications need t-of-n: the ability for a subset of participants to sign while the rest are offline, unavailable, or compromised. This is the gap that FROST fills.

FROST: Threshold Meets Aggregation

FROST combines the efficiency of Schnorr aggregation with the flexibility of threshold signing. A t-of-n FROST group can produce a valid Schnorr signature when any t participants cooperate, even if the remaining n-t participants are offline. The resulting signature is a standard 64-byte Schnorr signature: on-chain, it is identical to a MuSig2 signature or a single-signer signature.

How FROST Works

FROST operates in two distinct phases: distributed key generation (DKG), which happens once to set up the group, and signing, which happens each time the group needs to produce a signature. Understanding both phases requires some background on the underlying mathematics.

Shamir's Secret Sharing

FROST builds on Shamir's Secret Sharing (1979), a foundational cryptographic primitive. The idea: a secret value (like a private key) can be split into n shares such that any t shares can reconstruct the secret, but t-1 shares reveal nothing about it.

The mechanism uses polynomial interpolation. The secret is embedded as the constant term of a random polynomial of degree t-1. Each participant receives a point on this polynomial as their share. By the mathematical properties of polynomials, any t points uniquely determine the polynomial (and thus the secret), while t-1 points leave the secret information-theoretically hidden.

In classic Shamir's Secret Sharing, the shares must be brought together to reconstruct the secret. This creates a vulnerability: whoever performs the reconstruction sees the full private key. FROST avoids this by never reconstructing the key. Instead, each participant uses their share to compute a partial signature, and the partial signatures combine into a valid full signature through Lagrange interpolation in the exponent. The complete private key never exists in any single location.

Distributed Key Generation

The DKG phase creates key shares for all participants without any trusted dealer. This is critical: if a single party generated all shares, that party would temporarily know the complete private key, creating a single point of failure that defeats the purpose of threshold signing.

FROST's DKG is based on Pedersen's distributed key generation protocol, enhanced with verifiable secret sharing. The process works as follows:

1. Each participant generates a random polynomial of degree t-1 and computes commitments to the polynomial's coefficients using elliptic curve points
2. Each participant broadcasts their commitments and sends a secret share (a point on their polynomial) to every other participant over an encrypted channel
3. Each participant verifies received shares against the broadcasted commitments, rejecting any shares that do not match (this catches malicious or faulty participants)
4. Each participant sums up all the shares they received (including their own) to compute their final key share

The resulting group public key is the sum of each participant's first commitment point. No participant ever sees the group private key: it exists only implicitly as the sum of all participants' polynomial constant terms.

No trusted dealer: The DKG ensures that the group private key is never constructed or known by any single party. Even if t-1 participants collude, they cannot determine the key without the final participant's share. This is a stronger guarantee than "trusted dealer" setups where one entity generates and distributes all shares.

The Signing Protocol

When a subset of t participants wants to sign a message (such as a Bitcoin transaction), they execute a two-round protocol.

In the first round, each signer generates a pair of nonce values and broadcasts commitments to these nonces. The nonces must be fresh and random for every signing session: reusing a nonce across sessions leaks the signer's key share, just as nonce reuse in standard Schnorr signing leaks the private key.

In the second round, each signer computes a partial signature using their key share, their nonce, the aggregated group nonce, the message, and Lagrange interpolation coefficients that account for which specific subset of t signers is participating. Each signer broadcasts their partial signature.

An aggregator (which can be any participant or a separate coordinator) collects the t partial signatures and sums them to produce the final Schnorr signature. This signature is valid for the group public key and can be verified by anyone using standard Schnorr verification: there is no special verification procedure and no indication that multiple parties were involved.

Nonce Management

Nonce safety is the primary implementation risk in any multi-party Schnorr signing protocol. FROST addresses this through several design choices:

• Each signer uses a pair of nonces (not a single value), which are combined with a binding factor derived from all participants' commitments to prevent manipulation
• Nonces are generated using a combination of randomness and deterministic derivation from the signer's secret key and the message, reducing the risk of entropy failures
• The protocol supports pre-processing: signers can generate and distribute nonce commitments ahead of time, reducing the online signing phase to a single round

Pre-processing is particularly useful for applications with latency constraints. Signers generate batches of nonce commitments during idle periods, then consume one commitment per signing session. This amortizes the communication cost and reduces signing latency to a single round trip.

Threshold Schemes and Share Refresh

A t-of-n threshold scheme provides two independent security properties: it tolerates up to n-t unavailable signers (availability) and requires at least t signers to collude before they can produce a signature (security). The choice of t and n depends on the threat model.

Choosing t and n

A lower threshold increases availability at the cost of security: a 2-of-5 FROST group only needs two signers online, but an attacker only needs to compromise two shares. A higher threshold increases security but reduces availability: a 4-of-5 group requires four cooperating signers but tolerates at most one failure.

Unlike script-based multisig, changing the threshold in FROST does not require a new on-chain address. The group can run a new DKG with a different threshold and begin using the new shares, while the group public key (and therefore the on-chain address) remains unchanged if the same polynomial evaluation approach is used with proactive resharing.

Share Refresh (Proactive Secret Sharing)

FROST supports share refresh: the process of generating new key shares for the same underlying group key without any on-chain transaction. This is sometimes called proactive secret sharing, and it provides several critical benefits:

• A compromised share becomes useless after refresh because the new shares are not mathematically related to the old ones (an attacker who stole a share before refresh and another share after refresh still cannot reconstruct the key)
• Participants can be added or removed from the group without changing the group public key
• Periodic refresh limits the window of vulnerability: even if an attacker is slowly compromising shares one at a time, refresh invalidates previously stolen shares

The refresh protocol is essentially a DKG for a zero-secret polynomial: each participant generates a random polynomial with a constant term of zero, and the resulting shares are added to existing shares. Since the zero-secret contributions sum to zero, the group key remains unchanged while every individual share is replaced.

FROST vs Traditional Multisig

The practical differences between FROST and script-based multisig extend beyond privacy and transaction size. The two approaches differ in their trust models, failure modes, and operational characteristics.

Privacy

Script-based multisig reveals the spending policy to the entire network. A 3-of-5 P2WSH transaction exposes all five public keys, the threshold, and which three keys signed. This information persists permanently on the blockchain and enables chain analysis firms to track multisig users, estimate the size of organizations, and correlate transactions.

FROST reveals nothing. The on-chain transaction contains a single public key and a single signature: the same as any individual Taproot spend. Observers cannot determine whether the signer is one person, five people, or a hundred-member federation.

Cost

The fee difference is substantial for high-threshold schemes. A 5-of-7 P2WSH multisig spend occupies roughly 450 vbytes. The equivalent FROST signing operation produces a standard Taproot transaction of approximately 110 vbytes: the same cost regardless of threshold or group size. At fee rates above 50 sat/vbyte, this translates to meaningful savings per transaction.

Verifiability

Script-based multisig has one advantage that FROST cannot replicate: on-chain policy enforcement. With OP_CHECKMULTISIG, every full node on the Bitcoin network verifies that the required number of valid signatures is present. The spending policy is consensus-enforced and auditable by anyone.

FROST shifts policy enforcement off-chain into the cryptographic protocol. Verifiers on the Bitcoin network see a valid Schnorr signature and accept it: they cannot verify that a threshold of participants actually signed. This means the security of FROST depends on the correctness of the implementation, not on Bitcoin's consensus rules. A bug in the FROST library could allow unauthorized signing, and on-chain verification would not catch it.

FROST vs ECDSA-Based MPC

Before Taproot enabled Schnorr on Bitcoin, the only way to achieve threshold signing with a single-sig on-chain footprint was through ECDSA-based Multi-Party Computation (MPC) protocols like GG18 and GG20. These protocols are significantly more complex than FROST because ECDSA lacks Schnorr's linearity property.

ECDSA threshold signing requires multi-round protocols with Paillier encryption and zero-knowledge range proofs to securely multiply key shares during signing. A typical GG20 signing ceremony involves 4 or more interactive rounds. FROST achieves the same result in 2 rounds (or effectively 1 round with pre-processing) using simple polynomial interpolation and addition.

ECDSA MPC remains relevant for systems that need compatibility with pre-Taproot Bitcoin outputs or with other blockchains that do not support Schnorr. But for new Bitcoin applications built on Taproot, FROST is the more natural and efficient choice.

Implementation Status

FROST has progressed from an academic paper to multiple production-grade implementations. The IETF Crypto Forum Research Group (CFRG) has been working on a FROST specification that defines the protocol for multiple ciphersuites, including the secp256k1 curve used by Bitcoin.

Open-Source Implementations

Several open-source FROST implementations are available and actively maintained:

• The Zcash Foundation's FROST library (Rust) implements the full protocol for multiple ciphersuites including secp256k1, with a focus on conformance to the IETF draft
• The libsecp256k1 library (Bitcoin's core elliptic curve library) includes a merged MuSig2 module, and FROST support built on the same primitives is under active development
• The frost-ts library provides a TypeScript implementation targeting web and Node.js environments

Production Deployments

FROST is used in production by several Bitcoin infrastructure projects. The most notable deployment is within the Spark protocol, where FROST threshold signatures are a core architectural component.

In Spark, the user holds one key share while a set of independent operators (the Spark Entity) collectively hold the other share via FROST. The two-of-two structure between user and operator group ensures that neither party can move funds unilaterally. Within the operator group, FROST's threshold properties mean that no single operator possesses the complete operator key share: the key material is distributed across independent entities.

This design gives Spark a 1-of-n trust model: as long as one operator behaves honestly, user funds remain secure. When a transfer occurs, the operators generate new FROST key shares for the recipient and destroy the old shares, ensuring that previous owners lose cryptographic access. The revocation key mechanism reinforces this by providing fallback exit paths that do not depend on operator cooperation.

Because FROST produces standard Schnorr signatures, Spark transactions that settle to Layer 1 are indistinguishable from ordinary Taproot spends. On-chain observers cannot determine the number of operators, the threshold, or even that a Layer 2 protocol was involved. This is a direct consequence of FROST's core design: threshold signing that is invisible on the blockchain.

Security Considerations

FROST provides strong cryptographic guarantees, but its security depends on correct implementation and appropriate operational practices.

Honest Majority Assumption

FROST's DKG requires that fewer than t participants are malicious during key generation. If t or more participants collude during the DKG, they can bias the group key or learn enough information to reconstruct it. In practice, this means the DKG should occur in a setting where the honesty of a majority of participants can be reasonably assumed.

After the DKG, the security threshold applies: an attacker must compromise t shares to forge a signature. The DKG and signing security thresholds are distinct. Robust variants of FROST's DKG (such as those using verifiable secret sharing with complaint mechanisms) can detect and exclude misbehaving participants, relaxing the honest majority requirement.

Nonce Reuse

As with all Schnorr-based protocols, nonce reuse is catastrophic. If a signer uses the same nonce in two different signing sessions, their key share can be extracted algebraically. FROST mitigates this through its nonce commitment structure and recommended entropy practices, but implementations must take extreme care with nonce generation and storage. Embedded devices and hardware wallets face particular challenges here, as they may have limited entropy sources.

Rogue Key Attacks

In naive multi-party key aggregation, a malicious participant can choose their public key as a function of other participants' keys to cancel out their contributions and gain sole control of the aggregate key. FROST and MuSig2 both prevent this through proof-of-knowledge mechanisms during key generation: each participant must prove they know the discrete logarithm of their public key, making rogue key attacks infeasible.

FROST and Bitcoin Script Fallbacks

One of FROST's advantages over ECDSA-based MPC is its natural integration with Taproot's script path. A FROST group can use the key path for the cooperative case (producing a single Schnorr signature when the threshold cooperates) while embedding fallback conditions in the Taproot Merkle tree of scripts.

For example, a FROST output might include script path leaves for timelocked recovery (if the FROST group becomes unresponsive) or alternative spending conditions. In the normal case, the key path is used and no scripts are revealed. If the FROST signing protocol fails for any reason, the script path provides an on-chain enforcement mechanism. This hybrid approach combines FROST's efficiency with Bitcoin Script's timelock-based safety guarantees.

This is precisely the pattern used in protocols like Spark, where pre-signed exit transactions with relative timelocks allow users to unilaterally withdraw to Layer 1 if operators become unavailable, while normal transfers use the efficient FROST key path.

Comparison with Related Schemes

FROST exists within a broader landscape of threshold and multi-party signing protocols. Understanding how these protocols relate helps clarify when FROST is the right choice.

FROST vs ROAST

ROAST (Robust Asynchronous Schnorr Threshold signatures) is a wrapper protocol around FROST that adds robustness: the ability to complete signing even when some participants are actively disruptive (not just offline). ROAST achieves this by running multiple parallel FROST signing sessions and using the first one that succeeds. This is useful in adversarial settings where participants might deliberately stall or send invalid messages.

FROST vs Threshold ECDSA

Threshold ECDSA protocols (GG18, GG20, CGGMP) serve the same purpose as FROST but operate over the ECDSA signature scheme. They are necessary for blockchains without Schnorr support and for pre-Taproot Bitcoin UTXOs. The tradeoff is significantly higher protocol complexity: more communication rounds, larger proof sizes, and greater implementation surface area for bugs.

FROST vs Shamir + Trusted Dealer

The simplest threshold scheme is to have a trusted dealer generate a key, split it using Shamir's Secret Sharing, and distribute the shares. This works but introduces a fatal weakness: the dealer sees the complete private key. FROST's DKG eliminates this single point of failure. The group key is generated collaboratively and never exists in any one place.

Open Research and Future Directions

Several areas of active research extend FROST's capabilities:

• Accountable FROST variants that allow identifying which participant produced an invalid partial signature, useful for compliance and auditing in institutional settings
• Integration with adaptor signatures for atomic swaps and PTLCs, enabling threshold-signed Lightning payments that are decorrelated across routing hops
• Weighted threshold schemes where participants have different numbers of "votes" (useful for governance structures where not all signers have equal authority)
• Hardware security module (HSM) integration for enterprise deployments where key shares must reside in tamper-resistant hardware

The IETF CFRG standardization process continues to refine the specification. Once finalized, the standard will provide a common reference for interoperable implementations, reducing the fragmentation that currently exists across FROST libraries.

Conclusion

FROST represents a significant advance in how Bitcoin custody and signing can be distributed. By combining Schnorr's linearity with Shamir-style threshold secret sharing and a trustless DKG, FROST delivers the security benefits of multisig (no single point of failure, configurable thresholds) without the on-chain costs (policy exposure, increased transaction size, reduced privacy).

The progression from script multisig to MuSig to FROST follows a clear arc: each generation preserves the security properties of the previous one while removing its limitations. Script multisig introduced multi-party authorization but exposed the policy on-chain. MuSig2 hid the policy behind a single key but required all participants. FROST retains the single-key appearance while allowing flexible thresholds, offline tolerance, and share refresh.

For protocols like Spark that need distributed custody across independent operators, FROST is not merely an optimization: it is a foundational building block. The combination of threshold security, on-chain privacy, and Taproot-native compatibility makes FROST the natural signing protocol for the next generation of Bitcoin infrastructure.

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.