Closed sherlock-admin closed 1 year ago
Escalate for 10 USDC
As I mentioned earlier, the block.number of Arbitrum can be different from the block.number of Ethereum. According to Arbitrum Docs block.number returns the most recently synced L1 block number. Once per minute the block number in the Sequencer is synced to the actual L1 block number. This means that the Blueberry protocol could calculate the rewards based on an incorrect block.number. This could lead to liquidity providers receiving less rewards than they are entitled to. It could also lead to liquidity providers receiving rewards that they are not entitled to.
Escalate for 10 USDC
As I mentioned earlier, the block.number of Arbitrum can be different from the block.number of Ethereum. According to Arbitrum Docs block.number returns the most recently synced L1 block number. Once per minute the block number in the Sequencer is synced to the actual L1 block number. This means that the Blueberry protocol could calculate the rewards based on an incorrect block.number. This could lead to liquidity providers receiving less rewards than they are entitled to. It could also lead to liquidity providers receiving rewards that they are not entitled to.
You've created a valid escalation for 10 USDC!
To remove the escalation from consideration: Delete your comment.
You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.
the issue is in MockIchiFarm.sol, which is not in scope of the auditing
MockIchiFarm
MockIchiFarm was in the scope
Escalation accepted
Invalid issue Accepting this escalation because the file was included in the scope of the readme. But issues found in mock contracts of an external protocol are not valid issues in any standard smart contract audit.
Escalation accepted
Invalid issue Accepting this escalation because the file was included in the scope of the readme. But issues found in mock contracts of an external protocol are not valid issues in any standard smart contract audit.
This issue's escalations have been accepted!
Contestants' payouts and scores will be updated according to the changes made on this issue.
0xepley
medium
updatePool() and add() will not work properly for Arbitrum due to block.number
Summary
As mentioned on the contest page of sherlock, that the project is going to deploy on both mainnet and arbitrum![image](https://user-images.githubusercontent.com/95472385/235302655-768ef7cb-47be-47a0-9bdb-5441ee7fb42d.png)
The
lastRewardBlock
variable in theadd()
is used to keep track of the last block number where the rewards were calculated. If theblock.number
is incorrect, it could result in inaccurate calculations. Therefore, it's important to ensure that theblock.number
is accurate before using it in this function.Vulnerability Detail
In the
add()
function ofMockIchiFarm.sol
block.number
is being used which will not work properly on arbitrum. And same is the issue withupdatePool()
functionupdatePool() function
Impact
Code Snippet
https://github.com/sherlock-audit/2023-04-blueberry/blob/96eb1829571dc46e1a387985bd56989702c5e1dc/blueberry-core/contracts/mock/MockIchiFarm.sol#L139
https://github.com/sherlock-audit/2023-04-blueberry/blob/96eb1829571dc46e1a387985bd56989702c5e1dc/blueberry-core/contracts/mock/MockIchiFarm.sol#L218
Tool used
Manual Review
Recommendation