Remove friction in minting - Automate transfers, sell offers/acceptance and reduce reserves by not holding 1000's of NFTs and offers.

[martypaz]

Pain points

There a several pain points for users accepting mints from a marketplace. The goal here is to remove friction, improve speed of NFT delivery to the user’s wallet and reduce reserves.

As a user using our marketplace, you are able to win random NFTs from a collection using the spinner tool. We have many users who buy a lot of spins which results in a lot of time and effort – Prior to our bulk acceptance tool, accepting let’s say 20 NFT’s could take about 20 minutes.

From the xMart perspective, once an NFT has been allocated to a wallet, it’s then minted and the NFTokenID recorded. A 0 XRP sell offer is created for the user to accept. The user then goes to the offers and approvals page, ticks the items they want to accept. They then need to manually approve these in Xumm INDIVIDUALLY. This is not the fault of Xumm as multiple approvals could impact consumer protection.

Improve NFTokenMinter options via automated transfers

My proposal is to improve the options available for the NFTokenMinter. This could allow us to Mint the token and specify a destination address as part of the payload or a flag to either Mint, Mint and create offer or Mint and transfer to wallet.
This would remove the heavy burden of reserves for the minter as any offers created would automatically be accepted by the ledger on the buyer’s behalf. Plus we would have no reserves tied up in unclaimed tokens.

The buyer would also benefit from a much faster delivery of the NFT without the need to approve it manually. The marketplaces would benefit from less XRP tied up in reserves and a more robust, single transaction process.

Security

IMO, there would be no security risk as making it part of the mint process results in protection against subsequent offer creation. i.e., The minter would not be the owner. Additionally, as the buyer is already willing to accept NFTs from that collection/issuer and have paid for spins to do so it makes sense we can give them the NFT without the fuss.

I believe that as this is a transfer, secondary sales would not kick in as the price would be set at 0 XRP. Therefore, no royalties would be deducted.

This proposal should be easy to implement as it requires no new fields and simply expands on the functionality of the NFTokenMinter.

Current implementation

NFTokenMinter can:

• Mint

Proposed:

NFTokenMinter can:

• Mint
• Create initial offer during mint
• Transfer to Account without user needing to accept in their wallet

[WietseWind]

Based on user input, marketplace input, my own experience: yes, I think this should happen.

Looping in @nbougalis for a comment on feasibility of especially:

Create initial offer during mint

[crtag]

There's indeed unnecessary friction in the NFT life cycle. This suggestion addresses the customer pain points and I support the idea. Though, I feel this approach alone might create more headaches in the long run such as spamming with NFTs and hence exhausting reserves etc. It feels that it's necessary to introduce a preapproval mechanism, as well as its withdrawal to allow certain addresses (NFTokenMinter) set to transfer into accounts w/o an offer (the last proposed point) that is the greatest benefit of the proposed update.
Having said this, the existing "Authorized Minter" feature is what needs to get upgraded to allow authorized minters collection management instead.

[crtag]

@mvadari brilliant idea. The minter has to do all of that and point to the NFT that whitelists them, slightly different transaction payload then.

[mvadari]

@crtag yes, but far more efficient

[crtag]

Something like this then, and MinterValidation must contain NFTokenID owned by Destination and composed as described above. All naming convention is up for some thinking.

To be honest, this feels like one case of something more generic to implement, a kind of "permission" system that can be more flexible.

{
  "TransactionType": "NFTokenMintTransfer",
  "Account": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
  "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
  "MinterValidation": "<NFTokenID>"
  "TransferFee": 314,
  "NFTokenTaxon": 0,
  "Flags": 8,
  "Fee": "10",
  "URI": "697066733A2F2F62616679626569676479727A74357366703775646D37687537367568377932366E6634646675796C71616266336F636C67747179353566627A6469",
  "Memos": [
        {
            "Memo": {
                "MemoType":
                  "687474703A2F2F6578616D706C652E636F6D2F6D656D6F2F67656E65726963",
                "MemoData": "72656E74"
            }
        }
    ]
}

[ZachRoberts25]

This is a fantastic idea and would greatly improve the UX of XRPL NFTs. Is anyone actively working on a solution to this in a PR somewhere I can reference. I am happy to help out. I wonder if this could be applied NFT Transfers as well. Essentially NFT Buy Offers for 0 XRP. Could we include this NFT whitelisting logic to those offers, and have them automatically accepted if the buyer/destination owns an whitelist NFT that states the Issuer on the receiving NFT is valid and can be accepted without the need to be signed.

[xmart-git]

I'm not sure it's actually being worked on Zach

[ajkagy]

I love the idea. I think there needs to be some kind of mechanism for a destination wallet to opt into the automatic transfer of an NFT from an authorized minter, otherwise you end up in a situation where this can be exploited by a malicious actor minting thousands of NFTs and automatically transferring the NFTs to the victims wallet thereby spamming wallets and locking reserves.

There's also a few questions of what happens to the NFT if the destination doesn't have the wallet reserves required for the transfer, is there a tec code through from the transaction by the ledger because part of the functionality failed considering the automatic transfer?

[martypaz]

See above comment for thoughts on the whitelist.

Again, Nik's input will be invaluable here about logic checks to ensure the transfer can go through. Then we handle that according to tecNoReserve etc Technically, we could check first their balance but it's another call in the process and accurately predicting reserves is not my bag.

In fact I vaguely remember a discussion some time back between @WietseWind and I think Scott Schurr about reserves not being predictable or easily predictable at least.