# Multi-party computation (MPC) overview

This guide provides a conceptual overview of Multi-Party Computation (MPC) integration with Ripple Custody. MPC is a distributed key management approach that eliminates single points of failure by distributing key shares across multiple nodes.

**Deployment:** Deploy customer MPC nodes to AWS using Nitro Enclaves. See the [AWS deployment guide](/products/custody/v1.34/how-to/integrate-kms/mpc/aws-deployment) for detailed instructions.

## What is multi-party computation (MPC)?

Multi-Party Computation (MPC) is a cryptographic protocol that enables multiple parties to jointly compute a function over their inputs while keeping those inputs private. In Ripple Custody, MPC is used for distributed key management where:

- **No Single Point of Failure**: Private keys are never reconstructed in a single location
- **Distributed Key Shares**: Each party holds only a share of the private key
- **Threshold signatures**: A minimum number of parties must collaborate to sign transactions.
- **Enhanced security**: An attacker must compromise multiple nodes to steal the key shares, and would still need access to Ripple's proprietary algorithm to reconstruct private keys.


## How Ripple Custody uses MPC

Ripple Custody implements a **3-of-4 threshold signing scheme** for transaction signing, with **4-of-4 consensus required for account creation**:

| Aspect | Description |
|  --- | --- |
| **Total Nodes** | 4 nodes (2 Ripple nodes + 2 customer nodes) |
| **Signing Threshold** | Any 3 out of 4 nodes can create valid signatures |
| **Account Creation** | All 4 nodes must participate (4-of-4 required) |
| **Key Generation** | All 4 nodes must participate in Distributed Key Generation (DKG) |
| **Availability** | 1 node can be offline and transaction signing still works; account creation requires all nodes |


### Node ownership and shared responsibility

**Important:** The node numbering reflects ownership, not deployment order.

MPC deployment follows a **shared responsibility model**:

- **Ripple** deploys and manages Nodes 0 and 1, plus the Relay Server and vault
- **Customers** deploy and manage Nodes 2 and 3 in their own infrastructure


| Node | Owner | Managed By | Description |
|  --- | --- | --- | --- |
| **Node 0** | Ripple | Ripple | Ripple-hosted MPC node (connected to vault) |
| **Node 1** | Ripple | Ripple | Ripple-hosted MPC node |
| **Node 2** | Customer | Customer | Customer-deployed MPC node |
| **Node 3** | Customer | Customer | Customer-deployed MPC node |
| **Relay Server** | Ripple | Ripple | Coordinates P2P communication between nodes |
| **vault** | Ripple | Ripple | Hosted in Ripple environment, connected to Node 0 |


## Architecture

The following diagram shows the MPC network topology.

**Abbreviations:**

- **DKG** – Distributed Key Generation: The process where all 4 nodes collaborate to generate key shares
- **TSS** – Threshold Signature Scheme: The protocol enabling 3-of-4 nodes to produce valid signatures



```mermaid
flowchart TB
    subgraph ripple["Ripple Infrastructure"]
        vault["Vault"]
        relay["Relay Server<br/>libp2p Coordination"]
        subgraph rippleNodes["Ripple MPC Nodes"]
            node0["MPC Node 0<br/>Ripple-Hosted"]
            node1["MPC Node 1<br/>Ripple-Hosted"]
        end
        vault -->|"KMS Connect"| node0
    end

    subgraph customer["Customer Infrastructure"]
        subgraph customerNodes["Customer MPC Nodes"]
            node2["MPC Node 2<br/>Customer-Deployed"]
            node3["MPC Node 3<br/>Customer-Deployed"]
        end
    end

    node2 <-->|"libp2p P2P"| relay
    node3 <-->|"libp2p P2P"| relay
    node0 <-->|"libp2p P2P"| relay
    node1 <-->|"libp2p P2P"| relay

    style customer fill:#e8f5e9,stroke:#2e7d32
    style ripple fill:#e3f2fd,stroke:#1565c0
    style vault fill:#fff3e0,stroke:#ef6c00
    style relay fill:#fce4ec,stroke:#c2185b
```

### Key management flow


```mermaid
sequenceDiagram
    participant V as vault (Ripple)
    participant N0 as Node 0 (Ripple)
    participant N1 as Node 1 (Ripple)
    participant R as Relay
    participant N2 as Node 2 (Customer)
    participant N3 as Node 3 (Customer)

    Note over V,N3: Key Generation (DKG) - All 4 nodes required
    V->>N0: Initiate DKG
    N0->>R: Coordinate with peers
    R->>N1: DKG protocol
    R->>N2: DKG protocol
    R->>N3: DKG protocol
    Note over N0,N3: Each node generates and stores encrypted key share

    Note over V,N3: Signing (TSS) - Any 3 nodes required
    V->>N0: Sign transaction request
    N0->>R: Request signatures
    R->>N1: TSS protocol
    R->>N2: TSS protocol
    Note over N0,N3: 3 nodes collaborate to produce signature
    N0->>V: Return signed transaction
```

## Key encryption keys (KEK)

