Skip to content

Preparing for ENSv2

Everything you need to know to prepare your application for ENSv2.

ENSv2 brings multi-chain support and improved architecture to ENS. While names can still be stored on Ethereum Mainnet, ENSv2 introduces Namechain as the primary Layer 2 for ENS, with support for additional L2s as well. To ensure your application works seamlessly with ENSv2, you'll need to make a few key updates.

The good news? For most applications, preparing for ENSv2 is as simple as updating to the latest version of a supported library. At the time of writing, not all libraries have added ENSv2 support yet. Here's the current status:

If you're using a supported library, it should handle everything automatically. The sections below explain what's happening under the hood and how to test that your integration is working correctly:

Universal Resolver

The Universal Resolver is a smart contract on Ethereum Mainnet that simplifies the process of resolving ENS names. It should be treated as the canonical entrypoint to all ENS queries.

Even though ENSv2 supports multi-chain, all resolution starts on Ethereum Mainnet. ENS deployed a new Universal Resolver that acts as the canonical entry point. This resolver can be updated in the future if needed.

Your application needs to use this new Universal Resolver. As mentioned above, updating to the latest version of your library should handle this automatically.

Learn more about the Universal Resolver here and about the resolution process in general here.

Testing Universal Resolver Support

To test if your integration uses the Universal Resolver, try resolving the address for ur.gtest.eth. It should return 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE. If it instead returns 0x1111111111111111111111111111111111111111, you likely need to update your web3 library.

CCIP Read

ENSv1 already supports delegating resolution from Ethereum Mainnet to an L2 or completely offchain using CCIP Read (ERC-3668). All the libraries mentioned above implement CCIP Read. However, not all integrations handle it properly.

With ENSv2, you can store names on Ethereum Mainnet, Namechain, or any other supported L2. This makes CCIP Read support essential for your integration to work correctly.

Learn more about CCIP-Read, Offchain and L2 resolvers here.

Testing CCIP Read Support

To test if your integration properly implements CCIP Read, try resolving test.offchaindemo.eth. It should return the address 0x779981590E7Ccc0CFAe8040Ce7151324747cDb97.

DNS Resolution

ENS supports importing DNS names into ENS, allowing traditional domain names to work alongside .eth names. It's important that your application correctly also detects DNS names to avoid false positives.

Common Mistake: Only Matching .eth

Many integrations only treat .eth domains as ENS names like this:

if (input.endsWith('.eth') {
  // ...
}
 
This is **incorrect** because it excludes DNS names imported into ENS (like `ensfairy.xyz`).
 
### Correct Pattern: Match All Valid Domains
 
Instead, your integration should treat any dot-separated string with as a potential ENS name. For example, `a.co` should be treated as a potential ENS name.
 
```js
if (input.includes('.') && input.length > 2) {
   // ...
}
 
:::info
Note that inputs should always be [normalized](/resolution/names).
:::
 
This pattern correctly matches:
 
- `.eth` names like `vitalik.eth`
- DNS names like `ensfairy.xyz`
- Subdomains like `ses.fkey.id`
 
Learn more about [DNS integration here](/learn/dns).