---

name: bitcoin-frost description: | FROST (Flexible Round-Optimised Schnorr Threshold): t-of-n threshold signing on secp256k1. n participants share a key via Distributed Key Generation (DKG) or trusted dealer; any t can produce a Schnorr signature. Differs from MuSig2 (which is n-of-n). USE WHEN: t-of-n threshold custody (e.g., 3-of-5 board signatures) with single-sig appearance on chain, federated services, multi-sig with availability. allowed-tools: Read, Grep, Glob

FROST — t-of-n Threshold Schnorr

FROST is the standard t-of-n threshold Schnorr signature scheme suitable for Bitcoin. Like MuSig2, it produces a single 64-byte BIP340 signature under one aggregated pubkey. Unlike MuSig2 (which requires all n parties to sign), FROST allows any t ≤ n parties to sign.

Key properties

• t-of-n — any t parties can sign, fewer cannot.
• Single-sig appearance — output looks like a regular Schnorr sig on a regular x-only pubkey.
• Two rounds in the FROST signing protocol (after one-time DKG).
• No on-chain multisig — saves bytes and improves privacy.

Two phases

Phase 1: Distributed Key Generation (DKG)

n parties run a DKG protocol to set up shares of a common private key d corresponding to public key P = d * G. No single party ever knows d itself.

DKG variants:

• Pedersen DKG (classical, 2 rounds with broadcast).
• Trusted dealer — one party generates d, hands shares out. Acceptable for some custody models.
• DKG with verifiable secret sharing — using Feldman / Pedersen VSS so parties can verify their shares.

After DKG, each party i has:

• Share s_i (Shamir share of d).
• Public verification key S_i = s_i * G.
• Group public key P = d * G.

Phase 2: Threshold signing

When t parties want to sign message m:

Round 1 (commit)

Each signer i:

1. Generates two ephemeral nonces (d_i, e_i).
2. Computes (D_i, E_i) = (d_i*G, e_i*G).
3. Broadcasts (D_i, E_i) to coordinator.

Aggregation

Coordinator:

• Computes binding factor ρ_i = H(i, m, ((D_j, E_j) for all signers)).
• Computes group commitment R = sum(D_i + ρ_i * E_i).

Round 2 (sign)

Each signer i:

• Computes Lagrange coefficient λ_i for the cooperating subset of size t.
• c = TaggedHash("BIP0340/challenge", R.x || P.x || m).
• Partial sig: z_i = d_i + ρ_i*e_i + λ_i * s_i * c mod n.
• Sends z_i to coordinator.

Aggregation

• s = sum(z_i) mod n.
• Final sig: (R.x, s).

FROST vs MuSig2

Aspect	MuSig2	FROST
Threshold	n-of-n	t-of-n
Setup	trivial (just sum keys)	requires DKG
Round trip	2 rounds + nonce setup	2 rounds + DKG once
Partial sigs	per-signer-key contribution	Lagrange-based with subset selection
BIP	327	445 (draft, PR open)
Bitcoin-specific	yes (BIP340 alignment)	yes (BIP340 alignment)

Use MuSig2 when all n parties always sign together (e.g., 2-of-2 joint custody). Use FROST when subset signing is needed (e.g., 3-of-5 board, 2-of-3 multisig with social recovery).

Implementations

• frost-secp256k1 (Zcash / ZF FROST) — Rust reference.
• secp256k1-frost (bancaditalia/secp256k1-frost) — third-party Banca d'Italia (itcoin) fork of libsecp256k1 adding a secp256k1_frost_* C API; self-described "testing and experimentation" only, and not an upstream module as of September 2026 (see Status below).
• chillDKG (Blockstream research) — practical DKG with state recovery; now a submitted BIP draft (see Status below).
• frostsnap — Rust FROST stack behind the Frostsnap hardware wallet, MIT-licensed firmware + coordinator app (github.com/frostsnap/frostsnap).
• frost-dalek (Ristretto, not Bitcoin-relevant).
• Tools: frost-cli proof-of-concept.

Status for Bitcoin

• BIP 445 — "FROST Signing Protocol for BIP340 Signatures" (Sivaram Dhakshinamoorthy). Number assigned 2026-01-30; Status: Draft, spec version 0.10.0 (2026-08-26) as of September 2026. Submitted as bitcoin/bips#2070 (opened 2026-01-03, still open — no BIP 445 file in the bips repo yet; the README table skips 443 → 446). Specifies the FROST3 variant and adds what RFC 9591 lacks: BIP340 compatibility and key tweaking for BIP32 derivation and BIP341 Taproot. Key generation is explicitly out of scope for BIP 445.
• ChillDKG BIP draft — "ChillDKG: Distributed Key Generation for FROST" (Ruffing, Nick, Melnyk, Zhvanko, Dhakshinamoorthy), Requires: 445, spec version 0.3.0-dev, no BIP number assigned yet. Submitted as bitcoin/bips#2227 on 2026-07-30, still open as of September 2026. Dev repo: BlockstreamResearch/bip-frost-dkg.
• RFC 9591 is not a drop-in for Bitcoin. The IRTF published FROST as RFC 9591 (June 2024), including a FROST(secp256k1, SHA-256) ciphersuite — but its signatures are not BIP340-compatible, because BIP340 uses x-only public keys, and it specifies no key tweaking. An RFC 9591 library dropped into a Bitcoin wallet produces signatures Bitcoin will not accept. Use BIP 445 for signing; for key generation BIP 445 points at either ChillDKG or RFC 9591's own trusted-dealer setup (Appendix C).
• No FROST module in either C library (as of September 2026). bitcoin-core/secp256k1 master ships no FROST module — its module list is in secp256k1/SKILL.md — and secp256k1-zkp has only unmerged FROST pull requests, #138 (opened 2021-07-21) and #278 "FROST Trusted Dealer" (opened 2023-11-23), both still open. C callers have no upstream option; the Banca d'Italia secp256k1-frost fork above is not production-ready (last push 2026-06-11).
• Test deployments: Zcash uses FROST for orchard treasury; Bitcoin custodians experimenting (Coinkite, Lightning Labs research).
• Hardware wallet support: narrow, but no longer absent. Frostsnap ships a FROST-native Bitcoin hardware wallet — on-device DKG so the wallet secret never exists on any one device, arbitrary t-of-n, memory-safe Rust firmware on an ESP32-C3, MIT-licensed with deterministic builds; app/firmware v0.4.0 released 2026-08-25, units orderable with ~10-day delivery as of September 2026. The larger vendors had still not shipped FROST as of 2025.

Security model

• DKG correctness — must use a robust DKG; bad DKG can leak d.
• Nonce uniqueness — same as MuSig2, never reuse nonces.
• Subset binding (ρ_i factor) — defeats the same Wagner-style attack that MuSig2 mitigates.
• Identifiable abort — modern FROST variants identify which party cheated (vs old "round failed, who?" problem).

Use cases in Bitcoin

1. Federated mints (Fedimint guardians).
2. Lightning Service Providers with t-of-n key servers.
3. Wallet recovery social schemes (e.g., 2-of-3 friends).
4. Multi-vendor multisig with availability — currently P2WSH 2-of-3 on chain; FROST collapses to single-sig on-chain.

Common bugs

• Skipping verification step in DKG → silently corrupted shares.
• Reusing (d_i, e_i) nonces across signing sessions → key leak.
• Using non-Lagrange subset coefficients (e.g., linear weights) → produces wrong combined key.
• Mixing FROST and MuSig2 nonce derivation in a unified library and conflating tag domains.

See also

• musig2/SKILL.md
• schnorr/SKILL.md
• ../../l2/fedimint/SKILL.md