Each MPC node requires a **Key Encryption Key (KEK)** to encrypt its key share at rest. The KEK is an **AES symmetric key** stored securely that never leaves the node's secure environment.

When deploying customer nodes to AWS using the MPC Deployer tool:

- KEK is automatically generated during key generation (`--keygen` mode)
- KEK is stored in **AWS Secrets Manager**
- KEK is a 32-character hexadecimal string (256-bit AES key)
- Key shares are encrypted with the KEK before storage


## Communication keys (ComKey)

Each MPC node uses a **Communication Key** for secure node-to-node communication:

### Node identification key

- **Type**: Asymmetric key (ECDSA)
- **Purpose**: Each node signs its payload with its private key
- **Verification**: Other nodes verify payloads using known public keys (Peer IDs)


The Peer ID (public key) for each customer node is generated during the `--keygen` phase and must be shared with Ripple to configure the cluster.

## Backup and restoration

MPC deployments include encrypted backup capabilities using verifiable encryption:

### Backup encryption keys

- Each node can generate encrypted backups of its key shares
- Backups are encrypted using a separate **Backup Encryption Key**
- Backups include zero-knowledge proofs for verification


### Backup procedures

1. **Backup creation**: Initiated through the Ripple Custody API via the `v0_CreateBackup` intent
2. **Backup storage**: Encrypted backup files are stored securely
3. **Verification**: The backup can be verified using zero-knowledge proofs without decryption
4. **Restoration**: Requires the backup encryption key and coordination with Ripple


For detailed backup procedures, including key generation scripts, backup verification, and exit strategy information, see [MPC backups](/products/custody/v1.34/how-to/integrate-kms/mpc/backups).

## Comparison: MPC vs HSM

| Feature | MPC | Traditional HSM |
|  --- | --- | --- |
| **Key Storage** | Distributed shares across 4 nodes | Centralized in HSM appliance |
| **Single Point of Failure** | No | Yes (HSM itself) |
| **Threshold Signing** | Yes (3-of-4) | No |
| **Account Creation Threshold** | 4-of-4 (all nodes required) | N/A |
| **Deployment** | 2 Ripple + 2 Customer nodes | 1-2 HSM appliances |
| **Signing Availability** | High (1 node can fail) | Medium (depends on HA config) |
| **Account Creation Availability** | Requires all 4 nodes | N/A |
| **Geographic Distribution** | Nodes in different regions / Availability Zones | Limited by HSM location |
| **Regulatory** | Distributed custody model | Traditional custody model |
| **Backup** | Verifiable encrypted backups | HSM-specific backup procedures |


## Customer nodes deployment

Customer MPC nodes (Node 2 and Node 3) are deployed using the **MPC Deployer** tool:

> The MPC Deployer is a Docker-based tool that automates the deployment of customer MPC nodes (Node 2 and Node 3) to a specific cloud provider.


### Deployment process

Customer node deployment is a **two-step process**:

1. **Key material generation**: Generate cryptographic keys for your nodes.
2. **Node deployment**: Deploy the infrastructure and MPC node software.



```mermaid
flowchart TB
    subgraph aws["AWS Account (Customer)"]
        subgraph vpc["VPC"]
            subgraph priv1["Private Subnet 1 (AZ1)"]
                ec2_1["EC2 Nitro Instance<br/>MPC Node 2"]
            end
            subgraph priv2["Private Subnet 2 (AZ2)"]
                ec2_2["EC2 Nitro Instance<br/>MPC Node 3"]
            end
        end
        secrets["Secrets Manager<br/>Keys & Config"]
        cw["CloudWatch<br/>Logs"]
    end

    ec2_1 --> secrets
    ec2_2 --> secrets
    ec2_1 --> cw
    ec2_2 --> cw

    style aws fill:#fff3e0,stroke:#ef6c00
    style vpc fill:#e3f2fd,stroke:#1565c0
    style ec2_1 fill:#e8f5e9,stroke:#2e7d32
    style ec2_2 fill:#e8f5e9,stroke:#2e7d32
```

### Prerequisites

Before deploying customer nodes, ensure you have:

| Requirement | Description |
|  --- | --- |
| **AWS Account** | With permissions to create resources |
| **Docker** | Docker Desktop or Docker Engine installed |
| **MPC Deployer Image** | Provided by Ripple |
| **Tenant Configuration** | Alias and instance code from Ripple |


See the [AWS deployment guide](/products/custody/v1.34/how-to/integrate-kms/mpc/aws-deployment) for detailed instructions.

## Next steps

1. **Review [Prerequisites](/products/custody/v1.34/how-to/integrate-kms/mpc/aws-deployment#prerequisites)** for deployment
2. **Contact Ripple** to initiate MPC cluster setup.
3. **Follow the [AWS deployment guide](/products/custody/v1.34/how-to/integrate-kms/mpc/aws-deployment)**
4. **Review [Production best practices](/products/custody/v1.34/how-to/integrate-kms/production-best-practices)** for namespace segmentation, HA, and monitoring