Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt

Use this file to discover all available pages before exploring further.

Channels identify the stream you want. Symbols identify the market inside that channel’s venue family.

​
Examples

ws.send(JSON.stringify({
  op: "subscribe",
  channel: "orderbook",
  symbol: "BTC"
}));

​
Unsubscribe

ws.send(JSON.stringify({
  op: "unsubscribe",
  channel: "orderbook",
  symbol: "BTC"
}));
Pick the channel family and symbol format together. A HIP-3 symbol does not belong on a Lighter channel.

​
Channel Selection

Choose channels the same way you choose REST route families. Hyperliquid core channels are for standard perp symbols such as BTC and ETH. Spot work should use Spot-specific route and stream context when available. HIP-3 channels keep the builder prefix, HIP-4 channels keep outcome identifiers, and Lighter channels stay under the Lighter family.

​
Channel Family Matrix

Use this matrix to avoid treating every WebSocket channel as the same stream.
FamilyExample channelsSymbol shapeNotes
Hyperliquid coreorderbook, trades, funding, open_interest, liquidations, l4_diffs, l4_ordersBTC, ETHCore perp channels use bare symbols. L4 channels are order-level surfaces and can require higher access.
Hyperliquid Spotspot_orderbook, spot_trades, spot_l4_diffs, spot_l4_orders, spot_twapHYPE-USDC, PURR-USDCSpot channels use pair symbols and should not be mixed with core perp symbols. Funding, open interest, and liquidations are not Spot data families.
HIP-3hip3_orderbook, hip3_trades, hip3_funding, hip3_liquidations, hip3_l4_diffs, hip3_l4_orderskm:US500, hyna:BTCPreserve the builder prefix and case. Do not normalize these into ordinary perp symbols.
HIP-4hip4_orderbook, hip4_trades, hip4_open_interest, hip4_l4_diffs, hip4_l4_orders#0, numeric side ids, or outcome-side contextPreserve outcome and side context. REST HIP-4 candles are probability-history series; WebSocket channels do not include funding, liquidation, or a dedicated candle stream.
Lighter.xyzlighter_orderbook, lighter_l3_orderbook, lighter_trades, lighter_candles, lighter_funding, lighter_open_interestBTC, ETHKeep Lighter streams under the Lighter family even when the symbol text matches a Hyperliquid market.

​
Subscription Packet

Treat every subscription as a reviewed packet, not just a channel string.
FieldExampleWhy
Venue familyHyperliquid core, HIP-3, HIP-4, LighterKeeps route semantics tied to the stream
Channelorderbook, hip3_l4_diffs, hip4_orderbook, lighter_orderbookNames the server stream
SymbolBTC, km:US500, #0Preserves family-specific symbol format
Consumerdashboard, alert, local book, replay, export writerSets throughput and gap tolerance
Stop conditionunsubscribe, close, replay stop, retry budgetPrevents abandoned streams
Store the packet with active connection state. On reconnect, restore from this packet list. On unsubscribe, remove it from the list before trusting local subscription state.

​
Common Channel Mistakes

Do not send a HIP-3 symbol to a Lighter channel. Do not strip a HIP-3 prefix before subscribing. Do not treat HIP-4 outcome identifiers as ordinary perp symbols. Do not add Spot pairs to a generic perp stream; use Spot channel names such as spot_orderbook and keep dashed pair symbols visible in code.

​
State Handling

For order books and reconstruction workflows, treat the first snapshot as the baseline and each update as an ordered change. Store channel, symbol, timestamp, and message type with local state so a replay or reconnect can show what happened. If a gap event appears, mark the local state unsafe until it is rebuilt from a fresh snapshot or replay window.

​
Subscription Hygiene

Do not subscribe to every channel by default. Subscribe to the minimum channel and symbol set for the job, then add more only after throughput and reconnection behavior are understood. A dashboard can usually tolerate fewer channels than a backtest replay, and a backtest replay usually needs stronger gap handling than a simple monitor.

​
Review Rule

Subscription code should include the inverse operation. If an example subscribes, it should also show or link to unsubscribe behavior. Long-running clients should also track active subscriptions so reconnects do not accidentally duplicate streams. Use channel names as configuration, not as unreviewed prompt text. Treat subscription state as application state and expose the active channel set in debug output so stream bugs can be inspected without reproducing the whole session.
Last modified on May 18, 2026