Sandwich Attacks in Crypto: Protection Guide

A sandwich attack is a form of exploitation in decentralized finance where a bot or trader places transactions before and after your pending transaction in the blockchain to profit from your trade. These attacks happen because blockchain transactions are visible before they're finalized, allowing attackers to see your pending order and act on that information. Understanding how sandwich attacks work and how to defend against them is essential for anyone trading on decentralized exchanges.

What Is a Sandwich Attack?

A sandwich attack is a form of front-running that exploits transaction ordering: an attacker inserts their own transaction before yours (the "bread") to profit from the price movement your transaction will cause. In a typical scenario, you submit a trade to buy or sell tokens on a decentralized exchange, and this transaction sits in the public mempool waiting to be included in a block. The attacker detects your transaction, quickly submits their own with a higher fee to get it prioritized, and then watches as their transaction executes first, moving the price in their favor.

The name "sandwich" comes from the structure: your transaction is the filling, and the attacker's two transactions are the top and bottom slices of bread. The attacker's first transaction (the top slice) moves the market in a direction that benefits them. Then your transaction executes at a worse price than you expected because the market has already shifted. Finally, the attacker's second transaction (the bottom slice) exits their position and captures the profit.

Sandwich attacks are particularly common on Ethereum and other networks where the mempool is publicly visible before block inclusion. They represent a real source of hidden costs for everyday traders and have drawn attention from the DeFi community and protocol developers.

How Sandwich Attacks Work: Technical Mechanics

The technical process begins when you create a swap on a decentralized exchange like Uniswap. Your transaction—which includes details like the token you want to trade, the amount, and your slippage tolerance—is broadcast to the mempool and becomes visible to other network participants. Bots continuously scan the mempool for profitable opportunities, analyzing pending transactions to predict their price impact.

When an attacker identifies a large transaction that will move the price, they calculate how much they can profit by front-running it. They submit a transaction with a higher gas fee — or priority fee, under Ethereum's current proof-of-stake consensus — which incentivizes miners (on proof-of-work chains) or validators (on proof-of-stake chains like Ethereum) to include their transaction first. As their transaction executes, it moves the token price in the direction they predicted. When your transaction executes next, you get a worse price because the market has shifted. For example, if you wanted to buy tokens at a certain rate, the attacker's purchase has already driven the price higher. Your transaction now buys at that higher price, and you receive fewer tokens than you would have without the attack.

Fully executing the attack requires one more step: the attacker's second transaction exits their position by selling the tokens they just bought. This "back-running" transaction locks in their profit. The entire sequence—front-run, victim transaction, back-run—typically happens within a single block, all while you're unaware that the price you received was worse than it should have been.

Key Features and Characteristics

Sandwich attacks share several defining characteristics that make them distinct from other forms of market manipulation. First, they rely on **mempool transparency**—the public visibility of pending transactions before they are finalized. Without seeing your transaction in advance, attackers cannot profit from knowing what you're about to do. Second, they depend on **fee dynamics or validator priorities**. An attacker must be able to ensure their transaction is prioritized, which usually means paying a higher fee than yours.

Third, sandwich attacks are **most profitable on larger transactions**. A small trade might not move the price enough to make the attack worthwhile after accounting for transaction costs. Fourth, they are **largely automated** through bot software that continuously monitors the mempool, calculates potential profit opportunities, and executes attacks at machine speed. This automation means attacks can recur repeatedly throughout the day across many different tokens and trading pairs.

Finally, sandwich attacks exploit the **lag between intent and execution**. You express your intent to trade by submitting a transaction, but there's a delay before it's actually processed on the blockchain. During this window, attackers can act on knowledge of your intent. This timing gap exists because blockchain networks must gather transactions into blocks before processing them, creating an inherent opportunity for exploitation.

Common Targets and Use Cases

