# MPC quorums

MPC quorums distribute the shards of a wallet's private key across multiple devices, so that no single device holds the complete key. To create an MPC wallet, you must first create a quorum to securely provision the key shards among its devices.

Owners and administrators create quorums, review their membership, restructure eligible quorums, and coordinate key resharing when needed.

## Common MPC quorum configurations

MPC quorums can be configured in three different ways: using mobile devices only, CloudSign devices only, or a combination of both.

The optimal configuration for your wallet depends on what the wallet will be used for and your personal preference. Here are some example client setups and use cases:

### 1. Mobile only quorum

Suitable for:

* Wallets that handle fairly low transaction volumes. This is because on mobile devices, each transaction must be manually reviewed and signed by the device owner which can be time consuming and impractical if there are a large amount of transactions occurring daily. The device owner may not be able to sign all the transactions within the 5 minute timeframe, leading the transactions to fail.
* Wallets that require greater control or oversight. Each transaction is manually reviewed before it is signed. If enough device owners reject the signing or simply do not interact with their mobile device, the digital assets cannot be transferred and remain safely in the wallet.
* Wallets that require increased governance. Depending on the organization structure, customers can physically assign ownership of the wallet private key shards to specific mobile devices (for example: this particular shard is assigned to Kevin’s mobile). This allows for increased governance as organizations are able to see which shards participated in the signing process for each transaction.


Please note that while mobile only quorums offer increased control, they can also offer increased risk of redundancy. A mobile device could be lost or damaged, potentially rendering the quorum useless.

### 2. CloudSign only quorum

Suitable for:

* Wallets that handle high transaction volumes, such as omnibus wallets - signing multiple users’ transactions in an omnibus wallet is much quicker via CloudSign than mobile. CloudSign can sign numerous transactions within a matter of seconds.
* Wallets that use API credentials to submit transactions.
* Customers who want a simple backup recovery process. Customers only need to back up the disk, database, or device that they configured CloudSign on. After they complete this backup, if a malfunction occurs, they can easily get CloudSign back up and running with minimal overhead. For S3-based encrypted key backups, see [Backup and recovery](/products/wallet/signing-and-key-management/backup-and-recovery).
* Wallets that require increased security. CloudSign is typically run in an isolated environment - its own dedicated server. This means that the risk of malicious actors gaining access to the server is limited compared to a mobile device. The IP address is not public and other programs would usually not be running concurrently on the same server.


Please note that while CloudSign devices offer speed and the security of an isolated server, these devices automatically sign transactions without manual review. Further, clients have the added responsibility of ensuring the CloudSign servers are managed in a secure way (ie. that their firewalls are shut, they have backups etc) and that their policies are configured as narrowly as possible. Having approval groups configured for transactions can mitigate this risk with added transaction execution latency.

### 3. Mixed quorum

A mixed quorum comprises both mobile and CloudSign devices. These are suitable for customers who want the flexibility to benefit from both the control offered by mobile devices and the speed of CloudSign devices.

For example, a mixed quorum could contain 5 devices: 3 mobile devices and 2 passive CloudSign devices, with 3 signatories.

The benefit of having passive CloudSign devices is that they will immediately decline every signing request, meaning that the signing falls to the 3 mobile devices and the transaction can be manually reviewed before it is signed. However, if 1 or 2 mobile devices are lost or damaged, the CloudSign device(s) can be switched from passive to active and provide the benefit of instant signing.

