Design a Crypto Custodial Solution (Bank-Style)

Problem statement

Design a bank-style custodial platform where institutional clients — asset managers, hedge funds, corporate treasuries, fund administrators, and family offices — deposit large amounts of crypto and the custodian holds the private keys on their behalf. The platform stores signing material inside hardware security modules (HSMs) or multi-party computation (MPC) enclaves, enforces multi-step withdrawal approvals defined by client policy, logs every internal key operation to an immutable audit trail, and integrates compliance checks (sanctions screening, travel rule, KYT scoring) before any asset leaves the vault.

This is not an exchange. There is no matching engine, no order book, and no proprietary trading. The custodian is a fiduciary: it must prove, at any moment, that client assets are segregated, fully backed, and only movable through an authorization workflow the client itself configured. The core invariant is: no asset movement exists until a policy-approved, compliance-cleared, cryptographically signed, and audit-recorded workflow completes.

Why the problem is distinctive

A SaaS backend can retry a failed write. A custodian cannot retry a signed transaction that moved $50M to an attacker address — blockchain settlement is irreversible. Therefore the design separates mission success (workflow progress) from asset safety (key material never leaves protected boundaries, and every signature requires independently validated authorization). If a workflow component is down, withdrawals queue; they never bypass controls. If an authorization is ambiguous, the system fails closed and holds.

The brief requires secure key storage in HSM or multi-sig, account-based deposits and withdrawals, time-delayed withdrawal with manual checks, and auditing of all internal movements. Security is paramount against theft and insider compromise; reliability must support large clients with no downtime; the system must scale as assets and clients grow, and it must satisfy custodian regulations such as SOC 2.

Public operating baseline versus design assumptions

Public evidence establishes that this category is real and regulated. Fireblocks reports more than $6 trillion in cumulative transfer volume processed on its MPC-based custody and settlement network, protecting assets for hundreds of institutional participants. Anchorage Digital became the first federally chartered digital asset bank when the OCC granted it a national trust bank charter in January 2021. BitGo reports that its multi-sig platform has processed a substantial share of on-chain bitcoin transaction value and operates state-chartered trust companies. Coinbase open-sourced its cb-mpc multi-party computation library in late 2023, confirming that large custodians have moved from naive multi-sig toward threshold ECDSA. These are cited company figures and product disclosures, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes a mature custodian with 500 institutional clients, 1,200 client users, 50,000 wallet accounts across 25 chains, $50B assets under custody, 10,000 withdrawal requests per day, 50,000 detected deposits per day, and a five-times event peak. Unless tied to a citation, every number is a stated design assumption.

The four architectural planes

1. Key management plane: HSM clusters, MPC key shares, distributed key generation, key ceremonies, cold/warm/hot tiers, backup and recovery.
2. Workflow and ledger plane: withdrawal lifecycle, approval policy engine, double-entry internal ledger, client reporting.
3. Blockchain integration plane: node infrastructure, deposit detection, transaction construction, signing submission, confirmation and finality, reorg handling.
4. Governance and compliance plane: audit trail, travel rule messaging, sanctions screening, proof of reserves, regulator evidence.

A strong interview answer keeps these planes separate. The workflow plane may degrade and queue. The blockchain plane may lag. The key management plane never degrades its protection boundary, and the governance plane never loses an event.