Hyperliquid Latency Optimization: Co-location, Network and Code Tuning

Hyperliquid runs its matching engine on its own L1 chain, which means your latency profile is fundamentally different from a CEX like Binance: you are not racing against co-located servers in the same data center, you are racing against validators and other traders submitting L1 transactions over the public internet. That gap between "close enough" and "actually fast" determines whether your fills land or you chase price. Here is what we have measured and deployed across live strategies.

Region Selection: The Baseline Is Everything

Hyperliquid's primary validator infrastructure sits in AWS us-east-1 (N. Virginia). Before touching a single line of code, your first job is to cut the physical round-trip to that endpoint. Deploying in us-east-1 rather than eu-west-1 typically drops raw TCP RTT from ~110 ms to under 10 ms. That single decision dwarfs most software-level optimizations.

Within us-east-1, instance placement matters too. Prefer metal or dedicated-host instances over shared tenancy — you eliminate noisy-neighbor NIC contention at zero application cost. On a c7g.metal we saw p99 socket-level RTT to Hyperliquid's RPC drop from 8.2 ms to 5.9 ms simply by moving off a shared c7g.2xlarge. Not dramatic, but in a market-making strategy that p99 tail is exactly when you get picked off.

VPN and Proxy Bypass

This one catches people. Many trading shops route all egress through a corporate VPN or a SOCKS5 proxy for security and audit reasons. For latency-sensitive strategies, that path adds 3–20 ms of additional RTT depending on the VPN endpoint geography and encryption overhead.

The correct approach is split-tunneling: route Hyperliquid API traffic (api.hyperliquid.xyz, the websocket endpoint, and the JSON-RPC endpoint) directly over the instance's native NIC, and keep everything else inside the tunnel. On Linux this is two ip rule entries and an iptables ACCEPT mark. Compliance teams usually accept this if you log all order events to an immutable store (CloudWatch Logs with KMS and no delete permission works fine for most audit requirements).

WebSocket vs HTTP: Always Stay on the Socket

Hyperliquid exposes order placement over both HTTPS POST and a persistent WebSocket. The difference in practice: a cold HTTPS request pays TLS handshake + HTTP/1.1 framing + server-side session lookup on every order. A warm WebSocket pays only framing — the session is already authenticated. In our benchmarks on a co-located us-east-1 instance, median order ACK over HTTPS was 11.4 ms; the same order over the persistent WebSocket was 4.8 ms.

Keep exactly one WebSocket connection per strategy instance. Multiplex all order sends and cancel submissions down that single socket. Reconnection logic should use an exponential backoff capped at 500 ms with jitter — you want to reconnect fast after a drop, but not so fast that you hammer the endpoint during an outage.

Async Rust Client Architecture

Python asyncio clients are usable for low-frequency strategies. For anything placing more than ~50 orders per second under latency pressure, you want Rust with Tokio and the tokio-tungstenite WebSocket crate. The relevant structural points:

• Single-threaded Tokio runtime for the hot path (order sender + ACK receiver). Adding worker threads adds scheduler overhead you cannot afford.
• Pre-serialize all order structs at strategy init time for the static fields (asset ID, order type flags). At signal time, only patch in price and size bytes — this drops serialization latency from ~18 µs to ~3 µs on an M3/Graviton3 core.
• Zero-allocation message path: pool your BytesMut buffers and reuse them across orders. The bytes crate's BytesMut::split_to pattern works well here.
• Pinned OS threads + SCHED_FIFO: for the Tokio executor thread handling orders, set pthread_setschedparam to SCHED_FIFO priority 50. This eliminates preemption jitter from the kernel scheduler. Requires CAP_SYS_NICE on the process or ulimit -r.

This stack gets you to sub-1 ms application-level latency from signal to bytes-on-wire on a co-located Graviton3 instance.

Kernel-Bypass and SO_BUSY_POLL

Full kernel bypass (DPDK, AF_XDP) is generally not worth the operational overhead for Hyperliquid specifically, because you are still going over a WAN link to the validator — you are not co-located with the matching engine itself. The gains from bypassing the kernel TCP stack (maybe 30–80 µs) are noise compared to the 5–10 ms wire latency floor.

What does pay off is SO_BUSY_POLL. Setting this socket option tells the kernel to busy-poll the NIC receive queue for up to N microseconds before sleeping, trading CPU cycles for reduced syscall latency on the ACK path. We set it to 50 µs:

int val = 50;
setsockopt(fd, SOL_SOCKET, SO_BUSY_POLL, &val, sizeof(val));

Pair this with SO_INCOMING_CPU pinned to the same core as your Tokio thread, and net.core.busy_poll set to 50 in sysctl. Together these typically cut ACK receipt jitter by 30–40% — the p99 comes in rather than spreading. For a market maker, tight p99 matters more than median.

Measuring What You Actually Have

Do not trust perceived performance. Instrument every order with a u64 timestamp from clock_gettime(CLOCK_MONOTONIC_RAW) at bytes-sent and at first-byte-of-ACK. Log these to a ring buffer, flush to ClickHouse or a local SQLite. Aggregate p50/p95/p99 per market, per order type, per hour of day. Hyperliquid validator performance varies across the 24-hour cycle — there are measurable windows of 10–15% better round-trip times between 02:00–06:00 UTC when network load is lower globally.

The most expensive mistake we see is teams optimizing against their own latency in isolation without measuring the outcome that matters: fill rate at the intended price versus theoretical price at time of order. Our market-making work on Hyperliquid showed that reducing p99 ACK latency from 18 ms to 6 ms improved adverse-selection rates by about 12% — the edge was real and measurable.

The trading bot infrastructure we build at TierZero combines co-location design, Rust execution engines, and this kind of per-strategy latency instrumentation as a baseline, not an afterthought.

---

If you are building or scaling a Hyperliquid strategy and latency is a bottleneck, talk to us — we can audit your current stack and identify the highest-leverage fixes.