WebSocket replay

A replay request reads the stored records available when the request starts, emits the requested window, and completes with replay_completed. It does not continue following newly arriving events. Replay sends available historical data over the WebSocket. Standard replay paces events according to speed. Core L4 replay uses checkpoint-anchored bulk delivery and ignores speed. Check live and replay availability before choosing a channel.

Answer: Use WebSocket replay for bounded historical event order. Standard replay emits available records for the requested window; core L4 replay anchors to a checkpoint and delivers a snapshot plus ordered batches. It does not turn into a live subscription.Evidence: Verify the channel in WebSocket channels, apply the message contract from WebSocket schema, and check the selected window in Venue coverage.

All six Lighter channels support historical replay. Lighter replay returns historical_data rows in the stored Lighter shape, which differs from the live data payloads on lighter_orderbook, lighter_trades, lighter_open_interest, and lighter_funding. Parse the two separately; see Lighter WebSocket channels.Lighter on Robinhood Chain replays on its own five channels: rh_lighter_orderbook, rh_lighter_trades, rh_lighter_candles, rh_lighter_open_interest, and rh_lighter_funding, in the same stored Lighter shape. Trades replay from 2026-06-26; order books, open interest, and funding from 2026-08-22.

Single-Channel Replay

ws.send(JSON.stringify({
  op: "replay",
  channel: "orderbook",
  symbol: "BTC",
  start: 1681516800000,
  end: 1681603200000,
  speed: 10
}));

Core L4 Replay

Core L4 replay is available for l4_diffs and l4_orders. It is single-channel and uses a different delivery model from standard timed replay.

const end = Date.now() - 5 * 60_000;
const start = end - 2_000;

ws.send(JSON.stringify({
  op: "replay",
  channel: "l4_orders",
  symbol: "BTC",
  start,
  end
}));

The server anchors the run to the latest checkpoint at or before start, emits an l4_snapshot, then sends one or more l4_batch events for the requested window. For this bulk path, speed is ignored. The server-side collection, backfill, and checkpoint anchoring reduce infrastructure work; they do not remove client-side event application for a continuously updated local book. Apply each batch in order after the snapshot; a snapshot-only consumer can use the returned state directly. Bound the window and move batch processing off the message callback instead of using standard replay speed as backpressure. A core L4 request can be rejected when no usable checkpoint exists for the symbol and window. Check coverage and treat the accepted replay events as the authority rather than inferring one universal L4 start date. HIP-3, HIP-4, and Spot L4 channels are real-time only; replay requests for those L4 channel families are rejected.

Standard Multi-Channel Replay

ws.send(JSON.stringify({
  op: "replay",
  channels: ["orderbook", "trades", "funding"],
  symbol: "BTC",
  start: 1681516800000,
  end: 1681603200000,
  speed: 10
}));

Multi-channel replay should keep all channels inside the same venue family. Do not combine Hyperliquid core channels with Lighter, HIP-3, HIP-4, or Spot channels in one replay command. The two Lighter deployments are separate replay families too: rh_lighter_* channels replay together, never with lighter_* channels. Core L4 replay remains single-channel.

ws.send(JSON.stringify({
  op: "replay",
  channels: ["rh_lighter_orderbook", "rh_lighter_trades", "rh_lighter_funding"],
  symbol: "BTC",
  start: 1788220800000,
  end: 1788224400000,
  speed: 10
}));

Replay Controls

Pause, resume, and stop work for both standard replay and core L4. replay.seek is standard-only and is rejected for core L4. Core L4 bulk replay remains bounded by its requested window and does not use speed for pacing.

Pause

{"op":"replay.pause"}

Resume

{"op":"replay.resume"}

Seek

{"op":"replay.seek","timestamp":1681550000000}

Stop

{"op":"replay.stop"}

Gap Handling

ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  if (msg.type === "gap_detected") {
    console.warn("Replay gap", msg.channel, msg.symbol, msg.gap_start, msg.gap_end);
  }
};

Replay Event Flow

Replay control commands use dotted op values. Server events use underscore event names.

