Skip to main content
L4 workflows reconstruct order-level book state from snapshots, ordered diffs, and gap signals. They require a known venue family, symbol, baseline source, ordered updates, gap policy, and recovery path. A client that cannot satisfy those requirements will produce an unreliable local book.
SnapshotStart from a checkpointPull an L4 snapshot or replay baseline for one venue and symbol.
DiffsApply updates in orderProcess ordered diffs without dropping or reordering messages.
Live bookHold current stateOn a gap event, mark the book unsafe and rebuild from a fresh checkpoint.

​
L4 Workflow

StepPurpose
Choose familyKeep Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, and Lighter separate
Get baselineStart from a snapshot or route-specific history where available
Apply updatesProcess ordered diffs without dropping or reordering messages
Detect gapsMark local state unsafe when sequence or replay gap events appear
Rebuild stateRefresh from a snapshot or replay checkpoint before trusting output
Log metadataStore route, channel, symbol, timestamps, gap events, and request IDs

​
Implementation Pattern

1

Confirm route support

Use the REST route family and OpenAPI before assuming L4 exists for a venue, symbol, or plan.
2

Start with one symbol

Confirm the local book can process a small stream before widening to more markets.
3

Separate UI from book state

Drop or throttle noncritical UI updates before dropping book events.
4

Stop on unsafe gaps

If the book misses ordered events, mark it unsafe and rebuild from a known baseline.

​
L4 State Checklist

Capture this checklist before claiming a client maintains an L4 book.
FieldCapture
Venue family and symbolCore, Spot, HIP-3, HIP-4, or Lighter-specific context
Baseline sourceREST snapshot, WebSocket snapshot, checkpoint route, or replay snapshot
Update sourceLive diffs, replay messages, REST history, or SDK iterator
Ordering ruleSequence field, timestamp ordering, cursor, or replay order
Gap responseMark unsafe, stop output, rebuild, or rerun the bounded window
Storage labelL2, L3, L4, current, historical, replayed, or reconstructed

​
REST And WebSocket Together

Use REST when you need point snapshots or bounded historical L4 records. Use WebSocket for live updates or replay when event order matters. A production L4 client often uses both: REST or replay for baseline and recovery, WebSocket for live state, and data-quality routes for trust decisions. Do not collapse L4 into a generic “orderbook” label in storage. Store whether the data is L2, L3, L4, current, historical, replayed, or reconstructed. That distinction matters for backtests, visualizations, alerting, and customer-facing products.

​
Next Step

Open WebSocket channels, WebSocket replay, SDK reconstruction, and the relevant REST family before implementing a local book.
Last modified on June 28, 2026