Enablement of MEV and the Morals of Extracting

Let’s start with a definition for the MEV acronym:

Maximal extractable value: The maximum amount of value an agent can extract by including, excluding, or changing the order of transactions during the block production process

To put it more clearly, the concept of Miner Extractable Value (MEV) refers to a scenario in which an agent examines a user’s recent transaction, devises a strategy to generate profit from it, and subsequently implements that strategy to seize any potential earnings.

Thanks for reading Cryptocurrency and Friends! Subscribe for free to receive new posts and support my work.

Subscribe

More often than not, an agent who successfully captures MEV will do so at the expense of another party. It may be the user issuing a transaction or a passive agent in a DeFi protocol.

The very simple act of making money by interfering with the execution of a pending transaction has huge ramifications for users, DeFi Protocols, and the underlying blockchain network.

We’ll present some background information about MEV before diving into the core discussion — what is the morality of MEV? Both in the context of agents that exploit MEV and actors who attempt to defend against it.

Agents within the MEV Game

In addition to users seeking to engage with a smart contract, there are two other crucial roles deeply intertwined with the concept of MEV:

• Searcher. An agent who finds an opportunity to make profit from a user’s transaction, creates a bundle of transactions to exploit it, and proposes the bundle to the proposer.
• Proposer. An agent with the authority to decide the ordering of transactions.

A searcher can be a trading firm with extensive expertise or a hobbyist coding in their bedroom.

Being a searcher is a permissionless role.

The only obstacle is the searcher’s ability to find alpha, build a competitive MEV bot, and exploit the opportunities. Access to capital helps, but it is not yet a significant obstacle.

On the flip side, a proposer wields the power to determine the sequence of transactions and, consequently, the outcome of their execution. This pivotal role can be filled by various entities, including Miners (in proof of work systems), Stakers (in proof of stake systems), or Sequencers (in rollups).

While the pool of proposers is typically restricted, it can be open access.

There exist compelling reasons for imposing limits on who can take on the role of a proposer:

1. Consensus Protocol: Many blockchain systems necessitate proposers’ involvement in a round-based protocol, requiring cooperation from a majority (or supermajority) of them in each round. Coordinating communication among all N participants often proves to be a bottleneck.
2. Transaction Routing: Users must have a reliable means to transmit their transactions to the proposer. This can be achieved by forwarding transactions to a public memory pool or directly to the designated proposer.
3. Verifiable Integrity: The broader community may seek an objective metric to verify that all proposers are working together as a collective to decide the order of transactions and that they are always extending the latest ordering. For instance, the network may implement a fork-choice rule where a proposer builds on top of the heaviest chain (stake/work).
4. Risk of MEV: In some blockchain systems, particularly most rollups today, proposers are entrusted with the responsibility of not exploiting MEV opportunities. Hence, it’s crucial for the community to have the authority to decide whom they trust.

In simpler terms, there must be a mechanism that allows a user to verify, in an independent manner, whether a proposer holders the authority to decide the ordering of recent transactions. Without this assurance, malicious actors could flood the system with bogus transaction orderings, leaving users unable to discern the truth.

To keep the explanation of agents simple, we incorporate the role of a builder into the proposer, and assume a proposer will both build a block and have the authority to publish it.

Interplay and Relationship of Agents

What is the interplay between the searcher and the proposer?

A large focus of MEV research is understanding the interplay between searchers and proposers. Furthermore, it’s essential to establish whether these roles can be fulfilled by the same entity or if they necessitate distinct agents:

• Same agent. The searcher can be a proposer in the system,
• Separate agents. There are one (or more) searchers who are not proposers and they are all competing to influence the proposer.

Put another way, it is important to identify whether a searcher can have full and undisputed control of the transaction ordering policy. If the searcher is also the proposer, then it can potentially grant the searcher added power to observe the tactics employed by other searchers, enabling them to potentially steal opportunities from more competitive searchers.

On the other hand, if searchers cannot be proposers or collude with proposers, then it allows us to assume an environment where searchers must compete against each other. Their goal is to sway the proposer and persuade them to order a list of transactions according to the winning searcher’s preference.

