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

Transcript

Introduction to ENSv2 Identity

[music] Um yeah, hello everyone. My name is Kevin Workerman and the technical writer on the TEFL team at ENF labs. Um today I'm going to give you like a short workshop. There's no coding. It's just like walking through some slides. Um specifically uh highlighting the ENSV2 better deployment of Sapodia. And actually let me say up front we deployed like another set of contracts to Saporia specifically for the hackathon. So I would also like you to kind of make sure that you deploy against these contracts.

They are currently if you go to like docs.ns.domains domains the doc side there's a banner on top which takes you to a feature branch also listing the deployments telling you how to alter the VM or eos uh code uh to make sure that you're actually also talking to these contracts but I will post this into the uh the code channel and also the ENS developer telegram group so just as a heads up so yeah um I'm Kevin let's walk through a few slides I will give a brief introduction into ENS in general and then I will talk a little bit more about the NF2 and what you can manage.

So what is CNS? Um the name service is a decentralized permission as naring protocol that lives on Ethereum and um how did it start? Essentially turning complex hex addresses into human readable names, right? So in a situation um like this then $52, it's kind of hard to like remember like an address like this, right? I think nobody is actually able to do that. It's much easier to just say, hey, um, send 5 UCCC to work on, right? So, we think of ENS as a user experience protocol on Ethereum.

Decentralized Naming on Ethereum

Um, but that's just how it started. Uh, over time, ENS grew and it became also more like an onchain onchain profile essentially. So here you can see my personal um profs profile for my name in the manager app and for example I have my X handle my GitHub handle some addresses um across different chains so it's also kind of like multi-chain in the sense that you can store a base address a bitcoin address whatever like different addresses for people to kind of recover if they know your name and there's also an avatar which you can see here and much much more stuff like for example text and data records that

Onchain Profiles and Multichain Records

you can use to build interesting applications all like kind of contained under like one name. Um, so like one of the most basic applications I think of ENS is kind of like a feature like this when you connect to some D app and you just uh like after you connect your wallet you just have like the Ethereum address there and it's not really like a personable experience. And so what you can do is kind of change it to something that looks like this, right? For this however you kind of need to also not only resolve like an ENS name to an address um because like such an app would know the address but not maybe an associated name. So that's where like the uh reverse resolution aspect comes

Reverse Resolution for Better UX

into play. Um but here you can see for example snapshot.org or match XYZ like two apps that integrate this today. There are obviously a lot more. I'm sure you know lots of apps that integrate ENS resolution and display. Um, for example, like Ephoscan. Here you can see like a brief demo showing what it looks like without ENS and with ENS like at the bottom like just random like addresses, maybe contracts interacting with um this address and it's totally unreadable for a human being. on the at the top you can see okay like there there's a user involved and there's maybe like some contract involved and um I think it's like it's it's much better user

experience right um so the general idea is kind of users of crypto powered experiences should never have to interact with a hex address at all should be as easy as possible and um like ENS provides this naming layer that makes all of the stuff actually understandable to human beings So anywhere you read or write a hex, you should be able to just use a NS name. That's essentially um the idea. So how does it work? I already kind of briefly touched upon like forward backward resol like reverse resolution.

Forward and Reverse Name Matching

So these are the two main processes that we are kind of um that are the core of ENS on tracks. Forward resolution essentially you start from an ENS name let's say Nick. and you kind of resolve this into an address, right? So like an Ethereum address, a base address, something on optimism mainet. In this case, I think on the slide, I kind of forgot to change uh the addresses. So they can be different obviously, right? I mean, they are all EVM and so served by the same private key, but you can also store a different address if you wanted to. Then there's reverse resolution. This is the feature that would be used if you connect to to an app, right? That only

knows the uh wallet address, but you can also point that back to an ENS name if you like configure a reverse record. And so because this is a very useful concept, we have a name for that and it's called primary naming. you have reverse resolution and forward resolution. So the um ENS name pointing to an address and the same address pointing back to the ENS name, you have kind of like a loop and that's what we call primary name. Um yeah, so let me go to get to ENSV2. So a few weeks back we deployed finally the ENSV2 battle contracts on Solia and people have been playing around with

Primary Names Explained

