FROST

Key Facts

• The Zcash Foundation repository implements RFC 9591 two-round threshold Schnorr signatures in Rust.
• Threshold participants hold shares of a common private key, and a required subset must cooperate to sign.
• The repository includes trusted-dealer and distributed key generation, share repair, rerandomized FROST, and share refresh functions.
• The crates are described as stable and feature complete and follow Semantic Versioning guarantees.
• NCC audited version 0.6.0 for named crates; newer modules and later code are outside that historical scope unless separately reviewed.

What threshold signing changes

A conventional single-party signature places the full signing key under one authority. FROST divides that authority into shares. The group chooses a threshold, and at least that many participants must cooperate to produce a valid signature. No individual participant needs to reconstruct or possess the whole private key during normal signing. This can reduce the risk created by one stolen device or one administrator acting alone.

Threshold signing is not the same as simply collecting several independent signatures on-chain. The participants cooperate to produce one Schnorr signature under a shared public key. That can preserve a compact verification surface while moving approval policy into the signing ceremony. The operational design of that ceremony is as important as the mathematics.

Key generation determines the trust model

The repository supports trusted-dealer key generation and distributed key generation. A trusted dealer can create and distribute shares efficiently, but that dealer may temporarily know enough secret material to compromise the group if the process is not carefully designed and erased. Distributed key generation lets participants establish the shared key without one dealer constructing the complete secret.

Distributed generation removes one trust assumption and adds coordination complexity. Participants must authenticate each other, preserve messages, handle failures, and know which transcript defines the real key. Share backup and recovery also need policy. A secure threshold can become unusable if too many shares are lost, while weak recovery procedures can quietly recreate a single point of compromise.

Two rounds reduce overhead but do not remove coordination

FROST is designed to reduce network overhead compared with earlier threshold Schnorr constructions. The protocol uses two signing rounds and includes protections against known forgery attacks. Fewer rounds can make remote or hardware-separated signers more practical, especially when latency and intermittent availability matter.

The coordinator still has power over workflow and liveness. Implementers need to validate commitments, bind messages correctly, prevent nonce reuse, identify participants, handle retries, and make the exact payload visible to every signer. A coordinator that cannot steal the key may still censor, delay, reorder, or misrepresent a signing request unless the surrounding application detects it.

Stable crates are not a universal security certificate

The official repository calls the crates stable and feature complete and says their APIs follow Semantic Versioning guarantees. The current reviewed core release is frost-core v3.0.0 from April 2026. Stability is meaningful for integrators because it reduces surprise at the API boundary. It does not prove that a particular product uses the crates correctly or protects shares on real devices.

Ciphersuite choice matters as well. The repository publishes generic core traits and separate crates for curves including Ristretto255, Ed25519, Ed448, P-256, and secp256k1 variants. End users should select the crate matching the intended protocol instead of using frost-core directly as if it were one ready-made signing system.

Read the audit scope literally

NCC audited the version 0.6.0 implementation of frost-core and several named ciphersuite crates, including key generation and FROST signing. The repository says identified issues were addressed and reviewed. It also explicitly says the historical scope did not include the Taproot secp256k1 crate or rerandomized FROST. Later releases contain additional time and code beyond that snapshot.

The honest security statement is therefore neither unaudited nor audited without qualification. A deployment should record the exact crates and versions in use, compare them with the audit commit and scope, review later changes, test protocol failure cases, and protect participant devices. Threshold cryptography can eliminate one dangerous key concentration while leaving ordinary software, identity, backup, and governance failures intact.

FAQ