Cardano Ecosystem





Will we see the MEV problem on Cardano?

The term MEV stands for Miner Extractable Value. Block producers or other entities can make a profit through their ability to influence the order of transactions in a new block. Block producers have the right to include, exclude, or...

Will we see the MEV problem on Cardano?

The term MEV stands for Miner Extractable Value. Block producers or other entities can make a profit through their ability to influence the order of transactions in a new block. Block producers have the right to include, exclude, or re-order transactions within the blocks and are economically incentivized to do so. MEV is one of Ethereum's biggest problems, with over hundreds of millions of USD extracted from its users. We will explain the issue and discuss whether we can expect the same problem on Cardano.

What is MEV?

Each block producer maintains a list of unconfirmed transactions in a so-called mem-pool. Each time a user submits a new transaction, the transaction goes into the mem-pool where it waits to be added to the block. The same applies to transactions created through decentralized applications, such as exchanges. When a node gets the right to create a new block, it selects transactions from the mem-pool according to the protocol rules and inserts them into the new block. If a node receives a new block that was created by another node, it looks at the transactions in the block and can delete the same transactions in its own mem-pool. If the transactions are in a block, there is a good chance that they will subsequently be confirmed. A node may not delete transactions immediately, but after some time (after a few confirmations), because it cannot be sure if the new block will be accepted by the majority of nodes in the network and will become part of the blockchain forever. This is a general description of how nodes usually handle transactions in any blockchain network.

In an ideal world, block producers would be ignorant of and unconcerned with the meaning of transactions. They would insert them into the block fairly in the order they arrived. In the case of Ethereum, however, we are far from this ideal.

MEV is a fraudulent opportunity for block producers that allows them to maximize their profits by determining the order of transactions in a new block that is profitable for them. This includes arbitrarily reordering, including, or excluding transactions within a block at the expense of users.

An inevitable part of MEV is performed by autonomous network partakers called searchers. Searchers are operated by users that handle intricate algorithms detecting available profitable MEV opportunities. They try to understand the meaning of the transaction. For example, they know that there is a huge swap transaction on Uniswap. Based on this and other knowledge, they look for opportunities. Note that searchers are not necessarily operated by block producers. Searchers are bots that automatically submit profitable transactions to the network once they find an opportunity.

When searchers have found a secure profit opportunity, they are able to pay high gas fees. The high fee incentivizes block producers and validators to accept their proposed order of transactions. Ethereum allows users to set an arbitrarily large transaction fee. When searchers find a suitable opportunity, they are able to set a much higher fee than users. Because bots are able to find an opportunity very quickly and submit a transaction in the order of micro-seconds, their transactions skip user transactions in the mem-pool. More precisely, if block producers select transactions based on fee sizes, it is economically advantageous for them to select the transaction with the higher fee first. The fee size takes priority over the transaction delivery time.

This is called front-running. It involves keeping an eye on unconfirmed transactions in the mem-pool, looking for profitable trades, and then front-running the original transactions by submitting copies of them but with higher fees.

In other words, a profitable trade is made by the owner of the bot instead of the user. The user's transaction either fails or is economically less profitable than when the transaction was submitted. In this way, the block producer extracts economic value from the user.

A front-running example

On-chain liquidity is fragmented in many pools that do not communicate with each other. Fragmented liquidity creates the opportunity to buy low and sell high across different pools.

Imagine that a trader finds an arbitrage opportunity. He wants to buy $10 million worth of WBTC on Uniswap for $20,200 for 1 WBTC. He then wants to sell all the WBTC on Sushiswap where there is a value of $20,250 for 1 WBTC. So he has to buy the WBTC for a lower price on Uniswap and then sell it quickly at a higher price on Sushiswap. To profit from this opportunity, the trader has to submit a transaction that will wait in the mem-pool to be picked by a block producer and get executed.

The issue is that the submission of the transaction opens up a window for a front-runner bot to sweep in. The bots can analyze the content of the transaction and conclude that it makes economic sense to skip the user's transaction. While the user's transaction waits in the mem-pool to be executed, the bot quickly copies the transaction and set a higher fee. Thus, the bot's transaction will be executed before the user's transaction. This will effectively rob the trader of his arbitrage opportunity, profiting at his intellectual, monetary, and creative expense.

Unlike the traditional world, Ethereum cannot process on-chain transactions in parallel and only allows sequential processing. This means that all transactions in a block have a fixed order and this order must be maintained during validation. This provides block producers with a big power that might be misused. Even if block producers behave fairly and follow only their own economic interests bots can whenever submit transactions with a higher fee and thus influence the order of transactions in the blocks.

