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 = N_{shards} \times Capacity_{per\_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:

Asks (Sell Orders):
$50,200 × 1.5 BTC
$50,150 × 2.3 BTC
$50,100 × 3.1 BTC

Bids (Buy Orders):
$50,000 × 2.8 BTC
$49,950 × 1.9 BTC
$49,900 × 3.5 BTC

Spread: $100 (0.2%)

Depth Calculation: $Depth_{n} = \sum_{i=1}^{n} Volume_i$

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 = \frac{|Mark\_Price - Last\_Trade|}{Mark\_Price}$

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 = \lambda \times Oracle\_TWAP + (1 - \lambda) \times 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:

• Core Principles & Design Philosophy

• Infrastructure & Scalability