SOC 2 Type II-gecertificeerd · ISO 27001

On June 9, 2026, Hyperliquid's core team announced that several public WebSocket API feeds will push data less frequently after the next network upgrade. On June 11, 2026, the team adjusted the rollout based on user feedback: webData2 will keep its current 5-second push interval for one more network upgrade, standard l2Book will move to 20 levels every 2 seconds before a later move to 5 seconds, and a new fastAssetCtxs WebSocket feed will preserve 5-second mark price diffs for interfaces.

The affected feeds still include order book depth, mid prices, asset context, all DEX asset context, and webData2, which is still expected to migrate to webData3.

For dashboards, portfolio monitors, and human-facing views, the new intervals may be acceptable. For automated trading systems, they change the data model. A strategy that quotes, sizes, cancels, or routes orders from public WebSocket snapshots now needs a different data plane.

Hyperliquid's team was direct about the expected path for this workload:

This post explains what is changing, why it matters for bots, and how to move latency-sensitive Hyperliquid workloads to managed infrastructure with Quicknode.

What changed in Hyperliquid's public WebSocket API?

De l2Book change is the most important for automated strategies. Without fast: true, the public API returns 20 levels every 2 seconds after the next upgrade, with a later move to 5 seconds expected. With fast: true, it returns 5 levels every 0.5 seconds. Neither option provides a full, real-time book for strategies that depend on depth, queue behavior, or fast spread changes.

This is not an outage or a breaking change in the usual sense. It is a line between shared public infrastructure and the data profile needed by automated trading systems.

Why do slower WebSocket updates matter for trading bots?

A bot does not experience a stale book as an inconvenience. It experiences it as incorrect input.

Market makers need current depth to quote around live inventory and spread. Execution bots need current mids and book pressure to size orders. Liquidation, arbitrage, and basis strategies need the difference between the last snapshot and the current block to be as small as possible.

When a book updates on a 2-second or 5-second cadence, the strategy is not just behind by that interval. It is acting on a different market state. That affects:

• Quote placement and cancellation timing

• Spread, slippage, and adverse selection calculations

• Position sizing and risk checks

• Liquidation and funding monitors that trigger orders

• Backtests that assume a data feed similar to production

The public API can still make sense for UI, passive monitoring, and non-critical display data. Trading logic that depends on current depth needs a feed designed for it, whether that's a WebSocket subscription or a gRPC stream.

What does Hyperliquid recommend for automated traders?

Hyperliquid's guidance is to run a non-validating node for more levels or real-time update streams. That gives automated traders direct access to the data profile they need, but it also introduces infrastructure work: node operations, upgrades, monitoring, reconnect handling, capacity planning, and client integration.

Quicknode is a blockchain development platform that provides managed Hyperliquid infrastructure across HyperCore and HyperEVM through a single endpoint. Both WebSocket and gRPC are supported on every Hyperliquid endpoint. For teams affected by this public API change, the most relevant capability is HyperCore gRPC streaming. Not because WebSocket is the wrong tool, but because we see where WebSocket gets brittle at scale: reconnect storms, package-driven stream fragility, and payload overhead on multi-market subscriptions.

Quicknode's Hyperliquid docs list gRPC support across the full set of HyperCore data streams, with bidirectional streaming, sub-millisecond latency for market data, and native zstd compression that can reduce bandwidth by about 70%. Access to /hypercore JSON-RPC, /hypercore WebSocket, and HyperCore gRPC requires the Build plan or higher.

Start with the Quicknode Hyperliquid docs and the Hyperliquid gRPC Streaming API reference.

Which HyperCore datasets should automated traders use?

The key difference is not just a private endpoint. It is access to HyperCore datasets that fit automated trading workloads.

Quicknode's Hyperliquid datasets cover executed trades, order lifecycle events, book updates, TWAP execution data, account and balance events, HyperCore to HyperEVM writer actions, raw blocks, L2 order book snapshots, L4 order book snapshots and diffs, and testnet mempool transactions.

That matters because the right replacement for a public WebSocket feed depends on what the strategy is doing. A market maker needs different data than a liquidation monitor, and a dashboard needs different data than an order router.

StreamL2Book for current price-level depth

StreamL2Book delivers a full aggregated L2 order book snapshot every block. Each message includes current bids and asks by price level, with total size and order count at each level.

