# Mitigating Sandwich Attacks at the Protocol Level

In this write-up, I will explain what MEV is, show a few examples. Then I will propose a few ideas on how we could go about mitigating one form of MEV — namely sandwich attacks. In process, we'll talk about relayers like Flashbots, and how sandwich attack can already be avoided today.

**If you are already knowledgeable on MEV**: First, and while I'm by no means an expert, rest assured that this is not a super naive take on MEV. As the refrain go, we want to "minimize what MEV we can, democratize the extraction of what MEV is left". The ideas presented here definitely fall into the "minimize what we can". I'm also not entirely sure we should pursue them, and these are not new ideas, but I think they're presented in a way that is conducive to conversation. **Feel free to skip** to the section titled ["Preventing Sandwich Attacks at the Protocol Level"](#Preventing-Sandwich-Attacks-at-the-Protocol-Level).

## What is MEV

MEV stands for "miner extractable/extracted value", though there is some proposal to reinterpret that as "maximum extractable value".

There is extractable value each time a risk-less opportunity arises on the blockchain. I'll give a more detailed run down of the different kinds of MEV later, but here is a brief description of two of the main kinds. The first are loan liquidations, where you buy the collateral of a loan that is approaching its collateralization threshold, at a discount. The second example is arbitrage, where you buy something somewhere and sell it a higher price somewhere else.

The extractable value can or cannot become extracted. "MEV" is often used for both extractable and extracted value, though people talk about the extracted value more often. The "miner" in MEV comes from the fact that if a miner could detect all forms of MEV, he could extract them himself in the block that he mines, since he is the one that chooses which transactions make it into the block, as well as their ordering.

In practice, miners only capture part of the extracted MEV. Third parties known as "searchers" search for MEV, and attempt to extract it.

Not all forms of MEV rely on transaction ordering, but some do (notably sandwich attacks, see below). Transaction ordering is nevertheless a big concern for searchers: if multiple searchers attempt to extract MEV, only the first one whose transaction is executed will succeed. This leads searchers to run a sort of auction for the right to extract MEV, with the proceeds going to the miner. This is a mutually beneficial arrangement: miners do not have to learn how to find MEV, and searchers still get paid. Because there is competition, searchers are incentivized to find new forms of MEV, or to extract more efficiently so they can pay the miner more. All of this is profitable for the miner.

(Note that after the Ethereum 2.0 merge, block proposers will be in exactly the same position as miners today.)

Historically, MEV was mostly extracted one transaction at a time. Miners include the transactions that pay them the most (highest gas price) first in a block. This is known as a "priority gas auction" or PGA. As we'll see below, it was also interesting to run straight after a given transaction (seen in the mem pool), and so to try to craft a transaction whose gas cost is lower but as close as possible to that of the transaction to backrun.

