MEV bot architecture and value extraction strategies

What MEV looks like in practice

As I already described in the article about MEV itself - in theory, a user might think that transactions on a blockchain are executed in the order they are sent. In practice, however, the order is determined by validators, builders, and the fee market. There exist:

public mempool;
private order flows;
validators;
block builders;
searchers;
relays;
an auction for priority inclusion in a block.

In other words, a regular user’s transaction is not just a request to “exchange ETH for USDC.” It is a signal to the market that can be interpreted and monetized (and many do monetize it).

This is especially visible in DEXs with an AMM model, like Uniswap-style pools. If someone is going to make a sufficiently large swap, they noticeably move the price inside the pool. And if the price can be moved, someone else can earn:

before this shift (frontrun);
immediately after it (backrun);
between two markets (different DEXs) where the price is not updated simultaneously (arbitrage);
in the case of liquidations (liquidation).

1) Backrun: positioning immediately after a large transaction

Backrun - a bot wants to execute its transaction immediately after a specific transaction.

Typical case

A user makes a large swap and moves the price in the pool. After that:

on another DEX, no one has traded this token and the price remains the same;
a short-term imbalance appears in this same pool;
an arbitrage opportunity arises.

The bot places its transaction right after someone else’s trade to capture this imbalance before everyone else.

Example

Suppose:

on DEX A, the price of ETH = 3000 USDC;
on DEX B, the price of ETH = 3002 USDC.

The difference is small and uninteresting.

But a large swap comes to DEX A, pushing the ETH price up to 3035 USDC. Now the bot can:

buy ETH on DEX B cheaper;
sell it on DEX A for more;
lock in the difference.

Important: the user created this opportunity themselves with their trade. The bot simply inserted itself immediately after it.

Why backrun is even “useful”

Because in this model, the bot usually doesn’t directly worsen the user’s entry price and doesn’t interfere with them; it doesn’t change the price like in a sandwich attack (which I will describe later). It simply brings individual market elements toward a certain equilibrium - for example, it quickly aligns prices between different platforms, creating a “fair” market price.

But from the perspective of the bot’s profit - it is still an infrastructure race. The profit goes to the one who first saw the state change and was the first (after the one being hunted/observed) to execute their transaction.

2) Frontrunning and Sandwich: playing with execution order

If Backrun is a reaction after an event, here we are talking about an attempt to influence a user’s trade by inserting oneself before and around it.

Frontrunning: positioning before someone else’s transaction

This is an attempt to insert one’s transaction before someone else’s, knowing that it will change the market state.

A bot sees a large swap in the mempool and understands: after its execution, the price in the pool will shift. This means it can try to:

buy the asset before the user;
let the user shift the price;
sell higher.

Conceptually, this looks like basic speculation, but the key point here is control over the execution order within a block.

However, in its “pure form,” frontrunning is rarer than it seems. Because:

you need to land exactly before a specific transaction;
you need to account for the user’s slippage (otherwise their trade might simply not execute);
competition for this spot in the block is very high;
the risk that you will be “outrun” yourself never disappears.

Therefore, in practice, frontrunning almost always turns into a more stable form - the sandwich.

Sandwich attack: frontrun + backrun in one construction

A sandwich attack is an evolution of the frontrun idea, where the bot doesn’t just stand before the user but wraps their trade from both sides:

buys before (front leg);
the user executes at an already worsened price;
sells after (back leg).

In other words, the user finds themselves “squeezed” between two bot transactions.

How it works

Suppose a user makes a large swap in an AMM pool.

The bot sees this transaction and understands:

if it buys first - the price will already rise slightly;
the user will still execute (if slippage allows), but at a worse price;
after this, the bot can sell back into the “heated” pool.

As a result:

the bot buys cheaper than the user;
the user buys more expensively than expected;
the bot locks in profit on the reverse sale.

In effect, the bot’s profit is formed at the expense of worsening the user’s price.

Why it works

The key mechanism here is the AMM curve and slippage:

every trade shifts the price;
the user pre-sets an allowable range (slippage tolerance);
the bot can “take” part of this range for itself.

The wider the slippage - the more room for an attack.

