Building a Crypto Exchange: Architecture and Infrastructure

A crypto exchange is software that matches buy and sell orders for digital assets, maintains custody (or coordinates noncustodial settlement), and enforces trading rules. Building one means choosing between centralized orderbook architectures, hybrid custody models, or fully onchain automated market maker designs. This article covers the core infrastructure layers, decision points for matching engines and custody, and operational failure modes that emerge under load or regulatory scrutiny.

Matching Engine: Centralized Orderbook vs. Onchain Settlement

A centralized matching engine runs offchain in your data center. Orders arrive over WebSocket or REST, the engine maintains a limit orderbook in memory, and fills execute in microseconds. You record trades in a relational database and broadcast fills to connected clients. Most volume occurs on centralized engines because latency matters for market makers and arbitrageurs.

An onchain matching engine lives in a smart contract. Orders are transactions submitted to the chain. The contract holds an orderbook in contract storage or uses an AMM curve to price trades algorithmically. Settlement is atomic with execution, but throughput is limited by block time and gas cost. Uniswap and its forks popularized the constant product AMM model, eliminating the orderbook entirely in favor of liquidity pools.

Hybrid models keep the matching engine offchain but settle net positions onchain periodically. StarkEx and similar validity rollups batch trades into a zero knowledge proof and post state diffs to Ethereum. Users get fast fills with cryptographic settlement guarantees, but you still operate the sequencer and must decide who can censor or reorder transactions.

Custody Architecture: Hot Wallets, Cold Storage, and Withdrawal Flow

Centralized exchanges hold user funds in wallets controlled by the exchange. A typical setup:

Hot wallets: private keys live in memory on withdrawal servers, used for instant withdrawals up to a threshold. These wallets hold 2 to 5 percent of total assets.
Warm wallets: keys stored in hardware security modules or secure enclaves, requiring manual approval or time delay. Used for daily rebalancing.
Cold wallets: keys on air gapped hardware or distributed among multisig signers. Holds the majority of customer deposits and require physical presence or ceremony to access.

Withdrawal flow: user requests a withdrawal, the request enters a queue, risk checks run (velocity limits, KYC status, AML screening), then the system selects a hot wallet with sufficient balance. If the amount exceeds the hot wallet threshold, the request waits for a warm or cold wallet sweep. High frequency traders often negotiate dedicated hot wallet allocations to avoid delays.

Noncustodial exchanges never take custody. Users sign transactions from their own wallets and submit them directly to the settlement layer, whether that is a smart contract or a rollup. You operate infrastructure for orderbook hosting and API access but hold no private keys.

Order Types and Risk Controls

A production exchange supports limit orders, market orders, stop loss orders, and conditional orders. Each type requires distinct validation and execution logic:

Limit orders specify price and quantity. The engine checks balance, places the order in the book, and matches against crossing orders immediately.
Market orders execute at the best available price up to the specified quantity. You must enforce slippage limits to prevent user error or manipulation during low liquidity.
Stop loss orders trigger a market or limit order when the mark price crosses a threshold. The engine monitors a reference price feed and activates the order when conditions are met.

Risk controls include:

Self trade prevention: reject orders that would match against the same user’s resting orders.
Rate limits: cap order submissions per second per user and per API key to prevent queue saturation.
Position limits: enforce maximum exposure per user per asset, especially for margin and derivatives products.
Circuit breakers: halt trading if the price moves more than a defined percentage in a short window, indicating a potential oracle failure or market dislocation.

Liquidity and Market Maker Integration

Exchanges launch with minimal organic liquidity. Bootstrapping requires integrating professional market makers who provide continuous two sided quotes. You typically offer:

Fee rebates or zero fees for makers who post liquidity.
Colocation or low latency API access to reduce execution uncertainty.
Dedicated support and higher rate limits.

Market makers run algorithms that quote tight spreads while hedging on other venues. They need reliable WebSocket feeds with full orderbook depth updates and trade execution confirmations in under 10 milliseconds round trip time. Any latency spike or missed message causes them to widen spreads or withdraw entirely, degrading the trading experience for retail users.

Some exchanges operate their own market making desks to seed liquidity. This creates a principal agent conflict: the exchange knows all order flow and can front run or trade against customers. Segregating the market making entity with separate infrastructure and compliance oversight mitigates but does not eliminate the risk.

Regulatory Compliance and License Requirements

Jurisdiction determines whether you must register as a money services business, obtain a securities exchange license, or operate under a derivatives clearing organization framework. In the United States, exchanges offering tokens deemed securities must register with the SEC or operate under an exemption. Commodity tokens fall under CFTC jurisdiction if you offer margin or futures.

