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.

Raw financial fields typed string preserve their decimal representation from the node. Store them as strings or arbitrary-precision decimals. Calculated fields, including aggregated book sizes, are identified by their field notes.

• coin: required, one market per subscription

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 a gap is to resubscribe and replace local state. StreamL4Book itself does not accept a replay height.
• 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 & backfillReplay raw book diffs from a retained checkpoint on Ultra; StreamL4Book itself is live-only.
• Operations guideReconnect strategy, DATA_LOSS handling, and message-size limits.