Outsourcing vs. Monopoly in MEV Profit Maximisation: There is an interesting debate whether it is more lucrative for a proposer to subcontract the task of identifying and capitalising on MEV to an open marketplace of searchers or if they should instead aim to consolidate the opportunity through a monopolistic approach.

We will assume that a proposer will act as an honest party and stick to their promised transaction ordering policy. Additionally, that searchers and proposers are always separate agents.

Our focus is understanding the strategy used by a searcher to influence the ordering policy of a proposer and hopefully beat all other competitors to the same opportunity.

Transaction Ordering Policy

The pursuit, and defence, of MEV focuses on the searcher’s ability to influence a single component of the blockchain system:

• Transaction ordering policy. Given a list of pending user transactions, which ordering algorithm is applied to output the final list of ordered transactions (i.e., a confirmed block).

A blockchain system can implement a variety of ordering policies and its goal is to offer fairness to all users who may want to transact.

This prompts the inquiry: What is the definition of fairness?

• Should users all pay the same fee and transactions are ordered on a first-come-first-serve basis?
• Should users pay a fee according to the transaction’s priority and all transactions are ordered based on the fee paid?

Both cases follow the general principle that a user can transact as long as they have the capability to pay. It does not dictate the user’s transaction will have a promised position in the total ordering, only that it will eventually be ordered for execution in a timely manner.

This concept of fairness, which underpins why a blockchain network is censorship-resistant, is interesting.

It outlines that a user’s ability to transact should only depend on their ability to pay, and they are not discriminated based on their geographical location, identity, gender, or belief-system. It originates from the realm of Bitcoin and it can easily be applied as the network only supports payments.

However, the ability to guarantee the inclusion of a transaction falls short when we attempt to understand fairness within a smart-contract enabled system. For a network like Ethereum, we must broaden the scope of fairness beyond transaction inclusion in the global ordering. It should also consider the intent of a user who signed the transaction and whether the user’s desired outcome was achieved after the transaction was executed.

Recognising the Vital Role of User Intent in Fairness. Users gauge fairness, not only on the ability to include a transaction in a timely manner, but by evaluating the actual outcome of their transaction and whether it aligns with their initial expectations when they signed the transaction.

This can lead to a new, and interesting, definition for what we mean by censorship-resistance:

• Weak censorship resistance. A user can always order a transaction for execution as long as they are willing to pay the appropriate fee for it.
• Strong censorship resistance. A user can force the intended outcome of their transaction and again they only need to pay an appropriate fee.

Keep this in mind, as it will become important when we understand how MEV can be leveraged to interfere with a user’s transaction and force it to fail its execution. Thus, even though a user’s transaction can be forcefully included in the total ordering, the user’s desired outcome (intent) cannot be achieved.

It appears, to the best of our knowledge, that a ordering policy must prevent searchers having the ability to selectively interfere with a user’s transaction, if we want to build a system with strong censorship-resistance. This remains an open research problem.

The enablement of OFAC sanctions via Relays is actively testing whether a blockchain network can continue to treat users fairly based on their ability to pay for transaction inclusion.

Enablement of MEV

To delve deeper into the technical aspects of Miner Extractable Value (MEV), we must examine the following:

1. Locating MEV opportunities: Understanding how a searcher can discover a user’s recent transaction within the blockchain system.
2. Execution Environment: Examining the technical environment in which all transactions are executed.
3. Exploitation Strategies: Investigating the various strategies that a searcher can employ to exploit MEV opportunities, such as transaction reordering, front-running, and arbitrage.
4. Influencing Ordering: Exploring how a searcher can influence the proposer to prioritise the inclusion of their MEV-related transactions.

Once we’ve established a firm grasp of these fundamental components, we can proceed to evaluate the ethical implications and moral considerations surrounding MEV.

Locating MEV Opportunities

A searcher needs access to recent user transactions to find new MEV and money-making opportunities.

There are two approaches for finding transactions:

• Gossip protocol. A user submits their transaction to the peer to peer network and the transaction is propagated to all nodes within a very quick time frame (<1 seconds).
• Proposer feed. Proposer publishes pending and/or recently ordered transactions.

