Does MEV fall within scope of MiCA’s Market Abuse provisions?

This article was co-authored by Jonathan Galea, CEO at BCAS, and Vincenzo Furcillo, Senior Research Associate at BCAS.

With a lot having been unpacked about the Markets in Crypto Assets Regulation[1] (MiCA), and a ton more left to be unpacked, it is clearly emerging that this is the most extensive regulatory effort to date in relation to crypto-assets. It stands to reason that the more prescriptive a legislative instrument is, the more coverage there is, often with intended and unintended consequences. Something which may fall under the latter is Title VI (Prevention and Prohibition of Market Abuse Involving Crypto-Assets) and the effect it might have on participants pursuing Maximal Extractable Value (MEV). In particular, the article which is causing some debate is Article 92; however, before we delve further into the heart of the matter, it is best to start off with a comprehensive explanation about MEV and its implications, with the focus being on the Ethereum blockchain.

MEV 101

Introduction

MEV is the Maximal Extractable Value a blockchain miner or validator can obtain by reordering, censoring, or introducing its own transactions during the block production process. In other words, MEV refers to the maximum value that can be extracted from block production in excess of the standard block reward and gas fees.

Initially introduced within the context of proof-of-work (PoW), this concept was initially labelled as “miner extractable value”, owing to miners’ authority over transaction incorporation, omission, and sequencing. With Ethereum’s migration to proof-of-stake (PoS), these responsibilities have transitioned to validators, rendering mining obsolete within the Ethereum protocol. Nevertheless, the mechanisms for extracting value persist, prompting the adoption of the term "maximal extractable value" to better capture this phenomenon.

MEV Explained

The Ethereum yellow paper[2] does not specify how transactions should be ordered in a block. Therefore, in theory, it is up to the validator to decide what criteria to use during block production. In practice, the most popular (execution layer) implementation software, Geth, prioritises transactions based on gas price, nonce and transaction age (where older transactions are preferred over new ones, all other things equal).[3]

Figure 1- Standard Transaction Ordering. Source: Author

Figure 1 - Standard Transaction Ordering. Source: Author

The transaction with the highest fee would therefore be included first in a block (see figure 1), and for equal paying transactions, the transaction received first by the validator would take priority. In this basic scenario, validators take a passive role, simply collecting transactions and aggregating them into a block following predefined rules. However, validators can also choose to take a more active role in their block producing activities. Should they decide to leverage their position in the ecosystem, validators face the prospect of collecting incremental rewards by engaging in MEV-related activities.

Within a blockchain ecosystem, distinct roles such as users, attesting nodes, and block-producing nodes give rise to an inherent information flow asymmetry. Validators, as the gatekeepers of block production, have the ultimate say on what transactions are included and in what order. In the context of MEV, validating nodes can leverage their position as block producers to extract value, such as front/back running users pending transactions and pocket arbitrage profits. This can be achieved by adding transactions of their own in the block they are set to produce, for instance, by buying an asset before a large user buy order transaction set to increase the price, or vice versa by selling before a large sell order. This frontrunning strategy is just an example of MEV strategies employed by validators. Other examples include ordering optimization (OO) fees, fee-based forking attacks, and time-bandit attacks[4], as well as arbitrages, liquidations, sandwich attacks [5]and cross domain MEV.[6]

MEV-Induced Threats

Traders on decentralized exchanges (DEXs) are often the most vulnerable to front-running attacks. These attacks mean they get worse prices for their trades, instead of being fairly rewarded for their role in price discovery. On the other hand, front running entities take profits from traders reaping nearly risk-free gains, without contributing value to the ecosystem. A clear instance of this dynamic is seen in arbitrage transactions leveraging price disparities of the same asset across different DEX platforms. In such scenarios, front runners frequently mimic transactions of other traders and execute them first, receiving the trade profits in lieu of the original trader.

