A swap deadline expires when its transaction reaches the blockchain after the timestamp encoded in the swap call. If you were comparing ways to trade on Base, the base swap article connects that situation to BaseSwap, an automated market maker on Base, Coinbase’s Ethereum Layer 2. The same deadline mechanics apply across AMM routers: a fresh submission needs a valid deadline and current trade parameters.
BaseSwap’s official app, baseswap.io, is a way to swap tokens or provide liquidity on Base. To decide what to do after an expiry, first check whether the transaction is still pending or has already been included in a block.
What the deadline actually limits
A router deadline is a Unix timestamp, usually in seconds, passed as a parameter in the transaction’s calldata. A common implementation checks that the deadline is greater than or equal to the block timestamp; if it is earlier, the contract reverts with an expired-transaction error. Some swap integrations use a 20-minute deadline by default, while the chosen interval varies by interface and strategy.
The deadline limits how long the signed swap call remains executable. It does not hold a quote open, guarantee a price, or stop a transaction from sitting in the mempool. Slippage protection does a separate job: a minimum-output constraint rejects execution if the route would deliver less than the amount you accepted.
Check whether the old transaction is pending or reverted
Look up the transaction hash on a Base block explorer or in your wallet’s transaction history. A pending transaction has not yet been included; its deadline may still be valid, or it may already be too old to execute. A confirmed transaction with a failed status has reverted on-chain.
If an expired call is included after its deadline, the contract’s check fails and the swap’s state changes are rolled back. The transaction still consumes gas because the network processed it, and its nonce is consumed. Any token approval made in a separate, earlier transaction remains in effect; it is not undone by the failed swap.
Resubmit with fresh parameters
For a confirmed expiry, prepare a new swap call rather than trying to revive the old one. Refresh the route and quote, review the input amount and minimum output, and use a new deadline calculated from the current time. For example, if you submit at 14:00 UTC with a 20-minute window, the encoded deadline is 14:20 UTC; a block timestamp after that makes the call revert.
If the old transaction is still pending, sending another transaction with the next nonce may leave both waiting behind it. To replace it, wallets generally require a same-nonce transaction with a higher fee; replacement rules depend on the wallet and node. Alternatively, wait for the old transaction to be included or dropped, then submit the swap again. Check the nonce and status before signing, since a replacement can change what executes.
Extending the deadline can help when Base is congested or the fee is set too low, but a much longer window leaves the signed trade executable for longer while market conditions move. I’d use the shortest interval that reasonably covers expected inclusion time, then rely on a suitable minimum output to bound price movement. When researching base swap options, treat a fresh submission as a new trade decision, not a retry of the same quote.
Questions to settle before resubmitting
Will changing the deadline change the swap price?
No. The deadline changes the latest acceptable execution time, not the quoted rate or slippage limit. Refresh the route and inspect the minimum output separately. If the market has moved, a longer deadline will not make the old minimum output safer; it may simply leave the call valid for longer if that minimum is still achievable.
Does an expired swap require another approval?
Usually not if the required token allowance was granted in a separate transaction and remains sufficient. A failed swap does not reverse that approval. Check allowance and input token before resubmitting; if approval was bundled into the same reverting transaction, that approval also reverted and must be granted again.
Before acting, ask yourself: is the old transaction settled, and are the refreshed minimum output and deadline still acceptable?