Every custodial crypto product is, underneath the trading screens and the mobile app, a system for holding other people's keys and proving at any moment that the money is where the books say it is. That system is what I mean by crypto custody architecture: the key layer, the wallet topology, the deposit and withdrawal pipelines, the ledger that records all of it, and the governance that decides who may move what.

This page is the hub for everything I write about custody. It walks the whole architecture once, end to end, at the level of a design review. Each section ends with the deeper article that covers it in detail, where one exists. If you are building or auditing a custodial exchange, a wallet product or a crypto-to-fiat rail, start here.

What custody means in a system diagram

Regulators define custody as safeguarding client assets. Engineers need something more concrete. In practice a custodial system has three layers, and most architecture mistakes come from blurring the lines between them.

The single most useful rule I know: balances live in the ledger, never in the wallet. A wallet balance is a fact about a chain. A customer balance is a liability on your books. They should agree, and a job should check that they do, but they are not the same number and one must never be copied into the other.

Custody models and where the keys live

The first decision is who controls key material, and it shapes everything after it.

Layered on any of these is the temperature model. Hot wallets sign automatically within tight limits. Warm wallets need human approval. Cold storage is offline and slow by design. The engineering question is not which tier to use but how value flows between them, who approves each flow, and how the ledger represents assets that are in transit between tiers.

Deep dive coming: key management options compared, with the operational cost of each.

Wallet topology: omnibus, segregated and everything between

Once you know where keys live, you decide how customer assets map onto addresses.

Chains complicate the picture. Account-model chains (Ethereum, Tron) give every customer an address cheaply but make sweeping a gas cost. UTXO chains (Bitcoin) make address generation trivial but require careful coin selection. Memo-and-tag chains (XRP, Stellar) share one address and distinguish customers by a tag, which means a missing tag is a support ticket and a customer-facing warning. Your asset registry should carry all of these properties, and your routing layer should read them rather than hard-code them.

The deposit pipeline

Deposits look passive and are anything but. The pipeline has five stages, and each has a failure mode that costs money.

  1. Provision an address. Generate or request a deposit address for a customer and asset, persist the mapping, and remember which provider or key owns it. Addresses are sticky: they belong to the key that generated them for as long as any customer has them saved.
  2. Observe the chain. Either run your own indexers or consume a provider's events. Treat both as hints. The authoritative check is a read against the chain or the custodian's API.
  3. Apply the confirmation policy. The number of confirmations before you credit is a risk decision per asset, set by you, not inherited from a vendor's default. Store it in the asset registry.
  4. Credit the ledger. Post a journal entry: debit the custody asset account, credit the customer liability. This is the only step that changes a balance, and it must be idempotent on the deposit's chain identity.
  5. Sweep. Move funds from deposit addresses to the operational pool on a schedule that balances gas cost against hot-wallet exposure. Sweeps are internal transfers and should post as such, never as customer activity.

Reorgs are the case that separates a demo from a production system. A deposit credited at three confirmations that disappears in a six-block reorg is a real loss if the customer has already traded or withdrawn. The defensive posture is a confirmation threshold tied to the chain's reorg history, holds on freshly credited value for the riskiest assets, and a compensating ledger entry rather than a deleted row when the worst happens.

The withdrawal pipeline

Withdrawals are where custody systems lose money, so this is the pipeline that deserves the most design time. The shape I have converged on:

request → intent recorded → policy checks → approvals → routed to signer/provider
        → signed → broadcast → confirmed → settled in ledger

The hard part is idempotency across the gap between "we submitted" and "we know what happened". A timeout there does not mean failure; it means unknown, and unknown must be a first-class state that a recovery job resolves by reading back from the provider. Two of my articles cover this in depth.

Read next: Designing provider-agnostic crypto custody, on the custody port, status mapping and running two providers. Then Idempotency in payment systems, explained, on why intents and keys you generate are the only reliable protection. Deep dive coming: withdrawal pipelines, approvals, limits and audit trails.

The ledger is the system of record

I came to engineering from accounting, and this is the part of custody that the accounting habit maps onto directly. The ledger is double-entry. Every movement of value is a journal entry with at least two legs that sum to zero, and the entries are immutable once posted.

A minimal chart of accounts for a custodial exchange looks like this:

Reconciliation is what makes the ledger trustworthy. Scheduled jobs compare three things: your ledger's custody asset balances, the custodian's reported balances, and the chain itself. Differences are explained by in-transit entries or they are alerts. Done daily, this catches a mis-mapped decimal or a missed status transition the same day. It is also the raw material for proof of reserves, which is becoming an expectation rather than a differentiator.

Deep dive: Reconciling ledger, balance and custody state (coming), on the job design, what explains a break, and the alert thresholds that actually work.

Key governance and the policy engine

Keys are only as safe as the rules about who may use them. Governance is the set of controls that turns a signing capability into a custody service.

The CryptoCurrency Security Standard is a useful checklist for this layer, and the VARA custody rulebook sets expectations for licensed venues in Dubai. Neither tells you how to build it, which is why the policy engine deserves the same design care as the signing path.

Operating it

A custody architecture is judged in its worst week, not its launch week. The operational concerns worth designing for from the start:

A reference architecture

Putting the layers together, the shape most regulated custodial products converge on looks like this:

┌──────────────┐   ┌──────────────┐   ┌───────────────────────────┐
│  Public API  │──▶│ Policy engine│──▶│ Withdrawal orchestrator   │
│  (intents)   │   │ (rules+quorum│   │ intent → route → submit   │
└──────────────┘   └──────────────┘   └─────────────┬─────────────┘
                                                    │ custody port
                                   ┌────────────────┼────────────────┐
                                   ▼                ▼                ▼
                            ┌────────────┐  ┌────────────┐  ┌────────────┐
                            │ Adapter A  │  │ Adapter B  │  │ Self-signed│
                            │ (custodian)│  │ (custodian)│  │ (MPC/HSM)  │
                            └─────┬──────┘  └─────┬──────┘  └─────┬──────┘
                                  └───────────────┼───────────────┘
                                                  ▼
┌──────────────┐   ┌──────────────┐   ┌───────────────────────────┐
│Chain observer│──▶│   Ledger     │◀──│ Reconciliation jobs       │
│ + webhooks   │   │ double-entry │   │ ledger vs custodian vs    │
│ (hints only) │   │ system of    │   │ chain, daily              │
└──────────────┘   │ record       │   └───────────────────────────┘
                   └──────────────┘
         every box writes to an append-only audit log

Three properties make it work. The ledger is the only place a balance changes. The custody port keeps vendors replaceable. And every arrow that moves value is idempotent on an identifier you generated.

The series

This hub will grow as the deep dives are published. Current and planned articles:

If you are designing one of these systems and want a second pair of eyes, this is the kind of work I take on.

Written from public vendor documentation, published regulation and general industry practice. It does not describe the architecture, controls or operations of any employer or client. Views are my own.