Fastest cross-chain bridge quote API, live ms ranking
Time to receive a usable cross-chain quote, in milliseconds. Identical route and identical notional, measured every five minutes across Mobula, deBridge, Relay and LI.FI.
This benchmark measures how fast each cross-chain bridge quote API returns a usable response, the response-time half of the bridge story that fee tables never quote. Builders integrating a swap or bridge flow into a wallet, an aggregator or a chat-app care about the same number every public roundup ignores. how many milliseconds the API burns before the user sees a price. We hammer the same USDC routes (Solana, Base, Arbitrum) against every bridge from a single eu-west point, every five minutes, on three notional sizes. p50, p90 and p99 are computed via Prometheus `histogram_quantile` over the 24-hour window, so the leaderboard reflects sustained API performance, not a lucky cold-start. The same harness records failure mode for every request (quote_failed, unsupported route, timeout) and keeps it out of the latency aggregate, surfacing it as success rate instead so that a fast-but-broken provider cannot game the headline number.
Methodology
We benchmark how long the major bridge APIs take to return a usable cross-chain quote (route + fee + estimated settlement time). The harness cycles through 4 routes × 3 notional sizes × every supported bridge every five minutes, recording p50, p90 and p99 wall-clock latency along with the success rate. Quotes that error or return unsupported responses are excluded from latency aggregates and counted toward success rate.
Frequently asked
Which cross-chain bridge has the lowest API latency?
{{best_name}} currently leads the cross-corridor aggregate at {{best_p50}} (p50, 24 h) across {{count}} measured bridges, averaged over the 4 USDC routes the harness sweeps. The leaderboard re-sorts every five minutes against fresh Prometheus samples, so the ranking reflects the last 24 hours of actual API performance from a single eu-west origin under the same routes. Per-corridor latency leaders can differ from this aggregate where one provider has a solver pool closer to a specific destination chain, that breakdown is on the roadmap once corridor dimensions are surfaced in the page UI.
What is the difference between quote latency and bridge fill time?
Quote latency is the wall-clock time the bridge API takes to return a price. Fill time is the wall-clock time the funds take to land on the destination chain after the user signs. They are decoupled: a bridge can quote in 100 ms and take 30 seconds to settle, or quote in 2 seconds and settle in 5 seconds. This benchmark measures the quote half because that is the part a wallet, an aggregator or an embedded swap UI feels first and tunes its UX around.
Why does bridge quote latency matter for builders?
Every product that integrates a bridge sits behind that API. Wallets, aggregators, intent layers, chat-app swap modals. A 1500 ms p99 forces a long loading spinner; a 5000 ms p99 forces a timeout fallback. The number controls perceived UX, time-to-first-quote in side-by-side comparators, and how aggressively the integrator has to parallelise calls across bridges to mask the slowest one.
Are intent and relay bridges always faster than aggregators?
On a single-route query, usually. Intent layers like Relay quote against a pool of pre-positioned solvers, so the API is a thin price-discovery call. Aggregators like LI.FI run a route-search graph over N underlying bridges per request, which adds 100 to 400 ms of irreducible work. On multi-hop or rare-corridor queries the aggregator advantage in coverage matters more than the latency gap, and the comparison flips.
How does OpenChainBench measure bridge quote latency?
The harness issues identical quote requests against every bridge for the same route and notional, every five minutes, from a single eu-west origin. Each request times wall-clock duration from send to last byte received, then publishes a Prometheus histogram (50, 100, 200, 500, 1000, 2000, 5000, 10000 ms buckets). p50, p90 and p99 are derived via `histogram_quantile` over a rolling 24-hour window. Errored quotes (quote_failed, unsupported route, timeout) are excluded from the latency aggregate and counted toward success rate so a fast-but-broken bridge cannot game the headline.
Does quote latency affect the price the user gets?
Indirectly, yes. A slower quote API leaves a larger window between the moment the price is quoted and the moment the user signs. On volatile corridors the underlying spot can drift in that window, which surfaces as a quoted-vs-realized gap. Intent layers compensate by re-quoting at signing time; aggregators usually pass through a slippage parameter. The fee benchmark on this site (`/benchmarks/bridge-fee`) measures the realized cost; this page measures the latency half of the same flow.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/bridge-monitor