Development of a new standard that adds the ability to implement rebase tokens

IgorErkin commented 10 months ago

Summary

As of today, there are at least 3-4 teams (including us) in the public field who are developing or planning to develop projects based on rebase mechanics on the TON blockchain. However, at present, implementation of such tokens in a general way is impossible. In order for this to be possible, a new token standard is needed.

We have described this problem and possible solutions in detail in a separate article: https://medium.com/@united-finance/overview-of-ways-to-implement-rebase-tokens-on-ton-blockchain-3e23552cf0b3

The code of the Rebase-Jetton standard, which our team proposes and is described in the article, has already been implemented and is available here: https://github.com/united-finance/Rebase-Jetton

Within this bounty task, it is necessary to: 1) Improve/modify/rebuild the proposed Rebase-Jetton standard as needed, based on the community's feedback. 2) Describe the final version of the standard in accordance with the TEP template and complete the remaining steps of the TEP proposal process.

Context

Reasons why the ability to implement rebase-based projects in TON is necessary: 1) In single-chain blockchains, there are currently dozens of such projects with billions of dollars locked. TON blockchain, as a platform for launching projects, should remain competitive with other blockchains in this regard. Having such a standard, we will give the opportunity to implement rebase-based projects. The more projects there are, including those working on different mechanics, the better for the network as a whole for obvious reasons 2) Rebasing tokens are the only way to implement yield-bearing tokens that are 1:1 equal to and backed by the underlying asset. These tokens are much easier to understand for ordinary users who are not familiar with the deep mechanics of DeFi, so their presence in the system contributes to mass adoption. This is evidenced by the stable growth in the number of stETH holders (the most popular rebase liquid staking token), compared to non-rebase analogues.

More detailed information is also available in the article above.

References

1) A good explanation of the rebase mechanics in Lido docs: https://docs.lido.fi/contracts/lido 2) A short overview from Coinmarketcap: https://coinmarketcap.com/academy/glossary/rebase

Estimate suggested reward

$2000 in TON equivalent

IgorErkin commented 10 months ago

If the task is approved, please, assign it to me and @KonstantinK01

ProgramCrafter commented 10 months ago

I fail to see how the tokens that automatically change their amount are better than tokens that appreciate in value,

I think amount of user's tokens must not decrease in any case, since that's bad UX,

IgorErkin commented 10 months ago

1) Most projects on other networks are yield-bearing tokens, whose supply increases. From the user's point of view, rebase tokens are more understandable here. For example, rebase liquid staking TON is still TON, as it is 1:1 backed by it. Non-rebase liquid staking TON is a confusing derivative that has its own market price. However, both you and I may be wrong about what is better for the user. The only one who can determine this in the long term is the market. 2) I agree that negative rebases are quite strange from the user's point of view, but given the situation in other networks, there will be few projects in which negative rebases will take primary place. These are usually exotic projects, such as algorithmic stablecoins. 3) Currently, in the midst of the bear market, over $15 billion is locked in rebase-based projects on other networks. In the next bull market, this number can easily be multiplied by 10. It would be a big mistake to prevent developers from developing such projects and not allow this capital to be allocated to TON.

justdmitry commented 10 months ago

at present, implementation of such tokens in a general way is impossible

Rebase-Jetton standard ... has already been implemented

Looks contradictory to me.

Also, more information about how your implementation works (text docs, sequence diagrams etc) may help a lot to understand your solution, because at the first look your wallet renamed "balance" storage field to "shares", and added one op_getter_balance that responds win msg containing shares (=balance) value without modification.

