Operational Notes

This section describes production behavior that clients should account for when integrating with Hyperliquid Data Stream.

Ordering

Within a single coin, order book diffs are delivered in the same order as they are produced by the node.

Ordering is not guaranteed across different coins.

Ordering is also not guaranteed across different stream types, including:

Blocks
Order book diffs
Mempool transactions
Metrics
Pings

If a client needs to correlate events across streams, it should use timestamps.

Reconnection

Treat every disconnect as a full reset.

Hyperliquid Data Stream does not support session resume.

After reconnecting, the client should repeat the full connection sequence:

connect
→ esp
→ prime
→ subscribe to required coins and streams
→ continue reading frames

Example reconnect sequence:

{"method":"esp","version":1}
{"method":"prime"}
{"method":"subscribe","coin":"BTC"}
{"method":"subscribe","stream":"mempool"}

Clients should not assume that previous subscriptions are preserved after reconnecting.

No backfill

Hyperliquid Data Stream is a live-only stream.

Data emitted before a client connects is not replayed.

Historical backfill is not part of this service.

If a client disconnects, any data emitted during the disconnect window is missed.

Clock skew

The following timestamps are provided by the Hyperliquid node, not by Hyperliquid Data Stream:

ts_ms
wall_ts_us
receive_ts_us

If the client’s local clock differs from the node clock, latency calculations against the local clock may look skewed.

For latency analysis, prefer differences between server-stamped fields instead of comparing server timestamps against the local client clock.

Backpressure

Clients must continuously read from the WebSocket connection.

If a client cannot keep up with the stream, the server may disconnect it.

Block frames are strict. Missing a block frame disconnects the client immediately.

Other frame types tolerate brief slowdowns, including:

Order frames
Metric frames
Ping frames
Error frames

Persistent slowness still results in disconnection.

Close code	Reason	Cause
1013	`backpressure`	Client is not reading fast enough
1001	`server shutting down`	Server restart or deploy

If the server closes the connection because of a restart or deploy, the client should reconnect after a short delay and repeat the full connection sequence.

Clean shutdown

A clean client-initiated close is safe.

The recommended flow is:

Send a WebSocket Close frame.
Wait for the server’s Close response.
Close the local connection.

Recommended client behavior

Production clients should follow these rules:

Use binary mode for production.
Always send esp before prime.
Re-subscribe after every reconnect.
Read continuously to avoid backpressure.
Do not rely on session resume.
Do not expect historical replay.
Correlate cross-stream events using timestamps.
Use server-stamped timestamp differences for latency analysis.
Handle structured error codes programmatically.

Recommended production sequence

1. Connect to ws://<host>:<port>
2. Send {"method":"esp","version":1}
3. Send {"method":"prime"}
4. Subscribe to required coins
5. Subscribe to mempool, if needed and available
6. Continuously read and decode frames
7. On disconnect, reconnect and repeat from step 1

Example:

{"method":"esp","version":1}
{"method":"prime"}
{"method":"subscribe","coin":"BTC"}
{"method":"subscribe","stream":"mempool"}

This flow should be treated as the default integration pattern for production clients.