FROST (Flexible Round-Optimized Schnorr Threshold)

What Is FROST?

FROST (Flexible Round-Optimized Schnorr Threshold signatures) is a cryptographic protocol that allows a threshold subset of signers to cooperatively produce a single, standard Schnorr signature. Introduced by Chelsea Komlo and Ian Goldberg in 2020, FROST solves a long-standing problem in threshold cryptography: how to perform concurrent signing sessions securely with minimal communication overhead.

In a FROST setup, a group of n participants each holds a secret share of a group private key. Any t of those participants (where t is the threshold) can collaborate to produce a signature that looks identical to one created by a single signer. The remaining n minus t participants do not need to be online, available, or even aware that a signing session is happening.

This flexibility is what sets FROST apart from n-of-n schemes. If one keyholder loses their device, goes offline, or becomes uncooperative, the remaining participants can still sign as long as the threshold is met. For Bitcoin applications, this translates directly into more resilient custody models: a 3-of-5 FROST wallet survives the loss of two keys without requiring fund migration.

How It Works

FROST operates in two distinct phases: a one-time key generation ceremony, followed by a two-round signing protocol that can be repeated for every transaction.

Key Generation

Before signing can begin, the group must establish their shared key. FROST supports two approaches:

• Trusted dealer: a single party generates the master secret, creates polynomial shares using Shamir's Secret Sharing, and distributes one share to each participant over secure channels. This is simpler but requires trusting the dealer.
• Distributed key generation (DKG): each participant independently generates a random polynomial and distributes evaluations to every other participant. No single party ever knows the full secret. The group public key emerges from combining all contributions, but the corresponding private key exists only as distributed shares.

The DKG approach uses Feldman's Verifiable Secret Sharing, which lets each participant verify that their received shares are consistent with published commitments. If any participant sends invalid shares, the group can detect and identify the cheater before proceeding.

Round 1: Commitment

When the group wants to sign a message (such as a Bitcoin transaction), a coordinator identifies which t signers will participate. Each participating signer generates a pair of random nonces and computes elliptic curve commitments:

// Each signer p generates fresh nonces
d_p = random_scalar()
e_p = random_scalar()

// Compute commitments
D_p = d_p * G   // G is the generator point
E_p = e_p * G

// Send (D_p, E_p) to coordinator

Each nonce pair must be used exactly once. If a signing session is aborted, the nonces must be discarded and fresh ones generated for the next attempt. Reusing nonces across sessions can leak the signer's secret share.

Round 2: Signature Shares

Once the coordinator has collected all commitments, it broadcasts them along with the message to every participating signer. Each signer then:

1. Computes a binding factor for each participant by hashing the group public key, all commitments, the message, and the signer's identifier together
2. Derives the aggregate nonce point R from the combined commitments
3. Calculates the Schnorr challenge c = H(R || Y || m), where Y is the group public key
4. Computes their Lagrange interpolation coefficient based on the specific signing set
5. Produces a signature share combining their nonce values, secret share, and the challenge

The coordinator collects all t signature shares, verifies each one against the signer's public share (providing identifiable abort if anyone cheats), and sums them into the final aggregate signature (R, z). This output is a standard Schnorr signature: verifiers cannot distinguish it from one produced by a single private key.

Why Binding Factors Matter

The binding factor is FROST's key innovation. Earlier threshold Schnorr schemes were vulnerable to forgery when multiple signing sessions ran concurrently: an attacker could observe honest signers' commitments and craft their own to manipulate the aggregate nonce. FROST prevents this by deriving each signer's binding factor from a hash of all commitments combined. Since the binding factor cannot be computed until every commitment is published, no participant can retroactively influence the aggregate nonce.

FROST vs. MuSig2

Both FROST and MuSig2 produce standard Schnorr signatures compatible with BIP-340 and Taproot, but they serve different use cases:

The critical tradeoff: MuSig2 has simpler key setup (no DKG) but requires every signer to participate. FROST has a more complex key generation ceremony but offers operational flexibility afterward. For a deeper comparison, see the MuSig2 deep dive and the FROST threshold signatures explainer.