Besides traders and exchanges, rewards distribution and auctions can also be affected. Systems where decisions are made by voting, such as DAO governance systems in Ethereum, are also vulnerable to front running. DEX arbitrage and priority gas auctions (PGAs) may not seem immediately harmful or relevant to the security of an underlying blockchain, but research has shown that they present a serious security risk to the blockchain systems on which they operate, i.e., at the Consensus Layer.[7] Moreover, MEV creates an incentive for block producers to vertically integrate with trading firms to boost their returns. Should this issue not be addressed, it would be a centralizing force in Ethereum. As a response, the Ethereum community is working on a solution called Proposer-Builder Separation (PBS)[8], which will allow validators to outsource the difficult building of blocks to specialized parties called block builders.[9]

MEV-Boost and Other Stakeholders

The concept of separating proposers and builders holds the potential to mitigate the impact of MEV extraction. However, its actual implementation necessitates adjustments to the consensus protocol itself (i.e., changes to the fork choice rule on the Beacon Chain), which take time to properly design, implement and test. As a temporary measure, the Builder API steps in as a provisional solution, providing functional implementation of the proposer-builder separation principle, although with higher trust assumptions.

An example implementation of the Builder API is MEV-Boost. Over 90%[10] of blocks on Ethereum are built via MEV-Boost, an off-protocol software enabling proposers to access blocks from a builder marketplace. Builders participate in MEV-Boost auctions, wherein they present blocks and bids to trusted entities referred to as Relays (e.g., Flashbots, BloxRoute, Ultra Sound). Relays can connect to one or many builders, and a relay connecting to many builders will aggregate builders’ bids. These bids quantify the amount that a builder is prepared to remunerate the block proposer in exchange for the right to construct a particular block. The bid amount primarily hinges on the value derived from the blockExecutionPayload, factoring in the builder's desired profit margin, and accounting for the discrepancy between the two highest bidders. The auction concludes when the block proposer validator elects a block and commits to it, along with the corresponding bid. This auction cycle is repeated for each block proposed through MEV-Boost.[11]

In principle, existing Ethereum validators should capture the entirety of MEV, given their role as the arbiters of block creation within the network. However, with the emergence of advancements like MEV-Boost and PBS, a fresh array of stakeholders, namely Builders and Searchers, have entered the equation.

Figure 2- Block Building process in MEV-Boost. Source: Author

Searchers employ intricate algorithms that analyse publicly accessible blockchain data residing in transaction mempools. Their objective is to discern advantageous MEV prospects, and subsequently, employing automated bots to submit profitable transactions to the network. Searchers find profitable MEV transactions for inclusion in blocks, but a new class of specialized parties, called builders, are responsible for aggregating transactions and bundles into blocks. A builder accepts sealed-price bids from searchers, and then runs optimizations to find the most profitable ordering.

In this process, validators continue to process transactions submitted by these automated agents, thereby securing a share of the MEV bounty. This is facilitated by the willingness of searchers to allocate high gas fees, thereby increasing the likelihood of their transactions achieving inclusion within a block.

Benefits of PBS Solutions

The core benefit of the Builder API lies in its potential to democratize access to MEV opportunities. The utilization of commit-reveal schemes eradicates the need for trust assumptions and effectively lowers the barriers to entry for validators who seek to leverage MEV benefits. This shift is poised to alleviate the reliance on large staking pools for individual stakers, who often join such pools to enhance their MEV profits. A wide-ranging integration of the Builder API is poised to cultivate heightened competition among block builders, consequently bolstering the network's resilience against censorship. As validators evaluate bids originating from diverse builders, any attempts by a builder to censor user transactions necessitate outbidding all other non-censoring counterparts. Consequently, the escalating cost of censorship acts as a potent deterrent for censorship-prone actors.

In the future, the PBS will be formally integrated into the Ethereum protocol itself, further enhancing its trust model. If implemented successfully, PBS will reduce the impact of MEV induced payoffs on validators incentives, make MEV extraction losses negligible for honest users, and making profits due to MEV extraction minimal for unethical users.[12]

While PBS is well-advanced in terms of research, pivotal design considerations remain to be addressed prior to its prospective incorporation into Ethereum clients. As of now, a finalized specification for PBS is yet to be established, indicating that its actual implementation is likely to be a year or more away.[13]

