Add proposal for interest bearing tokens #15927
Conversation
|
@joncinque sorry for butting-in. My comments are written in rather hurry. Please ask me if elaboration is needed. This proposal looks promising for the next-gen of spl-token. Thanks for the write-up. Ultimately, I want to create very flexible framework for these token juggling play. So that we can attract more advanced/specialized token/nft use cases, considering we can offer larger computational resource to txes for wildest token economics because of being high-performance blockchain by definition. :) |
|
@ryoqun thanks for all of your time and thoughtful comments! You gave me a lot to consider, especially your ABI idea. That might be a better way forward rather than adding all of the |
| TODO What's the best approach to implement this? For example, does an ephemeral | ||
| account even need a public key? |
There was a problem hiding this comment.
This is probably just a syscall, create_ephemeral_account(program_id, size), that returns an AccountInfo. No public key required, the lamport balance is 0 (and probably the instruction fails if the lamport balance is !0 when the current instruction exits).
Flesh out more details with @jackcmay though
There was a problem hiding this comment.
Yeah, that's what I had in mind, could add information about the granted ephemeral accounts to InvokeContext so we can track it between calls. Need to flesh out granting memory access to the program, etc...
Co-authored-by: Michael Vines <[email protected]>
stale
bot
added
the
stale
joncinque
removed
the
stale
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
stale
bot
added
the
stale
joncinque
removed
the
stale
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
stale
bot
added
the
stale
joncinque
removed
the
stale
| 1,000 tokens, the program converts and asks to move 8.33 shares. The same concept | ||
| applies to mints and burns. | ||
|
|
||
| Following this model, we never have to worry about compounding interest. We |
There was a problem hiding this comment.
Would the interest be compounded periodically by the runtime and stored as a number in the i-token? Or would it need to be computed every time by AmountToUiAmount and not stored?
There was a problem hiding this comment.
The runtime would not be involved at all for this, so it would need to be computed every time and not stored anywhere.
Co-authored-by: Vladimir Komendantskiy <[email protected]>
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
stale
bot
added
the
stale
joncinque
removed
the
stale
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
stale
bot
added
the
stale
joncinque
removed
the
stale
| ### Voting Tokens | ||
|
|
||
| Outlined in a [GitHub issue](https://github.com/solana-labs/solana-program-library/issues/131), | ||
| voting tokens use additional data about how long a token has been held. |
There was a problem hiding this comment.
The opposite logic would be to make it possible to lock tokens for certain amount of time to know for how long they would be held. This would allow to calculate voting power based on the long term commitment (skin in the game).
Users don't really like to deposit governance tokens to vote. It makes them very uncomfortable especially when the governance tokens they posses have substantial economic value.
A better solution would be to allow the tokens to be locked to gain voting power while still being in user's possession.
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
stale
bot
added
the
stale
joncinque
removed
the
stale
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
stale
bot
added
the
stale
joncinque
removed
the
stale
| To convert between amount and UI amount, the wrapper library calls the `AmountToUiAmount` | ||
| instruction on the i-token program, or for SPL token accounts, it calls | ||
| `spl_token::amount_to_ui_amount` inline. |
There was a problem hiding this comment.
just fyi, I leaned that wstETH (wrapper version of stETH) just exists for the distinction of value-accruing vs re-basing token differences to be used for separately depending on upper defi primitive's token accounting assumption: https://help.lido.fi/en/articles/5231836-what-is-wrapped-steth-wsteth
Also, I think we now have return data runtime mechanism. :)
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
stale
bot
added
the
stale
|
tip: there's eth equivalent to this: https://eips.ethereum.org/EIPS/eip-4626 |
Problem
We need interest bearing tokens on Solana
Summary of Changes
Following the CONTRIBUTING.md path, add a proposal for the solution so we can discuss it.
Fixes #