One server in Europe, listening at DoubleZero’s Frankfurt edge. Kalshi sits in AWS us-east-2, an ocean away — 106 ms round trip from here, against 2.9 ms to the DoubleZero edge.
Kalshi stamps the trade
the execution timestamp the venue puts in the message
—
until DoubleZero stamps the frame it sends
DoubleZero sends the frame
the send timestamp in the frame header
—
in flight, by those two stamps
The packet lands on our network card
stamped by the kernel, on a clock we check against public time servers
Venue stamp → our network card, over DoubleZero
—
Where every trade landed
DoubleZero
public WebSocket
| Latency, venue stamp to our card |
P50 | P90 |
P95 | P99 | Max |
A US-East to Frankfurt hop cannot beat about 43–47 ms through real fibre, so the floor of this chart is physics, not engineering. The tail is where the two paths part company.
How this is measured
- The DoubleZero side
- Multicast group 233.84.178.3, Top-of-Book & Trades, taken off the doublezero1 tunnel with AF_PACKET. DoubleZero reports the edge device as fr2-dzx-001, metro Frankfurt; the tunnel peer resolves to Frankfurt am Main.
- The public side
- Kalshi’s own perpetuals WebSocket, external-api-margin-ws.kalshi.com, which anyone can connect to.
- Arrival
- The kernel’s SO_TIMESTAMPNS stamp, taken as the packet lands on the interface, not a clock read after our code wakes up.
- Sample
- Only trades seen on both feeds, joined on the venue timestamp, price and size, so the two rows describe the same prints.
- Limits
Measuring… the first matched trades are still coming in.