.svg){kind=icon}
.svg)
.svg)
.svg)
.svg)
.svg)
.svg){kind=icon}
.svg)
.svg)
.svg)
.svg)
Smart contract security researcher focused on the EVM, StarkNet, and Solana ecosystems, with experience auditing high-value decentralized finance and infrastructure protocols.
Now hiring!
•
Imagine a trader who spots a good trading opportunity in the market. They sign the transaction, hit confirm, and wait. But when the transaction settles, they notice that they bought the token at a higher price than expected. When trading on a DEX, this isn’t something unusual; they might’ve been the target of an MEV bot.
The public nature of blockchain transactions presents some challenges. While transparency ensures trustworthiness, it also exposes a user's intent before their action is finalized. The time gap between signing a transaction and its inclusion in a block is where frontrunning can occur.
As smart contract security researchers, we see the impact of frontrunning firsthand, particularly within Automated Market Makers (AMMs). Frontrunning other users’ trades is a sophisticated economic operation that drains millions from users and protocols annually.
To understand the meaning of frontrunning, one must first understand the mempool. When a transaction is sent to the network (for example, a swap transaction on a DEX like Uniswap), the transaction doesn't execute instantly. It enters a “waiting area” called the mempool, where it sits until it is picked up by validator nodes to be confirmed.
Validators select transactions from this pool to build the next block. Validators are financially incentivized to prioritize transactions that pay the highest gas fees.
It is the act of spotting a pending transaction in the mempool (i.e., a token swap transaction) and submitting your own transaction with a higher gas fee to ensure it gets processed before the original transaction.
Because the transaction data is visible, sophisticated bots can simulate the trade against the current state of the AMM. If they detect a profit opportunity, they copy the logic, pay a higher “bribe” (gas fee), and get their transactions processed before the original one.
Frontrunning is just one facet of a larger phenomenon known as MEV. Originally, this acronym stood for Miners Extractable Value, referring to the profit miners could extract by processing blockchain transactions.
MEV in crypto has become an industrial-scale operation involving "Searchers" (who run bots) and "Builders" (who bundle transactions). While some MEV is benign, "toxic" MEV, like sandwich attacks, directly harms users.
The most notorious form of frontrunning in AMMs is the sandwich attack. This occurs when an MEV bot detects a large swap order pending in the mempool.
In an AMM relying on the constant product formula where x * y = k, a large buy order inevitably pushes the price up. To demonstrate how the attack unfolds, let’s look at some vulnerable code.
Frontrunning often exploits poorly constructed slippage checks. Consider this naive swap function that ignores minimum output amounts:
// VULNERABLE CODE EXAMPLE
function naiveSwap(address tokenIn, uint256 amountIn) external {
// assume some checks take place here before the actual swap
// Interaction with the AMM
IERC20(tokenIn).transferFrom(msg.sender, address(this), amountIn);
// No minimum amount out specified -> no slippage protection
AMM.swap(tokenIn, amountIn, 0);
}
In the code above, the 0 in the swap function represents 100% slippage tolerance. A frontrunning bot sees this and knows they can manipulate the price before this transaction executes, and the trade will still succeed, forcing the victim to swap at a very unfavorable price.
Imagine that Alice calls the naiveSwap function above to swap 10,000 USDC for ETH.
Here is how the attack unfolds in the mempool:
0, the contract accepts any price as being valid.naiveSwap function lacked a slippage check.
To prevent this, smart contracts must enforce strict slippage parameters.
// SECURE CODE EXAMPLE
function secureSwap(
address tokenIn,
uint256 amountIn,
uint256 minAmountOut, // Slippage protection
) external {
// assume some checks take place here before the actual swap
IERC20(tokenIn).transferFrom(msg.sender, address(this), amountIn);
// The transaction will REVERT if the frontrunner pushes
// the return amount below minAmountOut
uint256 actualAmountOut = AMM.swap(tokenIn, amountIn, minAmountOut);
require(actualAmountOut >= minAmountOut, "Insufficient output amount");
}
By adding a minAmountOut parameter and enforcing that actualAmountOut >= minAmountOut, the user defines the "worst" price they are willing to accept. If a sandwich bot tries to frontrun this transaction to alter the price, the require statement at the end will cause the victim's transaction to revert, protecting their capital. The attacker's strategy fails, and the MEV bot wastes money on gas.
Not all MEV strategies involve frontrunning. Some happen immediately after.
Backrunning is the practice of submitting a transaction designed to be executed immediately after a target transaction. A common example is arbitrage.
A more sophisticated form of MEV in concentrated liquidity AMMs (like Uniswap V3) is Just In Time Liquidity.
While JIT liquidity actually gives traders better execution prices (less price impact due to deeper liquidity), it discourages passive liquidity providers (LPs) by stealing their yield since most of the fees from that particular swap will go to the MEV bot instead of going to long-term LP position holders.
Let's imagine a USDC/ETH pool with a 0.3% swap fee.
If a trade happens now, Bob and Charlie would split the swap fees 50/50 because they each own 50% of the active liquidity.
Without Alice, Bob and Charlie would have split the $3,000 fee. Because of the JIT liquidity “attack”, they only earned $15 each. Alice got 99% of the fee from that swap, impacting the yield of the other liquidity providers.
As long as validators choose which transactions to include and in what order, MEV exists. The spectrum runs from benign to damaging: arbitrage bots rebalance prices across markets, JIT liquidity improves execution for traders even while it erodes passive LP yields, and sandwich attacks simply take money from users who left the door open. What separates these outcomes is not the MEV infrastructure itself, but whether the smart contracts being targeted gave attackers anything to exploit.
The mempool is public, and every pending transaction is a statement of intent readable by anyone running a bot. That asymmetry does not go away, but what developers can control is how much that visibility costs their users. A single minAmountOut check is the difference between a trade that reverts safely and one that hands 80% of a user's value to a bot. Assume every transaction is being watched and build accordingly.
Need a smart contract code security review? Contact our security team today for a comprehensive audit.
The Leading Engineers of Blockchain Infrastructure
Nethermind © 2026
.svg)