ENS: ENSv2 - Identity for Apps, Agents & Beyond | Kevin Krone at ETHOnline 2026

Um, yes, hello everyone. Uh , my name is Kevin Welcome, and I'm a technical writer on the Enos Labs development team. Um, today I'm going to hold a little seminar for you . There will be no coding , we will just go through the slides. In particular, I want to highlight the Enos feature—better deployment in Sepolia.

And let me just say that we deployed another set of contracts at Sepolia specifically for the hackathon. So I would like you to make sure that you deploy with these contracts. If you go to docs.enos.domains, there is a banner docs.

enos.domains, there is a banner that takes you to a feature branch that explains deployment and how to modify your VM or Ethers code to make sure you are addressing these contracts. But I will post it on the God channel, as well as in the God channel, as well as in the ENS developer Telegram group. Just so you know . Yes, um, I'm Kevin .

Yes, um, I'm Kevin . Let's look at some slides. I'll briefly talk about ENS in general, and then go into more detail about ENS V2 and what you can create. So, what is ENS? Uh, Ethereum Name Service is a decentralized, permissionless naming protocol that runs on the Ethereum network.

And, um, how did it all begin? Essentially, converting complex hexadecimal addresses into human-readable names, right? In a situation like this, $5... this, $5... it's hard to remember an address like that, right?

I don't think anyone can do that. It's much easier to just say, "Hey, send 5 USDC to wakumon.eth, okay?" Therefore, we consider ENS to be a user interaction protocol in Ethereum . Um, but this is just the beginning.

Over time, ENS evolved and became something like an on-chain profile. Here you can see my personal ENS profile for my name in the manager app. For example, I have an X profile, GitHub X profile, GitHub , and addresses on various networks. This is a kind of multichain multichain solution where you can store BTC, Solana or any other addresses so that people can easily find you by knowing your ENS name. There 's also the avatar you see here, and much more, such as text entries and data that can be used to create interesting applications, united under the single name ENS.

So, one of the simplest uses of ENS is this feature: when you connect to the application, after connecting the wallet, you only see the Ethereum you only see the Ethereum address. It's not a very personalized experience. So you can change it to something like this, right? But this requires more than just converting the ENS name to an address, because a program may know the address but not the name associated with it. This is where the aspect of reverse resolution comes into play.

Here you see examples like snapshot.org or match.xyz—two apps that integrate this today. Of course, there are many more. I'm sure you know of many applications that integrate ENS with resolution and other capabilities.

For example, Etherscan—here you can see a short demonstration of what it looks like without ENS and with ENS. Look at the bottom : just random addresses, maybe contracts interacting with the address, and it's completely incomprehensible to a human. And on top you see that a user is involved and, perhaps user is involved and, perhaps , some kind of contract. And I think it's a much better user experience. The general idea is that users of crypto users of crypto services do not need to interact with hexadecimal addresses at all.

It should be as simple as possible, and ENS provides this level of naming that makes it all understandable to people. So anywhere you read or write a hexadecimal address, you should be able to just use the ENS name—that's basically the idea. So how does it work idea. So how does it work ? I have already briefly touched on forward and reverse resolution.

These are the two main processes that are at the core of ENS contracts. Direct resolution: you start with an ENS name, like nick.eth, and convert it to an address, right? So, an Ethereum address is a base address or something on the Optimism network. In this case, I think I forgot to change the addresses on the slide, so of course they could be different, right?

I mean right? I mean , they all run on EVM and are served by the same private key, but you can store different addresses if you want. Next comes the reverse resolution. This is the function resolution. This is the function that is used when you connect to the program, right?

Not only does it know the wallet address, you can also point to the ENS can also point to the ENS name if you set up a reverse write. So reverse write. So , because this is such a useful concept, we have a name for it—a have a name for it—a basic name. If you have reverse and forward resolution, i.e.

an ENS name points to an address and the same address points to an ENS name, you get a kind of loop, and this is what we call a primary name. Um, yes. So let me move on to ENS V2. A few weeks ago, we finally deployed ENS V2 beta contracts on the Sepolia network. And people have already started experimenting with them .

For this hackathon, as there are some changes coming up, we wanted to make sure you had a stable environment for the duration of the hackathon, so we deployed a new set of contracts that would not change throughout the hackathon. Um throughout the hackathon. Um , the core support for your deployment may vary depending on the patches before the mainnet launch. But let me tell you what's new in V2. First of all, the most obvious change: ENS V2 had one flat registry structure.

