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

[Token-2022] [Feature] Rebasing tokens extension. #6201

Open
faheelsattar opened this issue Jan 30, 2024 · 5 comments
Open

[Token-2022] [Feature] Rebasing tokens extension. #6201

faheelsattar opened this issue Jan 30, 2024 · 5 comments

Comments

@faheelsattar
Copy link

faheelsattar commented Jan 30, 2024

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

@buffalojoec
Copy link
Contributor

Some of what you're describing can be done by the InterestBearingConfig Mint extension. However, this extension is merely cosmetic. See the docs.

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 InterestBearingConfig to simply be a cosmetic calculator of sorts, where you can leverage the extension to automatically keep track of interest accrued at your designated rate, and then you can implement some action within your own protocol to manage the actual token balances.

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. transfer or burn). The amounts to move can perhaps be tracked by InterestBearingConfig.

I would ensure your users are explicitly aware of this delegate situation if that's the road you decide to go down.

@faheelsattar
Copy link
Author

faheelsattar commented Jan 30, 2024

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 totalShare.

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.

@buffalojoec
Copy link
Contributor

@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.

@faheelsattar
Copy link
Author

faheelsattar commented Jan 31, 2024

Managing the shares specifically in token 2022 program is the requirement which will make this use case worth while.

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.

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

@buffalojoec

@buffalojoec
Copy link
Contributor

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?

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

No branches or pull requests

2 participants