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.

Most DeFi oracles now operate in two distinct modes, and they have very different latency profiles:

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.

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.

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.

Every other section of this site reports a median (p50). The oracle pages report the floor — the fastest measurement in each sampling window. This is a deliberate exception, and it exists because the question here is different.

A median answers "what does a typical request cost?" — which blends the network path with whatever the server was doing at that moment. The floor answers "how far away is this thing?" Since the purpose of these pages is deciding where to put your infrastructure, distance is the number that matters, and it's the part that doesn't change from one request to the next.

For most oracles the distinction is academic — the responses are consistent enough that the floor and the median differ by well under a millisecond. It matters most where we are measuring from the outside without a subscription: there, individual responses vary widely for reasons we cannot see from where we stand. Ranking on the median let that variation decide the ordering, and the "closest" city changed from one sample to the next. Ranking on the floor gives a stable answer that matches physical geography — probes sitting in the same data centre now agree with each other, as they should.

The variation is still visible in the p95 column. We just don't let it choose the winner, because it isn't a fact about location.

• Every oracle has a home city. Pyth Pro (Lazer) favours Tokyo (single-digit ms from Tokyo probes); Switchboard Crossbar favours Amsterdam/London/Frankfurt; Chainlink Data Streams favours the US East coast, with Northern Virginia the clear floor and the rest of the world paying for the crossing.
• Pyth Pro is delivered from Tokyo.Lazer — the delivery rail behind Pyth Pro, the institutional feed now powering exchanges including Coinbase, BitMEX, Bitget, LMAX and Crypto.com — serves its public endpoints exclusively from Tokyo. The network floor is single-digit ms for infrastructure co-located there, and rises with every kilometre of distance: from EU or US, network RTT alone exceeds Pyth's published sub-100ms end-to-end figure. For latency-sensitive subscribers, proximity to Tokyo is the co-location decision.
• A CDN in front of an oracle is not a latency problem. Plenty of the infrastructure we measure elsewhere on this site sits behind a CDN and still lands in the low tens of milliseconds for a well-placed probe. Being CDN-fronted tells you almost nothing about how fast a gateway is — what matters is where its origins actually are, and a CDN can hide that from a casual look without hiding it from a probe network.

Pyth Hermes and Redstoneare 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 Pro (Lazer), which we do cover.

Stork JPwas previously monitored here, but we removed it because Stork began blocking our probes' IP addresses. Every probe — including those co-located in Tokyo right next to the endpoint — now gets rejected at connection time, so we can no longer collect usable latency data for it.

Pyth Pro (Lazer), Switchboard Surge, and Chainlink Data Streams are paid, auth-gated WebSocket products. We map their network geography from the outside, using public endpoints that share the same infrastructure as the feed itself. These figures are an estimate of the network path, made to the best of our ability without a subscription — good enough to answer the location question, and not a substitute for measuring the live feed from inside a paid account, which is something we may add in the future. Cadence figures for paid products come from each project's published documentation and are marked with †.

When an oracle sits behind a CDN, no probe talks to the origin directly — each one reaches its nearest CDN edge, and the CDN carries the request the rest of the way over its own private network. What we measure is the sum of those two legs.

This ranks locations correctly, because the second leg shrinks as you get closer to the origin — being behind a CDN does not prevent a gateway from being measured, or from being fast. It does mean the numbers are not a straight-line distance, so treat the ordering as reliable and the exact millisecond gaps between adjacent cities as approximate.

One consequence worth knowing: a CDN routes each edge to whichever origin suits it, so a provider running more than one origin will show several regional floors rather than a single point radiating outward. Chainlink Data Streams behaves this way — the US East coast is its strongest location, but the US West coast is far faster than a single East-coast origin could explain.