Skip to main content

​
Integrate DerivaDEX liquidity into your DApp

  1. Decide whether your application needs public market depth only, user-scoped updates, or both.
  2. Bootstrap the current market and product baseline from the public REST family before opening live feeds.
  3. Subscribe to the realtime feeds that match the UI component or workflow you are building.
  4. Normalize incoming liquidity and pricing data into one application-owned state model.
  5. Reconcile that live model against periodic REST snapshots so reconnects or feed gaps do not silently drift your UI.
  6. Keep contract-facing actions, if any, separate from the market-data integration layer.

​
Choose the data path first

If your application needs…Start hereDo not assume…
current products, market metadata, or a point-in-time market snapshotREST APIREST by itself will keep a live order book synchronized
continuously updated book depth or mark priceRealtime APIthe WebSocket feed replaces initial REST bootstrap
user-scoped order, strategy, or trader updatesRealtime Connection Model plus the relevant filtered user-data feedspublic market-data subscriptions alone are enough for account reconciliation
settlement or governance transaction flowsSmart Contract Addresses and Core Contract Referencethe smart-contract layer is the primary source of live order-book liquidity

​
Build the initial market view

  1. Use REST to fetch the products and symbols your DApp intends to display.
  2. Load the latest public market snapshot your screen or service needs before opening the WebSocket.
  3. Record the symbol set, any aggregation choices, and the environment you are targeting so later reconnect logic re-subscribes to the same shape.

​
Layer realtime updates on top

  1. Subscribe to ORDER_BOOK_L2, ORDER_BOOK_L3, or MARK_PRICE according to the depth and latency requirements of the DApp view.
  2. If the application also tracks user state, subscribe separately to the filtered ORDER_UPDATE, STRATEGY_UPDATE, and TRADER_UPDATE feeds rather than mixing market and account assumptions together.
  3. Apply messages in top-level ordinal order for the active connection.
  4. Keep globalOrdinal per update family so you can reconcile one family after reconnect without cross-comparing unrelated feed types.

​
Keep the app-state model honest

  • treat REST as the initial baseline
  • treat realtime as the live-update layer
  • persist the subscription shape and the last processed ordinals
  • run periodic REST reconciliation for the views that must stay exact

​
Boundary rule

Integrating DerivaDEX liquidity into a DApp does not mean the matching engine, order book, or settlement logic is exposed as one on-chain smart-contract API. Public liquidity integration is primarily a REST-plus-realtime application-data workflow. Keep smart-contract actions separate and bind them only when the DApp truly needs on-chain reads or writes.

​
Next routes

Last modified on April 13, 2026