This means that if you know about a subdomain, for example, alice.eth and sub.alice.eth, which is a subdomain of alice.eth, it's similar to subdomains in DNS.

This entire tree-like structure that exists in this namespace was encoded in a single flat registry using a name hashing algorithm, which at the time of ENS's release was a fairly successful and efficient approach to blockchain to blockchain programming problems. But over time, ENS evolved, and people wanted certain new features. Subjects have become much more interesting for users. Therefore, in ENSv2, we did a complete redesign, taking into account all the lessons learned over the past almost 10 years. And now almost 10 years.

And now , in ENSv2, this hierarchy and tree-like structure has become visible directly in smart contracts. So, on the right you can see a diagram of what our root level looks like now. Isn't that right? There is a root registry and then an ENS registry. Alice has her own registry, if she wants, she can buy two more, and so on.

So, it really is like an NFT NFT thing. And, um, the overall structure is also changing . So you buy the ENS name, and, um, what you can do is what you can do is —the general idea is you deploy your own resolver. Um, whereas in ENS V1 people usually used the default public resolver as a common resolver for all ENS names. There was always the option to simply deploy your own custom resolver, but that was more of an option.

Um, for V2, um, the standard is that you essentially deploy your own, uh, resolver own, uh, resolver . And this resolver, um, is deployed as a shared proxy. So there 's one implementation, and you just, uh, deploy a proxy, essentially. And this is done through a smart contract called a " fiber factory." And there's another fiber factory."

And there's another , um, thing you can do. Uh, you can deploy your own sub-registry. So there is a division between registries and resolvers. And the sub-registry, um, you also deploy through the fiber factory, but fiber factory, but , um, you may not need it. This depends to some extent on your use case use case .

You essentially think of it like this: if you want to have subnames and also tokenize them, then you deploy a subname registry. Or maybe you also want to provide different types of permissions for these subnames, then it makes sense to deploy a subname registry. You can also take the approach of simply taking a resolver and doing what's called what's called wildcard resolving. Essentially, you have entries inside this resolver for, um, subnames, but then they may not be tokenized. It's simply a way to store data for these subnames.

Um, so one configuration might look like this . By the way, we also have instructions in the documentation on how to do this. So this is a configuration, for example, nick.eth deploys its own sub-registry. And on top of that, you even have, um, a registrar's contract.

So that's one more contract . So you have a resolver, a sub-name registry, and a registrar sub-name registry, and a registrar is a contract that you use to set up how people can buy or get a name in your sub-name registry, right? For example, as it says on the slide here— five USDC per year, but you can be very creative in what you want to do, right? You might say, maybe, I don't know, maybe they need to own some kind of NFT or do something else to get a subdomain in your registry. And then you can also configure these subnames with permissions.

For example, giving them permission to deploy their own resolver, to have their own sub-registry. You can think of configurations where our subnames cannot be passed. One could consider a configuration that effectively creates " effectively creates " eternal names" where the parent name has a very long validity period in the future. And this seems to cancel all permissions to interfere with subnames, so they become effectively emancipated within the subregister. So within the subregister.

So , I think there's a lot of room for innovation here. Another thing that people will probably notice very quickly is the new ID token structure. In ENS V2 we have variable token IDs, which is essentially related to the new permissions and roles system. Let's call it EIC— roles system. Let's call it EIC— enhanced access control.

This system allows you...it's also role-based. Usually you have a specific role and an administrator role, and you can grant the permissions I mentioned: setting up your own resolver, creating a sub-registry, etc. Regarding such things, let's say you put the ENS name up for sale, and it would be unpleasant if someone said, "Okay, this set of permissions is added to the token and transferred to the new owner," but after putting the token up for sale, changed those permissions, effectively defrauding the buyer. Therefore, every time rights are granted or revoked for a token, it is destroyed and issued again for the same owner.

Accordingly, the token ID also changes. This is something you need to consider in your projects. If you simply change the sub-owner or continue the name, nothing will change. The token ID will remain the same . There are also some edge cases, for example, if a name expires or is re-registered, the token ID also changes.

All of this is described in our official documentation. So, why wait for ENS V2? I think if you work with ENS V2 a little , you will realize that V2 is much more flexible, as well as cleaner in design, compared to ENS V1 and, for example, Name Wrapper. And this is, in fact, the reason why it appeared. V1, like ENS, evolved over time, and people had many ideas for using ENS.

