> ## Documentation Index
> Fetch the complete documentation index at: https://cobo.com/products/agentic-wallet/manual/llms.txt
> Use this file to discover all available pages before exploring further.

# Custodial model

> How Cobo secures fully custodial wallets through layered asset segregation, HSM-based key isolation, and distributed infrastructure controls.

<Note>Fully custodial wallets are available on request. [Contact us](mailto:agenticwallet@cobo.com) if you would like to use this feature.</Note>

With a custodial wallet, Cobo holds and manages private keys on your behalf using institutional-grade infrastructure. This model is suited for users that prefer to delegate key management entirely rather than operate their own signing infrastructure.

No individual — including Cobo — can access key material in plaintext. Keys are generated and stored inside hardware security modules where all signing operations execute within the hardware boundary itself. Security rests on physical and cryptographic controls, not on trusting any individual or team.

## Three-tier asset segregation

Cobo's custodial architecture separates assets into three tiers matched to security requirements and operational frequency. The vast majority of assets sit in the most secure tier and are never touched by day-to-day operations.

| Tier     | Typical share      | Access pattern | Primary controls                                                                 |
| -------- | ------------------ | -------------- | -------------------------------------------------------------------------------- |
| **Cold** | \~95% of assets    | Offline only   | FIPS-certified HSMs in physically isolated environments; no network connectivity |
| **Warm** | Operational buffer | Periodic       | Scheduled payouts, settlement, rebalancing between cold and hot                  |
| **Hot**  | Minimal            | Real-time      | Online; HSM + Intel SGX secure enclaves + risk-control engine                    |

```mermaid theme={null}
flowchart TB
    Cold["Cold Storage<br/>~95% of assets · Offline HSMs<br/>Long-term reserves · Highest security"]
    Warm["Warm Storage<br/>Operational buffer<br/>Scheduled payouts · Rebalancing"]
    Hot["Hot Storage<br/>Minimal assets · Real-time operations<br/>HSM + SGX + Risk controls"]
    Cold <-->|"Periodic rebalancing"| Warm
    Warm <-->|"Operational flow"| Hot
```

### Cold storage

Cold wallets protect long-term and high-value holdings. Private keys are generated and stored entirely within FIPS-certified HSMs in offline or physically isolated environments. Keys never leave hardware. All operations require strict approval workflows before any asset movement is initiated.

Cold storage minimizes attack surface and ensures that the majority of assets remain unreachable from online systems under any operational condition.

### Warm storage

Warm wallets serve as an intermediate buffer between cold and hot. They support periodic rebalancing, settlement, and scheduled payouts — medium-frequency workflows that do not require real-time execution but still need timely handling. Warm storage reduces hot wallet exposure while enabling smoother operational throughput.

### Hot storage

Hot wallets are online and optimized for speed. They hold only a minimal share of total assets and power real-time business flows such as instant withdrawals, exchange operations, and API-driven interactions.

Even in the online tier, additional controls protect against hot-wallet risk:

* **Bank-grade HSMs** — private keys are stored in hardware even for online operations; keys never appear in plaintext outside the module
* **Intel SGX secure enclaves** — hardware-level memory isolation for key operations, protecting against attacks that target running processes
* **Risk-control engine** — real-time on-chain monitoring and policy-based controls (spend limits, address allowlists/blocklists, IP restrictions) that gate every outgoing transaction

These controls limit the impact of any hot-wallet incident and ensure that high-speed operational flows do not compromise assets in warm and cold tiers.

## HSM-based key isolation

Across all tiers, private key security is anchored by FIPS 140-2 certified Hardware Security Modules (HSMs). HSMs provide a tamper-resistant environment where private keys are generated, stored, and used exclusively within hardware. If physical tampering is detected, built-in mechanisms trigger automatic zeroization of key material.

The application layer above the HSM can request that a signature be produced, but it can never extract the key itself. Even an attacker with full administrative access to the host server cannot reach key material held inside the HSM boundary.

```mermaid theme={null}
flowchart TB
    APP["Application / service layer"]
    subgraph hsm ["HSM boundary"]
        direction TB
        NOTE["No key extraction possible"]:::note
        KG["Key generation"]
        KS["Key storage"]
        SIG["Signing operations"]
        NOTE ~~~ KG --> KS --> SIG
    end
    OUT["Signature output only"]
    APP -->|"Signing request"| hsm
    hsm --> OUT
    classDef note fill:#f5f5f5,stroke:#aaa,color:#666,font-style:italic
```

## Infrastructure resilience

Cobo's custodial infrastructure is deployed across multiple geographic regions and availability zones:

* No single data center failure causes asset unavailability
* Jurisdictional requirements for data residency can be met
* Correlated failures in one region do not affect others

Physical data centers use controlled access, surveillance, redundant power, and environmental safeguards consistent with high-security infrastructure standards.