Front-Running / MEV

Blockchain transactions sit in a public mempool before miners include them in a block. Bots and miners can observe pending transactions and insert their own transactions with higher gas fees to get ahead — a practice known as Miner Extractable Value (MEV) or front-running.

How it works

Common front-running scenarios include:

• Sandwich attacks: Bot buys an asset before your swap, then sells after — profiting from the price impact you caused.
• Displacement: A bot copies your transaction (e.g., claiming a governance reward) with higher gas and gets there first.
• Suppression: Miners delay or exclude transactions to extract value.

Vulnerable pattern

// VULNERABLE — first caller wins the reward (race condition)
function claimReward(uint solution) public {
    require(keccak256(solution) == targetHash);
    payable(msg.sender).transfer(reward);  // front-runner can copy this call
}

Mitigated pattern (commit-reveal)

// SAFER — commit-reveal scheme hides the solution until committed
mapping(address => bytes32) public commits;

function commit(bytes32 hash) public {
    commits[msg.sender] = hash;  // hash of (solution + secret)
}

function reveal(uint solution, bytes32 secret) public {
    require(commits[msg.sender] == keccak256(abi.encode(solution, secret)));
    require(keccak256(solution) == targetHash);
    payable(msg.sender).transfer(reward);
}

Real-world examples

• Uniswap traders lose millions daily to sandwich bots.
• NFT minting races where bots capture rare items before retail users.
• DEX arbitrage bots that capture price differences across pools.

How to reduce MEV risk

• Use commit-reveal schemes for competitive on-chain games.
• Add slippage tolerance checks and minimum output amounts on DEX trades.
• Use Flashbots or private RPC endpoints (like MEV Blocker) to bypass the public mempool.
• Design protocols to be order-independent where possible.