Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
Front-running is transaction-ordering exploitation: an actor sees or predicts an order, places a transaction ahead of it, and captures value from the resulting state change. A sandwich adds a transaction after the victim as well. This is one form of maximal extractable value (MEV), not a synonym for all MEV and not necessarily a consensus bug. Ethereum's MEV documentation distinguishes sandwiching from useful activities such as arbitrage and liquidations.
The application must expose an order-sensitive action and enough value to cover execution costs. Common examples include AMM swaps with loose output bounds, first-come claims whose inputs are public, auctions with visible bids, and liquidations where competing callers receive different outcomes.
A sandwich usually requires observable order flow, a predictable price impact, and a victim transaction that remains valid after the attacker moves the market. amountOutMin limits the victim's accepted loss; it does not hide the trade or guarantee that no sandwich is profitable. The Uniswap V2 router interface exposes both minimum-output/maximum-input bounds and deadlines because execution constraints belong to the caller's transaction.
Map every function whose result depends on another transaction landing first: swaps, mints, liquidations, auctions, registrations, governance actions, and reward claims. For each path, identify what a searcher learns before inclusion and whether the same input can be copied or bracketed.
Test adversarial orderings on a fork or economic model. Compare attacker → user → attacker with the intended sequence, include fees and price impact, and assert the user's on-chain bounds. Test competing callers, duplicate commitments, stale deadlines, partial fills, and reorg-sensitive assumptions. A static warning is only a lead; exploitability depends on live liquidity, routing, ordering, and costs.
Firepan can review submitted source for missing bounds, copyable claims, and ordering-dependent state transitions. It cannot prove that a transaction will remain private, predict every builder's ordering policy, or determine profitability without deployment-specific market data.
Does a minimum output prevent every sandwich?
No. It caps the execution the caller accepts. A searcher may still profit inside that tolerance.
Is every liquidation front-running a vulnerability?
No. Many protocols intentionally reward the first valid liquidator. The security question is whether ordering violates a documented invariant or extracts avoidable value from users or the protocol.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Assess smart contract admin powers, upgrade authority, key custody, delays, caps, and the limits of source-only centralization analysis.
Review smart contract liveness failures caused by gas growth, external-call reverts, griefing, and unrecoverable state.
Understand first-depositor and donation attacks against tokenized vaults, rounding conditions, tests, and mitigation tradeoffs.
Review accounting assumptions for fee-on-transfer, rebasing, and other non-standard ERC-20 tokens, with test and mitigation guidance.
Learn how weak swap bounds expose users and vaults to adverse execution, how to review integrations, and where minimum outputs and deadlines fall short.