Sandwich attacks occur across multiple DeFi applications and scenarios, wherever there's a delay between transaction submission and execution. **Decentralized exchanges (DEXes) like Uniswap** are the primary target because swap transactions are frequent, sizable, and their price impact is predictable. When you submit a swap for a significant amount of tokens, the price impact of your own trade is calculable, making it easier for attackers to estimate their profit.

**Large liquidity pool trades** and **token purchases during high-volume periods** are particularly vulnerable because the price impact is more substantial, which helps justify the transaction costs of the attack. Certain token launches and high-demand trades also attract sandwich attacks because price volatility creates larger profit windows. **Cross-chain bridges and automated market makers (AMMs)** that rely on on-chain oracle prices can also be targets, since any predictable price movement is exploitable.

Additionally, **limit orders and smart contract interactions** that trigger trades can be targeted if they announce their intent on-chain. For instance, if a smart contract will execute a trade based on a certain condition, an attacker who observes the pending contract call can sandwich that trade. Governance token sales and NFT minting transactions with embedded payment logic can also be vulnerable, though they're less common targets than simple DEX swaps.

Protection Method 1: Slippage Settings and Limits

One of the most basic protections against sandwich attacks is setting appropriate **slippage tolerance** on decentralized exchange interfaces. Slippage is the difference between your expected price and the actual execution price. When you perform a swap, you can specify a maximum slippage percentage—for example, 0.5% or 1%—which tells the smart contract to reject the trade if the price moves more than that amount.

If an attacker front-runs your transaction and moves the price beyond your slippage limit, your transaction will fail and you won't lose money. However, this protection has limitations. Setting slippage too low makes your transaction more likely to fail during normal market volatility, especially on volatile tokens or during congested network periods. Setting it too high leaves you vulnerable to sandwich attacks up to that threshold. Additionally, slippage limits only protect you from the worst outcomes—a skilled attacker can still execute a profitable attack within your slippage tolerance, resulting in a worse price than you would have received without the attack.

For most traders, slippage settings are a reasonable first line of defense and should be adjusted based on the volatility of the token pair and network conditions. However, they are not a complete solution because they only prevent you from executing at extremely poor prices, not from being targeted by attacks at all.

Protection Method 2: Private RPC and Private Mempools

A more robust protection is using a **private RPC (Remote Procedure Call) endpoint** or **private mempool service** that hides your pending transactions from public view. Instead of broadcasting your transaction to the public mempool where bots can see it, you send it directly to a private endpoint or a pool of builders that keep it confidential until it's included in a block. Services like Flashbots Protect and similar MEV-minimizing services offer this functionality.

Private RPC services work by creating a direct channel between you and the block builders or validators who will include your transaction. Your transaction remains hidden from public mempool scanners and sandwich bots, so attackers cannot see your trade in advance and cannot front-run it. This approach removes the transparency that makes sandwich attacks possible in the first place. The tradeoff is that you're trusting the private RPC provider not to exploit your transaction themselves, though reputable services have reputational and business incentives to behave honestly.

Private RPC solutions are increasingly popular among DeFi users and traders because they provide strong protection without requiring complex strategies. However, they are not universally available on all chains or through all protocols, and adoption is still growing. For chains like Ethereum with mature MEV protection infrastructure, private RPC is a strong option. For smaller or newer chains, availability may be more limited.

MEV-Resistant Solutions and Ecosystem Adoption

The broader DeFi ecosystem is developing technical solutions designed to resist sandwich attacks at the protocol level. **MEV (Maximal Extractable Value)-resistant protocols**, such as batch auctions and encrypted mempools, aim to make sandwich attacks economically impractical or technically infeasible. Some DEXes implement batch auctions where transactions submitted during a time window are executed in a randomized order, eliminating the advantage of front-running. Other protocols use encryption schemes that keep transaction details hidden until the block is finalized, preventing attackers from seeing them in advance.

**Application-level solutions** include threshold encryption, where transaction data is split and encrypted until a threshold of participants decrypt it, and sequencing services that order transactions in ways resistant to MEV extraction. **Rollups** like Optimism and Arbitrum also reduce sandwich-attack vulnerability by relying on a single sequencer, though this introduces different centralization and security trade-offs. Some newer layer-2 protocols are experimenting with encrypted mempools and decentralized sequencing to further reduce MEV exposure.

The ecosystem has also responded with real infrastructure. Flashbots, a research and infrastructure organization, built early MEV-mitigation tooling that is now integrated into many wallets and DEX aggregators, making private transaction routing accessible to everyday users. Tools like MEV-Share let users capture a share of the value their own order flow creates, and researchers have proposed mechanisms such as burning a portion of extracted MEV to change the underlying incentives, though adoption of these newer ideas is still early. Institutional and high-volume traders commonly rely on private RPC or MEV-minimizing services, and independent research groups have estimated that MEV extraction, including sandwich attacks, removes a substantial amount of value from DeFi users every year — though precise figures vary by methodology and network, and these protocol-level solutions are still maturing.

Risks and Limitations of Protection Methods

While protection methods are effective, each has limitations worth understanding. **Slippage settings** can reject legitimate transactions during volatile markets and don't eliminate attacks within your tolerance level. **Private RPC services** require you to trust a centralized or semi-centralized provider—if that provider is dishonest or compromised, it could extract MEV itself or expose your transaction data to attackers. There's also a risk that smaller private RPC providers may lack the liquidity or builder relationships to execute trades optimally.

**Protocol-level solutions** face adoption challenges and may introduce new security assumptions or trade-offs. Batch auctions can result in worse execution if your transaction is separated from favorable market conditions by several batches. Encrypted mempool solutions add complexity and latency. Rollups and other layer-2 solutions introduce their own MEV considerations. Additionally, protection measures only address sandwich attacks specifically—you may still face other MEV extraction vectors like displacement attacks or liquidation manipulation.

No single protection method is perfect for all scenarios. Most experienced traders use a combination of approaches: moderate slippage settings, private RPC for larger trades, and protocol selection based on MEV-resistance characteristics. The most important limitation is that MEV protection is still not universally accessible on all chains and for all users, creating unequal protection depending on where you trade and what tools you use.

Practical Takeaways for Traders

To protect yourself from sandwich attacks, start with these practical steps. **First, set reasonable slippage limits** on decentralized exchanges—typically 0.5% to 1% for stable pairs and up to 2% for more volatile tokens. This prevents the worst-case outcomes. **Second, use private RPC services** like Flashbots Protect for larger trades or whenever available through your wallet or DEX interface. Many major wallets and DEX aggregators now offer built-in access to MEV protection without requiring technical setup.

**Third, be aware of network conditions and avoid trading during extreme congestion**, since this increases both attack profitability and normal market volatility. **Fourth, use DEX aggregators that account for MEV** rather than optimizing purely for best quoted price, as they can route trades through MEV-resistant protocols or private mempools. **Fifth, consider the chain and protocol you're using**—some have more mature MEV protection infrastructure than others. If you're transacting on a chain with established MEV solutions like Ethereum, your exposure is generally lower than on chains without such infrastructure.

**Finally, stay informed about protocol updates and new MEV solutions.** The ecosystem is evolving, and new tools and protections are regularly being deployed. For most casual traders, using private RPC through your wallet combined with reasonable slippage settings provides solid protection. For high-frequency or very large traders, more sophisticated strategies combining multiple protections and protocol selection become worthwhile.

Frequently Asked Questions

Conclusion

Sandwich attacks are a significant challenge in DeFi, representing a hidden cost that affects traders across major blockchain networks. By understanding how these attacks work and implementing practical protections—combining slippage settings, private RPC services, and MEV-aware protocol selection—you can substantially reduce your exposure to this threat. As the DeFi ecosystem continues to evolve with better protocol-level MEV solutions, sandwich attacks will likely become harder to execute at scale, but staying informed about new tools and best practices remains essential for protecting your trades.

This article is for educational purposes only and does not constitute financial advice.