MEV Examination and Putting a Stop to MiCA’s Article 92 Nonsense

This article was co-authored by Jonathan Galea, CEO at BCAS, and Martin Azpiroz, Techincal Analyst at BCAS.

The ESMA's latest consultation under MiCA, addressing Market Abuse provisions in crypto-asset markets, has sparked engaging debates. The most significant controversy relates to the first question, specifically in its second part, which asked legal experts, 'Are there other types of entities in the crypto-asset markets that should be considered as a PPAET (e.g. miners/validators)?'. This question concerns the matters discussed in point 19 of the recent ESMA consultation:[1]

"ESMA notes that MiCA is clear when indicating that orders, transactions, and other aspects of the distributed ledger technology may suggest the existence of market abuse e.g., the well-known Maximum Extractable Value (MEV) whereby a miner/validator can take advantage of its ability to arbitrarily reorder transactions to front-run a specific transaction(s) and therefore make a profit."

Consequently, this sentence leads ESMA to question the potential inclusion of miners and validators under the definition of persons professionally arranging or executing transactions (‘PPAETs’) based on the concept of Maximum Extractable Value ('MEV') and the idea that MEV activities may suggest the existence of market abuse. This interpretation would mean that they would be obliged to abide by Article 92 of MiCA, requiring them to have in place arrangements, systems and procedures to prevent, detect and report to the national competent authorities instances of possible market abuse.

To establish our public position on the matter, as conveyed to ESMA via the appropriate reply, we deem it crucial to develop a detailed article tackling MEV from a technical perspective. This article aims to clarify its technical nuances and base the legal conclusions that substantiate our position on them.

Far from being a new topic on our blog - we previously covered whether MEV is under the scope of MiCA's market abuse provisions and analysed MiCA's Title IV on market abuse prevention and prohibition - the subject obliges us to extend its coverage with the present piece. Building upon our earlier articles, we propose a new MEV analysis, with a focus on:

A concise technical introduction to MEV.
The current MEV landscape on two of the most active blockchains in this domain.
A review of the main actors in the MEV ecosystem.
An analysis of the most significant MEV activities.
The arguments that underpinned our position in the ESMA reply.
A legal perspective of the consequences of the most common MEV activities.

What is MEV?

MEV stands for Maximum Extractable Value, which refers to the value block proposers can extract by reordering, excluding, or including transactions while proposing a new block. In other words, as defined in our previous article, MEV is the value block producers can extract over block rewards and transaction fees.

MEV is possible in different types of blockchains, whether they use Proof of Work ('PoW') or Proof of Stake ('PoS') mechanisms to reach their consensus. This is primarily due to the lack of a fixed and standardised process for including and ordering transactions in most blockchains. For instance, Ethereum clients such as geth[2] and reth[3] as well as the algorithm used by the Layer-2 solution Optimisms Stack sequencers[4], suggest ordering transactions by priorityFeePerGaspaid, with the oldest transaction preferred if other parameters are equal. This approach allows users to prioritise their transactions by increasing the priorityFeePerGasPaid. Nevertheless, validators retain the ability to include, reorder, or exclude transactions based on their own interests or benefit.

In this context, MEV can be seen as:

A means to generate additional value on top of block rewards and transaction fees, incentivising block producers to keep the blockchain running.
An existential threat to blockchains.

However, to classify MEV as 'beneficial' or 'harmful' is not a straightforward task. It depends on objective factors, such as users getting worse trade prices or stable prices across different decentralised exchanges ('DEXes'), and subjective factors, like potential block proposers' centralisation or transaction censorship.

To understand the impact of MEV and the role of miners and validators, it is necessary to identify all actors involved in MEV activities and then analyse each of the most common MEV activities individually. However, we will start by focusing on the landscape of two of the two blockchains with the largest MEV activities: Ethereum and Solana.

MEV in Ethereum

Priority Gas Wars (‘PGA’)

Ethereum was created as a PoW blockchain. In its early days, Ethereum transactions' ‘happy path' was as follows:

A users send a transaction.
The transaction was carried to the mempool by a node, where it waits to be picked up by a miner.
A miner picked up the transaction from the mempool and included it in a block.

The rise of decentralised finance ('DeFi') applications ('dApps') has significantly altered the landscape of Ethereum transactions. New opportunities have arisen, such as replicating users' profitable transactions from the mempool and executing them first, potentially 'stealing' their profit. This has led to the development of bots that monitor the mempool, seeking out profitable transactions to replicate and capitalise on before the user. This competition among bots has led to three major downsides on Ethereum:

