MEV: Who Should Profit From a Protocol’s Economic Activity?
It’s an ongoing question that must be faced in the core design of any blockchain protocol: Who stands to profit the most?
Maximum extractable value, or MEV, is a bit of a behind-the-scenes game — it’s all about finding a way to get the most value out of a protocol’s activity. Participants in the system are constantly looking for angles that will extract the most value — and not necessarily in a manner that benefits the majority of users.
On a recent Bell Curve podcast with Mike Ippolito and Hasu, guest Justin Drake, a researcher at the Ethereum Foundation, argues that the system should prioritize those “closest to Ethereum” — holders and proposers — rather than let value be leeched out by those further on the fringes. He says that a misalignment currently exists, but is confident that — at least in the case of Ethereum — developers can design MEV so that most of it benefits core users rather than those trying to game the system.
Mitigating MEV
Other protocols, such as Solana, attempt to solve the MEV problem through different mechanics, but run into problems of their own. Solana nodes do not have a mempool to be attacked and charge standardized gas fees, for example. But even these solutions don’t prevent arbitrage trading bots from running rampant on the protocol and congesting the network. Solana also fails to escape the problem of sandwich trading, which squeezes the average trader into losing value on trades due to slippage.
Almost all the alternatives that are being promoted are just a matter of choosing different priorities, suggests Bell Curve podcast guest Tarun Chitra, founder and CEO of Gauntlet Networks. “All you’re doing is preferencing a different type of actor in the system,” he said.
Fair ordering protocols, for example, set preferences for different applications over one another instead of different users. Chitra explains what he believes is the fairest approach to MEV, boiling it down to a straightforward choice: “Do you want to discriminate,” he asks, “at the user level or at the application level? Your particular design choices will inevitably leak down to doing some form of discrimination.”
What matters then, Chitra says, is transparency — designing protocols to ensure that fair allocation is determined in a transparent and trustworthy manner. “If you have that transparency, then you can think about redistribution in a credible way.”
When asked about the topic, Zaki Manian, co-founder of Sommelier protocol, offered his general philosophy for handling MEV effectively: “Mitigate what MEV you can, capture what you can of what remains, and then maximize tools for allocating what’s left at the application layer.”
Encryption-based solutions, Manian says, can go a long way towards eliminating undesirable MEV opportunities. Following this, mechanisms that “capture MEV at the protocol level” and off-chain sequencers can fairly allocate any remaining MEV, “even across different chains or rollups.”
Guest Justin Drake, a researcher at the Ethereum Foundation, asks, “How much of the MEV initially originates from somewhere and can be given back to the originator? Maybe it’s way more than we expect.” The problems of MEV can be fixed, Drake argues, by removing what he calls economic distortions — front-running, sandwich trades, reorganization and so forth — with clever design.
One example is the Flashbots MEV relay. As explained on Ethereum.org, it prevents transaction front-running by allowing searchers to submit transactions without revealing them to the public mempool. Front-running was once the primary cause of a notorious problem with MEV extraction — extreme gas prices — but implementing Flashbots successfully reduced fees.
“These clever designs include inclusion lists, encrypted mempools, enshrined PBS, and a slew of other designs like MEV burn, as well,” Drake says. The issue, then, is not so much a philosophical question of who should profit most, he concludes, it’s about effectively designing protocols with aligned incentives that benefit the system.