Private transaction routing is often presented as the answer to MEV sandwich attacks. If a transaction is hidden from the public mempool, an attacker cannot see it in time to trade before and after it.
Recent research makes that answer less comfortable.
One study examining Ethereum transactions from late 2024 identified 2,932 private sandwich attacks affecting 3,126 private victim transactions. It found that users often moved to private routing after being attacked publicly, but concluded that private channels did not guarantee protection. Sandwiched and Silent
Another study reached a more encouraging but narrower conclusion. Across the private Layer 2 mempools it examined, sandwich attacks were rare, generally unprofitable and largely absent. Without a public mempool and builder market, attackers had less certainty that the transactions needed for a sandwich would be included in the correct order. How to Serve Your Sandwich?
These findings are not necessarily contradictory. Private routing can make a sandwich attack much harder to coordinate. It does not make every transaction, private channel or execution environment immune.
At the same time, the legal status of some MEV behavior remains unsettled. In 2025, a federal jury could not reach a verdict in the case against Anton and James Peraire-Bueno. Prosecutors accused the brothers of exploiting Ethereum’s MEV-Boost infrastructure to take approximately $25 million from trading bots in 12 seconds. The defense argued that their conduct was a legitimate trading strategy in a competitive market. The judge declared a mistrial after the jury failed to agree on how fraud law applied to the conduct. Reuters
The brothers were not accused of carrying out a conventional sandwich attack against ordinary DEX users. They were accused of deceiving bots that were themselves pursuing MEV opportunities. The case nevertheless exposed how difficult it is to draw a clean legal boundary around transaction ordering, adversarial trading and onchain manipulation.
Together, the research and the court case bring us back to a more useful question:
What does an attacker actually need to profit from a sandwich attack, and what prevents the trade from working?
TL;DR
A sandwich attack places one transaction before a user’s trade and another after it, using the user’s transaction to make the sequence profitable.
The attacker needs more than visibility. The victim’s trade must still execute after the attacker moves the price.
Trade size relative to liquidity, pool fees and the user’s execution limits all affect whether an attack is profitable.
Private routing can reduce an attacker’s visibility and control over transaction ordering, but it is not a universal guarantee.
“MEV mitigation,” “MEV-resistant,” “MEV protection” and “sandwich immunity” do not mean the same thing.
Carbon DeFi maker orders provide sandwich immunity because the maker defines the executable price and cannot be forced to accept a worse one.
What Is an MEV Sandwich Attack?
MEV, or Maximal Extractable Value, refers to value that can be captured by controlling, anticipating or influencing the order in which blockchain transactions execute.
A sandwich attack is one form of MEV. It places a victim’s trade between two attacker transactions:
Front-run: The attacker trades before the victim, moving the market price against them.
Victim transaction: The victim’s trade executes at the manipulated price and receives fewer tokens than originally quoted.
Back-run: The attacker reverses the first trade after the victim’s transaction and keeps the difference.
The attacker’s profit comes at the user’s expense. The pool may end the sequence near its earlier state, but the user has already traded at a worse price.
Our earlier article, Understanding MEV Sandwich Attacks: Frequently Asked Questions, explains this process and the role public mempools, automated market makers and slippage play in making users vulnerable.
What Does an Attacker Need for a Sandwich Attack to Work?
Seeing a pending transaction is only the beginning. A profitable sandwich also requires the right economic and execution conditions.
The attacker needs to anticipate the victim’s trade and get one transaction ahead of it and another behind it. The price movement created by the victim must be large enough to cover the attacker’s pool fees, gas costs and other execution expenses.
The size of the victim’s trade matters, but not on its own. A $100,000 trade can be relatively small against deep liquidity and enormous against a shallow pool. What matters is the size of the trade relative to the liquidity available at the prices it will cross.
Most importantly, the victim’s transaction must remain valid after the attacker changes the pool state. If the transaction rejects the manipulated result, the attacker loses the victim trade needed to complete the profitable sequence.
That is where slippage tolerance and minimum return enter the attack.
What Does Slippage Have to Do With Sandwich Attacks?
When users submit swaps to an AMM, they usually specify the maximum difference they will accept between the quoted result and final execution. This is commonly called slippage tolerance.
The transaction also contains a minimum return: the smallest amount the user is willing to receive before the trade must fail.
If the user accepts a wide difference between the initial quote and minimum return, an attacker may have room to move the price while keeping the victim’s transaction executable. The attacker attempts to push the trade toward the worst result the user has already agreed to accept, then back-runs it.
A tighter minimum return leaves less room. If the attacker’s front-run pushes the result below that limit, the victim’s transaction reverts and the sandwich no longer works as planned.
This does not mean every transaction should simply use zero slippage. Prices can move naturally before a transaction executes, particularly in volatile or illiquid markets. A limit that is too tight can cause a legitimate trade to fail. The user is balancing successful execution against the amount of price deterioration they are willing to accept.
When Does a Sandwich Attack Become Unprofitable?
In The Forbidden Sandwich: A Theory of MEV-resistant CFMM Transactions, Dr. Mark Richardson examined the conditions under which the optimal front-running trade becomes zero — in plain English, the point at which the best decision available to the attacker is to leave the transaction alone.
The analysis identifies three relationships:
For a given trade size and liquidity reserve, there is a pool fee high enough to eliminate the attacker’s profit.
For a given liquidity reserve and pool fee, there is a maximum trade size below which an attack has no value.
For a given trade size and pool fee, there is a liquidity reserve deep enough to eliminate the opportunity.
The central insight is that absolute trade size is not the deciding factor. The important relationship is the trade size compared with the pool’s reserves.
A larger trade moves further through a shallow pool’s curve and creates more potential price movement for an attacker to exploit. Deeper liquidity reduces the effect of the same trade. Higher pool fees increase the cost of completing both sides of the attack.
These conditions can make an attack mathematically unprofitable within the model, but that does not automatically turn them into practical protections. Raising fees enough to deter an attacker can also make the user’s own trade expensive. Breaking a large trade into smaller transactions may reduce the value of each individual opportunity, but it can create additional transactions to monitor and execute. Adding liquidity is not something an individual trader can demand at the moment of a swap.
Minimum return takes another approach. Instead of changing the pool’s economics, it constrains the result the user will accept. If the manipulated trade no longer satisfies that condition, it cannot execute.
MEV protection is often described as though every method provides the same outcome. It doesn't.
What Do “MEV-resistant,” “MEV Protection” and “Sandwich Immunity” Mean?
The industry uses several overlapping terms for very different claims.
MEV mitigation
MEV mitigation is the broadest and most cautious term. It describes techniques intended to reduce MEV exposure, frequency or severity. Private routing, transaction batching, fair-ordering systems and tighter slippage settings can all fall into this category.
Mitigation does not promise that extraction is impossible.
MEV protection
MEV protection is the language users are most likely to encounter in wallets, RPC services and trading interfaces. It is an umbrella term rather than a consistent technical standard.
One product may use “protection” to mean that it routes a transaction away from the public mempool. Another may simulate transactions, restrict slippage, run an auction or reimburse certain losses. The protection can only be evaluated once the mechanism and its limitations are explained.
MEV-resistant or sandwich-resistant
Researchers and protocol developers often use “MEV-resistant” or “sandwich-resistant” to describe a design that makes an attack more difficult or unprofitable under stated conditions.
Resistance is not necessarily immunity. A system can resist one route, adversary model or transaction-ordering environment while remaining vulnerable under another. The assumptions are part of the claim.
MEV prevention
Prevention generally means stopping a specific attack from succeeding. It may apply to one transaction path or class of attacks without addressing every form of MEV.
Sandwich immunity
Immunity is the strongest and most specific claim. For a transaction to be sandwich-immune, an attacker cannot worsen that user’s execution by placing transactions around it.
Any claim of immunity should state exactly which user, transaction type and execution mechanism it covers. Saying that a protocol is broadly “MEV immune” would be much wider than saying its maker orders are immune to sandwich attacks.
Does Private Routing Prevent Sandwich Attacks?
Private routing addresses visibility and transaction ordering. Instead of broadcasting a transaction to the public mempool, it sends the transaction through a private relay, builder or sequencer path.
That can remove the easiest opportunity for public bots to observe and front-run the trade. It can also reduce the certainty that an attacker’s front-run, victim transaction and back-run will all execute in the required order.
The recent studies show why the answer still depends on the system being examined.
The research on private Ethereum transactions found documented private sandwiches and significant concentration among attackers. The Layer 2 study found that attacks in the private mempools it examined were rare and generally uneconomic because attackers could not guarantee the same atomic ordering available in Ethereum’s builder market.
Private routing can therefore provide meaningful mitigation. It should not be treated as proof that the trade itself cannot be manipulated.
A private route asks: Can the attacker see and position around this transaction?
An execution constraint asks: What result is this transaction permitted to accept?
Those are different parts of the problem.
Is MEV Illegal?
MEV is a category of transaction-ordering behavior, not one specific act. It includes activities such as arbitrage and liquidations as well as strategies that extract value from other users.
That makes “Is MEV legal?” too broad to have one answer. The relevant questions are what the actor did, whether deception or unauthorized access was involved, who suffered the loss and which laws apply in the relevant jurisdiction.
The Peraire-Bueno prosecution illustrates the uncertainty. Prosecutors characterized the alleged conduct as a deceptive scheme targeting trading bots. The defense described it as a legitimate strategy that outmaneuvered other bots in an adversarial market. After a four-week trial, the jury could not agree on whether the conduct met the legal requirements for wire fraud and money laundering, and the court declared a mistrial.
That outcome was not a finding that the conduct was legal. It also did not establish that sandwich attacks are categorically illegal. It left the central legal question unresolved.
For users, that unresolved status offers little protection. A trade can lose value to transaction manipulation regardless of whether a court later decides that the attacker committed a crime.
How Carbon DeFi Provides Sandwich Immunity for Makers
The approaches discussed above largely focus on protecting a user who submits a swap against an existing pool price.
Carbon DeFi makers operate differently. A maker creates an onchain order and defines the exact price or pricing curve at which their tokens are available. The maker is not asking an AMM to calculate a new execution price after earlier transactions have changed a shared pool state.
Someone can trade against the maker’s order, but they cannot force the maker to accept a worse price. If the order fills, the maker receives the result encoded in the order.
That is why Carbon DeFi describes its maker orders as immune to sandwich attacks rather than merely resistant. The claim is specific: a front-runner cannot worsen the maker’s execution price by trading before and after the fill.
This protection is native to the order’s execution. It does not depend on a private relay, oracle, keeper or hook. Carbon DeFi’s built-in solver helps orders get discovered and filled using liquidity from major DEXs chainwide, but the maker’s price remains the maker’s price.
For a broader introduction to the mechanism, see Understanding MEV Sandwich Attacks: Frequently Asked Questions. For the mathematical relationship among fees, liquidity depth and transaction size, see The Forbidden Sandwich: A Theory of MEV-resistant CFMM Transactions.
The Limits of Protection
Mitigation, protection, resistance and prevention differ in degree, but they all describe the same general objective: reducing the likelihood or impact of an attack. They express an intention—a hope that the safeguards are sufficient under the conditions in which they operate.
Immunity describes a technical limitation.
For a Carbon DeFi maker order, the protocol permits two outcomes: the order executes according to the maker’s predefined price, or it doesn't execute at all.
