This is the second article in a series where Atomic Form analyzes NFT metadata diversity across several chains. These efforts are intended to provide a path for developers to display the best available quality of NFT for a given device or screen. The first article, written by Will Johnson, analyzes Ethereum NFTs and is available here.

Atomic Form is taking on a very intriguing challenge. We want to allow users to authenticate multiple multi-chain wallets, choose from their NFT collections, and display the artwork within the NFTs on beautiful, high-quality, and high-resolution devices. In a recent article by Will Johnson, Will dove into the data fragmentation and diversity within a large NFT collection on the Ethereum blockchain. Like Will, we found this to be an eye-opening experience to explore the data behind the art. While we drive forward and provide a high-quality integration for NFTs across other chains, we must evaluate and normalize the available data in order to build software that displays the artwork as it is intended.

In this article, we will evaluate NFTs on Solana and what kind of challenges developers will face when working with the data within. As discussed in the previous article, NFT data offers a lot of flexibility but with that flexibility comes fragmentation. This becomes a challenge for end-users and developers alike. The key takeaways are a better understanding of the diversity in storage, metadata structure, and media types.

Solana is a newer chain and we anticipate more consistent standards. However, NFTs come in many media types and continue to evolve. This flexibility and diversity will inevitably lead to data fragmentation.

The first challenge we faced was the ability to pull in NFT data from a single wallet. After some research, we tested two API options, the Blockchain API and NftEyes sol-rayz. Both options allowed us to gather the NFT collection of a given wallet. There are a few small differences.

The Blockchain API is a paid service and requires an API key pair to obtain credits. There is a free level but the limits will block the integration fairly quickly. The credit system requires review to know what level will be needed. For example, the free version allows 25 requests per minute and use of 500 credits per month. However, each request utilizes a different number of credits. A request to obtain the NFT list for a given public address is a 3 credit charge. The service also works with other blockchains and a paid model suggests a reliable SLA, but those potential benefits will require additional research.

The sol-rayz package is a free package requiring no API credentials. The package has a tested use case as it was built for NftEyez, which has thousands of users.

Installation and use of both options is identical, requiring a handful of node packages and a few lines of code. The results are also very similar with small structural differences. For example, both APIs return a list of creators, creator verification status, and each creator’s royalty share.

The Blockchain API returns this information as three separate fields. Each field is an array and the user must connect the information based on the order.

NftEyez sol-rayz shows identical data, but as a single array with a creator object.

The difference in structure between the two APIs is moot, especially once one has been selected. However, both APIs will require a second call to the same URI to retrieve Javascript Object Notation (JSON) encoded data with NFT specific metadata.

Now that we have selected an API and pulled a list of NFTs to display, we have to pull the JSON encoded metadata for each NFT and parse it. This is where the real fun begins. There are numerous types of NFTs and within each type there are variants in the data structure. In this section, we will evaluate those variants and how the metadata should be parsed so that an application can interact with most NFTs structures that may appear.

To ensure we are maximizing our data sample, we searched for a variety of NFT types and interesting wallets on Magic Eden, Solanart, HowRare.is, Solsea, and HyperSpace. We pulled an intentionally diverse dataset of over 1,300 NFTs belonging to 24+ wallets and 223+ collections. It is important to note that the stats and information within this article are using an intentionally diverse set of data, not a random one intended to represent the average set of NFTs one may encounter.

The sample NFT collection consists of 1,124 images, 81 videos, 7 virtual reality files, 3 audio files, and 82 HTML files. There is a lot of data available for various Solana NFTs but for the purposes of this article, we will focus on the primary data elements needed to parse and display the NFT appropriately.

Regardless of the API used, the same URI to retrieve the JSON metadata is provided. The bulk of the Solana NFTs use areweave.net to store metadata. This is the type of consistency we expected but only accounts for 84.5% of our sample collection. Each creator can choose to host the metadata elsewhere. Other options account for 14.3% of our collection and include:

• amazonaws.com

• cloudfront.net

• digitaloceanspaces.com

• exchange.art

• googleapis.com

• ipfs.dweb.link

• ipfs.io

• ipfs.nftstorage.link

• mypinata.cloud

• raw.githubusercontent.com

In addition to storage services that can be used for one-off NFTs and entire collections, we found several examples of collections that host the metadata on a collection-specific service. This makes up 1.2% of our sample collection and includes:

• famousfoxes.com

• getdolphin.io

