Setting Up ENS Resolver in dApp with viem and wagmi: Step-by-Step Integration

A user enters vitalik.eth in the address field, and the application can't resolve the name — a familiar situation? The ENS resolver solves this task, but its setup requires attention to detail: name normalization, caching of RPC requests, handling missing reverse records.

We set up the ENS resolver turnkey using the modern viem/wagmi stack. 5+ years of experience in web3, more than a dozen dApps with ENS — we guarantee stable operation. Order the integration of an ENS resolver into your dApp.

What problems we solve

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

Reverse lookup without a reverse record. If the address owner has not set a reverse record, the useEnsName hooks return null. As a result, the interface shows an empty name instead of an address.

We implement a fallback: we display the shortened address (0x12...34) and prompt the user to register an ENS.

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

How does the ENS resolver work?

ENS is a decentralized naming system on Ethereum mainnet. Resolution happens 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, // mainnet only
});

// Reverse: address → name
const { data: ensName } = useEnsName({
  address: '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045',
  chainId: 1,
});

// Avatar
const { data: avatar } = useEnsAvatar({
  name: 'vitalik.eth',
  chainId: 1,
});

ENS only works on Ethereum mainnet (and Sepolia for testing). For cross-chain resolution, there are solutions based on EIP-3668 (CCIP-Read), which we are implementing for multichain dApps.

Step-by-step ENS resolver integration

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

Why is it important to normalize ENS names?

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

Comparing viem and ethers.js for ENS

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

What is included in the ENS resolver setup work

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

Common mistakes and how to avoid them

• Forgot normalize() — names with Unicode characters fail. Solution: always use viem/ens normalize.
• Did not configure a timeout — a request to mainnet can hang for 30+ seconds. Solution: publicClient.getEnsAddress({ ... }) with timeout: 10000.
• Ignoring subdomains — vitalik.eth works, but sub.vitalik.eth does not. Solution: validate the name via normalize() and use getEnsAddress with the full structure.
• Reverse without fallback — an empty interface instead of an address. Solution: always show the shortened address when ENS is absent.

Why choose our approach?

We have implemented ENS in 12 dApps for DeFi and NFT projects. We use formal contract verification (Slither + Mythril) and gas optimization. We guarantee that the resolver will not block UX — response time is less than 3 seconds with a stable RPC. Order ENS resolver integration for your dApp — contact us for a consultation.

Ethereum Name Service