Smart Order Routing

The Smart Order Router (SOR) is the execution engine behind POST /v1/parent_orders. It routes each order across connected venues to minimize expected all-in cost, not just displayed price.

Note

Plain English: SOR tries to get you the best final fill after fees, slippage, and execution risk, not just the best top-of-book quote.

How SOR Works

When you submit an order, SOR runs this pipeline:

Candidate Selection

SOR keeps only venues that pass eligibility checks for your order: symbol support, connected edge, valid credentials, and sufficient balance.

Per-Level Cost Scoring

SOR scores venue book levels using a cost model that includes slippage, latency risk, and fees. Newer routing versions also include freshness, reject, adverse-selection, and venue-impact terms.

Depth Sweep Allocation

Allocation is produced by a greedy depth sweep (heap-based), not a convex solver. The router consumes the best-scored levels across venues until target quantity is reached.

Risk + Min-Size Enforcement

Venue-level minimum quantity and notional constraints are enforced. Dropped residual allocations may be absorbed into surviving venues if headroom exists.

Child Dispatch + Monitoring

Child orders are sent to venue edges, fills are aggregated, and order status streams update in real time.

What Cost Means

SOR optimizes expected execution cost in basis points (bps). 1 bps = 0.01%.

Current objectives:

Routing V1: book slippage + latency risk + freshness penalty + fees
Routing V2/V3: V1 terms + adverse selection + reject penalty + venue impact

This is why the best quoted price is not always selected: SOR routes to the best expected net execution outcome.

Routing Versions (A/B)

Sequence supports deterministic A/B routing versions:

V1 baseline
V2 extended cost model
V3 adaptive routing logic

Assignment is deterministic from parent_id, so retries and analytics segmentation are stable. Each order stores its routing_version for TCA/reporting filters.

Tip

If you only care about production safety, use routing_version filters in analytics to compare V1 vs V2/V3 behavior directly.

Multi-Venue Splitting

For larger orders, SOR may split quantity across multiple venues and levels. Splitting decisions account for:

available depth per level
venue-specific fees
measured latency/risk terms
fill/reject quality signals
impact concentration risk on each venue

Example:

code

Parent order: Buy 5 BTC-USD
  -> Kraken: 3.2 BTC
  -> Coinbase: 1.8 BTC

Each split becomes a child order with independent status and fills.

Venue Selection

A venue must satisfy all of the following:

Symbol support -- the venue must list the exact trading pair
Connected edge health -- the venue edge is online and publishing data
Valid credentials -- your account has usable credentials for that venue
Sufficient tradeable balance -- enough base/quote for the order side

You can force single-venue execution by setting venue in the order request.

TCA Reporting

Completed orders include Transaction Cost Analysis (TCA) outputs:

Metric	Description
Achieved VWAP	Fill-weighted executed price
Arrival Mid	Mid price at order arrival
Implementation Shortfall	Achieved vs arrival (bps)
Savings vs Benchmark	SOR vs best single-venue benchmark
Execution Time	End-to-end time to completion
Fees + Impact Decomposition	Cost component visibility

TCA is available from:

GET /v1/parent_orders/{parent_id} (tca field when available)
GET /v1/analytics/tca* endpoints
GET /v1/tca/stream (event name tca_report)

Tip

Use notional-weighted IS and savings trends over time. A single order can be noisy; segmented aggregates are more reliable.