Sandwich Attacks and Front-Running on Uniswap: How Mempools Expose Your Transactions

A user submits a swap on Uniswap, intending to exchange $50,000 worth of ETH for a token with moderate liquidity. Within seconds, the transaction sits pending in the Ethereum mempool, visible to validators, searchers, and bots monitoring network activity. Before the user’s transaction executes, a competing transaction is placed ahead of it, moving the price upward. After the user’s swap settles at a worse rate, another transaction immediately follows, capturing the difference. This is a sandwich attack, and it costs users millions annually across DeFi.

The attack exploits a fundamental vulnerability in how decentralized exchanges work on transparent blockchains. Unlike centralized exchanges, which process orders in private databases, Uniswap transactions must be broadcast to the network before miners or validators include them in a block. That broadcast window creates an opportunity for extraction of what researchers call Maximal Extractable Value, or MEV. For traders on Uniswap V2 and V3, this risk is quantifiable and often ignored until a position becomes large enough to matter.

How the mempool exposes Uniswap transactions to observation

When a user initiates a swap on Uniswap, the transaction is not instantly private. It must be broadcast to the Ethereum network, where it enters the mempool—a temporary holding area where validators and other network participants can see pending transactions before they are included in a block. That visibility is by design: it allows the network to validate transactions before commitment. But it also creates a time window where the transaction details, including the token pair, direction of trade, and minimum acceptable output, are knowable to anyone monitoring the network.

A searcher or bot monitoring the mempool can observe the incoming transaction and calculate its likely impact on the liquidity pool. On Uniswap, all pools are public and their state is completely transparent. A bot can model the price movement that would result from a large swap, determine the slippage the user will absorb, and recognize an opportunity for profit. This is not hacking or theft in the traditional sense. The bot is not stealing private keys or funds. It is using information that is already available on a public blockchain to execute a profitable trade ahead of or after the user’s transaction.

The economics depend on transaction ordering. Validators and sequencers (on Layer 2 networks) have the power to order transactions within a block or batch. A searcher or MEV bot can pay a higher fee or use other incentives to encourage a validator to place its transaction first. This reordering can happen transparently within the rules of the protocol, making it technically difficult to prevent through client-side changes alone. The user believes they are making a simple swap; from the validator’s perspective, it is one transaction among many competing for block space, and the highest fee or best offer wins.

For large trades, the impact is measurable. A $500,000 swap on Uniswap V3 with moderate liquidity might slip 0.5 to 2 percent due to the pool’s mathematical formula. A sandwich attack can extract an additional 0.2 to 1 percent or more, depending on liquidity depth and the attacker’s confidence in the trade. For a $50,000 transaction, that might represent $100 to $500 in direct loss. Across thousands of daily trades, the aggregate extraction is substantial.

Sandwich attacks on Uniswap V2 and V3: mechanics and differences

Uniswap V2 and V3 both use automated market makers, but their fee structures and concentration patterns create different sandwich attack surfaces. In Uniswap V2, all trades on a pair use the same 0.3 percent fee by default, and liquidity is distributed uniformly across the full price range. A sandwich attacker on V2 can estimate the price impact of a pending swap by running a simulation locally. The attacker then places a transaction ahead of the victim’s, trades into the pool to push the price in the direction that worsens the victim’s output, waits for the victim’s transaction to execute at that worse price, and places a third transaction behind it to exit the position and pocket the difference.

Uniswap V3 introduces concentrated liquidity, allowing liquidity providers to specify a price range in which their capital operates. This can increase capital efficiency for narrow ranges, but it also creates steeper price impact curves. A smaller pool of liquidity in a given range means that the same trade size causes larger price movements. This paradoxically can make sandwich attacks more profitable: a smaller trade by the attacker can move the price further, the victim’s transaction suffers greater slippage, and the attacker’s back-run is easier to execute profitably. The concentrated liquidity may also mean fewer market makers in key price ranges, reducing competition that might otherwise provide better execution.

V3’s multiple fee tiers—0.01 percent, 0.05 percent, 0.30 percent, and 1 percent—add another layer. A user who does not carefully select the correct fee tier might end up using less liquid pools, either accepting worse execution or becoming more attractive to sandwich attacks because their transaction will have more visible price impact. The protocol does not force users to choose optimally; the choice is the trader’s responsibility, and mistakes create opportunities for extraction.

Both V2 and V3 are vulnerable because their transactions are ordered by validators and sequencers based on fee auctions, not on arrival time or user preference. A searcher willing to pay a higher fee or use advanced techniques such as private ordering services can jump the queue. The attack does not require breaking the protocol. It requires understanding the mempool, modeling price movements accurately, and having faster access to block-building infrastructure than the average user.

MEV extraction and why it persists across DeFi

Maximal Extractable Value, or MEV, is the profit that can be obtained by reordering, inserting, or censoring transactions. On Uniswap and other DeFi protocols, MEV extraction happens daily at scale. Estimates place annual MEV extraction on Ethereum alone in the hundreds of millions of dollars, with sandwich attacks representing a significant portion. This value does not disappear; it is transferred from traders to those with the best access to block-building infrastructure, which typically means large searchers, validators, or specialized MEV extraction services.

The persistence of MEV reflects a deeper structural issue: as long as transaction ordering is auctionable and transactions are public before execution, profit opportunities will be exploited. Validators have no incentive to refuse profitable arrangements. Users have weak bargaining power. The only real solution requires either hiding transaction details until after they are ordered, or removing the incentive to reorder transactions in the first place. Neither is trivial on a transparent, decentralized blockchain.

Some protocols have attempted to address MEV through encrypted mempools or threshold encryption, where transactions remain encrypted until a block is finalized. Others use threshold encryption where validators collectively agree not to see transaction details until after ordering is complete. These approaches have trade-offs: they may add latency, reduce transparency, or require coordination among validators. On Ethereum Layer 1, where Uniswap processes significant volume, neither solution has been widely adopted.

The alternative is to accept MEV as a cost of using transparent, permissionless infrastructure and to build protocols and user interfaces that mitigate it. This is where tools like slippage limits, transaction timing, and alternative architectures such as intent-based protocols become relevant. But the starting point is acknowledging that every transaction on Uniswap V2 or V3 is vulnerable to observation and reordering, and that the cost of this vulnerability should be calculated by any user making a large trade.

Slippage protection and its limits on Uniswap

Uniswap’s user interface and most trading frontends allow users to set a slippage tolerance before submitting a swap. Slippage tolerance is a percentage below the expected output that the user is willing to accept. If the actual output falls below that threshold, the transaction reverts and does not execute. This is a useful tool, but it is not a defense against sandwich attacks.

A sandwich attacker is aware of slippage tolerance settings in some cases, or can simply optimize their attack to stay just within the user’s tolerance. A 1 percent slippage tolerance might seem reasonable, but it can be breached by even a small sandwich attack if the pool is thin. More importantly, slippage protection only prevents execution; it does not prevent the user from seeing their transaction rejected at the moment they need it most. A rejected swap might occur when the user urgently needs to trade, and raising slippage tolerance to guarantee execution means accepting greater losses to sandwich attackers.

The second weakness is that slippage tolerance is set at the user interface level, not at the protocol level. A user might set 0.5 percent tolerance, but if the interface itself is vulnerable to manipulation or if the user is confused about acceptable slippage, they might increase the tolerance without fully understanding the cost. Sandwich attackers rely on this confusion and can design their attacks to extract value right at the boundary of the user’s tolerance.

Slippage tolerance is therefore a necessary but insufficient control. It protects against extreme outcomes caused by unusual market conditions or failed transactions, but it does not address the core vulnerability: the ability of a third party with block-building access to observe and front-run the user’s trade. The real solution requires either hiding transactions or changing the execution model entirely.

UniswapX and intent-based architecture as MEV protection

Recognizing these vulnerabilities, the Uniswap team launched UniswapX, an intent-based protocol that fundamentally changes how swaps are executed. Instead of broadcasting a traditional transaction to the public mempool, a user creates an intent—an off-chain message describing what they want to achieve. That intent is not public. It is sent to a small set of solvers, who compete to fill the intent at the best possible price without the intent being visible to the broader network.

The key advantage is that the user’s trade details are not visible in the mempool until after execution. A sandwich attacker cannot observe the pending transaction and front-run it because the transaction only appears on-chain after a solver has already committed to filling the intent. This removes the primary attack vector. UniswapX also offers gasless swaps, where the user does not pay gas fees directly; instead, solvers incorporate the gas cost into their pricing. For a user swapping on Ethereum mainnet, this can represent meaningful savings while also providing better execution through competitive routing across multiple solvers.

The trade-off is centralization on execution. Unlike Uniswap V2 and V3, where anyone can be a maker or taker, UniswapX relies on a set of solvers to fulfill intents. If solvers collude or if their number shrinks, execution quality might degrade. The protocol mitigates this through incentives for solver competition and by allowing users to fall back to traditional routing if they distrust current solvers. But the user is accepting some reliance on a smaller group of entities rather than the fully permissionless execution of Uniswap itself.

UniswapX is not a silver bullet. It protects against sandwich attacks on the user’s initial swap, but once the tokens are acquired, they are on a public blockchain. If the user then needs to swap those tokens for something else, that next swap faces the same MEV risks unless it also goes through UniswapX or a similar service. For DeFi power users and institutions trading large amounts, UniswapX represents a significant improvement. For small retail trades, the benefit may be less obvious, and users may choose traditional uniswap routing for simplicity.

Layer 2 networks and their impact on sandwich attacks

Uniswap operates on Ethereum Layer 2 networks including Arbitrum, Optimism, Base, and Polygon. These networks promise lower fees and faster finality, but their impact on sandwich attacks is mixed. Some Layer 2 solutions, particularly those with a single sequencer, actually increase sandwich attack risk. A sequencer is the entity responsible for ordering transactions in a batch before posting them to Ethereum. If the sequencer is the only entity with access to the full mempool, it gains complete ordering power and can conduct or permit sandwich attacks with impunity.

