Zilliqa announced the latest iteration of their NFT metadata standard as built for the Zilliqa ecosystem. With this update Zilliqa says that ZRC-7 will standardize the structuring of NFT metadata with regards to off-chain storage, and do so in a JSON structure. The ZRC-7 standard is open for public review until February 14, 2022.
Introduction
NFT metadata describes the properties of a given NFT and is an essential part of any NFT. It can contain data like names, resources (images, video, document, code, and 3D models), creator or artist details, and more.
Metadata is necessary across the whole spectrum of creator economy applications. For example, if an NFT represents an in-game item such as a magic potion or a legendary sword — the metadata would consist of its name, rarity, value and item-specific attributes.
ZRC-7 describes the NFT metadata standard specifically for the Zilliqa ecosystem. Compatible with both ZRC-1 and ZRC-6 NFT standards, it is designed to be broad enough for any future NFT standards.
The Problem Today
Today, different NFT projects in the ecosystem use different metadata structures. Also, some store it within the smart contract state, while others store it within off-chain storage. There is no widely accepted convention on how to structure NFT metadata. ZRC-7 provides a standard on how to structure such metadata on off-chain storage.
ZRC-7 NFT Metadata Standard
ZRC-7 NFT metadata standard provides a JSON structure for NFT metadata that is stored in off-chain storage.
Specification
The specification can be found at https://github.com/Zilliqa/ZRC/blob/master/zrcs/zrc-7.md.
Different types of metadata structure
ZRC-7 defines two different types of metadata structure:
- Collection metadata structure
- Token metadata structure
Collection metadata structure
The collection metadata is optional in ZRC-7. It defines properties that are global and universal to all tokens within a particular NFT contract. Such metadata are useful in providing a global description and properties of the NFT to marketplaces and metaverses. As such, one need not utilise out-of-band channels to individually inform marketplaces and metaverses — the data can be easily accessed by them.
By convention in ZRC-7, collection metadata should be accessible via “<base_uri>metadata.json” e.g. “ipfs://QmZILGa7zXUbixvYJpgkRkaSCYEBtSwgVtfzkoD3YkNsE1/metadata.json”.
Available properties in collection metadata are
- “name”
- “description”
- “external_url”
- “animation_url”
Token metadata structure
Each token in both ZRC-1 and ZRC-6 has its own unique token URI, which points to a JSON file containing the specific token metadata. ZRC-7 token metadata structure is designed to be broad, and not limited to specific use cases. Below, we explain the rationale behind some of the properties found in the token metadata structure.
Resource
Many of the existing metadata standards such as those used by Opensea and Algorand are geared towards images and use a property called “image” to represent them. However, as we venture further into Web3 and Metaverse, NFTs can be represented in many forms like images, videos, audios, documents, codes, and even 3D models. As such, in ZRC-7, we broaden the scope and use “resource” instead of “image” property to represent any file format beyond images.
Resource MIME type
The standard also provides an optional property called “resource_mimetype”. It provides the MIME type of a particular resource. This will be useful for the identification of a resource type before downloading the actual resource. For example, a metaverse could first read the MIME type of the NFT and determine whether it could be rendered onto the metaverse.
ZRC-7 MIME type follows the IANA media discrete type, which consists of a type and a subtype i.e. “type/subtype” to represent a single file. For example, to represent a png image, one can specify the MIME type to be “image/png”. The full IANA media type list can be found at https://www.iana.org/assignments/media-types/media-types.xhtml#application.
Resource integrity
It may be important for many use cases to ensure the integrity of the resource. For instance, if the resource is code or script, the user may want to verify the integrity of the resource before executing it.
To facilitate this, the optional “resource_integrity” property can be used to provide the digest of the resource. The “resource_integrity” value consists of the Secure Hash Algorithms (SHA) and the Base64 encoded SHA digest. For example, if the SHA-256 is the hash function and “8z5D++W8NDHzFm5rY4/JxkXlIlU2cSQ65XjighJVk9U=” is the Base64 encoded SHA digest of the resource file, the “resource_integrity” is “sha256–8z5D++W8NDHzFm5rY4/JxkXlIlU2cSQ65XjighJVk9U=”
Resource attributes
Each resource can come with numerous attributes to describe it. ZRC-7 allows for an optional property called “attributes”. The “attributes” value includes an array of objects, consisting of “trait_type”, “value” and “display_type” (optional).
Other useful properties
Lastly, the standard also specifies two optional properties “external_url” and “animation_url”. “external_url” is a URL that points to a website presenting the asset. “animation_url” is a URL to a multi-media attachment to the asset e.g. MP4. It can be used as a preview for the resource.
Community Review
We are now opening this ZRC-7 for public review starting today to 14 February 2022 — all marketplace builders, NFT project teams, and community members are invited to participate! Everyone is encouraged to discuss and provide feedback at our Github discussion page. We’re excited to finalise this specification shortly after the public review phase is completed.
via this site