Anyway, you may implement this new mechanics for your project, and then apply for next TON Awards (I don't know when/if will it happen, but 2022 was successful one: https://blog.ton.org/ton-awards-results).

IgorErkin commented 10 months ago

Yes, Rebase-Jetton has only minor changes compared to the regular Jetton, you are absolutely right. The mine idea of the new standard is to let other network participants understand, that tokens based on this standard operate with shares, not balances. E.g. wallet app, seeing such a token, must not display its balance directly. Instead it must first fetch shares from the Rebase-Jetton-wallet, and then invoke the get_jetton_balance(int shares) offchain getter located in the minter contract. Only after that it may display the user balance. It is described in the "Rebase-Jetton integration examples" section in the article

Also the problem cannot be solved just within one project, since this mechanic is related to token itself

Gusarich commented 10 months ago

LGTM in general, but 5000 is too much for that

IgorErkin commented 10 months ago

well, it is an attempt to compensate my own expenses which I made before the creation of this task. Overall they were even higher tbh (investigating different solutions in other networks, trying to adapt them to TON and invent new approaches, writing an article, etc.)

if it is not acceptable for such tasks, lets lower then, no problem. I agree that there is not so much work left)

behrang commented 10 months ago

I read your article, and it was great. My viewpoint:

I tried to implement Hipo in a rebasing way initially, then found out that it's not feasible in TON because we have to split wallets to different smart contracts. Then changed the architecture to a non-rebasing structure. So I went that route initially.
Maybe Lido's implementation is because of their initial instinct too, they went the route of a rebasing token, it was easily doable in Ethereum, and everything worked, they gained market share, and now they're number one. I mean, the fact that they have $15bn locked is not an evidence of ease of understanding for users. Maybe there are other reasons. In addition, their newer protocol on Solana is a non-rebasing token I think.
Your article was great in pinpointing the changes, and documenting different aspects of rebasing and non-rebasing.
For the wallets to not show the Jetton balance, I think you have to change the signature/method_id, so they won't show an incorrect balance.
I think having this standard, will do no harm. In the long run we will find out which is better for which task.

krigga commented 10 months ago

It is my understanding that rebase tokens are mostly meant to be used when the underlying asset is not owned by the rebase token issuer - that is, the rebase token issuer cannot just mint the underlying asset on a whim, it must come from somewhere. The current proposed implementation seems to assume that the underlying asset is owned by the rebase token issuer - the mint operation increases both the normal supply and the shares supply.

It seems that a more useful approach would be a system that allows locking up some jetton's balance on the main rebase token contract, and it would then issue shares as new jettons which can be transferred to other users or burned to retrieve the underlying asset. The jetton wallet code wouldn't even need to be changed from the reference implementation of TEP74 - only the minter needs to be changed to support this locking and unlocking (burning) operation. To facilitate the display of the underlying asset's balances in UIs, a get method would just need to be added to the minter - something along the lines of (slice underlying_asset, int underlying_balance) get_rebase_data() - then the UIs that support this standard would have enough data to calculate the balance to be displayed.

This lockup system really isn't particularly complex so 5000 USD for it is definitely too much, 1-2k is more like it I feel.

Also, if you strive to make a standard, I think you also need to provide at least a TEP draft along with your reference implementation.

Some other problems with your implementation:

the jetton wallet code (at least the core of it) is pretty much unchanged from the original version - its just that balance is now called shares, and is now stored as a uint256 instead of coins (which is wasteful), but the concept is pretty much the same - this would just make a contract incompatible with the previous jetton standard and is unnecessary here
the op_getter_balance in your jetton wallet is just a bad practice - something like this does not exist in the original wallet for a reason, and this reason is stated here - when the getter return message arrives, the data may be outdated already

All in all, the core idea is good, but I think a TEP and a better implementation is required.

Gusarich commented 10 months ago

This standard will be useful for some projects for sure. Mostly because the rebase mechanic doesn't work correctly with any of the wallet applications at the moment. I'd really like to help with it (without taking anything from the reward part). @IgorErkin can you please contact me in Telegram?

@delovoyhomie we can approve it and set the reward to 2k$. This is quite a simple task to be honest, just takes a lot of time to finalise.

IgorErkin commented 10 months ago

This standard will be useful for some projects for sure. Mostly because the rebase mechanic doesn't work correctly with any of the wallet applications at the moment. I'd really like to help with it (without taking anything from the reward part). @IgorErkin can you please contact me in Telegram?

@delovoyhomie we can approve it and set the reward to 2k$. This is quite a simple task to be honest, just takes a lot of time to finalise.

