0020 XLS-20d Non-Fungible Token Support (native)

[nbougalis]

An updated version of this spec can be found here: XLS-20: Non-Fungible Token Support.

The earlier version can be found by looking at the edit history.

[calvincs]

Digesting this, but from my initial read, looks pretty awesome!
Will think about this and return :-)

[mDuo13]

Should we allocate a draft number? Looks like 0020 XLS-20d is the next one available.

[WietseWind]

Good one. Done :)

[scottschurr]

I suspect we need to clarify rules for the AccountRoot MintAccount field.

1. Who pays the reserve on NFTokenPage objects minted by a MintAccount? I presume it must be the MintAccount, but I'm not clear from reading the spec.

2. Is it possible to create orphan NFTokenPages with the following steps?

   a. Alice sets Bob as the MintAccount field in her AccountRoot,
   b. Bob mints NFTokens on behalf of Alice, then
   c. Bob finishes minting, so Alice deletes or changes her MintAccount field.

In general the details on the MintAccount field feel a bit blurry to me.

[HaiderShahid]

you are 100% correct. Any chance you were able to integrate it? I am actually a novice coder. I am using NFT tester as my point of reference but unfortunately it doesn't have the details of AccountRoot and MintAccount. Do you have any code example you could share or any reference, really would help. Thanks.

[scottschurr]

The details for the AccountRoot changes don't appear to be available on the documentation site yet. So here's an example of an AccountSet transaction that sets the Minter field of an account root:

{
   "Account" : "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
   "Fee" : "10",
   "Minter" : "raMjuzZYRZ4yza9DAd5Szt9tz9ZDzD4QzP",
   "Sequence" : 75,
   "SetFlag" : 10,
   "TransactionType" : "AccountSet",
}

Note two important features:

• "SetFlag" : 10 indicates that you want to set the account's Minter field.
• "Minter" : "raMjuzZYRZ4yza9DAd5Szt9tz9ZDzD4QzP" specifies who that Minter is.

Once the Minter field is set, here's an example where the Minter mints an NFToken on behalf of the Issuer:

{
   "Account" : "raMjuzZYRZ4yza9DAd5Szt9tz9ZDzD4QzP",
   "Fee" : "10",
   "Issuer" : "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
   "Sequence" : 5,
   "TokenTaxon" : 0,
   "TransactionType" : "NFTokenMint",
}

Note the "Issuer" field which matches the AccountID of the account that set the "Minter" field. The "Issuer" is the AccountID that is embedded in the produced NFT. Once minted, the minted NFT itself is in the possession of the Minter, not the Issuer. So the Minter must take responsibility for any necessary owner reserves.

I hope that helps.

[scottschurr]

Regarding the question of the identifier of an NFTokenOffer when a ticket is used for the transaction, the answer is easy.

Use the TicketSequence associated with the ticket. The 32-bit integer TicketSequence value never overlaps with a valid Sequence value on the same account. So it is safe to use the TicketSequence. In fact, that's exactly how the identifier for a standard Offer is created using a ticket today.

[carlhua]

Interesting NFT spec:

1. Can we get more clarity on how the transfer fee would work? It indicates this is the fee charged on the secondary sales - what is a secondary sale? If I just send it to someone, do they get charged? If so, please consider removing such a feature.
2. I do not see a need for delegation as the authenticity of the NFT can be traced through token metadata if needed - for example, tracing it back to a domain would be sufficient IMO
3. I am skeptical about the brokered mode use case, this seems to be very contrived - if everything can be openly monitored by the network, why do we need a broker? Maybe I am missing something here.

One general comment - as we scale we should consider allowing for off-chain message signing for use on-chain. This means we will be able to do offchain orderbooks and onchcian execution to reduce offercreate noises.

[carlhua]

I see. I think being able to do native transfer like IOU is an important feature we should consider.

[HubertG97]

I second this, there could be a lot of new use-cases for NFTs which might want to arrange payment off-ledger or just want to pass ownership of a certain NFT to someone they know. Transfering NFTs like an IOU should be a feature you want to provide to the users.

[nbougalis]

The problem with a transfer is that there are no trustlines for this so there's no way for a recipient to indicate that they wish to hold an NFT.

The seller offering it to the recipient for 0 cost seems to achieve the same thing: if the recipients wants the token, he claims it for free; otherwise he cancels the offer and all is well.

[HubertG97]

Okay, understood! That was what I was looking for.

[carlhua]

