Safeguard
Security Guides•

MEV, front-running and sandwich attacks: a developer primer

What maximal extractable value means, how front-running and sandwich trades work against public transactions, and what builders can do about it.

Safeguard Security Team
3 min read

MEV is value that can be captured by including, excluding or reordering transactions in a block, beyond the normal block reward and gas fees. For developers the practical issue is that pending transactions are visible, so bots can copy or surround yours. Design contracts so ordering gives an attacker little to gain.

Definitions

ethereum.org describes MEV as the maximum value that can be extracted from block production in excess of the standard block reward and gas fees. Searchers extract most of it, and validators earn a share through gas fees.

Front-running. Bots watch the public mempool for profitable transactions. They copy the transaction, swap in their own address, and submit it with a higher gas price so it runs first.

Sandwich trading. A searcher sees a large trade on a decentralized exchange, buys just before it to get a cheaper price, then sells just after at the inflated price. The page notes sandwiching is riskier than arbitrage because it is not atomic.

Mitigations the documentation lists

  • Private submission. Flashbots lets searchers send transactions to validators without exposing them in the public mempool.
  • Proposer builder separation. Splits block building from block proposing, so builders compete and validators no longer optimize for MEV directly.
  • Commit reveal schemes. Publish only a commitment at first, then reveal later.
  • Builder APIs. More builder competition, with private channels that can help users avoid sandwiching.

These sit mostly at the protocol and infrastructure level. They are not something one contract author controls.

What a contract author can do

  • Let callers set a slippage limit and a deadline, and enforce both.
  • Avoid designs where the first caller of a public function wins a prize.
  • Use commit reveal for actions such as auctions where seeing a bid changes the outcome.
  • Do not rely on transaction ordering within a block for fairness.
  • Document the ordering assumptions in the specification so reviewers can challenge them.

What a user or team can do

Offer a private submission route for large operations, and set tight slippage. Treat any workflow that reveals intent in public before execution as one that will be observed.

Test ideas

  1. Simulate a buy placed immediately before and a sell immediately after your user's trade. What is the profit?
  2. Replay a user transaction with a higher fee from another address. Does the result change?
  3. Check whether any function pays more to whoever calls it first.

Predictable ordering is the same family of concern as insecure randomness in the OWASP list: anything an attacker can see and act on first is not secret.

Safeguard does not analyse onchain trading. It can scan the repositories and packages that build your contract tooling, and a free scan is at gold.safeguard.sh/scan.

Quick check

Is MEV always an attack?

No. The documentation describes it as value from ordering transactions, and some of it is arbitrage. Front-running and sandwiching are the forms that harm ordinary users.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.