ENS Resolver Setup in dApps with viem and wagmi: Step-by-Step Integration

A user enters vitalik.eth in the address field, but the application cannot resolve it — familiar? An ENS resolver solves this, but its setup requires attention to detail: name normalization, RPC caching, and handling missing reverse records. We configure ENS resolver turnkey using the modern viem/wagmi stack. With 5+ years in web3 and over a dozen dApps integrated with ENS, we guarantee stable operation. Contact us to integrate an ENS resolver into your dApp.

What Problems We Solve

Invalid ENS names. Users might input vItalik.eth or sub.vitalik.eth with Unicode characters. Without normalization (UTS-46), these names either fail to resolve or return the wrong address. We apply normalize() from viem/ens on every input.

Reverse lookup without reverse record. If the address owner hasn't set a reverse record, useEnsName returns null. The interface then shows an empty name instead of the address. We implement a fallback: display a truncated address (0x12...34) and prompt the user to register an ENS name.

Gas costs and latency. Each mainnet RPC request costs around 5000 gas and takes 2–5 seconds. Without caching, the dApp can lag. Wagmi automatically caches results via React Query, but we additionally configure TTL and retry for stability.

How Our ENS Resolver Works

ENS is a decentralized name system on Ethereum mainnet. Resolution occurs through the ENS Registry contract. In the dApp, we use ready-made hooks useEnsAddress (forward) and useEnsName (reverse) from wagmi v2:

import { useEnsAddress, useEnsName, useEnsAvatar } from 'wagmi';

// Forward: name → address
const { data: address } = useEnsAddress({
  name: 'vitalik.eth',
  chainId: 1, // only mainnet
});

// 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). For cross-chain resolution, solutions based on EIP-3668 (CCIP-Read) are available, which we implement for multi-chain dApps.

Step-by-Step Integration

1. Install libraries. Add wagmi and viem via npm or yarn.
2. Configure client. Set up Wagmi config with a mainnet provider.
3. Implement hooks. Replace address input fields with components using useEnsAddress and useEnsName.
4. Normalize input. Always apply normalize() from viem/ens before any request.
5. Configure caching. Specify staleTime and gcTime in wagmi hook options for optimal RPC usage.
6. Add fallback. If reverse lookup returns null, display a truncated address and a button to set an ENS name.

Why Normalize ENS Names?

normalize() from viem/ens converts the string to UTS-46 standard, correcting case and Unicode characters. Without it, names like vItAlik.eth may return a different address or throw an exception. Also check length: maximum ENS name length is 128 bytes encoded.

Comparison: viem vs ethers.js for ENS

viem wins on performance and convenience — for new projects we recommend this stack.

What’s Included in the Work

Included: codebase (TypeScript), API documentation, test instructions, initial monitoring setup (Tenderly). Support for 1 month after delivery. Pricing is calculated individually. Get a consultation for your project.

Typical Mistakes and How to Avoid Them

• Forgot normalize() — names with Unicode characters crash. Solution: always apply viem/ens normalize.
• No timeout configured — a mainnet request can hang for 30+ seconds. Solution: publicClient.getEnsAddress({ ... }) with timeout: 10000.
• Ignoring subdomains — vitalik.eth works but sub.vitalik.eth doesn’t. Solution: validate via normalize() and use getEnsAddress with the full structure.
• Reverse without fallback — empty interface instead of address. Solution: always show a truncated address when ENS is missing.

Why Choose Our Approach?

We have integrated ENS into 12 dApps for DeFi and NFT projects. We use formal contract verification (Slither + Mythril) and gas optimization. We guarantee the resolver won’t block UX — response time under 3 seconds with a stable RPC. Contact us for ENS resolver integration into your dApp — reach out for a consultation.

Ethereum Name Service