Fair Ordering: Taming MEV on Ethereum
Maximal Extractable Value exists because whoever proposes a block also gets to choose the order of transactions inside it, and transaction order has economic value — a validator or a searcher who sees a large trade about to execute can insert their own transactions immediately before and after it to capture a predictable profit. This isn’t a bug in Ethereum’s design in the sense of a mistake; it’s a direct consequence of block proposers needing ordering discretion for reasons that have nothing to do with MEV, like batching and gas optimization. Every mitigation approach is, underneath its specific mechanism, an answer to the same question: who gets to constrain that ordering discretion, and how much of it do they give up.
Why ordering discretion is valuable in the first place
A block proposer isn’t given ordering discretion as an oversight — some ordering freedom is necessary for a chain to function efficiently at all, because proposers need to be able to prioritize by fee, batch compatible transactions, and exclude transactions that would fail. The same discretion that makes those legitimate optimizations possible is what makes extraction possible: nothing in the protocol distinguishes “reordering to improve batching efficiency” from “reordering to sandwich a trade,” because both are just permutations of the same transaction set, evaluated by the same proposer, for the same reward — a larger fee for the more profitable ordering.
The three mitigation strategies, and what each one gives up
Transparency and redistribution (Flashbots-style). Rather than trying to prevent extraction, make the process of extracting it transparent and competitive, and route some of the resulting value back to users or validators through an open marketplace for block space. This doesn’t reduce MEV; it makes its existence visible and its capture more evenly distributed than an opaque, validator-only free-for-all would be. The trade-off: extraction still happens, and the mechanism’s fairness depends entirely on the marketplace actually being open and competitive rather than dominated by a small number of sophisticated searchers.
Encryption until commitment (commit-reveal and threshold encryption). Hide transaction contents until after the ordering is fixed, so nobody — proposer included — can order transactions based on information they shouldn’t have yet. Public projects in this space (Shutter Network is one publicly known example) use threshold encryption so that transactions are only decrypted after a committee, rather than any single party, agrees the ordering is already locked in. The trade-off: this adds real latency and coordination overhead, and it only protects against extraction that depends on seeing a transaction’s contents before ordering — it does nothing against extraction that depends only on transaction timing and gas price, which are visible in the mempool regardless of payload encryption.
Fair-ordering rules enforced by protocol or consensus. Define what “fair” ordering means precisely enough that it can be checked or enforced — for instance, ordering strictly by time of arrival at a sufficiently large fraction of network observers, so no single party’s local view of transaction order determines the final sequence. The trade-off: defining “arrival order” precisely across a decentralized network with no single global clock is a genuinely hard distributed-systems problem, and any definition has to be robust against a party who controls enough of the network to manipulate what “arrival order” appears to be.
Where commit-reveal schemes actually help, and where they don’t
It’s worth being precise about what encryption-based approaches defend against, because it’s narrower than “MEV” as a whole. Sandwich attacks that depend on knowing what a pending swap will do — which pool, which direction, roughly what size — are exactly what encrypting transaction contents until commitment defeats, because the searcher can no longer read the trade they’d need to sandwich. Extraction that depends purely on transaction ordering and timing rather than content — a validator simply reordering already-visible transactions for their own benefit, or racing to front-run based on gas price alone — isn’t touched by content encryption at all, because there’s no secret content being hidden in the first place. A complete mitigation strategy generally needs both a content-hiding mechanism and an ordering-fairness mechanism, addressing two distinct attack surfaces, not one mechanism doing both jobs.
Comparison: mitigation approach versus what it actually constrains
| Approach | What it constrains | What it leaves open |
|---|---|---|
| Transparent, competitive block-space auctions | Who captures MEV, and how evenly | Whether extraction happens at all |
| Commit-reveal / threshold encryption | Ordering based on transaction contents | Ordering based on timing/gas price alone |
| Protocol-enforced fair-ordering rules | Ordering based on arrival sequence | Requires a robust, manipulation-resistant notion of “arrival” |
| Doing nothing | Nothing | Everything — proposer has full ordering discretion |
A worked example
A large swap enters the mempool on a public AMM. Under no mitigation, any searcher watching the mempool can see the swap’s direction and approximate size, submit a buy transaction immediately before it (pushing the price up) and a sell immediately after (capturing the price they pushed), extracting value directly from the original trader’s slippage. Under a commit-reveal scheme, the swap’s parameters are encrypted until after ordering is fixed — no searcher can read “this is a large buy of token X” in time to front-run it, because by the time it’s decrypted, its position in the block is already locked in. The trader’s economic exposure to this specific attack (sandwiching based on visible pending content) goes to zero; a validator simply choosing to deprioritize the trader’s transaction for unrelated reasons is a separate problem the encryption doesn’t address, which is exactly why ordering-fairness mechanisms are usually discussed as a complement to encryption rather than a replacement for it.
Limitations
No single mechanism described here eliminates MEV in the sense of making transaction ordering economically worthless to influence — each addresses a specific attack surface (visible content, arbitrary reordering) while leaving others partially or fully open. Threshold-encryption schemes also introduce a new trust assumption of their own: users have to trust that the decryption committee behaves as designed and doesn’t collude to reveal contents early, which trades one trust problem (a single proposer’s ordering discretion) for a different, hopefully smaller one (a committee’s honest-majority assumption).
FAQ
Does encrypting transactions eliminate front-running entirely?
No — it eliminates front-running that depends on reading a transaction’s contents before it’s included, but does nothing against reordering strategies that only need timing or gas-price information, which remain visible regardless of payload encryption. See the “where it actually helps” section above.
Is MEV always bad for users?
Not uniformly. Some MEV-adjacent activity — arbitrage that corrects a price discrepancy between two venues, for instance — improves market efficiency and isn’t obviously harmful to any specific user, even though it’s technically “value extracted from block ordering.” Sandwich attacks specifically targeting a known pending trade are the clearest case of MEV that has an identifiable victim; the category as a whole is broader and more mixed than that specific example.
How does FairFlow Protocol’s approach fit into this landscape?
FairFlow Protocol combines commit-reveal schemes with fair transaction ordering specifically to address both the content-visibility attack surface and the ordering-discretion attack surface together, rather than relying on either mechanism alone — see the FairFlow publication for the underlying approach, and the earlier post on the MEV problem for background on why fairer value distribution is the goal these mechanisms are aimed at.
Why hasn’t the ecosystem converged on one standard solution?
Because the three mitigation families make genuinely different trade-offs — added latency, new trust assumptions, or unresolved distributed-systems questions about what “fair” ordering even means precisely — and which trade-off is acceptable depends on the application. A protocol handling large trades where sandwich attacks are the dominant concern will weigh these differently than one where transaction timing manipulation is the bigger problem.
Bottom line
MEV isn’t a single problem with a single fix; it’s a family of extraction strategies that each exploit a different piece of a block proposer’s ordering discretion. Content encryption, transparent auctions, and protocol-enforced ordering rules each close off a different attack surface, which is why serious mitigation designs increasingly combine more than one of them rather than treating any single mechanism as sufficient on its own.