Future of MEV opportunities on Solana

Current State:

Solana currently only has an internal mempool of pending TXs and not external/public. This means MEV opportunities only exist in terms of - running your own validator - inspecting TXs that come your way - running your own MEV code on top (not easy but feasible)

There is also no fees market, so there is no way for MEV searchers to incentivize validators to order Txs based on fees 'yet'!

Although, there are some rumors that some searchers are bribing validators to get priority access to their ports and slots.

wireless anon @wireless_anon

Unfortunately, this is not true; there are already backroom deals in which searchers pay validators for privileged access to their blockspace.

Misaka @0xMisaka

There is also no fees market, so there is no way for MEV searchers to incentivize validators to order Txs based on fees 'yet'! 3/x

Jito Labs (Flasbots on Solana):

Currently, Validators can only produce blocks according to their stake weight. Since TXs fees on Solana are low and MEV opportunities can bring validators more profit, Validators are incentivized to auction off their block space to searchers. https://docs.solana.com/cluster/leader-rotation…

@jito_labs is currently working on custom validator software similar to mev-geth to democratize MEV opportunities and expose validators' mempool and introduce fees market

Does that mean that gas fees on Solana will be more expensive? Yes and No. Solana is currently planning to introduce a local fees market at the Account Level.

https://github.com/solana-labs/solana/issues/22820

So, for example, even if there is a higher fee on the @projectSerum SOL-USDC pair because of significant activity, trading on the USDT-USDC pair shouldn't be affected.

Overall, this seems like a good path for Solana to take. The introduction of Qos by stake weight and local fees market would likely decrease network congestion and the impact of the DDOS attack.

Composability T◎ly, 🖤 @aeyakovenko

To address the general issue, engineers plan to introduce flow control in 1.9 with qos by stake weight, but now implementing this feature in 1.8 is the highest priority.  The implementation uses quic to rate limit senders, and should be rolled out in the next 4-5 weeks.