EIP-695: Create `eth_chainId` method for JSON-RPC

Discussion thread for EIP-695: https://eips.ethereum.org/EIPS/eip-695


Quantity in this context feels wrong - it’s not really a quantity - it’s an ID:

I think this thread is relevant for the discussion of the EIP-1637

Is there any reason this EIP is still Draft? cc @sorpaas

Just moved EIP-695 to last call status (https://github.com/ethereum/EIPs/pull/2128) with a review period of 4 weeks. Any comments appreciated!

I think it’s just naming convention for Ethereum JSON-RPC. We probably should have named everything as “Hex Numbers”, but for historical reasons they’re all named “QUANTITY” in current JSON-RPC docs.

I have completely reviewed this EIP and fully endorse it to go to FINAL status as is.

One potential improvement is this minor correction https://github.com/ethereum/EIPs/pull/2133

1 Like

Isaac Ardis, Wei Tang, Fan Torchz, can we please get a PR to move to final here if you will proceed?

1 Like

This EIP is more relevant considering EIP-1344’s inclusion into Istanbul, which will define a client-side configuration value that is available internally to the EVM, to which this proposal can make use of.

Discussion here: EIP-1344: Add chain id opcode

Just noticed that, like EIP-1344, it should probably be included in the rationale that the client needs to independently provide the value of Chain ID instead of looking it up from the latest signed transaction. Transactions currently have a corner case where both EIP155 compliant and non-EIP155 compliant transactions will validate, so this is not a reliable source of this value, but rather should be checked against the internally-provided configuration of chain ID.

1 Like

Yo what’s up here…

I believe both Parity and geth implement this endpoint, so it could probably get finalized on the next ACD call?

Edit: one thing to note is that the quantity should be a uint256 because of the opcode and the future potential scenario where it could be a 32 byte hash.

Pantheon also supports it and I believe MetaMask is already using it. I’m a little surprised this isn’t already final to be honest.

And the spec does explicitly reference the “configured chain ID” although admittedly the meaning of that felt a lot clearer prior to all the discussions around the CHAINID opcode. Mostly because this JSON-RPC method doesn’t execute in the context of a transaction, it’s a big leap to jump to picking some unspecified transaction from the chain and getting the chain ID from there.

1 Like

That discussion largely evolved into not having chain ID be set from a transaction, for the specific reason that it’s necessary to validate the EIP-155 v value against some configuration anyways. So, this EIP and EIP-1344 should just returned the configured setting from the client, as I believe they already do.


Is anyone trying to bring this over the finish line at the moment? As @ajsutton noted back in August, MetaMask is already using this.

An unfortunate development while this EIP has been in last call is that some widely used resources in the community have started to list chainIds as decimal numbers, for instance chainId.network.

At MetaMask, we’re inclined to continue returning a hex string per this EIP. Perhaps @pedrouid or @ligi could comment in their capacity as contributors to chainId.network?

What drawback do you see in chainid.network using decimal? It can be converted easily …

In that case, I take it your intention was not to be prescriptive? I’m fine with that.

Then the remaining question is whether anyone is championing this.

1 Like

no - that was not the intention.


1 Like

Basically going to repeat what @ligi said already. The chainId’s on chainid.network using decimal is purely informative.

I agree that eth_chainId JSON-RPC response should be in hexadecimal format. In fact, that should just be a rule for all values of Ethereum’s JSON-RPC API.

1 Like

it could make sense to to specify exactly what "describing the currently configured CHAIN_ID" means. As there are 2 edge cases:

  • what is with chains that did not start with EIP-155
  • what is with chains that changed the chainID in a fork

this was leading to an issue here:

Also I think we should add eth_chanId to: https://github.com/ethereum/wiki/wiki/JSON-RPC