NGC Ventures: Exploring the Path of MEV Redistribution

Author: Tudd Cai, NGC Ventures

When it comes to MEV (Maximal Extractable Value), most users have a strong aversion to it. When we trade Meme coins on Uniswap, we set a high slippage to ensure we can buy and sell during extreme volatility, but this gives MEV bots the opportunity to front-run our trades. For example, when we were trading the popular MeMe coin PePe, we used ETH to purchase PePe. When a Searcher noticed this transaction, they would use higher gas fees to front-run the purchase of PePe, causing the price of PePe to rise, resulting in us acquiring fewer PePe than theoretically expected. The Searcher would then sell for a profit, and this process is known as a Sandwich Attack. As regular users, we can set a lower slippage, such as 0.1%, to limit the profit margin for front-running bots. However, setting the slippage too low can lead to large transactions failing easily, and we still have to pay fees. Users can also choose to increase gas fees, which raises the attack cost for bots, but this also increases their own transaction costs.

It is evident that users can easily become the relatively weaker party when facing MEV bots. However, for MEV bots, this does not mean they can reap profits at will by harvesting users. By default, all transactions are monitored in Ethereum's public mempool, and MEV Searchers check for opportunities to exploit these transactions. When multiple Searchers compete for the same transaction, MEV Builders occupy the next block's space through priority fees, causing normal transactions to be congested and increasing on-chain costs. All transactions will be on-chain, but only one Searcher can succeed, leading to unnecessary losses for other unsuccessful Searchers. To protect users, projects dedicated to optimizing MEV issues provide private RPCs, promising that transactions broadcasted through these RPCs will not be front-run, such as Flashbot Protect RPC and OpenMEV RPC (Sushiswap's anti-MEV service provider). Taking Flashbot Protect as an example, it is a type of RPC tool designed to resist bots attempting to front-run user transactions for profit. Compared to other node providers, it primarily sends transactions to a privatized mempool to avoid being seen by Searchers before going on-chain, effectively reducing the occurrence of Sandwich Attacks.

When competition among Searchers intensifies and users are also protected, Searchers generate requests to collaborate with users. So why would users agree to collaborate with Searchers? Because MEV in the public mempool can be avoided from being captured by Searchers, but MEV in private transaction pools can still be easily captured. Even if users use Flashbot Protect RPC, it can only prevent public mempool Searchers from capturing their potential MEV; Searchers in Flashbots Auction still have the opportunity to extract MEV from their transactions. Flashbots Auction provides a private transaction pool + a sealed block space auction mechanism, allowing block validators to outsource the work of finding the best block construction to Searchers. In this private transaction pool, Searchers can communicate privately. Through Flashbots Auction, Searchers no longer need to ensure their transactions are prioritized through Gas Wars, nor do they need to pay fees for failed transactions.

Users think that since they cannot completely avoid having their MEV extracted, they might as well obtain some rebates from Searchers. Thus, a win-win solution emerged, called MEV-Share. MEV-Share is a protocol proposed by Flashbots in February 2023, achieving programmable privacy for users: users selectively share data about their transactions with Searchers. This allows users to decide how, when, and by whom their transactions are executed. By default, users only share the transaction hash and the addresses of supported liquidity pools. Searchers search for programmable private order flows (private order flows refer to non-publicly visible trading activities and order information submitted to the Flashbots auction system) and bid in the order flow auction to gain the right to execute users' private orders. This selective disclosure of transaction data helps Searchers bid better, optimizing competition among Searchers, and users will receive fees returned by Builders. So, who mediates the data exchange between users and Searchers? MEV-Share introduces a new participant called Matchmaker to regulate this exchange.

Matchmaker can regulate three stages in the MEV-Share supply chain process. It can receive users' transactions and selectively share this transaction data with Searchers. It can also insert users' private transactions into Searchers' incomplete bundles, creating complete bundles. Bundles are a role introduced in Flashbots Auction, consisting of multiple transactions to be executed. They can be sent by Searchers to Builders, who will select the most profitable transactions from the received bundles to form complete blocks and send them to Relays, which are then sent to Validators. In MEV-Share, Matchmaker can send complete bundles along with the validity terms that Builders must comply with (e.g., returning fees to users) to Builders, who must adhere to these validity terms to participate in the MEV-Share supply chain. We know that MEV-Share is a collaboration between users and Searchers; why would Builders also participate? Here we need to introduce the various roles in the MEV process.

As Ethereum transitions to proof of stake, Validators can sort transactions in the mempool and package them themselves, or they can choose to package blocks pushed by MEV-Boost that have been sorted by Builders, which have higher MEV income. Through MEV-Boost, Validators' income increases significantly, so the vast majority of Validators choose to connect to MEV-Boost rather than sorting themselves. In fact, according to mevboost.pics, the proportion of Validators connected to MEV-Boost has reached as high as 90.7%.

In the MEV-Boost supply chain, there are five different roles: users, Searchers, Builders, Relays, and Validators; their relationships can be referenced in the diagram below. Users are the initiators of order flow. When users submit a transaction on the blockchain, it generally first enters the transaction pool in the mempool. Searchers (arbitrage and liquidation bots, DeFi traders, Ethereum Dapps) begin to scan the mempool for extractable value and then bundle transactions together to provide to Builders. Builders (generally professional institutions) are responsible for packaging transactions from Searchers, as well as transactions from the public mempool and private transaction order flow into blocks. Relays connect Builders and Validators, verifying the validity of the blocks submitted by Builders and submitting the highest valid bid to Validators. Validators are the miners after Ethereum's transition to proof of stake, also known as proposers, responsible for proposing blocks to the network and adding blocks to the chain. Currently, the competitive landscape among Validators is stable, with Lido holding the largest market share. Validators can earn consensus rewards (block rewards) as well as execution rewards (MEV + Tips).

It can be seen that Builders are an important component of the MEV supply chain. Although MEV-Share regulates the relationship between users and Searchers, if Builders behave improperly and negatively impact order flow, users have almost no recourse. Therefore, it is necessary to build a method for sharing order flow with trusted Builders. Flashbots is building such a method; to receive order flow from Matchmaker, Builders must adhere to fair market principles. Under this principle, Builders need to ensure they act in a market-neutral manner and do not exploit their privileged position to manipulate auctions, thereby harming users' interests. Therefore, MEV-Share also serves to reduce the centralization of order flow.

So how do users, Searchers, and Builders use MEV-Share? The MEV-Share protocol is included in Flashbots Protect. Users can connect to Flashbots Matchmaker through Flashbots Protect. Users can also configure their RPC requests to choose whether to share their order flow with registered block Builders. Searchers can subscribe to Flashbots Matchmaker to search for programmable private order flows, while Builders can receive order flows through MEV-Share.

If we were to describe the role of MEV-Share in one sentence, how would we do it? My understanding is that it achieves collaboration and optimization in the MEV supply chain through programmable transaction data sharing. We know that MEV-Boost is dedicated to optimizing collaboration between Builders and Validators, while MEV-Share aims to do the same for users and Searchers. In the near future, there may also be collaborative solutions between Searchers and Builders.

Let’s think further: why do we need members of the MEV supply chain to share and collaborate? Why is Flashbots committed to proposing these small yet significant solutions? I believe at its core, this is a decentralized value proposition. As we know, the MEV market is a highly specialized and competitive dark forest, and Flashbots prefers to encourage community cooperation. Their ideal is to create a permissionless, transparent, and fair MEV ecosystem.

1) For blockchains, they hope to achieve maximum decentralization in sorting. For Validators, they hope to maximize block space income.

