MPC Wallets Aren’t Enough: What Institutional Crypto Custody Actually Requires

Key Takeaways

• MPC is the baseline now, not the differentiator. Distributing signing authority across independent key shares removes the single point of failure behind most major custody breaches. Any provider still building around one private key is selling a design the market has already moved past.
• The real value is governance, not cryptography. Thresholds and policy rules let a business encode who can approve what, under which conditions. Control stops depending on whether people follow a documented procedure and becomes a property of the system.
• The MPC label on its own tells buyers almost nothing. Custodial and non-custodial setups run the same math. What separates them is who holds the shares, whether the provider can sign without you, and whether any of that is contractually enforceable.
• Most losses now start with people, not keys. Social engineering, blind signing, and compromised interfaces bypass the key layer entirely by producing a valid signature from a legitimate share. That is why institutional custody has to be tiered: a policy engine, transaction screening, tamper-evident logs, and tested recovery built around the signing layer.

Bybit lost $1.5 billion in a single breach in February 2025. Across the industry that year, crypto theft reached $3.4 billion. What connects those incidents is not a broken blockchain or weak cryptography. It is control. Somewhere in each stack, one key, one device, or one approver could move everything, and an attacker only had to reach it. That is a custody design problem, which means it is a solvable one.

That pattern is exactly what institutional custody teams are trying to design out. Whether you’re a treasury lead evaluating custody options, a risk officer mapping approval workflows, or an exchange operator responsible for client assets, the core question is the same: how do you hold digital assets in a way that no single person, device, or vendor can unilaterally move them, and how do you prove that to auditors, regulators, and your board?

MPC (Multi-Party Computation) wallets were built to answer that question. Signing authority is distributed across independent private key shares held by separate parties, so no single share is ever a usable key on its own, and a transaction requires a threshold of shares to compute a valid signature without any share ever being combined or exposed in full.

But the cryptography is only part of the story. The deeper value for institutions is structural: distributed signing gives businesses a mechanism to define exactly who can authorize transactions, under what conditions, and with what recovery options, rather than inheriting a digital asset custody model someone else designed.

How Does an MPC Wallet Work?

This differs from both traditional single-key wallets and multisig arrangements in ways that matter for institutional and business use cases. MPC signing follows a four-stage process.

1. Key share generation. Rather than generating one private key and splitting it, participating parties each generate their own key share independently through a cryptographic protocol. The shares are mathematically linked but individually meaningless. (Note: specific key generation protocols vary by implementation and should be confirmed with your provider.)
2. Distributed storage. Each party stores only their own share. The shares can be held by different devices, organizational roles, or even different companies. Because no full key is ever assembled, there’s no moment of exposure during setup.
3. Threshold signing. When a transaction needs to be authorized, the required number of share-holders (the threshold) participate in an interactive computation, following what’s known as a threshold signature scheme. A valid signature is produced collaboratively; the shares never leave their respective environments, and no complete private key is ever reconstructed.
4. On-chain broadcast. The resulting signature is indistinguishable from a standard single-key signature on the blockchain. From the network’s perspective, the transaction looks normal. The distributed custody model is entirely off-chain.

What Business Problems Does an Institutional-Grade MPC Wallet Solve?

The cryptography is the mechanism. The reason institutions adopt it comes down to a specific set of operational problems that single-key and provider-controlled custody models can’t fix.

• Concentrated key risk. In a single-key model, one compromised laptop, one phished executive, or one rogue insider can drain the treasury. An institutional MPC wallet removes the target entirely: there is no full key to steal, and no single employee whose compromise equals total loss. This directly addresses the failure mode behind breaches like Bybit.
• Approval workflows that exist only on paper. Many organizations have a documented policy that large transfers require sign-off from finance and risk, but the actual signing key sits with one operations person. MPC lets the business encode the policy into the signing process itself: the transaction cryptographically cannot execute without the required roles participating. Governance stops being a procedure people are trusted to follow and becomes a property of the system.
• Unauditable custody operations. Boards, auditors, and regulators increasingly ask institutions to demonstrate who approved which transaction, when, and under what policy. A properly built MPC deployment produces a signing trail mapped to organizational roles, which turns audit season from reconstruction work into a reporting exercise.
• Single-person and single-vendor dependency in recovery. If your recovery plan is a seed phrase in a safe or a promise from a provider, business continuity depends on one artifact or one company. MPC supports recovery paths defined in advance, so a lost share, a departed employee, or a vendor disruption doesn’t translate into lost assets.
• Scaling approvals without scaling risk. As transaction volume grows, requiring senior sign-off on every transfer becomes a bottleneck, while loosening controls uniformly creates exposure. Threshold and policy configuration lets institutions route low-value transactions through fast paths and reserve multi-party approval for high-value or unusual activity, so control scales with risk rather than blocking operations.