The majority of users send their transactions on the gossip protocol with the hope that a proposer will discover their transaction and include it in their block. At the same time, anyone including searchers, can join the gossip protocol and listen for pending transactions.

It has led to ‘Dark Forest’ nickname as it is almost guaranteed that a searcher will find a user’s transaction and interfere with its execution if there is a money-making opportunity. For example, in the Dark Forest post, the authors failed to recover at risk funds as a searcher discovered their transaction, evaluated it, and collected the funds for themselves.

To date, the only way to defeat the dark forest is to avoid sending a transaction to the peer to peer network. In a subsequent post, the authors Escaped the Dark Forest by sending their transaction directly to an Ethereum miner. This, alongside other instances, eventually led to the Flashbot offering a direct transaction feature which allows a user to send their transaction directly to a trusted miner (as a service).

There is still a risk that MEV bots can exploit a direct transaction if the blockchain experiences a re-org and the user’s transaction is temporarily unconfirmed and placed in the memory pool. However, re-org events are relatively rare in proof of stake Ethereum compared to 7% of all blocks in PoW Ethereum.

The same risk does not apply on rollups (as implemented today). Almost all transactions are direct transactions as users have a direct communication connection to the Proposer (Sequencer). There is little to no opportunity for a searcher to eavesdrop on the channel and it significantly increases the difficulty to exploit MEV opportunities for pending transactions.

This has led to a perception that rollups have defeated the searchers. To date, any success has hinged on the trustworthiness of Proposers not exploit MEV for their own gain. Of course, this is not the entire story, and searchers can still find MEV opportunities.

In rollups, thanks to direct transactions, searchers have shifted their focus to locating recently confirmed transactions in the hope to find arbitrage-like opportunities.

For example, in Arbitrum, the Proposer maintains a feed that publishes recently ordered transactions. It is published every 250 milliseconds, primarily to assist infrastructure providers such as Infura and Etherscan in obtaining the most up-to-date data. This allows a user to send a transaction to the Sequencer and then check its status on Etherscan. Additionally, it allows anyone to run an Arbitrum node with Sequencer confirmed state.

Regrettably, MEV bots discovered this feed. A searcher will connect to the feed and exploit arbitrage-like opportunities from recently ordered transactions.

Any information about transactions can enable MEV. Most discourse about MEV focuses on the ability for searchers to locate and interfere with the execution of pending transactions. However, even if the Proposer is completely trusted not to allow searchers to locate pending transactions, there’s still the potential for searchers to utilize any information made available by the Proposer.

Shared Database State

The final execution of a transaction can be different to the expected execution at the time of signing the transaction.

Every blockchain system operates as a finite state machine and in this context there’s a state transition function (STF) that takes:

• Latest database state,
• User’s input.

Upon execution, the STF will output a new state of the database. We can summarise it as the following:

• STF(database_state, user’s input) = new_database_state

When a user initiates a transaction, they target a specific state transition function along with their input. It’s important to note the transaction doesn’t commit to the current database state; the latest database state is only known when the execution occurs.

In a blockchain system, the state transition function includes many components that may impact an update to the database.

To keep it simple, it is most notably defined by a virtual machine like the EVM, WASM, MIPS, or Cairo. Going a bit further, when a developer deploys a smart contract onto the virtual machine, they are locking an entry of the database for exclusive use by the smart contract. The database entry can only be updated when the smart contract executes on it.

A smart contract defines write access to a specific database entry.

So, when a user initiates a transaction and targets a smart contract, they are intending to update a specific entry in the database or any database entries that smart contract has write access too. Because the smart contract defines write access, it can define who is allowed to perform that action.

In the majority of cases, a smart contract operates with an inclusive policy, permitting anyone to execute it as long as they meet certain predefined criteria. Unless the smart contract function serves an administrative purpose, the criteria will not depend on the identity of the transaction initiator but are rather employed to uphold the rules governing the smart contract. For example, checking the user has a sufficient balance of token X before performing a swap of Token X → Token Y.

In summary, we must take into account two key aspects of a transaction:

1. Non-Commitment to Output: When a user signs a transaction, they aren’t locked into a specific execution outcome. Their signature covers the inputs and the target smart contract but doesn’t dictate the exact execution.
2. Smart Contract Preconditions: Smart contracts establish conditions that must be met for a successful execution. These conditions often revolve around enforcing protocol rules (such as swap logic) rather than the identity of the caller.

Both components are necessary to facilitate users to issue transactions at the same time and to deal with race conditions. Otherwise, as we saw with the launch of swaps on Cardano a few years back, it can lead horrendous usability issues.

At the same time, it leads to the enablement of MEV on any smart contract platform as it allows a bot to interfere with the execution of a user’s transaction and potentially generate a profit by doing so.

Transaction Bundles and Interference Methods

Thanks to the public nature of:

• User transactions,
• Shared database state.

A searcher can simulate pending transactions and have full insight into future database states. Their task is to simulate transactions and determine whether there is a future database state that is profitable for them. If so, then they should strive to make the future database state occur and capture the profit opportunity.

Once they find a pending transaction that is profitable for them, then the searcher can execute one of two strategies:

• Do not interfere. Allow the user’s transaction to execute as expected and the searcher will follow up with their own transaction that takes advantage of the resultant database state.
• Do interfere. A searcher must issue transactions that set up the ideal conditions before the user’s transaction is executed.

The do not interfere approach is straight-forward. The searcher has essentially pre-computed what the database will look like after the user’s transaction is executed and they can issue a transaction that execute after the fact and capture the resultant profit. As an example, a searcher may chase an arbitrage opportunity by back-running a user’s transaction.

A searcher may issue two transactions that sandwich a user’s transaction and interfere with its execution to collect a profit.

The do interfere approach requires the searcher to issue transactions and aim for their transactions to ordered before the user’s transaction. This will impact the execution of the user’s transaction and hopefully result in a desired database state that is profitable for the searcher.

Two examples of interference include:

• Sandwiching. A searcher will issue two transactions that surround a user’s transaction. It will interfere with the user’s transaction execution in order to collect a profit.
• Front-running. A searcher will copy the user’s transaction and get it executed before them. It allows the searcher to steal the profit opportunity before the user.

For the do interfere approach to work, it needs to make assumptions about the transaction execution model. As mentioned previously, we assume a user’s transaction has no fixed outcome at the time of signing and its final execution is dependent on the shared database state.

Thanks to the execution model, and the fact that a user can define a set of pre/post conditions that must be satisfied before the transaction to successfully execute, it can be argued that a user defines a range of acceptable outcomes, even if it may be used against them by searchers looking for an opportunity to capture profit.

The idea that a user has the authority to approve a range of acceptable outcomes is important when evaluating the morals of MEV.

Influencing How a Proposer Prioritises Transaction Ordering

This brings us to the final piece for enabling MEV — understanding how a searcher can convince the proposer to prioritise their bundle of transactions at a specific position in the total ordering.

The approach taken depends on the ordering policy implemented by the Proposer, but it generally falls into two categories:

• Priority Auction. A searcher must pay a bid that is higher than all other searchers.
• Latency Games. A searcher must send their transaction (that pays an appropriate fee) to the proposer before all other searchers.

Put another way, we need to consider the competition amongst searchers, how they can outcompete each other and which approach has the ability to enable an open-market of searchers to participate on a level-playing field.

An example of a priority gas auction as searchers constantly broadcast new transactions with a higher fee. There are at least 100 transactions within the 12-second block window.

Thanks to the public nature of a gossip protocol and the fee market auction mechanism on Ethereum, a new phenomenon emerged as the community became aware of MEV and it led to significant network congestion.

In the Dark Forest, if a single searcher finds an MEV opportunity, then it is very likely that other searchers will find it as well. Only one searcher can win the MEV opportunity and as a result it leads to a very competitive bidding war called a priority gas auction.

In a priority gas auction, a searcher wants to pay the minimum necessary bid that is higher than all competitors while maximising their profit. They must monitor the current sets of bids (in the memory pool) and issue a new transaction with a higher bid. All new transactions should replace their previous transaction.

