Front-Running

What Is Front-Running?

Front-running is the practice of using advance knowledge of a pending transaction to place your own transaction ahead of it, profiting from the predictable market impact. The term originates from traditional finance, where a broker might trade ahead of a large client order, but in crypto the concept has evolved into a far more systematic and automated phenomenon.

In blockchain networks with public mempools, every pending transaction is visible before confirmation. This transparency, essential for decentralization, creates an information asymmetry: anyone monitoring the mempool can see what trades are about to execute and position themselves to profit. On networks like Ethereum, where smart contract interactions produce deterministic price changes, front-running has become an entire extractive economy known as Maximal Extractable Value (MEV).

The core mechanic is simple: observe a profitable pending transaction, submit your own transaction with a higher gas fee to get it confirmed first, and capture the value that the original transaction would have produced. The victim's trade still executes, but at a worse price.

How It Works

Front-running relies on two properties of most blockchain networks: a public mempool where unconfirmed transactions are visible, and a fee-based priority system where higher-paying transactions get confirmed first. The attack follows a general pattern:

1. Monitor the mempool for profitable target transactions (large DEX swaps, liquidation triggers, oracle updates)
2. Analyze the target transaction to predict its market impact
3. Construct a transaction that profits from the predicted price movement
4. Submit the front-running transaction with a higher fee to ensure it confirms first
5. Collect the profit from the price difference

On Bitcoin, the Replace-by-Fee (RBF) mechanism allows transactions to be replaced with higher-fee versions, which in theory could facilitate front-running. However, Bitcoin's limited scripting capabilities mean there are far fewer exploitable patterns compared to Ethereum.

Pure Front-Running

The simplest form: a bot observes a large pending swap on a decentralized exchange and submits the same trade ahead of it. For example, if a victim is buying a large amount of Token X on a DEX, the front-runner buys Token X first, driving the price up. The victim's trade then executes at the higher price, and the front-runner sells Token X at the inflated price for a profit.

# Simplified front-running flow on an AMM

# 1. Victim submits swap: 100 ETH -> Token X
# Mempool shows: swap(ETH, TokenX, amount=100)

# 2. Front-runner sees this and submits first:
# Buy Token X with 10 ETH (higher gas price)
# Token X price rises from $1.00 to $1.05

# 3. Victim's swap executes at worse price:
# Gets fewer Token X per ETH ($1.05 instead of $1.00)

# 4. Front-runner sells Token X at $1.05
# Profit: price difference minus gas costs

Sandwich Attacks

A sandwich attack is a more sophisticated variant that wraps the victim's transaction between two attacker transactions: one before and one after. The front-running transaction moves the price in one direction, the victim's trade pushes it further, and the back-running transaction captures the profit by trading in the opposite direction.

1. Front-run: buy the asset before the victim, pushing the price up
2. Victim's trade executes at the inflated price, pushing it even higher
3. Back-run: sell the asset immediately after the victim, capturing the spread

Sandwich attacks are particularly effective against automated market makers (AMMs) because the price impact of each trade is mathematically predictable from the bonding curve. The attacker can calculate the exact profit before executing.

Liquidation Front-Running

In lending protocols, positions that fall below their collateral threshold become eligible for liquidation. Liquidators earn a bonus (typically 5-10% of the collateral) for closing these positions. Front-runners monitor the mempool for liquidation transactions and submit their own liquidation calls with higher fees, stealing the liquidation reward from the original liquidator.

This creates a cascading effect: when markets drop sharply, a rush of competing liquidation transactions drives up gas fees, which can trigger further liquidation cascades as the cost of maintaining positions increases. During Ethereum's "Black Thursday" in March 2020, liquidation front-running contributed to cascading failures across DeFi lending protocols.

Front-Running Across Blockchains

Ethereum and the MEV Ecosystem

Ethereum's account-based model and Turing-complete smart contracts make it the primary battleground for front-running. The MEV ecosystem has evolved into a sophisticated supply chain:

• Searchers: bots that scan the mempool for profitable front-running opportunities and construct transaction bundles
• Builders: entities that assemble blocks from searcher bundles, optimizing for maximum extractable value
• Relays: infrastructure that connects searchers to builders without revealing transaction details prematurely
• Validators: block proposers who select the highest-value block from competing builders

Projects like Flashbots emerged to democratize MEV extraction and reduce its negative externalities. Rather than competing through gas price wars that congest the network, Flashbots introduced a sealed-bid auction where searchers submit bundles directly to miners (now validators) through a private channel. This reduced on-chain spam but did not eliminate the underlying extraction from users.

Bitcoin's Limited Exposure

Bitcoin's exposure to front-running is fundamentally more limited. The UTXO model and Bitcoin Script's restricted capabilities mean there are no AMMs, lending protocols, or complex DeFi applications running natively on the base layer. Without stateful smart contracts, there are far fewer transactions whose outcomes can be profitably predicted and front-run.

However, Bitcoin is not entirely immune. The fee market dynamics create some front-running vectors:

• RBF sniping: observing an unconfirmed transaction and broadcasting a conflicting transaction with a higher fee. This is less about front-running for profit and more about transaction replacement or double-spend attempts.
• Ordinals and BRC-20 minting: during popular inscription mints, bots can monitor pending mint transactions and attempt to front-run them by submitting their own mints with higher fees.
• On-chain swap protocols: trustless swap mechanisms that use HTLCs or PSBTs can be vulnerable if the swap details are visible in the mempool before confirmation.

Lightning Network's Protection

The Lightning Network is inherently resistant to front-running for several structural reasons. Payments travel through encrypted onion-routed channels, meaning no single node (other than the sender) knows the full payment path. There is no public mempool: payments are negotiated directly between channel partners and propagate through the network in encrypted hops.

This architecture eliminates the two prerequisites for front-running: transaction visibility and fee-based ordering. A routing node can see that it is forwarding a payment, but it cannot determine the origin, destination, or purpose of the payment. Even if a node wanted to front-run, it would not know what transaction to construct. For a deeper look at these privacy properties, see the research on onion routing and Lightning privacy.

Additionally, blinded paths further obscure the receiver's identity, and PTLCs (once widely adopted) will prevent correlation of payments across hops, making any form of payment-level analysis even more difficult. The evolution toward PTLCs represents the next step in Lightning's privacy guarantees.

Mitigations and Defenses

Various approaches attempt to reduce front-running across different blockchain ecosystems:

Protocol-Level Defenses

• Commit-reveal schemes: users first commit to a transaction hash, then reveal the details in a later block, preventing mempool observation
• Encrypted mempools: transactions are encrypted until block inclusion, hiding their contents from searchers
• Fair ordering: protocols that enforce transaction ordering by arrival time rather than fee, removing the priority gas auction
• Batch auctions: DEXs that collect orders over a period and execute them at a uniform clearing price, eliminating ordering advantages

Application-Level Defenses

• Slippage limits: users set a maximum acceptable price deviation, causing the transaction to revert if front-running moves the price too far
• Private transaction submission: sending transactions directly to block builders rather than the public mempool
• Time-weighted average pricing: executing large trades over multiple blocks to reduce the impact of any single front-running attempt
• Off-chain execution: moving trading logic off-chain (as Lightning does for payments) eliminates the public mempool observation vector entirely

Layer 2 Advantages

Layer 2 solutions inherently reduce front-running surface area. On Lightning, the absence of a public mempool and the use of encrypted routing make front-running structurally impossible for payment transactions. Similarly, Spark's architecture processes transactions off-chain without exposing them to a public ordering queue. For a comparison of how different Layer 2 approaches handle transaction privacy, see the Bitcoin Layer 2 comparison.

Risks and Considerations

Systemic Impact on DeFi

Front-running imposes a hidden tax on DeFi users. Every sandwich attack or liquidation front-run transfers value from regular users to sophisticated extractors. Estimates suggest MEV extraction on Ethereum has exceeded several billion dollars cumulatively, with the cost distributed across millions of individual transactions as slightly worse execution prices.

Centralization Pressures

The MEV supply chain concentrates power among a small number of sophisticated builders and searchers. Block building has become increasingly centralized, with a handful of builders producing the majority of Ethereum blocks. This concentration creates censorship risks and undermines the decentralization that public blockchains aim to provide.

Arms Race Dynamics

Front-running defenses often trigger new attack vectors. Flashbots reduced gas price wars but created a new centralized infrastructure layer. Encrypted mempools may prevent mempool observation but could introduce latency or complexity. Each mitigation reshapes the landscape rather than eliminating the underlying incentive to extract value from transaction ordering.

Cross-Domain MEV

As more value moves across chains and layers, cross-domain MEV is emerging: extracting value from the ordering of transactions across multiple networks simultaneously. For example, observing a large trade on one chain and front-running the corresponding price update on another. This expanding attack surface highlights why protocol designs that minimize public transaction visibility, like Lightning's onion routing, become increasingly important.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.