2) For Searchers and Builders, they hope to achieve open access to user and Searcher transactions, express complex individual preferences, and coordinate across chains.

3) For users, they hope to achieve the best order flow execution paths and the lowest fees. Keywords like "preference, privacy, coordination" are specific expressions of decentralization  .

If MEV-Share is dedicated to research at the starting end of the MEV supply chain, another proposal called MEV-Burn is focused on research at the end of the MEV supply chain. Under the current MEV-Boost system, MEV is captured by Searchers and flows to block Builders, Validators, and the Ethereum network itself in the form of gas fees. A portion of the gas fees paid by Searchers is burned according to the EIP-1559 protocol, while another portion flows to block Builders as tips, and Builders pay fees to Validators to propose blocks to the network. For Builders, MEV profits are reflected as "transaction fees (Gas) + fees paid by Searchers - burned Gas fees - fees paid by Builders to Validators." For Validators, MEV profits are reflected as fees paid by Builders, and for the Ethereum network, MEV profits are reflected as ETH burned according to EIP-1559.

EIP-1559 was designed to address the inefficiencies caused by Ethereum transaction congestion; it can dynamically adjust the gas fee cap to respond to short-term transaction peaks, avoiding network congestion caused by excessive transaction volume, changing the payment structure and flow to ensure block utilization. In the MEV process, the block network also faces similar congestion issues, referred to as competitive fees. Arbitrageurs are willing to pay large gas fees for faster transaction execution, and the resulting competitive fees are the target of MEV-Burn.

