Proposal: Adjusted Staking Rewards Distribution in Cosmos SDK

[anilcse]

Proposal: Adjusted Staking Rewards Distribution in Cosmos SDK

1. Introduction

This specification proposes an enhancement to the Cosmos SDK's distribution module to adjust the distribution of staking rewards based on the proportion of locked (vesting) and unlocked tokens. The goal is to align incentives by rewarding stakers who contribute more liquidity (through unlocked tokens) with a higher proportion of staking rewards, while still allowing locked token holders to participate in securing the network.

2. Background and Rationale

2.1 Current Staking Rewards Mechanism

In the current Cosmos SDK implementation, staking rewards are distributed equally among all stakers based on their total staked tokens, without differentiating between locked (vesting) and unlocked tokens.

2.2 Issues with the Current Mechanism

• Liquidity Risk: Stakers who stake unlocked tokens take on higher liquidity risk compared to those staking locked tokens, as unlocked tokens could otherwise be freely transferred or sold.
• Incentive Misalignment: Equal reward distribution does not adequately compensate stakers who contribute more liquid capital to the network.

2.3 Proposed Solution

Introduce a Locked Token Reward Weight parameter (hereafter referred to as VestingRewardMultiplier), which adjusts the staking rewards allocated to locked tokens. This multiplier ranges from 0 to 1:

• 1: Locked tokens receive rewards equally to unlocked tokens.
• 0.3: Locked tokens receive 30% of the rewards they would receive if treated equally.
• 0: Locked tokens receive no rewards.

3. Specification

3.1 Definitions

• Unlocked Tokens: Tokens that are fully vested and can be freely transferred or unbonded by the staker.
• Locked (Vesting) Tokens: Tokens that are subject to a vesting schedule and cannot be freely transferred or unbonded until they are vested.
• VestingRewardMultiplier (VRM): A parameter between 0 and 1 that adjusts the reward weight of locked tokens.

3.2 Parameters

• VestingRewardMultiplier (VRM): A global parameter configurable via governance.
  • Type: decimal (range 0.0 to 1.0)
  • Default Value: 1.0 (to maintain current behavior unless changed)

3.3 Effective Stake Calculation

For each staker, calculate their Effective Stake as follows:

Effective Stake=Unlocked Tokens Staked+(Locked Tokens Staked×VRM)

3.4 Total Effective Stake

Sum the Effective Stakes of all stakers to obtain the Total Effective Stake:

Where NNN is the total number of stakers.

3.5 Reward Distribution

4. Examples

4.1 Example Scenario

Assume:

• VRM: 0.3
• Total Rewards: 300 ATOMs

Stakers:

1. User A

   • Unlocked Tokens Staked: 500 ATOMs
   • Locked Tokens Staked: 500 ATOMs

2. User B

   • Unlocked Tokens Staked: 1000 ATOMs
   • Locked Tokens Staked: 0 ATOMs

3. User C

   • Unlocked Tokens Staked: 0 ATOMs
   • Locked Tokens Staked: 1000 ATOMs

5. Considerations

5.1 Security

• Fairness: Ensure that the adjustment mechanism is fair and cannot be exploited.
• Manipulation Risks: Prevent stakers from gaming the system by artificially adjusting their locked and unlocked token balances.

5.2 Performance

• Computational Overhead: Additional calculations may introduce performance overhead. Optimize the implementation to minimize impact.

5.3 Backward Compatibility

• Default Behavior: Setting VRM to 1.0 maintains current reward distribution behavior.
• Migration: Ensure a smooth migration path for existing delegations when upgrading.

5.4 User Experience

• Transparency: Provide clear information to stakers about how rewards are calculated.
• Tooling: Update wallets and explorers to display Effective Stake and expected rewards.

6. Potential Impacts

6.1 Benefits

• Incentivizes Liquidity: Rewards stakers who contribute more liquid capital.
• Aligns Incentives: Adjusts rewards to reflect the liquidity risk borne by stakers.

6.2 Risks

• Staker Discontent: Locked token holders may feel disadvantaged.
• Complexity: Increased complexity in the reward distribution mechanism.

6.3 Mitigations

• Gradual Adjustment: Start with a VRM close to 1.0 and adjust gradually.
• Communication: Clearly communicate the rationale and benefits to all stakeholders.

7. Alternatives

• No Change: Maintain the current reward distribution mechanism.
• Different Adjustment Mechanism: Use a nonlinear scaling factor or tiers instead of a linear multiplier.
• Separate Reward Pools: Create distinct reward pools for locked and unlocked tokens.

8. Conclusion

Implementing the VestingRewardMultiplier in the Cosmos SDK allows for a more nuanced and fair distribution of staking rewards. By accounting for the liquidity risk associated with unlocked tokens, the network can better align incentives and promote a healthier staking ecosystem.

Author: @anilcse
Date: Oct 1, 2024

[zmanian]

Given the way the distribution module works right now, this seems like a complex implementation

Distribution mints a target number of coins.

Distributed them in pools prorata to the validator per block and then computes the necessary token distribution on a per delegator basis when the delegator withdraws rewards.

To implement the proposal distribution would need to track two pools.

1. Locked staked tokens and unlocked staked tokens.

And then mint correctly

[anilcse]

I think we can find a workaround for this by basing the rewards on reward_shares (i.e., effective_stake). It requires users to re-compute these shares on every vesting release but that shouldn't be a big concern as authz bot can do this for them

[anilcse]

On every delegate transaction, this reward_shares of the user will be computed based on the vestings and updated.

[robert-zaremba]

Maybe this will work: create a synthetic tokens, and rewards from that account will be distributed pro-rata to liquid stakers.

[robert-zaremba]

Other problems is with governance.

[anilcse]

What is the issue with governance for this case?

[robert-zaremba]

I like the idea, but I think investors won't like it.

[anilcse]

It's an option for product teams. This allows configuration.

[anilcse]

We have some working code for this, code changes are not that huge: vitwit#4
@zmanian would love your opinion on this, we would be happy to upstream it if its adding value