Implementation Status

FROST has moved from academic research to practical deployment across multiple stages of the standardization pipeline:

• RFC 9591 (published June 2024): the IETF informational RFC defines five ciphersuites including FROST(secp256k1, SHA-256) for Bitcoin's elliptic curve, though it is not directly compatible with BIP-340 due to x-only public key requirements
• BIP 445 (draft, January 2026): specifies a BIP-340-compatible FROST variant with support for BIP-32 key derivation and BIP-341 Taproot output key tweaking, bridging the gap between the RFC and Bitcoin's signature standard
• ZF FROST: the Zcash Foundation maintains a mature Rust implementation with a dedicated frost-secp256k1-tr crate for Taproot-compatible signing
• ChillDKG (Blockstream Research): a standalone distributed key generation protocol designed specifically for FROST that simplifies backup and recovery by deriving wallet state from device seeds plus public data

ROAST: Adding Robustness

FROST alone has a limitation: a malicious signer can disrupt the protocol by refusing to respond in Round 2, wasting the other signers' nonces. ROAST (Robust Asynchronous Schnorr Threshold signatures), developed by Blockstream researchers in 2022, wraps around FROST to guarantee that t honest signers can always produce a valid signature, even when other participants actively try to sabotage the process.

Use Cases

Bitcoin Custody

FROST enables custody setups where keys are distributed across multiple devices, locations, or organizations. A 3-of-5 FROST wallet, for example, can tolerate the loss or compromise of two keys while still allowing the remaining holders to access funds. Compared to traditional script-based multisig, FROST transactions are roughly 75% smaller on-chain (approximately 110 vbytes versus 450 vbytes for a 5-of-7 P2WSH multisig) and reveal no information about the signing structure.

Federated Protocols

Layer 2 protocols and federated systems use FROST to distribute trust across a set of operators. Spark, for instance, uses a signing model where one key is held by the user and the other is collectively managed by Spark Operators via FROST threshold signatures. Any sufficient subset of operators can participate in signing without requiring every operator to be online, while settling to Layer 1 produces standard Taproot spends indistinguishable from single-signer transactions. Learn more in the Spark Layer 2 overview.

Inheritance and Recovery

FROST thresholds can encode inheritance schemes: a 2-of-4 setup might give keys to the owner, a spouse, a lawyer, and a hardware device in a vault. Day-to-day spending requires only the owner plus one other key, but in the event of incapacitation, the remaining keyholders can recover funds without any single party having unilateral control.

Hardware Wallet Integration

Projects like Frostsnap are building FROST directly into hardware wallet devices. This approach lets users add or remove signers from a threshold group without moving funds to a new address, since the group public key can remain stable through signer set changes when using compatible DKG protocols.

Risks and Considerations

DKG Complexity

The distributed key generation ceremony is the most operationally complex part of FROST. All n participants must be online simultaneously, exchange data over authenticated channels, and correctly verify commitments. A failed DKG means restarting from scratch. For non-technical users, this ceremony can be a significant barrier compared to the simplicity of generating a standard seed phrase.

Nonce Management

Nonce reuse in FROST is catastrophic: if a signer uses the same nonce pair across two signing sessions, their secret share can be extracted algebraically. Implementations must guarantee that nonces are single-use, which requires careful state management, especially on hardware devices with limited storage. Aborting and retrying sessions further complicates nonce lifecycle tracking.

Coordinator Trust

While the coordinator in FROST does not need access to secret material, it does see all commitments and signature shares. A malicious coordinator can selectively exclude signers or refuse to aggregate, though it cannot forge signatures. In security-critical deployments, rotating the coordinator role or using ROAST mitigates this concern.

Standardization Maturity

As of mid-2026, the Bitcoin-specific FROST signing BIP (BIP 445) remains in draft status, and the companion DKG specification (ChillDKG) is still under review. While reference implementations exist and production deployments have begun, wallet developers should track the evolving specifications and test vectors closely before integrating FROST into shipping products.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.