AL #029: Fighting MEV with code

Exploring the limitations of protocol-only MEV resistance.

Thanks to Tarun Chitra, Moody Salem and Louis Guthmann for providing feedback on this post.

MEV is an incredibly challenging aspect of smart contract security.

There is a significant mismatch between the skills required to identify logic errors in smart contracts and the skills required to identify potential MEV attacks which are economic and cross-protocol in nature.

Surprisingly, there is very little material out there that can help smart contract developers and security researchers offset MEV in practice.

This is an attempt at trying to catalog different ways that protocols resist these attacks today.

What are the common types of MEV attacks

Before we start, let’s look at the types of attacks we are trying to mitigate.

Here's a partial list that probably covers 99% of MEV transaction volume (note: even some of the listed opportunities are actually considered long-tail).

All these attacks seem to exploit three conditions occurring in conjunction:

• Incomplete transaction intent. E.g., a swap transaction that doesn't express any price preferences. Clearly the user's intent is not to swap as the price of the sold asset tends to 0 but the transaction would often execute nonetheless

• Revealed transaction intent. Here it's important that the transaction intent is actually revealed which allows the MEV searcher to prepare their calldata in response.

• Revelation-settlement order. The settlement of the transaction occurs after the transaction intent is revealed which allows the searcher to interpose their transaction

Armed with this framework, we can begin to unpack ways protocols can offset MEV.

Fighting MEV with code

Of course, there are a number of research streams to address the above attacks at even the chain or off-chain infrastructure level (preventing transaction re-ordering, using a relayer, enforcing network-wide private transactions and many more).

But while those streams are in progress, smart contract developers face a real challenge of protecting their users from these attacks today.

So I cataloged 12 different mechanisms for MEV resistance.

Here they are.

On the surface, these approaches use very different ideas, ranging from more traditional trade order structures to more esoteric cryptographic techniques.

But they operate in remarkably similar ways – boiling down to 2 different ways of preventing MEV.

Enhancing Transaction intent

One set of approaches work to enhance transaction intent.

They allow the user's intent to be captured with more detail or less consequence.

This includes slippage protection, auctions / onchain intents, high fees, time weighing, concave pro-rata games, automatic extraction, liquidation backstop, decimal offsets and co-processing.

These approaches either allow more information and more constraints to be provided or they open declare something to optimize (e.g., prices) and let market forces compete for best execution in a way that isolates the transaction from manipulation.

Manipulating Revelation-Settlement Order

The smaller set of approaches work to manipulate revelation-settlement order (private transactions, multi-party/threshold cryptography).

These transactions manipulate revelation-settlement order to eliminate the opportunity window for searchers altogether.

While harder to implement and with significant UX/regulatory implications, one could also envision these techniques to be applied at the core protocol level.

So what to use?

I would have loved to provide a decision tree or checklist for protocol developers to figure out which approach they should use.

But a lot of these techniques affect many aspects of the product in ways where it’s hard to recommend a one-size-fits-all solution.

Instead this is best used as a catalog of ideas and perhaps more techniques can be discovered by deconstructing how MEV is applicable in the first place.

The safest protocols will take these approaches seriously but also understand that they are often mitigative but not comprehensive and seek to complement them with a holistic approach that includes off-chain mitigations (like using a relayer).