Composable NFTs/SFTs - MIP-1

MIPs
1

NFTs owning NFTs

Currently MultiversX has a set of built in functions for NFTs: token manager, create, burn, update, mint. It implements transfer and execute, multi transfer. Smart contracts can own NFTs, they can create new NFTs, can update attributes, update URIs.

Equipping. Our goal is to be able to equip NFTs with other NFTs, enabling ownership, attribute updates and some extra features. This can be done through a new SC standard - we will find some name for it - for now let’s call it MergeNFT. The basic contract should be as simple as possible, as it is a small standard. On top of that, developers and the market can create multiple usecases. So in the first place we will focus on building the MINIMUM VIABLE SMART CONTRACT to enable the NFTs owning NFTs feature.

Let’s think about the first usecase: user owns a character and buys a sword for it. He wants to equip that sword to the character and have a new image with both of the things combined. There is no game involved, it is only about 2 NFTs, each of them having one image, a set of attributes, and royalties.

The user makes a multiESDTNFTTransfer for those 2 NFTs to the new contract, the contract keeps the 2 NFTs and will send the user a new one, which contains some merged information on those 2. We do not need to duplicate the information of URIs, Attributes as those are already stored in the blockchain - we need to only create the smallest possible information through which every TOOL (marketplaces, indexer, xSpotLight, API, etc) will understand and can show the results of such merge. Furthermore, merging and selling a merged NFT should send the royalties back to the original owners - this is somewhat harder to do - but let’s try it - discussing a little bit later. If the merging of tokens is from the same artist there is no problem as royalties go to the same place. So in order to help creators we will check if the address of royalties for the selected NFTs is the same. To make it clear for users, we could even check that the address of royalties is the same as the owner of the SC.

MergeNFTs:

Take the list of NFTs from the multiESDTNFTTransfer, check that all NFTs have the same address for royalties (this can be eliminated in some usecases). Create a new NFT with the following information: Royalties - it has to be the maximum of all the NFTs merged. Hash - nothing Attributes - open ended - up to developer to do what he wants URIs - list of [TokenID, nonce and value] as first URI

No need to keep any storage in the contract.

UnMergeNFTs:

User comes with a merged NFT. The contract will check if the tokenID is the one the contract generated. The contract takes the list of NFTs from the URIs of the merged NFT, burns the NFT and sends back as multiTransferESDT the list of tokens from the attributes.

Royalties:
This contract has to implement the claimRoyalties module - as will create NFTs and needs to claim royalties from marketplaces. Distribute royalties: needs a new function to distribute the royalties to the original royalty owner.

In a sense of integration, we need to register these contracts - using the contract address, hash, tokenID in API in order to make sure the mergedNFTs will appear as they should be.

NFTs owning SFTs:

As you can see from the above resolution, there is no limitation of NFTs owning actual SFTs. So your character could own 10 mana potions, 100 apples, or stuff like that - everything being encoded in the attributes.

Full implementation can be seen here: https://github.com/multiversx/mx-sdk-rs/tree/master/contracts/modules/src/token_merge

10 Likes
2

Hi @robert,

Incredible idea for this new standard, funny that we talked about this exact subject with @joaquim few days before you posted this MIP.

Maybe MetaSFT can be a logical name for this one ?

As MetaESDT are a non-fungible collection of fungible ESDT as each nonce have their own intrinsec property (like unlocking schedule for xMEX), but since they have the same nonce (and therefore the same properties), two xMEX token are fungible;

A MetaSFT will be a non-fungible collection of a set of NFT/SFT, but that can be fungible if they have the same property. For example if you merge the NFT-1 with the sword-1, you will have a specific new asset that can be created theoretically as many times as you have a pair of NFT-1 and sword-1.

This would enable a certain composability on marketplace all the same merge could be listed as a single one offer like SFT, and thus simplify the UX/UI for users.

Some collections will only have unique merges, but it’s very likely that others will have merges that are identical, so that we can be sure that a single standard meets all the usecases!

I don’t know if you follow me on this, but the idea seems logical to me!

2 Likes
3

Hi @robert and @foudres,

I’ve been thinking about composable NFTs and I would like to share a different logic for them.

I’ll use the same example of an NFT of a character, a sword and some consumables.

The character is an NFT, the sword is an NFT in “Weapon” collection and each consumable is an SFT in “Consumable” collection.

The Merge SC is told which NFT or SFT is the principal, and therefore needs to be included, and which other N/SFT are allowed.

The user can then transfer the principal + any other allowed tokens, the smart contract updates the information of the principal and returns it but keeps the others until they are unequipped again.

This ensures better control and automation from each project as we can expect them to have created the illustration + information for each combination.

In addition, it allows to separate each merge to its distinctive SC, facilitating the tracking.

Example:
Equip SC = Character + Items
Forge SC = Items
Upgrade SC = Weapon + Items

I think this is a better suited solution since:

  • No need to mint/burn N/SFTs. Supply remains identical.
  • The Principal NFT remains the same nonce but evolves with time. We could track his evolution.
  • Royalties don’t need to be verified as the NFT remains the same.
  • Marketplace history of the Principal NFT reflects his whole journey.

Looking forward to hearing your thoughts.

Edit: Any Principal needs to be an NFT and not a SFT due to its unique and changeable properties.
We could create a different SC for upgrades. Where a certain recipe increases the supply of an SFT by 1 and sends it back while it burns/reduced supply of the ingredients.

Which reminds me, you need at least 1 SFT in possession to be able to increase its supply? Maybe that’s worth discussing too, allowing SC to increase a supply even if they don’t have it in stock. Ensuring the supply is correct and not correct+1.

4

Hi @robert

This is a super exciting update for multiple reasons and will greatly enhance the way projects and business can use and integrate NFTs for their purposes.

As a not-so-techy-person, I have a clarificatory question: With the Metadata being updateable, does this also mean that an image attached to the NFT can easily be changed? So, in our example, if we buy a sword for our character, could this update not just be displayed by “systems” that “read” the new metadata (e.g. gaming interfaces), but could this also be easily be reflected in the image the user sees in their xPortal App? Or would this require the burn and re-mint of an NFT?

1 Like
5

Hey @chessucation!

Indeed, we will be able to update the URI and, therefore, the image and JSON of the NFTs.

You can read this MIP which goes more indepth on this topic:

From what I understand, this part is more focused on creating a Smart Contract standard that would allow, using the features from the MIP-5, to Merge and UnMerge NFTs!

3 Likes
6

Exactly. The MIP-5 can be used with the composable SC.

1 Like
7

Hey.

Metadata is updateable right now, but only when you send it to a contract which has the role of update attributes and can rewrite it. With the dynamic NFTs, MIP-5, this can be done in an easier way, especially for those swords, or like digital passes, no need to burn and re-mint. And all updates like this will be visible in all systems, thus in xPortal as well.

1 Like