Threshold signing protocols, like FROST, help to facilitate trust while avoiding the reliance on a centralized authority. They do this by fault-tolerantly distributing information or computation among a cluster of cooperating computers. With the rapid advancement of secure digital systems, threshold cryptography is gaining traction through securing multi-signature wallets, protecting validator keys in proof-of-stake networks, and building resilient identity systems. One protocol drawing increasing attention is FROST—Flexible Round-Optimized Schnorr Threshold signatures (RFC 9591, [KG20]). FROST enables a group of participants to collaboratively produce a single, valid Schnorr signature in a way that’s efficient, secure, and privacy-preserving.
Our team recently performed a security audit of a Zcash demo implementation of FROST based on the open-source frost-crate. The demo includes both a CLI client and a FROST server that handles authenticated, secure communication using HTTP, optional TLS, and encryption via the Noise protocol. It supports both trusted dealer and distributed key generation (DKG) setups, allowing developers and researchers to explore real-world usage of the protocol. The demo was designed to be easy to run locally, allowing developers, auditors, and researchers to explore the FROST protocol without needing to deploy a complex distributed system.
In addition to reviewing and testing this implementation, we’re also performing security audits of other projects that are utilizing FROST. Once the final reports are available, we hope to share insights into the process and how FROST holds up under rigorous analysis.
How FROST Works (In Simple Terms)
FROST—short for Flexible Round-Optimized Schnorr Threshold signatures—is a cryptographic protocol that enables a group of participants to collaboratively generate a single Schnorr signature, even if only a subset (a threshold) of them are available.
This is known as a threshold signature scheme, and it’s especially valuable in decentralized systems where no one party should have full signing authority.
Key Features of FROST
- Efficiency: Traditional threshold schemes often require multiple rounds of communication between participants. FROST minimizes this to just two rounds, improving performance in latency-sensitive or bandwidth-constrained environments.
- Flexible Participation: Not all participants need to be online at the same time. If the threshold number is met, signing can proceed.
- Privacy-Preserving: FROST doesn’t reveal which subset of participants signed, preserving anonymity among signers.
At its core, FROST extends the well-known Schnorr signature scheme into a collaborative process—one where no single participant ever sees the full signing key.
Key Generation Options: Trusted Dealer vs DKG
FROST supports two methods for generating the initial set of key shares:
Trusted Dealer Setup
In this approach, a single party (the dealer) is responsible for generating the full key and securely distributing the secret shares to each participant.
- Pros: Simple to implement; efficient for testing or controlled environments.
- Cons: Requires trust in the dealer not to expose or misuse the full key.
Distributed Key Generation (DKG)
In a DKG setup, participants jointly generate their key shares without any single party knowing the full secret key. This removes the need to trust any one single entity.
- Pros: Stronger trust model; ideal for decentralized applications.
- Cons: More complex; requires extra coordination during setup.
Fun fact: The Zcash demo supported both key generation options, giving users a hands-on way to compare them and experiment with different security models.
Our Role as Auditors
As part of our broader cryptographic security work, our team is conducting security audits of projects with FROST implementations.
Auditing the use of threshold signature schemes like FROST is essential—not only because the math is subtle, but because implementation details (e.g., misconfigured DKG flows, message tampering, etc.) can introduce serious vulnerabilities.
Our audit process involves:
- Reviewing the FROST implementation against the FROST specification;
- Validating cryptographic assumptions, including random number generation, and nonce handling;
- Ensuring secure communication, authentication, and failure modes in the implementation; and
- Publishing the final security audit reports (pending client approval for public release) to promote transparency and contribute to industry learning, and sharing insights into key findings and protocol performance.
While the foundation of FROST is based on decades of research, its adoption, implementation and ecosystem development has experienced growth in just a short period of time. Our team has the cryptographic skills and experience needed to audit systems using complex protocols like FROST. If you’re looking for support in securing or reviewing such systems, feel free to get in touch or visit our website to learn more.