All of this changed with the introduction of [Flashbots](https://github.com/flashbots/pm), as well as other direct channels through which searched could communicate with miners (we'll call those "relayers"). Through these channels, the searchers send "bundles" of transactions (including their own transaction and potentially transactions they gleaned from the mem pool) that should be included atomically, and in the specified order. Additionally, this allows signifying the miner that he will receive a tip (sent by one of the transactions in the bundle) if the bundle is successfully included. Another important detail is that the miner is supposed to keep the received bundles entirely private.

## MEV Taxonomy

Roughly speaking, we can distinguish four kinds of MEV:

### 1. Frontrunning

Frontrunning, or racing for opportunities. Typically these are [loan liquidations,](https://medium.com/dragonfly-research/liquidators-the-secret-whales-helping-defi-function-acf132fbea5e) which can be quite profitable.

These opportunities arise from a change in the price oracle for the collateral (this could be an oracle protocol like Chainlink, or in rare cases the spot price in one or multiple liquidity pools — though I think this is less common these days because of the potential for [flash loans attacks](https://twitter.com/officer_cia/status/1419435199385980932)).

It's my understanding that the MEV competition used to be less fierce, and less sophisticated (especially pre [Flashbots](https://github.com/flashbots/pm)), and that searchers would sometime attempt to liquidate on the block following the oracle update. One difficulty is that it's easy to bid to be included early in the block (by default, miners include the transactions with the highest tip first), but pre-Flashbots, it used to be difficult to land right after the oracle update: it required crafting a transaction whose gas cost would as close as possible (but lower) than the oracle update. With Flashbots you simply put your transaction after the oracle update in a bundle.

Here is [an example of such a transaction](https://www.notion.so/d6b249a3a5d56ff1bc638375d1ce7db6) which I'm taking from [this article](https://medium.com/coinmonks/the-defi-liquidation-game-aaef5c0b903d) (both from April 2020).

What happens there is that the liquidator loans 340k DAI from Aave as a flash loan. He then pays 340k DAI to liquidate the bad loan, in exchange of which he receives 1,128k AAVE. He then proceeds to swap those for 193 ETH, 168 of which he swaps into 340k DAI, which he uses to repay the flash loan, leaving him with 25 ETH. If you factor the 7.5 ETH gas cost, this leaves our searcher with a 17.5 ETH profit (which was worth 2.2k$ on the date.) From that 25 ETH & ETH price, we can infer that the [liquidation reward](https://docs.aave.com/risk/asset-risk/risk-parameters) for the AAVE token was about 15%.

This particular transaction used Flashbots to bid on gas price, but, as explained in [the article](https://medium.com/coinmonks/the-defi-liquidation-game-aaef5c0b903d), the oracle update occurred in the previous block!

The article further has an example of trying to land exactly after an oracle update by trying to get as close as possible from the oracle update gas price.

Note that front-running can be more mundane, such as being first to buy when a piece of news that just landed will almost certainly cause the price to go higher. This could be interpreted as a form arbitrage — see below — because statistically any given exchange is unlikely to be where the price moves. The difference is that you expect the price change to have stickiness, and so you don't need to buy + sell in a single transaction.

### 2. Sandwiching

Sandwiching occurs when transactions are inserted around another user's transaction. Typically, this is to profit from the victim's slippage tolerance. So if there is a 100 ETH buy for USDC with a 1% slippage tolerance, the search might buy ETH in front of the victim, then sell it back after the victim has shifted the price in the liquidity pool.

Sandwiching isn't a new concept or phenomenon, here's [a 2018 post](https://ethresear.ch/t/improving-front-running-resistance-of-x-y-k-market-makers/1281) where Vitalik describes the issue (as well as an attempted AMM-specific solution — I wonder if it was ever attempted in practice?).

[This article](https://medium.com/etherscan-blog/rapid-rise-of-mev-in-ethereum-9bcb62e53517) has a nice example of sandwich attack:

- [Transaction 1 (front slice)](https://www.notion.so/888724fb86347ad5661f284c71812f27)
- [Transaction 2 (victim)](https://www.notion.so/fe1c3bd2403c97d367d32d935069e332)
- [Transaction 3 (back slice)](https://www.notion.so/7420f5ef22906eb21ede036209bb119b)

The attacker swaps ETH for RUNE, the victim swaps SUSHI for ETH then ETH for RUNE, then the attacker swaps RUNE for ETH, ending up with ~0.06 ETH more than he started out with, for a ~0.04 ETH profit after tips (note the sandwicher's transactions do not pay for gas).

While looking for examples, I also found [this excellent review paper (pdf)](https://pub.tik.ee.ethz.ch/students/2021-FS/BA-2021-07.pdf) (from barely a week ago!). Figure 3.2 shows the average profit of sandwich attacks, most of which net less than 0.3 ETH.

The author also made an amazing [sandwiching simulator](https://defi-sandwi.ch/) which is useful to understand what size of orders lead to profitable sandwich attacks.

### 3. Arbitrage

An arbitrage exploits price discrepancies between various liquidity pools and/or other kind of DEXes to buy on one side and sell at a higher price on another price. This can be done using a flash loan, assuming the price difference is high enough that the fee on the loan does not annihilate profit.

[This article](https://medium.com/flashbots/quantifying-mev-introducing-mev-explore-v0-5ccbee0f6d02) shows [this transaction](https://www.notion.so/89ea77fb05836d7f347a8409f141599f) (from January 2021) which performs an arbitrage between three pools, generating 16.7 ETH of revenue, of which 12 ETH were paid to the miner. It used its own inventory (no flash loans).

### 4. Other

Other kinds of MEV, which form a long tail.

I'd love examples here, please send them my way.

## Good MEV, Bad MEV

Some forms of MEV can be considered good. For instance, in the case of loan liquidation, it would be "unfair" for the first person to get a transaction in to get the price. The current auction system seems preferrable, especially since it allows miners/validators, which secure the network, to partake in the profit. (Besides, a timestamp-based system is also ultimately an auction where the chips are extremely low-latency hardware and communication systems.)

Other forms of MEV are universally reviled, this is notably the case of sandwich attacks, which worsens the slippage incurred by large-ish token swaps.

It seems desirable to try to mitigate sandwich-like MEV. Not only do these have an undesirable economic impact on the ecosystem, they are also a PR disaster. People simply hate the idea to be charged an implicit fee that is not payment for service. See [this opinion piece](https://www.coindesk.com/miners-front-running-service-theft) as an example. Here is [another very misinformed one](https://www.rekt.news/return-to-the-dark-forest/). If you've been around MEV, you've probably seen the sentiment echoed elsewhere.

Besides, front-running exchange-traded securities trades is illegal, at least in the USA, and the SEC has been known to investigate and prosecute cases of front-running.

I'm not so much interested in debating whether front-running on Ethereum is legal or not, as to point out that there is a strong pre-existing social consensus that front-running/sandwiching trade should not be accepted.

### Reorgs

Recently there was a lot of debate about the possible incentives for miners to reorg the chain in order to capture MEV, but I don't want to dive into this can of worms today. It suffices to say there are a lot of pseudo-game-theoretic reasons for this not to happen — if everybody reorgs, nobody wins, the usual defect-defect outcome. The actors who can do this stand to lose more than they'll gain, as the FUD is likely to adversely impact the price. Reputational damage is also a factor to consider. Vitalik wrote about [the situation after the merge](https://www.paradigm.xyz/2021/07/ethereum-reorgs-after-the-merge/). TLDR, it should be much less of a concern, owing to much stronger technical guarantees.

## Existing Mitigations Against Sandwiches

The problem of MEV has not gone unnoticed, and as a result, there exist a number of schemes to defend against it. It's possible to guard against MEV at the user level (i.e. change the pattern of transaction), app/contract-level (change the protocol to avoid creating extractable value), or "relayer" level (using Flashbots or one of its competitors). There are also some proposed core protocol-level schemes, though less than we would perhaps expect.

The simplest, is a user-level mitigation which consists of splitting a big transaction into multiple smaller ones that might not be (as) profitable to sandwich. The [calculator](https://defi-sandwi.ch/) linked above can be used to see how splitting a transaction can reduce its cost if it avoids sandwich attacks

At the app level, the solution space is only bounded by imagination and ingeniosity.

I currently know of two designs that prevent sandwich attacks. The first are request-for-quote (RFQ) exchanges.

[Hashflow](https://www.hashflow.com/), [Tokenlon](https://docs.token.im/tokenlon-onboarding/en/) and [0x](https://0x.org/docs/guides/rfqt-in-the-0x-api) enable off-chain quoting by market makers with on-chain settlement. [Cowswap](https://cowswap.exchange/#/faq#general) does the same, but additionally allows permissionless p2p matchmaking off chain (i.e. transfers between anons instead of between anon & partnered market maker). Obviously, the centralized component of such CEX-DEX hybrids mean they are in principle susceptible to some forms of arbitrage, though in practice they have a clear incentive to quote better price than available on regular DEXes.

The second is the [TWAMM (Time Weighted AMM) design](https://www.paradigm.xyz/2021/07/twamm/). While its main goal is to split up very large orders to minimize their price impact and reduce slippage, the execution mechanism can be used to mitigate sandwiches. TWAMM sub-orders are executed lazily (whenever someone tries to access the state of the pool) as if the order had occurred in between blocks. This means that a sandwich attack against such sub-orders must straddle blocks, which entails a lot of risk (see the "[sandwich attacks" heading of the article](https://www.paradigm.xyz/2021/07/twamm/#sandwich-attacks) for more details). This is obviously a solution for very large orders, but depending on the fees, might also be a solution for smaller order that are nevertheless large enough to be sandwiched.

As a side bar, it's also possible mitigate loan liquidations at the protocol level. [KeeperDAO's kCompound](https://medium.com/keeperdao/introducing-kcompound-a23511c847a0) protects loans by setting a virtual liquidation threshold higher than the actual one (meaning it triggers earlier). If triggered, Keeper adds a buffer to prevent actual liquidation. If the health of the loan keeps declining, Keeper liquidates the loan, though (as far as I understand) at a much lower rate than the underlying loan platform. [B.protocol](https://docs.bprotocol.org/info/1) works on the same principle, with [some fancy innovations](https://medium.com/b-protocol/b-amm-efficient-automated-market-maker-for-defi-liquidations-fea7b0fdc0c5). [Cono Finance](https://medium.com/gelato-network/cono-finance-is-here-to-protect-your-aave-debt-positions-wagmi-4ed1b57f8ed5) rebalances collateral between multiple loans to avoid liquidations (does not prevent MEV per se but reduces its incidence rate).

Finally, one can guard against sandwich attacks by leveraging the privacy afforded by relayers. The simplest option is the [Taichi Network](https://github.com/Taichi-Network/docs/blob/master/api_en.md#3-send-private-tx--eth_sendprivatetransaction), which can be configure as [RPC network in Metamask](https://github.com/Taichi-Network/docs/blob/master/sendPriveteTx_tutorial.md), and will relay your transactions privately to Spark Pool ([currently 20% of the hash rate](https://www.oklink.com/eth/pool-list)). Otherwise, there are a few convenient UIs wrapping existing pools: [Archerswap](https://swap.archerdao.io/) wraps Uniswap & Sushiswap using [ArcherDAO](https://docs.archerdao.io/for-traders/for-traders/traders) (the option to MEV-protect is also offered directly on the official Sushiswap UI). [BackRunMe](https://docs.bloxroute.com/introduction/backrunme) is a product from bloXroute, using [bloXroute](https://docs.bloxroute.com/apis/frontrunning-protection) as a relayer that provides the same service. Finally, [mistX](https://www.paradigm.xyz/2021/06/how-mistx-uses-flashbots-bundles-to-provide-frontrunning-protection/) does the same using [Flashbots](https://github.com/flashbots/pm).

(As I was finishing this up, a new option called [BetaRPC](https://twitter.com/mevalphaleak/status/1424705369603989505?s=09) came out, which can be configured as an RPC endpoint, only relays vulnerable transactions, and dispatches between multiple relayers.)

If you're code savvy, you can of course integrate with the relayer API directly, also including [MiningDAO](https://miningdao.io/) which does not seem to have an end-user wrapper.

Why would these services graciously offer you private transactions, and hence offer to pay miners a little extra to include your transaction? It's simple: by keeping your transaction private, the network reserves the possibility to backrun it, in case it would move some price significantly enough to produce an arbitrage opportunity. Interestingly, BackRunMe kicks back 25% of the arbitrage profit (if any) towards the user (but charges 10% extra compared to the normal transaction fees). Other services are a bit more opaquely priced and do not seem to kick back arbitrage profits.

As you can see, there are a lot of ways to mitigate sandwich attacks at a low cost. This is not to say that there are no concerns. When using a relayer, you have that trust that both the relayer and the miner won't sandwich your transaction. It's unlikely that they will, but only because of reputational incentives. You're also exposed to a small risk that your transaction will land in an uncle block but not in the canonical block, meaning it loses privacy and searchers could pick it up to be sandwiched. This risk is particularly present when using Taichi, since your transaction is only relayed to 20% of the hash rate, leaving 5% (assuming that's the uncle rate) of your transactions exploitable. We might also be wary of giving even more power over the network to relayers. Flashbots is benevolent, but there is no guarantee its successor should be. Decentralizing relayers (i.e. block proposers & sequencers) is something that is being researched (more on this in a bit).

Well-designed RFQ DEXes should be trustless, but you do rely on a centralized component. TWAMM avoids both of these caveats, but has yet to be deployed in practice.

Nevertheless, I think we can conclude that sandwich attacks are much less problematic than they are made out of to be. There are many ways to avoid being sandwiched available today, at a moderate cost.

That being said, if we can do something about it at the protocol level, shouldn't we? Then sandwich-avoidance would be transparent and automatic, without need for users to proactively seek protection.

I agree, but the issue is rather difficult to solve. In the next section, I give some ideas on how this could be achieved. Those won't be bulletproof proposals, but rather the starting point of a longer reflection.

## Preventing Sandwich Attacks at the Protocol Level

In this section, I will propose two lines of thinking on how we could mitigate sandwich attacks, based on transaction shuffling and threshold encryption.

I want to underscore that I don't think these are two novel ideas. In fact, I believe they've been floating around for some time. However, I want to offer a more mechanistic "nuts-and-bolts" approach of how they could work in practice, walking you through some of the pitfalls. The target abstraction level is more concrete than a conference talk / design space overview, but less specific than an EIP.

A good snapshot of the current thinking around MEV is the [MEV.wtf conference](https://hackmd.io/ivUzk3piQEG8ALzCGbxlag) (some take-aways: [part 1](https://femboy.capital/SummitSummaryPt1), [part 2](https://femboy.capital/SummitSummaryPt2)).

### Idea 1: Priority List + Shuffle List

The first idea I came across regarding MEV mitigating was ["why don't we shuffle blocks"](https://github.com/ethereum-cdap/cohort-zero/issues/69#issuecomment-864027830). The immediate answer was that shuffling leads to transaction spam, as searchers try to be included near the top of the block for loan liquidations, etc.

The same issue has [popped up in the past](https://github.com/ethereum/go-ethereum/issues/21350) when geth was ordering similarly-priced transactions randomly, which would cause searchers to send a lot of transactions in the hope to be included right after an oracle update.

I thought up a solution: why not split the list of transactions into two parts: a prioritized list of transactions, at the top of the block, and a shuffled list of transactions below. Shuffled transactions could be sent using a new [EIP-2178](https://eips.ethereum.org/EIPS/eip-2718) typed transaction envelope.

Could this work? One issue is that if oracle updates are sent in the shuffled part of the block, searchers will be incentivized to spam. This can be resolved by working with the major oracle providers (and other services whose transactions originate MEV). There is the risk that eventually, someone will originate MEV from the shuffled transaction list, however.

In fact, there is one category of transactions that wants to be in the shuffled list AND creates MEV. Those are of course large swaps, which don't want to be sandwiched, but do produce an arbitrage opportunity by virtue of their size.

As a side bar, such opportunities could be greatly reduced by running large orders through DEX aggregators like [1inch](https://docs.1inch.io/api/), [Dex.ag](https://dex.ag/faq), [Paraswap](https://www.totle.com/), [Matcha](https://matcha.xyz/), [Totle](https://www.totle.com/), [SwapSwap](https://swapswap.org/)... which are able to split a swap across multiple DEXes to minimize the price impact. In fact, I believe some of the aforementioned DEXes (Cowswap, Hashflow, ...) do this as well if they can't find an off-chain match for your order. However, with a liquidity pool popping up seemingly every other minute, it's likely that aggregators can't keep up with searchers.

This is the crux: can we take the spam of those kinds of arbitrage (which should be rare)? EIP-1559 should help mitigate the negative consequence of the occasional spike in transactions.

Another important note: this does not completely prevent sandwiching, although it does greatly disincentivize it. In theory, a searcher could pay a miner to only include the victim's transaction and his sandwich. Then, if the searcher provides a slew of slightly different transactions (i.e. varying the amounts by a few weis, which will cause the transactions to hash differently), the miner could iterate until it finds the desired ordering.

More worryingly, the searcher could pay the miner to simply exclude any other transaction touching the pool on top of which the sandwich attack is run. Then it won't matter that the sandwich slices are right before or after the victim's transaction, just that the front slice happens before and the back slice happens after — since none of the intervening transactions can shift the state of the pool. The process is similar as before, but without incurring as much fee loss for the miner.

Here's a long shot mitigation: have the shuffle algorithm depend on the result of a [VDF (verifiable delay function)](https://adlrocha.substack.com/p/adlrocha-a-gentle-introduction-to) which runs with the list of transaction to be shuffled as input. Even if the VDF is targeted at 1/10th of the block time, this would make re-ordering the transactions un-economical under PoW. You can't start hashing while you're running the VDF, and each time you try to re-shuffle, you incur a 10% time loss (which should ultimately be a ~10% profit loss). The result of the VDF would have to be included in the block, to enable speedy verification.

In PoS, a larger delay should be targeted (50%?) as there is no loss of hash rate.

However, I should say I don't know that much about VDFs, and I'm vaguely uneasy about their future-proofness, especially at such a fine time resolution.

Worse, it doesn't even work all that well. A searcher can include their front slice in the priority list, bribe the miner not to include any other transaction to touch the pool, and submit enough copy of the back-slice transaction that statistically, one is almost guaranteed to land somewhere after the victim's transaction.

I'm not very hopeful on this solution. It feels like a lot of engineering for something that ultimately fails to theoretically prevent the sandwiching of a very juicy transaction — though it certainly greatly limits the number of sandwiches per block. But hopefully walking through the reflection process was helpful.

While I'm talking of shuffling transactions, I'd be remiss not the mention [the "Alex" design](https://ethresear.ch/t/targeting-zero-mev-a-content-layer-solution/9224) by P McGoohan. I am personally skeptical of introducing such a complex design — introducing no less than four roles and a number of components (queues, pools, ...). Something I do like about it is that it prevents censorship and "order mining" (as seen above) by having actors collaborate to pick the block's transactions. Maybe it is worth considering a simpler protocol where validators collaborate to establish a canonical list of transactions under consideration. The proposal does however fail to disincentivize transaction flooding (this could be largely mitigated by adopting a priority list).

### Idea 2: Encrypted Transactions

The other big idea in avoiding MEV is to encrypt transaction. After all, if you don't know that a MEV creation event is coming, you can't exploit it. This is only partially true — arbitrage opportunities and liquidations will become visible once the transactions become public. But this moves all MEV to the "top-of-the-block" priority auction paradigm, which is much easier to manage and, crucially, sandwiching is no longer possible.

The logistics of encrypting transactions is not trivial, however. Let's design a strawman scheme to illustrate. In this strawman scheme, users send signed commitments for their (private) transaction. The miner will mine the block containing the commitments, after which the users would reveal their transactions, to be included in the next block (along with a new batch of commitments), in the same order as the commitments.

There are multiple problems with this scheme, besides the added technical complexity at the consensus and networking layers. First, we have to make users accountable for actually revealing their transactions. We could imagine that commitments are paired with a small bond that would be forfeited if the user does not reveal its transaction. But then we run into the problem that miners could sensor users to destroy their bond. We're also introducing a one-block latency in transaction execution.

To avoid the logistics of the reveal part and the censorship issue, transactions could be encrypted using the result of a verifiable delay function (VDF). For this to work, the VDF must take longer than the usual block time to execute, so we still have to contend with the lag. And I have the same reservations as before about VDFs

I have a better idea, leveraging PoS — but I'm not sure how feasible it is (haven't had the time to dig in the eth2 specs yet). Feedback welcome!

The idea is to use threshold encryption. We could include, on-chain, a public key that can be used to send encrypt transactions that can only be decrypted through the collaboration of a majority of attestors (I'm hoping this is feasible given the committee size). Users would encrypt their transactions using this key. The block proposer would then select transactions to form a block, sign it, and broadcast it to be signed by a majority of attestors, which would then collaborate to decrypt the transactions. The block proposer then releases the block matching his commitment. If he doesn't, any validator can use the signed commitment to slash the block proposer.

Now, this and the previous scheme ignore the fact that we still need to contend with the fair extraction of some MEV. To handle this, I just propose to use a priority list, as in idea 1.

As I was finishing up this write-up, Marcello from Nethermind came up with a remarkably similar idea, which you can read about here: [MEV mitigation protocol based on SSS](https://ethresear.ch/t/mev-mitigation-protocol-based-on-sss/10292)

His idea is more detailed, and he proposes using [Shamir's Secret Sharing](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing) (SSS) for threshold encryption. The technical details of the encryption idea are probably best discussed over at his posts.

## Democratizing MEV Extraction

As I said near the top, the community's approach towards MEV is "minimize what MEV we can, democratize the extraction of what MEV is left". My ideas tackled the "minimize MEV" side of that equation. Research efforts, on the other hand have mostly focused on MEV democratization. I think it's interesting to briefly look at why. It will also show that these proposals are completely orthogonal to MEV minimization.

The community at large benefits from some forms of MEV extractions, namely arbitrage and liquidations. It does not however profit from richly rewarding MEV searchers (nor do they profit from sandwiching).

As a community, we would like to maximize the amount of extracted MEV that goes towards things that benefit the community. The simplest form of this is having it go towards the miners / validators, as those contribute to the security of the network. As the rewards increase, the network can accommodate more miners/validators.

As we will see, there are even proposals to divert, at the protocol level, the revenue from MEV to directly benefit "public goods".

The main point is that we want MEV extraction to be competitive. The more competitive MEV extraction is, the higher the fraction of their profit searchers will have to bid to win the auction for bundle inclusion. The more searchers they are, the less practical it is for them to collude and keep tips low. For MEV extraction to be competitive, it needs to be as accessible as possible.

A problem with the way MEV is currently extracted is that it relies on a small number of **centralized** relayers. While those (and in particular Flashbots, the largest) seem to be benevolent, they nevertheless are in a position where they could have a significant impact on the network.

I haven't thought much on all possible scenarios here (feel free to contribute), but one particular thing to be worried about is that these relayers are able to effectively push against MEV democratization and competitiveness. They could do this by gatekeeping access and only letting in large established players. They could also help coordinate the searchers around price fixing, for instance by mandating a tip cap in % of transaction proceeds.

Here are a few proposals that have been made to assuage these concerns:

- [Vitalik proposes baking a block-builder market into the protocol.](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) The goal being to ensure that no one can be prevented from competing on transaction ordering. Note that nothing prevents these block-proposer to auction of the inclusion of transaction bundles in the block they are building.
- [Karl from Optimism proposes including MEV auctions (MEVA) into the protocol](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788) (same idea as before) but additionally redirecting the proceeds towards a public goods fund. (Note that MEVA is now used mostly for Flashbot-style auctions.)
- [The Flashbots teams proposed MEV-SGX](https://ethresear.ch/t/mev-sgx-a-sealed-bid-mev-auction-design/9677), a decentralized scheme for MEV auction that would leverage SGX secure enclaves to ensure transaction/bundle privacy and permissionlessness (anyone can participate and nobody is kept out). Of all the proposal, this is the most concrete/detailed, and the Flashbots teams is working on it. It is not a core-protocol-level solution.

## Conclusion

So, this was quite a bit of text. Besides brushing up on MEV basics, here's what I hope to have accomplished:

- Made the point that sandwich attacks are the worst kind of commonly occurring MEV.
- Shown that there are many ways to mitigate against sandwich attacks today. Those might not necessarily be long-term stable, but it shows that the urgency of the problem might have been overstated.
- Proposed using a prioritized list of transaction along with a shuffled list of transactions as one idea on how to mitigate sandwich attacks.
- Shown that this scheme can never truly avoid all sandwich attacks, although it effectively bounds the number of sandwich attacks per block, and make those attacks much more costly.
- Proposed using threshold encryption under PoS as one way to mitigate sandwich attacks
- Here the concern is that of feasibility, given my relative ignorance of the details of PoS and threshold cryptography. Input greatly appreciated.
- Go check Marcellus' post for a similar idea with a bit more details: [MEV mitigation protocol based on SSS](https://ethresear.ch/t/mev-mitigation-protocol-based-on-sss/10292)
- Made the point that MEV democratization and minimization efforts are orthogonal.

All your thoughts, remarks & feedbacks are welcome.