Note: This article is authored and contributed by members of Douro Labs. This is the second in a series of articles that discusses MEV. This series will introduce a new formalism with which to understand MEV before covering existing methods to mitigate MEV. Later articles in the series will introduce improvements to protocol design that can help recapture MEV.
In the previous article in this series, we discussed how MEV is not inevitable or impenetrable. Instead, it derives from divergences between on-chain state and external state. Bringing these states back into agreement can be profitable, and the value of these opportunities flows to the miners who control which parties get to transact.
We then provided a taxonomy of MEV into 4 categories as seen below. The differences across these categories inform how MEV currently flows to miners—and how it can be recaptured by the protocols that generate the divergences between on-chain and external states.
| On-chain state change | External state change | |
|---|---|---|
| Independent of oracles | 1A | 1B |
| Dependent on oracles | 2A | 2B |
From a protocol’s perspective, monetizing these different forms of MEV is equivalent to lowering its own cost of matching its on-chain state with external state. In particular, these forms of MEV benefit miners while harming passive stakeholders in the protocol like LPs. If a protocol is able to claim more of these forms of MEV, it can redistribute the profit currently claimed by miners toward its passive stakeholders and therefore makes itself more competitive and compelling to passive stakeholders (LPs, protocol token holders, etc.).
A fundamental similarity of all of the four classes above is that protocols have the ability to reclaim each form of MEV ahead of the miners and on-chain transactors. Value comes from having the sole permission to transact on—or to order the transactions on—a set of opportunities; as soon as there is more than a single entity with this ability, all profits will be competed away at the PGA level. A singular permissioned entity can capture all the opportunities or auction off rights to transact to others, thereby capturing the value.
In the status quo, profit opportunities are converted into MEV because miners control the ordering of transactions within the block. Protocols could instead reclaim this revenue by effectively exercising control over the ordering of transactions related to the opportunities they create.
Existing MEV Mitigation Techniques
Not all protocol designs have naively surrendered MEV to miners. In the decade of smart contract protocols, various designs have sought to recapture some of the value by means of different techniques.
Liquidations
Protocols that feature collateralized loans, such as lending, money markets, stablecoins, and perpetual protocols, see most of their MEV leak to miners in liquidation opportunities.
One MEV mitigation technique has been developing more intelligent liquidation mechanisms that allow a protocol to limit how much value they pay out according to the market appetite amongst searchers for liquidation bonuses.
For example, some protocols use a Dutch auction to determine the liquidation bonus payout: instead of a PGA bidding war within a single block, the liquidation opportunity is auctioned over multiple blocks. In the first block that the opportunity is present, the liquidation bonus will be relatively low, and with each subsequent block, the incentive will grow. At the first block where the liquidation bonus is equal to or greater than the value at which at least one searcher would willingly liquidate, that searcher will trigger the liquidation.
This allows the protocol to conduct much better price discovery on the liquidation opportunity, making it cheaper for the protocol in most cases and allowing the protocol to discover the necessary bonus in those cases where the standard flat percentage bonus is insufficient to incentivize searchers. It also disintermediates miners’ control on the ordering in most cases, which generally protects protocol value from flowing to the miners.
Despite these nice properties of the Dutch auction, there are clear tradeoffs. For one, the Dutch auction takes time to run. Instead of resolving within the same block as when the liquidation opportunity appears, the auction now could take many blocks to resolve. This could be dangerous when prices are especially volatile or an asset’s value is deteriorating rapidly, as it could cause bad debt to appear before the auction reaches the necessary price level to incentivize searchers to clear the collateral.
To handle this, the protocol can parameterize its Dutch auction value function (with respect to time/block) to reflect its risk tolerance. By adopting a steeper value function, the protocol can achieve faster resolution on its auctions. However, due to the discretized nature of blocktime, a steeper auction also entails less granular price discovery and thus more expected deadweight loss. Moreover, appropriately parameterizing a Dutch auction for different tokens and vault types is a nontrivial exercise and introduces a new source of complexity into the protocol design. Relatedly, integrating into a Dutch auction mechanism requires bespoke integration work by searchers, which reduces the “searcher liquidity” available to clear positions for the protocol and thereby increases the risks that the protocol faces.
Another MEV mitigation technique adopted by many perps protocols is to run a centralized liquidator, often with permissioning to prevent PGAs from leaking value to miners. Because there is no competition to perform the liquidation, the centralized keeper can liquidate without transferring to the miner any more than what is required for block inclusion.
However, there are obvious disadvantages related to centralization, including continual maintenance work on the protocol’s part to keep its clearing operations functional and cost-effective and the dangers of keeper downtime, custody responsibilities, and rapid price movements. Some protocols choose not to run a centralized keeper but instead to transfer risk immediately upon liquidation to their LPs (e.g. concentrating a liquidated vault’s position in the debt pool across LPs). This is just a tradeoff between LP value and risk: while the protocol and its LPs will not leak value every liquidation, they take on a risk that LPs usually aim to avoid.
AMM Trading
DEXs feature MEV most prominently in the form of CEX-DEX arbitrage and impermanent loss. When the external exchange price differs significantly from the on-chain DEX price, arbitrageurs can lock in a profit by making a trade in one direction on the DEX and a trade in the opposite direction on the external exchange.
One mitigation measure that protocols have taken is to develop an oracle-based AMM (oAMM), which uses oracle prices to determine the prices at which trades will occur. While this conceptually solves for the issue of impermanent loss, it creates a new dependency on an external oracle and in particular requires that oracle to be always up-to-date with external exchanges. Furthermore, oAMMs are constrained in terms of their size, as they are by definition lagging exchanges relative to the primary price discovery venues whose trades inform the oracle prices. If an oAMM were to grow too large, it could be manipulatable by traders moving the price on external exchanges, thereby shifting the oracle price and creating a profit opportunity on the oAMM.
Even outside of these issues, an oAMM does not universally solve for MEV; if a particular oracle update creates a profitable trade opportunity, the competition for that trade can result in a PGA that leaks most of the value to the miners.
Another interesting proposal comes from the CowSwap team in the form of the “MEV capturing AMM (McAMM)”. The original forum post proposes an AMM where the right to trade first is auctioned off at a low frequency. Since much large DEX MEV is of the form of 1B, with a large external price movement causing arbitrage opportunities at the top of the block, auctioning off the right to transact first to the highest bidder serves to recapture most of that MEV, given a competitive auction.
While a creative solution to top-of-the-block DEX MEV, this does not dis-intermediate miners’ control on the rest of the ordering after the first trade (i.e. MEV of form 1A). Moreover, low-frequency auctions suffer from uncertainty around ex-ante bidding and the size of the realizable opportunity. This uncertainty is likely to lead to lower bids (relative to higher-frequency auctions), causing deadweight loss for the protocol and LPs (especially in times of greatest volatility and MEV recapture potential). Finally, enforcing a bespoke set of ordering rules at the protocol level can lead to issues with DOSing by the permissioned first trader and unintentional failure, blockspace congestion, and uncertain transaction landing for other users. This introduces a new set of complexities to deal with and more painful UX.
Coda
The aforementioned MEV mitigation techniques have been tried in the wild in different forms, and they have found varying degrees of success. Ongoing experiments in optimal protocol design point to the fact that protocols realize that much of MEV is an unnecessary value transfer from their LPs to miners.
However, the fact that the status quo continues to feature relatively simple protocol designs suggests that the existing mitigation techniques introduce too much complexity or are too ineffective to efficiently recapture value. This complexity is often on the protocol side, but it also spills over into searcher integration pain. As a result, many of the most popular protocols continue to champion simple and straightforward designs that leak MEV to miners.
What is needed is a solution that recaptures value efficiently without adding much complexity to protocols and searchers. Put another way, the right solution would mitigate much of the pain for protocols and searchers by concentrating the complexity in layers of the system that can be shared across protocols and searchers.
In the following articles in this series, we will discuss one such solution that provides effective value recapture by creating a standardized interface and modular implementation layers that protocols and searchers can easily plug into. The next article in the series will discuss liquidations as a worthy target of value recapture.
We can’t wait to hear what you think! You can join the Pyth Discord and Telegram, and follow us on X and LinkedIn.
Stay Updated with Pyth
Stay informed about Pyth network's development and upcoming events!
