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.

L4 order-book streams are about order-level reconstruction behavior, not a generic channels list. L4 workflows are stricter than simple quote streams. They need a known venue family, symbol, baseline, ordered updates, gap policy, and recovery path. If the client cannot show those pieces, it should not claim to maintain a trustworthy local book.

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 Packet

Capture this packet 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 robust 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 May 18, 2026