Introduction
Over the course of last year, we have seen a rise in the popularity of NFTs on the Songbird network. At Sparkles, we are always looking towards the ever expanding evolution of NFTs as well as bringing mass adoption of NFTs to Flare Network with an optimum user experience.
With the fast approaching TDE (Token distribution event) of FLR and the observations we have made on the Songbird canary network, we have realized that there is a need and urgency for a unified metadata standard for NFTs on the network that projects can adopt to ensure interoperability.
What is NFT metadata?
NFT metadata is used by applications (such as NFT marketplaces) to display digital assets in-app.
The way in which the metadata is structured (metadata standards) affects how such applications do, or do not, display an NFT.
As such, the leading existing marketplaces on established EVM blockchains have a shared understanding in applying basic metadata standards, whilst also unifying certain ‘industry standards’ for additional metadata and structuring (such as different and/or multiple file types).
As a basic starting point, these EVM NFT marketplaces follow the official ERC721 metadata standard for ERC-721 NFTs, and the Enjin Metadata suggestions for ERC-1155 NFTs.
Unfortunately, the critical component of NFT metadata is something which, at present, appears to be being overlooked by some of the Songbird and/or Flare community.
Importance of unified metadata standard
The importance of NFT metadata was raised in an article by Binance published on 4 November 2022, where they concluded: “While it’s often overlooked when discussing NFTs, a digital asset’s metadata is arguably one of its most crucial components…the importance of metadata is likely to grow as the NFT industry continues to evolve and adoption becomes more widespread.”
When inconsistencies occur, ranging from a failure to apply the basic structuring of metadata, to a failure to apply more widely recognized industry standards for additional metadata properties, it can impact on various levels, such as:
1. Compatibility issues arise between NFT applications on the network, e.g., if some applications facilitate the creation of NFTs with poorly/wrongly structured metadata, yet display those NFTs as if the metadata were structured correctly, despite not adhering to metadata standards during the minting process;
2. Perception that the network is disjointed, inconsistent, and uncertain as to how NFTs should be structured, which is potentially off-putting to experienced and/or serious NFT collectors;
3. Inexperienced NFT buyers and sellers purchasing NFTs with ‘bad metadata’ which does not adhere to metadata standards and is poorly structured, yet being unaware of this due to point 1 (above); and
4. Future cross-chain interoperability issues and/or display issues potentially arise when bridging NFTs with ‘bad metadata’ from Flare, and/or NFTs with ‘good metadata’ to Flare.
Metadata Standards on Other Chains and Marketplaces
In applying the above metadata standards, the basic starting point is as follows:
{
“name”: “NFT name”,
“image”: “NFT image”,
“description”: “NFT description”,
“attributes”: […]
}
As mentioned, there can also be additional metadata properties (e.g., an NFT may contain both an image file and a video file, or an NFT may contain no image file and solely a video file).
For NFT applications to properly display these two distinct file types, specific metadata property names are required, with each property name accommodating a specific file type for display purposes.
When applying metadata standards, there is currently a consensus amongst NFT marketplaces on Ethereum and Binance Smart Chain that the following applies:
1. An “image” property should solely relate to image type files (e.g., .PNG, .JPG and .GIF). An “image” property should not contain video type files; and
2. An “animation_url” property should solely relate to animation/video type files (e.g., .MP4, .M4A and .MOV). An “animation_url” property should not contain image type files.
The below demonstrates how existing EVM compatible NFT marketplaces (and their respective blockchains) currently handle metadata standards:
Opensea (multichain)
Opensea’s metadata standards (available here) implement the following additional properties, which are followed as metadata standards by other NFT marketplaces and blockchains:
Rarible (multichain)
Rarible’s metadata standards (available here) implement those same properties:
Binance NFT, Gallar, Bazaar, NFTrade, TofuNFT, NFTb, Treasureland and PancakeSwap (BSC)
Binance Smart Chain’s metadata standards (available here), and the leading NFT marketplaces on BSC, leverage Opensea’s current metadata standards:
Solution
Until this point, the lack of NFT metadata standards on Songbird have resulted in a number of NFT collections that have been created with inconsistent metadata structures.
To find a solution, the Sparkles team has conducted comprehensive research into metadata standards across different blockchains where the majority of NFTs are traded. Consequently, the Sparkles team has put together a metadata standard document which can be found here.
Moving forward, Songbird and Flare projects, collections and applications are highly encouraged to adopt and align with this set of metadata standards to ensure future interoperability across all marketplaces, projects, and seamless cross-chain interoperability.
Sparkles is committed to remaining ahead of the curve when it comes to NFT ecosystem development, and we will keep open communications with all companies/brands/collections on Songbird & Flare, along with other blockchains, to ensure we develop as a unified community when it comes to NFTs and achieve Flare’s goal of connecting everything.
About Sparkles
Sparkles is the largest open NFT marketplace on the Flare and Songbird Network.
Website | Twitter | Instagram | Medium | Discord
About Flare Network
Flare is a blockchain built to connect everything. It presents developers with a simple and coherent stack for decentralized interoperability, allowing developers to serve multiple communities and ecosystems simultaneously through a single deployment.