Gebruik StreamL2Book when your strategy needs current depth by price level without building a local book from incremental diffs. The stream supports configurable depth, with n_levels up to 100, plus optional price bucketing for broader aggregation.

Compared with a public l2Book feed that pushes 5 levels every 0.5 seconds or 20 levels every 2 seconds before a later move to 5 seconds, this is the cleaner fit for market making, spread monitoring, depth-aware execution, and book-driven alerts.

StreamL4Book for individual order-level state

StreamL4Book delivers the order book at individual order granularity. On subscribe, it sends a full snapshot of resting bids and asks. After that, it sends per-block diffs.

Gebruik StreamL4Book when aggregated price levels are not enough. Examples include queue analysis, order-level liquidity studies, market microstructure research, and systems that need to track individual resting orders rather than only price-level totals.

StreamL2Book en StreamL4Book are gRPC-only. They are not available through WebSocket or JSON-RPC.

How should teams adapt Hyperliquid bots to the new cadence?

You do not need to move every Hyperliquid integration at once. Start by separating decision inputs from display inputs.

1. Classify each subscription.

   Feeds that trigger orders, cancellations, sizing, or risk limits should move first. Feeds that power dashboards, user-visible charts, or passive monitoring can often stay on WebSocket.

2. Replace public l2Book for trading decisions.

   Gebruik StreamL2Book if your strategy needs price-level depth, top-of-book freshness, or spread calculations. Use StreamL4Book if it needs individual order state or queue-level detail.

3. Design reconnect behavior around the stream model.

   With StreamL2Book, each message is a full L2 snapshot for that block, so your consumer can replace local price-level state with each update. With StreamL4Book, initialize from the snapshot, apply diffs, and reset from a fresh snapshot on reconnect.

4. Keep execution, analytics, and alerts on separate paths.

   A common production pattern is gRPC for the strategy's live market data, the Hyperliquid trading API or SDK for locally signed orders, JSON-RPC for batch and historical reads, Streams or Webhooks for asynchronous event pipelines, and SQL Explorer for research or investigations.

5. Run both feeds during the transition.

   Before the network upgrade, run your existing public WebSocket consumer next to the new gRPC consumer. Compare book age, observed spread, update gaps, fill quality, and any strategy-specific risk metric. This gives you a concrete cutoff plan instead of a last-minute endpoint swap.

What other Quicknode tools support Hyperliquid trading systems?

gRPC should be the first place to look for latency-sensitive HyperCore market data, but it does not need to carry every workload.

• WebSocket is available on every Hyperliquid endpoint. It still powers browser dashboards, portfolio views, monitoring surfaces, and any trading workload where the update profile matches the strategy.

• JSON-RPC can handle backfill, batch block reads, portfolio state, clearinghouse state, and HyperEVM contract interaction.

• Streams and Webhooks can push filtered events into backend systems and alerting pipelines.

• SQL Explorer can query 500B+ indexed rows of Hyperliquid data and expose queries as programmable REST endpoints.

Quicknode's Hyperliquid chain page also lists 99.99% uptime SLA, 6B+ Hyperliquid API requests per month, and 500B+ rows of queryable data. Those numbers matter when the workload is not a demo, but an always-on trading system.

How do you get started with Hyperliquid gRPC?

1. Create a Quicknode account at quicknode.com/signup.

2. Create a Hyperliquid endpoint from the Quicknode dashboard. One endpoint provides managed access across HyperCore and HyperEVM.

3. Review the available Hyperliquid datasets and map each strategy input to the stream it needs.

4. Use the Hyperliquid gRPC Streaming API docs to connect your consumer.

5. Choose the stream that matches your strategy: StreamL2Book for aggregated price-level depth, StreamL4Book for individual order-level state, or the standard datasets for trades, orders, events, and book updates.

6. Clone the HyperCore gRPC examples repo to test subscriptions in JavaScript, Python, Go, or Rust.

7. Review working examples in the Hyperliquid guide library and sample app library.

Hyperliquid's public API update is a signal that the network is moving shared endpoints toward lighter, broader access patterns. Automated traders need a different path: current depth, more levels, real-time streams, and infrastructure built for always-on systems.

Quicknode provides the managed path to that setup without running the node infrastructure yourself.

Start with the Quicknode Hyperliquid docs.