Threshold Signatures Explained: Distributed Signing

Introduction

In 2023, a single compromised private key drained over $600 million from the Ronin bridge — a cross-chain system that relied on a small set of individually held keys to authorize transactions. The attacker only needed to compromise five of nine validators because each one held a complete signing key in isolation. Threshold signatures would have prevented the full key from ever existing on any single machine in the first place.

A threshold signature scheme distributes signing authority across multiple participants so that a minimum number — the threshold — must cooperate to produce a valid signature. The private key is never assembled in one location, not during creation, not during signing, and not during storage. The result looks identical to a conventional digital signature, which means existing systems verify it without modification.

NIST considers this problem important enough to have launched a formal Multi-Party Threshold Cryptography project and issued NIST IR 8214C, a public call for threshold scheme submissions. Whether you manage cryptocurrency custody, enterprise certificate authorities, or cloud key infrastructure, threshold signatures are becoming the standard approach to eliminating the single biggest vulnerability in digital signing: a single private key sitting on a single device.

What Are Threshold Signatures?

A threshold signature scheme (often abbreviated TSS) is a cryptographic protocol that splits signing power across n participants, requiring at least t of them to cooperate before a valid signature can be produced. Cryptographers describe this as a t-of-n scheme — for example, a 3-of-5 setup means any three out of five participants can sign, but two participants together learn nothing useful about the key.

The concept traces back to 1991, when Yvo Desmedt and Yair Frankel published “Shared Generation of Authenticators and Signatures” at the IACR’s CRYPTO conference. Their work extended Shamir’s Secret Sharing — which splits a static secret into shares — into the domain of active computation, enabling participants to sign messages without ever reconstructing the underlying key.

What makes threshold signatures fundamentally different from simply splitting a key and reassembling it is that the complete private key never exists at any point in the protocol. Each participant holds a key share, and the signing protocol produces a valid signature through a coordinated mathematical process. An attacker who compromises fewer than t participants gains zero information about the private key — not partial information, not a weakened key, but mathematically provable zero knowledge.

The output is a standard digital signature that any verifier can check using the corresponding public key. There is no way to tell from the signature alone whether it was produced by one signer or by a threshold group.

How Threshold Signatures Work

The process unfolds in three phases. Each phase keeps the full private key distributed so it never materializes in any single location.

1. Distributed Key Generation (DKG). Instead of one person creating a private key and splitting it (which would create a single point of failure during creation), all n participants run a distributed key generation protocol together. Each participant generates a random secret, shares encrypted fragments of it with every other participant, and the group collectively derives a shared public key. At the end, each participant holds their own unique key share, but no participant — and no subset smaller than t — can reconstruct the full private key. This approach eliminates the need for a trusted dealer.

2. Distributed Signing. When the group needs to sign a message, at least t participants engage in an interactive protocol. Each participant uses their key share to compute a partial signature — a mathematical fragment that contributes to the final result. These partial signatures are combined using polynomial interpolation (the same mathematical foundation behind Shamir’s Secret Sharing) to produce a single, complete signature. The private key is never reconstructed during this process.

3. Standard Verification. The resulting signature is verified using the group’s public key, exactly the same way you would verify any conventional digital signature. The verifier does not need to know that threshold signing was used, how many participants contributed, or what the threshold was. This transparency is one of the strongest practical advantages of TSS: it is backward-compatible with all existing verification infrastructure.

The number of communication rounds required during signing depends on the specific protocol. Older threshold ECDSA protocols like GG18 and GG20 (by Gennaro and Goldfeder, published through IACR and ACM) require multiple interactive rounds with complex zero-knowledge proofs. Newer protocols like FROST (Flexible Round-Optimized Schnorr Threshold signatures), currently being standardized by the IETF as RFC 9591, reduce signing to just two rounds by using Schnorr signatures, which are algebraically simpler to distribute.

VIDEO · READY 16:9

PLAY

Introduction to Threshold Signatures in 9 Minutes

Threshold Signatures vs Multisig

Both threshold signatures and multisig (multi-signature) schemes aim to distribute signing authority across multiple parties. However, they achieve this goal through fundamentally different mechanisms, and those differences have major practical consequences.

Multisig operates on-chain: each participant generates their own independent key pair, produces their own full signature, and the blockchain protocol or a smart contract verifies that enough valid signatures were submitted. The signing policy — how many signers are required, who they are — is encoded in the transaction itself and visible to anyone inspecting the chain.

Threshold signatures operate off-chain: participants collaborate cryptographically to produce a single standard signature. The blockchain sees only one signature, one public key, and a normal-looking transaction.

The privacy advantage matters more than it might seem. When a multisig wallet publicly reveals a 3-of-5 signing policy, an attacker knows exactly how many parties they need to compromise. With threshold signatures, the attacker cannot even determine from the blockchain that distributed signing is being used.

The cost difference also compounds. On Ethereum, a multisig transaction that requires three separate ECDSA signature verifications consumes roughly three times the gas of a single-signature transaction. A threshold signature transaction consumes the same gas as any standard transaction because the chain verifies just one signature.

