Staking::claimRewards() fails to correctly compute the amount of staking rewards a user should get.
The vulnerability can be identified in the fact that the contract only tracks the last claim time (lastClaim) and computes the rewards based on the current staking balance (userStakes).
Anyone can call Staking::deposit() just before claming the rewards so that their userStakes is higher, meaning that they will receive more rewards.
Anyone can claim more tokens than normal by depositing before withdrawing.
Add the following unit test to StakingTest.t.sol:
In the example above the user initially deposits 100 tokens. Normally, after 10 weeks, he sould be able to claim 1000 but, before claiming, he deposits 100 token more. This causes Staking::claimRewards() to calculate the rewards on 200 tokens of initial deposit (even if only half of them actually stayed in the contract for 10 weeks) and he's able to claim 2000 tokens.
Add another mapping that tracks the amount of claimable rewards for each user and use this mapping to correctly calculate the amount of staking rewards.
With the following precautions:
Soulmate::ownerToId() should revert if 0 is returned because we want to avoid non-minters to be able to use the staking contract functions
Staking::deposit() should update both the amount of claimable rewards and lastClaim BEFORE updating the userStakes mapping
Staking::deposit() should update both the amount of claimable rewards and lastClaim BEFORE updating the userStakes mapping
High severity, this allows users to claim additional rewards without committing to intended weekly staking period via multi-deposit/deposit right before claiming rewards.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.