What is an MPC Wallet? How Multi-Party Computation Secures Digital Assets
Institutions managing digital assets at scale cannot afford a single point of failure. Yet most wallets rely on exactly that: one private key, one location, one breach away from total loss.
Multi-Party Computation (MPC) solves this problem by distributing signing authority among multiple secure environments or parties. Unlike standard wallets that require a complete private key in one place, MPC lets participants produce a valid signature without reconstructing the full key in one location.
In a threshold-signature MPC scheme, a certain number of parties must approve a transaction to sign it. For example, in a 2-of-3 scheme, two out of three parties must approve the transaction.
MPC systems minimise certain key-management risks but are not a complete security solution. Their efficiency also depends on access controls, transaction policies, recovery processes, and more.
This guide explains how MPC wallets work, which security risks they reduce, which risks remain, and how institutions should evaluate MPC implementations.
What is an MPC Wallet?
An MPC wallet is a private key management system that uses Multi-Party Computation to remove single points of failure in transaction signing. Instead of storing one private key in one location, a MPC wallet is a key management solution that uses multi-party computation to eliminate risk. In an MPC wallet, instead of the wallet relying on a single secret key, the signing authority is divided into shares. Depending on the protocol, the shares may be created from dealer-generated key material or jointly generated through distributed key generation.
Think of a bank vault containing $10 million. The bank creates a system with three different keys, held by three different people, to open it. But here’s the catch: no single person can access the contents alone. This is how an MPC wallet operates: it requires multiple people to share parts of a mathematical key to form valid blockchain signatures off-chain.
From the user’s perspective, an MPC wallet still produces standard blockchain signatures. You approve, and the transaction is processed. Behind the scenes, multiple key-share holders execute a distributed signing ceremony that produces one valid signature, but no single location ever assembles the complete key.
Does an MPC Wallet have a private key?
An MPC wallet still has underlying cryptographic signing authority corresponding to its public key, but how that authority is generated and represented depends on the protocol. In distributed key-generation systems, participants jointly create their shares without a single party first holding the complete private key.
From an operational security perspective, think of an MPC wallet as having no single point of private-key knowledge. No individual, device, or system ever possesses enough information to move funds independently.
Is an MPC Wallet the same as threshold cryptography?
MPC (Multi-Party Computation) is the broader cryptographic concept that enables multiple parties to collaboratively compute functions without revealing their private inputs to each other.
Threshold cryptography is a specific application of MPC; a minimum number of participants must cooperate to produce a valid signature.
Most institutional MPC wallets use threshold signatures, typically 2-of-3, 2-of-5, or 3-of-5 configurations. Different providers use different MPC protocols, key-generation methods, and threshold schemes.
Key Terms
| Term | Definition | Why It Matters |
| Key share | A cryptographic portion of a private key used in MPC. A single share cannot independently authorise or sign a transaction. | Distributing key shares helps reduce the risk of a single point of compromise. |
| Threshold | The minimum number of key shares required to produce a valid signature. In a 2-of-3 configuration, the threshold is 2. | Threshold design determines operational resilience. A 2-of-3 allows one share to be offline; a 3-of-5 requires more coordination but provides better separation of duties. |
| Quorum | The group of key shareholders required to reach the threshold. In a 2-of-3 setup, any 2 of 3 participants form a quorum. | Quorum composition determines who can act together. If your quorum is “operations + risk,” both must cooperate to sign. |
| Distributed Key Generation (DKG) | A process where multiple parties collectively generate key shares without any single party ever knowing the complete private key. Contrasts with dealer-based generation. | DKG avoids requiring a single dealer to possess the complete secret during generation, removing that particular trust assumption. |
| Threshold Signature | A threshold-signature implementation can produce signatures compatible with supported signature schemes, but actual blockchain support also depends on the provider’s protocol and production integration. | The resulting signature looks identical to a single-key signature on the blockchain. MPC’s complexity is invisible on-chain. |
| Signing Ceremony | The coordinated process where key-share holders execute local computations on their shares to produce a valid signature. Happens off-chain. | Signing ceremonies are the operational moment where MPC’s security is either maintained or compromised depending on implementation. |
How does an MPC wallet sign a transaction?
An MPC wallet signs a transaction through a multi-step process that keeps key shares separated while producing a valid blockchain signature.
How are MPC key shares generated and distributed?
Dealer-Based Share Generation
In dealer-based key generation, an authorised entity creates the entire private key at once, splits it into shares, and distributes them. The danger is that the dealer has the complete key for a while and must be trusted to destroy it securely afterwards.
Distributed Key Generation (DKG)
In collaborative key generation, no single party ever has access to the complete private key. Each participant independently generates random inputs, exchanges secure commitments, and contributes to the joint computation of the resulting key shares. This removes the need to trust a single party with the complete key during the generation process and reduces the risk of key exposure or manipulation by one participant.
Key sharing approaches vary between wallet tiers:
- Hot wallets: Shares stored across different cloud clusters for quick access
- Warm wallets: Shares stored between the cloud and an offline storage system
- Cold wallets: Shares stored in offline hardware security modules, vaults, or isolated devices
Key shares are assigned based on location, type, environment, and the people involved; the key point is that the complete private key is never formed during operation.
Transaction Request and Policy Validation
When a transaction is initiated:
- Policy Screening: The transaction is checked against approval rules: Is the recipient whitelisted? Does the amount exceed daily limits? Does it require approvals from specific roles?
- Approval Collection: Required approvers review and approve the transaction.
- Separation of Concerns: Policy logic is kept distinct from cryptographic signing. Policy rejections happen before signing.
- Ready for Signing: Only after policy validation passes does the transaction move to the signing phase.
Threshold Signing and Blockchain Broadcast
Once a transaction passes policy validation, the signing ceremony begins:
- Signing Initiation: The system notifies key-share participants that a signature is needed.
- Local Computation: Each shareholder performs local computations using their share without revealing it.
- Partial Signatures Combine: Partial results are combined mathematically to produce a valid ECDSA, EdDSA, or other blockchain-compatible signature.
- Blockchain Broadcast: The valid signature is broadcast to the blockchain and appears identical to a single-key wallet signature.
If the signing threshold is not met, then a 2-of-3 threshold can produce a signature if one participant is offline. A 3-of-5 threshold fails if only two participants are available, leaving the transaction pending. Timeout and retry behaviour is provider- and configuration-specific.
Invalid or unavailable signing contributions are handled according to the protocol and provider implementation. Institutions should understand whether a failed signing attempt remains pending, expires, requires retry or triggers additional security controls.
Share Refresh, Recovery and Business Continuity
Transfer of Shares: Depending on the protocol, implementations may support share refresh, resharing or participant replacement without changing the wallet’s public address. For example, in a 2-of-3 wallet, a lost share can be replaced by the remaining two participants executing a refresh protocol without changing the wallet address. Institutions should verify exactly how recovery works in their provider’s implementation.
Recovery of Shares: If one share is lost, the remaining shares above the signing threshold can generate a replacement share for continued operations.
Business Continuity: Operations continue as long as the configured signing threshold can still be met by available participants.
Which wallet-security risks does MPC reduce?
| Risk Category | Risk | MPC Contribution | Additional Control Still Needed |
| Infrastructure | Single server compromise | One compromised environment may expose one share. A below-threshold compromise should not independently provide sufficient signing authority under the protocol’s security assumptions. | Endpoint security monitoring, intrusion detection, regular security audits of all share locations |
| Personnel | Rogue employee | No single employee can sign independently when threshold and role-separation policies are properly implemented. | Role-based access controls, approval workflows, behavioural monitoring for suspicious approvals |
| Infrastructure | Lost or destroyed device | Remaining shares above the threshold can continue operations. Share recovery procedures replenish lost shares. | Tested recovery procedures, documented runbooks, regular disaster recovery drills |
| Infrastructure | Infrastructure outage | Threshold design can support geographic or provider redundancy. | Geographic distribution of shares, provider diversity, tested failover procedures |
| Transaction | Phishing or address substitution | MPC offers minimal protection against this attack vector. | Whitelisting of recipient addresses, transaction screening, manual review of large or unusual transfers |
| Personnel | Participant collusion | MPC prevents one participant from signing alone, but does not prevent a threshold of colluding participants from acting together. | Separation of duties across independent control domains, behavioural monitoring, audit trails reviewed by different teams |
Which risks does MPC not protect against?
MPC is powerful, but has clear limits. Institutions often overestimate MPC’s protection without understanding what it cannot protect against.
MPC does not protect against:
- Compromise of enough shares to reach the signing threshold: If attackers control 2 of 3 shares or 3 of 5 shares, they can sign transactions. Security depends entirely on keeping shares separate.
- Collusion between threshold participants: MPC prevents one participant from acting alone, but not a threshold of participants colluding together.
- Weak endpoint or device security: If a device holding an MPC key share lacks basic security controls, an attacker can compromise that key share regardless of MPC security.
- API compromise: A compromised API or application layer may allow an attacker to manipulate, submit or redirect transaction requests depending on the architecture, even if the underlying MPC protocol remains intact.
- Poorly designed approval policies: If policy rules allow unauthorised users to approve transactions, MPC’s security is irrelevant.
- Authorised users approving malicious transactions: MPC cannot distinguish between legitimate and malicious transactions approved by authorised employees.
- Smart-contract and blockchain protocol risk: MPC secures the signing process, not the smart contracts or protocols receiving the transaction.
- Weak backup and recovery planning: Insecurely backed up shares or untested recovery procedures can be exploited.
All in all, MPC is one critical layer within a broader institutional wallet-security architecture. It is not a complete security solution.
MPC VS Multi-Sig: What is the difference?
MPC and multi-sig both distribute signing authority, but they do it in fundamentally different ways. Confusing them can lead to the wrong architecture for your use case.
| Attribute | MPC | Multi-Sig |
| Signing model | Distributed mathematical shares of one private key | Multiple complete private keys |
| Signing visibility on-chain | Usually off-chain; standard signature on-chain | Often visible on-chain depending on blockchain and implementation |
| Blockchain compatibility | Protocol-independent; works on any blockchain supporting standard signature schemes (ECDSA, EdDSA) | Chain-dependent; requires a chain-native, script-based or smart-contract implementation, depending on the blockchain. |
| Quorum changes | Can often change the threshold without changing the wallet address | May require a new address or complex multi-sig script updates |
| Fee overhead | Standard blockchain signature; normal network fees | May create additional on-chain data (multiple signatures) or execution costs on some networks |
| Operational complexity | Depends on the protocol, participant architecture and provider implementation. | On-chain complexity; each additional signer adds friction and cost |
Cryptographic compatibility does not automatically mean that a wallet provider supports a particular blockchain in production.
Where do HSMs fit?
An HSM (Hardware Security Module) provides a hardware security boundary rather than serving as a wallet architecture that competes directly with MPC or Multi-Sig. Depending on the implementation, an HSM can protect a complete private key, an MPC key share, a Multi-Sig signing component, or other sensitive credentials.
Institutions can also combine MPC and HSMs to apply different layers of protection. For example, an HSM can protect individual MPC key shares while MPC distributes signing authority across multiple participants or environments. This can provide both cryptographic separation and hardware-based protection, although the overall security depends on how the architecture, access controls, recovery processes, and other security measures are implemented.
When is an MPC wallet appropriate?
MPC wallets do not offer a one-size-fits-all solution. The right architecture depends on transaction volume, team structure, regulatory requirements, and multi-chain scope.
MPC is appropriate when:
- Your institution needs to scale beyond single-key wallets but wants to avoid on-chain multi-sig complexity
- You operate across multiple control domains and need protocol-independent key management
- You require genuine separation of duties across teams or geographies
- Your transaction volume justifies operational investment in threshold governance
- Regulators or customers expect institutional-grade security
Regulatory expectations differ by jurisdiction, but institutions should evaluate requirements around key management, segregation of duties, asset safeguarding, wallet architecture, operational resilience and auditability against the rules applicable to their licensed activities.
MPC is particularly valuable for Banks and custody platforms, exchanges and fintechs, asset managers managing tokenised RWAs, and cross-border payment providers.
Retail VS Institutional MPC Wallets
MPC wallets can serve both retail and institutional users, but the requirements are often different. Retail MPC implementations typically prioritize usability, straightforward transaction flows and account recovery, while institutional MPC architectures generally require stronger governance and operational controls.
These may include role-based access, multiple operational participants, configurable transaction policies, compliance workflows, audit logging and business-continuity or recovery procedures. The appropriate design depends on the organization’s risk profile, operating model and control requirements rather than on MPC alone.
When MPC may not be appropriate
- Smaller or less complex operations with limited delegation requirements may not need the operational complexity of an institutional MPC architecture.
- Some high-frequency environments may require signing architectures optimized for low latency and high availability. Institutions should benchmark MPC performance and operational dependencies against their throughput and resilience requirements.
- Simple use cases like a single cold-storage wallet managed by one organisation with no delegation needs; traditional single-key HSM may suffice
- Organisations lacking operational maturity to implement proper share separation and access controls; MPC’s security depends on institutional discipline, and weak governance undermines it
The worst outcome is deploying MPC correctly in theory but operationally failing to maintain proper share separation. A complex system that’s poorly operated is less secure than a simple system that runs well.
How should institutions evaluate an MPC Wallet Provider?
Evaluating an MPC wallet provider requires examining both cryptographic design and operational reality. This framework helps structure those conversations:
| Evaluation Area | Question to Ask | Why It Matters | Red Flag |
| Cryptographic protocol | Which MPC protocol is used? (e.g., ECDSA with Lindell’s protocol, EdDSA variants?) | Different protocols have different security properties and auditability. You need to understand what you’re deploying. | Providers cannot articulate which protocol they use or resists technical scrutiny. |
| Key generation | Is key material dealer-generated or created through distributed key generation? Does the complete key ever exist? | Dealer-based generation has a single point of knowledge during key creation. DKG is more robust but more complex. | Dealer-based generation with inadequate controls over the dealer key destruction. |
| Threat model | Which participant-compromise and collusion scenarios does the design address? | The provider should articulate their assumptions about what attackers can do. Know where the boundaries are. | Provider claims MPC protects against all threats or refuses to discuss limits. |
| Independent audit | Who audited the protocol and implementation? When? What was in scope? | Look for an independent firm with demonstrated cryptography and implementation-security expertise. | No independent audit, or the audit covered only the protocol without an implementation review. |
| Share administration | Are shares genuinely separated across different control domains (people, systems, geographies)? Or do the same two people effectively control everything? | Real separation is the foundation. Audit configurations to confirm separation of duties is genuine, not theoretical. | All shares in one cloud provider’s account, or controlled by the same team. |
| Recovery | How are unavailable, lost, or compromised shares refreshed or replaced? Is recovery tested? | Recovery procedures are often the weakest point. Know exactly how it works before you need it. | Recovery procedures exist only in documentation; no evidence of regular testing. |
| Deployment | Which deployment options are supported? (cloud, on-premises, mobile, HSM, offline, TEE) | Your architecture depends on deployment flexibility. Confirm the provider supports your intended setup. | The provider offers only one deployment model with no flexibility. |
| Resilience & SLAs | What are the uptime, disaster-recovery, RTO and RPO commitments? | Resilience is operationally critical. Confirm SLAs are documented and tested. | No SLAs documented, or SLAs longer than your operational requirements. |
| Incident response | How are vulnerabilities disclosed and resolved? | Know the vulnerability disclosure and patching process before an incident occurs. | No formal vulnerability disclosure program or slow patching history. |
| Auditability | Are approvals, policy changes, and signing events recorded in appropriately protected and auditable logs? | Audit trails are essential for compliance and forensics. Confirm logs are recorded in an auditable transaction and activity log. | Logs can be modified or deleted, or retention is shorter than regulatory requirements. |
| Multi-chain support | Which blockchains are supported today vs. on the roadmap? | Confirm the provider actively supports all chains you need, not just planned support. | Limited chain support that doesn’t cover your roadmap. |
| Fit for your team | Is there a usable dashboard for non-engineers? Are APIs clean and well-documented? | The best architecture fails if your team can’t operate it. Evaluate usability seriously. | Complex APIs, poor documentation, or requiring deep cryptography expertise for operations. |
| Portability & Exit | What happens to assets, addresses, and signing control if the provider relationship ends? | Avoid lock-in. Understand your options if you need to migrate. | Assets locked in the provider ecosystem with no path to migrate to a competitor. |
How Liminal Implements MPC Wallet Infrastructure
Liminal’s institutional wallet infrastructure combines MPC-based key management with enterprise-grade policy controls and multi-chain support. The architecture separates cryptographic signing from operational governance, allowing institutions to enforce strict transaction rules while delegating key protection to a specialised cryptographic layer.
Wallet Architecture and Control Model
Key shares are generated across multiple participants and stored in geographically separate locations, cloud regions, HSMs or offline storage, depending on the wallet tier.
In a typical deployment:
- Hot wallet key shares are distributed across multiple cloud availability zones for high availability.
- Warm wallet shares are split between online infrastructure and offline backup, balancing speed and security.
- Cold wallet shares are stored in offline HSMs or air‑gapped devices, prioritising security over transaction speed.
The full private key is never reconstructed during normal operations. It comes together only under strict controls, in tightly audited recovery scenarios with explicit multi-party authorisation.
Policies, Compliance Controls and Automation
Liminal’s policy engine operates at the platform layer, distinctly from the underlying MPC cryptography. This separation allows institutions to update approval rules, limits and governance requirements without touching the cryptographic infrastructure.
An institution may configure different approval requirements based on transaction value, destination, asset type, risk level or user role.
Configured compliance checks such as transaction screening, sanctions controls and Travel Rule integrations where applicable can run before signing according to the institution’s configured workflow.
Automation capabilities handle routine tasks, sweeping rewards to cold storage, refilling hot wallets, optimising gas fees and rebalancing treasuries, all under the same policy and compliance rules as manual transactions.
Deployment and Integration
Liminal supports three primary deployment models:
- Wallet-as-a-Service (WaaS): Liminal hosts all infrastructure, manages blockchain connectivity and MPC operations, and provides 24/7 monitoring. Institutions integrate via REST APIs, define policies in the dashboard, and manage approvals and signing through Liminal’s platform.
- White‑label WaaS: Branded wallet experience with configurable policies; infrastructure hosted by Liminal (API/SDK integration).
- On‑prem / dedicated HSM Vault: Clients deploy cold storage in their own environment (on‑prem, co‑located, or via regulated partners); Liminal provides the HSM+MPC architecture and policy/compliance layer.
- Institutional custody: Liminal can operate wallets end‑to‑end for clients who prefer a managed service, with role‑based access, approvals, and signing; legal custody arrangements depend on the contract (non‑custodial sovereign models are also available).
Integration with enterprise systems happens through Liminal’s APIs: treasury platforms for balances and payments, ERP for reconciliation, payment rails for settlement, and compliance platforms for audit exports and regulatory reporting.
Liminal supports Bitcoin, Ethereum, Solana and 100+ other chains.
Liminal’s wallet infrastructure can support MPC-based wallet operations across multiple supported blockchain networks, subject to each network’s cryptographic requirements and Liminal’s production integration.
Institutional MPC Workflow in Practice
A typical institutional transaction shows how policy controls and MPC cryptography interact:
- The Treasury user creates the transaction.
- Platform performs policy/compliance checks.
- Human/business approvals are collected.
- Once approved, the MPC signing infrastructure or authorized signing endpoints participate according to the configured threshold.
- A valid signature is generated.
- Transactions are broadcast.
- Audit and monitoring records are captured.
Security Evidence and Implementation Experience
Recognised security certifications and a track record of large-scale deployments back Liminal’s institutional wallet infrastructure:
- Certifications: SOC 2 Type II attestation (security, availability, integrity controls) and ISO 27001 certification (information security management).
- Audit scope: Covers custody operations, key management, policy enforcement, access controls and incident management.
- Implementation experience: Liminal supports exchanges, custodians, asset managers and other institutions across Singapore, the UAE, India, Taiwan and other jurisdictions, with 2-of-3 and 3-of-5 MPC configurations and share separation across geographies and organisational boundaries.
- Transaction data: The platform has processed well over $100 billion in on-chain transaction volume to date across multiple chains.
