> ## 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.

# WebSocket Limits

> Size 0xArchive WebSocket subscriptions, replay jobs, and reconnection behavior.

WebSocket limits depend on your plan, channel mix, replay speed, and the amount of data a symbol emits.

## Client Rules

<Steps>
  <Step title="Keep subscriptions explicit">
    Subscribe only to the channels and symbols the job needs.
  </Step>

  <Step title="Bound replay windows">
    Split long replays into windows that can be resumed and audited.
  </Step>

  <Step title="Avoid reconnect storms">
    Use capped backoff and jitter after disconnects.
  </Step>

  <Step title="Track gaps">
    Treat gap messages as data-quality events and decide whether the downstream job can continue.
  </Step>
</Steps>

<CardGroup cols={2}>
  <Card title="Rate limits" icon="gauge" href="/rate-limits">
    REST and account-level limit model.
  </Card>

  <Card title="Reliability guide" icon="shield-check" href="/guides/reliability-and-gaps">
    Handle data gaps and freshness checks.
  </Card>
</CardGroup>

## Sizing A Stream

A stream's effective cost is a function of symbol count, channel count, venue activity, replay speed, and downstream processing. Start with one symbol and one channel, then widen only after the consumer can keep up without message drops. If a replay job is meant to produce research output, record the window, speed, channel list, and gap events with the resulting file.

## Limit Review Packet

Use this packet before increasing channel count, replay speed, or connection count.

| Field             | Capture                                                                                |
| ----------------- | -------------------------------------------------------------------------------------- |
| Mode              | Live subscription, replay, L4 reconstruction, dashboard stream, alert, or backtest     |
| Venue family      | Hyperliquid core, Spot, HIP-3, HIP-4, or Lighter                                       |
| Channel set       | Exact channel-symbol pairs or replay channel list                                      |
| Account envelope  | Plan, subscription count, replay speed, credit budget, and concurrent replay behavior  |
| Consumer capacity | Queue depth, processing lag, dropped UI updates, output write rate, and memory ceiling |
| Recovery policy   | Retry budget, reconnect backoff, resubscribe list, gap response, and rebuild path      |
| Stop trigger      | Lag threshold, gap state, storage failure, auth failure, or data-quality failure       |

The packet keeps a limit request tied to the client that has to consume the messages. A higher plan limit does not fix a consumer that drops messages or cannot write replay output in order.

## Backpressure

Clients should protect themselves from message bursts. Use bounded queues, drop or pause noncritical UI updates when necessary, and stop replay rather than letting memory grow without limit. A replay that cannot be consumed in order is not a trustworthy replay.

## Plan Interaction

Account limits can affect both REST and WebSocket use. If a workflow mixes REST preflights, WebSocket replay, and SDK reconstruction, budget them as one job instead of independent scripts. Pair this page with [Rate Limits](/rate-limits) and [Data Quality](/data-quality) before deploying shared tooling.

## Review Rule

Before raising subscription count or replay speed, verify consumer lag. A WebSocket job that receives data faster than it can process will eventually produce stale UI state, dropped messages, or incorrect local books.

Limit decisions should be documented near the consumer, not hidden in a connection helper.

Track replay speed separately from live subscription count.

They stress different parts of the client.

Live subscriptions stress steady-state consumers. Replay stresses backlog, ordering, storage, and gap handling. Size and observe them separately.