Starting a crypto exchange requires coordinating infrastructure, liquidity, custody, and compliance systems. This article covers the core architectural decisions, regulatory framework, and operational mechanics that determine whether an exchange can execute trades safely, maintain solvency, and survive regulatory scrutiny. It focuses on centralized exchange (CEX) models rather than decentralized protocols.
Core Architecture Patterns
Three dominant models exist: custodial centralized exchanges, noncustodial hybrid platforms, and pure order routing services.
Custodial centralized exchanges control user private keys and maintain an internal ledger. Users deposit assets into exchange controlled wallets. The exchange credits their internal account and settles trades by updating database records. Blockchain settlement happens only when users withdraw. This model minimizes onchain transaction fees and enables high throughput matching engines but concentrates custody risk.
Noncustodial hybrid platforms execute trades through smart contracts while users retain private keys. The platform provides the matching engine and order book interface but settlement occurs onchain. Latency and gas costs increase, but custody risk transfers to users. This model requires deeper integration with chain specific APIs and gas price oracles.
Order routing services aggregate liquidity from other venues without holding user funds. The platform connects to external exchanges via API, displays composite order books, and routes orders to the venue offering best execution. Revenue comes from markup on spreads or per trade fees. This model reduces regulatory burden but depends entirely on counterparty liquidity and API reliability.
Matching Engine and Order Book Design
The matching engine determines execution speed and fairness. Most production exchanges use price time priority (FIFO): orders at the same price level execute in arrival order. The engine maintains separate buy and sell order trees, typically implemented as red black trees or skip lists for O(log n) insertion and deletion.
Throughput requirements vary by target market. Retail spot exchanges handle 10,000 to 100,000 orders per second. Derivatives platforms or high frequency trading venues require sub millisecond latency and may process several hundred thousand updates per second. This necessitates in memory data structures, kernel bypass networking (DPDK or similar), and deterministic garbage collection if using managed languages.
Matching engines can run in continuous or periodic auction modes. Continuous matching executes trades immediately when orders cross. Periodic auctions batch orders and clear at discrete intervals (every 100ms, for example). Batching simplifies some front running attack vectors but reduces immediacy for market takers.
Order types beyond simple limit and market orders introduce complexity. Stop loss orders require monitoring last trade price and converting to market orders when triggered. Fill or kill and immediate or cancel orders demand specific expiry logic in the matching loop. Post only orders must check whether they would immediately match and cancel if so.
Custody Architecture and Hot Cold Wallet Management
Exchanges must balance liquidity access against theft risk. Standard practice splits funds across hot wallets (online, accessible to the withdrawal system), warm wallets (online but requiring multiple signatures or time delays), and cold wallets (offline or air gapped).
Hot wallet funding depends on expected withdrawal volume. A reasonable starting allocation keeps 2 to 5 percent of total assets in hot wallets, rebalanced daily or when withdrawal volume spikes. Automated rebalancing systems monitor hot wallet balances and initiate warm to hot transfers when thresholds are crossed.
Cold wallet schemes vary. Hardware security modules (HSMs) provide tamper resistant key storage but remain network accessible. Air gapped machines require manual transaction signing and physical media transfer. Multisignature schemes distribute key shares across devices or personnel, requiring M of N signatures to authorize withdrawals. Geographic distribution of signers reduces single point of failure risk but increases operational latency.
Address reuse creates clustering vulnerabilities. Best practice generates a unique deposit address per user per asset. The exchange monitors all controlled addresses via full nodes or block explorers and credits user accounts when deposits reach required confirmation depth (typically 6 blocks for Bitcoin, 12 to 30 for Ethereum depending on value).
Liquidity Bootstrapping
New exchanges face a cold start problem: traders demand liquidity, but liquidity only appears when traders arrive. Several strategies address this.
Market making bots provide baseline liquidity. The exchange operates automated agents that place layered buy and sell orders around the mid price. These bots must manage inventory risk, adjusting quote density and spread based on position size and market volatility. Some exchanges incentivize external market makers with fee rebates or trading credits.
Integration with liquidity aggregators or prime brokers allows routing orders to established venues when local depth is insufficient. This converts the exchange into a hybrid model temporarily while organic liquidity develops.
Wash trading (trading with yourself to inflate volume) is illegal in most jurisdictions and creates false signals. Regulators now monitor for circular trading patterns, self matching orders, and anomalous volume to depth ratios.
Regulatory and Compliance Framework
Licensing requirements depend on jurisdiction. The United States requires money transmitter licenses in most states plus federal FinCEN registration. EU member states require MiFID II authorization or e money licenses depending on services offered. Asian jurisdictions vary: Singapore requires a Major Payment Institution license, Japan requires registration with the Financial Services Agency, and China prohibits most crypto exchange operations.
Know Your Customer (KYC) and Anti Money Laundering (AML) systems must verify user identity and monitor transaction patterns. Minimum KYC collects name, address, date of birth, and government ID. Enhanced due diligence applies to high value accounts or high risk jurisdictions. AML systems flag structured deposits, rapid movement of funds between accounts, and transactions involving sanctioned addresses. Transaction monitoring tools typically integrate with blockchain analytics services that trace fund flows across addresses and identify mixing service usage.
Bank partnerships determine fiat onramp and offramp viability. Traditional banks often refuse crypto exchange accounts due to perceived compliance risk. Crypto friendly banks or payment processors charge higher fees (often 1 to 3 percent of fiat volume) and require proof of robust AML controls. Some exchanges partner with licensed money services businesses that handle fiat custody and settlement separately.
Reserve attestations or proof of reserves demonstrate solvency. Periodic third party audits verify that the exchange controls blockchain addresses holding at least 100 percent of customer liabilities. Real time cryptographic proofs using Merkle trees allow users to verify their balance is included in the commitment without revealing other account details. These proofs require the exchange to publish a root hash of all account balances and provide each user a Merkle path from their balance to the root.
Worked Example: Trade Settlement Flow
A user places a limit order to buy 1 BTC at 30,000 USDT. The matching engine inserts this order into the buy side order tree at the 30,000 price level. Another user submits a market sell order for 1 BTC. The engine matches this against the best available buy order.
The database transaction updates both account balances atomically: debit 30,000 USDT from buyer, credit 1 BTC to buyer, debit 1 BTC from seller, credit 30,000 USDT to seller. The engine publishes a trade event to downstream systems: risk management, fee calculation, reporting. Fee logic deducts maker and taker fees (illustratively 0.1 percent maker, 0.2 percent taker) and credits the exchange fee wallet.
If the buyer then requests withdrawal of the 1 BTC, the withdrawal system verifies account balance, checks daily withdrawal limits, and queues the transaction. The hot wallet service signs a Bitcoin transaction sending 1 BTC minus network fee to the user specified address. The transaction broadcast service submits to the Bitcoin network and monitors confirmation status. After 6 confirmations, the system marks the withdrawal complete.
Common Mistakes and Misconfigurations
-
Running matching engine and database on the same physical host creates contention for CPU and memory, degrading order execution latency. Separate these onto dedicated machines.
-
Insufficient database connection pooling causes connection exhaustion under load. Configure connection pools to 2x the number of worker threads handling order submissions.
-
Failure to implement idempotency checks on deposit crediting allows double spend attacks if the same blockchain transaction is processed twice. Hash and store transaction IDs in a deduplication table.
-
Broadcasting withdrawal transactions without Replace By Fee (RBF) or Child Pays For Parent (CPFP) capability leaves transactions stuck when network fees spike. Implement fee bumping logic that monitors pending transactions and rebroadcasts with higher fees if unconfirmed after a threshold period.
-
Storing private keys in application configuration files or environment variables exposes them to any process with filesystem or memory access. Use HSMs or encrypted key stores with access restricted to signing services.
-
Implementing order cancellation as a soft delete that leaves orders in the matching engine tree creates memory leaks and slows matching. Hard delete canceled orders immediately or mark them invalid and compact the tree periodically.
What to Verify Before You Rely on This
-
Current licensing requirements for your target jurisdiction: contact financial regulators directly or engage legal counsel specializing in crypto asset regulation.
-
Blockchain confirmation depth policies: verify current network hash rate and historical reorg depth for each supported chain to determine safe confirmation thresholds.
-
Third party service uptime and API rate limits: blockchain node providers, KYC vendors, and bank partners each impose different availability guarantees and usage caps.
-
Insurance coverage options: specialized crypto custodian insurance exists but policy terms, coverage limits, and premium costs vary significantly and change frequently.
-
Smart contract audit results if using any onchain settlement: verify audit firm credentials and review specific findings for each contract version you deploy.
-
Applicable sanctions lists: OFAC and other regulatory bodies update sanctioned addresses and entities regularly. Integrate automated checks against current lists.
-
Margin and leverage limits: if offering leveraged trading, confirm regulatory caps on maximum leverage ratios for retail versus institutional clients in your jurisdiction.
-
Cold wallet recovery procedures: test your backup and recovery process end to end before holding significant customer funds. Verify all key shares are accessible and functional.
-
Data retention and privacy requirements: GDPR, CCPA, and other privacy frameworks impose specific obligations on customer data storage and deletion rights.
-
Gas price oracle reliability: if using dynamic fee estimation for onchain settlement, validate that your oracle provides consistent data during network congestion events.
Next Steps
-
Deploy a testnet version with simulated order flow to validate matching engine throughput and identify bottlenecks under load. Use profiling tools to measure latency distribution across order submission, matching, and database persistence.
-
Establish relationships with at least two blockchain node providers and implement automatic failover if your primary provider experiences downtime or lags behind the chain tip.
-
Engage with a specialized crypto insurance broker to evaluate custodian insurance options and structure coverage that aligns with your hot, warm, and cold wallet allocations.
Category: Crypto Exchanges
