This topic is reserved for the TRC-6 Fungible Tokens standard (and being updated).
TIP: 6
Type: TRC
Title: TRC-6 Fungible Tokens Standard
Author: Anton Platonov <[email protected]>, Dmitriy Yankin <[email protected]>
Status: Draft
Created: 2021-06-08
Abstract
The following standard allows for the implementation of a standard API for fungible tokens within smart contracts.
This standard provides basic functionality to create wallets, transfer and manage tokens and send/receive events.
Motivation
A standard interface allows any tokens on Free TON blockchain to be re-used by other applications: from marketplaces to decentralized exchanges.
The motivation behind creation of new fungible token besides TIP-3 is that TIP-3 original standard:
- doesn’t respect asynchronous nature of Free TON blockchain (no callbacks or callback getters);
- is too broad (covers 4 types of tokens instead of one);
- is complicated (including ownership by both public key and address);
- allows sending tokens using wallet address directly (see
internalTransferFrom), terget contract can be a malicious contract which implementsinternalTransferfunction which will end up in loosing Tokens; - requires user to worry about wallet’s balance (having multiple wallets without automation system that manages balances is a great place for human errors);
thus different teams are forced to create numerous TIP-3 forks that are incompatible with each other.
Features
Internal Ownership
Designed to be distibuted analogue of ERC-20 contracts, TIP-6 presents a very important restrictions. User (as in Ethereum) doesn’t directly interacts TIP-6 wallet from “nowhere”. As in Ethereum each TIP-6 wallet has concrete specified owner address. This is a multisig wallet address. It means that user only interacts with his own TON wallet and all TIP-6 token management stuff is hidden between multisig and TIP-6 token Root Contract. TIP-6 Wallets in this mechanism are needed only as distributed storage. They don’t have any own identity.
Transfer By Owner Only
An important part of previous point. When you want to transfer some token in Ethereum you don’t need to specify any TIP-6 addresses, wallets and so on. You specify only owner address, that should receive them (because Ethereum doesn’t have any separate token wallets). We think that it’s a great practice, so you can’t specify any wallet addresses in TIP-6. You specify a target owner, and he just receive tokens. That’s all.
Closed Gas Chain
As all other token wallet management stuff is hidden from direct interaction with user, the same happens with Gas management. You don’t need to check wallet balance, neither you need to explicitly add any balance to wallets. They. Just. Work. It is made possible by combination of raw reserve flags, minimal balance and a strong requirement of returning all extra gas after all operations made in TIP-6 environment.
Usage of MYCODE Opcode
The large problem of TIP-3 contracts is their size. It happened because of a strong requirement of storing additional full Wallet code in each Wallet contract to resolve code and data against counterparty address and data. With the addition of MYCODE OpCode, we used its Solidity tvm.code() implementation to remove extra wallet code.
Cheap Storage
The size of of both Root and Wallet TVCs do not exceed 3.5Kb. It’s an outstanding result that became possible because all optimisations that were described before not only made TIP-6 more simple and usable, but also reduced the size of contracts.
Notification Payload Control
TIP-6 has a unique system of triple notifications. Besides a basic event emitting when you receive some tokens, there are also additional mechanisms for both invoker and receiver to receive separate notifications. If you’re wallet owner and want to receive notifications each time you get tokens - just set a special flag.
And if you’re a sender and you too want a notification, just specify it in transfer args, you will receive a separate notification to desired address.
Such broad capabilities allow you to implement Notification Callback Handlers in your separate service contracts and add any business logic.
We already have a working example of this logic - GitHub - laugual-contest/dex-core-2 , DEX by Augual.TEAM. When you want to swap your tokens, just send them to DEX. That’s all! No allowance, no calls to DEX contracts. You just send tokens to DEX and specify needed opetation in call payload. If it’s wrong, you will receive your tokens back.
Specification
Full specification can be found here: GitHub - laugual/liquid-ft
Specification includes README, interfaces and contract examples.
.