Multi-Party Computation (MPC) Bridge

The core cryptographic mechanism enabling MPC. A private key is never assembled in one place. Instead, it is split into secret shares distributed among a network of nodes. A transaction is only signed when a pre-defined threshold (e.g., 7 out of 10 nodes) collaborates to produce a valid signature. This prevents any single node or small group from compromising the bridge's assets.

MPC bridges eliminate the need for a centralized custodian or a single multi-sig wallet. The custody of locked assets is managed by the decentralized network of signing nodes. This architecture significantly reduces the attack surface compared to bridges that rely on a small, known multi-sig committee, as there is no central vault to attack.

By design, MPC bridges are resistant to several common attack vectors:

• Single Point of Failure: Compromising one node reveals nothing.
• Insider Threats: A malicious node cannot act alone.
• External Hacks: An attacker must compromise a majority of the signing nodes simultaneously, which is significantly more difficult than attacking a centralized server or a small multi-sig. This model is often compared to secure multi-party computation more broadly, where parties compute a function without revealing their private inputs.

Real-world implementations demonstrate the model's application and inherent compromises.

• Example: A bridge might use 10 nodes with a threshold of 7, operated by geographically and organizationally distinct entities.
• Trade-off: While more decentralized than centralized bridges, node operators are often known, permissioned entities (a federated model), creating a trust assumption about their collective honesty. Performance can be slower than a centralized service due to the coordination required for signing.

MPC sits between fully centralized and trust-minimized models.

• vs. Lock & Mint (Centralized): MPC is more secure; no single admin key.
• vs. Native Verification (e.g., IBC, Light Clients): MPC is less trust-minimized but more broadly compatible with chains that don't support light clients.
• vs. Optimistic/Rollup Bridges: MPC provides immediate finality, not a challenge period, but relies on the honesty of the node set rather than cryptographic and economic guarantees.

The security of an MPC bridge is defined by its threshold signature scheme (TSS). This requires a quorum (e.g., 7 of 10) of key shard holders to sign a transaction. Risks include:

• Key Generation: A malicious or compromised ceremony can create backdoored keys.
• Static vs. Proactive Secret Sharing: Static shares are vulnerable to gradual compromise; proactive schemes periodically refresh shares to mitigate this.
• Quorum Size: A low threshold (e.g., 2 of 3) increases the risk of collusion or takeover.

MPC nodes must agree on the validity of a cross-chain message before signing. This relies on an off-chain consensus layer, which is a critical attack surface.

• Liveness Attacks: If nodes cannot communicate (e.g., DDoS), the bridge halts, causing denial-of-service.
• Faulty/Malicious Nodes: The protocol must tolerate Byzantine nodes without allowing invalid state transitions. A bug in the coordination logic can lead to incorrect signatures being produced.

The security model often depends on the economic incentives and identity of the node operators.

• Operator Collusion: If a threshold of operators is controlled by a single entity or cartel, they can steal funds.
• Staking Slashing: Many MPC bridges use staking to penalize malicious behavior. Inadequate slash amounts or slow withdrawal periods may not deter attacks.
• Governance Centralization: Updates to the MPC node set or protocol parameters are often managed by a multi-sig or DAO, creating a centralized upgrade key risk.

MPC security rests on complex cryptography and its correct implementation.

• Algorithmic Vulnerabilities: Flaws in the underlying elliptic curves or signature schemes (e.g., ECDSA) can be exploited.
• Side-Channel Attacks: Physical attacks like timing or power analysis can leak private key shards from improperly shielded nodes.
• Library & Code Audits: Bugs in the MPC library (e.g., GG18, GG20 implementations) or the bridge's integration code are a primary source of exploits, as seen in several bridge hacks.

MPC bridges require a trusted view of the state on both connected chains. They typically rely on the node operators themselves or external oracles to provide this data.

• Data Availability: If nodes are fed incorrect block headers or transaction proofs, they may sign for invalid withdrawals.
• Reorg Attacks: A blockchain reorganization on the source chain can invalidate a deposit proof after the bridge has already processed it, potentially leading to double-spends if not handled with sufficient confirmation delays.

MPC bridges shift risk from on-chain code to off-chain infrastructure and social consensus.

• No Upgradable Contract Risk: Eliminates vulnerabilities in complex on-chain verifiers, but introduces off-chain coordinator risk.
• Custodial Model: The bridge assets are effectively held in an MPC wallet controlled by the node set, making it a trusted/custodial model, unlike trustless light client or liquidity network bridges.
• Attack Cost: Exploiting an MPC bridge often requires corrupting multiple entities, which can be more expensive than exploiting a single smart contract bug, but the payoff can be the entire bridge treasury.

The bridge's security is anchored in Threshold Signature Scheme (TSS), a form of MPC. A distributed network of signer nodes collaboratively generates and manages a single blockchain address's private key. No single node holds the complete key; signing authority requires a pre-defined threshold (e.g., 7 of 10) to authorize a transaction, eliminating single points of failure and reducing attack surfaces like private key theft.

MPC bridges operate on a trust-minimized model, contrasting with centrally managed bridges. Trust is distributed across the independent signer committee. While more decentralized than a single custodian, the trust assumption shifts to the honesty and security of the signer set. The security level is a function of the threshold configuration, the number of nodes, and their geographic/organizational distribution.

