QuantAMM
QuantAMM
49,600 OP
View results
Previous Next
Submission Details
Severity: low
Valid

Use of `block.number` in `afterUpdate` Function

TheKhans

Summary

In the afterUpdate function, which executes when an NFT is transferred, block.number is incorrectly used to record the deposit timestamp. However, during liquidity addition, the code correctly uses block.timestamp. This inconsistency can lead to inaccurate time tracking.

Vulnerability Details

When a user adds liquidity, the block.timestamp is stored in blockTimestampDeposit. This can be observed in the following code:

​
contracts/hooks-quantamm/UpliftOnlyExample.sol:219
219:
220: function addLiquidityProportional(
221: address pool,
222: uint256[] memory maxAmountsIn,
223: uint256 exactBptAmountOut,
224: bool wethIsEth,
225: bytes memory userData
226: ) external payable saveSender(msg.sender) returns (uint256[] memory amountsIn) {
....
252: poolsFeeData[pool][msg.sender].push(
253: FeeData({
254: tokenID: tokenID,
255: amount: exactBptAmountOut,
256: //this rounding favours the LP
257: lpTokenDepositValue: depositValue, // 0.5e18
258: //known use of timestamp, caveats are known.
259: blockTimestampDeposit: uint40(block.timestamp),
260: upliftFeeBps: upliftFeeBps
261: })
262: );
263:
....

But in the afterUpdate function, at Line 616, the code stores the deposit timestamp as block.number

​
contracts/hooks-quantamm/UpliftOnlyExample.sol:579
579: function afterUpdate(address _from, address _to, uint256 _tokenID) public {
...
610:
611: if (tokenIdIndexFound) {
612: if (_to != address(0)) {
613: // Update the deposit value to the current value of the pool in base currency (e.g. USD) and the block index to the current block number
614: //vault.transferLPTokens(_from, _to, feeDataArray[i].amount);
615: feeDataArray[tokenIdIndex].lpTokenDepositValue = lpTokenDepositValueNow;
616: @> feeDataArray[tokenIdIndex].blockTimestampDeposit = uint32(block.number);
617: feeDataArray[tokenIdIndex].upliftFeeBps = upliftFeeBps;
618:
619: //actual transfer not a afterTokenTransfer caused by a burn
620: poolsFeeData[poolAddress][_to].push(feeDataArray[tokenIdIndex]);
...

Impact

Using block.number instead of block.timestamp during transfers results in incorrect timestamps, causing inconsistencies for off-chain services relying on this timestamp.

Tools Used

Manual Review

Recommendations

To maintain accurate time records, it is recommended to replace block.number with block.timestamp.

- feeDataArray[tokenIdIndex].blockTimestampDeposit = uint32(block.number);
+ feeDataArray[tokenIdIndex].blockTimestampDeposit = uint32(block.timestamp);
Updates

Lead Judging Commences

n0kto Lead Judge 10 months ago
Submission Judgement Published
Validated
Assigned finding tags:

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.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!