MPC Wallets Explained: Threshold Signatures for Production Crypto Apps

Every self-custodial wallet ever shipped has carried the same liability on its balance sheet: one private key, sitting in one place, protecting everything. Hardware security modules, secure enclaves, mnemonic backups — they reduce the blast radius but never remove the single point of failure. If that key is read, the funds are gone. If that key is lost, the funds are gone. Operations teams have spent a decade engineering elaborate compensations for a primitive that was never designed for production.

An MPC wallet rejects the premise. Instead of protecting one secret, it splits the signing capability across multiple parties so that no single party ever holds, sees, or reconstructs the private key — not during key generation, not during signing, not during recovery. The key, in the classical sense, does not exist. This article walks through how an MPC wallet actually works, which threshold signature schemes are production-ready in 2026, and how to evaluate a provider before you put real money behind it.

The core idea: distribute the secret, not the trust

The naive way to split a key is Shamir Secret Sharing (SSS), proposed by Adi Shamir in 1979. You pick a t-of-n threshold, generate the secret, sample a random polynomial of degree t-1 with the secret as its constant term, and hand each party a point on that polynomial. Any t parties can interpolate the polynomial and recover the secret. Fewer than t parties learn nothing.

SSS is elegant, well-understood, and the wrong tool for a wallet. The reason is in the recovery step: to sign a transaction, the t parties must come together, reconstruct the private key, sign, and then ideally destroy the key. For a brief moment, the full secret exists in memory on one machine. That moment is a target. An adversary who compromises the reconstruction endpoint — through a side channel, a memory dump, a malicious dependency in the signing process — walks away with the full key. SSS distributes storage but centralises trust at signing time.

An MPC wallet built on threshold signatures fixes this. Multi-party computation, introduced in Yao's 1982 paper and generalised through the GMW protocol, lets a group of parties jointly compute a function over private inputs without revealing those inputs to one another. Applied to ECDSA or Schnorr signing, the parties each hold a key share, exchange a sequence of cryptographic messages, and produce a valid signature on the message. No party ever sees the other shares. No party ever assembles the private key. The signature that lands on chain is indistinguishable from a signature produced by a single signer holding the full key.

The distinction matters operationally. With SSS, an auditor has to verify that your reconstruction endpoint is uncompromised, that the key is wiped between signs, that memory is locked, that no hypervisor can snapshot the process. With a properly implemented MPC wallet, there is no reconstruction endpoint to audit. The threat model collapses from "protect the moment of key assembly" to "ensure the threshold of parties is not simultaneously corrupted." Those are very different problems, and the second one is the one you can actually solve with infrastructure.

Threshold signature schemes (TSS): the practical workhorse

A threshold signature scheme is the cryptographic engine inside any production MPC wallet. The literature is dense, but four schemes dominate real deployments.

GG18 (Gennaro & Goldfeder, 2018) was the first practical threshold ECDSA scheme for secp256k1. It supports arbitrary t-of-n thresholds and produces standard ECDSA signatures, which is why it landed quickly in Bitcoin and Ethereum custodians. The cost is round complexity: signing takes 8 to 9 rounds of communication, and the Paillier-based MtA (multiplicative-to-additive) sub-protocol is computationally heavy.

GG20 (Gennaro & Goldfeder, 2020) is the production refinement. It adds identifiable abort, meaning a malicious participant who deviates from the protocol can be detected and named, instead of just causing a silent failure. This is a critical property for any custodian operating an SLA. GG20 is the de facto standard in regulated MPC deployments today.

Lindell17 (Yehuda Lindell, 2017) targets the 2-of-2 case specifically. By restricting to two parties, it achieves a much simpler protocol — typically two rounds — and avoids the expensive zero-knowledge proofs that GG18 requires for the general threshold case. It is the workhorse for consumer MPC wallets where one share lives on a device and the other on a server.

FROST (Komlo & Goldberg, 2020) is the Schnorr-native scheme that has reset the field. It supports threshold Schnorr signatures over ed25519 and secp256k1, runs in two rounds (one of which is pre-processable), and tolerates malicious adversaries with strong security proofs. With Bitcoin's Taproot upgrade making Schnorr signatures first-class on secp256k1 and Solana running ed25519, FROST now spans the two largest signing surfaces in crypto.

Scheme	Rounds	Curves	Adversary model	Maturity
GG18	8 to 9	secp256k1	Malicious	Production since 2019
GG20	8 to 9	secp256k1	Malicious + ID	Industry standard for ECDSA
Lindell17	2	secp256k1	Malicious (2P)	Widely deployed for 2-of-2
FROST	2 (1 pre)	ed25519, secp256k1	Malicious	Production-ready, gaining adoption

The choice of scheme is not a detail. It dictates latency, the chains you can support without compromise, and the adversary model your security team has to defend against. A serious MPC wallet provider will tell you exactly which scheme runs for each curve they support, and which audit firm reviewed the implementation.

What an MPC signing flow actually looks like

Concretely, here is how a 2-of-3 ECDSA signature plays out in a GG20-style MPC wallet. The three parties are typically the user's device, the provider's signing node, and a recovery co-signer. A signing request from your application kicks off a deterministic exchange.

1. Client requests signature on tx hash H, signer set {P1, P2}
2. P1 and P2 each generate a per-signing nonce share k_i
3. Parties run distributed nonce generation:
     - Commit to k_i via Pedersen commitments
     - Exchange MtA shares to compute k = k_1 + k_2 mod q
     - Compute R = k * G without revealing k
4. Each party computes its signature share s_i locally:
     s_i = k_i^{-1} * (H + r * x_i) + masking_i
