-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[Token-2022] [Feature] Rebasing tokens extension. #6201
Comments
Some of what you're describing can be done by the In order to introduce changes that actually increase or decrease the token balance, you'd need a few particularly tricky pieces, the most relevant of which is some sort of crank to automatically update account state periodically. This is most likely why the engineering decision was made for the I don't believe you'll have an easy time trying to convince contributors to add such an instruction to Token-2022. I would encourage you to instead think of how Token-2022 can be composed with a protocol of your own implementation that can accomplish your goals. For example, perhaps you create token accounts where some protocol-owned account (likely a PDA) is the delegate. Then the delegate can be used to authorize transfers in and out of users' token accounts on their behalf. You can trigger this action via crank (or some other trigger, up to you) hitting your program's instruction, which can then CPI to Token-2022 (ie. I would ensure your users are explicitly aware of this delegate situation if that's the road you decide to go down. |
Hey @buffalojoec I see your point. I considered the interest bearing mechanism but using this would require to update all the users balances (i.e burn/ mint) whenever the interest accrues. This isn't feasible and not the right approach since you'll need to update accounts for all the users who hold your token. Rather a better approach will be adjust the shares and all the balances for the users will then updated accordingly without the need for updating every individual users account. Do you get my point? Also in the use case where you want to give interest to the token holders who don't use your protocol, you would need to rather run the program to update their accounts individually whenever the token accrues interest. Considering those people as well a better approach will be for their accounts to get adjusted when the shares gets updated. The balance of the users token gets automatically reflected since it shows how much share you earn from the Also adding a delegate for such a use case in my opinion isn't a great option too cuz then the trust will be minimum for the users of the token too in many cases. |
@faheelsattar why not just manage the shares portion of this within your program? The shares don't have to be tracked by Token2022 in your explanation. |
Managing the shares specifically in token 2022 program is the requirement which will make this use case worth while.
If we manage the shares in the protocol we would then need to update accounts for each token holders (also includes users who don't use the protocol) which isn't feasible. I believe share management in the token 2022 program will then easily solve the issue as the users token account balance will merely show the shares of that particular user from the total shares |
Could you maybe explain how your proposed changes to Token-2022 would work? What would be the new required extensions for Mints and Accounts? How would share management work? And how does managing shares within Token-2022, as compared with some other custom protocol, specifically prevent updating account state? |
Problem
Implement a yield bearing token which rebases and the users balance increases and decreases based of on their token shares. Similarly how lido finances steth work where each users balance gets adjusted without actually needing to transfer any tokens
https://github.com/lidofinance/lido-dao/blob/master/contracts/0.4.24/StETH.sol
Thoughts
I believe certain changes are required in order to standardise this for example Mint, balance of token, total shares, individual share of each users are to be tracked. This will allow anyone to create a token which will easily start rebasing and provides a neat use case for primitives to be built on top of it.
Willing to provide more feedback and answer any questions
The text was updated successfully, but these errors were encountered: