Multi-Party Computation (MPC)

Multi-party computation (MPC) is a cryptographic method that lets multiple participants jointly compute a function using private inputs without revealing those inputs to one another beyond what the prescribed output reveals.^[1]​^[2]

By distributing computation rather than concentrating secrets in one place, MPC can reduce reliance on a single party or device that could expose complete inputs or a full cryptographic key.^[1]​

History

The theoretical development of MPC is traced to 1982, when secure two-party computation was formally introduced through the “Millionaire’s Problem,” and to 1986, when Andrew Yao extended the framework to feasible computations more generally.^[2] MPC entered the digital-asset sector in 2016, where it became a technology used in institutional wallet infrastructure.^[2]​

MPC was long regarded as theoretically powerful but too expensive for routine use. Advances in protocol design, network assumptions, preprocessing, specialized subprotocols, hardware performance, and engineering have made it practical in more settings.^[1] Because network rounds, interaction patterns, and expensive cryptographic operations can dominate local computation, practical systems often reduce rounds, move work into preprocessing, or specialize protocols for tasks such as signatures and set intersection.^[1] Some deployments trade robustness for lower latency and use task-specific protocols rather than a general-purpose secure-computation system.^[1]​

Security Model

MPC security is commonly analyzed using the ideal/real simulation paradigm. In the ideal model, a trusted functionality receives participants’ private inputs, computes the requested function, and returns the prescribed outputs; an interactive protocol is considered secure when an adversary’s view of the real execution is no more informative than its view of that ideal process.^[1]​

This guarantee has limits. MPC does not prevent information leakage inherent in an output, such as a match result or an average calculated over a small population, and it does not generally establish that participants supplied truthful or well-formed inputs.^[1] Applications that require authenticated or range-limited inputs can add checks such as signatures, commitments, zero-knowledge proofs, or system-level controls.^[1] Security proofs also do not necessarily ensure that a protocol completes: participants may stall or abort, and privacy and correctness can hold even when the result is not delivered to everyone.^[1]​

The guarantees depend on the adversary model. Semi-honest participants follow the protocol but try to infer additional information from their transcripts; malicious participants may deviate, send malformed messages or inconsistent shares, or abort strategically.^[1] Defending against malicious behavior generally requires additional rounds, proofs, checks, and communication, while covert-security models aim to deter cheating by giving it a chance of detection.^[1]​

In a static corruption model, the adversary selects which parties to corrupt before execution; in an adaptive model, it can corrupt parties during execution.^[1] Proactive systems periodically refresh shares so that an attacker must compromise enough participants within a limited time window rather than accumulate compromises indefinitely.^[1] The number of corrupt participants tolerated, synchrony assumptions, and other thresholds affect which combinations of privacy, correctness, fairness, and guaranteed output delivery can be achieved.^[1] Fairness means that one participant cannot obtain the output while preventing the others from obtaining it.^[1]​

Computation and Protocols

MPC computations can be represented as circuits of operations such as addition, multiplication, comparison, or Boolean gates. Participants evaluate the circuit gate by gate using protected intermediate values rather than exposing the underlying inputs.^[1] In principle, arbitrary polynomial-time functions can be securely computed, although efficiency and achievable guarantees vary by setting.^[1]​

Secret-sharing protocols and two-party garbled circuits are major approaches to MPC.^[1] Garbled circuits, associated with Yao’s work, let one participant encode a circuit in encrypted form for another to evaluate without learning the hidden wire values.^[1] MPC protocols use encoded intermediate states—including shares, encryptions, masked values, and commitments—and transitions intended to preserve privacy and correctness.^[1] Composition theorems and universal composability provide formal ways to analyze security when protocols are combined or embedded in larger systems.^[1]​

Secret Sharing

Secret sharing is a common building block for MPC, but distributing a secret alone does not provide arbitrary computation on hidden inputs.^[1] In Shamir secret sharing, a secret is the constant term of a random polynomial over a finite field, and each participant receives the polynomial’s evaluation at a distinct nonzero point.^[1] A sufficiently large authorized set can reconstruct the polynomial and recover the secret, while a smaller set learns nothing about it in the standard model.^[1]​

For example, in a 2-of-3 scheme, a dealer chooses a random line (q(x)=s+a x) and gives its values at 1, 2, and 3 to three participants. Any two values determine the line and recover (s=q(0)), while one share is compatible with every possible secret.^[1] Parties can often add compatible shares locally to obtain shares of a sum; multiplication is more difficult because it increases the algebraic complexity of the sharing.^[1]​

Verifiable secret sharing (VSS) lets recipients check that shares are valid relative to public commitments without revealing the secret.^[1] Distributed key generation (DKG) lets participants jointly generate a shared secret or private key without a single dealer knowing the complete value.^[1] These techniques can reveal inconsistent or malicious setup, but their practical guarantees depend on implementation; a denial-of-service issue disclosed in some Pedersen DKG implementations resulted from missing validation.^[1]​

Threshold Cryptography

Threshold cryptography is a specialized application of MPC that includes threshold signing, decryption, key generation, and share refresh.^[1] In threshold signing, participants hold shares of a signing key and jointly compute a valid signature without reconstructing the full private key in one place. Enough valid contributions produce an ordinary signature verifiable under the corresponding public key.^[1]​

FROST is a two-round Schnorr threshold-signing protocol standardized by the Cryptography Forum Research Group (CFRG); preprocessing can allow it to use one round.^[1] It lets a threshold number of participants produce a Schnorr signature while keeping the signing key distributed.^[1] FROST is relatively efficient, but a faulty participant can cause denial of service unless an outer mechanism provides exclusion or retry.^[1]​

