> ## Documentation Index
> Fetch the complete documentation index at: https://corridor.udokaam.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# ADR 0009: Customers hold the keys

> Corridor signs through the customer's own KMS, HSM or MPC provider and never holds customer funds or key material.

## Context

The first build generated vault keys locally and moved money through wallets Corridor controlled. For a licensed payment company that is a dealbreaker: funds in flight would sit with an unlicensed intermediary, and due diligence stops at "who holds our money?". In most jurisdictions it would also make Corridor a money transmitter or crypto-asset service provider.

## Decision

**All signing goes through one interface, implemented by the customer's signer.** `@corridor/signer` defines secp256k1 (Tempo, Base) and Ed25519 (Solana) signers; adapters turn them into chain accounts. Corridor runs self-hosted or as a dedicated managed instance and calls the customer's KMS or MPC provider with digests only.

## Consequences

* Corridor is software, not a custodian: the licence, the funds and the keys stay with the customer.
* AWS KMS is supported now; each further provider is one adapter.
* Local keys remain for development and testnet only.
* The shielded lane keeps FROST 2-of-3 ([ADR 0006](/decisions/0006-frost-threshold-vaults)).

## Alternatives rejected

* **Corridor-run custody with a licence:** slow to obtain, and it puts Corridor in competition with the providers it should route through.
* **Partner custody (Corridor picks a custodian):** still a third party between the customer and its money, and it locks the customer to that custodian.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.