And, um, there were changes made to sort of accommodate that, but of course, a lot of the applications weren't obvious at the beginning, were they? So V2, taking all the lessons learned, is kind of a complete, um, redesign of the entire infrastructure. So, I think it provides flexibility provides flexibility , and, um, you can be, um, creative with it. And, um, the permissions system that I mentioned, the enhanced access control, also gives you the ability to even, um, give someone permission to change, for example, an individual text entry or, for example, change the avatar for a name, right? So this is, um, much more detailed compared to what was previously proposed previously proposed .

And another feature that I think is worth mentioning is aliases. Um, that's actually two, um, functions, since there are two types of aliases in ENS V2 . One is . One is , um, shared records. That is, text records, address records, you can point two names to the same set of records and they will be recognized identically.

Changing the record, for example changing the Ethereum address, um, will change it for both in terms of recognition. Of course? So, they're actually, sort of, pseudonyms in that sense. And then there's registry-level aliases, which means you point two, um you point two, um , ENS names to the same sub-registry, which means, let's say Alice and Bob both point to the same sub-registry, and in the sub- registry you have tokens labeled ABC, then after, ABC, then after, um, you create aliases for those names, both Alice and Bob will have a.alice.

eth, b.alice.eth, and for Bob the same thing : a.bob.eth, and so on.

You can create aliases for entire namespaces, which I think is also a very interesting application. So, a few more slides about what you can do with ENS, even with ENS V2, of course. AI agents have become, um, very popular at past hackathons, so I personally like to think of agents as namespaces. So for example, you have my name here rickman.eth, and I would have a subdomain agent.

rickman.eth, then I could have more subdomains, even one level down, like v1 or v2, different versions of the same on-chain same on-chain agent. And by parent name I could point to the last agent, for example v2 in this case, right? So, in that sense, you can think of agents as namespaces, where you can use data or text records to store some information about those agents in your ENS name. One example is ENS 25, which allows you to do a two-way communication between 804 agent registrations.

So you point to the registry, you give the agent ID, and then you can check: if there's an 804 agent and it has the ENS name as a service in its registration file, then you can specify from your ENS name: " your ENS name: " Okay, yes, I give consent for this 804 agent to use my ENS name, right?" So that's also a way you can connect to the 804 ecosystem. But there's also ENS 26, which is a little bit of a stand-alone thing. It's not shown here, but the idea is that you can store the endpoint for the agent in a text record or context, right? For example, if you want to provide an endpoint for agent-to- agent-to- agent interaction, you can simply store it in a text record standardized according to EP 136 in your ENS name.

And of course, these are just standards that were agreed upon at the time , but you are free to propose your own standard. So, a quick overview of what you can create: AI agents, I've already talked about this already talked about this . You can use text entries, aliases, and wallets. I think, from my perspective, it makes sense to integrate ENS and wallets by default, as it greatly improves the user experience. Social apps are also very popular.

You can even use ENS names as a kind of decentralized database if you want, and display ENS names as nicknames. And another topic is content. There is such a thing as a "content hash" . This is also a piece of data that can be attached to an ENS name. And, for example, using IPFS to create a decentralized website that stands behind your ENS name, right?

So, this is also a very interesting application. In general, wherever a hexadecimal address is displayed, it is a good idea to add the corresponding ENS name. Let's move on to the prizes of this hackathon. We have a consolation prize, $500. Perhaps it is worth noting at the outset that we have two directions.

One of them is the best use of ENS V2. We really want to focus on ENS V2 in this hackathon and see what you create. We're really excited to see how creative you can be with V2. So, this is an incentive prize, $500. Then, third prize, $1,000.

And, uh, first and second, uh, prizes are 1,500 each. And then, for the continuity track continuity track , there's, um, 500 bucks. A track, uh, of continuity, maybe to, uh, highlight it here. It would make sense if you could use a real production deployment instead of a hackathon deployment of V2 . The idea is to integrate ENS V2 into an application, uh, that already exists.

Um, in a smart way, and, uh, prepare it for, uh, the deployment of ENS V2 on the mainnet. Um, yeah, that's, uh, the end of my presentation. I would be happy to answer a few of your questions. Uh, you can also add me on Telegram. There is also, uh me on Telegram.