it already. for this hackathon because there are also like some changes coming up. We wanted to ensure that there's a stable environment for the duration of the hackathon. So we deployed the whole new set of uh of contracts that you can use and will like the set of contacts will not change over the duration of the hackathon. Um whereas like the kind of main deployment might might change depending on like some fixes before mainet. But let me get into what's new in V2. So first of all the I guess kind of the most obvious change is that ENFV2 had like one flat registry structure which means if you know about subnames for example like here's lis. And subs

ENSv1 Flat Registry Structure

which is a subname of lis. similar to subdomains on on DNS. All of these uh all of these this kind of tree structure that exists on this name space um is was encoded in one flat registry using the name hash algorithm which at the time of release was a very nice and efficient approach I think um to kind of the problems you face uh when you're programming for blockchains but over times uh grew people wanted to have uh certain features in y names became much more interesting for people also.

And so ENSB2 kind of is a whole redesign taking all of the lessons we learned over the past like almost 10 years at this point. And um at this now in ENF2 this hierarchy actually like those three structures actually visible in the smart contracts. So on the right hand side you can see um kind of like a schema on how how it would look now right there's a root registry then there's a leaf registry. Ellis has her own registry if she wants to bought maybe two and so on and so forth. So it's like really like a nest kind of thing and um also the general setup changes.

ENSv2 Hierarchical Registries

So say you buy an ENS name and um what you can do is generally the idea is that you would deploy your own resolver um whereas in NSV1 generally people would use public resolver by default like a shared resolver among all names. There was always the option to just deploy a custom resolver but it's kind of was like optional. Um for V2 the um default is essentially you deploy your own uh resolver and this resolver is um deployed like it's a shared proxy thing.

Custom Resolvers and Shared Resolvers

So there's one implementation and you just deploy proxy essentially and this is done via a smart contract called the fire variable factory and then there's another um thing that you can do you can deploy your own subreg so there's a separation between like registries and resolvers and the subregistry um similarly you also deploy varactory but um you might not need it. It kind of depends on your use case. can essentially think about it like if you want to have subnames and also tokenize them then you would deploy a subname registry or maybe you also want to give like different kind of permissions for these subnames then it makes sense to

Subregistries and Wildcard Resolution

deploy a subname registry. You can also go the approach of like just taking a resolver and do what's called white card resolution. Essentially you have records inside this resolver for um for certain names but then they might not be tokenized. It's just kind of to store data for these subnames. Um so one setup kind of can look like this. There's also a guide in our docs by the way on how to do this. So this is a setup. For example, Nick. deploys his own pl registry and then on top you do have um a register contract even so it's like one contract more so you have a resolver subname registry and register

the registar is a contract that you use to configure how can people buy or obtain a name in your subname registry right like for example in this and on this slide it says five USDC per year but you can be um very creative on on what you want do, right? You can say, I don't know, maybe they need to own some NFT or do something else uh to be able to claim a subname in your registry. And then you can also configure these um subnames uh with permissions. So for example, give them the permission to deploy their own resolver to have their own subreg. You can think about like configurations where subnames cannot be

Granular Permissions for Subnames

transferred. You can think about a configuration where actually it's kind of like for weather names. So the parent name has a long very long expiry into the future and uh kind of uh drops all permissions to interfere with the subnames in some way so that these subnames are essentially like emancipated below the subregistry. So there's a lot of room for activation there. I think uh another thing that people will um probably notice very quickly is the new token ID structure. So we have mutable token IDs in NSV2 which is essentially um related to the new permission and RO system. It's

Mutable Token IDs in ENSv2

called EC enhanced access control and this system allows you it's a role based system. Usually you have like a role and an admin role and you can give certain permissions. I already mentioned like setting your own resolder, creating your own subreg and so on. Of course, for these kind of things, um it would be kind of like let's say you wanted to offer an ENS name for sale. It would kind of suck if somebody uh says, okay, this set of permissions is included with this token and if transferred to the new owner, but then um after listing the token, they would just change the set of permissions, right? And essentially scam somebody. So whenever uh votes are granted or revoked on a on a token, the

token will be destroyed and minted again to the same owner. So and the token ID will change as well. So that's something that you need to uh consider in your projects. If you transfer or just renew a name, nothing will change. The token ID will be totally the same. And then there are some edge cases. For example, name expires or pre-registered token ID also changes. All of this is described in our V2 dogs. So why should you be excited about the NSB2? I think um if you hack a little bit with the NSB2 you figure out that V2 is much more flexible but also much cleaner in its design as compared to ENF1 and for example nameweber and that's um kind of the reason why it came into existence. B1 like ENS grew over

