MPC wallets: how Multi-Party Computation actually works
TL;DR. An MPC wallet uses Multi-Party Computation — specifically a Threshold Signature Scheme (TSS) — to compute signatures across two or more parties without ever assembling the full private key on any single machine. Zengo (2-of-2 user+server), Fireblocks (institutional threshold), Coinbase Wallet-as-a-Service (white-label), Portal HQ, and Web3Auth (social-login MPC) are the popular implementations. Different from Shamir SLIP-39, which assembles the key briefly at signing time; both approaches remove the 12-word BIP-39 seed phrase from the UI.
What MPC wallets actually are
Multi-Party Computation is a family of cryptographic protocols that let multiple parties jointly compute a function on their inputs without any party revealing its input to the others. Applied to wallets, MPC becomes a Threshold Signature Scheme (TSS): two or more parties each hold a share of the private key, and every signing operation runs an interactive protocol between them that outputs a valid signature. The full key never exists on any single machine at any point.
Contrast with a normal self-custody wallet, where the private key lives complete on one device and every signature is a local operation. And contrast with Shamir SLIP-39, where the key is split into backup shards that are reassembled in-memory at signing time. MPC alone keeps the key perpetually split.
The two threshold schemes MPC wallets use
- ECDSA-TSS — threshold ECDSA. Foundational papers: Lindell 2017 (2-party), Gennaro-Goldfeder 2018 (GG18, n-party), Doerner-Kondi-Lee-shelat 2018 (2-party fast). Signs on secp256k1: Bitcoin, Ethereum, and every EVM chain. Complex to implement — GG18 had a critical vulnerability disclosed in 2023 that let a malicious party recover the whole key from consecutive signing sessions. Newer variants (CGGMP, LN18) fix this.
- FROST — Flexible Round-Optimized Schnorr Threshold, Komlo-Goldberg 2020. Threshold Schnorr signatures, native to Bitcoin Taproot (BIP-340), Solana Ed25519, and the Cardano ecosystem. Simpler and safer than TSS-ECDSA. Two-round signing. Ships in production at Coinbase and several Bitcoin custody providers.
MPC vs Shamir SLIP-39, the critical difference
Both split a secret across parties. The distinguishing property is when the secret is assembled:
- Shamir SLIP-39. Splits a static private key into shards for backup. At signing time, the wallet reads a threshold of shards, reconstructs the full key in memory, signs, and zeroizes the reconstructed material. The key exists briefly (microseconds) inside the signing device's memory.
- MPC. The full key is never assembled. Each party holds a share for the entire lifetime of the wallet. Each signature runs an interactive protocol between the parties; the output is a valid signature but no party ever sees the full key.
MPC has the stronger cryptographic guarantee — the microsecond signing window that exists in Shamir simply does not exist in MPC. But MPC pays for it in operational complexity: every signature needs live network round-trips between parties, so signing is slow under bad connectivity and impossible when a party is offline. Shamir signs entirely offline once a threshold of shards is assembled.
See the SLIP-39 pillar for the Shamir side of the tradeoff.
2-of-2 vs n-of-m — what "threshold" really means in a wallet
MPC wallets in the wild pick very different threshold configurations:
- 2-of-2 (Zengo, most retail MPC): user device holds one share, vendor server holds the other. Both required for every signature. Convenient: no seed phrase, phishing that captures device state cannot sign without also compromising the vendor. Risky: single point of failure at the vendor — if Zengo goes offline permanently, users cannot sign without invoking the "ChillStorage" recovery path (which is itself a form of escrow, not zero-trust).
- 3-of-5, 4-of-7 (Fireblocks, institutional): shares distributed across geographic regions, security officers, and hardware boundaries. Higher fault tolerance, higher operational cost.
- Social-login MPC (Web3Auth, formerly Torus): one share bound to a social identity (Google, Apple, Twitter), one on the device, one held by the network. Convenience-first — no seed phrase, no backup responsibility for the user. Trust-first — the wallet is only as private as the social identity behind it.
Where MPC wallets win
- No seed phrase to phish. Same headline benefit as SLIP-39. The seed-phrase attack surface — the #1 crypto attack vector — is closed by construction.
- Institutional custody. Fireblocks, Copper, BitGo, Anchorage all use MPC (or MPC-derived HSMs) as the signing layer for hot wallets. Distributes signing authority across regions and organizational boundaries. Every institutional custodian today runs on MPC.
- 2FA-native flows. A 2-of-2 setup with vendor server as the second party is a natural fit for "sign transactions only after user + vendor agree" flows. Phishing that steals device state alone cannot sign; phishing that compromises the vendor alone cannot either.
- Compliance-friendly. Signing that requires vendor cooperation is a natural point to enforce sanctions screening, KYC, and travel-rule attestations. That is why every institutional custodian uses MPC.
Where MPC wallets lose
- Provider dependency. Every retail MPC wallet has a vendor as a required signing counterparty. Vendor goes offline, gets acquired, changes policy, or is compromised — user cannot sign without invoking the recovery path (which is itself vendor-controlled in most implementations). Not truly self-custody in the "works after the company is gone" sense that Shamir + hardware-bound signing delivers.
- Interactive signing. Every signature needs a live network round-trip between parties. Slow signing under bad network. Air-gapped signing is impossible.
- Immature spec. There is no MPC equivalent of SLIP-39. Each MPC vendor implements its own protocol; they do not interoperate. Users cannot migrate from Zengo MPC to Fireblocks MPC without funding a new wallet.
- Complex to audit. ECDSA-TSS security proofs are non-trivial and one popular class (GG18) shipped a critical vulnerability that took years to catch. FROST is simpler but newer. Auditor bench depth for MPC is a fraction of what exists for ECDSA-signature security.
- Recovery is escrow. If your device is lost, most 2-of-2 MPC wallets recover via a vendor-held share released after email verification or KYC challenge. This is custody hiding behind non-custody marketing. Zengo's ChillStorage, Web3Auth's key-recovery flow, and Coinbase WaaS all fall in this category.
Popular MPC wallet implementations
- Zengo. Retail 2-of-2 (user device + Zengo server). No seed phrase in UI. Recovery via ChillStorage: encrypted key material in Zengo custody, decrypted only with user email verification.
- Fireblocks. Institutional 3-of-5 or higher, geographically distributed. Not user-facing; used by exchanges, funds, and treasury desks. Signing layer for a large share of institutional crypto flow.
- Coinbase Wallet-as-a-Service (WaaS). White-label MPC-as-a-service for other wallet builders. Powers non-custodial wallets shipped by fintechs that want no key-custody responsibility.
- Portal HQ. MPC SDK for consumer wallets that do not want to build their own protocol. Ships with recovery, backup, and wallet-management primitives.
- Web3Auth (formerly Torus). MPC + social login. One share bound to Google/Apple/Twitter identity, one on device, one on the Web3Auth network. Convenience-first: wallet recovery is possible via social identity re-authentication.
- ZenGo, Argent, Ambire. Smart-contract-wallet-hybrids that use MPC or MPC-adjacent techniques for signing.
MPC vs Shamir SLIP-39 vs Multisig — the three-way comparison
| Property | MPC | Shamir SLIP-39 | Multisig |
|---|---|---|---|
| Full key ever assembled? | No — never | Yes — briefly, at signing time | Yes — one key per co-signer |
| On-chain footprint | Normal single signature | Normal single signature | Native multisig script (extra bytes, extra fee) |
| Offline signing possible? | No — requires live parties | Yes — assemble shards + sign offline | Yes — each co-signer signs offline, aggregate onchain |
| Interoperability across wallets | None — per-vendor lock-in | SLIP-39 spec (Trezor, Keystone, VEYRNOX) | On-chain standard (works across every wallet that supports the script) |
| Recovery model | Vendor-held escrow in most retail wallets | User-held shards, no third party required | Co-signer replacement via on-chain change |
| Best fit | Institutional custody, 2FA-native retail | Individual + family coercion-resistant wallets | Multi-user governance (treasury, DAO, fund) |
Why VEYRNOX chose Shamir SLIP-39 over MPC
VEYRNOX uses Shamir SLIP-39, not MPC, for the retail self-custody threat model we ship for. The reasoning:
- No vendor as a required counterparty. A VEYRNOX user can recover their wallet after VEYRNOX LTD is dissolved, sold, or blocked. A 2-of-2 MPC user cannot recover after their vendor is gone without invoking the vendor's own escrow path.
- Offline signing. A VEYRNOX device signs without any live counterparty, so signing works on planes, in Faraday cages, or during network outages. MPC needs a live server.
- Interoperability. SLIP-39 is a shared spec — Trezor and Keystone speak the same shard format as VEYRNOX. A user leaving VEYRNOX can reconstruct the wallet from shards in any SLIP-39-compatible wallet. No MPC wallet has that portability.
- Coercion resistance. The coercion primitives we ship on Safety Plus (duress PIN, decoy wallet, panic wipe) depend on the wallet being able to sign locally without vendor cooperation. MPC's vendor-in-the-loop makes coercion features harder to hide from the vendor.
For institutional custody, MPC is the correct choice. For retail self-custody with a coercion-first threat model, Shamir SLIP-39 is.