Every time a conventional wallet signs a transaction, the complete private key must exist in memory — on your phone, on a server, or on a hardware device — for the duration of that operation. That moment of wholeness is a target. Multi-Party Computation (MPC) wallets were designed around one idea: eliminate that moment entirely, not by hiding the key better, but by ensuring it never comes together in one place at all.
This is Part 2 of the series Beyond the Seed Phrase. Where Part 1 laid out why traditional key management creates a structural single point of failure, this article focuses on how MPC wallets actually work at the cryptographic level — and what the honest tradeoffs look like.
The Problem MPC Is Actually Solving
Conventional wallets — hardware or software — generate one private key. That key must be present and intact at signing time. If an attacker compromises the device at that moment, the key is exposed. The signing window is recurring: every outbound transaction reopens it.
Shamir's Secret Sharing (SSS) was an early attempt to spread this risk. A secret is split into N shares using polynomial interpolation, and any M shares can reconstruct it (an M-of-N threshold scheme). For a 2-of-3 setup, you need any two of three shares to reassemble the original. The problem: to sign a transaction, SSS must first reconstruct the full private key on a single device. The reconstruction moment is itself a single point of failure — an attacker who controls that device at that instant can steal the key. SSS distributes storage of the key, not the computation over it.
Multi-Party Computation (MPC) is a branch of cryptography in which multiple parties jointly compute a function over their private inputs without revealing those inputs to each other. Applied to signatures, this means the parties can produce a valid blockchain signature without any one device ever holding the complete private key — not during signing, and not even during key generation.
The core promise of MPC is not distributing where the key is stored. It is distributing the computation itself, so the key never exists as a whole.
SSS vs TSS: The Reconstruction Difference
Understanding the gap between Shamir's Secret Sharing and Threshold Signature Schemes (TSS) is important, because the marketing language around both is often blurred.
SSS at signing time: Each party holds a share. To sign, enough shares are collected and the original private key is reconstructed on one device. That device then signs normally. The key existed in one place.
TSS at signing time: Each party holds a key share and uses it to produce a partial signature. These partial signatures are aggregated — using Lagrange interpolation — into a final, chain-valid signature. As Web3Auth's documentation states, parties "create partial signatures simultaneously which are then aggregated via Lagrange interpolation, validating the final signature without ever reconstructing it." No device ever sees the full key.
Distributed Key Generation (DKG) extends this further. In a true TSS-MPC setup, the key pair is never assembled even at creation — parties run an interactive protocol that ends with each holding a share of a key pair whose public address is known, but whose full private key never existed anywhere.
A concrete analogy: SSS is like giving three colleagues each a third of a safe combination — they still need to meet in one room and dial the same combination to open it. TSS is like giving each person a separate partial lock that only releases in concert — they can collectively open the safe without any single person ever knowing the full combination.
Verifiable Secret Sharing (VSS), an improvement over basic SSS, lets participants verify that their shares are valid without reconstructing the secret. It reduces the risk of a malicious dealer but does not eliminate the reconstruction vulnerability at signing time.
Share Layouts: 2-of-2, 2-of-3, and Why the Math Matters
The threshold number determines both the security profile and the recovery options. In practice, consumer MPC wallets use two layouts.
2-of-2: Both parties must sign. Neither can act alone. ZenGo uses this model: one share on the user's mobile device, one on ZenGo's server. Signing requires both to communicate. The advantage is simplicity; the disadvantage is that either share going permanently offline locks the wallet. ZenGo's recovery relies on three factors: an encrypted backup of the device share held by ZenGo's server, a decryption code stored in the user's personal cloud (iCloud or Google Drive), and a biometric face-scan.
2-of-3: Three shares exist; any two can sign. This layout adds redundancy. Binance Web3 Wallet implements this model with shares distributed among: (1) the user's device, (2) Binance's server, and (3) an encrypted cloud backup protected by a recovery password in iCloud or Google Drive. If the user loses their phone, shares 2 and 3 — server plus cloud backup — can co-sign a migration transaction without share 1.
Coinbase's MPC wallet (one of the first at consumer scale, with over 5 million wallets created as of June 2023) distributes shares among the user's device, Coinbase infrastructure, and a backup service. Web3Auth's 2-of-3 model uses an OAuth login share (managed by the Web3Auth network), a device share, and a backup or 2FA share, supporting signing protocols including GG19, GG20, EdDSA, and DKLS19.
OKX Wallet was among the first major exchange wallets to integrate MPC across 37 blockchains simultaneously, also using a three-part share architecture.
For institutions, higher thresholds — 3-of-5, for example — add additional signers for compliance or governance. Fireblocks, which has processed over $10 trillion in digital asset transactions across 150+ blockchains, implements a 2-of-3 model where share 3 can be stored on an air-gapped mobile device, creating a cold-signing tier without a separate hardware device.
Key Refresh: The Advantage SSS Cannot Match
One of TSS-MPC's most important operational advantages over any SSS scheme is proactive secret sharing, also called key refresh or key rotation.
Parties can collectively compute a fresh set of shares that still map to the same public key — and the same blockchain address — without any party ever assembling the full private key. After a refresh, old shares become cryptographically worthless. A share stolen before the refresh gives an attacker nothing.
This has practical consequences: organizations can rotate staff, revoke a compromised device, or update infrastructure without moving funds on-chain. The attack window for a stolen share collapses to the interval between refresh cycles.
Fireblocks' MPC-CMP protocol achieves signing in a single communication round, compared to nine rounds in the older GG18 standard — approximately 8 times faster — making frequent key refresh operationally practical at scale.
Key refresh is a feature unavailable in Shamir's SSS (where shares are static after generation) and absent from traditional multisig (where on-chain signing keys are fixed).
The Self-Custody Nuance: Is MPC Truly Non-Custodial?
This is where the marketing language and the technical reality most often diverge. The answer depends on who holds the shares and what happens when the provider disappears.
In a 2-of-2 model where the provider holds one share, the provider cannot unilaterally steal funds — they need the user's device share to sign. But they can block any transaction. This is qualified self-custody: the user cannot be robbed by the provider alone, but they can be locked out under account termination or regulatory compulsion. The question of self-custody is not binary in MPC systems.
In a 2-of-3 model, the dynamics depend on which parties hold which shares. If the user holds two shares independently (device and personal cloud backup), the provider's share becomes optional for recovery. But in most consumer MPC wallets, the provider's share participates in every signing round — making them functionally custodial under server failure or account termination scenarios.
The key question any user should ask: If this company shuts down tomorrow, can I still access my funds? For most consumer MPC products the honest answer is: only if there is a mechanism to recover both shares independently of the provider. ZenGo's encrypted-share backup model is designed to survive company shutdown; some products are less explicit about this.
For high-value holdings, the comparison to a hardware wallet is still relevant. A hardware device provides offline key generation and signing with no shared secret — the security model is simpler and does not require trusting any provider's availability. MPC wallets trade that simplicity for recovery convenience and better multi-device UX.
Vendor lock-in is a structural feature of most current MPC products, not an accident. Proprietary signing protocols (MPC-CMP, GG20, DKLS19) mean key-share formats are not cross-provider portable. A share from Fireblocks cannot be imported by ZenGo or vice versa. With a seed phrase, portability across any compatible wallet is guaranteed. With MPC, that guarantee disappears. Users cannot freely migrate between MPC products the way they can migrate between HD wallets using a recovery phrase. By 2026, this vendor lock-in through proprietary signing logic is identified as a material risk in SaaS-based MPC wallets.
Risks Worth Understanding Before You Commit
No major consumer MPC wallet has had funds stolen through the MPC cryptographic layer itself — the protocol has held. But the protocol layer is not the only attack surface.
- Simultaneous share compromise: A 2-of-2 or 2-of-3 model only helps if the shares are stored on genuinely independent systems. An attacker who compromises both a provider's server and a user's device at the same time wins.
- Provider closure or regulatory seizure: MPC does not solve the business continuity risk. If a provider's server goes offline permanently and the user has no independent recovery path, funds may be inaccessible.
- Refresh frequency: A stolen share before a refresh is worthless — but if refresh only happens at recovery, or is infrequent, the exposure window is wide.
- Exchange wallet ambiguity: MPC wallets offered by exchanges (Binance, OKX, Coinbase) blur the line between self-custody and custodial. Under regulatory compulsion, the exchange holding one share can refuse to co-sign. Users who think they are self-custodying may be one court order away from a locked wallet.
For your broader threat model across MPC, passkeys, and recovery schemes, Part 5 of this series maps these failure modes side by side.
What to Do Next
- Identify who holds each share in any MPC wallet you use. Device share, provider share, and cloud backup share are distinct — understand each one.
- Test recovery before you need it. Most MPC wallets have a simulated recovery mode. Use it.
- Ask the provider shutdown question explicitly. Check whether the wallet has published a "key export" or "self-hosted recovery" mechanism.
- Consider key refresh settings. Where configurable, shorter refresh intervals reduce the exposure window of any stolen share.
- Compare your holdings to the custody model. For large holdings, a hardware wallet with no shared secret remains the simpler, more portable baseline — MPC's recovery convenience trades against portability and provider dependence.
