A complete guide to cryptocurrency exchange development

What is a cryptocurrency exchange?

A cryptocurrency exchange is an online platform that allows users to buy, sell, and exchange various digital assets (such as Bitcoin, Ethereum, USDT, etc.). Exchanges play the role of liquidity hubs in the crypto ecosystem and are the main channels for funds to enter and exit the crypto market.

Core functions of the exchange

Data reference from global leading exchanges

Exchange classification

CEX vs DEX Technology Comparison

System architecture design

The technical architecture of a production-grade cryptocurrency exchange involves dozens of microservices modules, and the following is the hierarchical structure of the core system:

Key performance indicators

• Matching delay:< 100 microseconds (single trading pair), supporting 1 million+ orders per second
• API response:P 99 < 10ms, supporting 100,000+ concurrent connections
• Market push: Full Tick data latency < 5ms, WebSocket broadcast
• System availability: 99.99% (< 52 minutes downtime throughout the year)
• Data consistency: Zero errors in funds, reconciliation frequency ≤ 1 minute

Matching engine

The Matching Engine is the heart of the exchange, responsible for matching buy and sell orders according to the principles of price first and time priority. Its performance directly determines the competitiveness of the exchange.

Matching algorithm core implementation

// matching/engine.go - 撮合引擎核心
type MatchingEngine struct {
    Symbol    string
    OrderBook *OrderBook
    Trades    chan *Trade
    mu        sync.Mutex
}

type OrderBook struct {
    Bids *RedBlackTree  // 买单（价格降序）
    Asks *RedBlackTree  // 卖单（价格升序）
}

type Order struct {
    ID        uint64
    Side      Side      // Buy / Sell
    Type      OrderType // Limit / Market / StopLimit
    Price     Decimal   // 限价
    Quantity  Decimal   // 数量
    Filled    Decimal   // 已成交
    Timestamp int64     // 纳秒时间戳
    UserID    uint64
}

func (e *MatchingEngine) ProcessOrder(order *Order) []*Trade {
    e.mu.Lock()
    defer e.mu.Unlock()

    var trades []*Trade

    if order.Side == Buy {
        // 买单 vs 卖单簿匹配
        trades = e.matchBuyOrder(order)
    } else {
        // 卖单 vs 买单簿匹配
        trades = e.matchSellOrder(order)
    }

    // 未完全成交的限价单挂入订单簿
    if order.Remaining() > 0 && order.Type == Limit {
        e.OrderBook.Insert(order)
    }

    return trades
}

func (e *MatchingEngine) matchBuyOrder(buyOrder *Order) []*Trade {
    var trades []*Trade
    asks := e.OrderBook.Asks

    for asks.Len() > 0 && buyOrder.Remaining() > 0 {
        bestAsk := asks.Min().(*Order)

        // 价格不匹配则停止
        if buyOrder.Type == Limit && buyOrder.Price.LessThan(bestAsk.Price) {
            break
        }

        // 计算成交量
        matchQty := Decimal.Min(buyOrder.Remaining(), bestAsk.Remaining())
        matchPrice := bestAsk.Price // 按挂单价成交

        // 生成成交记录
        trade := &Trade{
            Price:    matchPrice,
            Quantity: matchQty,
            BuyerID:  buyOrder.UserID,
            SellerID: bestAsk.UserID,
            BuyOrderID:  buyOrder.ID,
            SellOrderID: bestAsk.ID,
            Timestamp: time.Now().UnixNano(),
        }
        trades = append(trades, trade)

        // 更新订单状态
        buyOrder.Filled = buyOrder.Filled.Add(matchQty)
        bestAsk.Filled = bestAsk.Filled.Add(matchQty)

        // 完全成交则移除
        if bestAsk.Remaining().IsZero() {
            asks.DeleteMin()
        }
    }
    return trades
}

Matching engine design points

• Memory first: The order book is all maintained in memory, using the red and black tree/skip table to ensure O(log N) insertion and deletion
• Single-threaded matching: Each trading pair is threaded independently, avoiding lock contention and ensuring certainty
• Event traceability: All order operations are written to WAL (Write-Ahead Log) to support fault recovery
• Snapshot mechanism: Persist order book snapshots regularly, combined with WAL for fast restarts
• Serialization: Each order is assigned a globally incremental serial number to ensure consistency in replay

Order type vs. order book

Supported order types

Order book data structures

// orderbook/book.go - 高性能订单簿
type PriceLevel struct {
    Price    Decimal
    Orders   *list.List  // 同价格FIFO队列
    Quantity Decimal     // 该价位总挂单量
}

