Ethereum Staking Deep Dive: Analysing Execution Layer Rewards & MEV

Execution layer rewards make up 20% of a staker’s total rewards on average

Priority fees represent 17% of the total staking rewards on average, while payments for MEV transactions make up just 3% of a staker’s final payment. This is because execution layer rewards are only available when picked to propose a block, which a validator can expect around 3.23 times per year, and the skewed distribution of MEV opportunities.

These rewards are highly skewed

Despite their low average, execution layer rewards can be incredibly large. They boast a 99.99th percentile of 28.873 ETH, vs an average execution layer reward of just 0.112 ETH per block. While network activity contributes to their high variance, the extreme skew of MEV payments means that execution layer rewards can occasionally far outweigh the rewards that a staker earns on the consensus layer.

The MEV component exhibits clustering, and is driven in part by price volatility

While mean MEV rewards are 0.038 ETH per block, 52% of blocks since the Merge contained 0MEV fees. We see significant clustering in MEV, with the level of MEV in the previous epoch being a strong predictor of MEV in the subsequent epoch. This is explained by the strong relationship between MEV payments and volatility, and the cascading effect of MEV leading to further price volatility and MEV opportunities.

Stakers receive 20% of their total average rewards from Ethereum’s Execution Layer.

Ethereum staking offers many types of rewards of varying sizes and predictability. Consensus layer rewards are composed of attestation rewards, which are predictable and available to every validator once per epoch, and of proposer and sync committee rewards, which are available to a validator only when randomly selected.

In contrast, execution layer rewards are entirely dependent on random selection and are highly variable in their size. While accounting for only 20% of a staker’s average reward, they frequently result in incredibly high payments made to Proposers.

We provided a detailed coverage of consensus layer rewards in the first report of this three-part analysis of Ethereum staking. In this second issue, we will expand on this by evaluating the rewards available to stakers on Ethereum’s execution layer:

1. Describe how Proposers earn extra rewards from the execution layer on top of those that they earn from performing consensus layer duties.
2. Define MEV (or Maximal Extractable Value), illustrate a timeline of MEV rewards, and relate our methodology to assess its contribution to a staker’s income.
3. Analyse the drivers and properties of MEV rewards and their ultimate impact on the execution layer rewards collected by a Proposer.

In doing so, we aim to paint a complete, quantitative picture of the rewards available to every staker of 32 ETH on Ethereum’s Beacon Chain. By decomposing the full rate earned by stakers into its deterministic and stochastic components, we will better understand the drivers of some of the highest rewards earned by stakers so far.

The full rate breakdown

As we did for consensus layer rewards in the first report, we present each reward as an expected annualised percentage rate - the methodology for which is analogous to that in the first report and can be found in Appendix A.

Consensus layer rewards have made up the majority of the expected rate earned by stakers since the Merge. While some consensus layer rewards are only available if a validator is randomly selected to propose, the size of their rewards when picked is relatively consistent.

Therefore when scaling the potential reward by the expected number of blocks proposed in a year we see a very stable expected annual rate that falls as the number of validators on the network increases. A larger population of validators on the network reduces the size of the rewards earned each epoch, as the size of those rewards is inversely proportional to the size of the total amount staked on the Beacon Chain.

Execution layer rewards (MEV and Priority Fees) are also only collectable when randomly selected to propose. However, the size of the rewards is also highly variable. This leads to the highly variable expected annualised rate earned by a Proposer since the Merge. It is this highly variable rate that we will explore in detail in the sections that follow.

Empirically, we recorded the following statistics of the rewards earned since the Merge.

* Consensus layer rewards were discussed in the first edition of this report. Their high standard deviation can be explained by the infrequent chance to perform sync committee duties, which offer comparatively large rewards.

** Distribution statistics were recorded over the full historical dataset, applying the laws of total expectation and variance in order to handle the random probability of being randomly selected to collect certain reward types.

These statistics are calculated from the full distribution of rewards earned since theMerge in September 2023, taking into account the number of active validators in each epoch. Subsequently, we will quote the expected annualised rate based on the latest observation of the number of active validators on the network that is in our dataset.

