MEV and front-running - who earns from transaction order and how

Transactions are not executed "in queue order". Whoever assembles the block decides which transactions to include and in what order. When money depends on the order, a market emerges: MEV (maximal extractable value) - the profit that can be gained by controlling transaction order. To understand it you need to know how a transaction gets into a block (anatomy of a transaction).

Where MEV lives

A submitted transaction lands in the mempool - a public "waiting room" where everyone sees it. Specialised bots - searchers - scan the mempool for profit: they simulate transactions and look for ones before or after which they can insert their own at a profit.

The main kinds of MEV

Arbitrage

A token's price differs on two exchanges. A bot buys cheaper and immediately sells dearer. This is a useful form: it evens out prices between markets.

Liquidations

In lending protocols under-collateralised positions are liquidated for a reward (DeFi). Bots compete to be first to call the liquidation. Also useful: the protocol stays solvent.

Front-running

A bot sees your profitable transaction and sends its own ahead of it with a higher price, taking the opportunity.

The sandwich attack

The most unpleasant for users: a bot "squeezes" your purchase between two of its own.

An example on an x·y = k pool. The pool holds 1,000 ETH and 2,000,000 USDC. You want to buy 10 ETH.

• Without an attack: you would pay about 20,202 USDC (≈ 2,020 per ETH).
• The bot sees your transaction and buys 20 ETH before you (paying ≈ 40,816 USDC). The pool's price rises.
• Your purchase of 10 ETH now costs ≈ 21,039 USDC (≈ 2,104 per ETH).
• Right after you the bot sells its 20 ETH back and receives ≈ 41,654 USDC.

The bot's profit is ≈ 837 USDC, and you overpaid the same amount. The defence is a slippage limit in the swap settings (what slippage is): if the price turns out worse than allowed, the transaction reverts.

Back-running

A transaction is inserted right after yours to exploit its effect (for example arbitrage after a large swap).

Who takes part: the block supply chain

After the move to Proof of Stake most validators use PBS (proposer-builder separation), implemented through MEV-Boost:

1. Searchers send bundles of transactions promising a payment.
2. Builders assemble the most profitable blocks from them.
3. Relays pass the best blocks to validators.
4. The proposer (validator) picks the most profitable block and signs it.

As a side effect this system creates competition and a "bidding race": a significant share of MEV goes to validators. It also concentrates block building among a few players, which provokes debates about censorship.

How to protect yourself

1. Limit slippage. Do not set 10-50% "to make it go through".
2. Use private channels. A private RPC (for example Flashbots Protect) sends the transaction to builders, bypassing the public mempool. A sandwich is impossible if the bot cannot see the transaction.
3. Split large swaps into parts or use venues with batch auctions.
4. Commit-reveal schemes. First a hash of the intent is fixed, then revealed (hash commitments).
5. Check conditions before signing. The wallet window shows the minimum acceptable result.

MEV and escrow

Coin-Trust has no token swap and no prices on which a user could be "squeezed", so sandwiches do not apply. Still, transaction order matters.

Scenario: a race at the end of the term. The performance term has expired. The buyer sends claimExpired (close with a refund) and the seller sends openDispute (open a dispute). Both transactions land in one block. Whichever executes first is the one that works: if the dispute went first, the second call is rejected because the deal is no longer Active (lifecycle).

The practical conclusion: do not leave actions to the last second. A seller who wants to protect their position should open a dispute early, with a margin, not in the block where the term expires.

What is not a threat. If someone sees your acceptOffer transaction in the mempool, there is nothing to steal: only the named counterparty can accept an offer, and payouts go to addresses set in advance (access control).

An overview: good or bad

MEV is not one-sided. Arbitrage and liquidations are useful to markets. Sandwiches and front-running are direct harm to users. Researchers work on solutions: encrypted mempools, batch auctions, limiting builders' powers. For now MEV cannot be fully eliminated, so users should apply basic protective measures (checklist, catalogue of vulnerabilities).

What to read next

We will see how a wallet can become "smart" and defend itself: account abstraction. Or how to optimise spend: gas optimization.