For educational purposes only; not investment advice. Investing may result in loss.
Direct answer
On-chain front-running occurs when someone learns about a pending transaction and gets another transaction executed before it to capture value. The actor may copy a profitable call, buy before a known order, or compete for a scarce on-chain opportunity. Front-running is one form of maximal extractable value (MEV), not a synonym for every MEV strategy.
The opportunity exists because a submitted Ethereum transaction is normally broadcast and held in transaction pools before a validator includes it in a block. Searchers can inspect pending transactions, simulate outcomes, and send their own transactions or bundles. The final order is determined through the block-building process, so paying a larger priority fee may influence inclusion but does not guarantee a particular position.
For users, the practical questions are whether a transaction reveals a valuable intention before execution, whether its limits leave room for extraction, and who can influence ordering. DEX swaps with loose slippage, public claims with reusable secrets, liquidations, auctions, and limited mints can all attract competition.
How it works
In a sandwich trade, a searcher sees a pending DEX purchase, buys the same asset immediately before it, and sells immediately after it. The user’s purchase moves the pool price upward between the searcher’s two trades. The strategy succeeds only if the user’s minimum received amount still permits execution after the added price movement and all fees.
Generalized front-runners target calls whose value can be copied. If a transaction reveals an answer or authorization that is not bound to the intended recipient, another account may reproduce the call and seek earlier execution. Contract defenses include commit-reveal designs and binding claims to a specific recipient; simply asking users to raise fees does not protect exposed information.
Ethereum fee fields such as maxPriorityFeePerGas and maxFeePerGas affect what a sender is willing to pay. They do not make transaction contents private, and builders may evaluate bundles rather than sort every transaction by one fee field. Front-running is therefore an information-and-ordering problem, not merely a gas-price race.
Example
Suppose an AMM pool contains 100 ETH and 200,000 USDC. A user submits a public transaction to spend 10,000 USDC on ETH with 5% slippage tolerance. The pending transaction reveals the direction, size, and minimum acceptable output.
A searcher simulates the swap and submits a purchase to run before it, followed by a sale to run after it. If both are ordered around the user’s transaction, the user receives less ETH than without the sandwich but still remains within the 5% limit; the searcher keeps the difference after fees.
The outcome is not guaranteed. Competing searchers, pool fees, price changes, failed inclusion, or the user’s minimum-output check can make the strategy unprofitable or cause the sequence to fail. A normal large trade also creates price impact, so transaction traces and pool state are needed before attributing all slippage to an attack.
Risks and mitigations
No setting removes every ordering risk. The useful goal is to reduce unnecessary information leakage and cap the loss a transaction may accept.
- Set a defensible minimum output or price limit based on pool depth and current conditions; do not widen slippage merely to force execution.
- Review price impact, liquidity, token transfer rules, and the route before signing, especially for large trades in shallow pools.
- Use reputable private submission or MEV-protection services when appropriate, while checking their builder coverage, failure behavior, privacy policy, and trust assumptions.
- For protocol design, avoid first-come secrets in transaction data; use recipient binding, commit-reveal, batch auctions, or other mechanisms suited to the application.
Private submission can hide a transaction from the public pool, but it is not a universal guarantee. The user relies on the service and participating builders not to leak or misuse the transaction, and changing RPC routes before confirmation may expose it publicly. A transaction may also be delayed or omitted.
Common misconceptions
Myth 1: Paying more gas prevents front-running
A higher priority fee may improve inclusion odds, but it does not conceal the trade. Searchers and builders can submit a more valuable ordering or bundle, so fee bidding alone is not protection.
Myth 2: Every unfavorable fill is a sandwich attack
Large orders move AMM prices on their own, and markets can change while a transaction is pending. Routing fees, transfer taxes, and ordinary competition can also worsen execution.
Myth 3: Zero slippage is always safest
An extremely tight limit can reject ordinary price movement and still consume gas when a public transaction reverts. The appropriate limit depends on liquidity, trade size, urgency, and the user’s maximum acceptable loss.
Related topics
Sources
- Transactions - ethereum.org (accessed: 2026-08-20)
- Maximal extractable value (MEV) - ethereum.org (accessed: 2026-08-20)
- Flashbots Protect Quick Start - Flashbots (accessed: 2026-08-20)