With the concept of MEV clearly laid out and explained, we shall now move on to the legal aspect, that is whether participants throughout the MEV process potentially fall within scope of MiCA’s market abuse provisions. It is perhaps safe to assume that the legislators, while drafting MiCA, only had in mind transaction validation mechanisms at their most basic, with the use of the term ‘validators’ covering multiple functions ranging from transaction propagating to block signing. However, while PBS has not yet been implemented on Ethereum, it is clear that MEV-Boost has garnered widespread support and usage, and can be called a quasi-implementation of PBS, with the main difference being that PBS will serve to move the role of relays to the protocol itself.

Therefore, the second half of this article will assume that validators on Ethereum are not singular persons carrying out the various stages of transaction validation alone, but rather validation consists of a set of functionaries working together to validate transactions. Validators as well as Builders, Searchers and Relays will collectively be referred throughout as ‘MEV Operators’, while reference to individual functionaries may still be used where it is worth pointing out certain salient differences.

MiCA and the Market Abuse Provisions

Article 92 and the ‘arranging’ conundrum

Title VI starts off with Article 86 explaining the scope of the rules on market abuse, with the same Article stating the following:

This Title shall apply to acts carried out by any person concerning crypto-assets that are admitted to trading or in respect of which a request for admission to trading has been made.
This Title shall also apply to any transaction, order or behaviour concerning crypto-assets as referred to in paragraph 1, irrespective of whether such transaction, order or behaviour takes place on a trading platform.
This Title shall apply to actions and omissions, in the Union and in third countries, concerning crypto-assets as referred to in paragraph 1.

The applicability of Title VI extends beyond crypto-asset issuers and service providers, and covers “any person”, irrespective of their status, function, or geographical location. Title VI is intended to cover the widest spectrum of persons possible, and the only qualification is that the acts concerned are committed in relation to “crypto-assets that are admitted to trading [on a trading platform] or in respect of which a request for admission to trading has been made”; the legislator also clarifies that it is immaterial whether such acts, namely a transaction, order or behaviour takes place on a trading platform or not.

The one Article which has been highlighted by legal specialists and commenters, however, is Article 92, which tackles the prevention and detection of market abuse, and states the following under sub-article 1:

Any person professionally arranging or executing transactions in crypto-assets shall have in place effective arrangements, systems and procedures to prevent and detect market abuse. That person shall be subject to the rules of notification of the Member State where it is registered or has its head office or, in the case of a branch, the Member State where the branch is situated, and shall without delay report to the competent authority of that Member State any reasonable suspicion regarding an order or transaction, including any cancellation or modification thereof, and other aspects of the functioning of the distributed ledger technology such as the consensus mechanism, where there might exist circumstances indicating that market abuse has been committed, is being committed or is likely to be committed. [emphasis added by authors]

Persons arranging transactions in crypto-assets is to be construed as referring to persons which are offering the reception and transmission of orders for crypto-assets on behalf of clients as a service[14]. Similarly, the term ‘executing’ transactions is easy to understand in light of the crypto-asset service termed as ‘execution of orders for crypto-assets on behalf of clients’[15]. Further affirmation of this can be found in the Market Abuse Regulation, which defines a ‘person professionally arranging or execution transactions’ as:

A person professionally engaged in the reception and transmission of orders for, or in the execution of transactions in, financial instruments[16]

It is evident, therefore, that while Article 92, when read at a prima facie level, seems to capture any persons irrespective of whether they are issuers, offerors, or crypto-asset service providers (CASPs), a closer and more pragmatic read sufficiently leads to the conclusion that Article 92 is referring to persons professionally engaged in the reception and transmission of orders, or in the execution of transactions in crypto-assets, ergo CASPs. This is further detailed in the next section.

MiCA’s wider and original scope – Article 2

When in doubt, zoom out… or take a look at the scope & fundamental definitions of a legislative act. Article 2(1) of MiCA states:

This Regulation applies to natural and legal persons and certain other undertakings that are engaged in the issuance, offer to the public and admission to trading of crypto-assets or that provide services related to crypto- assets in the Union.

MiCA, therefore, has within its sights persons that issue, offer to the public, or seek admit to trading crypto-assets that are not excluded from MiCA, or that provide services related to crypto-assets within the Union. The provision of services must be on a professional basis, and the person providing such services must be doing so by way of his/her occupation or business[17]. The professional element is present both in the definition of a CASP as well as in Article 92, meaning that it can be safely assumed that if the arranging or execution of transactions is not being carried out professionally, then it does not fall within scope of Article 92. Therefore, this is to be interpreted as applicable only to CASPs.

