DEX swap deadline vs slippage

A DEX swap deadline limits how late a transaction may execute; slippage tolerance limits acceptable deterioration in token amounts. For an exact-input swap, the enforceable amount is usually a minimum output. Where both guards are present, each must pass, and an included transaction that reverts can still cost gas. Neither setting guarantees inclusion or preserves an earlier quote.

Read the two conditions in the signed call

A swap preview is an estimate. The transaction you authorize contains the conditions under which the contract may act on that estimate. A percentage in a settings menu is useful only when you know which amounts and deadline it produces.

The distinction is visible in the Uniswap v2 Router02 source. Its ordinary swapExactTokensForTokens call checks that the deadline is at least the block timestamp and that the calculated final output is at least amountOutMin. Its exact-output counterpart instead checks input against amountInMax.

These are specific router rules, not fields guaranteed to exist in every DEX transaction. Uniswap's current Universal Router command reference documents two execute overloads: one includes a deadline guard and one does not. Identifying the pool protocol alone therefore does not establish whether the surrounding call enforces expiry.

Also keep price impact separate. The route's own size-dependent effect may already be reflected in the quote. The concentrated-liquidity execution guide explains why output changes along a swap path. Here, the task is deciding which later outcomes the transaction is allowed to accept.

Follow one instruction through four possible outcomes

Consider a hypothetical exact-input sale of 1 token X. At 12:00:00 UTC, the route quotes 2,000 tokens Y. The instruction is broadcast at 12:00:20 with a minimum output of 1,980 Y and an absolute deadline of 12:02:00. Assume ordinary tokens, correct approvals, sufficient gas and the Router02 behavior described above. All other checks pass.

The floor is 2,000 × 0.99 = 1,980 Y, one percent below this example's quote. This is an illustrative output-shortfall convention. Check the actual minimum amount in your interface or encoded call rather than assuming every SDK translates a percentage identically.

Each row below is an alternative execution of that same instruction, not four consecutive attempts:

In the second row, the quote-to-output shortfall is 25 ÷ 2,000 = 1.25%. Extending the deadline would not fix that output failure. In the third row, the available output exceeds the floor, but widening slippage would not fix the elapsed deadline.

For this router, equality is allowed: a block timestamp of exactly 12:02:00 passes the deadline condition. An output of exactly 1,980 Y passes the amount condition. Those boundary checks matter when validating an integration; “before the deadline” can be an imprecise description of the actual comparison.

Passing both conditions still does not guarantee success. A failed transfer, invalid route or another contract check can stop execution. The table isolates two conditions rather than modeling every possible failure.

Expiry does not remove a pending transaction

The deadline check runs when the contract executes. It is not a timer that reaches into every node's pending pool and deletes the transaction. Ethereum's transaction lifecycle documentation distinguishes broadcast and pending transactions from transactions included in a block. A swap's deadline is part of its contract call, not proof that network processing has ended.

The practical consequence follows from these two mechanisms: an expired swap can still be included and execute far enough to fail its time check. Watching the wallet's countdown reach zero therefore does not establish a confirmed cancellation or a final gas charge.

For integrations, verify the timestamp's units and origin. Solidity defines block.timestamp in Unix seconds; a millisecond value would place an intended near-term deadline far in the future. Another consequence of the comparison is that a wrapper calculating block.timestamp + 120 only when it executes cannot limit how long the earlier quote waited. Preserve the previously authorized absolute expiry.

Use the transaction hash, network and sender nonce to reconcile what actually happened. Distinguish pending, included with failure, included with success and any confirmed replacement. A dropped label from one provider also describes that provider's observation; it is weaker evidence than a canonical inclusion record.

A dead man's switch for orders addresses another kind of time control: withdrawing outstanding trading permission when a required renewal stops. Its cancellation mechanism should not be assumed to describe a router's expiry check.

A reverted swap can have a real gas bill

On Ethereum, computation consumes gas whether included execution succeeds or fails. The Ethereum gas reference defines the fee using gas used and the price per unit of gas. The token exchange can fail while the sender still pays for processing.

For an illustrative failed transaction using 26,000 gas at an effective price of 18 gwei, the execution fee is:

26,000 × 18 × 10⁻⁹ = 0.000468 ETH

This is invented arithmetic, not a measured expiry cost. The amount depends on the executed path. A chain or rollup may also have fee components beyond this Ethereum execution-fee illustration.

Do not substitute the transaction's gas limit for actual gas used. EIP-140's REVERT specification provides for rolling back execution state without automatically consuming all remaining gas. Running out of gas is a different failure.

Likewise, distinguish a failed simulation or wallet rejection before broadcast from an included revert. The former does not itself create an on-chain execution fee. If a separate token approval transaction already succeeded, a later reverted swap does not undo that earlier approval. Preserve the two receipts separately.

When comparing attempts, include failed execution and any separate approval costs under a stated scope. The transaction-cost analysis worksheet explains how to retain original intent and explicit charges without double counting them.

Refreshing a quote can change what you authorize

A later deadline cannot make an old quote current. Uniswap's API guidance on quote freshness recommends refreshing quotes more than 30 seconds old before broadcasting. It also warns that simulation does not guarantee on-chain success because conditions can change before inclusion. That is guidance for this API, not a universal safe interval for all markets.

Inspect the elapsed time between quote, approval, wallet confirmation and broadcast. If signing or a separate approval consumes most of the intended window, obtain a current quote and review a newly built instruction before sending it.

Keep the old absolute bounds visible during that review. Suppose the original quote was 2,000 Y with a 1,980 Y floor. A new quote of 1,900 Y, reduced by the same illustrative one percent, gives a 1,881 Y floor. The percentage label is unchanged, but the new instruction permits 99 fewer Y than the original minimum. That change needs an intentional decision.

Similarly, repeatedly extending the deadline makes an instruction valid for longer. Whether the underlying trade remains appropriate is separate from whether the transaction is technically valid. Record the accepted minimum or maximum as a token amount, alongside the percentage and the quote that produced it.

An execution inside both bounds can still be economically unattractive. A short deadline does not prevent unfavorable ordering within its window, and a wide tolerance permits greater deterioration. The MEV sandwich-risk guide examines that ordering problem. Deadline and amount checks alone do not identify the cause of a worse execution.

Verify the call, then verify the outcome

Before signing, use a small validation worksheet:

After inclusion, reconcile the receipt, relevant transfers, final recipient amounts and actual fee. A transaction-level success flag is insufficient for some composed routes. The Universal Router's allow-revert flag lets a failed command leave the overall transaction running. Such a plan requires checking which commands succeeded and how residual balances were settled.

If an attempt fails, first identify the failed condition and reconcile its final state. Only then decide whether a new quote, different amount, changed time window or no further attempt fits the original intention. Preserve both the absolute amount bound and expiry in that decision: each controls a different permission, and neither is a promise that the swap will complete.