time and people had a lot of ideas on how to utilize ENS and um changes have been had been made to kind of accommodate for this but obviously like a lot of the applications were not obvious in the in the beginning right so we too with all of the lessons learned is kind of a total um redesign of the whole infrastructure and so I think it provides much more flexibility and um you can be uh creative improve it. And uh then the permission system that I already mentioned, enhanced access control also gives you the ability even to be um to give somebody the permission to change like a single text record or like uh change the avatar for for a name

Role-Based Permission Controls

for example, right? So it's um much more granular as compare compared to what was offerable before. And then one more feature I think that's worth mentioning is aliasing. Uh there's actually two uh features because there are two types of aliasing in NV2. One is um sharing records. So text records, address records, you can point two names to the same set of records and they re will resolve identical changing the record then like for example changing an address uh will change it for both in in terms of revolution right so they actually like they are alfs in a sense and then there's also registry level aliasing which means you point two ENF

Registry-Level Aliasing

names to the same subregistry which means let's Say Alice and Bob do both point to the same subregistry and in the subregistry you have tokens with labels ABC. Then after um you alias these names both Ellis and Bob will have a b. And for Bob it's the same a do. And so on so you can hard name spaces which also I think is very an interesting um application. So um a few more uh slides on things that you can can do with ENS. Um even with ENS1 of course AI agents have been like very popular over the past

hackathons. So I personally like to think as agents as namespaces. So for example you have um here my name recommen.e and I would have a subdomain agent. Then I might um have more subnames even like one one level lower like V1 or V2 different um versions of the same onchain agent and at the parent name I might point to the latest agent for example V2 in this case right so in this sense um you can think of agents as name spaces you can use data or text records to store certain information about these agents in your ENS name one example is ENSIP25 which allows you to make a two-way loop

ENSIP-25 and ERC-8004

between an 804 agent registration. So you would kind of point at the registry, give the agent ID, and then you can uh you can kind of verify that if there's an 804 agent and it carries an ENS name as a service uh in its agent registration file, then you can point back from your ENS name and say, okay, yeah, I kind of I consent to this 804 agent using my ENS name. Right? So that's also a way how you can bridge kind of in this 804 ecosystem. But there's also ENSIP 26 which is um kind of on its own. Uh it's not um displayed here. But the idea is essentially that you can store an endpoint for an agent in a text record or a context. Right? So

ENSIP-26 Agent Endpoints

for example you want to give an agent to agent endpoint then you can just store this as a text record that standardized under ENFP26 and your ENS name. And obviously like these are just like standards that have been kind of um agreed upon at this point but you're free to just come up with your own standard. So like a short overview um of things that you can buy uh build AI agents I I told you already about it. Um use user names text names wallet applications also. Um I think from my perspective it makes sense to integrate ENS and and wallets by default because it increases user experience a lot. Um social applications also it's a very popular

you can use ENS names even kind of as a kind of a decentralized database if you want and show ENS names as usernames. And then uh another topic is content. Um there's a thing called content hash. It's also like um a piece of data that you can attach to an name and uh use IPFS for example to build a decentralized website that is kind of behind your name, right? So that's also a very interesting application. Um generally anywhere you have shows a hexodus it should instead show an ENS name.

ENSv2 Hackathon Prizes

So let's get into the prizes for this hackathon. We have um a oneup price $500. Um maybe I should mention probably we have kind of two tracks. One is best views of ENF2. So we really want to focus on ENF2 and hackathon and um uh see what uh you uh what you build. Like we're very excited to see um how creative you can get with E2. Um so that's a runout price um 500 bucks. Then third price 1,000 bucks. And first and second uh price both 1,500.

And then for the continuity track, there's um 500 bucks. The uh continuity track maybe to uh kind of highlight it here, it would make sense that you then use actually the not the hackathon deployment of V2, but the kind of realia deployment. The idea is that you integrate ENFV2 into an app uh that already exists um in a sensible way and so uh make it ready for the ENFV2 mainet deployment.

Um yes, that's uh the end of my presentation. Happy to answer a few of your questions. Uh you can also add me on Telegram. There's also a Telegram developer group for ENS which uh I you can find in docs. I can also send you the link. Thank you. >> Amazing. Um, and we can spend just a couple minutes here if anyone has questions. I do see some um just in the chat that I can kind of read out to you. Um, I don't know if I'm saying this correctly, but can a subregistry or subname be under a subregistry?

Nested Registries and Subnames

