MPC-as-a-Service (MPCaaS)

The core cryptographic protocol enabling distributed key generation and signing. Private keys are never assembled in one place; they are mathematically split into shares distributed among multiple parties (or nodes). A transaction is signed only when a pre-defined threshold (e.g., 2-of-3) of participants collaborate, using their shares to produce a single, valid signature without reconstructing the full key. This eliminates the single point of failure inherent in traditional private key storage.

The service provider operates and secures the network of signing nodes or parties that hold the key shares. This removes the operational burden for the client, who does not need to manage servers, configure secure enclaves (like HSMs), or maintain uptime SLAs for the signing ceremony. The provider ensures node diversity across geographies and cloud providers to enhance fault tolerance and resistance to coordinated attacks.

Abstracts the complex MPC protocols into simple REST APIs and software development kits. Developers integrate wallet functionality without deep cryptography expertise. Typical endpoints include:

• POST /v1/transactions/sign for transaction signing.
• POST /v1/wallets/create for distributed key generation.
• Webhook notifications for transaction lifecycle events. This enables rapid integration of secure, non-custodial wallets into applications.

A rules-based system that governs authorization policies for transaction execution. Before a signing ceremony is initiated, the proposed transaction is evaluated against configurable rules, such as:

• Whitelists/Blacklists for destination addresses.
• Transaction limits (daily, per-transaction).
• Multi-approval workflows requiring human sign-offs.
• Time-locks for large transfers. This provides enterprise-grade security and compliance controls.

Provides immutable, cryptographically verifiable logs of all key operations and signing ceremonies. Every action—from wallet creation to transaction approval—is recorded with timestamps, participant identifiers, and transaction hashes. This creates a non-repudiable audit trail essential for regulatory compliance (e.g., SOC 2, GDPR), internal security reviews, and forensic analysis in the event of an investigation.

Built to be blockchain-agnostic, supporting a wide array of digital assets and networks (e.g., Ethereum, Bitcoin, Solana, Cosmos) from a single API. The underlying MPC protocol and key shares can be used to generate signatures for different cryptographic curves (like secp256k1 for Ethereum and Ed25519 for Solana). This eliminates the need to manage separate wallet infrastructures for each blockchain.

Enables institutions to securely manage private keys for cryptocurrencies and digital assets without relying on a single point of failure. The service splits key material across multiple parties, requiring a threshold of participants to authorize a transaction. This is a core alternative to traditional hardware security modules (HSMs) and single-key wallets.

• Key Feature: Threshold Signatures where no single entity holds a complete private key.
• Example: A crypto exchange using MPCaaS to secure customer funds, requiring 3-of-5 authorized officers to sign a withdrawal.

Provides backend key management for consumer-facing applications like wallets, DeFi platforms, and NFT marketplaces. Developers integrate via API, offloading the complexity of key generation, storage, and transaction signing to the MPCaaS provider.

• Key Feature: Non-custodial architecture where end-users retain control, but the service provider never has access to a complete key.
• Example: A mobile wallet app where user keys are generated and managed via MPCaaS, enabling secure, recoverable accounts without seed phrases.

Secures the signing keys for cross-chain bridges and institutional gateways, which are high-value targets. MPCaaS coordinates signatures across multiple validator nodes or geographically distributed entities to authorize asset transfers between blockchains.

• Key Feature: Distributed signing ceremonies that mitigate the risk of a bridge hack due to a compromised single key.
• Example: A bridge locking assets on Ethereum and minting equivalents on another chain, with signatures generated by an MPC protocol among independent operators.

Embeds business logic and compliance rules directly into the signing process. Transactions can be programmed to require multiple approvals, time delays, or checks against sanction lists before an MPC signature is produced.

• Key Feature: Policy-driven signing that enforces governance at the cryptographic layer.
• Example: A treasury requiring dual approval for transfers over $1M, with rules executed by the MPCaaS platform before the transaction is cryptographically signed.

