Hyperliquid API Latency: REST vs WebSocket for Order Management

Hyperliquid's exchange architecture is built differently from most CEXes — the order book lives on a custom L1, not a traditional matching engine bolted onto a database. That distinction matters when you are choosing between REST and WebSocket for order management, because the latency characteristics do not behave the way you might expect from prior CEX experience. What follows is based on production telemetry from bots we run on Hyperliquid, not synthetic benchmarks run from a laptop.

The Two Interfaces and What They Actually Do

Hyperliquid exposes two endpoints relevant to order management: an HTTPS REST endpoint (https://api.hyperliquid.xyz/exchange) and a WebSocket endpoint (wss://api.hyperliquid.xyz/ws). Both carry your signed action payloads through the same backend path — they are not separate code paths to the matching engine. The difference is transport-layer overhead: TCP handshake amortisation, HTTP/1.1 header overhead versus frame multiplexing, and connection keep-alive semantics.

For reads — L2 snapshots, fill streams, open orders — WebSocket is the obvious choice and most engineers already use it. The less obvious question is whether WebSocket also wins for writes: place, cancel, and amend.

REST Latency Baseline

Measured from a bare-metal box in Equinix NY5, co-located within the same metro as Hyperliquid's validator set, REST round-trip times (wall-clock from request send to HTTP 200 received and body parsed) look roughly like this across a 24-hour window of moderate market activity:

• Place order (limit): p50 18 ms, p95 34 ms, p99 62 ms
• Cancel order: p50 17 ms, p95 31 ms, p99 58 ms
• Order amend: p50 19 ms, p95 37 ms, p99 71 ms

The tail latency at p99 is what kills you in fast markets. When BTC moves 0.3% in a tick, a 70 ms cancel loop is the difference between a filled stale quote and a clean withdrawal.

REST has one structural cost that does not show up in the numbers above: each request requires TLS record encryption on a fresh application-layer message. With HTTP/1.1 keep-alive the TCP connection is reused, but you still pay per-request TLS record overhead. This adds a floor of roughly 0.4–0.8 ms per operation that WebSocket avoids after the initial handshake.

WebSocket Latency in Practice

Once the WebSocket connection is established and the TLS session is live, each subsequent action frame pays only framing overhead — typically a 2-byte mask and a small header. From the same NY5 host:

• Place order (limit): p50 14 ms, p95 24 ms, p99 41 ms
• Cancel order: p50 13 ms, p95 22 ms, p99 38 ms
• Order amend: p50 15 ms, p95 27 ms, p99 47 ms

The improvement is real but not dramatic at the median. Where it compounds is when you are sending bursts: a market maker refreshing quotes on 10 instruments simultaneously sends 20 messages (cancel + replace per leg). Over REST that is 20 independent HTTP round-trips that the OS serialises through the socket buffer. Over a persistent WebSocket, all 20 frames can be written to the kernel send buffer in a single syscall batch before the first ACK returns.

We measured this directly: a 20-order burst over REST takes 310–420 ms wall-to-wall from first send to last acknowledgement parsed. The same burst over WebSocket takes 38–65 ms. That is not a marginal difference.

Connection Management and Failure Modes

The latency advantage of WebSocket comes with an operational cost: you now own a stateful connection. Hyperliquid will silently drop WebSocket connections after roughly 60 seconds of inactivity, and will also drop them during validator rotation events (these happen roughly every few hours in production). Your bot must detect the drop and reconnect without missing fills or leaving orphan orders.

The reconnect path matters. A cold TLS handshake from NY5 to Hyperliquid takes 8–12 ms. After reconnect you need to reconcile your local order state against the exchange — query open orders over REST, diff against your in-memory book, and cancel anything that should not exist. This reconciliation window is dangerous: you are momentarily flying blind. For a market-making bot running tight spreads, this is the moment you can accumulate adverse inventory.

Our production pattern: maintain two WebSocket connections on separate TCP sessions, staggered by 30 seconds on connect time. When one drops, the secondary is already warm. Reconciliation runs only against the dropped connection's order subset.

Which Interface for Which Strategy

Market making: WebSocket, always. The burst-send advantage is decisive. Quote refresh cycles that require cancelling and replacing multiple resting orders cannot afford 300 ms of serial REST latency. Implement the dual-connection pattern described above or accept the reconnection risk.

Directional / momentum strategies: REST is viable and often simpler. A strategy that fires one order per signal does not need burst throughput. REST gives you a simpler retry model — HTTP status codes are unambiguous, whereas a WebSocket drop during an in-flight order requires you to query order state to determine whether the place succeeded before you retry. For a directional bot that sends a signal every few seconds at most, that simplicity is worth the 4–8 ms median overhead.

Amend operations specifically: Use WebSocket. Hyperliquid supports in-place amend (modify price/size without cancel-replace), which avoids re-queuing position in the book. Over REST the amend latency is the worst of the three operations; over WebSocket the delta versus cancel is negligible. If your strategy uses amend to track a reference price continuously, the accumulated latency difference across thousands of operations per hour is substantial.

Nonce and Signature Overhead

One latency contributor that engineers frequently overlook is local signing time. Every Hyperliquid action requires an EIP-712 signature. On a modern x86 core with a hardware-accelerated secp256k1 library (libsecp256k1 via eth-account or a Rust equivalent), signing takes 0.05–0.15 ms. With a pure-Python fallback it can reach 1–3 ms. At high message rates this accumulates: 200 amends per minute at 2 ms each is 400 ms of CPU time per minute that delays your send loop. Profile your signing path before optimising the transport.

---

If you are building or tuning an order-management stack on Hyperliquid and want production-grade infrastructure rather than a prototype, talk to us — this is exactly what we design and operate at TierZero.