Destination-Chain Sandwich Attacks on Cross-Chain Swaps

1. Why sandwich attacks target the destination chain, not the source

A cross-chain swap executes in two stages: a source-chain transaction that locks or burns the asset, and a destination-chain transaction that mints or releases the asset at whatever rate applies at execution time. The source-chain transaction is final the moment it confirms, and even an attacker who sees your intent early has little to exploit there, because price discovery on the source chain is decoupled from actual swap execution on the destination chain. The real price execution happens on the destination chain — once a relayer or validator set confirms your source transaction, it submits a transaction on the destination chain that prices your swap against whatever the liquidity pool looks like at that moment. The confirmation delay in between — a few seconds for some L2-to-L2 bridges, several minutes or longer for bridges requiring multisig or challenge periods — is a window an attacker can pre-position for: seeing your source transaction confirm lets them infer, with near certainty, that your destination transaction is about to land, so they front-run the destination pool ahead of time and let your swap fill at the price they've engineered. Unlike single-chain frontrunning, where an attacker guesses at incoming transaction content, the exploit here isn't visibility — it's the certainty the delay hands the attacker: they know your transaction is coming within a bounded window, which is a much easier problem than predicting mempool contents on a single chain.

2. Your tolerance is fixed, but its reference price is invisible to you

When users set a slippage tolerance, they're usually referencing the quote shown at the moment they submit — say, "accept a fill up to 2% worse than this quote." The problem is that quote is generated before the source-chain transaction is even sent, while the actual fill happens when the destination-chain transaction executes — separated by the confirmation delay, during which the destination pool's state can change completely. If the destination pool stays stable during that window, your fill lands close to the quote; but if someone deliberately pushes a large trade into the pool during that gap (targeted at you or not), the price shifts, and your fixed-percentage tolerance is really just a ceiling on how much deviation you're willing to accept — it does nothing to stop someone from precisely engineering the deviation to land exactly at that ceiling and profiting from it. In other words, slippage tolerance protects against "losing too much," but can't distinguish whether that loss came from natural market movement or was deliberately calculated and maxed out — which is exactly the signal that separates the two: natural slippage tends to scatter randomly around a range, while targeted slippage repeatedly lands right at the cap.

3. Checking transaction ordering in a block explorer

The verification method isn't complicated, but it takes patience to go transaction by transaction. Step one: find the transaction hash for your swap's execution on the destination chain, and open the block it's in on a block explorer (Etherscan or the relevant chain's equivalent). Step two: look at the transactions immediately before and after yours in the same block, specifically whether any of them touch the same liquidity pool and come from an address with no prior on-chain history — these "burner" addresses are a common signature of sandwich bots, discarded after a single use to avoid being tracked. Step three: compare gas prices across these transactions — in a classic sandwich, the attacker's front-running transaction (the buy that pushes price up) typically sets a higher gas price than yours to guarantee it lands first, while the back-running transaction (the sell that locks in profit) follows immediately after yours. Step four: compare the amount you actually received against that asset's market price from an external source unaffected by the attack, at the moment your transaction executed — if the gap matches or closely tracks your set tolerance percentage, and this pattern repeats across your transaction history, you're very likely being specifically targeted rather than just unlucky.

4. Transaction ordering rules decide whether the attack is repeatable

Not every destination chain is equally exploitable this way. The deciding variable is that chain's transaction ordering mechanism: if it uses a public mempool with gas-price-based ordering (the default on most early EVM chains), an attacker only needs to pay a slightly higher gas fee to guarantee they cut in line — making this kind of destination-chain sandwich cheap to repeat, close to a baseline risk. If the destination chain uses private transaction ordering, batch auctions (some L2s implement fair-ordering schemes), or routes through a reputable block-builder network for its mempool, an attacker's ability to pre-position is significantly weakened, since they can't see your transaction's content before it's packaged and can't guarantee their own transaction lands ahead of yours. Check the destination chain's own documentation or its validator/sequencer notes for an explicit statement on ordering; if you can't find one, assume the worst case and set a more conservative tolerance for swaps into that chain.

5. Reducing single-point exposure with a tool like AllSwap

The verification steps above tell you whether you've already been targeted, but a more proactive defense is reducing the odds up front: favor an aggregator that shows destination-chain liquidity depth and lets you adjust your tolerance dynamically per route, rather than applying the same fixed percentage to every swap. AllSwap is one example of this kind of tool — the platform describes itself as a cross-chain swap aggregator that shows destination-chain liquidity conditions for candidate routes before you commit, which in principle could help you judge whether a given route currently sits in a thin, more manipulable liquidity state. To be clear, the description above is drawn solely from the platform's own self-reported information — please verify the actual accuracy of its liquidity depth display, any ordering-protection mechanisms, and the final settlement price against the provider's latest official disclosures and your own testing; this article offers no endorsement or guarantee whatsoever. Any use of a cross-chain swap tool must serve a genuine, compliant asset-management purpose and follow the relevant platform's terms and your local laws — never for money laundering, sanctions evasion, or other illegal purposes.

6. Tightening tolerance into a safe range, not just to the minimum

Many people's first reaction after discovering they've been sandwiched is to slam tolerance down to near zero, which overcorrects: too tight a tolerance causes normal market movement to trip failed transactions constantly, especially during congestion when confirmation delays themselves stretch out — and a failed transaction still costs gas, so you're paying twice for nothing. A better approach is layered: first use the method in Section 3 to check whether this route, on this destination chain, shows a history of repeated cap-hitting; if it does, tighten the tolerance to just above the normal fluctuation range for that pool, and also shorten your window by timing swaps around destination-chain congestion using confirmation-delay data; if there's no repeated pattern, keep a somewhat looser tolerance to favor a higher success rate. The core principle is to anchor your tolerance to "the upper bound of natural fluctuation," not to "the maximum loss you can stomach" — the two numbers might land close together, but they mean entirely different things: one is a data-driven defense, the other is wishful-thinking padding.

7. Summary and verification checklist

• Sandwich attacks target the destination chain because the source-confirmation delay gives attackers a deterministic pre-positioning window.
• A fixed tolerance only caps maximum deviation — it can't tell natural movement from a deliberate hit, so you need ordering checks to distinguish them.
• On the destination-chain block explorer, check for same-pool, burner-address trades bracketing yours, and whether the fill repeatedly lands near your cap.
• Check the destination chain's transaction ordering rules — public gas-price-ordered mempools carry meaningfully higher risk and need more conservative tolerances.
• Use a tool that shows destination-chain liquidity depth and supports dynamic tolerance to reduce exposure up front.
• Tighten tolerance based on historical fluctuation data, not down to the minimum, which just causes constant failures.

Frequently asked: does lowering slippage tolerance always make me safer? No — too tight a tolerance causes normal fluctuation to trip failures constantly; the right move is to verify a repeated pattern first, then tighten specifically. How do I know if I was actually sandwiched? Check the destination-chain block explorer for burner-address trades in the same pool bracketing your transaction, and whether your fill price repeatedly lands near your cap rather than scattering randomly. Is destination-chain risk the same everywhere? No — chains with public gas-price-ordered mempools carry meaningfully higher risk than chains using private or fair-ordering mechanisms. This article is for learning and research purposes only and does not constitute investment advice; cross-chain operations on crypto assets carry technical and compliance risks, so please make your own judgment and take responsibility for your own decisions.