Offers secure, automated processes for key refresh and account recovery without exposing key material. Using MPC protocols, new key shares can be generated and distributed among parties, rendering old shares obsolete—a process known as proactive secret sharing.

• Key Feature: Key rotation that maintains security post-quantum or after a suspected breach without moving funds to a new address.
• Example: An institution periodically refreshing its key shares every quarter to limit the exposure window of any potential key compromise.

The service provider orchestrates a secure, distributed protocol to generate the master key. The process involves:

• Distributed Key Generation (DKG): The private key is never assembled; key shares are created in a decentralized manner among participants (e.g., user devices and service nodes).
• Secure Enclaves: Shares are often stored and processed within hardware-secured environments like Trusted Execution Environments (TEEs) or Hardware Security Modules (HSMs) to protect against memory extraction attacks.
• User-Controlled Share: In consumer models, the user typically retains one key share on their personal device.

To authorize a transaction, the MPC protocol runs a secure computation between the participating key shares. No single entity has the full private key at any point. The service provider facilitates the computation but cannot sign unilaterally. This maintains a non-custodial model, as the asset ownership is defined by the distributed key, not a centralized custodian's vault. The user's participation via their local key share is a mandatory input for any valid signature.

While eliminating seed phrases, MPCaaS introduces other considerations:

• Coordinator Compromise: An attacker compromising the service's coordination server could attempt to facilitate fraudulent signing sessions, though they still lack the necessary key shares.
• Network & Availability Risks: Dependence on service availability for signing. Providers mitigate this with high-availability architectures and optional offline signing modules.
• Side-Channel Attacks: Vulnerabilities in the implementation of the MPC protocol or the secure enclaves could leak information. Audits and formal verification of the cryptographic code are critical defenses.

MPCaaS represents a paradigm shift from traditional models:

• vs. Self-Custody (Hot/Wallet): Eliminates the catastrophic risk of a single compromised private key or seed phrase.
• vs. Multisig: Creates a single on-chain signature, reducing gas costs and blockchain footprint, while the complexity is managed off-chain.
• vs. Full Custody: The service cannot unilaterally move funds, as in a bank or exchange custodial account. The security is cryptographic, not just contractual.

MPCaaS platforms operate on a client-server model where the service provider manages the secure infrastructure for the MPC protocol. The client's secret key is never fully assembled; it is split into secret shares distributed between the client's device and the service's signing nodes. This architecture eliminates single points of failure and removes the need for users to manage complex cryptographic setups.

• Enterprise Wallet Management: Securely manage treasury and operational funds with distributed signing authority and policy controls.
• Exchange & Custody Hot Wallets: Replace vulnerable single-key hot wallets with MPC-based systems for faster, more secure customer withdrawals.
• DeFi and dApp Integration: Enable seamless, non-custodial user onboarding where the service handles key management complexity.
• Cross-Chain Operations: Provide a unified signing mechanism for transactions across multiple blockchain networks from a single interface.

Security relies on the cryptographic guarantees of the underlying MPC protocol (e.g., threshold signatures). The model assumes the service provider's nodes are honest-but-curious and that a threshold number of them do not collude. Users must trust the provider's implementation and operational security but do not need to trust them with the full private key. This is a shift from the trust-minimized model of self-custody to a distributed trust model.

Unlike traditional custodians who hold the entire private key, MPCaaS providers never have access to a complete key. Unlike hardware wallets, which are physical devices, MPCaaS is a cloud service enabling programmatic access and scalability. The trade-off is reliance on the provider's infrastructure and potential for liveness issues if the service is unavailable.

Integration typically involves:

• Using provider SDKs and REST APIs.
• Defining signing policies (e.g., M-of-N approvals).
• Handling transaction payloads and receiving signature shares. The service manages node coordination, network fees (gas), and nonce management, significantly reducing development overhead for secure transaction signing.