Competitors repeat the above process and it results in significant spam hitting the peer to peer network. For example, in the above chart, we can count at least 100 transactions within a 12 second window. Additionally, only one transaction can succeed and capture the MEV opportunity. All competing transactions are still included in a block and will likely fail to execute. Wasting both bandwidth and blockspace.

Flashbots fixed the congestion issue associated with priority gas auctions by moving the auction off-chain.

Flashbots emerged with a solution to alleviate the issues associated with priority gas auctions.

Flashbot’s solution: Take the priority auction protocol for picking the winner and move it off-chain.

All searchers were encouraged to submit bundles to a Relay run by Flashbots. It was up to the Relay to pick the winning bid and forward it to the proposer. All failed bids were discarded by the Relay.

This paved the way for the development of the proposer-builder separation (BPS) framework, a concept that distinguishes between the block builder who orders transaction for a block and the block proposer who is endowed with the authority to decide the final content of a block.

The separation of roles fosters an open marketplace for builders, as well as searchers, to collaborative create profitable blocks while sharing a portion of the profit with the proposer via a priority auction. The primary goal is to ensure no single party can take all profit generated by MEV opportunities.

The process for convincing a proposer is very different for a layer-1 blockchain like Ethereum compared to a rollup like Arbitrum.

Ethereum has ~800k validators, a public memory pool, and the process of picking the validator to become the next proposer depends on a random beacon. Whereas, Arbitrum only has a single Sequencer (Proposer) who has a private memory pool, easily identifiable and users can have a direct connection with them.

The rollup environment impacts how a searcher may attempt to influence the proposer as they no longer have access to pending directions and there is only one (or a few) parties to convince.

As mentioned previously, a searcher can:

• Listen to the Sequencer feed,
• Find recently ordered transactions,
• Leverage back-running strategies to capture MEV opportunities.

A searcher can increase their chance of winning the competition a profit if they are the first bot to learn about the MEV opportunity and they have the fastest connection to the proposer. Put another way, without a priority auction, the only way for a searcher to win is to compete in a latency game.

Searchers discovered, upon studying the Sequencer feed policy, that the feed will randomly prioritise a different web-socket connection to receive the transaction first.

The best strategy was to simply open as many connections as possible and receive the transaction first by winning the connection lottery. This led to >150k connections to the Arbitrum Sequencer.

The excess connections were a waste of resources, a potential denial of service attack on the Arbitrum Sequencer, and only beneficial to searchers who can successfully compete in a latency game.

Timeboost proposal. Combines first-come-first-serve with priority auctions. The majority of transactions can be ordered according to FCFS, but searchers have an opportunity to participate in a priority auction for back-running opportunities. Thus, it removes any latency advantage while still allowing users to enjoy a FCFS ordering policy.

Morality of MEV

All eco-systems need to grapple with the following question:

Should we foster an MEV environment or attempt to prevent it entirely?

Surprisingly, there is no straight-forward answer, yet many in the technical community have a binary opinion on the topic.

The word MEV sparks an emotion in many people that we are just throwing users to the wolves and it is always bad

There are two schools of thought around the exploitation and prevention of MEV:

• Anti-MEV camp. MEV as harmful. It is akin to throwing a user to the degen wolves and allowing them to be maximally exploited. We should do all we can to prevent its exploitation.
• Pro-MEV camp. MEV is good. It provides a financial incentive for searchers to perform actions that ultimately benefit the user experience and stabilities the marketplace. Even more, MEV exploitation is inevitable and we should do all we can to embrace it.

There are some easily identifiable factors contributing to the binary-like opinions within the community. More often than not, the perspective is rooted in anecdotal evidence and personal experience within the financial sector.

Some argue that the prevalence of high frequency trading in the traditional finance system tends to disadvantage smaller traders while favouring large trading firms who have the resources (and permissions) to execute their trades more quickly. Plus, it leads to users performing the trade to get the worse deal while allowing large firms to profit from it.

In contrast, others view the exploitation of MEV inevitable due to the open and permissionless nature of blockchain systems. It is an inherit aspect of how the system operates, and arguably, the stability of a blockchain system depends on our ability to maximise extract while sharing its profits to all participants.