type OrderBook struct {
    bids     *skiplist.SkipList  // 买单（降序）
    asks     *skiplist.SkipList  // 卖单（升序）
    orderMap map[uint64]*Order   // O(1) 订单查找
}

// 获取深度数据（L2）
func (ob *OrderBook) GetDepth(levels int) *Depth {
    depth := &Depth{
        Bids: make([]PriceQty, 0, levels),
        Asks: make([]PriceQty, 0, levels),
    }

    iter := ob.bids.Iterator()
    for i := 0; i < levels && iter.Next(); i++ {
        level := iter.Value().(*PriceLevel)
        depth.Bids = append(depth.Bids, PriceQty{
            Price:    level.Price,
            Quantity: level.Quantity,
        })
    }

    iter = ob.asks.Iterator()
    for i := 0; i < levels && iter.Next(); i++ {
        level := iter.Value().(*PriceLevel)
        depth.Asks = append(depth.Asks, PriceQty{
            Price:    level.Price,
            Quantity: level.Quantity,
        })
    }
    return depth
}

Wallet system

The wallet system is responsible for managing the recharge, withdrawal, aggregation, and secure storage of users' digital assets, which is the core of the security of exchange funds.

Wallet architecture

Recharge detection source code

// wallet/deposit_scanner.go - 充值扫描服务
type DepositScanner struct {
    chain       string
    rpcClient   BlockchainClient
    db          *gorm.DB
    confirmations int
}

func (s *DepositScanner) ScanBlock(blockNum uint64) error {
    block, err := s.rpcClient.GetBlockByNumber(blockNum)
    if err != nil { return err }

    for _, tx := range block.Transactions {
        // 检查是否为用户充值地址
        if s.isUserDepositAddress(tx.To) {
            deposit := &Deposit{
                TxHash:      tx.Hash,
                Chain:       s.chain,
                Address:     tx.To,
                Amount:      tx.Value,
                BlockNumber: blockNum,
                Status:      "pending",
            }
            s.db.Create(deposit)
        }

        // ERC-20 Transfer 事件检测
        for _, log := range tx.Logs {
            if s.isERC20Transfer(log) {
                token, to, amount := s.decodeTransfer(log)
                if s.isUserDepositAddress(to) {
                    deposit := &Deposit{
                        TxHash:  tx.Hash,
                        Chain:   s.chain,
                        Token:   token,
                        Address: to,
                        Amount:  amount,
                        Status:  "pending",
                    }
                    s.db.Create(deposit)
                }
            }
        }
    }
    return nil
}

// 确认数达标后入账
func (s *DepositScanner) ConfirmDeposits(currentBlock uint64) {
    var pending []Deposit
    s.db.Where("status = ? AND chain = ?", "pending", s.chain).Find(&pending)

    for _, d := range pending {
        if currentBlock - d.BlockNumber >= uint64(s.confirmations) {
            // 入账到用户余额
            s.creditUserBalance(d.UserID, d.Token, d.Amount)
            d.Status = "confirmed"
            s.db.Save(&d)
        }
    }
}

Futures Trading (Perpetual Contracts)

Perpetual futures are the core derivatives of cryptocurrency exchanges, with no expiration date and anchored to the spot price through a funding rate mechanism.

The core mechanism of perpetual contracts

Liquidation engine

// liquidation/engine.go - 强平引擎
type LiquidationEngine struct {
    positions  *PositionStore
    markPrices *MarkPriceService
    insurance  *InsuranceFund
}

func (le *LiquidationEngine) CheckPositions() {
    positions := le.positions.GetAllOpen()

    for _, pos := range positions {
        markPrice := le.markPrices.Get(pos.Symbol)
        marginRatio := le.calcMarginRatio(pos, markPrice)

        if marginRatio <= pos.MaintenanceMarginRate {
            le.liquidate(pos, markPrice)
        }
    }
}

func (le *LiquidationEngine) calcMarginRatio(pos *Position, markPrice Decimal) Decimal {
    // 未实现盈亏
    unrealizedPnL := pos.Side.PnL(pos.EntryPrice, markPrice, pos.Size)
    // 账户权益
    equity := pos.Margin.Add(unrealizedPnL)
    // 仓位价值
    positionValue := markPrice.Mul(pos.Size)
    // 保证金率
    return equity.Div(positionValue)
}

