No significant issues have been found since the last deployment on testnet. I’m very happy with this and we’re very close to getting things ready for mainnet.
We’ve made some improvements to the UX by adding in isWrapped() to the interface and also allowing it to make checks on .eth, so you can give it any name and find out if it is wrapped. This can be called offchain, on frontend applications or on-chain (we have a gas efficient version that requires you to do the namehashing yourself).
@taytems has helped us to write an unwrap contract just for testnet so anyone with testnet names on previous NameWrappers will be able to unwrap them and rewrap on the latest NameWrapper, which the ENS app v3 will connect to. I’ll update this thread when it’s deployed and you will be able to unwrap old names using Etherscan to interact with the contract or programmatically.
We’ve added a new feature which allows unruggable renewals with an immutable approval. Previously we added the ability for parent name owner’s to burn a fuse on the subname to allow forever subnames. This was inspired by a conversation with @hodl.esf.eth. Thanks for the back and forth!
Immutable Approval
This PR below adds the ERC721 approve function to the NameWrapper. NameWrapper is a ERC1155 token, but we’ve also added ERC721 functions, such as ownerOf. The approve function that is historically not widely used by other ER721s allows you to approve an address for a specific token (or name). We have integrated this standard function, with the following functionality:
Approved addresses only apply to that specific name
Approve can be blocked using a fuse: CANNOT_APPROVE
Approved addresses can only operate on subnames, they are not allowed to operate on the names
Approved addresses can only call extendExpiry() on subnames
Approved addresses reset when transferring the name, unless the fuse CANNOT_APPROVE is burnt
Approved addresses are reset on minting/burning - e.g. re-registering an expired name or unwrapping
I see a lot of usecases for immutable approval, immediately it can be used to guarantee registrations/renewals of subnames for any name. However since it’s a locked-in contract, it can pretty much do whatever you want it to do. The main usecase for this update is approving renewal controllers. Previously if you wanted this functionality you would have to transfer over ownership to a contract, but with this new approval mechanism, you can keep ownership over the ERC1155 token.
We are tantalisingly close to release based on the fact we have not found any significant bugs in the past 3+ weeks. I hope to have a more concrete update soon.
Edit: After the latest PR is merged, the functionality will be reduced to extendExpiry(). I’ve struck out information above that is incorrect after merging
This is so GRAT!
…most people have no idea how amazing & important these features are <3
Thank you to everyone working on this code, interface, and documentation!
Couple of UI issues that I have stumbled across as well as not being able to register a domain because it’s too long??…but I have already minted the same domains using main net…
Only labels that are 255 bytes or less (not characters, bytes, UTF-8) are allowed in the wrapper. Since the new manager UI will use the new registrar controller which goes through the wrapper, you will not be able to register any such name through the new UI. You will not be able to wrap any existing name with a long label like that either.
Each of those characters encode into four bytes with UTF-8 I believe. So you could only have 63 of those characters in a label. That name appears to have 389 of those emojis in it, so 1556 bytes, over 6 times the limit.
After some discussion I’ve decided to reduce the power of approval to only be able to call extendExpiry(). This means that the approve will be restricted to being an immutable renewal controller and cannot give immutable registrations. I think this is a fair trade-off as we reduce the backdoor possibilities to 0, but we still allow renewals to be immutable if the parent owner decides this is important to them.
A possible use-case would be to create a subdomain registrar, that has both registrations and renewals. setApprovalForAll() and approve() to the subdomain registrar. Then burn CANNOT_APPROVE to allow it to renew indefinitely. The owner can now revoke setApprovalForAll(), but is unable to stop renewals as they cannot change the approve address. This could also be a separate contract if the owner so chooses.
The PR is still waiting for review and will be merged post-review. The PR also contains some fixes that were found by @izhuer.eth during a code review. Thanks to him for the quick turnaround!
Did the Goerli contract addresses get updated? I see that there is a new contract that the app is now pointing at. Contract isn’t verified so I’m not sure which code version is currently being used.
There is a new wrapper deployed, but not with the changes above. If you want to use it, you can. However I didn’t want to update the address above until we deployed the wrapper with the fixes from the PR.
You can find it in the open PR deploying the wrapper to goerli
characters encode into four bytes with UTF-8 I believe. So you could only have 63 of those characters in a label. That name appears to have 389 of those emojis in it, so 1556 bytes, over 6 times the limit.