Who wins the World Cup?Research, stream, and trade on Hyperliquid
Learn moreHyperliquid Foundation WebSocket Changes: What It Means for You
The Hyperliquid Foundation is making changes to it's public WebSocket feeds after its next network upgrade. Here's what it means for automated traders and how to move latency-sensitive workloads to gRPC streaming with Quicknode.

June 12, 2026 — 10 min read

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:
"Automated traders should run a non-validating node for more levels or real time update streams."
This post explains what is changing, why it matters for bots, and how to move latency-sensitive Hyperliquid workloads to managed infrastructure with Quicknode.
Public API feed | New behavior after the upgrade | Operational impact |
|---|---|---|
webData2 | Stays at the current 5-second push interval for one more network upgrade. Migration to webData3 is still required. | Applications still reading webData2 have more time, but should not treat the feed as permanent. |
l2Book | 5 levels every 0.5 seconds with fast: true, or 20 levels every 2 seconds without fast: true. A later upgrade is expected to move the 20-level feed to every 5 seconds. | Trading logic must choose between shallow, faster top-of-book data and deeper, slower snapshots. |
The 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.
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.
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.
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.
Dataset | API availability | Where it fits |
|---|---|---|
TRADES | gRPC + JSON-RPC/WSS | Executed trades, price tracking, and trade analytics. |
ORDERS | gRPC + JSON-RPC/WSS | Order lifecycle monitoring, fills, cancellations, and execution state. |
BOOK_UPDATES | gRPC + JSON-RPC/WSS |
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.
Use 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 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.
Use 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 and StreamL4Book are gRPC-only. They are not available through WebSocket or JSON-RPC.
Trading need | Public WebSocket after upgrade | Quicknode path |
|---|---|---|
Fresh L2 depth | 5 levels every 0.5 seconds, or 20 levels every 2 seconds before a later move to 5 seconds | StreamL2Book full aggregated snapshot every block |
Top-of-book updates | Best approximated by l2Book fast polling every 0.5 seconds | StreamBboBook emit-on-change best bid/offer |
More than 20 levels |
You do not need to move every Hyperliquid integration at once. Start by separating decision inputs from display inputs.
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.
Replace public l2Book for trading decisions.
Use 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.
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.
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.
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.
Quicknode maintains a public HyperCore gRPC examples repository for developers building against Hyperliquid gRPC streams. The repo includes JavaScript, Python, Go, and Rust examples, with shared proto definitions, zstd decompression support, server-side filtering examples, and both mainnet and testnet endpoint formats.
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.
Create a Quicknode account at quicknode.com/signup.
Create a Hyperliquid endpoint from the Quicknode dashboard. One endpoint provides managed access across HyperCore and HyperEVM.
Review the available Hyperliquid datasets and map each strategy input to the stream it needs.
Use the Hyperliquid gRPC Streaming API docs to connect your consumer.
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.
Clone the HyperCore gRPC examples repo to test subscriptions in JavaScript, Python, Go, or Rust.
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.
Founded in 2017, Quicknode deploys institutional-grade blockchain infrastructure for developers and enterprises. With 99.99% uptime and support for 80+ chains, teams build and scale onchain applications without compromise.
The latest engineering insights, product updates, and web3 news delivered straight to your inbox.
Every 5 seconds. |
Mid-price driven logic can drift from current market state between pushes. |
spotAssetCtxs / allDexsAssetCtxs | Every 15 seconds. A new fastAssetCtxs WebSocket feed provides mark price diffs at the original 5-second interval. | Interfaces that need 5-second mark price diffs can use fastAssetCtxs; trading systems should still evaluate whether asset context belongs in the decision path. |
TWAP | gRPC + JSON-RPC/WSS | TWAP execution progress and algorithmic execution analytics. |
EVENTS | gRPC + JSON-RPC/WSS | Balances, transfers, deposits, withdrawals, vault activity, funding payments, and priority gas auction fees. |
WRITER_ACTIONS | gRPC + JSON-RPC/WSS | HyperCore to HyperEVM asset movement and bridge data. |
BLOCKS | gRPC only | Raw HyperCore blockchain data for archival systems and chain analysis. |
StreamL2Book | gRPC only | Aggregated price-level depth, with full snapshots every block. |
StreamL4Book | gRPC only | Individual resting orders, initial snapshots, and per-block diffs. |
StreamBboBook | gRPC only | Top-of-book best bid/ask, emitted only when the BBO changes. Closer fit than 0.5s l2Book fast polling. |
StreamL2BookDiff | gRPC only | Incremental L2 price-level changes with per-coin sequence numbers for efficient local order book maintenance. |
StreamL4BookUpdates | gRPC only | Typed per-order add/update/remove diffs for per-order tracking and microstructure analysis. |
StreamTpslUpdates | gRPC only | Trigger (TP/SL) order add/remove updates with open-order snapshot for stop monitoring and alerting. |
MEMPOOL_TXS | gRPC only, testnet only | Pending transactions before block confirmation on testnet. |
StreamL2Book with configurable depth up to 100 levels |
Individual order book | Not available through public WebSocket snapshots | StreamL4Book initial full snapshot plus per-block diffs |
Order lifecycle monitoring | Public feed cadence may not match execution needs | ORDERS over gRPC for fills, cancellations, and status changes |
Low-bandwidth multi-market streaming | JSON WebSocket payloads | gRPC with native zstd compression |
Historical backfill | Not the right access pattern | HyperCore JSON-RPC, including hl_getBatchBlocks for up to 200 blocks per request |