MPC Wallets: Enterprise Custody Guide

Every few months we get the same call. A fintech is preparing to list tokenised assets, a corporate treasury wants to hold stablecoins, or a regulated broker is launching a custody product. The question is always some version of: "How do we hold keys in a way that auditors, regulators, and our insurance underwriter will all sign off on?"

In 2026, the answer almost always involves MPC. Multi-party computation has quietly become the default cryptographic pattern for institutional custody, displacing both cold-storage paper wallets and traditional multisig for most enterprise use cases. This is what we have learned deploying it in production across trading firms, wallet platforms, and corporate treasuries.

What MPC Actually Is (Without the Marketing Layer)

Multi-party computation is a branch of cryptography that lets a group of parties jointly compute a function over their inputs without any single party learning the others' inputs. For wallets, the function is a signature, and the inputs are shares of a private key.

In a threshold signature scheme (TSS), the private key never exists in one place. It is split into shares distributed across machines, regions, or administrative domains. To sign a transaction, a threshold of shareholders (for example 2 of 3, or 3 of 5) runs a multi-round protocol that produces a valid ECDSA or EdDSA signature without ever reconstructing the key. The output looks identical to a signature produced by a normal single-key wallet — on-chain there is no "MPC signature" marker.

This distinction matters. Unlike on-chain multisig, MPC is invisible to the blockchain. You pay the same gas, you work with any chain that supports the underlying curve, and you are not locked into a specific smart contract standard. The policy layer lives off-chain, which is both the strength and the thing you have to engineer carefully.

Why Enterprises Are Moving Away From Traditional Approaches

For years the choices were cold storage, HSMs, or on-chain multisig. Each has real problems at institutional scale:

• Cold storage. Secure against remote attackers, but operationally expensive. Every signing ceremony needs a physical quorum, which rules out automated flows like market-making, programmatic settlement, or 24/7 client withdrawals.
• HSMs. Excellent for key confidentiality, but the key exists inside the device. A compromised operator, a firmware bug, or a vendor zero-day means the whole key is at risk. HSMs also do not natively speak blockchain signing semantics, so you end up wrapping them in custom code.
• On-chain multisig. Cryptographically sound but chain-specific. A Gnosis Safe on Ethereum is not a Safe on Solana. You maintain different policy models per chain, pay multiple on-chain signatures per transaction, and expose your custody policy publicly.

MPC solves the operational problem of cold storage, the single-point-of-failure problem of HSMs, and the chain-lock-in problem of multisig. That is why it has won.

The Architecture We Actually Deploy

A production MPC custody stack has four layers, and getting each one right matters more than the choice of underlying TSS library.

1. The Signer Nodes

We typically run three or more signer nodes in different trust domains. One inside the customer's primary cloud account (AWS, Azure, or GCP), one in a second cloud provider, and one either on-premises or with an independent custodian. The point is that no single vendor outage, credential breach, or insider can produce a signature.

Each node runs inside a confidential computing enclave where the platform supports it — AWS Nitro Enclaves, Azure Confidential VMs, or GCP Confidential Space. The key share lives only in enclave memory, attestation is verified before any protocol round starts, and boot images are reproducibly built and signed.

2. The Policy Engine

This is where most teams get it wrong. The policy engine decides whether a signing request is legitimate before the MPC protocol even runs. It enforces velocity limits, destination allowlists, time-of-day rules, dollar-value thresholds, and approval workflows for large withdrawals. We have seen customers with beautiful cryptography and a policy engine that would approve a transfer to any address as long as the API key was valid. The cryptography is useless at that point.

The private key is safe from theft, but the signing authority is not. Policy is where custody actually lives.

3. Key Lifecycle Management

Key generation, rotation, share re-randomisation, and disaster recovery all need to be planned before the first key is generated. Proactive share refresh (rotating shares without changing the public key) is the MPC equivalent of key rotation. We rotate shares quarterly on high-value keys and whenever any signer node is rebuilt.

Recovery is the scariest part. If you lose a threshold number of shares, the key is gone and so are the assets. We require every deployment to have offline, geographically distributed backup shares with a documented recovery ceremony that has been rehearsed — not just written down.

4. Observability and Audit

Every signing request, policy decision, and protocol round gets logged to an append-only store. Regulators and auditors will ask for this. So will the security team the first time something looks anomalous. We feed the signing telemetry into the SIEM alongside application logs and alert on deviations: unusual times, unusual destinations, unusual volumes, or signer nodes that fail attestation.

Regulatory Reality in 2026

MiCA in Europe, the revised FATF Travel Rule guidance, and the UK's cryptoasset regime have all matured to the point where "we use MPC" is no longer sufficient as a regulatory story. What auditors and regulators want to see:

• Segregation of duties. The person who can approve a signing policy cannot also hold a key share. The person who runs the signer cannot modify the policy.
• Demonstrable cryptographic soundness. Use TSS libraries that have been publicly audited (GG20, CGG21, DKLS and their production implementations). In-house TSS is a red flag.
• Proof of reserves and proof of control. You need to be able to show on demand that customer liabilities are backed by assets you actually control, using cryptographic attestation rather than a screenshot.
• Business continuity. Documented, tested procedures for signer node failure, region outage, and vendor compromise.

Where MPC Is Not the Answer

We try to talk customers out of MPC when the use case does not justify it. A small corporate treasury holding a single stablecoin position with manual, infrequent transactions is often better served by a well-configured hardware wallet plus multisig. MPC adds operational complexity — nodes to run, protocols to monitor, shares to back up — and that complexity has a cost. If transaction volume is low and automation is not a requirement, the simpler pattern wins.

MPC also does not fix smart contract risk, oracle manipulation, or social engineering. It protects the key. Everything else in the stack still needs its own controls.

How to Evaluate a Vendor or Partner

• Ask for the TSS protocol and library. If they cannot name it, walk away. If it is proprietary with no public audit, walk away.
• Ask how shares are generated and where they live. Enclave-backed, multi-domain deployments are the bar in 2026.
• Ask about policy engine expressiveness. Can you encode your actual governance rules, or just static allowlists?
• Ask about chain coverage. ECDSA (Bitcoin, Ethereum and EVM chains, Cosmos) and EdDSA (Solana, Sui, Aptos) cover most of the market. If you need Starknet, Tron, or newer curves, verify explicitly.
• Ask about recovery. If the answer is vague or involves a single vendor-controlled backup, that is the risk model you are buying.

The Short Version

MPC has matured from cryptographic research into the default custody pattern for institutional digital assets. The hard problems in 2026 are not whether to use it — they are policy design, operational readiness, and regulatory evidence. Teams that treat MPC as a cryptographic library get breached or audited. Teams that treat it as a custody system — with policy, lifecycle, observability, and rehearsed recovery — are the ones shipping regulated products on schedule.

We have built and operated this stack for trading firms, wallet platforms, and treasuries, and the patterns above are the ones that survive contact with real volume, real regulators, and real incidents.