QuantAMM

Summary

The UpliftOnlyExample contract incorrectly uses block.number for timestamp tracking on Arbitrum, where it returns the L1 Ethereum block number instead of the L2 block number. This causes inaccurate timing records since Arbitrum produces blocks 3-5 times per second compared to Ethereum's 12-second intervals per block.

Vulnerability Details

In the afterUpdate function of UpliftOnlyExample.sol, the contract stores block numbers for tracking deposit timing:

The issue arises because:

1. On Arbitrum, block.number returns the L1 Ethereum block number

2. Multiple L2 transactions can occur within a single L1 block

3. This means different deposits at different L2 times could be recorded with the same L1 block number

4. Example timeline:

   • User A deposits at t=0 (L2 block 1000, L1 block 100)

   • User B deposits at t=5 seconds (L2 block 1015, L1 block 100)

   • Both deposits record block 100 despite occurring 5 seconds apart

This breaks the contract's timing assumptions since:

• Ethereum produces blocks every 12 seconds

• Arbitrum produces blocks every 0.2-0.33 seconds (3-5 per second)

Impact

Unlike all the other chains Quant on Arbitrum will have an Inability to accurately read state, impacting any logic that will be using information related to the ordering/amount of participation (time base) of the LP's

Tools Used

Manual Review

Recommendations

Replace block.number with Arbitrum's native block number tracking:

This ensures accurate temporal tracking of deposits regardless of what chain it is on.