Design Institutional Custody

Problem Statement: Institutional Crypto Custody

An institutional custody platform holds billions in client crypto with hardware-backed keys, policy-gated withdrawals, and regulator-grade audit — the Coinbase Custody / BitGo / Fireblocks model. Clients (funds, exchanges, corporates) deposit assets the custodian secures; clients never touch raw seeds, and every outbound movement passes a policy/approval gauntlet. The single most important framing: a custodian is not an exchange — there is no matching engine, no trading; the product is safekeeping plus controlled movement.

The scale to anchor: ~500 institutional tenants, ~$80B assets under custody (AUC), with a withdrawal SLA of 99.9% policy evaluations < 400ms and broadcast p99 < 3 min for the hot tier. Sub-accounts per fund get segregated address pools and policy templates; deposits are credited only after a configurable per-asset confirmation depth.

The three invariants that govern the whole design — and what an interviewer is really testing: (1) the key invariant — private key material never leaves the HSM/MPC enclave except via a quorum-approved signing ceremony; (2) the ledger invariant — the internal book of record is CP (strongly consistent), while chain balances are reconciled asynchronously with explicit confirmation depth; (3) the policy invariant — every outbound movement carries a policy_version, an approver_set_hash, and an idempotency_key.

The failure stories that define custody are insider- and attribution-shaped, not throughput: an insider co-signing without the second approver (why maker-checker quorum exists), and an omnibus address with no per-tenant attribution (you cannot prove whose funds are whose). Naming SOC 2 CC6/CC7 controls mapped to the signing and audit pipelines — and the custody-is-not-an-exchange separation in one sentence — is what separates a staff answer from a generic microservices diagram.