How Does MPC Change Practical Control?

The cryptographic mechanics enable something operationally significant: configurable control.

A business deploying an MPC wallet can choose a threshold. For example, requiring 2 of 3 shares to sign, or 3 of 5 for high-value transactions. These thresholds can map to real organizational roles: a treasury team member, a risk officer, and an automated policy engine might each hold a share.

Beyond thresholds, a well-implemented MPC system supports a policy layer: rules that govern which transactions qualify for which approval paths. A $500 transfer might need one share; a $5 million withdrawal might require three, plus a time delay. Recovery paths can be defined in advance, so a lost share doesn’t mean lost assets.

This is the practical reframe: MPC doesn’t just reduce key-theft risk. It gives businesses a framework to encode their own governance directly into how signing works.

What Risks Doesn’t MPC Solve, and Why Do They Demand Institutional-Grade Architecture?

MPC addresses key-level vulnerabilities. It does not address everything else, and the clearest evidence is where crypto crime went after distributed signing became standard. Attackers largely stopped going after keys. They go after the people authorized to use them.

That shift explains why losses keep climbing in a market that has broadly adopted better key architecture. Bybit was approved by legitimate signers reading a manipulated interface. The same playbook runs through fake support calls, spoofed vendor payment instructions, malicious dApp approvals, and months-long impersonation of executives and counterparties. Every one of those attacks ends with a technically valid signature from a share its rightful holder still controls. The cryptography does exactly what it promises and the funds leave anyway.

• Social engineering and blind signing. Approvers can be manipulated into authorizing a malicious transaction with their legitimate share, especially when the payload they are signing is hard to read and the request arrives with urgency attached.
• Weak policy design. A threshold of 1-of-1 with one party holding all the influence defeats the point. The security of an MPC setup is only as strong as the governance policy built around it.
• Provider dependency. If a provider holds shares, goes offline, or changes terms, access may be disrupted. Understand the continuity provisions before committing.
• Collusion. If threshold parties collude, or if shares are held by entities under common control, the distributed model is nominal rather than real.
• Smart contract risk. When MPC wallets interact with DeFi protocols or token contracts, vulnerabilities in those contracts aren’t covered by the wallet’s signing architecture.

None of these are reasons to avoid MPC. They are the reason institutions cannot stop at MPC. Social engineering works precisely because it converts an authorized approver into the attack path, and the only durable counter is a system that will not take one approver’s word for it. Institutional-grade architecture is what enforces that, and it is what separates a wallet from a custody operation. 

What Does Institutional Custody Actually Require?

MPC is a signing architecture, not a custody model. The same cryptography sits underneath a self-custody wallet and a fully custodial platform, which is why the label settles on almost nothing during vendor selection. What defines institutional custody is everything built around the signing layer, and mature deployments treat that as tiers rather than a single control. Each tier assumes the one beneath it has already failed.

• Tier 1, the key layer. Shares are generated independently and never assembled, so there is no complete private key to steal, phish, or leak. This is where MPC does its work, and where most providers stop.
• Tier 2, the policy layer. Thresholds map to real organizational roles, and rules govern which transactions qualify for which approval path: value limits, address whitelists, time delays, and role-based routing are enforced at the system level rather than in a written procedure.
• Tier 3, the screening layer. Transaction risk screening checks destinations and counterparties before a signature is produced, so exposure to sanctioned or high-risk addresses is caught ahead of settlement instead of during a post-incident review.
• Tier 4, the evidence layer. Every signing event is logged in a tamper-evident way and mapped to organizational identity, which turns board reporting and audit season into a reporting exercise rather than a reconstruction project.
• Tier 5, the continuity layer. Recovery paths are documented, tested, and executable without reconstructing a full private key, and shareholder identities, thresholds, and continuity provisions are enforceable contract terms.

