L4 Order Book

The L4 book is the microstructure surface: every resting order, attributed to its wallet. Use it when aggregated levels are not enough: queue-position models, toxicity and spoofing detection, tracking which market makers are present at which prices, or reconstructing the exact book your strategy would have seen at any block.

It is strictly more information than L2 at strictly more cost: snapshots are large and liquid markets churn constantly. If you only price against depth, stay on the L2 book and keep your bandwidth bill small.

// stream.hyperliquidrpc.com:443 — gRPC over TLS (HTTP/2)// auth: API key in x-api-key metadata · server reflection enabledpackage hyperliquid; service OrderBookStreaming {  // Complete order-by-order snapshot first, then per-block diffs.  rpc StreamL4Book (L4BookRequest) returns (stream L4BookUpdate);}

Wire-compatible with QuickNode's order-book proto. The first message is the complete book for the coin; every subsequent message is the set of order-level changes for one block.

Fields typed string that carry numbers are byte-exact decimal strings, verbatim from the node. Compare and store them as strings or arbitrary-precision decimals. Never parseFloat a price you intend to reconcile.

• coin: required, one market per subscription
• replay from a block height

Filters are applied on the server, so filtered-out messages never leave our edge. You only pay for what you subscribe to. Request shapes for every stream family are on Filtering; backfill semantics on Replay & backfill.

Snapshot + diffs: the first message is the complete order-by-order book; each block then delivers the set of order-level changes. Full snapshots can be large; set max receive size ≥256 MB.

• Apply diffs in block order, against the snapshot. NEW inserts an order, UPDATE replaces its remaining size, REMOVE deletes it by oid. Key your local state on oid and the book stays exact.
• One coin per subscription. Like the L2 book, the request takes a single coin. Subscribe per market and budget bandwidth for the liquid ones.
• On reconnect, resync from a fresh snapshot. A new subscription always begins with a complete snapshot, so the cheapest recovery from any gap is to resubscribe and replace local state. For gap-free history, replay from a height instead. See Replay & backfill.
• This is the firehose behind 725M+ order updates a day. Liquid markets produce sustained high-rate diffs. Consume on a dedicated thread/task and avoid per-message allocations in hot paths.

{  "coin": "BTC",  "block_height": 612408134,  "is_snapshot": false,  "diffs": [    {      "type": "NEW",      "order": {        "oid": 91834221299,        "user": "0x2f8a91be6cda04417e3c50f1a7b9d20c1e664b07",        "side": "A",        "px": "67018.0",        "sz": "0.75000"      }    },    { "type": "REMOVE", "oid": 91834219841 }  ]}

High volume on liquid markets. This is the full order flow behind 725M+ order updates/day, so budget bandwidth accordingly or filter to specific coins.

• Raw book diffsThe same order-level deltas across many coins via StreamData.
• L2 order bookAggregated levels when you don't need owners or queues.
• Replay & backfillReconstruct the book at a past block, then continue live.
• Operations guideReconnect strategy, DATA_LOSS handling, and message-size limits.