Can a subregistry or subname be under a sub? Well, I mean, as far as I understand, it's just asking about like kind of nested subname spaces and the answer is yes. As long as the permissions have been granted uh to the parent uh subregistry. Yes. And you can have like um in like of length in infinite length subregistries. >> Amazing. And then just one last question here. Um is there a way to use ENS to host website front end? >> Website front end. Okay. Um, I'm not an expert on this topic. Uh, I think I mean the the front end thing is essentially if you want to actually store the front

end fully on chain, I guess you probably need to kind of figure out how to compress it in a way that that makes sense, right? I know there has been uh there has been work on this topic, but I'm not uh on the latest on that. But I think if you look into that you can find some work and for sure it's like very interesting application to host like to have the full website on chain. So um that would be like a very nice topic to explore during hackathon I think. >> Nice. Um someone's also requesting for the link to the ENS developer telegram chat but that's actually on screen right now guys. Um so just scan that QR code there that you're seeing on the presentation. Um also is that Javier? I saw you unmuting yourself. Uh yeah, I

had a question if it's all right if I ask it. Um >> sure. >> I was curious. So for my project, my hackathon project, I'm going to be making a game that I'm kind of excited for. And just on the ENSV2, like if I'm having like a a profile for each person in my game, is it possible for me to have like say like like every user would have like a Javier.mmyame and like the my game is like the main subdirectory and I let users connect beneath that or is it more so like people should have their own account and then they'll add the like my game uh like part to I I think you okay I think you're asking about subnames

Game Profiles With ENS Subnames

essentially. Um so you can totally I mean it would be like I guess the most straightforward solution would be to have Javier. And then have like every user of your name be like a subname of that right like Kevin. teeth, for example. And you could also, if it's a game, you can use text records, data records, and these subnames to store, for example, information that you want to use in this game, right? Like item stuff or whatever. >> Okay, sounds good. Thank you. >> There we go.

>> Uh, amazing. And I think just one more question I can fit in here is, can they use Arc with ENS? >> Um, I'm actually not sure. It kind of depends on what exactly they would want to do with ARC. I mean generally for example when it comes to kind of storing addresses or whatever. Um since resolution always uses Ethereum mainet you kind of you can store whatever you want right you you just have to get the information from mainet but if they can use arot kind of really depends on what exactly they're trying to do.

>> And I guess if you guys have any questions about that further you guys can ask in the discord. Um I do see Mauricio you have your hand up. um if you wanted to ask a question. Oh, I think you're muted. You just have to unmute yourself. >> Okay. Thank you. Uh thank you Kevin uh for your time. Um I'm from Bolivia from Coachabomba. Um we want to build uh an interoperable uh loyalty and gamification engine based on on something that we call gift tokens. So every rewards, every uh coupons, points, miles, whatever the companies want to give to their customers to to create

Loyalty Programs and Wallet Identity

loyalty programs programs, we want to convert in in tokens. And also we are creating uh a crypto let's let's call like loyalty crypto so that all customers will share the same crypto. In this case, in this scenario, of course, uh companies, they must have a wallet. Every campaign must have a wallet with a budget and also the the customers they have to they should have a a wallet for this and the wallet will keep the gift tokens and also the crypto that we call uh the next at this time.

So do you think that we can um focus uh this project in order to to have the the the this part of the N the ENS um feature about wallets uh the the enomes on on those things. Um, if I understand correctly, well, like I guess a kind of obvious application of ENS would be to use subnails to some extent for the users of the protocol. Um, there are also I mean it's kind of I'm trying to still understand exactly what you're trying to build but like I think subnames is the first thing that comes to mind, right? So instead of having of

of actually working with the addresses of the users, you could use the subnames that you issued to that point. Yeah, it will be very nice for for this companies for these brands customers to have their wallet with the name. So it would be more uh personalized every wallet for the people and for the campaign uh that and what about the pay master is something that we have to solve besides the ENS or do you have a pay master solution to pay the gas and those things? No, I think that's yeah that's something that you have to solve because that's kind of like a different level of the of the ST, right? So it depends on how exactly you want to want to do it. The ENS name first of all is just kind of like a resolution layer

Paymasters and the ENS Resolution Layer

like a discoverability layer to translate addresses into >> on the top. Okay, we we like a lot this this feature that you present today. So we are going to to figure out how we can make better this idea in order to have a personalized uh wallet for for this for these clients and customers. >> Cool. >> [music]