The expected annualised rate based on the latest observation is lower than the average over the historical period as there are now more validators on the network.The number of active validators impacts the rate that they can expect to receive in two ways. First, by reducing the size of consistent rewards which are dependent on the number of validators, and second, by reducing the probability that a validator is picked to propose a block. This precludes them from collecting including two consensus layer rewards as well as each of the execution layer rewards.

Priority Fee Rewards

What is contained in the block that a Proposer proposes?

Priority Fees*: 0.81%

* From an observed validator set size of 813,378, recorded at epoch 230,700 - 21:00 UTC 22nd Sept 2023

In addition to their consensus layer responsibilities, Proposers are asked to create an execution layer block and include it within their Beacon Chain block – this is sometimes called the payload.

The execution layer block is broadcast alongside the Proposer’s Beacon Chain block. The execution layer block contains user transactions and interactions with smart contracts that the Proposer (or Block Builder) has collected from users of the network.

This is how the Ethereum network separates information about chain consensus (held in Beacon Chain blocks) and about transactions and the network’s state (kept in execution layer blocks that live inside of Beacon Chain blocks).

How do Proposers get paid for including transactions in their blocks?

Ethereum users must pay to have their transactions included onchain, as is the case on many decentralised blockchains. The fee that a user must pay depends on three variables:

• Computational requirement of their transaction
• ETH cost per unit of computation (the units are measured in gas)
• Network demand for blockspace

While the switch to Proof-of-Stake means that Proposers do not expend any energy in mining blocks, they must still compute the operations that are submitted as transactions by users (simple ETH transfers and smart contract interactions). The computational effort required by a transaction is set out by Ethereum’s yellow paper, which assigns fixed numbers of gas units to a list of standard computational operations. The fee charged to users to have their transaction included onchain, paid per unit of gas that a transaction requires, is split into two parts:

Base Fee - the same for every transaction within the block

‍Priority Fee - optional and chosen by the sender

The Base Fee depends on the total gas used in the previous block in order to discourage users from overloading the network. The higher the gas usage in the previous block, the higher the Base Fee for each transaction in the current block. This fee is burnt – the ETH is removed from circulation and is not paid to the Proposer.

The Priority Fee is chosen by the sender of the transaction. Any per gas fee paid above the Base Fee is collected by the Proposer. A Proposer is encouraged to include transactions with high Priority Fees for which users have outbid other users to have their transactions included earlier.

MEV Rewards

MEV in a post-Merge Ethereum

MEV Fees*: 0.38%

* From an observed validator set size of 813,378, recorded at epoch 230,700 - 21:00 UTC 22nd Sept 2023.

MEV refers to the profit that can be extracted by including specific transactions inside of a block before other transactions. Before the Merge, when Ethereum used a Proof-of-Work (PoW) consensus mechanism, MEV (then called Miner Extractable Value) referred to the extra profit that miners could generate by using their privileged position to determine the order in which transactions were executed.

A new paradigm has emerged in the post-Merge, Proof-of-Stake (PoS) Ethereum ecosystem. In addition to building their own blocks, Proposers are now able to listen for blocks assembled by other Ethereum users (called Block Builders), who are able to bid large payments to Proposers to have their block included onchain and collect the transaction fees in the block themselves. Those blocks can contain transactions with incredibly high fees that are ultimately collected by the Proposer, especially MEV transactions which result in a large profit to the sender.

The value of an MEV transaction is different to each user that is involved in the process that results in a transaction being included onchain. Therefore we will first clarify our definition of MEV, which will be motivated by our goal of measuring the proportion of a staker’s reward that we can attribute to MEV activity.

How we will define MEV

There are several definitions of MEV, each roughly corresponding to a different measurement method. As we are interested in the rewards earned by an Ethereum validator who is chosen to propose a block, our definition will be motivated by measuring the effect of MEV transactions on the APR of a Proposer.

To that end, we will define an MEV transaction as a transaction or group of transactions (bundle) for which a user is willing to pay gas fees subject to its inclusion in a specific area in the block (specifically before other transactions). An MEV transaction is then any set of transactions whose value to the sender is dependent on their position within the block. The value of such a set of transactions is the gas fee paid to have the transactions included in a specific position in the block.

Defining MEV in this way has the advantage of being agnostic to the revenue it generates for the sender (which is unobservable in our data, although is tracked by others by looking closer at transaction data). It also keeps the definition close to that which we will ultimately measure - the APR earned by a Proposer due to the presence of MEV transactions within their block.

