Approaches to MEV: Ethereum vs Cosmos

Below, we’ve included a summary table of MEV approaches taken by Ethereum and Cosmos. If you’d like to dive into all the gory details, we recommend reading the piece that follows.

* * * * * * *

Introduction

It’s well documented that the economics of MEV represent a risk to the decentralization of consensus networks. For Proof of Stake networks, MEV extraction has the potential to accelerate validator centralization due to economies of scale.

The largest staking pools can take on this task on behalf of their participants and generate far more MEV revenue than independent validators. This creates a strong incentive for independent validators to join the largest staking pools, which in turn reduces the decentralization of these networks. 

In addition, “harmful” MEV strategies can significantly degrade the UX of decentralized applications. Harmful MEV extraction occurs when actions are taken based upon knowledge of other users' transactions. This includes strategies such as frontrunning, sandwiching, and censorship of transactions. This “tax” imposed on users could serve as a barrier to large scale adoption of decentralized applications.   

In response, a number of teams have presented approaches that aim to mitigate the risks of MEV to network decentralization and its negative impact on users. This post will compare a few of the approaches being taken in the Ethereum and Cosmos ecosystems. 

‍Philosophical Differences to MEV on Ethereum and Cosmos

At the layer 1 level, Ethereum has taken a very neutral approach to MEV. Instead of implementing mechanisms at the protocol level, Ethereum has leaned on off-chain systems and experiments at the rollup level to mitigate the effects of MEV. 

On the other end of the spectrum, we’ve seen many Cosmos chains take an active and opinionated approach to MEV. Because every validator runs the code of both the chain and the application, they have a much larger design space to develop novel approaches to MEV that align to their use case and ideology. 

Below, we detail some of the approaches to MEV taken by Ethereum and Cosmos projects.

‍MEV Approaches on Ethereum

Proposer-Builder Separation

Ethereum is pursuing a solution known as proposer-builder separation (PBS) to address the risks of network centralization. In PBS, the block construction role (transaction ordering) is separated from the block proposal role (transaction inclusion). 

PBS introduces a separate class of actors called block builders who submit bids to block proposers with transaction ordering preferences. The proposer’s job is only to accept the bundle with the highest bid. Importantly, the proposer must not be able to see the contents of a bundle until after they select the winning bid. This is necessary to prevent the proposers from stealing the MEV from builders.

Benefits

• Reduces congestion and gas fees at the protocol level by removing MEV transactions from the public mempool.
• Lessens the risk of collusion between validators and block builders by reducing the amount of trust required between them. 
• Increases validator decentralization by making it easier for independent stakers to capture MEV opportunities.

Risks / Challenges

• Guarantees that users will always endure a high level of MEV extraction.  
• Requires an additional layer of trust in the entities that maintain the block building and auction software (unless it is baked into the protocol).

MEV Approaches on Ethereum Rollups

Rollups present an opportunity to experiment with MEV solutions without having to implement changes into the base layer. While some rollups are embracing MEV, others are trying to eliminate all forms of MEV. Below, we highlight both approaches. 

MEV Auctions

One approach is a modified version of PBS known as MEV Auctions (MEVA). In this model, block producers run an on-chain auction to select a sequencer for a predetermined period of time. The sequencer cannot exclude or censor transactions, but they are given complete control over transaction ordering over this period. The DAO that operates the rollup can capture the auction proceeds and redistribute it to stakeholders of the ecosystem. 

Benefits

• Creates an additional revenue stream for the protocol.

Risks / Challenges

• MEVA could increase the amount of MEV that exists which is ultimately paid for by Ethereum users.
• Poses potential complications when the ordering of transactions impacts whether certain transactions are included (e.g., liquidations).

Privacy Centric Rollups

While some rollups embrace MEV as core to their business model, others are aiming to eliminate harmful MEV entirely. Rollups that utilize encryption mechanisms such as ZK-SNARKs or threshold encryption can make sure transactions are private until finalized on Ethereum. The use of encryption technology adds complexity but is very effective in protecting users from harmful MEV. 

Benefits

• Enforces protection against harmful MEV (front-running, sandwiching, etc). 

Risks / Challenges 

• Decreases the amount of value that the protocol can capture from MEV generated on the rollup (unless combined with a top of block auction).
• The added complexity makes it difficult to decentralize the rollup’s sequencer role.

Examples of Approaches in Ethereum

Flashbots MEV-Boost

Ethereum’s long-term plan is to integrate PBS directly into the protocol. Until this is ready, organizations such as Flashbots are building interim solutions. Flashbots introduced MEV-Boost, an initial implementation of proposer-builder separation (PBS) for proof-of-stake Ethereum.

With MEV-Boost, any validator can connect to multiple relays which host competitive marketplaces of block builders. Using MEV-Boost, validators are guaranteed to receive the most profitable block possible and searchers are guaranteed to have their transactions included. 

Optimism MEVA

Optimism plans to implement MEVA and distribute the revenue from sequencer auctions back to the ecosystem through retroactive public goods funding. The thesis is that funding public goods and compensating developers will have a bigger impact on user experience than if they were to return this revenue directly to users or token holders. 

