Mint, burn and send extra currencies

[yaroslavser]

Abstract

This document describes the principles of working with non-native tokens at the network protocol level.

Motivation

Currently, work with non-native tokens is implemented on smart contracts using the TIP3 standard. At the same time, at the protocol level it is possible to create and transfer non-native tokens, which allows

• Transfer more than one token at a time in one transaction
• Control value flow at the protocol level using validators.

The current implementation of currency collection has shortcomings

• no burn tokens (only transfer to burn address)
• creating a new token or minting existing ones requires changing the global network config
• Mint occurs at minter's address

This proposal is intended to correct shortcomings and make working with currency collection accessible to any network participant
This proposal is not intended to replace the TIP3 standard, but rather to enhance its capabilities.

Specifications

We propose to add a system smart contract that will allow you to

• create new currencies
• transfer tokens without reducing its balance (mint operation)
• not change its balance when receiving tokens (burn operation)

Description of Manager Currencies smart contract

• function register_new_token()
• function mint(uint256 value, address addr)
• function burn()

The operation of the contract cannot be completely free, even if it is made systemic, it should still require tokens for the operations of adding currency and minting tokens, as part of spam protection.

Modify virtual machine

Add a tvm.burn instruction that creates OutAction::Burn
Validators only allow this instruction to be used for addresses from global config

Pros and Cons:

What is the upside of using Currency collection?

• We will be able to reduce the chain of token transfers between users
• We will be able to transfer multiple tokens in a single transaction (as in 1155)
• We will be able to use for MESH networks

What are the downsides of using Currency collection?

• It seems that DEX will have to support both TIP3 and currency, more code to write in pools, legs, etc.
• Mint and burn is a load on the master and can't be a cheap operation
• Not suitable for CBDC
• Load on masterchain

Why burn only for contracts from master

When we burn we change global balance in the blockchain state and it is stored at masterchain

[mnill]

Is the size of the ExtraCurrencyCollection hashmap considered when calculating the storage fee for an account?

If yes, then uncontrollable growth in the number of extracurrencies could lead to a situation where a malicious actor could significantly increase the storage fee for any account simply by sending small amounts of 10,000 different currencies.

If not, given that we now do not delete accounts but only freeze them, it's possible to create a large number of frozen accounts that take up a lot of space (ExtraCurrencyCollection is not frozen).