Problem Statement: A Financial Control Plane, Not a Dashboard
Frames the treasury system as a custody-aware control plane with valuation, execution, and governance planes.
Problem statement
Design an internal crypto treasury management system for an organization holding multiple digital assets across self-custodied wallets, multi-sig contracts, and exchange accounts. The system must aggregate every balance, value the portfolio in near real time, detect policy drift such as a stable/volatile ratio leaving its band, propose and execute rebalancing under multi-person approval, sign large movements only through corporate-grade custody (multi-sig or MPC with HSM co-signers), and record every event in an append-only ledger that survives an external audit.
This is not a portfolio tracker. A tracker can show a stale number; a treasury system moves real money. The design therefore separates four planes. The custody plane owns keys, signing ceremonies, policy evaluation, and address whitelists. The valuation plane owns price ingestion, freshness classification, and mark-to-market. The execution plane owns order proposal, approval workflow, venue routing, broadcast, settlement watching, and reconciliation. The governance plane owns approvals, audit evidence, accounting snapshots, and compliance exports. A strong interview answer keeps these planes separate so a price-feed outage degrades valuation without ever unlocking the signing path.
Why the problem is distinctive
Every balance is a projection of an external, adversarial, reorg-capable source of truth: the chain itself. The system never owns the money; it owns a reconciled book about the money. Therefore correctness is defined as: no missed on-chain event, no duplicated ledger entry, no signed transaction outside policy, and no valuation presented without a freshness label. Concurrency appears in three places at once: thousands of price messages per second, per-chain indexer cursors that can rewind during a reorganization, and human approval workflows that race with market movement.
Public operating baseline versus design assumptions
Public evidence shows the category is operationally real. Fireblocks reports securing trillions of dollars in digital-asset transfers for thousands of institutional clients using MPC-CMP threshold signing. BitGo publicly describes multi-sig institutional custody with HSM-backed co-signing and a qualified trust charter. Safe (formerly Gnosis Safe) reports tens of billions of dollars in assets secured by on-chain multi-sig contracts used by DAOs such as Uniswap and MakerDAO. These are company-reported figures, not requirements for our fictional system. For capacity planning this answer explicitly assumes 500 wallets across 12 chains, 40 assets, 50,000 on-chain events per day, and a 5x event peak. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.
Key Highlights
- •A treasury system owns a reconciled book about money it does not hold; the chain is the only source of truth for balances.
- •Four planes: custody, valuation, execution, governance. A price-feed failure must never unlock the signing path.
- •Correctness invariants: no missed chain event, no duplicate ledger entry, no out-of-policy signature, no unlabeled valuation.
- •Company-reported scale (Fireblocks MPC, BitGo multi-sig, Safe on-chain treasuries) proves the category; our numbers remain assumptions.
- •Concurrency lives in price streams, reorg-capable indexer cursors, and human approval races simultaneously.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate money movement authority from money observation before choosing any technology."
- "I will treat every balance as a projection of an external chain and design reconciliation as a first-class workflow."