ENSv2 - Identity for Apps, Agents & Beyond | Kevin Krone at ETHGlobal Tokyo 2026

So, my name is Kevin Walkham. I'm from ENS Labs. And over the last year we have been working on ENS V2, which will be a new version of ENS that we will release very soon, but you can already test it in Sepolia right now. Today I will briefly tell you about ENS itself, if you have n't heard of it yet. I will also delve into the details of ENS V2 and tell you what directions we have at the hackathon.

So, to start: what is ENS? This is a definition that I once memorized once memorized . Ethereum Name Service is a decentralized, permissionless naming protocol based on Ethereum. True? To make an analogy, it's like DNS for Web 2.

0. And the initial idea was quite simple. It was about converting complex hexadecimal addresses into human-readable names. Again, similar to how DNS on the Internet translates IP addresses into domain names. So I like to think of ENS as a user experience protocol.

To me, it's like infrastructure on the Ethereum network. And in some of the best use cases, you don't even notice it's there. It just works. Er... I'm giving this example to explain why this is useful.

If you want to send me five dollars, you can use this address or just send it to my name ENS, which I think is much easier to remember. But this is just the beginning. Today, ENS has become much larger. It has evolved over the years, and in essence, ENS also allows you to have your own network user profile. This is my profile photo in the ENS manager app.

As you can see, my X account is connected here and my GitHub nickname is specified. You can have addresses for different networks, not only EVM, but also, for example, Bitcoin, as in this case. You can store your address there, and a wallet or other app can simply retrieve that information from ENS on the Ethereum mainnet, and the wallet can use it to, say, send bitcoins to that address bitcoins to that address . So, this is one of the things . So, this is one of the things you can do.

We'll move on to other possibilities a little later. Hmm, but just to give you an idea of ​​what it grew into. Hmm, yeah, maybe a few examples of what a typical ENS integration looks like. If you connect to some DApp, the typical thing you usually see is you connect a wallet connect a wallet , and if you're connected , and if you're connected , you see a little avatar with your address, right? With any ENS integration, it could look like this , right?

You take an avatar that is stored in a thread or referenced in the title of your ENS and display it to the user to make your app's interface more personalized. Here are two examples of applications where this already works: snapshot.org, match.xyz, but there are many other applications that use this. For example, here is Etherscan.

You can see the difference between using ENS names and just regular addresses. In one case, you understand that it comes from here, goes there, and so on. With addresses, you don't really understand it, do you? So, basically, the idea is that users of crypto services should never have to interact with a hexadecimal address, right? Getting back to the point that ENS is essentially a protocol to improve the user experience.

And yes, anywhere you see a hexadecimal address, you should be able to use the ENS name. So, how does it work? I've already touched on the technical side a little. There are two processes. One is called forward resolution, which is a common name in the ENS world.

You start with a name, such as nick.eth, and resolve it to an address. This could be an Ethereum address, a Base address, an Optimism address, or even a Bitcoin address. In this example, the addresses are the same, but they can be different, right? You may have, for example, a completely different Base address completely different Base address .

So actually, when address resolution happens, this direct resolution, you provide information like the chain ID. This is not exactly a chain identifier, but essentially it is —you specify exactly what address you want to get during this process. And there is also reverse resolution resolution —that is, yes, the reverse direction, from address to name. And, uh, if we combine the two, we call it the main name. So main name.

So , it's a two-way process, and it's actually the same thing that's used in the examples I showed earlier, where after you connected your wallet, you saw your username and your avatar, because the wallet, of course, goes back from address to name, right? So, yeah, let me tell you a little bit about ENSV2. ENSV1 was quite popular and, I think, quite established in the ecosystem. V2 is a complete redesign of ENSV1. And this became necessary to some extent , because ENS appeared very early, in my opinion .

This was one of the big projects in the, so to speak, "infancy" of Ethereum. Over time, the applications, the things people used or wanted to use ENS for, changed. ENS had to evolve with this, but of course, at some point, because it wasn't designed with such applications in mind, some shortcomings arose. And ENSV2 takes all this experience into account and embodies it in a completely new structure. Perhaps one of the most obvious differences is that in ENSV1 you essentially had one flat registry structure, meaning that even for subdomains like you see on the left, like alice.

eth, that's the name you're buying. If you have a subdomain for it, such as sub.alice.eth, all of these records were stored in the registry as a single smart the registry as a single smart contract on Ethereum. And in fact, the in fact, the parent-child relationship was more or less encoded in the name hash—it's a specific algorithm that's used to hash such names.

