ENS Labs | From Names to Namespaces: Building with ENSv2 - Yash | Common S3nse - 2026

[music] Hi guys, uh my name is H. I'm integrations engineer at ENS labs and today this uh talkworkshop is for ENSV2. So I'm going to give you a quick demo of uh some of the features of ENSV2. Uh so this talk's name is uh from names to name spaces. Uh so basically the biggest uh difference uh that has uh come in ENSV2 is uh the resistry layout.

So basically uh in the ENSv1 uh there used to be one big resistry which is going to hold uh all the different ENS names and subnames using name hashes. Uh now in ENSV2 uh there are resistries for each level uh and there are resolvers for each names. Uh so for example the uh ETH registry is one registry and then there is like another resistry for uh domain called XYZ. Uh currently we have like integrations withbox. Uh so take it like uh there would be some other uh DNS name uh top level name which would have like a separate registry and then all of the uh ENS names under the ETH registry can have their own uh subregistries which will be owned by the person who is having this ENS name.

Um and each name has a resolver which can be deployed using the verifiable factory contract or can be a custom resolver contract. So uh people can write their custom code of how a ENS name is going to resolve. Now this name will have like a subregistry which again can be a custom contract which will mention how uh the subnames from this uh ENS name are going to be defined and uh can be registered. So let me give you a quick demo of uh how this flow is going to work. So I have uh created this demo uh and I have a few domain names under uh my wallet.

So I'm going to demo with this uh ENS name. I just registered this uh 10 minutes ago. So basically we can deploy a subname registry with this uh ENS uh name and the subname registry is currently this demo suppose is like of these three types which is uh a fully controlled subname registry as in the person whose ENS name it is uh is going to uh own the registry and we'll be able to call the resistor function for creating subnames. Another way would be creating rendable names. Uh so let's say uh base names but if it was on the same network as the ENS contract which is currently on Sapoleia ENSV2 contract.

So the uh the person owning this ENS name will be able to sell the uh subnames using this configuration. And the third one uh I will show is unruggable unexpiring domain. So basically the people who register uh subnames under this ENS name uh their name is uh not going to expire and the resistry is going to be fixed to the domain. So I'll create one fully uh controlled resistry using a fresh resolver. So this would be the layout.

Uh the ETH registry owns uh or has this uh subdomain which is demo subregistry.eth which is going to deploy a new subregistry uh called subname registry which is going to store the records on a resolver contract which is again going to be a new resolver contract whose owner is my wallet. So let's say we want to deploy this. Currently there is um a bug in Metamas which is flagging these uh ENS contracts. We are in talks with them but uh let me just review these warnings and proceed.

So the first step is basically deploying the subname registry. The second step would be deploying the resolver contract. The third would be the pointing uh the name to the registry and then pointing the name to the resolver and then uh recording the parent resolver. Some of the benefits of uh deploying the resistry contract is creating aliases. For example, a person can own two different uh ENS names and then both ENS name can share the same subregistry.

So any uh subdomain created under one uh ENS name are going to be replicated on the second ENS name automatically. And similarly the resolver can be different in uh both of these uh sub uh both of these ENS names using the shared sub subname registry. So the records are going to be different on both of these uh names but the uh the resolver can also be the same. So all the records uh which are pointing to the first category of uh first batch of subnames are going to be the same with uh on the second batch of subnames. Okay.

So now the um subname registry is deployed and also the resolver has been attached. So this is the final layout which is the resistar of this subname registry is my wallet because this is a fully controlled registry. So I as the owner can create subnames using this registry. So let's say test one and I can register this for as many years as I want because uh I own the subregistry which is creating these names. But as soon as my parent name is going to expire, all the subnames are not going to be active anymore.

Uh yeah. So this is minting the name. The name has been minted now. So I can see the subname here and I can set it to my resolve uh set it to my address create its own resolver. So currently the configuration updated uh and uh this subname registry has another name inside it which is test one.

demo demo subre and it is using the parents resolver. Uh it can own its own resolver also but uh so if I want to switch to its own resolver then I have to first deploy its resolver and then I have to point this name to this new resolver. The reason why someone might want to deploy their own resolver is because as you can see in the previous uh resolver, the owner is my wallet. So I uh can create a custom resolver and then update the record based uh for all of the subnames. Uh but if the subname uh deploy its own resolver, then uh he owns the records which are present in this resolver.

