SRC-7; Arbitrary Asset Metadata Standard

[bitzoic]

Abstract

The following standard attempts to define the retrieval of on-chain arbitrary metadata for any Native Asset. Any contract that implements the SRC-7 standard MUST implement the SRC-20 standard.

Motivation

The SRC-7 standard seeks to enable data-rich assets on the Fuel Network while maintaining compatibility between multiple assets minted by the same contract. The standard ensures type safety with the use of an enum and an Option. All metadata queries are done through a single function to facilitate cross-contract calls.

Prior Art

The use of generic metadata was originally found in the Sway-Lib's NFT Library which did not use Fuel's Native Assets. This library has since been deprecated.

A previous definition for a metadata standard was written in the original edit of the now defunct SRC-721. This has since been replaced with the SRC-20 standard as SubId was introduced to enable multiple assets to be minted from a single contract.

The standard takes inspiration from ENS's public resolver with the use of a String as the key. This should enable human-readable keys to help minimize errors and enable the standardization of certain keys, such as "image" as opposed to an enum or u64 representation of keys.

We also take a look at existing common metadata practices such as OpenSea's Metadata Standards and seek to stay backwards compatible with them while enabling more functionality. Through the combination of String keys and various return types, both pre-defined URIs or specific attributes may be stored and retrieved with the SRC-7 standard.

Specification

Metadata Type

The following describes an enum that wraps various metadata types into a single return type. There SHALL be the following variants in the MetadataType enum:

- String: String

The String variant SHALL be used when the stored metadata for the corresponding asset and key is of the String type. The String variant MUST be used when a URI is required but MAY contain any arbitrary String.

- Int: u64

The Int variant SHALL be used when the stored metadata for the corresponding asset and key is of the u64 type.

- Bytes: Bytes

The Bytes variant SHALL be used when the stored metadata for the corresponding asset and key is of the Bytes type. The Bytes variant should be used when storing custom data such as but not limited to structs and enums.

Require Functions

fn metadata(asset: AssetId, key: String) -> Option<MetadataType>

This function MUST return valid metadata for the corresponding asset and key, where the data is either a String, Int, or Bytes variant. If no metadata exists, the function MUST return None.

Rationale

The SRC-7 standard should allow for data-rich assets to interact with one another in a safe manner.

Backwards Compatibility

This standard is compatible with Fuel's Native Assets and the SRC-20 standard. It also maintains compatibility with existing standards in other ecosystems.

Security Considerations

This standard does not introduce any security concerns, as it does not call external contracts, nor does it define any mutations of the contract state.

Example ABI

abi SRC7Metadata {
     #[storage(read)]
     fn metadata(asset: AssetId, key: String) -> Option<MetadataType>;
}

[miohtama]

Hi,

I copied here my comment from the PR to hope its end up in the right place.

TL;DR

• I suggest you engage in discussion with stakeholders like wallets and data indexers and ask what they wish to see for the metadata standard
• Standard should define core metadata everyone should provide, so that assets can be properly presented in various user interfaces
• Off-chain data storage is privacy and security risk, and there is less or little reason to do off-chain in 2023

---

Here is some feedback regarding this standard (discussed with @dmihal earlier)

• Because on-chain is no longer expensive (it's not 2016 anymore) and metadata is very small, most of the data should be stored on-chain instead of an external source to avoid privacy and security issues (see here)
• This information is going to be consumed by wallets, frontends and data indexers: have you engaged to discussions on any of these groups what they want to see on the metadata standard?
• Not only the interface how to fetch data, but the data content itself must be standardised
• You definitely want to have a method that fetches all data attributes once (to a some certain nice round limit like 256) attributes

When attributes you want to standardise

• Website
• Logo, various formats
  • Dark background
  • White background
  • Standard dimensions like 256x256, pick whatever Apple has decided
  • Note that sufficiently small logo files can be directly stored inline compressed on-chain, avoiding any issues with privacy leaks and exploits when fetching images
• Social media links
  - Twitter
  - Discord
  - Telegram
  - etc.
• Trading related
  • name; keypairs where to official trade the token
  • to avoid users landing on a phishing site through a Google
• Security incident contact email

For more inspiration, look what EtherScan, CoinGecko and TrustWalllet token repository offers as a metadata about the tokens.

Happy to help you to come up with descriptions of key metadata attributes any asset should have.