0029 XLS-29d: Mark an NFT (xls20d) as for sale to reduce spam/excessive traffic

[Cadey]

As per the XLS20d proposal users can make offers to buy and sell NFT tokens, this request focuses changing the way NFTokenCreateOffer works to take into account sellers preferences before the 'NFTokenOffer' is created.

The problem

As it stands there is no way to mark an NFT as "for sale" or to limit what currency types I seller would wish to accept, with out this being present any user can open a buy request for any NftToken, the owner of which would potentially be inundated with offers to buy an NftToken they have no intent to sell, or sell for the requested currency.

There is little to stop malicious actors spamming offers for NftTokens (Short of the 2xrp holding fee), all of which the owner would need to manage or at the very least filter out.

Owners of NftTokens could also be easily duped into selling there NftToken if they do no notice what currency the offer is in, since there is little control over the name of tokens created we might well see tokens like "xxrp" or "xrrp" being created in the hope 'NftToken' holders don't notice and agree the sale.

A solution

My proposal is the extent the XLS20d feature to include a two new fields to the NftToken object which only the current owner can update, and is cleared when the NftToken changes owners. With this change the owner of an NftToken explicitly opts into wanting to receive offers for the NftTokens they have in there wallet.

Field Name	Required?	JSON Type	Internal Type
IsForSale	Yes	Bool	Bool
AcceptableOffers	No	Array[AMOUNT] or string	Array[AMOUNT] or string

The AcceptableOffers array

The AcceptableOffers array will represent the currencies the owner is willing to accept. When set, any offers made in a currency not in the list, or for a valid currency but has an amount lower than the amount stated will automatically fail the NFTokenCreateOffer call and no 'NFTokenOffer' will be created.

If the value for AcceptableOffers is set as a decimal (or string number) the owner is signaling that they only accept XRP and for at least the amount stated.

If the value is null or an empty array that signals the owner is open to offers of any amount and currency.

[ledhed2222]

This is an interesting idea! I'm not sure that it's actually a problem for sellers if they receive spam offers, but perhaps there is an issue for both sellers and buyers where the latter doesn't know what currency to make offers in, but that seems like it could be (at least initially) managed by a platform.

[Cadey]

Thanks for taking the time to read it over, all feedback is valid 👍

There are two issues which this proposal is trying to mitigate against, firstly the network traffic and secondly the user experience. Let me explain them both here and see if this changes your opinion on if they are a problem or not :)

The network issue
Since all NFT's are discoverable by both people and bots (code which talks directly the XRPL) and there is no way at a protocol level to automatically reject an offer to buy an NFT this information always needs to the processed by the ledger. We know from experience how the ledgers performance can drop when activity is high.

The user experience
Imagen all of your personal possessions where visible on ebay and you could not hide them from users. The amount of unwarranted offers you would receive for things you have no intention of selling would cause you to stop using the service all together. This will unfortunately be true when XLS-20 goes live, all be it limited to the NFTs you hold :)

Now with regards to marketplaces carrying the burden of "hiding" their unwanted requests from the user. This is possible but, in my opinion, it will lead to a very inconsistent experience for the users and offers nothing in reducing network traffic, If the marketplaces are to manage this problem (say the user tells the marketplace which NFs they want alerts for etc) that's still a lot of traffic generated which is essentially useless. Since the marketplace will have to pull all the offers in any case, to then dispose of them.

Can Xrpl monitors / Trackers help us here???
I know there are some projects out there which are tracking changes on the XRPL and attempting to create a state machine or sorts, having a "current" view of the ledger which we can query. As good as these projects are in some circumstances they will never be trusted enough (again in my opinion) to offer a truly accurate representation of what the current state is, since they only need to miss a few changes and all the data is inaccurate. Also keep in mind, to have a "current state" of the XRPL you would have to start from the first block and catch up with the ledger, possible but not cheap :)