Smart Order Routing (SOR) Algorithm Development
Smart Order Routing (SOR) is an algorithm that automatically determines optimal execution location and method among multiple available venues. Goal: minimize execution cost (price + fees + slippage) within speed constraints.
SOR Task
Need to buy 50 BTC. Available:
- Binance: best ask 45,100, available 12 BTC
- Bybit: best ask 45,095, available 8 BTC
- OKX: best ask 45,102, available 25 BTC
- Kraken: best ask 45,098, available 10 BTC
Naive approach: take best price (Bybit). But only 8 BTC there. Need to optimally distribute 50 BTC across exchanges.
Optimal Allocation Algorithm
Sweep liquidity by levels: build merged order book from all exchanges, take best prices starting from cheapest.
def merge_orderbooks(orderbooks_dict):
"""
Merge order books from multiple exchanges into single
"""
merged_asks = []
for exchange, ob in orderbooks_dict.items():
for price, qty in ob['asks']:
# Account for exchange fees
adjusted_price = price * (1 + fees[exchange])
merged_asks.append({
'exchange': exchange,
'price': price,
'adjusted_price': adjusted_price,
'qty': qty
})
return sorted(merged_asks, key=lambda x: x['adjusted_price'])
def optimal_allocation(merged_asks, target_qty):
allocation = {}
remaining = target_qty
for level in merged_asks:
if remaining <= 0:
break
fill_qty = min(level['qty'], remaining)
exchange = level['exchange']
allocation[exchange] = allocation.get(exchange, 0) + fill_qty
remaining -= fill_qty
return allocation
Transaction Cost Accounting
Execution price is not the only cost component:
| Component | Description |
|---|---|
| Exchange fee | Taker fee on each exchange (0.03–0.07%) |
| Withdrawal fee | When transferring between exchanges (if needed) |
| Slippage | Difference between best price and execution price |
| Funding rate | For perpetual positions |
| Network latency | Faster execution on closer exchanges |
Adjusted cost model:
Total Cost = Σ(qty_i × price_i × (1 + fee_i)) + slippage_estimate_i
Latency Arbitrage Protection
If SOR posts orders on multiple exchanges simultaneously, price moves between sends — one exchange may have stale price. This is latency arb risk.
Mitigation:
- Simultaneous order sends to all exchanges (parallel execution)
- Timeout for each order
- Fallback: if order on one exchange unfilled — reallocate to others
Balance Management
SOR requires funds on each exchange. Automatic balance management:
- Monitor balances across all exchanges
- Auto-replenish via transfers (accounting for confirmation time)
- Reserve minimum balance on each exchange
Liquidity Aggregator
For DEX markets, SOR implemented in protocols 1inch, Paraswap, Cowswap — they aggregate liquidity from multiple DEX. For CEX, analog — custom implementation combining liquidity from multiple centralized exchanges.
DeFi SOR: smart contract splits swap into parts, routes best paths via Uniswap v3, Curve, Balancer. 1inch v5 uses exactly this approach.
Monitoring and Benchmarking
Execution quality score: actual average price vs theoretical (if took best price on one exchange). SOR should provide savings.
Fill rate: % of executed volume to requested.
Latency breakdown: time at each stage — merge order books, calculate allocation, send orders.
Technical Stack
Python (asyncio for parallel exchange requests), CCXT Pro (WebSocket for realtime order books), Redis for order book caching, PostgreSQL for execution logs. API interface for integration with trading systems and bots.
Develop SOR system supporting 5–10 major CEX, accounting for fees and slippage, parallel execution, detailed execution analytics.