You make a CloudSign node passive or active with its `SIGN_MODE_ACTIVE` environment variable (`true` by default). CloudSign reads the variable at startup, so restart the node after you change it. The setting applies to every quorum the node belongs to. See the [configuration reference](/products/wallet/signing-and-key-management/devices/set-up-cloudsign#configuration-reference). In this scenario, the customer would be left with 1 mobile device and 2 active CloudSign devices as signatories, and therefore receive the benefits of both types of device.

## Required number of devices and signatories

A quorum must have at least 2 key shard holders and at least 2 required signatures. A quorum can have at most 100 devices.

Quorums require a majority of signatures to sign. Set the number of required signatures to a majority of the key shard holders, and at least one below the total number of devices in the quorum, for these reasons:

* Convenience: the owner of one device may not be online when required
* Redundancy: a device may be lost or destroyed
* Security: one single compromised user cannot authorize a transaction


For example: if your quorum has 3 devices, set 2 required signatures. Following this guidance means that, in practice, a quorum needs at least 3 devices.

Design considerations
Choose your quorum size and threshold based on your security and availability needs:

| Configuration | Security | Availability | Use case |
|  --- | --- | --- | --- |
| 2-of-3 | Moderate | High | Small teams, sandbox testing |
| 3-of-5 | High | High | Production operations |
| 4-of-7 | Very high | Moderate | High-value wallets |


## Create a quorum via the console

Owner or Administrator role required
Only users with the **Owner** or **Administrator** role can create a quorum. Other roles don't see **Create quorum**. If you don't see it, ask an owner or administrator in your organization.

Before you start, add and pair the devices that will hold key shards, and have an owner or administrator approve them. See [Add and manage devices](/products/wallet/signing-and-key-management/devices/add-a-device). If you don't have enough eligible devices, the console prompts you to add more devices instead of offering **Create quorum**.

1. Go to **Controls** in the console sidebar and select the **MPC Quorums** tab.
2. Select **Create quorum**.
3. Select the **quorum type**:
| Type | Description |
|  --- | --- |
| **Mobile** | Uses mobile devices only. Each signing request requires manual approval on the device. |
| **Cloud** | Uses CloudSign instances only. Signs transactions automatically when quorum conditions are met. |
| **Mixed** | Combines mobile and CloudSign devices for flexibility. |
If the **Mixed** option doesn't appear, contact your Ripple representative to use mixed quorums.
4. Enter a **name** for the quorum (5 to 50 characters). The name should help identify the quorum.
5. Optionally, enter a **description** (5 to 100 characters). The description should make the purpose of the quorum clear.
6. Select the **key shard holders**: the devices that hold the MPC wallet key shards. Select at least 2 devices; for the reasons above, use at least 3.
7. Set the **required signatures**: the minimum number of devices that must participate to sign a transaction (see [Required number of devices and signatories](#required-number-of-devices-and-signatories)).
8. Select a **backup and recovery kit**. The console offers this field for Cloud and Mobile quorums. If you don't have a kit yet, select **Create backup kit** to create one first. Only an owner can create a backup kit. You can't add a kit to a quorum after you create it. Ripple Custody (Wallet) writes key shard backups only for Cloud quorums. See [Backup and recovery](/products/wallet/signing-and-key-management/backup-and-recovery).
9. Select **Create**, review the confirmation summary, and then select **Create quorum**.
10. Each quorum device receives a notification asking for its approval. The acceptance window is 60 minutes. When all devices have approved, the quorum moves to the **Confirmed** state and becomes available for selection when you create an MPC wallet.
  * If members don't approve within 60 minutes, the quorum request expires, and you need to create a new quorum.
  * If one or more devices reject the notification, the quorum isn't formed.


Use a majority threshold
Set the number of required signatures to a majority of the total shard holders. For example, in a quorum of 3 devices, use at least 2 signatures. This helps prevent a minority of compromised devices from signing transactions.

## View quorum details via the console

**Required role:** Owner, Administrator, Proposer, Approver, or Auditor.

1. Go to **Controls** > **MPC Quorums**.
2. Select a quorum to view its details: name, ID, threshold, creation date, backup kit, and the list of key shard holders with their device types and owners.


## Use a quorum

Once an MPC quorum has been created, quorum devices will receive notifications requiring them to approve or reject actions.

### MPC wallet creation

When an MPC wallet is created, all of the quorum devices will all be notified and required to approve within 5 minutes. If one or more devices rejects, the wallet will not be created.

### Transactions from MPC wallets

When a transaction is sent from an MPC wallet, all of the quorum devices will receive a notification requesting signature. When the minimum number of devices sign, the transaction will be submitted.

## Modify quorum devices

You can restructure a Cloud quorum to add new devices or replace existing devices. Key resharing isn't available as a console action.

### Key resharing

Key resharing rotates the key shards held by each device without changing the underlying wallet private key. The wallet address and blockchain identity remain the same. Ripple Custody (Wallet) doesn't currently expose a customer-initiated reshare action in the console, and it doesn't reshare keys automatically on a schedule. If your security program requires key resharing, contact Ripple support or your account team to coordinate it. See [Key resharing](/products/wallet/signing-and-key-management/mpc-quorums/key-resharing).

### Key restructuring

Key restructuring changes the quorum's membership and size. Unlike resharing, restructuring can add new devices and replace existing ones. It can't change the number of required signatures, and it can't only remove devices. To use a different threshold, create a new quorum. Restructuring is self-service in the console for Cloud quorums running CloudSign 1.10.0 or later. Ripple Custody (Wallet) doesn't support restructuring Mobile or Mixed quorums in production; contact Ripple support to plan changes to them. See [Key restructuring](/products/wallet/signing-and-key-management/mpc-quorums/key-restructuring), including the [procedure](/products/wallet/signing-and-key-management/mpc-quorums/key-restructuring#perform-a-restructure-via-the-console).

Key shard backups stay valid; node snapshots don't
Resharing and restructuring replace the key shards without changing the wallet's underlying key, so the encrypted key shard backups that Ripple Custody (Wallet) writes to S3 stay valid and need no action. CloudSign node database snapshots taken **before** a reshare or restructure contain obsolete shards, so never restore them. Take fresh node backups after every reshare or restructure. See [Maintain your backups](/products/wallet/signing-and-key-management/backup-and-recovery#maintain-your-backups).

## Best practices

- **Separate key shard holders**: Distribute devices across different team members to enforce separation of duties. Make sure no single person controls enough devices to meet the signing threshold alone.
- **Document your quorum design**: Record which devices belong to each quorum, who controls them, and the reasoning behind your threshold choices.
- **Review resharing requirements**: If your security policy requires key-share rotation, coordinate resharing with Ripple. The console doesn't reshare keys automatically.
- **Take fresh node backups after every reshare or restructure**: CloudSign node snapshots from before the change contain obsolete shards, so don't restore them. Key shard backups in S3 stay valid and need no action.
- **Test recovery procedures**: Verify in sandbox that you can recover from a lost device by restructuring the quorum.
- **Plan restructuring carefully**: Because restructuring puts wallets in maintenance mode, schedule it during low-activity periods and communicate the maintenance window to your team.


## Related topics

- [Key resharing](/products/wallet/signing-and-key-management/mpc-quorums/key-resharing): Refresh key shares while maintaining the same private key
- [Key restructuring](/products/wallet/signing-and-key-management/mpc-quorums/key-restructuring): Add or replace quorum participants
- [Add and manage devices](/products/wallet/signing-and-key-management/devices/add-a-device): Approve and manage devices before adding them to quorums
- [Backup and recovery](/products/wallet/signing-and-key-management/backup-and-recovery): Key shard backup model and maintenance