Crypto custody & compliance · engineering reference
MPC stands for multi-party computation. An MPC wallet splits a private key into shares held by different parties, and those parties compute a signature together without ever reassembling the key on any one machine. Nobody holds a spendable key, so nobody can be robbed of one. This sheet covers the protocols that do it, where to put the shares, what refresh and resharing actually change, and the attacks a threshold does nothing about.
A normal wallet has one private key, and whoever holds it can move the money. An MPC wallet never creates that key. Each participating machine generates a share, and signing is a short conversation between enough of those machines to meet a threshold. The chain receives one ordinary signature and cannot tell the difference.
Multisig puts several real keys on chain and the chain enforces the rule, so anyone can see which keys approved. MPC does the same job off chain and hands the chain a single ordinary signature. That is why MPC works on chains with no multisig support, and also why the chain records nothing about who signed.
Threshold signing protects the key material, not the decision to sign. An attacker who takes over the system that requests signatures gets a valid signature from a perfectly healthy quorum. Every share behaved correctly, and the money is still gone.
Refresh re-randomizes every share while the address stays the same, which makes all older shares useless. The realistic attack is not compromising three machines in one night, it is compromising one this quarter and another next year. Refresh puts a deadline on that.
Carefully, because this is where the scheme quietly collapses back into single-key custody. If you can bring enough shares together in one place to restore, you have rebuilt the single key you were trying to avoid.
If you remember one lineMPC protects the key. It does not protect the decision to sign. Spend your review time on the policy engine.
One worked 2-of-3 wallet: three shares exist, any two of them can sign, and one on its own is useless. Every value here is explained in the sections below.
The proofs describe an ideal protocol. NIST IR 8214 is blunt about how far shipped code can drift from it. Treat the signer, the policy engine, the callback service, the approver device, and the audit store as five separate places an attacker can land, and test each one.
| Term | Precise meaning | Production test |
|---|---|---|
| Share | A secret contribution; never a standalone private key | Exfiltrating one share cannot sign or reconstruct below threshold |
| DKG | Parties jointly create the key; no dealer knows it | Transcript and independently derived public key agree |
| t-of-n | Any t participants can sign; fewer reveal nothing | Exercise every authorized quorum and one below-threshold set |
| Refresh | New shares, same aggregate key and address | Old epoch + new epoch shares do not form a valid quorum |
| Reshare | Change participants or quorum without moving funds | Public key is byte-identical before and after |
| Boundary | MPC protects key use, not transaction intent | POLICY IS SEPARATE |
The math counts shares. Your risk depends on what those shares have in common. Three VMs in one cloud account share an IAM role, a hypervisor, an update channel, and an admin, so that wallet is really 1-of-1 wearing a 2-of-3 label.
Two vendors can both say “GG18” and ship very different code. The GG-family (GG18 → GG20 → CMP → CGGMP) is one lineage built on Paillier homomorphic encryption; DKLs (DKLs18 → DKLS23) is a separate lineage built on oblivious transfer — they don’t share a trust base, so “which generation” and “which family” are different diligence questions. Get the paper revision, the implementation commit, the curve suite, and the audit that actually covered that commit. RFC 9591 was checked August 2026.
| Family | Output / quorum | Rounds & preprocessing | Core assumption | Operational reading |
|---|---|---|---|---|
| Lindell17 | ECDSA · 2-party | Interactive online signing | Paillier + ZK proofs | Historical baseline; use only audited, patched implementations |
| GG18 | ECDSA · t-of-n | Offline presigning + online rounds | Paillier MtA | Dealerless DKG, arbitrary thresholds; heavy interaction, implementation proof validation is security-critical |
| GG20 | ECDSA · t-of-n | Adds identifiable abort | Paillier MtA | Fixes silent denial-of-service by abort; blame does not remove malformed-proof risk |
| CMP | ECDSA · t-of-n | Heavy offline preprocessing; ~1 online round | Paillier + adaptive-adversary proof | Presignatures ready before the transaction exists; that presignature inventory itself becomes security-sensitive state |
| CGGMP | ECDSA · t-of-n | 3 preprocessing rounds + 1 online round; identifiable abort | Paillier + commitments; UC-secure | Modern production baseline; pin paper, code commit, and audit together |
| DKLs18 | ECDSA · 2-party | 2 messages; no Paillier preprocessing | Oblivious transfer | Fast, minimal 2-party case; superseded by DKLS23 for anything beyond two parties |
| DKLS23 | ECDSA · t-of-n | 3 rounds, general threshold | Oblivious transfer | Avoids Paillier/RSA-style assumptions entirely; different implementation and side-channel surface than the GG family |
| FROST (RFC 9591) | Schnorr / EdDSA · t-of-n | 2 signing rounds | Prime-order group + hash | RFC is Informational; coordinator selection remains external |
| MuSig2 (BIP 327) | Schnorr · n-of-n | 2 communication rounds | Key aggregation | Not threshold: every signer is required |
Not the wallet app's lifecycle — the underlying key material's: how the shares behind one address are created, used, rotated, and eventually destroyed. Two of these five operations keep the address you already gave your counterparties. Mix them up with the other three and a routine rotation becomes an incident call.
Every party contributes randomness and proves it played fair. The full private key is never assembled, so there is no moment when one machine could have copied it.
Concrete use: For a 2-of-3 wallet, retain the DKG transcript hash, participant identities, public key, and independently derived first address.
Failure mode: Import an existing seed and split it afterward and the whole key sat on one machine first. Whatever was watching that machine has it.
Each participant checks the same canonical payload, burns one presign package if the protocol uses them, and the group emits a signature the chain cannot tell apart from a single-key one.
Concrete use: Bind request ID wd_20260831_0042, chain ID, nonce, asset, amount, destination, fee ceiling, and policy decision into the audit record.
Failure mode: A quorum will happily sign a payload someone else chose. Compromise the policy engine and the cryptography works perfectly against you.
Every share gets re-randomized while the public key and address stay put. Shares from the old epoch and the new one will not combine, so an attacker who stole one last quarter is left holding a dead number.
Concrete use: Refresh quarterly and after a suspected host compromise; prove completion on all three parties before deleting epoch N material.
Failure mode: A refresh job nobody has restore-tested is a scheduled task you hope works. You find out during an incident.
A live quorum hands a fresh set of shares to a different group, or changes t-of-n, and the funds never move.
Concrete use: Replace a departing 2-of-3 signer with a new HSM and verify the unchanged public key before revoking the old share.
Failure mode: Resharing needs a live quorum. Drop below t surviving shares and there is nothing left to reshare with, and the address is frozen for good.
Sweep the assets out first, then destroy every live share and presign cache. Keep the non-secret audit evidence, because that is what you show later.
Concrete use: After a chain is delisted, sweep all derivation paths, reconcile zero balances, then obtain destruction attestations from each domain.
Failure mode: Delete the vendor workspace with dust or a forgotten token balance still on those addresses and the value is stranded, with nothing left that can sign for it.
For each row, ask what a single attacker has to own to reach two shares. Count IAM roles, hypervisors, update channels, operators, regions, and whoever holds recovery authority. Do not count machines.
| Topology | Correlated failure | Liveness | Recovery | Collusion floor |
|---|---|---|---|---|
| 3 VMs / one cloud account / one IAM role | BROKEN | Fast | Easy | One admin credential |
| Separate cloud accounts, same provider | CONDITIONAL | High | Moderate | 2 account compromises |
| Two cloud providers + on-prem HSM | DIVERSE | Medium | Harder | 2 trust domains |
| Vendor 2 shares + customer HSM share | VERIFY | Vendor-dependent | Exit package required | Vendor + customer or vendor internal quorum |
| Mobile approver + cloud + HSM | DEVICE RISK | High | User lifecycle heavy | 2 device/domain compromises |
An attacker-crafted request that the policy engine approved looks exactly like a legitimate one to the signers. Splitting the key does nothing here.
Concrete use: Require an independently operated callback to compare the payload with ledger intent before any share acts.
Failure mode: One admin over both the policy engine and the shares collapses the whole design back to a single key.
An approver staring at a 32-byte hash has no way to tell where the money goes or what contract call they just authorized.
Concrete use: Decode EIP-712 or chain-native intent on a separate trusted display and bind it to the request.
Failure mode: The screen says one thing and the bytes reaching the signer say another. The approval is real; the description was fiction.
Malware waits for the business approval, then swaps the destination address before the transaction is serialized. Everyone signed what they thought they were signing.
Concrete use: Use allowlists with a 48-hour activation delay and out-of-band confirmation for additions.
Failure mode: Eyeballing the first and last four characters catches nothing. Attackers grind vanity addresses that match both ends.
The protocol cannot tell an honest quorum from a corrupt one. t valid participants who agree to steal is exactly what the design authorizes.
Concrete use: Set role separation so two approvers cannot also administer policy or signer infrastructure.
Failure mode: If a service account drives two of the three shares, your 2-of-3 needs zero humans to sign.
All the chain ever sees is one signature. Which parties took part, and which ones declined, exists only in whatever you logged.
Concrete use: Write append-only participant, policy, payload, and transcript hashes to an external audit store.
Failure mode: The privacy that makes MPC look like a normal wallet is the same property that costs you free on-chain attribution.
A tampered dependency or signer image can bias nonces, leak share material a few bits at a time, or rewrite payloads on the way in.
Concrete use: Pin reproducible builds, SBOM, signatures, audit commit, and measured boot evidence.
Failure mode: The proof covers the paper. It says nothing about the binary you are running.
Pick MPC when you need many chains and an address that survives staff changes. Pick native multisig when you want a cold quorum anyone can verify from the chain itself. Split hot and cold across both when your biggest worry is the vendor.
| Primitive | On-chain footprint | Quorum change | Attribution | Exit failure |
|---|---|---|---|---|
| Threshold MPC | Ordinary single signature | Same address via reshare | Off-chain log only | Need export/reshare package |
| Native multisig | Visible; chain-specific fee | Usually new policy/address | Often visible | Independent signers can survive coordinator |
| Smart-contract wallet | Contract call + execution gas | Upgradeable policy | Event/log dependent | Chain and contract governance remain |
| Single-key HSM | Ordinary signature | Re-key requires move | HSM audit log | Backup/key ceremony determines survival |
| Hybrid MPC hot + multisig cold | Tier-dependent | Independent paths | Mixed | Reduces common vendor failure |
The protocol name on the datasheet is where diligence starts. Everything below is what you still have to make them show you.
Every one of these sails through a vendor demo. Expand one for the control and why it still fails.
Splitting a key that already exists is secret sharing. It gives you the same runtime story as real DKG, minus the one guarantee that mattered.
Concrete use: Mark imported wallets as a distinct assurance class.
Failure mode: Calling it MPC afterward does not un-happen the moment the whole key existed in one place.
Three approvers who all report to the same VP can all be pressured, or fired, by the same person.
Concrete use: Require independent reporting lines for high-value tiers.
Failure mode: The org chart quietly undoes the separation the architecture diagram promised.
An ECDSA-only threshold stack cannot sign for Ed25519 chains like Solana or Cardano. Vendors bridge that gap with raw signing.
Concrete use: Inventory chain signature schemes before procurement.
Failure mode: Raw signing hands the signer bytes nobody parsed, so amount and destination limits never get a chance to fire.
You have exportability once a second implementation has actually restored the shares and produced a valid signature. Until then you have a promise.
Concrete use: Run an annual isolated restore using the contractual package.
Failure mode: The day you need the exit package is the worst possible day to learn the procedure was never run.
Every operational claim above was checked against these first-party documents on 2026-08-31. The examples are illustrative controls, not legal, investment, or vendor-selection advice.