Feature Proposal: ClaimableYield Extension

[tonton-sol]

Proposed Feature

Introduce a ClaimableYield extension to the SPL Token-2022 program that enables yield-bearing tokens where holders can claim accumulated yield as newly minted tokens. Unlike rebasing models that continuously adjust balances, this extension keeps balances stable until users explicitly claim their yield.

Key properties:

• Automatic yield tracking during standard token operations
• Manual claiming of accumulated yield into spendable balance
• Global yield index updated by an authority, applied uniformly across accounts when claiming
• Local indices per account to track individual accrual
• Fully compatible with standard SPL Token instructions (transfer, mint, burn)

Full technical documentation is provided here as a GitHub gist.

---

Why Is This Needed

Current SPL Token yield approaches each come with shortcomings:

• Exchange-Rate Based Tokens : Balances stay fixed; yield accrues via an increasing exchange rate (from staking rewards or borrower interest). Composable and common, but yield is implicit (not visible in balances) and requires reading the exchange rate.
• Token-2022 Scaled UI / Interest Extensions: On-chain mint extension applies a multiplier to displayed balances; raw amounts and supply don’t change. Mechanically sound and composable, but cosmetic only — no new tokens are minted, and in non-extension-aware contexts the “yield” is invisible.
• Internal Accounting / Claimable Rewards: Protocols track deposits and credit pending yield internally, which users later claim. This works but yield is siloed inside the protocol and not composable outside of it.

The ClaimableYield extension solves these problems by combining the strengths of both approaches without their weaknesses. Balances remain predictable for programs (like exchange-rate tokens), but yield is real — minted when claimed, not just cosmetic. Users explicitly control when to realize it, ensuring transparency and portability across all SPL-aware contexts.

---

Proposed Solution

The solution introduces two extensions:

• ClaimableYieldConfig (mint extension)
• ClaimableYieldAccount (account extension)

And four new instructions:

• InitializeMint: Set up ClaimableYield on a mint with authority and initial index.
• UpdateIndex: Authority-controlled index update for distributing yield (monotonic only).
• ConfigureAccount: Opt-in extension for accounts to track yield accrual.
• ClaimYield: Hard claim accumulated yield, minting new tokens into spendable balance.

Integration with Standard Instructions

These instructions integrate with SPL Token operations:

• Transfer/Mint/Burn trigger soft claims to update pending yield and indices.
• ClaimYield converts pending + accrued yield into spendable tokens.

Math & Safety

• 9-decimal fixed-point arithmetic for precision.
• u128 intermediates used to prevent overflow.
• Truncation always rounds down to protect protocol integrity.
• Global index is monotonic to prevent negative yield or manipulation.

---

Other Considerations

• Authority model: Index authority can only increase the yield index; it cannot decrease it or access user funds.
• Composability: Fully compatible with transfer fees; yield accrues before fee deductions.
• Precision: Minimum thresholds are documented so small accounts understand truncation limits.
• Security: Overflow checks, atomic updates, and immutable local index progression.
• Compatibility: Not yet compatible with ConfidentialTransfer or ConfidentialMintBurn (will be added).

---

References

• Full documentation (GitHub Gist)
• Implementation (Token-2022 repo fork)

[Oighty]

I think this is an interesting approach to creating yield-bearing assets. It addresses some of the UX complications with the rebasing token extensions (IBT, ScaledUiAmount) and simplifies integrating with yield-bearing assets in DeFi programs.

[buffalojoec]

Thanks for the writeup!!

I think your implementation is sound and mechanically it works, but I'm not really convinced as to the why behind enshrining one interest-bearing solution in SPL-Token. To me, distributed means of tracking, updating, and distributing interest is a feature not a bug. This gives protocols complete control and lets the market decide which standard works best.

Furthermore, supporting one mechanism in SPL-Token can create a situation where other methods of interest-bearing tokens and custom extended functionality become demanded for inclusion as well.

That being said, I will admit I know that this mechanism as a primitive has been used in many places, and it's typically reimplemented, so maybe there's a case to be made for enshrining the primitive, but it needs to be fleshed out, in my opinion.

• Internal Accounting / Claimable Rewards: Protocols track deposits and credit pending yield internally, which users later claim. This works but yield is siloed inside the protocol and not composable outside of it.

I agree that this is siloed but can you elaborate on why this needs to be un-siloed? Why does it matter which program you have to claim through?

From the linked Gist:

Authority controlled yield: A designated authority updates the global yield index to distribute yield

Doesn't this enshrine only one way to do the yield management? What if someone wants to do an oracle-based yield update? They would need to stand up a program anyway, in order to manage this through the authority/instruction.

Always increases or stays constant (never decreases)

As a side note: it's feasible with the suggested design to leverage burn in the same way you're leveraging mint to have a deflationary token.

[tonton-sol]

I'm not really convinced as to the why behind enshrining one interest-bearing solution in SPL-Token.

I am not sure what you mean here. I do not believe this extension should replace other extension that distribute yield (IBT and scaledUI). Its only an option in the same way users can choose all existing mechanics.

To me, distributed means of tracking, updating, and distributing interest is a feature not a bug. This gives protocols complete control and lets the market decide which standard works best.

Without enshrining some change to the transfer/mint/burn ix there is no way to verifiably track yield onchain. This is because you cannot enforce the updating of some state upon mint and burn. You could do the transfer portion with a transfer-hook, but there are no corresponding mint/burn-hooks.

I agree that this is siloed but can you elaborate on why this needs to be un-siloed? Why does it matter which program you have to claim through?

The issue here is not that it is specifically siloed, but that the tracking cannot be done onchain and would require an offchain component for tracking mint/burn events.

Doesn't this enshrine only one way to do the yield management? What if someone wants to do an oracle-based yield update? They would need to stand up a program anyway, in order to manage this through the authority/instruction.

The extension would only handle the yield distribution, it is agnostic to how the yield is calculated and when it is distributed.

As a side note: it's feasible with the suggested design to leverage burn in the same way you're leveraging mint to have a deflationary token.

I disagree. This is not possible under the current design because the Claim ix requires the owners signature.

[buffalojoec]

The issue here is not that it is specifically siloed, but that the tracking cannot be done onchain and would require an offchain component for tracking mint/burn events.

The mechanism you've proposed in the Gist is how many on-chain protocols already implement interest-bearing tokens, and you definitely can track it on-chain.

I'm not really convinced as to the why behind enshrining one interest-bearing solution in SPL-Token.

I am not sure what you mean here. I do not believe this extension should replace other extension that distribute yield (IBT and scaledUI). Its only an option in the same way users can choose all existing mechanics.

Sorry, I'm not talking about the other extensions offered by Token-2022. I'm talking about anyone who implements an interest-bearing token of any kind in their own protocols. This mechanism is very common, but there are other, more complex implementations that exist as well.

I'm not opposed to the feature itself, I'm basically trying to flesh out why this is better in SPL-Token-2022 instead of native to each protocol that does interest-bearing tokens. In my own opinion on this, I don't really see the issue with each on-chain protocol tracking rate/index, last_rate/last_index, and pending_rewards on their own.