Congested network.
Higher gas fees.
Less profit opportunities for regular users.

Nevertheless, while this bot competition negatively impacted the user experience, Ethereum miners benefited from it as higher fees meant more rewards for them, and trading bots also started to tip Ethereum miners to get transaction priorities.

The Advent of Flashbots and MEV-Geth

To mitigate the headaches from this era, known as priority gas auction ('PGA'), a group of developers known as Flashbots developed an Ethereum client known as MEV-geth. By running MEV-geth, miners were allowed to connect to a network of relayers. These relayers were, at the same time, connected with searchers. Searchers were entities or algorithms constantly monitoring the mempool, searching for high MEV transactions and bundling them to obtain the highest possible MEV profit. Miners accessed these searchers' bundles through the relayer network and used them to fill new mined blocks. However, they still had the opportunity to reorder, exclude or include transactions in their best interest. With this improvement, the MEV process, known then as Miner Extractable Value, became more transparent while mitigating some of the abovementioned issues, leading to more than 90% of miners leveraging the MEV-geth client.

MEV in Proof-of-Stake’s Era

Once Ethereum transitioned to a PoS consensus mechanism, the MEV landscape changed. In the first place, MEV was renamed Maximum Extractable Value, as miners were left out of the picture, and Ethereum validators overtook their role. Secondly, the Ethereum community's approach to MEV changed. Instead of modifying clients to enhance MEV handling, a protocol called MEV-Boost was created. This protocol follows the Proposer Build Separation ('PBS') philosophy, according to which the entities in charge of building and proposing Ethereum blocks should be different. By following this philosophy, the block proposers will receive a pre-ordered set of transactions to be included in their blocks. Therefore, a PBS approach removes the chance of validators to exclude, reorder or include transactions for their benefit. In this context, a new actor, a builder, was included.

Consequently, the Ethereum transaction landscape in the PoS era is the following:

Users send a transaction, which nodes carry to the mempool.
Searchers monitor the mempool for transactions with MEV opportunities.
Builders receive these transactions from searchers and arrange them to maximise MEV profits. In their proposed blocks, builders use their own addresses as the 'payload coinbase address', meaning they receive any reward from the block. At the end of the block, they include a transaction to transfer part of the fees received to the address of the validator selected as the next block proposer to compensate it for selecting their payload (transactions).
Relayers, which are connected to builders and validators, receive builders' proposals and verify the validity of the payloads, including the amount of ETH to be paid to the block proposer. Subsequently, they send the headers of the proposed blocks to the block proposer.
Once selected as a block proposer, the validator chooses the block header with the highest MEV profit, signs it, and sends it back to the relayer.
The relayer verifies if the validator replied with the correct block header and verifies its signature. To ensure the block is valid, relayers send the block header to a local node before replying to the block proposer with the actual block. If the block executed from the block header is not valid, the relayer will not reply to the validator with the full block, and the slot will be missed, meaning that the validator will be slashed. Conversely, if both parameters are verified, the relayer sends the full execution payload body (the complete block), which the validator uses to propose a new block to the blockchain.
Then, the block is proposed and added to the chain, awaiting other validators' attestations (confirmations).

The Role of Validators on the Ethereum MEV Landscape

Following the explanation of how transactions are handled and how new blocks are proposed on the Ethereum PoS blockchain, two concepts become significant to understanding the role of Ethereum validators on the current MEV landscape. On the one hand, the principle of commit-and-reveal and, on the other hand, the slot time limitation.

The importance of these concepts proves its value in light of the Ethereum community's concerns about the fact that validators, in their aim of pursuing the maximisation of MEV profits, could overlook its main tasks concerning its role within Ethereum's consensus mechanism; validating transactions, proposing new blocks and securing the network. Even though the PBS philosophy establishes a solid step ahead in the aim of keeping validators committed to their task of proposing blocks instead of chasing the best MEV opportunities, the following two points contribute to this fact:

