{"id":"EIP-2124","name":"Fork Identifier","status":"Final","chain":"both","category":{"id":"comprehension","name":"Comprehension & Display","description":"Making blockchain data readable to humans"},"journeyStages":[{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"EIP-2124 defines compact fork identifiers for peer-to-peer node compatibility checks. Nodes cross-validate fork history and the next scheduled fork using the specified rules; different fork IDs can still be compatible while syncing. This is a node diagnostic signal, not an RPC network identity or cryptographic proof of a chain.","officialUrl":"https://eips.ethereum.org/EIPS/eip-2124","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-2124","summary":"EIP-2124 defines compact fork identifiers for peer-to-peer node compatibility checks. Nodes cross-validate fork history and the next scheduled fork using the specified rules; different fork IDs can still be compatible while syncing. This is a node diagnostic signal, not an RPC network identity or cryptographic proof of a chain.","applicability":{"whenToUse":["An operator-facing node dashboard has access to peer compatibility diagnostics.","The node applies the specified fork-history cross-validation rules."],"whenToAvoid":["A wallet or dApp needs RPC network authentication or a chain selector.","Your implementation merely compares raw fork IDs for equality."]},"designerTakeaways":["Expose peer compatibility results in node diagnostics when useful.","Apply the specified history and next-fork rules rather than comparing raw IDs for equality.","Keep node compatibility separate from RPC trust and wallet network selection."],"problemsSolved":[{"problem":"Nodes couldn't quickly verify compatibility","oldWay":"Establish a stream connection and handshake before discovering an incompatible peer","newWay":"Use compact fork-history validation in a supported discovery or handshake protocol","impact":"high"},{"problem":"Network partitions after hard forks","oldWay":"Incompatible nodes stayed connected, causing issues","newWay":"Nodes reject peers only when the specified fork-history validation identifies an incompatibility","impact":"high"},{"problem":"Operators need an early peer-compatibility signal","oldWay":"Incompatibility appears after a peer connection or sync has progressed","newWay":"A node can apply fork-history validation during discovery or handshake","impact":"medium"},{"problem":"Post-fork network confusion","oldWay":"Old nodes confused new nodes and vice versa","newWay":"Reject incompatible fork histories while accounting for syncing peers and known validation limits","impact":"medium"}],"uxPatterns":[{"name":"Node fork diagnostic","description":"Show operators node fork status and compatibility results","userFlow":["Operator checks node status","Current fork ID and client context displayed","Historical fork data shown","Separate network metadata may be shown when sourced elsewhere","Operator understands the diagnostic scope"]},{"name":"Peer compatibility diagnostic","description":"Explain a compatibility result reported by the node client.","userFlow":["A node receives a peer fork identifier during discovery or handshake","The node applies the specified subset, superset and next-fork validation rules","The dashboard shows compatible, incompatible or unknown with the node-provided reason","An operator reviews client configuration or upgrades rather than inferring RPC identity from the checksum"]},{"name":"Upgrade metadata (separate source)","description":"Show an upgrade timeline only when supplied by trusted network metadata, not by EIP-2124","userFlow":["Trusted upgrade metadata is available","Timeline displayed with its source","New features explained from that source","Users can inspect the update context"]}],"uiComponents":[{"name":"ForkIdDisplay","description":"Shows current fork identifier","states":["synced","syncing","outdated"],"props":["forkId","forkName","blockNumber"]},{"name":"UpgradeTimeline","description":"Visual timeline of network upgrades","states":["loading","loaded"],"props":["upgrades[]","currentBlock","onSelect"]},{"name":"CompatibilityCheck","description":"Shows the node client peer-compatibility result, separate from RPC trust","states":["compatible","incompatible","checking"],"props":["localForkId","remoteForkId","onSwitch"]}],"antiPatterns":[{"pattern":"Treating different fork IDs as automatically incompatible","why":"Valid peers can have different known fork histories while syncing","instead":"Display the result of the specified cross-validation and explain its reason","severity":"high"},{"pattern":"Using fork IDs as a wallet upgrade schedule","why":"EIP-2124 does not define a dApp schedule, network selector, or countdown","instead":"Keep node diagnostics separate and source any user-facing timeline from trusted network metadata","severity":"medium"},{"pattern":"Showing raw fork ID without context","why":"0xdce96c2d means nothing to users","instead":"Show fork name (Shanghai) with ID as technical detail","severity":"low"}],"relatedStandards":[{"id":"EIP-155","relationship":"Chain ID identifies the chain, fork ID identifies the fork state"},{"id":"EIP-695","relationship":"eth_chainId returns chain ID, separate from fork ID"}],"specConstraints":[{"id":"fork-cross-validation","constraint":"Fork identifiers must be cross-validated rather than compared for raw equality when assessing peer compatibility.","appliesTo":"infrastructure","normativity":"normative","specQuote":"The *fork identifier* is defined as `RLP([FORK_HASH, FORK_NEXT])`. This `forkid` is cross validated (**NOT** naively compared) to assess a remote chain's compatibility.","specSection":"Specification","specUrl":"https://eips.ethereum.org/EIPS/eip-2124#specification","designImplication":"In an operator diagnostic, show the node's compatibility result and reason instead of labeling peers incompatible solely because their raw fork IDs differ. Keep this signal separate from wallet network identity."},{"id":"fork-id-scope","constraint":"EIP-2124 defines a fork identity scheme, not functional changes to the chain.","appliesTo":"infrastructure","normativity":"backwards-compatibility","specQuote":"This EIP only defines an identity scheme, it does not define functional changes.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/eip-2124#backwards-compatibility","designImplication":"Do not use a fork ID as a wallet upgrade schedule, feature-availability guarantee, or user-facing chain selector without a separate trusted source."}],"lastUpdated":"2026-09-18","technicalNotes":"A fork ID combines a CRC32 fork-history checksum with the next scheduled fork value. The specified validation accepts compatible subset/superset histories and rejects incompatible cases. CRC32 is not authentication, and the proposal does not resolve every three-way-fork ambiguity. EIP-2124 supplies no standard JSON-RPC method for a dApp to authenticate its network; peer diagnostics require node-client data.","lastReviewed":"2026-09-18","sources":[{"label":"EIP-2124 official specification","url":"https://eips.ethereum.org/EIPS/eip-2124","type":"official-spec"}]},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-2124","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-2124","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-2124","markdown":"https://www.eipsfordesigners.com/standards/EIP-2124/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-2124/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-2124","official":"https://eips.ethereum.org/EIPS/eip-2124","discussion":"https://ethereum-magicians.org/search?q=EIP-2124"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}