QuantAMM

Summary

The contract inconsistently records timing information, using block.timestamp for initial deposits but block.number for transfers, which could lead to incorrect timing-based logic.

Vulnerability Details

In addLiquidityProportional, the contract records the deposit time using block.timestamp:

However, in afterUpdate during transfers, it uses block.number:

This inconsistency creates two issues:

• Data corruption: The same field stores different types of values (timestamps vs block numbers)

• Semantic confusion: The variable name suggests timestamp but sometimes contains block number

While this timing information isn't currently used for critical calculations in the contract, it creates a confusing state that could lead to bugs if timing logic is added in future updates.

Impact

Low- While not immediately exploitable, this inconsistency corrupts timing data and could lead to issues if timing-based features are added. The inconsistency also makes it impossible to reliably track how long positions have been held.

Tools Used

Manual Review

Recommendations

Be consistent with timing information. Choose either block numbers or timestamps