Strategy specific builders: to censor or not to censor

[dmarzzz]

Opening this issue to start discussion around the topic of strategy censoring

Front-running is illegal in traditional financial markets so it is no stretch of the imagination to think that < large validator set run by corporate entity > [ Coinbase, etc ] may be required to enforce a similar restriction on its validator's MEV augmented profits.

Therefore, some type of strategy specific censorship is inevitable. And even if regulation isn't the driving force, it could be possible to see more altruistic focused validator sets coming from community governed groups such as Lido.

Some open questions around this:

• How to form open standards around types of arbitrage?
• Can this choice be made in protocol (builder, relay, validator?) or is it best left to be socially coordinated?
• Can we accurately classify MEV types?
• If a heuristic based classification model is used, what are the risks of misclassification?
• Will ignoring certain types of MEV lead searchers to construct builders for their censored strategy, and would this be a bad thing?

[come-maiz]

Thanks @dmarzzz for bringing the topic here. A few more things that came to mind:

• If this is regulated, who is the responsible party? The validator will receive a full block, with no option to front-run it. The builders are just sorting bundles, no front-running there. These bundles could even be encrypted with some futuristic stuff. The searchers? They can be anonymous. The protocol designers? Like they should protect their users, but is it actually possible? The relay? But then an anonymous relay can appear that skips regulation.
• What is altruism in here? There's the argument that when there is MEV, the only best thing to do for network stability is to maximally extract it. What kind of incentives will build up when builders censor transactions?
• Is censoring more legal than non-censoring?

Many many thoughts. But mostly questions. At flashbots we are thinking hard on this. It would be nice to hear more thoughts and experiences economic, legal an technical.

We are also designing the data collection and publication, so more people can contribute to the analysis. https://github.com/flashbots/flashbots-data-transparency

[come-maiz]

Here is a post by Uri from @bloXroute-Labs talking about a good block-builder, and an invitation to discuss this further: https://medium.com/@uri_61495/flipping-the-table-on-the-mev-game-dc31df8baaf7

[come-maiz]

Here is a tool by @pmcgoohan to visualize mev values and transaction ordering. Some transactions are labeled as toxic.

https://www.zeromev.org/

Are they toxic or is this how defi protocols are designed to work? If they are toxic, is it possible to identify them in real time? If so, should these toxic transactions have been censored? If so, where?

[PizBernina]

I will add some more input to what for some may be "the bad"/ toxic MEV.

Figment recently posted this https://www.figment.io/resources/figments-mev-policy-supporting-neutral-secure-and-open-solutions

In the post they state that "The Bad" are sandwich attacks and generalized frontrunners. In that sense they also use a similar definition as zeromev.org does for "toxic" MEV.

[quintuskilbourn]

There is a lot to be said on the topic of identifying "toxic" MEV. For starters, it's not easy (or possible?) to identify cases of front-running or sandwiching.

For example, in order to assess a builder's claim of not sandwiching, you could start off checking for sandwiches by checking swaps for a transaction immediately preceding and following it from the same address. Searchers/builders could catch on to this and start doing sandwiches from different accounts, rebalancing funds occasionally. Now one could check if a swap is preceded and followed by transactions touching the same pool (one a buy and one a sell), but one would already be mislabeling some normal occurrences as sandwiches. Add on to this that the sandwiching transactions don't need to be immediately next to the sandwiched transaction (you could add unrelated transactions in between) and it becomes very hard to tell if a block contains a sandwich or just a bunch of transactions touching the same pool. One could keep playing this cat-and-mouse game but ultimately it doesn't seem like a fruitful endeavour.

Perhaps there are some other metrics one could use like looking at average slippage per builder, but its not clear that such metrics wouldn't be gameable either.