Under the current system, Validators can monopolize slots (in Ethereum PoS, each slot is 12 seconds) through MEV bribery to achieve profit objectives. Validators can fully control which transactions occur in which slots. Even if other members of the MEV supply chain do a lot of work, Validators always enjoy comparatively more profits. When the more control Validators have, the more profits they can gain, this leads to centralization issues, where a single Validator has monopolistic rights over proposed blocks. To encourage competition among Validators, all striving for block proposal rewards, the MEV-Burn proposal emerged. The core idea of this proposal is to auction the "block proposal rights" of the consensus layer within the protocol. Once the winning Validator is selected, the execution block they propose will burn at least as much competitive fees as their bid. This idea will encourage Validators' highest bids to approach the maximum extractable value in the block, thereby allowing for the destruction of some MEV.

So why burn MEV, and what are the benefits? First, burning MEV can reduce the peak effects of MEV. As shown in the figure below, the average MEV payment (the image only describes the blocks created by Flashbots through MEV Boost) is about 0.05 ETH per block. However, at times, it can spike to an average of 1 ETH per block. During these market turmoil periods, there have been Ethereum blocks from which lucky Validators extracted over 100 ETH from a single block!

Burning MEV can smooth out these peaks, enhancing consensus stability. Smoothing out peaks reduces the motivation for individual proposers to steal MEV through short-chain reorganization, P2P attacks, and other means. Extreme MEV peaks can pose systemic risks to Ethereum, and MEV-Burn can enhance network security.

On the other hand, MEV-Burn can generate economic benefits similar to those of EIP-1559. Under the Ethereum proof of stake mechanism, Validators' rewards are primarily reflected in base rewards, which represent the average reward for each Validator under optimal conditions in each period. This is calculated based on the effective balance of Validators (up to 32) and the total number of active Validators.

For the issuance of ETH, the issuance is proportional to the square root of the number of Validators. Burning MEV reduces Validators' income, thereby reducing the total rewards for ETH staking, which will also lead to a decrease in ETH staking amounts. As the amount of ETH staked decreases, the total issuance of ETH will also decrease. Since the Beacon Chain is designed to ensure security solely through issuance, both EIP-1559 and MEV burning can reduce excessive investment in economic security and improve economic efficiency, and a decrease in the number of Validators can alleviate the pressure on Beacon nodes. Burning MEV can also achieve the effect of increasing the scarcity of ETH. If MEV-Burn can be successfully implemented, the rate of decrease in ETH supply will accelerate by approximately 2.5 times.

Another interesting point is taxation— in traditional business, when a company wants to distribute profits to shareholders, it often has two choices: the first is to pay dividends to shareholders, and the second is to buy back shares like Apple Inc. Buybacks are often subject to capital gains tax, while dividends are subject to income tax. The MEV burning model is quite similar to buybacks. For most jurisdictions, income tax is significantly higher than capital gains tax. In the UK, income tax is 50%, while capital gains tax is 20%. EIP-1559 and MEV burning can convert the income tax that users should pay into capital gains tax, significantly improving tax efficiency for cryptocurrencies in certain jurisdictions. EIP-1559 has already prevented approximately 1 million ETH from tax selling pressure, and MEV burning can similarly prevent millions of ETH from being sold.

A series of solutions regarding MEV are aimed at establishing a fair, transparent, and secure trading environment. In the exploration of MEV redistribution paths, we see collaboration between users and Searchers, and more intense competition among Validators, but MEV still faces challenges of centralization and unfair distribution. Throughout the research process, groups like Flashbots have expressed their commitment to maintaining decentralization, respecting the preferences of every user and every field involved in MEV, and look forward to more people joining in to study and discuss. Looking ahead, we anticipate more in-depth research and innovation, and let’s move towards more decentralization!

References:
https://collective.flashbots.net/t/announcing-mev-share-beta/1650
https://writings.flashbots.net/searching-on-mev-share
https://docs.flashbots.net/flashbots-protect/rpc/mev-share
https://ethresear.ch/t/mev-burn-a-simple-design/15590
https://ethresear.ch/t/burning-mev-through-block-proposer-auctions/14029
https://www.youtube.com/watch?v=jlGc0npwkeU\&pp=ygUIbWV2IGJ 1 cm 4% 3D
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties