HFT-tier Oracle Gateway Latency
A co-location guide for traders racing on oracle-dependent prices. We cover the HFT-tier oracle gateways — products designed for sub-100ms trading, where geographic distance to the origin actually matters. Consumer-tier oracles like Pyth Hermes and Redstone are excluded by design — they're served from edge infrastructure where geographic latency is uniform regardless of where you sit.
What we measure — and what we don't
We measure network round-trip time from each probe to the oracle's API gateway endpoint. Depending on the oracle's production protocol, this is a WebSocket subscribe RTT, a TCP+TLS handshake, or an HTTP TTFB.
This is not a measurement of how quickly each oracle delivers new price updates. Update cadence (how often new prices are published) and freshness (how stale each update is when it arrives) are separate properties that are independent of network RTT. A 5 ms RTT to an oracle that publishes every 400 ms is a very different product from a 5 ms RTT to one that publishes every 5 ms — but both show the same number on this page. See the Data Freshness tab for what we've measured on that front.
The cadence values in the column headers are from each oracle's published documentation. Values marked with † are for paid, auth-gated products that we could not independently verify.
Why off-chain API access matters — and how it differs from on-chain oracle reads
Most DeFi oracles now operate in two distinct modes, and they have very different latency profiles:
On-chain push oracles (Chainlink classic, Band, API3 dAPIs)
The oracle network writes price updates directly to a smart contract on-chain when a heartbeat timer elapses or a deviation threshold is crossed. Your smart contract reads the stored value via latestRoundData().
Geographic location is mostly irrelevant to the oracle data itself — all users of that chain read the same contract state once the update is on-chain. Location can still matter for RPC access, transaction submission, and block-propagation races, but not for receiving the oracle update.
Off-chain pull oracles (Pyth, Chainlink Data Streams, Switchboard, Redstone)
The oracle network aggregates prices off-chain and signs each update cryptographically. Your off-chain infrastructure (a keeper bot, searcher, or liquidation engine) subscribes to the oracle's WebSocket or HTTP gateway and receives a stream of signed price packages.
When you want to act on a price — placing a trade, triggering a liquidation, updating a hedge — you take the latest signed package from the oracle's gateway and include it as a parameter in your on-chain transaction. The smart contract verifies the signature and uses the embedded price.
Geographic location matters a lot here. The race becomes "how fast does my infrastructure receive the signed price update?" — which depends on the network path between you and the oracle's access layer: gateway, regional endpoint, CDN/edge, or HA cluster. A server close to the measured endpoint can receive updates tens to hundreds of milliseconds earlier than a server on another continent. That edge compounds into real P&L for liquidation searchers, oracle-CEX arbitrageurs, and mark-price hedgers.
The practical implication: for traders whose strategies react to oracle prices (liquidation searchers, oracle-CEX arbitrageurs, mark-price hedgers), the question "which oracle is fastest?" has a geographic answer. This page gives you the network distance component. Where your infrastructure sits relative to each oracle's gateway origin is a choice that directly affects your edge — and unlike execution speed or algorithm quality, it's a one-time infrastructure decision.
Cross-oracle comparison caveat
Absolute latency numbers across oracles are not directly comparable. Each oracle is measured using the protocol a real client would use in production. A WebSocket ping captures one round-trip. A TLS handshake captures roughly two. An HTTP TTFB captures one round-trip plus small server processing. A WS upgrade rejection captures two round-trips.
If we used a single uniform method across all oracles (say, TLS handshake everywhere), we'd get meaninglessly low numbers for Cloudflare-fronted oracles (Chainlink Data Streams) — a TLS handshake to those only reaches the nearest Cloudflare edge, not the actual origin. So we use per-oracle production protocols and explicitly disclaim cross-oracle comparison.
The story this data supports: "Oracle X favours traders in city A by Y ms vs traders in city B" — measured per-oracle. Not "Oracle A is universally faster than Oracle B." The ✓ winner column shows which oracle has the lowest raw network RTT from each probe, as a directional signal only.
Per-oracle methodology
| Oracle | Infrastructure | Measurement | Notes |
|---|---|---|---|
| Pyth Lazer | Tokyo bare metal | TLS handshake | HFT-tier. All 3 routers physically in Tokyo (TeraSwitch + Latitude.sh). Best of 3 routers shown per probe. |
| Stork JP | AWS ap-northeast-1 | TLS handshake | Tokyo regional endpoint. Other regional endpoints exist but are not surfaced via public DNS. |
| Switchboard | GCP eu-west4 (NL) | REST TTFB | — |
| Chainlink Data Streams | Cloudflare (US West) | REST TTFB | Auth-gated WS feed itself can't be measured publicly. Latency shown reflects the same network path as the WS feed. |
Key findings
- Every oracle has a home city. Pyth Lazer and Stork JP favour Tokyo (single-digit ms from Tokyo probes); Switchboard Crossbar favours Amsterdam/London/Frankfurt; Chainlink Data Streams favours the US.
- Pyth Lazer is Tokyo-only origin. Despite being marketed as an HFT tier, Pyth Lazer is only fast for traders co-located in Tokyo. From EU or US, you're looking at hundreds of milliseconds either way.
- CDN-fronting costs tens of milliseconds. Oracles that put a CDN (Cloudflare, CloudFront) in front of their origin add tens of milliseconds to every request, even for users right next to a CDN edge. Switchboard goes direct to GCP and lands in the low tens of ms for the best probes; Chainlink Data Streams is Cloudflare-fronted and pays the proxy tax on every request. Same protocol, different infrastructure choice.
Why some oracles aren't shown
Pyth Hermes and Redstone are excluded for measurement reasons, not positioning. Pyth Hermes is served from Cloudflare's edge mesh with no real geographic origin to traverse — probes anywhere near a Cloudflare PoP see the same edge-served response. Redstone offers both push-based and pull-based products (including a low-latency pull tier), but their public gateway sits behind a heavily CDN-cached path that we can't reliably bypass from outside, so we can't cleanly measure their origin geography. For HFT use cases, Pyth themselves direct users to Pyth Lazer, which we do cover.
Paid, auth-gated products
Pyth Lazer, Switchboard Surge, and Chainlink Data Streams are paid, auth-gated WebSocket products. We currently only map their network geography — freshness and cadence verification from inside a paid account is something we may add in the future. Cadence figures for paid products come from each project's published documentation and are marked with †.
A note on probe networks
Columbus sometimes shows faster Chainlink Data Streams latency than San Jose, even though San Jose is geographically closer. The Columbus probe runs on AWS, while San Jose runs on Fly.io — and AWS has stronger peering with Cloudflare than Fly.io. For CDN-fronted oracles, the probe-to-CDN leg can dominate the small differences, occasionally making a further probe look faster.
Disclaimer
Oracle Gateway Latency is a research tool provided for informational purposes only. Network RTT to a gateway measures one component of oracle latency — the others (pipeline lag, cadence, freshness) are separate and vary by oracle tier and subscription level. Numbers for paid/auth-gated products (marked †) are based on publicly available infrastructure geography, not live feed performance. Chainlink Data Streams rejection-RTT should be treated as a geographic signal, not an absolute benchmark. This page is not affiliated with, endorsed by, or connected to any of the oracle projects measured.