
A Sandwich Attack is a strategy in which bots exploit your trade by placing their own transactions both before and after yours to profit from slippage.
This attack falls under the broader category of Maximal Extractable Value (MEV), where validators or searchers gain extra profit by reordering transactions within a block. Sandwich attacks are most commonly seen in Automated Market Maker (AMM) pools such as Uniswap, where token prices are determined by an algorithm and update in real-time with every trade.
When a bot detects your pending transaction, it submits a "front-running" trade first to move the price against you, causing your swap to execute at a worse rate. After your trade goes through, the bot immediately executes a "back-running" trade to return the price to its original level, thereby locking in profit. The attacker’s main profit source comes from your slippage tolerance—the range of price deviation you’re willing to accept.
Sandwich attacks can significantly increase your trading costs and lead to worse outcomes than expected.
For regular users, the most visible effect is that a seemingly normal swap executes at a much less favorable price than quoted, and your transaction is flanked by two large trades in the transaction history. The smaller your trade or the wider your slippage tolerance, the more likely you are to be targeted.
For market makers and project teams, sandwich attacks can cause sharp price swings during token launches or marketing events, diluting real buy orders and impacting both pricing and user experience.
Understanding sandwich attacks helps you choose optimal trading methods and timing, reducing losses. It also enables teams to design more MEV-resistant routing and parameters.
A sandwich attack profits through a "buy-then-sell" or "sell-then-buy" sequence around your transaction.
Step 1: A searcher spots your pending swap in the mempool. Suppose you’re swapping 1,000 USDC for token X with a 1% slippage setting.
Step 2: The searcher submits a "front-run" trade, such as buying token X first to push the pool price higher. Since AMMs price tokens according to formulas, your expected execution price gets worse after this front-run.
Step 3: Your trade executes at this less favorable price. As long as your 1% slippage tolerance isn’t breached, the system processes your order, meaning you receive fewer tokens X at a higher price.
Step 4: The searcher immediately submits a "back-run" trade to sell the previously bought token X back into the pool, restoring the price close to its original state. The profit comes from the difference created by your slippage window, while the main risks are sudden market moves and failed transactions (gas costs).
Sandwich attacks are more likely—and profitable—when you set high slippage, use public RPC endpoints, or trade volatile tokens during peak activity. In contrast, using limit orders, private transactions, or protected routing makes it harder for searchers to detect and reorder your trade.
Sandwich attacks are common on Ethereum mainnet and L2 AMM pools, especially during high-volatility, event-driven periods.
In popular AMM pools like Uniswap, telltale signs include two large back-to-back trades surrounding your swap when tokens are newly listed, promoted by influencers, or in response to major on-chain news or airdrop speculation. Blockchain explorers often show your swap "sandwiched" between two large trades.
When using Gate’s Web3 wallet for aggregated swaps via public RPCs with high slippage on volatile tokens, you also face sandwich risk. By contrast, on Gate’s centralized exchange (CEX) spot order book, trades are matched by time and price priority and don’t appear in public mempools—making sandwich attacks nearly impossible—though other forms of trading costs and slippage (such as market impact) still apply.
On L2s (like Arbitrum, Optimism) and other EVM chains (such as BSC, Polygon), lower gas fees let searchers attempt more sandwich attacks at scale, but per-trade profits are smaller and rely on high-frequency strategies.
Mitigating sandwich attacks involves managing visibility, slippage tolerance, and timing.
Step 1: Lower your slippage. Set slippage for swaps only as wide as needed for execution—prefer tighter limits or limit orders during busy periods.
Step 2: Use protected RPC endpoints or private transactions. These send your trades through MEV-resistant relays or private pools, reducing mempool exposure. Many wallets and routers offer such options.
Step 3: Choose limit or fragmented execution. Limit orders or TWAP (time-weighted average price) splits reduce one-off market impact and minimize sandwich windows.
Step 4: Avoid hot periods. The first few minutes after token launches or major announcements see intense sandwich activity. Opt for deeper liquidity pools and more stable periods for trading.
Step 5: Simulate before trading. Use simulation tools or router “expected execution price” features to compare routes and spot abnormal price impact or slippage projections.
When using Gate’s Web3 aggregator, enable MEV protection if available, and use limit or split orders on volatile tokens. On Gate’s CEX, use limit orders or iceberg orders to control execution price and exposure.
Sandwich attack activity and defense mechanisms have evolved in tandem over the past year.
According to public dashboards and research teams’ data from 2025, MEV-derived revenue remains high—with sandwich attacks as a key contributor. While data varies by dashboard source, typical daily MEV revenue ranges from millions to several million USD; during major events, both the number and share of sandwich-tagged transactions spike (based on multiple public dashboards from Q3-Q4 2025).
Throughout 2025, as L2 trading volume increased and transaction fees dropped, sandwich attacks accounted for a higher share of L2 MEV activity—but per-trade profits decreased, relying more on frequency and optimized routing. More routers and wallets have launched protected RPCs, private transactions, and intents-based matching over the past six months. Some DEXs have reported declines in sandwich attack rates in major pools (referencing various protocol updates and dashboards from H2 2025).
For regular users, one clear change in late 2025 is that protected routing has become more common by default; recommended slippage settings are more conservative; and "price impact" warnings for trending tokens are clearer. In 2026, these protections are expected to become default settings across more wallets and aggregators.
A sandwich attack consists of both "frontrunning" and "back-running," while frontrunning only covers the first part.
Frontrunning refers to placing a trade just before yours to move the price against you; a sandwich attack "sandwiches" your order with both a preceding and a following trade that restores the original price, thus securing profit. Both rely on transaction ordering and mempool visibility, but sandwich attacks are more sensitive to slippage settings and pool depth due to their complete structure.
To distinguish them: If you see only one large trade in the same direction immediately before yours, it’s likely frontrunning; if you see both a large pre-trade and an opposite post-trade bracketing yours, it’s likely a sandwich attack. Understanding this difference helps you choose more targeted defensive strategies.
Sandwich attacks result in your trade executing at a worse price than intended—leading to extra slippage loss. Attackers manipulate prices by inserting their own transactions before and after yours so you buy at an inflated price or sell at a depressed one. These losses typically show up as devalued tokens or reduced profits, with especially significant impact on larger trades.
Watch for abrupt price swings just after submitting your trade. Key signs include: sharp immediate volatility upon submission; execution prices much worse than expected; unexplained wallet addresses rapidly trading right before and after yours in block explorers. Using limit orders instead of market orders on platforms like Gate can also help flag unusual activity.
Small trades are less likely targets because attacker costs (gas fees) may outweigh potential gains. However, in low-liquidity pairs or unusual market conditions, even small transactions can be at risk. It’s advisable to stick with high-liquidity pairs on mainstream platforms like Gate and to trade during busier periods for lower risk.
Private transaction pools (such as Flashbots) greatly reduce sandwich risk since your order is hidden from public mempools. However, they aren’t foolproof—the operators themselves may present risks, and some cross-chain or DeFi interactions can still expose your intentions. Combining platform-level risk controls (like those on Gate) with private pool usage offers optimal protection.
DEX trading is highly transparent—all transactions are visible in public mempools, making it easy for attackers to monitor and jump ahead. On centralized exchanges like Gate, order books are private with rapid matching engines—attackers cannot easily target specific trades. Moreover, DEX blocks take longer to finalize, giving attackers more time to act. For large trades especially, centralized exchanges tend to offer greater security.


