{"id":"EIP-155","name":"Replay-Protected Transaction Signing","status":"Final","chain":"both","category":{"id":"security","name":"Security & Trust","description":"Helping users verify, control, and protect their assets"},"journeyStages":[{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"EIP-155 adds chain ID to the replay-protected transaction signing path, while preserving the legacy six-field v=27/28 signature path for compatibility. Show the wallet's actual target chain and transaction envelope; a chain ID does not make every signature universally chain-bound.","officialUrl":"https://eips.ethereum.org/EIPS/eip-155","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-155","summary":"EIP-155 adds chain ID to the replay-protected transaction signing path, while preserving the legacy six-field v=27/28 signature path for compatibility. Show the wallet's actual target chain and transaction envelope; a chain ID does not make every signature universally chain-bound.","applicability":{"whenToUse":["The transaction path uses the EIP-155 replay-protected signing fields and the wallet can show target chain ID.","The product needs to explain legacy six-field v=27/28 compatibility separately.","The UI can show numeric chain ID and human-readable network as distinct context."],"whenToAvoid":["The transaction path uses legacy six-field signing and the UI cannot surface that compatibility case.","The app cannot confirm the target chain's numeric ID alongside its human-readable name.","The operation needs an application-level replay policy beyond transaction-envelope protection."]},"designerTakeaways":["Show clear target-network context before signing; make the numeric chain ID available where it helps verify unfamiliar or custom networks.","Explain when a transaction uses the EIP-155 chain-bound path and preserve a compatibility state for legacy signing.","Treat chain ID as transaction-envelope context, not as a proof that the displayed network name is correct."],"problemsSolved":[{"problem":"Transactions could be replayed across chains","oldWay":"Sign a transaction on mainnet, attacker replays it on Classic to drain the same address","newWay":"EIP-155 transactions can include chain ID so that replay-protected signatures target a specific chain","impact":"critical"},{"problem":"Network forks created security risks","oldWay":"A signature without chain binding could be replayed on another compatible chain","newWay":"The chain-bound path reduces replay across forks, while legacy six-field signatures remain a compatibility case","impact":"critical"},{"problem":"Users couldn't safely use multiple EVM chains","oldWay":"Using same address on multiple chains was risky","newWay":"The same address can be used across chains when the transaction envelope and application checks identify the target chain","impact":"high"},{"problem":"No way to verify which chain a transaction was meant for","oldWay":"Wallet showed transaction but not target network","newWay":"The wallet can show chain ID and envelope type so users can review the target network","impact":"medium"}],"uxPatterns":[{"name":"Network Indicator in Transaction","description":"Always show which network a transaction is being signed for","userFlow":["User initiates transaction","Wallet shows network prominently","Offer numeric chain ID in network details, or inline when the task requires it","When the EIP-155 path is used, the signed envelope carries chain ID; legacy signing remains separate.","Transaction signed with chain ID when the replay-protected path is used."]},{"name":"Wrong Network Warning","description":"Alert when user tries to sign for unexpected chain","userFlow":["DApp requests transaction for specific chain","Wallet detects mismatch with connected chain","Warning modal shown before signing","User can switch networks or cancel","User reviews the target network before signing or cancels"]},{"name":"Multi-Chain Transaction History","description":"Show chain context for all historical transactions","userFlow":["User opens transaction history","Each transaction shows its chain","Make numeric chain ID available in each transaction's network details","Clear which network each tx occurred on"]}],"uiComponents":[{"name":"ChainIdBadge","description":"Visual indicator of chain ID with network name","states":["mainnet","testnet","l2","unknown"],"props":["chainId","chainName","icon","color"]},{"name":"NetworkMismatchAlert","description":"Warning when requested chain differs from connected","states":["mismatch","matched","switching"],"props":["requestedChain","connectedChain","onSwitch","onCancel"]},{"name":"TransactionChainContext","description":"Shows chain context for a transaction","states":["pending","confirmed","failed"],"props":["chainId","txHash","explorerUrl"]}],"antiPatterns":[{"pattern":"Omitting target-network context","why":"Users can confuse otherwise similar transactions on different networks.","instead":"Show the intended network and make its numeric ID accessible when relevant to the task. This is design guidance, not a confirmation layout mandated by EIP-155.","severity":"high"},{"pattern":"Auto-switching networks without confirmation","why":"User might accidentally transact on wrong chain","instead":"Always confirm network switches before signing","severity":"high"},{"pattern":"Treating a chain name or numeric ID as network authentication","why":"An untrusted RPC can report a familiar chain ID and a custom network can reuse a name.","instead":"Validate the configured network and RPC through trusted sources; show numeric IDs as context rather than proof of identity.","severity":"high"},{"pattern":"Presenting replay protection as universal","why":"Legacy v=27/28 signatures remain valid, and chain ID alone does not authenticate a human-readable network name.","instead":"Show the target chain and whether the transaction uses EIP-155 replay-protected fields or the legacy path.","severity":"medium"}],"relatedStandards":[{"id":"EIP-695","relationship":"EIP-695 provides the RPC method to query chain ID that EIP-155 introduced"},{"id":"EIP-1344","relationship":"EIP-1344 adds chain ID opcode so smart contracts can also verify chain"},{"id":"ERC-1191","relationship":"ERC-1191 extends checksums to include chain ID for address validation"},{"id":"EIP-2718","relationship":"EIP-2718 defines a typed envelope with an opaque payload. Individual transaction types specify their chain-ID fields."}],"lastUpdated":"2026-09-18","technicalNotes":"EIP-155 defines a nine-field signing path with chainId, 0, and 0 and v = chainId * 2 + 35 or 36. The specification keeps the existing six-field signing with v = 27 or 28 valid for legacy compatibility. Chain ID identifies the numeric transaction target; application and wallet UI must still show the intended network. Replay protection separates chains with different IDs; chains that reuse an ID need additional operational safeguards.","specConstraints":[{"id":"chain-id-signing","constraint":"When chain ID is available, replay-protected signatures include it in the signed transaction and encode it in `v`.","appliesTo":"wallet","normativity":"normative","specQuote":"If `block.number >= FORK_BLKNUM` and `CHAIN_ID` is available, then when computing the hash of a transaction for the purposes of signing, instead of hashing only six rlp encoded elements `(nonce, gasprice, startgas, to, value, data)`, you **SHOULD** hash nine rlp encoded elements `(nonce, gasprice, startgas, to, value, data, chainid, 0, 0)`.  If you do, then the `v` of the signature **MUST** be set to `{0,1} + CHAIN_ID * 2 + 35` where `{0,1}` is the parity of the `y` value of the curve point for which `r` is the x-value in the secp256k1 signing process.  If you choose to only hash 6 values, then `v` continues to be set to `{0,1} + 27` as previously.","specSection":"Specification","specUrl":"https://eips.ethereum.org/EIPS/eip-155#specification","designImplication":"Show the chain context in transaction signing and treat a chain mismatch as a signing failure, not as a cosmetic network label."}],"sources":[{"label":"EIP-155 official specification","url":"https://eips.ethereum.org/EIPS/eip-155","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-155","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-155","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-155","markdown":"https://www.eipsfordesigners.com/standards/EIP-155/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-155/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-155","official":"https://eips.ethereum.org/EIPS/eip-155","discussion":"https://ethereum-magicians.org/search?q=EIP-155"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}