This post is also available in:
简体中文 (Chinese (Simplified)) 
Français (French) 
Deutsch (German) 
日本語 (Japanese) 
Русский (Russian) 
Español (Spanish)
Expanding on our first myth, its important to get a better understanding of “MEV” or “Miner Extractable Value”
A lot of fear mongering suggests that MEV means that blockchain miners are dangerous, manipulative middlemen who can modify your transactions, and that simply isn’t the case.
This uninformed rhetoric mostly stems from a type of attack called a “Sandwich Attack” that miners can perform when processing poorly constructed transactions.
To understand how that takes place, and the limitations of a MEV attack, we have to first have an overview of how blockchain transactions take place.
When we create a transaction on a blockchain, all we are doing is writing out a set of instructions for a system to carry out. Like any computer system this has the pros and cons that the computer will do what we tell it to do, and only what we tell it to do – regardless of the outcome being good or bad.
We sign that transaction with our private key, which makes it tamperproof and then we broadcast it to the network, for miners to process that transaction (by changing the state in the blockchains underlying records) where that change then sits in the public record.
You can think of this process a bit like writing a letter and sealing it with a wax seal. Inside the letter are a set of instructions you want your bank to carry out. The miners are like a postal service carrying the letter to the bank.
But, it does get a bit more complicated than that.
Once you’ve signed your letter, it sits in a pile with all the other letters. We call this place ‘the mempool’ and it is where transactions sit while they are waiting to be processed. The mempool is public and so anyone can see the transactions that are waiting there, the contents of the transaction and how much gas is being bid to execute that transaction.
Miners also aren’t just one unified entity. They are actually thousands of different users and hundreds of different collectives of miners. You can think of this like different shipping companies.
People claim a miner can censor your transaction from the blockchain, and that’s not true. Just like UPS can’t unilaterally decide to censor you from being able to send mail. But UPS does have the right to decide that the mail you are trying to send is something they don’t want to ship, or that the price isn’t good enough, and so you’d have to go with another provider. That’s fair and well within their rights.
Once you manage to select a shipping company and get them to take your transaction, then the process is the same. The letter gets sent, and the action in the letter gets taken.
Where this becomes a challenge (in the ‘Sandwich Attack’) we mentioned earlier, is that individual miners can decide to read your letter and ‘frontrun’ your action.
Imagine you were sending a letter to the bank, and you said “I want my bank to buy me $1M worth of gold at the current price, regardless of what that price is.” any mail carrier reading that would realize that since you aren’t putting in a set price, and because your purchase is so big, if they bought a bit of gold at the current price before your instructions arrived, then you’d be buying it off them at a higher price. This means your transaction would go through, and they would still make a profit.
This is part of the trade-off in a public, decentralized system. When things are on a public ledger, we have to change our behaviors.
Now in this case, your instructions didn’t change. In fact, your instructions were executed exactly the way you wrote them.
The problem is you gave bad instructions.
If you said “I want to buy $1M of gold at the current price of $x,xxx and not any higher” then the transaction wouldn’t have been front-run.
If you sent 100 separate letters saying “I want to buy $10,000 of gold at the current price, regardless of that price.” then none of the individual transactions would have seemed large enough to frontrun.
But, you put through a large order, all at once, regardless of the price into a public mempool and that’s what created the issue.
This isn’t something new, it actually exists in our current financial system. It’s called “High Frequency Trading” (HFT).
When you send a transaction to your bank asking them to purchase a certain stock on the stock market for you, they have to relay that transaction to the stock market. The relay of that transaction is something that can actually be seen by other trading firms. When they see you attempting to make a purchase of a stock, they instead purchase the stock fractions of a second before you and turn around to sell you that stock at a slightly higher price.
While this action is manipulative and predatory, it doesn’t make them financial intermediaries and doesn’t let them change the transaction.
These manipulations are a lack of user education and not adapting behavior to a new type of system with public visibility.
To recap, even in a MEV sandwich attack my transaction still does exactly what I told the system to do. It cannot be changed or edited. It cannot be modified. It cannot be censored.
If one service provider denies me because my payment was too low, another will pick it up.
The only thing that changes is the outside market conditions, not my transaction.
The “exploit” takes place because of how I formed my transaction instructions.
This is something that can be fixed and avoided with better user education, clear indicators on front-ends that highlight the risk, and using MEV proof systems.
It is possible to send tens of thousands of transactions, with tens of millions of dollars in trades, and not ever have a loss due to MEV manipulation.
MEV does exist, but the technology itself is not specifically good or bad; and while it creates competitive race conditions, miners cannot ever change your transaction. They can only take advantage of poorly formed transactions, methods and approaches.
MEV does not create a new problem. It only highlights one that is already there, users making bad transactions.