The Commit and Reveal Principle. As explained above, once a validator is selected as the proposer of the following block, relayers will present them with the block header containing the highest bid offer, equal to the highest MEV profit. In this process, at first instance, the relayer would not send the complete payload arranged by the builder but just the block header and the bid. The block header allows Ethereum nodes to verify whether the transactions included in that block are valid. However, the validator cannot access the transactions from that block header. Therefore, the commit-and-reveal principle means that validators must first commit to the block header by signing it. Once the relayer verifies its signature, the transactions will be revealed. The instauration of this principle prevents validators from applying MEV activities for their own benefit while protecting the builder’s work. Moreover, this principle represents another step ahead of the PBS philosophy.
The Slot Time Limitation. Ethereum consensus is structured around a period of time known as epoch. An epoch lasts 6 minutes and 24 seconds and is composed of another time period structure denominated slot. Each slot, which lasts 12 seconds, is the period within which a validator is selected to propose a new block to the Ethereum blockchain. Additionally, a set of validators are attributed to each slot as the 'slot attestators'. In this sense, to be considered 'confirmed,' the block must be proposed and receive enough attestations in this brief period of 12 seconds. If the block is not proposed or does not receive enough attestation on its slot, the slot will be considered a 'missed slot', and the validator selected as the block proposer will see its stake slashed. As shown in the picture below (Figure 1), before the moment 0 of the slot, builders start to arrange transactions received from searchers to obtain the highest MEV profits and share them with relayers.

Figure 1 – Frequency of Block Availability over Time.
Source: https://blog.metrika.co/relays-are-a-latency-game-303aadb393ce

This figure suggests that block proposers leveraging MEV boost should be able to propose a block at the proper time to propagate it successfully and gather the number of attestations required to get their block ‘pre-confirmed’. However, as slot time passes, the payloads presented by builders and handed to block proposers by relayers achieve higher MEV profits (see Figure 2).

Figure 2 – Highest Reward Blocks Availability over Time.
Source: https://blog.metrika.co/relays-are-a-latency-game-303aadb393ce

Therefore, block proposers face a crucial decision: let the time pass to propose a block trying to maximise its MEV profits or secure their slot renouncing to wait for a higher MEV payload. However, this decision is constrained by the slot time, as if they waited too long, their block would not been able to achieve the number of necessary attestations to be 'pre-confirmed', resulting in a missed slot and slashing sanction. In this sense, the slot time limitation incentivises validators to continue proposing and attesting blocks rather than waiting for the best MEV opportunities, keeping the Ethereum blockchain properly functioning.

MEV-Boost Limitations and its Future

MEV-Boost is an implementation of the PBS philosophy, currently leveraged by 90% of Ethereum validators. It helps to reduce the impact of MEV on users while democratising access to MEV profits for 'solo validators'. However, it also has its opposing sides. For instance, this protocol comes with many trust assumptions, with a 'chain of trust' that can be described as follows:

Searchers have to trust that builders using their transactions to post the winning bid to the next block proposer will not replace the transactions with their own and will share the MEV profits with them.
Searchers and builders have to trust that relayers will not steal or reveal their transactions/strategies to block proposers before committing to them.
Block proposers have to trust the information provided by the relayers as they accept their proposals by knowing only how much they will be paid and the block header.
Lastly, block proposers have to trust that relayers will reveal the block/transactions corresponding to the committed block header.

Another important point is that since validators run MEV-boost as a sidecar to Ethereum clients, the protocol is only aware of the bids that builders send to proposers once the builders' payloads are published on a proposed block. Additionally, there is a centralisation issue among block builders, with 87% of Ethereum blocks from the last 14 days being fulfilled by transactions proposed by the top 3 builders' solutions (Beaverbuild, Titan Builder and Rsync-Builder).[5] [6] [7] [8] To address these downsides, the Ethereum Foundation is working to implement a PBS system at a protocol level, establishing it as the official method to build and propose new blocks in the Ethereum network.

MEV in Solana

The MEV landscape in Solana differs from those in Ethereum and other EVM chains due to twofold critical characteristics:

Solana does not have a mempool; its transactions are processed in less than 200ms. Instead of a mempool, Solana relies on relayers, which forward incoming transactions to validators and perform tasks like packet de-duplication and signature verification.
Solana prioritises continuous functionality, processing transactions and generating blocks rather than uniform consistency across all nodes. As a result, nodes might not see the same transactions, creating latency where validators' geographical location influences how fast they receive new transactions.

To address these issues, a protocol named Jito was created. Jito, a fork of Solana validators' clients, introduced a "block space auction market" similar to that in Ethereum. By leveraging the infrastructure of this protocol, searchers can identify and arrange the most profitable MEV transactions in bundles. To find the best MEV opportunities, searchers can connect to 'Shred-Stream', the Jito low latency RPC providing access to the latest Solana transactions.

Searchers send their bundles to the Block Engine, along with a fee to incentivise validators to include their bundles in a block. The Block Engine, similar to relayers on MEV-boost, simulates the transactions, ensuring the bundle only contains successful transactions. The Block Engine charges a 5% fee on all MEV rewards in exchange for their work.

