Correctly Resolve All Names For ENSv2

ENS is upgrading to ENSv2 and the way ENS names get resolved is changing. Apps that don't upgrade their ENS resolution logic before ENSv2 launches will quietly start giving people the wrong names and addresses as soon as ENSv2 launches — a silent failure that would erode user trust and could even send funds to the wrong place.

This best practice checks that your app will keep resolving every ENS name correctly through the ENSv2 transition, with no disruption for your users.

The simplest way to get this right—and to continuously and automatically fetch data from ENS correctly even as ENS keeps evolving— is to use the ENS Omnigraph API (powered by ENSNode) which handles ENSv2-ready resolution for you. The implementation recommendations below cover how your engineering team can adopt it, or other supported options.

There are a few ways to make sure your app's ENS resolution is ENSv2-ready. Options below are ordered from the easiest to the most hands-on. Use the first option that fits your stack.

1. Use the ENS Omnigraph API (recommended).

Fetch your ENS data through the ENS Omnigraph API (powered by ENSNode) and ENSv2-ready resolution just works — no RPCs or contracts to track, no upgrades to chase. It's a single typed GraphQL API over both ENSv1 and ENSv2 for every chain and offchain names too. It also handles the indexed ENS data your app reads (e.g. the names an address owns, profiles, histories, etc.), with resolutions accelerated by Protocol Acceleration. Drop it in with enssdk (TypeScript) or enskit (React).

2. Using viem or wagmi? Update your version.

If you resolve names using ENS helper functions from viem or wagmi and aren't ready to adopt the Omnigraph yet, make sure you're on viem (v2.35.0+). On wagmi, pin the viem version yourself — wagmi accepts any viem 2.x, so upgrading wagmi alone won't get you there.

3. Writing raw RPC calls yourself?

If your app makes its own low-level RPC calls instead of using the Omnigraph or a helper library like viem, point your resolution RPC calls at ENS's new stable Universal Resolver proxy (0xeeeeeeee14d718c2b47d9923deab1335e144eeee) rather than hardcoding a specific Universal Resolver implementation. Because ENS controls the proxy, it transparently upgrades to the ENSv2-compatible implementation when ENSv2 launches, so apps pointed at it stay correct with no code changes. For additional guidance, see the ENSv2 readiness guide.