0046 XLS-46d: Dynamic Non Fungible Tokens (dNFTs)

[xVet]

Abstract

This proposal aims to provide support for XLS-20 NFTs to modify/upgrade token properties.

XLS-20 provides -Non-Fungible Token- support, these tokens are immutable and don’t allow any changes. Currently NFTs can’t be modified, resulting often in new mints, which leads to ledger bloat that eat valuable resources as well as experimental approaches to use website endpoints to mimic dynamic abilities.

Apart from the use of immutable NFTs, there is a wide range of use cases around dNFTs (Dynamic Non-Fungible Tokens) which are considered mutable NFTs. The goal is to provide both options to developers and users to cover all aspects of non fungibility, while choosing the least invasive approach to achieve this functionality.

Motivation

Usually, NFTs are typically static in nature. A static NFT refers to an NFT that possesses unchanging and immutable characteristics stored on the blockchain, rendering them unmodifiable. These static NFTs encompass various forms like images, videos, GIF files, music, and unlockable components. For instance, an illustration of a basketball player making a shot into a hoop serves as an example of a static NFT.

On the other hand, dynamic NFTs, often abbreviated as dNFTs, represent the next phase in the evolution of the NFT landscape. These dynamic NFTs seamlessly integrate the inherent uniqueness of NFTs with the inclusion of dynamic data inputs. These inputs can arise from calculations conducted either on the blockchain or off-chain.

Oracles could supply dynamic real-world data to NFTs. To illustrate, a dynamic NFT might showcase real-time updates of a basketball player's performance statistics as they actively play.

Specification

3. New Transactors and Flags

We will specify the following:

 New Transactor
	- NFTokenModify

 New Flags
	- lsfMutable

3.1 lsfMutable

New flags for NFTokenMint:

Flag Name	Flag Value	Description
lsfMutable	0x00000016	Allow issuer (or an entity authorized by the issuer) to modify “URI”.

3.2 NFTokenModify

NFTokenModify is used to modify the URI property of a NFT:

Transaction-specific Fields

Field Name	Required?	JSON Type	Internal Type
TransactionType	✔️	string	UINT16

Indicates the account which is owning the NFT, in case of account not specified, it's implied that the submitting account is also the Owner of the NFT.

Field Name	Required?	JSON Type	Internal Type
Account		string	ACCOUNT ID

Indicates the NFToken object to be modified.

Field Name	Required?	JSON Type	Internal Type
NFTokenID	✔️	string	UINT256

The new URI that points to data and/or metadata associated with the NFT.

Field Name	Required?	JSON Type	Internal Type
URI	✔️	string	BLOB

Example (modify URI):

{
  "TransactionType": "NFTokenModify",
  "Owner": "rogue5HnPRSszD9CWGSUz8UGHMVwSSKF6",
  "Fee": "10",
  "Sequence": 33,
  “NFTokenID”: “0008C350C182B4F213B82CCFA4C6F59AD76F0AFCFBDF04D5A048C0A300000007",
  "URI": "ipfs://bafybeicmns4zsolhliv4ltmn5kipbwcscq4alpsmlayiipfkstksm4rtke/Vet.png",

  ...

  }

If lsfMutable is not set, executing NFTokenModify should fail!

If lsfMutable is set, executing NFTokenModify should fail when neither Issuer or Owner (or an authorized entity), according to the specific flag, is executing the transaction.

This approach takes into consideration that NFToken Flags are part of the NFTokenID, mutating anything that is part of the NFTokenID must be avoided.

[tequdev]

The flag description says that TransferFee can also be modified, but there is no mention of TransferFee in the NFTokenModify transaction.

Perhaps only the URI can be modified.

[xVet]

The flag description says that TransferFee can also be modified, but there is no mention of TransferFee in the NFTokenModify transaction.

Perhaps only the URI can be modified.

Correct! Thats a typo, will change! TransferFee can't be changed really without re minting the whole NFT, as it's part of the NFTokenID .

[virtumbe]

Thanks @xVet for doing this, as a EVM developer (and XRPL enthusiast) I was longer than today wishing for this to become reality.

In your example you are referring to a png as your URI. Isn’t a json not a better example as that holds all the attributes and properties?

Second: Is it an option for NFT owner to not accept these changes? There are for sure great use cases, but seeing a prince turning into a frog (without my permission) is a showstopper (for me). And yes I know this is already common case on EVM chains (without permission).

And does it also means the marketplaces or wallets need to incorporate a ‘refresh data’ function? Or are these changes picked up automatically?

#keepbuilding

[xVet]

Thank you for your feedback! Highly appreciated :)

1. I'd put the png and json actually as equal here, in reality the data is really arbitrary, the on chain change history of such a NFT is more front and center.

2. I see where you're coming from. This would certainly introduce another Transactor to accept the changes and i want to keep the footprint as small as possible for dNFTs with minmal changes. The assumption here is, the lsfMutableIssuer is a publicly visible Flag indicating this NFT is subject to future changes, so if you don't agree with this you would not acquire one.

We took the same approach with lsfBurnable for XLS-20.

[shawnxie999]

I think it only could work with lsfMutableOwner.

Since NFTs are stored in NFTokenPages, ledger must know the owner of the NFT in order to fetch from their page accordingly. So, if owner is one submitting NFTokenModify, ledger can fetch the NFT just fine.

On the other hand, if it is the issuer who tries to NFTokenModify, the ledger will not be able to fetch the NFT without knowing the current owner of the NFT.

So, lsfMutableIssuer is not really feasible, unless, NFTokenModify adds another parameter that accepts the address of the current NFT owner.

[xVet]

Yes exactly that is how i envisioned it. The issuer would have indexed the NFT on his end and knows who is currently the owner and specifies the current owner. Much like when you do NFTokenCreateOffer you would need to know who is currently the owner.

Else the TX should fail, if it's not the owner.

[shawnxie999]

Indicates the account which is owning the NFT, in case of account not specified, it's implied that the submitting account is also the Owner of the NFT.

For the account param in NFTokenModify, I believe account is a required parameter for all transaction, so it wouldn't be possible to accept the tx with specifying the account.

[mvadari]

The Owner could be the optional/implied field then.

[kennyzlei]

I'm generally supportive of this idea. I think it can unlock more use cases for NFTs beyond the traditional non-mutable use case. One particular use case I had in mind was for NFT reveals. Some collections like to sell their NFTs as hidden at first and then modify them to reveal them later.

I think a feature that may be nice to have here in addition to your spec is to have a way to set a limit to the number of times an issuer or owner may modify the NFT after mint. In some cases like NFT reveals, limiting the issuer to up to one modification will provide more trust to the owner. Alternatively, if there is a way to allow the issuer or owner to give up their modification permissions at some point, it may achieve the same effect

[shawnxie999]

yeah I agree with @tequdev that it won't be feasible to keep track of remaining changes on ledger.

[tequdev]

It may be possible to store the field within the NFToken object (that contains the URI).

If the URI in the NFToken object can be changed, then the new field in the NFToken object can be changed as well.

[kennyzlei]

Yeah I was imagining adding a mutable field to the NFToken object that gets adjusted/checked when a NFTokenModify transaction happens

[mvadari]

I assume people would be against making the NFToken size larger, given that metadata is already very large.

[kennyzlei]

I imagine this potential mutable field would also be optional, in that it would only be present if someone does mint an NFT with this mutability constraint. So hopefully this does not affect the ledger space for existing NFTs and a good portion of future ones if this was implemented. I do understand that any additional space usage should be scrutinized and evaluate if the tradeoff is worth it