mev-and-mev-bots-hero

What is MEV (Maximal Extractable Value) and MEV Bots

What is MEV (Maximal Extractable Value) and MEV Bots

author & date of publication: Michal | 16.10.2025

Maximal Extractable Value – maximum value that can be extracted from block production in excess of the standard block reward and fees by including, excluding, and changing order of transactions in a block. It is important to understand how a transaction from a user gets to the blockchain. This is a simplified explanation sufficient for understanding MEV.

How a transaction lands and works in Ethereum – user sends a transaction (i.e. send ETH to someone, or swap) with information about how much gas is user willing to pay. That consists of base gas for transaction to run and tip for block builders. Higher the tip, bigger the chance that transaction will be chosen for the next block.

All those transactions from all users end up in Mempool. Block builders (validators who are selected to build/create a next block, in PoW they were miners) pick transactions to form a block. They tend to choose transactions with higher tip. Then this block is added to the blockchain. 

Searchers are users that look into Mempool and search for the transactions with the highest possible MEV. They run more or less complex algorithms transactions in Mempool and when they find suitable transaction (lets call it A), they insert their own transaction into Mempool (or directly to block builder, being explained later) and are willing to pay high gas so the validators pick their transaction together with the A. Gas fee for validators on those transactions can be as high as 100% of the searcher’s MEV.

More searchers means more competition for MEV and thus bigger profits for validators and less for MEV searchers (because they have to offer higher gas).

Searchers don’t do this manually but by using bots. Even though Ethereum block time is 12 s, it would be impossible to find profitable transactions in Mempool and then extract MEV in that timeframe manually. Even more impossible on Solana’s 400 ms blocks.

Types of MEV

Front-running

In this case searcher inserts a transaction before the user’s transaction. For example, if a user wants to buy a large amount of token A with USDC, it would move the price of token A higher (relative to USDC). Searcher sees this order in Mempool and places his own buy order for token A. Buying before a spike caused by the user’s transaction.

Back-running

In this case searcher inserts a transaction after the user’s transaction. If the user’s transaction is a buy order, searcher’s transaction would typically be a sell order. So the searcher sells his tokens for a higher price than he would otherwise sell them without the transaction that spiked the price.

Sandwich Trading

This is a combination of front-running and back-running. In our example, where the user places a large buy order for token A, the searcher inserts his own buy order for token A (front runs) user’s transaction. Buying cheap before the spike. And right after the price rises, he places a sell order to sell token A (back runs).

DEX Arbitrage

If two DEXes have the same token but at different prices, someone can buy a token on a cheaper exchange and sell it on the more expensive exchange in one, atomic transaction. This could happen if someone makes a large swap on one exchange which alters the price on this particular exchange. In that case it is a form of back running.

Censorship

This is a special category of MEV, where there are no searchers, but block builders (validator or miner in PoW) can choose not to include a transaction. For this to be effective a large number of nodes (validators or miners) need to do the same. This could be used to get MEV somewhere else by “blocking” transactions or demanding higher fees.

Liquidation

Searchers are liquidators. In borrow/lend protocols, users can borrow token B against their collateral token A. If due to the market fluctuations the value of collateral falls below liquidation threshold (value of borrowed assets compared to collateral value), borrow/lend protocol usually lets anyone to sell (liquidate) the collateral, which is then used to pay off the lenders. The borrower pays a liquidation fee which goes to the liquidator (or in most cases part of the liquidation fee). And this fee is the MEV opportunity that searchers compete for. The first one wins.

NFT MEV

Searchers might want to front-tun an NFT mint or they can buy multiple NFTs (or whole set) in one transaction.

Generalized Front Runners

Usually frontrunners (term for bots that belong to any of above categories) are specialized, meaning that they look for specific types of transaction. Like Uniswap contract or NFT mint. On the other hand, there are generalized frontrunners, those are bots that look for any profitable transaction in Mempool. They pick a transaction in Mempool, simulate the execution locally to find out if it is profitable and if it is, then front-run it by copying it and changing the addresses with their own addresses. Searchers running the generalized front-running bot don’t need to fully understand the transaction.

Toxic (Bad) and Non-Toxic (Good) MEV

Non toxic MEV doesn’t negatively impact users or blockchain. Here belong liquidations of collateral when it decreases bellow liquidation point. DEX arbitrage (back running) which takes care of different price for the same asset on different exchanges. Though non-toxic definition is not set in stone.

Toxic MEV has a negative effect on users and ecosystem. Front-running and sandwiching result in worse execution price for user (at the upper limit of the slippage). For network it causes congestion when more front runners compete for block space and that causes high gas price.

