# ERC-1191: Chain-specific Address Checksum

Source: https://www.eipsfordesigners.com/standards/ERC-1191
Agent brief: https://www.eipsfordesigners.com/standards/ERC-1191/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-1191
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Last Call |
| Chain | both |
| Category | Comprehension & Display |
| Journey stages | Status & Confirmation |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-1191 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-1191 |

## UX Impact

Use chain-aware checksums only on networks that adopt ERC-1191, and preserve ERC-55 elsewhere. Show the selected network explicitly. A mismatch is a validation warning, not proof of a different destination chain, and the checksum does not guarantee protection from wrong-network transfers.

## Summary

ERC-1191 is an opt-in variant of the ERC-55 address checksum that incorporates chain ID on adopting networks. It can catch some address-entry mistakes there. Ethereum and networks that have not adopted the variant continue to use ERC-55. A checksum does not identify the intended destination chain or replace explicit network selection.

## For Designers

- Choose the checksum rule supported by the selected network.
- Treat a mismatch as a validation warning, not proof of another chain.
- Keep the network name, recipient address and send review visible.

## Applicability

### When to Use

- The selected network is confirmed to adopt ERC-1191.
- Your product validates or displays addresses using that network’s checksum policy.

### When to Avoid

- The network uses ERC-55; preserve that checksum rule.
- You need to infer a unique destination chain from an address checksum.

## Problems It Solves

### An adopting network needs a checksum bound to its chain ID

Impact: high

Old way: Use an unqualified checksum rule for every network

New way: Use ERC-1191 only on verified adopting networks and ERC-55 elsewhere

### Users may mistake a checksum match for network verification

Impact: high

Old way: Infer a destination network from letter case

New way: Ask users to verify the selected network separately

## Anti-Patterns

### Applying ERC-1191 to every EVM chain

Severity: high

Most address integrations use ERC-55 unless the network adopts the variant

Instead: Maintain an explicit network checksum policy and preserve ERC-55 elsewhere

### Inferring a destination network from a checksum

Severity: high

A mismatch does not uniquely identify another chain

Instead: Show the selected network and ask the user to verify it

### Silently changing a pasted checksum

Severity: medium

Recasing can hide an input mistake from the sender

Instead: Explain the mismatch and ask the user to verify the address and selected network

## UI Components

### NetworkAddressInput

Validates using a known network checksum policy.
States: empty, valid, mismatch, unsupported-policy
Props: chainId, checksumPolicy, address, onChange

## UX Patterns

### Network-aware address review

Use the checksum policy of the selected network.

User flow:

- Select and label the destination network
- Look up whether that network adopts ERC-1191
- Validate with that rule, or ERC-55 for other networks
- Show a mismatch without guessing the intended chain
- Confirm the recipient and network before sending

## Related Standards

- ERC-55: ERC-55 is the base checksum standard, ERC-1191 extends it with chain ID

- EIP-155: EIP-155 introduced chain ID concept that ERC-1191 uses in checksums

- EIP-695: eth_chainId provides the chain ID used for checksum calculation

## Technical Notes

The ERC-1191 reference implementation includes chain ID in the checksum hash only for opted-in networks and otherwise uses ERC-55. The reference adopting-network list must not be interpreted as every EVM chain. Validate against the selected network policy rather than trying to infer a chain from a checksum.