Are you talking about approving the NameWrapper as an operator?
Call setApprovalForAll and use the NameWrapper address, currently 0xEe1F756aCde7E81B2D8cC6aB3c8A1E2cE6db0F39 on Goerli.
https://goerli.etherscan.io/address/0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e#writeContract#F1
Then you can call wrap on the NameWrapper to wrap any name you are currently a Controller for (as long as it isn’t a .eth 2LD)
Thank you @serenae .
I could successfully wrap 3ld domain with your help.
I could check that controller of 3ld is Namewrapper’s contract address (0xEe1F…) but not only I want to wrap it but also want to set that subdomain as primary name. But in ENS app website, it seems it cannot be edited because of the controller is Name wrapper contract.
Is it possible to do it?
The current UI is not hooked up to all the correct contracts on Goerli, that’s why.
But you can go directly to the current Reverse Registrar contract and set it manually: https://goerli.etherscan.io/address/0x9a879320A9F7ad2BBb02063d67baF5551D6BD8B0#writeContract#F7
Contracts have been redeployed to Goerli testnet after an issue I discovered during testing and the addresses have been updated above.
The issue had potential for names to burn themselves. If a user mistakenly thought that the ERC721 expiry represented the wrapper expiry, since they can now be unsynced (using the old controller). Once the name expires in the wrapper, the name would now have no owner on the wrapper, and the ERC721 is still owned by the wrapper, making the name inaccessible. Although this required the user to self-inflict the attack, it presented a large enough UX downside that I looked into various low-impact mitigations.
The mitigation itself is 2 lines of changes, which is about as low-impact as it gets. It allows unsynced names that are unexpired on the .eth registrar (but expired on the wrapper) to be resynced without having to wait for the name to be expired and losing ownership. The API of the contracts has not changed at all and the mitigation can be seen here: Allow expired names in wrapper but unexpired in registrar renew by jefflau · Pull Request #191 · ensdomains/ens-contracts · GitHub
I would like allow another 2 weeks from today to allow for additional testing. Thank you all for your patience!
I notice during the migration process using the alpha ens app it also migrates data to the new public resolver. What is the benefit of doing this for the user and is it required for the name to be wrapped?
Any name can use any resolver, but, it will be necessary to use the new Public Resolver to use the V3 app to edit records.
The Name Wrapper needs to be able to update the Public Resolver. The old public resolver doesn’t know about the Name Wrapper so can’t be updated by it unless an approval was made for every user which is a transaction that would require gas.
Sorry it maybe a dumb question to ask, how can I access the goerli subgraph?
Technically, no. You can migrate and continue to use your name as normal. As Premm points out the records won’t be updateable until you migrate to a resolver that is Name Wrapper aware. The reason for this is how the Name Wrapper works - it takes over ownership in the ENS registry. The original Wrapper unaware resolver uses the registry to check who owns the name and allows you to update records. Once the name has been wrapped, the name will always be owned by the Name Wrapper. Therefore if you want to be able to update your records, you need a new resolver. As soon as we release, the only resolver that will know about the Name Wrapper will be the public resolver, but if you know you want to use your own custom Wrapper aware resolver (or a resolver that doesn’t need to know such as an owned resolver), you can wrap without updating to the new public resolver.
I think so. Can you make a PR for this?
I have been working on making sure that we get delegation, similar to registrant and controller in the new NameWrapper and V3 app, and so I introduced delegation in the Public Resolver. This is very similar to the current ‘controller’. My first version was with multi-delegation, which allows any account to delegate to one or more other accounts in the public resolver in order to delegate records changes. I realized later that single delegation is better because clearing out old delegates can be done with a single transaction to change the delegate and clear out the previous delegate. I have the fix PR here, https://github.com/ensdomains/ens-contracts/pull/197….
If you are building on the NameWrapper, will this change affect you negatively?
Please comment on the github PR, either if YES or NO. I want to get a temp check on this change since it has been in the wild for awhile now.
Hey jeff, wondering how this scenario about parent & subname expiration will work with the current rules:
the fuse cannot be unburned (unless expired), that implies that the subname can still loses control over their expiry if the parent name got expired and someone else took over it can unburn the fuses.The technical reason why it is not possible to protect the 3LDs if the 2LD expires is due to the fact that the owner of .eth, the registrar contract, is not aware of the NameWrapper and cannot have any knowledge of it. As a result, when a name expires, it can be claimed by anyone and the new owner has the right to change the owners of the subnames. There is no technical solution to this issue, as the ownership of .eth is locked.
However, a solution to this problem is that 3LDs, such as name.web3.eth, can renew their 2LDs, like web3.eth. This means that the fate of 3LDs is in their own hands, as long as the PARENT_CANNOT_CONTROL feature is burned.
As Premm points out, this isn’t really enforceable. If the name expires and is reregistered, the new owner could simply not wrap it, at which point they can do whatever they like with the subdomains. The name wrapper is designed to recognise this fact.
As both Nick and Premm pointed out, it isn’t really enforceable on-chain for their outlined reasoning. In a situation where a .eth name has many subnames that have PCF for extending (forever subnames), the owners could band together to renew the parent name to continue their use forever, since renewing is open for anyone to call.
I wonder if this could be automated using a subname registrar itself. E.g. say X % of the fees collected from the registration gets saved by the contract that allows anyone to call renewParent(). The function can be called by anyone and gets paid the gas fees back + tip. I remember talking to @nick.eth about something like that is possible now due to EIP-1559. It would be an MEV opportunity that any bot would be able to call and could be marketed to searchers so it gets called regularly.
Hi! I’m working on the name wrapper feature on my application.
Is there any expected date (or approximately) for release on mainnet?
We’re currently on Goerli testnet, with already 2 redeployments due to issues found. There is no official date for release, but the next stage after testnet is mainnet.
We have created an integration guide of ENS NameWrapper at https://www.notion.so/enslabs/NameWrapper-third-party-support-guide-06b45e801830414da9825c8ffb747a30
This is relevant for dapps/wallets that allow you to register .eth names and marketplaces that search and show ENS names as NFT.
I will talk through the guide at today’s ecosystem WG call.
Thank you Makoto.