Skip to content
Open
1 change: 1 addition & 0 deletions src/components/HomePage.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,7 @@ const navigation = [
['Name Wrapper', '/wrapper/overview'],
['Subgraph', '/web/subgraph'],
['Sign In With Ethereum (SIWE)', '/web/siwe'],
['ENSv2 Readiness', '/web/ensv2-readiness'],
],
},
]
Expand Down
73 changes: 73 additions & 0 deletions src/pages/web/ensv2-readiness.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
# 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](/web/libraries). At the time of writing, not all libraries have added ENSv2 support yet. Here's the current status:

- [viem >= v2.35.0](https://github.com/wevm/viem/blob/main/src/CHANGELOG.md#2350)
- ethers.js: Not published yet. [Work in progress on v6.16.0](https://github.com/ethers-io/ethers.js/tree/wip-v6.16.0-ens)
- web3.js: Deprecated

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:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make it more clear that usually people don't need to read further


## Universal Resolver

The [Universal Resolver](/resolvers/universal) 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](https://eth.blockscout.com/address/0xeEeEEEeE14D718C2B47D9923Deab1335E144EeEe) that acts as the canonical entry point. This resolver can be updated in the future if needed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Even though ENSv2 supports multi-chain, all resolution starts on Ethereum Mainnet. ENS deployed a [new Universal Resolver](https://eth.blockscout.com/address/0xeEeEEEeE14D718C2B47D9923Deab1335E144EeEe) that acts as the canonical entry point. This resolver can be updated in the future if needed.

The reason the 0xeEeEE... version is a proxy contract controlled by the DAO is to hopefully never require an update again, so we probably shouldn't say this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My intention was to explain exactly this: That this is a proxy contract that will be updated (not redeployed) for ENSv2. Maybe this can be more explicit like:

"ENS deployed a new Universal Resolver that acts as the canonical entry point. This is a proxy contract, so this address won't change in the future if the implementation is changed."


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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is important to re-emphasize that they need to update to the latest universal resolver.


Learn more about the [Universal Resolver here](/resolvers/universal) and about the [resolution process in general here](/resolution).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Learn more about the [Universal Resolver here](/resolvers/universal) and about the [resolution process in general here](/resolution).

Explained above


### 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)](/learn/ccip-read). 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](/resolvers/ccip-read).

### 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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add some examples: emoji, ...


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

```js
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`

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also add emoji name example

Learn more about [DNS integration here](/learn/dns).
4 changes: 4 additions & 0 deletions vocs.config.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -161,6 +161,10 @@ export default defineConfig({
text: 'Tools and Libraries',
link: '/web/libraries',
},
{
text: 'ENSv2 Readiness',
link: '/web/ensv2-readiness',
},
{
text: 'Web & Querying',
items: [
Expand Down