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

[xVet]

• Update: This discussion has been closed in favor of the PR.
• Feel free to post comments or questions there: XLS-0046d-dynamic-non-fungible-tokens #205

title: Dynamic Non Fungible Tokens (dNFTs)
type: Spec
author: Vet 
co-author: Mayukha Vadari, TeQu

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
	- tfMutable

3.1 tfMutable

New flags for NFTokenMint:

Flag Name	Flag Value	Description
tfMutable	0x00000010	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
Owner		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.
If a URI is omitted then the corresponding URI record in the XRP ledger, if present, is removed.

Field Name	Required?	JSON Type	Internal Type
URI		string	BLOB

Example (modify URI):

{
  "TransactionType": "NFTokenModify",
  "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
  "Owner": "rogue5HnPRSszD9CWGSUz8UGHMVwSSKF6",
  "Fee": "10",
  "Sequence": 33,
  “NFTokenID”: “0008C350C182B4F213B82CCFA4C6F59AD76F0AFCFBDF04D5A048C0A300000007",
  "URI": "697066733A2F2F62616679626569636D6E73347A736F6C686C6976346C746D6E356B697062776373637134616C70736D6C6179696970666B73746B736D3472746B652F5665742E706E67",

  ...

  }

If tfMutable is not set, executing NFTokenModify should fail!

If tfMutable is set, executing NFTokenModify should fail when neither Issuer or an account authorized via NFTokenMinter, 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

[scottschurr]

I'm surprised that there has not been more discussion regarding who has the rights to modify the URI of an NFToken. The spec gives a hand wave at this:

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.

There are consequences to the specific choices made here.

1. To me, the most obvious entity that should be allowed to modify the URI is the Issuer. Presumably they are responsible for maintaining whatever information is at the other end of the URI. It perhaps makes sense that they need to change the URI in order to maintain the value of the NFToken.
2. It's not clear to me why the Owner of the NFToken should have the right to modify the URI of their NFToken. Presumably the NFToken was created as some kind of unique creation by the Issuer. If I own a painting signed by a famous artist (the Issuer) should I have the right to spray paint over that painting and then sell it as an artwork signed by the Issuer? What is the business case for allowing this kind of behavior?
3. The spec is not at all clear about who "an authorized entity" might be or how they would be identified on the ledger. The only "authorized entity" I can think of would be the NFTokenMinter designated by the Issuer. That sort of makes sense to me? But it means that an Issuer must now place a great deal more trust in their designated NFTokenMinter than they did previously. Remember that an Issuer is allowed to change their NFTokenMinter at any time. If they change their NFTokenMinter, then that new minter now would have authorization to replace the URI of any NFToken that the Issuer had previously created.

Thoughts? What am I missing here?

[shawnxie999]

I think the PR implementation only allows authorized minter or the issuer to modify URI. Maybe this spec needs to be updated

[xVet]

I think the PR implementation only allows authorized minter or the issuer to modify URI. Maybe this spec needs to be updated

Correct only the issuer and authorized entities which according to the documentation the NFTokenMinter

[scottschurr]

@tequdev wrote:

NFTokenMinter can burn a burnable NFT, and I think it has stronger authority than modifying the URI.

That's an excellent point. You are right. This change does not increase the level of trust an Issuer must place in a Minter. That level of trust already needed to be very high. Thanks.

[xVet]

I'm surprised that there has not been more discussion regarding who has the rights to modify the URI of an NFToken. The spec gives a hand wave at this:

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.

There are consequences to the specific choices made here.