Shutter Network

Shutter Network offers threshold encryption services to protect users against harmful MEV. While originally designed for users and apps on Ethereum, Shutter has extended this capability to integrate directly with the sequencer of a rollup.

With Shutter’s threshold encryption services integrated at the sequencer level, all applications that deploy on the rollup can offer their users protection from harmful MEV. 

MEV Approaches in Cosmos

The Cosmos ecosystem is rooted in the thesis that the future will be dominated by application specific blockchains. By optimizing the stack for a specific use case, applications can achieve better UX, performance, and value capture than counterparts built on monolithic chains.

In line with this philosophy, Cosmos blockchains are pursuing a range of MEV solutions, each of which is tailored to the use case of its blockchain.    

Protocol-Owned MEV Mechanisms

By owning the whole stack, the protocol can enforce custom transaction ordering and self-executing code that is run by all the validators. This opens up the possibility for a protocol to capture the MEV that’s generated by its application.   

In this model, all validators will run the same code that calculates MEV opportunities (arbitrage, liquidation, etc) from user transactions at the end of each block. The block proposer generates the arbitrage transactions and places them after the standard user transactions. After the block is executed, the revenue generated is sent to an account that is managed by the protocol.  

Benefits

• Allows the protocol to capture MEV generated on its application. 
• Allows the protocol to distribute revenue to as the community sees fit. 
• Fully on-chain and open-source methods of capture.

Risks / Challenges

• Similar to threshold encryption, the biggest risk is a drag on performance. 
• This approach is only effective when the majority of MEV available is bounded within a single application. 
• Does not support cross-venue MEV such as CEX to DEX arbitrage. 

Threshold Encryption

Threshold encryption aims to create private mempools. After a block of encrypted transactions is finalized, the validators decrypt each transaction in a block to see its values. Assuming the block is valid, the transactions are then executed.

Benefits

• Because the mempool is private, harmful MEV extraction should be impossible. 

Risks / Challenges

• Threshold encryption significantly increases the amount of messages that validators must send to each other in order to decrypt the block. This bandwidth overhead increases complexity and can lead to longer blocktimes.
• Becomes challenging in situations when the ordering of transactions impacts whether certain transactions are included (e.g., liquidations).

PBS and On-Chain Blockspace Auctions

For chains that host a diversity of applications, an approach that uses PBS and blockspace auctions is likely to capture a higher percentage of available MEV. While it introduces technical challenges, conducting the auction on-chain provides significant benefits to the protocol.

Benefits

• On-chain auctions can enforce rules that protect against harmful MEV. 
• The proceeds from blockspace auctions are captured and distributed transparently as determined through governance.

Risks / Challenges

• The chain would likely require encryption for all transactions in order to ensure that on-chain bids are private. 

PBS and Off-Chain Blockspace Auctions

Similar to Flashbots, many Cosmos chains use off-chain auctions where searchers can privately submit transactions to an off-chain, sealed bid auction. 

Benefits

• This guaranteed revenue decreases the incentives for validators to collude with searchers to maximize their profits. 
• Does not require privacy mechanisms such as threshold encryption. 

Risks / Challenges

• No way to enforce rules around the distribution of revenue. 
• No way to enforce rules that mitigate the extraction of harmful MEV. 

Frequent Batch Auctioning (FBA)

FBA allows protocols to batch transactions that do not impact the state of other transactions. For example, an application specific DEX chain can batch all trading orders within the same market and execute them at a uniform clearing price.

Since all transactions are executed at the same price, it's impossible to capture MEV based on the order of the transactions. We’ve also seen a version of this approach implemented at the application level on Ethereum, such as the CowSwap Batch Auctions.   

Benefits

• Provides significant benefits to chain performance as well as reducing the surface of potentially harmful MEV extraction.

Risks / Challenges

• Validators still have the ability to exclude profitable transactions from a block and include their own transactions instead. 
• MEV through transaction ordering is still possible for any transaction types that cannot be batched together.

Examples of Approaches in Cosmos

Osmosis 

As an application specific AMM blockchain, Osmosis can be very opinionated in its approach to MEV and has the flexibility to implement potential solutions. Osmosis’s position towards MEV can be summarized as follows: 

• Any harmful MEV extraction should be mitigated at all costs. 
• The protocol should capture benign MEV that it generates.

Osmosis can distinguish “harmful” MEV from “benign” MEV and mitigate the former. In contrast to harmful MEV, benign MEV is extraction based solely on the existing state or public information. This includes backrunning arbitrage and liquidations which improve the overall health of the protocol. 

Osmosis is implementing a number of systems that aim to 1) eliminate harmful MEV extraction entirely, and 2) use on-chain protocol controlled mechanisms that allow the protocol to capture the value of benign MEV extraction. These systems include: 

• Protocol-Owned Arb Bot (ProtoRev Module)
• Threshold Encryption
• On-chain Priority Blockspace Auction

In partnership with Skip Protocol, the Osmosis community recently approved a proposal to build a protocol-owned arbitrage module. The ProtoRev module will calculate arbitrage transactions and place them at the end of the block to “backrun” the standard user AMM transactions.

