Skip to main content

Architecture

Rollup Settlement Model​

This orderbook runs as a rollup execution layer:

  • Matching is executed offchain for low-latency trading.
  • The rollup posts proofs and full state commitments directly to VSL every 2 blocks.
  • Settlement and downstream consumers can verify state progression from onchain commitments.

This design is what enables high-throughput matching without trading off decentralization.

High-Level System Layers​

  • Trading interface: The public trading API where clients place orders, cancel orders, manage balances, and request withdrawals.
  • Execution layer: The matching system that validates orders, enforces market rules, and computes state transitions.
  • Query layer: Read-optimized APIs for order history, open orders, and user-facing market views.
  • Market data layer: Public REST and WebSocket surfaces for depth, trades, and candles.
  • Settlement layer: The Virtual Settlement Layer, where proofs and full state commitments are published for verification.

High-Level Request Flow​

What API Users Need to Know​

  • Writes and reads are intentionally separated: trading requests go through the execution path, while order history and market views are exposed through read-optimized APIs.
  • Market data and order-history endpoints are projections of the execution state, so they may lag the trading response briefly.
  • Onchain publication to VSL is the public verification boundary for the rollup state.

Public Surface Mapping​

NeedUse
Place or cancel tradesEngine API
Fetch open orders or order historyOMS API
Fetch depth, trades, or klinesMarket Data API
Understand final settlement guaranteesLiquidity Consensus Layer

Integration Implication​

  • Use the trading API for actions that change state.
  • Use OMS for user-facing order query views.
  • Use market-data for charting and live depth or trade streams.
  • Treat VSL posting cadence (every 2 blocks) as the verification boundary for rollup state commitments.