Analyzing Hyperliquid Order Book Depth for HFT Signal Generation

Hyperliquid's on-chain order book gives you something rare in crypto: a fully transparent, low-latency L2 feed with deterministic fill semantics. If you are building HFT or market-making logic, the order book depth stream is the primary raw material — not price, not trades, not funding. Everything useful derives from the queue.

Connecting to the L2 Feed

Hyperliquid exposes order book data through two surfaces: a REST snapshot endpoint and a WebSocket subscription. The REST call to https://api.hyperliquid.xyz/info with body {"type": "l2Book", "coin": "BTC"} returns a full depth snapshot — typically 20 levels on each side — with prices and sizes as strings. For production use you open a WebSocket to wss://api.hyperliquid.xyz/ws and subscribe with:

{"method": "subscribe", "subscription": {"type": "l2Book", "coin": "BTC"}}

Updates arrive as full snapshots on each change, not as deltas. This is a meaningful design choice: you never have to reconcile a missed delta message, but you will push more bytes per update than an incremental feed. At peak volatility on BTC-PERP you can see 50-80 updates per second. Budget your parsing time accordingly — use a zero-copy JSON parser or a binary shim if latency matters.

Bid-Ask Imbalance as a Short-Horizon Predictor

The single most useful signal you can derive from depth is bid-ask imbalance (BAI). Define it as:

BAI = (bid_volume_N - ask_volume_N) / (bid_volume_N + ask_volume_N)

where N is the number of levels (or a notional dollar depth). A BAI near +1 means aggressive buying pressure; near -1 means supply is stacking up. Empirically on Hyperliquid perpetuals, a 5-level BAI above 0.4 persists on average for 200-400 ms before mid-price reverts or confirms — long enough to trade into but not so long that a simple momentum entry captures it cleanly.

The critical implementation detail: weight levels by their distance from mid. Level 1 carries far more predictive weight than level 5. A common weighting is w_i = 1 / (i * tick_size * 10) — linear decay normalised by tick. Flat weighting overestimates the signal from resting iceberg orders deep in the book.

Queue Position and Fill Probability

For market-making you need to estimate fill probability conditional on queue position. Hyperliquid does not expose queue position directly — you infer it from the size at each level and the timestamp of your resting order relative to the level's first appearance in the feed.

A practical approximation: when your order joins a level, record the total size at that level at entry (Q_entry). As the level drains, your expected position in queue is Q_entry - (Q_entry - current_size) under FIFO assumptions. The fill probability at any moment is roughly 1 - (remaining_queue_ahead / Q_entry) — simple, but it gives you a number you can threshold. Below 30% remaining ahead, cancel risk drops enough to widen your quote; above 70%, you are deep in queue and should consider repricing.

This matters most on Hyperliquid because the matching engine is fast enough (~20 ms end-to-end from order placement to fill confirmation) that stale queue estimates compound into bad inventory decisions.

Mid-Price Momentum from Book Pressure

Mid-price momentum derived from order book pressure is distinct from trade-based momentum. The weighted mid-price is:

wmid = (ask_price * bid_size_1 + bid_price * ask_size_1) / (bid_size_1 + ask_size_1)

This micro-price leans toward the side with more size at the touch, anticipating where fair value is likely to settle. A rolling 500 ms exponential moving average of wmid - mid gives you a pressure indicator that leads trade momentum by one to two ticks on most Hyperliquid pairs.

Stack this with BAI: when BAI is directionally aligned with wmid pressure, signal quality improves meaningfully. When they diverge, it usually means a large passive order is absorbing flow — flatten inventory fast.

Latency Floors and the Cost of Python

Running the above signals in Python with asyncio is fine for research and modest throughput. In production, the bottleneck is usually JSON parsing and dict allocation, not network. On a co-located or well-peered machine you will see WebSocket messages arrive in 3-8 ms from Hyperliquid's matching engine. Parsing a 20-level book in pure Python adds another 0.5-2 ms depending on implementation. At 50 updates/second that is acceptable; at 300/second it is not.

The practical upgrade path is Rust or Go for the hot path, with the signal logic compiled and the Python trading logic calling into it via a shared memory ring buffer or ZMQ. You get sub-millisecond parse times and can dedicate Python to decision logic where the latency budget is looser.

Signal Decay and Recalibration

None of these signals are stationary. BAI predictiveness on BTC-PERP shifts with funding rate regime and open interest dynamics. What works at 0.01% funding may produce noise at 0.08%. Build in a rolling calibration loop — every 4-6 hours, recompute the BAI threshold and wmid sensitivity against realized mid-price moves. The parameters are not precious; the infrastructure to update them quickly is.

Queue depth predictiveness also degrades during high-volatility windows when market orders dominate and passive depth evaporates. A simple volatility gate — pause fill-probability-based quoting when 30-second realized vol exceeds a multiple of the median — prevents the worst adverse selection events.

---

If you want this stack built, tested, and running in production on Hyperliquid, talk to us — we ship these systems end to end.