Evaluating how MEV impacts a Blockchain System

Stolen from mev.day — a large focus of flashbot events is to understand how MEV impacts the consensus protocol of a blockchain system (like proof of stake).

To understand whether MEV is morally justifiable, we should evaluate how it impacts the fair reward assumption of layer-1 blockchain systems and whether it negatively impacts the intent of a user’s transaction.

Fair Reward for All Proposers

A core property for a layer-1 blockchain, like Bitcoin and Ethereum, is that all proposers make approximately the same reward for producing blocks on behalf of the network.

The motivation to offer a fair reward for all proposers has two key aspects that underpin the security and reliability of a blockchain system.

• Keep the proposer set decentralised. Firstly, it aims to prevent a single proposer from growing disproportionately larger than all other proposers over time, which could potentially enable them to accumulate enough capital to execute a 51% attack.
• Financial incentive to follow the longest chain. Secondly, it creates a financial incentive for all proposers to consistently extend the longest chain. If a block’s reward significantly surpasses the next block, then there is a risk that a proposer might be incentivised to re-org the chain’s tip, resulting in instability for users.

In the Ethereum community, the above insight has led to proposer-builder separation (PBS) as a method to democratize the profits of MEV. Put another way, the focus of embracing MEV is to fairly share the rewards across all Proposers, and ultimately protect the network’s decentralization and reliability.

A rollup does not focus on a fair reward for hundreds of thousands of participants, but to reward any party willing to step up and keep the system alive.

Conversely, the requirement to offer a fair reward to all proposers is different in a rollup ecosystem, primarily because of the divergent underlying trust assumptions.

In a layer-1 blockchain, such as Ethereum, the trust assumption rests on a majority of proposers acting honestly to maintain the system’s integrity. It should optimise for a vast network of diverse participants and rewarding them for their uptime.

In a rollup, the trust requirement is far more modest:

• Safety. One honest party to safeguard the system’s integrity.
• Liveness. Any user can submit their transaction using the on-chain forced inclusion mechanism.

Of course, the forced inclusion mechanism should be a last-resort option that can be used by the user (I am not a fan of based-rollups).

Nearly all users depend on the appointed Proposer to decide the ordering of transactions and to offer a soft confirmation about how their transaction will eventually execute. Soft confirmations can be upheld by a single proposer, or multiple proposers working together. You can read this article to learn more about the different tiers of transaction finality in a rollup.

Decentralized Sequencing. Some rollups may seek a stronger trust assumption, like an honest majority, if they want to guarantee uptime of soft-confirmations amongst a committee (or set) of Proposers. It is not a strict requirement for a rollup and various options are still being explored by the community.

The important takeaway is that a rollup does not necessarily need to guarantee the uptime for hundreds of thousands of participants or to maximise the decentralisation of participants. The priority is to ensure the system is openly accessible and a single honest party can step in at the right time to protect it.

Thus, there is a weaker need to embrace MEV and offer a fair reward for all proposers of a rollup, especially if there is only one proposer. The question to embrace MEV is not for security of the system, but whether it is in the proposer’s best interest to leave money on the table or to capture some profit from an additional revenue stream.

It remains an open research question, but empirical evidence that most rollups today have successfully operated with a single Sequencer while not embracing MEV, suggests this conclusion.

Interference of a User’s Transaction

Another facet to consider when evaluating the morality of MEV is to understand the potential influence, whether positively or negatively, that a searcher’s transaction bundle can exert on the execution of a user’s transaction.

We argue that only focusing on how it impacts the intent of a user’s transaction is overly limited.

An evaluation should encompass a broader perspective that takes into account ramifications on agents within a DeFi protocol, as well as its capacity to contribute to the synchronous operations of DeFi protocols.

Let’s take this opportunity to consider specific examples of transaction bundling and whether it can be justified as a moral activity.

Front-running

Front-running attacks can lead to censorship by forcing a user’s transaction to fail.

The strategy is often associated with a searcher evaluating a user’s transaction, copying its content, and stealing the user’s opportunity.

