Fungible Token Minting Standard

[robert-zaremba]

Summary

An interface for a fungible token minting, which is usually a part of a token life cycle,

Motivation

Token minting can be triggered by other smart contracts. Hence we need a standard interface for minting.

In a minting life cycle, token will be firstly minted and then transferred. Following scenarios are possible:

• user can mint tokens for himself (faucet)
• issuer will firstly mint tokens and then transfer
• smart contract will mint tokens for a user

Moreover, there are tools which filter transactions to report user tokens in a dashboard (eg the NEAR Wallet).
These tools will usually check the first transaction. In case of NEAR Wallet it check for the ft_transfer, ft_transfer_call function calls. If a user will receive a token through minting, the it won't be reported (see Minted Tokens via Contract not showing in Wallet #468 issue). So, we need a standard interface in order to have a tool support.

Outcome

We decided to reject this proposal. Reason:

• Most tokens don't just allow someone to mint them, they are minted as part of a more complex transaction, and this API is not suitable for this case. As a result, this API has very limited usability.
• Scope for token minting tools is very limited.
• User balance tracking should use events, not ft_mint calls. Tokens can be minted through various flows.

[mikedotexe]

Tagging @MaximusHaximus on this. Perhaps we can jump on a call to discuss. I have an idea in my head of how this all works, but when it comes to implementation, I think Daryl knows way better. The thing I'm trying to understand here is the idea of "first you mint, then it transfers so it'll get caught by the indexer."
Ideally, we'd let the indexer know about the mint function and parameters so it can keep track of that. Would that be a heavy lift?
Is the implication that this mint function must use an ft_transfer or ft_transfer_call before assigning ownership?

[robert-zaremba]

Coins are created by minting - and we would like to see that coins in the NEAR Wallet.
The issue is related to the wallet behavior. If you receive a token which doesn't match the required regexp then it won't be visible in the NEAR wallet.

[telezhnaya]

@mikedotexe we have a new piece of information from the #249 and the call.
Could you please have a look at this PR again?

[ilblackdragon]

As I have mentioned in #254 (comment), you can not and should not define minting or burning standard based on function names.

There are many times when tokens will be minted as a subsequent step of some other action:

• user deposited another token
• user swapped tokens via deposit of another token with ft_transfer_call
• user called add_liquidity
• user called liquidate
• user burnt another token
• some if statement when they get minted and when they dont'
  etc.

Function name based standard is impossible to define here.

Instead logs emitted when new tokens enter circulation and when they leave should be present.

[robert-zaremba]

I like the log based approach. Although, I still think it's good to have a standard for minting: it's useful when one contract wants to request minting (eg in farming). Composibility can't be done with logs. Logs are good for indexer and off-chain tools. That being said - our initial issue came from a wallet not being able to find new user assets.

[frol]

I like the log based approach.

Just for the readers' reference, since the time this NEP was proposed, NEP-297 was implemented, so the initial issue has already been resolved:

That being said - our initial issue came from a wallet not being able to find new user assets.

Wallet and Explorer extensively use the mint/transfer/burn logs these days (NFT and FT standards were also extended with the events).

Although, I still think it's good to have a standard for minting: it's useful when one contract wants to request minting (eg in farming). Composibility can't be done with logs. Logs are good for indexer and off-chain tools.

Most of the minting methods rely on some non-trivial logic that is hard to standardize, so I am leaning towards rejecting this NEP.

@near/wg-contract-standards Please, review this NEP

[mfornet]

Looks good to me. It is very simple, and it naturally extends FT capabilities.

[mfornet]

What about adding an extra method ft_mint_call (similar to ft_transfer_call). It can be an overkill, but it could simplify some scenarios where you need to mint and immediately react to these "transfers", potentially even burning part of the tokens that are not used on a callback.

I don't have any particular use case in mind.

[robert-zaremba]

Hmm, like minting for the smart contract? I think it will add more complexity, but if people think it's needed, then we can add it. We can always add it later to evaluate the need.

[mfornet]

@ilblackdragon I see this paragraph might be confusing.

you can not and should not define minting or burning standard based on function names.

As I read this standard, I don't think the goal is to enforce that all minting/burning goes through this method. It rather tries to consolidate a feature for some tokens that have a natural way of minting tokens (like faucets), so they can be used uniformly from external tools.

I agree that we should not rely on the ft_mint method to determine if users have some balance. In this case, I do suggest this standard enforce that the contract emits Mint events logs so that they can be used by indexers (wallet / explorer).

[telezhnaya]

It rather tries to consolidate a feature for some tokens that have a natural way of minting tokens (like faucets), so they can be used uniformly from external tools.

If we fix the function name just for faucets, that will confuse users even more. It should be fixed for everyone, or, if we can't do that, we should NOT declare this in NEPs.

In this case, I do suggest this standard enforce that the contract emits Mint events logs so that they can be used by indexers (wallet / explorer).

It's already done in https://nomicon.io/Standards/Tokens/FungibleToken/Event

[mfornet]

Some tokens won't expose the option to mint new tokens, and some will use a different approach. I'm thinking, for example, about bridged tokens, where you can "mint" new tokens after providing proof. I don't think this NEP is suitable for those use cases. The Mint event (log) needs to be emitted, though.

It should be fixed for everyone

For everyone interested in exposing the minting functionality.

In this regard @robert-zaremba, I suggest expanding the Motivation section with a real use case (maybe the one that motivated you to write this NEP).

[robert-zaremba]

Yes, for balance tracking Events should be used.

[robert-zaremba]

The goal is really for composability. For example, in Cheddar we added contract to contract authorization to allow farm for minting.

See comment about emitting Mint events.

[ori-near]

@near/wg-contract-standards – We would like to schedule a working group meeting to review this NEP. Before we proceed, we would like to get closer to a consensus on this NEP.

@abacabadabacaba @mfornet Could you please fully read this NEP and comment in the thread if you are leaning with approving or rejecting it? Please make sure to include your rationale and any feedback that you have for the author. Thank you.

[abacabadabacaba]

I lean with rejecting this NEP. Most tokens don't just allow someone to mint them, they are minted as part of a more complex transaction, and this API is not suitable for this case. As a result, this API has very limited usability.

[robert-zaremba]

OK, then let's close it. I will update the description of this PR with the outcome.