Skip to content

Chain ID

A verification-first guide to EVM chain IDs, EIP-155 legacy replay domains, typed transactions, CHAINID, wallet and RPC checks, EIP-712 domains and non-EVM network identifiers.

Updated

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

  1. 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.
  2. Pin a trusted network snapshot: RPC URL, expected chain ID in decimal and hex, genesis or finalized checkpoint, head block, client configuration, key contract codeHash and source timestamp. A wallet network name and icon are untrusted metadata.
  3. Query eth_chainId for 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 substitute net_version, and reject a mismatch before constructing a signature.
  4. 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.
  5. 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.
  6. 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.
  7. 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 by eth_chainId as 0x2105: 2 * 4096 + 1 * 256 + 0 * 16 + 5 = 8453. Ethereum mainnet is 1 = 0x1, and Arbitrum One is 42161 = 0xa4b1. If a wallet expects 8453 but receives 0x1, 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 ID 1, values are 37 or 38; with chain ID 61, values are 157 or 158. Conversely, floor((37 - 35) / 2) = 1. This arithmetic does not apply to the y-parity field of typed transactions or to unprotected legacy signatures using 27 or 28.
  • Typed transaction and wrong-chain rejection. A type-2 payload binds chain_id=8453. With 21,000 gas, base fee 20 gwei, maximum priority fee 2 gwei and maximum fee 30 gwei, effective gas price is min(30, 20 + 2) = 22 gwei and fee is 21,000 * 22 gwei = 0.000462 ETH. A correctly enforcing chain configured as ID 1 rejects 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-1 and independent EVM integer ID 262144 = 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_version as though it were always equal to eth_chainId.
  • Missing an EIP-1193 chainChanged event 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 v formula to typed transactions or other signatures.
  • Assuming a raw message or personal_sign request 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.

Sources

Navigation

Search the wiki...