But in ENSV2 this is done explicitly in the blockchain. So, at each level of the hierarchy, you actually have smart actually have smart contracts that are registries in themselves. And, probably, you have to get used to it. Also, these registries technically don't know where they are in the hierarchy, because they never store the full name store the full name , as they did in ENSV1. They only store labels.

That's why, that's why you can see these little labels here: Alice little labels here: Alice , Bob, or whoever. The registry is mounted at a specific position in the ENS V2 hierarchy, but you can unmount it and mount it elsewhere. And suddenly another name begins to exist, right? This gives you much more flexibility, as you can take a subtree of the hierarchy, detach it, and attach it elsewhere without losing data or infrastructure. In general, when working with ENS V2, you typically use two types of smart contracts types of smart contracts .

One is a resolver, and the other is a subdomain registry or a custom registry. The resolver is your own contract. You deploy it yourself. In ENS V1, the so- called public resolver was used by default. A resolver resolver was used by default.

A resolver is a contract where your ENS name data is stored. I used to show a profile: it had my X-handle, website link, avatar, etc. All this data is stored in the resolver contract. In ENS V1, this was the default public resolver, although you could use your own. But that wasn't standard practice, was it?

In ENS V2, deploying your own resolver instance became standard. It is deployed through a factory proxy factory proxy contract. It is cheap, allows you to store all data, and opens up wide possibilities for customization in ENS V2. Similarly, if you want to tokenize subdomains, you can deploy a sub-registry deploy a sub-registry . This allows you to expand the ENS V2 hierarchy that you saw earlier.

For example, here is Alice's registry. You can deploy such a registry contract to tokenize subdomains. Yes, specifically for tokenizing subdomains. Although this is not mandatory. You can create subdomains through the resolver: as soon as you write data to the resolver, it starts to be recognized.

So, if Alice decides she wants to use sub.alice.eth, she simply tells the resolver, " tells the resolver, " Hey, set up an Ethereum Hey, set up an Ethereum address for this subdomain name." And it will resolve in ENS V2. That is, it seems to appear on the network.

The only thing is that it is not yet tokenized. So the decision in ENS V2 is whether you want to tokenize your subdomain names. If you just want to use subdomains, for example to receive payments on another blockchain or for something else, and you want to have a short identifier, for example base.pay.alice.

eth, and just store your address there to make it easier for people to find you. You don't have to tokenize something like that. Although, of course, it is possible. You can expand the user registry. And in this case, you also get a token.

But in general, I think registries only make sense if you want to give out subdomains to other people. In particular, a new system has been implemented in ENS V2. Permission system. We call them roles. You can define specific roles for names at both the resolver level and the registry level.

And these roles give the user the ability to perform certain actions. For example, there is a role that allows a user to extend the name's expiration date, or set a resolver to point to a different smart contract, or create their own sub-registry to also issue subdomains. By having this structure, for example, where you place a registrar contract on top of your subdomain registry, you can automate this entire process. You can, for example, prohibit people who register subdomains in your .eth domain from transferring them to others, meaning they will be " meaning they will be " tied" to the owner.

This is what you can do. Or you can prevent them from installing their own resolver or creating their own sub-registry, and so on . So when designing such a system, you can think about what permissions make sense for you. This way, you can customize the entire subdomain space the way you want. But you could also be extremely liberal and say that they have essentially the same rights that you get when you buy a .

eth name. You can do whatever you want with it. You might even want to register your father's name for, I don't know, 100 years, so that it actually never expires. And then you can give away sub-names for free sub-names for free . So they become kind of eternal names, right?

So, there are a lot of different things you can do, and I find them quite interesting. But in general, the thing to think about is whether you want to tokenize subnames or not? Do I need to deploy a registry, or if I just want to use the subnames as entities with data for myself, can I do that already using the resolver? Another thing that is new in ENS V2 and that I think takes some getting used to is that in ENS V2, tokens, i.e.

names in these registries, have an immutable token ID. So, they are essentially ERC-1155 standard NFTs are essentially ERC-1155 standard NFTs , but with a token ID that changes. The reason for this is that with this permission system that I was talking about, you need to make sure, for example, that if the name is put up for sale, you're not essentially being scammed, right? So you want to make sure that, for example, when granting and revoking these permissions, a new ID token is created. So, what happens behind the scenes is that the token is regenerated.

