Core Contracts

## Summary

The StabilityPool contract suffers from a reward dilution issue, where new users who deposit their assets into the pool receive the same RAAC rewards as those who have been staking from the beginning. Since RAAC rewards are calculated using the formula totalRewards * userAsset / totalAsset, when new users deposit into the pool, the rewards for existing users are diluted. This results in unfair reward distribution, where early stakers are not appropriately compensated for their longer participation, while new users who deposit later receive the same reward share.

## Vulnerability Details

• Issue:
  RAAC rewards in the StabilityPool are distributed based solely on the proportion of a user’s deposit to the total pool's assets. This leads to dilution of rewards for early participants when new users deposit into the pool. Both new and early users receive the same rewards, but the new users are only staking for a short time, thus unfairly reducing the rewards of long-term participants.

  • Affected Code:

    return (totalRewards * userDeposit) / totalDeposits;

    This formula distributes RAAC rewards to users based on their deposit share relative to the total deposits. However, it doesn’t consider the staking duration, meaning users who have been staking from the beginning are treated the same as new users, leading to reward dilution.

• This issue already addressed by rareskill this blog post, which mention user shd get rewards based on when they staked.

  -> https://www.rareskills.io/post/staking-algorithm

## Impact

• Unfair Reward Distribution:
  Early users, who have staked for a longer period, are receiving the same RAAC rewards as new users, despite their greater contribution to the pool over time. The reward system does not properly account for the duration of the staking, leading to unfair dilution.

• Incentive Problems for Early Stakers:
  As the pool grows and new users participate, the RAAC rewards for long-term participants become diluted, reducing their incentive to remain staked and participate in the pool.

• Reward Inefficiency:
  New participants are rewarded as if they had been staking from the pool’s inception, which leads to an inefficient allocation of rewards, where long-term stakers are unfairly disadvantaged.

## Tools Used

• Manual Code Review

## Recommendations

1. Implement Time-Weighted RAAC Reward Calculation:
   Modify the RAAC reward distribution formula to account for the time a user has been staking in the pool. Early stakers should receive a larger portion of the rewards than late stakers.

   Example adjustment for time-weighted rewards:

   uint256 userStakingTime = block.timestamp - userStakingStartTimestamp[user];

   uint256 totalStakingTime = block.timestamp - poolStartTimestamp;

   ​

   uint256 weightedUserDeposit = userDeposit * userStakingTime;

   uint256 weightedTotalDeposits = totalDeposits * totalStakingTime;

   return (totalRewards * weightedUserDeposit) / weightedTotalDeposits;

2. Track User Staking Duration:
   Add a timestamp to track when each user first deposits into the pool. This will allow the calculation of rewards to reflect both the amount of assets deposited and the length of time they have been staked.

   Example for tracking user staking:

   mapping(address => uint256) public userStakingStartTimestamp;

   ​

   function deposit(uint256 amount) external {

   if (userStakingStartTimestamp[msg.sender] == 0) {

   userStakingStartTimestamp[msg.sender] = block.timestamp; // Set staking start time for new user

   }

   // Continue with deposit logic...

   }

3. Ensure RAAC Reward Fairness:
   Periodically adjust the RAAC reward distribution mechanism to ensure that rewards are proportional not only to the amount of assets but also to the time a user has been part of the pool, preserving fairness for early stakers.