Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TEP: create Rebase Jetton standard #130

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

IgorErkin
Copy link

This pull request follows the corresponding bounty task: ton-society/grants-and-bounties#342

@EmelyanenkoK
Copy link
Member

If I got it right, the aim of this TEP is to make it possible to increase "displayed balance" for all holders simultaneously.
While I'm not sure it is indeed needed, can the same purpose be implemented like here: #98
In particular will fractional decimals solve this less "invasive"? In particular, instead of "decimal":"9" you specify "fractional_decimal":"734555" and it means that for displayed balance wallet/explorer need to divide number of indivisible units by 734555. By changing "fractional_decimal" on Jetton Root all balances will be multiplied by a corresponding factor.
Advantage of "change metadata" approach is better compatibility with existing software.

If we are concerned that display on services that understand fractional decimals and not are different, it is possible to further introduce "fraction_decimal_symbol". In that case metadata will looks like:

{
   ...,
   "symbol": "RAWMyJett",
   "fraction_decimal_symbol": "MyJett",
   "decimal":"0"
   "fractional_decimal":"734555"
}

Those services that understand "fractional_decimal" will show MyJett rebased balance, those that don't will show not-rebase balance of RAWMyJett.

@IgorErkin
Copy link
Author

IgorErkin commented Jan 25, 2024

@EmelyanenkoK , thank you for your feedback!

Yes, you are correct about the purpose of this TEP. It is needed to implement rebasing mechanics, which imply changes in the token supply, and the corresponding changes in the balances of all holders.

Regarding your proposal, the only concern I have with this approach is that the balance value of the wallet will need to be calculated by each front-end application individually. Given that there are numerous front-end applications developed by different teams, there is a potential for discrepancies in calculation methods, such as using different data formats or rounding rules. In this regard, the use of getters seems preferable, as the calculation takes place in them and they act as SSOT.

So, we can add it, but at the same time I propose to also keep the getters.

A few words about why we need this standard:

  1. It is the only way to implement yield-bearing tokens that are 1:1 equal to and backed by the underlying asset.
  2. In other networks, there are already dozens of similar projects with billions $ in TVL.
  3. The trend towards RWA tokenization with a potential of trillions of $. This standard will play a significant role in this trend. For example, ondo.finance, one of pioneers in this direction founded by managers from Goldman Sachs, plans to implement rebasing mechanics for USDY (one of their products). Or, the first RWA project to come to TON - Ledgity Yield protocol, also plans to implement rebasing mechanics.
  4. At least 5-6 projects in the public field want/wanted to issue rebasing tokens in the TON blockchain

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants