An MPC wallet provider supplies infrastructure that splits a crypto private key into separate shares, distributes those shares across devices or data centers, and coordinates transaction signing without ever assembling the full key in one place. The market divides into two camps. On the institutional side sit platforms such as Fireblocks, which states that thousands of organizations including Worldpay, BNY Mellon, Galaxy, and Revolut use it to secure transactions across more than 150 blockchains. On the consumer and developer side sit products such as Zengo, Web3Auth, Dfns, and Turnkey.
​

Think of the setup like a vault that opens only when two of three branch managers turn their keys at the same time. Except here the keys are math, and the managers can be a phone, a cloud server, and an offline backup. Which parties hold those keys, how many must cooperate, and what happens when one goes missing are the questions that separate providers, and they matter more than any feature list.
​

If the underlying cryptography is new to you, start with the sibling explainer What Is an MPC Wallet?, which covers how threshold signatures work under the hood. This article stays on the buying decision: who the providers are, how their architectures differ, and how to match one to your situation.
​

MPC wallet providers sell key management infrastructure that splits a private key into shares held by separate parties, so no single device or server can sign alone. Offerings range from consumer apps like Zengo to institutional platforms like Fireblocks and Copper that add policy engines, compliance tooling, and settlement networks.
​

The core product is the same everywhere: distributed key generation, threshold signing, and share storage. What differs is the packaging. Fireblocks wraps its MPC engine in a policy layer where a quorum of at least three endpoints each independently validates a transaction against the organization's rules before contributing a signature share. Copper attaches custody to an off-exchange settlement network. Web3Auth and Dfns expose the same primitives as developer APIs, so a fintech can mint wallets for end users without touching key ceremony logistics. Zengo compresses all of it into a phone app.
​

That packaging question is why shortlists go wrong. A payments company evaluating stablecoin custody providers is really buying policy controls and compliance surface. A wallet startup is buying an SDK and a pricing curve. Both will type "MPC wallet providers" into a search bar, and both will find the same six names serving very different jobs.
​

The main MPC wallet providers in 2026 are Fireblocks, Copper, Dfns, and Web3Auth on the MPC side, with Turnkey competing through secure enclaves and Zengo serving consumers. Fireblocks anchors the institutional segment, Copper pairs custody with off-exchange settlement, and Web3Auth embeds wallets in roughly 8,200 apps.
​

Fireblocks is the reference point the rest of the market positions against. Its MPC-CMP protocol signs in a single round, which the company says makes it up to 8x faster than the older GG18 standard's nine rounds. Key shares, policy logic, and API credentials run inside hardware-isolated trusted execution environments, specifically Intel SGX, AWS Nitro, and GCP Confidential Spaces. The protocol also supports a cold configuration with at least one share held on an air-gapped device. Beyond the wallet itself, customers get access to the Fireblocks Network for counterparty settlement.
​

Copper, headquartered in London, builds its custody on three key shards created in isolation and held by three separate entities: the client, Copper, and a trusted third party, with a 2-of-3 quorum required to sign transfers. Its distinguishing product is ClearLoop, an off-exchange settlement network where trades settle on Copper infrastructure so funds never leave custody while trading on venues including Coinbase, OKX, Bybit, and Deribit. Copper cites more than $50 billion in monthly notional trading volume through the system as of July 2026.
​

Zengo is the consumer entry in the category, a mobile wallet that replaces the seed phrase with a 2-of-2 MPC split: a personal share on the user's phone and a remote share on Zengo's servers. The company, founded in 2018, reports passing 1,000,000 customers with zero wallets hacked, a claim it backs with a standing bounty on a live wallet. Its recovery model, covered below, is the most consumer-friendly in the group.
​

Web3Auth targets developers embedding wallets behind social logins. Key shares split across the user's device, a recovery factor, and a distributed network where key operations run on a 5-of-9 consensus system. Consensys acquired Web3Auth in June 2025 to power MetaMask's embedded wallet stack, at which point the company reported nearly 50 million end users across more than 8,200 apps.
​

Dfns sells wallets as an API for fintechs and banks. It runs threshold protocols for both ECDSA and EdDSA signatures, stores encrypted key shares across multiple cloud regions in T3+ and T4 data centers, and is moving its signers into AWS Nitro Enclaves so that even its own engineers cannot reach shares. The company states plainly that it is a technical infrastructure provider, not a custodian, and advertises 99.95% uptime with higher tiers for enterprise contracts.
​

