The Parts of a Crypto Exchange Beyond the Matching Engine

The matching engine receives orders, applies deterministic priority rules and emits fills. It is technically demanding, but an exchange also has to admit the right orders, reserve balances, distribute market data, move assets across blockchains, maintain custody policy, reconcile internal obligations and support investigations. A fill that cannot be reflected in a balanced ledger or funded by controlled wallets is not a complete trade. Architecture discussions that begin and end with matching throughput ignore the systems where money is represented, access is governed and asynchronous networks meet customer expectations. The right unit of design is the lifecycle from deposit through trading to withdrawal and reconciliation.

The order gateway protects the book

Clients should not connect directly to matching internals. Gateways authenticate sessions, authorise accounts, enforce rate and message limits, validate instrument status, tick size, lot size and order type, and assign stable identifiers. Pre-trade risk checks confirm available balances or credit and reserve funds so concurrent orders cannot overspend them. Sequence numbers and idempotency rules let clients distinguish accepted, rejected and uncertain requests after reconnecting. Cancel-on-disconnect and self-trade prevention require explicit policy. The gateway must preserve the deterministic input sequence expected by the engine while preventing a slow permission service or database lookup from entering the critical path unpredictably. Recovery semantics matter more than a successful single request.

Matching is a deterministic state machine

A central limit order book normally applies price priority and then time priority within a price level, although product rules can differ. The engine should process an ordered command stream, update book state and emit sequenced events for acknowledgements, fills and cancellations. Numeric representation must avoid floating-point ambiguity; integer ticks and lots or fixed decimal types are typical. Persistence may use an append-only journal plus snapshots so state can be replayed after failure. Active-passive recovery needs a clear fencing mechanism to prevent two writers. Determinism enables replay testing: given the same initial state and commands, the resulting book and event sequence should be identical.

The internal ledger is the financial core

Customer balances should be derived from immutable double-entry ledger entries, not overwritten fields. Deposits credit a customer liability against an asset or clearing account; trades transfer base and quote obligations with fees; withdrawals move value through pending and settled states. Entries must balance per asset and retain links to source events. Available, reserved and total balances have distinct meanings, and reservation changes need atomicity with order acceptance or a protocol that cannot create unbacked orders. Reversals correct mistakes without deleting history. The ledger should support point-in-time reconstruction and reconciliation to blockchain wallets, banking partners and the matching event stream. A cached balance can improve reads, but the journal remains authoritative.

• Order gateways, session control, pre-trade risk and balance reservation.
• Deterministic matching, event journals, snapshots and recovery fencing.
• Double-entry customer ledger, fee accounting and settlement states.
• Wallet custody, chain observation, deposits and controlled withdrawals.
• Market data, surveillance, reconciliation and operational case management.

Blockchain funding is asynchronous and reversible in practice

A deposit service derives or assigns addresses under custody policy, observes nodes or providers and maps transactions to accounts. It must handle chain reorganisations, replaced transactions, token contracts, memo or destination tags and assets sent on unsupported networks. Credit policy depends on confirmations and asset risk; “seen” is not the same as final. Sweeping consolidates funds from deposit addresses while managing network fees and nonce or unspent-output state. Chain indexing should be replayable from checkpoints and compare multiple observations where appropriate. Customer support needs transaction lineage from chain identifier through internal credit. Unsupported or ambiguous deposits require a controlled case process, not an improvised database update.

Withdrawals require layered control

A withdrawal crosses the strongest trust boundary in the system. The request should pass authentication, destination and network validation, account restrictions, velocity and risk checks, and policy-based review before signing. Address allowlists can use cooling periods; device or credential changes can increase scrutiny. Signing keys should be isolated from internet-facing services, with policy enforced both before and within the custody system where possible. Hot wallets hold bounded operational funds, while warmer or offline arrangements require replenishment procedures and separation of duties. The broadcast service must handle fee selection, nonce conflicts, replacement and uncertain submission idempotently. A timeout must never cause an accidental second transfer.

Market data is its own product

Consumers need ordered trades, book deltas, snapshots, tickers and candles. The market-data pipeline transforms engine events without changing their order and gives clients sequence numbers so gaps can be detected. A common recovery pattern is to obtain a snapshot and apply buffered deltas after the snapshot sequence. Slow consumers require bounded buffers and disconnection or degradation policy; they cannot be allowed to backpressure matching. Derived candles need defined interval boundaries, late-event treatment and correction rules. Public and private streams have different authorisation and privacy requirements. Internal surveillance and risk systems may consume richer events than public feeds, but all versions should trace back to the authoritative matching sequence.

Reconciliation connects every subsystem

Continuously reconcile engine fills to ledger postings, reservations to open orders, deposit credits to chain observations, withdrawals to signed and confirmed transactions, and internal asset balances to controlled wallets. Include pending states explicitly so timing differences are not mistaken for losses or hidden as plugs. Reconciliations need stable identifiers, cut-off definitions, tolerances where technically justified and ownership for breaks. Asset movements and administrative adjustments should produce immutable audit events. Operational tooling must let authorised staff investigate and replay safe processing steps without direct table edits. Disaster exercises should restore journals, snapshots, wallet state and sequence positions, then prove that processing resumes without duplication.

Administrative systems carry exceptional power

Operations staff need to suspend accounts, review withdrawals, resolve deposits and correct errors, but an unrestricted admin console can bypass every automated control. Design actions as narrow commands with reason codes, case references and explicit authorisation. High-impact actions can require separate approval according to policy, and the same person should not both propose and approve where separation is required. Administrators should never edit balance fields or order rows directly. Corrections enter the same immutable ledgers and state machines as automated events, with links to the original and to the approval evidence. Sensitive data displayed to support roles should be minimised and access itself audited. Risk controls also need independent state and predictable failure modes. Trading limits, account restrictions, instrument halts and withdrawal policy should be versioned, distributed and acknowledged by enforcing services. Decide whether stale or unavailable risk data causes a fail-closed rejection or a constrained mode; silent continuation is rarely defensible for asset movement. Emergency controls need testing so they stop the intended activity without corrupting sequence or settlement. Audit events should flow to a protected store outside the direct control of the service being observed. These systems are outside the matching loop, yet they determine whether exceptional human and automated actions remain accountable during the incidents when ordinary assumptions no longer hold.

Design from asset safety outwards

Begin with trust boundaries, asset and liability flows, and invariants: who can create an obligation, reserve funds, sign a transfer and correct a ledger entry. Specify identifiers and state machines across order, trade, deposit and withdrawal lifecycles. Build deterministic journals and idempotent consumers, then make reconciliation part of each integration rather than a later reporting project. Test duplicate commands, reconnects, chain reorganisations, nonce conflicts, stale risk data, partial outages and recovery fencing. Matching performance matters, but a credible exchange architecture is the larger controlled system that can account for every order and asset movement before, during and after failure.