A crypto exchange must hold customer assets while remaining operationally usable. How should key custody, signing, approval and monitoring be architected?

The tension

Keys that can sign are keys that can be stolen. Operational usability requires signing frequently and quickly; security requires the signing capability to be as constrained as possible. Every design here is a position on that spectrum rather than a solution to it.

The layered structure

• Cold storage for the majority of assets, with keys that never touch a network-connected system. Signing requires physical process, multiple people, and takes hours. This is where most value lives, and its usability cost is accepted deliberately.
• A warm tier with hardware-backed keys and policy enforcement, handling scheduled replenishment between cold and hot.
• A hot wallet holding only what is needed for expected withdrawal volume over a short horizon, with a hard cap. The hot wallet's balance is the maximum single-incident loss, which makes sizing it a risk decision rather than an operations convenience.

What must be true of the signing path

• Keys never leave the hardware boundary. The application requests a signature; it does not hold a key.
• Policy enforced at the signing boundary, not in the application — destination allow-lists, value limits, velocity limits, time-of-day rules. An application that has been compromised must not be able to request an arbitrary signature, and policy in application code offers no protection against that.
• Multi-party approval above a threshold, with genuinely separate credentials and ideally separate people and devices. Segregation that shares an identity provider account is not segregation.
• Every signature logged immutably, with the requester, the policy evaluation and the destination.

The monitoring that catches what prevention misses

• Balance reconciliation between recorded liabilities and on-chain holdings, continuously. This is the control that detects a loss regardless of how it happened, and it is the one that must never be skipped.
• Anomaly detection on withdrawal patterns — new destinations, unusual values, velocity — with automated holds rather than alerts, since an alert during a drain is too slow.
• A tested emergency halt that stops all withdrawals within seconds, exercised so that invoking it is not itself a risk.

The organisational requirement

Nobody can move funds alone, including the people who built the system. That is a design constraint on the architecture rather than a policy statement, and the test is concrete: can any single credential, including a root cloud account or a database administrator, cause an outbound transfer? If yes, the segregation exists on paper.