Description
tip:205
title: Freeze TRX tokenization
author: Kiven <kiven.liang@tron.network>
discussions to: https://github.com/tronprotocol/TIPs/issues/205
status: draft
type: Standards Track
category: TRC
created: 2020-11-27
Simple Summary
This TIP provides freeze TRX tokenization for java-tron.
Abstract
At present, in the Tron ecology, user freeze some TRX can only be used for voting, and the annualized reward of voting is only about 7-8%, According to the principle of POS consensus mechanism, a low staking rate is not conducive to the security and maintenance of the whole network,
so the main purpose of this improvement is to improve the overall security and reliability of the Tron ecology.
Motivation
Increase the profitability of TRX holders, while ensuring the health and stability of the Tron network.
Rationale
freezeBalance: Freeze a certain amount of TRX, get corresponding bandwidth/energy/voting rights, and get a certain amount of tokens/vouchers issued by the system.
unFreezeBalance:Users unfreeze a certain amount of TRX, clear the corresponding amount of bandwidth/energy/voting rights, and deduct the corresponding amount of tokens/vouchers.
transferAssets: Users can transfer TRC10 tokens
Technical Specifications:
Obviously, in order to increase the user's staking rate of TRX, the user must be willing to stake his TRX, and currently, the only way a user can gain a profit via staking TRX is voting, so we can come out with several possible solutions, which must satisfy some rule.
- Reward of staking TRX is not limited to voting revenue.
2.Improve voting incentives
For Scenario 2, increasing the voting bonus will lead to an increase in the amount of issuance(Inflation), which is not conducive to the stability and growth of the token price, of course, the current network issuance rate is the lowest among several mainstream public chains, but it is not within the scope of consideration.
So how do we make staking TRX more than just getting to vote? There are two main options.:
Solution 1:
We can design a TRC10 token/voucher, when users freeze their TRX, a certain number of these tokens/vouchers will be issued to users, and when users hold these tokens/vouchers, they can perform corresponding ecological operations, such as using these tokens/vouchers to mine.
When users want to unfreeze, they need t return the corresponding tokens/vouchers before they can unfreeze.
Solution 2:
This solution mainly takes advantage of the new voting instructions on the Tron20 Smart Contract, by issuing the official voting contract, users can vote for SR through the contract, and at the same time, we can issue a corresponding percentage of TRC20 tokens to users. When users redeem the TRX, they will also need to deduct the corresponding tokens. Since the current voting instruction can only vote for one SR, you need to deploy multiple voting contracts for the corresponding SR (this can also be done by modifying the voting instruction to allow one contract to vote for multiple SRs).
Both Scenarios 1 and 2 are relatively easy to implement.
Scenario 1 is to issue tokens/vouchers to users through the system, using the TRX10 token model.
Scenario 2 uses the smart contract development method, which increases the workload and is not conducive to system integration. The advantage is the direct use of the TRC20 token, which is more conducive to the application of the Defi project.
Here, we comprehensively compare and choose Option 1 to implement:
The ratio of token value to TRX value, which can be designed as a dynamic exchange, fixed ratio exchange.
Fixed Ratio: There are three schemes, which can be designed to exchange tokens for TRX at ratios of 1:1, 1:10, 1:100;
Dynamic Ratio: This can be positively correlated with the amount of TRX a user pledges, the more TRX a user pledges, the more new tokens he will receive. The more TRX a user pledges, the more new tokens he will receive. The specific dynamic exchange ratio can be seen in the following table.
user staking amount | ratio to TRX |
---|---|
0~1000 | 1:1.0 |
1000~10000 | 1:1.1 |
10000~100000 | 1:1.2 |
100000~1000000 | 1:1.4 |
1000000~10000000 | 1:1.6 |
10000000~100000000 | 1:1.8 |
1000000000~1000000000 | 1:1.9 |
1000000000~ | 1:2.0 |
The above redemptions are incremental in accordance with the user's pledge volume gradient.
Revenue Model:
Note: The above data are not promised reward rate, need to check it out in the real system operating environment.
Data Structures:
main parameters of the new insurance token:
"id":"1234567"
"owner_address":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"name":"0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"abbr": "0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"total_supply" :1000000000000,
"trx_num":1,
"num":1,
"precision":1,
"start_time" : 1530894315158,
"end_time":1533894312158,
"description":"007570646174654e616d6531353330363038383733343633",
"url":"007570646174654e616d6531353330363038383733343633",
"free_asset_net_limit":10000,
"public_free_asset_net_limit":10000,
"frozen_supply":{"frozen_amount":1, "frozen_days":2}
}'
Implementation
coming soon
Copyright
All content herein is licensed under Apache 2.0.