ENS Integration Guide for Wallets

Implement the full resolution path from user input to onchain address. Normalize the input string using ENSIP-15, namehash the domain, call the Registry to find the Resolver, and query addr(bytes32) for the EVM address. Handle multi-coin types by calling addr(bytes32,uint256) with SLIP-44 coin types for BTC, SOL, and other chains. Always verify the returned address is not zero before populating the send flow. Teams must handle invalid names, unregistered domains, and resolver timeouts gracefully without blocking the transaction UI.

Map user addresses back to primary ENS names for contact lists, transaction history, and confirmation screens. Call addr.reverse with the target address to get the reverse node, then resolve the name(bytes32) record on that node's resolver. Validate that the returned name forward-resolves back to the original address to prevent spoofing. Implement caching with a TTL derived from resolver records to avoid excessive RPC calls. This workflow is essential for replacing raw hex addresses with human-readable identifiers across all wallet surfaces.

Support resolution of addresses across EVM and non-EVM chains for wallets that manage multiple assets. Use the addr(bytes32,uint256) interface with SLIP-44 coin types to resolve BTC (0), SOL (501), LTC (2), and other chain-specific addresses. For L2 networks, handle CCIP-Read (EIP-3668) callbacks when the resolver returns offchain lookup signals. Display resolved addresses in chain-specific formats and warn users when a name has no address for their selected network. This workflow is critical for wallets positioning as multi-chain hubs.

Resolve and display ENS profile data including avatar images, email addresses, and social handles. Query the text(bytes32,string) interface for standard keys like 'avatar', 'email', 'url', 'com.twitter', and 'com.github'. For avatars, handle both direct image URLs and EIP-1559 NFT references by parsing the eip155: scheme, resolving the contract address and token ID, and fetching metadata from the NFT contract. Implement image sanitization to prevent SVG-based XSS and enforce size limits. Cache resolved metadata aggressively to avoid repeated gateway calls.

Prevent homograph attacks and UI confusion by normalizing all user input with ENSIP-15 before resolution. Strip zero-width characters, normalize Unicode confusables, and reject mixed-script names that could impersonate trusted addresses. When displaying ENS names, use the normalized form and consider highlighting potentially confusing characters. For send flows, always show both the ENS name and the resolved address in confirmation screens. Implement a warning system for names with recently changed resolver records or addresses to protect against front-running attacks.

Handle ENS names stored on L2s or offchain databases by implementing EIP-3668 callback support. When a resolver reverts with OffchainLookup, parse the gateway URL and sender data, make an HTTPS POST to the gateway, and submit the signed response back to the resolver via callback. Implement timeout handling (default 30 seconds), response size limits, and nested CCIP-Read support for names that chain multiple offchain lookups. Monitor gateway availability and latency to avoid blocking user flows. This is mandatory for wallets supporting L2-native names and subname registrars.

Start with the official ENS documentation for resolver concepts, registry interactions, name ownership, reverse records, and profile data. Wallet teams should use it to confirm the expected resolution sequence: normalize the input name, compute the namehash, query the ENS registry for the resolver, call the relevant resolver interface, and handle missing records or resolver failures without silently substituting unsafe values.

The ENSIPs repository is the canonical source for ENS-specific standards such as normalization, resolver behavior, wildcard resolution, profile records, and integration conventions. Wallet teams should review relevant ENSIPs when implementing name display, subname handling, avatar/profile rendering, and resolver edge cases because ENS behavior is not fully captured by Ethereum EIPs alone.

EIP-137 defines the core ENS model: human-readable names, namehashing, the registry, resolvers, and ownership records. Wallets should treat this as the base reference for forward resolution and should avoid shortcut implementations that assume a single resolver, a fixed TLD, or only .eth names. Correct namehashing and registry lookup are prerequisites for every safe send-flow integration.

EIP-181 defines reverse resolution, which maps an address back to a primary ENS name under the addr.reverse namespace. Wallets using ENS names as display labels should verify that the returned name resolves back to the same address before showing it as trusted identity context. This prevents misleading labels where an address claims an ENS name that does not actually point back to that address.

EIP-2304 defines coin-type address records for ENS, enabling names to resolve to assets beyond Ethereum, including Bitcoin and other chain-specific address formats. Wallets should not assume the Ethereum addr() record applies to every send flow. For multi-chain wallets, coin type selection, address decoding, checksum validation, and UI labeling must match the destination network before a transaction is constructed.

EIP-3668 defines CCIP-Read, the standard used by resolvers to fetch offchain data through gateway URLs and verify it through callback logic. Wallets that resolve ENS names should expect some records to require offchain lookup, including L2 or gasless subname systems. Implement timeout handling, gateway error reporting, nested lookup limits, and a clear distinction between unavailable resolution and a confirmed empty record.