Potential Exploit in setLumPerSecond Allowing Unfair Reward Spike Exploitation
Summary
The setLumPerSecond function in the contract allows the owner to adjust the LUM (reward token) distribution rate per second. However, this function does not immediately update all relevant pools, leading to potential reward spikes that can be exploited by users who time their staking and withdrawals to take advantage of these changes.
Vulnerability Detail
The primary issue lies in the fact that when lumPerSecond is changed, the function does not immediately update all pools to reflect the new reward rate. This creates a window of opportunity for users to exploit the system. Here is the sequence of events that could lead to exploitation:
Owner Changes lumPerSecond: The owner of the contract increases the lumPerSecond to a higher value.
Delayed Pool Update: The new rate is not immediately applied to all staking pools, leading to a temporary discrepancy in reward calculations.
User Exploits Timing: A savvy user, aware of the increase, stakes a significant amount of tokens just before the change and withdraws them immediately after the increase is applied, but before the pools are updated.
Unfair Reward Spike: Due to the increased lumPerSecond, the user receives a disproportionately high amount of rewards during the brief period of the discrepancy.
This loophole can be particularly damaging because it undermines the fairness of the reward distribution system and can lead to financial imbalances within the staking ecosystem.
Impact
Users can manipulate the timing of their staking and withdrawals to maximize rewards unfairly, leading to economic incentive distortion.
Alice Front-Runs the Change:
Alice stakes a large amount of tokens immediately before the lumPerSecond is increased from 10 to 100.
Admin Changes lumPerSecond:
The owner increases the lumPerSecond from 10 to 100.
Alice Withdraws:
After the update has taken effect and the higher reward rate is applied, Alice withdraws her staked tokens.
Due to the increased lumPerSecond, Alice receives a significantly higher amount of rewards than she would have if the pools were updated immediately.
By ensuring immediate updates to all pools and potentially introducing a time delay for withdrawals after changing lumPerSecond, the contract can prevent users from exploiting timing to receive disproportionate rewards. This will maintain the fairness and integrity of the rewards distribution system, ensuring all participants are rewarded equitably based on their stake and participation.
0xrobsol
High
Potential Exploit in setLumPerSecond Allowing Unfair Reward Spike Exploitation
Summary
The setLumPerSecond function in the contract allows the owner to adjust the LUM (reward token) distribution rate per second. However, this function does not immediately update all relevant pools, leading to potential reward spikes that can be exploited by users who time their staking and withdrawals to take advantage of these changes.
Vulnerability Detail
The primary issue lies in the fact that when lumPerSecond is changed, the function does not immediately update all pools to reflect the new reward rate. This creates a window of opportunity for users to exploit the system. Here is the sequence of events that could lead to exploitation:
Impact
Users can manipulate the timing of their staking and withdrawals to maximize rewards unfairly, leading to economic incentive distortion.
Code Snippet
https://github.com/sherlock-audit/2024-06-magicsea/blob/main/magicsea-staking/src/MasterchefV2.sol#L347-L360
Tool used
Manual Review
Recommendation
By ensuring immediate updates to all pools and potentially introducing a time delay for withdrawals after changing lumPerSecond, the contract can prevent users from exploiting timing to receive disproportionate rewards. This will maintain the fairness and integrity of the rewards distribution system, ensuring all participants are rewarded equitably based on their stake and participation.
Duplicate of #177