Demystifying Modular MEV: How to Achieve Fair Transaction Ordering?
TechFlow Selected TechFlow Selected
Demystifying Modular MEV: How to Achieve Fair Transaction Ordering?
The reason for building modularly should not be merely to fit a narrative, but because it enables better, more efficient, and more customizable applications.
Navigating Web3 tides with focused insightsAuthor: Maven11
Translation: Luffy, Foresight News
In the first two parts of this series, we focused primarily on the technical issues arising from stack splitting and the improvements needed in a modular world. We have covered many ongoing efforts to address problems that naturally emerge in cross-domain setups. However, in this final installment, we want to shift our focus more toward user experience. We aim to explore how modularity, customization, and specialization can help create better applications. This concluding chapter will examine the exciting and unique creative possibilities within modularity—possibilities that allow developers to build Web2-like user experiences with Web3 verifiability.
The reason for building modular systems should not be merely to fit a narrative or to pursue modularity for its own sake, but because it enables us to build better, more efficient, and highly customizable applications. When constructing modular and specialized systems, numerous unique capabilities naturally arise—some obvious, others less so. Our goal here is to provide an overview of modular system capabilities you may not yet know about, such as scalability.
We believe one key capability that modularity offers developers is the ability to build highly customizable, specialized applications that deliver superior end-user experiences. We've previously discussed the ability to set rules or re-order transaction execution sequences.
Verifiable sequencing rules (VSRs) represent one particularly interesting opportunity offered by controlled sequencing—especially for developers interested in building "fairer" trading systems in terms of execution. Clearly, topics related to liquidity provider losses versus rebalancing (LVR) are beyond the scope of this article, so we'll avoid delving deeply into them. Keep in mind that the mechanisms we’ll discuss are primarily aimed at AMMs rather than order book models. That said, CLOBs (and even CEXs) could greatly benefit from leveraging VSRs tailored to their specific environments. In off-chain settings, some concept of zero-knowledge or optimistic execution—backed by cryptoeconomic security—would clearly be required.
VSRs become especially interesting when we consider that most retail users have not (and likely won’t) adopt protective measures. Most wallets and DEXs also lack implementations of private mempools, private RPCs, or similar mechanisms. The majority of trades are submitted directly through front-ends—whether via aggregators or native DEX interfaces. As a result, unless the application itself actively intervenes in how orders and flows are processed, the execution quality experienced by end users is often suboptimal.
The role of VSR becomes evident when we examine where transaction supply chain sequencing occurs. It lies in the hands of specialized participants—the entities responsible for ordering or including transactions—typically based on auctions or base fees. This sequencing is crucial: it determines which transactions get executed and when. Essentially, whoever controls sequencing holds the power to extract MEV, usually in the form of priority fees (or tips).
Thus, designing rules governing how sequencing is handled—so as to offer fairer trade execution for end users (particularly in DEX contexts)—could prove highly valuable. However, if you're building a general-purpose network, you should generally avoid enforcing such rules.
Moreover, certain forms of MEV—such as arbitrage and liquidations—are essential to healthy markets. One idea is to establish a “highway” lane at the top of each block, reserved exclusively for whitelisted arbitrageurs and liquidators who pay higher fees and share a portion of their profits with the protocol.
In the paper titled "Trustworthy Decentralized Exchange Design via Verifiable Sequencing Rules", Matheus V., X. Ferreira, and David C. Parkes propose a model in which block sequencers are constrained by a set of executable sequencing rules—and these constraints are publicly verifiable. In case of non-compliance, observers can generate fault proofs (or, given that the constraints are mathematically verifiable, one could imagine a ZK circuit encoding these rules, using ZKPs as validity proofs). The core idea is to provide end users (i.e., traders) with execution price guarantees. Such guarantees ensure that a trade’s execution price is no worse than what would be achieved if it were the only trade in the block (clearly, there's some latency involved here, assuming a first-come-first-served buy/sell/buy/sell ordering). The fundamental premise of the proposal is that sequencing rules restrict builders (in a PBS context) or sequencers from including trades in opposing directions unless they offer better prices than those available at the top of the block. For instance, if a sell follows a sequence of buys (e.g., buy, buy, buy, sell), the sell might be disallowed—indicating potential manipulation by searchers (or builders/sequencers) exploiting earlier purchases to move prices in their favor. This essentially means the protocol ensures users aren't used to generate better prices for others (i.e., MEV), nor suffer slippage due to priority fees. Obviously, a downside of such rules (especially when sells outnumber buys or vice versa) is that users might receive relatively poor tail-end prices.
For general smart contract platforms, implementing such rules purely as on-chain constructs is nearly impossible, since you cannot control execution or ordering. Additionally, you’re competing with many others, making it unnecessarily costly to force those at the top of blocks to pay priority fees. One advantage of modular architectures is that they allow application developers to customize how their execution environment operates—whether through sequencing rules, different VMs, or customized modifications to existing VMs (like adding new opcodes or adjusting gas limits). Ultimately, these choices depend entirely on the developer and their product needs.
In a rollup leveraging data availability, consensus, and liquidity settlement layers, a possible architecture might look like this:
Another intriguing idea is transaction splitting. Imagine a pool where large orders (prone to high slippage) are executed. How should such large trades be processed? Would it be fair to end users if these trades were split across consecutive blocks—or executed at the end of a block if compliant with VSR?
If an end user cares about latency, they likely wouldn’t want their order split. However, this scenario is relatively rare. Optimizing for transaction splitting on large orders could lead to significantly more efficient executions for the vast majority of users. A concern remains that MEV searchers might detect these sequential trades and position their own trades before or after them. Still, due to the small size of split trades spread across multiple blocks, the total extractable MEV value would likely be much lower.
Another fascinating concept we mentioned earlier is the use of Frequent Batch Auctions (FBA), advocated by Eric Budish and colleagues, which processes trades in batches rather than serially. This helps uncover demand coincidence (CoW) and integrates arbitrage opportunities into market design. It also helps counter latency games inherent in sequential block building (or priority fee wars in serial blocks). Special thanks to Michael Jordan (DBA) for highlighting this paper and his work moderating Latency Roast. Implementing FBA as part of a rollup’s fork choice and sequencing rules presents another compelling configuration available to developers. We’ve seen growing interest in this approach over the past year, notably from projects like Penumbra and CoWSwap. A possible setup could look like this:
In this model, there is no first-come-first-served access or gas priority wars. Instead, at the end of each interval between blocks, a batch auction clears based on accumulated orders.
Generally speaking, as most trading shifts to non-custodial, on-chain environments, FBAs may offer one of the more effective methods for genuine price discovery—depending on block timing. Leveraging FBAs also reduces front-running significantly, since all large orders are batched and remain hidden until the auction closes (assuming some cryptographic setup). The uniform clearing price is critical here, as reordering trades becomes meaningless.
It’s worth noting that designs similar to what we just described were already discussed back in 2018 on the Ethresear.ch forum (see here). In that post, two papers were referenced proposing batch auction mechanisms on Plasma (a sort of precursor to modern rollups), where each batch accepted orders to buy other ERC20 tokens up to a maximum price. Orders were collected over fixed time intervals and settled at uniform clearing prices across all token pairs. The overarching idea behind this model was to eliminate the widespread front-running seen in popular AMMs.
Another important point: in such setups, sequencers may require incentives to execute—and enforce—these rules. This is often overlooked, yet much of blockchain infrastructure is operated by professional firms whose costs differ drastically from those of average home users. Generally, incentives are a vital component of secure infrastructure deployment. When incentives align with rule enforcement, sequencers and builders are more likely to invest greater effort. This implies such ecosystems should also foster active markets. Clearly, these markets tend toward centralization, as the capital costs of specialization can be high. Thus, the smartest (and wealthiest) players may consolidate and specialize to capture as much value as possible. Here, exclusive order flow can act like a knee-jerk arrow toward centralization. A baseline fee alone may suffice, but it doesn’t truly drive participants toward specialization. Therefore, you may want to introduce incentive mechanisms suited to your specific context—mechanisms that leave traders satisfied with outcomes.
This is obvious to many, but still worth mentioning when discussing sequencing at the rollup level. If you control sequencing, you can more easily "capture" value generated by the protocol. This stems from your power to re-sequence transactions—typically based on priority fees, akin to MEV-boost-style setups on most L1s. It allows you to collect priority fees paid by sophisticated on-chain actors extracting value. These actors are often willing to pay substantial amounts—up to the point where extraction no longer yields profit. Yet currently, most rollups rely primarily on first-come-first-served mechanisms. Most MEV extraction happens via latency races, placing severe strain on rollup infrastructure. For these reasons, we expect to see increasing numbers of rollups adopting sequencing frameworks incorporating priority fees (e.g., Arbitrum’s time-based enhancement mechanism).
Another example we appreciate is Uniswap. Currently, the Uniswap protocol generates significant inefficiencies. These inefficiencies are exploited by MEV-seeking participants (engaging in arbitrage at the expense of liquidity providers). Meanwhile, these actors pay substantial fees to extract value—but none of this value flows back to the Uniswap protocol or its token holders. Instead, much of this extracted value is funneled via MEV-Boost to Ethereum proposers (validators) as priority fees, granting them the right to include transactions in value-capturing blocks. Thus, despite abundant MEV opportunities in Uniswap order flow, none are captured by Uniswap itself.
If Uniswap could control sequencing within its protocol—and gain the ability to extract priority fees from searchers—it could monetize this flow, potentially redistributing some profits to token holders, liquidity providers, or others. With Uniswap’s evolution (e.g., UniswapX) shifting toward off-chain execution (with Ethereum serving as the settlement layer), such a mechanism appears increasingly feasible.
Assuming a rollup with partial PBS mechanics, the order flow and monetization process might look like this:
From this, the monetization model for rollup sequencers and proposers might follow this formula:
PoS issuance + fee revenue (+priority) - cost of DA, state publishing, storage
A good way to visualize how much value is currently being extracted on Ethereum—especially via arbitrage—is available at Mevboost.pics, which provides a clear overview of how much value can actually be extracted from inefficiencies.
Additionally, separating priority fee bidding wars from on-chain structures allows MEV extraction to be contained within execution environments, helping mitigate supply chain disruptions. However, if leader election occurs at the rollup level, most MEV will be extracted there, leaving little room for underlying layers—unless the DA layer captures value, settlement layer priority fees stem from liquidity aggregation, or other economies of scale apply.
To clarify, many of these structures can function purely off-chain, without requiring any verified bridges or strong security guarantees. Still, trade-offs must be made. We’re beginning to see more of these emerge—both visible and invisible. One key point: modular setups do not necessarily imply rollups.
The sequencing rules discussed above exemplify how fine-tuning infrastructure can dramatically improve the applications built atop it.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
