Hyperliquid L4 order book reconstruction requires more than tracking orders by ID.
A correct state machine must distinguish snapshots from incremental updates, resting orders from contingent children, and order-level events from reconciliation or lifecycle state. CoinAPI's book_l4 feed provides the order-level and lifecycle context needed to maintain this state in real time.
Start from the full snapshot, maintain individual order state, process updates in sequence, separate contingent orders from executable liquidity, and rebuild after a reconnect or sequence gap.
A production L4 consumer can follow a simple state model:
Full Snapshot
↓
Build Order State
↓
Apply Incremental Updates
↓
Track Parent/Child Lifecycle
↓
Project Executable Depth
↓
Validate the BookSome records describe contingent orders, lifecycle events, or structural context around another order.
An is_snapshot=true message establishes a new authoritative book state.
When it arrives:
After a reconnect, rebuild from a new full snapshot rather than continuing the previous connection's state.
A missing incremental sequence also requires recovery when the next message is not itself a new full snapshot.
For full snapshots, current executable liquidity can generally be identified by four signals:
| Signal | Expected state |
|---|---|
| Placement | Top-level bid or ask |
| Size | Positive |
| is_child | False, null, or absent |
| is_trigger | False |
This is more reliable than filtering by order_type.
For example, a Stop Limit, Stop Market, or Take Profit Limit order can become executable after triggering while retaining its original order-type label.
Snapshot orders also do not necessarily contain update_type or hl4_status. Their absence does not prevent a valid top-level, positive-size, non-child, non-trigger order from representing resting liquidity.
Hyperliquid can represent TP/SL instructions as children of a parent order.
Resting Parent
├── Take Profit Child
└── Stop Loss ChildThe parent may contribute to current market depth.
Contingent children do not.
They should be tracked for lifecycle analysis, but adding them independently to bids or asks can overstate available liquidity.
Parent and child representations can share the same numeric ID.
Use structural placement and is_child to distinguish them rather than maintaining a simple global map based only on:
order_id → orderFor some contingent legs, the feed may not provide a durable per-leg identifier. Fields such as order_type, trigger_px, and trigger_condition can help correlate events, but they should not be treated as guaranteed permanent identity keys.
When identity cannot be determined reliably, preserve the state as unresolved rather than infer it.
For normal order-level updates, reconstruction logic should be simple:
SET → add or replace
DELETE → remove if present
REJECTED → informational; do not add to depthA DELETE for an order that is already absent is a safe no-op.
Similarly, a SET for an existing order can legitimately restate its current state.
This matters because the first incremental message after a snapshot can overlap with information already represented by that snapshot.
The same principle applies later in a continuous sequence: an absent-ID DELETE by itself does not prove that data was lost.
Do not use equal timestamps to identify duplicate snapshot and delta data.
Two messages can legitimately share time_exchange or time_coinapi.
For reconstruction, use:
Identifies a new authoritative baseline.
Determines incremental update order within the connection.
This avoids dropping valid updates simply because their timestamps match.
time_exchange can also lag wall-clock time. Timestamp lag alone does not indicate a sequence gap or invalid book state.
A single message can contain multiple lifecycle events for the same order:
SET / OPEN
↓
DELETE / CANCELEDApply records in the order delivered and validate the resulting book after the complete message.
Checking the book after every individual record can produce false duplicate, missing-order, or crossed-book signals from temporary intermediate states.
After the complete message is applied, validate the reconstructed state. If the resulting book is crossed or structurally incomplete, discard that connection generation and rebuild from a new full snapshot.
On normal incremental messages, a top-level parent should contain lifecycle information such as update_type and hl4_status.
If an incremental parent appears with neither field, do not interpret its presence as an order-book operation.
Instead:
Leave resting state unchanged.
Do not infer a lifecycle event.
Preserve if needed for replay or diagnostics.
Do not infer a child SET, PENDING, or other lifecycle transition from that object.
Update child lifecycle only when a normal incremental event or a later full snapshot provides the required state.
The current Hyperliquid book_l4 incremental contract is based primarily on set, delete, and rejected.
Residual add and sub operations can still appear, but they should not be interpreted as anonymous price-level size adjustments.
For the current residual encoder behavior:
SET or ADD → this ID's resting size is now X
DELETE or SUB → this ID is goneApply them per order ID and in delivered order.
For example, an add immediately followed by a delete for the same ID results in no resting order.
Their appearance alone does not require a reconnect, and they should not be combined as aggregate price-level deltas.
For production systems, keep the reconstruction pipeline explicit:
CoinAPI book_l4
↓
Raw Events
↓
L4 State Machine
↓
Current Order State
↓
Executable Depth
↓
Validation
↓
Research / Trading ModelsKeeping raw events separate from reconstructed state makes the system easier to replay, test, audit, and debug.
It also prevents interpretation logic from destroying information that may be useful later.
For systems where reconstruction correctness matters, retaining the connection generation, sequence, timestamps, structural placement, and lifecycle fields alongside the raw message also makes recovery and investigation much easier.
Correct reconstruction opens the door to more detailed market microstructure research, including:
CoinAPI also provides Hyperliquid trade_l4, oracle-price, TWAP-status, miscellaneous-event, and system-event feeds for adding execution and exchange context to reconstructed order-book state.
Start with a full is_snapshot=true message, build the current order state, and apply subsequent incremental updates in connection-local sequence order.
After a reconnect, start again from a new full snapshot. If an incremental sequence is missing and the next message is not a new full snapshot, resubscribe and rebuild.
No. Contingent children should be tracked as lifecycle state but should not independently contribute to executable bid or ask depth.
Yes. The first incremental message can contain SET records for orders already present in the snapshot and DELETE records for orders already absent.
Treat SET as an upsert and an absent DELETE as a no-op rather than assuming the overlap indicates lost or duplicated data.
No. Use is_snapshot and connection-local sequence for reconstruction.
Equal time_exchange or time_coinapi values do not mean two messages represent the same state and should not be used as a reason to skip an incremental update.
Yes. A triggered order can become executable while retaining its original order-type label.
Determine whether it contributes to depth from its current structural state rather than its original order type.
Not necessarily.
A full snapshot is an authoritative replacement state even if its sequence is not exactly the previous sequence plus one. If an incremental message is missing and the next message is another incremental, resubscribe and rebuild from a new full snapshot.
Apply the complete delivered message before validating the book.
If the resulting state is still crossed or structurally incomplete, discard that connection generation and resubscribe for a new full snapshot. A replacement snapshot that is itself crossed or incomplete should also be rejected.
CoinAPI provides dedicated Hyperliquid L4 data for teams building market-making systems, quantitative research infrastructure, execution analytics, and market microstructure models.
Access book_l4 for order-by-order book state and combine it with trade_l4 and Hyperliquid-native event streams when your models need deeper execution context.