For PoW networks if the MEV available in a block exceeds block reward from mining, it is more desirable for miners to not mine the next block but instead remine past block with higher fees. That would lead to blockchain reorganization (this could most like happen during halvings).

History of MEV on Ethereum

In the early days, if a possible transaction for profitable MEV was found in Mempool (i.e. possible DEX arbitrage), MEV bots were outbidding each other on gas offered for including their transaction into the block. But when the winning transaction (highest offered gas) was included, a competing transaction was also included in the block but failed (because they were late). Thus incurring cost in form of paid gas but not being able to extract MEV. From a network perspective it meant high gas fees and network congestion for everyone else. This was later named Priority Gas Auctions.

MEV-Geth and MEV-Relay

MEV-Geth is a modification of ETH client that allows direct communication between miners and MEV searchers. Searchers could directly send bundles to the miner. Bundle is a series of transactions packaged together by searcher to maximize MEV; i.e. bundle contains all 3 transactions needed for a sandwich attack – front running transaction from a searcher, large swap transaction from Mempool and back running transaction from searcher).

MEV-Relay is a network of relays (nodes) that allow sending of these transaction bundles from MEV searchers to miners.

Miners would mix and match bundles from MEV-relay and transactions from Mempool to form a block that would get them the most fees. This helped with congestion and moved the “wild west” MEV extraction to more organized landscape.

Current State of MEV on ETH

With Merge, ETH switched from Proof of Work to Proof of Stake and miners ceased to exist, and with Proof of Stake concept of Proposer/block builder separation (PBS) was introduced. Instead of block proposer (validator who was selected to build a block for a given slot in an epoch) trying to create a block with highest possible fees by themselves, they rely on a market where third-party block builders create bundles. These bundles consist of complete block content and fee for proposers. The proposer then chooses the highest-fee bundle.

MEV-Boost is an implementation of PBS. It is a software that validators run to participate in a block-building market. Proposers can choose to build a block by themselves or accept bundles from the builders.

  • User submits a transaction via wallet. It goes through RPC to a public Mempool or private Mempools (such as Flashbots Protect, Merkle mempool , Blink mempool, CoW MEV Blocker,…).
  • Searchers scan the pending transactions in mempools and look for MEV opportunities. Then they pack them into bundles which are submitted together for inclusion in a block by builders.
  • Block builders batch the public transactions, bundles and private transactions together into a block and then send the block to relay(s).
  • Relay is the communication interface between builders and validators. Relay can connect to one or many builders and validator can connect to multiple relays.
  • Validator receives a proposed block from a relay, signs the block and proposes the signed block to PoS network for inclusion in the blockchain.

MEV-Share – is built on MEV-Boost and it unbundles the transaction supply chain even further. Where MEV-Boost is for collaboration between block builders and validators, MEV-Share enables collaboration between searchers and users.

It is (open source) protocol for users, wallets and dApps to receive part of the MEV their transaction creates. For searchers it offers a possibility to extract MEV they otherwise wouldn’t have access to. 

It creates order-flow auctions where users choose what data they want to share about their transactions with searchers who bid to include the transactions in their bundles. Users simply use Flashbots Protect RPC to participate on MEV-Share.

SUAVE (Single Unifying Auction for Value Expression) –  is still work in progress. It is an independent network (Layer 0) that can act as a plug-and-play Mempool and decentralized block builder for any blockchain (not just ethereum).

Its main purpose is to unbundle Mempool management and blockbuilding from existing blockchain runtimes. It can work for ETH L1 or L2s as well or even other blockchains.

SUAVE allows users to keep control over their transaction data and MEV and at the same time allows searchers and block builders to get the most possible MEV from cross-chain MEV opportunities. For blockchains it will offer maximally decentralized sequencing and network resilience. For validators it offers highest possible revenue from their blockspace (by virtues of transparent and competitive MEV market).

MEV on Solana

MEV on Solana works slightly differently than on Ethereum (or any other chain with Mempool). Solana has no Mempool because block proposer (called leader) is know before hand. So RPC nodes know where to send transactions for block building. This reduces possibilities for some types of MEV (i.e. front running). On Solana main problem searchers have is latency and not fees (like on Ethereum).

Liquidation – when borrower’s collateralization ratio falls below the set threshold on borrow/lend dApps (or perp trading on margin), their position is ripe for liquidation. Searchers look for these undercollateralied positions to liquidate them (partly or fully) and they receive part of the collateral as a reward.