Threshold ECDSA is more difficult because ECDSA’s algebra is less amenable to MPC than Schnorr’s.^[1] Practical protocols include dealerless designs that can tolerate malicious adversaries with a dishonest majority, but these require additional machinery.^[1] Robust or dealerless ECDSA can require four or more presigning rounds and extensive checks, with significant implementation demands.^[1] Implementations of distributed key generation have also had vulnerabilities when they failed to validate parameters, proofs, or commitment structures.^[1]​

Digital-Asset Wallets

Digital-asset wallets use private keys to authorize transactions, so control of a key determines control of the associated assets.^[2] In MPC-based custody arrangements, a wallet’s private key is distributed as separate shares among multiple endpoints, and the complete key is not assembled in one place.^[2] Participants can jointly compute a wallet’s public key and produce a transaction signature through distributed computation without any endpoint learning the full private key.^[2]​

​Fireblocks describes key shares as generated and randomized across endpoints such as cloud servers, on-premises hardware, or mobile devices. In its described signing flow, a quorum of at least three endpoints independently validates a transaction against organizational policy rules and contributes a signature share; distributed computation then produces the complete signature.^[2] Fireblocks says shares can be refreshed or rotated without changing the wallet’s blockchain address, and that organizations can add or remove authorized devices and change quorum configurations without disrupting on-chain activity.^[2]​

MPC-based threshold signing is used by bridges, wallets, and exchanges to avoid unilateral asset control and exposure of a complete signing key through compromise of one operator.^[1] One example described by Cube Exchange uses a 2-of-3 threshold-signature scheme for decentralized settlement: the user, Cube Exchange, and an independent Guardian Network each hold one key share, and any two shares are required to authorize settlement.^[1]​

Fireblocks describes its MPC-CMP as a protocol intended to improve on the GG18 industry standard in speed, flexibility, and operational security.^[2] The company says MPC-CMP completes signing in one communication round, compared with nine rounds for GG18, eight for Lindell et al., and six for Doerner et al., and claims it is up to eight times faster than standard MPC.^[2] Fireblocks says the protocol supports hot, warm, and cold storage, including configurations with at least one share held offline in an air-gapped device; it also says cold signing can be performed without physical proximity or manual intervention for every transaction.^[2] The company says MPC-CMP is published under a limited open-source license, periodically reviewed by independent auditors, and implemented for Intel SGX and AWS Nitro secure enclaves.^[2]​

Fireblocks describes its broader security architecture as combining MPC-CMP with trusted execution environments (TEEs), a Policy Engine, and the Fireblocks Network.^[2] It says key shares, policy logic, and API credentials are stored and executed in hardware-isolated environments including Intel SGX, AWS Nitro, and GCP Confidential Spaces, intended to prevent extraction of enclave memory even if an attacker gains operating-system-level access to a server.^[2] Its Policy Engine applies transaction rules covering source, destination, asset type, and amount thresholds, with separation of duties; Fireblocks says rules are signed by a quorum of administrators and enforced inside SGX.^[2] The company also says its network automates deposit-address authentication to reduce copy-and-paste errors and address-substitution attacks.^[2]​

Fireblocks states that it supplies custody technology for organizations to operate their own custody solutions, that customers control the key shares, and that Fireblocks does not hold their assets or move funds on their behalf.^[2] This differs from a custodial wallet in which a third party controls customers’ private keys, although custodial wallets can also use MPC.^[2] Fireblocks argues that MPC wallets in which a business controls the keys align with direct-custody models because regulators focus on who controls private keys rather than the cryptographic technology used.^[2] It also reports participating in a cross-industry coalition that submitted a joint letter to the National Institute of Standards and Technology urging formal standardization of MPC-based threshold-signature schemes.^[2]​

Relationship to Other Techniques

MPC differs from homomorphic encryption in how it distributes trust and computation. Homomorphic encryption permits computation on ciphertexts, often with one party holding the decryption key, whereas MPC distributes computation and trust across participants.^[1] The approaches can also be combined: homomorphic encryption can be used within MPC, and MPC can distribute decryption or key management for homomorphic schemes.^[1]​

Secret sharing is a component of many MPC protocols; MPC adds procedures for computing on protected inputs, verifying protocol behavior, and reconstructing outputs.^[1] MPC wallets also differ from multisignature wallets. Multisignature authorization is enforced on-chain through multiple separate private keys, and support varies across blockchains and implementations.^[2] MPC signing instead occurs off-chain among key-share holders before a transaction is broadcast.^[2] Fireblocks says this allows quorum changes without changing the wallet address, avoids on-chain multisignature overhead, and can use a single implementation across chains that use ECDSA or EdDSA.^[2]​

Applications and Limitations

Beyond digital-asset custody, MPC supports privacy-preserving statistics across sensitive datasets and collaborative data processing.^[1] In each case, the computation can produce a joint result without first gathering all private inputs in one place.^[1]​

MPC reduces the need to expose complete secrets to one participant, but it does not remove all operational or implementation risks. Participants may abort or stall a protocol, creating a liveness failure even when a signing key remains protected; practical security therefore depends on the protocol’s assumptions and implementation as well as the underlying mathematics.^[1] Some practical constructions rely on cryptographic hardness assumptions, including the discrete-logarithm assumption for Schnorr and FROST and factoring

• or Paillier-related assumptions in some ECDSA protocols.^[1]​