Real-World Use Cases

Institutional cryptocurrency custody. Exchanges and custodians like Fireblocks, Coinbase, and BitGo use threshold ECDSA to protect billions of dollars in digital assets. A 3-of-5 threshold scheme distributes key shares across geographically separated hardware security modules, so an attacker who breaches one data center cannot move funds. Share refreshing lets these custodians rotate participants — for example, when an employee leaves — without generating a new wallet address, which would require migrating all associated assets.

Certificate authority root key protection. The public key infrastructure that secures TLS connections across the internet depends on root certificate authority keys. Compromising a root CA key would allow an attacker to issue fraudulent certificates for any domain. Major CAs use threshold signing to ensure that their root key is never present on a single HSM — multiple HSM operators in different locations must cooperate to sign a certificate, and the root key itself never exists in extractable form.

Enterprise key management with compliance requirements. Organizations subject to SOC 2 or PCI DSS requirements use threshold signatures to enforce dual-control policies over cryptographic keys. Instead of relying on procedural controls (a policy document saying two people must be present), threshold signing makes dual control mathematically unavoidable — a single administrator simply cannot produce a valid signature, regardless of their access level.

Common Mistakes to Avoid

Using a trusted dealer to create and split the key. If one person generates the full private key and then distributes shares, that person is a single point of failure. Use proper distributed key generation so the full key never exists, not even for an instant.

Setting the threshold too low. A 2-of-10 scheme sounds robust because you have ten participants, but an attacker only needs to compromise two. Choose a threshold that reflects your actual threat model. For high-value assets, a threshold of at least half the participants (e.g., 4-of-7 or 5-of-9) provides a stronger security margin.

Ignoring the communication channel. Threshold signing protocols require participants to exchange messages. If those messages travel over an unauthenticated channel, a man-in-the-middle attacker can tamper with partial signatures or impersonate participants. Always use authenticated, encrypted channels between signers.

Skipping identifiable abort. Older threshold protocols cannot tell you which participant caused a signing failure. Modern protocols like GG20 and FROST support identifiable abort, meaning the group can determine exactly who misbehaved and exclude them. Without this feature, a single malicious participant can repeatedly block signing with no accountability.

Treating key shares like ordinary backups. Key shares are not interchangeable backup copies. Storing multiple shares in the same location defeats the purpose of distribution. Each share must be stored independently, ideally on separate hardware security modules or in different physical locations, with its own access controls.

Neglecting share refreshing. If the same key shares remain static for years, a patient attacker can gradually compromise them one by one. Proactive secret sharing generates new shares for the same underlying key on a regular schedule, so previously stolen shares become useless. NIST IR 8214C explicitly includes proactive threshold schemes in its call for submissions because of this operational importance.

Getting Started

Understand your signing requirements first. Before choosing a threshold scheme, define the questions that shape your architecture: how many participants will hold shares, what threshold provides adequate security without creating availability risk, and whether your verifiers expect ECDSA, EdDSA, or Schnorr signatures. A 3-of-5 configuration is a common starting point — it tolerates two compromised or unavailable participants while requiring meaningful consensus.

Choose the right protocol for your signature algorithm. If you need ECDSA compatibility (required by Bitcoin, Ethereum, and most existing TLS infrastructure), evaluate implementations of the GG20 or CGGMP protocols. If you can use Schnorr signatures (supported by Bitcoin Taproot, Ed25519 systems, and increasingly by modern applications), FROST is the preferred choice — it is simpler, faster, and currently being standardized through the IETF. For BLS signatures (used in Ethereum’s consensus layer and many proof-of-stake protocols), threshold signing is algebraically native and does not require complex MPC machinery.

Follow NIST’s threshold cryptography guidance. NIST’s Multi-Party Threshold Cryptography project provides the most authoritative framework for evaluating threshold schemes. Review NIST IR 8214A for the roadmap and criteria, and monitor NIST IR 8214C submissions for vetted, peer-reviewed implementations. The project distinguishes between single-device threshold schemes (for side-channel resistance) and multi-party schemes (for distributed trust), so make sure you are looking at the right track for your use case.

Implement share refreshing from day one. Do not treat share refreshing as an optional feature you will add later. Build your system so that key shares are rotated on a regular schedule — quarterly is a reasonable starting cadence for most enterprise deployments. This limits the window in which a compromised share remains useful and ensures that departing participants lose their signing authority automatically.

Audit the implementation, not just the protocol. Threshold signature protocols are mathematically sound, but real-world vulnerabilities often come from implementation errors — missing range-proof checks in GG18/GG20 implementations have led to demonstrated key-extraction attacks. Use implementations that have undergone independent security audits, and verify that those audits covered the specific protocol version you are deploying. The NIST submission process for threshold schemes requires open-source reference implementations, which provides a baseline for comparison.

If you are already using Shamir’s Secret Sharing for key backup, threshold signatures are the natural next step — they extend the same mathematical foundation from passive key splitting to active distributed signing, without ever reassembling the key. For organizations managing encryption keys across cloud providers, threshold signing adds a trust distribution layer that no single cloud provider can override.