# EIP-155: Simple Replay Protection

Source: https://www.eipsfordesigners.com/standards/EIP-155
Agent brief: https://www.eipsfordesigners.com/standards/EIP-155/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-155
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Security & Trust |
| Journey stages | Status & Confirmation |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-155 |
| Discussion search | https://ethereum-magicians.org/search?q=EIP-155 |

## UX Impact

Transactions include chain ID preventing replay across networks — signing on Ethereum won't accidentally work on Polygon. Design implications: show network badge prominently during signing, warn if signing for unexpected chain, auto-detect chain mismatches between wallet and dApp. Design decisions: whether to block cross-chain mistakes entirely or allow with confirmation — power users want flexibility, novices need protection.

## Summary

EIP-155 prevents replay attacks by including the chain ID in transaction signatures. Before this, a transaction signed on Ethereum mainnet could be "replayed" on Ethereum Classic (or any fork) to steal funds. Now every signature is bound to a specific chain, protecting users when networks fork or when using multiple chains.

## For Designers

- You can design UI that delivers signature includes chain ID, invalid on other chains.
- You can each chain has unique ID, signatures are chain-specific in the interface.
- You can design UI that delivers same address.

## Applicability

### When to Use

- Your product addresses: transactions could be replayed across chains.
- Your product addresses: network forks created security risks.
- The flow should deliver: signature includes chain ID, invalid on other chains.
- You are designing a network indicator in transaction experience with visible states and recovery paths.

### When to Avoid

- Always show network name AND chain ID in transaction confirmations.
- Always confirm network switches before signing.
- Show both name and numeric chain ID.
- Wrong-address or approval mistakes are not recoverable in your product context.

## Problems It Solves

### Transactions could be replayed across chains

Impact: critical

Old way: Sign a transaction on mainnet, attacker replays it on Classic to drain the same address

New way: Signature includes chain ID, invalid on other chains

### Network forks created security risks

Impact: critical

Old way: Every fork meant potential replay attacks on both chains

New way: Each chain has unique ID, signatures are chain-specific

### Users couldn't safely use multiple EVM chains

Impact: high

Old way: Using same address on multiple chains was risky

New way: Same address, different chain IDs, transactions isolated

### No way to verify which chain a transaction was meant for

Impact: medium

Old way: Wallet showed transaction but not target network

New way: Chain ID in signature proves intended network

## Anti-Patterns

### Hiding chain ID from users

Severity: critical

Users can't verify they're signing for the right network

Instead: Always show network name AND chain ID in transaction confirmations

### Auto-switching networks without confirmation

Severity: high

User might accidentally transact on wrong chain

Instead: Always confirm network switches before signing

### Using only chain name without ID

Severity: high

Fake networks could use same name as real ones

Instead: Show both name and numeric chain ID

### No indication of replay protection

Severity: medium

Users don't know their transaction is protected

Instead: Show "Protected on [Network]" badge

## UI Components

### ChainIdBadge

Visual indicator of chain ID with network name
States: mainnet, testnet, l2, unknown
Props: chainId, chainName, icon, color

### NetworkMismatchAlert

Warning when requested chain differs from connected
States: mismatch, matched, switching
Props: requestedChain, connectedChain, onSwitch, onCancel

### TransactionChainContext

Shows chain context for a transaction
States: pending, confirmed, failed
Props: chainId, txHash, explorerUrl

## On Monad

### Monad Chain ID

Ethereum: Chain ID 1 for mainnet

Monad: Monad has its own unique chain ID

Design implication: Display "Monad" name with chain ID in all transaction confirmations

### Cross-Chain Operations

Ethereum: Each chain requires separate transactions

Monad: Same requirement, but faster confirmation

Design implication: Show chain context even more prominently in fast-finality environment

## UX Patterns

### Network Indicator in Transaction

Always show which network a transaction is being signed for

User flow:

- User initiates transaction
- Wallet shows network prominently
- Chain ID displayed for verification
- User confirms on correct network
- Transaction signed with chain ID embedded

Mockup registry key: `concept/verify-safety` (React UI on the live standard page).

### Wrong Network Warning

Alert when user tries to sign for unexpected chain

User flow:

- DApp requests transaction for specific chain
- Wallet detects mismatch with connected chain
- Warning modal shown before signing
- User can switch networks or cancel
- Prevents accidental wrong-chain transactions

Mockup registry key: `concept/verify-safety` (React UI on the live standard page).

### Multi-Chain Transaction History

Show chain context for all historical transactions

User flow:

- User opens transaction history
- Each transaction shows its chain
- Chain ID visible for verification
- Clear which network each tx occurred on

Mockup registry key: `concept/verify-safety` (React UI on the live standard page).

## Related Standards

- EIP-695: EIP-695 provides the RPC method to query chain ID that EIP-155 introduced

- EIP-1344: EIP-1344 adds chain ID opcode so smart contracts can also verify chain

- EIP-1191: EIP-1191 extends checksums to include chain ID for address validation

- EIP-2718: Typed transactions include chain ID in the envelope structure