Architecture

System overview

Central Coordinators

Each CC handles routing logic, market data aggregation, and client-facing APIs for its region:

• REST API - processes client requests (orders, market data, credentials, algo management)
• Smart Order Router - evaluates venues and decides where to route each order
• Market Data Aggregator - merges feeds from all edges into a consolidated view (NBBO, unified book)
• Ledger - tracks order state, fills, and positions
• Algo Manager - stores WASM binaries and coordinates deployment to edges

The three CCs form a peer mesh — each CC maintains persistent connections to the other two over a private network. Market data (BBO, depth, pool state, gas prices) is mirrored in real-time between all CCs. This means an order submitted to the US CC can see Kraken prices from the EU CC and Binance prices from the AP CC, then route to whichever venue offers the best execution.

Your API requests hit any CC and get a global view — every endpoint (BBO, NBBO, order book, edges, pairs, analytics) includes data from all three regions. The response includes region and remote fields so you can see where each venue is connected.

Peer-link mesh

The CC-to-CC peer link carries:

• Market data mirroring — BBO, L2 depth, DEX pool state, and gas prices from each region's local edges are broadcast to all peer CCs
• Cross-region order routing — when the SOR determines the best venue is in another region, it sends an AllocateRemote to the target CC, which dispatches to its local edge
• Fill relay — fills from remote orders are relayed back to the originating CC for position tracking and client notification
• Balance reservations — broadcast to all CCs to prevent double-allocation across regions

The peer link uses mTLS with per-region certificates for authentication. RTT between peers is measured every 5 seconds and factored into the SOR cost model — the router automatically penalizes cross-region routes by their latency cost.

Co-located edges

Each exchange has a dedicated edge server deployed in the same region as the exchange's infrastructure. This co-location minimizes the network hop between the edge and the exchange.

Edges handle:

• Exchange connectivity - WebSocket feeds for order books and trades, REST for order submission
• WASM runtime - executes your custom algorithms directly on the edge, co-located with the exchange connection
• Local order management - rate limiting, order state tracking, and exchange-specific protocol handling

Edges communicate with their regional CC over encrypted gRPC. They have no direct external access - all client traffic goes through the CC.

Order lifecycle

When you submit an order, here's what happens:

1. Validate - the CC checks that the symbol exists, the quantity is positive, and the request format is correct
2. Risk check - the system verifies position limits, daily loss thresholds, and kill switch status before proceeding
3. SOR routing - the smart order router scores every connected venue on price, fees, available depth, and expected latency. For large orders, it calculates the optimal split across multiple venues to minimize total execution cost
4. Child orders - the parent order is split into one or more child orders, each sent to the appropriate edge server
5. Execution - each edge submits to its exchange and reports fills back to the CC
6. TCA - once complete, a transaction cost analysis report is generated showing the per-venue breakdown, total fees, and how the routing compared to a single-venue execution

Execution types

TWAP, VWAP, and Iceberg are managed by the algo scheduler and run as a series of smaller child orders over time.

Market data flow

Market data flows in the opposite direction - from exchanges to you:

Each edge maintains a local copy of the exchange's order book via WebSocket. The CC merges all venue feeds into consolidated views:

• BBO - best bid/offer per venue (human-readable floats for convenience)
• NBBO - national best bid/offer across all venues for a symbol
• Unified book - merged depth across all venues, sorted by price
• Trades - real-time trade feed from all venues

All market data carries a triple timestamp chain: when the exchange generated it, when the edge received it, and when the CC processed it. This lets you measure propagation delay at each hop.

WASM algo execution

Custom algorithms are compiled to WebAssembly and run on edge servers, co-located with exchange connections:

1. Deploy - you upload a .wasm binary via the CLI or API. The CC stores it and pushes it to the relevant edge servers.
2. Compile - the edge compiles WASM to native code once (typically under 100ms). After that, execution is near-native speed.
3. Connect - even in "stopped" state, the edge keeps WebSocket connections warm. When you start the algo, it begins receiving book updates immediately - no cold-start delay.
4. Execute - on every book update, the runtime calls your on_book() function with the current L2 order book. Your code returns actions (place order, cancel order, log), which the edge executes against the exchange.

Mesh: multi-venue algos

For strategies that span multiple exchanges (cross-venue arbitrage, spread trading, coordinated market-making), Sequence uses a mesh model: the same Algo type deployed as independent instances on different edges. Each instance:

• Runs on_book against its own venue — no extra hop to act on local liquidity.
• Optionally sees the cross-venue NbboSnapshot via on_nbbo.
• Exchanges small labeled payloads (≤256 bytes) with siblings via messaging::send(label, payload) → on_message(from, payload, …).

The CC routes mesh messages between edges: ~1–2 ms same-region, ~50–100 ms cross-region over the peer link. No central "strategy brain" — no single point of failure, no order relay.

See the Strategies & Mesh SDK guide for details.

Security model

Credential storage

Your exchange API keys are encrypted with AES-256-GCM before storage. Each client has a unique encryption key. The keys are decrypted only on the edge server that needs them to place orders - they are never logged, never exposed via API, and never visible to other components.

Non-custodial

Sequence never holds your funds. When you add exchange credentials, we recommend granting only read and trade permissions - never withdrawal access. You can revoke Sequence's access at any time from the exchange side.

Network isolation

All traffic between the CC and edge servers uses encrypted gRPC channels. Edge servers accept connections only from the CC - there is no direct external access to any edge. All client traffic is routed through the CC's REST API over HTTPS.

Latency

End-to-end latency depends on the venue and order routing path:

Local orders (edge in same region as CC):

1. Client → CC — depends on your location relative to the nearest CC
2. SOR routing — sub-millisecond
3. CC → Edge — sub-millisecond (co-located)
4. Edge → Exchange — 1-5ms (co-located)

Cross-region orders (best venue is in another region):

1. Client → CC — same as above
2. SOR routing — sub-millisecond (includes RTT penalty in cost model)
3. CC → Peer CC — 60-120ms (private network peering)
4. Peer CC → Edge — sub-millisecond
5. Edge → Exchange — 1-5ms (co-located)

The SOR automatically factors cross-region latency into its cost model. For large orders where spread savings exceed the latency cost, it routes cross-region. For small urgent orders, it prefers local venues.

Regional deployment

CEX orders complete in tens of milliseconds. DEX orders are slower because they wait for block confirmation (sub-second on Arbitrum, up to 12s on Ethereum mainnet).