-
Notifications
You must be signed in to change notification settings - Fork 59
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
base: main
Are you sure you want to change the base?
XCM Asset Metadata #125
Conversation
There was a problem hiding this 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!
Co-authored-by: Adrian Catangiu <adrian@parity.io>
There was a problem hiding this 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?
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
@xlc Could you please put this RFC for on-chain voting? |
/rfc propose |
Hey @xlc, here is a link you can use to create the referendum aiming to approve this RFC number 0125. Instructions
It is based on commit hash d16c0f71119a168e1be0cc4845902658c9ccaad2. The proposed remark text is: |
Voting for this referenda is ongoing. Vote for it here |
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.