Can a Sandwich Attack Make My Swap Fail?

A pending swap is not proof of a sandwich attack; it is exposed only if someone can see its details before execution and your slippage limit allows the trade to proceed at a worse price. If a swap on Base is waiting or has reverted, the transaction record and pool activity can help you tell a failed price check from a completed trade that got a poor fill. Base is Coinbase’s Ethereum layer 2, where decentralized exchanges use liquidity pools to trade token pairs.

A sandwich attack targets a pending pool swap by placing one trade before it and another after it. For a concrete Base DEX example, the base swap exchange relates to the same kind of automated market maker trade discussed here. The key question is whether the attacker’s trades changed the pool price enough to worsen your execution while staying inside the limit you accepted.

What happens in a sandwich attack?

A sandwich attacker tries to profit from the price movement your swap is expected to cause. In a typical automated market maker (AMM), trades change the pool’s token balance ratio, and the quoted price moves as a result. The attacker’s first trade shifts that ratio against you; your swap then trades at the worse price; the attacker’s second trade sells into the movement.

For example, imagine you submit a buy that would return about 1,000 tokens at the current pool price, with a 3% slippage tolerance. A bot that can observe the pending transaction may buy first, raising the token’s pool price. Your transaction then receives fewer tokens, perhaps 975 in this illustrative example, and still succeeds because the output remains above your minimum of 970. The attacker sells after your swap, aiming to capture the price movement, less trading costs and the risk that the market moves against them.

That is different from ordinary price impact, which your own trade causes, and ordinary slippage, which is the change between the quote and execution. A large order relative to pool liquidity creates more price impact; a sandwich adds an adversary’s trades around yours. Low liquidity, a large trade, and a permissive slippage limit can make the opportunity more attractive, but they do not prove a bot targeted your transaction.

Why might it stay pending or revert?

A pending status means the transaction has not yet reached a final result; it does not establish that an attacker has seen it or acted on it. Transactions can wait because of network conditions, fee settings, or ordering, and the execution price can change while they wait. Visibility also depends on how the transaction is sent and what information is available to block producers and searchers, so do not assume every pending Base transaction is publicly exposed in the same way.

A swap commonly reverts when execution would return less than the contract’s minimum output, which is calculated from the quote and your slippage tolerance. If a sandwich attempt pushes the expected output below that floor, your swap should fail instead of completing at that price. A revert generally means the token exchange did not happen, but the transaction may still consume network gas; check its final status rather than relying on a wallet’s temporary message.

The same failure can also come from a normal market move, a stale quote, or another trade changing the pool first. Transaction details can show whether the swap reverted and whether nearby pool trades moved the price, but timing alone is not conclusive proof of a sandwich. A completed swap with a worse result is more concerning when pool history shows a buy immediately before it and a sell immediately after it, in the same direction and size pattern.

What should I check before trying again?

Start with the transaction hash and wait for a final state. If it is still pending, avoid submitting another swap with the same intention until you know whether the original can still execute; duplicate attempts can both land. If it reverted, confirm that the swap did not complete, then compare the transaction’s minimum output with the quote and pool price around execution.

Before retrying a base swap, reduce the trade size or use a deeper pool if the quoted price impact is high. Set slippage only as wide as you can genuinely accept: widening it may help a volatile trade execute, but it also gives a sandwich more room to worsen your output. Splitting a large order can reduce its impact on one pool, though it may add transaction costs and leave later pieces exposed to changing prices.

Liquidity farming and pool depth are related but not interchangeable: a pool can offer rewards while still having limited liquidity at the price your trade needs. Check the actual pair depth and expected output for your order size. In practice, I would not raise the slippage limit simply to force a pending or repeatedly failing swap through.

Use this short recovery checklist

• Wait for the transaction to confirm or revert; do not assume pending means attacked.
• For a failed swap, verify the final status and check whether gas was charged.
• Compare minimum output, actual output, and the pool’s trades around execution.
• Retry with a smaller amount or deeper liquidity, and keep slippage within an acceptable loss.