Arbitrage – price arbitrage between DEXs, CEXs, intra-chain, cross-chain. More details are in the Ethereum section.

NFT MEV – during NFT mint searchers try to secure NFTs (possibly rare ones) for a mint price and sell them later (even 1 block later) for a profit. These types of MEV extraction caused large-scale congestion on Solana and halted temporarily Solana in late 2021.

To mitigate some of the problems with congestion during NFT mints (and other events) where the network was flooded with redundant transactions, Solana introduced optional priority fees. It gave users a way to land their transactions during high activity period by paying priority fees and at the same time discouraged flooding the network by searchers/bots with cheap transactions without priority fees (or made flooding more expensive).

Jito – is an out-of-protocol blockspace auction for partial blocks. For comparison, MEV-Boost on Ethereum is a blockspace auction for full blocks. Jito bundles are slightly similar to bundles in MEV-Geth). Jito bundles are executed sequentially and atomically , meaning that all transactions in a bundle are executed and that specific order or none. Searchers submit bundles with a Jito tip and if they win the auction, their bundle is included in the block. If more validators (by stake) are running Jito-client, more slots are available to searchers to submit their bundles.

How does Jito client work?

  • Incoming transaction – transactions from RPCs, other validators,…
  • Relayer – relayer on Solana has a different function than relayer on Ethereum. On Solana relayers do packet deduplication, signature verification and relay the transaction to Block engine and validator (leader).
  • Block engine – runs off-chain blockspace auctions and simulates transactions. MEV-maximizing bundles are sent to the leader (leader must use Jito-client therefore more validators use Jito, more blocks are available for bundle inclusion).
  • Searchers – users/bots that use sources like private Mempools or Jito’s Shreadstream to find MEV opportunities. 
  • Validator – produce blocks (as in blockchain).

Front-running – due to the lack of built in Mempool, front running is not as straight forward as on Ethereum. But with the creation of Jito validator client there was at the time Jito Mempool which offered searchers a 200 ms window when they could search transactions in the Mempool and if they found a profitable MEV opportunity, they could execute front-running transaction (or even sandwich attacks). Jito closed their Mempool in March 2024.

This lead to the emergence of private Mempools. Profitably running a Mempool is not easy as it requires a large amount of stake on validators that use this Mempool. It could be one with a huge stake, a lot of validators with a small stake or combination. Validators that use private Mempools are running Jito-client but set the realtor address to point to Mempool.

Ways How to Mitigate MEV

Low slippage  users can set slippage to a low value, decreasing potential MEV profit. This approach is not user friendly as illiquid tokens require different slippage than liquid ones.

Higher gas – the idea behind using higher gas fees to mitigate MEV is to make these exploitative transactions economically unviable

Dynamic slippage – offered by Jupiter Aggregator is an algorithm that takes into account different variables (such as current market conditions, whether token is liquid or not, route chosen for the swap,…) and sets the slippage to the lowest possible setting for the trade to succeed. Downside is slightly higher fees.

RFQ systems – Request for Quote systems (i.e. Hashflow) are used instead of on-chain AMM or orderbooks. Trades are fulfilled by professional market makers. Example of dApp using RFQ is Kamino Swap or Matcha.xyz, Downside is that they are very good at high liquidity tokens that exist also on CEXs. Less effective on low liquidity tokens. And low liquidity, new tokens are the place where the most MEV opportunities are.

Paladin – is a modified Jito client for Solana validators that offers P3 port (Paladin Priority Port) to receive transactions during the bundling stage. Users can send transactions to P3 when a leader runs paladin client. They include extra fee that ensures that validator will include these transactions in a bundle in the order they are received. Paladin validator client also searches for sandwich attacks in incoming transactions and rejects them.

zkAMM – novel approach of zero knowledge proofs to keep the intent of the trade secret until after the execution. So front-running is not possible as the searcher does not see the trade user wants to make. It works like traditional AMM with added MEV protection. Example is Darklake.fi.

sr-AMM – experimental design of AMM where no swaps are executed at a price more favourable than the pool’s price at the start of the slot. That means that profitability of sandwich attack is zero. However, sandwiching is still possible between the slots (front run with the user transaction in slot N and backrun in N+1).

As a user, the easiest is using DEXes that offer some kind of MEV protection, i.e. Kamino Swap using RFQ, Matcha using RFQ, 1inch Fusion using dutch auction system for whitelisted MM, Renegade.fi (order book with MPC matching), Jupiter (by sending transactions with Jito tip or using RFQ),…