Share ownership is what all five tiers rest on, so it is worth settling first. Ask who holds each share, whether the provider can sign without your participation, and what happens to access if that provider goes offline or becomes insolvent. If those answers are not written into a contract, everything layered above them is decorative. For a deeper breakdown of how share ownership determines the custodial and non-custodial line, see Non-Custodial vs. MPC Wallets: The Next Generation of Digital Asset Custody.

What Should You Look for in an MPC Wallet Provider?

A condensed checklist for evaluating providers:

• Share distribution: Does your organization hold at least one share independently?
• Policy configurability: Can approval thresholds be set per transaction type, amount, or role?
• Recovery design: Is there a documented, tested recovery path for lost shares?
• Audit trail: Are all signing events logged in a tamper-evident way, and is that logging paired with ongoing transaction monitoring rather than a one-time setup check?
• Provider continuity: What happens to your assets if the provider ceases operations?
• Technical transparency: Can the provider explain their signing protocol clearly, without hand-waving?
• Integration scope: Does the infrastructure support the chains and asset types you need?

Build Your MPC Wallet Infrastructure with ChainUp

ChainUp builds the infrastructure layer institutions run custody on, rather than a wallet product they have to bend their governance around. The MPC model is non-custodial and policy-configurable by default: businesses hold their own assets, set their own thresholds, and define approval logic per transaction type, value band, and role.

• The full custody stack from one infrastructure partner. Distributed signing, a configurable policy engine, KYT transaction screening, and tamper-evident audit logging come from the same system, so institutions are not stitching four vendors together and reconciling four sets of logs when an auditor asks who approved what.
• White-label by design. The infrastructure runs under your brand and your governance, which matters for exchanges, brokers, and custodians whose clients need to see one accountable operator instead of a chain of subcontractors.
• Built for multi-asset, multi-chain operations. Coverage spans the chains and asset types institutional desks actually hold, so custody policy does not fragment every time the business adds a new asset or a new market.
• Compliance-ready infrastructure, not a compliance promise. AML/CFT, KYC, KYT, travel rule support, and audit trails are built into the software, so the evidence regulators and boards ask for is produced by the system rather than assembled after the fact.
• Recovery designed in advance, not improvised. Documented recovery paths restore signing capability after a lost share or a personnel change without ever reconstructing a full private key.

Digital asset custody control stays with the business. ChainUp provides the infrastructure that makes that control operational, enforceable, and provable.

Explore ChainUp’s White Label MPC Wallet to see how the policy engine, share distribution, and recovery design work in practice, or talk to the ChainUp team today for a walkthrough mapped to your own approval thresholds.

Frequently Asked Questions

What is the difference between MPC and multisig wallets? 

Both distribute signing authority, but multisig records approval logic on-chain and is typically chain-specific. MPC handles signing off-chain, making it more flexible across asset types and easier to update governance rules without on-chain transactions.

Does an MPC wallet mean I always control my crypto? 

Not automatically. Custodial MPC arrangements exist where a provider holds sufficient shares to sign without user participation. Control depends on who holds which shares and whether the threshold requires your involvement.

How many parties need to sign in an MPC wallet? 

This is defined by the threshold configuration, commonly expressed as M-of-N (e.g., 2-of-3 or 3-of-5). The appropriate threshold depends on the organization’s risk tolerance, transaction volume, and governance requirements.

Can an MPC wallet be hacked? 

MPC eliminates the risk of a single key being stolen, but other attack vectors remain: compromised signing interfaces, weak approval policies, collusion among shareholders, and smart contract vulnerabilities on receiving protocols. Security depends on the full system, not just the key architecture. This is why institutional deployments pair MPC with a policy engine, transaction monitoring, and audit logging.

Is MPC suitable for businesses rather than individual users? 

MPC is particularly well-suited to institutional and business contexts where multiple stakeholders need to participate in transaction approval, governance needs to be auditable, and asset values justify a more structured custody model.

What happens if one key share is lost? 

A well-designed MPC system includes a recovery protocol for lost shares. The specifics vary by provider, so confirm that a tested recovery path exists and that it doesn’t require reassembling a full private key.