DKLS23 is a multiparty threshold ECDSA protocol. Any t of n participants can jointly sign a message — and the output is a standard single ECDSA signature. No trusted setup. No single point of failure.
The full private key never exists — not during generation, not during signing. Yet the output is a perfectly standard ECDSA signature.
The resulting signature is a standard (r, s) ECDSA pair. On-chain or off-chain verifiers see no difference from a single-party signature.
Unlike GG18/GG20, DKLS23 requires no trusted dealer or MPC ceremony to bootstrap. Key generation is fully distributed from the start.
Signing completes in just two communication rounds using OT extension, making it practical for real-time applications and blockchain transactions.
Choose any threshold: 2-of-3, 3-of-5, 7-of-10. Any qualifying subset of signers can produce a valid signature — without involving absent parties.
Security is based solely on the hardness of ECDSA — no additional assumptions like DDH or Paillier encryption are required.
On-chain verification uses the same ecrecover as single-sig. No extra verification logic, no additional smart contract cost.
A walkthrough of the two core phases: distributed key generation and threshold signing.
Each of the n participants generates their own random secret share xᵢ. Through a Verifiable Secret Sharing (VSS) protocol, parties exchange commitments so that no single party ever holds the complete private key x. The combined public key X = x·G is publicly known.
The heart of DKLS23 is using OT extension to allow two parties to perform a multiplication of their secret shares without revealing the values. Party A learns a·b while Party B learns nothing about a.
When t parties want to sign a message, they first jointly generate a nonce k using an OT-based multiplication. Each party contributes a share kᵢ. They publish the nonce's public point R = k·G, from which the signature's r value is derived.
Each party computes a partial signature share using their key share xᵢ and nonce share kᵢ on the message hash H(m). A designated combiner aggregates these into the final s value, completing the standard (r, s) signature.
Configure your threshold, generate key shares, sign a message, and verify — step by step.
Each party generates a random key share. Commitments are exchanged so the group can compute the joint public key.
Select t signers and sign a message. Real SHA-256 hash, real Shamir reconstruction, real secp256k1 signature.
Standard ECDSA verification against the joint public key. On-chain this is identical to ecrecover.
The threshold determines both security and availability. Higher thresholds mean stronger security; lower thresholds mean higher fault tolerance.
| Config | Fault Tolerance | Use Case |
|---|---|---|
| 2-of-2 | 0 faults | 2FA-style authorization |
| 2-of-3 | 1 fault | Personal wallets, small teams |
| 3-of-5 | 2 faults | Enterprise, DAO governance |
| 4-of-7 | 3 faults | Bridge validators, custody |
| 5-of-9 | 4 faults | High-value institutional |
Fault tolerance = n - t. The number of parties that can crash or be compromised without breaking availability. Security threshold = t - 1 parties must be corrupted before security is broken.
How does DKLS23 stack up against popular threshold ECDSA alternatives?
| Protocol | Trusted Setup | Sign Rounds | Keygen Rounds | Security Assumption | Sig Output | Status |
|---|---|---|---|---|---|---|
| DKLS23 | None | 2 | 3 | ECDSA only | Standard ECDSA | Active |
| GG18 | Paillier | 8 | 5 | Paillier + DDH | Standard ECDSA | Legacy |
| GG20 | Paillier | 7 | 5 | Paillier + DDH | Standard ECDSA | Widely deployed |
| FROST | None | 2 | 2 | DL assumption | Schnorr only | Active |
| Lindell17 | Paillier | 4 | 3 | Paillier + Strong RSA | Standard ECDSA | 2-party only |
Any application needing distributed custody or authorization over an ECDSA key.
MPC wallets where no single server holds the full private key. Standard blockchain transactions with no key reconstruction.
Validator committees sign bridge transactions. t-of-n threshold matches existing validator quorum requirements.
Multisig that looks like a single wallet on-chain, eliminating gas overhead of on-chain multisig contracts.
Distribute key material across cloud regions or hardware. No single hardware failure can compromise the key.
2-of-2 split between user device and server. Biometric on device, rate-limiting on server — without ever combining.
Threshold signing for autonomous agents — require human co-signature above certain transaction values.
Papers, implementations, and benchmarks for production use.