• piggygang.com

• pixtapes.com

• shkarysharks.com

• sovanadao.com

• tatsu.gg

Unlike our Ethereum analysis where the majority was IPFS, the Solana ecosystem has largely used Arweave for media storage. NFTs in our sample collection range from one to five or more media assets. These are provided in various elements of the JSON metadata which we will break down in the next section.

Our sample collection of NFTs includes images (86.7%), HTML (6.3%), videos(6.2%), VR (0.5%), and audio (< 0.3%). As a reminder, the diversity of media types in this sample collection does not accurately represent the percentage of media types throughout Solana NFTs. We intentionally wanted diverse samples, such as our relatively large sampling of HTML NFTs.

When displaying Solana NFT assets of all types, the primary data points to focus on include image, animation_url, and properties.

• image: URL to the image asset.

• animation_url: URL to a media asset. The asset could be various file types, including gif, mp4, mov, Quicktime, mp3, HTML, or glb (3d file format used for VR).

• properties: an object providing links for media assets, media category, and other metadata. For the purposes of this article, we will focus only on the files and category elements within the properties object.

In our sample set, all NFTs made use of the image element. This element contains a string to a preview image, or in some cases for NFT assets, the image element is the primary asset. The animation_url is also consistently used by all non-image NFTs in our sample data.

The properties object is less consistent. There is a variety of data available within the properties object, but for the purposes of quality display, we focus on the files element (properties.files) and the category element (properties.category). The relationship between the properties object and image and animation_url elements varies by NFT type and collection. Before getting into some of those variations, let’s cover the types of data structures one could expect within the properties object.

In our evaluation, 3.8% of the NFTs did not use the properties object to specify files and additional information about the NFT. Based on a review of these assets, they appear to be PFP NFTs with a single image.

The 96.2% of NFTs from our sampling that do use the properties object provided a files element in one of three structures: an array, an object, or an array of objects. The majority of the NFTs in our sample data use an array of object structure, even if only one file exists. We did not find many array and object structures in our search for a diversified collection of NFTs. It is very likely the percentage of structure variety within our sample collection does not represent Solana NFT as a whole, but we do feel confident that “array of objects” is the norm.

Array of Objects

Array

Object

While most of the NFTs use the “array of objects” structure, the majority of those have only one asset.

The category element in the properties object (properties.category) can also be helpful when programmatically evaluating Solana NFTs, but it also has some inconsistencies to consider. From our sample data, we see several categories. Our results included the following categories:

• image

• video

• Animation

• vr

• html

• image/png

• audio

“Animation” only occurred once and was used for an mp4 video asset. “image/png” also only occurred once.

With an understanding of how the above NFT metadata is structured and used, we can then dissect how it is used for different NFT asset sites and point out some of the logic that will need to go into displaying the best asset possible for a given NFT.

As mentioned before, all Solana NFTs that we have seen consistently use the image element as a URL to an image asset. Furthermore, from our sample data, over 83% of the image NFTs have the same link to the image element and the properties.file object. However, 9.6% of the image NFTs also have a second file link in the properties.files object. This typically means the asset link used in the image element is a preview and a much larger asset exists for better display.

Manual testing of NFTs that have different URLs in the image element and properties.files object with no repeating URL between the fields revealed several different scenarios. File assets in these two locations include the following scenarios:

• The exact same images with identical dimensions exist at two different links. In some cases, the different links were for an identical asset with different hosting, such as areweave versus amazon.

• The image element contains a smaller, square asset for preview. The properties.files asset is a large asset for high-resolution viewing. In some cases, the properties.files object array includes multiple versions of high-resolution assets.

• The image element contains a smaller, square asset for preview. The properties.files assets include the same preview image and a large asset for high resolution viewing.

• Other relationships between the two locations used for images assets. It seems the best way to gather the best high-resolution images in these cases is to programmatically check file size and dimensions.

We noticed many NFTs provided multiple assets in the properties.files element. This various aspect ratios and quality of these assets shows artists are making progress in providing quality options for different displays, including mobile devices, smart watches, web, and high definition displays. One interesting example of image asset diversity in our sample set of Solana NFTs comes from “New York”, part of the “Solsunsets Special Editions” collection. This NFT provides three image assets in the properties.files element.

1. Landscape animated gif (470KB). This is the image used in the image element as well.

2. Landscape animated gif (1.2MB).

3. Landscape png (131KB).