The token is destroyed and reissued to the same owner without their knowledge, but the token ID changes. So if someone puts it up for sale on OpenSea or anywhere else and then changes the permission to defraud the buyer, the token will be destroyed and regenerated with a new token ID, and the offer will become invalid, right? So, for the most part, things like token ID variables are something you don't usually touch, I guess. But it's good to know about it, isn't it? Because you cannot assume that the ENS name has a fixed, i.

e. permanent ID token. It will change depending on different actions. But if, for example, you simply pass on your name to a friend or someone else, the ID token remains unchanged. So it's really just a thing that has to do with the name expiration and the owner's permissions model.

So, yeah, why should you be, why should you be excited about ENS V2? So, ENS V2, I think mostly for me, provides a lot of flexibility compared to ENS V1. Many things for which you had to deploy your own contracts in ENS V1 work out of the box in ENS V2. This sounds a little technical because I'm trying to explain the technical side, but in reality, if you buy an ENS name, deploy a resolver, and so on, you have an interface where you just click a button and everything happens automatically. So, you don't have to do much unless you want to.

The ENS V2 documentation has code examples for all of these things. How to deploy a resolver, how to deploy a user registry, how to delegate rights, etc. There are code examples for all of this There are code examples for all of this . The permission model, by the way, is very interesting, especially in the context of this hackathon, because you can do this: I have a resolver that has, let's say, 10 people on it, and my product is a payment processing agent that provides each of them with their own Bitcoin address, and when they receive a payment, a new address is created for them . They seem to be rotating Bitcoin rotating Bitcoin addresses, right?

But actually automatically actually automatically . You can give this agent permission to access only one of these records, just the address record, and they won't be able to do anything else. He can only change these addresses, right? I recently wrote a blog post on this topic. This is just an example, of course, but this permission system...

permission system... I'm sorry. It is very powerful in what you can do. For example, what an agent is allowed to do. Yes?

And there are also aliasing, which is also quite interesting. Aliases are essentially the ability to share records between names. So, there could be a standard entry that you want all names to have immediately upon registration. And then maybe later they can use their own records, but initially they default to shared records. Or you have certain settings for your brand.

And you want certain names to also have shared records or something. So this, in my opinion , is also an interesting feature. Yes, maybe I'm fast, I still have a little time left. So the agent as a namespace—that's also interesting. Try using subdomains for your agents.

There are also already several specifications that link different standards. ENSIP 25 links 804 and ENS. Ahem. Maybe faster. So, what can be created?

AI what can be created? AI agents, a lot of things related to AI related to AI agents. Use usernames, text entries—this is very important. Also data records, subdomains in general. If you are creating a wallet, then of course you can use usernames, avatars, primary names.

Or you are creating some kind of social platform. Again, ENS—it's also about identity, right? So, usernames, avatars, and things like that can be used there too. And perhaps one underutilized area is content. There is also a field called content hash that can be used for decentralized websites.

So, maybe so. It's something like a credo. If your app shows a hexadecimal address anywhere, it should show the ENS name instead. Let me quickly move on to the prizes. We have two directions.

The first is the directions. The first is the best use of ENS V2. 1000 for third place. 2000 for second and 3000 for first place. And for the continuity track—1,000 for the first and second prizes and 2,000 for the finalists.

Yes, this is my Telegram, and there is also a Telegram group for ENS developers. Feel free to come to our stand or write to me on Telegram. Yes. If you have any questions, I'll be happy to answer. What is a continuity track?

What is a continuity track? I mean, are you familiar with the general system or are you asking specifically about ENS? What are your rewards? The idea is that... The idea is that...

maybe to clarify, it's good that you ask. Well, ENS V2 is not running on the mainnet right now , right? ENS V2 is located in the Sepolia network. So, for the continuity track, you can extend an existing application or project to integrate with ENS V2. Which is a bit tricky since ENS V2 is not on the mainnet right now.

But again, it depends on what project you are working on. Maybe you can integrate ENS V2 to bring it to a state where once it's launched on the mainnet you can just flip a switch, right? And then integrate it and run it. As for the continuity track, I think we're a little more lenient about what we allow to be done, right? Because ENS V2 is currently only in Sepolia.

Yes. Yeah only in Sepolia. Yes. Yeah . What worked for me?

What work remains? Well, there were several stages of the audit, right? And we also need to work on migration. Or are there different stages of this migration. And so, yeah, I think that's the biggest part of the job, right?

Anyone else? Good. Thank you.