Bundles are then ordered according to their tip, and validators select bundles to be included in their proposed blocks. An important detail is that these transaction bundles must be executed in the order provided by the searcher, removing the chance for validators to re-order, exclude or include transactions. However, blocks are 80% filed with Jito bundles, while the remaining 20% of block space is filled with transactions directly selected by validators, allowing them to profit from MEV opportunities.

It is worth noting that Jito initially introduced a mempool on Solana. However, due to 'negative externalities impacting users on Solana', as searchers easily copied and replicated their transactions, the Jito mempool was deprecated.[9]

Who are the actors in MEV?

After introducing the MEV landscape in two of the most relevant blockchains in terms of MEV activity, it is safe to conclude that the general MEV space includes the following actors:

Searchers: Entities, bots or algorithms that constantly monitor the most profitable MEV transactions to get them included in a block.
Builders: An actor related to the Ethereum current MEV scenario in charge of arranging the transactions presented by searchers to obtain the highest MEV profits. In exchange for their work, they ask block proposers for a fee.
Relayers: In Ethereum, relayers, and in Solana, the Block Engine, connect those proposing transactions to be included in blocks with block proposers. They represent the trust assumption point of the system, acting as intermediaries between block producers and block proposers. As they are responsible for verifying the validity of the builders' proposed payload and the block proposer's signature, both parties rely on their honest behaviour. In Ethereum, Relayers are encouraged to run several nodes to avoid relying on a node when they check blocks' validity.
Block Proposers: Validators in PoS blockchains and miners in PoW blockchains are responsible for proposing and propagating new blocks on their networks. In an MEV context, they will try to include, reorder or exclude transactions to maximise their profits on top of block and transaction fee rewards. However, following the implementation of solutions like MEV-Boost, Ethereum validators cannot exclude, include or reorder blocks, as they are proposing blocks based on the transaction order decided by block builders. In Solana, while validators cannot modify transaction bundles, as Jito's bundles do not occupy the full block, they still have room to fill the remaining block space with their own selected transactions, leaving room for their MEV activities.

Most Common MEV Activities

Having clarified what MEV is and how it currently works on Ethereum and Solana and identified the key players involved in MEV activities, it is time to analyse these MEV activities in detail. For the purpose of this article, our scope will be limited to the following MEV activities:

Front running.
Back running.
DEX arbitrage.
Sandwich attacks.
Spam attacks.
Time Bandit attacks.
Uncle Bandit attacks.

Front running

In an MEV context, front-running consists of attempting to profit by executing transactions ahead of others pending transactions. To perform a front-run, MEV profit searchers constantly monitor for pending transactions that can benefit them if they place a transaction before them.

The classic front-running example is the DEX transaction sent by a regular user trying to buy a token. To cope with token volatility, DEXes offer slippage, which signifies the price change percentage the user is willing to accept. Once the slippage is defined and the transactions sent, it will fail if the price changes over the slippage percentage before its execution. Therefore, what front runners do in this case is search for DEX token buy transactions. Once they find an appealing transaction, they replicate it, with a higher gas fee to be executed first than the user's transaction. To succeed in their task, front-runners must calculate that the price impact on the token from their transaction does not exceed the user's slippage limit. Once the front-runner transaction gets executed, the price of the token increases, and the user buys the token at a higher price than the one seen at the time of sending its transaction. However, at this stage, the MEV searchers would not end up making any profit.

Back-running

Back-running is the opposite of front-running; it consists of attempting to profit by executing transactions immediately after others' pending transactions. In this case, MEV profit searchers will monitor for transactions that can benefit them if executed right before their transactions. A classic example frequently executed by trading bots is called sniping. In this case, trading bots monitor for transactions that create new token DEX pairs. Once they identify one of these transactions, they send a transaction to buy some of these new tokens at a low price, as they are just being launched. To succeed in back-running, staying within the target transaction regarding gas fees is crucial, as the MEV transaction must be executed immediately after it. Consequently, MEV searchers tend to send their transactions with the same amount of gas or slightly less than the target transaction. Subsequently, as users start noticing and buying the new pair, the bot holding a percentage of the tokens purchased at the launch price can profit by selling them at a higher price.

Another example of back-running is when MEV searchers try to profit from lending platforms' liquidations. Lending platforms allow users to borrow tokens by depositing collateral in exchange. To guarantee that lenders are to be paid, loans must be over-collateralised, meaning that the borrower's deposits must be a pre-determined percentage higher than the borrowed amount. Therefore, lending platforms establish minimum over-collateralisation percentages to track borrowings' health. When a borrower's collateral falls below the minimum percentage due to price fluctuations in either the deposited or the borrowed token, the borrower's position can be liquidated, and a fee is to be paid to the borrow liquidator.

