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.5ms median	n=4,314
Lighter	10.6ms median	n=4,321
Bullet (via Cloudflare)	12.8ms median	n=4,305
Nado	14.8ms median	n=4,321
Pacifica	18.0ms median	n=4,321
Aster	104ms median	n=4,320

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,314	8.5 ms	29.6 ms	51.6 ms	53.5 ms	0	0	0
Lighter	4,321	10.6 ms	50.5 ms	293 ms	384 ms	21	6	0
Bullet (via Cloudflare)	4,305	12.8 ms	21.1 ms	37.4 ms	70.5 ms	0	0	0
Nado	4,321	14.8 ms	3,926 ms	5,004 ms	8,582 ms	1,108	880	717
Pacifica	4,321	18.0 ms	45.6 ms	78.8 ms	168 ms	1	0	0
Aster	4,320	104 ms	198 ms	306 ms	590 ms	2,496	20	1

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-25 12:47 UTC · 25,902 orders · 6 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.