An MPC wallet splits signing across several parties so the full private key never exists. How it works, MPC vs multisig, and when to build one.
An MPC wallet is a crypto wallet in which the private key is never created or stored in one place. Several parties each hold a secret share of the key, and a threshold of them run a multi-party computation protocol to produce a standard signature, so no single device, employee, or vendor can move funds alone.
That property has made MPC the default architecture for exchanges, fintechs, and institutional custodians. This guide covers the cryptography behind MPC wallets, how they compare with multisig, HSMs, and TEEs, which protocols and libraries are sensible choices in 2026, and how to decide whether to build, integrate, or buy. For the broader picture of wallet architecture and cost, see our crypto wallet development guide.
A traditional wallet protects one secret. An MPC wallet removes that secret as a single object: the key exists only mathematically, defined by shares held on separate machines, often under separate administrative control.
Classic Shamir's Secret Sharing splits an existing key into pieces, usually for backup. To sign, the pieces are brought back together and the full key is reconstructed in memory, even if only for a moment. That moment is exactly what attackers target. MPC wallets use threshold schemes where the key is generated in distributed form from the start and is never reconstructed, not during key generation and not during signing.
In a threshold signature scheme, a transaction is signed when at least t of n share holders take part. Each party runs its side of an interactive protocol using its own share, exchanging messages and zero-knowledge proofs with the others. The output is an ordinary ECDSA or EdDSA signature.
GG18 and GG20, both by Gennaro and Goldfeder, were the first widely deployed threshold ECDSA protocols and still sit under many older wallets. CGGMP21, which grew out of Fireblocks' MPC-CMP research, added stronger security proofs and built-in proactive key refresh. DKLs (DKLs19 and DKLs23) takes a different route based on oblivious transfer and avoids the heavy Paillier encryption used by the GG family. For Schnorr and EdDSA chains such as Solana, FROST is the standard choice and was published as RFC 9591 in 2024. Most production wallets need more than one protocol: an ECDSA scheme for Bitcoin and EVM chains, plus FROST or a similar scheme for Ed25519 chains.
A production MPC wallet has three logical layers: key management, signing orchestration, and policy enforcement. Mixing them, for example letting the signing service also decide which transactions are allowed, is a common source of security holes.
Shares are created through distributed key generation (DKG). Each party generates its own randomness locally, the parties exchange commitments and proofs, and each ends up with a share plus the common public key. The ceremony should run on the same hardened infrastructure that will later sign, and its transcript should be logged for audit.
Signing nodes hold shares and run the protocol. A coordination layer routes signing requests, checks that a quorum is available, handles timeouts, and retries when a node drops out. Placing nodes with different cloud providers, regions, or organizations is what turns "several shares" into real independence.
Key refresh re-randomizes every share while keeping the same public key and address. Shares from an earlier epoch stop working after a refresh, so an attacker has to compromise a threshold of nodes within a single refresh window instead of collecting shares slowly over months.
Many teams run signing nodes inside hardware-isolated environments such as AWS Nitro Enclaves, which have no persistent storage and no direct network access, and support attestation, so a node can prove what code it is running before it receives a share. AWS publishes a walkthrough of running an MPC co-signer inside Nitro Enclaves. Intel SGX is another option, although its history of side-channel attacks means it should be treated as one layer of defense, not a guarantee.
The MPC vs multisig question comes down to one architectural choice: whether approval logic lives on-chain or off-chain.
An MPC wallet produces one standard signature from one public key. On-chain it looks like any single-key wallet, which is good for privacy and fees but means outsiders cannot see how the wallet is controlled.
On EVM chains, multisig usually means a smart contract wallet such as Safe (formerly Gnosis Safe). Owners typically sign off-chain and one transaction executes with all signatures, but that execution still costs more gas than a plain transfer, the contract has to be deployed on every chain, and the safety of funds now depends on contract code as well as keys.
MPC is largely chain-agnostic: the same infrastructure can serve Bitcoin, EVM chains, and Solana, with an ECDSA protocol for the first two and an EdDSA protocol for the third. Multisig depends on what each chain supports. Bitcoin has native multisig scripts and Taproot, and EVM chains need a contract.
| MPC (TSS) | Multisig | HSM | TEE | |
|---|---|---|---|---|
| Where the key lives | Split across parties, never assembled | Several full keys, one per signer | One full key in tamper-resistant hardware | One full key inside an isolated enclave |
| On-chain footprint | Standard single signature | Visible contract or script | Standard single signature | Standard single signature |
| Chain support | Any chain with a supported curve | Depends on native support or contracts | Depends on curve support in the device | Any chain |
| Main risk | Implementation bugs in the protocol | Contract bugs, key loss per signer | Single key, operator and physical access | Enclave vulnerabilities, trust in one hardware vendor |
| Typical fit | Exchanges, fintechs, institutional custody | DAOs, protocol treasuries | Banks, regulated custody, cold storage | Consumer embedded wallets |
Some vendors now argue that TEE is replacing MPC. For consumer embedded wallets with email or social login, TEE-based designs are gaining ground: they are fast, simple for users, and avoid multi-round signing. For institutional custody, MPC remains stronger because trust is spread across parties instead of resting on one hardware vendor. Many modern stacks combine both by running MPC nodes inside enclaves.
MPC removes the single key as a target but introduces protocol-level threats that need their own threat model.
MPC is only as independent as the parties holding shares. If one company controls enough nodes to meet the threshold, or all nodes share one cloud account, one admin, or one CI pipeline, the threshold is cosmetic.
Enclaves shrink the attack surface but do not remove it. SGX has been hit by attacks such as Foreshadow and Plundervolt, and any node can leak information through timing or memory access patterns if the cryptographic code is not constant-time.
The most serious MPC incidents so far have come from implementation bugs, not broken math. In 2023, Fireblocks disclosed BitForge, a set of flaws in widely used GG18, GG20, and Lindell17 implementations that could let a malicious party extract the full key. The same year, Verichains presented TSSHOCK, a set of attacks against threshold ECDSA libraries used by several wallets and cross-chain bridges. In both cases the root cause was missing or weak zero-knowledge proofs in code. Builders should use an audited, maintained implementation of a modern protocol and treat any fork of an older library as suspect until it has been reviewed.
If you move funds across many chains, process thousands of withdrawals a day, and need approvals without paying gas for each one, MPC is the default choice.
A DAO treasury on Safe gives token holders on-chain proof of who can move funds. For protocols whose community expects that transparency, or whose governance already executes through contracts, multisig remains the better fit.
The two combine well. A common pattern uses MPC keys as the signers on a Safe: each signer is itself an MPC wallet, so there is no single key behind any approval, while the treasury rules stay verifiable on-chain.
A custom TSS stack needs engineers who understand protocols like CGGMP21, DKLs, and FROST, plus distributed systems and security operations. Our rough estimate is 12 to 18 months with four to six senior engineers before the product is audit-ready.
Integration sits in the middle: you run the nodes and own the infrastructure, but you do not write the cryptography. We do not recommend starting new projects on ZenGo's multi-party-ecdsa, which is no longer maintained, or on older GG18 and GG20 codebases such as Binance's tss-lib without careful review, since both were affected by the 2023 disclosures above. Actively maintained options include Coinbase's open-source cb-mpc, Silence Laboratories' DKLs23 implementation, and the cggmp21 Rust library originally developed by Dfns.
Providers such as Fireblocks, BitGo, Dfns, Fordefi, and Cobo offer MPC custody through APIs and SDKs. You get audited cryptography, policy engines, and compliance reports from day one. The trade-offs are recurring fees that grow with volume, dependence on the vendor's chain and token coverage, and lock-in, since migrating keys between providers is rarely simple.
The MPC layer is rarely the hardest part of a provider integration. Most of the effort goes into everything around it: mapping your approval flows to the provider's policy engine (withdrawal limits, address whitelists, per-amount approval thresholds), handling webhooks and transaction status reliably, planning key backup and recovery with the provider, and managing gas funding for token transfers.
Three questions settle most cases. Is custody a core differentiator of your product, or a supporting feature? Do your regulators or clients require that you control key generation and storage yourself? Can your team maintain cryptographic infrastructure for years, including patching after the next disclosure? For most early-stage fintechs the answers point to a managed provider or a well-chosen library.
Regulation has not caught up with distributed key management, so builders work from principles more than explicit rules.
SOC 2 and ISO 27001 do not mention MPC, but MPC supports the controls they test: segregation of duties, access control, and logging. Custody rules tend to focus on control. MiCA defines custody as safekeeping or controlling crypto-assets or the means of access to them, such as private keys, and FinCEN's 2019 guidance treats the independent ability to move funds as the deciding factor. If a provider holds enough shares to sign alone, regulators are likely to see it as the custodian.
In a 2-of-3 setup where the client holds one share, the provider one, and a backup party one, neither the client nor the provider can act alone, which may support a non-custodial position. If the provider holds two shares, it likely has control. Get legal advice on your specific setup before launch.
Because the chain cannot show who approved a transaction, the audit trail has to. Log every signing request, which nodes participated, which policy rule approved it, every key ceremony and refresh, and all access to nodes.
All figures below are rough estimates and vary widely with scope, supported chains, and audit depth. A custom MPC stack typically lands between $800K and $2.5M through its first audit. Managed providers usually charge from tens of thousands to a few hundred thousand dollars a year, depending on volume and features.
Protocol selection (for example CGGMP21 or DKLs for ECDSA and FROST for EdDSA), threshold and share placement across parties and environments, threat modeling, and key ceremony design. Teams almost always underestimate this phase.
Signing orchestrator, node deployment in enclaves or HSM-backed environments, policy and approval engine, key refresh, backup and recovery flows, and blockchain connectivity for each supported chain.
A cryptographic audit from a firm with MPC experience, such as Trail of Bits or NCC Group, penetration testing of signing nodes and APIs, and preparation for SOC 2. Our breakdown of blockchain security audit scope and pricing covers what to expect from this stage.
An MPC wallet splits a private key into shares that are never combined. The math behind it is sound, and the risk lives in implementations, which is why library choice and independent audits matter as much as protocol choice. For institutional custody, MPC is the strongest option available today. For consumer embedded wallets, TEE-based designs are gaining ground, and many teams combine the two.
If you are deciding whether to build, integrate, or buy, our team can help you choose an architecture and ship it. Learn more about our crypto wallet development services.
An MPC wallet is a crypto wallet whose private key is split into shares held by separate parties. A threshold of those parties runs a multi-party computation protocol to sign transactions, and the full key is never created or stored in one place.
Multisig uses several full private keys and enforces the approval rule on-chain, usually through a smart contract or script. MPC uses one key split into shares and enforces the rule off-chain, producing a single standard signature. Multisig is more transparent, while MPC is more private, cheaper per transaction, and works across more chains.
The cryptography behind MPC is well studied, and major custodians rely on it. The real risk is implementation: the BitForge and TSSHOCK disclosures in 2023 showed that flawed libraries can leak keys. An MPC wallet is as safe as its implementation, its audits, and the operational separation between share holders.
Yes, as long as enough shares remain to meet the threshold. In a 2-of-3 setup, losing one share still leaves two, which can sign and run a key refresh to issue a new set of shares without changing the wallet address. Losing more shares than the threshold allows means the funds cannot be recovered, so backup share design is critical.
Not across the board. TEE-based wallets are growing in consumer apps because they are fast and simple for users. MPC remains the stronger choice for institutional custody, where trust should not depend on a single hardware vendor.
