Multi-party computation custody solves the oldest problem in digital assets: a private key is a single secret, and single secrets get stolen, lost, and misused. MPC removes the single secret entirely. The key is never assembled in one place — not at generation, not at signing, not ever. Instead, several parties each hold a mathematical share, and they cooperate to produce a valid signature without any of them learning the full key.
That one sentence explains why MPC has become the default signing technology at most major digital asset custodians and wallet platforms. It also explains almost nothing about whether an MPC product is actually safe, because the cryptography is the easy part. Where the shares live, who controls the machines that hold them, and what policy engine gates the signing ceremony — that is where MPC custody programs succeed or fail.
This guide explains how MPC signing works in plain terms, how it compares to multisig and hardware security modules, and what to ask a vendor before trusting one with institutional assets. It extends our foundation guide to institutional crypto custody, which covers the full control stack around any signing technology.
Image: Fireblocks — mobile signing request queue
The problem MPC exists to solve
Every blockchain asset is controlled by a private key. Whoever can produce a signature with that key owns the asset, as far as the network is concerned. Traditional key storage — even excellent key storage — concentrates that power in one artifact. A hardware wallet is one device that can be stolen. An HSM is one machine that can be misconfigured. An encrypted file is one file plus one password.
Security teams call this a single point of compromise, and every custody architecture is ultimately a strategy for eliminating it. Three main strategies exist.
Multisig puts several complete keys on-chain: the blockchain itself enforces that, say, 2 of 3 keys must sign. HSM-based custody keeps one key locked inside certified hardware and wraps procedure around access — the approach we describe in our guide to bank-grade crypto custody. MPC splits one key into shares mathematically, so a quorum of share-holders can sign but no single machine ever contains the key.
These are not competing religions. Serious custodians mix them — MPC for operational wallets, HSM-backed cold storage for deep reserves — and the mix matters more than the label.
The cryptography behind MPC custody is called a threshold signature scheme. Walking through its life cycle removes most of the mystery.
Key generation. The parties — typically two or three machines in different environments — run a distributed protocol that ends with each machine holding one share. The full private key is never computed on any of them, at any point. There is nothing to photograph, export, or write on paper.
Signing. When a withdrawal is approved, the share-holding machines run an interactive protocol. Each computes a partial result using its own share, they exchange messages, and out comes one ordinary signature. To the blockchain it looks exactly like a normal single-key transaction — cheaper and more private than multisig, which visibly publishes its structure on-chain.
Image: Safeheron — private key shards held separately on device and MPC node
Threshold. Schemes are described as t-of-n: three shares exist, any two can sign. An attacker must compromise two independent environments — a phone and a cloud enclave, or two data centers run by different parties — within the same window. One stolen share is useless.
Share refresh. Good implementations periodically re-randomize the shares without changing the public key. After a refresh, a share stolen last month no longer combines with anything. This quietly converts the attacker's job from "steal two shares eventually" to "steal two shares simultaneously," which is a much harder crime.
The standard institutions ask about by name is CMP/GG-style threshold ECDSA; NIST began a formal process to standardize threshold cryptography schemes in 2023, which is worth watching because certification regimes follow standards.
MPC versus multisig versus HSM: an honest comparison
Vendors sell whichever architecture they built. Here is the comparison we actually use when evaluating custody platforms, compiled from the design trade-offs above:
| MPC (threshold signatures) | On-chain multisig | Single key in HSM | |
|---|---|---|---|
| Key ever whole | Never | Each co-signer key is whole | Yes, inside hardware |
| Chain support | Any chain using ECDSA or EdDSA | Only chains with native multisig | Any chain |
| On-chain footprint | Looks like one normal signature | Multisig structure is public | Normal signature |
| Quorum change | Re-share off-chain, address unchanged | New contract or address migration | Procedural change only |
| Signing latency | Interactive rounds, sub-second to seconds | One transaction per co-signer | Immediate after approval |
| Certification story | Maturing, scheme-dependent | Inherited from each signer | FIPS 140-2/3 certified for years |
| Main failure mode | Implementation bugs, share co-location | Co-signer collusion or apathy | Procedure around one box |
Two rows deserve emphasis. Chain support is MPC's quiet advantage: one signing stack covers hundreds of chains, where multisig support varies chain by chain. Certification is MPC's quiet weakness: HSMs have decades of formal validation behind them, while threshold schemes are newer and audits substitute for certificates. That is why regulated custodians so often run MPC inside hardware-isolated environments — taking both properties rather than choosing.
The threshold math guarantees nothing if the deployment undermines it. When you diligence an MPC custodian, the entire conversation is really about share placement and control.
Independence. Shares must sit in genuinely separate trust domains — different machines, different credentials, ideally different organizations. Three shares in three containers on one cloud account is theater: one compromised administrator reassembles the quorum.
Who holds what. In a co-signing model, the customer holds one share and the platform holds others, so neither can move funds alone. In a fully hosted model, the vendor operates all shares and independence is internal to the vendor. The first model gives you cryptographic veto power; the second gives you convenience and a bigger trust assumption. Know which one you are buying.
Image: Zengo — MPC security model with no seed phrase
Hardware isolation. Leading platforms run share-holding processes inside secure enclaves or HSM-adjacent environments so that even a compromised host cannot read the share. Ask specifically: if an attacker gets root on the server, do they get the share?
Backup and recovery. Every share needs a recovery path that does not recreate a single point of compromise. Encrypted share backups held by independent parties, with a documented, rehearsed recovery ceremony, are the standard. A vendor who cannot describe the recovery ceremony in detail has not rehearsed it.
Here is the observation that surprises most first-time evaluators: in day-to-day operation, the MPC protocol is invisible. What your team touches every day is the policy layer that decides when the shares are allowed to sign.
Image: Fireblocks — transfer approval with full transaction context
A production-grade policy engine enforces, at minimum: quorum approvals that vary by amount and destination; allowlists so funds move only to pre-registered addresses; velocity limits that cap outflow per hour and per day; and role separation so the person who creates a transaction can never be the person who approves it. These are the same controls a qualified custodian is examined on — MPC changes the signing math, not the governance obligations.
The critical question: is the policy enforced inside the share-holding environment, so that a share simply will not participate in a signature that violates policy? Or is it enforced by an application server in front of the MPC layer? In the second design, compromising that server turns your threshold cryptography into an expensive rubber stamp. This single architectural question separates institutional MPC platforms from wallets with an MPC sticker.
An audit trail completes the picture. Every request, approval, rejection, and policy change should land in a tamper-evident log tied to named individuals.
Image: Safeheron — timestamped policy and team-change approval feed
More in Guides
What MPC looks like to the people using it
One reason MPC has spread so quickly is that, done well, it is invisible. The end user sees a wallet: balances, send, receive, an approval prompt when policy requires one. There is no seed phrase ceremony, no hardware dongle in a drawer, no envelope in a safe — the enrollment of a device is the creation of a share, and recovery is a guided re-enrollment rather than a treasure hunt.
Image: Zengo — MPC wallet home screen with no seed phrase behind it
This user experience is not a cosmetic detail; it is a security control. Most real-world crypto losses are not cryptographic breaks — they are seed phrases photographed, typed into phishing sites, or inherited by nobody. Removing the seed phrase removes the most-attacked object in the entire system. Consumer MPC wallets proved the model at scale, and institutional platforms borrowed the lesson: the fewer secret artifacts a human can mishandle, the fewer ways the program fails.
For an operations team, the daily surface is the approval queue shown earlier — requests arrive with full context, the right people confirm on enrolled devices, and the signature happens wherever the shares live. Your evaluation should include sitting with the actual approval flow for a week of simulated operations. A platform whose approvers routinely tap approve without reading the destination has a governance problem no threshold scheme can fix.
An honest vendor will volunteer this list; an evasive one makes you extract it.
Approved-but-fraudulent transactions. If an attacker phishes your operations team into approving a withdrawal to their address, MPC signs it flawlessly. The defense is the policy layer — allowlists, dual approval, transaction simulation — and staff training, not the threshold math.
Implementation bugs. The protocols are peer-reviewed; the code implementing them is ordinary software. Several publicly disclosed vulnerabilities in threshold ECDSA libraries have shown that a flawed implementation can leak key material across many signing sessions. Ask for the audit reports on the specific library in production, not the whitepaper of the scheme.
Share co-location drift. Systems deployed correctly can degrade — a backup process that quietly copies two shares to the same bucket, a disaster-recovery region that hosts both signers. Independence is an operational property that must be monitored, not a launch-day fact.
Governance capture. If one administrator can change the policy, re-enroll devices, and approve transactions, your t-of-n scheme has n of 1. Administrative actions need the same quorum discipline as withdrawals.
Three situations, three answers
"We are a fund running frequent DeFi and exchange operations." MPC platforms with enforced policy engines were built for exactly this: hot-capable signing with governance on every transaction, one integration across every chain you touch, and no on-chain multisig overhead. Put your working capital here and keep strategic reserves in bank-grade cold custody.
"We are a corporate treasury holding one large, rarely-moved position." Signing speed is worth little to you; certification and recoverability are worth a lot. An HSM-based qualified custodian, or a hosted MPC custodian with hardware-isolated shares and insured recovery, fits better than operating MPC infrastructure yourselves.
"We are a bank or fintech embedding wallets in our product." Wallet-as-a-service MPC — one platform share, one customer-device share — gives you non-custodial positioning with recoverability. Your diligence should focus on the device-share recovery flow, because that is where your support burden and your regulatory characterization both live. Positions in tokenized real-world assets add an allowlist wrinkle: confirm the MPC platform supports the token standards involved.
- Name the scheme and the library. Which threshold protocol, whose implementation, audited by whom and when. Insist on the reports.
- Map every share. For each: what environment, what hardware isolation, who operates it, what jurisdiction.
- Test the veto. If you hold a share, prove the platform cannot move funds without you — in a live exercise, not a diagram.
- Probe policy enforcement depth. Confirm shares refuse to sign policy-violating transactions even if the application layer is compromised.
- Rehearse recovery. Walk through a lost-share and a lost-device scenario end to end, with timings, before funding the wallets.
- Check share refresh cadence. Proactive re-randomization on a schedule, and reactive refresh after any suspected incident.
Buying the acronym. "We use MPC" tells you as much as "we use encryption." The scheme, the share placement, and the policy depth are the product.
Ignoring the second share's home. In co-signing models, the customer share often lives on an executive's phone. That phone is now custody infrastructure — it needs enrollment controls, backup, and a revocation path.
Treating MPC as cold storage. MPC wallets are operationally warm; shares sit on connected systems by design. Deep reserves still belong in genuinely offline custody, whatever the signing math.
Skipping the exit plan. Because MPC addresses look like ordinary addresses, migrating away means signing real transactions to new wallets. Negotiate the assisted-migration commitment before onboarding, while you still have leverage.
Frequently asked questions
Is MPC custody safer than a hardware wallet?
For an institution, generally yes — not because the math is stronger, but because MPC removes the single artifact whose theft ends the story, and platforms wrap quorum policy around every signature. For an individual, a well-kept hardware wallet remains excellent; MPC's advantage grows with team size and transaction volume.
Is MPC the same as multisig?
No. Multisig uses several complete keys and the blockchain enforces the quorum, visibly, on-chain. MPC produces one ordinary signature from key shares, works identically on almost any chain, and keeps the quorum structure private. Operationally they solve the same problem; technically they are unrelated.
Can an MPC custodian move my funds without me?
It depends on the model. If you hold a mandatory share, no — the cryptography itself blocks it. If the custodian operates all shares, then policy and procedure protect you, not math, and your diligence should treat it like any hosted custody arrangement.
What happens if a key share is lost?
A threshold scheme tolerates losing fewer shares than the quorum requires: with 2-of-3, one lost share is recoverable by re-sharing from the remaining two. Losing quorum without backups is unrecoverable — which is why the recovery ceremony and encrypted share backups are the first thing to diligence.
Do regulators accept MPC custody?
Regulators evaluate custody outcomes — exclusive control, segregation, recoverability — rather than mandating a signing technology, and MPC-based custodians operate today under trust charters and state licenses. The certification gap versus HSMs is closing as threshold cryptography moves through NIST standardization.
Sources
- NIST, "Multi-Party Threshold Cryptography" project, first call for input NISTIR 8214C — initial public draft January 25, 2023.
- Fireblocks, "MPC-CMP: our open-source contribution to MPC" — algorithm publication, June 2020.
- Safeheron, open-sourced MPC implementation announcements — March 2023.
