For educational purposes only; not investment, legal, or security advice. A matching chain ID reduces specified replay risk but does not authenticate an RPC, network, contract, asset, signature request, or final state.
Direct answer
In the EVM ecosystem, a chain ID is a configured integer used as a replay-domain parameter. EIP-155 binds it to protected legacy transaction signatures; typed transaction formats such as type 2 encode it in their own signed payload; CHAINID exposes it during EVM execution; and eth_chainId reports it through JSON-RPC. These are related interfaces, not a universal identity certificate.
The value is not guaranteed globally unique or permanent. Private networks and contentious forks can reuse it, an RPC can lie, and the same address can contain different code and state on different chains. EIP-712 includes an optional chain ID domain field, while raw messages and non-EVM systems have different replay and network-identity rules. Correct use therefore requires the exact signing scheme, endpoint, genesis or checkpoint and application domain.
How it works
- Identify the ecosystem and identifier semantics first: EVM EIP-155 integer, EIP-712 domain, CAIP-2 namespaced reference, Cosmos string chain ID, Solana genesis hash or another scheme. Never compare an unqualified number across ecosystems.
- Pin a trusted network snapshot: RPC URL, expected chain ID in decimal and hex, genesis or finalized checkpoint, head block, client configuration, key contract
codeHashand source timestamp. A wallet network name and icon are untrusted metadata. - Query
eth_chainIdfor EVM signing and parse the hexadecimal JSON-RPC quantity without precision loss. Compare the normalized integer with the expected configuration and wallet provider state; do not substitutenet_version, and reject a mismatch before constructing a signature. - Reconstruct the exact signing domain. Distinguish unprotected legacy transactions, EIP-155 protected legacy encoding and typed envelopes; for EIP-712 verify the domain fields,
verifyingContract, nonce and deadline; for relayed or smart-account intents inspect the inner protocol hash. - Verify the execution target on the active chain: recipient, value, calldata, token address, contract code or proxy implementation, account nonce, fees and simulated state. Chain ID separates a domain but does not prove that any of those objects are genuine.
- Treat EIP-1193
chainChanged, account changes and disconnects as hard state boundaries. Discard cached quote, allowance, nonce, simulation and signing requests, re-read the chain and target, and broadcast only the reviewed raw transaction to the pinned endpoint. - Reconcile the transaction on the intended chain: raw signed bytes and hash, RPC acceptance, receipt status, block number and hash, nonce use, state changes and required finality. Monitor chain splits, ID changes, L1/L2 domain confusion and provider drift, and fail closed on unexplained differences.
Worked examples
- Hex and decimal RPC gate. Base has decimal chain ID
8453, represented byeth_chainIdas0x2105:2 * 4096 + 1 * 256 + 0 * 16 + 5 = 8453. Ethereum mainnet is1 = 0x1, and Arbitrum One is42161 = 0xa4b1. If a wallet expects8453but receives0x1, it must abort before signing rather than trust the displayed network name. - Protected legacy transaction v. For EIP-155 legacy transactions,
v = 35 + 2 * chainId + yParity. With chain ID1, values are37or38; with chain ID61, values are157or158. Conversely,floor((37 - 35) / 2) = 1. This arithmetic does not apply to the y-parity field of typed transactions or to unprotected legacy signatures using27or28. - Typed transaction and wrong-chain rejection. A type-2 payload binds
chain_id=8453. With21,000 gas, base fee20 gwei, maximum priority fee2 gweiand maximum fee30 gwei, effective gas price ismin(30, 20 + 2) = 22 gweiand fee is21,000 * 22 gwei = 0.000462 ETH. A correctly enforcing chain configured as ID1rejects that signed payload for domain mismatch, so rejection itself consumes no on-chain gas there; the transaction can still fail for other reasons on ID 8453. - Non-EVM and dual identifiers. A Cosmos EVM deployment can use Cosmos SDK string ID
local-1and independent EVM integer ID262144 = 0x40000. Cosmos-native signing uses the string plus its account number and sequence; EVM transaction signing uses the integer domain. Solana instead exposes a genesis hash and uses a recent blockhash or durable nonce in transaction messages, not an EIP-155 integer.
Risks
- Connecting to the wrong RPC endpoint or active wallet chain.
- Trusting a malicious RPC that lies about chain ID, state or broadcast results.
- Confusing hexadecimal and decimal chain ID representations.
- Losing precision by parsing a large chain ID with an unsafe numeric type.
- Using
net_versionas though it were always equal toeth_chainId. - Missing an EIP-1193
chainChangedevent or network-switch race. - Reusing cached nonces, quotes, approvals or simulations after a switch.
- Assuming chain IDs are globally registered and collision-free.
- Signing across private networks or forks that reuse one chain ID.
- Failing to define behavior when a fork changes or retains the ID.
- Accepting an unprotected legacy transaction with no EIP-155 domain.
- Applying the legacy
vformula to typed transactions or other signatures. - Assuming a raw message or
personal_signrequest includes a chain domain. - Omitting or misencoding chain ID in an EIP-712 domain.
- Omitting
verifyingContract, application nonce, deadline or purpose. - Trusting identical contract addresses without comparing code and state.
- Confusing L1, L2, bridge-origin and destination signing domains.
- Ignoring the inner domain of a relayed intent, permit or smart-account operation.
- Treating wallet-add metadata, explorer labels or icons as network authentication.
- Transplanting EVM semantics to Cosmos, Solana, Bitcoin or another protocol.
Common misconceptions
- A chain ID is a globally unique and permanent official registration number.
- A correct chain ID proves the RPC endpoint, network and contracts are authentic.
- Every Ethereum signature automatically commits to chain ID.
- Different chain IDs prevent replay of every signed message and application intent.
- Every blockchain uses an EIP-155-style integer chain ID.
Related topics
Sources
- EIP-155: Simple replay attack protection - Ethereum Improvement Proposals (accessed: 2026-08-12)
- EIP-1559: Fee market change for ETH 1.0 chain - Ethereum Improvement Proposals (accessed: 2026-08-12)
- EIP-1344: ChainID opcode - Ethereum Improvement Proposals (accessed: 2026-08-12)
- EIP-1193: Ethereum Provider JavaScript API - Ethereum Improvement Proposals (accessed: 2026-08-12)
- EIP-3085: wallet_addEthereumChain RPC Method - Ethereum Improvement Proposals (accessed: 2026-08-12)
- EIP-712: Typed structured data hashing and signing - Ethereum Improvement Proposals (accessed: 2026-08-12)
- CAIP-2: Blockchain ID Specification - Chain Agnostic Improvement Proposals (accessed: 2026-08-12)
- getGenesisHash RPC Method - Solana Documentation (accessed: 2026-08-12)