ENS Resolver dApp Setup
ENS (Ethereum Name Service)—DNS-like naming system for Ethereum. Resolving vitalik.eth → 0xd8dA6BF... works via on-chain lookup in ENS Registry contract. In most dApps needed in two places: in address input fields (user types .eth name instead of hex) and when displaying addresses—reverse lookup turns 0xd8dA... into readable name.
Resolving via viem / wagmi
Modern stack with wagmi v2 and viem provides ready hooks:
import { useEnsAddress, useEnsName, useEnsAvatar } from 'wagmi';
// Forward: name → address
const { data: address } = useEnsAddress({
name: 'vitalik.eth',
chainId: 1, // mainnet only
});
// Reverse: address → name
const { data: ensName } = useEnsName({
address: '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045',
chainId: 1,
});
// Avatar
const { data: avatar } = useEnsAvatar({
name: 'vitalik.eth',
chainId: 1,
});
ENS works only on Ethereum mainnet (and Sepolia for testing). Chain ID 137 (Polygon) or other EVM chains—not natively supported, though cross-chain ENS resolvers exist in development (EIP-3668, CCIP-Read).
Real-Time Input Validation
Standard UX pattern for address field:
const resolveInput = async (input: string) => {
if (input.endsWith('.eth')) {
const address = await publicClient.getEnsAddress({ name: normalize(input) });
if (!address) throw new Error('ENS name not found');
return address;
}
if (isAddress(input)) return input;
throw new Error('Invalid address or ENS name');
};
normalize() from viem/ens handles Unicode normalization per UTS-46 standard—without it, names with non-standard characters may resolve incorrectly or throw entirely.
Caching
ENS queries hit Ethereum mainnet RPC and take time. Cache results in memory with ~1 hour TTL—ENS records change rarely. wagmi does this automatically via internal query cache (React Query under the hood). For custom implementation, simple Map with timestamps or SWR with appropriate dedupingInterval suffices.







