ENS ownership has evolved alongside the protocol itself. What started as a clear way to own and transfer `.eth` names has grown into a richer model that supports subnames, permissions, token regeneration, and ENSv2's registry-native architecture.
ENS names have often been described as NFTs. An NFT, or non-fungible token, is a unique onchain token that can represent ownership of something digital. In the case of ENS, that "something" is a name.
ENS is not just a collectable. It's a naming system. A name can point to addresses, a website, a profile, an avatar, or other records. Those records live with the name, but they can include addresses for different chains. It can also sit inside a larger namespace, like alice.eth sitting under .eth, or pay.alice.eth sitting under alice.eth.
So the token is only one part of what makes an ENS name work. It helps wallets, marketplaces, and apps understand who owns a name. But ENS also needs to understand what that name can do, who can manage it, what records it points to, whether it can create subnames, and what permissions come with it.
That's why the token standard has changed over time.
The evolution from ERC721 to the Name Wrapper to ENSv2 is not just a history of different token standards. It's the story of ENS moving toward a model that better matches what names actually are.
The first widely understood token model for ENS was ERC721.
ERC721 is the standard commonly associated with NFTs. It works well for unique assets, where each token represents one distinct thing. That made it a natural fit for .eth names. There can only be one alice.eth, one vitalik.eth, or one ens.eth, so representing a .eth name as a unique NFT made sense.
In ENSv1, .eth second-level names were handled by the .eth registrar. When someone registered a name like alice.eth, they received an ERC721 token that represented ownership of that name. This made ENS names easier for the wider Ethereum ecosystem to understand. Wallets could show them. Marketplaces could list them. Users could transfer them.
For many people, this is still the simplest mental model: "my ENS name is an NFT in my wallet."
That model was useful, but ENS names were never only standalone objects. They were always part of a larger naming tree: the owner of alice.eth can create pay.alice.eth, a company can issue names under company.eth, and an app or community can hand names to its members.
ERC721 suited the earliest experience of registering, holding, transferring, or selling a .eth name. But at that stage, the token model was focused on .eth second-level names. Subnames and DNS names also existed in ENS, and as those became more important, people wanted more than simple ownership.
Names could act as namespaces, issue subnames with defined permissions, and support different relationships between a parent and its children. That introduced questions like what a parent can still control, what rights a subname owner receives, and whether those rights can be changed later.
ERC721 gave .eth names a strong foundation as user-owned tokens. The next step was extending that clarity to more of the ENS naming tree.
The Name Wrapper was introduced to solve that next layer of the problem.
By this point, ENS was no longer just about people registering a single .eth name and pointing it to a wallet. Names were becoming namespaces. People wanted to create subnames, issue them to others, set rules around them, and give users stronger guarantees.
This is where ERC1155 entered the picture.
At that stage, ENSv1's ERC721 registrar tokenized .eth second-level names. But ENS needed a model that could represent names across the whole naming tree: .eth names, DNS names, and subnames alike. It also needed a way to attach more information to each name, including permissions and expiry.
ERC1155 fit that next step well. It can manage many different token types through one contract, supports actions across multiple tokens at once, and offers a more flexible metadata model. For ENS, that meant the Name Wrapper could represent many kinds of names in a consistent way, while still keeping the part that mattered most to users: each name remained a single token with one owner.
With the Name Wrapper, an ENS name could be wrapped into an ERC1155 token. That could include a .eth name, a DNS name, or a subname.
The word "wrapper" is important here. The wrapper doesn't create the ENS name from scratch. The name already exists in ENS. What the wrapper does is place that name inside a smart contract that can give it a richer ownership layer.
A simple analogy is putting a document inside a legal envelope. The document already exists, but the envelope adds rules around how it can be used, transferred, or controlled. In the same way, a wrapped ENS name is still an ENS name, but it now comes with additional token behavior and permissions.
In other words, the Name Wrapper gave ENS names a more robust ownership layer without rebuilding the entire ENS system underneath it.
The most important part of that layer was fuses.
A fuse is a permission that can be permanently revoked. The metaphor is useful: once a fuse is burned, that action cannot simply be undone for as long as the name stays registered. For example, a name can be made non-transferable. A resolver can be locked. A parent name can give up its ability to control a child name. A subname can be given stronger guarantees.
This changed what ENS ownership could mean.
Imagine a company owns company.eth and gives Alice alice.company.eth. Without stronger permissions, Alice may technically have a subname, but the company may still be able to change it, revoke it, or replace it. That might be fine for an internal employee account, but it's not ideal if Alice is supposed to rely on that name as a long-term identity.
The Name Wrapper made it possible to define those relationships more clearly. A parent could issue a subname and then burn certain fuses to limit its own future power over that subname. That gave subname owners more confidence in what they had actually received.
So the move from ERC721 to ERC1155 was not random. ENS needed a token model that could tokenize names at every level of the tree and carry permissions and expiry on the token itself, while still giving each name a single owner.
ERC721 worked well for a single unique .eth name.
ERC1155 through the Name Wrapper worked better for a wider naming system, where .eth names, DNS names, and subnames could all be tokenized, and where ownership could include permissions.
But the wrapper was still working around the original ENSv1 architecture. It added a more powerful ownership layer on top of the existing system, but it did not replace the underlying structure. Wrapped names still had to stay in sync with the legacy registry and registrar. The system had to account for wrapped names, unwrapped names, expiry, fuses, and compatibility with older ENS infrastructure.
That was the tradeoff. The Name Wrapper made ENS ownership much more expressive, but it also made the system more complex.
It proved that ENS needed richer tokenized ownership. It also showed that this ownership model would eventually make more sense as part of the core architecture, not as a layer wrapped around it.
ENSv2 takes the ideas behind the Name Wrapper and moves them deeper into the protocol.
The biggest architectural change is that ENSv2 is built around hierarchical registries. In ENSv1, there was one flat registry that tracked all names. The hierarchy still existed conceptually, but the core registry was a single contract mapping names to owners and resolvers.
ENSv2 changes that model. Each name can have its own registry for the names beneath it. If alice.eth wants to create pay.alice.eth or blog.alice.eth, those subnames can be managed through a registry associated with alice.eth.
The simplest way to understand this is that ENSv2 makes the contracts look more like the naming system.
Names are hierarchical, so the registries become hierarchical too.
That change affects the token model. In ENSv1, the token mostly sat beside the registry as a representation of ownership. With the Name Wrapper, the token became a more advanced layer around an existing name. In ENSv2, token ownership is built directly into the registry model.
A registry can represent the names inside it as tokens. So instead of treating the token as something separate from the name's management system, ENSv2 brings the two closer together. The same structure that manages names can also express ownership, permissions, expiry, resolver settings, and subregistry settings.
This is the clearest way to think about the progression:
ENSv1 made .eth names visible as NFTs.
The Name Wrapper made more ENS names tokenized and gave them permissions.
ENSv2 makes tokenized ownership part of how ENS registries work.
That is the important shift. The token is no longer just a user-facing object that says, "you own this name." It becomes part of the system that defines what owning the name actually means.
ENSv2 uses a modified ERC1155 model called ERC1155Singleton. The technical details can get dense quickly, but the user-facing idea is simple: ENS still wants the flexibility of ERC1155, but names themselves are unique. You don't need multiple copies of the same name. You need one owner for one name. That single-owner model carries over from the Name Wrapper, where wrapped names already had one owner per token. What changes in ENSv2 is where the rest of the name's data lives. ERC1155Singleton keeps ownership on the token, while permissions and expiry move into the registry itself.
So ERC1155Singleton keeps the ERC1155 structure that helps ENS support many names inside a registry, while treating each name like a single unique token. For users, the model stays familiar: one name, one owner. For the protocol, it gives ENS a token system that works better with hierarchical registries and more advanced permissions.
This is what ENSv2 is really doing in the context of tokens. It is not just swapping one token standard for another. It is making tokenized ownership match the way ENS names are structured.
A name can be a standalone identity, but it can also be a namespace. It can support subnames. It can have a resolver. It can delegate permissions. It can be used as infrastructure by an app, community, company, or individual.
ENSv2 gives the token model enough room to express that.
One of the biggest lessons from the Name Wrapper was that ownership is not always one thing.
Sometimes the owner of a name should be able to do everything. Sometimes they should only be able to change records. Sometimes they should be able to create subnames, but not transfer the parent name. Sometimes a registrar contract should be able to issue names, but not change where existing names resolve.
ENSv2 handles this through role-based permissions.
Instead of relying on a separate wrapper and fuse system, ENSv2 builds permissions into the registry model. A name can have roles that determine what different accounts or contracts are allowed to do. These roles can cover actions like setting a resolver, setting a subregistry, renewing a name, transferring a name, or controlling the registry that issues subnames. Unlike fuses, which are burned permanently, roles are reversible: whoever holds the corresponding admin role can grant them and revoke them again later. This makes permissions something you can adjust over a name's life, not just lock down once.
This makes ENS ownership more specific.
Owning a name is not just "having the token." It is having a defined set of rights over that name. Those rights can be shaped depending on the use case.
This matters a lot for subnames. A project issuing subnames may want some control over the namespace, while still giving users confidence that their individual names won't be arbitrarily changed. A company might want employee names that can't be sold. A community might want names that act more like membership credentials. A wallet might want to issue names that point to user accounts without giving every user full administrative power over the entire namespace.
These are all different ownership models. ENSv2 gives the registry a more native way to represent them.
Token regeneration helps protect against this.
When a name's permissions change, either by granting or revoking a role, its token ID updates. The name still exists, but any marketplace listing tied to the old token ID now points to an older version of the name's rights. That means the sale can no longer go through as if nothing changed.
Think about a seller who lists a name, then changes what the buyer would actually receive before the sale is completed. The label may look the same, but the rights attached to it have changed. Token regeneration makes that change visible at the token level, so the old listing cannot quietly remain valid.
A normal sale does not change the token ID. What changes it is a change to the rights attached to the name, or a change in the name's lifecycle, like being unregistered or expiring and then being registered again by someone new. This also prevents a fresh registration from inheriting the previous owner's approvals or marketplace history.
In short: if the permissions change, the token changes with them.
This is the security model ENSv2 uses: a change to a name's permissions changes its token ID, so a listing tied to the old ID can no longer be filled and a buyer cannot be handed a name whose rights were quietly altered after it was listed.
This is especially important for ENS because names are active infrastructure. People use them for payments, websites, profiles, wallets, apps, and subnames. A name is not just something you display. It is something other systems rely on.
So marketplace safety for ENS cannot only be about whether the label is real. It also has to be about whether the buyer is receiving the rights they think they are receiving.
ENS names became tokens because Ethereum needed a standard way to represent ownership. A token makes a name portable. It lets wallets display the name, marketplaces trade it, and apps recognize who controls it.
But as ENS grew, the token model had to carry more meaning.
ERC721 made .eth ownership simple and visible. The Name Wrapper expanded that model to more names and added permissions through fuses. ENSv2 brings tokenized ownership into the registry architecture itself, so names can be represented, managed, and permissioned in a way that more closely reflects how they actually work.
That alignment is the real story.
A name is unique, but it's not isolated. It can sit inside a larger namespace. It can point to records. It can support subnames. It can be managed by different roles. It can be bought, sold, delegated, locked, renewed, or used as infrastructure.
The token model has evolved because ENS has evolved.
The goal was never just to make names look like NFTs. The goal was to make tokenized ownership accurately reflect what an ENS name is, what it can do, and what rights come with it.