BlogResearch

Hyperliquid API Latency by Region

We streamed Hyperliquid's BTC order book from AWS servers in 10 regions, from both the native API and Hydromancer. How fast? The data is here.

HydromancerTeam
Hyperliquid API Latency by Region

If you're building a trading interface, a market-making bot, a liquidation monitor or a real-time dashboard on Hyperliquid, your market data has to be fast, fresh, complete and reliable. A slow or stale book means worse fills, late alerts and screens that lag the market. A missing update or a stalled feed is worse.

In June 2026, Hyperliquid slowed its public WebSocket feeds. That leaves builders who need speed with three options: accept the throttled native feed, run their own infrastructure, or use a specialized data provider.

To see what that choice means in practice, we streamed the same Bitcoin order book from Hyperliquid's native API and from Hydromancer, side by side, from servers on two clouds: AWS in 10 regions and Vultr in 9 cities, 13 locations across Asia, Oceania, Europe and North America. We measured speed and freshness region by region, and checked completeness and reliability along the way.

TL;DR: if your application needs fresh, deep order books on Hyperliquid, Hydromancer is the faster choice from every region we tested.

  • Faster on the very same update. When both APIs sent the identical book, Hydromancer's copy arrived first 98.6% of the time, a median 71 ms sooner.
  • A fresher book everywhere. Hydromancer's book was fresher in every run, in all 10 regions. The book you hold is about 50% younger on average (43–58% by region), typically ~310 ms fresher, and it was the newer of the two books 95% of the time.
  • Same result on a second cloud. On Vultr in 9 cities, Hydromancer's book was fresher in 27 of 27 runs, and the same book arrived first 98.5% of the time. Where the two clouds overlap, Hydromancer's book age agrees to within about 20 ms.
  • Almost never stale. A Hydromancer user held a book under half a second old 98–99.7% of the time, and never one older than a second. On the native feed, that was 18–34% and up to 4.6%.
  • Complete and reliable. 0 missed updates in 302,610 Hydromancer messages, 0 unplanned disconnects, and book content identical to Hyperliquid's own on every matching update.
  • More updates, more depth. A new book about every 75 ms instead of every 540 ms, with 20 levels per side in our test (up to 50 available) instead of 5.
  • Ahead of other providers, too. In an independent evaluation, Hydromancer had the lowest latency on mean, median, P95 and P99, for both the full order book and BBO.
  • More headroom. Per-key allowances of 5,000–50,000 REST weight a minute, against the official API's 1,200 per IP shared with your trading. See our rate limits guide.
  • Cheaper than building it. A comparable self-hosted setup costs roughly $835–$3,245 a month plus engineering. Hydromancer starts at $300 a month, and it's free for early-stage teams.

Why the native feed falls short

After the June 2026 changes to Hyperliquid's public WebSocket feeds, the standard order book updates about every 5 seconds. A fast flag restores a roughly half-second cadence, but only 5 levels per side. The public API is also rate-limited.

Stream Levels per side Typical gap between books
Native l2Book 20 ~5.4 s
Native l2Book with fast: true 5 ~540 ms
Hydromancer l2Book up to 50 ~75 ms

Hyperliquid produces a block about every 70 ms. The native fast feed shows you one book for roughly every seven blocks, five levels deep. Hydromancer's l2Book sends a snapshot on each block where the book changes. (New to these feeds? See our guide to Hyperliquid data feeds and BBO vs L2Book vs L4Book.)

Proof 1: Faster and fresher from every region we tested

Builders aren't all in Tokyo, so we tested from where they are. In each region we ran a server on AWS, opened both feeds at the same moment, and compared them two ways:

  • Delivery: when both APIs send the same book, whose copy arrives first?
  • Freshness: how old, on average, is the newest book you're holding? That's what a trading screen or a bot actually works with. It combines delivery speed with how often updates arrive.

We compared Hydromancer against the fastest native option (fast: true), not the 5-second default.

Faster on the same update

Whenever both APIs sent the identical book (same block timestamp, same content), we timed how long each copy took to reach our server:

AWS region Hyperliquid API Hydromancer Hydromancer faster by Same book arrived first on Hydromancer
Tokyo, JP 304 ms 198 ms 106 ms 99%
Seoul, KR 301 ms 214 ms 87 ms 99%
Kuala Lumpur area, MY 335 ms 237 ms 98 ms 99%
Singapore, SG 318 ms 247 ms 71 ms 99%
Sydney, AU 325 ms 248 ms 77 ms 99%
N. California, US 332 ms 252 ms 80 ms 99%
Ohio, US 332 ms 279 ms 53 ms 98%
Frankfurt, DE 387 ms 309 ms 78 ms 98%
London, GB 369 ms 317 ms 52 ms 98%
Paris, FR 381 ms 318 ms 63 ms 98%