The intention of the multiple assets appears to be to provide an animated banner, and png banner, and a lower quality preview of the animated banner. We manually checked many other NFT image assets and found similar collections of assets that provide various quality, file size, and ratio (landscape, square, and portfolio). It seems commonplace for Solana NFTs to provide high and low-quality options for media assets.

Videos are one of the more consistent sets of metadata in the Solana NFT sample collection. These assets can be confidently displayed using the animation_url asset. All of the samples in our collection use the image element as a preview image. The only additional file options we noted in the properties.files object were occasional animated gifs that could be used to substitute the video.

The virtual reality NFTs consistently use image, animation_url and properties.files, repeating the files from the image and animation_url elements in the properties.files array of objects. At Atomic Form, we will be researching the best way to display virtual reality NFTs. The easiest way for an end-user to view a file is by using a Google Chrome extension to view the file in the browser.

The audio NFTs we found in our sample collection used the image element for an image to be displayed with the audio file and the animation_url element linked to an mp3 file. The same files were present in the properties.files object.

The HTML NFTs in our collection are also very consistent, using the image element as a preview and the animation_url as a link to an interactive web page to be displayed. The properties.file object repeated the links for these assets.

Can I reliably display an NFT using a dependable data point within the metadata? Yes! Based on our research and a wide variety of NFTs from many wallets and collections, Solana NFTs can be dependably displayed using only two data points, image, and animation_url. If animation_url is empty, it is safe to assume the NFT is of the image type and only the image media asset will be needed.

However, we have seen and discussed many examples of NFTs offering alternative assets to better fit quality requirements. While a preview or basic display is easy to achieve and very standardized in Solana, it will be important to check the properties.files element for additional asset options. This is less standardized and will require developers to resolve data fragmentation as well as be able to detect the best asset for a given scenario.

As we suspected, Solana does offer more consistency than Ethereum. Solana still offers plenty of challenges in detection and options. We expect this to increase as NFTs become more diverse and offer more sophisticated options for display. Taking this into consideration with the diversity we see in Ethereum and what is expected from other chains, developers will have some fun challenges in displaying multi-chain artwork collections for collectors.

Find the code that was used during this analysis here.

Written by Brandon Williams at Atomic Form

This is the second article in a series where Atomic Form analyzes NFT metadata diversity across several chains. These efforts are intended to provide a path for developers to display the best available quality of NFT for a given device or screen. The first article, written by Will Johnson, analyzes Ethereum NFTs and is available here.

Atomic Form is taking on a very intriguing challenge. We want to allow users to authenticate multiple multi-chain wallets, choose from their NFT collections, and display the artwork within the NFTs on beautiful, high-quality, and high-resolution devices. In a recent article by Will Johnson, Will dove into the data fragmentation and diversity within a large NFT collection on the Ethereum blockchain. Like Will, we found this to be an eye-opening experience to explore the data behind the art. While we drive forward and provide a high-quality integration for NFTs across other chains, we must evaluate and normalize the available data in order to build software that displays the artwork as it is intended.

In this article, we will evaluate NFTs on Solana and what kind of challenges developers will face when working with the data within. As discussed in the previous article, NFT data offers a lot of flexibility but with that flexibility comes fragmentation. This becomes a challenge for end-users and developers alike. The key takeaways are a better understanding of the diversity in storage, metadata structure, and media types.

Solana is a newer chain and we anticipate more consistent standards. However, NFTs come in many media types and continue to evolve. This flexibility and diversity will inevitably lead to data fragmentation.

The first challenge we faced was the ability to pull in NFT data from a single wallet. After some research, we tested two API options, the Blockchain API and NftEyes sol-rayz. Both options allowed us to gather the NFT collection of a given wallet. There are a few small differences.

The Blockchain API is a paid service and requires an API key pair to obtain credits. There is a free level but the limits will block the integration fairly quickly. The credit system requires review to know what level will be needed. For example, the free version allows 25 requests per minute and use of 500 credits per month. However, each request utilizes a different number of credits. A request to obtain the NFT list for a given public address is a 3 credit charge. The service also works with other blockchains and a paid model suggests a reliable SLA, but those potential benefits will require additional research.

The sol-rayz package is a free package requiring no API credentials. The package has a tested use case as it was built for NftEyez, which has thousands of users.

Installation and use of both options is identical, requiring a handful of node packages and a few lines of code. The results are also very similar with small structural differences. For example, both APIs return a list of creators, creator verification status, and each creator’s royalty share.

