Designing Against Extraction: Protocol-Level Responses to the MEV Problem

In 2019, a team of researchers coined the term "Miner Extractable Value" to describe a phenomenon that practitioners had long observed but rarely named: the ability of block producers to profit by reordering, inserting, or censoring transactions within the blocks they produce. The terminology has since evolved—"Maximal Extractable Value" better reflects the post-merge Ethereum landscape—but the underlying dynamic has only grown more consequential. MEV is no longer a marginal concern. It is, by most measures, a defining structural feature of contemporary blockchain economics, and one that protocol designers can no longer afford to treat as an externality.

This article does not argue that MEV can be eliminated. The more defensible position—and the one that informs the most serious current research—is that MEV can be bounded, redistributed, and structurally contained. The question for protocol engineers is which containment strategies are technically viable, what they cost in performance and complexity, and whether they are consistent with the decentralization properties that justify building on public blockchains in the first place.

Understanding MEV as a Protocol Design Problem

MEV arises from a structural asymmetry: block producers have privileged knowledge of pending transactions and the unilateral ability to determine transaction ordering within their proposed blocks. In a competitive DeFi environment—where arbitrage opportunities, liquidation events, and sandwich attacks can generate substantial profit within a single block—this privilege is economically significant.

The extractable value does not appear from nowhere. It is transferred, often invisibly, from ordinary users to sophisticated actors who have invested in the infrastructure to identify and capture it. Arbitrageurs running optimized bots, validators with proprietary transaction ordering pipelines, and relay networks that bundle profitable transaction sequences all participate in an economy that the average protocol user neither understands nor benefits from.

From a protocol design perspective, this creates three distinct problems. First, it introduces a regressive economic dynamic where users bear costs they cannot observe or anticipate. Second, it creates incentives for validators to engage in behaviors—including time-bandit attacks and selective censorship—that undermine chain security. Third, it concentrates block-building capability among a small number of technically sophisticated actors, which is structurally at odds with decentralization.

Proposer-Builder Separation: Structural Containment

The most widely adopted response to MEV at the infrastructure level is Proposer-Builder Separation, or PBS. The core insight behind PBS is straightforward: if the entities that build blocks are distinct from the entities that propose them, the worst forms of extraction—particularly those that require validators to actively construct advantageous orderings—can be structurally limited.

Under PBS, specialized block builders compete to construct the most profitable block body, submitting sealed bids to proposers. Proposers select the highest bid without seeing the block's contents until after commitment, reducing their ability to engage in selective extraction. Ethereum's current MEV-Boost implementation approximates this model at the middleware layer, with full in-protocol PBS remaining an active area of research under the ePBS proposals.

The design is effective at redistributing MEV revenue—much of it flows to validators as bid premiums—but it does not eliminate extraction. It relocates the extraction capability from validators to a smaller, more specialized set of block builders. Critics argue, with some justification, that this represents a centralization of a different kind: the PBS market on Ethereum mainnet is dominated by a handful of builders, creating concentration risk that is arguably worse than a distributed validator set engaging in opportunistic ordering.

For protocol teams considering PBS implementations, the key design variable is the competitive structure of the builder market. A PBS architecture that supports many competing builders with low barriers to entry is meaningfully different from one that, through technical or capital requirements, concentrates building among a few dominant players.

Threshold Encryption and Encrypted Mempools

A more radical approach to MEV mitigation targets the information asymmetry at its source. If pending transactions are encrypted and only decrypted after ordering is committed, the informational advantage that enables front-running and sandwich attacks disappears. This is the premise behind encrypted mempool designs.

Threshold encryption schemes distribute decryption keys across a committee of validators such that no single party—and no colluding minority below a defined threshold—can decrypt transactions before they are included in a block. Once the block is finalized and ordering is committed, the committee collectively reveals the decryption keys and transactions become readable.

The implementation challenges are substantial. Threshold decryption introduces latency: the committee must coordinate to produce decryption shares, which adds rounds of communication to the block production pipeline. For high-throughput networks where block times are already measured in hundreds of milliseconds, this overhead is non-trivial.

There is also a liveness concern. If committee members fail to provide decryption shares—whether through technical failure or adversarial behavior—transactions may remain permanently encrypted. Robust liveness guarantees require careful committee design and fallback mechanisms that themselves introduce complexity.

Projects including Shutter Network and Penumbra have explored practical encrypted mempool implementations with varying degrees of production readiness. The theoretical properties are compelling; the engineering path to production deployment at scale remains an open research problem.

Fairness Ordering and the FCFS Question

A third category of MEV mitigation focuses not on information concealment but on ordering rules. Fair ordering protocols attempt to define and enforce a canonical transaction ordering that is resistant to manipulation—most commonly, something approximating first-come-first-served based on observed arrival times.

Avalanche's research on fair ordering and Chainlink's Fair Sequencing Services represent practical efforts in this direction. The fundamental challenge is that "arrival time" in a distributed system is not a well-defined concept. Different nodes observe transactions at different times, and an adversary can exploit this ambiguity.

Time-based fairness also interacts uncomfortably with geographic distribution. Validators physically closer to high-frequency trading infrastructure will consistently observe certain transactions before geographically distant validators, creating a structural advantage that no software-level ordering rule can fully eliminate.

The Decentralization Constraint

Every MEV mitigation strategy described above involves tradeoffs with decentralization. Encrypted mempools require committee infrastructure. PBS concentrates block building. Fair ordering requires coordination mechanisms. The pattern is consistent: extracting MEV is technically easy; containing it without centralizing something else is genuinely hard.

This suggests a principle for protocol designers: MEV resistance should be treated as a design constraint from the outset, not retrofitted onto an existing architecture. Networks that launch without MEV mitigation and attempt to add it later face significant coordination challenges, as any mitigation that reduces extraction also reduces revenue for the actors—validators, builders, searchers—who have built businesses around the existing system.

The more promising path is to design protocols where the economic incentives of validators are aligned with user fairness from the beginning. This requires treating MEV not as a peripheral concern for the mempool team, but as a core variable in consensus design, validator economics, and peer-to-peer architecture. The networks that get this right will be meaningfully more trustworthy—and more defensible as public infrastructure—than those that do not.