1. To me, the most obvious entity that should be allowed to modify the URI is the Issuer. Presumably they are responsible for maintaining whatever information is at the other end of the URI. It perhaps makes sense that they need to change the URI in order to maintain the value of the NFToken.
2. It's not clear to me why the Owner of the NFToken should have the right to modify the URI of their NFToken. Presumably the NFToken was created as some kind of unique creation by the Issuer. If I own a painting signed by a famous artist (the Issuer) should I have the right to spray paint over that painting and then sell it as an artwork signed by the Issuer? What is the business case for allowing this kind of behavior?
3. The spec is not at all clear about who "an authorized entity" might be or how they would be identified on the ledger. The only "authorized entity" I can think of would be the NFTokenMinter designated by the Issuer. That sort of makes sense to me? But it means that an Issuer must now place a great deal more trust in their designated NFTokenMinter than they did previously. Remember that an Issuer is allowed to change their NFTokenMinter at any time. If they change their NFTokenMinter, then that new minter now would have authorization to replace the URI of any NFToken that the Issuer had previously created.

Thoughts? What am I missing here?

Thanks Scott, great comment !

1 & 2: We agree ! Only Issuers and accounts authorized via NFTokenMintershould be allowed, Owners should not be allowed to alter such NFT, this would take away the integrity of the NFT -> Changed the spec, this was a mistake !

3. Correct, its the authorzized NFTokenMinteraccount we are talking about here. Currently an account authorized this way has the ability to mint completely new NFTs on behalf the issuer. If someone mints new NFTs on behalf of an Issuer without their consent is a huge damage you can do -already- e.g a marketplace mints NFTs on behalf of an Issuer of tokenized Diamonds. In this case, the Issuer can sue the authorized account as the Issuer should have a contract in place limiting the abilities and their misuse of an authorized account.

In case of modifying the URI, if an authorized account updates the URI of NFTs (only those with lsfMutableflag) then the same approach should be taken as if someone mints unbacked/out of contract NFTs without Issuer consent.

Does this make sense ? Essentially we aren't introducing a feature that gives someone more power than they already would have and even if someone would see it that way, you can then avoid setting the flag as its not forced. Only trusted and contracted NFTokenMinter accounts should be considered, i rather deal with the risk off chain than having it on chain in this aspect.

Let me know your thoughts!

[scottschurr]

Thanks @xVet. Yes, I think this is a good resolution. As both you and @tequdev point out, a Minter already requires a great deal of trust from the Issuer. Giving the Minter the new ability to modify a mutable URI does not really change that balance of power.

The new phrasing of the spec...

If lsfMutable is set, executing NFTokenModify should fail when neither Issuer or an account authorized via NFTokenMinter, according to the specific flag, is executing the transaction.

looks good to me. I especially appreciate the clarity of directly referring to the NFTokenMinter for how the authorization is provided.

Thanks for the change.

[scottschurr]

Just a quick note that the implementation has diverged from the spec regarding the URI field in the NFTokenModify transaction. In the implementation the URI field is optional, not required. Also, in the implementation if the URI field is omitted then the URI record associated with the NFTokenID is removed from the ledger.

Personally, I think the implementation got this one right. The NFTokenModify implementation behaves similarly to the NFTokenMint transaction with respect to the URI field. I think preserving that symmetry is the right call.

My suggestion would be to modify the spec to say the URI field is optional, and if the URI field is omitted, then the corresponding URI record in the ledger, if present, is removed.

[xVet]

Just a quick note that the implementation has diverged from the spec regarding the URI field in the NFTokenModify transaction. In the implementation the URI field is optional, not required. Also, in the implementation if the URI field is omitted then the URI record associated with the NFTokenID is removed from the ledger.

Personally, I think the implementation got this one right. The NFTokenModify implementation behaves similarly to the NFTokenMint transaction with respect to the URI field. I think preserving that symmetry is the right call.

My suggestion would be to modify the spec to say the URI field is optional, and if the URI field is omitted, then the corresponding URI record in the ledger, if present, is removed.

Good catch Scott! Will edit accordingly

[tequdev]

Account field mentioned in Section 3.2 is already used as a common field in transactions, so I propose to change it to the Owner field instead. (The implementation already uses it as Owner field).

[xVet]

Thank you everyone who contributed to the discussion so far!

I'll close this discussion by the end of this week, given its a already a well discussed Standard.

[xVet]

Closing the discussion here!

The XLS PR can be found here: #205

Code PR can be found here: XRPLF/rippled#5048