ENSv2: what changes for name holders (and what doesn't)

Updated 13 August 2026: the ENS App, ENS Explorer and new ENSv2 registry are now in Public Beta on Ethereum Sepolia. Mainnet timing will follow the results of public testing.

ENSv2 is the largest protocol change in ENS history. It keeps resolution compatible while replacing the flat registry, shared ownership model and optional NameWrapper with hierarchical registries, per-account resolvers and granular roles.

One correction matters because older explainers still circulate: ENSv2 was originally planned for a dedicated L2 called Namechain. ENS Labs cancelled that plan in February 2026. The production protocol is intended for Ethereum mainnet; Sepolia is the current public testing environment.

What is live in the Public Beta

The Beta is a fresh Sepolia deployment. Names created during the earlier Alpha do not appear in the new registry, so Alpha testers start again. The official ENS App and ENS Explorer now support:

• the first public ENSv1-to-ENSv2 upgrade flow for eligible Sepolia names;
• new registration and renewal flows with test USDC or mockUSDC;
• permissioned resolvers with per-name and per-record roles;
• hierarchical subname creation and deletion;
• primary-name changes, flexible expiry dates and renewal reminders;
• a price-cooldown view for recently expired names; and
• richer registry, token, contract and transaction inspection.

The contracts remain experimental. The normalization upgrade framework is not in this Beta, and payment tokens have no monetary value. Use the official testing surfaces for transactions.

What changes under the hood

Hierarchical registries

ENSv1 records every name in one flat registry. ENSv2 lets each name point to its own subregistry. A parent can choose the ownership, renewal and transfer rules for its namespace without forcing those rules on unrelated names.

Permissioned resolvers replace broad manager access

Standard ENSv2 accounts get their own resolver proxy. Roles can be scoped across a resolver, to one name, or to one record type. A company could let finance change payment addresses while a communications team changes only the avatar and description.

Names become ERC-1155 tokens in per-name registries

ENSv2 token IDs can change when roles change, preventing old approvals from leaking into a new permission state. Marketplaces and indexers must key names by labelhash and registry context, not assume one stable token ID in a single collection.

A shorter lifecycle and new prices

ENSv2 reduces the post-expiry grace period from 90 days to 28 days. A 21-day temporary premium period still follows, with the premium decaying from a deliberately extreme starting point to zero.

The Beta pricing model is $640 per year for three-character names, $160 for four characters, and $8 for five or more. Multi-year registrations and renewals receive stepped discounts: two years costs less per year, three to five years share a larger discount, and six years reaches the strongest published tier. These parameters are still part of the Beta rollout rather than a promise about final mainnet pricing.

What does not change for app developers

Forward resolution, text records, avatars and primary names keep the same public interfaces. Apps using current versions of viem, ethers, ENSjs, web3.py or web3j automatically query the canonical Universal Resolver. CCIP-Read remains essential for offchain and L2-backed records.

ENSv1 names that have not upgraded continue resolving through a mirror resolver. Read-only apps generally do not need to detect whether a name has migrated. Write flows do: the app must look up the name's current resolver and respect its roles instead of assuming one shared Public Resolver address.

How migration actually works

Existing names are premigrated into ENSv2 as RESERVED slots. The owner later claims the slot by transferring the v1 token to the appropriate migration controller. Unwrapped and unlocked names use one controller; locked NameWrapper names use another so their burned fuses can be converted into equivalent v2 roles.

Migration is not purely cosmetic. Most names choose a new v2 resolver and may need records copied; locked names with CANNOT_SET_RESOLVERpreserve their v1 resolver under special rules. Use the official upgrade interface, which can inspect the token and construct the correct path.

There is no need to upgrade immediately when mainnet launches, but “do nothing forever” is not a sound plan. After launch, v1 registrations and normal v1 renewals are disabled. Reserved names renew through a dedicated compatibility renewer and continue resolving until they eventually expire.

What ENS.Tools now supports

• Real Beta network selection. The header switch moves ENS reads between mainnet v1 and Sepolia ENSv2 instead of changing only a badge.
• Canonical resolution. Current viem and ethers versions, the fixed Universal Resolver proxy, CCIP-Read and DNS-name detection are all in place.
• Direct Beta registry inspection. Domain pages read v2 status, owner, expiry and mutable token ID from the Sepolia ETHRegistry.
• Migration context. Reserved names retain their ENSv1 owner and wrapper state so the page can point the owner to the correct official eligibility check.
• Safe v2 write handoff. Experimental registration, renewal, role, record and subname transactions open in the official Beta App or Explorer while ENS.Tools continues to provide native reads.
• No cross-network data mixing. Mainnet marketplace, history and subgraph views stay hidden while Beta mode is active.

How to test it

1. Switch the header from Mainnet to v2 Beta.
2. Open a .eth domain page and inspect its Beta registry state.
3. If it is reserved, open the official App to check upgrade eligibility.
4. Use the Explorer for resolver roles, subnames and transaction flows.
5. Remember that Sepolia ETH, mockUSDC and testnet USDC have no value.

Inspect a name in ENS.ToolsOpen ENSv2 Beta AppOpen ENS Explorer