On September 15, 2022, Ethereum changed its consensus algorithm, moving from Proof-of-Work (PoW) to Proof-of-Stake (PoS). This event is commonly known as “The Merge”. While this change has considerably reduced the overall energy consumption, it has been observed that 40% of the first 1,000 blocks since then have been validated by a very limited amount of cryptocurrency holders. This raises serious questions about the decentralized nature of the system. To address this concern, and to mitigate the potential negative externalities of current Maximal Extractable Value (MEV) extraction strategies, the community has agreed to implement a permissionless, transparent, and fair ecosystem for MEV extraction. In this paper, after describing the new ecosystem, we perform an analysis of the blocks validated after Ethereum's “The Merge”. In particular, we analyze the actual distribution of validators by accounting for their activity both inside and outside the MEV ecosystem, and discuss how the scenario has changed in recent months.
Ethereum is a decentralized, open-source blockchain with smart contract functionality [
PoW generates consensus and guarantees network security by combining computational
power with cryptography, in the form of block mining [
To solve these problems, PoS was introduced, which instead of performing tangible work,
relies on the existence of verifiable stake in the ecosystem. A user must basically prove to own
a particular amount of cryptocurrency tokens that are native to the blockchain. The probability
to create a block and receive the associated reward is proportional to the amount of the
tokens put in stake. The hypothesis behind the proper functioning of this mechanism is that
the users with the highest stakes in the system have the greatest interest in maintaining the
network secure, as they would sufer the most if the reputation and price of cryptocurrency
decreased due to attacks. Furthermore, if users act maliciously, they may lose their stake as a
result of their actions. One possible disadvantage of PoS concerns the fact that the network
may, in fact, be subject to the dominance of the most important token holders. This is due to
the so-called compounding of wealth phenomenon, by which the rich simply stake their wealth
and get richer with stake rewards [
So far, the scientific literature has investigated the behavior of the Ethereum blockchain
before “The Merge”, addressing several issues about mining power [
In light of these issues, since (to the best of our knowledge) no in-depth scientific analysis of the decentralization and economic efects of “The Merge” and the introduction of these new MEV-related players in the Ethereum ecosystem has been published in the literature, the purpose of this article is to analyze the current situation of the network and whether the proposed solutions are actually working to not favor the few at the expense of the many. In particular, the rest of the article is organized as follows: Section 2 describes in detail Ethereum and its PoS consensus mechanism; Section 3 describes current MEV on-chain and of-chain extraction strategies; Section 4 discusses the operation of Flashbots in the Ethereum ecosystem; Section 5 provides an analysis related to the actual distribution of validators in Ethereum; finally, Section 6 concludes the paper and provides some perspectives on future research directions.
Ethereum is an open-source, permissionless, decentralized blockchain platform that establishes
a peer-to-peer network that securely executes and verifies transactions. These are sent from
and received by user-created Ethereum accounts. A sender must sign transactions and spend
Ether (ETH), i.e., Ethereum’s native cryptocurrency, as a cost of processing transactions on the
network. Transactions may involve the execution of application code, called smart contracts.
Approximately every 12 seconds, a batch of new transactions, known as a block, is processed
by the network. Each block also contains a cryptographic hash identifying the series of blocks
that must precede it if the block is to be considered valid. This series of blocks, from the
genesis (first) block to the most recent one, is known as the blockchain. Transaction records
are immutable, verifiable, and securely distributed across the network, giving participants full
ownership and visibility into transaction data. Ethereum can be seen as a (very large) state
machine, where the state is given by Ether balances and other storage values of all Ethereum
accounts; transactions modify some of these values, thus altering the overall state of the machine.
In this context, the Ethereum Virtual Machine (EVM) is the runtime environment for transaction
execution. It includes a stack, memory, and persistent storage for all Ethereum accounts
(including contract code), and is designed to be deterministic, so that given a pre-transaction
state and a transaction, each network node produces the same post-transaction state, thereby
enabling network consensus. The Ethereum Yellow Paper formally defines the EVM [
Post-Merge Ethereum consists of an execution layer and a consensus layer, both running on diferent client software. The execution client is responsible for transaction-related actions, as detailed below, while the consensus client implements the Proof-of-Stake consensus algorithm. There are also two types of accounts on Ethereum, i.e., user accounts (also known as externallyowned accounts, EOAs), and contract accounts. Both types are identified on the blockchain and in the state by an account address; they have an Ether balance and may send Ether to any account, call any public function of a contract, or create a new contract. User accounts are the only type of account that may create transactions. For a transaction to be valid, it must be signed using the sending account’s private key, which is generated with the corresponding public key when creating the account. Figure 1 depicts the process of proposing and validating transactions (and blocks). When a transaction is submitted to an execution client, it verifies its legitimacy by ensuring that the balance of the sending account contains enough Ether to complete the transaction and that the digital signature is correct. If the transaction is legitimate, the execution client adds it to its local memory pool (Mempool), i.e., a list of pending transactions, and broadcasts it to the other nodes of the network. Upon hearing about the transaction, the other nodes also add it to their local Mempool.
In Ethereum’s implementation of Proof-of-Stake, time is divided into slots, each lasting 12
seconds. In each slot, a single validator is (pseudo-)randomly selected to be the block proposer
responsible for creating a new block and sending it out to other nodes on the network. In order
to participate in the selection of validators in the PoS Ethereum network, a user is required to
deposit 32 Ether, and run three separate pieces of software: the previously introduced execution
and consensus clients, and a validator client. Upon deposit, the user aiming to become a validator
is added to an activation queue, which limits the rate of new validators joining the network.
Additionally, a committee of validators is randomly chosen in each slot to vote on the validity of
the block being proposed [
In Ethereum, each transaction has a cost, which is determined by a base fee, set by the protocol, and a priority fee, set by the user to make the transaction more appealing for being included in a block. The base fee acts as a reserve price; its value is calculated independently of the current block and is instead determined by the blocks before it – making transaction fees more predictable for users. When the block is mined this base fee is “burned”, removing it from circulation. Further, validating the transaction consumes a number of gas units, whose value varies according to the market’s law. Overall, the total fee is obtained as units of gas used * (base fee + priority fee). Tweaking the value of the priority fee can be done by experienced users to arrange transactions in upcoming blocks for Maximal Extractable Value (MEV).
The term Maximal Extractable Value (MEV) is commonly used in the blockchain community to
indicate the goal of maximizing the extra value that can derive from including ad-hoc transactions
in a block, or from controlling the order of inclusion of the transactions thereby [
Importantly, blockchain allows for MEV opportunities to be pursued with technical flavors that are not there in the case of traditional finance. For instance, continuing with the example of arbitrage transactions, the blockchain trader can succeed to make the buying and selling transactions become part of the same block, thus making them appear as transactions that happened atomically at the very same time. In this way, they obtain the corresponding profit immediately as that block gets included in the blockchain, incurring no risks that prices may oscillate in between. In the blockchain community, the term MEV is used to refer by generalization to both the behavior of pursuing such type of speculative revenues and the resulting profit obtained by actuating behavior of this type. Furthermore, the word maximal is to be interpreted in a best-efort fashion. Thus it makes sense to refer to arbitrage actions as a type of MEV opportunity or quantify the MEV that resulted from actuating a given arbitrage action.
In the simplest instance of the phenomenon, the validator in charge of proposing the next block at a given blockchain epoch is directly in the position to exploit MEV opportunities, provided that they identified any viable MEV opportunity at that time. 1 However, the activities of searching for MEV opportunities and proposing the next blocks are inherently separable, and indeed, in blockchain finance, MEV opportunities are often pursued by traders that are not necessarily validators themselves. Blockchain traders searching for MEV opportunities are commonly referred to as searchers.
Because of the strong technical flavors related to identifying and exploiting MEV opportunities, a searcher is most often reified in the form of a software agent. Following programmed algorithms, a searcher monitors the evolution of the blockchain status in real-time, while new transactions get included, inspects the transactions submitted in the Mempool as candidates for future inclusion, identifies if the inclusion of some specific transactions generates MEV opportunities, and readily deploys the further transactions needed to exploit those MEV opportunities.
When a searcher agent eventually succeeds in identifying a MEV opportunity, it must face
the problem of compelling some validators to propose a block that includes the MEV
transactions. This requires: () establishing the interaction between the searcher and a validator,
() convincing the validator to choose the transactions deployed by the searcher, in particular,
because there can be other searchers that are trying to exploit the same MEV opportunities, and
() making the validator build a proper block, i.e., a block that includes all needed transactions
in the proper order. To reach these goals, searchers can opt for either on-chain or of-chain
solutions [
On-chain solutions ground on the mechanisms that the blockchain naturally ofers for traders to accomplish the execution of transactions. Upon identifying a MEV opportunity, searchers put MEV transactions in the public Mempool, such that the validators can look up those transactions. To improve the chances of succeeding, the searchers set high gas fees for the MEV transactions, thus incentivizing validators to select those transactions for inclusion in the next blocks. Packaging the transactions in a smart contract may assist in achieving a proper sequencing of the transactions, although the actual control of the searcher on the ordering of the transactions might be admittedly insuficient for some types of MEVs. Unfortunately, the publication of the MEV transactions in the Mempool allows for others to spot those transactions before their inclusion in the blockchain. This opens the possibility that malicious traders frontrun those transactions, meaning that they put in the Mempool their own transactions for addressing the same MEV, but setting higher fees than the original searcher, such that validators will prefer the frontrunning transactions to the searcher’s ones. This attack can be technically sophisticated by implementing generalized frontrunners, i.e., software agents that inspect the Mempool, simulate the transactions (in any possible sequence) in sandboxes in order to readily identify possible MEVs, and indiscriminately frontrun any set of MEV transactions.2
As the risk of incurring frontrunning discourages the use of On-chain solutions to accomplish MEVs, of-chain solutions have become increasingly popular over time. In of-chain solutions, searchers establish private channels with the validators that are in charge of proposing the next blocks and use the private channels to advertise the MEV-augmented blocks, maintaining that the fees in their blocks overcome the fees that the validators could gain by selecting the transactions out of the public Mempool. In particular, the of-chain solutions work well in the context of blockchains based on PoS as a consensus protocol, where the validator in charge of proposing the next block is designated an epoch in advance with respect to the epoch in which the block will get included in the blockchain, and thus the negotiation between the validator and the searchers can take place at that epoch.
Of-chain solutions have led to the rise of of-chain platforms assisting validators and searchers
to meet and negotiate on the MEV blocks. This way, searchers compete with each other in
fee auctions, trying to win the assistance of the in-charge validators by ofering them higher
fees than other searchers. These platforms are commonly referred to as private mempools, or
also permissioned mempools: like the public Mempool, they allow for validators to look up
transactions for inclusion in the blockchain; unlike the public Mempool, they can be controlled
by parties that can limit the access to subsets of validators, e.g., the ones considered well-reputed,
or censor some transactions on the basis of commercial or political reasons.
2Anecdotally Paradigm’s researchers wrote the story of their attempt to recover a relevant amount of liquidity
tokens that people at their company had erroneously frozen in a smart contract [
As we commented above, PoS-based blockchains enable MEV searchers to opt for of-chain solutions to the problem of establishing their interactions with validators, and indeed such of-chain solutions are most often the favorite choice of searchers in order to successfully accomplish their MEV revenues. Since the transition to PoS (“The Merge”), the Ethereum blockchain has seen a flourishing of of-chain MEV interactions, up to the emergence of a rich ecosystem of actors, roles, and platforms, which interplay among them to support the interests of each other, while attempting to contrast the possible vulnerabilities and detrimental aspects that derive from the of-chain deployment of the mechanism. Figure 2 sketches Ethereum’s of-chain MEV ecosystem, and we refer to it to explain the ecosystem’s roles, platforms, and solutions.
Searchers and validators (leftmost and rightmost sides of the figure) are the endpoints of MEV interactions. As previously introduced, searchers are trader agents, usually instantiated as bots, who identify MEV opportunities; validators are the main actors of Ethereum’s PoS protocol, who can be designated in a pseudo-random fashion as proposers of the next blocks. In particular, in Ethereum, each blockchain epoch is comprised of 32 block slots, and the execution of the PoS protocol results in designating a validator as the block proposer for each slot.
The of-chain MEV ecosystem depicted in Figure 2 aims to assist and optimize the interactions
between the searchers and the block-proposer validators. In Ethereum, an ecosystem of this
type is currently being promoted by the Flashbots organization [
Builder actors address the task of block building, that is, they aggregate the MEV transactions identified by searchers as blocks ready for inclusion in the blockchain. Separating the roles of builders and searchers allows for builders to receive MEV transactions (each referred to as a bundle) from multiple searchers, while also monitoring the transactions in the public Mempool. With all this information available, builders can construct the blocks by optimizing the ordering of the transactions in each block, possibly putting together multiple MEV bundles along with public transactions, in order to maximize profits.
Once a builder has created a block, it must bid for validator block spaces. Flashbots publicized the so-called Builder API as an open-source standard interface for builders to ofer their service. As part of this standardization, they recommend a method by which builders can pay validators, which involves the builder setting (in the block header) their own address as the fee recipient of the block, while they append the block with a special last transaction that sends a payment to the validator. Thus, as soon as the block will become part of the blockchain (if it eventually indeed will), the builder will receive the fees of the transactions in the block and the validator will receive the specified payment from the builder. At the same time, the MEV bundles in the block will trigger the revenues expected from the searchers.
The relay and MEV-Boost components provide the middleware for builders and validators to connect with each other. We remark that this specific architecture, as well as the denominations of the components as relays and MEV-Boost, explicitly refer to the design of this type of middleware in the Flashbots platform [19, 20]; other designs could be easily imagined. A relay connects with one or many builders, provided that they implement the Builder API. The relays verify the validity of the blocks sent by the builders, and select the valid blocks that ofer the highest bid to the validator; then they feed the selected blocks to the MEV-Boost component, which in turn is in charge to present the most profitable block to the validator. The Flashbots organization participates directly in the ecosystem with its own builder.
To participate in the ecosystem, validators install and setup the MEV-Boost client, such that they can receive the bids from the builders. In the configuration, they can specify from which relays they would like to receive block bids. MEV-Boost was activated on September 15, 2022, just 17 epochs after “The Merge”.
Based on what has been exposed so far about the Ethereum of-chain MEV ecosystem, we now analyze the distribution of validators in the ecosystem from September 15, 2022, to January 24, 2023.
Block data were downloaded from the date of Ethereum’s transition to PoS (September 15, 2022). In particular, we started from block 15,537,394, i.e., the first block of PoS Ethereum’s Paris Network Upgrade,3 to block 16,474,262 (January 24, 2023). In total, we constructed a dataset containing data from 936,869 blocks over a time period of 131 days. By employing the Etherscan API,4 we collected the following information about each considered block: block number, the number of the block, timestamp, the block time, fee recipient, the account address for paying block reward, and block reward, the reward for the block producer. For MEV-Boost data of the Flashbots relay, we used the proposer_payload_delivered endpoint from the Data section of the Relay API [21].5 In this way, we were able to collect all the information of the blocks 3https://etherscan.io/block/15537394 4https://etherscan.io/apis, using the getblockreward endpoint. 5https://boost-relay.flashbots.net in which a validator requested a block from the Flashbots relay. In particular: block number, builder public key, proposer public key, proposer fee recipient, the address chosen by the validator to receive the reward from the builder, and value, the amount of the reward. Finally, since Flashbots standardizes how payments are made from builders to block proposers, i.e., via a transaction contained at the end of the block proposed by the builder to an address given by the validator [22], we collected the last transaction of each block number contained in the data from the Flashbots relay. To do this, we used the Python Web3.py library along with the Infura API6, collecting the block number, sender’s address, which corresponds to the fee recipient of the block, receiver’s address, which corresponds to the proposer fee recipient, and value, the amount of the reward.
In this section, we analyze the distribution of validators in the Ethereum blockchain after “The Merge”. We show that the analysis may lead to diferent conclusions if we just look at the fee recipient information stored in the blocks, or if we extract the actual identities of validators based on the knowledge of the of-chain MEV ecosystem. Indeed we claim that the latter analysis provides a clearer picture of the phenomenon than the former one, making the distribution of validators more apparent.
The first analysis we performed was on the first 1,000 blocks after “The Merge", to verify the
many websites, blogs, and online articles claiming that 40 percent of the blocks were validated
by just a few entities [
Having collected data from the 131 days following Ethereum’s transition to PoS, we analyzed the distribution of fee recipients following the introduction of actors who can carry out of-chain MEV strategies. By observing Figure 4, we can notice that the ifrst three fee recipients are diferent from those of the first 1,000 blocks. Lido collapses from 27.9% of the first 1,000 blocks to 6.64%; the first place is now occupied by the address 0xdafea492d9c6733ae3d56b7ed1adb60692c98bc5, which corresponds to ENS address flashbots-builder.eth, with a percentage of 20.9%; it is followed by the address 0x690b9a9e9aa1c9db991c7721a92d351db4fac990, which corresponds to 6https://docs.infura.io/infura/ 7https://lido.fi/
ENS address builder0x69.eth, with 15.8%; then, in third place, we find the address 0x95222290DD7278Aa3Ddd389Cc1E1d165CC4BAfe5, with 10.6%, for a total of 47.3%. With respect to Figure 3, it would seem that the situation has completely reversed in favor of these three builders, which are in fact fee recipient addresses of builders employing the Flashbots relay.
By way of example, by further analyzing only Lido and flashbots-builder.eth, we can see in Figure 5 that the number of blocks per day in which Lido appears as a fee recipient begins to collapse from thousands to less than a hundred over time. In contrast, the exact opposite occurs for flashbots-builder.eth, as it emerges from Figure 6.
Analyzing only the fee recipient addresses is not suficient to understand who really performs the activity of validation. In fact, it is necessary to recall that Flashbots builders (and other builders based on the Flashbots relay) have a specific standard to reward actual validators. The builder is indeed the fee recipient, but it includes a transaction (the last in the block) that pays Ether tokens to the block-proposer validator [22]. Hence, we extracted the addresses of these rewarded validators within the Flashbots relay data, in order to investigate who was in charge of validation. As a result, we noticed that the top-3 validator addresses are the same as those in Figure 3. This is detailed in Figure 7, illustrating the addresses of rewarded validators instead of those of fee recipients for the top-3 builders in Figure 4. To make this concept even clearer, as an example, let us show in Figure 8 the number of blocks per day in which Lido appears as a validator rewarded by the builders; we clearly see that the number of blocks per day does not collapse after the introduction of builders, but maintains instead a constant trend. Hence, based on this preliminary analysis, it does not appear that the of-chain MEV Ethereum ecosystem contributes to modify the actual validator distribution in Ethereum, which still remains largely the preserve of the already wealthier players.
In recent times, MEV has become an important topic for the Ethereum community. As a
result, several initiatives have been developed to mitigate the negative impact of MEV (e.g.,
centralization) on the network. Flashbots’ MEV-Boost is a noteworthy proposal that aims to
create a more equitable distribution of value. In this article, we conduct an analysis of the
validated blocks after Ethereum’s update to PoS, known as “The Merge", showing how the
scenario has changed in recent months. In fact, the recipient of the fee no longer always
indicates only the validator, but often indicates the MEV builder, and tracking rewards related
to the validator requires some additional steps. From a preliminary analysis, it seems to remain
confirmed what was observed in [
Accessed on April, 28th, 2023. [21] Flashbots, Flashbots Relay API, https://flashbots.github.io/relay-specs/#/Data/ getDeliveredPayloads, 2022. Accessed on April, 28th, 2023. [22] Flashbots, Block Builders, https://docs.flashbots.net/flashbots-mev-boost/block-builders, 2022. Accessed on April, 28th, 2023. [23] Ethereum.org, Gas and fees, https://ethereum.org/en/developers/docs/gas/, 2023. Accessed on April, 28th, 2023. [24] Lido, Execution Layer Rewards Vault, https://docs.lido.fi/deployed-contracts/, 2023. Accessed on April, 28th, 2023.