skip to content

Exploring MEV on EigenLayer

Exploring MEV on EigenLayer

EigenLayer node operators have the potential to one day dominate the Ethereum validator set and become powerful block proposers of not only Ethereum, but also programs built on top of Ethereum. Without effective mitigation, these nodes will benefit from exclusive order flow, cross-domain MEV, and foster multiblock MEV, entrenching EigenLayer nodes and middleware on Ethereum. 

Introduction 

Maximal or miner extractible value (MEV) is the value extracted from transactions by privileged parties like miners and validators. Historically, MEV has existed in contained environments like Ethereum. With the advent and expansion of new transacting venues such as layer 2s like Arbitrum and Optimism, and layer 1s like Solana and Polygon*, MEV has become a cross-domain phenomenon where more privileged parties can extract extra value from working across venues. This cross-domain MEV pushes permissionless systems towards centralization, opening them to capture and weakening credible neutrality.  

Restaking is the technique of repurposing cryptoeconomic security — e.g., slashable staked assets — to secure new applications, allowing the same assets to participate in multiple different instances of Proof-of-Stake consensus at once. EigenLayer, which is yet to launch, is bringing restaking to Ethereum. EigenLayer will use staked ETH to power middleware. This includes apps like oracles, bridges, settlement layers, decentralized sequencers, and possibly even new execution environments. Because EigenLayer nodes are simultaneously Ethereum validators and power middleware which alters L1 state, EigenLayer nodes can manipulate MEV to their benefit, earning rewards inaccessible to others.  

EigenLayer nodes can harness their spot as sequencers on Ethereum and other apps that rely on EigenLayer for shared security to capture MEV. Without effective mitigation, these nodes will benefit from exclusive order flow, cross-domain MEV, and foster multiblock MEV, entrenching EigenLayer nodes on Ethereum. 

In this piece, we examine the basics of the cross-domain MEV problem, using research from Flashbots and other groups. We then examine instances of cross-domain MEV with EigenLayer applications, looking at oracles in depth before summarizing MEV opportunities with other middleware. We then consider mitigation mechanisms, including fallback applications, like Barnabe’s Protocol-Enforced Proposer Commitments and Flashbots’ Suave. Ultimately, we conclude that while mitigation mechanisms exist, most fall short today. 

TXN MEV Cross-Domain Mev

Cosmos Already Experiences Cross-Domain MEV 

First off, restaking already exists elsewhere in crypto, namely in Cosmos. The Cosmos ecosystem’s instances of cross-staking and restaking illustrate what impact EigenLayer may have on Ethereum:  

  • Cosmos MEV is despotic due to dPoS. In Cosmos, block building is not evenly dispersed among nodes, relying on the weight of delegated tokens for leader election. With this design, a few actors typically win the rights to sequencer transactions on Tendermint chains. Notably, this MEV can have high success as the operator has monopoly power on both chains when their proposer slots overlap. Sophisticated and well-capitalized parties that run validator infrastructure across multiple chains can access exclusive MEV opportunities. 

  • Mesh security leads to enhanced MEV extraction. Cosmos is also working on different forms of restaking, including one called mesh security. With mesh security, nodes and assets on one blockchain can participate in validation on another Tendermint network. This design results in a few nodes controlling even more of their respective networks as it lowers coordination costs, opening these networks to more cross-domain MEV extraction and creating a greater incentive for collusion. 

To date, the amount of MEV extracted on Cosmos has been diminishingly small compared to MEV extracted on Ethereum. However, it’s notable that the validator infrastructure for cross-domain MEV is already in place with limited market forces encouraging development.   

EigenLayer Encourages “T-Shaped” Integration 

On Ethereum, stronger market forces and novel technical designs like restaking on EigenLayer is likely to turbo-charge the availability and extraction of cross-domain MEV, while centralizing such capability to advantaged validators. Sophistication, availability of capital, proprietary information, and good infrastructure all contribute to being an advantaged validator. 

Collusion between proposers and EigenLayer nodes or between distinct EigenLayer nodes is costly as it requires trust, sharing MEV rewards, and other costs associated with coordination. Coordination costs are significantly reduced when collusion is internal -- when the proposer also is the EigenLayer node or also acts as a builder -- but some costs persist. 

Research from Flashbots and others suggests that there is an incentive to collude when the MEV from sequencing across two domains is greater than the MEV two separate entities earn sequencing on one domain each. In other words, collusion occurs when the coordination cost for capturing cross-domain MEV is lower than the revenue from capturing it. With EigenLayer, an Ethereum node sequences both Ethereum and EigenLayer blockspace, capturing exclusive MEV from arbitrage, liquidations, and more. 