This makes sense Nik, though my hesitation is still that this is a rather non-conventional way of doing things and might hurt the adoption rate. Perhaps we can abstract this away from the end user.

[RetirePerspired]

It feels like this standard is very close to enabling an on-ledger software licensing model. @WietseWind have you considered what issuing a XUMM Pro license via NFT would look like? I don't think that you could pull off a subscription based licensing model with this standard, but the ability to profit off of every secondary market transaction seems very appealing.

[HubertG97]

This is really interesting! I like the idea of the native support of NFTs on the XRPL.
About the Metadata, wouldn't it be an advantage if the metadata has an option to be living on the XRPL like explained in my proposal using a CTI from a transaction using the memo's field. In this particular example, the metadata is immutable.
You could make it mutable If an extra field would be added to NFToken called CTI that could be updated when the metadata has to change. This way the metadata will always be on the XRPL and not reliant on some individual hosting it.

[calvincs]

I still like the idea where mutable data can be stored in the Domain Field (if required): #44

With the additional fields given in this proposal (URI), the fields given could be reduced in the Domain field.
As an example, the URI field can be used to store the IPFS content address, while the Domain field can be used to link to other services/data/api's etc.

I do have questions on the URI Blob field size, would this also be 256 Bytes?
Is the URI field mutable (could that be made optional?) I can see a use case where the URI is set immutable, and the Domain field mutable. Giving owners the ability to set meta like ILP addresses, use IPNS, etc.

It my opinion we should stay away from relying on data put in memo fields, as this will require the use of full history nodes.

[nbougalis]

Actually, I really like the idea of using the CTI. I'll look back and see how we can leverage that.

[calvincs]

I too like the idea of the CTI, just not storing it in a memo field :-)

[RichardAH]

CTI could be trivially referenced via the URI field (e.g. xrpl://cti/67835576823535218) without sacrificing flexibility or giving it special treatment

[RetirePerspired]

In the interest of (a) minimizing the footprint of an NFT but without sacrificing utility or functionality; and (b)
imposing as few restrictions as possible, this specification does not allow an NFT to hold arbitrary data fields. Instead, such data, whether structured or unstructured, is maintained separately and referenced by the NFT. This proposal recommends using one of the following two approaches to provide external references to obtain NFToken data and/or metadata.

Really wrestling with this part. I don't have any experience with the IPFS, so that's probably slowing me down. I can envision a NFT's that are "minimally invasive" that the ledger should be able to accommodate directly on chain. I don't know what that limit is (128 characters?) but I can easily see something like ownership of virtual land being nothing more than a hash and some coordinates. Seems a shame to necessitate a pointer off-ledger for something so simple.

[calvincs]

If the URI field is the same size as the Domain field (which would make sense), you should get ~256 ASCII chars.
That is more then enough for a hash and some coordinates, or whatever data you likely want to reference.
You could even use some some format like: #44
IPFS / Torrents / Domain (external pointers) just allow for larger data/content to be attached.

Some info on what IPFS is: https://docs.ipfs.io/concepts/what-is-ipfs/#content-addressing

[nbougalis]

Think of the URI as a more general version of a URL. It can be used in many different ways.

Your example could be well-served by a URI that uses the data scheme, allowing for the simple inclusion of "small" amounts of data.

[yyolk]

IPFS hasn't necessarily proven itself and has already burned artists and buyers. IMO imgur or archive.org (both free, forever) would be better recommendations for newcomers who don't wish to burn potential buyers while navigating this new space, where buyers have found their works have been lost because the artist's closest node didn't propagate it.

Most aren't aware you may not win the popularity contest and never reach propagation beyond your closest node.
Even if it's pinned.

I'd point this out in the docs, but I'm unable to view them because I block certain IPs coming from certain countries on my lab network, and their docs are apparently coming from that range.

[enricohomann]

The paper sounds plausible in itself, but I think the part with the external references still needs to be clarified. Offchain data storage in particular has some pitfalls in the context of data management, such as trustworthiness, rights management, data integrity and data security. A simple link is usually not enough. You should therefore pay particular attention to the secure connection to external data services.

IPFS sounds promising at first, especially for NFTs (Hash of Content eq. Address), but I am currently not clear about how IPFS itself regulates data access restrictions. I think it is unfavorable if all data content is publicly available one way or another. But in the end this is also part of the NFT's rights policy and order of responsiblity.

[calvincs]

What is the primary concern here, keeping data out of the hands of others. Like behind a paywall or inaccessible by others (its encrypted?).

With IPFS, you can run gateways that only server CIDs you desire to host. You can easily build in checks to validate who is requesting what resources from you. This assumes you are running a private IPFS network of course.

You could encrypt the data, however, once you start passing that NFT around, and give them the key, now all of you have access to that data. Once the cat is out of the bag, its out, IMHO.

This is an idea that I am currently exploring as well, so very open to hearing others opinions.

[enricohomann]

IPFS is also new territory for me.

As I understand the gateway concept under
https://docs.ipfs.io/concepts/ipfs-gateway a distinction is made between private and public gateways.

How one can apply ACL or the like to a single object is not yet fully apparent to me. As I have understood, the security concept of IPFS relies on trust in the gateway through corresponding certificates on the entire gateway.

If you just want to prove NFT ownership via XRPL and the referenced data can be viewed by everyone, then a public gateway is certainly sufficient. However, it does not prevent external data from being accessed by other applications or "pirated copies" via other channels. (Although this cross-ledger NFT validation also represents a new business opportunity .. So many ideas ...)

It gets a little more complicated if you want to assign specific access rights more precisely because the data is externalized. This could then perhaps be done via private IPFS gateways, which then add a DRM-like concept on top of the pure data storage. This would also be conceivable in conjunction with XRPL hooks. But I would first have to play through the whole thing as a prototype in my spare time in order to fully understand it.

It remains exciting.

[yyolk]

@enricohomann i would love to expand on your ideas a bit, because you're touching on points i definitely agree with

IPFS has no acl - an object once uploaded can not be deleted. this is problematic is most cases, and it doesn't implicitly mean permanence. If an object doesn't win the popularity contest it doesn't get to exist anymore, if it's not picked up by a node other than your closest node, it will no longer exist.

An NFT mint is permanent, the underlying uri should be just as permanent. I'd recommend someone uploading an image to archive.org which has a mandate already to store our most precious assets. Unfortunately it's slow, and works on a budget that should last for decades. Object storage is cheap, and has arguably better incentives in the competitive sphere of cloud storage; already housing most of the objects on the internet.

GitHub, Imgur also provide, and have mandated permanence beyond what IPFS has shown thus far. I've been thinking about this a lot, and there's far better ways to deliver content in an (optionally) immutable way, where the underlying asset, the digital Art, is precious.

You can add in ACL yourself, regardless of host - if you're pushing a static file

In regards to your idea about proving access to an object, one might think about how asymmetric key encryption works, where you have a private and public key pair. If you wanted to think about encrypting an image like a private message, you'd want to scramble the image against the key.

The simplest way i can think of is sequentially XOR'ing all the bytes against some equally long length of random bytes. A more efficient method would use a small fraction of the overall image byte length and use it over and over.

If you store this key in some way, where you can then prove you are logging in with your wallet (signing a txn on xrpl). You show you own what you own to the "picture frame", which then vends the scrambled image (embedded in the NFT, the URI embedded in the NFT) with the known private key, doing a XOR of the bytes again, which will undo the scrambling. Note: There are better methods to do this!

The service can itself not know anything about the image or the NFT, but there would be only one key if the image / asset itself is immutable. If the asset is like how buckets work today, where you must authenticate to retrieve it, or in a simpler sense; with basic http auth; where you'd get a <200: Content-Type: image/png> if you're authorized

Another way to prove an original would be with steganography, where you may hide some piece of arbitrary data in the header of an image, that can then later proven as an original if the image itself is re-rendered, resized, lossless, or not where this particular data wouldn't carry over, unless it was 1:1 bytes.

[dangell7]

If social media platforms checked an exif field on the asset containing the wallet signature, any asset uploaded could be rejected if the user uploading the asset didn't have access to the wallet that owned the asset.

This is what I believe will happen over the next 3 to 5 years. You should NOT be able to upload assets that you can't prove ownership of..

Just my thoughts.

[mDuo13]

You should NOT be able to upload assets that you can't prove ownership of..

That's a fascinating concept, but given how many of our current social media networks built their current position on the basis of the exact opposite, I can't see it catching on. But also, how would brand-new assets be marked? Are you going to configure your digital camera with signing keys? Your scanner? Not to mention every piece of software out there that people use to make digital art. And if it's just an EXIF field, it seems like it would be trivial to remove the field and replace with one that has a different signature.

Not to mention the complicating and chilling effects that any such restriction could have on the creation of legally-allowed derivative works, licensing agreements including time-limited licenses, and so on.

Certainly, there are way too many difficult challenges (social and legal ones, which are not so quickly resolved as technical ones) for a restriction like that to be put in place in 5 years.

[BooneTB]

Excited to see the possibilities of NFTs on XRPL. I am working on CO2 Bonds/Conservation NFTs and would love to learn if something like this https://github.com/BooneTB/CO2StakingBonsai/blob/main/CarbonBOND
Would be possible to implement with this update to XRPL?

[nbougalis]

Sorry I haven't been able to review your GitHub link. I'll try to take a read this weekend and follow up.

[dangell7]

I've got an Social Media prototype using ethereum hybrid 721's....

Every asset uploaded is a "721" contract but can also hold a token balance. I call my tokens SAMY.

Every view on the asset reduces the token balance by one, paid to the "viewer"

Every comment/like, adds a token to the balance, paid by the "commenter/liker".

A simple basic decentralized way to measure engagement and reward users.

I stripped the ETH protocol today and I'm going to try to add the XRP protocol features for NFT.

I did have one question. Smart Contracts on ethereum can hold value, I view this feature in XRPL as just the wallet that holds the value. Sure, the functionality of the code doesn't reside inside the wallet on XRPL, but by using multi sign, I can basically create the same idea and did this using a swift class if anyone is interested.

Is there a better way to achieve this? I know you just released hooks but to be honest I've been head down in my ethereum private blockchains. I like XRP more tho.

Would love to discuss.

[nbougalis]

Hooks has not been released; there is a test network operated by the amazing team at XRPL Labs, but I believe that they are still actively developing the Hooks feature. I don't want to speak for them, but I suspect they'd characterize it as an alpha release.

Beyond that, I'm not quite sure what you're asking. If you want to lock up value, you can look at Escrow, which includes support for preimage cryptoconditions. If I'm understanding your question, it may be a good analog.

[dangell7]

I'll checkout hooks. I think that solves my problem. Also, are these just specs for later development or can I actually start testing these features in the testate?

[FlareCraft]

I think there's a devnet that you can use for hooks. I found these links. https://hooks-testnet.xrpl-labs.com/ https://github.com/XRPL-Labs/xrpld-hooks/blob/hooks-ssvm/README.md

XLS-20 (this page) isn't in devnet yet, but my guess it that some version of it will be very soon.

[dangell7]

Looking forward to it. Hooks + NFT is going to bring some really cool features.

[drsm79]

Would it be possible for a TransferFee to go to two places? Thinking of something like an art gallery that mints works for artists, and them both being paid on secondary sales? There's kind of two roles in that scenario - the minter and the creator - and it would be nice if that could be reflected somehow.

[nbougalis]

Great question. That would be a neat feature but it's a little tricky to implement directly; the challenge is that we want to keep the size of an individual NFT object minimal. Implementing this suggestion would increase the complexity and the size of the object.

Despite that, I think that what you're describing is useful and I wonder if it could be a good use case for the Hooks amendment that @RichardAH is working on.

[VexyCats]

When minting an NFT it looks like there are 2 routes that can be taken from a 3rd parties perspective.

The MintAccount field, if set, specifies an alternate account which is allowed to execute the
NFTokenMint and NFTokenBurn operations on behalf of the account.

The SetAccount transaction should be augmented to allow the field to be set or cleared.

Example: Website A wants to offer the ability for users to create NFTs.
User B goes to the website to mint an NFT.

Website A must either:

1. Set the issuer as User B when minting
2. Include an extra transaction for User B to submit, adding them to the MintAccount field

Is this correct?

What are the downsides for setting User B, User C, User D, as issuers when they mint their own NFTs and not setting Website A as the issuer?

[nbougalis]

So, it depends. If website A wants to allow the minting under its own account, the no; it doesn't need to do anything special. If it wants to allow user A to mint with their own account then either user A must set their MintAccount field to the account of website A, or website A must generate the transaction under account A and provide some interface that allows user A to sign that transaction. That's could be a neat use case for Xumm.

[aqrl]

Great proposal! I think this is a solid step towards supporting NFTs on XRPL.

I have a question about NFTokenPage objects.

These objects are updated automatically with NFTokenMint and NFTokenBurn transactions. Additionally it seems there will be an ability to update/change an NFTokenPage object outside of a mint or a burn transaction. Is this correct?

If so, what possible use cases could there be for having the ability to change this object outside of a mint or burn transaction?

[nbougalis]

These pages hold collections of NFTs. Because we need the ability to transfer NFTs from one user to another, the transaction makes that possible must be able to:

1. remove the NFT from the NFTokenPage of the person transferring the NFT; and
2. add the NFT to the corrcet NFTokenPage of the person to which the NFT is being transferred to.

[aqrl]

Ah I see. That makes sense.

Are these transfer operations quantified? For e.g. an NFTokenSend? If they were, then the NFTokenPage changes could be encapsulated in these operations and an arbitrary change operation would not be required.

[nbougalis]

I've been thinking a little more about this proposal and would like to suggest a change that should make NFT objects even more lightweight.

Currently, an NFT contains both a 20-byte issuer and a 32-byte hash, for a total of 55 bytes.

The 32-byte hash is meant to distinguish this NFT from any other, but in reality it only adds trouble. For example, an issuer could "double-issue" a token, and there's no way for the ledger to detect this, much less prevent it. Maybe that's fine, of course; maybe issuers shouldn't shoot themselves in the foot, but the spec is meant to allow for "non-fungible" tokens and yet it allows for the creation of binary-identical objects. What does it mean when have two "non-fungible" tokens that are identical and cannot be distinguished?

What if we were to add an additional field: a "serial number" of sorts. But what to set it to? Well, the transaction's sequence number seems reasonable. It's never reused, so it works. It means that even if the issuer reuses the hash, the two resulting NFTs are distinct.

This causes trouble with the mint account, but we can solve this by adding a new optional field to the account root: a 64-bit number TokenSerial which gets incremented with every token issued by this account (whether directly or via the mint).

But if we're going to do that, why even have a 256-bit identifier? Why not just treat the pair {Issuer,TokenSerial} as the unique token identifier? And as a bonus, that saves us 24 bytes too!

And this also enables something else that's really neat: we can create semi-fungible tokens. We can simply add an optional 32-bit field to an NFT, let's call it TokenType. The issuer can set this to any value they seek.

So, now we can use {Issuer, TokenType, TokenSerial} as the NFT's identifier.

Let's say the issuer wants to issue an NFT to represent a limited edition album. They can assign that album a unique 32-bit number, and issue any number of tokens which are all "linked":

{rIssuer / 666 / 443556}
{rIssuer / 666 / 443557}
{rIssuer / 666 / 443558}

[WietseWind]

I like this. Lightweight is good. I think we should use existing standards and build upon them, not adding new standards & not by storing a lot of data on ledger.

These NFT's are probably going to live on the ledger forever. All kinds of meta data stored in e.g. URI Blob fields aren't supposed to live on the ledger imo.

I would propose to even scratch the URI field, and simply use:

• The domain field
• The token code
• The .toml standard, a good example is the one by Gatehub: curl https://validator.gatehub.net/.well-known/xrp-ledger.toml - All issuing accounts and issued tokens are listed there. Adding more fields for more metadata + possibly a location to show user friendly NFT info (using IPFS, HTTPS, etc. doesn't even matter here) to this (toml) standard if needed.

[calvincs]

I agree with this, less is more :-) I am concerned that using HTTP domains create a possible issue, like said person looses the domain. Creates a *possible centralized point of failure.

Proposed solution: IPNS/Domain
Example:ipnsAddress.com
( k2k4r8jzuhjc31n1f37iyhj4ka4nggz8pace0ho5korctclj7aqt8jxu.com )

Owner creates an IPNS key pair, gets address and then registers a domain w/ the same name. Both the IPNS location and domain can be updated, aka keep the toml file updated with the latest information.

If the user looses control over either one, they have a fall back they can use. The IPNS key can be generated in such a way as to be easily stored away in case it needs to be recovered.

There are downsides to this of course.

[Mwni]

Agree with Wietse, the URI fields invites issuers to bad practice, and you could imagine the XRPL being cluttered with alot of dead-link NFTs in the future. Dropping it would

• Save memory
• Simplify the implementation
• Simplify issuing & displaying
• Prevent irrecoverable deadlinks

[ledhed2222]

Unfortunately that is not possible given the directory structure of NFTs. That structure was chosen for performance, and to reduce reserve requirements for end-users. This is just an example of dev tradeoffs, but Clio is able to fill in the gap.

…

On Wed, Apr 20, 2022 at 4:19 PM Julian Gums ***@***.***> wrote: Clio seems like a great tool but arguably looking up who a given NFT belongs to seems to be something that is so common that it would be great if it was natively supported. — Reply to this email directly, view it on GitHub <#46 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXUFDOSR5MBJD6BHDANFSLVGBRERANCNFSM45N47IJA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bashash]