Event	Meaning	Client behavior
`replay_started`	Replay window accepted	Start the run manifest and record channel, symbol, start, end, and `speed` for standard timed replay. For core L4, record `delivery: checkpoint_anchored_bulk` and checkpoint metadata instead
`replay_snapshot`	Initial state for a standard multi-channel replay	Build baseline state before processing standard replay messages; single-channel standard replay starts with `historical_data`
`historical_data`	Standard replay data emitted in timeline order	Apply the message according to channel semantics and preserve timestamp
`l4_snapshot`	Core L4 checkpoint state	Initialize the order-level book before applying the bulk events
`l4_batch`	Core L4 events for a bounded part of the requested window	Process the event array in order and keep batch work off the socket callback
`gap_detected`	Missing or discontinuous interval in a stream that emits gap events	Mark the output incomplete, stop, or rebuild from a known checkpoint; for core L4, also validate batch block/order continuity
`replay_paused`	Replay paused after `replay.pause`	Keep state but stop advancing the run clock
`replay_resumed`	Replay resumed after `replay.resume`	Continue processing from the current timestamp
`replay_completed`	Replay reached the end of the configured window	Close the manifest and label the output complete, partial, or rejected
`replay_stopped`	Replay stopped by `replay.stop`	Close the manifest as stopped and keep the stop reason

Replay Design

Replay is for workflows where event order matters: backtests, local book reconstruction, incident review, data QA, and model-input regeneration. Choose the narrowest channel set that can answer the question. A single-channel order-book replay is easier to audit than a broad multi-channel replay, and a broad replay should be split into windows that can be resumed independently.

Replay Manifest

Store a manifest beside every replay output. This is application metadata, not an additional 0xArchive wire schema. At minimum record:

Field	Record
Surface	WebSocket replay
Venue family and symbol	The exact family and symbol sent to the server
Channels	`channel` for a single-channel run or the bounded `channels` list
Window	`start` and the requested `end`, or the effective end reported by `replay_started` when `end` was omitted
Delivery	`timed` for standard replay or `checkpoint_anchored_bulk` for core L4
Controls	Standard replay `speed` and any pause, resume, seek, or stop commands; omit `speed` for core L4
Baseline	`replay_snapshot` for standard multi-channel replay, or `l4_snapshot` checkpoint metadata for core L4
Gaps and terminal state	Gap events, `replay_completed` or `replay_stopped`, and whether output is complete, partial, or rejected
Code and output references	SDK package/version or direct client revision, plus the operator-controlled output location

Include replay controls used during the run. Standard replay supports pause, resume, seek, and stop. Core L4 supports pause, resume, and stop but rejects seek. If a standard replay client changes speed or seeks to a new timestamp, record that in the manifest so another run can explain the output sequence. For core L4, record delivery as checkpoint_anchored_bulk, omit speed, and retain checkpoint and batch metadata.

Window Sizing

Start with a narrow window and one channel. Widen only after the consumer can keep messages ordered, write output without backlog, and handle gaps. For long jobs, split replay into resumable windows and keep a cursor or output checkpoint between them.

Output Discipline

Store replay configuration with the output: channel list, symbol, start, end, delivery model, speed when applicable, requested venue family, gap events, and any request or correlation IDs. If a replay emits a gap, mark the derived output as incomplete or rebuild from a safe checkpoint. Do not silently interpolate missing market events.

REST Or Replay

Use REST history when you need records from a bounded window and ordering can be handled after retrieval. Use replay when the sequence itself is the product requirement: maintaining a book, testing a strategy against event cadence, or reproducing a historical stream.

Review Rule

Replay examples should include stop conditions. A safe standard replay has a bounded window, controlled speed, gap handling, and a clear output destination. A safe core L4 replay has a bounded window, a usable checkpoint, explicit bulk-batch handling, and the same output discipline. For backtests, store the replay config, replay events, and gap events beside the result so another engineer can inspect the run without reproducing the whole stream. For interface selection, compare Best WebSocket Market Data API without treating replay availability as live-channel support.

Connect

Stream

Replay

Webhooks

Single-Channel Replay

Core L4 Replay

Standard Multi-Channel Replay

Replay Controls

Pause

Resume

Seek

Stop

Gap Handling

Replay Event Flow

Replay Design

Replay Manifest

Window Sizing

Output Discipline

REST Or Replay

Review Rule

​Single-Channel Replay

​Core L4 Replay

​Standard Multi-Channel Replay

​Replay Controls

Pause

Resume

Seek

Stop

​Gap Handling

​Replay Event Flow

​Replay Design

​Replay Manifest

​Window Sizing

​Output Discipline

​REST Or Replay

​Review Rule

Single-Channel Replay

Core L4 Replay

Standard Multi-Channel Replay

Replay Controls

Gap Handling

Replay Event Flow

Replay Design

Replay Manifest

Window Sizing

Output Discipline

REST Or Replay

Review Rule