For the lazy guys, here’s the implementation on GitHub. Don’t forget to star the repo ⭐
On August 9, 2023, the Fireblocks cryptography research team published one of the most consequential disclosures in wallet security history.
They called it BitForge.
The disclosure named names Coinbase Wallet-as-a-Service, Binance, Zengo. Over fifteen widely-deployed MPC implementations, all running protocols described in peer-reviewed academic papers, all vulnerable to a class of attacks that could extract the full private key from a single compromised participant.
Some implementations could leak the key in 16 signatures. Others required up to a billion. But the point was the same: the multi-party guarantee that MPC promises, that no single party ever has the key was broken in production.
The cause was almost embarrassing. The original GG18 and GG20 papers, which much of the industry had implemented, were missing zero-knowledge range proofs around values used in their Paillier-based multiplication protocol. Nobody added them, because nobody noticed they were missing. Cryptographers writing papers don't always spell out every defensive check. Engineers reading papers don't always know which omissions matter.
The fix took weeks. The architectural lesson is still being absorbed.
If you’re reading tutorials about building MPC wallets today, there’s a decent chance the protocol they’re teaching you is one of the broken ones. There’s a near certainty they’re skipping the parts that make MPC actually safe in production: distributed key generation without a trusted dealer, share refresh, cheater identification, replay protection, hardware-backed share encryption.
This article is the one I wish existed when I started. It walks through how MPC wallets actually work, what the current cryptographic state of the art is, why every architectural choice matters, and how to build a working 2-of-3 threshold signature wallet for Solana that you can run today.
It is long. It is technical. It will not waste your time.
A traditional wallet has one private key. Whoever holds the key controls the funds. Lose it, lose everything. Leak it, lose everything. Get phished into signing the wrong thing, lose everything. Single points of failure all the way down.
A multisig wallet improves on this by requiring multiple signatures. But each signature comes from a complete private key held by a different party, and the signatures are combined on-chain. The blockchain knows it's a multisig, different address format, higher fees, privacy leakage about who signed.
An MPC wallet is different. It splits a single conceptual private key into mathematical shares distributed across multiple parties. To sign a transaction, a threshold number of share-holders cooperate in a cryptographic protocol that produces one standard signature indistinguishable on-chain from a normal single-key signature. The blockchain doesn't know it's MPC. There is no special address format. The full private key is never reconstructed at any point, on any device.
Two primitives matter:
Distributed Key Generation (DKG) : A protocol where N parties collaboratively generate a shared key. Each party ends up with a share of the key. No party ever sees the full key. The protocol also outputs a group public key (the on-chain address).
Threshold Signature Scheme (TSS) : A protocol where T-of-N parties (where T ≤ N) cooperate to produce a valid signature using their shares. The signature verifies against the group public key like any ordinary signature. The full private key is never reconstructed during signing.
Together: DKG creates the key, TSS uses it. Neither involves anyone ever holding the complete secret.
A typical 2-of-3 MPC wallet might distribute shares like this:
To sign a transaction, you need 2 of the 3 shares to participate in the signing ceremony. Lose your phone? Use the backup share to recover. Service compromised? They can’t sign alone. Phone compromised? They can’t sign alone either.
The threshold is configurable. 2-of-3 is the most common for retail. Institutional setups use larger configurations like 3-of-5 or 5-of-9 with shares distributed across geographic regions, secure enclaves, hardware modules, and key personnel.
Here’s the property that makes MPC magical for blockchain wallets.
When a 2-of-3 FROST signing ceremony completes for an Ed25519 signature on Solana, the output is a 64-byte Ed25519 signature. The Solana validator checks it with the standard Ed25519 verification routine. The validator has no idea. and no way to know, that the signature was produced collaboratively.
Compare with on-chain multisig:
Multisig: validator sees a transaction calling a multisig program, decodes it, verifies each signer separately, applies threshold logic. Costs more compute. Reveals all signers. Limited portability.
MPC: validator sees a normal signature. No extra logic. Costs nothing extra. Reveals nothing about the signing process.
This is why every major wallet infrastructure provider, including Fireblocks, Coinbase WaaS, Dfns, Zengo, Safeheron, Portal HQ, Privy, and Turnkey, uses MPC or MPC-adjacent architectures.
The MPC protocol you choose determines almost everything about your wallet’s security, performance, and operational characteristics. Most engineers building wallets don’t actually pick the protocol; they pick a library, and the protocol comes with it. That’s fine when the library is well-chosen. It’s catastrophic when it isn’t.
Here’s the honest state of the field.
ECDSA is what Bitcoin and Ethereum use. Threshold ECDSA is much harder than threshold Schnorr because of how ECDSA’s signing equation is structured (the inverse of the nonce makes things ugly). Three generations of protocols matter.
GG18 and GG20 (Gennaro-Goldfeder, 2018 and 2020) were the original practical threshold ECDSA protocols. They made MPC wallets commercially viable. They also missed a zero-knowledge range proof around their Paillier homomorphic encryption that turned out to be load-bearing for security. This is the BitForge vulnerability. Do not implement these for new systems. If a tutorial or library uses GG18 or GG20 without explicit BitForge mitigations, walk away.
CGGMP21 (Canetti-Gennaro-Goldfeder-Makriyannis-Peled, 2021) fixed the missing proofs and added universally composable security. Fireblocks calls their implementation MPC-CMP. Dfns has CGGMP21 in Rust. It’s the institutional gold standard. The tradeoff is heavier computation, reliance on a 2048-bit Paillier modulus, and the need for extremely careful implementation.
DKLs23 (Doerner-Kondi-Lee-Shelat, 2023) takes a different approach: replace Paillier homomorphic encryption with Oblivious Transfer. This sidesteps the entire Paillier-related vulnerability class, reduces communication rounds from 6 to 3, and runs faster on resource-constrained devices like phones. Utila, MetaMask Embedded Wallets, and Web3Auth use DKLs23 (or DKLs19, its predecessor).
Schnorr signatures are mathematically cleaner than ECDSA, which makes threshold Schnorr much simpler than threshold ECDSA. FROST (Flexible Round-Optimized Schnorr Threshold) is the standard protocol.
FROST is a 2-round signing protocol. There’s a trusted-dealer variant and a fully distributed DKG variant. It’s the protocol you want for any chain that supports Schnorr or Ed25519:
The ZcashFoundation maintains a production-grade Rust implementation: frost-core v2.0, with ciphersuite-specific crates for each curve. It’s partially audited by NCC Group and is what we’ll use in our reference implementation.
Three classes of implementations should be treated as red flags in 2026:
Anything claiming GG18 or GG20 without explicit BitForge patches. The missing ZK proofs are not optional.
MPC-SSS wallets that reconstruct the key in memory during signing. This is Shamir’s Secret Sharing dressed up as MPC. The key is reassembled, even briefly, on the client. Web3Auth V1, older Privy SDKs, and many “MPC tutorial” projects fall in this category. Real MPC-TSS never reconstructs the key.
Trusted-dealer DKG in production. If a single party generates the key and distributes shares, that party is a single point of failure. Use a fully distributed DKG.
The cryptographic protocol is one axis. The other axis is where the shares live and how they’re protected. Three camps dominate the production landscape.
The shares are split across genuinely independent parties, typically a combination of user devices, service backends, and cold backups. Each party runs the MPC protocol locally. No party ever sees the full key. Fireblocks, Coinbase WaaS, Zengo, Safeheron, Dfns operate here.
Strengths: No single point of failure. Cryptographically pure model. Independent of hardware trust assumptions.
Weaknesses: Slower signing (MPC ceremonies have latency overhead). Harder to implement correctly. The cryptographic protocol must be the most-recent, most-audited version.
The keys live inside hardware-isolated enclaves like AWS Nitro Enclaves, Intel SGX, or Apple Secure Enclave. The enclave generates the key, the enclave signs, the key never leaves. Turnkey, Privy (iframes), Portal HQ operate here.
Strengths: Very fast (50-100ms signing latency). Simpler to reason about, you trust the hardware vendor. Strong attestation gives cryptographic proof of what code is running.
Weaknesses: Trust shifts to the hardware vendor (Amazon, Intel, Apple). Side-channel attacks against TEEs are a known research area. Recovery typically depends on the vendor’s infrastructure.
The key is split using Shamir’s Secret Sharing. Shares are distributed across devices and backends. But during signing, the shares are combined in client memory to reconstruct the full key, which then signs normally and is wiped. Web3Auth V1 and some other consumer-focused providers operate here.
Strengths: Easier to implement. Works with standard signing libraries. Faster than pure MPC.
Weaknesses: The key does exist, however briefly, in memory on the client. A compromised client at the moment of signing extracts the full key. This is not real MPC, it’s distributed key recovery with key reconstruction.
The right architecture depends on the threat model. Institutional custody chooses pure MPC. Consumer apps optimizing for latency choose TEE. Hybrid models exist but should be evaluated honestly, many "MPC wallets" in market are actually MPC-SSS.
This is the end of Part 1. In Part 2, we’ll cover implementation, share refresh, the production concerns most tutorials skip (untrusted coordinators, replay protection, policy engines, hardware-backed share encryption), how this reference compares to what Fireblocks, Coinbase WaaS, Privy, and Turnkey actually run, and what hiring managers in the MPC space are looking for in 2026.
Subscribe to get Part 2 when it drops.