• Negative — Guaranteed Tx Delivery
  • Near’s Rainbow Bridge took advantage of MEV bots to guarantee transaction delivery for their fraud proofs. This helps to protect the integrity of a DeFi protocol and ultimately protects users.
• Negative — Censorship issues
  • Front-running can enable censorship as the searcher forces the user’s transaction to fail.
  • This was witnessed when Vitalik was attempting to “dump” SHIBA tokens and MEV bots interfered with his trades to prevent his ability to sell the tokens.
  • Vitalik was forced to migrate to CoW Swap and send this transactions directly to the proposers (miners).
• Positive — Cannot recover exposed funds
  • In the Dark Forest example, the MEV bot was able to steal the funds while the user tried to recover it from an exposed/broken smart contract.

Sandwiching

The strategy is often associated with a searcher changing the exchange rate before and after a user’s trade.

• Negative — Worst exchange rate
  • There are many instances of sandwiching where a user ultimately ends up with the worst exchange rate when performing their swap. This is because the searcher moves the price not the user’s favour, the user’s swap executes, and then the searcher moves the price back.
  • The searcher benefits by creating an arbitrage-opportunity and collects any positive slippage that the user may have received. There are arguments that sandwiching can be beneficial for routing trades, but most discourse focuses on the immediate negative experience for the user.
• Positive — Best exchange rate (Positive).
  • Just In Time Liquidity (JIT) entails the searcher strategically injecting concentrated liquidity just before the user’s swap and subsequently withdrawing it immediately after the swap.
  • This allows the user to secure a more favourable exchange rate when performing their swap while the searcher earns the bulk of the fees for facilitating the swap.
  • Passive liquidity providers (LPs) may find themselves at a disadvantage, as they receive minimal to no fees since it’s the searcher’s liquidity, not theirs, that is utilised to execute the swap.

Unfortunately, it was recently discovered in the wild that both sandwich strategies can be combined and results in the worse of both worlds. The user will receive the worst exchange rate and allows the searcher to obtain most of the fees for facilitating the swap. Thus, both the user and passive LPs lose out.

Back-running

The strategy is often associated with a searcher chasing an arbitrage-like opportunity.

• Arbitrage-like opportunities (Positive).
  • The most common case for backrunning, to the best of my knowledge, is when a searcher wants to arbitrage the exchange rate after a large swap performed by the user.
  • This is beneficial to the synchronicity of DeFi Protocols as it keeps the price of tokens in sync and ultimately for the user as they are always paying the market rate when exchanging for a token.

I cannot recall any back-running strategies that have a negative impact on a user or DeFI protocol. If you can think of any, please leave it in the comments!

Objective Assessment with Subjective Judgements is Required

We can shine a light into the dark forest, objectively measure its impact, and then make a judgement call on whether it should be embraced (and to what extent).

There is an increasing need for an enhanced methodology to gauge the impact of MEV.

This methodology should encompass:

• Transaction bundle strategy,
• Application-specific effects,
• Profitability for agents it benefits,
• Potential losses for agents that do not benefit,
• Frequency of occurrence.

With objective metrics as the above, the community can then make a value-judgement on its morality. For example, if we consider Just in Time liquidity, it provides users with a better exchange rate for tail-end assets, and if it represents <1% of all trades, then it could be a justifiable MEV strategy to allow as the benefits outweigh the risks.

To the best of my knowledge, the above type of analysis is completely missing in the discourse of MEV. The on-chain data is available, but the data set is not yet easily accessible for the above analysis.

There is a discussion to be had in the community on how to strike the balance between supporting MEV activities while maintaining fairness in the ecosystem, where fairness should be explicitly defined,

Enforcing Subjectiveness?

The discourse surrounding the acceptance of morally justifiable forms of MEV prompts a fundamental inquiry:

Who, in the blockchain system, has the responsibility for upholding the subjective judgements on what type of MEV should be embraced or restricted?

In the context of a layer-1 blockchain like Ethereum, there is no central authority empowered to impose subjective judgements. The responsibility for determining whether certain types of MEV should be excluded falls upon individual proposers or builders. However, such exclusions are often impractical without coordinated collective action.

