# Flexible MEV Recirculation Policies

A common discussion point around MEV is the idea of recirculating it to various parties, including searchers, protocols, and wallets. As of today we mainly see these arguments as being in favor of one party over another unilaterally. While these discussions are important, why not make it a spectrum and allow for upgradable patterns, essentially Flexible MEV policies. These are alot like NFT royalties, see Prior Art below.

This work is not concerned with gurantees around payment enforcement, although that does greatly inform the implementation. This system assumes a proper enforcement system that it can plug into.

Let's break down the two key ideas here:

## Flexible

Within this idea there are two main discussion points:
1) The implementation details
- approach 1 : smart contract - protocol upgradable. A protocol can sign a message which is then used used to update an array [ 30% : 0x123, 70%: txn_originator]
- approach 2 : smart contract - inherited interface. Smart contracts can't sign messages, so instead they can inherit an OpenMEV.sol with object MEVPolicy{ setPolicy, getPolicy, etx} with similar settings like [ 30% : 0x123, 70%: sender]
- approach 3 : inside the ethereum protocol - I wont think through this cause it seems wrong
- approach 4 : alternative DA layer - this could be a roll-up, IPFS, another blockchain, engraved in the stars.

2) The update design
- It is best to leave this as open as possible and to the individual protocol. This reduces the MEV to a governance issue, something sxysun brought up in his 2022 MEV day talk.

Is there more to think of here? As in, were only focused on L1 and smart contract level. Do roll up sequencers need considerations? How about other L1s like Polygon

### Questions
- How do wallets get a say? Do they need to someone bartering on their behalf to *each* individual protocol? That sounds painful.
- How conditional can MEV payments be?
- If account abstraction is ubiquitous, how does that affect such a scheme.

## MEV Policy

A policy is an official way for protocols to handle how MEV from their dapp is created. Every app has different MEV profiles so it makes sense that they should each hope for the MEV created from their protocol to be handled differently.

MEV Policies should have a concept of an `action`, these are instructions to be processed after MEV is extracted, but prior to block finalization (or bundle finalization).

### Questions
- Are there system level tangible benefits such an approach gains, or are the benefits entirely psychological? (i.e. "Uniswaps MEV Policy is clearly XYZ and Compounds is clearly ABC")
- How can we reason about gas used by an `action`. Something like "Purchase token and burn" has way more gas than "transfer".

## Prior Art

These are basically NFT royalties, which as we saw with exchanges recently, are a major pain point once some services started to ignore public standards around royalties. (An ERC721 does not facilitate its own exchange for eth, the exchange contract like OpenSea does. Therefore creators need to register their preferred royalties to a public contractand exchanges like OpenSea respect the royalties)

## Attack Vectors

Is it possible to update this policy such that it can be used maliciously against the user?

What happens when a protocol dies or becomes inactive?