FROST
FROST (Flexible Round-Optimized Schnorr Threshold signatures) is a two-round threshold signature protocol. Any subset of k honest participants out of n can produce a single BIP340 Schnorr-compatible signature for a shared public key, and fewer than k cannot. With a Bitcoin-compatible ciphersuite the result verifies like an ordinary Schnorr signature. FROST is specified in RFC 9591. It is not a Bitcoin consensus change and is not a BIP. It is an off-chain signing protocol whose output is a normal signature.
Script-based k-of-n multisignature publishes keys and multiple signatures on chain. MuSig (MuSig2) aggregates keys into one on-chain key but requires every listed participant to sign (n-of-n). Threshold Schnorr schemes share the secret so only k shares are needed to sign.
Signing
FROST, described by Chelsea Komlo and Ian Goldberg, binds each signer to a nonce commitment before the challenge is known, which addresses earlier forgery attacks on naive threshold Schnorr designs. Signing uses two rounds of commitments and signature shares. A coordinator may assemble shares into one signature. Nonce reuse across sessions can leak key material. Partial signature shares must be verified before they are combined. A coordinator that skips share verification can output an invalid aggregate signature and waste a signing round without learning the group secret.
RFC 9591 also describes identifiable abort for some failure cases so honest parties can recognize a misbehaving participant's share. Removing the coordinator role is possible when signers broadcast commitments among themselves, at higher communication cost.
A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a Taproot internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.
Key generation
Distributed key generation must produce verifiable shares before signing. Many deployments use a dealer or a multi-round DKG so that no single machine ever holds the full secret. A dishonest coordinator can bias which honest subset completes a signing session, but cannot forge a BIP340-valid signature without k valid shares. Implementations that target Bitcoin should document their ciphersuite and Taproot tweak handling explicitly.
Threshold wallets must define what happens when signers go offline between DKG and spending. Refreshing shares (proactive security) is optional in RFC 9591 deployments and must be documented if used. Lost shares below the threshold stall signing until a refresh or a recovery path in the Taproot tree is available.
Ciphersuites and Bitcoin
RFC 9591 defines several ciphersuites, including FROST(secp256k1, SHA-256). Bitcoin wallets that want BIP340 verification must additionally follow x-only key encoding and the Taproot challenge hash as in BIP340 and BIP341. A ciphersuite that verifies on Ed25519 or P-256 is not interchangeable with on-chain Bitcoin verification even when the FROST round structure is the same.
Because the published signature is an ordinary Schnorr signature, explorers and nodes do not learn k or n. Operational security still depends on share storage, the honesty threshold, and whether a script-path backup exists when too many sharers disappear.
Status
FROST is deployed in threshold-custody and multiparty wallet stacks outside Bitcoin Core consensus. There is no single Bitcoin BIP that mandates one FROST ciphersuite. Integrators should treat RFC 9591 plus their BIP340/BIP341 mapping as the specification surface and publish test vectors for their exact tweak and encoding choices.
Compared with MuSig2, FROST fits custody settings where not every key holder can be online for every spend. Compared with on-chain multisig Script, it hides the threshold policy on key-path spends and produces a smaller witness.