Lending platforms allow anyone to perform liquidations by calling the specific function provided by the platform's smart contracts. To successfully execute a liquidation transaction, the liquidator has to repay a portion of the borrower's debt, reclaiming the collateral at a discount, often referred to as a liquidation fee. In this scenario, the back-running strategy consists of placing the liquidation transaction right after the transaction that marks a borrow as available for liquidation, which takes place after the Oracle platforms update the involved token prices, profiting from the liquidation fee.

DEX Arbitrage

DEX arbitrage represents one of the most common MEV techniques. In this case, MEV searchers exploit price differences for the same token in different DEXes.

An arbitrage strategy can involve the following sequence. First, the MEV searcher will look for a pending transaction trying to sell a token on a DEX. The transaction must be relevant enough to impact the token's price, making it decrease significantly. The first part of this strategy would be to back-run the selling transaction to buy the token at a lower price. The second part of the arbitrage consists of selling the tokens on a different DEX, where the token's price is still above the buying price on the first exchange. By placing this second transaction immediately after the first one, the arbitrage opportunity is exploited almost at the same time it is created.

DEX arbitrage is considered a beneficial and necessary MEV activity, as stable prices across different DEXes contribute to more efficient markets.

Sandwich Attack

A sandwich attack combines front-running and back-running. In this case, MEV searchers look for pending transactions from which they can profit by placing a transaction immediately before it and another immediately after. The most common example involves DEX transactions. In a sandwich attack, MEV searchers monitor the blockchain for unexecuted transactions that aim to buy a token. The MEV searcher then places a transaction just before the target transaction by setting higher gas fees and buying the token ahead of the user. Subsequently, the MEV searcher places another transaction to be executed right after the target transaction, selling the token bought in the first transaction to the user. In this scenario, the MEV searcher buys the token at price x. The target user of the sandwich attack then buys the token at a higher price, x1. After the price increase caused by the user’s transaction, the MEV searcher sells the token, profiting from the difference between prices x and x1. After the price increase caused by the user transaction, the MEV searcher will sell the token, profiting from the difference between x and x1 prices.

The general sentiment from the crypto-space indicates that sandwich attacks harm the user experience, as users buy a token at a higher price than expected when sending their buying transaction. This sentiment is reflected in the Solana Foundation's decision to withdraw their staked SOL from validators for allowing sandwich attacks[10] and the above-cited decision of Jito to deprecate their custom mempool. However, a counter-argument can be made. As explained, to successfully execute a front-run to a transaction aiming to buy a token on a DEX, the MEV searcher must contemplate its price impact to stay within the slippage percentage selected by the user. Therefore, once users select the slippage percentage, they declare they will buy the token if its price is within these pre-determined limits. In this context, the argument against labelling sandwich attacks as harmful activity stems from the fact that users are buying the token within the limits they agreed to buy it beforehand.

While there are solutions implemented to protect users from this practice, such as CowSwap[11], users can also protect themselves from sandwich attacks by setting low slippage percentages. Although this increases the risk of transaction failure if the token price changes between the time the transaction is sent and when it is executed, a low slippage percentage reduces or even eliminates the margin for sandwich attackers to profit while still covering the fees for their two transactions.

Spam attacks

The spam attack consists of sending a large number of transactions to a blockchain to congest it. A congested blockchain results in higher transaction fees, deterring other users from trying to extract MEV profits. While the blockchain is congested enough, the attacker can profit from performing MEV strategies or with fewer competitors.

Time-bandit attacks

PoW miners or PoS validators, who are responsible for proposing new blocks, can perpetrate this kind of attack. Both actors propose the next block in the blockchains that they participate in, and an essential factor for this type of attack resides in their ability to choose which block they propose on top of. Therefore, by exploiting this entitlement, miners and validators can be tempted to reorder the blockchain to pursue MEV profits.

A time-bandit attack occurs when block proposers detect an "unconfirmed" block, for example, two blocks before the last one, which contains a high MEV opportunity, such as DEX arbitrage or sandwich attack opportunities. The block proposer can then attempt to "re-create" or "re-propose" the MEV-profiting block and propose it on top of the previous block, pretending that the last two blocks do not exist. In this scenario, the blockchain will fork, creating two versions of the chain.

