The big lie: NFTs are “just JPEGs.”

The reality: NFTs are the web3 equivalent of index.html in web1.

Developers have near infinite flexibility in what they put into a web page. They can change the layout, style, and content to create a bland Craigslist listing all the way to media rich-platforms like Youtube. Similarly, NFTs (through the tokenURI field) can be filled with data and links to other datasets. As we start to see developers and artists push the boundaries of this, we could see the same sort of flexibility and diversity in NFTs as we saw with web pages.

Here’s the catch.

• With flexibility comes fragmentation.

• With fragmentation comes friction (to both developers and end-users).

We saw the same play out in the early days of the web, where new features worked in one browser, but not another. It was typical for end-users to need one browser to login to their bank, but another browser to watch videos on youtube. Developers had to choose which browsers they would support. End-users had to determine how many browsers they were willing to put up with.

We are still in the early days of the NFT expansion. Within this expansion is exploration as we push the boundaries of these new primitives. Over time, we expect the same friction will arise as end-users and developers start trying to wrangle millions (billions?) of NFTs. The need for standards will arise in an attempt to make it easier to create new experiences with NFTs.

An N=4,000 Analysis

To get a sense of of how much fragmentation we are seeing in early 2022, we performed a data analysis of more than 4,000 NFTs (from a single collector) with a focus on the three biggest variables in NFTs:

1. Media Type

2. Metadata Structure

3. File Storage Type

In addition to diversity within the NFTs data itself, there is an additional challenge to overcome. Different NFT marketplaces and APIs don’t all return the same information for a given NFT. Some create their own thumbnails and additional metadata fields. Others will not provide you the raw data from the NFT’s tokenURI field. Therefore, if you want to get all of the necessary metadata for a collection of NFTs from different marketplaces, creators and projects, you need to normalize these different values in order to properly experience the NFTs.

Aside: Getting Meta About Metadata

NFT metadata is a crucial part of every NFT. Whether you’re an artist, developer or collector, we can all benefit from better understanding it. An NFT without metadata is just a record on the blockchain. Metadata is the magic sauce for NFTs. It describes what your NFT will actually look like and any other properties or functionality your NFT might have. Whether it’s the artwork, attributes that differentiate your nft in a collection or your character in a game with its stats, metadata is what makes the differentiation possible. If an NFT is a book, the metadata is the book cover, all the pages inside of it and all the words on those pages.

Metadata as a Design Decision

Below I’ve put an NFT and a subset of its metadata side by side. See the full metadata here and the NFT on Opensea here. You’ll notice I’m omitting a lot but the important thing here is that the data on the right differs for different NFTs and that there are some design decisions the NFTs creator makes when implementing an NFT’s metadata.

Below I’ve put two different NFTs and the storage decisions made when implementing them.

Below I’ve put two different NFTs and the storage decisions made when implementing them.

Why Atomic Form cares about NFT metadata

At Atomic Form we want to make it easy for people to verify, display and organize their NFT’s and in order to do that, we need to be able to know what they are. To know how to best display them, we need to understand the format of the NFT and the best way to know that is by checking the NFT’s metadata. The NFTs metadata can tell us contextual info about the art but also what format it’s in, like gif, jpeg, mp4, html and where that media is stored. Having this info means we can ensure we’re rendering the NFT as it was meant to be viewed.

This sort of analysis can also unlock new ways of exploring NFTs and understanding the ecosystem like the below mock up showing some of our favorite artists and their collections.

This info may not be the type of thing you focus on when buying or selling an NFT but its super important when it comes to understanding them and the whole ecosystem on a deeper level.

Digging into Vincent Van Dough’s NFT Collection

To get a diverse sample set to analyze, we decided to look at Vincent Van Dough’s NFT Collection on the Ethereum Blockchain, primarily using OpenSea, Alchemy and Zora. Something that immediately stuck out was the amount of variability in the metadata across the NFTs in his collection.

