Front-Running

Front-Running Explained in Detail

Front-running happens when a pending transaction reveals a profitable action. An attacker sees it, submits a competing transaction, and gets included first.

The attacker may copy the transaction, act before it, or make the victim's transaction execute under worse conditions.

Transaction example

1. Submit: A user sends a transaction to claim a reward.

2. Observe: A bot sees the calldata in the mempool.

3. Outbid: The bot submits the same claim with higher priority.

4. Capture: The bot claims first and the user's transaction fails or becomes worthless.

Front-Running in Auditing

Front-running turns public calldata and transaction ordering into an adversarial surface. It matters when "first caller wins" or when execution order changes price, eligibility, or payout.

Red flags in code

• Public claim, bid, mint, liquidate, settle, reveal, or execute functions.

• Calldata contains a secret, solution, signature, price, or profitable route.

• No commit-reveal for hidden information.

• No slippage, deadline, or price bounds.

• Function behavior depends on current mempool ordering or first inclusion.

• Auctions, liquidations, reward claims, and mints with open competition.

How to test or review it

• Simulate both execution orders, plus sandwich-style placement around the victim transaction.

• Check whether calldata can be copied for profit.

• Test stale quotes, missing deadlines, and weak price bounds.

• Review whether commit-reveal is needed for secrets.

• Check whether private transaction routes are a mitigation or only a UX layer.

• Prefer designs that remove MEV advantage instead of assuming fair ordering.