BNB Smart Chain method
eth_chainId
Returns the chain ID the node is serving, as a hex quantity.
How each provider handles it
| Provider | Status | Success | Median |
|---|---|---|---|
| BNB Chain | Supported | 99.9% | 18 ms |
| NodeReal | Supported | 99.9% | 18 ms |
| PublicNode | Supported | 100.0% | 25 ms |
| Blast API | Supported | 99.7% | 105 ms |
| 1RPConerpc | Failing | 6.4% | 131 ms |
Success excludes calls the provider does not implement — an optional method a provider declines to offer is a capability fact, not a failure, and is never scored as one.
Over time
Median latency per hour. Gaps are periods with no measurement, drawn as gaps rather than joined across — a line through missing data invents a measurement that was never taken.
Logarithmic scale — each gridline is ten times the one below it. Click a provider in the legend to hide it.
When it degraded
A degradation is a bucket where a provider fell away from ITS OWN median for this method over the window, not from the cohort's. A provider that is consistently slower than its peers is not degraded — it is slower, which the ranking already says. Buckets with fewer than 20 samples are skipped, because a claim about a provider cannot rest on a handful of calls, and adjacent bad buckets are merged so one outage reads as one incident.
1RPC
success fell to 0.0% from a typical 31.7%
availability · 2026-10-07 20:00Z → 2026-10-07 23:00Z
success fell to 1.0% from a typical 31.7%
availability · 2026-10-08 01:00Z → 2026-10-08 14:00Z
success fell to 0.0% from a typical 31.7%
availability · 2026-10-08 16:00Z → 2026-10-08 18:00Z
What it does
The chain ID identifies which network an endpoint is actually connected to — `0x1` for Ethereum mainnet, `0x38` for BNB Smart Chain. It was introduced by EIP-155 to stop a transaction signed for one chain being replayed on another, and every wallet and signing library reads it before submitting anything.
It is the cheapest call an Ethereum node serves. Nothing is read from state and no computation happens; the answer is a constant baked into the node's configuration.
Returns
QUANTITY — the chain ID in hex.
Try it
Runnable as written, against a keyless public endpoint. Nothing here needs an API key.
Request
curl -s https://ethereum-rpc.publicnode.com \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}'As JSON-RPC
{
"jsonrpc": "2.0",
"method": "eth_chainId",
"params": [],
"id": 67
}Response
{
"id": 67,
"jsonrpc": "2.0",
"result": "0x1"
}Things that bite
- A mismatch between the configured chain and the returned ID is treated here as a correctness failure rather than a slow response. An endpoint answering quickly with the wrong chain is worse than one that is slow.
Why it is measured
It is the closest thing to a pure network round trip an EVM endpoint offers. Because it touches no state, its latency is dominated by the path between the probe and the provider's edge, which makes it the cleanest baseline to compare every other method against.
Called every 60 seconds per endpoint, with jitter so the fleet does not hit a provider in lockstep.
24h window · generated 2026-10-08 19:33:52 UTC · 5 providers