# ERC-137: Ethereum Name Service (ENS)

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

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | ethereum |
| Category | Comprehension & Display |
| Journey stages | Authentication & Identity, Asset Discovery & Display |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-137 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-137 |

## UX Impact

Users can send to 'vitalik.eth' instead of '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045' — memorable names replace error-prone addresses. Design implications: always show ENS names where available, provide autocomplete for .eth names, display both name AND resolved address for verification, show avatar/profile data from ENS records, handle subdomains gracefully. Design decisions: when to show address vs name (trust tradeoff), how to handle unregistered/expired names, whether to require re-resolution before transactions, loading states for async resolution. 910K+ active domains. ENS is a primary solution to Sending to Wrong Address (Critical severity). Showing ENS names alongside addresses is High priority for safety UX.

## Summary

ERC-137 is the Ethereum Name Service (ENS) standard. It turns "0xd8dA6BF26964aF..." into "vitalik.eth". Human-readable names for addresses, just like DNS for the internet. Users can send to "alice.eth" instead of copying 42-character hex strings. It's the foundation of human-readable web3 identity.

## For Designers

- You can design UI that delivers type "alice.eth" or scan ENS name.
- You can design UI that delivers names are memorable, typos are obvious.
- You can design UI that delivers your .eth name works everywhere.

## Applicability

### When to Use

- Your product addresses: addresses are unreadable hex strings.
- Your product addresses: easy to make typos in addresses.
- The flow should deliver: type "alice.eth" or scan ENS name.
- You are designing a ens input field experience with visible states and recovery paths.

### When to Avoid

- Always show the resolved address.
- Accept both ENS names and addresses.
- Verify resolution on intended network.
- Users never see addresses, amounts, or signing payloads in your UI.

## Problems It Solves

### Addresses are unreadable hex strings

Impact: critical

Old way: Copy-paste "0x7a3d8f2c9e1b4a5c6d7e8f9a0b1c2d3e4f5a6b7c"

New way: Type "alice.eth" or scan ENS name

### Easy to make typos in addresses

Impact: critical

Old way: One wrong character = funds lost forever

New way: Names are memorable, typos are obvious

### No portable identity across dApps

Impact: high

Old way: Different username on every platform

New way: Your .eth name works everywhere

## Anti-Patterns

### Not showing resolved address

Severity: critical

User can't verify where funds will go

Instead: Always show the resolved address

### Only accepting raw addresses

Severity: high

Users forced to copy long hex strings

Instead: Accept both ENS names and addresses

### Not checking resolution network

Severity: high

ENS name might resolve differently on L2

Instead: Verify resolution on intended network

### Displaying addresses without ENS lookup

Severity: medium

User sees hex when human name exists

Instead: Do reverse resolution, show name if found

## UI Components

### ENSInput

Input that accepts and resolves ENS names
States: empty, typing, resolving, resolved, invalid
Props: value, resolvedAddress, onResolve

### ENSAvatar

Displays ENS avatar or generates placeholder
States: loading, loaded, fallback
Props: ensName, address, size

### AddressDisplay

Shows address with ENS when available
States: address-only, with-ens, loading
Props: address, ensName, truncate

## On Monad

### ENS Resolution

Ethereum: ENS is native to Ethereum mainnet

Monad: May need cross-chain resolution or Monad native names

Design implication: Check if ENS works or use Monad equivalent

## Key Takeaways

- ENS = human-readable .eth names
- Accept both ENS names and addresses in inputs
- Always show resolved address for verification
- Do reverse lookup to display names instead of hex
- Verify resolution on the correct network

## UX Patterns

### ENS Input Field

Accept both ENS names and addresses

User flow:

- User types ENS name
- App resolves to address
- Shows resolved address
- Validates on correct network
- User confirms and continues

Mockup registry key: `generic/token-transfer` (React UI on the live standard page).

### Profile with ENS

Display user identity with ENS details

User flow:

- User views address
- App does reverse lookup
- Fetches ENS name if exists
- Loads avatar and records
- Displays complete profile

Mockup registry key: `generic/list-selector` (React UI on the live standard page).

## Technical Notes

ERC-137 defines ENS registry with resolver pattern. namehash(name) produces deterministic node ID. Registry maps nodes to owners and resolvers. Resolvers implement addr() for address resolution, text() for records. ERC-181 adds reverse resolution via [address].addr.reverse. CCIP-read enables off-chain and L2 resolution.