Choosing a stream

One endpoint, nine streams. Start from what your system needs — a price, fills, book state, or full microstructure — and take the narrowest stream that carries it. Narrower streams mean less bandwidth, less parsing, and lower bills.

Decision table

You needUseMethod
Just the BTC priceDedicated BTC pricehyperliquid_btc_price.v1.BtcPriceStreaming/StreamBtcPrices
A price ticker for any marketL2 Order Bookhyperliquid.OrderBookStreaming/StreamL2Book (n_levels: 1)
Fills with wallet, PnL, feesTrades / Swapshyperliquid_swaps.v1.SwapStreaming/StreamSwaps
Aggregated depth by levelL2 Order Bookhyperliquid.OrderBookStreaming/StreamL2Book
Every resting order, with ownerL4 Order Bookhyperliquid.OrderBookStreaming/StreamL4Book
Order-status eventsOrder lifecyclehyperliquid.Streaming/StreamData (stream_type: ORDERS)
Every book delta (microstructure)Raw book diffshyperliquid.Streaming/StreamData (stream_type: BOOK_UPDATES)
TWAP / large-order detectionTWAP algoshyperliquid.Streaming/StreamData (stream_type: TWAP)
Funding, liquidations, transfersEventshyperliquid.Streaming/StreamData (stream_type: EVENTS)
Raw L1 blocksBlockshyperliquid.BlockStreaming/StreamBlocks
Your existing Dwellir clientDwellir-compatible gatewayhyperliquid_l1_gateway.v2.HyperliquidL1Gateway

Price only

For BTC, use the dedicated Dedicated BTC price ticker — one message per last-trade price change, three fields, a few messages per second at most. It is the cheapest stream on the endpoint and available on both self-serve plans.

For any other market, subscribe to L2 Order Book with n_levels: 1: a snapshot, then one top-of-book update per block. Predictable rate, tiny payload.

Fills and attribution

Trades / Swaps is the richest feed: every executed fill with the trader's wallet, direction, realized PnL (closed_pnl), fee and rebate flag, maker/taker role, and TWAP linkage. This is the stream for copy-trading, flow analysis, and anything that needs to know who traded — around 6.5M fills a day across 462 markets, so filter by coins or wallets unless you want the full tape.

If you only care about order-status transitions (placed, canceled, triggered, rejected) rather than executions, use Order lifecycle — but note its volume: 725M+ order updates a day platform-wide. Server-side filters are strongly recommended.

Book state

L2 Order Book gives aggregated depth by price level (1–100 levels, guaranteed never crossed) — the right surface for quoting, spread monitoring, and execution checks. L4 Order Book gives the full order-by-order book with each resting order's owner: queue position, order ownership, and per-block diffs after an initial snapshot.

Microstructure

Raw book diffs is the lowest-level surface: every new/update/modified/remove delta on every book, in strict block order. Pair the deltas with a compatible snapshot to reconstruct the book within the connected or recently replayed range. It is also the highest-volume stream on the endpoint — filter by coin unless you genuinely need the firehose.

Everything else

  • TWAP algos — native TWAP status and execution progress; low volume, useful for large-order detection.
  • Events — funding payments with rates, liquidations, deposits and withdrawals; bursty around funding intervals and volatility.
  • Blocks — the raw L1 block stream, if you run your own decoding or verification.
  • Dwellir-compatible gateway — keep your existing Dwellir stubs and just change the endpoint.

Cross-cutting

Every stream filters server-side (by coin, and where applicable by wallet), covers all markets — perps, spot @N, HIP-3 dex:SYMBOL — and carries byte-exact decimal strings for raw financial values. Ultra can replay from a block within the last 6 hours before going live. See Filtering and Replay & backfill.