OMNITERMINAL / DOCS

Node + Data

Trader-first Hyperliquid data from an owned node and orderbook stack.

Omni operates the node, orderbook, stream, and derived-data path used to expose public trader positions, margin state, liquidation levels, L4 depth, and wallet investigation workflows.

At a glance

Delivery
Dedicated or shared Customers can use a dedicated node setup or lower-cost shared fanout with an explicit latency tradeoff.
Trader state
Positions + margin Public profiles and global views expose live positions, leverage, funding, fills, and activity.
Market depth
L4 + identity Order-level depth and per-fill maker/taker identity support liquidity and wallet investigation.

Why It Matters

What traders and researchers should take away

  • Liquidation levels are more useful when they are tied to live public position and margin state.
  • A trader profile should show current actions, positions, fills, funding, and leverage—not only historical PnL.
  • Desks and builders need a clear choice between low-latency dedicated infrastructure and cheaper shared access.

How it works

What the product uses behind the scenes

  • The consensus node and orderbook services feed stream processing and derived analytics rather than reselling a generic RPC response.
  • The public terminal API exposes stable REST and websocket contracts for browser and customer workflows.
  • ClickHouse, Kafka, and stream consumers support historical and live views while keeping private infrastructure details out of public docs.

Notes

Things to know

  • Shared fanout can have higher latency than a dedicated customer deployment.
  • Liquidation levels and margin stress are analytical views of available state, not guarantees of forced execution.
  • Public docs never expose credentials, host inventory, access headers, or private customer data.

Trader and market data products

One source path supports both terminal features and external data access.

  • All-user positions, margin use, liquidation levels, and funding state.
  • L4 order-level depth, fill identity, wallet clusters, and trader profiles.
  • REST, websocket, and fanout contracts for customer applications and research.

Dedicated setup versus shared fanout

The delivery model makes the latency and cost tradeoff explicit.

  • Dedicated customer node and data services for the lowest controlled latency.
  • Shared fanout and APIs for lower setup cost and simpler integration.
  • Public-safe documentation and observable contracts for verification.

Live streams and historical context

Stable data contracts connect low-latency market state to the history needed for analysis.

  • WebSocket streams deliver orderbook, trade, funding, position, and liquidation updates.
  • REST snapshots provide bounded recovery and historical context for terminal and customer workflows.
  • Canonical symbols and per-dex identity keep instruments consistent across live and stored data.

References

Implementation references

  • Node authority

    omni-terminal/docs/LLM_NODE_AUTHORITY.md

    Documents why Omni operates its own Hyperliquid node and the public-safe authority boundary.

  • Terminal and API architecture

    omni-terminal/docs/ARCHITECTURE_TERMINAL_API.md

    Documents the node-to-API-to-terminal contract and public route model.

  • Websocket streams

    omni-terminal/docs/WS_STREAMS.md

    Documents live stream surfaces used by price, L4, positions, liquidations, and news.

Next