(It is literally the last message before you posted.)
This will go to vote on Monday,
…then voting period is seven days.
1 Like
I don’t think so… Vote is delayed for one last review of the code and should get findings back next Monday. Date of vote will probably be discussed then.
The NameWrapper, and new versions of the PublicResolver, ETHRegistrarController, and ReverseRegistrar have all been deployed to mainnet. Addresses of these new contracts can be found here: Mainnet deploy of new contracts by Arachnid · Pull Request #236 · ensdomains/ens-contracts · GitHub
They will not be active until the DAO approves a vote to activate them. This will be forthcoming shortly, after the ENS team verifies the deployment.
Edit: We’ve identified a misconfiguration in the original deployment. I’ve redeployed and the team is verifying the new version.
9 Likes
Congratulations everybody!
2 Likes
Hey Nick, is it mandatory for platforms to subscribe to the new contracts or can it still use the (now) old registry/controller/registrar/resolvers in parallel?
1 Like
The old .eth registrar controller will remain usable until deprecated (separately); there’s no rush to do that as it still works just fine. Users can use the old resolvers just fine, though they won’t be able to use them with wrapped names.
We’re not upgrading the registry or .eth registrar (in fact, they’re not upgradeable).
The new reverse registrar will need to be used immediately; only one registrar can exist at a time.
5 Likes
woohoo!
1 Like
Great news on the mainnet deployments. Congratulations to the team.
I was wondering if before the voting commenced there would also be some visibility of the changes to the metadata of namewrapper. This seems like a very important detail as it contains information across all the marketplaces / dapps for the state of the names, permissions, expiries etc.
Metadata does not seem to be working currently on Goerli.
Also, I know it would require another deployment but I would consider adding in events for eip-4906 Metadata Update Extension so when there is any changes to expiry / fuses the marketplaces can pick them up without a manual refresh of metadata.
6 Likes
I think the metadata service has yet to be updated, I believe @mdt is working on that.
See this PR for an example of what will be added to the metadata: add namewrapper specific traits to the metadata by mdtanrikulu · Pull Request #150 · ensdomains/ens-metadata-service · GitHub
-
Namewrapper State (string)
Wrapped | Emancipated | Locked
- Namewrapper Expiry Date (date)
-
Namewrapper Fuse States (object)
- Boolean
true|falsefor every individual fuse/permission
- Boolean
2 Likes
Thanks for the reply.
Shouldn’t this be completed before the voting starts? No-one actually know what this is going to look like on opensea / looksrare until it is finished and working on goerli.
Is there going to be enough time to complete and test it before the deployment datetime?
Also, have you considered implementing eip-4906?
2 Likes
Well, wrapped names will be a new contract, so new collection I believe on most platforms.
OpenSea and most other places will just show those two new state/expiry traits, for wrapped names.
OpenSea and most other places will likely not show anything for the individual fuse states, as that is a complex object and not just a string/date/number. However, perhaps other platforms more in tune with ENS could show extra information, like ENS.Vision.
EIP-4906 probably doesn’t make sense as the ENS metadata service is not on-chain at all. It is a separate service run by ENS Labs Actually, see below
2 Likes
eip-4906 event tells the marketplace there has been a change and to pull the metadata again from whichever the uri is, (onchain / ipfs / centralised). If a fuse is burned then markets won’t update unless the metadata is manually refreshed.
1 Like
Yep, that is right.
There are FusesSet / ExpiryExtended events that are emitted by the wrapper whenever that changes, but not that MetadataUpdate event.
2 Likes
Only ENS specific marketplaces will pick up those events though. Opensea etc most definitely won’t.
I’d suggest that implementing eip-4906 would be preferable, but maybe as a compromise, if you don’t want to do that you could add the current datetime into the metadata so that user can see when it was last cached?
cc. @jefflau.eth @mdt
7 Likes
I was investigating the process of updating my various contracts to work with the new NameWrapper contracts.
@jefflau.eth mentioned in his initial post under the contract discovery section the process of discovering the ETH registrar controller address and the NameWrapper address using the appropriate interface IDs.
I only realised that Jeff had mentioned the interface IDs after Googling them having created a new tool (Ethereum Interface ID Generator | EthTools.com - Online tools for Ethereum users and developers.) to derive them whilst clarifying the inputs from which they are produced.
So I derived the ID for the new registrar controller, and it matches…
New ETH Registrar Controller - 0x612e8c09 - Ethereum Interface ID Generator | EthTools.com - Online tools for Ethereum users and developers.
But what I am getting for the NameWrapper differs (0x9ce846a0 instead of 0x019a38fe)
NameWrapper - 0x019a38fe - Ethereum Interface ID Generator | EthTools.com - Online tools for Ethereum users and developers.
I’m using the function selectors from the verified contract deployed at https://etherscan.io/address/0xd4416b13d2b3a9abae7acd5d6c2bbdbe25686401#code#F21#L166
I suspect that this is because you are using a subset of the function selectors to generate the interface ID for the wrapper, but in the off chance this is a mistake (identifier from an old version of the contract) I figured I’d post.
Either way, it would be useful to clarify how the IDs are being derived.
1 Like
Yes, unfortunately our deploy script generated the wrong identifiers, which we only realised after the vote.
We’ve decided to make do with the incorrect identifiers for now, rather than putting the DAO to the trouble of a second vote.
1 Like
This is a great idea. Even if we go with the eip-4906 option at some point, having a timestamp can serve as a simplified alternative to any other marketplace or project out there.
Edit: Here is the PR; add last request date field to ENS metadata response by mdtanrikulu · Pull Request #155 · ensdomains/ens-metadata-service · GitHub
5 Likes
An update to the subgraph was pushed a few days ago and is currently syncing (currently at 89.8%). The Graph is slow to re-index and there’s not much we can do about that, unfortunately. You can see the pending version here.
3 Likes