ENSv2 fundamentally changes how names are represented onchain, moving from a single global registry to a hierarchical system of linked registries. The new architecture makes ownership and delegation explicit, opening up more flexible and composable naming systems within ENS.
When you use an ENS name, it feels simple. One name, one owner, one resolver that returns whatever data you need, whether that is an address, a text record, or a content hash.
That intuition largely held up in ENSv1, where every name ultimately existed as a single entry in one global registry. But beneath that interface was a more compressed representation of how names were structured onchain.
To understand what's changing in ENSv2, it helps to start with a more fundamental question: where do ENS names actually live? The answer begins with the registry.
At a high level, a registry is the contract that keeps track of ownership. It's the source of truth for who controls a label at any point in time.
If that feels abstract, it helps to think about registries outside of crypto. A land registry keeps track of who owns a piece of property. A company registry records who owns or operates a business. A vehicle registry links a car to its registered owner. In each case, the registry is the authoritative record of ownership.
ENS works the same way.
When you register a name, what you're really doing is creating or updating an entry in a registry that says, "this address controls this label." That entry can also point to a resolver, which is where the data for a name lives, but the registry itself is focused on ownership and delegation.
In ENSv1, there was one global registry that held entries for every name. At its core, the registry stored a mapping from a namehash to a record containing the owner, resolver, and TTL for that name.
This meant that every name, regardless of how many labels it had, existed as a single entry in the registry. A name like sub.nick.eth was represented as one key in that mapping, with its hierarchy encoded into the namehash itself.
The structure was there, but it was compressed.
ENSv2 takes a different approach. Rather than encoding the hierarchy into a single identifier, it models that hierarchy directly onchain.
ENSv2 makes that hierarchy explicit. Instead of representing a full name as a single entry, it represents each label as its own entry in its own registry, with registries connected to each other as part of a tree.
To understand this, it helps to look at how a name is traversed.
Take sub.nick.eth. In ENSv2, this is no longer stored as one object. It is composed of separate entries:
ethin the root registrynickin theethregistrysubin thenickregistry
Each of these entries represents ownership at that level. Each can have its own resolver. Each can point to its own subregistry. Each can also be represented as its own token.
To work with a full name, the system starts at the root and walks down the tree, following each label in sequence. For sub.nick.eth, that means traversing from <root> to <eth> to <nick> to <sub>. What used to be a single lookup becomes a traversal across multiple registries.
A name is no longer stored as one entry. It is constructed by following a hierarchy of linked entries.
A helpful way to visualize this shift is to compare it to a room of safe deposit boxes.
In ENSv1, you can think of the registry as a single vault room. Each box represents a name. From the outside, every box looks the same. A box representing nick.eth and one representing sub.nick.eth might sit side by side, and their hierarchical relationship is not visible. It exists only in how their identifiers were derived through the namehash algorithm.
The structure is there, but it is opaque.
In ENSv2, the model changes. Instead of one room filled with boxes, you have a nested system. You enter a root room. Inside it, there is a box labeled eth. That box does not just contain one name. It contains an entire namespace, with boxes for every .eth that exists, whether that is nick, vitalik, or millions of others.
Inside the nick box, you might then find another layer containing sub. The relationship between names is no longer implied. It is physically represented by how labels are nested.
This is one of the core ideas behind ENSv2. It takes what was implicit and makes it explicit onchain. The hierarchy that always existed conceptually is now reflected in how the system is built.
That shift brings a more granular model of ownership. Instead of relying on a global system to manage all names, each name owner can control their own namespace. A label is not just a point in a system. It becomes a boundary of authority. This also moves ENS closer to the hierarchical delegation model used in systems like DNS, where authority is passed down step by step.
What follows from this is flexibility. Subnames can be managed independently without relying on a central contract. Entire subtrees can be reconfigured or replaced without affecting the rest of the system. Different parts of the namespace can adopt their own logic, their own resolvers, and their own rules.
A flat space of names turns into a composable system of namespaces.
Making the hierarchy explicit introduces a different kind of responsibility.
In ENSv1, ownership was verified against a single registry entry. In ENSv2, ownership is distributed across the hierarchy of registries that make up a name. Each step in that hierarchy must be valid, and each parent registry must correctly reference the next level below it.
A name is only valid if the full hierarchy connecting it back to the root remains intact. If part of that structure is broken or misconfigured, the name no longer resolves as expected. Verification becomes a process of traversing the hierarchy and confirming that each connection holds.
Resolution follows a similar pattern. Instead of relying on a single lookup, the system walks the registry hierarchy and determines the appropriate resolver based on the deepest valid match. The process reflects the structure of the name itself.
For applications and marketplaces, this changes how names are verified and represented under the hood. Instead of relying on a single registry entry, integrations need to ensure that a name is correctly connected through the hierarchy back to the root.
This introduces additional complexity at the infrastructure layer, particularly around validating names and traversing registries. But for most users, these details are abstracted away. ENS resolution infrastructure, including the Universal Resolver, is designed to handle this process automatically so names continue to behave as expected at the application layer.
At the same time, this architecture opens up new patterns that were difficult to support before. Protocols can build naming systems within ENS rather than around it. Teams can create namespaces that behave differently from one another while still remaining part of the same global system.
ENSv2 is more expressive. Names are no longer single entries but structured systems composed of linked parts. That added structure brings complexity, but it also gives names meaning at every level of the hierarchy, and that is what makes the system more powerful to build on.