Methodology for calculating Proposer rewards earned from MEV

We identify the value of MEV within a block by considering the sum of internal transactions paid to the builder of the block and assuming that these correspond to MEV transactions. For blocks built with MEV-boost, we assume that the final payment to the Proposer is made up of the same proportion of regular and MEV transaction fees as the revenue collected by the Block Builder cases. There, we assume that the Block Builder has collected revenue by including their own MEV transaction within their block.

Finally, we quote expected APRs based on an assumed balance of 32 ETH and by considering the number of blocks a validator is expected to propose in a year. A full description of this methodology can be found in Appendix A.

Note that this methodology:

• Does capture cases where the MEV payments are made to Proposers in atomic transactions using Flashbot’s coinbase.transfer() function. This includes arbitrages and liquidations.
• Fails to include cases where value is captured outside of the Ethereum chain, such as an arbitrage between a centralised exchange and an onchain, decentralised exchange.
• Fails to identify sandwich attacks as MEV transaction reward type - these show up as regular transactions and so their fees will be classified as regular priority fees, not MEV activity.

The biggest MEV spikes since the Merge

While there are many types of MEV opportunities for which a user might want their transaction to be positioned in a certain spot in the block, the most popular and profitable types fall into three main categories: liquidations, arbitrages, and sandwich attacks. Note that while our methodology does not systematically identify payments from sandwich attacks, we are able to identify individual sandwich attack transactions using block explorers.

Each strategy takes advantage of the implementation of a financial application on the blockchain – interacting with either decentralised trading exchanges or onchain lending markets to exploit small, fast changes in the price of tokens or digital assets. In addition, our definition extends to smart contract exploits or hacks. If an exploiter needs to send their exploit transaction before a protocol developer can patch the issue, then they will be willing to pay very large priority fees to Proposers in order to be first onchain – although it is unlikely that these will be sent via internal transactions.

To illustrate the history of MEV since the Merge, we will examine a high-profile example of each of the cases set out above while discussing some of the events that caused these opportunities to arise.

MEV example 1 - sandwich attacks

Some Decentralised EXchanges (DEXs) adjust their prices algorithmically when they are traded against, via a process called Automated Market Making (AMM). When a user buys token A from the exchange by paying with token B, the exchange’s AMM will increase the price of token A relative to token B for the next user without needing a user input to explicitly set the new price.

Large trades (relative to the number of tokens in the DEX’s Liquidity Pool) will move the price more. This is akin to moving through the liquidity levels in a centralised orderbook and incurring price slippage. MEV Searchers will often take advantage of the resulting foreknowledge of the price movement by including a transaction before and after a target user’s trade, “sandwiching” the user's transaction and resulting in a worse execution price for the original trade:

1. Attacker buys the same asset from the DEX as the target transaction first, causing the price quoted by the DEX to increase.
2. Target transaction buys the asset from the DEX at the new higher price, driving its price up even further.
3. Attacker sells the asset back to the DEX at a higher price than they paid in transaction #1 for profit.

Sandwich attacks take advantage of the information asymmetry intrinsic to a public mempool: a trade with a DEX is shown publicly before the transaction has been executed. If they include their transactions immediately before and after the target transaction (which they can do by specifying a high enough transaction fee), they can guarantee a risk-free profit at the target user’s expense.

Target transactions with larger price impacts make sandwich attacks more profitable. This is because the target transaction creates more substantial price shifts, allowing the sandwich attacker to guarantee a larger profit when reselling the asset back to the DEX. Even regular-sized trades can have a large impact when the liquidity held on the DEX is small, such as soon after a token is newly listed for trading by the exchange.

In May, a meme coin called PEPE was listed on Uniswap for trading against wrapped ETH (a token whose value is pegged to the value of ETH). Soon after, a single large transaction (at 11:22 UTC in the figure below) bought and removed 147B PEPE tokens (with a market price of over $300K at $0.000002097 per token) from Uniswap’s trading pool. At the time, this was around 16% of the pool’s 894B tokens.

As a result, the post-trade price of PEPE against WETH (wrapped ETH) quoted by the DEX increased dramatically. This transaction was sandwiched, resulting in a large MEV fee that was ultimately paid to the Proposer to have the block included onchain.

