Crypto exchanges sit between user intent and onchain execution, translating buy and sell instructions into database updates, blockchain transactions, or both. Understanding their internal mechanics helps you choose the right venue for your use case, anticipate failure modes, and assess counterparty risk. This article walks through order lifecycle, matching engines, settlement layers, and custody models for centralized and decentralized architectures.
Centralized Exchange Architecture: Offchain Order Books
Most centralized exchanges (CEXs) run an offchain order book and matching engine. When you deposit BTC or USDT, the exchange credits your account balance in its internal database. Your deposit transaction settles onchain, but from that point forward your trades happen entirely in the exchange’s ledger.
The matching engine sorts limit orders by price and time priority. When you submit a market buy, the engine matches your order against the best available sell orders, executes fills at those prices, and debits your quote asset balance while crediting your base asset balance. The entire sequence happens in microseconds, well below blockchain block times.
Settlement finality is database finality. The exchange’s internal ledger is authoritative until you withdraw. Withdrawals trigger an onchain transaction from the exchange’s hot or cold wallet to your address. This design enables high throughput (thousands of matches per second) and sub-millisecond latency, but introduces custodial risk: you trust the exchange to honor its internal ledger and process withdrawals.
Decentralized Exchange Models: AMM vs. Onchain Order Books
Decentralized exchanges avoid custodial risk by executing trades onchain or through smart contracts. Two dominant models exist: automated market makers (AMMs) and onchain order books.
AMMs pool liquidity into smart contracts. Liquidity providers deposit token pairs (for example, ETH and USDC) into a pool. The contract prices trades using a formula, typically constant product (x times y equals k). When you swap ETH for USDC, the contract removes ETH from the pool, adds it to your balance, removes USDC from the pool, and sends it to you. Price adjusts according to the formula. No order book or matching engine exists. This model works well for standard pairs but suffers from slippage on large trades and impermanent loss for liquidity providers.
Onchain order book DEXs post limit orders as blockchain transactions or contract state updates. A matching engine (either onchain or offchain with onchain settlement) pairs orders and executes fills. Examples include certain Solana programs that leverage fast block times to make onchain matching viable. Settlement happens onchain per trade, not per withdrawal, so finality depends on block confirmation. Latency and throughput are constrained by the underlying chain.
Order Lifecycle in a Centralized Venue
A typical lifecycle proceeds as follows:
-
Submission: You send a REST or WebSocket message with order parameters (symbol, side, type, quantity, limit price if applicable). The exchange validates balance, applies rate limits, and inserts the order into the book.
-
Matching: The engine scans the opposite side of the book. For a limit buy at $30,000, the engine matches against sell orders at $30,000 or lower, starting with the lowest price. Partial fills occur if available liquidity is insufficient.
-
Execution: The engine updates account balances for both parties. Maker and taker fees apply (makers provide liquidity, takers remove it). Fee schedules vary by tier, often volume based.
-
Confirmation: The exchange publishes a trade message over WebSocket and logs the fill in the user’s order history. The order remains open if partially filled or closes if fully filled or canceled.
-
Reconciliation: Backend processes periodically reconcile the matching engine’s ledger against the database of record, ensuring consistency.
Order types include market, limit, stop loss, stop limit, and algorithmic variants (iceberg, time weighted average price). Each interacts with the matching engine differently. Market orders execute immediately at best available price. Stop orders convert to market or limit orders once a trigger price is reached.
Custody Models and Wallet Infrastructure
Exchanges hold customer funds in hot wallets (connected to the internet for fast withdrawals) and cold wallets (offline, multisig, or hardware secured). The split depends on withdrawal demand and security policy. A common pattern allocates 5 to 10 percent to hot wallets and the remainder to cold storage.
Hot wallets monitor withdrawal queues and automatically sign transactions up to predefined thresholds. Larger withdrawals or unusual patterns trigger manual review. Cold wallet access requires multiple signatories or hardware device interaction, slowing throughals but reducing attack surface.
Proof of reserves schemes attempt to verify that the exchange holds onchain assets equal to or greater than customer balances. The exchange publishes a Merkle tree of account balances (hashed for privacy) and signs onchain addresses proving control. Users verify their balance appears in the tree and that total liabilities do not exceed proven reserves. This method does not prove solvency (liabilities could include undisclosed debts), but it does verify a lower bound on asset holdings.
Worked Example: Limit Order Fill Sequence
You place a limit buy for 0.5 BTC at $29,500 on a CEX with a maker fee of 0.10 percent and taker fee of 0.15 percent. Current best ask is $29,600. Your order rests in the book as a maker bid.
Another user submits a market sell for 0.3 BTC. The matching engine scans bids, finds your order at $29,500, and fills 0.3 BTC against it. Your account is debited $8,850 (0.3 BTC times $29,500) plus $8.85 maker fee, total $8,858.85 USDT. You are credited 0.3 BTC. The seller’s account is debited 0.3 BTC and credited $8,835.75 USDT (after 0.15 percent taker fee).
Your order remains open for the unfilled 0.2 BTC. If another market sell arrives at $29,400 or the best ask drops below $29,500, your order will not match (you specified a maximum buy price of $29,500). If the best ask rises and a market sell occurs, your order matches if it remains the best bid.
Common Mistakes and Misconfigurations
-
Assuming database updates are onchain settlement. Trades on CEXs settle in the exchange’s ledger. Only deposits and withdrawals touch the blockchain. If the exchange’s ledger is compromised or insolvent, your balance may not be recoverable.
-
Ignoring taker vs. maker fee schedules. Market orders always pay taker fees. Using limit orders and allowing them to rest in the book converts you to a maker, often halving your fee rate.
-
Overlooking withdrawal thresholds and approval times. Exchanges batch withdrawals or impose manual review above certain amounts. A 10 BTC withdrawal may take hours, not minutes.
-
Trusting proof of reserves without checking liabilities. An exchange can prove it holds 100,000 BTC onchain but still owe users 150,000 BTC. Proof of reserves is not proof of solvency.
-
Failing to verify contract addresses on DEXs. Phishing sites present fake AMM interfaces with malicious contract addresses. Always confirm the router or pool address against official sources before approving token spend.
-
Misunderstanding slippage settings in AMM swaps. A 0.5 percent slippage tolerance on a $100,000 swap permits up to $500 adverse price movement. During volatility or for illiquid pairs, the actual execution price may hit your slippage cap, causing the transaction to revert.
What to Verify Before You Rely on This
- Current fee schedule (maker, taker, withdrawal) for your volume tier. Exchanges adjust rates periodically.
- Withdrawal processing times and any minimum or maximum limits per transaction or per 24 hour period.
- Hot wallet and cold wallet allocation policy, if disclosed. Some exchanges publish security whitepapers.
- Proof of reserves attestation date and scope. Verify whether the attestation includes all supported assets or only BTC and ETH.
- Insurance fund size and coverage terms. Some venues maintain funds to cover liquidation shortfalls or security incidents.
- Onchain contract addresses for DEX routers, factories, and pool implementations. Cross reference against the protocol’s GitHub or official documentation.
- Block explorer confirmation for onchain order book DEXs. Ensure the matching contract is audited and settlement transactions are visible.
- Jurisdiction and regulatory status. Licensing and compliance obligations vary by region and affect withdrawal rights during disputes.
- API rate limits and WebSocket message caps if you run automated strategies. Exceeding limits results in temporary bans.
- Order type support and execution guarantees. Not all exchanges support stop limit or post only flags.
Next Steps
- Review the order API documentation for your primary exchange. Identify supported order types, time in force options, and error codes.
- Set up a testnet account or paper trading environment to observe order lifecycle without capital at risk. Submit limit and market orders, monitor fill messages, and inspect resulting balances.
- For DEXs, simulate a swap using a block explorer’s contract interaction tool. Read the pool reserves before and after to see how the constant product formula adjusts price.
Category: Crypto Exchanges
