Latency, priority and infrastructure

Latency on Hyperliquid is about where you stand relative to others, not absolute speed. Every order is a transaction: an API server forwards it to a node, which gossips it into the mempool, and the answer comes only once it’s committed, usually two blocks later in pipelined HyperBFT. Per the docs, that makes latency incomparable with a centralised matching engine, but ordering is precise: sends under 10 ms apart should land in a predictable order on the L1.

One production process in Ireland hedges each fill on another venue. Measured against the exchange’s fill timestamp, the hedge completed 350 to 500 ms later.

About 110 ms was transit; 240 to 310 ms was four serialised HTTPS round trips to the hedge venue, each on a fresh HTTP client, and three were removable. That was the process’s design, not geography.

This is the strategy view; the code-level view is optimising latency.

Where the time goes

Segment	What sets it	Measured or documented	What you can change
You to the API server	Distance. The API servers run in Tokyo	About 110 ms each way between Tokyo and Ireland	Where your process runs
Mempool to commit	Consensus: usually two blocks	About 380 ms end to end for a cancel or post-only order	Priority fees; order type
Ordering against other senders	Cancels and post-only orders at time t run before Ioc and Gtc at t	Documented; spans several blocks	Use post-only and cancels where you can
Your own round trips	How many serial requests a decision needs	A cross-venue hedge measured at 350 to 500 ms, of which about 110 ms was transit	Software, with no box moved
Reading state	API and WebSocket, or your own node	Split client blocks read inputs 70 to 150 ms sooner	Run a node

Distance to the network sets your floor

Gossip peers drop ICMP, but their gossip ports accept TCP, and connect time is a faithful round trip. A monitor probing every gossip peer from nine pinned regions every five minutes recorded:

Vantage region	Round trip to the peer cluster
Asia-Pacific	70 ms
Western North America	107 ms
Eastern North America	157 ms
Oceania	174 ms
Western Europe	235 ms
Eastern Europe	252 ms

From Europe the network is more than three times as far as from Asia-Pacific.

Priority is for sale, and the fee is burned

The protocol sells priority in two independent forms, and both fees are burned (priority fees and the activation fee). Cancels always go before immediately executable orders, whatever the fee.

	Gossip priority, for reading	Order priority, for writing
Mechanism	two independent Dutch auctions on one 3-minute schedule; respecting nodes send the mempool stream and client blocks to peers in slot order	a grouping {"p": N} on an order batch, a rate of N / 100000000 of notional
Effect	a winner receives data sooner, about 25 ms per slot on mainnet, per the docs	Ioc: linear from 0 to 8 bps, about 45 ms of end-to-end latency per 1 bp; above 8 bps, orders arriving in the same 70 ms window are sorted by fee. Post-only: orders under 400 ms old at a price level are sorted by fee
Price	each auction starts at 10 x its slot’s previous winning price, minimum 0.1 HYPE	the rate on notional; post-only is charged at placement, filled or not
Paid from	spot balance	undelegated staking balance
Applies only if	the IP registered on chain exactly matches the IP the sending peer sees	the batch meets the grouping conditions below

Run a node to read the network directly

The docs recommend a non-validating node (running a node) against a reliable peer, building the book locally from its output: faster and more granular than the API. Its split client blocks stream transactions before execution, without results, which a consumer must estimate; gossip priority applies to what it receives.

The numbers

Quantity	Value	Source
End-to-end latency, co-located client	median 0.2 s, 99th percentile 0.9 s	docs
Cancel or post-only order, end to end	about 380 ms	docs
Commit	usually 2 blocks	docs
Sequencing variation in controlled experiments	under 10 ms between send times gives a predictable order	docs
Tokyo to Ireland transit	about 110 ms	production bot
Fill to external hedge, from Ireland	350 to 500 ms; estimated 170 to 190 ms with three round trips removed	production bot
Gossip peer round trip	70 ms Asia-Pacific to 252 ms eastern Europe	peer monitor
Gossip priority	2 auctions, 3-minute schedule, about 25 ms per slot, minimum 0.1 HYPE, resets to 10x the last price	docs
Ioc order priority	linear 0 to 8 bps (p = 80000), about 45 ms per 1 bp; maximum rate 100%	docs
Post-only order priority	fee-sorted within the last 400 ms at a level	docs
Node hardware	32 logical cores, 128 GB RAM, 500 MB/s disk	docs
Split client blocks	70 to 150 ms faster inputs, without results	docs
HyperEVM order path	small EVM blocks every 1 s, then 0.35 to 0.51 s from block to order acceptance	REFERENCE.md; spec 01

Match the spend to the strategy

• Resting orders: post-only orders and cancels already beat takers sent at the same moment, free. Buy post-only priority only when queue position is worth more than the fee, charged on resting notional even if nothing fills.
• Taking: paying 8 bps of Ioc priority to capture a mispricing under 8 bps loses money on every fill.
• Hedging across venues: fix the hedge path before moving hardware; in the measured case software cost more than twice the transit.
• Location: Europe starts 165 to 182 ms of round trip behind Asia-Pacific. Only moving narrows that.
• The HyperEVM is not faster. The docs call CoreWriter orders deliberately delayed; measurement found no multi-second delay, but an order waits for an EVM block, then 0.35 to 0.51 s more (one HyperEVM transaction).

Levers in the order they usually pay

1. Keep reads off the request path: stream the book and fills over the WebSocket. One process polled /info into the per-IP limit and blocked its own orders, whose preparation queried /info first.
2. Remove serial round trips, reuse connections, set TCP_NODELAY.
3. Send cancels with f: true, and post-only orders in their own batches.
4. Move the process closer to Tokyo.
5. Buy priority where the edge covers it.
6. Run a node for reads.

{
  "type": "order",
  "orders": [{ "a": 0, "b": true, "p": "100.5", "s": "1", "r": false, "t": { "limit": { "tif": "Ioc" } } }],
  "grouping": { "p": 10000 }
}

p = 10000 is 10000 / 100000000, 0.0001 of filled notional: 1 bp. Gossip auction state is on the info request {"type": "gossipPriorityAuctionStatus"}.

Conditions on priority, nodes and sockets

• Priority grouping conditions: every order on a non-outcome asset; the batch all Ioc or all non-reduce-only post-only.
• Gossip slots are not additive: an IP winning several is prioritised by its lowest, and any hop to the validators may ignore the auction.
• Auction results apply to the next period only: winners set the order for the following auction’s duration.
• Predicting execution from split client blocks is reasonable for simple orders, not for everything.
• The docs’ reference order book server is unmaintained: fork it or write your own, including post-only priority ordering.
• WebSocket limits: at most 10 connections, 1,000 subscriptions and 100 in-flight posts per IP.

For where latency turns into money, see Market making on Hyperliquid. For why one ordering matters more than raw speed, see Ordering, finality and fairness.