Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRC-15; Off-Chain Native Asset Metadata #156

Open
bitzoic opened this issue Oct 23, 2024 · 0 comments · May be fixed by #159
Open

SRC-15; Off-Chain Native Asset Metadata #156

bitzoic opened this issue Oct 23, 2024 · 0 comments · May be fixed by #159
Assignees
Labels
Draft This standard is currently in draft. Experimentation and feedback is encouraged.

Comments

@bitzoic
Copy link
Member

bitzoic commented Oct 23, 2024

SRC-15: Off-Chain Native Asset Metadata

The following standard attempts to define arbitrary metadata for any Native Asset that is not required by other contracts onchain in a stateless manner. Any contract that implements the SRC-15 standard MUST implement the SRC-20 standard.

Motivation

The SRC-15 standard seeks to enable data-rich assets on the Fuel Network while maintaining a stateless solution. All metadata queries are done off-chain using the indexer.

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 SRC-7 standard exists prior to the SRC-15 standard and is a stateful solution. The SRC-15 builds off the SRC-7 standard by using the Metadata enum.

Specification

Metadata Type

The Metadata enum from the SRC-7 standard is also used to represent the metadata in the SRC-15 standard.

Logging

The following logs MUST be implemented and emitted to follow the SRC-15 standard.

SRC15MetadataEvent

The SRC15MetadataEvent MUST be emitted once for each distinct piece of metadata.

There SHALL be the following fields in the SRC15MetadataEvent struct:

  • asset: The asset field SHALL be used for the corresponding AssetId for the metadata.
  • metadata: The metadata field SHALL be used for the corresponding Metadata which represents the metadata of the asset.
  • sender: The sender field SHALL be used for the corresponding Identity which made the function call that has emitted the metadata of the asset.

Example:

pub struct SRC15MetadataEvent {
    pub asset: AssetId,
    pub metadata: Metadata,
    pub sender: Identity,
}

Rationale

The SRC-15 standard allows for data-rich assets in a stateless manner by associating an asset with some metadata that may later be fetched by the indexer.

Backwards Compatibility

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

Security Considerations

When indexing for SRC-15 metadata, developers should confirm that the contract that emitted the SRC15MetadataEvent is also the contract that minted the asset that the metadata associates with.

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

Example Implementation

TODO

@bitzoic bitzoic added the Draft This standard is currently in draft. Experimentation and feedback is encouraged. label Oct 23, 2024
@bitzoic bitzoic self-assigned this Nov 11, 2024
@bitzoic bitzoic linked a pull request Nov 12, 2024 that will close this issue
9 tasks
@bitzoic bitzoic linked a pull request Nov 12, 2024 that will close this issue
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Draft This standard is currently in draft. Experimentation and feedback is encouraged.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant