Imagine three executives who must collectively authorize wire transfers, a custody service guarding crypto assets across geographically separate machines, or a certificate authority that does not want any single operator able to sign on its behalf. The shared requirement: an action that needs multiple parties to agree, with no individual able to act alone, and ideally no single machine that — if compromised — hands an attacker the full signing power.
There are several ways to approximate this, and they are not equally good. Understanding why threshold signatures win for many of these cases means understanding what the alternatives leak.
The Three Approaches, and Their Seams
Secret sharing
Shamir's Secret Sharing splits a key into n shares such that any t reconstruct it and fewer reveal nothing. It's elegant for protecting a key you rarely use. But the act of using the key requires reassembling it — gathering t shares onto one machine, which becomes a single point of total compromise at exactly the moment of highest value. The full key briefly exists. An attacker who owns that machine during signing owns everything.
Multisignature (multisig)
Multisig, familiar from Bitcoin, takes a different route: each party has a fully independent key, and the verifier checks that t separate signatures are present. No key is ever combined — a real strength. The cost is on the verification side: the signatures are visible as multiple distinct signatures, the policy (who signed, how many are required) is exposed on-chain or on the wire, and the size and fees grow with the number of signers. It works, but it advertises its own structure.
Threshold signatures
A threshold signature scheme (TSS) gives you the best of both. Like multisig, no party holds the whole key. Unlike multisig, the parties run an interactive protocol that outputs one ordinary signature — indistinguishable from a signature made by a single key. The verifier sees a normal signature against a single public key and has no idea, from the signature alone, that a quorum of five machines in four countries produced it.
In a threshold scheme the full private key is never assembled — not during setup, not during signing, not ever. It exists only as a mathematical relationship distributed across the participants' individual key shares. There is no instant where stealing one machine's memory yields the whole secret.
Where FROST Comes In
Threshold Schnorr signatures are appealing because Schnorr signatures are clean and linear, which makes them friendlier to "split across parties" math than ECDSA. But early threshold Schnorr constructions needed multiple interactive rounds of communication for every signature, and were fragile in the face of concurrent signing sessions — a serious problem for any real service handling parallel requests.
FROST — Flexible Round-Optimized Schnorr Threshold signatures, introduced by Komlo and Goldberg in 2020 and specified by the IETF in RFC 9591 (2024) — solved the practicality problem. Its headline properties:
- Round efficiency. Signing takes a single round of interaction when participants pre-process commitments in advance, or two rounds without pre-processing — a major improvement over earlier multi-round schemes.
- Concurrency safety. FROST is designed to remain secure even when many signing sessions run at once, avoiding the ROS-style attacks that broke naive parallel Schnorr signing.
- Standard output. The result is a normal Schnorr signature, verifiable with the ordinary single-key verification algorithm. No special verifier is needed.
- Flexible thresholds. Any t-of-n policy, configurable at key-generation time.
How a FROST Signature Comes Together
Without drowning in notation, the shape of the protocol is:
- Distributed key generation (DKG). The n participants jointly run a protocol that produces a shared public key and gives each participant a private share. No party — and no coordinator — ever sees the corresponding full private key. (A trusted dealer can alternatively distribute shares, but DKG removes even that single point of trust.)
- Commitment. Each of the t signers picks fresh random nonces and publishes commitments to them. With pre-processing, this happens before the message to sign is even known.
- Signing. Given the message, each signer computes a partial signature using its share and its nonces, binding in the others' commitments to prevent manipulation.
- Aggregation. A coordinator (who needs no secret material) sums the partial signatures into one final Schnorr signature. The coordinator can verify each partial contribution, so a misbehaving signer can be identified rather than silently corrupting the result.
The randomness handling deserves emphasis. Schnorr signatures are catastrophically broken by nonce reuse — repeat a nonce and the private key falls out of the algebra. Distributing signing across parties multiplies the ways nonce handling can go wrong, which is exactly why FROST's careful, binding commitment structure (and its concurrency analysis) is the substance of the scheme, not a detail.
Threshold vs Multisig, Compared
| Property | Multisig | Threshold (FROST) |
|---|---|---|
| Full key ever assembled | No | No |
| Output signature | Multiple, distinct | One, ordinary |
| Policy visible to verifier | Yes — exposes signers/threshold | No — looks single-key |
| Size / cost scaling | Grows with signers | Constant |
| Needs interaction to sign | No (signers act independently) | Yes — signers coordinate |
| Verifier complexity | Must understand the policy | Standard verification |
The trade-off is real: threshold signing requires the participants to be online and to interact during signing, whereas multisig signers can act fully independently. That interactivity, plus the subtlety of getting the protocol right, is the price of the privacy and uniformity benefits.
A threshold signature is the cryptographic version of a rule that says "this door needs three keys turned at once, but anyone watching it open just sees a door open." The structure of the authority is invisible from outside.
Where You'll Encounter It
Threshold and multi-party signing now underpin institutional crypto custody, hot-wallet protection, distributed certificate authorities, and the signing infrastructure behind some software supply-chain and code-signing systems. The common thread is high-value signing authority that no single person or machine should be able to exercise alone — and that benefits from not advertising its own governance structure to everyone who checks a signature.
It is not a tool for everyday application authentication; the interactivity and operational complexity only pay off when the signing key is genuinely catastrophic to lose. For most systems, simpler controls are the right answer. But where the stakes justify it, FROST is the current state of the art for doing it efficiently.
Where Haven Fits
Haven doesn't ask you to run a quorum to send a message — that would be the wrong tool for personal communication. But the underlying principle is exactly the one we build on: no single party should hold the power to read or impersonate you. In Haven, your keys are derived on your device and never assembled on a server we could be compelled to hand over. Threshold cryptography is the institutional expression of the same idea we apply at the individual level — distribute trust so there is no one place an adversary can break to win everything. If you found this useful, our pieces on elliptic-curve cryptography and forward secrecy dig into the primitives underneath.