Fastest on-chain bridge execution: real settlement latency, Mobula vs Relay vs LI.FI vs Near Intents
Real on-chain settlement latency (deposit included to credit observed, ms), success rate and realized fees for executed bridge transactions on a self-conserving USDC triangle (Solana, Base, Arbitrum), at $3 and $30, measured from EU-West.
TL;DR. As of , Mobula posts the lowest execution latency at 1.43 s (p50, 7d) across 4 ranked providers. Source: OpenChainBench, https://openchainbench.com/benchmarks/bridge-execution-latency.
Every other bridge comparison on the internet measures quotes. This one measures the transaction. We run a self-conserving USDC triangle (Solana to Base to Arbitrum and back) with real capital, broadcasting real transfers through Mobula, Relay, LI.FI and Near Intents, and we time each one from the moment the deposit is included on the source chain to the moment the funds are credited on the destination chain. Quotes are a promise; settlement is the truth, and the gap between them is where slippage, failed fills and refunds live. This benchmark reports the real millisecond settlement latency, the success rate (fills versus reverts and refunds) and the realized fee (amount sent minus amount received) at two ticket sizes, $3 and $30, pooled per corridor, measured from EU-West. Inventory is conserved across the cycle, so only fees burn.
Methodology
We execute real cross-chain transfers on a conserving USDC triangle (Solana to Base, Base to Arbitrum, Arbitrum to Solana) through Mobula, Relay, LI.FI and Near Intents, at $3 daily and $30 twice a week. For each executed transaction we record the settlement latency (deposit included to credit observed, in milliseconds), the end-to-end latency (quote to funds received), the realized fee, and whether it settled, reverted, was refunded or got stuck. With one execution per corridor per day, p50, p90 and p99 are derived over a rolling 7-day window (about 7 to 9 executions per bridge and corridor); success rate is fills over fills plus reverts, refunds and stuck deposits. Only settled transactions enter the latency distribution.
Results: 4 providers ranked by Execution latency (p50, 7d)
| № | Providers | p50 | p90 | p99 | Realized fee (bps of ticket) | Slippage vs quote | All-in gas we paid | Success |
|---|---|---|---|---|---|---|---|---|
| 1 | Mobula | 1.43 s | 1.56 s | 1.56 s | 0.18% | -$0.00377 | $0.00731 | 100.00% |
| 2 | Relay | 1.92 s | 2.32 s | 2.32 s | 0.79% | $0.0000037 | $0.00339 | 100.00% |
| 3 | LI.FI | 7.47 s | 14.10 s | 14.10 s | 1.04% | -$0.0000130 | $0.00782 | 100.00% |
| 4 | Near Intents | 34.89 s | 37.92 s | 37.92 s | 0.27% | $0.00823 | $0.0620 | 100.00% |
Frequently asked
How is this different from the bridge quote and bridge fee benchmarks?
Those measure the API response: how fast a quote comes back and what it claims the cost will be. This benchmark broadcasts and settles a real transaction, then measures how long the funds actually took to arrive and what the realized cost was. A provider can quote fast and cheap yet settle slowly or fail, and only an execution benchmark surfaces that.
What does the triangle conserve, and why does it matter?
The route returns every unit of capital to its origin over a full cycle (Solana to Base to Arbitrum to Solana), so the loop can run indefinitely on a fixed float with only fees burning. That is what makes continuous real execution affordable to benchmark.
Why only $3 and $30?
The goal is settlement reliability and latency, which do not require large notionals. Small tickets keep the standing capital and the burned fees low while still exercising the full broadcast, settle and accounting path on every provider.
How is the success rate computed?
Settled transactions divided by settled plus reverted, refunded and stuck, over the last 7 days. A transaction that never broadcast (a pre-flight or quote failure) is not counted against a provider; a broadcast that reverts, is refunded, or never resolves in the 5-minute poll window is.
Where does this run from?
EU-West. The execution node holds a single wallet and signs every broadcast, so running a second origin would race the same inventory. The latency therefore reflects an EU-West vantage; the quote-latency benchmark on this site covers multi-region read latency separately.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/bridge-monitor