Sure, I will reach out to you today. Regarding the reward, ok, let's set it to 2k$. I have udpated the task description

IgorErkin commented 10 months ago

@krigga, thanks for your feedback!

It is my understanding that rebase tokens are mostly meant to be used when the underlying asset is not owned by the rebase token issuer - that is, the rebase token issuer cannot just mint the underlying asset on a whim, it must come from somewhere. The current proposed implementation seems to assume that the underlying asset is owned by the rebase token issuer - the mint operation increases both the normal supply and the shares supply.

If we consider an example of a project with collateral, then for it we must deploy the Rebase-Jetton-minter contract, after which we must transfer admin rights to the managing Vault contract, which will be responsible for managing the collateral. That is, the Vault contract will be the owner of the underlying asset.

Accordingly, when the Vault contract receives (op_transfer_notification 0x7362d09c) the underlying asset, it sends a transaction to mint shares in accordance with the amount of the underlying asset received from the user. This can be schematically represented as follows:

The Vault contract will manage the underlying asset, for example, by distributing it to yield-generating projects. The amount of the underlying asset from these investments may change over time. The Vault must reflect this in the total_supply variable by sending a message to the Rebase-Jetton-minter with the op code op_change_supply. We will add this op code and the corresponding handling to the Rebase-Jetton-minter to the standard level. Perhaps its absence caused misunderstanding.

When a user burns a rebase jetton, his share of the underlying asset will be sent to him:

It seems that a more useful approach would be a system that allows locking up some jetton's balance on the main rebase token contract, and it would then issue shares as new jettons which can be transferred to other users or burned to retrieve the underlying asset. The jetton wallet code wouldn't even need to be changed from the reference implementation of TEP74 - only the minter needs to be changed to support this locking and unlocking (burning) operation. To facilitate the display of the underlying asset's balances in UIs, a get method would just need to be added to the minter - something along the lines of (slice underlying_asset, int underlying_balance) get_rebase_data() - then the UIs that support this standard would have enough data to calculate the balance to be displayed.

You are right, most projects based on rebasing mechanics do use collateral. However, there are projects, such as algorithmic stablecoins (e.g. AMPL), that have no collateral. In general, we cannot assume what the rebasing mechanism will be for each specific project (some mechanics may be not even invented yet), so we proposed a generic standard that does not restrict projects mechanics in any way.

The solution you are proposing is a tokenized vault. There is a similar solution in Ethereum, the ERC-4626 standard. We can indeed follow this way, but it will not be a generic standard for all rebasing projects, as this approach limits the set of all projects to a subset of yield-bearing tokens.

The tokenized vault standard is useful, and it is probably worth implementing it in TON as well, but we propose doing it separately. Such a tokenized vault should be able to work with both Rebase-Jetton and regular Jetton. That is, we need a tokenized Vault standard that will also allow locking up some jetton's balance on the main Vault contract, and issuing in return either Rebase-Jetton or regular Jetton, depending on whether the developers want to implement a rebase or non-rebase yield-bearing token.

the jetton wallet code (at least the core of it) is pretty much unchanged from the original version - its just that balance is now called shares, and is now stored as a uint256 instead of coins (which is wasteful), but the concept is pretty much the same - this would just make a contract incompatible with the previous jetton standard and is unnecessary here

You are right about the incompatibility, it is important. We added increased precision to shares for the reason described in this article: https://docs.openzeppelin.com/contracts/4.x/erc4626. If shares and balance have the same precision, this opens up an attack vector. In the example with Vault, during minting, due to rounding, a situation may arise where the user sends the underlying asset, but does not receive shares in return. To solve this problem, as many shares as possible should correspond to one unit of balance. To improve resource usage, we can use VarUInteger 32 instead of uint256, although this will not affect compatibility.

the op_getter_balance in your jetton wallet is just a bad practice - something like this does not exist in the original wallet for a reason, and this reason is stated here - when the getter return message arrives, the data may be outdated already

I agree, this is the most controversial part. We will better remove it.