MPC and Threshold Signatures
Prerequisite: Security Model, Blockchain Fundamentals
Your hot wallet’s private key sits in an HSM in us-east-1. An insider with HSM access — or an attacker who compromises the credentials that control the HSM — can sign any transaction. There is no second check, no approval gate, no way to distinguish a legitimate $50 transfer from a $50 million drain. The key is a single point of failure, and the blast radius is the entire wallet balance.
Multi-party computation eliminates the single key. Instead of one secret that one party holds, multiple parties each hold a share of the key material. No individual share is sufficient to sign a transaction. The parties collaborate — using a cryptographic protocol that never reconstructs the full key — to produce a valid signature. An attacker must compromise multiple independent parties simultaneously.
Threshold Schemes
A threshold signature scheme is defined by two numbers: t (the threshold) and n (the total number of parties). Any t-of-n parties can collaborate to produce a valid signature. Fewer than t parties learn nothing about the key — not even a partial signature.
| Configuration | Meaning | Use case |
|---|---|---|
| 2-of-3 | Any 2 of 3 parties must agree | Small team, fast signing |
| 3-of-5 | Any 3 of 5 parties must agree | Mid-size treasury, some redundancy |
| 5-of-8 | Any 5 of 8 parties must agree | Large institutional custody |
| 2-of-2 | Both parties must agree | Client-server co-signing |
The choice of t and n balances security against availability. A 2-of-3 scheme tolerates one compromised party (an attacker needs two) and one unavailable party (two can still sign). A 5-of-8 scheme tolerates four compromised parties and three unavailable ones. Raise t and you harden against collusion but increase the operational cost of every signing operation. Lower t and a smaller coalition can drain the wallet.
A threshold scheme where t ≤ n/2 allows a minority of parties to sign. This is appropriate when the parties are trusted infrastructure nodes. It is dangerous when the parties include external actors who might collude.
MPC vs Multi-Sig
Multi-sig and MPC both require multiple parties to authorize a transaction. The difference is where the coordination happens.
Multi-sig coordination is on-chain. Each party signs independently with their own key, and the smart contract verifies that enough valid signatures are present. The transaction carries m signatures, each from a distinct key. On Ethereum, a Gnosis Safe checks signatures.length >= threshold against registered owners. On Bitcoin, OP_CHECKMULTISIG validates k-of-n public keys.
MPC coordination is off-chain. The parties run a distributed signing protocol that produces a single standard signature from a single public key. The blockchain sees one signature from one key — indistinguishable from a transaction signed by a single party.
| Dimension | Multi-sig | MPC |
|---|---|---|
| On-chain footprint | Multiple signatures, larger transaction | Single signature, standard size |
| Gas cost (Ethereum) | ~60K gas per additional signer | Standard ~21K gas |
| Chain support | Requires chain-level multi-sig support | Works on any chain with standard signatures |
| Key rotation | Change on-chain contract state | Off-chain resharing, no on-chain change |
| Privacy | Signing policy visible on-chain | Signing policy hidden |
| Recovery | Per-key recovery | Share redistribution |
MPC costs less gas per transaction. A 3-of-5 multi-sig on Ethereum costs approximately 150K–200K gas (base 21K plus ~40K per ECRECOVER). MPC produces a single ECDSA signature: 21K gas, regardless of how many parties participated. At 50 gwei gas price, the difference is $15–25 per transaction. At 1,000 transactions per day, that is $15K–25K per month.
MPC also works on chains that have no native multi-sig support. Bitcoin’s OP_CHECKMULTISIG has been available since 2012, but Solana’s transaction model makes on-chain multi-sig cumbersome. MPC produces a standard Ed25519 signature that Solana processes without modification.
The Signing Protocol
MPC signing happens in three phases: key generation, signing, and (optionally) key resharing. No phase ever reconstructs the full private key.
Distributed Key Generation (DKG)
Each party generates a random secret share and broadcasts commitments to the other parties. The protocol produces two outputs: a shared public key (known to everyone) and individual secret shares (each party holds one, knows nothing about the others).
The DKG ceremony runs once per key. It requires all n parties to be online simultaneously. Duration varies by implementation: Fireblocks completes DKG in under 5 seconds for a 3-of-5 configuration. Turnkey’s infrastructure-grade DKG runs in sub-second times for 2-of-2 configurations.
Distributed Signing
When a transaction needs signing, t parties run a multi-round protocol:
- Round 1: Each party computes a partial signature from their share and a fresh random nonce. Each party broadcasts a commitment to their nonce.
- Round 2: Each party reveals their nonce and partial signature. The coordinator (or any participant) combines the partial signatures into a complete ECDSA or EdDSA signature.
The number of communication rounds depends on the protocol:
| Protocol | Rounds | Pre-signing | Key type |
|---|---|---|---|
| GG18 | 8 | No | ECDSA |
| GG20 | 4 | Yes (1 offline round) | ECDSA |
| CGGMP21 | 4 | Yes | ECDSA |
| FROST | 2 | Yes (1 offline round) | Schnorr/EdDSA |
GG20 and CGGMP21 support pre-signing: parties complete most computation in an offline phase, reducing the online signing phase to 1–2 rounds. Fireblocks uses a variant of GG20/CGGMP21. Pre-signing reduces signing latency from ~1 second to ~200ms for a 3-of-5 configuration.
Key Resharing
Key resharing changes the set of parties or the threshold without generating a new key. The old parties run a protocol that produces new shares for a new set of parties. After resharing, the old shares are cryptographically useless — even if an attacker collected t−1 old shares, they cannot combine them with new shares.
Resharing enables:
- Key rotation without changing the public key or on-chain addresses
- Party replacement when a device is lost or an employee leaves
- Threshold changes from 2-of-3 to 3-of-5 as security requirements grow
The public key remains the same. No on-chain migration, no new addresses, no customer-facing changes.
Architecture Patterns
Client-Server Co-Signing (2-of-2)
The simplest MPC deployment. The client (mobile app or browser) holds one share. The server holds the other. Every transaction requires both parties — the user’s intent (client share) and the platform’s approval (server policy check).
Turnkey uses this model. The user’s share lives in an iframe-isolated enclave on the client. The server share sits in an AWS Nitro Enclave with attestation. Neither party can sign alone. The server enforces spending policies (amount limits, destination whitelists, velocity checks) before contributing its partial signature.
Signing latency: 100–300ms for the full protocol, including network round trips. The user sees no difference from a standard single-key signing flow.
Institutional Custody (t-of-n)
For treasury operations and large reserves. Shares are distributed across geographic regions, organizational roles, and infrastructure providers.
A typical 3-of-5 deployment:
| Share holder | Location | Storage |
|---|---|---|
| CTO | US East | Hardware token (YubiKey) |
| CFO | US West | Hardware token (YubiKey) |
| Head of Security | EU | HSM in secure facility |
| Automated policy engine | Cloud (us-east-1) | AWS Nitro Enclave |
| Disaster recovery | Cold storage | Paper backup in vault |
The automated policy engine holds one share and contributes it automatically for transactions that pass policy checks (under $50K, to whitelisted addresses, within daily limits). Transactions that exceed policy require a human share holder to approve. This creates a tiered authorization model: routine transactions need 2 humans plus the policy engine (effectively 2-of-4 human approval), exceptional transactions need 3 humans (3-of-4 human approval).
Fireblocks processes over $6 trillion in cumulative transaction volume using this model. Signing latency for automated approvals: under 1 second. Signing latency with human approval gates: minutes to hours, depending on policy configuration.
Geographic Distribution
Distributing shares across jurisdictions protects against coercion, subpoena, and physical compromise. A 3-of-5 scheme with shares in the US, EU, Singapore, and two additional locations means no single government can compel enough shares to sign.
The tradeoff is signing latency. Cross-region MPC rounds add network latency: US-East to Singapore is ~250ms round trip. A 4-round signing protocol across three geographies adds ~1 second of network overhead. Pre-signing moves this overhead to the offline phase, keeping online signing under 500ms.
Operational Security
Nonce Management
The signing protocol’s security depends on fresh, random nonces. Reusing a nonce across two signing operations with the same share leaks the share — this is the same vulnerability that broke the PlayStation 3’s ECDSA implementation and has drained multiple cryptocurrency wallets.
MPC libraries handle nonce generation internally, but the operational risk is in the pre-signing phase. Pre-computed nonces must be stored securely and used exactly once. If a system crash causes a pre-signed nonce to be reused, the share is compromised. Production implementations use persistent, append-only nonce logs with deduplication checks before every signing operation.
Incident Response
When a share is suspected compromised:
- Reshare immediately. Generate new shares for all parties except the compromised one. The compromised share becomes cryptographically useless after resharing.
- Do not move funds first. The compromised party holds fewer than t shares — they cannot sign. Resharing is the containment action, not an emergency withdrawal.
- Audit the signing log. Every MPC signing operation should produce an audit record: which shares participated, the policy check result, the transaction hash. Review for unauthorized signatures.
The resharing operation takes seconds for most configurations. The window between compromise detection and resharing completion is the exposure period. Automating the detection-to-resharing pipeline reduces this window to under a minute.
See Security Model. MPC distributes the signing authority, but the policy layer — spending limits, destination whitelists, velocity checks — is equally critical. A correctly functioning MPC system that approves a malicious transaction has fulfilled its cryptographic obligations and failed its security purpose.
Choosing Between MPC and Multi-Sig
Use multi-sig when you want the signing policy visible on-chain and enforceable by the contract — governance DAOs, shared treasury management, and systems where the approval structure is part of the protocol’s trust model.
Use MPC when you need standard transaction format, lower gas costs, cross-chain portability, or when revealing the signing policy on-chain creates a security risk. MPC is the dominant choice for institutional custody, exchange hot wallets, and payment systems that operate across multiple chains.
The two are not mutually exclusive. A multi-sig contract where each signer is itself an MPC key provides both on-chain governance and key-level security. The contract enforces the macro policy (3-of-5 role approval). The MPC protects each role’s key from single-point compromise. Fireblocks offers this layered model for clients who require both smart-contract-enforced governance and MPC-grade key security.