func (le *LiquidationEngine) liquidate(pos *Position, markPrice Decimal) {
    // 1. 取消该仓位所有挂单
    le.cancelOpenOrders(pos)
    // 2. 以破产价格提交平仓单
    bankruptcyPrice := le.calcBankruptcyPrice(pos)
    order := &Order{
        Symbol:   pos.Symbol,
        Side:     pos.Side.Opposite(),
        Type:     Market,
        Quantity: pos.Size,
        Source:   "liquidation",
    }
    // 3. 盈余归入保险基金
    proceeds := le.executeClose(order, markPrice)
    if proceeds.GreaterThan(Zero) {
        le.insurance.Add(pos.Symbol, proceeds)
    }
}

Risk control system

Risk control systems act as security barriers for exchanges, monitoring abnormal behavior in real-time and preventing market manipulation and misappropriation of funds.

Risk control level

Real-time risk control rule engine

// risk/realtime_engine.go
type RiskEngine struct {
    rules    []RiskRule
    metrics  *MetricsCollector
}

type RiskRule interface {
    Check(order *Order, context *RiskContext) *RiskResult
}

// 价格偏离检测
type PriceDeviationRule struct {
    MaxDeviation Decimal  // 如 5%
}

func (r *PriceDeviationRule) Check(order *Order, ctx *RiskContext) *RiskResult {
    if order.Type != Limit { return Pass() }
    
    lastPrice := ctx.LastTradePrice(order.Symbol)
    deviation := order.Price.Sub(lastPrice).Abs().Div(lastPrice)
    
    if deviation.GreaterThan(r.MaxDeviation) {
        return Reject("price_deviation_exceeded",
            fmt.Sprintf("偏离 %.2f%% 超过阈值 %.2f%%", deviation*100, r.MaxDeviation*100))
    }
    return Pass()
}

// 频率限制
type RateLimitRule struct {
    MaxOrdersPerSecond int
    window             map[uint64]*slidingWindow
}

func (r *RateLimitRule) Check(order *Order, ctx *RiskContext) *RiskResult {
    w := r.getWindow(order.UserID)
    if w.Count() >= r.MaxOrdersPerSecond {
        return Reject("rate_limit", "下单频率超限")
    }
    w.Add()
    return Pass()
}

Liquidity management

Liquidity is the lifeblood of exchanges. A well-depth order book can provide tighter bid-ask spreads and less slippage, attracting more traders to form a positive cycle.

Sources of liquidity

• Market Maker: Professional institutions continue to place orders on both sides of the buyer and seller to earn spread profits. Fee discounts or rebate incentives are usually given.
• API trader: The quantitative team accessed through the REST/WebSocket/FIX protocol contributes a large number of limit orders.
• Move bricks across the place: Arbitrage robots move liquidity between different exchanges to help price converge.
• Liquidity aggregation: Access to third-party liquidity pools (e.g., B2C2, Cumberland) to replenish depth.

Market maker API design

// 批量下单接口（低延迟专用）
POST /api/v1/mm/batch-orders
{
    "symbol": "BTC-USDT",
    "orders": [
        {"side": "buy",  "price": "67450.00", "qty": "0.5", "type": "limit"},
        {"side": "buy",  "price": "67400.00", "qty": "1.0", "type": "limit"},
        {"side": "sell", "price": "67550.00", "qty": "0.5", "type": "limit"},
        {"side": "sell", "price": "67600.00", "qty": "1.0", "type": "limit"}
    ],
    "cancelPrevious": true  // 原子性替换旧订单
}

// 做市商专属 WebSocket（Colocation 级别）
// 延迟 < 1ms，独立通道，优先处理
ws://exchange.com/ws/mm?apiKey=xxx&dedicatedLine=true

KYC and compliance system

With tighter regulations around the world, KYC (Know Your Customer) and AML (Anti-Money Laundering) have become mandatory requirements for exchanges.

KYC tiered verification

AML compliance system

• Transaction Monitoring: Real-time detection of large transactions, split transactions (Structuring), and fast in and out modes
• On-chain analytics: Integrate Chainalysis / Elliptic to identify high-risk addresses (dark web, coin mixers, sanctions lists)
• SAR report: Suspicious activity automatically generates reports and submits them to the financial intelligence unit of each jurisdiction
• Travel rules: Comply with the FATF Travel Rule, large transfers come with sender/receiver identity information

Security system

Multi-layered security protection

Recommended technology stack

Exchange development process

Based on the delivery experience of the NovaLinkR team in multiple exchange projects, the complete development process is as follows: