The value provided in increaseLiquidity function's deadline parameter is pointless, and would cause undesired amount liquidity to be added, or can potentially be arbitraged by MEV bots.
In L2TokenReceiver.increaseLiquidityCurrentRange, the function adds liquidity to the pool which is set by the protocol. The function prepares parameter and eventually calls NonFungiblePositionManager.increaseLiquidity with prepared parameters:
However, notice that the deadline is set to block.timestamp. This action completely defeats the purpose of such parameter, can potentially cause undesired amount of liquidity to be added.
Normally, when such function call is made, it would eventually be mined by miners when the gas price is reasonable enough for them. But there exists a scenario where the transcation won't get mined until a while, now, the purpose of deadline parameter starts to show. In NFPM, the modifier of checkDeadline sees that the deadline set has way passed, and transaction will be reverted, sender can make another transaction but with higher gas value to make sure the transaction gets mined asap. When the value is set to block.timestamp, the checkDeadline essentially does not as the comparison is always true: block.timestamp <= block.timestamp. When the time has passed well, and this transaction gets mined eventually, the actual liquidity added will likely be different than the sender has originally expected.
This past issue explains the impact well, and how it may potentially be exploited by MEV bots.
Manual review
Add deadline parameter to the function, and forward this to the call to NFPM.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.