Skip to main content

MEV Protection on Ethereum: Prevent Sandwich Attacks and Execution Manipulation

Overview​

Maximal Extractable Value (MEV) is an inherent property of public blockchain systems like Ethereum. It arises from the ability of block producers and external actors to observe, reorder, insert, or censor transactions prior to finalization.

This creates a structural risk for users: a transaction can be valid, signed, and successfully included on-chain, yet still produce an economically unfavorable outcome due to adversarial interference.

This page explains how MEV works, why existing mitigation strategies are insufficient, and how a constraint-based execution model can provide stronger guarantees.

What is MEV?​

MEV refers to the maximum value that can be extracted from block production beyond standard transaction fees. This value is typically captured by actors who monitor pending transactions and strategically manipulate ordering.

Common MEV strategies include:

  • Sandwich attacks: inserting transactions before and after a target trade to extract price impact
  • Front-running: executing a similar transaction ahead of a known pending transaction
  • Back-running: reacting to a transaction to capture arbitrage or liquidation opportunities

These strategies are enabled by the public visibility of the mempool, where transactions are broadcast before inclusion in a block.

The Core Issue: Lack of Execution Guarantees​

Ethereum guarantees that valid transactions will be executed according to the state at the time of inclusion. However, it does not guarantee that the execution outcome aligns with the user’s expectations at the time of signing.

This creates a gap between:

  • Intent: the expected economic result when the transaction is created
  • Execution: the actual result at the time of inclusion

Examples of this gap include:

  • Receiving significantly fewer tokens than expected in a swap
  • Executing at a worse price due to intermediate state changes
  • Being adversely impacted by transaction reordering

The protocol enforces correctness of execution, but not correctness of outcome.

Sandwich Attacks in Detail​

A sandwich attack exploits predictable price impact in automated market makers (AMMs).

The sequence is as follows:

  1. An attacker detects a pending swap in the mempool
  2. The attacker submits a transaction that executes before the target, moving the price
  3. The victim’s transaction executes at a worse price
  4. The attacker submits a second transaction to revert the price movement and capture profit

The attacker’s profit is derived directly from the victim’s slippage.

Limitations of Existing MEV Mitigations​

Private Transaction Submission​

Private RPC endpoints and relay systems prevent transactions from being broadcast to the public mempool.

  • Reduces visibility to generalized searchers
  • Does not eliminate all forms of MEV
  • Does not enforce execution constraints

A transaction can still execute under unfavorable conditions if the state changes between simulation and inclusion.

Slippage Parameters​

Users can specify a maximum acceptable deviation in execution (e.g., 1–5% slippage).

  • Provides a bounded tolerance
  • Still allows losses within that bound
  • Does not account for complex multi-step manipulation

Slippage is a soft constraint evaluated at execution time, not a guarantee of economic outcome.

Interface-Level Warnings​

Wallets and interfaces may display warnings about potential risks.

  • Improves user awareness
  • Requires manual interpretation
  • Does not affect transaction execution

Warnings do not prevent adverse outcomes.

Reframing MEV as an Execution Integrity Problem​

Most mitigation strategies focus on reducing transaction visibility.

However, visibility is only one dimension of the problem.

The fundamental issue is that:

Transactions are allowed to execute even when the resulting state violates the user’s original intent.

This suggests that MEV should be addressed at the level of execution conditions, not just transaction propagation.

A Constraint-Based Approach to MEV Protection​

A more robust model introduces explicit execution constraints that must be satisfied for a transaction to be included.

This approach consists of:

  1. Pre-execution simulation
    The transaction is simulated against current state to estimate expected outcomes.

  2. Constraint definition
    The user (or an automated system) defines acceptable bounds, such as:

    • minimum output amounts
    • maximum price impact
    • invariant conditions on balances or state

  3. Signed intent
    These constraints are cryptographically bound to the transaction.

  4. Enforced inclusion
    The transaction is only included in a block if all constraints are satisfied at execution time.

If any constraint is violated, the transaction is not executed.

Preventing Sandwich Attacks with Constraints​

A sandwich attack relies on altering execution conditions between submission and inclusion.

Under a constraint-based model:

  • Any adverse price movement reduces output below the minimum threshold
  • This violates the defined constraint
  • The transaction becomes ineligible for inclusion

As a result, the attack fails to extract value, because the victim’s transaction does not execute under manipulated conditions.

Combining Private Order Flow and Enforcement​

Effective MEV protection requires both:

  • Controlled transaction propagation: limiting exposure to adversarial actors
  • Deterministic execution conditions: ensuring outcomes remain within defined bounds

Private order flow reduces the attack surface.

Constraint enforcement eliminates execution under invalid conditions.

Together, they provide stronger guarantees than either approach alone.

Applicability​

Retail Users​

  • Protection against silent value extraction
  • Reduced need to understand MEV mechanics

Advanced Users​

  • Precise control over execution conditions
  • Ability to define strict invariants for complex transactions

Institutional Participants​

  • Alignment with pre-trade certainty requirements
  • Mitigation of execution risk in large transactions
  • Improved auditability of transaction outcomes

Conclusion​

MEV is not solely a consequence of transaction visibility. It is a consequence of allowing transactions to execute without enforcing the conditions under which they were intended.

Mitigation strategies that rely only on hiding transactions or warning users are insufficient.

A constraint-based execution model addresses the problem at its source by ensuring that:

  • transactions execute only when predefined economic conditions are satisfied
  • adverse state changes invalidate execution rather than degrade outcomes

This shifts the paradigm from best-effort execution to enforceable intent, providing a more robust foundation for secure transaction processing on Ethereum.