letās go. Good protocol to go for.
1 Like
Hi @nxt3d how about collaborating in this mission?
We are developing contracts of ENS compatible domain that can cross-chain across L2 from scratch. This enable us to implement new cutting edge technology and solve any unnecessary complexity and pain points of the ENS contracts.
With this we can solve pain point you faces while building on top of ENS in ETH mainnet. I have remember a long time ago that ENS fuses system doesnāt allow parent controllable and other fuses like cannot transfer to be burned at the same time. Which close the door to many use cases.
Our concept for ENS scaling to Optimism is to point .eth on L1 to .op on L2 through CCIP gateway solution. This way, developers just need to build on top of .op on L2 and all records and subdomains will be reflected to the .eth on L1 automatically through our CCIP gateway. Developers donāt need to know or worry about the gateway implementation at all. Their experience will be similar to building on top of .eth on L1.
We will develop the core ENS contracts on L2 (which many new features), host CCIP gateway and develop the resolver contract on L1.
This way you donāt need to develop registry, resolver and gateway system. Only left is to develop an unruggable subdomain registrar that other developers can inherit (on top of our .op registrar) and the interface to register subdomain.
Our in development smart contract is available at GitHub - Opti-domains/modular-ens-contract: Modular and cross-chain ENS implementation by Opti.domains
Feel free to reply to this post if you are interested to collaborate.
1 Like
Any combination of fuses can be burned in the NameWrapper on L1 currently, as long as some conditions are met, in one transaction. Which use cases?
Are you talking about a subdomain of .eth? If yes, this is definitely possible.
We are currently aligning our efforts, with the expected development of an official ENS L2 registry on Optimism, that will allow for the development of custom resolvers and registrars.
For this reason, this proposal doesnāt include writing a new registry, but could include writing registrars for specific use cases. We are focused on basic use cases including renting subnames, free subnames, and selling subnames, such as tim.opcommunity.eth. We also contemplate providing a dapp interface for teams that want to offer subnames and donāt want to make their own front end.
3 Likes
Itās any use case that involves transferring subnames to somebody but preventing them from reselling or transferring it to someone else and later, the parent can transfer subname back or transfer to someone else according to the logic specified in the subname registrar.
In this case, we need to burn CANNOT_TRANSFER but not PARENT_CANNOT_CONTROL. This is not allowed in ENS because, at some time, the parent can transfer the name to someone else, so it conflicts with the burned CANNOT_TRANSFER fuses.
For example, for the name renting, we allow renters to set resolver records but canāt transfer, set resolver, and register nested subnames. After the rent is over, the domain owner can claim the name back which involves the parent transferring the name back that conflicts with CANNOT_TRANSFER.
In addition, we need to clean up all resolver records in the name renting use case after the rent is over.
Yes but in a way thatās not being explored. Developers will develop a registrar contract on L2 to register *.netflux.op for example. Then link netflux.eth to netflux.op. When someone registers handsome.netflux.op on-chain on Optimism, he will also get handsome.netflux.eth resolved through the CCIP gateway.
UI can hide .op things and only show .eth things which makes UX the same as .eth subdomain registrar UI.
I feel like ENS is against the idea of deploying an official ENS registry on L2. At least in this discussion which should be directed to this deployment but actually, itās ended up discussing about CCIP gateway again.
I will get into this discussion once our technical document is ready.
We also want to build .eth registry on Optimism but safer to avoid political problems.
Itās not a bad idea to use a registry on Optimism unless ENS is going to deploy it. IMO
The Grants Council has opened early submissions as an Indication of Interest for this mission request here
For your application to be considered, the Mission request must pass the Token House vote on February 14th. Early submissions will not be considered if a Mission Request is not approved on the 14th.
2 Likes
Agree this is an important step & good use of gov budget.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
1 Like
Scaling ENS to optimism is a good mission request and would help the ecosystem if accomplished so I am voting for it.
4 Likes
I voted for this proposal, Iām very excited about scaling ENS to Optimism.
4 Likes
Hey, the milestone adding template hasnāt been working since yesterday. Theyāre requesting a field called āToken,ā but the field isnāt editable. Does anyone know what happened?
1 Like
Very glad to see this proposal has gone through! We just applied for a builders grant and will most likely integrate this solution once itās ready. It will allow us to extend our entire platformās (Namespace) functionality to Optimism, thus allowing every single ENS Name owner (communities, games, wallets, individual ENS name owners, etc.) to easily customize, manage, and issue Subnames on OP.
1 Like
Hello! good job sirs! SĆ©e you soon !
This is fixed sorry for the delay and the bug.
1 Like
donāt worry, I saw your comments on charmverse and I was able to adjust everything, tysm
Ready for this ! Letās go!
1 Like