The large increase in price also saw a rush of trading activity, as is common with memecoin trading. This led to higher payments to Proposers for both regular and MEV transactions for many of the blocks that followed. Note that the priority fees paid for sandwich attacks do not show up as internal transactions, which means that our MEV classification methodology does not systematically identify their fees as MEV fees.

MEV example 2 - arbitrage

Ethereum users can exploit the prices quoted by different exchanges for the same trading pair with an arbitrage, either between two onchain DEXs or between an onchain exchange and a centralised exchange. The mechanics of the strategy work exactly as they do in a traditional arbitrage:

1. Buy the asset on the exchange with the lower price.
2. Sell the asset on the exchange with the higher price.

Provided that the prices do not move between transactions #1 and #2, the trader will have locked in a risk-free profit. These transactions must be executed sequentially (or atomically, in DeFi parlance). Otherwise, the relative pricing on the target exchanges may change, exposing the trader to exchange rate risk.

The USD Coin (USDC - stablecoin pegged to the US Dollar via promises of redemption at par by its issuer Circle) de-peg in March of this year was a profitable event for onchain arbitrages. USDC, a stablecoin, fell sharply from $1 to as low as $0.90 per token. This meant that the prices quoted onchain by DEXs quickly became stale relative to prices on off-chain, centralised exchanges – as well as other onchain DEXs that had their automated price updated faster.

Noticing this, traders began to buy USDC tokens on other markets (including centralised exchanges and other onchain DEXs) at prices lower than $1. Then, they sold the USDC tokens to the DEX pool at the higher, out-of-date price of $1 per token. We see strong evidence of this in the balances of Tether (USDT) and USDC in one such pool – the supply of USDC held by the DEX increased soon after the de-peg occurred as traders bought its USDT tokens with their USDC tokens.

Traders selling USDC for USDT automatically adjusted the price of USDC lower relative to USDT, bringing the price in line with off-chain exchanges. When the price of USDC subsequently recovered its peg to the dollar, the process repeated in reverse: USDT was sold to the pool in return for USDC, leading to the recovery of the peg on the DEX.

Arbitrage behaviour is incredibly profitable to Proposers as traders each rush to be the first to exploit the difference in prices between exchanges. To be first, they are willing to pay a transaction fee up to the total revenue they stand to earn if successful. During this event, nearly 700 ETH was paid to Proposers per hour at the height of the craze. Those high transaction fees were paid for by a mixture of arbitrage transactions, sandwich attacks on those arbitrage transactions, and regular priority fees as a result of the high congestion on the network.

MEV example 3 - liquidations

The most popular onchain lending protocols allow lenders to deposit assets into a pool of tokens that borrowers can interact with pseudonymously. As with the trade price set by DEXs, the rate that borrowers pay to borrow from the pool is set algorithmically without taking into account the credit worthiness or identity of the borrower.

As a result, these protocols require borrowers to over-collateralise loan positions with other assets. The more volatile the asset that they pledge as collateral (relative to the asset that they are borrowing) the larger the factor by which they must over-collateralise their loan.

If the value of the asset that they have posted as collateral falls, then the borrower is required to post more collateral to maintain their collateralisation ratio above a pre-agreed level. If they fail to maintain that ratio, any other Ethereum user can repay part of their loan for them, liquidating part of the borrowed amount in return for a financial reward. This is called a liquidation and is a common source of MEV fees collected by Proposers.

Liquidations are common when the value of an asset that many users have used to collateralise borrow positions falls suddenly, catching borrowers out and causing them to be liquidated by automated MEV Searchers before they are able to re-collateralise their position. That is exactly what happened in November last year, when the collapse of centralised exchange FTX sent crypto-asset prices spiralling.

The fall in ETH price meant that liquidators were able to repay other borrowers’ loans for a profit. In turn, they were willing to pay to be the first user to have the privilege to liquidate a loan, meaning an increase in MEV profits ultimately collected by Proposers. This period saw a maximum of 40 ETH per block sent to Proposers, with that particular transaction being an arbitrage between decentralised exchanges.

Liquidations were most frequent during sharp downturns in price, with up to 5 per block (every 12 seconds) recorded on 9th November. We also see them cluster – with the same downturn in price causing many positions to fall underwater. This count of liquidations is limited to those positions collateralised by wrapped ETH tokens on Aave lending markets, but a concurrent drop in the prices of many other digital assets saw many more positions liquidated at the same time, causing the volatility to ripple through the digital asset market.

