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

XCM Asset Metadata #125

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

mrshiposha
Copy link

This is a refined version of the XCM Asset Metadata RFC.

This PR supersedes the PR opened in the xcm-format repository following the migration of XCM RFCs to the Fellowship RFCs.

Summary

This RFC proposes a metadata format for XCM-identifiable assets (i.e., for fungible/non-fungible collections and non-fungible tokens) and a set of instructions to communicate it across chains.

Copy link
Contributor

@acatangiu acatangiu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

text/0125-xcm-asset-metadata.md Outdated Show resolved Hide resolved
text/0125-xcm-asset-metadata.md Outdated Show resolved Hide resolved
Co-authored-by: Adrian Catangiu <adrian@parity.io>
@anaelleltd anaelleltd added the Proposed Is awaiting 3 formal reviews. label Nov 3, 2024
Copy link
Contributor

@xlc xlc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe explicit define MetadataMap and MetadataKeys

type MetadataKey = Vec<u8>;
type MetadataValue = Vec<u8>;
type MetadataMap = BTreeMap<MetadataKey, MetadataValue>;
type MetadataKeys = BTreeSet<MetadataKey>; // or call it MetadataKeySet?

text/0125-xcm-asset-metadata.md Outdated Show resolved Hide resolved
text/0125-xcm-asset-metadata.md Outdated Show resolved Hide resolved
@xlc
Copy link
Contributor

xlc commented Dec 13, 2024

Let me know if you want me to put this for onchain voting


The `ReportMetadata` can be used without origin (i.e., following the `ClearOrigin` instruction) since it only reads state.

Safety: The reporter origin should be trusted to hold the true metadata. If the reserve-based model is considered, the asset's reserve location must be viewed as the only source of truth about the metadata.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're envisioning this metadata to be useful for fungible assets as well? In that case, would it be something small like name, decimals, symbol?

If that's the case, I guess we only need to have this security measure for NFTs. Runtimes should identify foreign NFTs and not report the metadata for them since they don't hold the source of truth.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're envisioning this metadata to be useful for fungible assets as well? In that case, would it be something small like name, decimals, symbol?

Yes, since Asset { id: ASSET_ID, fun: NonFungible(AssetInstance::Undefined) } now means a collection.
However, we'd need some standards so different fungible implementations could report something universally applicable.

If that's the case, I guess we only need to have this security measure for NFTs.

What about the derivative fungible collections? They might also have a symbol, decimals, etc. However, other chains shouldn't use derivative collections' information as true information (though maybe they might want to inspect such information?).

Runtimes should identify foreign NFTs and not report the metadata for them since they don't hold the source of truth.

True. Yet, a counterparty might act maliciously. I wrote this safety note just to highlight that it is our decision on whom to trust.


Regarding ergonomics, no drawbacks were noticed.

As for the user experience, it could discover new cross-chain use cases involving asset collections and NFTs, indicating a positive impact.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if there are any metadata keys that we can make known and standard instead of leaving everything as a Vec<u8>. But I think this is a good start and cross-chain NFT standards can start to emerge from this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, metadata standards should exist. This is one of the tasks of the NFT Collective (a project launched by Unique Network).
However, this RFC outlines the technical possibility of interchanging data in a universal way via XCM.

@mrshiposha
Copy link
Author

@xlc Could you please put this RFC for on-chain voting?

@xlc
Copy link
Contributor

xlc commented Jan 18, 2025

/rfc propose

@paritytech-rfc-bot
Copy link
Contributor

Hey @xlc, here is a link you can use to create the referendum aiming to approve this RFC number 0125.

Instructions
  1. Open the link.

  2. Switch to the Submission tab.

  1. Adjust the transaction if needed (for example, the proposal Origin).

  2. Submit the Transaction


It is based on commit hash d16c0f71119a168e1be0cc4845902658c9ccaad2.

The proposed remark text is: RFC_APPROVE(0125,7e5c5f974903fc550ec31aa565177f22675f1238255dd5d7c89561d33b654b49).

@xlc
Copy link
Contributor

xlc commented Jan 18, 2025

Copy link

Voting for this referenda is ongoing.

Vote for it here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposed Is awaiting 3 formal reviews.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants