0052 XLS-52d: NFTokenMintOffer

[tequdev]

Abstract

This proposal extends the minting capabilities of NFToken (XLS-20).

NFToken are not only held by the issuer, but are often distributed or sold by the issuer to others.

XRPL NFToken requires two transactions (NFTokenMint and NFTokenCreateOffer) to be sent by the issuer before the NFToken can be minted and distributed (or sold).
NFTokenOfferMint extends the existing NFTokenMint transaction to allow an NFToken Sell Offer to be created at the same time as the NFToken is minted.

NFTokenOfferMint is expected to significantly improve the experience of NFT projects and users.

Specification

New NFTokenMint Transaction Field

Add 3 new fields to theNFTokenMint transaction.

Field Name	Required?	JSON Type	Internal Type
Amount		Currency Amount	AMOUNT
Destination		string	AccountID
Expiration		number	UINT32

These fields have the same meaning as the field of the same name used in the NFTokenCreateOffer transaction, but the Amount field is not a required field.

If the Amount field (and the other 2 fields) are not specified, NFTokenMint transaction behaves exactly like a previous NFTokenMint transaction.

Creating an NFTokenOffer

Since NFToken issuers can only create a sell offer for their NFToken, the Owner field is not set and tfSellNFToken flag is always set in the NFTokenOffer created in an NFTokenMint transaction.

In an extended NFTokenMint transaction, an NFTokenOffer is created when

• Amount field is specified.

An error occurs in the following cases

• One or both of Destination and Expiration fields are specified, but the Amount field is not .

Owner Reserve

The NFTokenPage and NFTokenOffer reserves will not change, but will create the possibility of up to 2 incremental reserves (NFTokenPage, NFTokenOffer) in an NFTokenMint transaction.

[mvadari]

Why edit the NFTokenMint transaction instead of creating a new transaction type?

[tequdev]

Considering the HookOn field in Hooks, I thought it would be a bad idea to unnecessarily increase the number of transaction types.
Is there any significant advantage to using this as a new transaction type?

[Ekiserrepe]

I think it's helpful to have a process that allows you to join both processes (it happens to me a lot) but as @mvadari says I was expecting to be a new tx type instead to modify the original one just for legacy issues for those who doesn't know the new change. I'm not against to rewrite the original tx but it's true it will create the issue to reeducate those who don't know the new changes. Thanks for the work @tequdev ❤️

[WietseWind]

Considering the HookOn field in Hooks, I thought it would be a bad idea to unnecessarily increase the number of transaction types.

I agree with this. It's similar to flags imo, or even for example regular offers, where you can also cancel another offer optionally.

I would propose to prevent using more and more transaction types for things to be considered an option in an existing flow.

[shawnxie999]

Just curious why we need this change on the protocol level instead of calling NFTokenMint and NFTokenCreateOffer on client side? Just curious why you think calling these two separate transactions is problematic, leading to this proposal.

[tequdev]

This is especially useful for large random Mints rather than small creators.
If 1000 NFTs are used to create Mints and Offers at the same time, 2000 transactions are required.

Also, NFTokenCreateOffer requires an NFT ID that depends on MintedNFTokens, and the NFT ID required for the 1000th offer cannot be calculated in advance given the possibility of failure of any of the 1~999th NFTs to be minted.

It is more about improving convenience on the developer's side than on the user's side.

[mvadari]

Thoughts about this method in relation to XLS-56d? #162

[ximinez]

Something to consider is that functionality always comes with costs, including potential for new bugs, maintenance over time, extra documentation, etc. If an Atomic transaction can do what NFTokenMintOffer can do (and it looks like it can), and the only difference is ~20 drops per mint and fewer mints per Atomic, then I don't think NFTokenMintOffer is worth the extra load and work.

[shawnxie999]

But NFTokenCreateOffer needs the NFT ID, which is generated only after the NFTokenMint is successful. Unless I'm missing something in the Atomic spec

[mvadari]

You could predict what it would be if it's successful.

[shawnxie999]

You could in most cases, but I would oppose doing that...

This is not robust and prone to changes on rippled

[xVet]

Yea we don't do that usually, calculating it ourselves, we take the NFTokenID from the metadata of the TX as this is actually what happens on chain.

[tequdev]

Since the implementation of this proposal has already been merged into the develop branch of rippled, this discussion will be closed and moved to the PR of this repository.

#224