Optimism and Arbitrum have historically used single sequencers, though both have roadmaps to decentralize this role. Until sequencer decentralization is complete, users on these networks accept some centralized ordering risk. That said, MEV extraction may be lower in absolute terms because gas costs are so much cheaper. A sandwich attack that extracts $100 in value might cost $10 in fees, leaving $90 profit. On Ethereum mainnet, the same attack might cost $50 in fees, leaving only $50 profit, making marginal attacks less worthwhile. So the lower fees might actually reduce sandwich attack incentives, even if the risk is not technically eliminated.

Polygon, which uses a set of validators rather than a single sequencer, distributes ordering power more broadly. This can reduce any single entity’s ability to sandwich all transactions, but Polygon’s lower cost and higher throughput also mean that smaller sandwich attacks become viable. Base, built on Optimism’s stack, inherits similar dynamics. The key takeaway is that moving to Layer 2 does not automatically solve MEV problems; it redistributes them. A user should understand which sequencer or validator set they are trusting and whether that entity has incentives to conduct or permit sandwich attacks.

For traders concerned about sandwich attacks and MEV, Layer 2 solutions might reduce fees enough to offset the extraction cost, but they do not eliminate the risk. UniswapX is available on these networks as well, offering the same intent-based protection. The best outcome for users is to combine Layer 2 cost reduction with intent-based execution where possible, rather than assuming that simply moving to a cheaper network eliminates MEV exposure.

Practical mitigation strategies for Uniswap traders

For users trading on Uniswap V2 or V3, several strategies can reduce sandwich attack risk without requiring complete protocol changes. The first is to break large trades into smaller transactions executed over time. A $500,000 swap split into ten $50,000 transactions over an hour reduces the profit potential for any single sandwich attack and makes the pattern less obvious to automated searchers. The cost is higher total gas fees and potential slippage from price movements between transactions, so this trade-off must be evaluated case by case.

The second strategy is to use private transaction routing through services that do not broadcast to the public mempool. Some wallets and protocols integrate Flashbots Protect or similar services that send transactions to block builders directly rather than to the public mempool. This does not eliminate MEV extraction—the builder still sees the transaction and can sandwich it—but it reduces the number of third parties who can observe and compete for the opportunity. The drawback is that this route introduces a new intermediary and a small risk that the private transaction service could fail or be unavailable.

The third strategy is to use UniswapX for swaps where MEV protection is worth the trade-off of relying on solver competition. UniswapX is not available for every token or trading pair, but for major tokens on Ethereum and Layer 2 networks, it is an available option. Users should be aware that solvers may have different execution quality, and occasionally a swap through UniswapX might be worse than a traditional route if solvers are not competing aggressively for a specific pair.

The fourth strategy is to carefully choose the pool and fee tier when trading on Uniswap V3. More liquid pools and lower fee tiers typically have tighter spreads and less slippage, which reduces both legitimate market impact and opportunities for sandwich attackers. Checking several pools and fee tiers before committing to a trade can reveal which execution route offers the best combination of price and security. This is a simple analysis that most retail users do not perform, but it is within reach of anyone willing to check one or two alternatives.

Finally, users should maintain realistic slippage tolerance settings. A 0.1 percent tolerance on a major pair with deep liquidity might be appropriate and safe; the same tolerance on a small cap token might cause frequent reversions and frustration. The goal is to set tolerance high enough that legitimate execution succeeds, but low enough that potential sandwich attacks have limited room to operate. No setting is perfect, but a thoughtful choice is better than a default.

The future of MEV and Uniswap’s role in solving it

The long-term trajectory of sandwich attacks and MEV extraction depends on protocol-level changes that are still in development. Ethereum is not currently implementing encrypted mempools or threshold encryption schemes, but research continues on approaches such as Threshold Encryption, MEV-burn, and order flow auctions. Some of these mechanisms might eventually be deployed, fundamentally changing how MEV is distributed or eliminated. Until then, users must rely on mitigation strategies and alternative protocols like UniswapX.

Uniswap’s governance through the UNI token gives token holders a voice in the protocol’s future direction. Decisions about whether to integrate further MEV protection, support encrypted transactions, or encourage adoption of UniswapX are ultimately community decisions. That governance structure is a strength in theory—it gives the protocol’s users a stake in its evolution—but it also means that progress on MEV is subject to community consensus and may not move quickly.

Meanwhile, competing DeFi protocols are also developing MEV solutions. Some chains are experimenting with decentralized ordering protocols, others are building encrypted mempool designs, and still others are scaling transaction throughput so severely that MEV becomes economically marginal. Uniswap’s dominance and first-mover advantage make it a target for innovation, but they do not guarantee that it will remain the best option for every user. Over the next few years, the protocol that best balances security, cost, and decentralization will likely capture the most trading volume.

For users today, the message is clear: sandwich attacks and MEV extraction are real, quantifiable costs when using Uniswap V2 and V3 on any blockchain where transactions are publicly ordered. These costs are not random failures or network degradation; they are systematic profit opportunities being captured by entities with better information and ordering access. Users can reduce exposure through transaction splitting, private routing, slippage management, and the use of intent-based protocols like UniswapX. But the fundamental vulnerability remains inherent to transparent, decentralized exchanges until the underlying infrastructure changes.