Deployment of new contracts (inc NameWrapper) to Testnet (Goerli)

Ahh got it, thanks! I didn’t realize that the current ETHRegistrarController would remain as a controller for the registrar (that’s what you mean right?). I know that the registrar has a removeController method, and so that would not be performed as a part of the on-chain DAO proposal for these new contracts.

I was going off of what Jeff said in the first post, so that’s where I was confused:

Anyway I think that resolves my concerns then, thanks! Basically the NameWrapper will just not support really long labels, and I think that’s fine. Or at least I can’t think of any problem with that.


Just thinking out loud though, wouldn’t it be better for future maintainability if the new ETHRegistrarController was made a controller for the registrar as well, and then it could have an alternate method (or flag parameter) to register unwrapped names directly?

Otherwise now we’ll have two registrar controllers to maintain. So if we want to change the price oracle we’ll need to do it on both. And if we want to make more complex price structure changes that requires code changes for the registrar controller, then we’ll need to make changes to both contracts, deploy both, and replace both as controllers on the .eth registrar.

Will my name be able to be wrapped?🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇🦇.eth/details

Nope, that label is 400 bytes I believe

1 Like

Yes this is true for the new .eth registrar controller contract, and also for the new app. Legacy names could be continued to be registered on the old registrar controller contract until the DAO decides to remove it as a controller. We expect to have this contract on there for several months to ensure the stability of the NameWrapper

1 Like

If the old registrar controller was ever removed, then people would have no way to register .eth names directly anymore, everyone would be forced through the NameWrapper.

Could the new registrar controller have a boolean flag (or alternative function) to register without wrapping?

As it stands we know one limitation already with the NameWrapper: no label greater than 255 bytes will be allowed. So if the old controller was ever removed, that would now effectively be a new contract-level restriction on .eth registrations.

1 Like

I can’t see us disabling the old controller any time soon; as long as the pricing is the same and there are no known vulnerabilities, I don’t think there’s a compelling reason to disable it.


Hi all,

Myself and @nick.eth have been hard at working fixing the issue that @lcfr.eth initially reported, and also another issue that @Premm.eth reported. For transparency, Premm was also rewarded a bounty similar to the one lcfr.eth received. Thanks Premm!

In the mean time we found things we could optimise and improve on in the NameWrapper. After much discussion, we have decided to proceed with another audit. This will be the 3rd official audit on the NameWrapper in over 2 years. Whilst this wouldn’t be our ideal situation, each time we have found bugs in the NameWrapper we’ve actually found ways to make it more useful and elegant with more features. However with more features comes increased complexity, and the risk is always increased so we’ve decided to go for a private audit with Code4rena starting 22 November.

Despite the setback, I hope the increased transparency shows we’re dedicated to getting this out and we’re definitely not intentionally dragging our feet.


The new NameWrapper docs are live here: ens-contracts/ at master · ensdomains/ens-contracts · GitHub

If anyone has any feedback/questions on the docs, please feel free to contact me. I will work on a less technical in the future about how parent-controlled fuses have implications on NameWrapper usecases as well once things have settled a bit.