ENSv2 is a complete reimagining of the ENS protocol. It replaces the single flat registry of ENSv1 with a hierarchical architecture where every name can define its own registry and resolver, unlocking patterns that were not previously possible. From instant subtree management and granular roles to resolver aliasing and seamless backward compatibility, ENSv2 preserves everything that made ENS successful while expanding what names on Ethereum L1 can do.
Seven years ago, ENS launched with a simple but powerful vision: replace complex blockchain addresses with human-readable names. Since then, ENS has become the naming infrastructure for blockchains, with over 1.5 million names registered and integrations across the ecosystem—from wallets to social apps to enterprise platforms. ENSv2 is a complete reimagining of the ENS protocol that preserves everything that made ENS successful while unlocking capabilities that weren't possible before.
ENSv2 deploys exclusively on Ethereum L1, replacing the single flat registry of ENSv1 with a hierarchical architecture where every ENS name has its own registry. This architectural shift enables powerful new patterns: instant subtree management, shared registries across multiple names, granular permission controls, and immediate expiration handling. Combined with improved cross-chain interoperability and two new purpose-built applications (ENS App for consumers, ENS Explorer for power users), ENSv2 gives users unprecedented control over their namespace. Let's dive into how this works.
ENSv1 used a single, flat registry contract, which was elegant in its simplicity, but limiting in its flexibility. Every name had to follow the same ownership model, enforced by that single contract.
In ENSv2, registries are hierarchical: each name can have a resolver and a subregistry.
ENSv2 introduces hierarchical registries. Each name can provide its own registry implementation for managing subnames, giving name owners direct control over ownership and transfer rules. Names can also define their own resolvers, rather than relying on shared infrastructure. Together, this forms a directed graph structure rooted at a single root registry. If that sounds complex, bear with us: here are a few contextual examples of what that could mean in practice.
In ENSv1, if you wanted to delete or replace all subnames under dao.eth, you'd have to modify each one individually. In ENSv2, you can replace the entire subtree in a single operation by updating the registry for dao.eth.
Imagine a DAO that issues member1.dao.eth, member2.dao.eth, etc. At the end of each governance period, they can deploy a fresh registry and reset all membership names at once rather than individually revoking hundreds of subnames.
With ENSv2, multiple names can point to the same registry contract. This creates powerful new patterns:
Registry 0x123 contains:
- manager
- moderator
- member
If both dao.eth and community.eth point to Registry 0x123:
- manager.dao.eth exists
- manager.community.eth exists
- moderator.dao.eth exists
- moderator.community.eth exists
Adding a new role to Registry 0x123 automatically creates it for both organizations.
This isn't limited to names at the same level either. You could have dao.eth and team.project.eth both pointing to the same registry, creating manager.dao.eth and manager.team.project.eth simultaneously.
This pattern is perfect for organizations that want to maintain consistent role structures across multiple namespaces, or for creating standardized templates that can be shared across different projects.
ENSv1's flat structure meant expired names continued to exist in the registry until someone registered them again. Worse, any subnames remained active, creating "zombie records" that could confuse users.
In ENSv2, when a name expires, it vanishes from the registry immediately. The name stops resolving, and the entire subtree becomes inaccessible. When someone registers the name again, they start with a clean slate.
ENSv1 introduced the Name Wrapper to enable locked names and permission controls through "fuses." It worked, but added significant complexity and overhead.
ENSv2 replaces fuses with a more flexible roles system. You can now set granular permissions at three levels:
- Resolver level: Permissions apply to all records in the resolver, regardless of which name they're for.
- Name/Node level: Permissions scoped to all records under a specific name.
- Record level: Permissions for specific record types or even individual records.
Consider these examples:
Example 4: Multi-Administrator Setup
Company.eth configuration:
- Alice: Can update all records
- Bob: Can only update address records (for payment routing)
- Carol: Can only update the avatar record (for branding)
Example 5: Delegated Content Management
Museum.eth resolver permissions:
- Curator role: Can update 'description' and 'contentHash' records
- Finance role: Can only update cryptocurrency address records
- Public: Can read all records but modify none
This becomes especially powerful with custom text records, where you can create application-specific data fields with precisely scoped access controls.
Example 6: Gaming Guild with Custom Text Records
Guild.eth uses custom records for game state:
- Custom record: "guild.rank" (values: Initiate, Member, Elite, Leader)
- Custom record: "guild.treasury_allowance" (spending limit in USDC)
- Custom record: "guild.quest_completions" (integer count)
Permission structure:
- Guild Master: Can update all custom records for any member
- Treasurer: Can only update "guild.treasury_allowance"
- Quest Manager: Can only update "guild.quest_completions"
- Members: Can read all records but modify none
When member1.guild.eth completes a quest:
- Quest Manager updates their "guild.quest_completions" from 5 to 6
- Once they hit 10 completions, Guild Master updates "guild.rank" from Member to Elite
- Treasurer then adjusts "guild.treasury_allowance" from 100 to 500 USDC
This pattern enables applications to store structured data on ENS names while maintaining fine-grained access control—perfect for DAOs, gaming guilds, credential systems, or any application that needs to attach verifiable metadata to identities.
Resolution in ENSv2 works differently. Instead of clients implementing the entire resolution process themselves, they call the Universal Resolver contract that handles everything internally, from direct on-chain resolution to orchestrating CCIP-Read lookups, where off-chain data is fetched by the client and resolution is finalized on-chain.
This architecture provides a smooth upgrade path. We deployed a Universal Resolver for ENSv1 and migrated client libraries to use it as the canonical entry point. With ENSv2, the resolver implementation evolves behind the scenes while preserving that interface. Applications built on these libraries require no changes, as the transition is handled transparently on-chain. The complexity of the new hierarchical lookup process is completely hidden from client implementations.
One of the most powerful but subtle features of ENSv2 is the aliasing system for resolvers.
You can configure multiple names to use the same resolver and define aliases within that resolver to create an alias relationship. When you update records once, all aliased names reflect the change:
Example 7: Personal Brand Consistency
Your resolver at 0x<YourAddress> contains:
- name: "Alice B"
- description: "Product Designer"
- avatar: ipfs://...
- url: "alice.design"
You configure these names to use the same resolver and enable aliasing:
- alice.eth
- alicedesign.eth
- alice.box
Now all three names show identical records. Update your avatar once, and it changes everywhere.
Example 8: Multi-Brand Management
Your company owns:
- brand.eth
- brand-official.eth
- brandname.eth
All aliased by the same resolver with consistent company information.
A new product launch? Update the description once, and all brand names reflect it.
ENSv2 launches with all existing ENS names pre-upgraded to a special state. Legacy names will:
- Continue resolving exactly as they do in ENSv1
- Reflect any changes made to ENSv1 records
- Work seamlessly for end users
When you're ready to upgrade, the process is straightforward:
- Call the upgrade contract
- Specify your desired resolver and registry settings
- The contract transfers ownership and updates your configuration
For names that were wrapped and locked in ENSv1, ENSv2 preserves those guarantees by requiring the use of a special wrapper-aware registry contract, which enforces the same restrictions.
Every legacy name is assigned an ENSv1 Fallback Resolver. When queried, this resolver:
- Looks up the name in the ENSv1 registry
- Returns the current ENSv1 data
- Supports wildcard resolution for all subnames
This means even changes made to ENSv1 after ENSv2 launches will continue to appear in ENSv2 resolution—at least until you upgrade and set your own ENSv2 resolver.
If you've integrated ENS into your application, here's what you need to know:
- Universal Resolver Readiness: If you're using an up-to-date Ethereum client library, you're likely already ENSv2-ready and don't need to make changes. Custom ENS integrations should ensure they resolve names via the Universal Resolver to remain compatible with ENSv2. See the ENSv2 readiness guide for the latest compatibility matrix and integration guidance.
- Registry Awareness: For advanced integrations, you can now query individual registries to understand the specific governance and permission structures of different namespaces.
- Subname Management: If you issue subnames (like Coinbase's
cb.idor Uniswap'suni.eth), ENSv2's registry system gives you much more powerful tools for managing your namespace. - Custom Registries: Advanced users can deploy custom registry contracts with application-specific logic—rental systems, subscription models, algorithmic allocation, you name it.
ENSv2 represents a fundamental upgrade to the ENS protocol, one that was only possible with seven years of experience building and maintaining the identity infrastructure of web3.
By staying on Ethereum L1, we're doubling down on our core values: decentralization, security, and neutrality. By restructuring the protocol around hierarchical registries, we're unlocking capabilities that simply weren't possible before.
And by building purpose-specific applications in the ENS App and ENS Explorer, we're ensuring that whether you're claiming your first web3 identity or building the next major ENS integration, you have the tools you need.
The upgrade to ENSv2 will happen over the coming months. We'll share detailed timelines, tooling, and documentation as we get closer to launch. In the meantime, your names will continue to work exactly as they always have—and when you're ready to upgrade, you'll have access to capabilities that make ENS more powerful than ever.
Want to learn more? Check out our docs and join the discussion in the ENS DAO Forums.