On April 19, at the Token2049 conference, after a speech by Pavel Durov, the appearance of a stablecoin from Tether in the TON - USDt network was announced. Since this is a centralized stablecoin, the issuer of such a token must have control over user funds to comply with regulatory requirements, for example, block user funds. In this short article I will tell you how tokens on TON work and what opportunities a stablecoin issuer has.
If you are already familiar with the TON blockchain and the concept of how tokens work, you can immediately skip to the Locking your funds paragraph, which discusses the mechanics of a stablecoin, since we will start in this article with the basics.
How smart contracts work in the TON network
The TON blockchain is asynchronous, smart contracts transmit data to each other by messages. Contracts are written in TACT and FUNC, the logic written in these languages is quite understandable without detailed study, we will use this when reviewing stablecoin contracts. But if you want to understand deeper, there are free open source lessons here.
Smart contracts on TON do not involve storing large dictionaries within themselves; instead, it is supposed to create a master contract that can “recreate” (the address is a hash of the initial information of the smart contract and its code, which makes similar mechanics possible) within itself the addresses of related contracts and thus send them messages, my information was stored in them
This mechanism is called smart contract sharding. Don't worry if this is not very clear, below we will look at how it works using examples. For now, just note that at TON we almost always deal with a group of smart contracts transferring information from each other.
The sharding mechanism allows business logic on smart contracts to be scalable, but this complicates the design of smart contracts. This is worth considering if you plan, for example, to transfer the logic of some EVM-compatible decentralized application to TON.
For each smart contract, there are reserved methods for internal and external messages. Typically, these methods describe the logic of what the smart contract should do, depending on the message payload. It looks something like this:
Like other networks, TON has smart contract standards. The standard describes the required signature of smart contract methods and the required logic. Standards allow decentralized applications, such as wallets, to display information, to understand, for example, what is an NFT contract and what is a token contract.
A stablecoin is a fungible token tied to the price of the token, so before moving on, let's look at the standard fungible token in the TON network - Jetton.
Jettons or how to store data without a dictionary
Tokens in the TON network are fungible tokens. A token is a unit of accounting for some digital asset in some blockchain network. It is important to note that a token does not usually mean a cryptocurrency, but rather a record distributed on a blockchain that is managed using smart contracts. The smart contract records the values of account balances of token holders (the balance of a certain address of the owner), and the smart contract also provides the ability to transfer tokens from one account to another.
Accordingly, a technical problem arises: how to store balances of tokens of different addresses and effectively update these balances. This is where sharding comes in handy.
We will split the storage logic into several contracts, for each token owner, we will issue a separate wallet contract (namely the wallet of this token, not the wallet for Toncoin), which will store information about the balance of only this wallet, and there will also be a master contract that will store information about the token itself, for example, its name, symbol, general offer, etc.
Thus, if our token is owned by 1,000,000 different users, exactly 1,000,001 contracts will be deployed. And with various messages, you can perform certain functions.
Let's look at a simple token transfer. So, in order to transfer tokens from wallet one to wallet two, we will need to send a message with the transfer flag to our token wallet, which in turn, having received such a flag, will send funds to token wallet 2 and here is an interesting point, since the messages use Toncoin as fee for messages and execution of smart contracts (like gas in EVM networks), then in the end the token wallet 2 will return the excess back to Toncoin wallet
Note that the master smart contract is not involved at all in transferring tokens between wallets. But if we didn’t want to transfer the tokens, but, for example, just burn them, then we would have to send a separate message to the master contract, because when burned we would change the total supply of the token.
Of course, these are slightly simplified diagrams, the purpose of which is to give an idea of the architecture of smart contracts on TON. If you want to dive deeper into how Token standard tokens work, I have a full breakdown of the standard here.
Another small nuance: most often it is the master contract that deploys contracts and wallets.
Locking your funds in a stablecoin
Like a regular token, a stablecoin smart contract has a master contract and a wallet contract. And the first thing that distinguishes a regular token from a stablecoin is storage.
A regular token stores the balance, owner's address, master contract address and wallet code (together with the contract storage, the code allows you to obtain the code of a given token wallet). From jetton-wallet.fc (this is the wallet code in FunC language):
But the stablecoin, in addition to this information, also stores the Status, and it is this variable that allows you to block your funds.
Before describing how it works, I’ll make a small clarification for those attentive: if you compare smart contract storages, you will not see cells with code in the stablecoin, this is due to the fact that during the time between the creation of the token standard and the stablecoin token, there were updates to the virtual machine TVM and at the moment you can not transfer a cell with a code, but simply get the current smart contract code through the MYCODE primitive
In the proposed standard, the status variable, if we simplify the logic with bits, can take three values:
0 - unlocked, you can safely use your funds
1 - wallet owner cannot send stablecoin
2 - the wallet owner cannot receive stablecoin
This status can only be changed from the contract master; the following conditions are in the function that processes internal messages:
It works quite simply, the owner of the master contract sends a message with a certain payload to the master contract, and the master contract changes the status of the message.
Thus, the issuer of a stablecoin can block the funds of any wallet with a given stablecoin. As I mentioned at the beginning of the article, this is necessary to comply with the requirements of regulators by the issuer, which are usually funds that provide the stablecoin in a certain ratio with fiat and, of course, such funds cannot ignore the requirements of the state.
But blocking your funds is not the only option for the administrator of the master contract - the issuer. In addition, your funds can be burned or simply transferred.
Burning and Transferring Your Funds
If we go to the master contract jetton-minter.fc (this is the master contract) and see how the status change is implemented, then in the function for processing internal messages we will see the call_to fork, in which you can send a command to any wallet with stablecoins to transfer a stablecoin, burning or just a change in status, which we considered in the previous block of the article.
Thus, the admin of the master contract can easily manage your funds. It is important to note here that if an administrator tries to steal your funds without regulatory pressure, this will discredit the stablecoin, since all transactions in the blockchain are visible and a similar precedent will be replicated by telegram channels in a couple of days to all users who do not want to use such a stablecoin.
Such a system of incentives restrains the stablecoin issuer from abusing technical capabilities.
But that's not all.
Mechanism for replacing code and master contract data
The title of this paragraph reveals its entire essence - yes, this is possible, a complete replacement of the master contract code. It looks something like this:
From the message that comes to the contract, they will simply take new data for the storage and a new code.
This way, the creators of the stablecoin can change almost everything about it. And this is some reality that cryptocurrencies face, forced under pressure from regulators to create blocking mechanics, as well as leave the opportunity to change everything if something goes wrong.
Conclusion
I like the TON blockchain for its technical elegance; at least it’s not another copy of Ethereum, which is being overclocked with the help of a lot of capital without regard to why the user needs it in general.
If you want to learn more about the TON blockchain, I have open source lessons that will teach you how to create full-fledged applications on TON.
https://github.com/romanovichim/TonFunClessons_Eng
I post new tutorials, data analytics and articles here: https://t.me/ton_learn
Stablecoin standart code: https://github.com/ton-blockchain/stablecoin-contract/tree/main
Top comments (0)