ENSv2 Overview

Welcome to the next evolution of the Ethereum Name Service!

ENSv2 introduces a suite of upgraded smart-contracts designed to make the protocol more scalable, modular and future-proof. This section will outline the high-level architecture, guiding principles and migration strategy for ENSv2.

What's new in ENSv2?

• Native L2 Support – contracts have been designed with cross-chain resolution in mind, building on existing CCIP-Read support in ENSv1.
• Hierarchical Registries – while ENSv1 used a single flat registry for all names, ENSv2 allows each name to provide its own registry implementation for subnames. This provides name owners and developers with direct control over the ownership and transfer rules for names and subnames.
• Permissions as Standard - All of the functionality enabled by the Name Wrapper in ENSv1 has been integrated into the core of ENSv2, using a new, highly flexible, role-based permissions model.
• No Grace Period - The grace period is no longer a part of the ENS protocol, meaning names expire when they say they expire. Upon expiration, names immediately enter into the temporary premium period. The owner of a recently-expired name doesn't have to pay the premium fee during this period.
• Contract Factories - Rather than relying on large multi-user contracts such as the default public resolver, every name gets its own resolver, and every name with subnames gets its own registry contract. This simplifies the contracts significantly, while offering users new functionality such as the possibility of 'aliasing' multiple domains to the same records.

What hasn't changed?

• Resolvers - while we have developed new resolver contracts to take advantage of the changed environment enabled by ENSv2, the interface used by resolvers remains the same, and all existing ENSv1 resolvers will continue to work seamlessly in ENSv2.
• True Ownership - ENSv2 continues to prioritize trust minimization, enabling you to own your name fully, without having to worry about interference from centralized third-parties.
• Truly multi-chain - ENS continues to support all L2s.

Registry Architecture

ENSv2 replaces ENSv1's single flat registry with a hierarchical model where each name can have its own registry for managing subnames, and its own resolver for storing records. Names don't exist as single on-chain objects. Instead, a full name like sub.alice.eth is a chain of entries across registries linked by subregistry pointers.

See Registry Hierarchy for the full explanation with diagrams, including subtree operations, namespace aliasing, token representation, and the permissions model.

Architecture

Contracts

Deployments (Sepolia)

Guides