MEV and Private Order Flow: The Sandwich Attack Didn't Disappear, It Just Changed Hands

1. MEV Is Not a Hidden Tax — It Is the Price of Ordering Power

Maximal Extractable Value describes a simple structural fact: whoever controls the sequence in which a batch of transactions gets included in a block can extract additional value purely from that control over ordering. It is not a separate tax bolted onto normal blockchain activity — it is the market price attached to ordering power itself, the same way a scarce resource commands a price wherever it grants leverage over an outcome.

A common mistake among researchers new to this area is treating MEV as an anomaly, a bug that a sufficiently clever protocol redesign should eliminate outright. That framing misses the underlying mechanics. As long as reordering, inserting, or excluding transactions within a block can be made profitable, some form of MEV will exist — because the profit opportunity is a direct function of having ordering discretion, not of any particular implementation detail. The question worth asking was never "does MEV exist," which is trivially yes; it is "who is positioned to capture it, and through what specific mechanism does that capture happen."

This matters because the answer to that second question has shifted meaningfully over time, and tracking that shift is where actual research value lives. A prior article in this series, covering DEX liquidity and swap pricing, already established how automated market maker price impact creates the underlying profit opportunity that sandwich attacks exploit — a large trade moves price along a curve, and that movement is predictable and therefore front-runnable. This article does not re-derive that mechanism. Instead it goes one level deeper: the full three-step structure of a sandwich attack, and — more importantly — how the method by which a transaction gets submitted to the network changes who is actually in a position to execute that attack at all.

• MEV = the price the market puts on control over transaction ordering, not an external tax
• Eliminating MEV entirely is not realistic; the real research question is capture and mechanism
• This article extends, rather than repeats, the AMM price-impact mechanics covered previously in the series

2. Decomposing the Sandwich Attack: More Than Just Front-Running

A sandwich attack is often described loosely as "front-running," but it is more precisely a three-transaction structure with a specific internal logic. First, the attacker observes a pending victim transaction — a swap of meaningful size on an AMM pool — and inserts their own transaction immediately before it, buying the same asset in the same direction. This pushes the pool price upward before the victim's trade executes. Second, the victim's transaction then executes at this now-inflated price, absorbing price impact that would have been smaller, or avoidable altogether, had the attacker's transaction not been placed first. Third, the attacker immediately sells the position acquired in step one, capturing the price differential as profit, effectively "sandwiching" the victim's trade between two of their own.

The variable that determines how much an attacker can safely extract is the victim's configured slippage tolerance — the maximum price deviation the victim is willing to accept before their transaction reverts. A tighter tolerance caps how large a front-run trade the attacker can insert without pushing price past the victim's threshold and causing their own transaction to fail (which would forfeit the attacker's profit). A looser tolerance directly expands that addressable window.

Consider a purely illustrative example: a victim sets 3% slippage tolerance on a swap. An attacker calculates that a front-run trade sized to move the pool by roughly 2.5% still leaves the victim's transaction executable, so they size their insertion right up to that boundary — capturing the difference between the pre-attack price and the post-attack price on both legs. Had the victim set 0.5% tolerance instead, the attacker's safe insertion size — and therefore their extractable profit — would have been substantially smaller. All figures here are invented purely to illustrate the causal relationship, not observed data.

• Step 1: attacker buys ahead of the victim, pushing price up
• Step 2: victim's trade executes at the inflated price
• Step 3: attacker sells immediately after, realizing the spread as profit
• Slippage tolerance is the single largest lever on attacker-addressable profit size

3. Private Transaction Channels "Solved" Public Front-Running — and Created a New Problem

The most primitive version of a sandwich attack requires the attacker to observe a victim's pending transaction in a public mempool — the shared waiting area where submitted transactions sit visible to anyone before being picked up by a block producer. Private transaction channels changed this by letting a user submit a transaction directly to a specific block builder rather than broadcasting it publicly, bypassing the public mempool entirely.

This genuinely eliminates one category of attack: a random opportunistic observer scanning the public mempool for profitable insertion targets no longer has anything to see for transactions routed privately. That is a real improvement, and it is why private order-flow channels have become a common recommendation for larger trades.

But the improvement is narrower than it sounds. Removing public visibility does not remove ordering power from the system — it relocates that power. The transaction is still being ordered by someone; it has simply moved from "anyone watching the public mempool" to "the specific block builder that receives this private order flow and now has exclusive visibility into it." A builder that receives private flow is structurally capable of doing exactly what a public front-runner did — inserting its own transactions around the private one — except now with a monopoly on the information rather than competing against every other observer.

This is not a new pattern for this series. It closely mirrors the hidden-intermediary concentration risk already explored in the context of vote-aggregator platforms and restaking operator concentration — a small number of intermediaries end up holding disproportionate leverage over an outcome that users assumed was decentralized. Here, what concentrates is not custody of assets or voting weight, but informational advantage over transaction ordering, and the execution power that advantage confers. A researcher evaluating private-channel safety should therefore ask not "is this transaction visible publicly" but "who is now the exclusive party who can see it, and what obligations, if any, bind their behavior."

• Private submission removes public-mempool visibility, closing off opportunistic public front-running
• It does not remove ordering power — it concentrates that power in the receiving builder
• Structurally parallel to intermediary-concentration risk already seen in vote-market and restaking research

4. Under Proposer-Builder Separation, Who Actually Decides Transaction Order

Proposer-builder separation (PBS) is an architectural category worth understanding in the abstract, independent of any specific implementation. Under this model, the role of assembling a block's transaction contents is split from the role of proposing that block to the network. Block builders compete against each other to construct the most valuable possible bundle of transactions — valuable in the sense of maximizing combined user-paid fees plus any extractable MEV embedded in the ordering — and then pay the block proposer for the right to have that particular bundle included as the next block.

The practical consequence is that the entity actually deciding which transactions are seen, in what order, and with what insertions around them, is frequently not the base protocol's consensus mechanism at all — it is whichever builder wins that block's competition. Proposers, in this model, are largely price-takers accepting the highest-paying bundle rather than active curators of transaction order.

This has a direct research implication: builder market concentration is not a side detail, it is the structural variable that determines how much practical ordering power sits in how few hands. If a small number of builders consistently construct the large majority of blocks over a sustained period, that concentration is itself a risk worth flagging — regardless of whether any individual builder has done anything provably improper. Concentrated ordering power creates the standing capability for coordinated or systematic extraction even absent evidence of a specific incident.

This is the same verification logic this series has applied elsewhere to operator and aggregator concentration: the question is never "has this intermediary misbehaved yet," but "how much unchecked capability does its position grant it, and how many independent entities actually hold that position." Applied to builders, that means tracking market share distribution over time rather than treating PBS as a solved, neutral background mechanism.

• PBS splits block assembly (builder) from block proposal (proposer)
• Builders compete on total extractable value; proposers largely accept the highest-paying bundle
• Builder concentration, not any single transaction, is the structural risk metric to track

5. What a Researcher Can Actually Verify: From "Does MEV Exist" to "Who Does It Go To"

Given that MEV in some form is close to a structural constant, the more useful research posture is to stop asking whether any single transaction was affected by it — the answer is almost always yes to some degree — and start asking where the extracted value ultimately ends up. Three concrete, trackable angles follow from that reframing.

First, builder share over time: what fraction of total blocks does a given builder construct, and how has that distribution shifted across recent periods? A stable, top-heavy distribution is a different risk profile than a fragmented, rotating one, even if neither shows evidence of active misconduct. Second, sandwich-attack frequency trends: as the mix of public-versus-private transaction submission has shifted in a given ecosystem, has observable sandwich-attack frequency moved with it, and in which direction? A drop in observable attacks alongside a rise in private submission volume is consistent with relocation of the capability, not elimination of it, and is worth stating explicitly rather than assuming the metric improved for the reason it appears to. Third, rebate and profit-sharing design: does a given private order-flow channel or builder arrangement return any portion of captured value back to the originating transaction or the end user, versus retaining it entirely for the bots and builders involved in extraction?

None of these three angles requires resolving the philosophically harder question of whether MEV is "fair." They are observable, comparable across channels, and directly relevant to whether a user routing a transaction through a particular private channel is meaningfully better off than one left in the public mempool, or merely trading one extractor for another with better manners.

• Track a given builder's share of total blocks over time, not just its existence
• Track sandwich-frequency shifts against the public/private submission mix, not in isolation
• Check for any rebate or profit-sharing mechanism returning value to the originating transaction

6. Common Misconceptions and Methodology Scope

Three misconceptions recur often enough in this area to flag explicitly. The first is assuming that adopting a private transaction channel means MEV has been eliminated from the user's activity. What has actually happened, per Section 3, is a reallocation: extraction capability has moved from an open field of public-mempool observers to a concentrated set of builders with exclusive visibility. Treating that as "solved" skips the step of asking who holds the concentrated capability now.

The second is fixating on whether a single transaction was sandwiched as the unit of analysis, rather than examining builder concentration as the structural metric that actually governs systemic risk, per Section 4. A transaction-by-transaction audit can show "clean" outcomes indefinitely while the underlying concentration of ordering power keeps growing — the individual-transaction lens simply cannot see that trend.

The third is treating slippage tolerance as purely the system's fault when a sandwich attack occurs, rather than recognizing it as a variable substantially within the user's own control with a direct, quantifiable causal link to an attacker's addressable profit, per Section 2. A looser tolerance is sometimes a deliberate and reasonable trade-off against transaction failure risk in volatile conditions — but it should be understood as a trade-off being made, not an externally imposed vulnerability.

This article is confined to abstract mechanism categories: how ordering power creates value, how sandwich attacks are structured, how private submission and proposer-builder separation redistribute who holds that power, and what a researcher can concretely measure about that distribution. No real exchange, block builder, relay, or wallet product is named or implicated anywhere in this analysis, and no figures presented are drawn from live data — all numeric examples are explicitly invented to illustrate a mechanism. Nothing here constitutes investment advice or a claim about any specific platform's current practices.

• Private channels reallocate MEV-extraction capability; they do not eliminate it
• Builder concentration is the structural metric; single-transaction outcomes are not a substitute for it
• Slippage tolerance is a user-controlled variable with a direct, measurable causal link to attacker profit