Articles on: Whitepaperchevron-right

Matching Engine & Order Book Design

The matching engine is the heart of use.com, responsible for executing trades with sub-millisecond latency while maintaining strict fairness guarantees. This section describes the design principles and performance characteristics that enable institutional-grade execution.


Design Philosophy


Deterministic Execution: Every order is processed according to published rules with no discretionary intervention. Price-time priority is strictly enforced with deterministic tie-breaking.


Symbol Sharding: Each trading pair operates as an independent matching instance, eliminating cross-symbol contention and enabling horizontal scaling.


Event Sourcing: Every state change is recorded as an immutable event, enabling complete auditability and deterministic replay.


Order Priority Rules


Orders are matched according to strict priority:


  1. Price: Best price executes first
  2. Time: Earlier orders execute before later orders at same price
  3. Sequence ID: Deterministic tie-breaking for simultaneous orders


No Hidden Advantages: No preferential routing, no hidden order types, no "maker-taker" games that advantage certain participants.


Performance Characteristics


Latency Targets:


  • Matching latency (p50): < 400 microseconds
  • Matching latency (p99): < 800 microseconds
  • Order-to-fill acknowledgment: < 15 milliseconds globally


Throughput Capacity:


  • Orders per second (per shard): 100,000+
  • Fills per second (per shard): 50,000+
  • Market data updates: 200,000+ per second


Scaling Formula: Total_Capacity=Nshards×Capacityper_shardTotal_Capacity = N_{shards} \times Capacity_{per_shard}Total_Capacity=Nshards​×Capacityper_shard​


Example: 100 trading pairs × 100,000 orders/second = 10 million orders/second aggregate capacity.


Order Types


Market Orders: Execute immediately at best available price


  • Pros: Guaranteed execution
  • Cons: Price uncertainty during volatility


Limit Orders: Execute only at specified price or better


  • Pros: Price certainty
  • Cons: May not execute if price doesn't reach limit


Stop Orders: Trigger market order when price reaches stop level


  • Use Case: Stop-loss protection
  • Trigger: Based on mark price (not last trade price)


Stop-Limit Orders: Trigger limit order when price reaches stop level


  • Use Case: Controlled exit with price protection
  • Risk: May not execute if price gaps through limit


Order Book Structure


Price Levels: Orders grouped by price, sorted by time within each level


Example Order Book:


Depth Calculation: Depthn=∑i=1nVolumeiDepth_{n} = \sum_{i=1}^{n} Volume_iDepthn​=∑i=1n​Volumei​


Where n is the number of price levels from best bid/ask.


Matching Algorithm


Incoming Market Buy Order (1.0 BTC):


  1. Match 1.0 BTC @ $50,100 (best ask)
  2. Update order book (remove filled order)
  3. Publish trade event
  4. Update mark price
  5. Notify both parties


Incoming Limit Sell Order ($50,050, 2.0 BTC):


  1. Check if crosses spread (yes, $50,050 < $50,100)
  2. Match 2.0 BTC @ $50,000 (best bid price, price improvement for seller)
  3. Remaining 0.8 BTC stays in book as new best ask
  4. Publish trade events
  5. Update mark price


Circuit Breakers


Price Deviation Trigger: Deviation=∣Mark_Price−Last_Trade∣Mark_PriceDeviation = \frac{|Mark_Price - Last_Trade|}{Mark_Price}Deviation=Mark_Price∣Mark_Price−Last_Trade∣​


Thresholds:


  • BTC/ETH: 5% deviation triggers pause
  • Major Alts: 10% deviation
  • Long-tail: 15% deviation


Recovery Process:


  1. Pause matching (orders remain in book)
  2. Verify order book integrity
  3. Confirm oracle health
  4. Gradual resume (10% → 50% → 100% capacity)
  5. Monitor for 5 minutes before full restoration


Mark Price Construction


Mark price is used for liquidations and funding rate calculations:


Mark_Price=λ×Oracle_TWAP+(1−λ)×Mid_BookMark_Price = \lambda \times Oracle_TWAP + (1 - \lambda) \times Mid_BookMark_Price=λ×Oracle_TWAP+(1−λ)×Mid_Book


Where:


  • λ = Oracle weight (0.6-0.9 depending on liquidity)
  • Oracle_TWAP = Time-weighted average from multiple oracles
  • Mid_Book = (Best_Bid + Best_Ask) / 2


Example (BTC):


  • Oracle TWAP: $50,000
  • Mid Book: $50,100
  • λ = 0.8
  • Mark Price: 0.8 × $50,000 + 0.2 × $50,100 = $50,020


Performance Monitoring


Published Metrics:


  • Matching latency (p50, p75, p90, p95, p99, p99.9)
  • Order success rate
  • Fill rate
  • Order book depth
  • Spread statistics


SLO Compliance: Monthly reports showing adherence to latency targets with historical trends.


Fairness Guarantees


No Preferential Treatment:


  • All orders processed in strict sequence
  • No "fast lanes" or priority queues
  • Co-location available to all (transparent pricing)
  • Same market data timestamps for all clients


Audit Trail: Every order lifecycle event recorded with microsecond timestamps, enabling independent verification of execution fairness.


Conclusion


use.com's matching engine delivers institutional-grade performance through symbol sharding, event sourcing, and deterministic execution. By publishing priority rules and performance metrics, use.com enables traders to verify fair execution and plan strategies with confidence.



Previous: ← Product Architecture Overview Next: Risk Engine & Liquidation System →


Related Sections:


Updated on: 10/03/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!