The Blockchain API returns this information as three separate fields. Each field is an array and the user must connect the information based on the order.

NftEyez sol-rayz shows identical data, but as a single array with a creator object.

The difference in structure between the two APIs is moot, especially once one has been selected. However, both APIs will require a second call to the same URI to retrieve Javascript Object Notation (JSON) encoded data with NFT specific metadata.

Now that we have selected an API and pulled a list of NFTs to display, we have to pull the JSON encoded metadata for each NFT and parse it. This is where the real fun begins. There are numerous types of NFTs and within each type there are variants in the data structure. In this section, we will evaluate those variants and how the metadata should be parsed so that an application can interact with most NFTs structures that may appear.

To ensure we are maximizing our data sample, we searched for a variety of NFT types and interesting wallets on Magic Eden, Solanart, HowRare.is, Solsea, and HyperSpace. We pulled an intentionally diverse dataset of over 1,300 NFTs belonging to 24+ wallets and 223+ collections. It is important to note that the stats and information within this article are using an intentionally diverse set of data, not a random one intended to represent the average set of NFTs one may encounter.

The sample NFT collection consists of 1,124 images, 81 videos, 7 virtual reality files, 3 audio files, and 82 HTML files. There is a lot of data available for various Solana NFTs but for the purposes of this article, we will focus on the primary data elements needed to parse and display the NFT appropriately.

Regardless of the API used, the same URI to retrieve the JSON metadata is provided. The bulk of the Solana NFTs use areweave.net to store metadata. This is the type of consistency we expected but only accounts for 84.5% of our sample collection. Each creator can choose to host the metadata elsewhere. Other options account for 14.3% of our collection and include:

• amazonaws.com

• cloudfront.net

• digitaloceanspaces.com

• exchange.art

• googleapis.com

• ipfs.dweb.link

• ipfs.io

• ipfs.nftstorage.link

• mypinata.cloud

• raw.githubusercontent.com

In addition to storage services that can be used for one-off NFTs and entire collections, we found several examples of collections that host the metadata on a collection-specific service. This makes up 1.2% of our sample collection and includes:

• famousfoxes.com

• getdolphin.io

• piggygang.com

• pixtapes.com

• shkarysharks.com

• sovanadao.com

• tatsu.gg

Unlike our Ethereum analysis where the majority was IPFS, the Solana ecosystem has largely used Arweave for media storage. NFTs in our sample collection range from one to five or more media assets. These are provided in various elements of the JSON metadata which we will break down in the next section.

Our sample collection of NFTs includes images (86.7%), HTML (6.3%), videos(6.2%), VR (0.5%), and audio (< 0.3%). As a reminder, the diversity of media types in this sample collection does not accurately represent the percentage of media types throughout Solana NFTs. We intentionally wanted diverse samples, such as our relatively large sampling of HTML NFTs.

When displaying Solana NFT assets of all types, the primary data points to focus on include image, animation_url, and properties.

• image: URL to the image asset.

• animation_url: URL to a media asset. The asset could be various file types, including gif, mp4, mov, Quicktime, mp3, HTML, or glb (3d file format used for VR).

• properties: an object providing links for media assets, media category, and other metadata. For the purposes of this article, we will focus only on the files and category elements within the properties object.

In our sample set, all NFTs made use of the image element. This element contains a string to a preview image, or in some cases for NFT assets, the image element is the primary asset. The animation_url is also consistently used by all non-image NFTs in our sample data.

The properties object is less consistent. There is a variety of data available within the properties object, but for the purposes of quality display, we focus on the files element (properties.files) and the category element (properties.category). The relationship between the properties object and image and animation_url elements varies by NFT type and collection. Before getting into some of those variations, let’s cover the types of data structures one could expect within the properties object.

In our evaluation, 3.8% of the NFTs did not use the properties object to specify files and additional information about the NFT. Based on a review of these assets, they appear to be PFP NFTs with a single image.

The 96.2% of NFTs from our sampling that do use the properties object provided a files element in one of three structures: an array, an object, or an array of objects. The majority of the NFTs in our sample data use an array of object structure, even if only one file exists. We did not find many array and object structures in our search for a diversified collection of NFTs. It is very likely the percentage of structure variety within our sample collection does not represent Solana NFT as a whole, but we do feel confident that “array of objects” is the norm.

Array of Objects

Array

Object