Each time is the median from Hyperliquid's block timestamp to our server, so it includes Hyperliquid's own confirmation time and the distance from Tokyo (see What the absolute numbers include). The difference between the two columns is what switching feeds changes.

Across 14,028 identical books, Hydromancer delivered first 98.6% of the time. Comparing each pair directly, its copy arrived a median 71 ms sooner, while carrying a 20-level book against the native feed's 5 levels.

A fresher book in every region

Hydromancer also sends about seven times as many books: one on every block where the book changes, instead of one every half second. Faster delivery plus more updates is what the book you hold reflects:

AWS region Native book age Hydromancer book age Hydromancer fresher by Book is younger by
Tokyo, JP 605 ms 254 ms 351 ms 58%
Seoul, KR 595 ms 268 ms 327 ms 55%
Kuala Lumpur area, MY 620 ms 291 ms 329 ms 53%
Sydney, AU 610 ms 302 ms 308 ms 51%
Singapore, SG 614 ms 303 ms 311 ms 51%
N. California, US 618 ms 305 ms 313 ms 51%
Ohio, US 614 ms 332 ms 282 ms 46%
Frankfurt, DE 691 ms 365 ms 326 ms 47%
London, GB 656 ms 371 ms 285 ms 43%
Paris, FR 664 ms 374 ms 290 ms 44%

Hydromancer's book was fresher in every run, by 276–360 ms. The advantage holds wherever you build, because a feed that sends seven times as many books can't be overtaken by geography.

Fresh nearly all the time, not just on average

An average can hide stretches where the other feed is ahead, or where your book goes stale. So at every 10 ms sample we also checked which book was newer, how often each book was fresh or stale, and how old it got at its worst:

AWS region Hydromancer held the newer book Book under 500 ms old: native / Hydromancer Book over 1 s old: native / Hydromancer Worst-case book age (p99): native / Hydromancer
Tokyo 98% 33% / 99.4% 2.5% / 0% 1,119 / 428 ms
Kuala Lumpur area 97% 29% / 99.6% 1.7% / 0% 1,043 / 433 ms
Seoul 96% 34% / 99.7% 1.9% / 0% 1,081 / 407 ms
Frankfurt 96% 18% / 98.4% 4.6% / 0% 1,199 / 536 ms
N. California 96% 29% / 99.6% 1.6% / 0% 1,045 / 445 ms
Sydney 95% 31% / 99.6% 1.5% / 0% 1,036 / 440 ms
Singapore 95% 30% / 99.2% 2.0% / 0% 1,082 / 478 ms
Paris 94% 21% / 98.2% 1.3% / 0% 1,020 / 542 ms
Ohio 93% 30% / 99.5% 0.8% / 0% 979 / 471 ms
London 93% 23% / 98.8% 2.1% / 0% 1,071 / 515 ms

Across every run, Hydromancer held the newer book 95% of the time. Its book was never older than a second in any region, and its worst-case age was roughly half the native feed's. Its slowest 1% of individual deliveries (p99 arrival) were also faster than the native feed's in every region: 326–496 ms against 592–793 ms.

Same result on a second cloud: Vultr

To check the results aren't specific to AWS, we repeated the test on Vultr on 29 September, in 9 cities, with three 10-minute runs in each.

Same book, time to reach our server:

City Hyperliquid API Hydromancer Hydromancer faster by Same book arrived first on Hydromancer
Tokyo, JP 285 ms 198 ms 87 ms 99.8%
Seoul, KR 293 ms 214 ms 79 ms 99.8%
Singapore, SG 304 ms 231 ms 73 ms 99.5%
Melbourne, AU 363 ms 256 ms 107 ms 99.5%
Mumbai, IN 335 ms 272 ms 63 ms 98.5%
Frankfurt, DE 399 ms 314 ms 85 ms 98.5%
Paris, FR 383 ms 317 ms 66 ms 96.7%
Amsterdam, NL 392 ms 319 ms 73 ms 97.0%
London, GB 390 ms 323 ms 67 ms 97.1%

Book freshness:

City Native book age Hydromancer book age Hydromancer fresher by Book under 500 ms old: native / Hydromancer
Tokyo, JP 567 ms 252 ms 315 ms 38% / 99.9%
Seoul, KR 580 ms 268 ms 312 ms 36% / 99.9%
Singapore, SG 587 ms 285 ms 302 ms 35% / 99.9%
Melbourne, AU 654 ms 313 ms 341 ms 23% / 99.4%
Mumbai, IN 621 ms 330 ms 291 ms 29% / 99.2%
Frankfurt, DE 687 ms 373 ms 314 ms 18% / 98.3%
Paris, FR 668 ms 376 ms 292 ms 20% / 97.7%
Amsterdam, NL 679 ms 379 ms 300 ms 19% / 97.3%
London, GB 671 ms 382 ms 289 ms 19% / 97.3%

Hydromancer's book was fresher in all 27 runs, by 270–355 ms, and about half as old on average. The identical book reached Hydromancer first 98.5% of the time (23,243 books), a median 75 ms sooner comparing each pair, and its slowest 1% of deliveries were faster than the native feed's in every city: 311–501 ms against 532–712 ms.

Where the two clouds overlap, the results agree closely. Across the six cities measured on both, Hydromancer's book age differed by 0–18 ms: Tokyo 254 ms on AWS and 252 ms on Vultr, Seoul 268 and 268, Paris 374 and 376, Frankfurt 365 and 373, London 371 and 382, Singapore 303 and 285. That consistency is what you'd expect if the numbers reflect distance from Tokyo, not the hosting company.

On Vultr, a Hydromancer book was older than one second at most 0.16% of the time in any city, against up to 2.9% on the native feed. Nearly all of it comes from a single pause of about 1.5 seconds at 05:00 UTC, which hit both feeds in Mumbai, Melbourne and Frankfurt at the same moment, so it came from upstream of both.

What the absolute numbers include

The book ages above are measured end to end, from the moment Hyperliquid timestamps a block to the moment our server holds it. Most of that time isn't the feed provider at all:

Stage Approx. time Who controls it
Hyperliquid consensus: nobody can see a block until validators commit it (median ~0.2 s, even for a co-located client) most of it Hyperliquid; the same for every feed, including your own node
Distance from Tokyo to your server ~20–235 ms round trip across these regions Geography
Hydromancer's processing of each block ~20 µs (p50) Hydromancer, effectively zero

That's why the absolute ages rise with distance from Tokyo (Tokyo 254 ms, London 371 ms), while Hydromancer's lead stays roughly constant. AWS and Vultr gave almost identical results where they overlap, so the hosting provider matters far less than the distance.

Proof 2: Faster than other providers, too

Beating the throttled native feed is one thing. A builder choosing a provider also wants to know how Hydromancer compares with the alternatives. Our Hyperliquid data latency benchmark features an evaluation run by a team comparing providers before it became a customer, in its own environment:

Full L2 order book (HYPE) Mean P50 P95 P99
Hydromancer 190 ms 180 ms 245 ms 341 ms
Provider A 263 ms 246 ms 323 ms 696 ms
Provider B 315 ms 260 ms 638 ms 1,288 ms
Native Hyperliquid stream 345 ms 311 ms 580 ms 860 ms

Hydromancer was the lowest feed on every metric, with a P99 less than half the native stream's. That matters most when markets move fastest. The same evaluation found Hydromancer lowest on BBO as well, ahead of the native stream and three other providers.

Proof 3: Built for low-latency builders

Speed in a benchmark only helps if the feed gives you what you need to build. From our orderbook streaming docs:

  • Every block, at depth. l2Book sends up to 50 levels per side on each block where the book changes. The docs even publish each stream's relative latency: l4BookUpdates is fastest, l2BookDiff ~2 ms after it, raw l2Book ~5 ms after.
  • Streams the native API doesn't have. Keep your own book with changes-only diffs (l2BookDiff), or see every individual order and the address behind it (l4BookUpdates). Natively, that requires running your own node.
  • Near-zero processing. ~20 µs per block (p50).
  • Infrastructure placed for speed. We run our own validator and bare-metal servers, close to Hyperliquid's Tokyo network, so you don't have to. See why teams choose Hydromancer.
  • No data lost on reconnect. Sessions replay what you missed (up to 30 seconds) and flag any gap.
  • Proven in production. From market makers to exchanges like VALR, teams build on Hydromancer.

Proof 4: Cheaper than building it yourself

The alternative to a provider is running your own low-latency setup. It's possible. Here's what it takes, based on Hyperliquid's node documentation and our non-validator node guide:

