Skip to content

Ethereum 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 (opens in a new tab)

How each provider handles it

This method has not been measured in this window.

It is scheduled but no observation has landed yet.

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-08-24 20:31:24 UTC · 0 providers