Thanks to Alex Stokes for suggesting this topic and discussion about it.
The Ethereum public mempool, the traditional gateway for all transactions, is facing a decline in usage. The reason is the rise of MEV, where sophisticated actors can profit from transactions while they're pending. In response, the community have devised innovative ways to mitigate the negative effects of MEV. One strategy involves redesigning applications to delay sending transactions to the public mempool until potential MEV is minimized. This is achieved through offchain transaction optimization, and currently, 22% of swaps use these redesigned applications. Additionally, users are increasingly opting for private transactions, completely bypassing the public mempool. They do this to either avoid MEV entirely or get its value returned to them. Currently, about 10% of transactions use this method. I believe both trends will intensify. The future likely lies in MEV-optimized applications seamlessly integrated with private transactions, maximizing user benefit. Ultimately, the public mempool may become a niche tool primarily used for transactions requiring the highest level of censorship resistance, even if it means suffering the negative consequences of MEV.
Don't worry if that introduction seemed confusing, I'll break everything down and explain it in a clear way 🫡
In this post I’ll explain:
How the Ethereum transaction process originally worked.
Why MEV led to the creation of new transaction pathways.
How new applications are designed to minimize MEV.
Methods for bypassing the public mempool via private transactions (private RPCs, OFAs).
The role of L2s and future Ethereum upgrades.
Why the public mempool will only have a niche role for censorship resistance.
Let's start by giving an overview of how the transaction supply chain originally worked and briefly go over what MEV is and how it changed everything. Originally there was only one way for a transaction to land onchain, your wallet would format your transaction, and you'd sign and broadcast it to an Ethereum node (either your own or a service like Infura or Alchemy). These nodes would gossip the transaction to their connected peers, creating a network wide pool of pending transactions called the public mempool. You can view the current live public mempool here. In PoW, miners would then fill blocks with the highest gas-paying transactions and compete to find the "golden nonce" to propose the block. However, the public mempool's transparency creates an issue. While your transaction awaits confirmation, it's visible to everyone, including sophisticated actors who can exploit this visibility for profit, leaving the sender of the transaction worse off. This is called MEV, and because of it the transaction landscape had to be changed.
In PoS, the validator that’s randomly selected to propose a block has a temporary monopoly over the transactions that go into a block and can extract higher yields than just issuance and gas fees. This is done by strategically reordering, including, or excluding transactions to benefit themselves. This poses a serious risk: if one actor becomes exceptionally good at MEV extraction, they could attract a disproportionate amount of validator stake. They could create a staking pool, offering higher yields to stakers and thereby attracting more stake. This would lead to significant centralization within the validator set and undermine Ethereum's core principle of trustlessness.
To combat this, the transaction supply chain was redesigned with proposer-builder separation (PBS). While the exact workings of PBS aren't crucial for this post, it's important to understand that any validator can now also run a piece of software created by Flashbots called MEV-Boost, giving them access to sophisticated entities called builders who create blocks and bid to have their blocks included onchain by the randomly selected validator. There’s also an entity in the supply chain called searchers that specialize in finding profitable MEV opportunities and bid to have their bundles included in the builders' blocks. However, PBS doesn't address the ways builders can exploit the public mempool to extract MEV from users. In fact, it further entrenches MEV in the ecosystem, since running MEV-Boost is economically rational for validators, more users are likely to feel the consequences of MEV. If you do want a deeper understanding of PBS, you can refer to my post: Ethereum Proposer Builder Separation: Past, Present, and Future.
The public mempool remains a prime target for searchers. These sophisticated actors analyze pending transactions and can insert their own transactions to profit at the expense of users – think sandwich attacks, DEX/CEX arbitrage, or exploiting offchain knowledge about NFTs. With around 90% of validators running MEV-Boost it's clear that MEV remains a major issue for users. But this doesn't mean users and developers have been passive. Far from it, they've been actively developing strategies to counter MEV's negative effects.
The playbook for users to avoid the negative effects of MEV is simple: avoid the public mempool. There are two main approaches to accomplish this, which can also be used together for maximum benefit. The first is to use “MEV-optimized” applications where you express and sign your intent offchain (e.g., the trade you want to make). This intent is analyzed and only submitted to the public mempool (potentially as multiple optimized trades) when it minimizes MEV risk. The second strategy is to send your transaction directly to a builder, bypassing the public mempool entirely. This limits searchers' ability to exploit your transaction. The MEV-optimized applications I previously introduced could also submit their transactions directly to builders for even greater MEV protection. Let's break these down further.
All transactions included in L1 blocks via the public mempool are vulnerable to MEV. Ethereum's 12 second block times create a window for exploitation, but some applications are particularly prone to MEV extraction. AMMs, particularly those designed like Uniswap V2, are major sources of MEV. In fact, 98.85% of extracted MEV has come from just three AMMs: Uniswap V2 (63.4%), Balancer V1 (19.39%), and Uniswap V3 (16.06%). Their design allows searchers to profit from slippage. In simplified terms, slippage is the difference between your desired swap price and the actual executed price. When you submit a swap transaction to the public mempool, searchers can manipulate the order to ensure you receive the worst possible price within your specified limit, profiting from this price difference. However, there are app designs that mitigate this issue by using offchain intents to optimize transactions before they hit the public mempool.
These swapping applications that limit MEV are known as DEX aggregators. While their specific designs vary (like 1inch, Matcha, or the upcoming UniswapX), the overall principle is the same: you express your trading intent offchain and it’s analyzed and executed onchain in a way that minimizes slippage and MEV risk. There are two common approaches. The first is smart routing, where you submit your intent (e.g., swap 1 ETH for 3,500 USDC) to a server. It analyzes liquidity across multiple AMMs and devises an optimal trade route, potentially splitting your order across exchanges for the best price. The goal is to minimize potential slippage, making MEV extraction unprofitable for searchers. The second approach is offchain order matching, used by systems like CoW Swap. Here decentralized "solvers" match buyers and sellers offchain, and then execute these matched orders onchain in batches to save gas costs. Think a decentralized order book. Both methods introduce some degree of trust in the offchain components, as they could theoretically fail to execute your order or go offline. Despite this tradeoff, DEX aggregators are gaining popularity, currently representing 22% of total DEX volume. This share is likely to grow as users become more aware of the price benefits compared to swapping directly on a single AMM, where they often pay higher costs due to additional fees (like the Uniswap frontend fee), slippage, and hidden MEV costs. We can expect further innovation in MEV-optimized app design, building on the foundation laid by these early examples.
Now let's break down the second way users can avoid the public mempool: private transactions. These transactions capitalize on the fact that builders now create 90% of Ethereum blocks. Instead of broadcasting your transaction to the public mempool, you send it directly to a builder or group of builders. There are two main approaches within private transactions: private RPCs and OFAs (Order Flow Auctions).
An example of a private RPC is Flashbots Protect. Unlike broadcasting transactions to the public mempool, Protect submits them directly to selected builders, shielding them from the view of frontrunning searchers. Builders may share limited transaction details with certain searchers to facilitate inclusion, but this information is insufficient for frontrunning and restricts them to backrunning strategies only. Since its inception, Protect has protected over 13 million transactions and has processed nearly $30 billion in DEX trading volume.
Flashbots Protect further benefits users with MEV-Share, an integrated Order Flow Auction (OFA, I’ll explain OFAs in more detail in the next paragraph). MEV-Share auctions backrunning opportunities among searchers, returning a significant portion of the MEV extracted from your transaction. The trade-off is that limiting the number of builders or the amount of back run MEV you tolerate can potentially slow down your transaction's inclusion onchain. MEV-Share has refunded over over 360 ETH across 10.5k transactions.
OFAs build upon the concept of a private RPC and add an auction component. The defining characteristic of OFAs is that they aim to refund most of the MEV extracted from your transaction back to you. Users submit their orders (transactions or intents) to an auctioneer, where MEV searchers compete to execute them. While searchers can still use MEV strategies, competition within the auction drives them to bid aggressively, allowing the bulk of the MEV proceeds to flow back to you. With MEV-Boost, most of the value extracted from MEV flowed to validators, but OFAs shift this dynamic to benefit the users who generate the value. This realignment is generally considered a more fair outcome. For example, consider a large swap on Uniswap where you want to trade 100 ETH for 350,000 USDC. If submitted directly, MEV bots could manipulate the order to cause significant slippage, potentially resulting in you receiving only 320,000 USDC. However, in an OFA, searchers will compete to execute this trade, bidding up the amount of slippage they're willing to return to you. This competition could result in bids where searchers offer to return, say, $29,000 back to you (minus fees taken by the auctioneer). As a result, you might end up receiving 349,000 USDC (320,000 from the swap and 29,000 as an MEV refund), dramatically reducing the negative impact of MEV. OFAs are a relatively new concept and are still under development. While originally pioneered in 2021 by the now-closed project Rook, they are currently offered in various forms by projects like UMA's Oval and Flashbots' MEV-Share. Continued innovation will likely bring greater refinement to OFA models and potentially address challenges like centralization or potential trust assumptions.
Currently, around 10% of transactions are sent privately, bypassing the public mempool. You can see this trend on mempool.pics. I believe this number will continue to grow. With the financial incentives of MEV refunds or avoidance, why would users choose to expose their transactions on the public mempool? It's a matter of increasing awareness and improving the designs of OFAs and private RPCs. In the long term, I envision MEV-optimized apps like DEX aggregators integrating with private RPCs and/or OFAs to further benefit users. While they aim to minimize MEV, it can't be fully eliminated, so returning the remaining MEV to users (via OFAs) is a logical next step.
So, is the public mempool dead? Not entirely. There's more to consider, especially with Ethereum's rollup-centric roadmap. How do L2s and future upgrades factor into this equation?
When you submit a transaction on an L2, it's typically forwarded from an RPC service like Alchemy or Infura to the L2's centralized sequencer. If your transaction has sufficient gas, the sequencer will bundle it with others and submit the batch to L1 to update the L2's state. Depending on the design of the rollup it's mempool can be public (queried through the RPC service) or private (visible only to the sequencer itself). However, regardless of the mempool's visibility, the sequencer has full control over transaction ordering, creating the potential for MEV extraction. However, to date, L2 sequencers have generally honored their commitments to avoid this practice. But even if the sequencer chooses not to extract MEV on L2 itself, if their mempool is public, searchers may still be able to leverage information from the mempool to extract MEV on L1. While this centralized sequencer model reduces MEV on the L2, it also creates a significant risk of censorship.
Centralized sequencers can censor transactions. This was demonstrated during a recent hack on an application built on the Blast blockchain on March 27th. The hacker stole $63M, but Blast's sequencer blocked the hacker's transactions, preventing them from cashing out and moving the tokens off the rollup. Left with no other option, the hacker surrendered their private key to the Blast team. The Blast team then used this private key to submit and process a transaction (on behalf of the hacker) that recovered the stolen funds. While this example highlights how censorship can work in the protocol's favor, it also underscores the risks of centralization. It weakens the system's credible neutrality. Long-term, a reliance on centralized sequencers poses significant risks, especially on the regulatory side.
While the future is uncertain, many L2s will likely move towards decentralizing the sequencer role. This decentralization, even if not achieving the same level of permissionlessness as Ethereum validation, remains crucial for credible neutrality. However, it also reintroduces MEV risks. How MEV will evolve in this new landscape is unclear, but we can build off of the lessons we've learned on L1. The development and use of apps that minimize MEV leakage will undoubtedly continue to rise. As a user, preference will always lean towards systems that offer protection from excessive MEV extraction. L2s understand this, and I anticipate they will design systems that limit public mempool use and incorporate MEV redistribution or auction mechanisms similar to those on L1. Additionally, the “private transaction space” is continuing to innovate, with solutions like Flashbots SUAVE potentially playing a significant role in shaping the future of L2 MEV mitigation and harnessing.
It's important to remember that all of this is speculation. Another way rollups could potentially decentralize the sequencer is to have a permissioned sequencer set controlled by the rollup's DAO. DAOs could have the power to kick sequencers off the set if they're caught extracting MEV or censoring transactions. The future of decentralizing the sequencer remains an open question, and different rollups will likely approach this problem in different ways. If this problem interests you, I'd recommend checking out StarkNet's community forums where they're tackling this problem in the open and accepting community input.
There's a specific type of rollup with a unique design that deserves its own analysis: Based Rollups. Many in the Ethereum community, including Justin Drake, see them as the maximally credible neutral solution for L2s, potentially addressing the sequencer centralization challenge I was just describing. These rollups leverage Ethereum's existing transaction supply chain for sequencing and proposing L2 blocks. L1 block builders take on the role of what current L2 sequencers do, ordering L2 transactions and submitting blocks (along with proofs, if applicable) to update the rollup's state on the L1 smart contract. The exact implementation of the transaction supply chain, including the presence of a public or private mempool, varies across Based Rollup construction. Taiko, the first Based Rollup, will launch with a public mempool similar to Ethereum's. This simplifies the launch process, but reintroduces MEV risks. When you send a transaction on Taiko, it goes to a Taiko node for verification and then is broadcasted to other Taiko nodes, creating a public mempool that L1 builders can query. Long-term, I believe Based Rollups will evolve away from public mempools to further mitigate MEV. They might adopt private RPC approaches, implement OFAs, or utilize systems like Flashbots SUAVE, which offers a form of encrypted mempool that significantly differs from the fully transparent public model.
If you stopped reading here you might think the public mempool is as good as dead due to MEV risks. Well, the public mempool's role will actually evolve, serving a specific, less frequent, but vital purpose: maximizing censorship resistance. For the absolute highest guarantee of transaction inclusion using the public mempool is the best option. Transactions sent via private RPCs bypass the public mempool entirely, meaning validators who don't run MEV-Boost and outsource block building will never see them. While this is currently a minority (around 10% of validators), these validators do not censor at all and simply include the transactions that pay the highest gas price in a block.
Currently, a majority of relays (entities that pass blocks and bids from builders to validators) engage in censorship, refusing to forward blocks containing transactions from OFAC sanctioned addresses. If you want to send a transaction from one of those addresses and use a private RPC to avoid the public mempool, validators who don't run MEV-Boost won't see it. In this scenario, you'll rely on a non-censoring relay winning the proposed block, potentially leading to a longer wait time. While a non-censoring relay will likely include your transaction eventually, submitting it to the public mempool would generally lead to faster inclusion as it's visible to validators who don’t run MEV-Boost in addition to all the builders. Additionally, there's the risk of relays that currently don’t censor also adopting censorship. Ultimately, the public mempool remains the strongest tool for maximizing censorship resistance. If you're sending a transaction from an address that faces potential censorship, accepting the negative effects of MEV might be a necessary trade-off to ensure timely inclusion, or in the worst case, inclusion at all.
Ethereum's future upgrades might significantly impact public mempool usage. One exciting proposal gaining traction is inclusion lists, this upgrade might be included in the upcoming Pectra hard fork. This aims to strengthen censorship resistance by giving MEV-Boost running validators more control over transaction selection. Essentially, blocks would include a new "inclusion list" specifying transactions that must be included in the next block. If the next block doesn't contain all the transactions in the inclusion list then the block is invalid. This enforces a certain level of compliance among validators. The transactions on these lists would come from the public mempool, potentially solidifying its role as a censorship resistance tool.
It's important to note that Ethereum client implementations could offer customizable options for censorship. Certain clients may allow users to configure filtering mechanisms to prevent certain transactions from being included in inclusion lists. Despite this potential for optional client-level censorship, the very existence of inclusion lists forces builders to respect them. Validators defying inclusion lists risk having their blocks rejected, leading to missed rewards. This economic incentive, along with the likely large presence of non-censoring clients, helps mitigate censorship, uphold resistance principles, and strengthen the public mempool's role as a place for transactions needing maximum censorship resistance.
Another potential change to Ethereum's transaction flow is the Execution Tickets upgrade. This upgrade offers various benefits like smoother validator rewards, improved trustlessness for liquid staking protocols, L1 preconfirmations for Based Rollups, an easy to implement MEV burn, and more. However, our main concern is how it affects the public mempool. Execution Tickets change the system by removing validators ability to build blocks locally. It introduces an inprotocol lottery system that does two things: it sells "tickets" granting holders a chance to propose the transaction list for a block, and it randomly selects winning tickets. Holders of winning tickets can propose a block and their ticket is consumed. This change eliminates the previous advantage of the public mempool where a non-MEV-Boost validator could locally build and propose blocks in a credibly neutral way. However, Execution Tickets will still work with inclusion lists. Validators will still publish their inclusion lists, and the following execution ticket winner must include those transactions or their block is invalid. Therefore, the public mempool retains its value as a censorship resistance tool. If a transaction is in the public mempool it’s likely to be included in an inclusion list, guaranteeing its inclusion in a future valid block.
Regardless of the future of Ethereum, whether users are on L1 or L2, which upgrades are included, or continued reliance on existing infrastructure, one trend is certain: MEV-optimized applications and private transactions will continue to rise. Users will increasingly seek out DEX aggregators, and private RPCs / OFAs, either individually or combined, to minimize MEV's impact. These advancements and further innovations will empower users and come close to eradicating the negative consequences of MEV for the vast majority.
However, the public mempool won't disappear entirely. It will evolve from a universal gateway to a niche tool, crucial for a specific use case: guaranteed censorship resistance. A small portion of users, prioritizing the fastest possible onchain inclusion for their “transaction facing potential censorship” over MEV minimization, will continue to leverage the public mempool. Here, transactions are visible to everyone. This transparency comes at a cost in the form of potential MEV extraction, but it prioritizes the core principle of censorship resistance.