If a user allows 3–5%, they are essentially giving the system a range within which their trade will still execute. The bot simply uses part of this range to its advantage.

Technical complexity

Despite the simple idea, implementation requires precision:

you need to estimate how much the price can be shifted without breaking the user’s trade;
you need to correctly select the volume of front and back transactions;
you need to account for pool fees and gas;
you need to guarantee the order: front → user → back;
you need to compete with other bots doing exactly the same thing;
you need to avoid a situation where other bots can use our own bot transaction as a target for their front-run.

This is exactly why infrastructure, not the idea, is what matters here.

Why it’s harmful for the user

Because the user gets a worse price than they could have. Their trade doesn’t just execute - it becomes an object of parasitism. Formally, the protocol works as intended, but the economic result for the user is worse. Therefore, for critical and large trades, I personally recommend either using limit orders or protecting against parasitism with precise slippage specifications (minimum/maximum allowable prices).

The wider the user sets their slippage tolerance, the more room for an attack.

If a person allows 5%, the bot understands that the price can be worsened quite significantly, and the trade will still execute. In other words, the user “signs” the range in which they can be exploited.

3) Arbitrage

Arbitrage is the search for price differences between platforms and extracting profit from these differences.

In DeFi, this happens constantly because every DEX is a local liquidity curve, not a single “central order book” as on centralized exchanges. The price can differ:

between two AMMs;
between a DEX and a CEX;
between spot and derivative markets;
between different blockchains or L2s.

Basic example

If a token costs 0.99 USDC on one DEX and 1.02 USDC on another, the bot can:

buy cheaper;
sell dearer;
take the spread.

Arbitrage is the backbone of the MEV ecosystem

After a large trade, liquidation, or sandwich, the market is temporarily deformed. And someone must return prices closer to equilibrium.

This is exactly why some MEV bots are not “user hunters”, but market state rebalancing machines.

4) Liquidation: the most “legitimate” type of MEV

Liquidations often stand apart because they are needed by the lending protocols themselves, and most often, some of these bots are implemented by the protocols themselves. If a borrower provided collateral and took a debt, and the collateral price fell below the allowable threshold, someone must close part or all of the position and return stability to the system.

That “someone” becomes the liquidator bot.

How it works

In a lending protocol, there is a rule:

a position is healthy as long as the collateral ratio is above the threshold;
if the market falls and the position goes below this threshold, it becomes liquidatable;
the liquidator pays off part of the debt and receives collateral at a discount or with a bonus.

Example

A user collateralized 1 ETH and, when the price was 4000, borrowed 2000 stablecoins. ETH dropped sharply to 2300. The position’s health factor went below the threshold, and the position can now be liquidated.

A bot that monitors:

oracle/market prices,
position states,
bonus size/liquidation parameters,
competition/calculations for gas costs/inclusion in the block,

sees an opportunity. It forms a transaction in which it sends 2000 stablecoins to the lending protocol and receives 0.9 ETH from the user’s collateral (“collateral at a discount” or “liquidation bonus”). It then exchanges these 0.9 on some DEX at 2300, receiving 2070. Ultimately, it earns a profit of around 70 (not accounting for execution costs, etc.). This is a very simplified scheme, as liquidation thresholds/collateral returns, bonuses to liquidators, and the schemes themselves vary depending on the lending protocol.

Why liquidation is not exactly exploitation

Because liquidations are built into the protocol’s economy. This is not a bug or an attack in the classic sense. But it is still MEV, because the profit arises from the right to be the first executor of an event, which is available to everyone but goes to the fastest.

Where the struggle actually lies: not in strategy, but in infrastructure

If you remove the romance, almost all MEV bots run into the same engineering problems:

extremely fast reception and decoding of the transaction stream;
local simulation of execution math;
profit estimation after gas and fees;
working with multiple state sources;
resilience to reorgs and outdated data;
sending via public and private channels;
fighting competitors who have the same idea but better latency.

Therefore, developing such systems is not so much about “writing a script in some language” as it is about building an infrastructure where even a minor error in just one point from the list above can nullify “better-than-competitor” implementations of all other actions.