BNB Smart Chain method

eth_chainId

Returns the chain ID the node is serving, as a hex quantity.

cheapCheap for a provider to serve — no state is read, or one key is.Primary specification

How each provider handles it

Provider support for eth_chainId on BSC
Provider	Status	Success	Median	Worst p95	Incidents	Samples
PublicNode	Supported	100.0%	27 ms	394 ms	none	240
Blast API	Supported	100.0%	108 ms	488 ms	none	235
1RPConerpc	Rate limited	0.0%	—	—	none	23
BNB Chain	Degraded	98.7%	17 ms	123 ms	none	475
NodeReal	Degraded	98.7%	18 ms	69 ms	none	230

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 minute. 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. 1 provider is not plotted: they returned no successful response in this window, so they have no latency.

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.

1h window · generated 2026-10-08 19:23:28 UTC · 5 providers