Front-Running and MEV Exploit Generator

Overview

The front-running and MEV exploit generator validates findings from the mev-vulnerabilities and frontrunning detectors by simulating how a contract’s state changes when a searcher transaction is inserted before or after a victim transaction. The primary focus is on sandwich attacks (buy-victim-sell) and liquidation front-running, both of which exploit the public mempool and predictable transaction ordering.

MEV (Maximal Extractable Value) extraction exceeded $700M in 2023 across all EVM chains. Sandwich attacks on DEX swaps are the largest subcategory, silently extracting value from user transactions by exploiting slippage tolerance.

Note: Exploit generation in Sigvex is for vulnerability validation purposes only.

Attack Scenario

Sandwich attack on a DEX swap:

1. Setup: A victim submits a swap transaction (e.g., sell 100 ETH for USDC with 1% slippage tolerance). This transaction is visible in the mempool before execution.
2. Front-run (buy): The searcher detects the pending transaction and submits a buy transaction with a higher gas price. This executes first, pushing the token price up within the DEX pool reserves.
3. Victim executes: The victim’s transaction executes at the now-elevated price, receiving fewer USDC than expected. The trade still falls within slippage tolerance, so it does not revert.
4. Back-run (sell): The searcher immediately sells the tokens they bought in step 2, now at the elevated post-victim price.
5. Impact: The searcher profits the spread. The victim loses value up to their slippage tolerance limit (up to 1% on each trade).

Liquidation front-running:

1. A borrower’s collateral ratio drops below the liquidation threshold due to a price feed update.
2. Multiple liquidators see the opportunity in the mempool simultaneously.
3. The winner is whoever submits the highest gas price (priority fee), not whoever identifies the opportunity first.
4. Liquidation bots extract significant MEV by monitoring oracle updates and racing to be first.

NFT sniping:

1. An NFT is listed at below-market price.
2. Bots monitor mempool for listing transactions.
3. A bot front-runs the listing or the first buyer, acquiring the NFT and immediately relisting at market price.

Exploit Mechanics

The generator configures the pool’s reserves and gas price environment across three scenarios:

Scenario	Reserve0	Reserve1	Gas price	Description
1 — Normal	1,000 ETH	2,000,000 USDC	20 gwei	Baseline
2 — After front-run	900 ETH	2,200,000 USDC	20 gwei	Price moved against victim
3 — After sandwich	950 ETH	2,100,000 USDC	5 gwei	Post-attack equilibrium

The generator checks whether the output received in Scenario 2 differs significantly from Scenario 1. A price discrepancy exceeding MAX_ACCEPTABLE_SLIPPAGE (configurable) confirms the transaction is vulnerable to sandwich extraction.

For the MEV simulation, the calldata targets the swap function with amountOutMin set to the victim’s acceptable minimum. If the reserve manipulation causes amountOut < amountOutMin, the swap would revert with slippage protection — but if slippage tolerance is too high, the swap succeeds with reduced output.

The generated PoC demonstrates the sandwich attack bot structure:

contract SandwichBot {
    function sandwich(
        address pool,
        uint256 attackAmount,
        uint256 victimAmountIn,
        uint256 victimAmountOutMin
    ) external {
        // Step 1: Buy (front-run) — higher gas price
        swap(pool, attackAmount, 0); // push price up

        // Step 2: Wait for victim tx to execute (different block/order)
        // victim receives: less than victimAmountOutMin would allow

        // Step 3: Sell (back-run) — profit from price recovery
        swap(pool, 0, attackAmount); // sell at elevated price
    }
}

Remediation

• Detector: Front-Running Detector
• Remediation Guide: Front-Running Remediation

For DEX swaps, set a tight amountOutMin based on TWAP prices:

// VULNERABLE: 10% slippage tolerance — profitable sandwich window
function swap(uint256 amountIn, uint256 amountOutMin) external {
    // amountOutMin is set too low by the user interface
}

// BETTER: compute minimum from TWAP, not spot price
uint256 twapPrice = oracle.getTwap(pair, 1800); // 30-minute TWAP
uint256 amountOutMin = amountIn * twapPrice * 99 / 100; // 1% max slippage from TWAP

For protocols that cannot avoid MEV, consider:

• Commit-reveal: Submit a hash of the transaction parameters, then reveal later.
• Private mempools: Use Flashbots Protect, MEV Blocker, or similar services to route transactions directly to validators without public mempool exposure.
• Auction mechanisms: Replace first-come-first-served with sealed-bid auction patterns where ordering cannot be gamed.

References

• Flashbots Research: MEV Taxonomy
• MEV-Boost: Validator MEV Infrastructure
• Uniswap: Slippage and Price Impact
• Fomo3D: Block-stuffing and front-running exploitation (2018)