Using block.timestamp as deadline for swapping is incorrect, allowing outdated slippage.
Deadline "block.timestamp" is used as the deadline in L2TokenReceiver.swap() and L2TokenReceiver.increaseLiquidityCurrentRange(). Without a deadline parameter, the transaction may sit in the mempool and be executed at a much later time potentially resulting in a worse price for the user. Most of the functions that interact with UniswapV3 do not have a deadline parameter, but specifically, the one in the SwapRouter.vy, is passing block.timestamp to a UniswapV3 router, which means that whenever the miner decides to include the transaction in a block, it will be valid at that time, since block.timestamp will be the current timestamp. Malicious validator can hold back the transaction and execute it at a more favourable block number. This offers no protection as block.timestamp will have the value of whichever block the transaction is inserted into, and it can be held indefinitely by malicious validators.
In that case transaction stays pending in the mempool/sequencer for extended periods, which could be hours, days, or even longer. During this time, the price of the tokens has changed and the user has unknowingly performed a bad trade due to the pending transaction.
Manual review.
Recommended to pass the deadline as an argument to the "swap" and "increaseLiquidityCurrentRange" functions like that:
User can manually set the time frame for the execution of the transaction, based on the time of the call "swap" function, and not the time of its adding into the block.
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.