MEV on BSC - where we are and where we should go

[xcarlo]

Recently, several validators began to quietly capture MEV.
This development was predictable, but has some negative effects:

1. Unfairness - it's unfair that some validators make more $ by extracting MEV, while others do not.
   Whatever decision the BSC community reaches regarding MEV - it should be fair for all validators.
2. Centralization - MEV validators yield higher APY, causing stakers to abandon other validators and concentrate the stake with the best MEV-extracting validator.
   Any MEV solution should allow all validators to capture similar yield to avoid it.
3. Half-measure is the worst of all worlds.
   It's fine if validators don't capture MEV, and it's potentially fine if they do.
   But if some of the validators extract MEV while others don't, it's bad for the traders who lose trades, and bad for MEV searchers who can only capture a fraction of the opportunity.
4. No clear standards.
   Right now each actor acts independently without synchronization. Having clear guidance from the BSC community and foundation would allow any solution/approach (no matter what it is) to be utilized effectively across the ecosystem to everyone's benefit.

The problem of centralization is so significant, that on ETH it drove the adoption of MEV-boost, which allows 3rd-party block-builders to suggest blocks which capture MEV.
The rational is something like: if a vanilla solo-validator yields 4% APY, and a large validator can invest in capturing MEV and yield 7% APY, everyone will stake with the 7% MEV validator.

We would like to explore potential MEV solutions to the BSC ecosystem, balancing between:

• Validator yield
• Decentralization
• DeFi user experience

bloXroute will be glad to explore, collaborate, implement, and/or maintain a MEV solution which best fits the BSC community.
Such potential solutions include:

1. MEV-boost-like solution, allowing specialized MEV actors the suggest the most valuable blocks to any validator
2. Implementing Themis - a fair-ordering solution suggested by Cornell / Chainlink - which eliminates MEV and include Tx according to the order they were received by all validators (MEV minimization)
3. Enabling validators to back-run / capture arb, but preventing front-running / sandwiching which is the most harmful for users (only "good MEV")
4. MEV-geth-like solution, allowing Searchers to provide bundles and private Tx to validators, but not full blocks
5. Incentivizing searchers to maintain an open-source code which allows validators to capture MEV locally
6. Back-running MEV auctions which allow validators to back-run, but prevents front-running

or a combination of the above.

This post doesn't offer a solution - rather, it's an invitation to collaborate and explore which MEV approach would serve the BSC ecosystem best and get it done fast.

As a service provider for some of the largest DeFi traders in the world, and as key actor in multiple alternative MEV ecosystems on different chains, we would be glad to do our part and contribute to the BSC ecosystem.

[brilliant-lx]

MEV is a missing part of BSC right now, but it is not a high priority for BSC.
Unlike Ethereum, BSC community has stronger control over the network, the MEV is not quite a problem right now. The previous unbalanced APY distribution is not caused by MEV as I know.

But in long-term, BSC needs to support MEV, make it fair and transparent. And I think it would be necessary to put some effort on it as long as the community has the resource.

[github1youlc]

Validator should not capture MEV and be neutral.
As a user, front-run transation stole my money. validators should not guarantee this MEV behaviour. otherwise, users will leave !!

[bnb-tw]

Validator should not capture MEV and be neutral.
As a user, front-run transation stole my money. validators should not guarantee this MEV behaviour. otherwise, users will leave !!

I'm not sure how this is supposed to be enforced given that the node code is open source, and the rules for transactions to be included in a block are clearly defined.

[tinhbao789]

Good project

[zzzckck]

There is a MEV proposal, see: #322