While most of the NFTs use the “array of objects” structure, the majority of those have only one asset.

The category element in the properties object (properties.category) can also be helpful when programmatically evaluating Solana NFTs, but it also has some inconsistencies to consider. From our sample data, we see several categories. Our results included the following categories:

• image

• video

• Animation

• vr

• html

• image/png

• audio

“Animation” only occurred once and was used for an mp4 video asset. “image/png” also only occurred once.

With an understanding of how the above NFT metadata is structured and used, we can then dissect how it is used for different NFT asset sites and point out some of the logic that will need to go into displaying the best asset possible for a given NFT.

As mentioned before, all Solana NFTs that we have seen consistently use the image element as a URL to an image asset. Furthermore, from our sample data, over 83% of the image NFTs have the same link to the image element and the properties.file object. However, 9.6% of the image NFTs also have a second file link in the properties.files object. This typically means the asset link used in the image element is a preview and a much larger asset exists for better display.

Manual testing of NFTs that have different URLs in the image element and properties.files object with no repeating URL between the fields revealed several different scenarios. File assets in these two locations include the following scenarios:

• The exact same images with identical dimensions exist at two different links. In some cases, the different links were for an identical asset with different hosting, such as areweave versus amazon.

• The image element contains a smaller, square asset for preview. The properties.files asset is a large asset for high-resolution viewing. In some cases, the properties.files object array includes multiple versions of high-resolution assets.

• The image element contains a smaller, square asset for preview. The properties.files assets include the same preview image and a large asset for high resolution viewing.

• Other relationships between the two locations used for images assets. It seems the best way to gather the best high-resolution images in these cases is to programmatically check file size and dimensions.

We noticed many NFTs provided multiple assets in the properties.files element. This various aspect ratios and quality of these assets shows artists are making progress in providing quality options for different displays, including mobile devices, smart watches, web, and high definition displays. One interesting example of image asset diversity in our sample set of Solana NFTs comes from “New York”, part of the “Solsunsets Special Editions” collection. This NFT provides three image assets in the properties.files element.

1. Landscape animated gif (470KB). This is the image used in the image element as well.

2. Landscape animated gif (1.2MB).

3. Landscape png (131KB).

The intention of the multiple assets appears to be to provide an animated banner, and png banner, and a lower quality preview of the animated banner. We manually checked many other NFT image assets and found similar collections of assets that provide various quality, file size, and ratio (landscape, square, and portfolio). It seems commonplace for Solana NFTs to provide high and low-quality options for media assets.

Videos are one of the more consistent sets of metadata in the Solana NFT sample collection. These assets can be confidently displayed using the animation_url asset. All of the samples in our collection use the image element as a preview image. The only additional file options we noted in the properties.files object were occasional animated gifs that could be used to substitute the video.

The virtual reality NFTs consistently use image, animation_url and properties.files, repeating the files from the image and animation_url elements in the properties.files array of objects. At Atomic Form, we will be researching the best way to display virtual reality NFTs. The easiest way for an end-user to view a file is by using a Google Chrome extension to view the file in the browser.

The audio NFTs we found in our sample collection used the image element for an image to be displayed with the audio file and the animation_url element linked to an mp3 file. The same files were present in the properties.files object.

The HTML NFTs in our collection are also very consistent, using the image element as a preview and the animation_url as a link to an interactive web page to be displayed. The properties.file object repeated the links for these assets.

Can I reliably display an NFT using a dependable data point within the metadata? Yes! Based on our research and a wide variety of NFTs from many wallets and collections, Solana NFTs can be dependably displayed using only two data points, image, and animation_url. If animation_url is empty, it is safe to assume the NFT is of the image type and only the image media asset will be needed.

However, we have seen and discussed many examples of NFTs offering alternative assets to better fit quality requirements. While a preview or basic display is easy to achieve and very standardized in Solana, it will be important to check the properties.files element for additional asset options. This is less standardized and will require developers to resolve data fragmentation as well as be able to detect the best asset for a given scenario.

As we suspected, Solana does offer more consistency than Ethereum. Solana still offers plenty of challenges in detection and options. We expect this to increase as NFTs become more diverse and offer more sophisticated options for display. Taking this into consideration with the diversity we see in Ethereum and what is expected from other chains, developers will have some fun challenges in displaying multi-chain artwork collections for collectors.

Find the code that was used during this analysis here.

Written by Brandon Williams at Atomic Form