Turnkey belongs on this list with an asterisk: it is not an MPC provider at all. Founded by former Coinbase Custody engineers, it keeps whole keys inside AWS Nitro secure enclaves, a tamper-proof trusted execution environment, and states that private keys are never decrypted outside them. It appears on every MPC shortlist because it competes for the same buyer with a different answer to the same problem, and its per-signature pricing undercuts most MPC options at scale.

Key-share hosting follows four models: provider-hosted shares in trusted execution environments, customer-run co-signers on your own infrastructure, device-held shares on end-user phones, and third-party shard holders for dispute resistance. The model determines who must cooperate, or collude, to move funds, which makes it the core diligence question.
​

Provider-hosted is the default. Fireblocks and Dfns both keep shares inside hardware-isolated environments they operate, and Dfns documents that key shares are encrypted and persisted across multiple cloud regions and availability zones. The pitch is that the provider's security team is better resourced than yours. The cost is that availability and change management now run through a vendor.
​

Customer-hosted co-signers flip that. Institutional platforms let clients run one share on their own infrastructure, so the provider alone can never reach quorum. This is the configuration most institutional custodians steer regulated clients toward, and it is the one that satisfies auditors asking who can actually move money.
​

Device-held shares define the consumer and embedded segment. Zengo's personal share and Web3Auth's device share both live on end-user hardware, which removes the provider as a unilateral signer but makes the user's phone part of the security perimeter. Copper's third-party shard model is the odd one out and exists for a specific institutional fear: if the provider fails or a dispute arises, the client plus the independent shard holder can still reach 2-of-3 and recover assets without Copper's cooperation.
​

Threshold schemes define how many key shares must participate in signing. Zengo uses 2-of-2 between phone and server, Copper mandates 2-of-3 across client, Copper, and a third party, Fireblocks runs quorums of at least three shares, and Web3Auth distributes login shares across a 5-of-9 network.
​

The scheme is a trade between liveness and safety. A 2-of-2 split means both parties are required for every signature, so either side can freeze funds but neither can steal them. A 2-of-3 adds redundancy: any one share can vanish and signing continues. Higher quorums push further toward safety at the cost of coordination overhead, which is where protocol speed starts to matter. The older GG18 protocol needed nine communication rounds per signature; Fireblocks' MPC-CMP reduces this to a single round, and the company chose not to patent the protocol so other vendors can implement it.
​

Two details are worth probing in any vendor conversation. First, whether the threshold applies to key shares or to policy approvals, because Turnkey-style enclave systems enforce quorums in policy software rather than in the key itself. Second, whether shares can be proactively refreshed, meaning re-randomized on a schedule so a slowly-compromised share goes stale before an attacker collects enough of them. Most institutional platforms support refresh; consumer products rarely surface it. The distinction rarely appears on pricing pages, and it is exactly the kind of question that separates a real evaluation from a logo comparison, as coverage of how custody, execution, and settlement are splitting keeps showing.
​

The scheme also interacts with wallet temperature. A hot MPC wallet keeps every share on networked machines for instant signing, which suits payment flows. A cold configuration parks one share on an air-gapped device, so the quorum physically cannot complete without a human retrieving hardware. Fireblocks supports both under the same protocol, and several providers let a single vault mix them, hot shares for operating balances and a cold-inclusive quorum for reserves. Ask where each share in the proposed quorum actually runs before assuming a deployment is one or the other.
​

MPC wallets recover access by re-issuing a lost share or credential instead of restoring a seed phrase. Zengo combines email, a cloud recovery file, and a face scan. Dfns invalidates old passkeys and registers new ones while key shares never move. Institutional platforms keep an offline backup share in cold storage.
​

Recovery is where MPC providers differ most, because there is no standard to converge on. Zengo's 3FA model requires three factors the user controls: an email address, a recovery file stored in the user's own cloud, and a 3D FaceLock biometric scan. Any single factor leaking does not compromise the account. Dfns takes the opposite approach for its API customers: the wallet key sits in the MPC network and never moves, and recovery replaces the user's passkey credential while invalidating every old one.
​

Institutional recovery is more procedural. Fireblocks-style deployments include a disaster recovery share held offline, and Copper's third-party shard means a client can reconstitute signing power even if the provider disappears. When comparing options, write the failure scenarios down explicitly: lost device, dead employee, provider bankruptcy, subpoenaed server. A provider that cannot walk you through all four is telling you something. Reviews of the best stablecoin wallets apply the same test at the consumer level.
​