At the time of publishing this (March 2022), Vincent Van Dough’s Ethereum NFT collection includes

• 4,106 NFT’s divided between

• 3,429 ERC-721s and

• 677 ERC-1155s

ERC-721 NFTs are the original NFT (Non Fungible Token) standard, an example is the Art Blocks we looked at previously. ERC-1155 came later and is a standard for semi-fungible tokens, where many collectors can own the same token. A popular example of ERC-1155 is Parallel, a blockchain based Trading Card Game where it makes sense for multiple collectors to have the same NFT.

These NFTs come from 249 different collections and have a high degree of variability in the metadata, the media type of the NFT and the service being used to store the media. Each collection traditionally has its own contract, which means design decisions were made when creating then minting functionality. This in turn changes the features available for a given NFT, and impacts the metadata included. This makes Vincent Van Dough’s collection a good one to analyze, because the larger the number of contracts, the more likely we will see variations.

Where is the art though?

One of the first things I noticed in this analysis, and one of the most variable parts of NFT metadata is the name of the property that contains the link to the NFT’s art or asset. That’s uh, not great.

NFT metadata is represented as key-value pairs. In order to get the value, the NFT’s art or a link to it in this case, we need to know the specific name of the key or we’re just straight up not going to be having a good time.

The official standards for ERC-721 and ERC-1155 identifies three primary contextual properties, “name”, “description” and “image”. This was good at the time but as NFTs have become more complex and include new media types and schemas, people have had to improvise. The most commonly adopted unofficial standard that I found in my analysis was Opensea’s metadata structure.The important ones for this analysis are

Image — The URL to the NFT’s image.
Image_data — Raw SVG image data
Animation_url — a URL to the NFT’s media, this can be video, audio, 3d assets or even a webpage

So already we can see that there’s a couple different keys where the NFT’s art can be stored at and that key ideally should tell us something about the type of media associated with the NFT, so we’ve got that going for us which is nice.

However, NFT creators didn’t stop there. After all, this is a new space to explore and push the boundaries of the state of the art! Why not throw in the kitchen sink and see what else we can do? We’ve seen everything from timezones to longitude and latitude information being added.

Also, different marketplaces and artists have different conventions for the level of abstraction between the NFT, the associated media file and metadata, and whether or not they decide to follow these emerging standards. There’s no metadata checker like Grammarly for NFTs that warns the creator when they’re about to do something that doesn’t fit the emerging standards. The only incentive currently is to be close enough that the NFT will show up properly on a marketplace so collectors can sell them.

What I found in VVD’s collection

Part 1: Image? Image_url? ImageUrl?

Since OpenSea is the most popular marketplace and since everyone else is doing it, I started with their API to get the data. While OpenSea’s Indexer and API is very comprehensive, their normalization of the data is done in a way that hides the actual metadata and asset links because they’re renaming things and storing their own cached version of the art. This wasn’t going to work so I had to improvise. Ultimately, a combination of Alchemy’s API and Zora’s Metadata Parser got me what I was looking for.

Looking at the metadata for Vincent Van Dough’s collection, we can see that image is the most common key pointing to the NFT’s media with ~75% of the contracts in his collection using this key in their metadata. The next most common is animation_url at 18%, then image_url at ~5% and then imageUrl and image_data are each only used in one contract a piece. The little differences, like image_url and imageUrl highlight the entropy of NFT metadata. image_data was a property introduced by OpenSea as an indicator that the value of that field is a data URI as opposed to http URI but now most NFT marketplaces can support data URIs through the image field.

So looking at the primary content key, it lines up pretty well with what is considered standard in the space.

However, figuring out which is the primary isn’t always straightforward as a NFT can have multiple of these properties. To achieve the above I created an algorithm to iterate through all of the known metadata keys that contain URL links, IPFS links or encoded image data and then make a best guess at what the primary key was based on what other properties were present in the NFT’s metadata. Below you can see a table of the different metadata keys ordered by the number of contracts that they appear in.