Owner test with regards to accepting buy offers.

The following describes a simple flow to demonstrate the somewhat counterintuitive role of the Owner field with regards to the creation of NFToken Buy Offers on the XRPL. This counterintuitive behaviour can be attributed to the premise that the requirement of an Owner field in the NFTokenCreateOffer transaction ensures that such an offer may only be accepted by the address specified in the owner field. The flow described below, however, reveals that this is not the case:

Account 1 creates offer for 100 XRP with owner Account 3
"50A7839F5C3AB0AC5568EE3F4D075CAF21FF738C9FE4162673A98FC74D9080A7"

Account 2 creates offer for 100XRP with owner Account 3
"2B7C3F585F3C2F4D04E0F7B36E75AA9004C5FE03590C62E6DB877C8C4F30A87C"

Account 3 accepts Account 2’s offer
"1638B62DEFF957A5C029B9977D5C8763D251B49B6823EF86F6EC156F6B71936B"

Account 2 accepts Account 1’s offer
"90069636D3847EEF8F4FE3AE418F6007679A4EBC5EE7DE11C5342BD08404BEF9"

Following from the above described premise, Account 2 should not have been able to accept Account 1’s offer on the principle that Account 1’s offer was made with the Owner field specified as the address of Account 3. The conclusion, thus, is that the Owner field is significant only when a buy offer is being created. Assigning the Owner field with an address that is not the current owner of the NFT prevents that offer from being successfully made, but does not appear to have any further behaviours or interactions. That is to say, the Owner field does not prevent buy offers from being accepted by a ‘new’ owner whose address is different from the ‘original’ owner address which was used to create that buy offer.

[scottschurr]

@bashash, thanks for reporting this concern. I've reproduced the scenario you've described. Yes, it's confusing, but it is the way things currently work.

The Owner field of an NFTokenCreateOffer buy transaction is used by the ledger to locate the NFToken in the ledger when the in-ledger NFTokenOffer object is created. Once the NFToken is located, the Owner information is no longer needed, so the value of the field is not preserved in the in-ledger NFTokenOffer. Since the information is not preserved in-ledger, there is no way to enforce any rules regarding the current owner if the NFT is transferred after the buy offer is created.

I'm not particularly concerned about the issue you raise because, under most situations, the value of an NFT that you own should be a reflection of the NFT itself, not who you bought it from. In all cases the buyer spent the amount of money that they committed to in their offer.

In summary, what you are seeing is expected behavior, even if it is not intuitive. I hope that helps.

[Andrewkasko]

@scottschurr When transferring an NFT would all the past orders for that token id owned by XYZ be "destroyed" or is it up to the user client or rpc indexing to handle this?

[scottschurr]

@Andrewkasko, when an NFTokenAcceptOffer transaction completes successfully, only the (one or two) offers that were directly involved in the transfer are removed from the ledger. Any other offers for that token remain in the ledger.

The former owner of the transferred NFToken will probably want to cancel any remaining sell offers they may have in the ledger. Since they no longer own the NFToken such an offer can never be successfully accepted. I'm ignoring the weird case where the former owner buys the NFToken back.

However any buy offers in the ledger for that NFToken remain valid. They are still buy offers for the same NFToken, even though the owner of that NFToken has changed. So accounts with buy offers for that NFToken may not wish to cancel their offers. Their choice.

[Cadey]

Hi guys, I have written up a new proposal to expand on the XLS-20d proposal for NFTs. The change would help owners manage the NFT's they have in there wallets and also mitigate some potential bad user experience and negative feedback on how NFT's work in XRPL.

It would be good if you take a look, comment and hopefully up-vote my proposal.

#75

[Silkjaer]

Suggested edits to align the standard with the implementation, prior to moving XLS-20d from draft to final:

1.2.1.1.1.4 Example

• Should change from Flags: 12 to Flags: 11

Example TokenPage JSON

• The example should be updated to reflect the current structure, e.g. rename Tokens to NFTokens and make it an Array. Example:


