QuantAMM

Summary

Every instance of blockTimestampDeposit and really any storage of time is done in uint40. Except for one instance in the afterUpdate function. In this function the value is casted to uint32. This will result in the max value being exceed 99.6% sooner then it should be.

Vulnerability Details

The afterUpdate function is used to update the state of the LP position after a transfer occurs. This includes updating the deposit value the deposit time and the uplift fee. However, The deposit time is casted to uint32 where as every other instance of time being casted is in uint40.

After Updater
feeDataArray[tokenIdIndex].blockTimestampDeposit = uint32(block.number);

addLiquidityProportional
blockTimestampDeposit: uint40(block.timestamp),

The issue with this is that there is a 99.6% change between the two max values which means that what was once a nearly impossible unrealistic time to hit with uint40. Is now achievable in roughly 81 years. as opposed to the 34810 years that it would take with uint40.

Now it has been made very clear that known use of timestamp caveats are known as per the known issues and nat-spec

However, because this is documented right above a casting of uint40 And every other instance is casted in uint40. It seems safe to assume they are aware of timestamp issues and are willing to accept the risk of uint40. However, the use of uint32 does not appear to be intentional and given that uint40 was the maximum acceptable risk everywhere else in the protocol it is safe to assume that anything less is not an acceptable risk especially when that amount less is by a percentage of 99.6%.

So while timestamp issues are known the current incorrect implementation of using uint32 is not known given the state of the rest of the protocol.

I also see that block.number is used instead of block.timestamp. This as shown in one of my other issues is a mistake and should be timestamp as that is what the variable is named after and initially set to. However, the uint32 issue in the context of the current code (using block.number) is even worse since chains like Arbitrum produce just shy of 4 blocks per second on average. A uint32 used to cast block.number on arbitrum would reach and exceeded the max in roughly 31 years ((2^32 - 293177972)/4)/60/60/24/365

This is low likelihood but in terms of validity this is a in scope issue. That is outside of the known issue section, not by much but it is.

Impact

Incorrect casting will lead to incorrect time being stored in the future.

Tools Used

Manual Analysis

Recommendations

cast blockTimestampDeposit to uint40 as it is elsewhere.