However, this attack is not without risk. The risk block proposers face while perpetrating this attack is that other network participants might consider the first version of the chain valid and continue adding blocks on top of it. If this happens, the block proposer loses the opportunity to propose a valid block and the attack is unsuccessful. While there will be no further consequences to the idle use of the energy required to create a block in a PoW network, in the context of a PoS network, the attacker could see his stake impacted by the slashing penalty. Otherwise, if the attack is successfully perpetrated, the validator or miner will earn rewards for the proposed block, transaction fees and MEV profits.

The Proposer Boost Mitigation

On May 25, 2022, seven months before Ethereum transitioned from a PoW network to a PoS one, the Ethereum PoS, which had been functioning as a side chain since December 2020, allowed ETH holders to participate by staking their tokens in some ‘testing in production’ state, suffered a seven-block re-organisation. In this case, the so-called time bandit attack was due to a latency problem.

In simple words, one of the blocks received enough attestations to be considered ‘pre-confirmed’, but its propagation was delayed due to latency inconveniences. The next block proposers, as it could not see that block, proposed their own block on top of the previous one, and another chain started to be built on top of it, ending up with a new network fork. Ethereum PoS network has a rule to decide between forked versions, in which its nodes must decide to ‘support’ or ‘follow’ the chain version with more attestation weight. In this specific case, the latency-affected block was seen by a large part of the network participants, who continued to attest to it as the latest block. At the same time, the forked version was sustained by those who did not see the latency-affected block continue to gain attestations on its own. The problem finally became visible when the latency-affected block gained more attestations than the forked version, which already had 7 blocks more than the first chain version, and a block was built on top of the latency-affected block. However, the question might be how this situation was deemed possible.

The explanation behind this undesired situation on Ethereum was caused by the solution that the protocol introduced to avoid re-organisations attacks, such as the time-bandit attacks. Known as proposer boost, it modified the Ethereum fork choice rule. Once a node performs an honest re-organisation, such as the one in the above example, its block will receive a boost of 40% on the attestation received once it attempts to forcibly reorg blocks with attestation weight below 20%. In this sense, the rest of the network would have no option but to choose its version of the chain as canonical. However, at that point, the proposer boost update was released as a soft fork, a fact that created a situation where some validators were using proposer boost and some were not, splitting the views. Now that proposer boost is part of Ethereum clients, the network has a method to deal with honest re-organisations and avoid time bandit attacks.[12] [13]

Uncle bandit attacks

Uncle bandit attacks can only take place in PoW blockchains. This type of attack can occur in two different situations. The first situation materialised when two blocks were mined simultaneously with the same 'number, ' something that cannot happen in PoS blockchains, where the blockchain's protocol randomly determines block proposers. Once two blocks are mined at the same time, only one of them can be added to the blockchain, making the other an 'uncle' block. Once a block is labelled as 'uncle', it becomes public, meaning that other miners can see and pick the transactions from the uncle block and add them to their own set of transactions in a new block to obtain the maximum MEV value possible.

The second type of uncle bandit attack occurs when a miner deliberately delays the propagation of a mined block and then propagates another block containing the highest MEV value transactions from the uncle block. The rationale for this type of uncle bandit attack lies in the fact that the miner will earn block rewards, transaction fees and MEV profit from the second block and block rewards from the uncle block. In this type of attack, different MEV opportunities like front-running, back-running, and sandwich attacks are combined to extract the maximum value.

Labelling MEV from a Technical Standpoint

As with many other technological developments, MEV cannot be catalogued as a harmful or beneficial activity in itself; instead, it can be used, in this context, to perform actions according to the blockchain consensus rules or against them. While the first type of action can be seen as a way to extract the maximum value generated by blockchain transactions, something that can incentivise all the involved actors to do their best to keep blockchains up and running, the second kind of use of MEV can pose an existential threat toward blockchain centralisation while harmfully impacting the user experience.

However, an attempt can be made to categorise MEV activities according to their purpose as follows:

Harmful MEV Activities. Examples of harmful MEV activities are those that hamper blockchain consensus achievement, such as the time-bandit attacks, which can lead to discrepancies among miners or validators. Then, we can catalogue MEV practices as harmful when they undermine the user experience. Cases such as uncle bandits' attacks, time bandit attacks and spam attacks are situations in which the user experience gets decremented by seeing their transactions delayed or too expensive to execute.
Beneficial MEV activities. However, MEV activities can also have a beneficial impact on the blockchain ecosystem. For instance, trading bots that arbitrage token prices between DEXs contribute to market stability. In the same sense, liquidating under-collateralised loans helps maintain healthy lending platforms, guaranteeing that lenders will be paid. Furthermore, the evolving Ethereum landscape has democratised access to the benefits of MEV, beyond hardware-intensive validator clusters to "solo validators" and even users. This is materialised in the increasing trend of projects that share the benefits of MEV with its users.

