NameWrapper updates (including testnet deployment addresses)

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

When will subgraph be released for the new contracts on Mainnet?

cc. @jefflau.eth

2 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

As Greg mentioned, we’re still syncing. We had an issue with an earlier sync and with any issues, they need to be restarted from the beginning. The sync is passed where it failed initially and fingers crossed will be synced soon!

7 Likes

I guess that you already know this, but reverse resolution for names does not work on Etherscan that have been registered on the new reverse registrar.

Here’s a transfer from a new set account.

https://etherscan.io/tx/0x6f21d884c2d8f297be39f461afbfe585ff19f1c83198203c26c1960d09f27be4

1 Like

I guess they’re doing their own indexing/caching, and they might have the reverse registrar address hard-coded into that process or something.

No issues with the contract, just an Etherscan UI thing looks like.

1 Like

Yes, I agree. It’s an etherscan issue. Did you want me to reach out to them, or would someone from ENS do it?

1 Like

The ENS Labs team has been notified, but feel free to reach out yourself as well

2 Likes

Ok, I will… Last time I spoke to them on blockchat, and they got back to me quite quickly so i’ll do that again.

edit: I’ve logged a support request with them, I’ll let you know what they say.

7 Likes

It looks like there is some issues with the goerli subgraph at the moment. It shows failed at 99%.


Edit: Looks to be fixed now.

1 Like

Question:

Are the new contracts going to be ens named, maybe with an ens.eth subdomain? I assume you would do that.

2 Likes

Tha’d be very cool!

2 Likes

Yes, this is standard practice for ENS contracts. This is already on the dev team’s todo list :+1:

7 Likes