The Drivers of MEV

MEV is incredibly skewed

We have seen that the distribution of execution layer rewards (and MEV rewards in particular) is far more event-driven than consensus layer rewards. Priority fees are highest during extended periods of high demand for on-chain blockspace. The MEV strategies that we have discussed above, such as sandwich attacks, liquidations, and arbitrages, are most profitable during periods of high volatility in the spot prices of digital assets. Here, we will quantify some of MEV’s unique attributes and attempt to explain what drives its unusual behaviour.

* As defined by the methodology set out above that considers the fees paid to the Block Builder via internal transactions.

• Over half of the blocks that have we observed since The Merge did not contain any MEV.
• When MEV is present in blocks, it is usually small in value.
• However, we have occasionally seen incredibly large single transaction MEV opportunities.
• These infrequently huge rewards skew the distribution of MEV in blocks strongly to the right.
• Large MEV rewards result in some of the highest payments ultimately collected by proposers as users pay to have profitable transactions included in blocks.

The volatility-MEV feedback loop

‍Volatility leads to MEV. The design of many DeFi protocols mean that large and swift moves in spot prices can result in many MEV opportunities:

• Newly stale prices on DEXs cause arbitrage opportunities to emerge.
• Collateralised positions fall underwater, exposing them to liquidations.

As a result, we observe a strong relationship between large, stepwise moves in spot prices and the amount of MEV collected in the hours that follow.

Since the Merge, there have been only four hour-to-hour price moves of 6.8% or higher, resulting in over 6,000 ETH being forwarded to Proposers.

MEV leads to more MEV. Arbitrage opportunities between two DEXs update the price of an asset pair on both DEXs. This can create arbitrage opportunities between those DEXs and the same asset pair on a third DEX, or triangle arbitrage opportunities with a third asset. Arbitrage transactions are also vulnerable to sandwich attacks as they (necessarily) have a significant price impact on DEXs.

‍MEV leads to more volatility. After receiving a reward denominated in the collateralised asset after successfully liquidating another user’s borrow position, liquidators will often swap the distressed asset for another token. This adds further selling pressure to an asset that was already falling in price, exacerbating an already volatile move. If the asset is swapped on a DEX, there are further opportunities for sandwich attacks.

These mechanisms combine to create a feedback loop that begins with a large move in spot prices and cascades across DeFi protocols to cause more spot price volatility and further opportunities to collect MEV. As a result we see strong evidence of periods of large MEV payments near to large moves in price and periods of extended volatility.

We see a strong relationship between a rolling sum of the MEV collected over the last seven days and the 7-day estimate of realised volatility in ETH’s spot price. Therefore, Proposers have received a higher APR when they are picked to propose blocks during times of high volatility. While stakers may be able to forecast realised volatility around events or news in the future, they are not able to choose when they will be asked to propose a block.

Appendix A: Methodologies

An Annualised Percentage Rate (APR)

To compare each source of staking reward we will quote its Annualised Percentage Rate (APR). To do so, we begin with the ETH-denominated payment to a staker for each activity. We then calculate the return that this generates on an assumed balance of 32 ETH – the minimum required stake by an Ethereum staker to start a node. This figure is annualised by multiplying it by the number of periods that a validator can be expected to receive that reward per year.

Rewards earned on the execution layer are only available when a staker is randomly chosen to propose a block. Therefore we will display the distribution of rewards scaled by the expected number of opportunities to earn them in a year and quote the unconditional distribution’s mean and standard deviation by applying the laws of total expectation and variance respectively – this means that we can consider the random chance of being able to earn these rewards.

This contrasts with several of the consensus layer rewards discussed in the previous report which are consistently available once per epoch and whose size is dependent only on the validator’s performance. For these rewards, we multiply by 82,125 (the number of epochs in a year), which assumes no compounding on rewards.

This methodology produces the time series of staking rewards displayed on page 6. The time series shows the actual reward recorded in each block for each activity scaled by the expected number of times per year that a staker will be picked to perform that activity. That expected number of chances to receive a reward is dependent on the number of validators active at each slot, meaning that the scaling factor varies from epoch to epoch.

Our methodology for calculating Proposer rewards earned from MEV

