Proposal to use ENS to verify NFT collections in avatars

From talking to people, it’s clear the ENS avatar is a very popular feature of the ENS names. It helps communicate that the name represents a profile, and it’s quite popular with NFT holders that want to showcase their favorite ones.

Some NFT holders have asked for us to add some sort of “verified” badge on the avatar, to prove that the image truly belongs to a “verified collection”. I see this as troublesome as it adds centralization end points (the authors of the “verified” collection lists) and it doesn’t fully solve the issue. You can, after all, clone existing NFT and have a “true NFT” that has any image you want. Also, it would requiring having some sort of “non verified” badge for images, which I think takes away from people who just like having their images as their avatars.

I would propose updating the metadata service for ENS with a new layout that includes an ENS name for the NFT collection:


Top left is a simple image avatar, while the others represent NFTs. Notice that some of them are not .eth names.

The underline on the image avatar helps promote the idea that these names are really links, and could even be websites if properly set up. When the image is an NFT the underline becomes a small text. In small sizes the url might be seen as a simple line, but in larger images you should be able to read the URL.

Because the underline is always on image avatars, someone trying to “fake” their verified NFT by just adding the verification overlay on the image, will end up with a striked out URL.

I’ve experimented with some other designs, like having the name be inside the line, or on the side, like a copyright notice, but the underline is my favorite so far.

Notice on how in smaller sizes, a properly designed line just looks like an underline:

Screen Shot 2022-03-17 at 3.25.34 PM

Screen Shot 2022-03-17 at 3.25.34 PM

To prevent homograph attack, I would add the requirement that the name must all be of the same alphabet. If any mixed character set was found (exception for emojis) then the metadata would display it as if it was just an image.

How do we get the “correct” ens name for a contract?

Of course the whole proposal supposes we have ENS names for major collections of NFTs, many who are already existing and can’t change retroactively to fit a new standard. So here’s how I would propose a standard:

  1. Reverse registrar: First, of course, if the address is set on the reverse registrar, then we use that. This is what we already do for EOA but very few contracts have support to arbitrary transactions, and even less have a specific function for the reverse registrar.

  2. Allow owner to set it: update the reverse registrar to allow it being set if a contract has a owner() function (and maybe even if that owner has an owner). This serves a large number of contracts (specially multisigs and tokens) and was in the plan anyway.

  3. Use DNSSEC on the baseURI() or contractURI() address: these are not part of the erc721 standard but are quite common practice in most NFT collections. Since they need to download the image from somewhere, most are just pointing to an external link. We could use DNSSEC to check if that domain is registered on ENS or if that domain points to an ENS name. This would solve a majority NFT contracts: but there are some exceptions. Namely, some contracts don’t use baseURI, others use it to point to an AWS server they can’t update records to and finally some adopt the (good) practice of using direct IPFS links. For these we’d have to find an alternative solution.

  4. Only in the cases that none of these methods worked, then default to a list of addresses → ens names that uses chainlink or kleros as their oracle. This would also be useful for all sorts of other contracts.

This method would not, of course, be limited to NFT verification, but it’s also useful for ERC20 listings or even naming contracts on block explorer and would once again tie ENS to the inner workings of the ecosystem. It’s also a quite decentralized model, in which new collections can verify themselves.

We don’t need to add verification for all collections, but if we can get the top 20 largest ones to do that (or we do it for them) then we could help set that as a standard.

9 Likes

Are the NFT overlay images even used anywhere?

The only place I can think of is the asset page for the .eth name on marketplaces like OpenSea. Everywhere else, the avatar that is used is not the NFT overlay image, but just the regular avatar.

Maybe the avatar metadata endpoint could also include that information about the NFT contract itself? Though… I don’t think many (or any) sites/dapps even check the current is_owner flag in the metadata or do anything with it, similar to how the ENS manager app shows that green Owner banner.

Incidentally, in the example you give, boredapeyachtclub.eth resolves to some other contract that is not the BAYC NFT contract. I’d imagine there are many other cases where the .eth name of a project is actually owned by some other account, perhaps not even by the project owners either, maybe just a squatter…

6 Likes

That is a good point but I think we need to work more on promoting the idea of ENS as your main avatar. Also, the same service could be used elsewhere: your wallet could use these reverse ENS names for checking the true provenance of your NFTs.

boredapeyachtclub.eth resolves to some other contract that is not the BAYC NFT contract.

The only thing that matters is what the NFT contract itself resolves to.

4 Likes

