Skip to main content

​
Separation of Matching and Settlement

Silvana Orderbook separates execution (order matching) from settlement:
  • Execution (Order matching) runs off-chain in a private matching engine. No orders or depth are exposed to the public.
  • Settlement runs on-chain on Canton using Delivery-versus-Payment (DvP), so asset transfer and payment are atomic.
Agents and clients never perform matching themselves; they submit orders and consume events. The Orderbook service does the matching and then drives the settlement flow via the coordination layer.

​
Participants and the Orderbook API

Participants (or their agents) talk to the Orderbook over the Silvana API, typically through the orderbook client. The API is defined by the Orderbook protocol and implemented as a gRPC service. The client uses a JWT for authentication and a Transport (e.g. Node or web) to send requests and receive streams. From the client’s perspective, execution revolves around:
  • Submitting and cancelling orders: e.g. submitOrder, cancelOrder.
  • Reading book and orders: e.g. getOrderbookDepth, getOrders, getOrderHistory.
  • Subscribing to real-time updates: e.g. subscribeOrderbook, subscribeOrders, subscribeSettlements.
Execution is event-driven: agents place/cancel orders and react to orderbook updates, order state changes, and settlement events.

​
Order Submission and Matching Flow

  1. Submit orders
    A participant (or agent) calls the API to submit an order for a given market, with order type (e.g. limit/market), price, quantity, time-in-force, optional expiry, and optional trader order ref and signature/nonce for authentication and replay protection. Orders are sent to the Orderbook service over the authenticated channel.
  2. Private matching engine
    The Orderbook service holds a private order book per market. Its matching engine runs off-chain: it takes incoming orders, matches them against resting bids and asks according to price-time (or other configured) rules, and produces fills and trades.
This is where execution happens, it is not visible to the public!
  1. Optimistic execution outcome
    When orders match, the system produces an optimistic state: the trade is considered executed from the participant’s perspective. Order state (e.g. open, filled, partially filled, cancelled) is updated and exposed via the API and streams.
Agents can subscribe to order updates and orderbook depth to stay in sync and react to fills without polling.
  1. Settlement proposals and DvP
    Matched trades are not settled on-chain immediately. The coordination layer turns them into settlement proposals and runs the Delivery-versus-Payment (DvP) workflow on Canton. Participants can query settlement proposals and settlements via the API and subscribe to settlement updates to know when proposals are created and when settlement is final.
Orders are scoped by market and carry order type, price, quantity, time in force, and optional expiry. The client uses the same JWT for all calls; the backend associates orders and streams with the authenticated party.
Agents do not match orders! They submit them and subscribe to orderbook, order, and settlement streams. The Orderbook service performs matching and hands off to the coordination layer for DvP settlement.