{"id":"ERC-137","name":"Ethereum Name Service (ENS)","status":"Final","chain":"ethereum","category":{"id":"comprehension","name":"Comprehension & Display","description":"Making blockchain data readable to humans"},"journeyStages":[{"id":"authentication","name":"Authentication & Identity","description":"Proving who you are and logging in"},{"id":"asset-display","name":"Asset Discovery & Display","description":"Seeing tokens, NFTs, and balances"}],"uxImpact":"ERC-137 defines the ENS registry and resolver model for looking up records such as an address for a registered name. A compatible client can resolve a name like alice.eth and show the resulting address, but registration, ownership, resolver support, network scope, and client display remain separate checks. A name does not make typos obvious or prove identity by itself.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-137","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-137","summary":"ERC-137 defines the ENS registry and resolver model for looking up records such as an address for a registered name. A compatible client can resolve a name like alice.eth and show the resulting address, but registration, ownership, resolver support, network scope, and client display remain separate checks. A name does not make typos obvious or prove identity by itself.","applicability":{"whenToUse":["Users enter supported ENS names or inspect names alongside addresses.","Your product can resolve names on the intended network and verify reverse-to-forward matches."],"whenToAvoid":["The selected chain or resolver cannot provide the required record.","A reverse name fails forward verification; display the original address instead."]},"designerTakeaways":["Accept a supported ENS name alongside a raw address and show the resolved destination before signing.","Treat ENS display as a resolver result, not as proof of identity or typo safety.","Display a .eth name only when the selected client and network support resolution and the address binding is verified."],"problemsSolved":[{"problem":"Addresses are unreadable hex strings","oldWay":"Copy-paste \"0x7a3d8f2c9e1b4a5c6d7e8f9a0b1c2d3e4f5a6b7c\"","newWay":"A compatible resolver can turn a registered name into an address for user review","impact":"critical"},{"problem":"Long addresses are difficult to review","oldWay":"Users compare or copy a hexadecimal address with limited context","newWay":"A supported name can provide a readable label while the app still shows and verifies the resolved address","impact":"critical"},{"problem":"No portable identity across dApps","oldWay":"Different username on every platform","newWay":"A .eth name resolves in supported clients and networks; verify the address binding before display","impact":"high"}],"uxPatterns":[{"name":"ENS Input Field","description":"Accept both ENS names and addresses","userFlow":["User types ENS name","App resolves to address","Shows resolved address","Validates on correct network","User confirms and continues"]},{"name":"Profile with ENS","description":"Display user identity with ENS details","userFlow":["User views address","App does reverse lookup","Fetch candidate reverse name and forward-resolve it on the intended network","Require the forward result to equal the original address before loading name-linked identity details; otherwise display the address","Displays complete profile"]}],"uiComponents":[{"name":"ENSInput","description":"Input that accepts and resolves ENS names","states":["empty","typing","resolving","resolved","invalid"],"props":["value","resolvedAddress","onResolve"]},{"name":"ENSAvatar","description":"Displays ENS avatar or generates placeholder","states":["loading","loaded","fallback"],"props":["ensName","address","size"]},{"name":"AddressDisplay","description":"Shows address with ENS when available","states":["address-only","with-ens","loading"],"props":["address","ensName","truncate"]}],"antiPatterns":[{"pattern":"Only accepting raw addresses","why":"Users forced to copy long hex strings","instead":"Accept both ENS names and addresses","severity":"high"},{"pattern":"Not showing resolved address","why":"User can't verify where funds will go","instead":"Show the resolved address alongside a displayed name","severity":"critical"},{"pattern":"Displaying addresses without ENS lookup","why":"User sees hex when human name exists","instead":"Reverse-resolve, then require a forward match to the original address before displaying the name; otherwise show the address","severity":"medium"},{"pattern":"Not checking resolution network","why":"ENS name might resolve differently on L2","instead":"Verify resolution on intended network","severity":"high"}],"keyTakeaways":["ENS = human-readable .eth names","Accept both ENS names and addresses in inputs","Show the resolved address alongside a displayed name","Only display a reverse name after forward resolution matches the original address","Verify resolution on the correct network"],"technicalNotes":"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. A reverse record is address-owner-controlled. Use an ENS resolver/library that verifies the forward match before treating a name as a primary identity. A missing or mismatched record must fall back to the original address, not a spoofed name with a warning.","lastUpdated":"2026-09-18","lastReviewed":"2026-09-18","specConstraints":[{"id":"ens-name-normalization","constraint":"ENS names use dot-separated labels normalized under UTS46 with transitional processing disabled and STD3 ASCII rules enabled.","appliesTo":"application","normativity":"normative","specQuote":"In short, names consist of a series of dot-separated labels. Each label must be a valid normalised label as described in [UTS46](https://unicode.org/reports/tr46/) with the options `transitional=false` and `useSTD3AsciiRules=true`. For Javascript implementations, a [library](https://www.npmjs.com/package/idna-uts46) is available that normalises and checks names.","specSection":"Specification — Name Syntax","specUrl":"https://ercs.ethereum.org/ERCS/erc-137#name-syntax","designImplication":"Normalize and validate names before display or lookup, and show the canonical form when the user entered an equivalent spelling."},{"id":"ens-zero-address-safety","constraint":"Clients must treat a zero address from an `addr` lookup as unresolved and refuse to send funds or interact with it.","appliesTo":"application","normativity":"normative","specQuote":"Clients resolving the `addr` record MUST check for a zero return value, and treat this in the same manner as a name that does not have a resolver specified - that is, refuse to send funds to or interact with the address. Failure to do this can result in users accidentally sending funds to the 0 address.","specSection":"Specification — Resolver specification — Contract Address Interface","specUrl":"https://ercs.ethereum.org/ERCS/erc-137#contract-address-interface","designImplication":"Block send and contract-interaction actions when resolution returns the zero address. Show the name as unresolved rather than as a valid destination."},{"id":"ens-name-input-guidance","constraint":"ENS labels and full names should stay within legacy DNS-compatible length and character guidance.","appliesTo":"application","normativity":"normative","specQuote":"Labels and domains may be of any length, but for compatibility with legacy DNS, it is recommended that labels be restricted to no more than 64 characters each, and complete ENS names to no more than 255 characters. For the same reason, it is recommended that labels do not start or end with hyphens, or start with digits.","specSection":"Specification — Name Syntax","specUrl":"https://ercs.ethereum.org/ERCS/erc-137#name-syntax","designImplication":"Use a soft compatibility warning for unusually long labels or DNS-incompatible starts and endings. Do not present these lowercase recommendations as protocol rejection rules."}],"sources":[{"label":"ERC-137 official specification","url":"https://ercs.ethereum.org/ERCS/erc-137","type":"official-spec"}]},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-137","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-137","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-137","markdown":"https://www.eipsfordesigners.com/standards/ERC-137/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-137/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-137","official":"https://ercs.ethereum.org/ERCS/erc-137","discussion":"https://ethereum-magicians.org/search?q=ERC-137"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}