Capture time and exchange time on four venues

Two clocks per message

Each row in our data has a ts_exchange, the timestamp the venue put on the event, and a ts_capture, the time our capture host received the message. Both are int64 nanoseconds since the Unix epoch, UTC. Venues stamp at millisecond resolution, so the low six digits of ts_exchange are always zero.

Our capture hosts discipline their clocks with PTP from the AWS Time Sync Service and log the estimated clock error bound every second. Over the measurement window the 99.9th percentile of that bound was 38 µs in Tokyo and 44 µs in Ireland. Everything measured below is in milliseconds, roughly two orders of magnitude above our own clock error, so we treat ts_capture as ground truth for when a message arrived.

Setup

Hyperliquid numbers come from our ongoing capture. The other three venues are centralized exchanges, labeled Venue A, Venue B and Venue C here. For them we ran a short measurement of their public market data feeds from May 4 to May 17, 2026, on the same hosts. That measurement was a one-off for this study and is not part of any product. The labels are anonymized because the subject is method, not a comparison between exchanges. On every venue we recorded trades and book deltas for BTC, ETH and SOL perpetuals from Tokyo (ap-northeast-1) and Ireland (eu-west-1) independently. That came to 2.71 billion messages per region.

Latency here means ts_capture minus ts_exchange. It mixes three things: time inside the venue between the event and publication, network transit, and any offset between the venue's clock and ours. Separating them is only partly possible from outside, and we note where we tried.

Where a venue offers more than one timestamp we use the one closest to the matching event. On Venue A that is the transaction time rather than the publication time, which ran a median 1.9 ms later in our sample.

Latency distribution

Milliseconds, ts_capture minus ts_exchange, trades and book deltas pooled. Percentiles are Tokyo unless marked.

LATENCY FROM TOKYO, LOG SCALEFDC MEASUREMENT

On the three centralized venues the distribution sits around a fixed offset, and most of that offset is the network path from our Tokyo hosts. Venue A's median is under 4 ms, and Venue B and Venue C sit around 28 ms and 37 ms. All three are tight until the far tail, where bursts of activity push p99.9 past 100 ms on Venue B and Venue C. These figures describe our hosts' position on AWS as much as the venues, so they should not be read as a ranking.

Hyperliquid's number is not comparable with the other three. Its ts_exchange is the block timestamp, so every message produced by one block carries the same value. The latency we measure is the time from that block timestamp until the API node publishes, plus transit, and it has a sawtooth shape tied to block cadence. For Hyperliquid, ts_exchange tells you which block an event belongs to. It cannot tell you when within the block it happened, and ordering inside a block comes from the sequence number.

Clock drift

We cannot read a venue's clock directly, but we can watch its offset change. In each 10-minute window we take the 0.1th percentile of latency. That lower envelope is set by the fastest messages, whose network path is close to constant, so movement in the envelope mostly reflects the venue's clock moving against ours.

The step on Venue B is the one that matters for research. For those 40 minutes, any strategy that compared that venue's ts_exchange against another venue's timestamps would have seen its events shift by almost 4 ms with no change in the market. Measured on ts_capture, nothing happened. We saw no negative latencies on any venue from Tokyo, which is a basic check that our clock was never ahead of the events it recorded.

Out-of-order messages

We count two kinds of disorder. Within a channel, a message is out of order if its ts_exchange is earlier than the previous message's in arrival order. Across channels, a trade is out of order if it arrives before the book update that reflects it.

Within a channel, disorder is rare everywhere. Across channels it is routine. Where depth updates are batched and trades are pushed one by one, as on Venue A, the trade usually arrives first. Code that updates a book from the depth stream and then checks it against the latest trade will see an inconsistent state four times in ten. The fix is to order by sequence and venue time, never by arrival.

What two regions add

Before merging, the Tokyo streams were missing between 0.8 (Venue A) and 3.4 (Venue B) messages per million, measured against venue sequence numbers. After merging with Ireland by sequence, the residual was between 0.02 and 0.11 per million, and those residual gaps are what the gaps table records. Ireland delivered a message first for 0.01% to 0.04% of messages depending on venue, almost always during a brief stall on the Tokyo side such as a TCP retransmit. In the merged stream, ts_capture is the earliest receive time across the two regions.

What this means for research

• To ask what could have been known at time t, use ts_capture. Features built on ts_exchange quietly assume zero latency, and on Hyperliquid they assume knowledge of the whole block at its start.
• To order events within one venue, use the sequence number first and ts_exchange second.
• Cross-venue lead-lag on ts_exchange compares four clocks with different offsets and a step change on one of them. On ts_capture from one region the comparison is fair, but the measured lead includes geography. From Tokyo, Venue A appears about 33 ms ahead of Venue C purely from distance.
• Never assume the arrival order of two channels matches the order of the events they describe.

Limits of this measurement

Fourteen days is short, and infrastructure changes. Three of the four venues were measured in a dedicated window, so seasonal effects or any change after May would not show up here. All paths ran over AWS networks, and a capture host in a colocation facility would see different absolute numbers. When further venues join under data agreements with the exchanges, we will repeat the measurement on that capture and publish it alongside the timestamp documentation.

How we record gaps and what we do with them is described in data quality.