The Next Five Years of MEV: Understanding the Latest Trends in the MEV Field
Author: James Prestwich
Original compilation: aididiaojp.eth, Foresight News
Author: James PrestwichPenumbraDuring the bear market, there will be some coordinated measures in the market to promote the development of MEV supply chains in other ecosystems, such as Solana, Cosmos, Near, etc. From our standpoint, it appears that the searcher-builder-proposer SBP structure will replicate in all these ecosystems, and specialization wins in complex markets. The SBP structure will continue to dominate because simple boundaries allow each role to specialize without coordinating with other roles. It is difficult to see the possibility of other market structures forming in the current landscape.
The MEV market and the protocol fee market are currently in a state of tension, with values tilting towards the highest price auction. If one tries to alleviate this tension by dividing the fee market into MEV and abnormal MEV, the normal fee market will be moved towards SBP structures that can generate enough accessible MEV to make software development worthwhile, and the abnormal fee market may You will see a unique MEV supply chain.
image description
source link
The resurgence of the controversy
We've had an excellent debate on whether MEVs are morally or legally theft. During the bull market, everyone was busy acquiring MEV, and many things were covered up by the heat of the market. Currently on-chain financial activity has moderated, and I expect to see a “moral return” to MEV acquisition. There will also be reruns of some old episodes on Twitter, and there will be some heated debate among fans over who deserves the MEV. But searchers won't care, and MEV acquisition will continue.
MEV-Aware Hard Fork
The MEV fee market will move to a first-price auction. Core developers have considered MEV in terms of protocol design. From my interactions with several ecosystems, core developers tend to lean into two camps.
Take EIP-1559 as an example, although it is not an explicit MEV EIP, it considers these three issues. EIP-1559 minimizes the impact of fee surges on users by allowing block space expansion and user fees to float with the base fee. It mitigates the impact of fee spikes on the protocol by regulating the relationship between block size, gas usage, and base fees. Finally, it participates in value capture by increasing the base fee ratio.
image description
source link
Mechanisms as complex as EIP-1559 are difficult to use widely, and they're not really a suitable solution. I think developers will follow in EIP-1559's footsteps with the goal of reducing proposer commissions. The shadow fee market for MEV benefits proposers and MEV builders to the detriment of all other users. As with fees prior to EIP-1559, the MEV block production and inclusion dynamics create a fundamentally unfair market. To that end, I hope we see a 1559-like mechanism specifically aimed at improving the relationship between builders and proposers.
Be it proposers or useless speculators, whose income should be stifled, my prediction for the future is very simple: in the next 5 years, we will see multiple hard forks in different ecosystems, these hard forks Clearly target MEV markets for specific chains. They can extract costs against MEV or share of MEV profits. Ideally, we will see tight integration of the MEV supply chain with L1.
Vertical integration
There has been a lot of debate in the marketplace about vertical integration between proposers, builders, and searchers. The basic idea is that a proposer might keep an internal builder for builder revenue, or a builder might prioritize a particular searcher. Vertical integration can squeeze smaller businesses and lead to a market dominated by a few major builders.
I think that fear is a bit overblown. The protocol randomly selects proposers, and the search and build markets are highly competitive. Horizontal cooperation between proposers (with all the power in the market) seems more worrisome. Price-fixing arrangements between proposers can be enforced through staker-activated soft forks. The protocol may have to be a proposer trustbreaker to prevent a harmful PBS market from affecting the user experience. Even worse is the fact that multiple blocks of MEV can be withdrawn as long as colluding proposers have adjacent slots, which could have destabilizing effects on blockchain finalization.
Vertical integration will definitely happen in special cases. A certain amount of MEV is generated by the interaction between bundles. Builders have access to this cross-bundles MEV and may integrate an internal dedicated searcher. There may be other special circumstances that make a closer, more trusted relationship between searchers, builders, and proposers economically viable.CowSwapMEV-Aware Application Design
It's like cheating because it's already happening. For example
The team is already rolling out the MEV-Aware application. MEV minimization will be at the center of the discussion for some time as we need to make trade-offs. Research here is driven by a single core question: what must we give up in order to remove MEV?
Although the design space of the agreement is very limited, it is also difficult to reach a consensus agreement in practice. But the application has a large number of options to achieve MEV minimization. What works depends on the application, and we'll see DEX minimization mechanisms (such as batching) that don't work for lending protocols. New research will drive some changes in each dApp vertical. However, new MEV minimization models need to contend with the momentum of existing applications. It is uncertain which dApps will see widespread user adoption of MEV-resistant designs, and which dApps will embrace current levels of MEV generation.
However, we will not stop at designing protocols to minimize MEV. Instead, MEV will become a tool in application design, and the application designer will choose when and how to generate MEV. We will propose a unique framework for deciding when MEVs are acceptable, and a set of standard techniques for adjusting the amount of MEVs produced by the system.
Explicit MEV
A corollary to MEV-Aware application design is co-opting MEV and using it as a tool. To the surprise of all, the MEV supply chain provides the guarantee that normal transactions are inaccessible, that MEV transactions will never be restored, and builders will not waste block space on unprofitable chains. MEV transactions confirm faster, and Seekers convert that MEV into a shadow fee, giving transactions higher priority. Applications will start to use MEV intentionally to access these functions, which I call "explicit MEV".
MevWeth
Explicit MEVs can give applications certain superpowers. It allows users to opt out of the EIP-1559 tip and still get their transactions confirmed quickly. Applications can intentionally unlock MEV opportunities and tie them to critical system operations. For example, we can add 0.1 ETH MEV to an oracle update. This MEV opportunity creates a race among Seekers, and the first Seeker to confirm a transaction earns that MEV. Before PBS MEV, this would result in a priority gas auction, which could be very expensive for participating Seekers. However, the modern MEV supply chain eliminates the cost of losing this race, and the searcher knows that restoring the transaction will be deleted by the builder.
The logical conclusion of MEV-aware design is MEV-inclusive design. Applications will explicitly create MEV, they will incorporate MEV into their design, and use it to purchase privileged positions in the blockspace market. Explicit MEV transactions will effectively replace standard transactions for high-value use cases.
Explicit MEV requires two things:
First, standards need to be created. To avoid expensive gas, all explicit MEVs should use the same on-chain state regardless of the contract that created it. This allows MEV to establish connections across many transactions without drastically increasing complexity. Seekers need an easy way to know if an application is creating an explicit MEV. Seekers should be able to look for specific, predictable state changes. They don't have to scan lots of contracts to detect explicit MEV. If each contract manages its own explicit MEV, searchers cannot obtain it without doing a lot of state lookups and changes. A single specific contract should be able to manage explicit MEV.
Second, a separate accounting system, explicitly MEV should be denominated in ETH. Because the Seekers take the gas price risk, their payment should be in the Gas asset, which simplifies everything enormously. However this places a new requirement on contracts that generate explicit MEV: contracts must keep track of how much ETH they can spend on MEV. It would be disastrous for a DEX to accidentally spend user ETH on explicit MEV. Therefore any contract using explicit MEV and ETH must maintain a balance of MEV-able ETH and non-MEV-able ETH.
So we need a standard for creating MEVs and an accounting system for MEVs. A very clear, obvious, and intuitive solution combines these needs, and we can easily build a system to track user balances for MEV-able ETH. We know exactly how to build contracts that accept ETH and hold it for users, and implementing tracking and managing explicit MEV functionality is a breeze.githubWe can call it "MEV Wrapped ETH" or MevWeth.The code might look like an extension to WETH 10 with an explicit MEV management interface, which might be hosted aton, and possibly
Already deployed on mainnet
superior.
MevWeth is an ERC 20 that provides a standard for:
Create MEV through the addMev() series of functions
Retrieve MEV via the getMev() family
Add explicit MEV creation to the contract via the Mevitize.sol base contract
Negative MEV
An explicit MEV cannot be separated from the transaction that created it. Explicit MEV adds implicit MEV to transactions. Together they are used to subsidize faster confirmations (and all the other benefits of a modern MEV supply chain). However, certain categories of transactions already have a lot of MEV. Liquidations, DEX trades, etc. already generate enough MEV to get priority confirmation without any explicit value creation. Adding any explicit MEV to the population would overpay for access to the MEV supply chain.
In any case, these transaction costs are prohibitively high. Uniswap users don't sit down and calculate the extent of MEV creation for their trades, they don't compare it to some concept of "fee-priority market-cleared MEV". No one is yet treating MEV as a priority fee, and even if they did, there is no efficient way for them to recover that value. A negative MEV can change all that.
A negative MEV is an explicit MEV below zero. On-chain operations with negative MEV require payment of MEV via MevWeth. The operation cannot be completed without prior payment. It is important to understand the existing power relationships in the MEV supply chain, users and applications create the value that is extracted but do not yet participate in the extraction supply chain. Proposers charge rents to other supply chain participants, negative MEV is an acknowledgment that proposers ultimately cannot control this process, and proposers are dependent on the value created by users and applications.
By specifying a negative MEV, a user or protocol can recapture the MEV created by valuable operations. We can take MEV from the proposer and give it back to whoever created that value. Negative MEV provides a simple and straightforward way to function in MEV supply chains. With negative MEV, users become participants in the value extraction process, not its targets.
MevWallet
MevWalletFor example, Uniswap users might protect against MEV by reducing the slippage margin on trades. However, this often makes the deal worse or less likely to close. Negative MEV provides an out-of-band way to improve transaction outcomes without changing the transactions themselves. Instead of narrowing the slippage range, users can attach a small amount of negative MEV to a transaction. This effectively provides fee rebates through interaction with the searcher. Users get better results. The transaction itself is not affected. The atomic coupling of transactions and payments to users allows users to explicitly share in the value that is ultimately created by users.
Negative MEV will change how the protocol controls access to high MEV processes like liquidation, and it will change the way users perform high MEV operations like DEX trading.
is a smart contract wallet that allows users to attach explicit MEV to transactions. It follows the very standard EIP-712 meta-transaction standard and allows users to specify which transactions to tip for them. Once a transaction is signed, anyone can broadcast it. MevWallet will verify transaction details and enforce some basic conditions before executing the transaction. As with any smart contract wallet, transactions are executed from the wallet, not from any EOA. msg.sender is the wallet and tx.origin is the searcher.
MevWallet transactions support timelocks and deadlines, as well as nonce-based duplicate payment protection. This combination allows complex fee adjustments based on time. For example, a transaction may generate more explicit MEV over time until it is confirmed. This creates a Dutch auction among searchers, ensuring deals are confirmed at the lowest price available on the market. Many other interesting fee escalator models can be implemented without on-chain overhead. Because fee auctions happen between Seekers and rollback transaction confirmations, no matter how complex the Gas Auction becomes, neither users nor Seekers incur additional gas costs.TypeScriptandRustMevWallet is inandThere is a code base in the
Minimal agent factory
Deploy new MevWallets. The code is licensed and available on GitHub. The main thing MevWallet is missing right now is a way for searchers to see transactions. I'm still looking for the best way to do this. I've considered a simple CRUD API and a dedicated memory pool, but I'm not sure that's a viable long-term solution.
The MEV story now belongs to profit margins, which makes it predictable. Profit margins breed stability and reliability, and the more money is made through market norms, the more sticky the norms become. The story of the next five years will be to consolidate the existing, stable supply chain and use it to build systems that did not exist before.
