Order to confirmation

Timed from order submit to the order appearing on the venue's own account feed, not to an acknowledgement of receipt: confirmation is the point the order is live in the book and can be filled.

Order → Confirmation

Updated just now

3-day windowLower is better

Each mark = one measured order20× slow motion

Order-to-confirmation latency by endpoint: median and number of measured orders.
Endpoint	Median latency	Orders measured
Bullet (direct)	8.2ms median	n=4,315
Lighter	9.6ms median	n=4,317
Nado	10.2ms median	n=4,320
Pacifica	15.8ms median	n=4,319
Bullet (via Cloudflare)	19.6ms median	n=4,315
Aster	107ms median	n=2,167
Hyperliquid	410ms median	n=4,086

Tail latency

Lower is better

Log scaleDashed past p99.9 = slowest order in 1,000

Tail latency by endpoint: measured orders, median, 99th percentile, 99.9th percentile, slowest measured order, and the number of orders slower than 100, 250, 500 milliseconds.
Endpoint	Orders	p50	p99	p99.9	Slowest	Over 100 ms	Over 250 ms	Over 500 ms
Bullet (direct)	4,315	8.2 ms	12.6 ms	31.4 ms	89.9 ms	0	0	0
Lighter	4,317	9.6 ms	18.9 ms	98.2 ms	200 ms	3	0	0
Nado	4,320	10.2 ms	392 ms	2,476 ms	4,183 ms	131	70	35
Pacifica	4,319	15.8 ms	26.8 ms	47.4 ms	228 ms	1	0	0
Bullet (via Cloudflare)	4,315	19.6 ms	38.7 ms	64.3 ms	86.9 ms	0	0	0
Aster	2,167	107 ms	209 ms	259 ms	349 ms	1,517	5	0
Hyperliquid	4,086	410 ms	781 ms	991 ms	1,110 ms	4,086	4,086	567

Quoting means cancelling: every time the price moves, the order resting at the old one has to go. Cancels carry the same tail as orders, so one cancel in a hundred takes at least your p99 to land. Until it lands, your stale quote is still resting where the fastest taker on the other side can lift it. That is latency arbitrage, and it is paid out of your PnL.

The length of each exposure is set by p99, not p50. The frequency is set by your quote rate. Per $1M quoted, one basis point of adverse selection is $100. At 100 orders a second you settle that bill once a second.

What is measured

Window: 72 hours to 2026-09-07 18:09 UTC · 27,839 orders · 7 endpoints
Timed: One interval per order: submit to account-feed confirmation. The cancel that follows is not in it, and neither is signing. No network-floor subtraction, no speed-bump adjustment.
Source: api.mainnet.bullet.xyz/latency
Harness: One m8gd.2xlarge in ap-northeast-1d. One client, one clock, identical for every endpoint.
Orders: One order per measurement, one measurement a minute per endpoint, submitted singly and cancelled once it confirms. Post-only, so it rests or is rejected and never trades. Batch submissions are excluded.
Transport: One WebSocket per endpoint, held open across measurements. No order opens a connection, so no figure here includes a TCP or TLS handshake. What is timed is the venue and the round trip.
Endpoints: Bullet (direct) hits our trading API load balancer with nothing in front of it. Bullet (via Cloudflare) is the same engine behind Cloudflare, which is there to absorb abuse and charges latency and a good deal of jitter for it, so market makers take the direct path.
Volleys: A display grouping on the track. Orders do not arrive synchronised across venues.
Cancels: Measured separately by the same collector and not shown here: a long order tail means a long cancel tail.
Prior art: Inspired by Check the Chain's benchmark. Ours is written from scratch in Rust, so no garbage collector can pause the harness in the middle of a measurement.