Core Contracts
Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View all submissions
Previous Next
Submission Details
Severity: high
Valid

Flawed Reward Distribution (calculateRaacRewards)

Author Revealed upon completion

Summary

The calculateRaacRewards function in the StabilityPool contract is vulnerable to front-running attacks and reward manipulation. A malicious user can strategically deposit funds right before reward distribution to receive an unfairly high share of the rewards. This issue results in an uneven distribution of rewards and significantly reduces incentives for honest participants.

Vulnerability Details

function calculateRaacRewards(address user) public view returns (uint256) {
uint256 userDeposit = userDeposits[user];
uint256 totalDeposits = deToken.totalSupply();
​
uint256 totalRewards = raacToken.balanceOf(address(this));
if (totalDeposits < 1e6) return 0;
​
return (totalRewards * userDeposit) / totalDeposits;
}

The rewards are distributed based on the user's deposit ratio at the time of calculation, without considering when the deposit was made. This allows a last-minute depositor to manipulate the reward distribution.

Attack Scenario

Victim deposits early with 100 tokens.

Owner funds rewards pool with 500 tokens.

Attacker front-runs and deposits 900 tokens right before rewards are calculated.

Reward distribution occurs, and the attacker receives 90% of the rewards while the victim gets only 10%, despite the victim staking for a longer period.

Impact

The impacts of this vulnerability are already outlined in the Impact section of the report. However, I can expand on them further:

Economic Exploitation

Attackers can extract disproportionate rewards by depositing large amounts at the last moment.

The protocol's reward distribution becomes skewed, making the system unfair.

Loss of User Trust

Honest stakers who deposit early receive fewer rewards, discouraging participation.

Users may abandon the protocol if they realize the system is easily exploitable.

Depletion of Reward Pool

Repeated execution of the exploit can drain the reward pool prematurely.

Honest users may never receive their fair share of rewards.

Market Manipulation Risks

Attackers can coordinate deposits to manipulate reward distribution.

May encourage MEV (Miner Extractable Value) attacks where validators prioritize their own transactions to maximize gains.

Tools Used

Recommendations

Solution 1: Time-Weighted Rewards

Adjust the reward formula to factor in how long a user has staked:

function calculateRaacRewards(address user) public view returns (uint256) {
uint256 timeWeightedShare = (deposits[user] * (block.timestamp - depositTime[user])) / totalDeposits;
return (rewardPool * timeWeightedShare) / totalDepositTimeWeight;
}

Solution 2: Reward Snapshots

Take a snapshot of deposits before rewards are added, ensuring only existing deposits get rewarded.

Solution 3: Lockup Periods

Require users to stake for a minimum duration before earning rewards, preventing last-minute deposits.

Updates

Lead Judging Commences

inallhonesty Lead Judge 8 days ago
Submission Judgement Published
Validated
Assigned finding tags:

StabilityPool::calculateRaacRewards is vulnerable to just in time deposits

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.