MEV capturing AMM (McAMM)

[fleupold]

@bowaggoner

I’m wondering about more decentralized solutions the AMMs can implement themselves.

This proposal can be implemented by AMMs themselves. They would store the address of the lead searcher and the last block they trades. The AMM would then revert if a swap is called by someone else and the lead searcher hasn’t transacted in the current block yet.

@bowaggoner

Specifically, the AMM could have a slower “tick” time. If multiple trades all arrive within one tick, they are batched and executed together in a way that treats them all equally. Concretely, if a ton of orders all arrive to buy A during the same minute, none of those orders will get the original great price for A.

I think this is difficult to implement at the AMM level without breaking atomicity of transferIn/transferOuts. CoW Protocol is actually implementing this type of batching on a layer above the AMMs (netting traders p2p and settling the excess on the best available AMM).

@bowaggoner

So there is a fairness question of who should get to capture the value. Miners seems unfair, letting the trader keep it isn’t necessarily desirable.

Agree that it should be the LP since they are the ones incurring the cost. This type of MEV has been more formally quantified in ongoing research by Jason Millonis, Tim Roughgarden, al. In their work they conclude that providing liquidity in traditional AMMs is incurring a cost compared to actively mimicking a rebalancing strategy on CLOBs (they call it loss versus rebalancing LVR) which today is offset by trading fees. However since trading fees are mainly affected by noise trading volume and volatility it’s quite hard to model the correct fee amount with a fixed fee tier (instead they should be adjusted based on volatility over time).
This proposal basically off-loads the decision on how to value LVR to professional searchers which bid ex-ante for the optionality to get exclusive first execution right.