This module will provide a novel form of protocol revenue as well as improving the health of the protocol by rebalancing the liquidity pools. 

Later next year, Osmosis plans to implement threshold encryption. Because the mempool will be private, the ProtoRev module will be modified to place its arbitrage transactions at the top of the next block to back-run any opportunities generated in the previous block. 

As Osmosis adds additional protocols and features, they plan to supplement the ProtoRev module with an on-chain blockspace auction. This marketplace should allow Osmosis to capture auction revenue for any MEV opportunities that aren’t picked up by the ProtoRev module. 

Duality

Duality is another AMM appchain that will be launching over the coming months. They plan to utilize a highly customized version of Skip Protocol’s off-chain auction to allow searchers to capture MEV opportunities that are generated by its AMM. 

Duality will have this capability from inception, but does not plan to launch a token immediately. Instead of paying for liquidity with inflationary token incentives, Duality will capture MEV auction proceeds and redistribute the revenue to the LP’s. By avoiding inflationary token incentive models and its associated impact on price, they hope to create an economic model that is more sustainable in the long-term.    

Sei Network

Sei is an upcoming Cosmos project that has built order book infrastructure directly into the chain. Unlike Osmosis, Sei will not have a “canonical” application associated with the protocol. Instead, Sei aims to host an ecosystem of DeFi applications that leverage its order book infrastructure.   

Sei’s approach will leverage two primary systems – Frequent Batch Auctioning (FBA) and an off-chain blockspace auction. Their FBA system will calculate a uniform clearing price for each market and execute all orders at that price.

While FBA will mitigate MEV in order book transactions, Sei will utilize an off-chain PBS system to address non-order book related MEV opportunities such as AMM transactions, liquidations, and cross-venue arbitrage. This approach makes sense given that Sei is optimizing for performance and aims to host a diverse range of applications on its platform.  

FairBlock

Another Cosmos project, FairBlock, is building a threshold encryption as-a-service solution which aims to address the bandwidth challenge. Unlike traditional threshold encryption, validators in FairBlock send shares for each block rather than for each transaction. By raising the decryption process to the block level, FairBlock believes it can reduce the bandwidth requirement of threshold encryption by ~99%.

MEV Approach Recommendations  

In a perfect world, every chain would have an MEV solution that satisfies the below requirements: 

1. Mitigates the risk of validator centralization. 
2. Protects users against harmful MEV extraction. 
3. Allows the protocol to capture revenue from benign MEV. 
4. Allows the value captured to be distributed transparently to the stakeholders of the network.

In reality, such a solution isn't technically possible and may not even be desirable in some ecosystems.

The optimal solution for any platform depends on its architecture and use case. For simplicity, we’ll categorize the recommendations by general purpose smart contact platforms and application specific chains.          

General Purpose Smart Contract Platforms

Off-chain PBS systems are currently the most effective solution for permissionless, general purpose smart contract platforms. The diversity of activity at the application layer results in a great deal of MEV opportunities.

Furthermore, it’s very difficult to enforce any rules that mitigate “harmful” MEV because the chain is not built to  “understand” the application layer. Given the amount of MEV available and limitations in architecture, it makes sense to delegate MEV capture to a network of searchers.  

While a trustless, in-protocol PBS system would be optimal, this approach presents technical challenges around privacy. Without a mechanism that encrypts the contents of the winning bids, the MEV would likely be stolen or replaced with the block proposer’s own transactions.

Until this is developed, these platforms should focus on cultivating a competitive market of relay providers that host off-chain sealed-bid auctions. 

Application Specific Chains

On-chain MEV systems can be a far better approach for application specific chains. Because every validator runs the code of the chain as well as the application, the protocol can enforce systems that are completely transparent to all network stakeholders. The amount of MEV available is also relatively bounded to the complexity of a single application.

These qualities allow app chains to implement solutions that not only mitigate validator centralization risk, but can also improve the user experience and economic sustainability of the protocol. Application specific chains should lean into this competitive advantage and design an approach that achieves as many of these objectives as possible. 

Conclusion  

Any application that is weighing the trade-offs between ecosystems should think carefully about how MEV could affect their product, both positively or negatively.     

While Ethereum’s generalized infrastructure can support any kind of application, it also limits the design space for potential MEV solutions. PBS can address the risks of network centralization, but it cannot effectively enforce systems that distinguish harmful from benign MEV. The onus falls upon the applications and rollups to design solutions that protect users and capture value directly from the MEV that they generate.   

By owning the whole stack, Cosmos chains can be custom designed for their application’s use case. In the same sense, Cosmos chains have maximum flexibility to be opinionated in their approach to MEV. If they choose to do so, they can implement systems that effectively satisfy all four requirements of the “perfect world” MEV solution.     

We love geeking out on MEV with teams. If you're thinking about which MEV approach to take and need a design partner, reach out to us!

Shout-out to Maghnus Mareneck, Barry Plunkett, Felix Lutsch, Michael Moser, Hasu, Yang Wong, and Max Holloway for reviewing earlier versions of this post.