Unfortunately, there’s an additional challenge with metadata that has the animation_url key. Notably, people use it for different types of files types and formats, which makes it difficult to pick the appropriate player to display it. Take for instance this Synthtopia NFT. There can be an image, like cover art stored at one key and then the audio file (wav, mp3 ogg, ogg, flac) stored in animation_url. The animation_url for this NFT actually leads to a web page that runs in the browser. WTF?!

Not to mention 3D files can require special renderers or plugins if the 3D file is directly linked from the animation_url instead of being exported as a jpeg, gif or movie.

So even once we’ve identified where the media we should use is, we still have the challenge of ensuring that we are presenting it properly.

Part 2: Diving into the media types

I experimented with Zora’s metadata parser because it returns the Mime type of the NFT’s asset as one of its properties. A Mime type defines a file’s media type, so a jpg image would have a Mime type of image/jpg. After some double-checking, I found that the value being returned by Zora was sometimes missing or checking the Mime type of the wrong key so I ran my own analysis to get a complete dataset for his collection. The results are below.

VVD’s collection is again a good example because of the variety of media types that are linked in the metadata. The majority being basic image types, png, jpg, gif, apng and webp. These are all more or less trivial to display but sometimes things like image resolution and dimensions can make that tricky.

We also see that movie files are pretty common with mp4 being the most common type and .mov being less commonly represented.

Seeing a pattern? There are some common media types with a long tail of less commonly used types that is only likely to expand as time goes on. However, as long as we can identify the right key and media type, we’re a couple giant steps closer to rendering the NFT properly.

Part 3: Do you know where your kids (NFT media) are?

Another part of the dataset that I was interested in was to find out where NFT’s in his collection were storing their assets. Having done several drops using a combination of on-chain metadata and IPFS hosted files, I was curious about where the NFT’s in his collection stored their metadata and media.

We can see in the chart below the distribution of the most common storage providers for NFT collection that VVD has collected. There’s strong evidence that most people are using decentralized hosting solutions like IPFS and Arweave, with IPFS being dominant. We also see significant usage of centralized hosting via AWS and GCP and a minority of NFTs being stored on chain. This should be cause for concern for those thinking they hold decentralized assets that can disappear if those web2 services go away!

NFTs that store their data on off-chain storage services, like IPFS or AWS can benefit from having more flexibility in the art that is associated with them. They don’t have any gas or storage size concerns like you would if you were storing your NFT’s art on chain. What it means for an nft to be on-chain is an interesting topic and one that’s been a matter of much debate but I’ve always thought of dhof’s tweet on the subject.

A lot of on chain art is using the browser to render SVG or html. Some, like autoglyphs, use base encoded ASCII characters to create art. The benefit to on-chain art, despite the limitations there, is that there are less dependencies which makes the art more resilient and longlived.

Conclusion

This article and research has been narrow in scope, we’ve looked at just one collector’s NFTs on one chain and focused even more narrowly on how and where NFT media is stored and referenced. Even within that narrow field of view, we saw a microcosm of the entropy in NFT metadata because of the lack of standardization and normalization.

This fragmentation adds friction to developer and consumer experiences and makes it more difficult to build communities, products and platforms. As we get closer to a 1 billion (trillion?) NFT world, we at Atomic Form are going to be fighting this entropy by building the tooling and services to normalize this data. We will be partnering with key stakeholders in the community to advocate for better standards. Ultimately, this will empower builders, artists and collectors to grow, experiment and try new things while ensuring that people will be able to enjoy all of their collections in a cohesive and consistent way.

If you’re looking to contribute to efforts to increase interoperability NFT space, check out standardish, an informal working group that meets the first Wednesday of every month at noon PT.

If you’re looking to work in the space and help build dope stuff for NFTs, Web3 media and the Internet of property, hit us up about joining the team at Atomic Form!

Find the code that was used during this analysis here

Written by Will Johnson at Atomic Form