Summary
Offer more flexibility to NFTs and SFTs to respond to new use cases and remove the dependency on IPFS for attributes.
Motivation
-
Spica upgrade brought dyNFTs allowing projects to update NFTs, such as name, image, and attributes. Friction is the dependency on IPFS and therefore off-chain interaction to update an NFT.
-
Gaming, ticketing, RWA etc.. need a clear and flexible standard to respond to their needs.
-
Risk of not using MultiversX as infrastructure due to lack of tailored solutions.
Solution
No protocol changes are needed, all are based on ES and APIs.
-
Format standard:
Creating an NFT or a SFT should be in this format which works retroactively for existing collections:
Attributes Field:
Attributes: On-chain attributes (optional)
Metadata: CID attributes (optional)
Tags: tags (optional)
URI 1: Media stored on IPFS.
URI 2: Dynamic attributes, not limited to IPFS (Game Server, API endpoint etc..) (optional) -
API & ES Logic: The API and ES now return on-chain attributes if no Metadata is passed or Metadata if no Attributes are passed.
-
Branding: For the API & ES to be able to return the on-chain attributes, the project has to do a branding request including the format of the on-chain attributes.
-
Marketplaces, Explorer, xSpotlight, Wallets: Check if URI 2 exists and is responsive. If not, use the attributes field.
The main goal is to create a standard that requires the least amount of changes while working retroactively.
Those changes allow SCs to read and write the attributes of NFTs directly on-chain without depending on an external microservice to do the IPFS uploading and pinning.
Example: NFT of a character gains XP and levels UP.
Existing solution: The server needs to check the SC, create a new JSON, upload it to IPFS, Pin it, and send a transaction to update the NFT with the new level.
New solution: SC can read the XP and Level, trigger an update of the Level and rewrite the attribute field without depending on IPFS.
Establishing URI 2 as a dynamic attributes field ensures that marketplaces can display the latest values of said NFT based on the game server. This was done on a per-project basis like Cantina Royale with XOXNO.
Example: Player profile stats.
Existing solution: No standard, the projects do it differently, contacting each marketplace/explorer/xSpotlight for them to adapt to their solution.
New solution: Making URI 2 the standard for dynamic data (not blocked to IPFS) ensures projects and infrastructure providers don’t need to adapt on a case-by-case basis and the data is available from the get-go.
Impact
-
Clearer Standard: Be able to offer a clear standard and thorough examples for each use case of NFT/SFTs making MultiversX an attractive solution.
-
Easier integrations: Removes the need for custom integrations for most use cases.
-
Removes off-chain dependency: Attributes can now be fully updated on-chain without needing to use IPFS to store each change
FAQ
Q: Does it change anything for existing collections?
A: No, this proposal has been designed to be retroactive and therefore will still display all information as it used to be.
Q: Does it benefit existing collections?
A: Yes, dynamic NFTs will be able to edit the URIs to display dynamic data. The attributes field can also be updated to contain on-chain attributes, thereby removing the IPFS dependency.
Q: Why make changes to the standard?
A: A much clearer and more flexible standard is needed to respond to the requirements of projects. We’ve seen those changes and similar standards being implemented on other chains.