Returning MEV to users and dapps

Here’s the dominant narrative in MEV: "MEV is here to stay, so let's design mechanisms to distribute it." This is effective in limiting MEV’s negative effects on network congestion and validator centralization. But it’s done little to eliminate harm to network participants.

It’s questionable whether MEV extraction is really such an intractable problem. And maybe we, therefore, don’t need to rush to patch up network consensus mechanisms with centrally controlled infrastructure.

The motivation to remove MEV

MEV exposes so much value that it heavily influences decentralized networks:

• MEV threatens consensus through time-bandit attacks;
• MEV threatens validator decentralization and hence network security;
• MEV imposes a tax that threatens Defi adoption;
• Now, under PBS, MEV threatens centralization on the blockbuilder side.

Even so-called "beneficial" MEV, such as cross-domain price arbitrage, contributes to these risks.

MEV comes from dapps

Here’s a less common perspective on MEV: All MEV originates from the design choices and specific limitations of dapps:

• AMM design exposes sandwiching and backrunning possibilities;
• The specific design of liquidation rewards defines liquidation costs to borrowers;
• The design choices of oracles define the conditions for oracle and latency arbitrage.

What does this suggest? Perhaps dapps, who can implement any possible mechanism design, are well-positioned to eliminate MEV. Dapps also have strong incentives to eliminate MEV: the rewards for their liquidity providers, stakers and treasuries – and service quality for their users – is negatively impacted in direct proportion to the amount of MEV they expose.

A lot has been done – 1inch, CowSwap, Euler all remove a lot of MEV. But dapps are strictly limited by their execution environment: the conditions of the protocol they execute on.

The limits of on-chain computation

In theory, computational design for dapps has no restrictions. But the specific blockchain dapps execute on limits their ability to mitigate MEV in two ways:

1. Compute is limited and costly;
2. State is only updated with every block.

Hence, the tempting conclusion that some MEV will be intractable for dapps to remove. And the idea that we have to redesign mechanisms of block-production – or redesign on the network layer – to deal with MEV.

But this overlooks a couple of things:

Dapps are not necessarily limited to on-chain computation: Dapps can incorporate off-chain keepers to fulfill critical functions, without losing trust and user confidence. How? Through off-chain keepers that verify their actions on-chain.

Enshrining extraction on the network-layer takes agency from the user: Users and dapps produce all MEV. And MEV isn’t generic; it’s often a very specific issue, intimately connected to a protocol’s particular design. Taking the question of MEV-aware design away from the dapp – or even deferring the dapps’ responsibility – to the network layer crucially restricts the dapps community from finding more optimal domain-specific solutions.

This is why maximally fair solutions to distributing value that originates purely from the dapp and user level – which all MEV does – should be in the dapp’s domain and decided under it’s governance. To control and capture their MEV dapps only need to overcome their specific on-chain limitations:

Solving MEV on the dapp level

All MEV originates in the domain of dapps: their lps, stakers and users. Smart contracts are limited by on-chain computation. But to overcome these limitations, dapps can reach for better mechanism design, together with off-chain computation.

Excellent examples of such solutions already exist. CowSwap elegantly outsources resource-intensive off-chain computation (to solvers) to achieve better prices, while execution is still fully on-chain.

Most dapps are not explicitly designed with off-chain computation in mind. But after reviewing the majority of MEV-producing dapps, adding protective mechanisms to any dapp turns out to be simple in most cases.

The solution follows the same pattern: Off-chain computation (a solver) permissioned by the dapp to perform a computation, which eliminates all MEV. For most apps, this solution means capturing the MEV and returning it to the dapp.

Solving MEV on a dapp level has important advantages:

• What constitutes fair MEV distribution is answered in the domain where the value originates, by the dapp governance.
• No MEV is exposed to the wider system. This means there’s no MEV to power the negative externalities of MEV, including…
• The dapp removes friction from its design and is maximally efficient and competitive.

Between MEV-aware designs and the use of domain-specific solvers to stop MEV exposure, dapps can remove most MEV from blockchain ecosystems. In turn, this will free protocol designers from a lot of the urgency currently driving the MEV ecosystem.