Smart contracts often facilitate token swaps and othertime-sensitive operations. An improper or missing deadline check vulnerabilityarises when these contracts fail to ensure transactions are executed within aspecified timeframe. This oversight can lead to several issues:
Without a deadline, transactions can remain pending in themempool during periods of network congestion. This delay causes transactions tobe executed much later than intended, potentially leading to unfavorableoutcomes for users.
Let's look at a very simple illustration with Bob.
1. Bobwants to Swap 500 XYZ for 5 ETH and then sell 5 ETH for 10,000 USDC.
2. Transactiongets stuck. Maybe Bob sets a low gas fee to save costs. Miners prioritizeother transactions, leaving their swap pending in the mempool for hours ordays.
3. Marketconditions change. When the transaction finally executes, ETH's price hasdropped. Bob still gets 5 ETH, but now they are only worth 6,500 USDC insteadof 10,000 USDC. This specific example is slightly tricky but elaborates theproblem even with proper slippage parameters: Bob has as minOut parameter 5 ETHand would usually receive more ETH due to the ETH price decrease. However, aMEV bot now sandwiches Bob's swap which results in Bob only receiving 5 ETHwhile Bob actually should receive 8 ETH (or whatever would be the appropriateamount) which would be the fair price due to the price drop.
4. Outcome.Instead of a profitable trade, Bob just made a loss because his transactionwas executed far later than intended while at the same time he was sandwichattacked.
Consider the flashswapDeleverage function shown below. TheflashswapDeleverage function does not include a deadline parameter, whichintroduces a risk of delayed execution due to network congestion, fluctuatinggas prices, or manipulation attempts. Without a deadline, transactions can sitin the mempool indefinitely and be executed at an unexpected time:
One significant issue is that market conditions can changebetween when a transaction is sent and when it is confirmed. The price in theliquidity pool may shift during the delay. This means that the originallyintended trade parameters — such as the amount of debt to remove and theslippage limits — may no longer be favorable at execution.
Another risk stems from transaction ordering manipulation,particularly sandwich attacks. Because there is no deadline to enforce timelyexecution, malicious actors can monitor the mempool and strategically placetransactions before and after the user's swap. This can artificially push theprice and force the user to execute at a worse rate, allowing the attacker toextract value from the trade.
Using block.timestamp as a deadline in smart contractfunctions helps prevent transactions from remaining valid indefinitely byensuring they are only executable within a specific timeframe. However, it doesnot eliminate all risks, particularly in time-sensitive applications.
For most standard deadline enforcement, such as preventing oldtransactions from executing, block.timestamp is generally sufficient, however,in high-precision use cases where, even small timing variations can impactoutcomes.
When implementing deadlines in smart contracts, it is crucialto ensure that transactions cannot be executed after a specified expirationtime.
This condition ensures that the transaction must be executedbefore or exactly at the deadline. If the current block timestamp(block.timestamp) exceeds the deadline, the transaction will fail.
Contrarily, when deadline <= block.timestamp, only allowalready expired transactions to proceed, which is incorrect and defeats thepurpose of setting a deadline. Such a condition would instantly reject allvalid transactions while allowing only those that are past the deadline,effectively inverting the logic.
The swapExactTokensForTokens function shown below is a goodexample of a function taking a deadline parameter for a swap and using theensure(deadline) modifier to define the behavior of the deadline during swaps.
Link to the article: https://x.com/0xCharlesWang/status/1893434631011111165
