Methodology

Every number on this site comes from a script anyone can run. Here's exactly how each benchmark works, from exchange APIs to blockchain settlement, so you can reproduce it or tell us we're wrong.

B1: Exchange REST API latency

We open a single persistent HTTPS connection (keep-alive) to each exchange's public market-data endpoint and issue a fixed number of back-to-back GET requests, timing each with a monotonic clock around send-plus-full-response-read. This mirrors what a running bot experiences after its first connection.

• Handshake excluded from samples. DNS + TCP + TLS setup is done once during warm-up and reported separately as connect_ms, because a live bot pays it once.
• Warm-up requests are discarded. The first few calls prime the connection and any server-side cache.
• Stats. We report min, p50, p95, p99, max, and mean over successful samples. Non-200 responses and errors are excluded from the stats and counted separately.
• Public data only. No API keys, no authentication, no order placement. Only ticker and orderbook reads.
• Politeness. Requests are spaced to avoid tripping rate limits, so absolute throughput is not what's being measured. Per-request latency is.

Latency depends heavily on where the test runs. Each report states its region and date. A single-region snapshot is directional, not gospel; we publish multiple regions where it matters (e.g. the VPS matrix).

B2: Real cost to trade (fees + spread + slippage)

Latency is not the whole cost of a trade. For each US exchange we compute the all-in one-way cost, in basis points, to market-buy a fixed dollar size: the published base-tier taker fee, plus the measured half-spread (mid to ask), plus the measured order-book slippage to fill that size. We measure at two sizes ($10k and $100k) and for two assets (BTC, a deeply liquid case, and SOL, a mid-cap where spread and slippage differ far more by venue), so you can see how the cost scales.

• Read-only. Order-book snapshots only, no orders are ever placed.
• Fees are dated and sourced. Each taker fee records the date it was verified and links to the venue's fee schedule.
• Total = fee + half-spread + slippage. Every component is shown, not just the headline number.

B6: x402 settlement latency (blockchain payment rails)

For agent payments over the x402 protocol, the number that matters is how long a stablecoin micropayment takes to reach true finality on-chain, the point it cannot be reversed, because an x402 endpoint releases the data the moment the payment clears. We submit a real on-chain transaction from a funded account and time it from submit to finality, repeated for a fixed sample count.

• Measured to true finality, not soft confirmation. Where a chain has both (e.g. Solana), we measure the finalized state, not the faster-but-reversible one, so chains compare fairly.
• Identical test per chain. Same sample count, same submit-to-final timing, so the numbers are apples to apples.
• Sequential, one payment at a time. Each transaction is submitted and confirmed before the next goes out, so every sample measures a single payment's own settlement time, the way one x402 request experiences it, not batching or congestion from a burst. Throughput under concurrency is a separate test: we also fire bursts of up to 500 payments at once and measure how finality, fee, and success rate hold up, published on the x402 throughput benchmark.
• Verifiable. The benchmark account and every transaction are public on a block explorer, and the raw data is published under CC BY 4.0.
• Vantage-independent. Unlike API latency, settlement time is a property of the chain's consensus, so where we run it barely matters.

The per-chain measured results and the on-chain proof live on the x402 payment rails page.

What we don't do

• We don't accept payment to change a ranking. Affiliate links never move a row.
• We don't publish a number we can't reproduce on demand.
• We don't present a single run as a universal truth. Dates and sample sizes are always shown.

Reproduce it yourself

The raw JSON behind each report is published with the report, and the benchmark scripts are open. If your numbers differ from ours, that's useful signal. Tell us the region and time and we'll dig in.