Component Why you need it ~Cost / month
A node server in Tokyo At least 16 vCPU, 128 GB RAM and 500 GB of fast SSD; Hyperliquid recommends Tokyo for the lowest latency $725 (bare metal) to $1,067 (AWS, next to the Foundation's sentry)
A second node If your single upstream peer drops, your feed stalls for 10–30 seconds; production needs failover × 2
A reliable upstream peer Direct Foundation access needs >0.5% of 14-day maker volume; everyone else uses public or paid peers Hydromancer Peering: $500 per node
Egress out of Tokyo One full 50-level book is ~106 GB a month ~$110 for 10 books
A book server + operations The node doesn't serve order books or WebSockets; you run or build a book server and handle gaps, pruning and upgrades Engineering time
Self-hosted, minimal Self-hosted, production-grade Hydromancer
Monthly total ~$835 + engineering ~$3,245 + engineering from $300

Machine prices are on-demand in Tokyo, as of 15 August 2026.

Proof 5: More headroom before you're rate-limited

A fast feed doesn't help if you get throttled. The official API limits you per IP address, and every service behind that address shares one budget. Our guide to Hyperliquid rate limits covers the full picture. The parts that matter for latency-sensitive apps:

  • REST: 1,200 weight points per minute per IP. An l2Book or clearinghouseState request costs 2 points. Polling ten order books once a second uses the entire budget. So does refreshing 100 wallets' positions every ten seconds.
  • Data reads and trading share that budget. If a dashboard and a trading service leave through the same IP, heavy data fetching leaves less room for placing or cancelling orders.
  • WebSockets: 10 connections, 1,000 subscriptions and 10 unique users per IP. Opening more connections doesn't raise the ten-user cap, which limits wallet trackers.

Hydromancer's allowances are per API key, not per IP, and scale with your plan:

Official API (per IP) Hydromancer Starter Growth Scale
REST weight per minute 1,200 5,000 20,000 50,000
WebSocket connections 10 50 500 1,000
Total subscriptions 1,000 500 5,000 10,000
l2Book coins streamed Within the subscription cap 10 50 100

It also cuts the number of requests you need. batchClearinghouseStates refreshes 100 wallets in one request, so that ten-second refresh drops from 600 requests a minute to 6. Streaming books over one WebSocket replaces polling altogether.

Two things don't change. Hydromancer has limits of its own, so capacity-plan against the published allowances. And trading actions sent to Hyperliquid stay under Hyperliquid's own limits. What moves is your data traffic: reads sent to Hydromancer no longer consume the IP budget your orders depend on.

Proof 6: Complete and reliable

Speed only helps if the data is right and keeps flowing. A book that's fast but quietly missing an update is wrong, and a feed that drops at the wrong moment is worse than a slow one. Here's what we observed across all 43 runs on both clouds (430 minutes of streaming in 13 locations), plus earlier tests of Hydromancer's book-building tools:

Check Result
Missed or out-of-order updates 0 sequence gaps in 302,610 Hydromancer L2 messages. Every message carries a sequence number, so a gap would be visible immediately
Content matches Hyperliquid's own book 100% identical: all 37,271 books that both feeds sent for the same block had the same top 5 levels on both sides
Unplanned disconnects 0 on either feed, in any region. Each run used one connection from start to finish
Longest wait between books 490 ms on Hydromancer, against 1,222 ms on the native fast feed (AWS runs). On Vultr, both feeds paused together once, for about 1.5 s, at 05:00 UTC
Rebuilding a book from changes only A BTC book rebuilt from l2BookDiff matched Hydromancer's l2Book snapshot, top 50 levels on both sides, in 653 of 653 blocks (earlier test, 28 September)
Catching and repairing a gap When we deliberately dropped one update, the gap was flagged on the very next message, and resyncing from a fresh snapshot restored an exact match (earlier test)

If your connection does drop, Hydromancer's sessions replay what you missed (up to 30 seconds) and flag any gap, so your book doesn't silently drift.

These are results from our test windows, not a long-term uptime figure. For that, every plan comes with a 99.9% uptime SLA.

Which plan fits your build

Plan Price / month Concurrent order book streams
Starter $300 10
Growth $1,200 50
Scale $2,500 100

Every plan includes a 99.9% uptime SLA and direct founder access. See pricing and the full limits.

Bottom line

If you're building on Hyperliquid and latency matters, you have three choices:

  1. The native API: free, but throttled to a 5-level book about every half second.
  2. Your own infrastructure: fast, but ~$835–$3,245 a month plus the engineering to build and run it.
  3. Hydromancer: the same update delivered first 98.6% of the time, a book about 50% younger in every region we tested, no missed updates in our tests, the lowest latency against other providers in an independent evaluation, and order-level streams the native API doesn't offer, from $300 a month.

For builders who need low latency on Hyperliquid, Hydromancer is the best fit. Get an API key or compare plans, and stream your first book in minutes.

Methodology and notes

Setup

  • Market and dates: BTC. AWS: 28 September 2026, 10:21–10:42 UTC. Vultr: 29 September 2026, 04:12–05:51 UTC.
  • Streams: four WebSocket connections opened together on each server: Hydromancer l2Book (20 levels), native l2Book with fast: true (5 levels), and both APIs' BBO streams.
  • Runs: 600 seconds each: a 30-second warm-up, then 570 seconds analysed on a shared 10 ms grid. AWS: two runs per region, one in Tokyo, Singapore, Paris and Frankfurt (16 runs). Vultr: three runs per city (27 runs). 43 runs in total.
  • Servers: an AWS t3.small (2 vCPUs, 2 GB) running Ubuntu 24.04 in each region: ap-northeast-1 (Tokyo), ap-northeast-2 (Seoul), ap-southeast-5 (Malaysia), ap-southeast-1 (Singapore), ap-southeast-2 (Sydney), us-west-1 (N. California), us-east-2 (Ohio), eu-central-1 (Frankfurt), eu-west-2 (London) and eu-west-3 (Paris). All timestamps were taken on that server. AWS doesn't publish an exact city for its Malaysia region.
  • Vultr servers: a vc2-2c-2gb (2 vCPUs, 2 GB) running Ubuntu 24.04 in each city, three cities at a time. Each server set itself up at boot, ran its three captures, uploaded the results and was then deleted. We planned 15 Vultr cities and stopped after 9; the three cities running when we stopped were discarded, not included.
  • Clocks: each server was synchronised with chrony, with its offset recorded before and after every run. The largest clock adjustment during a run was under 0.5 ms in 12 of 16 runs, and 1.2–2.8 ms in the single Tokyo, Singapore, Paris and Frankfurt runs. On Vultr, the largest adjustment in any run was 0.8 ms. Both are small next to the 270–360 ms gaps being measured.
  • Same-update comparison: we paired each native message with the Hydromancer message carrying the same block timestamp and identical content (top 5 levels per side for L2; bid and ask for BBO), then compared arrival times on the same server.
  • Timestamps: both APIs label books with the block's timestamp. Whenever the two feeds carried the same timestamp, the book content was identical in 100% of cases (37,271 L2 books and 155,737 BBO updates across both clouds). When the book doesn't change between blocks, Hydromancer doesn't resend it, so its held book keeps the older timestamp. That makes our freshness figures slightly conservative for Hydromancer.
  • Completeness and reliability: sequence gaps, timestamp regressions and connection events were logged for every feed in every run. The l2BookDiff rebuild and gap-recovery tests ran separately on 28 September from a single machine in Malaysia, streaming BTC.
  • Round trips: measured with Globalping probes (three per city, three rounds) using a request answered by Hyperliquid's own server, not the CDN cache.

Freshness calculation

Every 10 ms, we took the newest book each stream had delivered and calculated its age. Samples before a stream's first message were skipped.

code
def book_freshness(arrivals, t_from, t_to, step=0.010):
    """arrivals: sorted list of (recv_time_s, block_time_ms) for one stream."""
    ages, j, t = [], -1, t_from
    while t < t_to:
        while j + 1 < len(arrivals) and arrivals[j + 1][0] <= t:
            j += 1
        if j >= 0:
            ages.append(t * 1000 - arrivals[j][1])
        t += step
    return sum(ages) / len(ages)

Freshness differs from the arrival latency in our benchmark series: it also counts the wait for the next update, which is what a user sees on screen.

Notes

  • Depth. Native fast sends 5 levels per side; the Hydromancer stream we tested sent 20. The larger payload can only slow Hydromancer down, so the comparison doesn't favour it.
  • BBO. Both APIs send best bid/offer only when it changes, so there's no refresh-rate gap. On identical BBO updates, Hydromancer's copy arrived first 76.5% of the time on AWS, a median 20 ms sooner, and 55–95% of the time by city on Vultr. Ohio and Paris on AWS, and London on Vultr, were roughly even.
  • Coverage. This post covers 10 AWS regions and 9 Vultr cities, 13 locations in all. We plan to add more, and update this post as we do.
  • Networks. These were datacenter servers. A home or office connection adds its own delay to both feeds.
  • Transparency. We ran this ourselves, which is why we publish the method and every result, and add it to our living latency benchmark.

Related reading

← All posts

Read next