Chain ID

What Is a Chain ID?

A chain ID is a unique numerical identifier assigned to a blockchain network. It is included in the cryptographic signature of every transaction, binding that transaction to a single chain. If someone attempts to broadcast the same signed transaction on a different chain with a different chain ID, the network rejects it because the signature verification fails.

Chain IDs were introduced to solve a specific problem: when two networks share the same transaction format and account history (as happens after a hard fork), a transaction signed on one chain is equally valid on the other. This opens the door to replay attacks, where an attacker rebroadcasts a legitimate transaction on the sibling chain to steal funds. By embedding a chain-specific identifier into the signing process, EIP-155 made each transaction inherently chain-bound.

How It Works

EIP-155, authored by Vitalik Buterin in October 2016 and activated in the Spurious Dragon hard fork at block 2,675,000, modifies how Ethereum transactions are signed. The change is subtle but effective: three additional fields are included in the data that gets hashed before signing.

Transaction Signing Before EIP-155

Before chain IDs existed, the signing hash was computed over six RLP-encoded fields:

// Pre-EIP-155 signing payload
rlpEncode(nonce, gasPrice, gasLimit, to, value, data)

// The ECDSA signature produced (r, s, v)
// v = recovery_id + 27 (so v was 27 or 28)

Because no chain-specific data entered the hash, the resulting signature was valid on any EVM chain that shared the same account state.

Transaction Signing After EIP-155

EIP-155 appends three fields to the signing payload: the chain ID itself and two zero-value padding fields:

// Post-EIP-155 signing payload
rlpEncode(nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0)

// The ECDSA signature produced (r, s, v)
// v = recovery_id + chainId * 2 + 35

The chain ID is also encoded into the v parameter of the ECDSA signature. A verifying node can extract the chain ID using chainId = (v - 35) / 2 (integer division) and reject the transaction if it does not match the node's own chain. This makes replay protection cryptographic rather than relying on convention.

Chain ID vs. Network ID

Chain ID and network ID are related but distinct concepts. The chain ID is used in transaction signatures for replay protection (EIP-155). The network ID is used in the peer-to-peer devp2p protocol for node discovery. For most public networks these values are identical, but they serve different layers of the stack. EIP-695 introduced the eth_chainId JSON-RPC method so that wallets and decentralized applications can programmatically query which chain a node belongs to.

Why Chain IDs Were Created

The direct catalyst for EIP-155 was the Ethereum/Ethereum Classic split in July 2016. After the DAO hack drained approximately 3.6 million ETH through a reentrancy vulnerability, the Ethereum community voted to hard fork at block 1,920,000 to reverse the theft. The portion of the community that rejected the fork continued on the original chain, now called Ethereum Classic.

Because both chains shared identical transaction history up to the fork point, every account existed on both chains with the same private key and balance. A transaction signed on Ethereum mainnet could be replayed on Ethereum Classic (and vice versa), causing users to unintentionally send funds on both chains. This replay attack vulnerability made the split dangerous for ordinary users.

EIP-155 solved this by assigning Ethereum mainnet chain ID 1 and Ethereum Classic chain ID 61. Transactions signed with chain ID 1 are cryptographically invalid on a chain expecting chain ID 61.

Well-Known Chain IDs

Every EVM-compatible network has a registered chain ID. Some of the most widely used:

The de facto registry for chain IDs is the ethereum-lists/chains GitHub repository, which powers the ChainList directory. Registration is first-come-first-served via pull request: there is no central authority like IANA for domain names.

Use Cases

Replay Protection Across Forks

The primary purpose of chain IDs is preventing replay attacks after chain splits. Any time a network undergoes a contentious hard fork that produces two live chains, chain IDs ensure transactions are only valid on the intended network. Without this protection, every transaction on one fork could be copied and executed on the other.

Wallet Network Switching

