The Importance of Deadline Checks in Swaps
In decentralized finance (DeFi), users often rely on automated market makers (AMMs) and decentralized exchanges (DEXs) like Uniswap to execute token swaps. These protocols facilitate swaps between tokens using liquidity pools, allowing users to trade without the need for a centralized exchange. However, one critical security feature that can prevent serious vulnerabilities during swaps is the use of deadline checks.
When executing a swap, users submit a transaction that goes through the blockchain's mempool, waiting to be picked up and included in a block by miners. If there are no deadline checks, a pending transaction can remain unexecuted in the mempool for an extended period. This creates a potential vulnerability that could be exploited by miners, arbitrage bots, or malicious actors. This section will explore the risks of missing deadline checks, focusing on their importance and how failing to include them can lead to severe losses.
Understanding Deadline Checks
In most DeFi protocols, when users perform token swaps or other time-sensitive operations, they include a deadline parameter—a timestamp that indicates how long the transaction is valid. If the transaction is not executed by the blockchain before the deadline is reached, it becomes invalid and reverts.
This feature is essential for ensuring that swaps are executed within the price conditions that the user expects. Without it, pending transactions can linger in the mempool, waiting to be executed when network conditions are favorable—at the cost of the user’s potential loss.
Missing Deadline Checks: How the Vulnerability Works
Let’s look at the vulnerability in more detail. When a protocol fails to include deadline checks in its swap functions, the following can occur:
Stale Transactions: A user may submit a swap transaction to exchange tokens at a certain price (e.g., 100 DAI for 1 ETH). If gas fees are too high at the time, the transaction may not be included in a block immediately and could remain pending in the mempool.
Price Volatility: Over time, token prices fluctuate due to market conditions. By the time the pending swap is executed, the original price may no longer be relevant. The user could end up exchanging tokens at a drastically worse rate than they expected.
Front-Running and Sandwich Attacks: In the worst case, Miner Extractable Value (MEV) bots can monitor the mempool for pending transactions. They can exploit the lack of a deadline by sandwiching the pending transaction (i.e., front-running and back-running it) to generate profits for themselves while the user suffers from slippage or bad pricing.
Example Scenario: Vulnerability Exploitation
Let’s walk through a step-by-step example of how a missing deadline check can lead to significant losses for a user:
Scenario: Missing Deadline During a Swap
Alice wants to swap 100 tokens for 1 ETH on a decentralized exchange (DEX) like Uniswap V3.
She submits a transaction, but due to high gas fees, it remains pending in the mempool for hours or even days.
While her transaction is pending, the price of ETH increases substantially, meaning her swap would no longer be profitable.
Since there is no deadline parameter to invalidate the transaction, it eventually gets executed after the price change, giving Alice a much worse deal than expected. She still receives 1 ETH, but it’s now worth much less than what she could have gotten.
MEV Exploit Example
A MEV bot detects Alice’s pending swap in the mempool and notices that the price of ETH has changed significantly since she submitted the transaction.
The bot sandwiches Alice’s trade by front-running her swap with its own transactions, driving the price of ETH up even more.
When Alice’s swap is finally executed, the slippage results in Alice losing a significant portion of her tokens to the bot, which then profits from the trade.
Preventing the Vulnerability: Adding Deadline Checks
The simplest and most effective way to prevent this vulnerability is to include a deadline parameter in every swap transaction. This ensures that if the transaction is not mined within a specified time limit, it is canceled and cannot be executed later under worse conditions.
Last updated