Malicious user can manipulate reward calculations, preventing other users from receiving the correct amount of rewards
Summary
Malicious user can manipulate reward calculations, preventing other users from receiving the correct amount of rewards.
Vulnerability Detail
A malicious user can exploit the claim function to repeatedly update the _lastUpdateTimestamp.
This manipulation affects the _calculateRewards function, which uses the _lastUpdateTimestamp to determine the rewards.
When another user tries to vote and deposit, the rewards calculation will be based on a much shorter duration than expected, significantly reducing the rewards they receive.
Example scenario:
Malicious user participates in period 1. Let's say that this period lasts 10 days.
Period 2 starts, user1 claims his rewards with claim and by doing that he sets the _lastUpdateTimestamp to the beginning of period2. Let's say that period 2 lasts from 10th to the 20th day so again 10 days.
On the day15 i.e day 5 of period2, a user deposits.
Because of the way the rewards are calculated in _calculateRewards he should receive rewards for 5 days:
where block.timestamp is not > than endTime since period 2 is still going. so timestamp = block.timestamp
In the 2nd condition:
timestamp > lastUpdatedTimestamp is true, then the rewards he should get is block.timestamp - lastUpdateTimestamp(currently beginning of the period2)) * emissions. So he should receive rewards for 5 days.
However, the malicious user can continuously claim rewards even if he doesn't have anything to claim, because that will update _lastUpdateTimestamp constantly.
Therefore, when the victim user claims, his reward will be calculated as block.timestamp - lastUpdateTimestamp and this will result in only a couple of seconds period for which he'll receive rewards.
Impact
Malicious user can manipulate reward calculations, preventing other users from receiving the correct amount of rewards.
Silvermist
High
Malicious user can manipulate reward calculations, preventing other users from receiving the correct amount of rewards
Summary
Malicious user can manipulate reward calculations, preventing other users from receiving the correct amount of rewards.
Vulnerability Detail
A malicious user can exploit the
claimfunction to repeatedly update the_lastUpdateTimestamp.This manipulation affects the
_calculateRewardsfunction, which uses the_lastUpdateTimestampto determine the rewards.When another user tries to vote and deposit, the rewards calculation will be based on a much shorter duration than expected, significantly reducing the rewards they receive.
Example scenario:
claimand by doing that he sets the_lastUpdateTimestampto the beginning of period2. Let's say that period 2 lasts from 10th to the 20th day so again 10 days.Because of the way the rewards are calculated in
_calculateRewardshe should receive rewards for 5 days:where block.timestamp is not > than endTime since period 2 is still going. so timestamp = block.timestamp
In the 2nd condition:
timestamp > lastUpdatedTimestampis true, then the rewards he should get isblock.timestamp - lastUpdateTimestamp(currently beginning of the period2)) * emissions. So he should receive rewards for 5 days.However, the malicious user can continuously claim rewards even if he doesn't have anything to claim, because that will update
_lastUpdateTimestampconstantly.Therefore, when the victim user claims, his reward will be calculated as
block.timestamp - lastUpdateTimestampand this will result in only a couple of seconds period for which he'll receive rewards.Impact
Malicious user can manipulate reward calculations, preventing other users from receiving the correct amount of rewards.
Code Snippet
https://github.com/sherlock-audit/2024-06-magicsea/blob/42e799446595c542eff9519353d3becc50cdba63/magicsea-staking/src/rewarders/BribeRewarder.sol#L300-L313
Tool used
Manual Review
Recomendation
Implement a mapping that stores the
_lastUpdateTimestampfor each user individually.Duplicate of #52