Nevertheless, it is paramount to highlight that the activities included in the second category take place more often and regularly, propelling MEV as a beneficial activity for blockchains, as it keeps incentivising all the participants that make blockchains work. This fact, coupled with the ongoing efforts from the Ethereum and Solana communities to cope with MEV activities that can have a negative impact on blockchain consensus achievement, such as MEV-boost or the proposer-boost, allows us to sustain a general view of MEV as a positive activity in the blockchain ecosystem.

Regulatory Assessments of MEV

After having gained a clear understanding of the technical characteristics of MEV, how it works in Ethereum and Solana, the role that each of the actors involved in the MEV landscape plays and which are the most common MEV activities in the crypto space, regulatory assessments of its implications can be drawn following several different avenues. In our case, this technical assessment of MEV propelled and substantiated our position in replying to the first question asked by ESMA on its third consultation package. In light of this technical analysis, let’s unpack why we consider that miners and validators should not be regarded as a PPAET.

Comments on ESMA’s extension of the interpretation of a PPAET

ESMA's analysis rightly extends the scope to include crypto-asset service providers (CASPs) operating a trading platform as persons professionally arranging or executing transactions (PPAETs). Moreover, the inclusion of CASPs providing services of reception or transmission of orders for crypto-assets on behalf of clients and/or execution of orders for crypto-assets on behalf of clients is aligned with the interpretation of the definition of persons professionally arranging or executing transactions (PPAETs) under MAR’s Article 3(28).

However, the inclusion of CASPs providing custody and administration of crypto-assets on behalf of their client seems contrary to the idea behind MiCA’s Article 92. The definition of custody and administration service under MiCA - the safekeeping or controlling, on behalf of clients, of crypto-assets or of the means of access to such crypto-assets, where applicable in the form of private cryptographic keys – does not typically include or denote activities that constitute professional arrangement and/or execution of transactions; for instance, a CASP providing custody and administration as a service does not always additionally provide the ancillary service of reception and transmission of orders as a service, which would typically be seen as a form of transaction arrangement. Therefore, where a CASP solely provides custody and administration services, such an activity should not be considered as equivalent to a PPAET and should therefore fall outside the scope of Article 92.

Why should Miners and Validators not be classified as PAPETs?

Needless to say, BCAS strongly disagrees with the proposed inclusion, even by way of an example, of miners and validators under the definition of PPAETs, which should remain limited to CASPs and persons who are not involved in ensuring the proper functioning of distributed ledger technology (DLT) networks. Miners and validators do not execute transactions, as transactions are only executed after validation resulting from the network’s collective consensus. Additionally, miners and validators are not always responsible for 'arranging' (in the loosest sense of the term) transactions in blocks, as their roles may differ depending on the network in question.

The Role of Miners and Validators in Decentralised DLT Networks

Miners and validators play a crucial role in securing the running of permissionless DLT networks. Under point 63 of its second Consultation Paper ‘Technical Standards specifying requirements of MiCA’ (5 October 2023, ESMA75-453128700-438), ESMA considered that such networks are to be excluded from the possibility of outsourcing arrangements under MiCA because 'no formal contractual relationship (such as a service level agreement) is required to interact with permissionless blockchains'. Crucially, ESMA mentioned that 'permissionless DLT networks may be considered a form of "common good" resource'. Based on this interpretation, it is safe to state that miners and validators play a vital role in ensuring the proper running of a 'common good' resource, a marked departure and difference from the ‘traditional’ role attributed to PPAETs, which provides no services that may be deemed to support a "common good" resource.

As outlined in point 19 of the present consultation, ESMA’s questioning around the potential inclusion of miners and validators under the definition of PPAETs seems based on the concept of Maximum Extractable Value (MEV) and the idea that all MEV activities suggest the existence of market abuse. This is far from a correct picture; MEV activities – which refer to the value block proposers can extract by reordering, excluding, or including transactions while proposing a new block – are often crucial for the efficient functioning of permissionless DLT networks.

MEV and its Positive Effects