MPC wallet pricing follows four shapes: per-active-wallet subscriptions starting near $69 per month at Web3Auth, per-signature metering from $0.10 down to fractions of a cent at Turnkey, negotiated platform fees at Fireblocks and Copper, and free consumer apps like Zengo that monetize swaps and on-ramp spreads.
​

The shapes matter more than the numbers because they scale differently. Web3Auth meters monthly active wallets: free to 1,000 MAWs, then $69 per month for 3,000 with $0.045 per additional wallet, and $399 per month for 10,000 at $0.040 each. That curve favors apps with many dormant users. Turnkey meters signatures instead: 100 free wallets and 25 free transactions, then $0.10 per signature on pay-as-you-go, $0.05 on the $99 monthly Pro tier, and enterprise rates the company quotes as low as $0.0015. That curve favors high-wallet-count, low-transaction products and punishes payment flows that sign constantly.
​

Fireblocks, Copper, and Dfns publish no self-serve price list. Contracts are negotiated and typically combine a platform fee with volume components, which is standard for platforms sold alongside compliance commitments. Budget owners comparing them against treasury settlement options should model two years of projected transaction volume before signing, because per-signature and per-wallet curves cross at surprisingly low usage levels.
​

Diligence beyond price follows a short checklist. Ask for the SOC 2 Type II report, not the badge on the website. Ask whether insurance covers key compromise or only crime at the provider's premises, because the two are routinely confused. Ask what the contract says about export: whether you can extract keys or re-derive wallets if you leave, and how long that takes. And ask for the incident history in writing. Every provider in this article publishes security marketing; far fewer will put their last three incidents and response times in a diligence packet, and the ones that will are telling you something useful.
​

MPC has real costs: signing latency from multi-round protocols, vendor lock-in through proprietary implementations, and weak onchain auditability because MPC signatures look like ordinary single-key transactions. Providers using enclaves answer the latency problem but reintroduce hardware trust. No model removes the need to trust someone's operational discipline.
​

Three limitations deserve honest treatment. First, lock-in is structural. Key shares generated under one provider's protocol do not transfer to another, so migration means generating new keys and moving every asset onchain, address by address. Anyone who has re-platformed a large vault estate will describe it as a quarter-long project.
​

Second, MPC hides policy from the chain. A Safe-style multisig publishes its signer set and threshold onchain where anyone can verify them; an MPC wallet's quorum lives in the provider's infrastructure, invisible to auditors reading the ledger. Turnkey's own comparison of MPC, TEEs, and account abstraction is candid that every architecture in this category trades transparency against flexibility somewhere.
​

Third, an MPC provider is not automatically a custodian in the legal sense. Dfns says this outright about itself, and it applies broadly: holding a key share is not the same as holding a regulated custody license, insurance, or bankruptcy-remote client asset segregation. Teams with regulatory obligations usually end up pairing MPC technology with a qualified custodian or checking how treasury compliance platforms fill the gap.
​

Choosing an MPC wallet provider comes down to three questions: who holds the shares, what threshold governs signing, and how recovery works when a share disappears. Institutions gravitate to Fireblocks or Copper, developer teams to Dfns, Turnkey, or Web3Auth, and individuals to consumer apps like Zengo.
​

A working decision tree, based on the provider landscape as it stands in July 2026:

One more distinction keeps the shortlist honest: key management is not money movement. An MPC provider secures the signing; getting stablecoins where they need to be across chains and venues is an orchestration problem layered on top, the same split described in how custodians and orchestrators divide the work. Eco sits on that orchestration side, routing stablecoin liquidity and settlement across chains for businesses regardless of which MPC or custody setup holds their keys, which is why teams often evaluate the two layers together when designing stablecoin payments infrastructure.
​

The reader who takes one sentence away should take this one: an MPC wallet provider is a counterparty in your signing quorum, so choose it the way you would choose a co-signer, by asking what it can do alone, what it can refuse to do, and what happens the day it is gone.
​

Methodology: provider architectures, threshold schemes, recovery models, and pricing were verified against official provider documentation, pricing pages, and announcements (Fireblocks, Copper, Zengo, Web3Auth, Consensys, Dfns, Turnkey) in July 2026. Pricing tiers change frequently; confirm current numbers on each provider's pricing page before budgeting.
​