> For the complete documentation index, see [llms.txt](https://canopy-network.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://canopy-network.gitbook.io/docs/canopy-network/canopy-kms.md).

# Canopy KMS

#### What Canopy KMS Is

Canopy KMS is Canopy's purpose-built key management system (KMS): dedicated signing infrastructure that generates and custodies Canopy's high-value signing keys and performs transaction signing on their behalf. It is infrastructure, not a wallet. Nothing outside Canopy KMS ever holds, sees, or moves a private key.

A caller asks that a transaction be created, signed, and sent on-chain. It never constructs the transaction itself and never receives one back, signed or otherwise. Canopy KMS evaluates the request against policy and, once satisfied, handles the rest itself: building, signing, and submitting the transaction.

#### Why Purpose-Built

The core custody principle behind Canopy KMS: separate the systems that can *request* a signature from the systems that can *produce* one, and authorize every request against policy before it's executed. Canopy KMS applies that separation specifically to Canopy's own operations, rather than adapting a general-purpose platform built for someone else's chain.

Generic remote signers and off-the-shelf custody platforms are built for broad protocol compatibility across arbitrary chains and asset types; they treat every request as an undifferentiated byte string to sign, with policy bolted on afterward as configuration rather than designed in from the start. That approach means no single chain gets policy or risk controls tuned to its actual operational profile.

Canopy KMS takes the opposite tradeoff. It is built from scratch, specifically for Canopy's own operations. It understands Canopy-native transaction types (virtual chain swaps, minting/burning of wrapped assets, treasury disbursements, cross-chain bridge transfers, chain creation) natively, and applies policy and risk controls tuned to each one, rather than treating signing as an undifferentiated service.

#### What Canopy KMS Provides

Canopy KMS exists so that Canopy services (Canopy Terminal today, additional callers over time) can request signing without taking on custody themselves. Instead they get:

* **Custody across every high-value signing identity Canopy relies on**, from per-chain treasury wallets to bridge, multisig, and threshold-signature co-signer keys
* **Authenticated, per-request signing**: Canopy KMS cryptographically authenticates every request at the application layer, with granular permissions scoped per operation and per caller
* **A closed signing boundary**: no component outside the enclave can request a signature directly from Canopy KMS
* **No return path**: no caller, inside the enclave or out, ever constructs a transaction itself or receives one back. It only ever asks that one be created, signed, and sent on-chain
* **A fail-closed policy engine**: Canopy KMS gates every signing request against policy before it's signed, and denies it by default on any failure
* **Behavioral anomaly detection**: Canopy KMS can deny a request before it signs, not just flag it after the fact in a log
* **Redundant, always-hot deployment**, geographically and network-segregated, with no single point of failure across nodes
* **Native, context-aware integration across Canopy services**: treasury disbursement, bridge settlement, and chain-creation flows each sign under policy tuned to that specific flow

Canopy KMS is not a general-purpose wallet or a validator signer. It is a tightly scoped, auditable signing boundary built around what Canopy's ecosystem depends on.

Canopy KMS isn't limited to a single signature scheme. It supports ed25519 for Canopy-native transactions, secp256k1 for EVM-side operations, and BLS12-381 for multisig and threshold-signature scenarios, choosing the scheme each operation actually calls for rather than forcing everything through one. That range lets it span a broad set of services across the ecosystem today: chain treasury operations, cross-chain bridging, multisig co-signing, and liquidity operations, each signed under policy tuned to what it actually is, not treated as an undifferentiated request.

#### Managed Services for Nested Chains

A nested chain launched on Canopy doesn't have to build its own key infrastructure. It can draw on the same custody Canopy KMS already provides for Canopy's own keys. Every chain's treasury wallet is signed through this same infrastructure today, and that extends into a configurable, tiered service for nested-chain operators: creator-defined spend policies on their own treasury key, or a fully managed bridge, with contract deployment, relayer/operator identity, and liquidity all signed the same way Canopy's own bridge is.