Lines of code
<https://github.com/code-423n4/2023-03-neotokyo/blob/dfa5887062e47e2d0c801ef33062d44c09f6f36e/contracts/staking/NeoTokyoStaker.sol#L1331-L1332&gt;
<https://github.com/code-423n4/2023-03-neotokyo/blob/dfa5887062e47e2d0c801ef33062d44c09f6f36e/contracts/staking/NeoTokyoStaker.sol#L1342-L1343&gt;
<https://github.com/code-423n4/2023-03-neotokyo/blob/dfa5887062e47e2d0c801ef33062d44c09f6f36e/contracts/staking/NeoTokyoStaker.sol#L1355-L1357&gt;

Vulnerability details

Impact

Huge over calculating user rewards
When user claim rewards for the first time rewards over calculated

Proof of Concept

getPoolReward function uses ‘‘uint256 timeSinceReward = block.timestamp - lastRewardTime’’ formula to calculate period of time that rewards should apply for , but when a user stake some token for example some lp token and stake function doesn’t set any value for lastRewardTime so it has zero value by default , this causes lastRewardTime in the above formula have zero value when claimReward function get called for the first time so timeSinceReward will be equal to block.timestamp and this lead rewards calculated such that she/he has staked as long as block.timestamp .

Scenario :
1- user stake some lp token .
2- user calls getReward in BYTES2 contract ( which calls claimReward in NeoTokyoStaker ) in the same transaction.
3- now huge amount of bytes2 token will be minted as reward for user due that no time passed from staking

Tools Used

Manual Review

Recommended Mitigation Steps

Set lastRewardTime to block.timestamp in stake function .

The text was updated successfully, but these errors were encountered:

All reactions