You submit a swap on a decentralized exchange — buying 5 ETH worth of a low-liquidity token. The transaction appears in the public mempool, pending confirmation.
Within seconds, another transaction appears in the same block — buying the same token. But this transaction pays a higher gas fee, so miners (or validators) process it first. The price moves. Then your transaction executes — at a worse price than you expected.
The other trader just bought the token cheaper, then sold it at the price your transaction created. They pocketed the difference. You paid for it.
This is a front-running attack. It did not exploit a smart contract vulnerability. It did not require access to any privileged system. It used only information that was publicly available — your pending transaction — and the economic incentive built into every blockchain: pay more gas, get processed first.
BLUF: Front-running is the practice of observing a pending transaction in the public mempool, then submitting your own transaction to profit from the predictable price impact — paying higher gas to ensure your transaction is processed first. The three main forms are: (1) classic front-running — buying before a large order to sell after the price moves; (2) back-running — placing a sell order immediately after a large buy to capture the price impact; (3) the sandwich attack — combining both (front-run + back-run) to extract maximum value. The root cause is structural: blockchains process transactions in gas-price order, and the mempool is public. Defenses include slippage tolerance, private transaction pools, and DEX aggregators that split orders across multiple pools.
How Front-Running Works
To understand front-running, you need to understand how transactions move from submission to execution on a blockchain.
The Transaction Lifecycle
- Submission — You sign and broadcast a transaction. It enters the mempool, a temporary holding area for pending transactions.
- Visibility — The mempool is public. Anyone running a node — including automated bots — can see every pending transaction in real time.
- Ordering — Miners or validators select transactions from the mempool and arrange them into blocks. The primary ordering criterion is gas price: higher-paying transactions go first.
- Execution — Transactions execute in the order they appear in the block.
The vulnerability is in steps 2 and 3. Because the mempool is public (step 2), anyone can see what you are about to do before it happens. Because ordering is determined by gas price (step 3), anyone who pays more can jump ahead of you.
This is the structural foundation of every front-running attack.
The Attack Sequence
Here is how a classic front-running attack unfolds on a decentralized exchange:
| Step | Who | What |
|---|---|---|
| 1 | Victim | Submits a large buy order for Token X (visible in mempool) |
| 2 | Attacker bot | Detects the pending transaction, calculates its price impact |
| 3 | Attacker bot | Submits a buy order for Token X with higher gas |
| 4 | Block producer | Processes the attacker’s transaction first (higher gas) |
| 5 | Block producer | Processes the victim’s transaction second — price is now worse |
| 6 | Attacker bot | Submits a sell order for Token X, capturing the price difference |
The attacker profits from the price movement caused by the victim’s own transaction. The victim’s order — which they thought would execute at the current market price — instead executes at a worse price because the attacker moved the market first.
This entire sequence can happen within a single block — a few seconds.
Front-Running vs. Sandwich Attacks vs. MEV
These terms are related but distinct. Understanding the differences helps you identify which type of attack you are dealing with.
Classic Front-Running
The attacker places a single transaction ahead of yours — typically a buy before your buy, to profit from the price increase your order will cause. The attacker exits their position in a later transaction (sometimes in a later block).
Back-Running
The attacker places a transaction immediately after yours — typically a sell after your large buy, capturing the temporary price spike your order created. Back-running is less harmful to the victim than front-running because it does not change the price the victim receives — it only profits from the price recovery afterward.
The Sandwich Attack
A sandwich attack combines both: the attacker front-runs your buy with their own buy (pushing the price up), then back-runs your transaction with a sell (capturing the difference). Your transaction is “sandwiched” between the attacker’s two transactions. This is the most harmful form because the victim pays the full cost of both legs.
| Attack Type | Transactions | Victim Impact |
|---|---|---|
| Classic front-running | 1 (before victim) | Worse execution price |
| Back-running | 1 (after victim) | Minimal — attacker profits from price recovery |
| Sandwich attack | 2 (before + after) | Significantly worse execution price |
MEV (Maximal Extractable Value)
All three are forms of MEV — the total value that can be extracted by reordering, including, or censoring transactions within a block. MEV bots constantly monitor the mempool for profitable ordering opportunities and execute them automatically.
MEV is broader than front-running. It also includes arbitrage (rebalancing prices across different pools, which is generally beneficial) and liquidations (front-running liquidation opportunities on lending protocols).
Why Front-Running Is So Hard to Eliminate
Front-running is not a bug. It is a direct consequence of two fundamental blockchain design choices:
1. Public Mempools
Most blockchains broadcast pending transactions to all nodes. This transparency is a feature — it allows anyone to verify that transactions are being processed fairly. But it also means that predatory traders can see exactly what is about to happen and position themselves accordingly.
Private or encrypted mempools would prevent front-running but would compromise the transparency that makes blockchains trustworthy. Some networks, like Flashbots Protect and MEV-Share on Ethereum, offer private transaction pools that bypass the public mempool — but these are opt-in services, not protocol-level changes.
2. Gas-Based Ordering
Blockchains let block producers choose which transactions to include and in what order. The economic incentive is clear: higher-paying transactions are more profitable to include. This means anyone willing to pay more can get processed first — which is exactly what front-runners do.
Proposed solutions like fair ordering (where transactions are ordered by timestamp rather than gas price) sound simple but are technically difficult to implement in a decentralized network where clock synchronization is imperfect.
3. Smart Contract Transparency
On-chain smart contracts are visible to everyone. If a DEX pool has low liquidity, anyone can calculate the exact price impact of a large swap by reading the contract state. This makes it trivial for MEV bots to identify profitable front-running opportunities programmatically.
Where Front-Running Happens Most
Not all transactions are equally vulnerable. Front-running is most profitable — and therefore most common — in these scenarios:
Low-Liquidity Pools
In a pool with $50,000 of liquidity, a $10,000 swap moves the price significantly. An attacker can front-run the swap, buy at the current price, and sell at the inflated price with minimal capital. In a pool with $50 million of liquidity, the same $10,000 swap barely moves the price, making front-running unprofitable.
Large Swaps Relative to Pool Size
Even in a well-capitalized pool, a very large swap can create a profitable front-running opportunity. The attacker’s profit comes from the price impact — bigger swaps mean bigger impact means bigger profit.
Time-Sensitive Transactions
Some transactions are inherently time-sensitive — liquidations on lending protocols, NFT mints with limited supply, token presales. For these transactions, users often set high slippage tolerance (to ensure the transaction goes through), which makes front-running even more profitable because the attacker knows the victim will accept a much worse price.
How to Protect Yourself
1. Set Realistic Slippage Tolerance
Slippage tolerance is the maximum price change you are willing to accept. A high tolerance means your transaction is more likely to execute — but it also means front-runners can extract more value before your transaction rejects. Set slippage as low as possible while still allowing for normal price movement (0.5%–1% for major tokens, 2%–3% for smaller tokens).
2. Use Private Transaction Services
Services like Flashbots Protect route your transaction directly to block builders, bypassing the public mempool entirely. Front-running bots cannot attack what they cannot see. Most major wallets and DEX interfaces support this option — look for “MEV protection” or “private transactions” in your settings.
3. Split Large Orders
Instead of swapping $50,000 in a single transaction, split it into five $10,000 transactions over several blocks. Each smaller transaction has less price impact, making front-running less profitable. Many DEX aggregators do this automatically.
4. Use DEX Aggregators
Aggregators like 1inch, Paraswap, and Matcha split your swap across multiple pools and DEXes to minimize price impact and slippage. By routing through multiple paths, they reduce the visibility and profitability of front-running opportunities.
5. Avoid Peak Congestion
Gas prices spike during periods of high network activity — often triggered by major market moves or popular NFT mints. During these periods, MEV bots are most active and most profitable. If your transaction is not urgent, wait for quieter periods.
How to Detect If You Were Front-Run
You cannot always prevent front-running, but you can detect it after the fact:
Check Transaction Order
Look up your transaction on a block explorer. Check whether any other transactions interacting with the same liquidity pool were included in the same block, immediately before or after yours. If a large buy or sell by an unknown address sandwiched your transaction, you were likely attacked.
Compare Expected vs. Actual Price
Most DEX interfaces show you an expected output amount before you confirm a swap. Compare this to the actual amount you received. If the difference significantly exceeds your slippage tolerance, front-running is the likely cause.
Use MEV Dashboards
Tools like Flashbots Explorer, EigenPhi, and libmev.com track MEV extraction in real time. You can search for your transaction hash to see if it was included in an MEV bundle and how much value was extracted.
The Broader MEV Landscape
Front-running is the most visible and most harmful form of MEV — but not all MEV is predatory.
| MEV Type | Description | Impact on Users |
|---|---|---|
| Arbitrage | Rebalancing prices across different DEX pools | Generally positive — keeps prices efficient |
| Liquidation | Front-running liquidation opportunities on lending protocols | Neutral — protocol functions as designed |
| Front-running | Jumping ahead of user transactions for profit | Negative — users get worse prices |
| Sandwich attacks | Front-running + back-running | Highly negative — maximum extraction from users |
| JIT liquidity | Providing liquidity just for a swap, then withdrawing | Mixed — can improve or worsen execution |
The Ethereum ecosystem is actively developing solutions to redirect MEV from predatory forms (front-running, sandwich attacks) toward beneficial forms (arbitrage) while protecting ordinary users. Proposals like Proposer-Builder Separation (PBS), MEV-Boost, and encrypted mempools represent different approaches to the same goal: making the public mempool safe for ordinary users without sacrificing the benefits of an open, transparent transaction system.
Until these solutions mature, individual protection — slippage limits, private pools, order splitting — remains the primary defense.
For more on protecting yourself on-chain, read our guides on sandwich attacks, MEV explained, and how to verify a token before buying.
Front-running is a structural feature of transparent, gas-ordered blockchains — not a hack. Understanding the mempool and using MEV protection tools is essential for anyone trading on DEXes.