Deadline check is not effective, allowing outdated slippage and allow pending transaction to be unexpected executed
AMMs provide their users with an option to limit the execution of their pending actions, such as swaps or adding and removing liquidity. The most common solution is to include a deadline timestamp as a parameter (for example see Uniswap V2 and Uniswap V3). If such an option is not present, users can unknowingly perform bad trades:
Alice wants to swap 100
tokens for 1 ETH
and later sell the 1 ETH
for 1000 DAI
.
The transaction is submitted to the mempool, however, Alice chose a transaction fee that is too low for miners to be interested in including her transaction in a block. The transaction stays pending in the mempool for extended periods, which could be hours, days, weeks, or even longer.
When the average gas fee dropped far enough for Alice's transaction to become interesting again for miners to include it, her swap will be executed. In the meantime, the price of ETH could have drastically changed. She will still get 1 ETH
but the DAI
value of that output might be significantly lower.
She has unknowingly performed a bad trade due to the pending transaction she forgot about.
Loss of fund for the user (owner/protocol) in this case
Manual Review
Instead of using block.timestamp
as deadline, use an effective deadline or calculate it from frontend and send it to smart contract, block.timestamp
is similar to having no deadline as it will set deadline too far in the future
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.