Extra currency minting
Extracurrency
According to TON Blockchain Whitepaper 3.1.6, the TON Blockchain allows users to create arbitrary cryptocurrencies or tokens, in addition to the Toncoin, provided certain conditions are met. These additional cryptocurrencies are identified by 32-bit currency_ids. The list of these defined cryptocurrencies is a part of the blockchain configuration stored in the MasterChain. Each internal message and account balance includes a special field for ExtraCurrencyCollection
, which is a set of extracurrencies attached to a message or maintained in a balance:
extra_currencies$_ dict:(HashmapE 32 (VarUInteger 32)) = ExtraCurrencyCollection;
currencies$_ grams:Grams other:ExtraCurrencyCollection = CurrencyCollection;
Extracurrency config
A dictionary, specifically ExtraCurrencyCollection
, containing all currencies to be minted is stored in ConfigParam7
:
_ to_mint:ExtraCurrencyCollection = ConfigParam 7;
ConfigParam 6
contains data related to the minting:
_ mint_new_price:Grams mint_add_price:Grams = ConfigParam 6;
ConfigParam2
contains the address of Minter.
Low-level minting flow
In each block, the collator compares the old global balance (the global balance of all currencies at the end of the previous block) with ConfigParam7
. If any amount for any currency in ConfigParam7
is less than it is in the global balance, the config is invalid. If any amount of any currency in ConfigParam7
is higher than it is in the global balance, a minting message will be created.
This minting message has source -1:0000000000000000000000000000000000000000000000000000000000000000
and Minter from ConfigParam2
as destination and contains excesses of extracurrencies in ConfigParam7
over the old global balance.
The problem here is that the minting message includes only additional currencies and no Toncoins. As a result, even if the Minter is designated as a fundamental smart contract (as indicated in ConfigParam31
), a minting message will lead to an aborted transaction with the error: compute_ph:(tr_phase_compute_skipped reason:cskip_no_gas)
.
High-level minting flow
One possible high-level minting flow, which is implemented here (check *.tolk
files) is as follows:
- There is
ExtraCurrencyAuthorizationConfig
: the config contains information on which contracts (addresses) have authorization to request minter to mint new extracurrencies. This config has the following scheme:
_ (Hashmap 32 std_addr) = ExtraCurrencyAuthorizationConfig;
where key - currency_id
and std_addr
is admin of this currency (can be in any WorkChain).
-
Minter accepts mint requests from admins, forwards requests for mint to Config, Config updates
ConfigParam 7
, and responds to Minter. Since extracurrencies would be minted to Minter only on the next MasterChain block, withdrawing extra currencies to admin should be delayed. It is done via Echo smart-contract, not in MasterChain. When a response from Echo comes to Minter, it sends extracurrencies to admin. So the scheme is as follows:Admin -> Minter -> Config -> Minter -> Echo (in other workchain to wait until the next masterchain block) -> Minter -> Admin
An example of this flow is as follows: minting 2'000'000'000 units of currency_id=100
Each minting of new extracurrency or an increase in the supply of existing currency necessitates a change to ConfigParam7
, which in turn alters the configuration and creation of keyblocks. Frequent keyblock generation can slow down shard performance since each key block causes a rotation of validator groups and affects the synchronization of liteclients. Therefore, contracts like swap.tolk
should not be utilized in production environments. Instead, it is advisable to use schemes that involve reserves to minimize minting events.
Sending of extracurrency to blackhole has the following effect: extracurrency amount is burnt, but since ConfigParam7
is not changed, on the next block, Minter will receive the burnt amount on its balance.
How to mint your own extracurrency
-
Ensure that your network has the Minter Contract and that
ConfigParam2
andConfigParam6
are set correctly. -
Create a Currency Admin Contract that will control how the extra currency is minted.
-
Submit a proposal to the validators to add your Currency Admin contract address to the
ExtraCurrencyAuthorizationConfig
for a specificcurrency_id
and obtain their approval. -
Send a
mint
request from the Currency Admin Contract to the Minter. Wait for the Minter to return the extra currency.