KYC and AML requirements vary by jurisdiction and customer type. Most regulated venues collect government ID, proof of address, and source of funds documentation during onboarding. Ongoing monitoring flags suspicious deposit or withdrawal patterns, and exchanges file SARs when thresholds are crossed.

Banking relationships determine fiat onramp and offramp capability. Payment processors and correspondent banks conduct their own due diligence and impose transaction limits, reserve requirements, or outright refusal if your compliance program is weak. Loss of banking is an operational kill switch for centralized fiat exchanges.

Failure Modes and Downtime Scenarios

Matching engines fail under extreme load when order submission rate exceeds processing capacity. The queue fills, new orders time out, and existing orders experience delayed fills or incorrect execution sequence. Mitigation: rate limit aggressively and overprovision compute capacity to handle 10x typical peak volume.

Database replication lag causes stale balance reads. A user with 100 USDT available sees that balance, submits an order for 100 USDT, but the balance check reads a replicated database that shows 90 USDT due to a recent trade. The order rejects incorrectly. Use synchronous writes for balance updates or lock balances at order submission rather than execution.

Hot wallet depletion blocks withdrawals when deposit inflows slow and withdrawal requests spike. Users see pending withdrawal status for hours. Automate warm wallet sweeps to hot wallets when balances drop below thresholds, and display estimated wait times to set expectations.

Oracle failures or manipulation cause incorrect mark prices, triggering liquidations or stop orders at wrong levels. Use multiple independent price feeds and reject outliers before publishing the reference price. Log all oracle inputs for post incident analysis.

Worked Example: Limit Order Execution Path

Alice submits a limit order to buy 1 BTC at 45,000 USDT. The engine receives the order, checks that Alice has at least 45,000 USDT available, then locks that balance. The order enters the book on the buy side at 45,000.

Bob submits a market order to sell 0.5 BTC. The engine matches against the best bid, which is Alice’s order at 45,000. Bob’s order fills 0.5 BTC at 45,000 USDT per BTC, for a total of 22,500 USDT. The engine debits 22,500 USDT from Alice’s locked balance, credits 0.5 BTC to Alice, debits 0.5 BTC from Bob, and credits 22,500 USDT to Bob. Alice’s remaining 0.5 BTC limit order stays in the book with 22,500 USDT still locked.

If Bob’s market order was for 2 BTC, the engine matches 1 BTC against Alice at 45,000, then walks down the book to the next best bid. If insufficient liquidity exists, the unfilled portion either rejects (fill or kill) or rests as a limit order at the worst fill price (immediate or cancel with post).

Common Mistakes and Misconfigurations

Using floating point arithmetic for balance tracking. Rounding errors accumulate over millions of trades. Use fixed point integer math with a defined precision, such as 8 decimal places represented as integers.
Skipping idempotency checks on order submission. Network retries cause duplicate orders. Assign client order IDs and reject duplicates within a time window.
Exposing admin endpoints to the public internet. Separate control plane APIs onto a private network or VPN. One leaked admin token can drain all wallets.
Running a single matching engine instance. Hardware failure or process crash halts all trading. Deploy active passive or active active pairs with failover automation.
Insufficient load testing before launch. Simulate 100x expected order volume to find bottlenecks. Test database failover and hot wallet failover under load.
Mixing omnibus custody with individual balance tracking. If the database corrupts and you lose the balance ledger, you cannot reconstruct who owns what from the blockchain alone.

What to Verify Before You Rely on This

Current licensing requirements in your target jurisdictions. Regulations change frequently and vary by asset type and customer location.
Smart contract audit status and findings if using onchain settlement. Check for open critical or high severity issues.
Blockchain finality guarantees and reorg depth for the chains you support. Settlement assumptions differ between proof of work and proof of stake.
Payment processor terms and reserve requirements for fiat rails. Confirm withdrawal limits and hold periods.
Insurance coverage and proof of reserves publication frequency if the exchange claims to hold assets in custody.
API rate limits and WebSocket message throughput if you plan to integrate as a market maker or arbitrageur.
Withdrawal processing times and fee structure. Test small withdrawals to measure actual speed versus published claims.
Supported order types and execution guarantees. Not all exchanges honor stop loss triggers during circuit breaker halts.
Jurisdiction restrictions and VPN detection policies. Some exchanges block VPN access or geoblock entire countries.
Historical uptime and incident disclosure. Review post mortems for past outages to assess operational maturity.

Next Steps

Deploy a testnet matching engine and connect simulated market makers to measure latency and throughput under load.
Prototype a withdrawal flow with hot wallet, warm wallet, and cold wallet tiers using multisig wallets on a test blockchain.
Consult with a securities or derivatives attorney in your target jurisdiction to map licensing and registration paths before committing to an architecture.

Category: Crypto Exchanges