MPC Wallets Without the Hype: Shares, Signing, Recovery and the Bugs That Broke Them

This is a condensed version of our MPC Wallet Development Guide on the iTech Soft Solutions blog. The full guide adds diagrams, compliance notes (MiCA, VARA), build-vs-buy and a cost section.

Most crypto losses come from keys stored in the wrong place. Multi-party computation (MPC) wallets attack that problem directly: the private key is split into shares that never come together, not when the key is created, not when you sign, not when you recover. This post is the developer's version: what the protocols do, where the shares should live, which published attacks you need to design against, and the mistakes we see most often.

Four wallet models, compared

For consumer and exchange wallets, a strong combination is an MPC key controlling an account with EIP-7702 or ERC-4337 features: MPC protects the key, the smart account gives you gas abstraction and batching.

What the protocols actually do

Distributed key generation (DKG). Each party (device, co-signer, recovery component) contributes randomness and ends up with a secret share. Together they agree on one public key, which becomes the address. No party, and no coordinator, ever sees the full key. Avoid a "trusted dealer" that creates the key and splits it; if you must use one during a migration, run it on the user's device and erase the key immediately.

Threshold signing. A threshold of parties exchange messages over several rounds and output one ordinary signature. For ECDSA the lineage is GG18 → GG20 (identifiable abort) → CGGMP21 (UC security proof, preprocessing so only the last round needs the message, built-in refresh). Two properties matter in production:

• Presigning makes signing feel instant, but a presignature must never be reused and must be bound to the right key and session.
• Identifiable abort tells you whether a failure was the network or a party sending bad data. Without it, a malicious party can stall signing and you can't tell who.

Key refresh. Shares are replaced while the public key and address stay the same. A share stolen last month can't be combined with one stolen today. Refresh on a schedule, after incidents and after device changes.

Resharing. Refresh that changes the members or the threshold, such as a new device or moving from 2-of-3 to 3-of-5, without moving funds. This is what makes seedless recovery possible.

Where the shares live in a 2-of-3 setup

• Share A, user device: hardware-backed keystore or Secure Enclave, gated by biometrics or a passkey. On the web, encrypted with a passkey-bound or password-derived key.
• Share B, co-signer: run by the provider, ideally in an HSM or a confidential-computing enclave. It only joins when the user starts a session and the transaction passes policy.
• Share C, recovery: stored independently: user-controlled cloud backup, a hardware key, a trusted contact or a separate recovery service.

Normal signing is A + B. Recovery is C + B, resharing to a new device. If the provider disappears, A + C can still move the funds out. One share alone can't sign, which is what keeps it non-custodial. If your servers hold two of the three shares, you have built a custodial wallet with extra steps.

ECDSA vs EdDSA and FROST

Bitcoin (legacy and SegWit) and every EVM chain use ECDSA on secp256k1. Its non-linear signing equation forces Paillier encryption, zero-knowledge range proofs and multiplicative-to-additive conversions, and that is where most published bugs live. Use a CGGMP21-class implementation with public audits.

Schnorr and EdDSA are linear, so threshold versions are simpler. FROST (RFC 9591, June 2024) defines a two-round protocol with ciphersuites for Ed25519, ristretto255, Ed448, P-256 and secp256k1. It leaves key generation to you. The practical consequence: EVM-only means threshold ECDSA; adding Solana means a second protocol, a second set of shares and a bigger audit scope.

The architecture around the cryptography

• Client apps (web, extension, iOS, Android) hold Share A. Build the MPC core once, for example in Rust compiled to native and WebAssembly, and wrap it per platform. Use EIP-712 so users sign readable typed data.
• Co-signer holds Share B. Authenticate sessions with a device-bound key or passkey, not just a cookie. Rate-limit and log everything.
• Policy engine: per-transaction and daily limits, allowlists with a cool-off for new addresses, step-up auth for large or new-device transfers. Loosening a policy should itself take time.
• Simulation and phishing screening: simulate every transaction against current state and show outflows, inflows and approvals before the co-signer signs. Flag unlimited approvals and address poisoning.
• Relayer or paymaster for gas abstraction, multiple RPC providers per chain with failover, and a back office that can pause the co-signer per chain.

BitForge and TSSHOCK: what broke in 2023

BitForge (Fireblocks, 9 August 2023) affected more than 15 wallet providers, chains and open-source projects. In GG18/GG20 implementations a missing zero-knowledge proof allowed full key extraction. In Lindell17 two-party ECDSA, vendors deviated from the spec when handling failed signatures, and the key could be extracted after about 200 signature requests.

TSSHOCK (Verichains, Black Hat USA 2023) targeted the dlnproof in threshold ECDSA libraries: ambiguous encoding before Fiat-Shamir hashing (α-shuffle), replacing repeated proof iterations with one large challenge (c-split), and cutting iterations, in one case from 128 to 1 (c-guess).

The pattern behind both:

1. Deviating from the specification: skipping a proof, reducing iterations, handling errors differently.
2. Ambiguous serialisation: hashing concatenated values without length-prefixed encoding.
3. Abandoned forks: modifying a library and never pulling upstream fixes.

Defences: use maintained, publicly audited libraries; never "optimise" proofs; validate every inbound message (group membership, range proofs, session IDs); track upstream advisories and pin versions; after a patch, generate new keys and move funds, because key material may already have leaked. Budget for three audits (cryptographic, application and contract, infrastructure) and a bug bounty at launch.

Recovery without a seed phrase

The goal: restore the owner after device loss without letting the provider, one guardian, or someone holding a stolen phone take over. A flow that works:

1. Recovery starts on the new device, proven with Share C or pre-chosen guardians.
2. A waiting period starts (24–72 hours covers most designs; NexVault uses 48). The new device can't sign yet.
3. Every channel is notified: email, push to the old device, other linked devices.
4. The real owner can cancel with one action.
5. If nobody cancels, shares are reshared to the new device and the old share is invalidated. Address and funds don't change.

Mistakes we see most

1. Calling a design non-custodial when servers hold two of three shares.
2. Writing your own threshold ECDSA, or optimising its proofs.
3. A trusted dealer "for convenience".
4. No provider-exit path.
5. Device shares in plain local storage or unencrypted localStorage.
6. No transaction simulation.
7. Instant recovery with no delay or cancel.
8. Never refreshing keys.
9. One RPC provider.
10. Treating the audit as a launch checkbox.

One lesson from building it

We built this design into NexVault, our non-custodial wallet: 2-of-3 MPC with no seed phrase, simulation and phishing screening before every signature, 48-hour cancellable social recovery, and gas paid in any token through EIP-7702, across 7 EVM chains. The surprise was where the time went. Simulation, phishing screening, RPC reliability and the recovery flow took more engineering than the MPC protocol itself. Plan your schedule around that, not around the cryptography.

Read the full guide for the diagrams, multi-chain notes, compliance and cost sections.

iTech Soft Solutions has built AI and blockchain products since 2016. If you're planning a wallet, see our wallet integration services.