Hey everybody. Um, I'm Kevin Wokemon from ENS Labs. And today I want to give you a short introduction into ENS and into the protocol. And also go into uh a little bit more detail on some specific topics like AI agents and interoperable names. But yeah, first let me start with like a general introduction.
So, what is ENS? Uh, ENS is Ethereum Name Service. So, it's a decentralized permissionless naming protocol that is on Ethereum. Uh, quite well known at this point, I think. Probably have seen people with dot eth names, for example.
But I think also a lot of people don't know yet that uh ENS is much more than that. You can have like a whole uh identity and you can also import DNS names, for example. Um, like the main use case initially, like the problem ENS started with turning complex hex addresses into human readable names, right? So, um I guess that's what ENS is known for by the most people. Um, and essentially like ENS is a user experience protocol, right?
So, like imagine a scenario, somebody like a friend of yours is buying Pokemon cards for you and uh they want to send you 5 bucks. Then you probably don't want to like read out your whole Ethereum hex address. Um, you can send it to them, but then still you have like you need to copy it, you need to paste it, and maybe along the way you have to also think about it, okay, maybe there's like some malicious code running and replacing the address, you know. So, it's much easier actually and I think that much better UX if you have a name attached to it, right? I can just say, okay, my just send it to wokemon.
eth. I think uh a great improvement. And um that's how it started, but really um you can do much more. You can have like a whole profile attached to an ENS name. Uh for example, like this is what my profile looks like.
You can see uh there's metadata like accounts. I have my excellent there, my GitHub handle. There are different addresses like Ethereum. Okay, there's also Bitcoin address. OP, base, and there are much, much more.
And these can also be different across networks. So, in this case all of the EVM uh chains in my case they have the the same address, but it's not necessary. You can have different addresses. You can also have an avatar and uh like much, much more stuff actually. Um So, I guess we've seen this like you've seen this top a thousand times probably before.
You log into a new dApp and this is kind of what you get, right? You connect your wallet, you get like this grayish pill and a wallet address. It's not like a very personalized experience. You might not even really know your wallet address. So, that's kind of it's it's it it can be much better with ENS, right?
It's kind of like this scenario. Uh you're in a sense a customer, but um you're also anonymous in a way, right? It's like um not the best experience. Um but in an ideal world, I'd say it could look like this. You connect your wallet, your avatar and your ENS name shows up, and it's much more personal.
Um So, for example, these are two scenarios uh that are live today like on snapshot.org or matcha.xyz um where this is already implemented and there are obviously like much more protocols that do this. And for example, here you can see like in MetaMask um how it looks like. You enter an ENS name and it gets resolved into the underlying uh Ethereum address.
Also on uh Etherscan you can see out like from this ENS name to this ENS name. But here you actually also see that like ENS names, once you own one of like a .eth name, you can also create like subdomains, right? You have here you have like zk.ens.
like bill.eth. And if you compare this to the to the transactions below, it's kind of like very obscure, right? You have no idea what's going on there. So, all of this to say that users of crypto powered experience should never have to interact with a hex editor.
Anywhere where you read or write to hex editors, you should be able to use an ENS name. So, let me explain you to you how this work. Essentially, there are like two processes at play. The first one is forward resolution. So, that's you have an ENS name like nick.
eth in this example. And this name gets resolved to the underlying address, right? So, here like for example, it's like Ethereum base address, this is kind of like the the most straightforward way. And then there's also reverse resolution where you go from an address back to a name. And together, these two things constitute what we call a primary name.
The idea is that if you have say you own two names like name1.eth name2.eth, um you might forward these two one address, like to your like maybe you have only one wallet address. You both you forward both names to this address. But if you want to go back from the address to the name, it's kind of you have to decide now like what is your canonical name?
Do you want to have name1.eth or name2.eth to be like your canonical name that matches this address. So, once you set this up, you have like a one-to-one mapping from the address to the name and back from the name to the address. And this is what we call a primary name.
So, yeah, one-to-one relationship. And that's something that's live on the mainnet, but also on few other uh chains at this point. Um essentially, I don't want to go too too deep into this, but it works in this way that you set up um your address for the specific chain using a coin type on Ethereum L1. But then you also have to um configure this on the reverse register, which is a smart contract deployed on the specific chain. So there's like um you can see it here in this like uh code snippet.
There's a set name function where you would uh would do that. Um you can find more about this in our docs. I won't go too deep into it, but just for you to understand the idea. So there's something you have to set on L1 and also something on the specific chain. What may be also interesting is that um since you can have different addresses for different chains, primary names can also differ from chain to chain.
Okay. Uh AI agents are something that I uh like um like I'm like most of you, I'm very interested in, and that's also why I want to spend some time thinking about it here. Um we do have two prizes. Uh one is for AI agents and the other one is like creative use of ENS. But I think for AI agents, um ENS is actually the perfect place for them to live because ENS is essentially a registry.
So I would like to think of agents as namespaces essentially. Um in this slide, uh I just drafted like a small idea. Um let's say I have like a subdomain to my name, agent.werner.eth.
And then maybe for major agent uh releases or versions, I do use subnames. I have V1 or V2.agent.werner.eth.
And in the uh parent domain, I might say, "Okay, I put a text record there because you can also have in your ENS name not only addresses as metadata, but also text records. You can set arbitrary text. And um you might have agent latest of V2 and then another agent looks up your agent and sees oh, the latest of V2. I know I have to go down in the sub name kind of tree. And at V2.
agent.work.eth, maybe I find some other uh metadata like uh what protocols it understands, like the endpoints for these protocols, um like maybe a readme.md kind of file that explains what's going on, skill file, any like sort of thing in that direction. Um Yeah, so agent metadata can be stored in your ENS name.
One um example that is already kind of canonical at this point is um the interaction between ENS and ERC-804. You If you have used 804, you might know that um essentially you have to registry like identity registry, and for that um you create this registration and at the same time you also upload an agent registration file, which is essentially like a JSON file with some information. And uh inside of this you have a services um key, and you also can put any ENS name there. Uh the kind of the problem that we were facing was that this ENS name, you can essentially set whatever you want, but there was no way way to verify that you actually own this agent, right? Um so one use of text records as metadata um is to actually say, "Okay, here is a text record key that will serve as the canonical way to attest to this association.
So, if an agent on 804 claims, "I'm associated with this ENS name," then we can verify this by setting the specific uh a record on the name. Um which essentially contains the registry address on a specific interoperable format because 804 can also be deployed on like not only a mainnet but also base OP and so on. And then also the agent ID which is just a token ID like for these kind of contracts. And um I actually uh came up with a small demo that I want to show you. I hope this will work as planned.
Um Let me move this over there. Okay, now I cannot really see it but I'll try to try to understand it. So this is like a web tool that you can also use if you're interested. Um Let me try to push the button. I'm actually not seeing a button.
One second. That's not working. One second. Well, that kind of sucks. Well, I can also explain it to you.
Um oh, there we go. Okay. So, what you can see is um you can put in any ENS name. You select uh you enter an agent ID and um the chain where you have this agent this 804 agent registered. And then essentially um this tool will create for you the text record that is that you would need to put on your name to attest to the uh registration.
And um it will also tell you if this is actually verified from this scenario. The verification loop is closed which means the token ID like the agent behind this token ID in 804 has an ENS service set with this exact name. And also the ENS name has the text record that matches that. So, it's kind of like a closed loop, right? So, there can be different scenarios.
For example, the 804 agent um attest to 4 minutes name, but the ENS name doesn't know anything about that. So, in this case, it would be like one-sided. And also, the other way is possible. It's just 4 minutes to 804. Um which maybe is a little bit less common.
Um but ideally, you would want to have like a closed loop, right? If you want to interact with 804 with your name. So, I think like this is just to show you how you could use these text records in a practical way, right? So, you can use it to store metadata, but you can also use it to to create some sort of like verifiable credential. Okay.
Um let me try to turn to the lights. Okay, there we go. Okay. So, um ah before I forget it. So, I think like AI agents and general AI is like very like very very popular right now, very hyped.
Um but I think there are a lot of things that are not really solved or would need much more work to solve them. One thing is reputation. 804 has on-chain reputation. Um but ironically, it kind of suffers maybe like in my opinion from the fact that it's decentralized. Um Another thing is verifiability in general, right?
So, I would really like to see people come up with like creative ways on how to solve this with ENS. Another uh big thing that just happened very recently is um the deployment of of on.eth, which is the first two-letter ENS name. Um on.eth is essentially an extension of uh ENS names to chain so forth.
So, I was talking before about how would we give AI agents names? And this is also like in a similar vein how do would we give chains names? And um this is kind of how we approached it. So, on on.eth essentially it's just like a normal ENS name but with a specific resolver that serves as a resolver and a registry at the same time.
So, what it enables is um to have interoperable names ERC-7828 in a specific manner so that you have for example you can see it in the right corner vitalik.eth at base. So, it's not you can address like the idea is to address like to resolve a name cross-chain in a manner like to have like a very nice way to store this information in a human readable way um without having to to worry about anything really, right? So, the vitalik.eth um ENS name is resolved like in a normal ENS fashion.
And the the chain label is resolved during using this on.eth resolver. So, this is a resolver that stores metadata about chain. Um for example like you can also store like your chain's X handle there um or the website or whatever, right? So, but like specifically chain label, chain ID, these kind of things are stored there and it enables these sort of names.
So, that's very new. Uh it's not used widely at this point but I think it's like very interesting uh thing that can uh drastically improve UX on the ecosystem. Um so, yeah things you can build. Yeah. You got like a 90% of the TLDs, right?
You can You can use any ENS name. You need a universal resolver like a universal resolver like if let's say I just make chain it's not going to be in your universal or it's not going to be there, right? Ah, that's what you mean. Okay. So, uh it's like this in the beginning, it's kind of like permissioned in a way that there is like an initial path of chains that's part of this um of this chain resolver.
This is kind of a manual part uh currently. But, um the the goal is to have this like um to hand like hand over the administration of these chains to the specific people that are running these chains. And of course, there's uh like kind of we're trying to let people running this are trying to take care that like not every kind of should chain like part of this Uh no, no, no, no, no. Block? No.
I mean, technically like it like well, there are multiple levels to this, right? Like this needs to somebody needs to implement this kind of resolution, right? You can If you If you go ahead and implement like this kind of interoperable name resolution, it's kind of up to you who are you talking to, right? So, um you kind of have to have like some trust that there is no censorship going on in this way because that's quite a point. Um but, you can also always fork or use something else, right?
Kind of. How is it like we can pick our own resolvers? Like does it just bubble up to like what we have now with like Web 2? Like everyone just uses yours, or like how have you seen it play out in like Like I could run my own resolver for my own ENS name now, right? And you just point at my address.
But like how do What do most people do? Well, I guess most people would use like a kind of public resolver at this point. But yeah, you're totally free to have your own resolver. And in the future, actually, uh it's like everybody will have their own resolver kind of, right? So, it's um you this is also about you owning your data and like being fully in charge of what your name is doing.
Can I maybe like can you wait for questions maybe like after that? Okay, let's be quick. A fix you can build. Um AI agents I talked about it. These are kind of the features that maybe are interesting for you.
Usernames in general, text records as you've seen. Subnames also to have like some hierarchy, versioning, whatever. Um wallet, social content, and so on. There are like a lot of features that can be utilized for these projects. Essentially, anywhere you have shows the hex address, it should instead show an ENS name.
But as you've learned, you can do much much more with ENS names besides that. So, let me go into the prizes real quick. We do have two tracks. The first one is best ENS integration for AI agents. Like three different prizes up to 3.
5 ETH. And then the second track is most creative use of ENS, which is um essentially like totally free as long as it's cool and creative, you are eligible for this uh prize track. Yeah, my Telegram, you can just text me, but you can also come over to our booth over there and ask your questions, make a pitch, whatever you want. We are there to help. Thank you.
Automatic transcript — names and jargon may be misspelled.