Wallets use chain IDs to manage multi-chain experiences. The EIP-3085 standard (wallet_addEthereumChain) allows decentralized applications to request that a wallet add a new network by providing its chain ID, RPC endpoints, and native currency details. EIP-3326 (wallet_switchEthereumChain) lets applications request a switch to a specific chain ID already known to the wallet.

// Request wallet to switch to Polygon (chain ID 137)
await window.ethereum.request({
  method: "wallet_switchEthereumChain",
  params: [{ chainId: "0x89" }], // 137 in hex
});

// If the chain is unknown, add it
await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0x89",
    chainName: "Polygon PoS",
    rpcUrls: ["https://polygon-rpc.com"],
    nativeCurrency: {
      name: "POL",
      symbol: "POL",
      decimals: 18,
    },
  }],
});

Smart Contract Chain Verification

Smart contracts can read the current chain ID using the CHAINID opcode (introduced by EIP-1344) or Solidity's block.chainid. This enables contracts to verify they are executing on the correct network, which is useful for cross-chain messaging protocols and bridge security checks.

Multi-Chain Application Routing

Applications that operate across multiple EVM chains use chain IDs as routing keys. Cross-chain bridges, DEX aggregators, and payment orchestration platforms reference chain IDs to determine which network a user's assets reside on and where to route transactions.

Bitcoin's Approach

Bitcoin does not use a chain ID system. Instead, it differentiates networks through several complementary mechanisms:

• Network magic bytes: each Bitcoin network uses a unique 4-byte prefix at the start of every P2P protocol message. Mainnet uses f9beb4d9, Testnet4 uses 1c163f28, and Signet uses 0a03cf40.
• Address version bytes: mainnet addresses begin with 1 (P2PKH), 3 (P2SH), or bc1 (Bech32). Testnet addresses use different prefixes (m/n, 2, tb1), making them visually and programmatically distinguishable.
• Separate genesis blocks: each Bitcoin network has a different genesis block, so they maintain entirely independent UTXO sets. A transaction referencing a UTXO that only exists on mainnet is structurally invalid on testnet.

Bitcoin's replay protection is structural rather than cryptographic: networks are separated at the data level (different UTXOs, different addresses) rather than at the signature level. Ethereum needed chain IDs specifically because account-model blockchains share account state across forks.

Risks and Considerations

No Central Authority

Chain ID assignment relies on a community-maintained GitHub repository with first-come-first-served registration. While collisions are prevented by CI checks, there is no formal governance body overseeing the registry. ERC-7785, proposed in September 2024, would move to an onchain registration system using Keccak-256 hashes and ENS, but it remains in draft status.

Legacy Transaction Compatibility

EIP-155 was designed with backward compatibility: pre-fork transactions with v values of 27 or 28 (no chain ID) are still accepted on most networks. This means very old unsigned-with-chain-ID transactions could theoretically be replayed. EIP-3788 proposed closing this loophole by rejecting transactions where the derived chain ID is 0, but it has not gained implementation momentum.

Chain ID Spoofing in Wallets

When a wallet adds a new chain via wallet_addEthereumChain, it relies on the provided RPC endpoint returning the correct chain ID. A malicious RPC could serve a different chain's data while claiming to be a trusted network. Wallets mitigate this by verifying that the eth_chainId response matches the declared chain ID, but users should still verify RPC endpoints from trusted sources.

Multi-Chain Complexity

With hundreds of EVM-compatible chains, each with its own chain ID, users face increasing complexity. Sending tokens to the right address on the wrong chain is a common mistake. Chain abstraction protocols aim to hide this complexity, but the underlying chain ID infrastructure remains essential for security.

Chain IDs in Context

Chain IDs are one piece of a broader set of network differentiation mechanisms across blockchains. For a deeper look at how transaction replay works and how different protocols defend against it, see the glossary entries on replay attacks and anti-replay protection. For context on how layer-2 networks like Spark handle network identification and asset movement across chains, see the research article on Spark as a Bitcoin layer 2.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.