For blocks built using Flashbot’s MEV-boost system, our dataset observes a single payment from the Block Builder to the Proposer that is included within the block they have built (usually the last transaction in the block). That payment is the entire execution layer reward that a Proposer earns when randomly picked to propose.

We aim to break the Proposer’s payment down further, attributing some portion of the payment they receive to MEV activity within the block and the rest to “regular” transaction fees. In doing so we hope to analyse them independently and examine their relationship. To do this, we will break down the profit that a Block Builder receives from the different types of transaction fees in the block.

Block Builders collect all the fees (the proportion that are not burnt) that are attached to the transactions within a block. Transactions sent by MEV Searchers will often pay the Block Builder to include their transaction within the block using a special type of transaction called an internal transaction. Doing so allows them to interact with multiple smart contracts and pay the Block Builder all at once.

Crucially, it also allows them to make the payment of the transaction fee to the Block Builder dependent on the transaction’s position within the block – meaning that it is only included in the block if it successfully generates a profit for the sender. This gives us a flag by which to classify MEV transactions. We will classify all other transactions as non-MEV transactions and the payments that are made for them as Priority Fees.

Most often, the payment from the Block Builder to the Proposer (to have the block they have built included onchain) is smaller than the revenue the Block Builder stands to earn from the transaction fees, allowing the Block Builder to earn a net profit. In this case, we will assume that the final payment received by the Proposer is attributed to MEV and non-MEV transaction fees in the same proportion as the Block Builder’s revenue.

In some observed blocks, the payment to the Proposer is larger than the revenue that a Block Builder stands to earn.

In such cases, we will assume that the Block Builder has an extra financial incentive for the block to end up onchain – either because they have included an MEV transaction of their own in the block or perhaps they stand to make an offchain profit (such as by arbitraging price differences between centralised and decentralised exchanges) - and that they are not producing the block at a loss. Note that this transaction would have no fee attached (apart from the Base Fee that is burnt) and so it would not be accounted for within the MEV Fees that we label from other accounts.

In this case, we are unable to observe the Block Builder’s full revenue and so cannot proportion the Proposer’s reward according to the proportions of the Block Builder’s revenue. Instead, we will assume that the Block Builder passes on the entirety of the MEV fees and “regular” Priority Fees to the Proposer, and that the remaining balance is paid for by the Block Builder’s own MEV opportunity.

While by some measures of MEV this does not capture the full MEV available onchain (by missing the full revenue collected by the Block Builder), it does provide a robust (if incomplete) measure of the proportion of a Proposer’s rewards attributable to MEV activity – our stated aim. This methodology processes blocks that were built with MEV-boost. For blocks built by the Proposer themselves, we can immediately attribute the sum of the internal transaction fees to the Proposer to MEV activity and all other Priority Fees to regular transactions without concerning ourselves with Block Builders (and applying the same caveats).

Appendix B: MEV and Flashbots

The MEV lifecycle

In the post-Merge, PoS Ethereum, the entities who can profit from ordering transactions are far more diverse. Instead of miners, there are three key types of users who are involved in generating MEV: Searchers, Block Builders, and Proposers.

MEV generation begins with Searchers. These are specialised users who scour the mempool to seek out potential MEV opportunities and create MEV transactions - examples of which we have discussed in detail above. When a Searcher finds a transaction to profit from, they will create a special type of Ethereum transaction and send it to a Block Builder.

Block Builders assemble Ethereum blocks by listening out for transactions in the mempool, as well as transactions sent to them by Searchers, checking that they are valid, and ordering them into a block. Searchers will pay a fraction of the revenue they stand to gain from their opportunity to gain a favourable position within a block which includes their MEV transactions into the block. This payment happens only if the blocks eventually end up on-chain. Block Builders compete against one another by submitting bids to the Proposer to have their blocks included on-chain.

Proposers are Ethereum stakers that have been randomly selected to propose a block. They are tasked with proposing a valid block to the network when called upon in their slot. While many Proposers build the blocks that they propose, over 90% of Ethereum blocks are built by third party Block Builders using Flashbot’s MEV-Boost. This is a third-party system that allows Proposers to create a market for space in their block by out-sourcing block construction. In return for building the block for the Proposer, the Block Builder is allowed to keep the priority fees from each of the transactions within the block.