QuantAMM

Title

Wrong use of block.number to blockTimestampDeposit in Arbitrum network

Summary

The afterUpdate function in the UpliftOnlyExample contract uses block.number to update the blockTimestampDeposit field. While this approach works correctly on Ethereum's L1 network, Arbitrum operates differently.
In the Arbitrum network, block.number reflects the L1 block number, not the Arbitrum L2 block number. This discrepancy leads to incorrect data being stored in the blockTimestampDeposit field, impacting subsequent operations that rely on this value.

Vulnerability Details

The vulnerability lies in the following implementation of the afterUpdate function in the UpliftOnlyExample contract:

block.number Behavior in Arbitrum
On Arbitrum, block.number reflects the L1 block number, not the L2 block number. As a result, the blockTimestampDeposit field will store incorrect values when the contract is deployed on the Arbitrum network.

Impact on Time-Sensitive Calculations
This incorrect value can disrupt time-sensitive operations or calculations in the contract that depend on the accurate block index for the Arbitrum L2 network.

Impact

1. Inaccurate Record Keeping: The blockTimestampDeposit field stores incorrect values on Arbitrum, as block.number reflects the L1 block number instead of the L2 block number.

2. Disrupted Calculations: Time-sensitive operations, such as uplift fee calculations, may produce invalid results.

3. Reduced Interoperability: The contract behaves inconsistently across networks, affecting usability on L2s like Arbitrum.

Tools Used

Manual Review

Recommendations

Use Arbitrum's L2 Block Number API by replacing block.number with ArbSys(100).arbBlockNumber() in case of ARBITRUM network. It'll require additional conditional statements inside afterUpdate function.