DeFi

Front-Running

Front-running is a transaction-ordering attack where an attacker observes a pending transaction and submits their own transaction so it executes first.

Someone sees what a user is about to do on-chain, pays for earlier execution, and captures the opportunity first.

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.

Sources