OpenChainBench
All benchmarks
RPCsUpdated

IoTeX RPC endpoints: free public URLs by latency

HTTP round-trip latency for eth_getBlockByNumber against every free, no-key public IoTeX RPC endpoint, audited every 60 seconds from 3 regions.

TL;DR. As of , IoTeX Foundation has the lowest median latency of the 2 free public IoTeX RPC endpoints measured, 158 ms (p50, 24h, 3 regions). Source: OpenChainBench, https://openchainbench.com/benchmarks/iotex-rpc. Chain ID 4689. 2 public endpoints, no key: babel-api.mainnet.iotex.io, babel-api.mainnet.iotex.one. Full URLs with their 24h median are listed below.

Companion page

Comparing free RPC endpoints across every chain we measure? Open the cross-chain RPC matrix →

IoTeX (chain 4689) is an EVM-compatible Layer 1 designed for decentralized physical infrastructure networks (DePIN), IOTX gas token, combining IoT device identity, data streams, and on-chain settlement. The IoTeX Foundation's Babel gateway, its .one mirror and Thirdweb provide keyless eth_ JSON-RPC access (Ankr now requires a key and left on 2026-10-19) probed every 60 seconds from three regions.

Methodology

IoTeX: 2 free public RPC endpoints answering `eth_getBlockByNumber` every 60 seconds from us-east, eu-west and Singapore, ranked by 24h median. IoTeX Foundation leads at 158 ms. We measure the round-trip latency of a single, identical RPC call (`eth_getBlockByNumber`) against every no-key public IoTeX endpoint that sustains continuous probing, 2 providers live today, every 60 seconds, from us-east, eu-west and Singapore. The harness classifies every response (ok / http_err / jsonrpc_err / stale / timeout) so the leaderboard rewards sustained availability rather than fast error messages. The cross-chain view lives on the parent `rpc-capabilities` benchmark; this page is the IoTeX-scoped answer with per-region breakdowns as a first-class dimension.

  • 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":<rotating>,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request.
  • Latency measurement, call-result classification (`ok`, `http_err`, `jsonrpc_err`, `stale`, `timeout`) and the archive-depth audit follow the cluster method documented on [rpc-capabilities](openchainbench.com/benchmarks/rpc-capabilities#methodology); this page is the IoTeX-scoped view of the same harness, with the same exclusion rules.
  • Chain scope: every query on this page is pinned to `chain="iotex"`. Provider coverage today: 2 no-key endpoints.

Results: 2 free public IoTeX RPC endpoints ranked by p50 latency (24h, 3 regions)

IoTeX RPC endpoints: free public URLs by latency: RPC latency per provider (p50, 24h).
№Providersp50p90p99Success
1IoTeX Foundation158 ms204 ms630 ms98.19% (n=4314)
2IoTeX Mirror159 ms189 ms294 ms99.47% (n=4314)

Public IoTeX RPC endpoints measured

Chain ID 4689, currency IOTX. The 2 no-key endpoints answering our probes today, with their current 24h median. Paste one into a wallet or a client as is: no signup, no key. Private providers (API key) are never listed with a URL.

Median round-trip and success rate over the last 24 hours across the probe regions; the ranked table above carries p90, p99 and the per-region split.

Declared, but not answering our probes

This endpoint is named in the spec and probed on the same schedule as the rest, and answers too rarely to carry a median. Below 5 % success we leave it out of the table rather than publish a latency drawn from a handful of replies. A provider can serve a browser and refuse a datacenter, so this says what a server deployment would meet, not what the endpoint is capable of.

  • Thirdwebhttps://4689.rpc.thirdweb.com1.7 % success over 24 h

Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/rpc-capabilities