# Cold vaults

Executive summary
**Cold vaults isolate the signing environment from network-connected systems.**

- Cold vault signing uses the same governance approval model as hot vault signing.
- The difference is transport: operations move between the online system and the cold vault server as `.dat` files.
- A cold bridge runs on the cold vault server and provides the local interface that the vault polls for signing work.
- Accounts and manifests created for a cold vault remain `Pending`, and transactions remain `Prepared`, until you import the signed payload back into Ripple Custody.
- Cold vault operations give up speed and automation in exchange for stronger physical isolation.


Why this matters
Cold storage reduces the attack surface for high-value assets because the online deployment cannot reach the signing environment. Even if an attacker compromises an online component, they still cannot directly reach the cold vault signing environment.

**For architects and operators**: Cold vaults require operational discipline. You need a cold vault server, controlled transfer media, clear verification steps before signing, and recovery procedures for the server, vault configuration, and KMS material.

Prerequisites
Before using cold vaults, you should understand:

- [Key management](/products/custody/v1.34/concepts/key-management) - How vaults relate to KMS, accounts, and governance-approved signing.
- [Transaction processing](/products/custody/v1.34/concepts/transactions-processing) - How approved transactions move to signing and broadcast.
- [Key management planning](/products/custody/v1.34/deployment/planning/key-management) - How KMS choices affect signing and recovery.


## Cold vault architecture

A cold vault uses a physically isolated signing environment. The online deployment prepares operation payloads, an operator transfers those payloads to the cold vault server, the cold bridge makes the payload available to the local vault, and the operator transfers the signed result back for import.

```mermaid
flowchart LR
    subgraph Online["Online Ripple Custody environment"]
        UI["UI or API"]
        Core["Core services"]
    end

    subgraph Transfer["Manual transfer"]
        DatOut["Unsigned .dat file"]
        DatIn["Signed .dat file"]
    end

    subgraph Cold["Cold vault server"]
        Bridge["Cold bridge"]
        Vault["Vault"]
        KMS["KMS<br/>HSM or MPC"]
        Bridge --> Vault --> KMS
    end

    UI --> Core
    Core --> DatOut --> Bridge
    Bridge --> DatIn --> Core
```

| Component | Role |
|  --- | --- |
| Online Ripple Custody environment | Creates accounts, transactions, and manifests as governed operations. Exports pending cold vault operations. |
| Transfer media | Moves `.dat` payloads between the online environment and the cold vault server. |
| Cold bridge | Runs on the cold vault server. Provides the local UI and API used to upload, inspect, sign, and download operation payloads. |
| Vault | Polls the cold bridge for signing work, verifies the notary attestation, builds the transaction, and signs. |
| KMS | Protects the signing key material and performs cryptographic operations. |


## Hot vaults and cold vaults

Both vault types follow the same governance and approval process. They differ after Ripple Custody prepares the operation for vault signing.

| Factor | Hot vault | Cold vault |
|  --- | --- | --- |
| Connectivity | Network-connected. | Air-gapped. |
| Signing path | Vault polls the online API for operation queries. | Vault polls the local cold bridge for operation queries. |
| Operator involvement | Automated after approval. | Manual export, transfer, signing, and import. |
| Typical use | Frequent transactions, payments, and operational liquidity. | High-value reserves and cold storage. |


## Signing workflow

```mermaid
sequenceDiagram
    participant User as User
    participant Online as Online system
    participant Media as Transfer media
    participant Bridge as Cold bridge
    participant Vault as Vault

    User->>Online: Submit and approve operation
    Online->>Online: Prepare cold vault operation
    Online->>Media: Export unsigned .dat file
    Media->>Bridge: Transfer to cold vault server
    Bridge->>Vault: Vault polls for signing work
    Vault->>Vault: Verify notary attestation and sign
    Vault->>Bridge: Return signed payload
    Bridge->>Media: Download signed .dat file
    Media->>Online: Import signed operations
    Online->>User: Continue account, transaction, or manifest processing
```

## First-time cold vault handshake

When you first register a cold vault, it can appear in a `Pending` state because it cannot automatically connect to the online deployment. Complete the manual handshake before using the vault for accounts, transactions, or manifests.

At a high level:

1. On the cold vault server, retrieve the vault UUID and vault public key from the vault container logs.
2. Register the cold vault using the standard vault registration flow, with the UUID and public key from the logs.
3. Download the vault data from the cold bridge on the cold vault server.
4. Transfer the `.dat` file to the online environment.
5. Import the file into Ripple Custody.
6. Verify that the vault status is `Completed`.


For steps, see [Process cold vault operations in the UI](/products/custody/v1.34/ui/environment/vault/cold#complete-the-first-time-vault-handshake) or [Process cold vault operations with the API](/products/custody/v1.34/api/environment/vault/cold#complete-the-first-time-vault-handshake).

## Operational responsibilities

| Responsibility | Why it matters |
|  --- | --- |
| Air-gap controls | The cold vault server must remain isolated from networks so no one can reach signing remotely. |
| Transfer media controls | `.dat` files move between the online environment and the cold vault server. Use approved media and handling procedures. |
| Payload verification | Inspect operation details before you allow the cold vault to sign. |
| HSM master key | After you register the vault, the cold vault server stores no state locally. To recover a cold vault, the replacement HSM must use the same master key as the original HSM. |
| Configuration backup | Recovery requires the same vault configuration, including the vault UUID and the notary messaging public key. |


## Next steps

| Task | Page |
|  --- | --- |
| Plan the cold vault server | [Cold vault server planning](/products/custody/v1.34/deployment/planning/cold-vault-workstation) |
| Deploy the cold bridge | [Deploy a cold bridge](/products/custody/v1.34/deployment/install/cold-bridge-deployment) |
| Register, view, update, lock, or unlock vaults | [Manage vaults](/products/custody/v1.34/ui/environment/vault) |
| Process cold vault operations in the UI | [Process cold vault operations in the UI](/products/custody/v1.34/ui/environment/vault/cold) |
| Process cold vault operations with the API | [Process cold vault operations with the API](/products/custody/v1.34/api/environment/vault/cold) |
| Recover cold vault operations after server loss | [Recover a cold vault](/products/custody/v1.34/how-to/recover-cold-vault) |