5. Parties broadcast s_i with zero-knowledge proof of correctness
6. Aggregator computes s = s_1 + s_2 mod q
7. Output: standard ECDSA signature (r, s), verifiable on chain

A few things are worth noting. The key shares x_i are long-lived and were created once during distributed key generation (DKG). The nonce shares k_i are fresh per signature and must never be reused — nonce reuse in ECDSA leaks the private key, as Sony learned with the PlayStation 3. The Pedersen commitments and zero-knowledge proofs are what make this protocol secure against a malicious participant: a party that tries to inject a bad share is detected before the signature is finalised. The on-chain verifier has no idea any of this happened. It sees an ordinary signature.

Security trade-offs you need to understand

MPC is not magic. It moves the threat model rather than eliminating it, and operating a production MPC wallet means engineering around several real risks.

Share refresh and proactive secret sharing. Long-lived key shares are a slow leak. An attacker who compromises one party's share today and another party's share next year reaches the threshold without ever triggering an alarm. Proactive secret sharing, formalised by Herzberg, Jarecki, Krawczyk and Yung in 1995, rotates the shares on a schedule — the underlying private key stays constant, but every share is replaced with a new random value that recombines to the same secret. Any attacker who had not yet reached the threshold loses their progress. Production deployments refresh shares daily or weekly.

Side channels. Each signing party runs cryptographic operations on its own hardware. Cache timing, electromagnetic emissions, and speculative execution leaks can reveal share material to a co-located attacker. The mitigations — constant-time arithmetic, fault-resistant implementations, SGX or Nitro Enclaves for hot signing nodes — are the same techniques HSM vendors have spent decades on, now applied to general-purpose hardware. Ask your provider where their signing nodes run and what attestation they publish.

Adversary models. Semi-honest security assumes parties follow the protocol but try to learn extra information. Malicious security assumes parties may actively cheat. Anything touching real value needs malicious security with identifiable abort. GG18 is malicious-secure; GG20 adds identifiability; FROST is malicious-secure under the algebraic one-more discrete log assumption. Semi-honest schemes show up in research papers and prototypes — they should not show up in production.

Why FROST is gaining ground. Two rounds. One of those rounds is offline-preprocessable, so the online signing path is effectively a single message exchange. Schnorr signatures are linear, which makes aggregation cheap and proofs short. Native support across ed25519 and Taproot-era secp256k1 means one scheme covers Solana, Bitcoin, and a growing slice of EVM L2s adopting BLS or Schnorr-compatible precompiles. Newer wallets are FROST-first for this reason.

MPC vs hardware wallets vs smart accounts

These are not interchangeable. A hardware wallet like a Ledger or a YubiHSM keeps a single key in tamper-resistant silicon — strong against remote attackers, weak against loss, theft, and the user accidentally signing a malicious payload. A smart account (ERC-4337 and its successors) moves the access logic on chain: multisig, social recovery, session keys, all enforced by a contract. Smart accounts are programmable but limited to chains that support them, and every authorisation costs gas.

An MPC wallet sits at a third corner. It is chain-agnostic — the signature it produces is indistinguishable from a single-key signature, so it works on every chain with no contract deployment. It supports policy enforcement off chain at signing time, including velocity limits, geofencing, and risk scoring, without paying gas for each rule. And it supports flexible recovery — passkeys, social recovery, hardware co-signers — without locking the user to a specific chain's account abstraction story. For a multi-chain application that needs sub-second UX and consistent behaviour across EVM and non-EVM ecosystems, an MPC wallet is usually the right primitive.

Evaluating an MPC wallet provider

Use this checklist before you sign a contract.

1. Which threshold signature scheme runs for each supported curve? "We use MPC" is not an answer. You want "FROST for ed25519, GG20 for secp256k1, Lindell17 for 2-of-2 flows."
2. Who audited the implementation, and when? Look for reports from Trail of Bits, NCC Group, Kudelski, or Cure53 within the last 18 months. Ask for the public report, not a summary slide.
3. How often are shares refreshed? Daily is the floor for hot signing. Anything longer than weekly is a smell.
4. What is the recovery model? Passkey-based, social, hardware co-signer, time-locked — and what happens if the provider disappears? You want a documented self-recovery path.
5. Which curves and chains are first-class? secp256k1 and ed25519 are table stakes. Ask about BLS12-381 if you touch Ethereum consensus or Filecoin.
6. What are the published signing latencies? P50 and P99. Anything advertising only "fast" is hiding the tail.
7. Is there on-chain attestation of signing nodes? Enclave attestation reports, signed by the hardware vendor, published on a verifiable feed. This is the difference between a provider you trust because they said so and one you trust because you can check.

A vendor that hesitates on any of these is telling you something. The good ones answer in their docs before you ask.

How Blocsafe uses MPC

Blocsafe runs threshold signatures as the default signing path for every non-custodial wallet on the platform. FROST handles ed25519 for Solana and Schnorr secp256k1 for Taproot. GG20 handles ECDSA secp256k1 for the rest of EVM and the long tail of secp256k1 chains across the 30+ networks we index. Key shares are refreshed daily, signing nodes run in attested enclaves with public attestation reports, and every signing path has been audited end-to-end.

Recovery is passkey-first with optional social co-signers, so a user can replace a lost device without writing down a seed phrase and without giving Blocsafe custody. The wallet API exposes one signing primitive with consistent latency targets: sub-300ms P99 across EVM and Solana, with the cryptographic work parallelised across regional signing nodes so the round trip is bound by network, not by the protocol.

If you are building a crypto app and want to ship MPC without staffing a cryptography team, start at /signup and pull a key in under five minutes.