It is possible for bots to borrow $10M of USDC from the Aave lending pool for free, provided that the transaction returns exactly $10M USDC back to the lending pool at the end of the transaction. This is called a flash loan. This can be done by using a custom smart contract which is pre-deployed onto the chain. The owner of the bot does not even need the needed capital for the front-running attack. The bot creates a transaction that temporarily borrows the needed capital and makes both trades on Uniswap and Sushiswap. It will be an atomic operation from the network perspective.

Let us add that there are more types of attacks based on a similar principle, such as a back-run attack, sandwich attack, and others.

Will we see an MEV issue on Cardano?

The MEV problem has not yet appeared in the Cardano ecosystem. However, Cardano has no active measures to prevent MEV. In principle, nothing can prevent pool operators from quickly creating and inserting a transaction into a block while intentionally omitting another transaction. It is therefore theoretically possible to commit a front-running attack similar to Ethereum. Why hasn't this happened in practice yet?

One reason is that the Cardano protocol sets fees deterministically. If someone creates a copy of a transaction that is the same or very similar to the original, the transaction fee will be the same. Moreover, getting a transaction fee is not directly tied to the creation of a block. All transaction fees are pooled and distributed to all operators (and stakers) once every 5 days at the end of the epoch. Even if, hypothetically, the operator prefers a transaction with a high fee, it will only receive a negligible part of that fee.

As a result, it is difficult to commit MEV attacks for non-operator entities as they cannot exploit the size of the fee to enforce the re-ordering of transactions.

The high decentralization of the Cardano protocol prevents MEV attacks since only the node that is currently the slot leader can perform them. The chances that a node will find profitable MEV opportunities and at the same time be a slot leader exist, but are relatively small. As decentralization increases, the odds will decrease, so if a given pool has, say, a 1% stake, it has a similar chance of being the slot leader when it suits it.

If the pool was involved in MEV attacks, it could discourage delegates. The pool operator has to think whether an MEV attack is worthwhile, as it risks losing stakes and therefore a share of the block production. There is a good chance that if the MEV attack could be uncovered and the information publicized to the delegate community, the pool would lose influence. It turns out to be advantageous that delegates can directly economically influence the fair behavior of pool operators. They must value their delegates and not betray the ecosystem by exploiting MEV opportunities.

There would be some chance of successfully exploiting MEV opportunities if more large pool operators joined together. This would increase the chances of someone from the group becoming a slot leader at the appropriate time. I don't think this would happen in practice, but it cannot be ruled out. It is theoretically possible that pool operators would share the extracted value with delegates. The delegates would then continue to support the pool with their ADA coins and essentially participate in the fraud. If the pool operator had to share the profit with the delegates, the economic incentive would be lower for all parties involved.

The MEV attack is somewhat more complex on Cardano due to the EUTXO model and the fact that transactions are not dependent on the global state and order of transactions in the block. However, this does not provide 100% resistance to this phenomenon.

Are there any effective measures to prevent MEV attacks?

From our point of view, the anonymity of transactions could help. If the content of transactions could not be analyzed, it would not be possible to search for MEV opportunities. The content of transactions could be public only after the block is published.

Increasing parallelization of transaction processing could help, with second layers assisting. Ouroboros Leios will allow transactions to be processed essentially instantaneously upon submission, reducing the time required to analyze transactions and quickly submit competing fraudulent transactions.


The more the Cardano ecosystem is adopted by users, the more interested attackers will be in exploiting the system for their own benefit. The economic motivation may also be interesting for internal actors, i.e. pool operators. They risk a loss of trust and an outflow of stakers to another pool. It is possible that a pool operator will take a one-off risk. If an MEV attack is detected and proven, the community should respond appropriately.

MEV is certainly an interesting phenomenon for the IOG team to think about as well, as they should be thinking about how to create an effective defense. We haven't seen MEV in the Cardano ecosystem yet, which we can be happy about, but that doesn't mean we can forget about MEV. We need to talk about potential problems and look for solutions today.


NotifyLog - One stop tool for events tracking and analytics

NotifyLog is a powerful tool for events tracking and analytics. It helps you to track events from your website, mobile app, and server.CREATE YOUR FREE ACCOUNT

Read Original Article on Cexplorer



Disclaimer: Cardano Feed is a Decentralized News Aggregator that enables journalists, influencers, editors, publishers, websites and community members to share news about the Cardano Ecosystem. User must always do their own research and none of those articles are financial advices. The content is for informational purposes only and does not necessarily reflect our opinion.

NotifyLog - One stop tool for events tracking and analytics

More from Cexplorer

See more
The number of Cardano pools must never decrease
The number of Cardano pools must never decrease




Related News

See more
WingRiders Governance Token

Featured News

See more
WingRiders Governance Token

NotifyLog - One stop tool for events tracking and analytics