FROST stands for Flexible Round-Optimized Schnorr Threshold. It is a threshold signing protocol in which enough participants sign under a shared public key without assembling the entire secret key in one place during signing.
In a 2-of-3 scheme, two available authorized shares suffice, while one cannot produce a signature. An attacker who obtains two can also meet the threshold. A long-term key share is not a partial signature of a particular message; signing requires the joint protocol and fresh one-time values. [RFC 9591 — FROST]
A trusted dealer can create the secret and distribute shares, so it knows the entire key and must handle it securely. DKG enables joint generation without that single dealer but adds its own communication and verification. RFC 9591 primarily specifies signing; its dealer appendix does not mean every deployment automatically uses DKG. [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
In round one a participant creates two secret nonces and shares their public commitments. In round two it verifies the message, participant list and its own commitments, then computes its signature share. A coordinator aggregates the shares. Binding factors tie nonces to the particular message and commitment set; the two rounds exclude prior key generation. [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
Nonce reuse can expose secret key material. Secret nonces must be securely retired after use even in an aborted attempt; restoring an old backup must not make them usable again. Randomness, concurrent sessions and durable consumption tracking are part of security, not merely speed optimizations. [RFC 9591 — FROST]
The coordinator collects commitments and signature shares; without enough key shares it has no authority to sign alone. It can nevertheless withhold messages or cause an abort. Checking a faulty share may identify its originator, not guarantee that a session finishes. Authenticated transport and enough available participants remain necessary. [RFC 9591 — FROST]
For Bitcoin the result must satisfy the exact encoding, hashing and rules of BIP 340 and any Taproot key tweaks. Merely choosing secp256k1 in a generic FROST ciphersuite is insufficient. ZF provides separate frost-secp256k1-tr for Taproot; verify the specific suite and its tests. One on-chain signature alone does not reveal the internal threshold. [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
A share needs its correct identifier, group public information and compatible software. Recovering a lost share with others or refreshing shares involves further protocols that the deployment must actually support. Copying the same share does not add an independent participant. Backups must preserve the threshold while preventing consumed nonces from returning. [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
Every signer should check recipients, amounts, fees and approval rules rather than blindly sign a coordinator-supplied hash. FROST provides joint signing, not correctness of the business intention. Before use, verify the implementation version, recovery procedure and failure behaviour; an informational RFC does not certify the entire wallet. [RFC 9591 — FROST]
For the clearest picture, read this entry together with Schnorr signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing.