Submission Details
Severity:
Incorrect use of L1 `block.number` on L2s like Arbitrum
Summary
According to Arbitrum's documentation, block.number returns the approximate L1 block number at which the sequencer received the transaction instead of the current L2 block number.
Vulnerability Details
UpliftOnlyExample:
function afterUpdate(address _from, address _to, uint256 _tokenID) public {
<...>
if (tokenIdIndexFound) {
if (_to != address(0)) {
// Update the deposit value to the current value of the pool in base currency (e.g. USD) and the block index to the current block number
//vault.transferLPTokens(_from, _to, feeDataArray[i].amount);
feeDataArray[tokenIdIndex].lpTokenDepositValue = lpTokenDepositValueNow;
>> feeDataArray[tokenIdIndex].blockTimestampDeposit = uint32(block.number);
feeDataArray[tokenIdIndex].upliftFeeBps = upliftFeeBps;
Impact
Using of approximate L1 block number
Tools used
Manual Review
Recommendations
Consider using ArbSys(100).arbBlockNumber() to retrieve the L2 block number on Arbitrum to receive an accurate value.
Updates
Lead Judging Commences
n0kto 7 months ago
Submission Judgement Published Reason: Other
Assigned finding tags:
invalid_Arbitrum_block_number
The real bug is that blockTimestampDeposit should use “block.timestamp” and not number.
Prize pool breakdown
Total prize
49,600 OP
nSLOC
3,00017 OP / LOC
44,640
4,960
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.