SRC-7; Arbitrary Asset Metadata Standard

[bitzoic]

Type of change

• New standard

Changes

The following changes have been made:

• Introduces the SRC-7; Arbitrary Asset Metadata Standard

Notes

• A separate standard will be defined for off-chain data retrieval
• This PR will fail to compile until a new release of forc

Related Issues

Closes #18

[K1-R1]

LGTM, happy to approve once @Braqzen 's comments are addressed

[Voxelot]

Is there any reason to enforce metadata to be stored by the same contract that mints the NFTs? It seems like this interface would support metadata for any AssetId, even if the contract doesn't own it.

[bitzoic]

Is there any reason to enforce metadata to be stored by the same contract that mints the NFTs? It seems like this interface would support metadata for any AssetId, even if the contract doesn't own it.

I believe the best practice would be to ensure that the contract that mints the asset implements the SRC-7 standard, hence requiring that the SRC-20 standard must also be implemented. With a sub id, anyone can verify that the asset was minted from the said contract. There could be security implications if another contract holds the metadata without a way to ensure that this data is valid.

[chappie1998]

With metadata, can there be a function called token_uri, the same as erc-1155? This will make it easy to get NFT data. Because Mint will be considered an NFT, and just after that, there will be a call to get metadata (.json file) to store that data offline.

[bitzoic]

With metadata, can there be a function called token_uri, the same as erc-1155? This will make it easy to get NFT data. Because Mint will be considered an NFT, and just after that, there will be a call to get metadata (.json file) to store that data offline.

While we intend to add an off-chain data retrival standard that focuses more on the implementation rather than an interface, to query a token's URI the "URI" key can be used.

For example, here we are using the "URI" key:

fn foo(contract_id: ContractId, asset: AssetId) {
     // Use the SRC-7 standard to query any arbitrary contract without
     // the need to know any other ABI implementations it may have
     let contract_abi = abi(SRC7, contract_id);

     // Define the key we want, in this case "URI"
     let key = String::from_ascii_str("URI");

     // Fetch the URI with the asset and key
     let metadata = contract_abi.metadata(asset, key);

     // Ensure the data we retrieved is what we expected
     assert(metadata.is_some());
     let string_data = match metadata.unwrap() {
          Metadata::String(data) => data,
          _ => revert(0),
     }
}

[miohtama]

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.

[bitzoic]

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.

Yes absolutely agree that we should standardize attributes and keys along with what sort of data they return.

Our intent is to do this across multiple categories which become living standards building atop this one, allowing for additions over time as needed as more projects get built out onchain. The first example of this is the SRC-8 standard which defines the metadata and keys for any bridged assets.