"Instoppable" MEV in the protocol

[norswap]

Sequencer-Enabled vs Instoppable MEV

I think we can divide MEV into two categories:

1. Sequencer-enabled MEV (SEV?)
2. Instoppable MEV

The first one needs the sequencer's involvment (maybe the sequencer is itself extracting the MEV). This notably enables sandwiching. Since the sequencer is currently centralized, this category can be ignored for now, although we need to have a plan for it long-term. One possibility is to adopt something similar to what Flashbots is proposing for after the merge (based on the initial idea from Vitalik).

If the sequencer does not facilitate MEV, MEV still exists — in particular, lending liquiditations still occur, as do arbitrages. If we do nothing, these will go to the fastest actors. This is not particularly fair as a few actors capture value generated by the network, while the network and its users capture none of it. It also risk rewarding bad actors, see below.

I call this "instoppable MEV", and this post is meant to discuss this kind of MEV.

Problems with Instoppable MEV

Leaving this MEV easily accessible could be a problem for us in the short to medium term, in the form of spam. It could be that the optimal strategy for searchers is to innundate us with requests, either by (A) aggressively polling the JSON-RPC endpoint (can we learn about recent transactions this way, or do we need to wait for p2p block announcements?), or (B) even worse, by submitting a ton of almost identical transactions that revert until the MEV opportunity (typically, an oracle update) is executed by the sequencer. This is better than waiting to learn about the transaction by other channels, as the MEV-extracting transaction is already in the queue when the MEV-enabling transaction lands.

It is possible to do some DoS mitigation (and I suspect sequencers might need to include this anyhow), but this then becomes a frustrating game of whack-a-mole, in which MEV searchers have a particularly high financial incentive (unlike real DoS attackers).

Handling Instoppable MEV: Ideas

Here are some ideas for a scheme that would handle this kind of MEV:

Core Idea: The sequencer lets searchers register a Solidity contract that implements a standard interface. For every confirmed transaction, the sequencer calls this contract, passing it the transaction it just confirmed as calldata. If the searcher does not want to backrun the transaction, it reverts. Otherwise, the sequencer picks the searcher whose contract pays him the most, and confirms this transaction as the next transaction.

Note that this does not require the searcher to trust the sequencer with his funds, as those are held by the contract. The sequencer can front the gas costs and deduct them from the searcher's payout when computing profitability.

One issue is that these contracts are publicly deployed on-chain. This is already an issue with MEV on L1, but it is worse here because the contract itself is responsible to filter MEV opportunities, hence clearly defining the MEV opportunities it targets before exploiting them.

This can be mitigated by splitting the contract in two: a private part that filters the opportunities (this need not necessarily be written in Solidity) and possibly even generate the transacton to emit. Normally, this shouldn't require more trust in the sequencer, as the contract should include a profitability check.

Also note that running a bunch of contract calls after every regular transaction is quite a bit of added overhead. One way around this is to make the "filter" part actually a bunch of declarative selectors (on the address, destination, solidity call parameters ...) that can be converted into very efficient indexes.

Searchers would have to pay a small fee for this service (one part for each filter they register, one part for transaction simulation gas). The goal is to avoid DoS attacks.

Conclusion

So in summary, such a system of searchers registering a contract along with some declarative filters could be used to ensure the sequencer captures a large part of the MEV value that cannot be prevented by other means, and avoid collateral damage to the protecol in the form of transaction spam. The proceeds can serve to further develop the protocol and/or retroactive public goods funding. Moreover, this makes MEV extraction more fair and more efficient, as anyone can participate, not just actors that can afford low-latency connections and high-speed hardware.

[obadiaa]

Hello!

First off, I recommend checking out these two great posts by Alejo that will contribute to forming your mental model wrt to MEV: https://writings.flashbots.net/research/formalization-mev/ & https://writings.flashbots.net/research/quantifying-rev

I think you're correct that there is a 'conservation' of market inefficiencies in your system and that the challenge is thus about understanding how users will seize these opportunities (and to reason about extraction costs). Spamming is intuitively one of the worst ways (for the system) to extract MEV and can take many shapes, latency races are also bad but the reason for why are more subtle and maybe philosophical?

I'm not sure I follow the solution you outlined above. This is what I understand:

• for every tx seen by Opti sequencer, the tx is passed to an arbitrary number of Opti contracts
• these contracts are created by searchers and contain logic to decide whether to backrun a particular tx
• for each tx, the contract either 1) reverts, 2) outputs some bid it's willing to pay to be behind the particular tx it has received
• the sequencer selects the highest bid, and the associated tx, and places it after that tx

if I'm correct, then you're describing an MEV auction 😁 and I recommend you check out how the Flashbots auction works. I have a lot more thoughts, looking forward to chatting more about this :)

[norswap]

Hey Alex!

Your understanding is correct! It is in fact a MEV auction.

The key difference from flashbots auctions is that we have no bundles and only allow backruns. This makes sandwiching and sniping impossible if we assume users sends transactions to the sequencer directly (unless the sequencer does it himself). Another difference is that I would charge (more or less at-cost) searchers for the privilege of running MEV filters, which avoids the issue of separating searchers into a fast and slow lane.

For the proposed mechanism, a assume a single centralized & well-behaved sequencer. There are a lot more challenges that pop up once we consider permissionless decentralized sequencers. This will mostly depend on the decentralization mechanism. I can see a world where there is a L2 consensus that is essentially a mini L1 with a small number of huge nodes — in which case MEV considerations/lessons from L1 mostly carry over. But it could also end up looking completely different, the design space hasn't really been explored yet.