Osmosis RPC endpoints: free public URLs by latency
HTTP round-trip latency for the Tendermint `status` method against every free, no-key public Osmosis Cosmos SDK endpoint, audited every 60 seconds from 3 regions.
TL;DR. As of , PublicNode has the lowest median latency of the 4 free public Osmosis RPC endpoints measured, 81 ms (p50, 24h, 3 regions). Source: OpenChainBench, https://openchainbench.com/benchmarks/osmosis-rpc. 4 public endpoints, no key: osmosis-rpc.publicnode.com, rpc.osmosis.zone, osmosis-rpc.polkachu.com, rpc.lavenderfive.com. 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 →
Osmosis is the first Cosmos SDK chain in the RPC latency cluster. CometBFT (Tendermint) consensus, JSON-RPC 2.0 wire but a chain-family specific method set: the probe is Tendermint `status` (returns `sync_info.latest_block_height` as a decimal string plus `latest_block_hash`) rather than `eth_getBlockByNumber`. Everything else on this page is the same bench pattern used on Ethereum, Base, Solana, Polkadot and the 20+ other chains: identical POST every 60 seconds from three regions, latency measured client-side at millisecond precision, per-region breakdowns first class. Provider cohort at launch: Osmosis Foundation's `rpc.osmosis.zone`, Polkachu, PublicNode (Allnodes), Imperator and LavenderFive. Lava, OnFinality, Numia, AutoStake, BlockApsis, WhisperNode, Enigma-Validator, StakeTown and reece.sh were audited alongside and excluded (Lava 403 on the public osmosis endpoint, OnFinality osmosis public gateway timing out at probe cadence, Numia 401 without a key, the others returned connect errors or moved paths during the launch sweep); each will be revisited when a stable no-key path reappears.
Methodology
Osmosis: 4 free public RPC endpoints answering `status` every 60 seconds from us-east, eu-west and Singapore, ranked by 24h median. PublicNode leads at 81 ms; the chain-official endpoint measures 101 ms. We measure the round-trip latency of a single, identical JSON-RPC call (Tendermint `status`) against every no-key public Osmosis Cosmos SDK endpoint that sustains continuous probing, 4 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) with a Cosmos-scaled staleness gap (40 blocks ≈ 4 minutes at Osmosis's ~6 s block time), so the leaderboard rewards sustained, honest availability rather than a fast error message. The cross-chain view lives on the parent `rpc-capabilities` benchmark; this page is the Osmosis-scoped answer with per-region breakdowns as a first-class dimension.
Results: 4 free public Osmosis RPC endpoints ranked by p50 latency (24h, 3 regions)
| № | Providers | p50 | p90 | p99 | Success |
|---|---|---|---|---|---|
| 1 | PublicNode | 81 ms | 99 ms | 308 ms | 99.86% (n=4322) |
| 2 | Osmosis Foundation | 101 ms | 121 ms | 455 ms | 98.78% (n=4331) |
| 3 | Polkachu | 165 ms | 295 ms | 561 ms | 99.75% (n=4322) |
| 4 | LavenderFive | 174 ms | 221 ms | 534 ms | 99.84% (n=4323) |
Public Osmosis RPC endpoints measured
The 4 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.
PublicNodehttps://osmosis-rpc.publicnode.com81 ms99.9%
Osmosis Foundationhttps://rpc.osmosis.zone101 ms98.8%
Polkachuhttps://osmosis-rpc.polkachu.com165 ms99.7%
LavenderFivehttps://rpc.lavenderfive.com:443/osmosis174 ms99.8%
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.
Frequently asked
Which Osmosis RPCs work without an API key?
5 endpoints are probed on this chain: Osmosis Foundation's `rpc.osmosis.zone`, Polkachu (`osmosis-rpc.polkachu.com`), PublicNode / Allnodes (`osmosis-rpc.publicnode.com`), Imperator (`rpc-osmosis.imperator.co`) and LavenderFive (`rpc.lavenderfive.com/osmosis`). Every listed endpoint was live-verified with a `status` POST returning a parsable decimal `sync_info.latest_block_height` before inclusion. Excluded by the audit: Lava's `osmosis.tendermintrpc.lava.build` returned 403 without a key, OnFinality's public osmosis gateway kept timing out at probe cadence, Numia rejected without an API key (401), Ankr and Chainstack require paid Cosmos tiers, and several community-run endpoints (BlockApsis, WhisperNode, Enigma-Validator, StakeTown, reece.sh) returned connect errors during the sweep.
Why is the probe `status` and not `abci_info` or `block`?
Two reasons. First, Tendermint `status` returns `sync_info.latest_block_height` on every Cosmos SDK chain in a shape the cluster's cross-provider tip machinery understands without a chain-specific code path. Second, `abci_info` returns application-level metadata that a polite CDN can synthesise without touching the underlying node, defeating the point of a latency probe on the RPC path; `block` requires a height parameter and would either bias toward providers with a fast archive path or duplicate the head-block work `status` already does. `status` forces the endpoint to actually read the head from the consensus engine, which is what integrators care about.
Why is there no archive-depth or hash-quorum column for Osmosis?
Cosmos SDK chains access historical state via ABCI queries keyed on module + KV-store, which has no chain-agnostic depth analog for the EVM `eth_getBalance(address, height)` probe the cluster uses on other chains. Hash quorum (bench 083 cross-provider height-hash agreement) is technically feasible on Cosmos because `latest_block_hash` in the `status` response corresponds to the same block the height is reported for, 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 the quorum path here. Both columns are omitted honestly rather than filled with a proxy that would misrepresent the chain.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/rpc-capabilities