For instance, back-running is a type of MEV activity consisting of executing a transaction right after a targeted transaction. Such activity is often performed on lending platforms, where anyone can perform liquidations in exchange for a percentage of the liquidation fee to keep loans over-collateralised. In this scenario, back-running activities allow MEV operators to profit from the liquidation fee while rendering service to lending platforms by enabling them to operate safely and maintain financial health for the protocol in question. Contrary to a common yet misconceived understanding of front-running, front-running can actually help level out crypto-asset prices across multiple AMMs or DEXes, making it a form of arbitrage that prevents users from acquiring crypto-assets at significantly different prices across various decentralised forms of trading venues. Front-running often occurs when users increase the standard slippage rates by an amount which would be considered a disparity in prices for the crypto-assets; it is up to the users to accept the risk coming from increased slippage, which is what leads to arbitrage opportunities.

MEV Classification

In any case, it is extremely difficult to differentiate between beneficial instances of MEV and potentially harmful ones. Even if one were to consider imposing obligations on operators of MEV, namely searchers, relayers, and builders (as miners/validators, depending on the network, may not even have the opportunity to engage in MEV), it is almost impossible to enforce such obligations, as a) the identity of any such participants who may be using MEV in a malicious manner for their own benefit is often not known/not possible to be known and b) integrating any systems to detect, prevent and report market abuse would just inhibit their ability to perform their functions versus other searchers/relayers/builders not located in the EU/EEA, likely to result in the ousting of such entities, and therefore harming the Union’s prospects in remaining as technologically relevant in the industry of crypto-assets.

In summary: from a technological perspective, MEV keeps blockchains running in the most efficient manner possible by incentivising block producers to act in competition. Therefore, ESMA’s attempt to prevent or limit MEV by including miners and validators in the definition of PPAETs, or any other operators involved in MEV, is tantamount to a disproportionate measure that would hamper the efficiency of the decentralised markets, rather than increase their level of protection against malicious participants – which in any case are likely to be located around the world, including outside of the Union.

Conclusion

All in all, defining MEV as a beneficial or harmful activity for blockchains requires a thorough understanding of the current developments in the field, and is generally an exercise that can easily backfire. While several developments are being made to curb its harmful effects, block-building cartelisation still threatens decentralisation. At the same time, Ethereum and Solana’s history is valuable proof that unattended MEV competition among validators leads to consensus instability, flawed security, and private communication between block producers and proposers. Therefore, in our view, the most prudent approach is to acknowledge the presence of MEV opportunities in the blockchain landscape. Simultaneously, the industry should persist in developing tools to effectively mitigate its limited harmful effects, without limiting its beneficial contributions.

Concerning the latest public consultation by ESMA on the RTS/guidelines concerning the detection and prevention of market abuse under MiCA, its first question worryingly leaves the door open to the possible interpretation that 'persons professionally arranging and executing transactions' (PPAETs) could be extensively interpreted to include miners/validators. This would mean that they would be obliged to abide by Article 92 of MiCA, requiring them to have in place arrangements, systems and procedures to prevent, detect and report to the national competent authorities instances of possible market abuse.

Not only would this be a departure from the current interpretation that this is limited to purely centralised service providers that include 'buy-side firms, proprietary traders, DEA providers and non-financial firms that trade on their own account as part of their business activities', but it would be a death knell to any miners/validators located in the EU/EEA.

It is simply an impossible obligation for miners/validators to abide by for various reasons, not least of which being that a) they do not execute transactions (it's the collective consensus of the network which does), b) in certain networks they are not the ones responsible for 'arranging' transactions in blocks (and in any case, they are unlikely to be dealing on own account), and c) in Permissionless DLT Networks as defined by ESMA are excluded from key obligations under MiCA simply because there is 'no formal contractual relationship (such as a service level agreement) is required to interact with permissionless blockchains... permissionless DLT networks may be considered a form of "common good" resource' (quoted from ESMA’s own separate second consultation document on MiCA’s RTS) - a critical difference when compared with the normal understanding of PPAETs, which provide no services whatsoever that may be deemed to support a 'common good' resource.

---

[1] https://www.esma.europa.eu/sites/default/files/2024-03/ESMA75-453128700-1002_MiCA_Consultation_Paper_-_RTS_market_abuse_and_GLs_on_investor_protection_and_operational_resilience.pdf

[2] https://github.com/ethereum/go-ethereum/blob/master/core/types/transaction.go#L476

[3] https://reth.rs/docs/reth/transaction_pool/trait.TransactionOrdering.html

[4] https://docs.optimism.io/stack/transactions/fees#priority-fee

[5] https://mevboost.pics/

[6] https://beaverbuild.org/

[7] https://www.titanbuilder.xyz/

[8] https://rsync-builder.xyz/

[9] https://x.com/jito_labs/status/1766228889888514501

[10] https://x.com/0xMert_/status/1799955514786234751

[11] https://swap.cow.fi/