Canopy KMS: Keeping Our Highest Value Signing Keys Inside an Enclave

Yesterday The Defiant covered our launch of Canopy KMS, a purpose-built key management system that isolates our highest value signing keys inside a dedicated signing enclave.

Here is the longer version from our side: what it does, why we built our own instead of buying one, and what it protects.

The problem with the normal approach

Protecting cryptographic keys is one of the harder problems in this space, and it gets harder as a network carries real value. Traditional remote signers often keep key material in software on networked hosts, which is exactly where it is exposed to remote extraction.

Canopy KMS reduces that exposure by keeping key material inside a dedicated, hardened signing enclave. The private key never leaves. The enclave returns the signed transaction and nothing else. An attacker cannot reach it through normal paths, and a compromised connected system has no way to extract the key material.

Why we built our own

Generic signers are built for broad compatibility. They are not built for the volume or the shape of Canopy Terminal's transfers, and compatibility is not the same as fit.

Canopy KMS is built from scratch rather than wrapped around an existing product, and it is purpose-built for the transaction types Canopy actually runs, including virtual chain swaps and the minting and destroying of wrapped assets. As Andrew put it when we announced it, we engineered it from the ground up for those workflows, so that the moment a key is generated it is isolated in a way networked infrastructure alone cannot reach.

Defense in depth, not just isolation

Isolation is the first layer. The second is behavioral.

Canopy KMS applies velocity controls and anomaly detection to every signing request, checking it against expected patterns of volume, cadence, destination and transaction type, and alerting on any deviation. A request that looks wrong gets flagged whether or not anything upstream has been compromised.

What it protects

Canopy KMS is natively integrated into our own operations rather than bolted alongside them. It governs signing for treasury disbursements, bridge transfers, and chain-creation.

That integration is the difference from a general-purpose custody platform. Our systems inherit the protection by default, with no extra configuration.

Why now

We deployed this before those keys became high-value targets rather than after.

Security work is easiest to justify after something goes wrong and cheapest to do before. Treating key management as part of the architecture, rather than something added once there is enough at stake to worry about, is the same principle behind the rest of what we are shipping ahead of mainnet: build the boring infrastructure properly while the stakes are still low enough to get it right.

You can read The Defiant's coverage here.

‍