The phrase “front-running vulnerability” gets applied to two completely different classes of problem in DeFi security. The first class is an inherent property of transparent blockchains: any public transaction can, in principle, be observed and acted on by an economically rational party who controls transaction ordering. The second class is a genuine protocol bug: a design choice that creates an extraction surface that did not need to exist, where removing the bug eliminates or substantially reduces the attack surface. An auditor’s job is to clearly separate these two classes, communicate the severity of each, and give actionable remediation for the second.
This article walks through the major MEV and front-running patterns that appear in real protocol audits, explains the mechanics behind each one, and ends with a practical framework for categorizing findings.
1. Transaction Ordering Dependence (TOD)
Transaction Ordering Dependence is the foundational concept from which all MEV patterns derive. A function is TOD-vulnerable when its output — including state changes, token transfers, or payouts — differs materially depending on the order in which it is included relative to other transactions in the same block.
The canonical example is a race condition in an approval-based token flow:
In the above pattern, anyone who observes the pending swap in the mempool can insert a price-moving trade before it, shift the effective exchange rate, and profit from the delta. The victim’s transaction still executes successfully — which is precisely why this is not detected by standard testing.
TOD surfaces in many non-obvious places:
- NFT mint pricing: if mint price is calculated dynamically from bonding curve state, a bot can front-run a large mint to push the price.
- Governance votes: a snapshot that reads live token balances can be gamed if a voter can flash-loan tokens into their wallet before the block closes.
- Reward distributions: protocols that compute per-user rewards based on a ratio at the time of claim are vulnerable to a “last second deposit” attack that dilutes existing depositors.
The auditor’s first question is always: does the outcome of this function depend on state that a third party can change inside the same block? If yes, the function is TOD-exposed. Whether that exposure constitutes a vulnerability or an inherent risk depends on what follows.
2. Sandwich Attacks and the minAmountOut Fix
The sandwich attack is the most quantitatively documented MEV pattern in DeFi. An attacker observes a victim’s pending transaction in the mempool and strategically places one transaction before it (front-running) and another after it (back-running). By manipulating transaction ordering via gas fees, the attacker inflates the asset price before the victim’s swap and reverses the trade afterward, extracting a guaranteed profit at the victim’s expense.
The economic scale is significant. Sandwich attacks constituted $289.76 million, or 51.56% of the total MEV transaction volume of $561.92 million in the DeFi landscape. On an individual basis, a single sandwich attack in January 2025 generated over $800,000 in profit.
Sandwich attacks are especially common on AMM-based DEXs like Uniswap and are particularly damaging for large trades or when slippage tolerance is high.
The Protocol-Level Bug: Missing or Zero minAmountOut
Here is the critical distinction for auditors: the existence of sandwich attacks on a public blockchain is inherent. The protocol bug is when the swap function does not accept a caller-supplied minimum output parameter, or accepts one but ignores it.
// CORRECT: caller specifies minimum acceptable output function swapExactInput( address tokenIn, address tokenOut, uint256 amountIn, uint256 minAmountOut, // ← required parameter uint256 deadline // ← prevents stale execution ) external returns (uint256 amountOut) { require(block.timestamp <= deadline, “Expired”); amountOut = _swap(tokenIn, tokenOut, amountIn, minAmountOut); require(amountOut >= minAmountOut, “Insufficient output”); outputToken.transfer(msg.sender, amountOut); }`}
Developers should implement commit-reveal schemes for sensitive submissions, enforce slippage protection with minAmountOut parameters on all swaps, add transaction deadlines to prevent stale execution, and consider integrating with batch auction systems.
A missing minAmountOut is a High severity vulnerability. A present but user-defaulted-to-zero minAmountOut is a Medium or Design Risk — it means the UI or integration layer is failing users, not the contract per se, but the contract should enforce a reasonable non-zero floor or at minimum emit a warning event.
The pattern also has a subtle cross-chain variant. Attackers can exploit events emitted on the source chain to learn transaction details on the destination chain before they appear in the destination chain mempool. This information advantage allows attackers to strategically place front-running and back-running transactions, ensuring their front-running transactions always precede those of existing MEV bots monitoring the mempool of the destination chain. Bridge-aware minAmountOut enforcement at the destination side of a cross-chain swap is an emerging audit pattern.
3. Liquidation MEV and Dutch Auction Designs
Liquidation is structurally an MEV-heavy event: the moment a position becomes liquidatable, there exists a risk-free profit for whoever can liquidate it first. When a user’s collateral drops below the liquidation threshold, MEV actors use fast bots to race for the liquidation and claim a fixed reward, usually around 5 to 10%. These rewards are meant to keep the protocol stable, but in practice, they mostly benefit validators and professional searchers.
Fixed-Discount Systems and the Gas War Problem
Protocols like Compound and Aave implement fixed liquidation bonuses, offering immediate purchase of collateral at a predetermined discount, typically 5% to 10%. This approach prioritizes speed over optimal price recovery, accepting slightly worse outcomes in exchange for certainty and simplicity. Liquidators compete through transaction speed rather than pricing, often employing sophisticated MEV strategies to capture profitable liquidations first.
The fixed-discount model has two auditable failure modes:
- Bonus too high: a 10% fixed discount means the protocol systematically overpays for liquidations, transferring value from borrowers (and ultimately the protocol’s insurance/reserve fund) to searchers.
- Bonus too low: if the discount does not cover gas costs plus execution risk, liquidations may fail to occur in time, creating bad debt.
Neither is a “bug” in the traditional sense — but both represent design parameters an auditor should flag for review, especially if the discount is set in a constructor with no governance override.
Dutch Auction Liquidations
Euler addresses the liquidation and MEV issues in traditional DeFi lending protocols through Dutch auction liquidation and soft liquidation mechanisms, providing more competitive fees and higher Loan-to-Value ratios (LTV). The mechanics are illustrative: Euler Finance for their V1 protocol incorporated a quasi-Dutch auction mechanism for liquidations. This helped mitigate losses for liquidated users by reducing liquidation bonuses paid to third parties, and instead accrue some of this value to an insurance fund. These features provided users significant value via what are essentially MEV rebates, and increased lender security against bad debt.
In a canonical Dutch auction liquidation, the protocol starts the discount at zero (or near-zero) and increases it over time until a liquidator accepts. Competitive liquidators wait until the discount just covers their costs, preventing the gas war seen in fixed-bonus systems.
// Discount grows linearly from 0 to MAX_DISCOUNT over AUCTION_DURATION
discount = (elapsed * MAX_DISCOUNT) / AUCTION_DURATION;
if (discount > MAX_DISCOUNT) discount = MAX_DISCOUNT;}`}
However, Dutch auction designs introduce their own audit surface. The design still requires liquidators to participate in a second auction for blockspace on top of the initial Euler auction. This creates uncertainty for the auction participants which will probably lead to under-bidding in the Euler auction. Auditors should check:
- Auction start price: if the starting discount is already profitable, the Dutch auction provides no benefit over fixed-discount.
- Duration calibration: too short, and the auction reverts to a gas war at the bottom of the curve; too long, and the protocol accumulates bad debt during volatile periods.
- Price feed dependency during auction: if the discount is computed relative to an oracle price, and that oracle can be manipulated, the auction discount becomes manipulable. This is the interaction between liquidation design and oracle security.
For alternative queue-based approaches, bids with the smallest discounts are filled first, which leads to an optimal discount rate and avoids quick selling by MEV bots.
4. Oracle Front-Running and Latency Arbitrage
Oracle-related MEV is classified under a separate umbrella: Oracle Extractable Value (OEV). The inherent time delay in oracle price updates leads to a subtype of value extraction known as Oracle Extractable Value (OEV), which includes front-running, arbitrage, and inefficient liquidations.
Latency Arbitrage on Push Oracles
Push oracles update on schedules. According to Chainlink’s documentation, their price feeds update based on deviation thresholds or heartbeat intervals. This predictability creates opportunity. If an oracle updates every 60 seconds, MEV searchers know there’s a 60-second window where on-chain prices lag real markets. They monitor both and profit from the gap.
This is not a vulnerability in the oracle itself — it is an architectural consequence of push-based designs. The vulnerability arises when a protocol fails to account for this lag in its design. Oracle front-running and arbitrage are colloquially referred to as “toxic flow” in derivative protocols because these trades occur under conditions of information asymmetry, often extracting risk-free profits at the expense of liquidity providers. Decentralized exchanges like GMX have long been victims of toxic front-running; approximately 10% of protocol profits have been lost to front-running before all oracles on GMX are updated.
Flash Loan Oracle Manipulation
A more severe class of oracle vulnerability involves active manipulation rather than passive latency exploitation. An attacker uses borrowed capital to buy or sell aggressively in the AMM pool, shifting its reserves and therefore its spot price. In an ordinary market context, this would be a temporary distortion that arbitrageurs quickly trade away. But the attacker does not wait. In the same transaction, while the pool is still distorted, the attacker deposits token B into the lending protocol. The protocol queries the oracle, sees the manipulated spot price, and allows the attacker to borrow too much.
Protocols using a liquidity pool as their oracle are essentially 99.9% likely to be exploited because of the volatility in prices when leveraging flash loans. This is a Critical vulnerability. Using a single DEX spot price as a price oracle is never acceptable in a production lending protocol.
The TWAP oracle is a common mitigation, but it has its own surface: for a short time frame setting of a TWAP oracle, it is ineffective to filter out the extreme price data points injected by attackers. For a TWAP oracle with a long time frame, the time delay and price deviation error would be increased, creating additional opportunities for arbitrage attacks. A well-calibrated TWAP window (typically 30 minutes or longer on Ethereum mainnet) substantially increases the cost of manipulation but is not bulletproof on low-liquidity assets or low-activity periods.
Oracles like Chainlink, which are decentralized in nature, are significantly harder to break since the attacker would have to manipulate 50% +1 of nodes on a price feed.
OEV Recapture as a Protocol Design Consideration
Newer oracle designs attempt to return OEV to protocols rather than simply preventing extraction. In December 2024, Chainlink introduced Smart Value Recapture (SVR) — a novel oracle solution designed to enable DeFi applications to recapture the MEV derived from their use of Chainlink Price Feeds. The initial version was built in collaboration with BGD Labs, Flashbots, and other contributors to the Aave DAO and will initially focus on enabling DeFi lending protocols to recapture oracle-related MEV from liquidations.
For auditors, protocols that claim to implement OEV recapture create an additional audit surface: the mechanism by which recaptured value is returned must not itself create a new attack vector (e.g., a manipulable distribution function).
5. Commit-Reveal Schemes and Their Failure Modes
Commit-reveal is the primary protocol-level countermeasure against front-running of sensitive actions. The commit-reveal scheme uses cryptographic hashing to hide player moves during a commit phase, then reveals them in a separate phase. Players submit keccak256(move + secret) during commit, then reveal the actual move and secret for verification.
While it does not solve all forms of MEV, it significantly raises the difficulty for attackers. They are forced to operate blindly during the commitment phase, removing the informational advantage they typically hold in a transparent ledger environment.
Failure Mode 1: Short or Predictable Secrets
The most common implementation mistake is using weak entropy for the secret. If the secret is derived from an on-chain value (block hash, timestamp, tx.origin), an attacker can either precompute it or brute-force the short space.
// VULNERABLE: small secret space (uint8 = 256 possibilities) bytes32 commitment = keccak256(abi.encodePacked(move, uint8(secret)));
// CORRECT: large, user-supplied random secret bytes32 commitment = keccak256(abi.encodePacked( move, secret // ← bytes32 from secure off-chain random ));`}
An auditor should check not just whether a commit-reveal scheme exists, but what the entropy of the secret is. A uint8 secret provides only 256 possible values — trivially brutable by any observer of the commitment.
Failure Mode 2: Reveal Ordering Attacks (Last-Revealer Attack)
Multi-party commit-reveal schemes face a structural attack that is more subtle. Traditional Commit-Reveal mechanisms are susceptible to last revealer attacks, where an adversary can manipulate the random outcome by withholding their reveal. Concretely: in a multi-party scheme (such as an on-chain randomness beacon or blind auction with multiple participants), the final party to reveal has full knowledge of what the outcome will be before they commit to revealing. They can simply withhold their reveal if the outcome is unfavorable.
Simple implementations, such as RANDAO, provide conceptual clarity and low complexity, but suffer from poor liveness or manipulation, notably the last revealer attack where the final participant strategically withholds their secret.
The Commit-Reveal mechanism offers strong safety but suffers from poor liveness. If any participant fails to reveal their secret, the process halts. This vulnerability is exploited by the Last Revealer Attack, where the final participant strategically decides whether to reveal based on potential outcomes, a concern amplified when randomness impacts financial incentives.
The solution is to randomize the reveal order: mitigating last revealer attacks by randomizing the reveal order using a two-layer Commit-Reveal process: randomness from the first phase dictates the reveal sequence for the second.
For auditors reviewing commit-reveal implementations, the checklist is:
| Check | Severity if missing |
|---|---|
| Secret has ≥ 128 bits of entropy | High |
| Secret cannot be derived from on-chain state | High |
| Reveal deadline enforced (no indefinite withholding) | Medium |
| Commitment is not replayable across rounds | Medium |
| Multi-party: reveal order is randomized or penalties apply for non-reveal | Medium |
| Single-party: timeout and fallback path defined | Low/Informational |
Failure Mode 3: Front-Running the Reveal
A less obvious failure mode: the reveal transaction itself is public in the mempool. If the reveal contains the secret and the protocol computes the outcome on-reveal, an observer can copy the secret from the pending reveal, construct a competing transaction, and submit it with higher gas. The original revealer’s transaction either gets front-run or back-run depending on the attack.
The fix is to ensure that the outcome of a reveal transaction is bound to msg.sender at commit time:
// CORRECT: commitment is bound to the original committer function commit(bytes32 commitment) external { playerCommitments[msg.sender] = commitment; }
function reveal(bytes32 move, bytes32 secret) external { bytes32 expected = keccak256(abi.encodePacked(move, secret)); require(playerCommitments[msg.sender] == expected, “Invalid”); delete playerCommitments[msg.sender]; // … process move }`}
6. Private Mempool Solutions: Capabilities and Limits
The infrastructure-layer response to mempool-based MEV is the private transaction relay. Protect RPC endpoints facilitate sending private transactions directly to a block builder to be included on-chain. As a result, these transactions completely bypass the public mempool.
MEV protection services like Flashbots Private Transactions shield Ethereum trades from front-running and sandwich attacks by routing them through private mempools. With the introduction of Proof of Stake and Proposer-Builder Separation, the transaction supply chain on Ethereum has shifted from relying entirely on the public mempool to an astonishing 80% usage of private RPCs. These private RPCs submit transactions directly to builders, therefore skipping the public mempool, while conducting Order Flow Auctions (OFAs) to capture MEV backrun rebates and gas rebates.
MEV-Share takes this further: MEV-Share is essentially a matchmaker. Rather than allowing MEV profits to concentrate among a few sophisticated actors, MEV-Share creates a more fair system by letting users share the value extracted from their transactions.
Why Private Mempools Are Not a Protocol Fix
Auditors must be careful not to treat private mempool integration as a remediation for a protocol-level vulnerability. Private mempools operate at the user/wallet layer, not the contract layer. A protocol that requires minAmountOut = 0 cannot be made safe simply because the deployer recommends Flashbots Protect.
More critically, migration to private routing does not prevent MEV extraction: 3,126 private victim transactions from November to December 2024 demonstrate systematic exploitation. One operator controls approximately 65% of private sandwich volume, suggesting potential compromise or collusion within private routing infrastructure. These findings challenge the assumption that private routing offers genuine protection from MEV, revealing that private channels may constitute a narrower but highly concentrated attack surface.
Not all RPCs and OFAs produce the same outcomes. These insights underscore the significant implications of OFA design choices on transaction efficiency and execution quality, and thus why an order flow originator should pay close attention to which OFA they use.
The practical guidance:
- Private mempool integration is a Mitigation for informational-class MEV exposure, not a fix for protocol vulnerabilities.
- Contracts must implement all necessary on-chain protections (
minAmountOut, deadlines, TOD-safe state reads) regardless of what the front-end recommends. - If a protocol’s security model requires users to route through a specific private relay, this is a centralization dependency that should be flagged.
7. Distinguishing Protocol Vulnerability from Inherent MEV Exposure
Before presenting the audit framework, it is worth stating the distinction explicitly, because it is frequently confused in security reports.
Inherent MEV exposure exists when a blockchain-based protocol, by virtue of being on a public, ordered ledger, creates opportunities for economically rational actors to extract value. Arbitrage between two DEX pools is the cleanest example: the price difference is real, the extraction is not harmful to any individual counterparty (no individual is being “attacked”), and eliminating it would require changing how blockchains work. Some forms of MEV extraction (like DEX arbitrage) are considered legitimate, while sandwich attacks that directly harm users are increasingly scrutinized.
Protocol vulnerability exists when a specific design choice creates an extraction vector that the designers did not intend and that can be closed by changing the protocol. Missing minAmountOut is the canonical example: the designer presumably intended users to get a fair price, and the bug is that nothing enforces this. A fixed-bonus liquidation system that is calibrated 300 basis points too high is a design vulnerability: the protocol is overpaying by design.
The line between the two categories is not always sharp. A liquidation system that works correctly during normal conditions but creates bad debt during rapid price moves is not exactly buggy and not exactly safe — it is a parameter risk. Auditors should use a three-tier framework:
8. Audit Categorization Framework
The following framework is used to classify MEV and front-running related findings. It maps to standard severity tiers but adds the MEV-specific Design Risk tier that sits between Vulnerability and Informational.
Tier 1: Vulnerability (High / Critical)
A specific, fixable code-level mistake that creates an unintended extraction surface.
Criteria:
- Missing or ignored
minAmountOut/minAmountInin swap or liquidity functions - Missing
deadlineparameter that enables stale transaction execution - Use of spot price (DEX balance ratio,
getReserves()at execution time) as a price oracle in any lending, minting, or redemption path - Commit-reveal secret derivable from on-chain state or too short to be secure
- Reveal function not bound to
msg.sender, allowing front-run of the reveal itself - Single-source oracle for any function with non-trivial financial consequence
- Liquidation function callable with
amount = 0or with parameters that allow griefing (repeated zero-value liquidations to block genuine liquidators) - Transaction ordering dependence where the outcome of a state-changing function can be manipulated by a third party inserting a transaction within the same block, and the protocol provides no protection
Remediation pattern: Code change. The fix is deterministic and contained.
Example finding:
[HIGH] SwapRouter.swapExactInput() does not accept a minAmountOut parameter.
All swaps are executable with zero slippage protection, enabling complete
extraction of user funds via sandwich attack with no limit on loss per transaction.
Recommendation: Add minAmountOut and deadline parameters. Revert if
amountOut < minAmountOut or block.timestamp > deadline.Tier 2: Design Risk (Medium / Low)
A design choice that creates MEV exposure beyond what is inherent to the protocol class, but where the “correct” design is debatable or involves a tradeoff.
Criteria:
- Fixed liquidation bonus calibrated significantly above gas cost + execution risk floor (excess bonus is pure MEV transferred to searchers)
- Push oracle with known heartbeat interval used for a derivative protocol, without any fee or penalty to counteract latency arbitrage
- Dutch auction liquidation with start price already in the profitable range (defeats the purpose)
- Dutch auction with duration too short to differentiate between competing liquidators under high network load
- Commit-reveal used in a multi-party context without last-revealer mitigation
- Protocol-level integration of a single private RPC as a dependency for safe operation
- Large single-sided liquidity additions allowed without TWAP-based price sanity check (enables LP manipulation vector)
Remediation pattern: Parameter change, architectural recommendation, or documentation of accepted risk. The designer must make a tradeoff decision.
Example finding:
[MEDIUM - DESIGN RISK] The liquidation bonus is hardcoded at 8% with no
governance override. At current gas prices on mainnet, a viable liquidation
requires approximately 1.5% bonus to cover costs. The remaining 6.5% is
pure MEV transferred to searchers, unnecessarily disadvantaging borrowers.
Recommendation: Consider a Dutch auction model or a governance-adjustable
bonus parameter. If the fixed bonus is intentional, document the rationale.Tier 3: Informational / MEV Exposure Disclosure
Inherent MEV exposure that is a property of the protocol class and cannot be eliminated without changing the fundamental design. No code fix is recommended — documentation and user education are the appropriate responses.
Criteria:
- AMM swap function is sandwichable when user supplies a non-zero
minAmountOutbut sets it to maximum slippage (user choice, not a protocol bug) - Cross-DEX arbitrage opportunities created by any trade (inherent to AMM design)
- Liquidation events are visible on-chain and will attract competitive searchers (inherent to any open liquidation system)
- Pull oracle latency creates a finite window of opportunity between real-world price and on-chain price (inherent to oracle architecture)
- Block proposer can theoretically reorder transactions within a block they produce (inherent to proof-of-stake)
Remediation pattern: Documentation. Recommend private mempool integration at the UI/wallet layer as a user-experience improvement. Note in security documentation that the protocol has inherent MEV exposure of type X.
Example finding:
[INFORMATIONAL] The AMM pool is subject to sandwich attacks when users
supply high slippage tolerances. This is inherent to the AMM design and
is not a protocol vulnerability. The swap function correctly enforces
caller-supplied minAmountOut. Users submitting transactions through the
public mempool with high slippage tolerance may be sandwiched.
Recommendation: The front-end should encourage tight slippage settings
and offer integration with a private RPC endpoint (e.g., Flashbots Protect,
MEV Blocker) as an opt-in feature.Quick Reference
| Pattern | Default Category | Escalates To |
|---|---|---|
Missing minAmountOut | Vulnerability (High) | Critical if funds can be fully drained |
Missing deadline | Vulnerability (Medium) | High if paired with missing slippage |
| Spot price oracle | Vulnerability (Critical) | — |
| TWAP oracle (short window) | Design Risk (Medium) | Vulnerability on low-liquidity assets |
| Fixed liquidation bonus (miscalibrated) | Design Risk (Medium) | Vulnerability if bonus enables self-liquidation |
| Dutch auction (poorly parameterized) | Design Risk (Low/Medium) | — |
| Short commit-reveal secret | Vulnerability (High) | — |
| Last-revealer attack (multi-party) | Design Risk (Medium) | Vulnerability if randomness is safety-critical |
| Reveal front-runnable (no sender binding) | Vulnerability (Medium) | High if auction bids can be stolen |
| Private mempool as security dependency | Design Risk (Low) | — |
| Inherent AMM sandwich exposure | Informational | — |
| Cross-DEX arbitrage | Informational | — |
| Liquidation competition (gas wars) | Informational | Design Risk if bonus is excessive |
Conclusion
MEV is not something auditors can patch away. It is encoded in the structure of public blockchains: anyone with visibility into the mempool and control over transaction ordering can, in principle, extract value. The auditor’s contribution is not to declare all MEV “exploitable” — that would make every DeFi protocol unfixably broken — but to identify the specific design choices that create unintended extraction surfaces.
The clearest signal of a protocol vulnerability in this space is when the designers obviously intended a behavior (users get a fair price, liquidations are competitive, committed values are private) but the code fails to enforce it. minAmountOut = 0, spot price oracles, and commit secrets derived from block timestamps are all examples of code that fails to enforce the designer’s stated intent.
Design risks are subtler: they are cases where the protocol works as designed, but the design transfers value to searchers in ways that were either not fully modeled or not documented. Liquidation bonuses that far exceed execution costs, push oracle integrations in derivatives protocols, and Dutch auction curves that are poorly calibrated all fall into this category.
Everything else is informational: documented, disclosed, mitigated at the infrastructure layer where possible, and accepted as the cost of building on a transparent, orderless ledger.
A rigorous audit report in this space does all three things — and never conflates them.