# Key restructuring

**Key restructuring** in MPC is the process of redistributing key shares among a new set of participants without ever reconstructing the original private key. This is crucial for maintaining long-term security, adapting to organisational changes, or replacing compromised participants in an MPC quorum.

## Overview

In Threshold Signature Schemes (TSS), key restructuring allows a set of existing signers to securely transfer their key shares to a new group while **preserving the same private key**. You can modify the quorum (for example, by adding or replacing nodes) without generating a completely new key. Restructuring doesn't change the number of required signers.

This ensures **operational continuity** while improving resilience against:

- Key compromise
- Insider threats
- System upgrades
- Organisational changes


Wallet-as-a-Service's implementation of key restructuring allows organisations to seamlessly rotate signers, ensuring that access control remains **dynamic, secure, and breach-resistant** without ever exposing the private key.

## When to use key restructuring

Key restructuring is appropriate when you need to:

| Use case | Description |
|  --- | --- |
| **Expand the quorum** | Add more participants so the quorum tolerates more lost devices |
| **Replace a participant** | Swap out a device or user without changing the key |
| **Respond to incidents** | Replace a potentially compromised device |
| **Adapt to org changes** | Update quorum membership as team members change |


## Key restructuring process

The key restructuring process follows these steps:

1. **Initiate restructuring**: Administrator starts the key restructuring operation
2. **Define new quorum**: Specify the new participants (the threshold stays the same)
3. **Generate new key shares**: The system computes and distributes new shares
4. **Update quorum policy**: The system applies the new configuration
5. **Invalidate old shares**: Previous key shares become obsolete


Throughout this process, the **private key is never reconstructed**.

## Example 1: Expanding the quorum

### Scenario

A company uses Wallet-as-a-Service MPC with a **(2-of-3) quorum**:

- **CloudSign 1** (cloud-based signing node)
- **CloudSign 2** (cloud-based signing node)
- **CloudSign 3** (cloud-based signing node)


Currently, **two out of three participants** must approve to sign a transaction. To tolerate the loss of more nodes, the company decides to **expand to a (2-of-4) quorum**.

### Key restructuring process

1. **Initiate restructuring**: The administrator starts a key restructuring operation, adding CloudSign 4 to move from (2-of-3) to (2-of-4)
2. **Generate new key shares**: The system securely computes and distributes new key shares:
  - CloudSign 1 receives a refreshed key share
  - CloudSign 2 receives a refreshed key share
  - CloudSign 3 receives a refreshed key share
  - **CloudSign 4** (new) receives a newly generated key share
3. **Update quorum policy**: The new configuration still requires **two** participants, now out of four, to approve transactions
4. **Invalidate old shares**: The system retires the old key shares from the (2-of-3) quorum


### Outcome

✅ The **private key remains unchanged**, with no disruption to wallets or smart contracts

✅ The quorum is now **(2-of-4)**, so it can lose two nodes and still sign

✅ **CloudSign 4 is now part of the quorum**

✅ Old key shares are **no longer valid**, which prevents unauthorized use

## Example 2: Replacing a participant

### Scenario

A company uses Wallet-as-a-Service MPC with a **(2-of-3) quorum**:

- **CloudSign 1** (cloud-based signing node)
- **CloudSign 2** (cloud-based signing node)
- **CloudSign 3** (cloud-based signing node)


The organisation needs to **replace CloudSign 3 with CloudSign 4** because the host that runs CloudSign 3 is going out of service.

### Key restructuring process

1. **Initiate restructuring**: The administrator triggers a key restructuring operation
2. **Generate new key shares**: The system computes and distributes new key shares:
  - CloudSign 1 receives a refreshed key share
  - CloudSign 2 receives a refreshed key share
  - **CloudSign 4** receives a newly generated key share
3. **Retire CloudSign 3**: Its previous key share becomes obsolete and can no longer participate in signing
4. **Quorum remains intact**: The (2-of-3) quorum remains operational with the updated participants


### Outcome

✅ The **private key remains unchanged**, with no impact on wallets or authentication

✅ **CloudSign 4 now participates in signing**, replacing CloudSign 3

✅ The system remains **resilient to insider threats** because no one can reuse the old key shares

## Performing key restructuring

To perform key restructuring in Wallet-as-a-Service:

1. Navigate to the **Controls** section in the Wallet-as-a-Service console
2. Select the **MPC Quorums** tab
3. Select the quorum you want to restructure
4. Open the **Actions** menu and select **Restructure quorum**
5. Add participants or replace existing ones. You can't only remove participants, and you can't change the threshold
6. Confirm the restructuring
7. The system distributes new key shares to the new set of participants


Wallets that use the quorum can't sign while restructuring runs. See [Manage MPC quorums](/pt-br/products/wallet/admin-guide/manage-mpc-quorums#perform-a-restructure) for the full procedure.

Limitation
Wallet-as-a-Service supports restructuring only on Cloud quorums in production. It rejects restructuring for Mobile and Mixed quorums. If you need to change one, contact Ripple support.

## Best practices

- **Plan restructuring carefully**: Document the changes before initiating
- **Ensure device availability**: All current and new participants should be available
- **Communicate with stakeholders**: Inform relevant team members of the change
- **Test in sandbox first**: Verify the process in a test environment
- **Refresh node backups after restructuring**: CloudSign node database snapshots from before the restructure contain obsolete key shares, so don't restore them. Encrypted key shard backups in S3 stay valid, because Wallet-as-a-Service binds each one to the wallet's key ID and quorum ID, and neither of them changes. The backup file doesn't store the quorum ID, so keep it in your offline wallet inventory


## Related topics

- [Key resharing](/pt-br/products/wallet/user-interface/security-controls/key-resharing) – Refresh key shares without changing participants
- [MPC quorums](/pt-br/products/wallet/user-interface/security-controls/mpc-quorums) – Create and manage quorums
- [Understanding MPC-TSS](/pt-br/products/wallet/introduction/understanding-mpc-tss) – How MPC-TSS works
- [MPC terminology](/pt-br/products/wallet/introduction/mpc-terminology) – Key terms and definitions