This is awesome - super interesting to see the design and iteration happen live, on forums.

Idea seems to add greater value to different NFT collections and also more choice for the end-user.

Recording this in the metadata allows for greater indexing of collections and allows other industry players (like ourselves) to identify and group by collections.

An issue I see is the arbitrary-ness of separating collections. Some are not clearly defined - what makes a collection? What if multiple collections use the same address? What if they mint in a series (i.e. V1, V2, V3)?

2 Likes

This isn’t attempting to separate that. We are just verifying the “official name” of the contract address.

1 Like

An updated design, with a dotted line for images and an all caps url for NFTs:

It works quite well at both small and large sizes, as as it gets too small to be legible the url looks like a grey dotted line.

1 Like

Looks pretty cool!

Would the length of the collection name / underline always match up with the length of the .eth name itself? I’m thinking of 3/4-character names where it’d be easy for that collection name to get cut off if so.

I like this idea! It’s visually appealing and solves the issue of people trying to make NFT-alike images.

I don’t think the DNSSEC route is practical; registering a DNS domain is expensive, and we’re moving towards an entirely offchain solution anyway.

1 Like

Please don’t LOL

I believe the simple clean look of the current ENS Avatar is becoming a recognizable icon everywhere. I believe this simplicity needs to be protected so that the icon grows even more as the emblem of ENS.

I understand the need to “verify” the ENS Avatar image. But perhaps this needs to be done at the next layer, where the ENS avatar is being recognized or integrated.

I agree with the above statement. And in this case, “validation” or proof of provenance is basically there. The one place I think I can’t check for provenance is on preview.ens, but then again this info could be added on the front end.

From a design point, adding this extra line of text may look good in some and horrible on others. It may also cover interesting features of the art being displayed.

I don’t think the ENS Protocol is where this verification should take place, IMHO.

Thanks!

1 Like

This isn’t really part of the ENS protocol per se, it’s actually a separate metadata service hosted and run by the core team. Since ENS names themselves do not support the tokenURI method from ERC-721, this service provides the avatar and associated metadata to clients instead.

If nobody ever actually sees the NFT overlay avatar anywhere besides OpenSea anyway, then I don’t see it as being a big deal right?

1 Like

I personally dislike the overlay, especially the text. It is an unnecessary addition forced upon users from my singular perspective. One of my avatars, for example, is a Glyph which is OCR readable. The overlay however screws it up wherever it is implemented. I’d like my avatar to be clean. I should have the option to choose. The implementation in itself is great, no doubt. If it has to be done, I like what avsa has proposed. It also looks cooler than the text to be honest. If it is going to ruin my avatar, it might as well make it look cool and authenticate it at the same time :grin:

3 Likes

I am afraid if we keep pushing the overlay agenda, we’ll normalise the overlay and end up standardising a feature that is not necessary. For instance, .eth.xyz gateway also uses overlay derived from OpenSea.

Just checked and etherscan also has an overlay although it is not pulled from OpenSea.

2 Likes

@AvsA Wen vote on design?

I’d like to propose a 4th option (I think discussed in this forum a while ago): fund the development of a Token Curated Registry to assign human readable names to “verify” collections.

Ok, so how would we use CCIP-read (or whatever is we call it) to verify the owner of a domain that was on the tokenURI() of a contract?

I have been working on metadata as well. I have been focusing my efforts on a draft ENSIP for decentralized metadata. With the new NameWrapper contract, which includes the full name of the domain, e.g., vitalik.eth, it is possible to have all of the metadata decentralized, for example using a decentralized indexing service like The Graph.

It could also possible to provide more control over metadata for domain holders. The feature that I am most interested in is a “No Overlay” setting, wherein a domain would become a fully functional NFT platform. @Nick.eth has pointed out in the past that this could lead to fake names being “overlaid” into the avatar image, which could trick people into buying a name with missing or hidden characters. I pointed out that it is already possible by adding a letter to the beginning of a “overlaid” name, e.g. mazon.eth becomes Amazon.eth, or Iarget.eth becomes Target.eth, by simply photoshoping the extra bits in the avatar image.

I believe that marketplaces should require buyers to manually check a box under each Unicode character in the domain, with info on each character and also the results of combinations of characters, letting buyers know exactly what they are buying. This will solve the overall problem of fake names.

If anyone else is interested in working on decentralized metadata and options for custom metadata, let me know. Also thanks to everyone who has supported my Gitcoin grant!!! Here is a link to read more about my projects:

3 Likes