So this is useful as like uh if a app developer wants to create uh subnames for its users and they want to maintain all the records uh for the subnames created then they might be using a shared resolver but if for example the use cases like base name where the users own the uh subnames then uh they they might want to deploy their own resolver contracts to own the records inside those resolvers. So now the um configuration has updated. Now this domain owns uh a resolver which is handling the records for the sub subdomain. Now I can use the same uh ENS name and change the uh change the setup to deploy another subregistry. What that is going to do is like remove all the subnames from uh this ENS name and this time I'm going to deploy using the uh standard run table subregistry which is where I can specify the cost uh so let's say 10 USDC for one year and the minimum duration uh is 30 days of uh renewal uh I can continue to review.

So this is going to be the new setup which is this domain is going to have this subname registry which is going to have this new registr contract this time. So basically the register contract is the entry point where the user are going to interact to register the uh subnames under this subname registry and the cost is going to go to the resistor contract which is going to be owned by the wallet who is deploying this right now but it can be a custom contract and uh the cost can be split or whatever. So this time you can see there are like seven actions instead of five. Uh the additional two actions are deploying this resistry contract and pointing this to the subname registry and in the meantime maybe I can open this tab. So I have uh these two domains which I previously uh did some uh deployment for but I'm using the same registry in both of these.

No actually not so this is good. Uh so basically right now for this domain uh subname resistry demo name I have two subnames under this resistry and for this domain uh hyphen 2 I have only one uh subdomain under it the test owned three. So what I can do is uh relink this name with another subname registry which is same as the first name. So basically they are going to share the same subname registry. So I'm trying to create aliases right now.

Uh so both of these names are going to share the same subname registry. So that's why all the subfra names present under one ENS are going to be the same which are present under the second ENS. Okay. So I think that transaction is in the queue uh behind all of these transactions. Okay.

Uh so let me Okay. Now uh both of these names the subname uh subregistry demo name 2 and subregistry demo name are sharing the same registry. So you can see there are two subnames here. And if I switch to the first domain name, there are also these same uh subdomains there and they're also sharing the same resolver. So this has created aliases for both of these subnames and uh yeah I'll go back to the previous example which was creating the rentable uh subregistry.

So I can create subnames now using the resistar not as the owner. Uh in the resistar I can type in the subnames label created for one year. Basically now I'm going to pay for this subname because uh I'm registering it through the register which has the cost of 10 USD per registration and this cost is going to go to the owner of this uh register contract. Yeah. So this name is also registered.

Uh another benefit of using v2 is creating permissions. So these registries can specify certain permissions for the subnames like permissions can include these subnames can or cannot create their own subnames or whether they can deploy their own resolver contracts whether they can transfer the subnames or are they bound to the address they first got created to uh or they can extend the expiry whether they can delete the subnames. So these are the permission which we can specify in the regist uh subname registry contract and also can set up the delegation uh permissions. This these create like this bit map which is storing all of these roles present uh in the registry and also uh the person who is creating these sub subnamed registries can relinquish all the permissions he has to this registry to make it unruggable. uh and another uh thing that the person can do is basically buy the ENS or uh the subname which he is using for this subregistry for a longer uh time period like for example one guy uh he purchases for like 6,000 years and now all the users know that it's unruggable in a sense that he doesn't have the permission to update the subretory also in the sense the ENS this name is not going to expire for the next thousands of years and at the same time you can give all the permissions to the user.

So basically you are creating this naming system which uh people can use and it's automatically going to be supported on all the wallets and you can charge uh the cost if you want like whatever uh this framework can be anything. So basically a person who might own an NFT uh can get a subname. A person who pays for something can get a subname. You can submit ZK proofs to create these subnames. So this subname registry is very customizable.

And yeah that was basically the demo. Uh another uh feature that we have added in the V2 applic. Oh by the way uh these are the two new applications for V2. So uh these are still only on Sapolia. Uh this is the new uh ENS application and there is another which is the explorer application.

So this is more developer friendly and this is more user friendly. Um and recently Greg also announced uh on Twitter but let me also give you a quick demo which is uh creating these ENS name previously required two steps uh one is creating the first transaction and then waiting for the 60cond for the cooldown period and then uh the names are going to be issued and now uh it's just one transactions uh and that two is a signature it's not even a transaction. So basically uh there is a uh wallet uh which is being used beneath this uh so you are just signing a transaction so that the wallet has permission to buy this name on your behalf and then it transfers that name to you. So it registers the name and it then transfers the name to you uh and that to guestless plus it's only one transaction. So yeah, any questions?

Yes. Uh, sorry. Can you repeat? Yes. Uh so that currently can be done using uh CCIP uh read.

Uh although this demo was only for Sapoleia uh but there are a couple of projects which are doing a cross network deployments of uh ENS. Uh I will share some links with you later. Any other question? Okay. Thank you guys.