There is also, uh , a Telegram group of ENS developers, which, uh ENS developers, which, uh , I, uh, you can find in the documentation. I can also send you a link. Thank you. Perfectly. Um, and we can take a few minutes if anyone has any questions.

I see some, um, in the chat that I can read to you that I can read to you . Um, I don't know if I'm phrasing this correctly , but can a sub-register or sub-name be under a sub-register? Can a sub-registry or a sub-name be under a sub-... sub-name be under a sub-... Well, I mean, as far as I understand, it's just a question of nested sub- namespaces, and the answer is namespaces, and the answer is yes.

As long as permissions are granted, uh, for the parent, uh, sub-register, yes, then you can have, like, um, sub-registers of, like, um, unlimited length. Perfectly. And one last question here, um, is there a way to use ENS to host the frontend of a website? Website frontend, okay. Um, I'm not an expert on this topic.

Uh, I guess I mean with the frontend, if you want to really keep the frontend completely in-chain, I guess you probably need to figure out how to compress it so that it makes sense, right? I know this topic has been, uh, worked on, but I'm, uh, not up to date on the latest news. But I think if you search, you can find the best practices. And, of course, this is a very interesting application interesting application — to host, to have a complete website in a chain. So, um, that would be a really good topic to explore during a hackathon, I think .

Class. Someone is also asking for a link to the ENS developers' Telegram chat, but it's actually on the screen right now, guys. Just scan the QR code you see in the presentation. Also, is this Javier? I saw you turn on the microphone?

Uh, yeah, I had a question, can I ask it? Uh, of course. I'm curious, for my project, my hackathon project, my hackathon project, I'm going to make a game that I'm really looking forward to. And regarding ENSV2, if I have a profile for each person in my game, is it possible for each user to have, say, Javier.mygame, where mygame is the main subdirectory, and I allow users to connect under it?

Is it better for people to have their own account and then add the mygame part to it? I think you're...okay. I think you're asking about aliases, essentially. You could totally...

so probably the easiest solution would be to have Javier.eth and then every user of your name would be a sub-name of that, right? Like, for example, Kevin.Javier.eth.

And you can also, if it's a game, use text records, data records in these sub-names to store, for example, information that you want to use in the game, right? For example, objects or something else. Okay, that sounds good. Thank you. Please.

Amazing, and I guess one more question I can squeeze in here: can they use Arc with ENS? Uh, I'm not really sure. It depends on what exactly they want to do with Arc. I mean, usually, for example, when it comes to storing addresses or something like that, since the resolution always uses the Ethereum mainnet, you can store anything you want, right? You just need to get the information from the Ethereum mainnet, but whether they can use Arc really depends on what exactly they are trying to do.

And I think if you have any more questions about this, you can ask them on Discord. Mauricio, I see you raised your hand if you wanted to ask a question. Oh, it looks like your microphone is muted. You just need to turn it on. Okay, thank you.

Thank you, Kevin, for your time. I am from Bolivia, from Cochabamba. We want to create an interoperable loyalty and gamification engine based on something we call gift tokens. So, all the rewards, coupons, points, miles, everything that companies want to give their customers to create loyalty programs, we want to convert into tokens. And we are also creating a crypto, let's call it a " loyalty crypto," so that all customers can use the same currency.

In this case, in this scenario, of course, companies need to have a wallet. Every campaign should have a wallet with a budget. And also customers must have a wallet for this. And the wallet will store gift tokens, as well as the crypto we now call "next". So do you think we can focus this project on this part of ENS that deals with wallets, names, or something like that?

Um, if I understand correctly, the obvious application of ENS would be to identify all users of the protocol to some extent. Ahem. There are also...I'm trying to understand what exactly you're building, but I think subnames are the first thing that comes to mind, right? Instead of working directly with users' addresses, you could use the subnames you give them, right?

Yes, it would be very good for customers of these companies and brands to have a wallet with their name on it. This would make each wallet more personalized for both the people and the campaign. What about the paymaster? Is this something we need to address separately from ENS? Or do you have a solution for paying for gas in such things?

No, I think that's something you have to decide for yourself because it's a different level of the stack, you know? So it depends on how exactly you want to implement it. The name ENS is, first of all, just a level of resolution, a kind of address translation layer on top. Okay, we really like this feature that you introduced today. We will think about how to improve this idea to create personalized wallets for our customers.

Steeply. Good.