Cross-Domain Collusion
Cross-Domain Collusion

This MEV won’t necessarily be open to every Ethereum node, as not all ETH stakers are sophisticated, have additional capital, are willing to subject ETH to additional slashing risks, or are connected to crypto’s major financial rails (e.g., having a higher tier Binance account) for successfully competing. This is why a smaller subset of specialized Ethereum validators could earn all the MEV from restaking. For more details on MEV sophisticated actors, read here. The space for cross-domain MEV on Ethereum goes beyond this initial example that explored a simple oracle run with restaking. Restaking encourages a new type of integration within the 3-role proposer-builder market due to nodes earning self-referential MEV.

MEV Supply Chain

MEV Supply Chain
MEV Supply Chain

Swap out Chainlink for restaked nodes and EigenLayer can generate  and encourage proposers (who can just be themselves) to collude to get unique MEV. 

Self-referential MEV involves a node or party sequencing transactions also controlling or influencing state elsewhere, prior to that state touching Ethereum state. This self-referential MEV is fundamentally exclusive, meaning other parties need to collude with or join to capture it. 

This MEV then fosters T-shaped integration, a MEV market structure where both horizontal and vertical collusion occur simultaneously. Vertical collusion is when actors in the MEV Supply Chain pass exclusive order flow to lower-level actors on the Supply Chain. Special features, inclusion guarantees, or MEV sharing incentives vertical integration between parties. Horizontal collusion is when validators outsource their block production to a subset of other validators. Essentially, a subset of the validator set sequences transactions for all validators. Again, this occurs because of the economic benefits or feature additions this subset of nodes provides. Taken together, this creates T-shaped integration, a MEV market where a smaller cohort of actors dictate most order flow. 

T-Shape Integration (Lukas Kmoth)
T-Shape Integration (Lukas Kmoth)

T-shaped integration is bad for decentralization because it exasperates problems from exclusive order flow (while the builder and searcher market is competitive, T-shaped integration will make it less competitive as builders and searchers can dominate with a proposer cartel) and can lead to other, worse types of MEV like “lazy” or multiblock MEV. Exclusive order flow, where transactors or actors like builders or searchers don’t broadcast transactions to the entire mempool, limits the network’s robustness against capture, hampering credible neutrality. 

Multiblock MEV is MEV where a node acts as a proposer for concurrent blocks on Ethereum. This is more profitable than proposing the same number of blocks separately or non-concurrently. Proposers increase profit from arbitrage and sandwich attacks by excluding transactions from the first block, meaning when swaps are finally executed the prices have been static for longer. This lets the proposer extract more MEV, hurting users. It also lets nodes manipulate oracles and harness more of their MEV. Multiblock MEV isn’t prevalent today but could be fostered by restaking. For more on multiblock MEV, see Alex Nezlobin from the London School of Economics coverage here.  

MEV Case Studies 

Oracle Updates  

This type of MEV is often called “spike” MEV due to its irregular occurrence that comes with large, asymmetric profit opportunities. Oracles have a history of cheating to win liquidations on their own protocols and it makes sense - tinkering with price updates can be profitable and is fairly riskless. If designed incorrectly, EigenLayer nodes could now capture MEV from Ethereum. 

Liquidations from oracle updates yield chunky MEV opportunities to EigenLayer nodes. Source: Flashbots.
Liquidations from oracle updates yield chunky MEV opportunities to EigenLayer nodes. Source: Flashbots.

An oracle run with EigenLayer — of which we believe there is at least one in development — could extract MEV by 1) colluding with the current block proposer / builder to land the transaction in a particular position and/or 2) by withholding price updates for a few blocks.  

MEV actors can game oracle updates in a number of ways:

Proper sequencing rights auctioned to Builder
  • EigenLayer node is Ethereum proposer: If an EigenLayer node responsible for updating the oracle is also the current proposer on Ethereum, they can build the block locally and earn the MEV associated with the oracle update. 

  • Other Ethereum node is proposer: If an EigenLayer node is not the current proposer, they can withhold the update until a node willing to collude is selected as proposer (reverts to A). In this situation, the EigenLayer node would split profits with colluding proposers. The proposers willingness to collude plus the length of time the oracle update can be withheld would correlate positively with the MEV the oracle update would generate. 

  • No node will collude: If no node willing to collude is selected as proposer within a given time span, the oracle update still earns EigenLayer nodes rewards as they will be paid for inclusion by searchers, increasing their yield over basic Ethereum nodes. This sort of revenue from state transitions EigenLayer controls likely encourages exclusive order flow.   