A typical MPC bridge flow involves:

• Locking: User deposits assets into a vault address on the source chain.
• Attestation: Signer nodes observe and cryptographically attest to the deposit event.
• Signing: Upon reaching the threshold, nodes perform an MPC ceremony to generate a signature authorizing a mint.
• Minting: A relayer submits the valid signature to the destination chain, minting wrapped assets for the user.

• No Native Asset Requirement: Unlike some validator-based bridges, MPC bridges don't require a separate bridge token for security.
• Cost Efficiency: Transaction costs are typically lower than running a full validator network on multiple chains.
• Chain Agnosticism: Can be deployed to connect virtually any blockchain that supports the bridge's signature scheme (e.g., ECDSA, EdDSA).
• Rapid Finality: Once the threshold signature is produced, the transaction can be executed immediately.

While robust, MPC bridges are not risk-free. Primary concerns include:

• Signer Collusion: If the threshold number of signers collude, they can steal funds.
• Implementation Bugs: Flaws in the MPC library or smart contracts can be exploited.
• Operational Security: Compromise of multiple signer nodes through coordinated attacks.
• Liveness Risk: Failure to reach the signing threshold can halt withdrawals.

Real-world implementations demonstrate the model's application:

• zkLink Nexus: An MPC-secured aggregation layer connecting over 15 L1/L2 networks, using TSS for its gateway.
• Celer cBridge: Employs a State Guardian Network (SGN) that uses an MPC-based threshold signature scheme to secure cross-chain messages and liquidity.
• Multichain (formerly Anyswap): Initially used an MPC model for its router contracts, though its specific architecture evolved.

A core cryptographic primitive enabling MPC Bridges. A Threshold Signature Scheme (TSS) allows a group of parties (or nodes) to collaboratively generate and use a single digital signature without any single party ever holding the complete private key.

• Key Generation: The full private key is secret-shared among participants using cryptographic protocols like Shamir's Secret Sharing.
• Signing Process: To authorize a transaction (e.g., minting assets on a destination chain), a pre-defined threshold (e.g., 2-of-3) of participants must collaborate to produce a valid signature.
• Security Benefit: Eliminates the single point of failure inherent in bridges that rely on a single, exposed private key held by a multi-sig wallet.

MPC Bridges exist on a spectrum between trusted and trustless models, defined by their security assumptions.

• Trusted (Custodial) Bridges: Rely on a federated committee or a single entity to hold and control the bridged assets. Users must trust these operators not to collude or act maliciously. Most MPC Bridges fall into this category, as trust is placed in the committee running the nodes.
• Trustless (Native) Bridges: Rely solely on the cryptographic security and consensus of the underlying blockchains. Examples include light client bridges (e.g., IBC) and liquidity networks (e.g., some rollup bridges). No external committee is trusted with custody.

MPC Bridges improve upon simple multi-sig models but do not achieve full trustlessness.

The security of an MPC Bridge hinges entirely on how the signing key is managed and distributed.

• Secret Sharing: The master private key is split into shares distributed to independent nodes/parties. Individual shares reveal nothing about the full key.
• Distributed Key Generation (DKG): A protocol where parties collaboratively generate the key shares without ever creating a complete key in one place, enhancing setup security.
• Geographic & Entity Distribution: To mitigate correlated failures, MPC node operators should be geographically dispersed and run by legally distinct entities. Concentration risk is a major vulnerability.

An alternative cross-chain model that does not rely on a centralized custodian or committee. Liquidity networks facilitate peer-to-peer asset swaps across chains using Hash Time-Locked Contracts (HTLCs).

• Mechanism: A user locks Asset A on Chain 1. A liquidity provider (or another user) locks Asset B on Chain 2. Cryptographic proofs ensure the swap either completes atomically for both parties or fails, returning funds.
• Trustlessness: No third party ever holds user funds; security depends on the correctness of the smart contracts and time-locks.
• Trade-off: Typically requires readily available counterparty liquidity and can be less efficient for large, one-way asset transfers compared to locking/minting bridges.

External data services that are critical for many bridge designs, though MPC Bridges may use them for auxiliary functions. Oracle networks (e.g., Chainlink) aggregate and deliver verified off-chain data to blockchains.

• Role in Bridging: Can be used to relay state proofs or attest to events on a source chain (e.g., "100 ETH was burned") for a destination chain's bridge contract. Some hybrid bridges combine MPC committees with oracle networks for attestation.
• Security Model: Introduces a different trust assumption based on the oracle network's decentralization, node reputation, and cryptographic proof system.
• Contrast with MPC: Oracles attest to data, while MPC committees directly sign transactions to move assets.

A cryptographic tool sometimes used in MPC Bridge implementations to enhance security and fairness. A Verifiable Random Function (VRF) produces a random output that is provably unpredictable and publicly verifiable.

• Use Case 1 - Leader Election: Randomly and verifiably select which subset of the MPC committee members must participate in a signing round, making targeted attacks more difficult.
• Use Case 2 - Task Assignment: Assign specific bridge validation or relaying tasks to nodes in a bias-resistant manner.
• Security Property: The randomness cannot be manipulated by the VRF provider after the fact, providing auditability and resistance to manipulation of the node selection process.