Wrong usage of block.number for blockTimestampDeposit in UpliftOnlyExample
Summary
In poolsFeeData within UpliftOnlyExample, the blockTimestampDeposit property is expected to store a timestamp, as indicated by its name and how values are assigned in the addLiquidityProportional() function. The problem is that during the transfer of an NFT from one user to another, the afterUpdate() function is called, where instead of a timestamp, the block.number is assigned.
Vulnerability Details
https://github.com/Cyfrin/2024-12-quantamm/blob/a775db4273eb36e7b4536c5b60207c9f17541b92/pkg/pool-hooks/contracts/hooks-quantamm/UpliftOnlyExample.sol#L610
Impact
It is not a problem in the current moment because the blockTimestampDeposit is not in use but it may become in future.
Tools Used
Manual review
Recommendations
Use consistently timestamp for blockTimestampDeposit.
Lead Judging Commences
finding_afterUpdate_blockNumber_instead_of_timestamp
Likelihood: Medium/High, any NFT transfer will change this variable. Impact: Informational/Very Low. This variable is unused and won’t impact anything, but the array is public and its getter will return a variable with inconsistencies.
Prize pool breakdown
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.