Engineering Pitfalls of MPC Wallets and Threshold Signatures

This article has three layers:

1. Layer 1: The Intuition: From "splitting keys" to "never reassembling keys"
2. Layer 2: Real-World Use: Institutional custody, exchanges, personal MPC wallets, and real vulnerabilities
3. Layer 3: Mathematics and Engineering details: The difficulty gap between threshold Schnorr and threshold ECDSA, share refreshing, and implementation checklists

Layer 1: The Intuition

1.1 From "Splitting Keys" to "Never Reassembling Keys"

1.2 An Analogy

Three people each know one part of a number, and they want to collectively calculate the result of "this number multiplied by a public number." Through a carefully designed set of rules for exchanging information, all three eventually obtain the correct result, but no one learns the complete number. Threshold signatures do something similar, except "multiplication" is replaced by signature computation.

Layer 2: Real-World Use

• Institutional Custody and Exchanges: Custody systems for institutions like Fireblocks and Coinbase make extensive use of MPC, distributing shares across different servers, different clouds, and Hardware Security Modules (HSMs).
• Personal MPC Wallets: A typical configuration is "one share on the phone, one share with the service provider, and one backup share." If the phone is lost, the other two shares can be used for recovery, eliminating the need for a recovery phrase.
• On-chain Transparency: MPC produces standard signatures, so it looks like a regular address on-chain. This differs from multi-sig in EOA and smart contract wallets: it incurs no extra gas fees, but the rules are not enforced on-chain.

Real-world Vulnerabilities:

These are not mathematical errors in the protocol papers, but rather omissions of checks during implementation for the sake of performance or convenience.

Layer 3: Principles and Engineering

3.1 Threshold Schnorr is Easy, Threshold ECDSA is Hard

The signature value $s = k + c\,x$ of a Schnorr signature is linear with respect to the private key $x$ and the nonce $k$. If $x$ and $k$ are both split using Shamir Secret Sharing, each party calculates their own $s_i$, and the full signature is obtained by summing them up using Lagrange coefficients. The FROST protocol works this way.

The ECDSA signature value is:

$$s = k^{-1}(h + r\,x) \bmod n,$$

It contains $k^{-1}$, as well as the product of $k^{-1}$ and $x$. Multiplication and inversion after splitting cannot be done by simply "calculating individually and then adding"; they require additional cryptographic tools. Common practices involve using Paillier Homomorphic Encryption (see "Homomorphic Encryption") or Oblivious Transfer (OT) to perform "multiplication of secret shares," combined with extensive zero-knowledge proofs to ensure every party is honest. The protocol involves many steps and many parameters, leading to many potential points of failure.

3.2 Proactive Refresh

If an attacker can steal shares one by one over time, they will eventually reach the threshold. The countermeasure is periodic refreshing: the parties collaborate to replace their shares with a new set, where the corresponding private key remains unchanged, but the old shares become invalid. This forces an attacker to steal enough threshold shares within a single refresh cycle.

The refresh protocol itself must be handled carefully: if a refresh fails midway or a participant goes offline, it must not leave the system in a chaotic "half-new, half-old" state.

3.3 Implementation Checklist

3.4 Problems MPC Cannot Solve

• Off-chain Policy: The MPC server "only participates in signing when the policy is met," but this commitment relies on the server's code and operations rather than on-chain rules. If the server is compromised, the policy may fail.
• Frontend Tampering: If all participants sign the same tampered transaction, MPC will still produce a valid signature (see "Bybit Incident and Frontend Integrity").
• Service Provider Dependency: If one party is a service provider, can the remaining shares be used for recovery if the provider goes bankrupt or refuses service? This must be clarified when choosing a product.

Summary