Who can be a Crypto-Asset Service Provider (CASP)?

A CASP under MiCA is defined as follows:

‘Crypto-asset service provider’ means legal person or other undertaking whose occupation or business is the provision of one or more crypto-asset services to third parties on a professional basis, and are allowed to provide crypto-asset services in accordance with Article 53[18] [emphasis added by authors]

The phrase “on a professional basis” has been highlighted as it is emphasised in Recital 21, which states that “any person that provides such crypto-asset services on a professional basis should be considered as a ‘crypto-asset service provider’”. This is further emphasised in the CASP definition which states such services are provided by way of exercising an occupation or business, reasonably excluding those who provide services on a non-professional basis as well as outside their main occupation. However, contrary to certain opinions, it does not exclude natural persons; rather, being a legal person or other undertaking is a sine qua non requirement to offer crypto-asset services. This theory is supported by Article 2(1), which states that MiCA “applies to natural, legal persons and other undertakings and the activities and services performed”.

Speaking of undertakings, it is an important term to examine, as it determines whether the provision of services by non-profit entities is excluded or not for example. In the case Ministero dell’Economia e delle Finanze v Cassa di Risparmio di Firenze SpA and Others (decided on 10 January 2006), the European Court of Justice stated that the concept of undertaking “covers any entity engaged in an economic activity, regardless of its legal status and the way in which it is financed”. Moreover, in the case Motosykletistiki Omospondia Ellados NPID (MOTOE) v Elliniko Dimosio (decided on 1 July 2008), the ECJ stated that “the fact that the offer of goods or services is made on a not-for-profit basis does not prevent the entity which carries out those operations on the market from being considered an undertaking, since that offer exists in competition with that of other operators which do seek to make a profit”. Finally, in the case Congregación de Escuelas Pías Provincia Betania v Ayuntamiento de Getafe (decided 27 June 2017), the ECJ stated that “Services normally provided for remuneration are services that may be classified as ‘economic activities’”. Therefore, it is clear enough that the term ‘undertakings’ should be interpreted widely, and covers entities such as non-profit foundations, as long as some form of remuneration is being paid in return for the provision of services.

With CASPs being defined in such a manner that establishes a very low threshold to satisfy, it is logical to look at the definition and nature of the various crypto-asset services within MiCA’s scope, including any particular exemptions applicable in their regard.

The exclusion relating to validators, nodes or miners

Recital 93 speaks about the provision of transfer services, stating that such can be offered by an entity that provides for the transfer, on behalf of a client, of crypto-assets from one distributed ledger address or account to another. It further goes on to state that:

Such transfer service should not include the validators, nodes or miners that might be part of confirming a transaction and updating the state of the underlying distributed ledger. [emphasis added by authors]

This particular Recital is often misconstrued as a carte-blanche exclusion from MiCA for validators, nodes or miners, which unfortunately is not the case. The exclusion is solely in relation to the provision of transfer services, which must be performed on behalf of a client, and is qualified further in that the actions that are ‘excluded’ are those which might be part of the confirmation process of a transaction and updating the state of the underlying distributed ledger.

What is noteworthy is that MEV Operators are, in fact, collectively updating the state of the underlying distributed ledger. This can, in turn, be used as argumentative leverage to state that in their pursuit of maximal value extraction, they are ultimately primarily performing the various respective functions of searching, collecting, relaying, and validating transactions and updating the state of Ethereum’s blockchain; no single function (save for relaying) can be eliminated from this whole process, as otherwise there would be no block validation in the first place. These various functions can be either separately carried by individual persons, or collectively by one, but each function is crucial, or at the very least important, for block validation to subsist. Searchers are required in order to locate and identify the most economically advantageous transactions for Builders, with the whole MEV-Boost process being based upon searching activities; Builders are responsible for aggregating transactions and bundles into blocks; Validators are needed as the persons ultimately signing off a block and including it into the chain. Arguably, the only function which is not strictly necessary is that of relaying; Relayers, at this moment in time, play an important role by preventing validators from prejudicing builders and front-running them, but with the implementation of PBS, Relayers will become obsolete.

