UI & Market Data Display Requirements

This document defines the required UI standards, the recommended consumption architecture, and best practices for any platform integrating with the zerohash Central Limit Order Book (CLOB).

Execution model. The zerohash CLOB is an execution venue — a single exchange order book on which participants' orders rest and match directly against one another. When a platform submits an order, it executes against the liquidity resting on that book, at the price available on the book at the moment
of execution.

Liquidity scope. All liquidity is the set of limit orders resting on the CLOB, generated by a combination of both; institutional grade liquidity providers and other participants in the zerohash CLOB. The venue matches orders against its own book only, based on price-time-priority. The book delivered over market data is therefore the complete and authoritative view of what is tradable.

Platform responsibility. Platforms are responsible for how they present the book, price, and order state to their clients within the standards defined below.

Sample UI:

  • Histortical OHLCV data displayed on left.
  • Live Order Book displayed on right.


Live Market Display Requirements

Connecting to the zerohash CLOB requires Platforms to handle transparent, real time market data and charting to their end customers. Platforms will stream this data using the zerohash FIX5.0SP2 Market Data gateways, offering a Market By Order (MBO) schema for full visibility into the order that create the market.

Order book depth display

Participants must have good visibility into the market they are trading in — not just the best price, but a meaningful view of the resting liquidity around it.

⚠️

Showing only top-of-book hides the depth, shape, and true cost of trading against the book.

Platforms must display the order book using Level 2 (Market-by-Order), showing a minimum of 10 price levels per-side (10 bids + 10 asks) at all times.

  • If the book has more than 10 levels resting on a side, showing additional
    levels is encouraged — 10 is the floor, not a cap.
  • If the book has fewer than 10 levels resting on a side, display all
    available levels. You cannot show liquidity that is not resting on the book.

Formatting.

  • Bids: sorted descending (highest price first)
  • Asks: sorted ascending (lowest price first)
  • Both sides anchored at the spread.

Each displayed level must include:

FieldDefinition
PricePrice of the level
SizeResting size at that level

Market To Limit estimated price — adverse fill monitoring

If a platform displays an estimated fill price for order executions, it must:

  • Scan the live order book in real time to obtain the most accurate executable price, and
  • Warn the user before execution whenever the estimated fill will face slippage in the MTL price collar.

Order book state synchronization

Platforms consuming zerohash market data as a live fvia snapshot plus incremental updatesnot by polling a single top-of-book value.

  • Track sequence numbers on every update.
  • On any sequence gap or desync: discard local snapshot.
  • Never continue displaying a book that may be stale or incorrect.

Best practices (not required for sign-off)

Display & usability

  • Color-code sides (e.g., green bids, red asks).
  • Provide a tick-aggregation control to group levels into broader buckets.
  • Show more than the 10-level minimum where screen sa floor, not a target.
  • Highlight spread and mid prominently as the live-price reference points.

Data integrity

  • Build event-driven (snapshot + incremental) from Market Data FIX feed.
  • Fail safe on sequence gaps — drop the data and re-snapshot the order book.

Execution UX

  • Warn early when a Market To Limit estimate approaches the collar, not only at rejection.
    • Display a warning of slippages on order entry.
    • Use the full order book data to calculate an accurate indicicative price that the Market to limit order will execute at.
  • Show cumulative depth and notional at the level a they understand the true cost of a larger order.

Set client expectations

  • Make clear to your own clients that this is a single-venue CLOB. The book they see is the liquidity they trade against — not smart-routed best execution across markets.

Pre-PROD sign-off checklist

#RequirementMet?Reviewer
2.1≥10 levels/side displayed
2.2MTL estimated price scans book in real time
2.3Live price shown as mid; spread calculated and available
2.4Book maintained via snapshot + incremental updates;
3.xFeed consumed via backend gateway with authoritative book state (recommended)

Approval: Contact your platforms Solutions Engineer or Relationship Manager.



Did this page help you?