In Layer 2 (L2) networks, similar to Layer 1 (L1), there are potential issues when relying on block.timestamp for time-dependent operations, such as setting a deadline for token swaps. Despite L2 offering faster transaction processing and reduced latency, the synchronization with Layer 1 (L1) can introduce discrepancies in block timestamps. These discrepancies can lead to failed transactions if the block.timestamp used as a deadline becomes outdated due to network delays, block confirmation times, or price fluctuations in decentralized exchanges.
The purpose of these two functions is to exchange WETH for ALETH and ensure that the amount of ALETH is greater than the amount of WETH. For example, if 1e18 WETH is input, 1.01e18 ALWETH is output. However, setting the time in the swapExactTokensForTokens function to block.timestamp will cause a problem. If an output path has been found to output the amount that satisfies ALWETH, but block.timestamp has been jumped out, this will cause the transaction to fail, because the output that meets this condition may not be at the current time.
• In DeFi exchange protocols, prices can fluctuate over time, especially in high-frequency trading or market volatility. Even when a satisfying output path is found (e.g., 1e18 WETH exchanged for 1.01e18 ALETH), market conditions can change in just a few seconds.
• If block.timestamp is set as the deadline, the transaction may be considered expired due to timestamp mismatch or network latency, resulting in transaction failure.
Manual review
Add buffer to block.timestamp: As mentioned before, it is recommended to add a certain buffer time to the deadline. For example, use block.timestamp + 1 minutes to provide a sufficiently loose time window for transactions to prevent transaction failures due to network delays or inconsistent block confirmation times.
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.