To summarise the paragraph above, ‘validators’ (in the generic sense of the word) on Ethereum can be seen as a group of persons/operators working in tandem to execute the task of transaction validation, at least through the implementation of MEV-Boost and, in the future, PBS. Without the use of MEV-Boost, validators may simply be a singular person performing all the mentioned functions required to validate transactions. It can therefore be concluded that MEV Operators generally tend to, at the very least, be classified as nodes, with most of the individual functionaries being also potentially classified as validators, in turn leading to them being excluded from being seen as offering a transfer service thanks to Recital 93. The only possible exception when it comes to classification as a ‘node’ relates to searchers, which are not required to hold a complete or partial replica of records of transactions on a distributed ledger[19] as they may operate with just a block snapshot; it is therefore recommended that, where possible, searchers hold a complete or partial replica of records on a distributed ledger in order to qualify as a node. However, a searcher’s role is an essential element of the validation process, meaning that even if they do not qualify as nodes, they would arguably qualify as validators.

Naturally, singular validators carrying out all the pertinent functions of searching, building and validating on their own are likewise excluded.

What is also of material relevance and importance is that Recital 93, and the definition of a CASP for that matter, highlight the essential element of providing the service on behalf of a client. Indeed, in order for the provision of a service to be deemed as professional, it must be performed or offered to a client, and for there to be a service provider – client relationship, there must be an agreement. This leads us to the next section which will delve into the argument of why, in our opinion, Article 92 generally also is likely to exclude MEV Operators on the basis that there is no service provider – client relationship being established.

Professionally arranging or executing transactions

Under this section, we’ll start off by first tackling the service of execution of orders for crypto-assets on behalf of clients. Validators, nodes or miners do not execute transactions, and neither do MEV Operators; they are responsible for technically selecting and bundling transactions into blocks, relaying them and signing them off for validation and subsequent inclusion in the underlying chain, as the case may be with respect to the role in question. Therefore, it is safe to conclude that since Article 92 is referring to CASPs offering the mentioned service, often referred to as ‘brokerage’, then MEV Operators are out of scope in relation to this particular crypto-asset service.

To elaborate further: for this service to be provided, there must be clients that have engaged for the provision of this service to them. Indeed, the client’s consent is required in relation to the order execution policy amongst other things, and any changes thereto must be accepted by the client[20]. This corroborates the theory that in order for one to professionally provide a service, one must have a client in the first place. Without a brokerage agreement that includes an execution policy, and without a client, the service of execution of orders for crypto-assets on behalf of clients does not subsist.

Likewise, when a person arranges transactions, a person must have a client in order for it to be deemed as professionally arranging transactions, as required under Article 92. It stands to reason that unless a person has a client, then that person is not acting in a ‘professional’ capacity, as would be the case if the person is acting solely for his/her own interests, and furthermore, without there being any form of contractual arrangement that can amount to a service provider - client relationship, irrespectively of whether the service provider qualifies as a CASP or not.

Generally speaking, MEV Operators on Ethereum do not have a contractual relationship with users transacting on Ethereum, and therefore such users can certainly not be deemed to constitute clients in the proper sense of the word. While users do pay transaction fees, in the form of gas, for their transactions which are submitted to the Ethereum network, this on its own is not sufficient for a service provider – client relationship to be established.

Neither the service providers (for lack of a better term) nor the clients can be easily identified due to the decentralised nature of Ethereum’s blockchain network, with the suppliers being the MEV Operators. MEV Operators cannot choose or identify their users, and while users can selectively choose searchers or searcher-builders, these functionaries are only part of the validation process. Their function is a limited one in that they select the most economically advantageous transactions for the builders, and this restriction on their function severely limits the capacity in which they can be seen as partaking in a service provider – client relationship; in other words, the searcher’s best interest is to submit an economically advantageous set of transactions to the builder, without taking into consideration the interests of the user submitting the transaction.

Even if a person undertakes both the searching and building function itself, it will continue to seek the most economically advantageous outcome in then having the block relayed to the validator, as otherwise it would risk having its proposed block rejected for a more advantageous one relayed by a different builder. This goes against the very essence of the provision of crypto-asset services which must retain the best interests of the client at the forefront, as stipulated in Article 66.