Furthermore, given the community’s commitment to preserving credible neutrality and upholding the principles of decentralisation to safeguard the right to transact, enforcing any form of subjective judgement on a network like Ethereum is highly unlikely. Even the OFAC sanctions enforcement ultimately failed to garner 100% support.

Now, when we shift our focus to a layer-2 rollup solution, we encounter a different scenario.

Here, a single entity, the Proposer, possesses the authority to enforce subjective judgements regarding soft-confirmations they may choose to provide for transactions. For instance, in most rollup implementations, trust is placed in the Proposer not to exploit their privileged position for additional rewards through the manipulation of MEV opportunities. However, it’s conceivable that in the future, a Proposer might opt to restrict specific forms of MEV — at least to the best of their ability to do so.

This raises the question on the practicality to enforce subjectiveness and leads to an interesting research problem:

Facilitate soft-confirmations for selective MEV. Evaluate the effectiveness for a Sequencer to inspect transactions in real-time, determine the MEV strategy deployed and decide whether they should be rejected, without impacting the overall user experience or increasing the system’s latency for soft finality.

Put another way, if there is an objective methodology for evaluating the impact of MEV and a subjective framework for deciding which MEV should be tolerated, how practical is it for a rollup’s Sequencer to enforce it.

Credible neutrality above all else?

By implementing a system that freely allows a Proposer to exclude certain transactions, we may open the door to further eroding the rights of users to transact.

As we delve into the ethical considerations of MEV and the potential justification for restricting certain forms of it, a broader moral dilemma emerges—one that revolves around the potential for these judgements to inadvertently foster censorship.

There is a legitimate fear that the freedom of users to transact can be eroded over time as certain transactions are seen as morally unjust by the operators of the system. It may start off with transactions that do directly harm the user, but eventually lead to the censorship of other forms of transactions simply because the technology now exists to enable it.

I strongly believe that a layer-1 blockchain like Ethereum must remain credibly neutral at all costs. Not only to protect the right to transact, but also protect all rollups that build on top of it. It is a pre-requisite to guarantee that Ethereum can be the root of trust and the platform for protecting user’ funds that are locked into an off-chain system.

On the other hand, there is a potential for Proposers in a rollup-like system to implement real-time transaction filtering and forego credible neutrality.

This avenue of research is likely to be pursued regardless of our opinions on the importance of credible neutrality. It is imperative for our community to proactively engage with it and understand the extent to which it can be practically implemented.

It is true that embracing the practicality of transaction filtering may inadvertently lead to a system that erodes the freedom of users to transact.

This is why our community must work in parallel on another research stream that focuses on ordering protocols that tie the hands of the proposer, preventing their ability to filter specific transactions, and ultimately protect the user’s right to transact.

Can’t be evil by default. In my view, the end-game is to build a rollup where the Proposer cannot be evil as opposed to simply promising that they won’t be evil.

Assuming the community decides to implement protocols that tie the hands of the proposer, then there is a legitimate fear that MEV must be embraced by default. I hold the view that this is not necessarily the case.

For example, the Time-boost proposal is an example that combines:

• First come first serve ordering,
• Ordering agreement by committee,
• Enable back-running via micro-auctions.

It allows a rollup to embrace back-running strategies, something that is generally considered morally just, while making it difficult to sandwich a user’s transaction without direct access to the user.

Without transaction filtering, the trade-off is that an ordering protocol may discourage entire categories of MEV strategies, but this may be necessary to help protect the freedom of users to transact.

Of course, on the flip side, perhaps a rollup should not try to prevent MEV opportunities at all and embrace MEV in its entirety. Allow the marketplace to reach some equilibrium around the profits generated by MEV by enabling an open-market of searchers to participate. Anything can happen!

There is no right answer on whether to prevent or embrace MEV.

Thankfully, rollups as a technology stack, offer us the freedom to experiment with all of the above, and find the solution that best protects the interest of all parties involved including the transacting user, agents in DeFi protocols, and the participants in the underlying protocol.

Disclaimer：

1. This article is reprinted from [Cryptocurrency and Friends]. All copyrights belong to the original author [PATRICK MCCORRY]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.