The uTON token contract
Last updated
Last updated
In this section, we focus on the generation and liquidity of uTON, i.e. the liquidity re-staking token (LRT). In most cases, with the generation of uTON, funds will enter the Vaults for subsequent processes. We give the overall design of the uTON contracts. The main focus of the contract is to manage the liquidity of TON, uTON, and other LSTs such as stTON.
The overall design of the contract is centered around uTON, which has a standard Jetton interface. We will extend its capabilities to support various re-staking functions. Given TON's asynchronous processing and messaging mechanisms, and considering the potential for multiple staking forms in the future, we will delegate the minting and burning functions of uTON to a series of proxy contracts. The proxy contracts are also part of the UTONIC system contracts.
For the uTON Jetton contract, it maintains a proxy pool, which functions similarly to a whitelist mechanism. Each proxy in the pool has its own logic to call the uTON Jetton contract interfaces. The addition and removal of proxies in the proxy pool are managed by the owner of the uTON Jetton contract. It also maintains an exchange rate relationship between uTON and TON, which is monotonically increasing.
According to the above sections, UTONIC supports two main categories for collateral: naive TON and LST, to generate uTON.
For native TON, UTONIC's support is divided into two categories: retail users and whale holders, where the whale holders refer to those who have enough TON to operate a single nominator pool for independent staking.
For retail users, the UTONIC system has a globally unique Proxy_retail contract for management. When a user deposits TON, it is passed through the Proxy_retail contract to the uTON Jetton, which mints the corresponding uTON for the user, while the TON is transferred to the vault. When a user withdraws, they first need to transfer uTON to the proxy_retail contract. After waiting for a period, the Proxy_retail will notify the uTON Jetton to complete the destruction of uTON and the repayment of TON.
For whale users, the restaking of TON is managed by the users themselves. In this case, uTON is in a jointly managed state between the project team and the users. Each whale user has a separate Proxy_whale contract that enters the uTON Jetton's proxy pool, while uTON will be minted accordingly. The Proxy_whale interfaces with the subsequent single vault. Once TON flows into the single vault, whale users can independently complete the subsequent restaking process through UTONIC.
The restaking of LST TON is generally consistent with the restaking of retail users' TON. However, it involves converting Native TON into LST TON. For each type of LST TON token, there is a Proxy_LST. Unlike Proxy_TON, Proxy_LST additionally maintains the price of the LST token relative to TON, which is used for converting into the quantity of uTON to be minted.
