Jetton contract
Digital token issue
Did you notice something unclear, incorrect or get stuck with some issue in this guide? Please ask a question in the Telegram chat (opens in a new tab) or text me directly @iftryalexg (opens in a new tab). Guide will be updated ASAP and all unclear points will be clarified 🚒💦🔥.
Jetton is a part of TON
Jettons is implementation fungible tokens on the TON Blockchain. Fungible Tokens means that they have a property that makes each Token be exactly the same (in type and value) as another Token. From the side of users - it's digital tool in blockchain, that allow to organize business process of distribution and keeping funds with zero trust functions in transaction. In TON Blockchain Jettons declared according to Jetton standard (opens in a new tab). This standard already fully successfully implemented with FunC language and support in libraries in various languages. Some of them, you can find and research here.
The scope of this article are:
- Remind how Fungible Tokens works in TON blockchain.
- Research how jetton standard could be implemented in the Tact language.
Note, that jetton.tact is used for learning goals and was not thoroughly tested. It should test necessary before use in production.
Jetton as example of designing architecture
Implementation of jetton demonstrate how relationships between contracts could be implemented. Idea of scaling in TON allows to think about Jetton standard as a workable process even if userbase will grow in digits. It becomes possible, because in Jetton standard we have no any parts, that could slow down. But why does this possible and what the price?
- This is possible, because every part of jetton processing become independent element(smart contract) of the whole jetton wallets. No matter how many users will come, it's just increase quantity of smart contracts, shards and will not slow down blockchain.
- Price we have to pay is increasing of complexity of development. Asynchronous messages increase number of cases, we have to handle in smart contracts. Developers of smart contract have to solve this during at very first steps of designing smart-contract.
Classic issue of fungible token
Suppose we have amount of users with wallets(wallet smart contract) with funds on them in native Blockchain currency. Now, we want somehow to add tokens to user's wallet.
In the ERC20 (opens in a new tab) standard we keep balance and processing transaction in special token contract. This contract stores a map of wallet addresses and their token balances.
If we want to deliver to user information about his token balance, we read data from his wallet and token contract.
Both actions will be delivered to off-chain space, where we will display and use it in our application.
Here, Wallet A, Wallet B - regular wallet contracts.
Then, how to implement token transfer? We can use special transfers between wallet contracts, that will update their balance in Token Master.
With sharding paradigms in TON blockchain we can without problem support a million of users and millions of transactions. But for Token Master will always live in one shard, and become unscalable now.
And what we can do, to solve this issue? Redesign our solution to case, where every atomic part(smart contract) of our process is a small blockchain, that will never grow to infinity.