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 
7 Likes
I am confused by the new ability to wrap a second level dns domain. I thought we’d only be able to wrap subdomains of them. What does it mean to wrap ______.com and then send it to someone else? Would the recipient effectively become the controller of that domain in the web3 sphere?
If the DNS TLD is using the default DNSRegistrar (which allows 2LD registrations via DNSSEC signed TXT records), then the owner of the DNS 2LD can always reclaim that 2LD in the ENS registry. This is because neither the DNS TLD nor the 2LD is locked/emancipated. So even if the 2LD is wrapped and the NFT is sent to someone else, the owner on the DNS side can still forcefully unwrap and take back that name on the ENS side at any time.
The DNSRegistrar could also possibly be updated in the future to enable fuses by locking the TLD, and making any 2LDs locked and non-transferrable. There are no current plans for this, it’s just a future possibility that has been floated in the past.
If the owner of the DNS TLD has control over that TLD on the ENS side (like .art), then it’s completely up to the DNS TLD owner how to handle that. They could decide to use ENS as the “source of truth” for ownership and automatically transfer ownership on the DNS side for example. They could decide to issue their own custom NFTs for 2LDs (like .kred did in the past). Or, they could also decide to Lock that TLD in the Name Wrapper and emancipate 2LDs, thereby enabling the fuse/permission system for all domain owners in that namespace, just like .eth names.
Of course the TLD owner still has ultimate ownership on the DNS side of things, so there is still a layer of human trust there for DNS domains. Even if the 2LDs are wrapped and emancipated on the ENS side, the TLD owner could technically still takeover / overwrite records for the 2LD on the DNS side. Or if the TLD were to ever change ownership on the DNS side, then the new owner could request ownership of that TLD on the ENS side per the ENS DAO constitution. Those cases would probably be rare (like if a government agency coerced the DNS TLD owner to do something), but you’ll need to evaluate the risks or lack thereof for yourself.
5 Likes
this is fascinating. thanks for the very detailed answer!
1 Like
OpenSea now has a filter for “Namewrapper state: Wrapped”.
7 Likes
Hey Premm. Awesome!
I noticed that opensea still shows butchered metadata for a wrapped dns subdomain. The wrapped dns domains look normal on there now but a subdomain still looks like this: https://opensea.io/assets/ethereum/0xd4416b13d2b3a9abae7acd5d6c2bbdbe25686401/35362451777606356783924180670401527086319760602512061277739689399609412972547
1 Like
What you’re seeing is the token ID [35362451777606356783924180670401527086319760602512061277739689399609412972547] without any metadata at all. We’ve seen this before with opensea after new ENS have been minted, however, this appears to be something a bit deeper as there are other names with similar provenance in the same state…
2 Likes
I’ve noticed that on Goerli the resolver for the ‘eth’ namespace set in the registry hasn’t been updated to point to the correct new ETH Registrar Controller. Is it possible to have this set?
More generally the contract discovery for the various ENS contracts isn’t clearly documented (as far as I can tell), but even if it were there are issues like incorrect identifiers being used (as mentioned here).
I would deploy my own contracts and develop against them, but again the deployment process with hardhat is not clearly documented and is a little arduous. It also doesn’t look on the face of it like the deployment scripts are complete - I don’t believe the ETH resolver is set in the registry for example.
I’ve got things working on a local hardhat node but testing on a production like testnet requires jumping through hoops that put me off (after hours of effort), and may well have put others off.
Little things like this make the dev experience a little rough around the edges.
Not a dig - appreciate all the fantastic work you and the team have put in, just some feedback from an independent dev on the ground. Unsure where to direct it 
2 Likes
Hey @clowes.eth,
We can setup the resolver for the new Goerli resolver.
You’re right on the contract discovery, at the moment things are a bit scattered and I’ve been document it here in this thread, but it would be best to be in our docs at some point with any gotchas, such as incorrect identifiers. It’s something we need to improve on.
We are using the deploy scripts in a lot of places, including our own app. Can you be more specific to where the deployment scripts are incomplete. If so, @taytems can probably help you a little and we can document things that are confusing.
The feedback is appreciated and well received!
Fixed, thanks for the heads-up!
We’re looking to improve this. If you see specific shortcomings in docs or ease of use, or things that aren’t set, would you mind opening a bug for them?
4 Likes