No matter the implementation, EigenLayer moves to the front of the MEV Supply Chain, giving them some power over transactions with MEV potential. However, cross-domain MEV doesn’t just come from oracles - possibilities for extraction, collusion, and centralization from restaking are much larger than just MEV related to price updates.    

Bridges & Other VMs 

Arbitrage makes up the vast majority of MEV profits today. Cross-domain arbitrage would give EigenLayer nodes an advantage over vanilla nodes. This could be via a bridge, a DEX built on top of EigenLayer nodes (an orderbook-based DEX comes to mind as a highly desirable design), or an entire other blockchain built on nodes (e.g., Solana on EigenLayer). Albeit, building any of these would require altering an Ethereum client substantially, but it’s entirely possible long-term given the incentives. 

2-domain arbitrage on Ethereum and Polygon* possible with EigenLayer. Source: Flashbots/Westerngate
2-domain arbitrage on Ethereum and Polygon* possible with EigenLayer. Source: Flashbots/Westerngate

Drawing from Unity is Strength, sophisticated nodes with capital on both ends and solid infrastructure will win most of the MEV from cross-domain arbitrage. EigenLayer nodes will be particularly advantaged for the simple reason that sometimes they will dictate the sequencing and inclusion of transactions on both domains. Notably, the higher the revenue from running EigenLayer, the greater adoption EigenLayer will have, increasing the frequency with which EigenLayer nodes act as both MEV transaction generators and Ethereum proposers. 

Sequencing 

Decentralizing the nodes or sequencers responsible for ordering L2s is a work in progress, but one idea is to use restaked EigenLayer nodes to sequence transactions on L2s. This sequencer would naturally have exclusive information on L2 state prior to its confirmation, and can collude with the Ethereum node selected to propose the current block to earn greater MEV. This extraction would be more profitable if the Ethereum proposer and the EigenLayer node sequencing the L2 were the same entity. In other words, EigenLayer sequencing encourages centralization.  

Relative to other sequencer designs, EigenLayer nodes acting as sequencers have much lower costs. Restaked sequencers have zero cost capital, can collude with a subset of proposers automatically (including themselves), and earn other types of self-referential MEV. This makes them more competitive economically than other sequencer designs and could lead to cartelization where most L2 sequencers are just a cohort of EigenLayer nodes.  

Greater profit incentivizes collusion between EigenLayer nodes but also between L1 proposers and EigenLayer nodes. Cartelization may be minimized at certain levels of EigenLayer adoption, but high adoption introduces other risks induced by a majority of nodes restaking which could — in the extreme — poise systemic issues to base layer security. 

Other Forms of MEV Capture 

Lastly, if some version of EigenLayer PBS (MEV-Boost++) or some sort of MEV auction uses EigenLayer, nodes will further be segmented into those with exclusive opportunities and those without. EigenLayer could also provide better MEV capture mechanisms or guarantees as a service (e.g., flashloans to searchers or builders that lasts a whole block), enabling more MEV capture. 

Wading further into speculative attacks, it’s possible other service offerings from EigenLayer (data availability, settlement, etc) earn restaked nodes MEV. This could be from self-referential MEV like discussed above or more complex attacks like data withholding attacks. While work is being done to mitigate all sorts of MEV maneuvers and they won’t all necessarily occur, it’s likely that cross-domain MEV extraction is a wider problem space than the above examples indicated.   

Mitigation 

Having discussed EigenLayer as a centralizing force via asymmetric MEV opportunities, what factors mitigate this? 

Spreading Awareness  

Spreading awareness of MEV is the first step towards mitigating, capturing, and controlling externalities. To spread awareness, EigenLayer will run a dashboard showing restakers positions, limiting leveraged players middleware could be exposed to. This dashboard can help identify opportunistic nodes acting in different roles across domains. 

Unfortunately, obscuring if you run different nodes isn’t hard, so identifying these actors and their actions will be challenging. Regardless, spreading awareness and information is the first step towards illuminating EigenLayer and other forms of cross-domain MEV. The next one is to research and develop mechanisms and products capable of harnessing and mitigating MEV.  

Can SUAVE save us?  

Suave + Eigenlayer
Suave + Eigenlayer

