Sigvex
EVMRemediation2 min read

MEV Vulnerabilities Remediation

How to reduce order-flow exploitation with slippage bounds, deadlines, commit-reveal, and private submission.

evmmev

MEV Vulnerabilities Remediation

Overview

Related Detector: MEV Vulnerabilities

MEV extraction profits from controlling where a transaction lands in a block: sandwiching a slippage-free swap, front-running a liquidation, back-running an oracle update. You cannot stop ordering games at the protocol level, but you can make them unprofitable. The remediation combines user-supplied slippage bounds and deadlines, commit-reveal for sensitive actions, and — off-chain — private transaction submission.

Before (Vulnerable)

function swap(uint256 amountIn) external {
    // No slippage bound and no deadline — a sandwich attacker sets the price.
    _swap(amountIn);
}

After (Fixed — slippage bound + deadline)

error DeadlinePassed();
error Slippage();

function swap(uint256 amountIn, uint256 minOut, uint256 deadline) external {
    if (block.timestamp > deadline) revert DeadlinePassed();
    uint256 out = _swap(amountIn);
    if (out < minOut) revert Slippage();   // caller caps how much value can be extracted
}

For actions where even bounded slippage leaks value (auctions, liquidations), use a commit-reveal scheme so the intent is hidden until it is committed. Off-chain, submit sensitive transactions through a private mempool/relay to avoid public front-running.

Common Mistakes

  • Accepting a minOut/deadline parameter but letting the front end default them to 0/max, disabling the protection.
  • Relying on a spot price the same transaction can move; combine with a manipulation-resistant oracle.
  • Assuming a private relay alone is enough while leaving the on-chain function unbounded for anyone who does see it.

References