# OpenChainBench live state > Auto-refreshed every 60s · last fetch 2026-07-26T22:56:35.155Z · license CC-BY-4.0 OpenChainBench publishes open, reproducible benchmarks for crypto infrastructure. Cite as: "according to OpenChainBench" with the page URL. The numbers below come from the same Prometheus that powers https://openchainbench.com. ## Fastest crypto price API, live head lag across Mobula, Codex, GeckoTerminal - Category: Aggregators - Metric: Head lag (s) - Page: https://openchainbench.com/benchmarks/aggregator-head-lag - JSON: https://openchainbench.com/api/stat/aggregator-head-lag - Status: live - Headline: Codex leads head lag at 0.8 s (p50, 24h) on Fastest crypto price API, live head lag across Mobula, Codex, GeckoTerminal. **Rankings (p50, 24h):** 1. Codex: 0.8 s (p99 1.4 s, success 97.4%, sample 65746) 2. Mobula: 1.5 s (p99 5.3 s, success 97.4%, sample 67340) 3. GeckoTerminal: 12 s (p99 44 s, success 97.4%, sample 67340) **Methodology**: - Aggregators measured: Mobula, Codex, GeckoTerminal. - Chains: Base, BNB Chain, Solana, Robinhood Chain. - Regions: us-east, eu-west, sgp. Cross-region median reported in the headline. - Reference: archive nodes per chain, validated against block hashes. - Metric: gauge `head_lag_seconds`, sampled every 15 seconds. Aggregated over the 24-hour window using `quantile_over_time`. - Success rate: presence ratio. Share of expected sampling slots where a value was actually emitted (5,760 expected per provider per day at the 15s cadence). 100% means the aggregator's feed was reachable for the full window. - Cardinality: 3 aggregators × 4 chains × 3 regions = 36 active series. ## Fastest cross-chain bridge quote API, live ms ranking - Category: Bridges - Metric: Quote latency (ms) - Page: https://openchainbench.com/benchmarks/bridge-quote-latency - JSON: https://openchainbench.com/api/stat/bridge-quote-latency - Status: live - Headline: Mobula leads quote latency at 195 ms (p50, 24h) on Fastest cross-chain bridge quote API, live ms ranking. **Rankings (p50, 24h):** 1. Mobula: 195 ms (p99 9.37 s, success 77.9%, sample 3361.58) 2. deBridge: 281 ms (p99 5.08 s, success 99.9%, sample 3452.6) 3. Near Intents: 500 ms (p99 4.94 s, success 100.0%, sample 1728.3) 4. Relay: 935 ms (p99 4.40 s, success 98.9%, sample 4272.74) 5. LI.FI: 1.53 s (p99 4.82 s, success 100.0%, sample 4319.75) **Methodology**: - Routes: USDC pairs spanning Solana, Base and Arbitrum. - Notional sizes: $5, $50, $300 per quote. - Cadence: full sweep (4 routes × 3 amounts × N bridges) every 5 minutes for 24 hours. - Region: eu-west. Single point of measurement; multi-region requires running additional monitor instances. - Histogram buckets: 10, 25, 50, 100, 200, 500, 1000, 2000, 5000, 10000 ms. Sub-50ms buckets added 2026-07-13 so solver-cached fast paths (Near Intents on HyperCore in particular) surface their true p50 instead of being floored at the interpolation of the (0, 50] bucket. - Failures (quote_failed, execution_failed, unsupported route) excluded from latency aggregates and counted toward success rate. ## Cheapest cross-chain bridge for USDC at $300 notional - Category: Bridges - Metric: Effective fee (pct) - Page: https://openchainbench.com/benchmarks/bridge-fee - JSON: https://openchainbench.com/api/stat/bridge-fee - Status: live - Headline: Near Intents leads effective fee at 0.057% (24h avg) on Cheapest cross-chain bridge for USDC at $300 notional. **Rankings (p50, 24h):** 1. Near Intents: 0.057% (p99 0.058%, success 100.0%, sample 11518) 2. Relay: 0.13% (p99 0.15%, success 100.0%, sample 23036) 3. Across: 0.14% (p99 0.14%, success 66.7%, sample 17277) 4. Mobula: 0.22% (p99 0.22%, success 97.6%, sample 23036) 5. LI.FI: 0.47% (p99 0.83%, success 100.0%, sample 23036) 6. deBridge: 0.91% (p99 0.97%, success 100.0%, sample 17277) **Methodology**: - Routes: USDC pairs spanning Solana, Base and Arbitrum. - Reference notional: $300 USDC. Smaller sizes ($5, $50) are captured by the harness but excluded from this report. - Cost: `bridge_cost_percent{amount_usd="300"}`, in percent of notional. Includes fees + slippage + destination gas. - Cadence: full sweep every 5 minutes for 24 hours. - Aggregation: the headline number is the average of per-corridor 24h medians over the corridors a provider actually quotes. The TRUMP to BRETT calibration route is excluded. Near Intents has no USDT legs, so its aggregate covers the Solana to Base and Arbitrum to HyperCore corridors only. deBridge does not quote the Arbitrum to HyperCore corridor, so its aggregate covers the remaining three. Across also skips Arbitrum to HyperCore, so its aggregate covers the same three corridors as deBridge. - Normalization: cost is quoted USD in minus quoted USD delivered, the same all-in definition for every provider. Near Intents bundles the destination chain withdrawal fee into its quoted amountOut (the 1Click API documents withdrawFee as already deducted), so no extra gas term is added on top. - Region: eu-west. Single point of measurement; multi-region requires running additional monitor instances. - Failures (quote_failed, unsupported route) excluded from cost aggregates and counted toward success rate. - Provider types are surfaced as badges: direct protocols (deBridge) charge their own bridging fees; aggregators (LI.FI) route through whichever underlying bridge is cheapest, so their effective fee includes that bridge's cost plus any aggregator markup; intent / relay layers (Mobula, Relay, Across, Near Intents) bake cost into the spread of a settlement intent or optimistic fill rather than charging an explicit fee. - Excluded by design: Stargate, because its keyless quote endpoint was deprecated in favor of a key-gated LayerZero API, and its on-chain quoteOFT path is same-asset EVM-only, which matches none of this bench's corridors. CCTP, because Circle's burn/mint has no quote that returns a delivered amount; standard transfers mint 1:1 and the whole cost is user-paid gas we would have to estimate ourselves, which breaks the quoted USD in minus quoted USD delivered definition used for every other row. ## Best crypto data API for token metadata, live across Mobula, Codex, Jupiter - Category: Aggregators - Metric: Field coverage (pct) - Page: https://openchainbench.com/benchmarks/metadata-coverage - JSON: https://openchainbench.com/api/stat/metadata-coverage - Status: live - Headline: Mobula leads field coverage at 64.9% (24h avg) on Best crypto data API for token metadata, live across Mobula, Codex, Jupiter. **Rankings (p50, 24h):** 1. Mobula: 64.9% (p99 72.1%, success 100.0%, sample 90651.7) 2. Codex: 64.7% (p99 72.8%, success 100.0%, sample 90651.7) 3. Jupiter: 0.64% (p99 25.0%, success 100.0%, sample 76897.4) **Methodology**: - Token discovery: Mobula Pulse V2 WebSocket on `solana`, `evm:56` (BNB), `evm:8453` (Base) for known launchpads (pump.fun, Meteora DBC, Four.meme, Raydium CPMM, Zora, BaseApp, Bags, Moonshot). - Coverage check: for each fresh token, query each aggregator's metadata endpoint and record whether `logo`, `description`, `twitter` and `website` are populated. - Aggregators in scope: Mobula (`/api/2/token/details`), Codex (GraphQL `token` query, JWT-authenticated), Jupiter (`/v6/tokens/`, Solana only). - Cadence: queue-driven; every newly-discovered token is checked once across the three aggregators. Steady-state ≈ several hundred checks per provider per hour. - Region: single probe origin (one monitor instance on our infrastructure). The bench intentionally declares no region dimension; multi-region would require additional monitor instances and is not currently planned. - Ratio: `metadata_coverage_success_total / metadata_coverage_checks_total`, expressed in percent. Failures of the metadata API itself (timeouts, 5xx) are not counted in the denominator. only successful responses with the field check applied. - Jupiter is Solana-only. it appears with zero coverage on EVM chains by construction; the cross-chain headline excludes Jupiter on chains it does not support. ## Crypto data API with most blockchains in asset registry, live coverage ranking - Category: Aggregators - Metric: Asset-registry chains (count) - Page: https://openchainbench.com/benchmarks/asset-registry-coverage - JSON: https://openchainbench.com/api/stat/asset-registry-coverage - Status: live - Headline: CoinGecko leads asset-registry chains at 461 (24h) on Crypto data API with most blockchains in asset registry, live coverage ranking. **Rankings (p50, 24h):** 1. CoinGecko: 461 (p99 461, success 100.0%, sample 461) 2. CoinPaprika: 307 (p99 307, success 100.0%, sample 307) 3. Mobula: 81 (p99 81, success 100.0%, sample 81) **Methodology**: - Source: each provider's public asset-registry endpoint. - CoinGecko: GET /api/v3/asset_platforms (public, no auth). Every chain CoinGecko can look up tokens on by contract address. - CoinPaprika: GET /v1/contracts (no auth). Lists every platform supported for contract-address lookup. - CoinStats: GET /wallet/blockchains with X-API-KEY. Chains CoinStats indexes for wallet portfolio and token metadata. - Mobula: GET /api/1/blockchains with an Authorization key. Chains Mobula covers for token metadata + market data. - Cadence: full refresh every 6 hours. - Counting: one count per unique chain (platform slug or chain id, whichever the provider exposes); mainnet only. - Failures (network errors, rate limits, auth errors) leave the previous count in place and increment a fetch_errors counter. the page falls back to its last successful sample. ## Fastest L1 blockchain finality, live across 11 chains - Category: Blockchains - Metric: Finality time (s) - Page: https://openchainbench.com/benchmarks/l1-finality - JSON: https://openchainbench.com/api/stat/l1-finality - Status: live - Headline: Gram leads finality time at 0.4 s (p50, 24h) on Fastest L1 blockchain finality, live across 11 chains. **Rankings (p50, 24h):** 1. Gram: 0.4 s (p99 1.4 s, success 98.9%, sample 190610) 2. SUI: 0.5 s (p99 0.5 s, success 100.0%, sample 171223) 3. BNB: 1.1 s (p99 1.9 s, success 99.8%, sample 191521) 4. Avalanche: 1.6 s (p99 5.7 s, success 100.0%, sample 80951.1) 5. Stellar: 7.1 s (p99 11 s, success 100.0%, sample 12805.2) 6. Solana: 14 s (p99 16 s, success 100.0%, sample 5759) 7. TRON: 57 s (p99 1.0 min, success 100.0%, sample 5759) 8. Ethereum: 15.9 min (p99 19.0 min, success 100.0%, sample 5759) 9. Monero: 18.3 min (p99 34.4 min, success 100.0%, sample 5759) 10. Litecoin: 30.6 min (p99 52.5 min, success 100.0%, sample 5759) 11. Bitcoin: 51.5 min (p99 113.0 min, success 100.0%, sample 139.024) **Methodology**: - Cadence: every 10 seconds for HTTP-polled chains, continuous WS for BNB and Avalanche. - Ethereum: `eth_getBlockByNumber("latest")` minus `eth_getBlockByNumber("finalized")`. - BNB / Avalanche (WS wall-clock): persistent `eth_subscribe("newHeads")` records T1 = first time block N is seen as latest. Periodic `eth_getBlockByNumber("finalized")` over same WS records T2 when N becomes finalized. lag = T2 − T1, ms precision, independent of chain timestamp resolution. - Solana: `getSlot{commitment:"processed"}` + `getBlockTime` minus `getSlot{commitment:"finalized"}` + `getBlockTime`. - TRON: `/wallet/getnowblock` (head) minus `/walletsolidity/getnowblock` (solidity-confirmed). - Stellar (SSE wall-clock): Horizon `/ledgers?cursor=now&order=asc` event-stream records T1 on first sight of ledger N and T2 on the next ledger close (SCP-final at every close). - SUI: `sui_getLatestCheckpointSequenceNumber` minus 5 checkpoints back. - Gram: wall-clock lag of the tonapi.io masterchain head. Masterchain blocks are BFT-final at production, so head commit lag is the finality figure; the chain produces a block about every 0.4s since the accelerated upgrade. - Bitcoin (probabilistic, own-clock): mempool.space `/blocks/tip/height` polled every 30 s. T1 = first poll where block N is the tip, T2 = first poll where tip − N ≥ 6 (the exchange deposit convention). lag = T2 − T1 on the harness clock; miner-set block timestamps (consensus allows 2h skew) are never used. The startup tip is not timed. On a tip regression, pending timers above the new tip are dropped; same-height reorgs are invisible to height polling, bounding error to about one block interval. - Litecoin (probabilistic): blockchair `/stats.best_block_height` minus 6 confirmations via `/dashboards/block/{height}.block.time`. - Monero (probabilistic): monero-rpc `get_info` minus 10 confirmations via `get_block_header_by_height`. - Hedera (planned, currently disabled): mirror-node `/api/v1/blocks` only exposes already-final blocks, so true wall-clock lag is impossible from public endpoints. Re-enables once Block Nodes (HIP-1056) leave private preview. - Result: `lag_seconds = headTimestamp - finalizedTimestamp`. We also record the block-height delta and per-chain fetch latency. - Excluded by design: XRP (no close-time on `ledger_current`, wall-clock measurement requires WS subscribe to ledger stream, not yet implemented). - Failures (5xx, timeouts, rate limits) leave the previous gauge in place and increment a per-chain `fetch_errors_total` counter; the page falls back to the last successful sample. ## Cheapest perp DEX, live all-in cost from $1k to $1M on ETH, BTC and SOL - Category: Trading - Metric: All-in cost (bps) - Page: https://openchainbench.com/benchmarks/perp-fees - JSON: https://openchainbench.com/api/stat/perp-fees - Status: live - Headline: Lighter leads all-in cost at 0.0023% (24h avg) on Cheapest perp DEX, live all-in cost from $1k to $1M on ETH, BTC and SOL. **Rankings (p50, 24h):** 1. Lighter: 0.0023% (p99 0.0072%, success 100.0%, sample 5759) 2. Extended: 0.026% (p99 0.031%, success 99.7%, sample 5759) 3. Paradex: 0.037% (p99 0.053%, success 100.0%, sample 5759) 4. gains.trade: 0.040% (p99 0.040%, success 100.0%, sample 5759) 5. Polymarket: 0.041% (p99 0.055%, success 100.0%, sample 5759) 6. Hyperliquid: 0.046% (p99 0.046%, success 100.0%, sample 5759) 7. Aster: 0.050% (p99 0.054%, success 100.0%, sample 5759) 8. dYdX v4: 0.052% (p99 0.068%, success 100.0%, sample 5759) **Methodology**: - Cadence: every 5 minutes, in parallel across all venues. - Trade simulated: a long at 10x, measured independently on ETH, BTC and SOL (the chain tabs scope the board; the unfiltered view averages the three). Headline notional $1,000 with $10k, $100k and $1M tiers rewalked on the same book. - Hyperliquid: `POST /info {type: l2Book}` for asks + `{type: userFees, user: 0x000...000}` for taker fee + `{type: metaAndAssetCtxs}` for funding. - dYdX v4: indexer `/orderbooks/perpetualMarket/ETH-USD` + `/perpetualMarkets` (funding) + Cosmos REST `/dydxprotocol/v4/feetiers/perpetual_fee_params` for tier-0 default fee. - GMX v2 (Arbitrum): Subsquid GraphQL on the synthetics-arbitrum subgraph for `positionFeeFactorForNegativeImpact` (worst-case open) on the ETH/USD, BTC/USD and SOL/USD markets + gmxinfra REST for funding. Oracle priced, no orderbook: the spread term is zero. - Lighter: `/orderBookDetails` (taker fee per market) + `/orderBookOrders` (orderbook walk). - gains.trade (Gains v8 on Base): fees read directly on-chain. `eth_call pairs(N)` gives `spreadP` and `feeIndex`, then `eth_call fees(feeIndex)` gives the open fee (`totalPositionSizeFeeP`). The taker crosses one side of the book, so we charge half of `spreadP`. SOL has `spreadP` 0 on-chain (Gains prices that pair's spread dynamically), so its figure is the open fee alone. Values in 1e10 precision per Gains v8 convention. Fee tier cached 1h, pair config 6h. - Paradex: `/markets` fee config for the api-tier taker rate + `/orderbook?depth=100` walk. The book endpoint caps at 100 levels (about $1M visible on majors), so the $1M tier can be skipped when the visible book thins. - Extended: full public book from `/info/markets//orderbook` + `/stats` funding (1h native). Its taker fee is not exposed by any public endpoint; the documented base rate of 2.5 bps is used and this is the one venue where the fee is not read live. - All-in formula: `all_in_bps = taker_fee_bps + spread_bps`. Both components emitted as separate metrics for transparency. - Notional tiers: the same measurement runs at $1,000, $10,000, $100,000 and $1,000,000 by rewalking the already fetched book, published to `perp_fees_all_in_bps_tier{venue, chain, notional}`. The headline `perp_fees_all_in_bps` stays defined at $1,000. A tier the book cannot fill is skipped and counted in `perp_fees_tier_skipped_total`, never extrapolated. Oracle priced venues (GMX v2, gains.trade) charge a flat percentage of size, so their figure repeats across tiers. - Book depth for the $1M tier: Lighter is walked on its top 100 levels, dYdX on the full indexer book, Polymarket on up to 500 levels. Hyperliquid returns its 20 best raw levels; when those cannot absorb the tier the harness refetches with nSigFigs=5, the finest price aggregation the API offers, which extends coverage with negligible price rounding. - Failures (5xx, timeouts, rate limits) leave the previous gauge in place and increment a per-venue `fetch_errors_total` counter. The page falls back to the last successful sample. ## Best wallet labeling API provider - Category: Aggregators - Metric: Coverage rate (pct) - Page: https://openchainbench.com/benchmarks/wallet-labels-coverage - JSON: https://openchainbench.com/api/stat/wallet-labels-coverage - Status: live - Headline: Helius leads coverage rate at 84.1% (24h avg) on Best wallet labeling API provider. **Rankings (p50, 24h):** 1. Helius: 84.1% (p99 84.1%, success 100.0%, sample 920.16) 2. StellarExpert: 80.1% (p99 80.1%, success 80.1%, sample 483.084) 3. XRPScan: 79.8% (p99 79.8%, success 89.9%, sample 486.084) 4. Blockscout: 56.4% (p99 56.4%, success 98.4%, sample 4021.7) 5. OLI: 50.4% (p99 50.4%, success 100.0%, sample 5581.97) 6. Moralis: 44.2% (p99 44.2%, success 99.9%, sample 1315.23) 7. Mobula: 43.5% (p99 43.5%, success 99.4%, sample 8639.5) 8. TonAPI: 35.9% (p99 35.9%, success 78.8%, sample 683.119) 9. WalletExplorer: 15.9% (p99 15.9%, success 80.2%, sample 485.084) **Methodology**: - Sample: ~180 curated anchor addresses across 11 chains (CEX hot wallets, DEX routers, Safe multisigs, OFAC SDN, public figures, verified smart contracts), shuffled and re-checked every 30 minutes. List rotated quarterly from public sources. - Each anchor is tagged with a kind: `contract` (verified smart contracts where a non-generic name comes from source code) or `eoa` (externally-owned accounts where the name must come from a curated entity graph). The kind is set at curation time using an on-chain code probe (eth_getCode for EVM, equivalent RPC for non-EVM). - Kind tab on the bench page: `contract` measures contract-name resolution (easy for any explorer reading verified source), `eoa` measures entity resolution on plain wallets (the curated-graph job). The two views are separate Prometheus queries with `kind="contract"` and `kind="eoa"` injected into every selector. - Query each provider's labels endpoint live: Mobula `/api/2/wallet/labels`, Helius `/v1/wallet/{addr}/identity`, Moralis `/api/v2.2/entities`, Blockscout `/api/v2/addresses/{addr}`, OLI Base EAS GraphQL, TonAPI `/v2/accounts/{addr}`, StellarExpert `/explorer/directory/{addr}`, XRPScan `/api/v1/account/{addr}`, WalletExplorer `/api/1/address-lookup`. - A provider scores 'hit' when it returns a non-generic entity name. Filler labels like 'EOA', 'Contract', 'Wallet', 'Multisig', 'Unknown' are explicitly excluded, they carry no entity signal. - Per-chain leaderboards. providers are filtered by their declared chain support, so Helius (Solana-only) doesn't get penalized on Ethereum and vice versa. - Failures (timeouts, 5xx, auth errors) are counted as 'no label' and surfaced separately as `wallet_labels_fetch_errors_total`. - Region: `eu-west` (single point). ## Fastest L2 block time, live across Robinhood, Arbitrum, Base and 7 more - Category: Blockchains - Metric: Block time (ms) - Page: https://openchainbench.com/benchmarks/l2-block-time - JSON: https://openchainbench.com/api/stat/l2-block-time - Status: live - Headline: Robinhood Chain leads block time at 80 ms (p50, 24h) on Fastest L2 block time, live across Robinhood, Arbitrum, Base and 7 more. **Rankings (p50, 24h):** 1. Robinhood Chain: 80 ms (p99 195 ms, success 100.0%, sample 861317) 2. Arbitrum One: 272 ms (p99 498 ms, success 99.9%, sample 344411) 3. Mantle: 1.77 s (p99 2.97 s, success 100.0%, sample 43200.5) 4. Optimism: 1.91 s (p99 2.98 s, success 100.0%, sample 43199.5) 5. Base: 1.93 s (p99 2.98 s, success 100.0%, sample 43199.5) 6. Blast: 1.98 s (p99 2.98 s, success 100.0%, sample 43200.5) 7. Taiko: 1.98 s (p99 2.99 s, success 100.0%, sample 43196.5) 8. Scroll: 4.32 s (p99 59.50 s, success 99.8%, sample 9700.68) 9. zkSync Era: 4.57 s (p99 53.60 s, success 99.6%, sample 10660.9) 10. Linea: 5.57 s (p99 45.53 s, success 99.9%, sample 10154.8) **Methodology**: - Robinhood Chain exception: the sequencer exposes no public WebSocket, so its block time is derived from eth_blockNumber deltas polled every 2 seconds over HTTP. A window that advanced N blocks contributes N samples of (elapsed / N) ms, which preserves per-block weighting and yields an accurate average; per-block jitter is not captured on this chain and this note is the disclosure. - Cadence: continuous WebSocket subscription per L2, one persistent connection, no polling. - Subscribe payload: `{"jsonrpc":"2.0","id":1,"method":"eth_subscribe","params":["newHeads"]}`. No API key, public endpoints (publicnode.com mostly, era.zksync.io/ws for zkSync). - Sample: block-time(N) = T_recv(N) − T_recv(N-1), measured in milliseconds with `time.Now()` precision on the harness clock. Block-number duplicates from the same connection are filtered. - Sanity bound: any single sample > 5 min is dropped (reconnect artifact, never a real block-time). - Reconnect logic: exponential backoff 2 s → 60 s on dial / read errors. Per-chain `l2_block_time_reconnects_total` counter exposed for instability alerting. - Endpoint health: client-side ping every 30 s defensive against idle close, pong handler resets the read deadline. publicnode and era.zksync.io endpoints verified live for 90-second windows during harness inception (full table in the harness README). - Excluded by design: Polygon zkEVM and Mode (no public no-key WS available, would require an API-keyed contributor endpoint; deferred to v2). Starknet excluded, Cairo stack with a different RPC shape, would live in its own bench. ## Fastest free public RPC for Ethereum, BNB, Polygon and 23 more chains (plus Solana and Polkadot) - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/rpc-capabilities - JSON: https://openchainbench.com/api/stat/rpc-capabilities - Status: live - Headline: Binance leads rpc latency at 73 ms (p50, 24h) on Fastest free public RPC for Ethereum, BNB, Polygon and 23 more chains (plus Solana and Polkadot). **Rankings (p50, 24h):** 1. Binance: 73 ms (p99 396 ms, success 100.0%, sample 4279.74) 2. PublicNode: 144 ms (p99 518 ms, success 100.0%, sample 123765) 3. dRPC: 172 ms (p99 538 ms, success 72.0%, sample 132158) 4. Avalanche: 178 ms (p99 323 ms, success 100.0%, sample 4311.75) 5. Lava: 243 ms (p99 1.93 s, success 99.7%, sample 21209.7) 6. Base: 246 ms (p99 371 ms, success 100.0%, sample 4341.75) 7. Nodies: 247 ms (p99 389 ms, success 66.8%, sample 25730.5) 8. Arbitrum: 251 ms (p99 332 ms, success 100.0%, sample 4345.75) 9. MeowRPC: 269 ms (p99 485 ms, success 96.8%, sample 8567.49) 10. Tenderly: 314 ms (p99 364 ms, success 100.0%, sample 105513) 11. Optimism: 331 ms (p99 368 ms, success 99.9%, sample 4321.92) 12. Flashbots: 683 ms (p99 995 ms, success 100.0%, sample 4321.75) **Methodology**: - Cadence: every 60 seconds per (provider, chain) pair, from each of 3 Railway replicas (us-east Virginia, eu-west Amsterdam, sgp Singapore). The harness stamps a `region` label on every metric from `$RAILWAY_REPLICA_REGION`. Headline p50/p90/p99 are the mean of per (chain, region) `quantile_over_time` cells: all 3 regions, and on the All chains tab every chain the provider serves. Per-region breakdowns are on the time-series chart. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side `time.Now()` delta around the round-trip, in milliseconds. Exposed as both a gauge (`rpc_latency_milliseconds`) and a histogram (`rpc_latency_milliseconds_histogram`) with buckets 50 ms → 10 s, so p50/p90/p99 are computed via Prometheus `histogram_quantile` / `quantile_over_time`. Latency is recorded only for calls classified `ok`; failed calls never enter the latency distribution, so every percentile is conditional on success. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err` (status ≠ 200 or transport failure), `jsonrpc_err` (HTTP 200 with an `error` field, the Cloudflare-eth trap), `stale` (returned block more than 20 behind the cross-provider tip for that chain), `timeout`. Counter `rpc_call_total{result}` powers the reliability leaderboard. - Success gating: because failed probes record no latency, a mostly failing endpoint can post a fast p50 from its rare successes. The ledger pairs every latency figure with a Success column computed as ok calls over total calls in the same 24h window; read rows below 50 percent success as degraded. Providers with under 5 percent success lose their latency series to Prometheus staleness and are pinned below the table as unresponsive instead of being ranked. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head, depth) for `depth` in {300, 7200, 216_000, 1_296_000, 5_000_000}. Gauge `rpc_archive_depth_supported{depth}` is 1 when the response is non-pruned, 0 otherwise. The 300/7200 thresholds cover Geth's default pruned-cap range; 216k ≈ 1 month; 1.3M ≈ 6 months; 5M ≈ genesis-era full archive. - Chain coverage: 26 chains (24 EVM plus Solana and Polkadot). EVM majors: Ethereum, Arbitrum, Base, Optimism, Avalanche, BNB, Polygon, Linea, Scroll, Mantle. EVM long-tail: Sonic, Gnosis, Celo, Blast, Taiko, Moonbeam, Berachain, zkSync, Cronos, Fraxtal, Unichain, Soneium, Monad, MegaETH. Non-EVM: Solana (getSlot probe), Polkadot (chain_getHeader probe). Provider matrix per chain is documented in `harnesses/rpc-capabilities/cmd/script/config.go`. - Excluded: 1RPC (delisted 2026-07-09, under 13% success even at two chains and one probe per minute), Ankr (key-gated), gateway.fm (29 req/IP budget too tight for 15s polling), LlamaRPC + BlockPI + OmniaTech (Cloudflare 521 region-blocked), Alchemy demo (rate-limited dead), NodeReal + GetBlock + Chainstack (key-gated). Blink, formerly Merkle (no public eth_getBlockByNumber) + Lava and MeowRPC outside ETH/Arb excluded. Every (provider, chain) was live-verified no-key before inclusion. ## Most accurate gas oracle, live gap vs realized priority fee - Category: RPCs - Metric: Gap vs realized (gwei) (gwei) - Page: https://openchainbench.com/benchmarks/gas-estimation - JSON: https://openchainbench.com/api/stat/gas-estimation - Status: live - Headline: Owlracle leads gap vs realized (gwei) at ~0 gwei (p50, 24h) on Most accurate gas oracle, live gap vs realized priority fee. **Rankings (p50, 24h):** 1. Owlracle: ~0 gwei (p99 ~0 gwei, success 50.2%, sample 4935.64) 2. PublicNode: 0.010 gwei (p99 0 gwei, success 94.8%, sample 24629.7) 3. MetaMask: 0.010 gwei (p99 0 gwei, success 100.0%, sample 18253.9) 4. Etherscan: 0.015 gwei (p99 0 gwei, success 96.2%, sample 13931.2) **Methodology**: - Chains: Ethereum (chainid=1), Polygon PoS (chainid=137), Arbitrum One (chainid=42161). Ethereum and Polygon are EIP-1559 with dynamic base fee. Arbitrum is included as an L2 reference where priority fee converges to ~0 (centralised sequencer, no MEV auction); the bench shows this empirically. Actually-meaningful L2 cost is L1 data fee, planned for a separate bench. BNB Chain excluded (not EIP-1559). Avalanche C-Chain also collapses to ~0 priority. - Oracles per chain. Ethereum + Polygon: PublicNode feeHistory, Owlracle, Etherscan v2 (free tier), MetaMask. Avalanche: same set minus Etherscan (free plan restricted for chainid 43114). - Per-oracle endpoints. PublicNode `eth_feeHistory` on each chain's RPC; Owlracle `/v4/{eth|poly|avax}/gas` (slug per chain); Etherscan v2 `?chainid=&module=gastracker&action=gasoracle`; MetaMask `gas.api.cx.metamask.io/networks//suggestedGasFees` (public no-key, EIP-1559 low/medium/high mapped to p25/p50/p90). - Cadences. PublicNode feeHistory and MetaMask every 12s per chain; Owlracle every 60s per chain (free quota ceiling); Etherscan every 15s per chain with a global rate-gate enforcing ≥6s between any two Etherscan requests across chains (no-key limit is 1 req/5s per IP, shared). - Tier normalization. Each oracle's named tiers (fast / standard / slow / safe / propose) are mapped onto a unified p25 / p50 / p75 / p90 / p99 scheme. The leaderboard ranks the p50 tier (the standard speed wallets use by default). - Realized priority fee. For each pending block, the harness pulls the full block via `eth_getBlockByNumber(.., true)` on the chain's primary RPC and computes p25/p50/p75/p90/p99 directly from the actual effective `maxPriorityFeePerGas` values across every included transaction. Every tier is a real percentile of the mined block, none are interpolated. Empty or low-tx blocks (`gas_realized_tx_count` near zero) are surfaced separately because the realized percentile is noisy when tx count is low. - Realized-side independence check. Each chain configures a second RPC on a different upstream (dRPC / native chain RPC) as `GAS_REALIZED_RPC_VERIFY_`; on each block the harness cross-checks baseFee and increments `gas_realized_quorum_disagreement_total{chain, kind}` on mismatch. Primary is still trusted; the counter makes visible whether our ground truth is actually independent across upstreams. - Realized base fee. Recorded for completeness as `gas_realized_base_gwei{chain}` and per-oracle baseFee error as `gas_error_base_gwei{oracle, chain}`. Not the ranking signal since every EIP-1559 oracle inherits this from `eth_feeHistory` and converges. - Pending buffer. Per (oracle, chain) in-memory map of predictions waiting on a realized block. TTL is ~25 blocks (~5 minutes on Ethereum, ~50 seconds on Polygon due to faster blocks). Beyond that, predictions are dropped as no-longer-informative. Buffer growth surfaces via `gas_pending_buffer_size{oracle, chain}`. - Polling result classification. `ok`, `http_err`, `parse_err`, `throttled` (HTTP 429 or oracle-specific quota message), `timeout`. Counter `gas_oracle_call_total{oracle, result, chain}` powers the reliability column. - Ranking metric. The table ranks on the p99 of the absolute gap over 24h, not the p50. At current fee levels the typical-minute gaps are fractions of a micro-gwei apart across oracles (ranking noise); the p99 captures behaviour during the volatile minutes where a wrong prediction either overpays or misses the block. The typical p50 and p90 gaps stay visible as secondary columns. - Prediction age disclosure. `gas_prediction_age_seconds{oracle, chain}` records the wall-clock time between an oracle's poll returning and the realized block being graded. This surfaces the free-tier cadence asymmetry (Owlracle at 60s vs PublicNode at 12s vs Etherscan at 15s) so readers can see how much of an oracle's error is stale-sample rather than model quality; it is not part of the ranking, only a diagnostic column. - Over/under split. In parallel with the absolute-error histogram, the harness emits `gas_error_priority_over_gwei_histogram` (predicted > realized, cost = overpay) and `gas_error_priority_under_gwei_histogram` (predicted < realized, cost = transaction stuck). Same buckets. The two branches lets the leaderboard decompose asymmetric behaviour: inclusion-confidence oracles skew fat on the over side by design, percentile trackers skew fat on the under side during spikes. - Lag=2 secondary grade. `gas_error_priority_lag2_gwei_histogram` grades each prediction against the block 2 slots after its target, not the very-next block. Removes the latency-race bias where whoever scraped the mempool 100ms before us wins by construction; closer to the wallet UX (sign, broadcast, propagate) than block+1. Same buckets as the primary histogram so a leaderboard column can plot the two side by side. - Asymmetric Pinball Loss (APL). `gas_error_priority_apl_gwei_histogram` emits a proper scoring rule (Koenker & Bassett 1978): per sample `(1-τ)·over_gap` if the oracle over-predicted, else `τ·under_gap`, with τ=0.9. Encodes wallet UX asymmetry: under-prediction (tx stuck) is 9× more costly than over-prediction (small overpay). Same buckets as the abs error histogram. Rank-stable at n=few-hundred samples where p99 of abs error is still dominated by 2-3 tail blocks. - Covered rate. Share of time (24h) each oracle's posted p50-tier prediction was at or above the realized p50 priority fee, recorded as `ocb:gas_p50_covered:pct_24h` via a recording rule. Same-instant gauge comparison (current prediction vs latest realized block), a proxy pending a harness-side matched counter. High = errs on the side of inclusion; low = under-bids vs the block's realized median. - Excluded by design. (a) BNB Chain (not EIP-1559). (b) L2 OP Stack chains (Optimism, Base, Arbitrum), priority fee ≈ 0 there because sequencer is centralised, the relevant cost is L1 data fee which is a different metric and belongs in a separate bench. (c) Rough median oracles that publish only a single number (no tier breakdown). (d) Solana, different fee model entirely (lamports per CU, MEV via Jito), separate bench needed. ## Most stable stablecoin, live peg deviation across USDC, USDT and DAI - Category: Trading - Metric: Peg deviation (bps) - Page: https://openchainbench.com/benchmarks/stablecoin-peg - JSON: https://openchainbench.com/api/stat/stablecoin-peg - Status: live - Headline: DAI leads peg deviation at 0.0057% (24h avg) on Most stable stablecoin, live peg deviation across USDC, USDT and DAI. **Rankings (p50, 24h):** 1. DAI: 0.0057% (p99 0.014%, success 99.9%, sample 7200.25) 2. USDC: 0.0095% (p99 0.022%, success 100.0%, sample 51840) 3. USDT: 0.099% (p99 0.11%, success 100.0%, sample 51840) **Methodology**: - Sources per stable, USDC: Binance USDC/USDT (USDT-anchored, secondary), Kraken USDCUSD, Bitstamp usdcusd. USDT: Coinbase USDT-USD, Kraken USDTUSD, Bitstamp usdtusd. FDUSD: Binance FDUSDUSDT (USDT-anchored, secondary). USDe: Binance USDEUSDT (USDT-anchored, secondary). DAI: Curve 3pool `get_dy`, quoted forward (USDC → DAI) and reverse (DAI → USDC), published as the geometric mean of the two quotes. - DAI's source class differs from the rest. No liquid CEX USD pair for DAI exists (live check July 2026: Kraken DAIUSD under $150k per 24 h with a 9 bps spread, Bitstamp at zero volume, Coinbase DAI-USD delisted), so DAI is measured from the Curve 3pool on-chain quote while USDC and USDT come from CEX tickers. The geometric mean of forward and reverse `get_dy` cancels the pool swap fee; residual pool imbalance is DAI's genuine price signal, not an artifact. - Cadence: 5 seconds for CEX REST tickers, 12 seconds for Curve `get_dy` on-chain (matches Ethereum block time). Per-venue samples are grouped into 60-second buckets for the liquidity-weighted median aggregation. - Aggregation: per-minute liquidity-weighted median across USD-quoted venues (`Quote = QuoteUSD`). Weight is 24 h USD volume estimate. The aggregated price drives `peg_deviation_bps` (per-minute median, retained for backward compatibility) and `peg_deviation_bps_histogram`. - Primary headline: `peg_deviation_worst_bps`, the per-minute MAX |price - $1.00| across all venue samples in the 60-second bucket, in bps. The ledger sorts on `quantile_over_time(0.50, peg_deviation_worst_bps[24h])`, the 24 h median (everyday tightness); the p99 column is the depeg tail. Per-minute max surfaces sub-minute depeg wicks a median would smooth away. Gauges `peg_minute_min_bps`, `peg_minute_open_bps`, `peg_minute_close_bps` expose the bar shape. - Cross-venue gap (OCB-only number): `max(price across USD-quoted venues) - min(price)`, per minute, in basis points. Surfaces the windows where Coinbase quotes USDT at $1.0003 while Kraken quotes $0.9978. Stored as `peg_cross_venue_gap_bps`. - USDT-anchored secondary metric: Binance USDC/USDT, FDUSD/USDT and USDE/USDT are exposed on `peg_deviation_usdt_anchored_bps{venue}` separately so the USD-anchored primary leaderboard is not contaminated by USDT's own peg deviation. - Time outside band: total seconds in the trailing 24 h during which the per-minute aggregated price fell outside [0.995, 1.005] (±50 bps). Split into `peg_time_below_peg_24h_seconds` (< 0.995) and `peg_time_above_peg_24h_seconds` (> 1.005) because Circle redemption only clears above-peg, so the direction tells you which failure mode is active. - Depeg event flag: binary `peg_depeg_event_flag` set to 1 when the per-minute aggregated price has been outside [0.97, 1.03] for ≥5 consecutive minutes; cleared after 30 minutes back inside. Conservative so it does not flap during normal stress events. - Outlier rule (multi-venue consensus): a sample more than 2% off peg is kept only when at least one other venue was outside the same band in the same direction within the last 30 seconds. Isolated single-venue glitches are dropped as `dropped_isolated`; corroborated moves (Kraken AND Bitstamp both at $0.87) are kept as `kept_corroborated`, so a real depeg like USDC during SVB in March 2023 survives into the percentile metric. Anything more than 50% off peg is treated as a parser bug and dropped. - Excluded by design: aggregator-only prices (CoinGecko, Coinmarketcap, DefiLlama) because they are themselves liquidity-weighted medians of the venues we already poll directly. Algo-stables that have already failed (UST, USDR) are out of scope; the bench tracks live, currently-redeemable stables. ## Cheapest USDT stablecoin swap on Binance, live USDC, FDUSD, USDe spread - Category: Trading - Metric: USDT-pair spread (bps) - Page: https://openchainbench.com/benchmarks/stablecoin-peg-usdt-anchored - JSON: https://openchainbench.com/api/stat/stablecoin-peg-usdt-anchored - Status: live - Headline: USDe leads usdt-pair spread at 0.085% (24h avg) on Cheapest USDT stablecoin swap on Binance, live USDC, FDUSD, USDe spread. **Rankings (p50, 24h):** 1. USDe: 0.085% (p99 0.085%, success 100.0%, sample 17280) 2. USDC: 0.087% (p99 0.088%, success 100.0%, sample 17280) 3. FDUSD: 0.17% (p99 0.17%, success 100.0%, sample 17280) **Methodology**: - Source: Binance REST `/api/v3/ticker/bookTicker?symbol=` polled every 5 seconds per pair. No API key required. Mid-price = (bid + ask) / 2 in USDT. - Pairs: USDCUSDT ($2.8B daily, reference anchor for USDT-vs-USD drift), FDUSDUSDT ($41M daily, FDUSD's primary book), USDEUSDT ($1.8M daily, the book that flashed to $0.65 on October 10 2025). - Metric: `peg_deviation_usdt_anchored_bps{stable, venue="binance"}` = |mid_price - 1.0000| × 10000. 1 bp = 0.01% = 0.0001 USDT off pair-reference. - Aggregation: p50 / p90 / p99 over 24 hours via Prometheus `quantile_over_time`. p99 is the headline because swap cost during stress is what matters for inventory rotation, not the calm-minute median. - USDC reference anchor: USDC/USDT spread is the floor below which no other pair can credibly score, because that gap reflects USDT's own drift away from USD reaching back into the pair. Read other stables' true vs-USDT drift as `their_p99 - usdc_p99` to control for it. - Depeg event flag (shared with bench № 014): binary `peg_depeg_event_flag{stable}` fires when the per-minute aggregated price is outside [0.97, 1.03] for ≥5 consecutive minutes. The flag clears after 30 minutes back inside the band. Conservative so it does not flap during normal stress. - Out of scope: this is a swap-cost / pair-spread bench, NOT a peg-robustness bench. Reserve attestations, basis-trade health, redemption windows, on-chain pool liquidity and other fundamental peg signals live on `stablecoin-peg` (bench № 014) or off-chain in each issuer's transparency dashboard. ## DeFi token buyback tracker, live executed vs promised ratio - Category: Trading - Metric: Execution ratio (pct) - Page: https://openchainbench.com/benchmarks/buyback-audit - JSON: https://openchainbench.com/api/stat/buyback-audit - Status: live - Headline: Hyperliquid leads execution ratio at 103.8% (24h avg) on DeFi token buyback tracker, live executed vs promised ratio. **Rankings (p50, 24h):** 1. Hyperliquid: 103.8% (p99 103.8%, success 100.0%, sample 7356500) **Methodology**: - Promised USD, DeFiLlama `summary/fees/` endpoint, summed over the rolling window, multiplied by the protocol's documented buyback share. Hyperliquid: `hyperliquid` slug, share 0.97 (HyperCore fees → Assistance Fund). Sky: `makerdao` slug, share 1.00 (Maker / Sky protocol surplus → SBE). - Executed USD, Hyperliquid, HYPE buys credited to the Assistance Fund multisig `0xfefefefefefefefefefefefefefefefefefefefe` on HyperCore, retrieved from the Hyperliquid `info` API user fills endpoint. Quantity is converted to USD using the on-chain oracle price returned by `metaAndAssetCtxs` because that is the price the AF actually pays at execution, not a CEX index. - Executed USD, Sky, SKY ERC-20 inflows into the SBE receiver `0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB` on Ethereum mainnet, paginated through Etherscan v2 (`chainid=1`, single API key for the whole multichain unified endpoint). Quantity is decoded with the SKY contract's 18 decimals and priced at the CoinGecko `sky` spot at scrape time. - Windows, rolling 7d and 30d. The harness recomputes the full window's sums each scrape rather than maintaining a delta, so historical revisions of DeFiLlama's fees series propagate automatically and no state leaks across restarts. - Cadence, 5 minutes per protocol. The numbers are gauges, not counters; sub-5-minute resolution is meaningless because both promised and executed sides are bounded by minutes-to-hours-grain upstream data (DeFiLlama daily aggregation, on-chain block time). - Excluded, GMX. V2 does not run a single on-market buyback wallet whose inflows we can audit. Fees flow to GLP / GM pool LPs in ETH and stables and to GMX stakers via esGMX reward distributors. The original treasury `0x68863dDE…dea6A` has been dormant since 2022-08 (verified via Etherscan v2), so there is no executor address that would let an audit of this shape resolve. v2 of this bench will add Jupiter Litterbox Trust (50% fees → JUP buyback on Solana) and Aave AFC as cleaner replacements. - Pricing, CoinGecko free tier (`hyperliquid`, `sky`) for the executed-side USD valuation. For Hyperliquid the on-chain oracle from `metaAndAssetCtxs` is preferred when available because that is the AF's actual fill reference, not a delayed third-party median. Aggregator drift between CoinGecko and the on-chain oracle is typically < 50 bps and is dwarfed by the ratio's own measurement scale. - Honesty boundary, the ratio measures execution against a documented promise. It does not measure whether the promise itself is generous or stingy, whether the bought-back token is held vs burned vs redistributed, or whether the buy was timed adversarially. Those are separate benchmarks that this one explicitly does not try to answer. ## Chainlink vs Pyth vs Binance vs Coinbase, live oracle deviation - Category: Trading - Metric: Max cross-oracle deviation (bps) - Page: https://openchainbench.com/benchmarks/oracle-deviation - JSON: https://openchainbench.com/api/stat/oracle-deviation - Status: live - Headline: LINK/USD leads max cross-oracle deviation at 0.068% (24h avg) on Chainlink vs Pyth vs Binance vs Coinbase, live oracle deviation. **Rankings (p50, 24h):** 1. LINK/USD: 0.068% (p99 0.14%, success 100.0%, sample 23036) 2. POL/USD: 0.087% (p99 0.26%, success 100.0%, sample 23036) 3. AVAX/USD: 0.089% (p99 0.23%, success 100.0%, sample 23036) 4. XRP/USD: 0.090% (p99 0.11%, success 100.0%, sample 17277) 5. BNB/USD: 0.091% (p99 0.13%, success 100.0%, sample 23036) 6. ETH/USD: 0.092% (p99 0.12%, success 100.0%, sample 23036) 7. BTC/USD: 0.093% (p99 0.11%, success 100.0%, sample 23036) 8. SOL/USD: 0.093% (p99 0.12%, success 100.0%, sample 23036) 9. ADA/USD: 0.094% (p99 0.18%, success 100.0%, sample 17277) 10. DOGE/USD: 0.096% (p99 0.15%, success 100.0%, sample 17277) **Methodology**: - Sources. Chainlink AggregatorV3 via `eth_call(latestRoundData())` on Ethereum mainnet (no API key, public RPC with fallback), Pyth Network via Hermes REST `/api/latest_price_feeds` batch endpoint (no key), Binance REST `/api/v3/ticker/price` on USDT-quoted symbols (treated as ≈ USD), Coinbase REST `/products/

/ticker` on USD-quoted products. All four are free, no-auth, public endpoints. - Pairs (10). BTC, ETH, SOL, BNB, AVAX, LINK and POL are tracked on all 4 sources. XRP, ADA, DOGE are tracked on 3 sources (Pyth + Binance + Coinbase) because the Chainlink mainnet AggregatorV3 contracts for these USD feeds are deprecated and no longer updated by node operators, the provider tag flags it. - Cadence. 30 second polling interval per (source, pair). 4 sources × 10 pairs × 2/minute = 80 requests/minute total, comfortably under every free-tier ceiling (Binance 1200/min, Coinbase 10/s public, Pyth ~30/s soft, public RPC courteous). HTTP timeout is 8 s per request to match the gas-estimation harness. - Deviation formula. For every unordered pair of sources `(a, b)` that both have a fresh sample for the same pair: `deviation_pct = |price_a - price_b| / ((price_a + price_b) / 2) * 100`. With 4 sources we compute 6 pairwise deviations per asset; with 3 sources we compute 3. Per-pair headline is the max across all source-pairs (`ocb_oracle_max_deviation_pct`). - Stale-price guard. A source's sample is considered stale and excluded from the deviation calculation if its last successful update is older than `2 * pollInterval` (60 s). Prevents a dead Coinbase ticker from registering as a 0% deviation against itself by leaving the price gauge fossilized. - Chainlink round age. The on-chain `updatedAt` timestamp from `latestRoundData()` is published separately as `ocb_oracle_last_round_age_seconds{source="chainlink", pair}`. Chainlink updates only on deviation (typically 0.25-0.5% for blue chips) or heartbeat (~1 h), so a 30-minute age on a quiet ETH minute is normal; a 2-hour age on SOL during a volatile minute is the actual signal. - USDT ≈ USD assumption. Binance only quotes USDT pairs (BTCUSDT, etc.). We treat USDT as ≈ USD ± 10 bps drift, which is acceptable for a bench whose alert floor is ≥ 10 bps. A real USDT depeg would surface as Binance drifting from the other three sources for *every* pair simultaneously, exactly what we want this bench to flag, not hide. - MATIC → POL migration. Polygon migrated MATIC → POL 1:1 on Sep 4 2024. The Chainlink mainnet feed contract is still named MATIC/USD but on-chain `description()` confirms it tracks the POL token; Pyth renamed the feed to POL/USD; Coinbase delisted MATIC-USD and only lists POL-USD; Binance kept MATICUSDT as a frozen historical pair AND lists POLUSDT. We point Binance at POLUSDT so all four sources track the same underlying asset. Bench label is kept as `pair="MATIC/USD"` for query continuity. - Time-aligned deviation (canonical headline). For every source pair we anchor on the more recent SourceTS (Chainlink's on-chain `updatedAt`, fetch time for continuous sources) and look up the older source's price in a 30-minute rolling history at that moment. Published as `ocb_oracle_deviation_at_oracle_ts_pct`, feeding `ocb_oracle_max_deviation_pct`. Removes Chainlink heartbeat-lag inflating deviation; alignment misses count as `ocb_oracle_alignment_miss_total`. - Excluded by design. Redstone (push-pull, no continuous gauge to scrape without integration contract), Uniswap V3 TWAP (per-pool integration + derivation of same CEX prints), DIA (smaller footprint than the four kept), and aggregator-of-aggregators (CoinGecko, CMC, DefiLlama), re-aggregating already-aggregated data adds latency and hides per-source disagreement. ## Highest staking yield, live validator net APR across Solana, Hyperliquid and Ethereum - Category: Blockchains - Metric: Net yield (bps) - Page: https://openchainbench.com/benchmarks/validator-yield - JSON: https://openchainbench.com/api/stat/validator-yield - Status: live - Headline: Cosmos Hub leads net yield at 9.83% (24h avg) on Highest staking yield, live validator net APR across Solana, Hyperliquid and Ethereum. **Rankings (p50, 24h):** 1. Cosmos Hub: 9.83% (p99 9.83%, success 100.0%, sample 200) 2. Avalanche: 6.80% (p99 8.33%, success 100.0%, sample 100) 3. Solana: 5.30% (p99 5.62%, success 100.0%, sample 200) 4. Cardano: 4.95% (p99 5.00%, success 100.0%, sample 50) 5. Ethereum: 2.60% (p99 2.60%, success 100.0%, sample 1) 6. Hyperliquid: 2.18% (p99 2.25%, success 100.0%, sample 34) 7. Sui: 1.44% (p99 1.60%, success 100.0%, sample 125) **Methodology**: - Sources. Solana primary: `GET api.stakewiz.com/validators` (free, no key). `total_apy` already includes inflation + Jito MEV tips. Solana enrichment: `GET kobe.mainnet.jito.network/api/v1/validators` for MEV-share split. Hyperliquid: `POST api.hyperliquid.xyz/info {type:validatorSummaries}`, field `predictedApr.day` × `uptimeFraction`. Prices: CoinGecko (SOL/USD), HL `metaAndAssetCtxs` (HYPE/USD). - Cadence. 5-minute scrape interval per chain. Validator-level metrics (APR, commission, uptime, stake) move on epoch boundaries (~2 days on Solana, ~30 seconds on Hyperliquid), so sub-minute polling would add Prom cardinality cost without information. - Net yield formula. `net_yield_bps = gross_apr_bps × uptime_fraction`. Slashing is treated as negligible in v1, Solana has never slashed in production, and Hyperliquid's jailed-validator state is surfaced as `ocb_validator_jailed{chain, validator}=1` separately rather than amortised into the APR. Both chains report APR (simple yield), not APY (compounded); the bench reports APR-as-bps to match what the upstream APIs publish, no compounding adjustment applied. - Cap. Solana exposes ~3000 active validators across the full set; the bench caps to the top 200 by `activated_stake` (USD-weighted) to keep Prom cardinality at ~230 series total across the two chains. The top 200 represent ~90% of staked SOL by value, so the median is representative of where real stake sits, not of the long tail of <1k SOL validators. Hyperliquid exposes ~30 active validators total, all are tracked. - Median (chain-level headline). `ocb_chain_median_net_yield_bps{chain}` is computed harness-side over the per-validator gauges every scrape, not derived from Prom. This includes the ~42 Solana validators currently at 0% APY (commission 100% or no leader slots), which materially pulls the Solana median down vs the modal active-validator yield. A reader who wants 'yield I would get if I picked a sane validator' should look at p75 or higher on the Solana distribution, not the chain median. - MEV treatment. Solana: MEV tips from Jito are already folded into Stakewiz `total_apy`. `ocb_validator_mev_share_bps` is exposed for transparency (a reader sees 'Helius APR 600 bps of which 80 bps MEV') but NOT subtracted to produce a 'staking-only' figure. Hyperliquid: no separate MEV layer (centralised sequencer captures order-flow value at the protocol level), so the MEV gauge is 0 by convention. - Ethereum. Source: `GET ultrasound.money/api/v2/fees/effective-balance-sum` (free, no key), live total beacon-chain effective balance. APR = 64 × epochs_per_year / sqrt(total_gwei), the consensus spec reward formula at 100% participation (realized ~99.5%, under 2 bps of drift). One network-average series: consensus rewards are uniform per 32 ETH increment, so the average equals the solo validator nominal APR. Execution tips and MEV excluded. Price: CoinGecko (ETH/USD). - Jailed / inactive handling. Hyperliquid: `jailed=1` validators (currently 4) land in the dataset with `predictedApr=0`, so `net_yield_bps=0`. Solana: ~42 validators report `total_apy=0`. Live data shows two causes: commission 100% (operator routes everything to themselves, delegators get 0) or zero leader slots this epoch (no block-production rewards). Both legitimate transient states, both count toward total + median. - Excluded by design. Per-validator Ethereum gauges (~1M indices; beacon-node ingestion, v2). Ethereum execution tips + MEV (per-relay MEV-Boost scraping needed; published figure is consensus only). Lido/RocketPool/Coinbase are products with fees, not validator yields (separate bench). Polkadot v2. Cosmos Hub, Avalanche, Cardano, Sui now tracked. ## Hyperliquid frontends builder revenue leaderboard - Category: Trading - Metric: Builder fees collected (USD) (usd) - Page: https://openchainbench.com/benchmarks/hyperliquid-frontends - JSON: https://openchainbench.com/api/stat/hyperliquid-frontends - Status: live - Headline: Phantom leads builder fees collected (usd) at $19.5K (24h) on Hyperliquid frontends builder revenue leaderboard. **Rankings (p50, 24h):** 1. Phantom: $19.5K (p99 $8.76, success 100.0%, sample 22319) 2. Invo: $12.1K (p99 $1.21, success 100.0%, sample 98783) 3. MetaMask: $10.4K (p99 $11.91, success 100.0%, sample 9218) 4. OneKey: $3,525.46 (p99 $34.91, success 100.0%, sample 2156) 5. FOMO: $2,616.74 (p99 $5.7, success 100.0%, sample 5011) 6. Rabby: $2,251.25 (p99 $4.17, success 100.0%, sample 6758) 7. Moonbot: $2,198.72 (p99 $30.97, success 100.0%, sample 7300) 8. Legend Trade: $1,559.01 (p99 $19.49, success 100.0%, sample 2140) 9. Insilico: $1,465.76 (p99 $11.02, success 100.0%, sample 13401) 10. Metascalp: $1,301.66 (p99 $7.11, success 100.0%, sample 33623) 11. 0x42f3…f992: $1,194.51 (p99 $11.71, success 100.0%, sample 7506) 12. Axiom: $1,186.49 (p99 $6.82, success 100.0%, sample 2165) 13. 0x7cc0…e781: $902.56 (p99 $0.5309, success 100.0%, sample 7813) 14. Liquid Perps: $897.79 (p99 $3.59, success 100.0%, sample 1928) 15. Hyperdash: $835.86 (p99 $6.48, success 100.0%, sample 2918) 16. cro.trade: $732.59 (p99 $61.05, success 100.0%, sample 532) 17. Tread.fi: $690.08 (p99 $9.33, success 100.0%, sample 19919) 18. BullpenFi: $636.13 (p99 $7.31, success 100.0%, sample 1411) 19. Bitget Wallet: $521.1 (p99 $2.67, success 100.0%, sample 1243) 20. 0x53a1…fcd1: $502.31 (p99 $19.32, success 100.0%, sample 230) 21. Nansen: $484.21 (p99 $5.15, success 100.0%, sample 1321) 22. MarsGO: $482.4 (p99 $120.6, success 100.0%, sample 79) 23. VergeX: $454.74 (p99 $6.79, success 100.0%, sample 1124) 24. Markets Mobile: $449.37 (p99 $9.17, success 100.0%, sample 531) 25. 0xdbc2…97a6: $437.45 (p99 $6.16, success 100.0%, sample 547) 26. Onchain.cc: $361.04 (p99 $0.8396, success 100.0%, sample 4404) 27. Dexly Trade: $345.81 (p99 $6.52, success 100.0%, sample 511) 28. based.app: $333.45 (p99 $1.41, success 100.0%, sample 2852) 29. Mass.money: $308.02 (p99 $9.06, success 100.0%, sample 585) 30. Trust Wallet: $255.48 (p99 $0.3583, success 100.0%, sample 10683) 31. Dreamcash: $229.77 (p99 $1.34, success 100.0%, sample 1134) 32. MetaMask (alt): $213.36 (p99 $4.74, success 100.0%, sample 312) 33. CCXT: $194.28 (p99 $2.31, success 100.0%, sample 2988) 34. HyperX: $186.7 (p99 $3.39, success 100.0%, sample 2647) 35. defi.app: $168.27 (p99 $8.41, success 100.0%, sample 114) 36. Dextrabot: $165.26 (p99 $8.26, success 100.0%, sample 362) 37. Wunder: $148.14 (p99 $1.21, success 100.0%, sample 1479) 38. Rainbow: $140.45 (p99 $2.99, success 100.0%, sample 220) 39. Pear: $140.39 (p99 $4.39, success 100.0%, sample 567) 40. Miracle: $133.66 (p99 $6.08, success 100.0%, sample 528) 41. pvp.trade: $132.61 (p99 $5.77, success 100.0%, sample 158) 42. 0x9f83…31d9: $94.44 (p99 $1.97, success 100.0%, sample 285) 43. Senpi: $76.61 (p99 $1.24, success 100.0%, sample 805) 44. ApexLiquid: $75.45 (p99 $1.14, success 100.0%, sample 1231) 45. Infinex: $67.4 (p99 $5.18, success 100.0%, sample 86) 46. 0xb290…c34a: $61.45 (p99 $4.39, success 100.0%, sample 135) 47. goodcryptoX: $58.67 (p99 $1.09, success 100.0%, sample 1321) 48. Sushi: $50.13 (p99 $6.27, success 100.0%, sample 159) 49. Dexari: $44.07 (p99 $3.15, success 100.0%, sample 85) 50. Tradoor: $39.89 (p99 $9.97, success 100.0%, sample 2826) 51. Arena: $39.5 (p99 $3.95, success 100.0%, sample 69) 52. 0xc95d…1aca: $28.52 (p99 $7.13, success 100.0%, sample 1187) 53. 0x446f…d6c6: $28.37 (p99 $7.09, success 100.0%, sample 27) 54. Hyprearn: $21.85 (p99 $2.18, success 100.0%, sample 97) 55. MinaraAI: $21.47 (p99 $0.6315, success 100.0%, sample 367) 56. CoinPilot: $20.55 (p99 $0.3425, success 100.0%, sample 574) 57. STRYX: $19.35 (p99 $19.35, success 100.0%, sample 15) 58. Wallet V: $19 (p99 $1.58, success 100.0%, sample 260) 59. tuleep.trade: $18.29 (p99 $4.57, success 100.0%, sample 3888) 60. Splash: $14.41 (p99 $4.8, success 100.0%, sample 46) 61. Moontrader: $12.65 (p99 $3.16, success 100.0%, sample 141) 62. Liminal: $7.65 (p99 $1.27, success 100.0%, sample 37) 63. Owly.fi: $5.85 (p99 $1.95, success 100.0%, sample 23) 64. Katoshi: $5.4 (p99 $1.8, success 100.0%, sample 12) 65. DeFi Saver: $4.66 (p99 $0.9325, success 100.0%, sample 27) 66. 0xf85a…5688: $4.6 (p99 $0.5746, success 100.0%, sample 42) 67. Origami Tech: $3.6 (p99 $0.2771, success 100.0%, sample 567) 68. XBIT: $2.4 (p99 $1.2, success 100.0%, sample 5) 69. KuCoin Web3: $1.8 (p99 $0.5984, success 100.0%, sample 35) 70. Lit Trade: $1.72 (p99 $0.8605, success 100.0%, sample 185) 71. SuperCEXy: $1.47 (p99 $1.47, success 100.0%, sample 8) 72. Okto: $1.37 (p99 $0.1243, success 100.0%, sample 32) 73. GTR Trade: $0.9314 (p99 $0.3105, success 100.0%, sample 12) 74. PerpsWLD: $0.6808 (p99 $0.1702, success 100.0%, sample 14) 75. Gem Wallet: $0.4322 (p99 $0.1080, success 100.0%, sample 9) 76. Cwallet: $0.4164 (p99 $0.0521, success 100.0%, sample 19) 77. UnityWallet: $0.3433 (p99 $0.0286, success 100.0%, sample 59) 78. UXUY: $0.3204 (p99 $0.3204, success 100.0%, sample 2) **Methodology**: - Data source. A local hl node operated on OCB infrastructure tails the Hyperliquid mainnet and writes every block of attributed fills to node_fills_by_block hourly YYYYMMDD HH on local disk. Each line is one JSON block, the events array carries one entry per fill, and every fill that opted into the builder code attribution system includes the builder address plus builderFee in USDC. - Cadence. The Go harness re-reads the current and previous hourly files every 30 seconds, parses appended lines, and updates per-builder hourly buckets keyed by the UTC hour floor of the fill timestamp. Prometheus scrapes the metrics every 30 seconds via a Caddy reverse proxy with basic auth. End-to-end staleness from fill landing on-chain to bench page render is typically under one minute. - Headline calculation. For each builder over the last 24 rolling hours, we sum the builderFee USD values of every attributed fill. The figure is the raw amount of USDC the frontend collected through the builder code field. The 7 day and 30 day figures sum the same field over the last 168 and 720 hourly buckets respectively, so the metric is consistent across the three ranges. - Window mechanics. The harness keeps a small in-memory hourly bucket map per-builder going back 30 days. Memory footprint is about 600 KB total for 104 builders. Older buckets are pruned on every publish. This is cheaper than keeping fill-level granularity for 30 days and lets the bench expose the three ranges without expanding the live fill window. - Volume companion. hl_frontend_volume_usd_24h_v2, _7d_v2 and _30d_v2 are computed the same way on the px times sz product of every fill. They feed the Volume tabs. - Users 24h. Count of unique wallet addresses that placed at least one attributed fill on this builder in the last 24 hours. Computed on the fill-level window, not the hourly buckets, because uniqueness requires the full set. - Effective fee bps companion. Volume weighted ratio computed as sum of builder fees divided by sum of notional, times ten thousand, over the rolling 24h window. Surfaces the trader perspective on cost. Volume share dashboards rank frontends by raw notional, this column ranks them by what a representative dollar of flow paid them. - Time since last fill. Seconds elapsed since this builder's most recent attributed fill. During active hours the cohort baseline runs under one minute, so anything above a few minutes is a real anomaly. Catches frontends whose routing pipeline is down and frontends that quietly stopped operating but still have their builder code in circulation. - Builder registry. `miniapps/hyperliquid-frontends/local/builders.json` is a hand-curated array of slug, name, address and notes for every tracked frontend, currently 104 entries. New addresses ship via public PR. Builder addresses outside the registry remain visible in the raw node stream but stay off the leaderboard until added. - Exclusions. Native Hyperliquid UI orders carry no builder code and are not user attributable by this method. Roughly 95 percent of Hyperliquid fills land without a builder field. The 5 percent that do are the frontend ecosystem this bench measures. - Reproducibility. Harness source at `miniapps/hyperliquid-frontends/local` in the mobula api repo, written in Go. Anyone running their own hl node can clone, point the data flag at their node_fills_by_block hourly root, run the binary against a Prometheus scraper, and reproduce these metrics. - Failures. Any read error on the hourly files leaves the previous gauge values in place. Hourly bucket pruning is idempotent. Restarts replay the warmup window from disk before going live tail. ## Cheapest blockchain transaction fee, live across 15 L1 and L2 chains - Category: Blockchains - Metric: Native transfer fee USD (usd) - Page: https://openchainbench.com/benchmarks/network-fees - JSON: https://openchainbench.com/api/stat/network-fees - Status: live - Headline: Litecoin leads native transfer fee usd at $0.000106 (24h) on Cheapest blockchain transaction fee, live across 15 L1 and L2 chains. **Rankings (p50, 24h):** 1. Litecoin: $0.000106 (p99 $0.000108, success 100.0%, sample 40317) 2. Base: $0.000239 (p99 $0.00248, success 100.0%, sample 40317) 3. Taiko: $0.000347 (p99 $0.00135, success 100.0%, sample 40317) 4. Solana: $0.000375 (p99 $0.000380, success 100.0%, sample 40317) 5. Mantle: $0.000434 (p99 $0.000817, success 100.0%, sample 40317) 6. BNB Chain: $0.000685 (p99 $0.00566, success 99.9%, sample 40317) 7. Arbitrum One: $0.000795 (p99 $0.000825, success 100.0%, sample 40317) 8. zkSync Era: $0.00179 (p99 $0.00185, success 99.6%, sample 40317) 9. Robinhood Chain: $0.00218 (p99 $0.00280, success 100.0%, sample 40317) 10. Ethereum: $0.00376 (p99 $0.3560, success 100.0%, sample 40317) 11. Sui: $0.00544 (p99 $0.00550, success 100.0%, sample 40317) 12. Linea: $0.0152 (p99 $0.0601, success 100.0%, sample 40317) 13. Cardano: $0.0275 (p99 $0.0276, success 100.0%, sample 40317) 14. Monero: $0.0435 (p99 $0.1769, success 100.0%, sample 40317) 15. TRON: $0.0937 (p99 $0.0937, success 100.0%, sample 40317) **Methodology**: - Refresh cadence. 30 seconds. One process samples all 15 chains in parallel goroutines. - Ethereum and BNB Chain on the L1 tab. eth_feeHistory over the last 4 blocks at percentiles 25, 50 and 90. Cost = (base_fee + reward_percentile) * 21000 gas, mapped to slow, standard and fast. - Arbitrum, Base, zkSync Era, Linea, Mantle and Taiko on the L2 tab. Same eth_feeHistory flow against each rollup's sequencer RPC. ETH is the native gas asset on every tracked rollup except Mantle, which prices gas in MNT. - Layer 2 caveat. The published figure is L2 execution cost only. The L1 data posting fee (blob market for EIP 4844 rollups, calldata for the rest) is excluded from this page and will be added as a separate blended figure in a later phase. On OP Stack rollups the L1 data fee can dominate the wallet visible total during expensive blob periods. - Solana. getRecentPrioritizationFees percentiles 25, 50 and 90 of micro lamports per compute unit, times 200 compute units, plus 5000 lamports base. Empty fees response collapses to a single standard tier at the 5000 base. - TRON. getChainParameters.getTransactionFee (currently 1000 sun per byte) times 268 bytes for a typical native transfer. Single tier because TRON native transfers do not bid into a priority market. - Cardano. koios epoch_params.min_fee_a and min_fee_b, times 250 bytes for a typical native transfer. Deterministic by protocol, refreshes only when on chain parameters change. - Sui. suix_getReferenceGasPrice times 76000 gas (typical observed for a Coin::transfer call). Single standard tier. - Litecoin. litecoinspace.org /api/v1/fees/recommended (hour, half hour and fastest fees in litoshi per vByte) times 225 vBytes for a typical 1 input 1 output P2WPKH transfer. - Monero. monero rpc get_fee_estimate.fees[0..2] times 1500 bytes for a typical 1 input 2 output RingCT transaction. - USD prices. api.mobula.io/api/1/market/multi-data polled every 30 seconds for all 15 native tokens in one call. - Failures. Any upstream error leaves the previous gauge in place, increments tx_fee_fetch_errors_total{chain, error_type}, and sets tx_fee_health{chain} to zero. ## Fastest prediction market data API, live freshness across venues - Category: Aggregators - Metric: Freshness delta vs venue (ms) - Page: https://openchainbench.com/benchmarks/pm-data-freshness - JSON: https://openchainbench.com/api/stat/pm-data-freshness - Status: live - Headline: Polymarket leads freshness delta vs venue at 0.5 ms (p50, 24h) on Fastest prediction market data API, live freshness across venues. **Rankings (p50, 24h):** 1. Polymarket: 0.5 ms (p99 0.5 ms, success 93.3%, sample 17107.3) 2. Kalshi: 0.5 ms (p99 0.5 ms, success 99.8%, sample 2149950) 3. Codex: 1.08 s (p99 7.10 s, success 100.0%, sample 388697) **Methodology**: - Anchor rows: on each venue tab the venue itself (Polymarket, Kalshi) is the canonical T0, so its row reads as the harness network round trip, near zero by construction. It is kept on the board to document the reference point, not as a competing feed; the comparison rows are the data providers measured against it. - Polymarket T0. `wss://ws-subscriptions-clob.polymarket.com/ws/market` is public, no auth, sub 50ms gateway publish latency from EU West. Cross correlation uses (conditionId, priceUSD rounded to 3 decimals, sizeUSD micros, 5s time bucket). - Kalshi T0. `https://api.elections.kalshi.com/v1/social/trades` (REST), polled every 5s with cursor pagination. Every trade carries `create_date` at microsecond precision; that timestamp is the canonical T0. Poll cadence affects only correlation timing, not the freshness number. The official Kalshi WebSocket needs RSA PSS signed headers from a US KYC account and 403s from non US IPs, not viable for a public benchmark. - Codex GraphQL subscriptions. `wss://graph.codex.io/graphql` with the `graphql-transport-ws` subprotocol. Firehose `onPredictionTradesCreated` subscription filtered client side to the venue's marketIds. Covers both Polymarket and Kalshi. - Basket. Top 20 active markets by 24h volume per venue, refreshed every 5 minutes. Polymarket pulls from `gamma-api.polymarket.com`, Kalshi pulls from `api.elections.kalshi.com/trade-api/v2/markets`. - Histogram buckets: 10, 25, 50, 100, 250, 500, 1000, 2500, 5000, 10000, 30000, 60000 ms. The venue's own arrivals always land in the smallest bucket because by construction we measure other providers against it. - Region. `eu-west` (Railway europe-west4). Both venue gateways are geographically distributed; deltas reflect EU client to EU gateway latency. - Venue clock asymmetry. Polymarket CLOB trades carry no venue timestamp so T0 is when our harness receives the WS event; the Polymarket-to-harness RTT cancels inside the Codex delta. Kalshi's REST `create_date` is venue-side so the Codex Kalshi delta includes a Codex-to-harness RTT (50 to 100 ms) the Polymarket math cancels out. Kalshi rows are slightly stricter for the same provider, not more favorable; the gap is small versus the multi-second deltas the chart highlights. ## Fastest EVM swap quote API - Category: Aggregators - Metric: Quote latency (ms) - Page: https://openchainbench.com/benchmarks/evm-quote-latency - JSON: https://openchainbench.com/api/stat/evm-quote-latency - Status: live - Headline: Mobula leads quote latency at 168 ms (p50, 24h) on Fastest EVM swap quote API. **Rankings (p50, 24h):** 1. Mobula: 168 ms (p99 761 ms, success 100.0%, sample 4320.63) 2. KyberSwap: 194 ms (p99 909 ms, success 100.0%, sample 4319.63) 3. LI.FI: 786 ms (p99 1.89 s, success 62.0%, sample 2680.39) 4. Enso: 1.31 s (p99 3.89 s, success 100.0%, sample 4320.63) 5. CoW Protocol: 2.66 s (p99 4.84 s, success 100.0%, sample 3456.5) **Methodology**: - Five fixed pairs across four chains. Polygon and Optimism will be added in v2 once they reach a comparable sample volume. - 60 second tick, one pair per tick, round robin. Every (provider, chain) sees a quote every 5 minutes. - Three regions (us east, eu west, sgp). Each is a separate Railway service writing the same metric family with a region label, so the page can filter to a single edge or aggregate across all three. - Latency is wall clock from request dispatch to last byte received, observed only on the happy path (HTTP 2xx and a parseable output amount). Failures land on dedicated counters (auth, throttle, no route, other) and pull the success gauge to 0. - Native asset sentinel is the canonical 0xEeeeeEeee form. Odos uses 0x0000... and Bebop substitutes the wrapped equivalent on the sell side. The adapter normalises per provider. - Provider auth: Mobula requires the sponsor key in an Authorization header. KyberSwap, Bebop, LI.FI and OpenOcean accept anonymous traffic. ## Cheapest blockchain to deploy a token, live USD cost across 7 non-EVM L1 chains - Category: Blockchains - Metric: Token deployment cost USD (usd) - Page: https://openchainbench.com/benchmarks/token-deployment-cost - JSON: https://openchainbench.com/api/stat/token-deployment-cost - Status: live - Headline: Osmosis leads token deployment cost usd at $0.000976 (24h) on Cheapest blockchain to deploy a token, live USD cost across 7 non-EVM L1 chains. **Rankings (p50, 24h):** 1. Osmosis: $0.000976 (p99 $0.000988, success 100.0%, sample 40317) 2. Aptos: $0.0933 (p99 $0.0955, success 100.0%, sample 40317) 3. Cardano: $0.1934 (p99 $0.1946, success 100.0%, sample 40317) 4. Sui: $0.3582 (p99 $0.3616, success 100.0%, sample 40317) 5. Stellar: $0.4454 (p99 $0.4541, success 100.0%, sample 40317) 6. Injective: $0.4947 (p99 $0.5093, success 100.0%, sample 40317) 7. Solana: $0.6841 (p99 $0.6981, success 100.0%, sample 40317) **Methodology**: - Refresh cadence. 5 minutes. One process samples all 7 chains in parallel goroutines and emits Prometheus gauges. - Solana SPL. getMinimumBalanceForRentExemption(82) for the mint + (165) for the Associated Token Account + (679) for the Metaplex Token Metadata account + 5000 lamports per signature. Multiply by SOL USD price. Without the metadata account the headline would understate by ~2.5x. - Sui. suix_getReferenceGasPrice times 5 million MIST gas units for a canonical coin module publish (net of storage rebate). Converted to USD via SUI price. - Aptos. /v1/estimate_gas_price.gas_estimate octas per unit times 150000 gas units for a canonical FA standard publish. Converted to USD via APT price. - Cosmos TokenFactory (Osmosis, Injective). LCD //tokenfactory/v1beta1/params.denom_creation_fee. Empty array (Osmosis) means gas only, rendered as less than 0.001 dollar. Injective charges a flat 0.1 INJ. - Cardano. Koios /epoch_params.coins_per_utxo_size. Apply Conway minUTxO formula = (160 byte overhead + 70 byte single asset bundle) × coins_per_utxo_size + 180000 lovelace mint tx fee. Converted to USD via ADA price. - Stellar. Horizon /ledgers.base_reserve_in_stroops and base_fee_in_stroops on the latest ledger. Total cost = 5 base reserves (the protocol minimum of 2 per new account for issuer and distribution, plus 1 for the trustline) + 2 base fees (create_account + change_trust). Reserves are locked capital, refundable on account closure, counted here because bringing the asset into existence requires them upfront. Converted to USD via XLM price. - USD prices. api.mobula.io/api/1/market/multi-data?symbols=SOL,SUI,APT,OSMO,INJ,ADA,XLM polled every 5 minutes. - Failures. Any upstream error increments token_deployment_samples_total{chain,status=error} and leaves the previous gauge value in place. - EVM chains excluded. Ethereum, BNB Chain, Avalanche, Polygon, Arbitrum, Optimism, Base, Blast, Mantle, opBNB, Celo, Scroll and Linea were previously exposed but relied on a placeholder init bytecode that undercounted real ERC20 deploy cost by 30 to 500x. Removed until the canonical OZ v5 artifact is finalised. ## Hyperliquid HIP-3 deployer revenue leaderboard - Category: Trading - Metric: Deployer fees collected (USD) (usd) - Page: https://openchainbench.com/benchmarks/hyperliquid-hip3-deployers - JSON: https://openchainbench.com/api/stat/hyperliquid-hip3-deployers - Status: live - Headline: trade.xyz leads deployer fees collected (usd) at $32.3K (24h) on Hyperliquid HIP-3 deployer revenue leaderboard. **Rankings (p50, 24h):** 1. trade.xyz: $32.3K (p99 $0.1875, success 100.0%, sample 1664220) 2. Paragon: $23.63 (p99 $1.43, success 100.0%, sample 150) 3. HyENA: $18.01 (p99 $0.1481, success 100.0%, sample 1700) **Methodology**: - Data source. A local hl node operated on OCB infrastructure tails the Hyperliquid mainnet and writes every block of fills to node_fills_by_block hourly YYYYMMDD HH on local disk. Each line is one JSON block, the events array carries one entry per fill, and every fill on a HIP-3 market includes the dex namespaced coin (xyz:AAPL) plus the deployerFee in USDC. - Attribution. A fill belongs to a HIP-3 dex when its coin carries a namespace prefix (xyz:AAPL belongs to xyz). Namespaces are unique on chain by construction, so no hand-curated registry is needed; the harness starts tracking a new deployer with its first observed fill, and the namespace is added to this page on the next spec review. Core Hyperliquid markets carry no namespace and no deployer fee, they are excluded. - Cadence. The Go harness re-reads the current and previous hourly files every 30 seconds, parses appended lines, and updates per-dex hourly buckets keyed by the UTC hour floor of the fill timestamp. Prometheus scrapes the metrics every 30 seconds via a Caddy reverse proxy with basic auth. End-to-end staleness from fill landing on-chain to bench page render is typically under one minute. - Headline calculation. For each dex over the last 24 rolling hours we sum the deployerFee USD values of every fill on its namespaced markets. The 7 day and 30 day figures sum the same field over the last 168 and 720 hourly buckets, so the metric is consistent across the three ranges. - Volume companion. hl_hip3_deployer_volume_usd_24h, _7d and _30d are computed the same way on the px times sz product of every fill. They feed the Volume column and tab. - Users. Unique wallet addresses with at least one fill on the dex. The 24h figure is a union of per hour wallet sets over the rolling window; 7d and 30d are unions of per UTC day wallet sets. After a harness restart the day sets are reseeded from the on disk fill history before the 7d and 30d gauges publish, so they never lowball. - Markets. Count of distinct namespaced coins traded on the dex in the last 24 hours. A dex with 70 active equity markets and a dex with one commodity market are different products; the column makes that visible next to the revenue number. - Effective fee bps. Deployer fees divided by notional volume, times ten thousand, over the rolling 24h window. The trader perspective on what a representative dollar of flow paid the dex operator. - Window mechanics. Hourly buckets per-dex go back 30 days in-memory and are pruned on every publish. Per fill state is never retained; the largest dex clears about 4 million fills per day, so the bench aggregates at ingestion time instead of keeping fill-level granularity. - 30 day caveat. The node retains hourly fill files for a bounded horizon and the harness backfill reads what exists on disk. Until 30 full days of history accumulate, the 30d figures cover the available horizon and grow toward the full window. - Naming. Every namespace is resolved against the on-chain perpDexs registry, which publishes the deployer address and full name: xyz is trade.xyz, vntl is Ventuals, cash is Dreamcash, km is Markets by Kinetiq, hyna is HyENA by the Based team, flx is Felix Exchange, para is Paragon. Attribution is by namespace prefix either way, so the numbers do not depend on naming. - Reproducibility. Harness source is open in the OCB harness tree. Anyone running their own hl node can clone, point the data flag at their node_fills_by_block hourly root, run the binary against a Prometheus scraper, and reproduce these metrics. - Failures. Any read error on the hourly files leaves the previous gauge values in place. Hourly bucket pruning is idempotent. Restarts replay the warmup window from disk before going live tail, and reseed the user sets from history in the background. ## Cheapest perp venue to hold a position, live funding normalized - Category: Trading - Metric: Funding cost to hold a long 24h (bp) - Page: https://openchainbench.com/benchmarks/perp-funding - JSON: https://openchainbench.com/api/stat/perp-funding - Status: live - Headline: dYdX v4 leads funding cost to hold a long 24h at 0.46 bps (p50, 24h) on Cheapest perp venue to hold a position, live funding normalized. **Rankings (p50, 24h):** 1. dYdX v4: 0.46 bps (p99 -3.76 bps, success 100.0%, sample 2879) 2. OKX: 0.71 bps (p99 1.01 bps, success 100.0%, sample 2879) 3. Binance: 0.87 bps (p99 1.05 bps, success 100.0%, sample 2879) 4. Aster: 1.49 bps (p99 1.71 bps, success 100.0%, sample 2879) 5. Bybit: 1.51 bps (p99 -0.48 bps, success 100.0%, sample 2879) 6. Paradex: 2.50 bps (p99 1.67 bps, success 100.0%, sample 2879) 7. Hyperliquid: 2.92 bps (p99 1.73 bps, success 100.0%, sample 2879) **Methodology**: - Sources. One public, unauthenticated endpoint per venue: Hyperliquid info metaAndAssetCtxs (live 1h rate), Binance fapi premiumIndex plus fundingInfo for per pair intervals, Bybit v5 tickers plus instruments-info (interval in minutes), OKX public funding-rate (interval from settlement timestamps), dYdX v4 indexer perpetualMarkets (per hour rate), Paradex markets summary (8h period), Aster premiumIndex (Binance compatible). - Normalization. Every venue quotes a rate for its own settlement period. The harness divides the quoted rate by the venue's interval in hours to get a per hour rate, then publishes per hour bps (rate times 10000), 24 hour hold cost (per hour times 24) and annualized percent (per hour times 24 times 365 times 100). A 0.01 percent per 8h rate and a 0.00125 percent per 1h rate are the same number on this page. - Sign convention. Positive means longs pay shorts, negative means longs are paid to hold. Signs are preserved through every column; the ranking treats negative as cheaper, so a venue where the long side is being paid ranks first. - Headline. Cost in bps of notional to hold an ETH long for 24 hours, averaged over the last 24 hours of one minute samples. The instantaneous rate moves every settlement; the 24 hour average is what a position opened yesterday actually paid. BTC and SOL columns are computed identically. - Windows. The 7 day and 30 day columns are avg_over_time of the normalized hold cost series, the carry trader's view. A venue with attractive funding for one hour and brutal funding the rest of the week ranks accordingly on the longer windows. - Cadence. The harness polls all venues in parallel every 60 seconds with a 10 second timeout per request; Prometheus scrapes every 30 seconds. End to end staleness is under two minutes in normal operation. - Failures. A venue that errors or times out keeps its previous gauge values and its perp_funding_venue_ok_unix timestamp stops advancing; the Success column turns red after 5 minutes of silence. No value on this page is ever interpolated or guessed. - Scope. BTC, ETH and SOL are the assets every venue in the cohort lists. GMX is excluded because its borrow fee model has no comparable funding rate. Lighter is excluded until the interval semantics of its public funding endpoint are documented; it joins the cohort once its numbers can be normalized honestly. - Funding versus fees. This bench prices holding. Its companion perp-fees prices opening (taker fee plus spread plus impact on a $1000 ETH long). Read both to know the all in cost of a trade you intend to hold. - Reproducibility. The harness source is open in the OCB harness tree (funding.go in the hyperliquid-frontends harness). Point it at the same public endpoints and you reproduce every number on this page. ## Prediction market API rate limits, tested with a daily ramp - Category: Trading - Metric: Warm book latency (ms) - Page: https://openchainbench.com/benchmarks/pm-rate-limits - JSON: https://openchainbench.com/api/stat/pm-rate-limits - Status: live - Headline: Polymarket leads warm book latency at 200 ms (p50, 24h) on Prediction market API rate limits, tested with a daily ramp. **Rankings (p50, 24h):** 1. Polymarket: 200 ms (p99 250 ms, success 100.0%, sample 51828.6) 2. Limitless: 282 ms (p99 1.09 s, success 99.9%, sample 51829.4) 3. Kalshi: 324 ms (p99 589 ms, success 100.0%, sample 51830.5) 4. Manifold: 325 ms (p99 399 ms, success 100.0%, sample 37018.9) 5. Myriad: 1.27 s (p99 3.18 s, success 99.7%, sample 51768.2) **Methodology**: - Endpoint classes per venue. Polymarket: CLOB `/book`, `/midpoint`, Gamma `/markets`. Kalshi: `/markets/{ticker}/orderbook`, `/markets/{ticker}`, `/markets`. Limitless: `/markets/{slug}/orderbook`, `/markets/{slug}`, `/markets/active`. Manifold: `/v0/bets`, `/v0/market/{id}`, `/v0/markets`. Myriad: `/markets/{slug}`, `/markets`. Myriad exposes no order book endpoint; that absence is reported, not worked around. - Pinned market per venue: most liquid, near the money (price between 0.15 and 0.85), expiring more than 24h out. Re pinned daily at 00:00 UTC and immediately on probe_invalid. A degenerate 0.99 book has a latency profile that does not represent real usage. - Warm probes every 5s (7s on Manifold, whose entire API sits behind max-age=5 plus stale-while-revalidate=10; tighter spacing would only measure the cache). Cold connect probe once per minute with keep alives disabled, TCP plus TLS handshake recorded separately. - Every sample records a cache flag from cf-cache-status, x-cache and age headers. Kalshi's market list is served from CloudFront with max-age=15, so its list latency measures the edge, not the API. Edge served samples (cache=hit) are excluded from every latency aggregate and reported through the cache label, so no venue ranks on its CDN. - Outcome classification: ok, timeout (8s), http_4xx, http_5xx, throttled (429), probe_invalid, net_error. Latency aggregates include successful requests only; failures count toward the success rate. probe_invalid covers stale pins, e.g. Limitless serves a CDN cached 400 for four hours once a market expires. Those are our fault, never the venue's. - Daily ramp: 60s per tier at rising requests per 10s window against the book endpoint, one venue at a time, one region at a time on disjoint UTC hours (02:00 us-east, 04:00 eu-west, 06:00 sgp). - Ramp tier clamps: Polymarket and Kalshi 25/50/100 per 10s (at most 7 percent of Polymarket's documented 1500 per 10s book budget), Manifold 15/30/60 (500 req/min per IP documented), Limitless 10/20/40 (limits undocumented, so conservative). Kalshi stops at the first 429 since its token bucket is documented. Myriad is excluded: its keyless budget is 30 req per 10s and ramping it would only measure our own quota. - Ramp abort guard: the run stops the moment throttled plus 5xx responses exceed 1 percent of any 10 second window. The headline ramp metric is p50 latency during the tier minus the warm baseline p50 of the previous hour in the same region, because venues behind Cloudflare queue bursts without ever returning 429, and added latency is the only honest throttle signal there. - WebSocket panel covers venues with a public market WebSocket, which today means Polymarket only. Kalshi requires authentication for WS, Manifold and Myriad have none, Limitless uses socket.io. Absence is shown, not penalized. - Myriad's origin is a single region US East deployment behind Heroku. Latency from eu-west and sgp is geography, reported as measured. - All probes hit documented public developer APIs with the identifying User-Agent `OpenChainBench/1.0 (+https://openchainbench.com/methodology; contact@openchainbench.com)`. We publish latency measurements only, never order book contents or prices, in line with venue data redistribution terms (Kalshi's in particular, applied to all venues equally). - Regions: us-east, eu-west, sgp (Railway). Histogram buckets 25ms to 10s. ## Best prediction market API, ranked by live latency and uptime - Category: Trading - Metric: API latency (price endpoint) (ms) - Page: https://openchainbench.com/benchmarks/pm-api-latency - JSON: https://openchainbench.com/api/stat/pm-api-latency - Status: live - Headline: Limitless leads api latency (price endpoint) at 96 ms (p50, 24h) on Best prediction market API, ranked by live latency and uptime. **Rankings (p50, 24h):** 1. Limitless: 96 ms (p99 639 ms, success 100.0%, sample 51832.4) 2. Polymarket: 200 ms (p99 250 ms, success 100.0%, sample 51831.6) 3. Manifold: 325 ms (p99 399 ms, success 100.0%, sample 37021.7) 4. Kalshi: 326 ms (p99 561 ms, success 100.0%, sample 51833.5) 5. Predexon: 354 ms (p99 2.33 s, success 99.9%, sample 155446) 6. Myriad: 1.27 s (p99 3.18 s, success 99.7%, sample 51772.3) **Methodology**: - Price endpoint per venue. Polymarket: CLOB `/midpoint`. Kalshi: `/markets/{ticker}`. Limitless: `/markets/{slug}`. Manifold: `/v0/market/{id}`. Myriad: `/markets/{slug}`. This is the hot path of real integrations: one market, one quote, polled in a loop. - Warm probes every 5s (7s on Manifold, whose API sits behind max-age=5 plus stale-while-revalidate=10) from us-east, eu-west and sgp over a keep alive pool. A separate cold connect probe once per minute records the TCP plus TLS handshake a brand new client pays. - Every sample carries a cache flag read from cf-cache-status, x-cache and age headers. Latency aggregates exclude cache hits: a CDN hit measures the nearest edge, not the venue's API, and including Manifold's residual cache hits would flatter it by design. - Uptime is the average of a per venue, per region health gauge (pmapi_health) computed by the harness from probe outcomes. 100 percent means every probe cycle in the window succeeded from that region. The 24h and 7d panels below are the live answer to whether each API is up. - Outcome classification: ok, timeout (8s), http_4xx, http_5xx, throttled, probe_invalid, net_error. probe_invalid covers failures that are our pin's fault, such as a market that resolved intraday; those are excluded from both latency and uptime. The pinned market is re selected daily at 00:00 UTC and immediately on probe_invalid. - Division of labor with the sibling benches: how each venue behaves as request rates climb, including throttle onset and 429 handling, is measured in pm-rate-limits (bench 037). How fresh third party data providers relay Polymarket data is measured in pm-data-freshness (bench 032). This bench ranks the venues' own APIs on latency and uptime at a polite request rate. - Myriad's origin is a single region US East deployment behind Heroku, so its latency from eu-west and sgp is dominated by geography. Reported as measured, called out per region. - All five venues are probed by the same open source harness as bench 037, from the same processes, so the two benches share one probe budget and one identifying User-Agent: `OpenChainBench/1.0 (+https://openchainbench.com/methodology; contact@openchainbench.com)`. We publish latency and uptime measurements only, never market data. - Aggregators that resell venue data (Codex, Predexon) are deliberately excluded from this leaderboard. They are not venue APIs, they are relays on top of venue APIs, and ranking them next to the venues they relay would compare two different products on one axis. Their freshness lag against the Polymarket CLOB T0 stream is the relevant metric, measured in the pm-data-freshness bench. The prediction markets hub data feeds tab lists each aggregator with the venues it covers. - Regions: us-east, eu-west, sgp (Railway). Histogram buckets 25ms to 10s. ## Polymarket resolution time, measured onchain - Category: Trading - Metric: Resolution delay (s) - Page: https://openchainbench.com/benchmarks/polymarket-resolution-delay - JSON: https://openchainbench.com/api/stat/polymarket-resolution-delay - Status: live - Headline: Crypto leads resolution delay at 11.2 min (p50, 24h) on Polymarket resolution time, measured onchain. **Rankings (p50, 24h):** 1. Crypto: 11.2 min (p99 71.7 min, success 100.0%, sample 23692) 2. All markets: 48.8 min (p99 237.9 min, success 100.0%, sample 231435) 3. Sports: 51.8 min (p99 237.9 min, success 100.0%, sample 154370) 4. Other: 132.0 min (p99 238.9 min, success 100.0%, sample 52357) 5. Politics: 180.5 min (p99 320.3 min, success 100.0%, sample 1016) **Methodology**: - Anchor: the first OO ProposePrice block timestamp, not Gamma fields. Verified live: Gamma closedTime equals the QuestionResolved block timestamp to the second (circular by construction) and endDate is a scheduled buffer that a majority of markets resolve before. Any 'resolves within X' claim computed from those fields is unfalsifiable. - Sources: Polygon logs of the post-migration UMA CTF adapters (binary 0x65070BE9..., neg-risk 0x69c47De9...) and their Optimistic Oracle (0x2c0367a9...), all address-configurable. Gamma supplies the market catalogue and category tags. - Join: questionID = keccak256 of the proposal ancillary data, verified against QuestionInitialized events. Neg-risk markets expose a different Gamma questionID; categories fall back to keyword classification for those, the delay itself is unaffected. - Categories: sports, politics, crypto, other, classified from Gamma tags plus keyword fallback. Categories run different UMA verification windows, so per category rows are the honest unit of comparison. - Disputes: a DisputePrice before resolution marks the market disputed and its delay lands in the disputed series. QuestionReset events are tracked so re-proposals do not create duplicate joins. - Pending backlog: markets past their scheduled endDate with no onchain resolution, polled from Gamma every cycle. This includes markets whose underlying event has not happened yet despite the date passing, so it is an upper bound. - Listener: 45s incremental Polygon log polling with a 7 day chunked backfill on restart, two public RPC endpoints with rotation and backoff. Counters re-count the backfill window after a restart; quantiles are computed on the cumulative histogram, which the backfill repopulates within minutes. - Delays are measured between block timestamps, so the resolution granularity is Polygon's block time (~2s), negligible against delays measured in minutes and hours. - What this does not measure: the gap between the real world event ending and someone submitting the first proposal. That interval is not observable onchain; the proposal is the first onchain signal that the outcome is known. Reported delays are therefore a lower bound on the total wait. ## Best NFT collection metadata API: Moralis, Alchemy, OpenSea benchmarked - Category: NFT APIs - Metric: Field coverage (pct) - Page: https://openchainbench.com/benchmarks/nft-collection-metadata - JSON: https://openchainbench.com/api/stat/nft-collection-metadata - Status: live - Headline: Moralis leads field coverage at 97.2% (24h avg) on Best NFT collection metadata API: Moralis, Alchemy, OpenSea benchmarked. **Rankings (p50, 24h):** 1. Moralis: 97.2% (p99 97.2%, success 100.0%, sample 3915.68) 2. OpenSea: 94.3% (p99 94.3%, success 100.0%, sample 4145.72) 3. Alchemy: 74.7% (p99 74.7%, success 100.0%, sample 6001.04) **Methodology**: - Collection set: a fixed list of 50 Ethereum blue-chip collections (BAYC, CryptoPunks, Azuki, Pudgy Penguins, Doodles, MAYC, Moonbirds, CloneX, Otherdeeds, Meebits and others). The list is committed to the harness repo and only changes via PR. - Fields scored (5): `name`, `image`, `description`, `floor_eth`, `external_url`. A field counts as covered if the provider returns a non-empty string or a positive number. - Apple-to-apple: each provider gets exactly one chance per field. No OR-of-multiple-URLs tricks. - Providers in scope: Moralis (`/nft/{address}/metadata`), Alchemy (`getContractMetadata`), OpenSea (`/api/v2/collections/{slug}` plus `/api/v2/collections/{slug}/stats` for floor; slug pre-resolved via `/api/v2/chain/ethereum/contract/{addr}`, so OpenSea costs two API calls per collection per check). - Cadence: every 6 hours per provider × collection. Steady-state ≈ 200 checks per provider per day, ~1000 field checks per provider per day. - Region: `eu-west` (single point. multi-region requires running additional monitor instances). - Ratio: `nft_metadata_success_total / nft_metadata_checks_total`, expressed in percent. Failures of the metadata API itself (timeouts, 5xx) are not counted in the denominator. only successful responses with the field check applied. ## Perp DEX volume share, live 24h notional ranked - Category: Trading - Metric: 24h perp volume (usd) - Page: https://openchainbench.com/benchmarks/perp-volume-share - JSON: https://openchainbench.com/api/stat/perp-volume-share - Status: live - Headline: Hyperliquid leads 24h perp volume at $1.27B (24h) on Perp DEX volume share, live 24h notional ranked. **Rankings (p50, 24h):** 1. Hyperliquid: $1.27B (p99 $1.56B, success 83.3%, sample 5759) 2. Lighter: $1.00B (p99 $1.18B, success 83.3%, sample 5759) 3. GRVT: $636.87M (p99 $682.36M, success 66.7%, sample 5759) 4. Aster: $619.05M (p99 $788.30M, success 83.3%, sample 5759) 5. Pacifica: $248.43M (p99 $287.07M, success 66.5%, sample 5759) 6. Extended: $158.46M (p99 $222.95M, success 83.1%, sample 5759) 7. Vertex: $21.91M (p99 $53.26M, success 100.0%, sample 5759) 8. Polymarket: $16.91M (p99 $27.37M, success 80.0%, sample 5759) 9. dYdX v4: $5.92M (p99 $7.10M, success 83.3%, sample 5759) 10. Paradex: $4.03M (p99 $4.94M, success 83.3%, sample 5759) 11. Aevo: $1.96M (p99 $2.33M, success 66.5%, sample 5759) **Methodology**: - Cadence: every 5 minutes per venue in parallel, 10 second timeout per request. - Hyperliquid: info dayNtlVlm summed across all assets, published as the trailing 24 hour taker notional in USD. - Aster: fapi 24h ticker per instrument, quoteVolume summed across all USDT perps. - Lighter: public stats endpoint, 24h volume per market summed across markets in USD. - GRVT: public markets endpoint, 24h volume per instrument summed in USD. - Extended: public markets API, 24h volume per instrument summed in USD. - Pacifica: onchain reads on the Solana program state for trailing 24h taker notional. - Vertex: public indexer, 24h volume per product summed across all perps. - dYdX v4: indexer perpetualMarkets, volume24H summed across markets in USD. - Aevo: public markets endpoint, 24h volume per instrument summed in USD. - Paradex: markets summary on Starknet L2, 24h volume summed across perps. - Headline. avg_over_time of the 24 hour volume gauge over the last 24 hours, so a one-print spike does not move the ranking. The Series tab plots the raw gauge. - Failures. A venue that errors or times out keeps its last gauge value and its perp_venue_health gauge drops toward 0; the leaderboard tags it as stale. ## Perp DEX open interest, live USD notional ranked - Category: Trading - Metric: Open interest (usd) - Page: https://openchainbench.com/benchmarks/perp-open-interest - JSON: https://openchainbench.com/api/stat/perp-open-interest - Status: live - Headline: Hyperliquid leads open interest at $7.51B (24h) on Perp DEX open interest, live USD notional ranked. **Rankings (p50, 24h):** 1. Hyperliquid: $7.51B (p99 $7.73B, success 83.3%, sample 5759) 2. Aster: $967.91M (p99 $986.31M, success 83.3%, sample 5759) 3. Lighter: $441.31M (p99 $450.93M, success 83.3%, sample 5759) 4. GRVT: $357.74M (p99 $364.66M, success 66.7%, sample 5759) 5. Extended: $191.50M (p99 $194.89M, success 83.1%, sample 5759) 6. Pacifica: $103.24M (p99 $104.91M, success 66.5%, sample 5759) 7. Vertex: $66.09M (p99 $67.24M, success 100.0%, sample 5759) 8. dYdX v4: $40.82M (p99 $41.58M, success 83.3%, sample 5759) 9. Ostium: $38.06M (p99 $40.50M, success 60.0%, sample 5759) 10. Polymarket: $26.65M (p99 $28.54M, success 80.0%, sample 5759) 11. Aevo: $9.76M (p99 $9.99M, success 66.5%, sample 5759) 12. Paradex: $9.28M (p99 $9.44M, success 83.3%, sample 5759) 13. gains.trade: $6.58M (p99 $7.81M, success 60.0%, sample 5759) **Methodology**: - Convention: open interest counts each contract once (one side), the standard used by CME, Binance and Coinglass, and the only convention comparable across venues. Aggregators can differ: DefiLlama doubles Lighter and Ostium (long plus short), folds 1,682 options markets into Paradex, and adds HIP-3 sub-dex OI to Hyperliquid. Where our number is about half of theirs, that is the convention gap, not missing data; five venues where conventions align match DefiLlama within 2 percent. - Cadence: every 5 minutes per venue in parallel, 10 second timeout per request. - Hyperliquid: info metaAndAssetCtxs, openInterest summed across all assets and priced in USD using the venue's own mark price. - Aster: fapi openInterest endpoint per instrument, summed across all listed USDT perps. - Lighter: orderBookDetails per market, open interest summed across markets in USD. - GRVT: public markets endpoint, open interest per instrument summed in USD. - Extended: public markets API, open interest per instrument summed in USD. - Ostium: subgraph read for open interest across all listed pairs on Arbitrum. - Pacifica: onchain reads on the Solana program state for aggregate open interest. - Vertex: public indexer, open interest per product summed across all perps. - dYdX v4: indexer perpetualMarkets, openInterest per market summed in USD. - Aevo: public markets endpoint, open interest per instrument summed in USD. - Paradex: markets summary endpoint on Starknet L2, open interest summed across perps. - gains.trade: trading-variables endpoint per chain backend (Arbitrum, Base, Polygon, ApeChain), per-collateral pairOis summed then multiplied by collateralPriceUsd, summed across all chains. - Headline. avg_over_time of the live OI gauge over the last 24 hours, so a one-print spike does not move the ranking. The Series tab plots the raw gauge. - Failures. A venue that errors or times out keeps its last gauge value and its perp_venue_health gauge drops toward 0; the leaderboard tags it as stale. ## Perp DEX funding stability, 24h stddev of ETH funding ranked - Category: Trading - Metric: 24h ETH funding stddev (bps) - Page: https://openchainbench.com/benchmarks/perp-funding-stability - JSON: https://openchainbench.com/api/stat/perp-funding-stability - Status: live - Headline: Polymarket leads 24h eth funding stddev at 0.0015% (24h avg) on Perp DEX funding stability, 24h stddev of ETH funding ranked. **Rankings (p50, 24h):** 1. Polymarket: 0.0015% (p99 0.00064%, success 100.0%, sample 2879) 2. Paradex: 0.0024% (p99 0.0065%, success 100.0%, sample 2879) 3. Coinbase: 0.0031% (p99 0.0045%, success 100.0%, sample 5759) 4. Hyperliquid: 0.0033% (p99 0.016%, success 100.0%, sample 2879) 5. MEXC: 0.0058% (p99 0.0092%, success 100.0%, sample 5759) 6. Gate: 0.0058% (p99 0.0041%, success 100.0%, sample 5759) 7. OKX: 0.0064% (p99 0.0042%, success 100.0%, sample 2879) 8. Bitget: 0.0073% (p99 0.0051%, success 100.0%, sample 5759) 9. Aster: 0.0094% (p99 0.0074%, success 100.0%, sample 2879) 10. Binance: 0.0095% (p99 0.0078%, success 100.0%, sample 2879) 11. Kraken: 0.0097% (p99 0.037%, success 100.0%, sample 5759) 12. dYdX v4: 0.0099% (p99 0.025%, success 100.0%, sample 2879) 13. Bybit: 0.010% (p99 0.014%, success 100.0%, sample 2879) 14. KuCoin: 0.011% (p99 0.0088%, success 100.0%, sample 5759) 15. Lighter: 0.014% (p99 0.014%, success 100.0%, sample 5759) **Methodology**: - Young venues read artificially stable at first: a venue whose funding has not moved since listing (Polymarket perps launched 2026-07-08 with a constant default rate) shows a stddev near zero until real funding history accrues. Read the sample count next to the rank. - Source. Same upstream as perp-funding: each venue's public funding endpoint polled every 60 seconds, normalized to bps per hour and per 24h hold, sign preserved. - Metric. stddev_over_time(perp_funding_hold_24h_bps{asset="ETH"}[24h]) per venue. The 7d window smooths intraday noise but reacts to regime shifts within a week. - Sign handling. The underlying series is signed (positive means longs pay). Stability measures the swing, so the ranking uses the unsigned stddev. Average direction and level are the perp-funding bench. - Cohort. 15 venues across two sources. 7 polled directly (perp_funding_hold_24h_bps): Hyperliquid, Bybit, dYdX v4, Binance, OKX, Paradex, Aster. 8 via Mobula CEFI aggregator (perp_venue_funding_24h_bps): Bitget, Coinbase, Deribit, Gate, Kraken, KuCoin, Lighter, MEXC. Both normalize to bps per 24h hold, sign preserved, so the unsigned stddev compares cleanly across the full cohort. - Success. Same freshness signal as perp-funding: perp_funding_venue_ok_unix advancing within the last 5 minutes. A venue whose scrape stalls is tagged stale on the row. - Cadence. The upstream funding harness polls every 60 seconds; Prometheus scrapes every 30 seconds. The 7 day stddev refreshes on every scrape. - Failures. A venue whose upstream funding feed errors keeps its last gauge value; the leaderboard tags the row stale once the success gauge drops to 0. - Reproducibility. The harness emits perp_funding_hold_24h_bps with labels venue and asset; the bench query is the stddev over 7d on that series with asset=ETH pinned. ## Fastest free Ethereum RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/ethereum-rpc - JSON: https://openchainbench.com/api/stat/ethereum-rpc - Status: live - Headline: dRPC leads rpc latency at 43 ms (p50, 24h) on Fastest free Ethereum RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. dRPC: 43 ms (p99 337 ms, success 77.4%, sample 4172.76) 2. PublicNode: 93 ms (p99 269 ms, success 100.0%, sample 4260.74) 3. Tenderly: 244 ms (p99 298 ms, success 100.0%, sample 4258.74) 4. Lava: 247 ms (p99 2.33 s, success 99.7%, sample 4237.74) 5. MeowRPC: 270 ms (p99 541 ms, success 99.6%, sample 4285.75) 6. Nodies: 271 ms (p99 442 ms, success 100.0%, sample 4311.75) 7. Flashbots: 683 ms (p99 995 ms, success 100.0%, sample 4321.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="ethereum". Provider coverage: 8 no-key endpoints (PublicNode, dRPC, Tenderly, Nodies, Lava, MeowRPC, Flashbots, Cloudflare). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Arbitrum RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/arbitrum-rpc - JSON: https://openchainbench.com/api/stat/arbitrum-rpc - Status: live - Headline: PublicNode leads rpc latency at 90 ms (p50, 24h) on Fastest free Arbitrum RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 90 ms (p99 283 ms, success 100.0%, sample 4251.74) 2. Nodies: 179 ms (p99 313 ms, success 100.0%, sample 4317.75) 3. Lava: 201 ms (p99 1.45 s, success 99.2%, sample 4199.74) 4. Tenderly: 246 ms (p99 291 ms, success 100.0%, sample 4294.75) 5. Arbitrum: 251 ms (p99 332 ms, success 100.0%, sample 4345.75) 6. MeowRPC: 267 ms (p99 428 ms, success 94.0%, sample 4281.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="arbitrum". Provider coverage: 7 no-key endpoints (PublicNode, dRPC, Tenderly, Nodies, Lava, MeowRPC, Arbitrum). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Base RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/base-rpc - JSON: https://openchainbench.com/api/stat/base-rpc - Status: live - Headline: PublicNode leads rpc latency at 90 ms (p50, 24h) on Fastest free Base RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 90 ms (p99 307 ms, success 100.0%, sample 4248.74) 2. dRPC: 164 ms (p99 320 ms, success 65.6%, sample 4216.77) 3. Base: 246 ms (p99 371 ms, success 100.0%, sample 4341.75) 4. Tenderly: 247 ms (p99 274 ms, success 100.0%, sample 4255.74) 5. Nodies: 268 ms (p99 372 ms, success 100.0%, sample 4243.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="base". Provider coverage: 5 no-key endpoints (PublicNode, dRPC, Tenderly, Nodies, Base). Blink (formerly Merkle) was delisted 2026-07: its gateway does not serve `eth_getBlockByNumber`, the anti-cache probe this cluster standardized on, so it cannot be measured on equal terms. Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Optimism RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/optimism-rpc - JSON: https://openchainbench.com/api/stat/optimism-rpc - Status: live - Headline: PublicNode leads rpc latency at 85 ms (p50, 24h) on Fastest free Optimism RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 85 ms (p99 127 ms, success 100.0%, sample 4252.74) 2. dRPC: 163 ms (p99 253 ms, success 66.0%, sample 4285.74) 3. Tenderly: 247 ms (p99 277 ms, success 100.0%, sample 4284.74) 4. Nodies: 269 ms (p99 429 ms, success 100.0%, sample 4324.75) 5. Optimism: 331 ms (p99 368 ms, success 99.9%, sample 4321.92) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="optimism". Provider coverage: 5 no-key endpoints (PublicNode, dRPC, Tenderly, Nodies, Optimism). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Avalanche RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/avalanche-rpc - JSON: https://openchainbench.com/api/stat/avalanche-rpc - Status: live - Headline: PublicNode leads rpc latency at 89 ms (p50, 24h) on Fastest free Avalanche RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 89 ms (p99 278 ms, success 100.0%, sample 4261.74) 2. dRPC: 163 ms (p99 240 ms, success 79.7%, sample 4210.78) 3. Avalanche: 178 ms (p99 323 ms, success 100.0%, sample 4311.75) 4. Tenderly: 336 ms (p99 363 ms, success 100.0%, sample 4334.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="avalanche". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Avalanche). Nodies was delisted 2026-07 when its Avalanche endpoint moved behind a paid plan. Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free BNB Chain RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/bnb-rpc - JSON: https://openchainbench.com/api/stat/bnb-rpc - Status: live - Headline: Binance leads rpc latency at 73 ms (p50, 24h) on Fastest free BNB Chain RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. Binance: 73 ms (p99 396 ms, success 100.0%, sample 4279.74) 2. PublicNode: 170 ms (p99 1.99 s, success 99.8%, sample 4246.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="bnb". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Nodies, Binance). Blink (formerly Merkle) was delisted 2026-07: its gateway does not serve `eth_getBlockByNumber`, the anti-cache probe this cluster standardized on, so it cannot be measured on equal terms. Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Polygon RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/polygon-rpc - JSON: https://openchainbench.com/api/stat/polygon-rpc - Status: live - Headline: dRPC leads rpc latency at 13 ms (p50, 24h) on Fastest free Polygon RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. dRPC: 13 ms (p99 463 ms, success 99.1%, sample 4219.88) 2. PublicNode: 90 ms (p99 357 ms, success 100.0%, sample 4322.8) 3. Tenderly: 338 ms (p99 538 ms, success 100.0%, sample 4225.73) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="polygon". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Nodies). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Linea RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/linea-rpc - JSON: https://openchainbench.com/api/stat/linea-rpc - Status: live - Headline: PublicNode leads rpc latency at 86 ms (p50, 24h) on Fastest free Linea RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 86 ms (p99 261 ms, success 100.0%, sample 4236.73) 2. dRPC: 101 ms (p99 281 ms, success 80.0%, sample 4211.78) 3. Tenderly: 333 ms (p99 421 ms, success 100.0%, sample 4334.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="linea". Provider coverage: 3 no-key endpoints (PublicNode, dRPC, Tenderly). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Scroll RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/scroll-rpc - JSON: https://openchainbench.com/api/stat/scroll-rpc - Status: live - Headline: PublicNode leads rpc latency at 86 ms (p50, 24h) on Fastest free Scroll RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 86 ms (p99 288 ms, success 100.0%, sample 4292.75) 2. dRPC: 202 ms (p99 422 ms, success 79.0%, sample 4306.73) 3. Tenderly: 333 ms (p99 409 ms, success 100.0%, sample 4333.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="scroll". Provider coverage: 3 no-key endpoints (PublicNode, dRPC, Tenderly). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Mantle RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/mantle-rpc - JSON: https://openchainbench.com/api/stat/mantle-rpc - Status: live - Headline: dRPC leads rpc latency at 19 ms (p50, 24h) on Fastest free Mantle RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. dRPC: 19 ms (p99 462 ms, success 78.2%, sample 4182.77) 2. PublicNode: 90 ms (p99 854 ms, success 100.0%, sample 4333.75) 3. Tenderly: 335 ms (p99 366 ms, success 100.0%, sample 4237.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="mantle". Provider coverage: 3 no-key endpoints (PublicNode, dRPC, Tenderly). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Best DEX for a $BOT market order, live slippage ranked - Category: Trading - Metric: Effective slippage (bps) - Page: https://openchainbench.com/benchmarks/perp-execution-quality - JSON: https://openchainbench.com/api/stat/perp-execution-quality - Status: live - Headline: Hyperliquid leads effective slippage at 0.30% (24h avg) on Best DEX for a $BOT market order, live slippage ranked. **Rankings (p50, 24h):** 1. Hyperliquid: 0.30% (p99 0.56%, success 100.0%, sample 3897) 2. Lighter: 5.45% (p99 5.96%, success 100.0%, sample 5759) **Methodology**: - Cadence: every 30 seconds, in parallel across both venues, 10 second timeout per fetch. - Lighter: `GET https://mainnet.zklighter.elliot.ai/api/v1/orderBookOrders?market_id=185&limit=100` returns the top-100 asks and bids for the $BOT perp market. - Hyperliquid HIP-3: `POST https://api.hyperliquid.xyz/info {"type":"l2Book","coin":"xyz:BOT"}` returns the L2 book for the xyz-deployed BOT perp under HIP-3 permissionless listings. - Mid price: (best_bid + best_ask) / 2 from the top of each book, per tick, per venue. - Walk: for each USD notional bucket, iterate the sorted side, consuming `min(level_notional_usd, remaining_target_usd)` until target is filled; size-weighted average execution price is target_usd / total_base_filled. - Slippage bps: (avg_execution_price - mid) / mid x 10000 on the buy side, mirrored on the sell side, sign-normalized so every published value represents cost to the trader. - Buckets published: $100, $1,000, $5,000, $10,000, $25,000, $50,000, $100,000, $500,000. Both sides (buy, sell). - Depth fallback: if the visible book does not cover 99% of the requested size, the slippage series for that (venue, side, size) is dropped for that tick and `perp_execution_max_fillable_usd{side}` reports the ceiling instead. - Headline. avg_over_time of `perp_execution_slippage_bps{asset="BOT", side="buy", size_usd="5000"}` over 24h, per venue. A one-print spike does not move the ranking. - Failures. A venue that errors or times out drops its `perp_execution_health` to 0 and increments `perp_execution_fetch_errors_total{error_type}`; the leaderboard tags it as stale. - CEX venues are intentionally out of scope. Traders comparing against a Binance or Bybit fill should read DefiLlama for the CEX-side audit; the DEX bench does not aggregate what it cannot orderbook-walk from a public endpoint. ## Fastest free Sonic RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/sonic-rpc - JSON: https://openchainbench.com/api/stat/sonic-rpc - Status: live - Headline: PublicNode leads rpc latency at 91 ms (p50, 24h) on Fastest free Sonic RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 91 ms (p99 297 ms, success 100.0%, sample 4212.73) 2. dRPC: 173 ms (p99 265 ms, success 77.8%, sample 4186.77) 3. Sonic Labs: 214 ms (p99 668 ms, success 100.0%, sample 4321.75) 4. Tenderly: 335 ms (p99 373 ms, success 100.0%, sample 4212.73) 5. Lava: 469 ms (p99 2.67 s, success 100.0%, sample 4235.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="sonic". Provider coverage: 5 no-key endpoints (PublicNode, dRPC, Tenderly, Lava, Sonic Labs). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Gnosis RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/gnosis-rpc - JSON: https://openchainbench.com/api/stat/gnosis-rpc - Status: live - Headline: PublicNode leads rpc latency at 89 ms (p50, 24h) on Fastest free Gnosis RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 89 ms (p99 304 ms, success 100.0%, sample 4277.74) 2. dRPC: 167 ms (p99 244 ms, success 81.9%, sample 4294.77) 3. Tenderly: 336 ms (p99 420 ms, success 100.0%, sample 4260.74) 4. Gnosis: 349 ms (p99 1.32 s, success 100.0%, sample 4251.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="gnosis". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Gnosis). Nodies was delisted 2026-07 when its Gnosis endpoint moved behind a paid plan. Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Celo RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/celo-rpc - JSON: https://openchainbench.com/api/stat/celo-rpc - Status: live - Headline: PublicNode leads rpc latency at 94 ms (p50, 24h) on Fastest free Celo RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 94 ms (p99 482 ms, success 100.0%, sample 4277.74) 2. Celo (Forno): 198 ms (p99 369 ms, success 100.0%, sample 4264.74) 3. dRPC: 236 ms (p99 1.12 s, success 70.6%, sample 4251.74) 4. Tenderly: 337 ms (p99 507 ms, success 100.0%, sample 4243.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="celo". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Celo (Forno)). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Moonbeam RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/moonbeam-rpc - JSON: https://openchainbench.com/api/stat/moonbeam-rpc - Status: live - Headline: PublicNode leads rpc latency at 89 ms (p50, 24h) on Fastest free Moonbeam RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 89 ms (p99 500 ms, success 100.0%, sample 4225.73) 2. Moonbeam: 183 ms (p99 536 ms, success 100.0%, sample 4301.75) 3. dRPC: 203 ms (p99 491 ms, success 78.8%, sample 4247.74) 4. Tenderly: 335 ms (p99 360 ms, success 100.0%, sample 4227.73) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. ## Fastest free Unichain RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/unichain-rpc - JSON: https://openchainbench.com/api/stat/unichain-rpc - Status: live - Headline: PublicNode leads rpc latency at 93 ms (p50, 24h) on Fastest free Unichain RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 93 ms (p99 309 ms, success 100.0%, sample 4284.74) 2. dRPC: 164 ms (p99 227 ms, success 78.6%, sample 4166.77) 3. Unichain: 249 ms (p99 348 ms, success 100.0%, sample 4237.74) 4. Tenderly: 335 ms (p99 372 ms, success 100.0%, sample 4248.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="unichain". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Unichain). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Blast RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/blast-rpc - JSON: https://openchainbench.com/api/stat/blast-rpc - Status: live - Headline: Blast leads rpc latency at 2 ms (p50, 24h) on Fastest free Blast RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. Blast: 2 ms (p99 3 ms, success 100.0%, sample 4237.74) 2. PublicNode: 89 ms (p99 272 ms, success 100.0%, sample 4230.73) 3. dRPC: 177 ms (p99 293 ms, success 78.0%, sample 4208.78) 4. Tenderly: 336 ms (p99 384 ms, success 100.0%, sample 4345.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="blast". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Blast). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Taiko RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/taiko-rpc - JSON: https://openchainbench.com/api/stat/taiko-rpc - Status: live - Headline: PublicNode leads rpc latency at 94 ms (p50, 24h) on Fastest free Taiko RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. PublicNode: 94 ms (p99 620 ms, success 100.0%, sample 4266.74) 2. Taiko: 220 ms (p99 879 ms, success 100.0%, sample 4209.73) 3. dRPC: 244 ms (p99 1.43 s, success 74.1%, sample 4264.74) 4. Tenderly: 333 ms (p99 352 ms, success 100.0%, sample 4252.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="taiko". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Taiko). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Berachain RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/berachain-rpc - JSON: https://openchainbench.com/api/stat/berachain-rpc - Status: live - Headline: Berachain leads rpc latency at 171 ms (p50, 24h) on Fastest free Berachain RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. Berachain: 171 ms (p99 515 ms, success 100.0%, sample 4284.74) 2. PublicNode: 201 ms (p99 601 ms, success 100.0%, sample 4274.74) 3. dRPC: 248 ms (p99 1.55 s, success 76.6%, sample 4176.76) 4. Tenderly: 333 ms (p99 360 ms, success 100.0%, sample 4258.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="berachain". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Berachain). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free zkSync Era RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/zksync-rpc - JSON: https://openchainbench.com/api/stat/zksync-rpc - Status: live - Headline: dRPC leads rpc latency at 167 ms (p50, 24h) on Fastest free zkSync Era RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. dRPC: 167 ms (p99 242 ms, success 81.5%, sample 4292.75) 2. zkSync: 223 ms (p99 873 ms, success 99.4%, sample 4285.76) 3. Tenderly: 338 ms (p99 403 ms, success 99.8%, sample 4338.78) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="zksync". Provider coverage: 3 no-key endpoints (dRPC, Tenderly, zkSync). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Cronos RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/cronos-rpc - JSON: https://openchainbench.com/api/stat/cronos-rpc - Status: live - Headline: Cronos leads rpc latency at 25 ms (p50, 24h) on Fastest free Cronos RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. Cronos: 25 ms (p99 49 ms, success 100.0%, sample 4231.73) 2. PublicNode: 95 ms (p99 374 ms, success 100.0%, sample 4225.73) 3. dRPC: 254 ms (p99 377 ms, success 78.3%, sample 4182.77) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. ## Fastest free Fraxtal RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/fraxtal-rpc - JSON: https://openchainbench.com/api/stat/fraxtal-rpc - Status: live - Headline: Fraxtal leads rpc latency at 22 ms (p50, 24h) on Fastest free Fraxtal RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. Fraxtal: 22 ms (p99 176 ms, success 100.0%, sample 4287.74) 2. dRPC: 166 ms (p99 248 ms, success 77.1%, sample 4186.79) 3. PublicNode: 254 ms (p99 657 ms, success 100.0%, sample 4311.75) 4. Tenderly: 335 ms (p99 364 ms, success 100.0%, sample 4313.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="fraxtal". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Fraxtal). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free Soneium RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/soneium-rpc - JSON: https://openchainbench.com/api/stat/soneium-rpc - Status: live - Headline: Soneium leads rpc latency at 12 ms (p50, 24h) on Fastest free Soneium RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. Soneium: 12 ms (p99 26 ms, success 100.0%, sample 4230.73) 2. PublicNode: 151 ms (p99 834 ms, success 100.0%, sample 4296.75) 3. dRPC: 171 ms (p99 675 ms, success 76.1%, sample 4164.77) 4. Tenderly: 335 ms (p99 361 ms, success 100.0%, sample 4264.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - Archive depth: every 5 minutes we issue `eth_getBalance` at (head − depth) for depths from Geth's default pruned cap up to 5M blocks, exposing which free endpoints actually serve historical state. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to chain="soneium". Provider coverage: 4 no-key endpoints (PublicNode, dRPC, Tenderly, Soneium). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Freshest wallet data API. Zerion, Moralis, Allium, GoldRush, Mobula - Category: Aggregators - Metric: Indexing freshness (sec) - Page: https://openchainbench.com/benchmarks/indexing-freshness - JSON: https://openchainbench.com/api/stat/indexing-freshness - Status: live - Headline: Zerion leads indexing freshness at 1.6 s (p50, 24h) on Freshest wallet data API. Zerion, Moralis, Allium, GoldRush, Mobula. **Rankings (p50, 24h):** 1. Zerion: 1.6 s (p99 10.7 s, success 100.0%, sample 144.025) 2. Mobula: 1.8 s (p99 7.9 s, success 100.0%, sample 144.025) 3. Allium: 2.6 s (p99 3.9 s, success 100.0%, sample 48.0083) 4. Moralis: 13.7 s (p99 23.9 s, success 97.2%, sample 36.0062) **Methodology**: - Ground truth: one probe event per 10 minutes. The harness watches new Base blocks through its own RPC and picks one random plain native transfer (value > 0, empty calldata, OP-stack system deposit excluded). T0 is the instant the harness observes the containing block; the same T0 is used for every provider. - Anti-gaming by construction: the measured wallet is a random real user's address, different on every event, so no provider can whitelist or pre-warm a known benchmark wallet. Every measurement is re-verifiable by anyone from the public tx hash. - Poll schedule: each provider's wallet transactions endpoint is polled at 1, 2, 3, 4, 6, 8, 11, 15, 20, 26, 34, 45, 60, 80, 100 and 120 seconds after T0. Reported lag is the first poll at which the response contains the tx hash, an upper bound with resolution equal to the gap between consecutive polls. - Detection is parser-free: the raw response body is scanned for the tx hash substring. Every cohort API returns the hash verbatim, so no provider gains or loses from response schema differences. - Cold wallets by design: because each event uses a never-before-queried address, results include any on-demand indexing path a provider runs for new wallets. This mirrors the experience of a user opening an app on a fresh address, and it is disclosed here because warm, continuously-queried wallets may see lower lags. - Classification: found (lag recorded), missed (not indexed within 120s), api_error (provider errored on every poll of the event). Percentiles are computed from the histogram of found lags over 24h; the miss rate is published alongside because latency without reliability is a misleading ranking signal. - Quota fairness: per-provider monthly call budgets sized to each free tier with headroom, enforced by a guard that pauses probing at 90%. Allium participates in every third event (20k calls/month free tier); all other providers join every event. Sample sizes per provider are published. - Scope: Base mainnet, single probe region. Freshness lags are measured in seconds while cross-region network deltas are milliseconds, so multi-region probing would add cost without changing the ranking; this is revisited if two providers converge within one poll-step of each other. ## Fastest free Monad RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/monad-rpc - JSON: https://openchainbench.com/api/stat/monad-rpc - Status: live - Headline: Monad leads rpc latency at 2 ms (p50, 24h) on Fastest free Monad RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. Monad: 2 ms (p99 3 ms, success 100.0%, sample 4225.73) 2. OnFinality: 124 ms (p99 2.22 s, success 100.0%, sample 4314.75) 3. dRPC: 187 ms (p99 231 ms, success 99.0%, sample 4246.74) 4. Tenderly Gateway: 335 ms (p99 356 ms, success 100.0%, sample 4317.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms to 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. Every endpoint on this page was live-verified (eth_chainId match + anti-cache probe) before inclusion on 2026-07-08. - Chain scope: every query on this page is pinned to chain="monad" (chain id 143, mainnet since November 2025). Provider coverage: 5 no-key endpoints (Monad Official, dRPC, Tenderly Gateway, bloXroute, OnFinality). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest free MegaETH RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/megaeth-rpc - JSON: https://openchainbench.com/api/stat/megaeth-rpc - Status: live - Headline: MegaETH Official leads rpc latency at 22 ms (p50, 24h) on Fastest free MegaETH RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. MegaETH Official: 22 ms (p99 135 ms, success 100.0%, sample 4273.74) 2. dRPC: 167 ms (p99 293 ms, success 78.9%, sample 4214.77) 3. Tenderly Gateway: 336 ms (p99 355 ms, success 100.0%, sample 4330.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that answer eth_blockNumber without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms to 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 20 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](/benchmarks/rpc-capabilities) benchmark; the identical harness, methodology and exclusion rules apply on every chain. Every endpoint on this page was live-verified (eth_chainId match + anti-cache probe) before inclusion on 2026-07-08. - Chain scope: every query on this page is pinned to chain="megaeth" (chain id 4326, mainnet since February 2026). Provider coverage: 3 no-key endpoints (MegaETH Official, dRPC, Tenderly Gateway). Exclusions follow the cluster-wide rules documented on the parent benchmark. ## Fastest MEV protection RPC, live wallet latency and method coverage - Category: RPCs - Metric: Wallet call latency (ms) - Page: https://openchainbench.com/benchmarks/mev-protect-rpc - JSON: https://openchainbench.com/api/stat/mev-protect-rpc - Status: live - Headline: bloXroute Protect leads wallet call latency at 9 ms (p50, 24h) on Fastest MEV protection RPC, live wallet latency and method coverage. **Rankings (p50, 24h):** 1. bloXroute Protect: 9 ms (p99 10 ms, success 100.0%, sample 60463.2) 2. 48 Club Privacy RPC: 21 ms (p99 25 ms, success 100.0%, sample 30231.5) 3. PancakeSwap MEV Guard: 23 ms (p99 33 ms, success 100.0%, sample 30231.5) 4. MEV Blocker: 36 ms (p99 220 ms, success 99.8%, sample 30225.7) 5. Blink: 96 ms (p99 108 ms, success 96.4%, sample 90693.9) 6. Flashbots Protect: 102 ms (p99 110 ms, success 100.0%, sample 30230.7) 7. BlockSec Anti-MEV: 103 ms (p99 113 ms, success 100.0%, sample 60463.1) **Methodology**: - Providers measured, one row per (provider, chain), all keyless and live-verified 2026-07-12. Ethereum cohort: Flashbots Protect (rpc.flashbots.net), MEV Blocker (rpc.mevblocker.io), Blink formerly Merkle (ethereum.blinklabs.xyz), bloXroute Protect (eth-protect.rpc.blxrbdn.com), BlockSec Anti-MEV (eth.rpc.blocksec.com). - Base cohort: Blink (base.merkle.io) alone. No other MEV-protect gateway exposes a keyless Base endpoint today; Flashbots and MEV Blocker are Ethereum-only by design and base.rpc.blxrbdn.com is plain RPC, not documented as Protect. - BSC cohort: Blink (bsc.merkle.io), bloXroute Protect (bsc.rpc.blxrbdn.com), 48 Club Privacy RPC (rpc.48.club), PancakeSwap MEV Guard (bscrpc.pancakeswap.finance, powered by 48 Club), BlockSec (bsc.rpc.blocksec.com). - Exclusions: SecureRPC probed dead 2026-07-10. Alchemy MEV Protect and GetBlock protected endpoints are key-gated. Blink's Ethereum row uses the blinklabs.xyz host because the legacy eth.merkle.io alias rate-limits harder; on Base and BSC the merkle.io hosts are Blink's only keyless surface (base/bsc.blinklabs.xyz do not resolve as of 2026-07-12). - Chain dimension: the tabs pin every query to one chain. The All chains headline averages each provider over the chains it actually serves, the same convention as the rpc-capabilities cluster; the Chains covered panel shows the multi-chain footprint explicitly. - Method set: eth_chainId, eth_blockNumber, eth_gasPrice, eth_getBalance, eth_call (USDC balanceOf), eth_estimateGas, eth_feeHistory. One request per method per tick, 1.5s apart, rotating request ids against body-keyed edge caches. - Cadence: every 60 seconds per region (us-east, eu-west, sgp), 7 requests per gateway per tick, rows probed in parallel so each gateway still sees one request per 1.5s. Deliberately polite: these gateways rate-ban aggressive callers. - Headline: median latency across the methods the provider served that tick, aggregated over 24h with quantile_over_time. A rejected method does not poison the latency; it lowers the coverage panel instead. - Coverage: mev_rpc_methods_supported counts the wallet methods served on the last tick (max 7) per chain. Flashbots rejects eth_call on the public endpoint; Blink blocks full-node reads like eth_getBlockByNumber, which keeps it off the general RPC benches but not off this one. - Out of scope, disclosed: inclusion rate, refund economics and sandwich protection efficacy are the write path and require funded transactions. See the arXiv study Private MEV Protection RPCs (2505.19708) for a one-off execution-quality comparison. - Success rate counts transport failures only (timeouts, throttling, network); a method a gateway refuses by policy is a coverage gap shown in the coverage panel, not an outage. Failures increment mev_rpc_call_total{result}; the gauge keeps its last value so the chart shows the outage in the success column rather than a fake zero. ## Fastest free Solana RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/solana-rpc - JSON: https://openchainbench.com/api/stat/solana-rpc - Status: live - Headline: Solana leads rpc latency at 10 ms (p50, 24h) on Fastest free Solana RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. Solana: 10 ms (p99 463 ms, success 99.9%, sample 4291.98) 2. PublicNode: 85 ms (p99 479 ms, success 100.0%, sample 4217.73) 3. Solana Vibe Station: 209 ms (p99 704 ms, success 100.0%, sample 4295.75) 4. Lava: 223 ms (p99 1.47 s, success 99.5%, sample 4210.73) 5. LeoRPC: 616 ms (p99 2.02 s, success 62.0%, sample 4187.93) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"getSlot","params":[{"commitment":"processed"}]}`. Plain HTTP POST, identical for every endpoint, no API key in any request; the rotating id defeats body-keyed edge caches. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram, percentiles computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok`, `http_err`, `jsonrpc_err`, `stale` (more than 300 slots, about 2 minutes, behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - No archive-depth audit on Solana: the EVM chains probe `eth_getBalance` at historical heights, which has no equivalent on public Solana endpoints. Disclosed rather than faked. - LeoRPC disclosure: the endpoint uses a publicly documented FREE query key (solana.leorpc.com/?api_key=FREE). It is admitted as keyless in practice since no signup is required; flagged here for transparency. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; identical harness and exclusion rules. - Chain scope: every query on this page is pinned to chain="solana". Provider coverage: 5 no-key endpoints (Solana Labs, PublicNode, Lava, LeoRPC, Solana Vibe Station). Excluded with verified refusals 2026-07-12: dRPC (Solana is paid-tier only), Ankr (403 key required), OnFinality (shared quota permanently 429), BlockPI (no public URL), Triton free.rpcpool.com (403), Blast API + ExtrNode + AllThatNode (DNS dead), OMNIA (521), Helius + Shyft + BlockEden (key-gated). ## Tokenized stock price accuracy, live onchain vs Nasdaq across 11 equities - Category: RWA - Metric: Price deviation (bps) - Page: https://openchainbench.com/benchmarks/tokenized-stock-peg - JSON: https://openchainbench.com/api/stat/tokenized-stock-peg - Status: live - Headline: NVDA leads price deviation at 0.18% (24h avg) on Tokenized stock price accuracy, live onchain vs Nasdaq across 11 equities. **Rankings (p50, 24h):** 1. NVDA: 0.18% (p99 0.18%, success 100.0%, sample 40317) 2. PLTR: 0.26% (p99 0.26%, success 100.0%, sample 40317) 3. META: 0.37% (p99 0.37%, success 100.0%, sample 40317) 4. MU: 0.53% (p99 0.53%, success 100.0%, sample 40317) 5. AMD: 0.61% (p99 0.61%, success 100.0%, sample 40317) 6. AAPL: 0.71% (p99 0.71%, success 100.0%, sample 40317) **Methodology**: - Onchain leg: one JSON-RPC batch per tick to StateView (0xF3334192D15450CdD385c8B70e03f9A6bD9E673b) getSlot0(poolId) on the Uniswap v4 PoolManager singleton, keyless against the official Robinhood Chain RPC. sqrtPriceX96 converts to USDG per share with the per-pool currency ordering and the USDG 6 vs stock 18 decimal gap (factor 1e12). - Reference leg: Yahoo Finance v8 spark batch, one call for all 11 symbols per tick, browser User-Agent, no key. regularMarketPrice doubles as the last-close reference when the market is closed, which is exactly the weekend baseline. - Market session labels: derived from Yahoo currentTradingPeriod epochs (pre / regular / post / closed), which Yahoo publishes holiday-aware, so the harness maintains no NYSE calendar. The headline ranking pins market_state="regular"; the closed series is the drift panel. - Deviation: 10000 x |pool_price - reference_price| / reference_price, sampled every 60 seconds, quantiles over 24h via quantile_over_time. - Cohort: the 11 official tokenized equities (name pattern * Robinhood Token, shared verified Stock implementation) whose USDG pool has real liquidity and swap history: NVDA, AAPL, GOOGL, TSLA, PLTR, META, AMD, MSFT, AMZN, SPY, MU. Pool fees range 0.3% to 2%. - Excluded, with reasons: SPCX (SpaceX pool holds ~$196k but SpaceX is not listed, no reference price exists), SNDK and QQQ (pool depth under $2k, deviation would be noise), CRCL (pool at zero liquidity), ~80 other official tokens (issuer-seeded placeholder pools at 90-95% fee, zero swaps), HOOD (never issued onchain, all HOOD tokens on the chain are third-party spam). - Thin liquidity is part of the story, not a defect: pool depths run $24k to $330k, so a single mid-size swap can move the onchain price meaningfully off the reference until arbitrage closes it. The bench measures how fast that closure actually happens. - Reading grid: an AMM price can sit anywhere inside the pool's fee band without creating an arbitrage opportunity, so a 2% fee pool resting 150 bps off its reference is economically at equilibrium, not broken. Cross-symbol ranking therefore partly reflects each pool's fee tier (disclosed in every tag); the within-symbol trend over time is the purest signal. - Quote-asset caveat: pool prices are denominated in USDG and compared against USD references. A USDG peg wobble would appear as a correlated deviation across all 11 symbols simultaneously, which is the signature to check before reading a broad move as tracking error. - Caveats: the issuer can pause or blocklist a token (the harness drops the sample and lets the series age out rather than freezing), and the Stock contract carries a split multiplier; a corporate action can look like a one-day deviation spike until reconciled. ## xStocks price accuracy, live onchain vs Nasdaq across 12 equities on Solana - Category: RWA - Metric: Price deviation (bps) - Page: https://openchainbench.com/benchmarks/xstocks-peg - JSON: https://openchainbench.com/api/stat/xstocks-peg - Status: live - Headline: AMZNx leads price deviation at 0.057% (24h avg) on xStocks price accuracy, live onchain vs Nasdaq across 12 equities on Solana. **Rankings (p50, 24h):** 1. AMZNx: 0.057% (p99 0.057%, success 97.8%, sample 40317) 2. TSLAx: 0.094% (p99 0.094%, success 97.7%, sample 40317) 3. HOODx: 0.096% (p99 0.096%, success 97.5%, sample 40317) 4. NVDAx: 0.11% (p99 0.11%, success 100.0%, sample 40317) 5. AAPLx: 0.18% (p99 0.18%, success 100.0%, sample 40317) 6. COINx: 0.19% (p99 0.19%, success 96.5%, sample 40317) 7. QQQx: 0.33% (p99 0.33%, success 96.5%, sample 40317) 8. GOOGLx: 0.39% (p99 0.39%, success 97.8%, sample 40317) 9. PLTRx: 0.42% (p99 0.42%, success 100.0%, sample 40317) 10. METAx: 0.51% (p99 0.51%, success 100.0%, sample 40317) 11. SPYx: 0.66% (p99 0.66%, success 96.5%, sample 40317) 12. MSFTx: 0.73% (p99 0.73%, success 97.8%, sample 40317) **Methodology**: - Onchain leg: Jupiter lite-api swap quotes, keyless, both directions per symbol (sell 1 share to USDC, buy the proceeds back), spaced 1.1s apart, ~26s per sweep for 12 symbols. Price = mid of the two implied prices: an executable aggregated price across Raydium, Orca and every routed venue, not a single pool spot. - Token-2022 correction: 7 of 12 xStocks mints carry a ScaledUiAmount multiplier (~1.0009 observed). One batched price/v3 call per tick supplies the live multiplier per mint (usdPrice over usdPricePrescaled), converting raw quote units to exactly one UI share. Ignoring it would bake a ~9bp systematic error into affected symbols. - Reference leg: Yahoo Finance spark batch, one keyless call for all 12 underliers per tick, 1 minute candles; session labels (pre, regular, post, closed) derived from Yahoo currentTradingPeriod, holiday aware. HOODx maps to HOOD, SPYx to SPY, QQQx to QQQ, COINx to COIN. - Deviation: 10000 x |executable mid - reference| / reference, quantiles over 24h via quantile_over_time. Headline pins market_state="regular"; the closed series is the weekend drift panel. - Cohort: the 12 xStocks with verified Jupiter routes at under 2bp of 1-share price impact (2026-07-13): TSLAx, NVDAx, AAPLx, MSFTx, AMZNx, GOOGLx, METAx, HOODx, SPYx, QQQx, COINx, PLTRx. All mints 8 decimals, verified individually; counterfeit lookalike mints excluded by address allowlist. - Round-trip honesty: the sell/buy spread observed at verification was ~11bp on TSLAx. Using the mid rather than one side keeps the fee component out of the deviation number; the spread itself is executable cost, not tracking error. - Quote asset caveat: prices are in USDC against USD references. A USDC peg wobble would appear as a correlated deviation across all 12 symbols simultaneously. - Cross-issuer reading: this bench shares its metric contract with the Robinhood Chain tokenized stock bench (issuer label). Same equity, same reference, two issuers: the pages are directly comparable, with the depth difference disclosed (Solana xStocks pools run 10x to 100x deeper). ## USDY NAV basis, live market price vs official redemption rate - Category: RWA - Metric: NAV basis (bps) - Page: https://openchainbench.com/benchmarks/usdy-nav-basis - JSON: https://openchainbench.com/api/stat/usdy-nav-basis - Status: live - Headline: Orca (Solana) leads nav basis at 0.055% (24h avg) on USDY NAV basis, live market price vs official redemption rate. **Rankings (p50, 24h):** 1. Orca (Solana): 0.055% (p99 0.055%, success 71.2%, sample 40317) 2. Pyth market composite: 0.16% (p99 0.22%, success 100.0%, sample 40317) **Methodology**: - NAV leg: the Pyth Hermes feed Crypto.USDY/USD.RR (the redemption rate Ondo publishes onchain), fetched keyless. The same Hermes call carries the Pyth USDY/USD market composite, which doubles as a venue row. - Market leg, Orca: the USDY/USDC whirlpool on Solana (~$2.9M, the deepest genuine USDY pool anywhere), price decoded straight from getAccountInfo bytes (sqrtPrice u128 at offset 65, both mints 6 decimals). Keyless against a public RPC. - Basis: signed, (market - NAV) / NAV x 10000. Negative = the market discounts the NAV. The ranking sorts by absolute basis; the sign is the story and both are displayed. - Excluded, verified 2026-07-13: the Arbitrum Camelot USDY/USDC pool holds 232 USDY against 7M USDC, effectively drained, its stale price sitting ~345bps under NAV with near zero volume. Kept out of the ranking as the textbook example of why pool depth gates peg quality; revisited monthly. - Also not measurable, disclosed: OUSG, BUIDL and BENJI are transfer-restricted mint/redeem instruments with no genuine open pools, so no market test of their NAV exists to publish. - USDY is yield accruing: the redemption rate rises daily, so a naive USD peg comparison would show permanent drift. Comparing against the live RR feed removes that by construction. ## Tokenized stock weekend drift, how far each equity wanders Friday to Monday - Category: RWA - Metric: Weekend max drift (bps) - Page: https://openchainbench.com/benchmarks/tokenized-stock-weekend-drift - JSON: https://openchainbench.com/api/stat/tokenized-stock-weekend-drift - Status: live - Headline: AAPL leads weekend max drift at 0.97% (24h avg) on Tokenized stock weekend drift, how far each equity wanders Friday to Monday. **Rankings (p50, 24h):** 1. AAPL: 0.97% (p99 1.13%, success 100.0%, sample 40317) 2. NVDA: 1.08% (p99 2.86%, success 100.0%, sample 40317) 3. META: 1.51% (p99 2.01%, success 100.0%, sample 40317) 4. AMD: 2.62% (p99 4.14%, success 100.0%, sample 40317) 5. MU: 4.04% (p99 8.88%, success 100.0%, sample 40317) 6. PLTR: 4.24% (p99 4.24%, success 100.0%, sample 40317) **Methodology**: - Data source: the tsp_deviation_bps series emitted by the tokenized-stock-peg harness with the label market_state="closed". No new probe; the metric is a recording rule on existing samples. - Session windows come from Yahoo currentTradingPeriod (holiday aware), which the harness already labels; the closed state runs from post-market close (roughly 21:00 UTC) to the next regular open (roughly 13:30 UTC). - Weekend max drift: max_over_time(tsp_deviation_bps{issuer="robinhood", market_state="closed"}[72h]), aggregated per calendar weekend and labeled with the ISO week. The 72h window covers all pre-market and after-hours slots on either side of the weekend, not just the 60h weekend gap. - Cohort: the 11 tokenized equities measured by the tokenized stock peg bench (NVDA, AAPL, GOOGL, TSLA, PLTR, META, AMD, MSFT, AMZN, SPY, MU). Same pool addresses, same reference, same fee tiers. - The measurement is a bound, not a fair value: an AMM can sit anywhere inside its fee band without creating arbitrage, so weekend drift on a 2 percent fee pool starts at 200 bps by construction. Read the drift number alongside the pool fee, disclosed on the tokenized-stock-peg page. - Not a claim about corporate fair value: the reference is Friday close, not the theoretical opening indication. When earnings, dividends or macro events happen on the weekend, Monday open will differ from Friday close by the same amount whether the pool moved or not. ## Fastest Ethereum WebSocket newHeads push, live block-push lag across RPC providers - Category: RPCs - Metric: Block push lag (ms) - Page: https://openchainbench.com/benchmarks/ws-head-latency-ethereum - JSON: https://openchainbench.com/api/stat/ws-head-latency-ethereum - Status: live - Headline: PublicNode leads block push lag at 0.4 ms (p50, 24h) on Fastest Ethereum WebSocket newHeads push, live block-push lag across RPC providers. **Rankings (p50, 24h):** 1. PublicNode: 0.4 ms (p99 10.24 s, success 100.0%, sample 28732.9) 2. dRPC: 126 ms (p99 10.24 s, success 99.9%, sample 28710.8) 3. OnFinality: 258 ms (p99 2.77 s, success 75.0%, sample 21547.3) 4. Tenderly: 2.59 s (p99 10.24 s, success 99.8%, sample 28682.5) **Methodology**: - Providers measured (keyless WebSocket endpoints): PublicNode (wss://ethereum-rpc.publicnode.com), dRPC (wss://eth.drpc.org), Tenderly (wss://mainnet.gateway.tenderly.co), Onfinality (wss://eth.api.onfinality.io/public-ws). Keyed providers (Alchemy, Infura, Chainstack, QuickNode) join the cohort when contributor keys are wired via WS_URL__ETHEREUM env vars; the harness skips them cleanly when unset. - Cohort saturation: Ankr, Blast, LlamaRPC, BlockPI, 1RPC, NodeReal and Omniatech all reject a keyless WebSocket handshake at the time of ship (verified 2026-07), which is why the keyless tier stops at four (PublicNode, dRPC, Tenderly, Onfinality). - Chains: Ethereum (headline, all four providers compete), Base via newHeads and Solana via slotSubscribe as secondary cohorts. Headline queries on this page are pinned to chain=ethereum so the ranking never mixes block cadences. - Race scoring: the first provider to deliver block N sets T0. Each provider's sample for block N is arrival(N) minus T0 in milliseconds. The cohort closes 5 seconds after the first arrival; a provider arriving later than that is scored as a missed block (ws_block_gap_total), not as a huge latency sample. - Relative, not absolute: a single vantage point cannot separate its own network path from provider pipeline time, so we subtract the two arrivals over the same path instead. Consequence: the fastest provider reads ~0 by construction, and the honest readings are win rate, the trailers' lag distribution, and gap counts, not the leader's absolute number. - Blocks where only one provider delivered within the window emit no lag samples and no win: a one-horse race carries no relative information. Gap counters still increment for live providers that missed the block. - Connection discipline: one persistent WebSocket per (provider, chain), client ping every 30s, read deadline 60s, plus a 90s head watchdog that forces a reconnect when a provider keeps the socket heartbeat alive but silently drops the subscription (a failure mode we have observed in production on other benches). Reconnects use exponential backoff 2s to 60s and are counted in ws_reconnects_total. - Coverage score: ws_head_blocks_seen_total per provider divided by the cohort maximum over the same 24h window, clamped to 1. A provider that pushes fast but skips blocks loses on this column rather than hiding in the latency percentiles. - Aggregation: per-provider lag histogram with a sub-millisecond floor (0.5 ms bucket up through 10 s tail), p50/p90/p99 via histogram_quantile over the 24h rate. Duplicate announcements of the same block on one connection are dropped; per-provider liveness is exported as ws_health (1 = connected and delivered a message in the last 120s). - Cheat vector disclosure: a provider could theoretically pre-announce heads it has not fully validated to win the race. We keyed the cohort on block number as pushed; hash-level cross-checking against a reference node is on the v2 list. Reading win rate together with the gap counter already flags a provider that pushes early but wrong (retracted heads show up as cohort inconsistencies and reorg noise). - Vantage point: a single eu-west host. Geography moves absolute arrival times but affects all providers over the same path; still, a provider whose nearest edge is far from eu-west is disadvantaged, and a us-east probe is the planned second vantage before any cross-region claim is made. ## Most reliable free public RPC, correctness incidents across 7 EVM chains - Category: RPCs - Metric: Reliability incidents (count) - Page: https://openchainbench.com/benchmarks/rpc-reliability - JSON: https://openchainbench.com/api/stat/rpc-reliability - Status: live - Headline: Flashbots leads reliability incidents at 1 (24h) on Most reliable free public RPC, correctness incidents across 7 EVM chains. **Rankings (p50, 24h):** 1. Flashbots: 1 (p99 0, success 100.0%, sample 138.019) 2. PublicNode: 12 (p99 0.130, success 98.1%, sample 570.071) 3. Binance: 30 (p99 0, success 50.0%, sample 60.0054) 4. Nodies: 158.02 (p99 0, success 69.3%, sample 514.068) 5. dRPC: 225.02 (p99 0.206, success 60.5%, sample 570.067) **Methodology**: - Consensus lag: the bench-010 latency probe fetches the full latest header every 60 seconds per (provider, chain); its height and hash, previously discarded, feed this bench. rpc_consensus_lag_blocks is the gap between the provider's reported head and the highest head any probed provider reported for that chain (rolling max). Valid-but-stale responses still count as observations; failed probes delete the series so dead endpoints age out. - Hash quorum: per chain, a height-to-hash vote map. When one hash at height H is backed by at least 2 providers AND strictly more than any competing hash, it is canonical; a provider that reported a different hash at H is counted in rpc_hash_mismatch_total, at most once per (provider, height). A 2-2 split, the signature of a live reorg, resolves to no quorum and counts nobody. - Fixed-vector integrity, cadence: every 5 minutes ONE chain is checked, rotating through the 7 chains with a canonical high-traffic USDC deployment (Ethereum, Arbitrum, Optimism, Base, Polygon, BNB, Avalanche). Each provider on that chain gets 2 checks per round, so a single-chain provider accrues ~82 checks per day and a 7-chain provider ~575. - Logs completeness vector: eth_getLogs for the chain's canonical USDC contract (Circle native deployments; Binance-peg on BNB) over a 10-block window ending at tip minus N. Returned log counts are compared across providers; deviation from the strict majority count increments rpc_logs_disagreement_total and books a disagree incident. Live calibration on Ethereum returned 1371 logs consistently on drpc, tenderly and blastapi over the same fixed range. - Anti-gaming rotation: N rotates daily over {20, 30, 40, 50, 60} blocks, so a provider cannot special-case a published fixed range, and request ids rotate on every call (the same edge-cache defeat as the latency probe). All depths stay far inside non-archive territory, so a pruned-but-honest node is never penalized. - State consistency vector: eth_getBalance of a fixed well-known address (the same Vitalik address the archive-depth probe uses) at the tip-minus-N block. The hex answer must be byte-identical across providers; divergence from the strict majority increments rpc_state_disagreement_total. Live calibration showed byte-identical balances across all responding providers at a fixed block. - Errors are signal: rpc_integrity_check_total{result} is ok, error or disagree. error covers blocked methods (1RPC answers eth_getLogs with -32000), depth gating (PublicNode keyless regressed to under 150 blocks of archive depth in July 2026, returning -32602 asking for a personal token), and transport failures. The headline counts error and disagree alike: a method you cannot call is unreliable regardless of why. - Headline: incidents per 24h = increase of integrity checks with result error or disagree, plus increase of hash mismatches, from the eu-west vantage. Raw counts, no weighting; the p90/p99 columns are consensus-lag quantiles in blocks, published as raw companion dimensions. - Single-region disclosure: incidents are counted from the eu-west probe only. Correctness, unlike latency, is location-independent in principle, but every provider fronts with anycast, so what we audit is the serving cluster eu-west traffic lands on; a diverged cache in another region is invisible to this bench. The us-east and sgp replicas emit the same metrics for cross-checking on the time-series chart. - Quorum honesty: strict plurality everywhere. Two agreeing providers outvote one dissenter; two against two resolves to no quorum and books nothing; a lone answer with no second opinion is unverifiable, not wrong, and books ok. Disagreement requires being outvoted by an established majority. - Cohort: 12 keyless providers from the bench-010 audited matrix. Excluded: LlamaRPC (fully down, HTTP 521, already delisted from the harness), 1RPC (delisted 2026-07-09 at under 13 percent success; when probed live it also blocked eth_getLogs with -32000, exactly the incident class this bench counts), Ankr / NodeReal / GetBlock / Chainstack (key-gated). Avalanche's foundation endpoint is probed by the harness and visible on bench 010; it is left out here only to keep the cohort at 12. - Provider matrix and vector addresses are documented in harnesses/rpc-capabilities/cmd/script/config.go and integrity.go; the harness is shared with bench 010, so both benches see the identical provider set and probe budget. ## Ethereum block builder market share - Category: Trading - Metric: Block share (24h) (pct) - Page: https://openchainbench.com/benchmarks/evm-block-builders - JSON: https://openchainbench.com/api/stat/evm-block-builders - Status: live - Headline: Titan leads block share (24h) at 52.2% (24h avg) on Ethereum block builder market share. **Rankings (p50, 24h):** 1. Titan: 52.2% (p99 52.2%, success 100.0%, sample 1304.81) 2. Quasar: 14.3% (p99 14.3%, success 100.0%, sample 356.222) 3. BuilderNet: 12.0% (p99 12.0%, success 100.0%, sample 300.187) 4. Eureka: 9.61% (p99 9.61%, success 100.0%, sample 240.15) 5. Vanilla: 8.09% (p99 8.09%, success 100.0%, sample 202.127) 6. Other: 1.88% (p99 1.88%, success 100.0%, sample 47.0297) 7. Builder+: 1.20% (p99 1.20%, success 100.0%, sample 30.0189) 8. Bob The Builder: 0.36% (p99 0.36%, success 100.0%, sample 9.00564) 9. beaverbuild: 0.24% (p99 0.24%, success 100.0%, sample 6.00375) **Methodology**: - Source: keyless public Ethereum RPC (ethereum-rpc.publicnode.com by default, env-overridable). eth_getBlockByNumber(latest) every 12s, matching the mainnet slot time. Gaps between polls are backfilled by block number (capped at 10) so the counters see every block, not just the ones that happen to be head at poll time. - Attribution: extraData hex is decoded to printable ASCII and matched, lowercase, against a curated substring table (titan, quasar, eureka, buildernet, beaverbuild, rsync, builder0x69, flashbots, bloxroute, builder+/btcs, penguinbuild and more). First match wins; most specific substrings are ordered first. - Vanilla detection: empty extraData or execution-client default tags (geth, reth, nethermind, besu, erigon, go1.x, platform strings) count as builder=vanilla, meaning the proposer built the block locally instead of outsourcing to a builder. This row is the live self-built share of Ethereum. - Unattributed handling: any non-empty tag not in the table counts as builder=other, increments ebb_unattributed_total, and logs the raw extraData string. The table grows from operator logs instead of silently under-counting, the bench 016 pattern. - Self-labeling caveat: extraData is voluntary. A builder can rebrand, blank its tag, or impersonate another. The relay cross-check below is the independent signal; a large divergence between extraData share and relay-side delivered payloads would surface tag games. - Relay cross-check: seven MEV-Boost relay data APIs (Flashbots, ultrasound, Agnostic, bloXroute max-profit, bloXroute regulated, Titan, Aestus) are polled keyless every 5 min via GET /relay/v1/data/bidtraces/proposer_payload_delivered?limit=50. Delivered payloads are counted per relay (ebb_relay_payloads_total), deduped per relay by slot high-water-mark. The same slot on multiple relays is normal: builders multi-home bids, so relay counters measure relay share, not a partition of blocks. - Single vantage: one harness in one region observes the chain through one public RPC. Attribution is not latency-sensitive (extraData is consensus data, identical from every vantage), so single-vantage only affects liveness, which the health gauges expose. - Companion L2 metrics: the same harness measures Arbitrum sequencer-feed soft-confirmation lag (ebb_arb_softconf_lag_milliseconds, feed arrival to public RPC visibility, offset derived at runtime) and Base flashblocks cadence plus flashblock-to-RPC lag (ebb_base_flashblock_interval_milliseconds, ebb_base_softconf_lag_milliseconds). These are per-chain, not per-builder, so this spec surfaces builder share only; the L2 lag series feed a future bench page. ## Fastest free Polkadot RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/polkadot-rpc - JSON: https://openchainbench.com/api/stat/polkadot-rpc - Status: live - Headline: OnFinality leads rpc latency at 55 ms (p50, 24h) on Fastest free Polkadot RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. OnFinality: 55 ms (p99 2.02 s, success 100.0%, sample 4212.73) 2. Parity: 200 ms (p99 1.50 s, success 100.0%, sample 4211.73) 3. PublicNode: 250 ms (p99 631 ms, success 100.0%, sample 4252.74) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"chain_getHeader","params":[]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the latest-header fetch with a rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 40 relay blocks behind the cross-provider tip, roughly 4 minutes at Polkadot's ~6 s block time), `timeout`. Latency without reliability is a misleading ranking signal. - No archive-depth loop on this chain. Polkadot's state model is accessed via `state_getStorage` keyed by a Blake2-hashed storage key rather than the EVM `eth_getBalance(address, height)` pattern, so the archive probe used on the EVM cluster is not applied here. - No cross-provider hash quorum on this chain. `chain_getHeader` returns the parent-block hash rather than the current-block hash (the current hash is derived by Blake2 over the SCALE-encoded header). Bench 083's height-hash quorum check is therefore skipped for Polkadot; the same reliability signal is still captured via `ok` / `stale` classification against the rolling cross-provider tip. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="polkadot"`. Provider coverage at launch: 3 no-key endpoints (Parity official, OnFinality public gateway, PublicNode). Excluded by the launch audit: 1RPC filters `chain_getHeader` as "Not Allowed" on its privacy relay; Dwellir returned 503 during the audit sweep; Ankr paid Polkadot tier only; Chainstack key-gated; RadiumBlock requires a referral header; Grove and Thirdweb return invalid-chain or key-gated. ## Fastest Base WebSocket newHeads push, live block-push lag across RPC providers - Category: RPCs - Metric: Block push lag (ms) - Page: https://openchainbench.com/benchmarks/ws-head-latency-base - JSON: https://openchainbench.com/api/stat/ws-head-latency-base - Status: live - Headline: dRPC leads block push lag at 3 ms (p50, 24h) on Fastest Base WebSocket newHeads push, live block-push lag across RPC providers. **Rankings (p50, 24h):** 1. dRPC: 3 ms (p99 10.24 s, success 92.2%, sample 159382) 2. PublicNode: 3 ms (p99 151 ms, success 100.0%, sample 159382) **Methodology**: - Providers measured (keyless WebSocket endpoints): PublicNode (wss://base-rpc.publicnode.com), dRPC (wss://base.drpc.org). Tenderly does not expose a keyless Base WebSocket path and is scoped out until a public gateway is announced. Keyed providers (Alchemy, Infura, Chainstack, QuickNode) join the cohort when contributor keys are wired via WS_URL__BASE env vars. - Cohort saturation: Blast, LlamaRPC, BlockPI, 1RPC, mainnet.base.org and Ankr all reject a keyless WebSocket handshake at the time of ship (verified 2026-07), which is why the keyless tier stops at two. - Chain scope: every query on this page is pinned to chain="base". Base block cadence is 2 seconds, so a 24h window carries roughly 43000 samples per provider (versus ~7200 on Ethereum), well above the 7000 sample floor used by the parent bench. - Race scoring: identical to the parent [ws-head-latency](https://openchainbench.com/benchmarks/ws-head-latency-ethereum) benchmark. First provider to deliver block N sets T0. Each provider's sample for block N is arrival(N) minus T0 in milliseconds. Cohort closes 5 seconds after the first arrival; late arrivals are scored as missed blocks via ws_block_gap_total rather than as huge latency samples. - Relative, not absolute: subtraction of two arrivals over the same path removes vantage-point network latency. Consequence: the fastest provider reads near zero by construction. The honest readings are win rate, trailers' lag distribution, and gap counts. - Aggregation: per-provider lag histogram with a sub-millisecond floor (0.5 ms bucket up through 10 s tail), p50/p90/p99 via histogram_quantile over the 24h rate. Coverage score = ws_head_blocks_seen_total divided by cohort maximum, clamped to 1. A provider that pushes fast but skips blocks loses on this column, not on the latency percentiles. - Connection discipline: one persistent WebSocket per (provider, chain), client ping every 30s, read deadline 60s, 90s head watchdog forcing reconnect when a socket keeps the heartbeat alive but silently drops the subscription. Exponential backoff 2s to 60s on reconnect. - Vantage point: a single eu-west host. Multi-region deployment is a follow-up on the parent bench roadmap; the same limitation and the reasoning behind it are documented there. ## Fastest Solana WebSocket slotSubscribe push, live slot-push lag across RPC providers - Category: RPCs - Metric: Slot push lag (ms) - Page: https://openchainbench.com/benchmarks/ws-head-latency-solana - JSON: https://openchainbench.com/api/stat/ws-head-latency-solana - Status: live - Headline: Solana leads slot push lag at 0.3 ms (p50, 24h) on Fastest Solana WebSocket slotSubscribe push, live slot-push lag across RPC providers. **Rankings (p50, 24h):** 1. Solana: 0.3 ms (p99 0.5 ms, success 77.7%, sample 616234) 2. PublicNode: 96 ms (p99 10.24 s, success 100.0%, sample 793103) **Methodology**: - Providers measured (keyless WebSocket endpoints): PublicNode (wss://solana-rpc.publicnode.com) and Solana Foundation (wss://api.mainnet-beta.solana.com). Keyed providers (Alchemy, Chainstack, Helius, QuickNode) join the cohort when contributor keys are wired via WS_URL__SOLANA env vars. - Cohort saturation: dRPC's free Solana tier explicitly disallows slotSubscribe ("method is not available on freetier") and the other public Solana WSS gateways audited (Blast, BlockPI, Ankr, extrnode, Chainstack public) all reject the handshake (verified 2026-07), which is why the keyless tier stops at two. - Chain scope: every query on this page is pinned to chain="solana". Solana slot cadence is ~400ms, so a 24h window carries roughly 216000 samples per provider, an order of magnitude beyond the 7000 sample floor used across the head-lag cluster. - RPC method: `slotSubscribe`, not `signatureSubscribe` or `logsSubscribe`. The notification payload includes the slot number and the parent slot; the harness dedupes on slot number and uses the first arrival per slot to define T0. - Race scoring: identical to the parent [ws-head-latency](https://openchainbench.com/benchmarks/ws-head-latency-ethereum) benchmark, applied per slot instead of per block. First provider to deliver slot N sets T0. Each provider's sample for slot N is arrival(N) minus T0 in milliseconds. Cohort closes 5 seconds after the first arrival. - Relative, not absolute: subtraction of two arrivals over the same path removes vantage-point network latency. Consequence: the fastest provider reads near zero by construction. The honest readings are win rate, trailers' lag distribution, and gap counts, not the leader's absolute number. - Aggregation: per-provider lag histogram with a sub-millisecond floor (0.5 ms bucket up through 10 s tail), p50/p90/p99 via histogram_quantile over the 24h rate. Coverage score = ws_head_blocks_seen_total divided by cohort maximum, clamped to 1. - Connection discipline: one persistent WebSocket per (provider, chain), client ping every 30s, read deadline 60s, 90s slot watchdog forcing reconnect when a socket keeps the heartbeat alive but silently drops the subscription. Exponential backoff 2s to 60s on reconnect. - Vantage point: a single eu-west host. Multi-region deployment is a follow-up on the parent bench roadmap; the same limitation and reasoning are documented there. ## Which tokenized T-bill actually pays what it promises - Category: RWA - Metric: Yield deviation (bps) - Page: https://openchainbench.com/benchmarks/rwa-yield-accuracy - JSON: https://openchainbench.com/api/stat/rwa-yield-accuracy - Status: live - Headline: SyrupUSDC leads yield deviation at 0.040% (24h avg) on Which tokenized T-bill actually pays what it promises. **Rankings (p50, 24h):** 1. SyrupUSDC: 0.040% (p99 -4.82%, success 100.0%, sample 1046590000) **Methodology**: - Cohort: USDY (Ondo), USTB (Superstate), OUSG (Ondo), SyrupUSDC (Maple). BUIDL (BlackRock) and BENJI (Franklin Templeton) measurement is currently paused: BUIDL's distributor mints conflate new subscriptions with yield distribution, making the dividend-event model inaccurate; BENJI's Ethereum wrapper exposes no on-chain NAV function and Franklin has not yet published a machine-readable NAV endpoint. - Delivered yield: derived per issuer from on-chain events. Rebase-model tokens compare totalSupply snapshots (t=now vs t=window ago). Dividend-model tokens sum USDC Transfer events from the treasury wallet to holders across the window. NAV-model tokens compare share NAV snapshots published by the issuer (fetched via the issuer's public endpoint, cross-checked with the smart contract's own price oracle where one exists). - Promised yield: the APY the issuer publishes on its official dashboard or fund fact sheet. Sourced at least weekly from each issuer's own disclosures, with URL plus date logged in the harness config. When an issuer updates its stated APY, the change is tracked; historical values remain in Prometheus for the retention window. - Windows: headline is 30-day rolling annualized. Also emitted: 7-day rolling (for volatility) and lifetime since token inception (for the honest cross-issuer comparison unaffected by short-window distribution cycles). - Sign: delivered minus promised, in basis points. Negative means the token paid less than advertised over the window. Positive (rare) means more. - Fees: promised APY is stated net of management fees. Delivered yield is measured on the same net basis. Any residual structural deviation typically reflects distribution timing (dividend-style tokens accrue daily but pay monthly), weekend accrual conventions (T-bills yield on business days only), or measurement methodology, not accounting. - Cadence: on-chain reads every 60 seconds. Delivered-yield 30d rolling window is recomputed hourly (calculation is heavy, values move slowly). Promised-yield config file is reloaded every 60 seconds so a weekly update lands within a scrape cycle. - Multi-chain tokens: USDY exists on Ethereum plus Solana, Aptos, Sui. V1 measures the Ethereum instance; V2 will surface per-chain deviations weighted by supply. - Reproducibility: harness source at github.com/ChainBench/OpenChainBench/tree/main/harnesses/rwa-yield-accuracy. Every delivered-yield number derives from a public RPC read (contract address, event signature, block range documented). Every promised-yield number cites its source URL and date. ## DEX indexer with most blockchains, live coverage ranking - Category: Aggregators - Metric: DEX-indexed chains (count) - Page: https://openchainbench.com/benchmarks/dex-network-coverage - JSON: https://openchainbench.com/api/stat/dex-network-coverage - Status: live - Headline: DefiLlama leads dex-indexed chains at 479 (24h) on DEX indexer with most blockchains, live coverage ranking. **Rankings (p50, 24h):** 1. DefiLlama: 479 (p99 479, success 100.0%, sample 479) 2. GeckoTerminal: 253 (p99 253, success 100.0%, sample 253) 3. Codex: 122 (p99 122, success 100.0%, sample 122) 4. Sim by Dune: 64 (p99 64, success 100.0%, sample 64) 5. DexPaprika: 36 (p99 36, success 100.0%, sample 36) **Methodology**: - Source: each provider's public DEX-indexer networks endpoint. - GeckoTerminal: GET /api/v2/networks (paginated, no auth). Chains where GeckoTerminal actively indexes DEX pools + trades. - Codex: GraphQL `getNetworks` query at https://graph.codex.io/graphql with an official API key. Chains covered by Defined.fi's DEX data pipeline. - DefiLlama: GET https://api.llama.fi/chains (no auth). Chains tracked by DefiLlama's TVL crawler, every chain with at least one indexed DeFi protocol, DEX chains are a subset. - DexPaprika: GET https://api.dexpaprika.com/networks (no auth). CoinPaprika's dedicated DEX tracker product, separate from the market-data API. - Sim by Dune: GET https://api.sim.dune.com/v1/evm/supported-chains (no auth). EVM only, mainnets filtered via the `mainnet` tag. - Cadence: full refresh every 6 hours. - Counting: a provider's network is counted once per unique chain id or slug; mainnet only. - Failures (network errors, rate limits, auth errors) leave the previous count in place and increment a fetch_errors counter. the page falls back to its last successful sample. ## Fastest free Osmosis RPC, live no-key endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/osmosis-rpc - JSON: https://openchainbench.com/api/stat/osmosis-rpc - Status: live - Headline: Osmosis Foundation leads rpc latency at 190 ms (p50, 24h) on Fastest free Osmosis RPC, live no-key endpoint latency. **Rankings (p50, 24h):** 1. Osmosis Foundation: 190 ms (p99 4.03 s, success 99.0%, sample 4286.77) 2. LavenderFive: 192 ms (p99 403 ms, success 100.0%, sample 4212.73) 3. Polkachu: 193 ms (p99 382 ms, success 86.1%, sample 4140.71) 4. PublicNode: 247 ms (p99 517 ms, success 100.0%, sample 4209.73) 5. Imperator: 428 ms (p99 474 ms, success 67.8%, sample 4231.76) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"status","params":[]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare status query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable decimal `sync_info.latest_block_height`), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 40 blocks behind the cross-provider tip, roughly 4 minutes at Osmosis's ~6 s block time), `timeout`. Latency without reliability is a misleading ranking signal. - No archive-depth loop on this chain. Cosmos SDK chains access historical state via ABCI queries keyed on module + KV-store, which does not map onto the flat `eth_getBalance(address, height)` probe cleanly. - No cross-provider hash quorum on this chain at v1. Tendermint `status` does return `latest_block_hash` on the same block the height is reported for, so a quorum check is technically feasible, but the initial Osmosis add-on ships without it to keep the reliability change surface small; the hash normalisation across Cosmos chains will be validated before wiring bench 083 here. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="osmosis"`. Provider coverage at launch: 5 no-key endpoints (Osmosis Foundation, Polkachu, PublicNode, Imperator, LavenderFive). - Excluded by the launch audit: Lava (osmosis.tendermintrpc.lava.build 403 without a key despite public branding), OnFinality (osmosis public gateway timing out at probe cadence), Numia (401), AutoStake (404), BlockApsis / WhisperNode / Enigma-Validator / StakeTown / reece.sh (connect errors, likely IPv6-only or geo-gated), Ankr + Chainstack (paid Cosmos tiers only). ## Fastest free Hyperliquid RPC, live no-key HyperEVM endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/hyperliquid-rpc - JSON: https://openchainbench.com/api/stat/hyperliquid-rpc - Status: live - Headline: dRPC leads rpc latency at 14 ms (p50, 24h) on Fastest free Hyperliquid RPC, live no-key HyperEVM endpoint latency. **Rankings (p50, 24h):** 1. dRPC: 14 ms (p99 163 ms, success 80.0%, sample 4209.8) 2. Hypurrscan: 72 ms (p99 248 ms, success 100.0%, sample 4265.74) 3. Hyperliquid Labs: 73 ms (p99 116 ms, success 92.9%, sample 4237.78) 4. Purroof Group: 174 ms (p99 540 ms, success 100.0%, sample 4252.74) 5. Stakely: 393 ms (p99 1.16 s, success 100.0%, sample 4226.73) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body , this is how the audit caught thirdweb's `Invalid chain` failure), `stale` (more than 25 blocks behind the cross-provider tip, roughly 50 seconds at HyperEVM's ~2 s block time), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="hyperliquid"`. Provider coverage at launch: 5 no-key endpoints (Hyperliquid Labs official, dRPC, Stakely, Purroof Group, Hypurrscan). - Excluded by the launch audit: Alchemy demo path (rate-limited dead), thirdweb (`Invalid chain` on HyperEVM), Grove/Pocket public LB (requires an app id at the LB path), AllThatNode + Blast API + Chainstack + Gelato + Imperator HyperEVM paths (DNS-fail or 401 without a key), PublicNode (no HyperEVM subdomain yet). HyperEVM is a young chain (mainnet Feb 2025) so this list will shift quickly. ## Fastest free TRON RPC, live no-key JSON-RPC endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/tron-rpc - JSON: https://openchainbench.com/api/stat/tron-rpc - Status: live - Headline: TronGrid leads rpc latency at 11 ms (p50, 24h) on Fastest free TRON RPC, live no-key JSON-RPC endpoint latency. **Rankings (p50, 24h):** 1. TronGrid: 11 ms (p99 77 ms, success 100.0%, sample 4340.83) 2. PublicNode: 167 ms (p99 777 ms, success 100.0%, sample 4230.73) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 25 blocks behind the cross-provider tip, roughly 75 seconds at TRON's ~3 s block time), `timeout`. Latency without reliability is a misleading ranking signal. - Surface scope: only the EVM-compatible JSON-RPC surface (`/jsonrpc` endpoints) is measured, because that is the path every cross-chain wallet, TronWeb / EVM bridge and arbitrage bot integrates against. The native TRON REST API (`wallet/getnowblock`, `wallet/triggersmartcontract`) is out of scope for this bench; a chain-specific `tron-rest` bench can be added later when there is clear demand from integrators using TronWeb directly. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="tron"`. Provider coverage at launch: 3 no-key JSON-RPC endpoints (TronGrid, dRPC, PublicNode). The TRON JSON-RPC provider market is materially smaller than the EVM one; most TRON infra vendors expose only the native TRON REST API keyless, and gate the JSON-RPC path behind an API key. - Excluded by the launch audit: Ankr (`rpc.ankr.com/tron_jsonrpc` returned `API key is not allowed to access blockchain` without a key), Chainstack / NOWNodes / GetBlock / Tatum / BlockPI (all require an API key on the TRON JSON-RPC path even though branded as public), OnFinality + Blast API + AllThatNode (no public TRON JSON-RPC gateway), Tron Foundation's `rpc.trongrid.io` (DNS not resolving; the correct official host is `api.trongrid.io/jsonrpc`). ## Fastest free Cosmos Hub RPC, live no-key Cosmos SDK endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/cosmos-hub-rpc - JSON: https://openchainbench.com/api/stat/cosmos-hub-rpc - Status: live - Headline: Lava Network leads rpc latency at 76 ms (p50, 24h) on Fastest free Cosmos Hub RPC, live no-key Cosmos SDK endpoint latency. **Rankings (p50, 24h):** 1. Lava Network: 76 ms (p99 1.71 s, success 100.0%, sample 4325.75) 2. Polkachu: 192 ms (p99 386 ms, success 99.6%, sample 4324.76) 3. LavenderFive: 193 ms (p99 419 ms, success 100.0%, sample 4252.74) 4. PublicNode: 254 ms (p99 631 ms, success 100.0%, sample 4350.76) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"status","params":[]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable decimal `sync_info.latest_block_height`), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 40 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="cosmos-hub"`. Provider coverage at launch: 4 no-key endpoints (PublicNode, Polkachu, LavenderFive, Lava Network). ## Fastest free Injective RPC, live no-key Cosmos SDK endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/injective-rpc - JSON: https://openchainbench.com/api/stat/injective-rpc - Status: live - Headline: Polkachu leads rpc latency at 192 ms (p50, 24h) on Fastest free Injective RPC, live no-key Cosmos SDK endpoint latency. **Rankings (p50, 24h):** 1. Polkachu: 192 ms (p99 402 ms, success 50.5%, sample 4220.1) 2. LavenderFive: 200 ms (p99 583 ms, success 100.0%, sample 4323.75) 3. Injective Foundation: 228 ms (p99 274 ms, success 98.8%, sample 4228.76) 4. PublicNode: 257 ms (p99 634 ms, success 100.0%, sample 4321.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"status","params":[]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable decimal `sync_info.latest_block_height`), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 40 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="injective"`. Provider coverage at launch: 4 no-key endpoints (Injective Foundation, PublicNode, Polkachu, LavenderFive). ## Fastest free Neutron RPC, live no-key Cosmos SDK endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/neutron-rpc - JSON: https://openchainbench.com/api/stat/neutron-rpc - Status: live - Headline: Polkachu leads rpc latency at 192 ms (p50, 24h) on Fastest free Neutron RPC, live no-key Cosmos SDK endpoint latency. **Rankings (p50, 24h):** 1. Polkachu: 192 ms (p99 400 ms, success 100.0%, sample 4267.74) 2. LavenderFive: 192 ms (p99 400 ms, success 100.0%, sample 4242.74) 3. PublicNode: 363 ms (p99 766 ms, success 100.0%, sample 4293.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"status","params":[]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable decimal `sync_info.latest_block_height`), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 40 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="neutron"`. Provider coverage at launch: 3 no-key endpoints (PublicNode, Polkachu, LavenderFive). ## Fastest free World Chain RPC, live no-key EVM endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/world-chain-rpc - JSON: https://openchainbench.com/api/stat/world-chain-rpc - Status: live - Headline: World Chain leads rpc latency at 5 ms (p50, 24h) on Fastest free World Chain RPC, live no-key EVM endpoint latency. **Rankings (p50, 24h):** 1. World Chain: 5 ms (p99 28 ms, success 100.0%, sample 4284.74) 2. dRPC: 166 ms (p99 263 ms, success 79.1%, sample 4188.74) 3. Tenderly Gateway: 246 ms (p99 284 ms, success 100.0%, sample 4234.73) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 25 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="world-chain"`. Provider coverage at launch: 3 no-key endpoints (World Chain, dRPC, Tenderly Gateway). ## Fastest free Kaia RPC, live no-key EVM endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/kaia-rpc - JSON: https://openchainbench.com/api/stat/kaia-rpc - Status: live - Headline: Kaia Foundation leads rpc latency at 74 ms (p50, 24h) on Fastest free Kaia RPC, live no-key EVM endpoint latency. **Rankings (p50, 24h):** 1. Kaia Foundation: 74 ms (p99 99 ms, success 100.0%, sample 4311.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 25 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="kaia"`. Provider coverage at launch: 2 no-key endpoints (Kaia Foundation, dRPC). ## Fastest free Ink RPC, live no-key EVM endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/ink-rpc - JSON: https://openchainbench.com/api/stat/ink-rpc - Status: live - Headline: QuickNode leads rpc latency at 165 ms (p50, 24h) on Fastest free Ink RPC, live no-key EVM endpoint latency. **Rankings (p50, 24h):** 1. QuickNode: 165 ms (p99 196 ms, success 100.0%, sample 4333.75) 2. dRPC: 176 ms (p99 227 ms, success 77.9%, sample 4177.77) 3. Tenderly Gateway: 246 ms (p99 274 ms, success 100.0%, sample 4347.75) 4. Gelato: 341 ms (p99 1.30 s, success 100.0%, sample 4226.73) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 25 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="ink"`. Provider coverage at launch: 4 no-key endpoints (Gelato, QuickNode, dRPC, Tenderly Gateway). ## Fastest free opBNB RPC, live no-key EVM endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/opbnb-rpc - JSON: https://openchainbench.com/api/stat/opbnb-rpc - Status: live - Headline: BNB Chain Team leads rpc latency at 74 ms (p50, 24h) on Fastest free opBNB RPC, live no-key EVM endpoint latency. **Rankings (p50, 24h):** 1. BNB Chain Team: 74 ms (p99 286 ms, success 100.0%, sample 4335.75) 2. dRPC: 91 ms (p99 310 ms, success 81.5%, sample 4286.76) 3. PublicNode: 244 ms (p99 315 ms, success 100.0%, sample 4294.75) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 25 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="opbnb"`. Provider coverage at launch: 3 no-key endpoints (BNB Chain Team, PublicNode, dRPC). ## Fastest Wormhole VAA finalization by source chain, live latency - Category: Bridges - Metric: VAA finalization (ms) - Page: https://openchainbench.com/benchmarks/wormhole-vaa-latency - JSON: https://openchainbench.com/api/stat/wormhole-vaa-latency - Status: live - Headline: Sui leads vaa finalization at 3.95 s (p50, 24h) on Fastest Wormhole VAA finalization by source chain, live latency. **Rankings (p50, 24h):** 1. Sui: 3.95 s (p99 11.53 s, success 100.0%, sample 139.024) 2. Monad: 4.42 s (p99 9.87 s, success 100.0%, sample 21.0036) 3. BNB Chain: 6.31 s (p99 934.50 s, success 100.0%, sample 531.092) 4. Avalanche: 6.92 s (p99 13.30 s, success 100.0%, sample 34.0059) 5. Polygon: 7.43 s (p99 14.70 s, success 100.0%, sample 161.028) 6. Berachain: 7.50 s (p99 9.95 s, success 100.0%, sample 1.00017) 7. Ink: 7.50 s (p99 9.95 s, success 100.0%, sample 3.00052) 8. Solana: 18.08 s (p99 29.47 s, success 100.0%, sample 6607.15) 9. Moonbeam: 42.92 s (p99 80.70 s, success 100.0%, sample 31.0054) 10. Ethereum: 901.61 s (p99 1194.03 s, success 100.0%, sample 1110.19) 11. Arbitrum: 1034.21 s (p99 1767.00 s, success 100.0%, sample 33.0057) 12. Celo: 1050.00 s (p99 1197.00 s, success 100.0%, sample 1.00017) 13. Unichain: 1050.00 s (p99 1197.01 s, success 100.0%, sample 3.00052) 14. Base: 1246.88 s (p99 1788.94 s, success 100.0%, sample 59.0102) **Methodology**: - Data source: `https://api.wormholescan.io/api/v1/vaas?pageSize=100`, the public wormholescan indexer of Wormhole VAAs. Polled every 60 seconds. - Latency definition: `updatedAt − timestamp` from the VAA row. `timestamp` is the source-chain observation time (block containing the Wormhole message); `updatedAt` is the moment wormholescan first indexed the VAA as fully-signed by 13-of-19 Guardians. - Dedupe: last 10 000 VAA ids kept in memory (rolling FIFO). Wormholescan returns ~100 VAAs/min sustained; 10k cache holds ~100 minutes of history, well above any poll interval. - Bucketing: histogram with geometric buckets 2, 5, 10, 15, 20, 30, 45, 60, 90, 120, 180, 300, 600 seconds. - Guard: samples with `updatedAt − timestamp < 0` or `> 3600 s` are dropped (clock skew or backfilled VAAs whose `updatedAt` refers to a later re-index event). - No canary transactions: this bench observes organic Wormhole traffic (thousands of VAAs/day). No wallet is funded, no gas is paid. - Scope: 20 source chains Wormhole supports that are already tracked on OpenChainBench's chain registry. Chains with negligible VAA volume in a 24-hour window may appear with wide error bars or a low sample count. - Destination chain is not measured: VAAs are relayed on demand once quorum is reached, so post-quorum latency is caller-driven (relayer choice, destination gas price, etc.) and not a property of Wormhole itself. ## Best DEX aggregator for quoting newly-launched tokens - Category: Aggregators - Metric: Quote coverage (pct) - Page: https://openchainbench.com/benchmarks/token-quote-coverage - JSON: https://openchainbench.com/api/stat/token-quote-coverage - Status: live - Headline: Jupiter leads quote coverage at 95.0% (24h avg) on Best DEX aggregator for quoting newly-launched tokens. **Rankings (p50, 24h):** 1. Jupiter: 95.0% (p99 95.0%, success 95.0%, sample 717.216) 2. Mobula: 67.6% (p99 67.6%, success 67.6%, sample 1181.39) **Methodology**: - Token discovery: five sources in parallel. (1) Dexscreener token-boosts: pump-fun (Solana) and pons (Robinhood). (2) Virtuals Protocol API: Virtuals agents on Base and Robinhood chain (virtuals). (3) GeckoTerminal BSC new_pools: four-meme. (4) GeckoTerminal Solana moonshot/pools: moonshot. (5) GeckoTerminal Solana meteora-dbc/pools: meteora-dbc. Boosted tokens from (1) are enriched via Dexscreener batch lookup to resolve dexId to venue labels. - Quote probe: 1 USDC → token, fired in parallel to all in-scope providers with a 10s timeout. Input token is always USDC (native USDC on Solana and Base, bridged USDC.e on BNB). A probe is a coverage hit when the HTTP response is 2xx and the parsed outAmount field is a non-zero positive integer or decimal. All other outcomes (4xx, 5xx, no-route JSON, empty outAmount, timeout) record as misses. - Aggregator endpoints: Jupiter lite-api.jup.ag/swap/v1/quote (Solana), Mobula /api/2/swap/quoting (EVM + Solana, API key), Relay api.relay.link/quote (EVM + Solana, no key). Each adapter normalises chain identifiers, input/output decimals, and error response shapes before recording outcome. - Jupiter strictMode=false: queried without the curated-token filter so Jupiter will attempt routing for any token with a discoverable on-chain pool, matching how most wallets call the API. strictMode=true would trivially exclude new tokens and defeat the purpose of the benchmark. - Chain-scope enforcement: Jupiter probes Solana-only. Mobula and Relay probe all four chains (Solana, Base, BNB, Robinhood). Providers are never penalised for chains they do not support: null cells are excluded from cross-chain aggregates. - Coverage metric: Prometheus counters token_quote_coverage_success_total and token_quote_coverage_attempts_total carry labels {provider, venue, chain}. The bench queries compute increase(success[24h]) / increase(attempts[24h]) * 100 live at read time. No pre-aggregation; the ratio reflects exactly the tokens probed in the rolling window. - Probe cadence and deduplication: each batch cycles through the current Dexscreener token-boosts feed. Tokens are not deduplicated across batches; the same token may appear in multiple 30-minute windows if it remains boosted. The score therefore reflects freshness of the aggregator's current routing graph, not historical coverage depth. - Single origin: all probes originate from the eu-west OCB VPS. Regional latency is not a factor in this bench (the outcome is binary hit/miss, not latency). No region dimension in v1. ## Fastest Chainlink CCIP source chain by end-to-end delivery latency - Category: Bridges - Metric: CCIP delivery (ms) - Page: https://openchainbench.com/benchmarks/chainlink-ccip-latency - JSON: https://openchainbench.com/api/stat/chainlink-ccip-latency - Status: live - Headline: BNB Chain leads ccip delivery at 80.00 s (p50, 24h) on Fastest Chainlink CCIP source chain by end-to-end delivery latency. **Rankings (p50, 24h):** 1. BNB Chain: 80.00 s (p99 279.84 s, success 100.0%, sample 84.0164) 2. Solana: 82.11 s (p99 119.24 s, success 100.0%, sample 24.0048) 3. Monad: 90.00 s (p99 119.40 s, success 100.0%, sample 3.00066) 4. Avalanche: 97.50 s (p99 293.60 s, success 100.0%, sample 16.0038) 5. Polygon: 800.00 s (p99 1188.00 s, success 100.0%, sample 4.00077) 6. Ethereum: 1035.14 s (p99 1721.46 s, success 100.0%, sample 144.029) 7. Robinhood Chain: 1059.38 s (p99 1758.00 s, success 100.0%, sample 21.0041) 8. Arbitrum: 1111.37 s (p99 1780.91 s, success 100.0%, sample 35.0231) 9. Base: 1444.45 s (p99 2196.00 s, success 100.0%, sample 102.021) 10. Mantle: 1500.00 s (p99 1794.00 s, success 100.0%, sample 3.00157) **Methodology**: - Data source: `https://api.ccip.chain.link/v2/messages?limit=100`, the public CCIP Tools API. Polled every 60 seconds. - Latency definition: `receiptTimestamp - sendTimestamp` from a CCIP message row with `status: SUCCESS`. `sendTimestamp` is the source-chain tx block time; `receiptTimestamp` is the destination-chain execution block time. - Filter: only mainnet lanes are observed. Testnet messages (Ethereum Sepolia, TON Testnet, etc.) are dropped before histogram observation. - Filter: only `status: SUCCESS` messages contribute to latency. In-flight statuses (SENT, SOURCE_FINALIZED, COMMITTED) are counted separately in `ccip_message_status_total` so a spike in COMMITTED without matching SUCCESS surfaces a stuck-execution incident. - Dedupe: last 10 000 messageIds kept in memory (rolling FIFO). CCIP sustained rate is ~25 messages/minute network-wide, so the cache holds ~7h of history. - Bucketing: histogram with buckets extending to 90 minutes (5 400 s). Wider than the Wormhole VAA bench because CCIP structurally waits for source-chain finality before its DON commits , Ethereum-source p99 legitimately reaches 25-30 min in adverse epochs. - Guard: samples with `receiptTimestamp - sendTimestamp < 0` or `> 2h` are dropped (clock skew, stuck messages re-executed later, or timestamp typos). - No canary transactions: this bench observes organic CCIP traffic (~500 mainnet messages/day across the top corridors). No wallet is funded, no gas is paid. - Scope: CCIP-supported source chains with mainnet traffic in the observation window. Long-tail source chains (0G, ADI, Astar) will show wide error bars or a low sample count. - Fair-comparison caveat: CCIP intentionally waits for source-chain finality before its DON commits, while some other cross-chain messaging networks (Wormhole, LayerZero) sign pre-finality. Comparing raw end-to-end numbers on ETH-source lanes is not apples-to-apples with those networks; the meta-bench view (cross-chain-messaging-latency) exposes a finality-normalized column that isolates the pure DON+execution work. ## Fastest LayerZero source chain by end-to-end message delivery - Category: Bridges - Metric: LayerZero delivery (ms) - Page: https://openchainbench.com/benchmarks/layerzero-message-latency - JSON: https://openchainbench.com/api/stat/layerzero-message-latency - Status: live - Headline: Monad leads layerzero delivery at 24.39 s (p50, 24h) on Fastest LayerZero source chain by end-to-end message delivery. **Rankings (p50, 24h):** 1. Monad: 24.39 s (p99 1161.75 s, success 100.0%, sample 102.024) 2. Robinhood Chain: 26.43 s (p99 115.86 s, success 100.0%, sample 407.09) 3. Arbitrum: 28.69 s (p99 1735.06 s, success 100.0%, sample 1526.32) 4. BNB Chain: 29.06 s (p99 208.48 s, success 100.0%, sample 1244.26) 5. Sui: 45.00 s (p99 59.70 s, success 100.0%, sample 1.00028) 6. Avalanche: 47.52 s (p99 137.10 s, success 100.0%, sample 243.062) 7. Celo: 52.50 s (p99 119.00 s, success 100.0%, sample 10.0028) 8. Unichain: 54.91 s (p99 1761.00 s, success 100.0%, sample 39.0115) 9. Solana: 55.18 s (p99 119.67 s, success 100.0%, sample 295.067) 10. Ink: 56.79 s (p99 3574.00 s, success 100.0%, sample 13.0037) 11. Base: 59.43 s (p99 615.01 s, success 100.0%, sample 1330.29) 12. Mantle: 90.00 s (p99 756.26 s, success 100.0%, sample 48.0114) 13. Optimism: 98.98 s (p99 5400.00 s, success 100.0%, sample 417.101) 14. Polygon: 112.61 s (p99 1041.53 s, success 100.0%, sample 317.073) 15. Linea: 201.00 s (p99 495.03 s, success 100.0%, sample 35.0094) 16. Scroll: 229.10 s (p99 586.91 s, success 100.0%, sample 48.0121) 17. Ethereum: 251.46 s (p99 1183.02 s, success 100.0%, sample 1249.25) **Methodology**: - Data source: `https://scan.layerzero-api.com/v1/messages/latest?limit=150`, the public LayerZero Scan API. Polled every 60 seconds, 2 pages per poll (cursor via `nextToken`). - Latency definition: `destination.tx.blockTimestamp - source.tx.blockTimestamp` from a LayerZero message row with `status.name: DELIVERED`. Both timestamps are Unix seconds from the source and destination chain blocks respectively. - Filter: only `DELIVERED` messages contribute to latency. In-flight statuses (INFLIGHT, CONFIRMING, PAYLOAD_STORED, BLOCKED, FAILED) are counted separately in `lz_message_status_total` so a spike in CONFIRMING without matching DELIVERED surfaces a stuck-message incident. - Dedupe: last 10 000 guids kept in memory (rolling FIFO). LayerZero sustained rate is ~4 messages/second network-wide, so the cache holds ~40 minutes of history. - Bucketing: histogram with buckets 2, 5, 10, 15, 20, 30, 45, 60, 90, 120, 180, 300, 600, 900, 1200, 1800 seconds (30 min ceiling). - Guard: samples with delta `< 0` or `> 30 min` are dropped (clock skew, stuck messages re-executed later). - No canary transactions: this bench observes organic LayerZero traffic (~250 messages/hour network-wide). No wallet is funded, no gas is paid. - Scope: LayerZero-supported source chains with mainnet traffic in the observation window. LayerZero exposes many exotic chains (orderly, flare, ape, robinhood) that show up as separate rows once volume is non-trivial; low-traffic sources will have wide error bars. - Fair-comparison caveat: LayerZero DVNs sign pre-finality by default, so end-to-end delivery excludes the source-chain finality wait that finality-aware networks (Chainlink CCIP, Axelar on Ethereum-source) impose. Comparing raw numbers to those on ETH-source lanes is not apples-to-apples; the meta-bench (cross-chain-messaging-latency) documents the tradeoff. ## Fastest Hyperlane source chain by end-to-end message delivery - Category: Bridges - Metric: Hyperlane delivery (ms) - Page: https://openchainbench.com/benchmarks/hyperlane-message-latency - JSON: https://openchainbench.com/api/stat/hyperlane-message-latency - Status: live - Headline: Celo leads hyperlane delivery at 10.00 s (p50, 24h) on Fastest Hyperlane source chain by end-to-end message delivery. **Rankings (p50, 24h):** 1. Celo: 10.00 s (p99 14.90 s, success 100.0%, sample 1.00016) 2. BNB Chain: 12.64 s (p99 48.45 s, success 100.0%, sample 154.023) 3. Polygon: 12.69 s (p99 50.45 s, success 100.0%, sample 191.024) 4. Arbitrum: 12.72 s (p99 56.56 s, success 100.0%, sample 498.064) 5. Ink: 13.85 s (p99 29.66 s, success 100.0%, sample 23.0038) 6. Unichain: 14.32 s (p99 29.76 s, success 100.0%, sample 19.0035) 7. Avalanche: 22.50 s (p99 29.85 s, success 100.0%, sample 3.001) 8. Sonic: 24.17 s (p99 29.88 s, success 100.0%, sample 70.0092) 9. Optimism: 25.10 s (p99 52.26 s, success 100.0%, sample 155.028) 10. Base: 25.71 s (p99 59.66 s, success 100.0%, sample 413.058) 11. Solana: 29.50 s (p99 115.25 s, success 100.0%, sample 95.0145) 12. Linea: 60.00 s (p99 118.80 s, success 100.0%, sample 4.00114) 13. Ethereum: 239.89 s (p99 298.80 s, success 100.0%, sample 527.064) **Methodology**: - Data source: `https://api.hyperlane.xyz/v1/graphql` (Hasura), the public Hyperlane Explorer feed. Polled every 60 seconds, 100 messages per poll ordered by id DESC. - Latency definition: `delivery_occurred_at - send_occurred_at` from a message row with `is_delivered: true`. Both timestamps come from the Mailbox contract events on the source and destination chains. - Filter: only delivered messages contribute to latency. Undelivered messages (`is_delivered: false`) are counted separately in `hyperlane_message_undelivered_total` so relayer coverage gaps surface as a distinct signal rather than polluting the latency histogram. - Dedupe: last 10 000 msg_ids kept in memory (rolling FIFO). Hyperlane sustained rate is ~150 messages/hour network-wide, so the cache holds ~66 hours of history. - Bucketing: histogram with buckets 2, 5, 10, 15, 20, 30, 45, 60, 90, 120, 180, 300, 600, 900, 1200, 1800 seconds (30 min ceiling). - Guard: samples with delta `< 0` or `> 30 min` are dropped (clock skew or stuck messages re-delivered later). - No canary transactions: this bench observes organic Hyperlane traffic. No wallet is funded, no gas is paid. - Scope: Hyperlane-deployed source chains with mainnet traffic in the observation window. Non-EVM domains (Solana) map to their own row when Hyperlane exposes them under a numeric domain id. - Relayer caveat: Hyperlane is permissionless; the observed latency is whichever relayer actually delivered the message. Applications choosing an under-served or misconfigured Interchain Security Module (ISM) will see structurally slower delivery. The bench reads practical UX, not a theoretical protocol floor. ## Fastest Axelar GMP source chain by end-to-end delivery - Category: Bridges - Metric: Axelar GMP delivery (ms) - Page: https://openchainbench.com/benchmarks/axelar-gmp-latency - JSON: https://openchainbench.com/api/stat/axelar-gmp-latency - Status: live - Headline: Avalanche leads axelar gmp delivery at 27.00 s (p50, 24h) on Fastest Axelar GMP source chain by end-to-end delivery. **Rankings (p50, 24h):** 1. Avalanche: 27.00 s (p99 117.90 s, success 100.0%, sample 7.00129) 2. BNB Chain: 51.75 s (p99 118.80 s, success 100.0%, sample 88.0172) 3. Osmosis: 53.30 s (p99 126.01 s, success 100.0%, sample 92.0155) 4. Polygon: 53.65 s (p99 118.30 s, success 100.0%, sample 19.0046) 5. Moonbeam: 106.68 s (p99 176.40 s, success 100.0%, sample 253.042) 6. Ethereum: 1012.92 s (p99 1199.56 s, success 100.0%, sample 113.018) 7. Arbitrum: 1283.35 s (p99 1789.67 s, success 100.0%, sample 31.0055) 8. Base: 1500.00 s (p99 1794.00 s, success 100.0%, sample 76.0117) 9. Celo: 1575.00 s (p99 2370.00 s, success 100.0%, sample 5.00103) 10. Optimism: 1619.99 s (p99 2379.00 s, success 100.0%, sample 7.00559) **Methodology**: - Data source: `https://api.axelarscan.io/gmp/searchGMP` (POST), the public AxelarScan API. Polled every 60 seconds, 25 messages per poll (server-side cap). - Two latency signals per message: `time_spent.call_confirm` (source-tx to Axelar validator quorum) and `time_spent.total` (source-tx to destination-chain execution). Both are pre-computed in seconds; the harness records both as separate Prometheus histograms. - Filter: only `status: executed` messages contribute to latency histograms. Non-executed statuses (called, confirmed, approved, error) are counted separately in `axelar_gmp_status_total` so a spike in approved without executed surfaces a stuck-relayer incident. - Dedupe: last 10 000 message ids kept in memory (rolling FIFO). Axelar GMP sustained rate is ~41 messages/hour network-wide, so the cache holds ~240 hours of history , never overflows in practice. - Bucketing: histogram with buckets 2, 5, 10, 15, 20, 30, 45, 60, 90, 120, 180, 300, 600, 900, 1200, 1800 seconds (30 min ceiling). - Guard: samples with delta `< 0` or `> 30 min` are dropped (clock skew or stuck messages). - Cosmos block-time quantisation: Axelar itself has 6-second Tendermint blocks, so sub-6s latencies always quantise to 0 or 6 seconds. This shows up as a visible floor on `call_confirm` for fast source chains and is a property of Axelar's own consensus, not our measurement. - No canary transactions: this bench observes organic Axelar GMP traffic (Squid Router, ITS, Interchain Amplifier apps). No wallet is funded, no gas is paid. - Scope: Axelar-supported source chains with mainnet traffic in the observation window. Axelar covers all major EVM L1s and L2s plus a large Cosmos set (Osmosis, Injective, Sei, Celestia, Kava) that no other bench in our cross-chain messaging cluster observes. Notable gap: Axelar mainnet does not support Solana yet. - Fair-comparison caveat: Axelar validators wait for source-chain confirmations before signing (about 96 blocks / 20 minutes on Ethereum), so Ethereum-source lanes are structurally slower than pre-finality signers (LayerZero, Hyperlane) but still faster than Chainlink CCIP which waits for full Casper FFG finality. The meta-bench (cross-chain-messaging-latency) documents this ranking. - Coverage caveat: This is Axelar-exclusive Cosmos coverage. Comparing raw numbers to networks that only cover EVM (LayerZero, CCIP) is only meaningful on shared EVM corridors; the meta-bench view (cross-chain-messaging-latency) enforces this by only showing cells where both protocols support the corridor. ## Fastest cross-chain messaging protocol, live end-to-end delivery latency - Category: Bridges - Metric: Cross-chain delivery (ms) - Page: https://openchainbench.com/benchmarks/cross-chain-messaging-latency - JSON: https://openchainbench.com/api/stat/cross-chain-messaging-latency - Status: live - Headline: Hyperlane leads cross-chain delivery at 25.12 s (p50, 24h) on Fastest cross-chain messaging protocol, live end-to-end delivery latency. **Rankings (p50, 24h):** 1. Hyperlane: 25.12 s (p99 446.05 s, success 100.0%, sample 3345.8) 2. LayerZero: 57.71 s (p99 1681.87 s, success 100.0%, sample 9614.33) 3. Axelar: 103.02 s (p99 1764.93 s, success 100.0%, sample 915.156) 4. Chainlink CCIP: 1007.41 s (p99 3583.48 s, success 100.0%, sample 511.085) **Methodology**: - Data sources: each protocol's own public message tracker, polled every 60 seconds. LayerZero via scan.layerzero-api.com/v1/messages/latest, Chainlink CCIP via api.ccip.chain.link/v2/messages, Hyperlane via api.hyperlane.xyz/v1/graphql, Axelar via api.axelarscan.io/gmp/searchGMP. - Latency definition: wall-clock seconds from source-chain transaction submission to destination-chain execution, computed from each tracker's own source and destination block timestamps. All four protocols expose the same shape (source_ts, destination_ts); the harness converts to milliseconds and records a per-source-chain histogram. - Fairness caveat on Ethereum-source lanes: CCIP AND Axelar both wait for source-chain finality before signing (CCIP via Casper FFG, Axelar via ~96 confirmations) so ETH-source lanes structurally add 12-20 min. LayerZero and Hyperlane sign pre-finality by default. L2 and non-EVM lanes are more directly comparable because they finalize quickly. - Wormhole excluded from this side-by-side: wormholescan only exposes source-tx-to-Guardian-quorum (signing) latency, not destination-side execution. Including Wormhole would compare signing time (about 18s) against end-to-end delivery time (about 30-55s) and make Wormhole look 3x faster than it actually is. Wormhole gets its own dedicated bench at wormhole-vaa-latency with the same signing-time methodology. - Aggregation: the number on this page is the p50/p90/p99 across ALL corridors each protocol observes over the last 24 hours. Per-corridor breakdown is on each dedicated bench (layerzero-message-latency, chainlink-ccip-latency, hyperlane-message-latency, axelar-gmp-latency). - Coverage: LayerZero covers 30+ chains including Solana. Chainlink CCIP and Hyperlane cover most EVMs; CCIP added Solana Oct 2025. Axelar covers all major EVMs plus a Cosmos set (Osmosis, Injective, Sei, Celestia) but not Solana. Aggregation is honest because each protocol is aggregated over its own footprint; per-corridor drill-down lives on each dedicated bench. - No canary transactions: every value on this page is a real user message. No wallet is funded, no gas is paid. Total observation cost is API polling. - Circle CCTP not included: Circle's Iris API does not expose a list-recent endpoint, so passive polling is not feasible without maintaining nonce state via chain-scan on all ~10 CCTP source chains plus Solana. A CCTP bench is on the roadmap. ## Fastest free Sei RPC, live no-key EVM endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/sei-rpc - JSON: https://openchainbench.com/api/stat/sei-rpc - Status: live - Headline: Sei Labs leads rpc latency at 80 ms (p50, 24h) on Fastest free Sei RPC, live no-key EVM endpoint latency. **Rankings (p50, 24h):** 1. Sei Labs: 80 ms (p99 111 ms, success 100.0%, sample 1389.82) 2. Stakeme: 194 ms (p99 2.71 s, success 100.0%, sample 1389.82) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 25 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="sei"`. Provider coverage at launch: 4 no-key endpoints. ## Fastest free Mode RPC, live no-key EVM endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/mode-rpc - JSON: https://openchainbench.com/api/stat/mode-rpc - Status: live - Headline: Mode Labs leads rpc latency at 176 ms (p50, 24h) on Fastest free Mode RPC, live no-key EVM endpoint latency. **Rankings (p50, 24h):** 1. Mode Labs: 176 ms (p99 340 ms, success 100.0%, sample 1396.82) 2. dRPC: 190 ms (p99 875 ms, success 93.2%, sample 1379.83) 3. 1RPC: 310 ms (p99 1.39 s, success 97.6%, sample 1373.49) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 25 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="mode"`. Provider coverage at launch: 4 no-key endpoints. ## Fastest free Ronin RPC, live no-key EVM endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/ronin-rpc - JSON: https://openchainbench.com/api/stat/ronin-rpc - Status: live - Headline: dRPC leads rpc latency at 162 ms (p50, 24h) on Fastest free Ronin RPC, live no-key EVM endpoint latency. **Rankings (p50, 24h):** 1. dRPC: 162 ms (p99 247 ms, success 94.7%, sample 1380.84) 2. Sky Mavis: 221 ms (p99 301 ms, success 100.0%, sample 1389.82) 3. Tenderly Gateway: 332 ms (p99 351 ms, success 100.0%, sample 1376.81) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 25 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="ronin"`. Provider coverage at launch: 4 no-key endpoints. ## Fastest free Immutable zkEVM RPC, live no-key EVM endpoint latency - Category: RPCs - Metric: RPC latency (ms) - Page: https://openchainbench.com/benchmarks/immutable-rpc - JSON: https://openchainbench.com/api/stat/immutable-rpc - Status: live - Headline: Immutable leads rpc latency at 225 ms (p50, 24h) on Fastest free Immutable zkEVM RPC, live no-key EVM endpoint latency. **Rankings (p50, 24h):** 1. Immutable: 225 ms (p99 255 ms, success 100.0%, sample 1415.83) 2. Tenderly Gateway: 329 ms (p99 353 ms, success 100.0%, sample 1373.81) 3. dRPC: 347 ms (p99 671 ms, success 92.5%, sample 1404.86) **Methodology**: - Cadence: every 60 seconds per provider, from each of 3 probe regions (us-east Virginia, eu-west Amsterdam, sgp Singapore). Headline p50/p90/p99 aggregate across all 3 regions via Prometheus `avg(quantile_over_time(...))`; per-region breakdowns are first-class on this page via the region tabs. - Payload: `{"jsonrpc":"2.0","id":,"method":"eth_getBlockByNumber","params":["latest", false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node. - Latency: client-side round-trip delta in milliseconds, exposed as both a gauge and a histogram (buckets 50 ms → 10 s), so percentiles are computed via Prometheus `quantile_over_time` over the last 24 hours. - Call-result classification: `ok` (HTTP 200 + non-empty result with a parsable hex block number), `http_err`, `jsonrpc_err` (HTTP 200 carrying an error body), `stale` (more than 25 blocks behind the cross-provider tip), `timeout`. Latency without reliability is a misleading ranking signal. - This page is part of the per-chain RPC cluster derived from the cross-chain [rpc-capabilities](https://openchainbench.com/benchmarks/rpc-capabilities) benchmark; the identical harness, cadence and exclusion rules apply on every chain. - Chain scope: every query on this page is pinned to `chain="immutable"`. Provider coverage at launch: 4 no-key endpoints. --- Want machine-readable indexes? - JSON index: https://openchainbench.com/api/citable - OpenAPI: https://openchainbench.com/api/openapi.json - MCP server: https://openchainbench.com/api/mcp/mcp - llms.txt: https://openchainbench.com/llms.txt