If EigenLayer wants to use Flashbot’s SUAVE [Single Unified Auction for Value Extraction] or be a part of it, there is likely 1) a coordination issue between onboarding all the different middlewares once they are already live and, 2) an incentive issue of getting middleware and nodes to onboard to SUAVE. This would entail essentially giving up some of the MEV they would otherwise receive. 

Besides these BD problems, SUAVE doesn’t solve all the externalities created by EigenLayer. While it could help with something like arbitrage or front-running, it can’t limit nodes from harnessing more sophistic MEV strategies created from transactions like liquidations.  

Limiting EigenLayer  

At a certain scale, EigenLayer poses systemic risk to Ethereum security. If a middleware is resource-intensive generating high revenue, fewer EigenLayer nodes would naturally earn greater amounts of MEV over time. In turn, this could encourage cartelization as validators would outsource proposing blocks to EigenLayer nodes. It may be best for EigenLayer to limit staking to pure ETH, not restaked ETH, so savvy players have more hurdles to ordering for both EigenLayer apps and Ethereum. Limiting staking to ETH, instead of liquid staking tokens, only introduces friction by not letting nodes re-use capital - cross-domain capture is still possible, just at a higher capital cost, which may conversely de-democratize access to MEV. 

Another alternative would be forcing restaked nodes to give up construction of their block completely, but collusion likely limits the effectiveness of doing this. This also forces EigenLayer yields to compete with ETH yields and also weakens one of the biggest selling points for EigenLayer as a restaking protocol. 

Restaking

Re-visiting proposer commitments  

Barnabe Monnot from Ethereum’s Robust Incentives Group has proposed making the Ethereum protocol aware of EigenLayer node balances via protocol-enforced proposer commitments. This lets Ethereum check commitments that EigenLayer nodes enter into are fulfilled, regardless if the node checking also runs middleware. This would give middleware better assurances and more importantly, minimize the risk EigenLayer poses to Ethereum. 

Proposer commitments can minimize negative externalities from MEV and limit opportunistic nodes attempting to re-org EigenLayer space during the delay period in order to steal funds, making reorgs and theft from reorgs more challenging. Still, however, because slashing conditions are delayed, nodes can act maliciously and/or siphon MEV over the delay period.   

Dapp Design  

Until research and new methods or products are introduced, social norms can limit MEV’s effects today. But Ethereum needs neutrality backed by cryptographic and economically robust systems, not by social consensus. The key to this, ultimately, is applications designed with MEV in mind. 

The protocol grants proposers a monopoly on ordering and users initiate MEV opportunities, but current dapp designs ultimately generate most MEV. Better application designs have already been introduced (e.g., Uniswap V3 generates a lot less MEV than V2), but applications can go further. 

Ideas include internalizing MEV to the protocol (Maker’s dutch auction does this, pushing keepers to compete on price instead of latency) and passing explicit MEV back to the user via something like a fee escalator. EigenLayer should build with MEV in mind.  

As far as internalizing MEV goes, there is an incentive for middleware to own its revenue or MEV with pooled security, requiring restakers to stake a governance token. This puts a bigger impetus on nodes for capital, centralizing EigenLayer’s nodes further, but also redirects some MEV revenue. EigenLayer will allow this, which is fine as experimentation is good after all, but it shouldn’t be a requirement for restaking as capital won't be kept idle in an open system for long. 

MEV Smoothing  

EigenLayer can smooth MEV between its entire node set, limiting the power of ones capable of running more intense apps and/or more sophisticated strategies. This would limit cartelization within the EigenLayer protocol. 

MEV smoothing can be important for transactions coming from middleware like oracles, where one node gets to influence Ethereum state. Reading prices is light-weight, meaning many nodes can participate. Smoothing MEV from the node selected to update price to all nodes would increase participation, making collusion with Ethereum proposers less likely.   

At higher participation rates the cartel is weakened, but importantly for intense, high resource middleware a few well equipped nodes would maintain control. To get specific, EigenLayer nodes could offer additional features like pre-confirmations, specific transaction placement in blocks and other features that basic nodes simply can’t offer. In turn, this would make these nodes more effective builders and searchers or better partners for searchers and builders. 

Future research likely needs to focus on this specific integration opportunity between power proposers and nodes not running EigenLayer. 

Thanks to Quintus, Tina, Josh, Calvin, Will, and others for insight and/or review.  

Also available to read on the EigenLayer and Flashbots forums.  

* Denotes Galaxy portfolio company