"NFTokens": [{
	"NFToken": {
		"NFTokenID": "000100001E0A8858DD68F269821325252F4303340C9C3A11BD944ED000000035",
		"URI": "6576726C656173650001757A0237B44D8B2BBB04AE2BAD58138554871AFD498D0000"
	}
	/* potentially more objects */
} 


The NFTokenMint transaction

• A required parameter to this transaction is the Token field specifying the actual token. should be removed.
• TokenFlags should be NFTokenFlags

Example NFTokenMint transaction

• The example lacks a NFTokenTaxon field

The NFTokenBurn transaction

• Misses an Owner field definition

1.3. Account Root modifications

• Stylistic only: Heading level should be increased

1.3.3 BurnedNFTokens

• Stylistic only: Heading level should be decreased

1.4.1.1. NFTokenOfferID Format

• lsfSellToken should be lsfSellNFToken

1.5.4.1. Fields

• tfSellToken should be tfSellNFToken

[mDuo13]

Should also update to remove the tfTrustLine definition

[Silkjaer]

I wonder if that should be left in the standard and documentation, but be updated with a deprecation notice, as it's basically fixed in a fix amendment?

[mahiros-tech]

I minted NFTs on behalf of other account. I used Account A and minted for Account B.
To do this, on Account B set NFTokenMinter as Account A, and successfully minted.
But minted NFTs are owned to Account A, not to Account B.
Is there a way to send them all to Account B?
I think if Account A mints NFTs for Account B, NFTs should be owned to Account B including issuer address changing on TokenID.

[ihomp]

Is there a way to send them all to Account B?
You can create sell offers with price 0 and destination Account B and then accept sell offers from account B.

[mahiros-tech]

If I create sell offers with price 0, they will go to another account, not account B.
If I were an owner of Account C, I will get them all before they go to Account B.

[ledhed2222]

@mahiros-tech - no, this is the purpose of the destination field as @ihomp notes. If you set the destination to B then only B can accept them.

More generally though, what is the purpose of this flow? If you want B to own them then why don't you just mint them from B in the first place?

[mahiros-tech]

Minting from B is possible, but when minting bulk nfts, it's terrible to mint one by one from the client or user side.

[mahiros-tech]

Hello
I minted a NFT and made a sell offer to another address with price 0, just for transferring, this one.
https://xls20.bithomp.com/explorer/000D0000B9BD7D214128A91ECECE5FCFF9BDB0D043567C512CC835D70000013B
I accepted the sell offer with XUMM app and it does not success.
But the owner is changed without any informs and I can not accept the sell offer anymore since its owner is changed.
I think the sell offer should be removed once it affected the ledger?
Means 2 opposite transactions or ???
Please explain me about this.
Thanks.

[HadaNFT]

I've come across an issue. It is very easy to create buy offers from unfunded accounts. Here is one I have done for 250M XRP. Obviously I don't have that, even in devnet.

https://xls20.bithomp.com/explorer/18B9E787507DD6EA61874BD1E8EA6C61E41825B343542F3FCE97C1666CD899F0

These buys orders generate a tech unfunded error on the sell side.

[tequdev]

You can create a similar situation by creating a purchase offer for 10,000 XRP while holding 10,000 XRP and then sending 10,000 XRP to another address.

We have to check in our auction system if the bidder has enough balance for the winning bid amount.

Alternatively, the NFTokenCancelOffer transaction could be used to cancel the offer if the account balance is less than the purchase offer amount.

[juliangums]

I'm not sure how the NFTokenPage concept works on an atomic level but I noticed that they never get completely filled with NFTs. Initially, I thought they always fill up to 32 but I'm seeing token pages with 17-29 NFTs in them when I mint. If I mint the same things twice, I get the same amount of pages so it does not seem random but there seems to be a deterministic algorithm for it. But how? How can I work out if I am going to mint x amount of NFTs, how much reserve I will need? Or does this depend on the exact NFTokenIDs as it seems like this is some kind of indexing issue and an NFTokenID can either fit into a page or it can't, based on how high/low it is and a new one needs to be created? Anyone that can explain?

[BooneTB]

Good questions, thanks for asking. Looking forward to someone's insights!

[scottschurr]

@juliangums, FWIW, NFToken pages do get filled to 32, but on average they will tend to contain about 23 to 24 NFTokens per page on average. This is observed experimentally and there is some intuition for how this ends up being the case. Following are some details for the curious.

The implementation is struggling with four different things that need to be optimized:

1. We want to minimize the number of pages required to store NFTokens,
2. We want to minimize compute power required to add or remove an NFToken from an NFTokenPage.
3. We want to minimize on-ledger churn when NFTokenPages are added or removed.
4. There are certain rare NFTokens that must all reside on the same NFTokenPage. Those NFTokens must stay together.

The implementation does this by following a few simple rules:

1. When the 33rd NFToken needs to be added to an NFToken page, that page must split. The page is inclined to split into two 16-NFToken pages. Once the split is done, then the new NFToken is added to the appropriate page. The page is split evenly because we don't know if the next several NFTokens will need to be added to the upper or lower page. If the split is even then we're as well prepared as we can be for either case.

2. There are rare situations where certain NFTokens must always reside on the same page. Because of this, sometimes when a page is split, the split is not even. This is so the NFTokens that must stay together actually do stay together.

3. When an NFToken is removed from a page the implementation attempts to combine that page with the next higher and the next lower page. Whether that can be done is determined by whether the combined page would contain 32 NFTokens or fewer. If any of those pages can be combined, then the combination is done. The algorithm stops once those three pages have been looked at. There are no "domino" effects.

So the very first page will always fill to 32 NFTokens. Then there will be two pages with 16 and 17 each. From there it depends on which page each newly added token is added to. Once any page exceeds 32 it will split into two pages of 16 and 17 each.

Given an account that owns more than 16 NFTokens, it should be a fairly unusual circumstance where one NFTokenPage contains fewer than 16 NFTokens.

I hope that helps, even though it does not give you a predictable algorithm to follow.

[WietseWind]

Thanks @scottschurr - gives us some understanding of what we're seeing, but it's very, very hard to explain this to end users. Who do want to know why their reserve changed. Being as unpredictable as it is right now, this is resulting in quite a lot confusion. I don't have the answer yet, but I do feel more predictable behaviour would be very welcome, as it would allow clients to inform users what will happen to their reserve before support tickets are being sent about 2 XRP being 'stolen', etc.

[scottschurr]

Hi @WietseWind. I sympathize with your position. I feel motivated to point out that even though I described the current implementation, it is not my design. I've simply spent enough time working with the current design (occasionally being surprised by it) that I can describe the design fairly succinctly.

It seems likely, although I haven't tested this, that if we tell people to expect to pay one owner reserve for every 16 NFTokens, then they may be pleasantly surprised that their actual owner reserve is somewhat less. I think that guidance should usually keep people from running up against reserve limits. That should probably be tested before actually offering it as guidance. I may be missing a corner case or two.

Beyond a heuristic like the one above, re-designing how NFTokens are packed into pages so the result is more predictable would take some serious work. I don't have immediate suggestions for how to approach that.

[ledhed2222]

In my communication with marketplace start-ups (not the same kind of user), I also use Scott's heuristic. IE as long as the user knows that we're talking about averages here, we can say that roughly every 24th NFT increases your reserve.

[tadejgolobic]

I know that this is already active/enabled on mainnet, but just for the sake of having this documentation correct, I propose following changes to original post:

1.2.1.1.1.4 Example

For example, the NFTokenID 000B013A95F14B0E44F78A264E41713C64B5F89242540EE2BC8B858E00000D65 would uniquely identify the token with Taxon 146,999,694 and Sequence 3,429, issued by rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2. The TransferFee is 3.14% and the Flags associated with the token are: lsfBurnable, lsfOnlyXRP and lsfTransferable:

That is actually not true.
000B013A95F14B0E44F78A264E41713C64B5F89242540EE2BC8B858E00000D65
Flags: Burnable, Transferable, onlyXRP
TransferFee: 314
Issuer: rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2
Taxon: 146999694
Sequence: 3429

So actually the transfer fee is wrong.
This tokenId would actually represent the value that you wrote: 000B0C4495F14B0E44F78A264E41713C64B5F89242540EE2BC8B858E00000D65.

Also, in the same section, you are showing how tokenId is calculated. With flags as first for characters etc.
You wrote this:

000B 0C44 95F14B0E44F78A264E41713C64B5F89242540EE2 BC8B858E 00000D65
+--- +--- +--------------------------------------- +------- +-------
|    |    |                                        |        |
|    |    |                                        |        `---> Sequence: 3,429
|    |    |                                        |
|    |    |                                        `---> Taxon: 146,999,694
|    |    |
|    |    `---> Issuer: rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2
|    |
|    `---> TransferFee: 314.0 bps or 3.140%
|
`---> **Flags: 12 -> lsfBurnable, lsfOnlyXRP and lsfTransferable**

000B => Flags: 11, not 12.

We cannot have flags with value of 12.

[JoeyKhd]

+1 on this

[intelliot]

Note for future readers: This spec has been implemented and adopted, and is being updated and approved here: #95