While whether the existence of a contractual relationship or not ultimately shall depend on the applicable law of a country with jurisdiction, general principles of contract law state that, as a fundamental minimum, the parties to a contract must be identified, something which is not easily possible, if at all, in this kind of scenario. Secondly, for a service provider – client relationship to exist as structured under MiCA, the service provider must act in the best interests of the client, and if the client were to be hypothetically assumed as the user submitting transactions on Ethereum, then that certainly cannot subsist since MEV Operators have differently aligned economic incentives.

The exception on decentralised finance (DeFi)

For those who have read some of our blog posts, by now you will appreciate that one of our favourite topics is DeFi, and it would be amiss not to make reference to it in this article as well. Recital 22 states that MiCA applies to CASPs and natural/legal persons involved with or in such CASPs, including when part of such activities or services is performed in a decentralised manner. The Recital famously goes on to state that:

Where crypto-asset services are provided in a fully decentralised manner without any intermediary, they should not fall within the scope of this Regulation.

While the Recital talks about the provision of crypto-asset services rather than the constitution of DLT networks per se, inevitably in order for services to be deemed as being provided in a fully decentralised manner without any intermediary, then the underlying DLT network must itself also be seen as being decentralised and operating without any intermediary. This necessitates the involvement of validators, nodes or miners, which are rightly excluded from being classified as CASPs offering transfer services under Recital 93. However, it can further be argued that validators are essential in forming a DLT network, and that including them within scope of any provisions under MiCA, be it in a professional capacity or otherwise, would go against the spirit of the law, namely Recital 22 that excludes the provision of crypto-asset services in a fully decentralised manner without any intermediary.

Indeed, the implementation of PBS will serve to further decentralise the transaction validation process on Ethereum, and penalising any of the newly-created roles would run counter to the spirit of the law which ‘rewards’ efforts of decentralisation in that it excludes them from the scope of MiCA. On the same note, it would fly in the face of technical reason and possibilities to impose upon validators the requirement to have in place effective arrangements, systems and procedures to prevent and detect market abuse, since such would go against the very nature of decentralised and distributed DLT networks. Certainly, prevention of market abuse would be an obligation that is futile to meet, since even if it were possible to implement, an omitted transaction by one validator will simply be picked up by another one.

Conclusion

It is safe to conclude, with sufficient reasons and argumentations as laid out above, that Article 92 of MiCA does not appear to capture MEV and/or persons involved in activities that constitute MEV. Naturally, the thesis laid out above is based on the main text itself, and subject to change depending on the content of the Regulatory Technical Standards issued by the EBA & ESMA. However, any attempt to include validators within scope of MiCA’s market abuse provisions would go against both the spirit of the law as well as the technical nature of blockchain networks, meaning that it is highly unlikely that the thesis laid out herein will be challenged to the contrary.

Nevertheless, it is important to underline the need to ensure that a person, whenever carrying out any form of activity in relation to crypto-assets, is not undertaking such in a form that meets the criteria for qualification as a CASP, and if that is the case, to ensure that at the very least, the activity being undertaken falls under one of the exemptions afforded in MiCA. The provision of a service in a centralised manner and a professional capacity by way of an occupation or business is an almost sure-fire way to be categorised as a CASP offering crypto-asset services, and therefore, while removing centralisation may not always be possible, at the very least eliminating incentives or factors that may lead to a service provider – client relationship would go a long way towards reducing the possibility of falling within scope of MiCA.

[1] Regulation EU 2023/1114

[2] https://ethereum.github.io/yellowpaper/paper.pdf

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

[4] https://arxiv.org/pdf/1904.05234.pdf

[5] https://arxiv.org/pdf/2101.05511.pdf

[6] https://arxiv.org/pdf/2112.01472.pdf

[7] https://arxiv.org/pdf/1904.05234.pdf

[8] https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance

[9] https://writings.flashbots.net/why-run-mevboost/

[10] https://mevboost.pics/

[11] https://ethresear.ch/t/empirical-analysis-of-builders-behavioral-profiles-bbps/16327

[12] https://notes.ethereum.org/@RMFhKOrSSEWxmqjZMOT1Ag/rJb_cq8Co