MEV / transaction-order abuse

Front-running

Description:
Front-running is when an attacker or MEV searcher deliberately inserts their transaction just before a target transaction to gain an economic edge – for example buying before you to profit from your price impact, or grabbing an arbitrage you have uncovered.

How it works:
Attackers watch the public mempool (and private order-flow channels where they have access). When they see a profitable victim transaction – a large DEX trade, a liquidation opportunity, a mint, an oracle update – they submit their own transaction:

• with a higher gas price / priority fee, or
• inside a custom bundle to a block builder or validator,

so that it is mined just before the victim. If successful, the attacker captures the opportunity and may leave the victim with a worse price, reverted trade, unexpected liquidation or higher gas spent.

Known patterns in the wild:
On Ethereum, BNB Smart Chain and other EVM chains, on-chain studies show large volumes of front-running around DEX trades, liquidations and NFT mints. Many of these are “classical” arbitrage or liquidation bots; others are abusive, such as racing in front of users’ swaps purely to extract a spread.

sharesToMint = (depositAmount * totalXardmSupply) / totalArdmInPool

deposit(20_000e18)

ARDM.transfer(pool, 20_000e18)

sharesToMint ≈ (20_000e18 * 1) / (20_000e18 + 1) ≈ 1

Best practices and security advice:

For users and integrators:

• Prefer DEX front-ends that offer some MEV protection (batch auctions, RFQ systems, or private routing to builders).
• Use reasonable slippage limits; avoid huge “just make it go through” tolerances.
• For large or sensitive trades, consider using protocols that do off-chain matching then on-chain settlement in batches, which weakens single-transaction front-running.

Developer / architect notes:

• Design critical operations so that a single public transaction does not reveal a “free lunch” – use commit-reveal, auctions or batched execution for things like mints, liquidations and large rebalances where possible.
• Where strict ordering matters (e.g. for rebalances or vault accounting), make functions idempotent and resilient to being called just before or after another related call, rather than assuming a specific ordering.
• Be explicit that your protocol is transaction-order dependent, and test under adversarial ordering – fuzzers and formal tools now exist that specifically model reordering attacks on DeFi.

Back-running

Description:
Back-running is the mirror image of front-running: the attacker (often an arbitrageur or liquidator) deliberately places their transaction immediately after a target transaction to harvest the state change it creates – for example restoring a DEX price after a large trade, or liquidating a position after the protocol marks it under-collateralised.

How it works:
Back-running usually follows a three-step logic:

1. Observe a pending victim transaction that will create a profitable condition (mispriced pool, liquidatable position, juicy arbitrage route).
2. Simulate the chain with that transaction included to compute the optimum response.
3. Submit a transaction (or bundle) that is executed directly after the victim, capturing the new value before anyone else.

In many lending protocols this manifests as extremely fast liquidations: as soon as collateral ratios move, specialised bots back-run the triggering transaction to seize collateral with minimal risk.

Best practices and security advice:

• Accept that benign back-running is part of healthy price discovery and liquidation.
• Design your liquidation and auction mechanisms so they are competitive, transparent and minimise insider advantage – for example sealed-bid or batch auctions instead of “first call wins” liquidations.
• Where user welfare is a concern (e.g. leverage products marketed to retail), consider “cool-down” windows or more gradual liquidation curves rather than instant, all-or-nothing liquidations at a single threshold, to reduce the impact of highly optimised back-running bots.

Developer / architect notes:

Back-running risk increases any time your protocol exposes predictable “one-block” edges: discrete jumps in prices, sharp kinked payoff curves, or binary state changes. Run adversarial simulations where a sophisticated agent always gets to trade one transaction after any user and see whether that produces pathological behaviour, cascades or unfair outcomes.

Sandwich attacks

Description:
A sandwich attack is a specific pattern where an attacker both front-runs and back-runs the same victim trade: they buy before the victim to push the price against them, then sell after the victim to lock in profit. The victim ends up “sandwiched” between the attacker’s buy and sell and suffers a worse execution price.

How it works:
Most sandwich attacks target constant-product AMMs:

1. The victim submits a swap with a visible maximum slippage (for example “I will accept at most 2% price impact”).
2. The attacker front-runs with a buy order that moves the price up (for victim buying) or down (for victim selling) as far as possible while still keeping the victim’s trade executable under their slippage limit.
3. The victim’s swap executes at the now-worse price.
4. The attacker immediately back-runs with a sell in the opposite direction, returning the pool price closer to where it started and capturing the difference as profit.

The attacker often routes through flash loans to amplify the price movement without upfront capital, and uses private transaction relays or bundles to ensure both legs land around the victim.

Known patterns:
On major DEXes, sandwiching is one of the best-studied abusive MEV strategies. Analyses repeatedly show bots scanning pending swaps for loose slippage and low gas prices, flagging them as ideal sandwich targets.

Best practices and security advice:

For users:

• Keep slippage tight, especially on volatile or illiquid pairs.
• Avoid public mempool routing for very large trades where possible; use RFQ-style or batch-auction venues when they are available.
• Be wary of trading during thin-liquidity periods where a small trade can move price a lot.

For protocol designers:

• Use designs that reduce single-trade price impact (e.g. dynamic fee curves, concentrated liquidity with careful guardrails, or batch auctions that clear many trades at once).
• Consider integrating with order-flow auctions or MEV-sharing schemes so that users capture some of the value instead of giving it all to external searchers.
• Expose an explicit “no-sandwich” mode (private routing, match-then-settle) for wallets that want to opt into protection.

Developer / architect notes:

Explicitly model your swap function under attacks where an adversary trades immediately before and after the user within their slippage limit. Look for situations where the user consistently loses value even though the trade technically executes “within tolerance” – that is the hallmark of a structurally sandwichable design.

Front-running / ERC-20 approval

Description:
Classic ERC-20 approvals suffer a race condition. If a user changes an existing allowance from X to Y using a single approve call, a malicious spender can front-run the change and spend the old allowance before the new value takes effect. This is a logic flaw in the pattern, not in any single token.

How it works:
The vulnerable flow looks like this:

• The user has already approved spender S for amount A.
• They now wish to change that to amount B (often smaller than A).
• Their wallet sends approve(S, B).
• A malicious or compromised S watches the mempool, sees the user trying to reduce the allowance, and quickly submits transferFrom for the full old allowance A.
• If the malicious transferFrom is mined first, S drains up to A tokens; the later approve call then quietly updates the allowance to B, hiding the theft behind a “successful” transaction.

Best practices and security advice:
For end users and front-ends:

• When changing allowances, use the pattern “set to zero, then set to new value” wherever the token supports it.
• Avoid granting unlimited approvals to arbitrary dApps; prefer per-use approvals for high-value tokens.
• Regularly review token allowances and revoke ones you no longer need.

Developer / architect notes:
On the token side:

• Implement increaseAllowance and decreaseAllowance helpers so that dApps and wallets never need to overwrite a non-zero allowance directly.
• Where backwards compatibility allows, consider reverting when approve attempts to change a non-zero allowance directly to a different non-zero value.

On the dApp side:

• Use the “set to zero then set to new value” pattern when interacting with plain ERC-20s.
• Prefer EIP-2612 style permit flows with nonces and deadlines; these avoid the specific approve race, though they introduce their own signature-handling surface you must secure (see “Front-running – signatures” below).

Front-running – signatures and off-chain orders

Description:
Many protocols accept off-chain signed messages – orders, permits, meta-transactions – that anyone can submit. If those signatures are not tightly bound to who may relay them, to which contract, chain and time window, an attacker can copy the signature and front-run the intended relayer, or reuse it in a different context.

How it works:
The basic flow:

1. A user signs a structured message (for example a permit giving a relayer permission to spend tokens, or a limit order for an RFQ system).
2. The signature is broadcast or visible (e.g. sent over an unencrypted channel, leaked via logs, or later posted on-chain).
3. Because the contract verification logic does not pin all relevant parameters – such as chain ID, expected relayer, or a strict deadline – anyone can take that signature, wrap it in their own transaction, and submit it first.

In some designs, this lets an attacker:

• steal funds via a front-run permit spend,
• execute an order on a different market or price environment than intended, or
• grief the user by consuming nonces or honouring stale orders in a new context.

Best practices and security advice

For users:

• Never sign arbitrary blobs you do not understand; prefer wallets that show human-readable EIP-712 messages.
• Treat generic “increase allowance” or “permit” pop-ups from unknown sites as highly suspicious.

For protocol and wallet authors:

• Use EIP-712 typed data with explicit domain separation (name, version, chainId, verifyingContract) so signatures cannot be replayed onto other chains or contracts.
• Enforce strict, short deadlines and unique nonces for all signed messages; reject signatures with stale deadlines or reused nonces.
• Where appropriate, bind signatures to a specific relayer or execution context so that only the intended party can submit them.
• Carefully log which messages have been consumed so you can detect replay attempts.

DeFi slippage attacks

Description:
A DeFi slippage attack focuses on abusing a user’s slippage tolerance or a bot’s execution logic, rather than only the AMM curve itself. The attacker either:

• crafts trades that cause a victim with loose slippage to execute at a terrible price, or
• lures naive MEV / arbitrage bots into executing “profitable” transactions that are actually toxic once all steps are included.

How it works:
Two common patterns:

1. User-targeted slippage abuse
   An attacker sees a pending trade with very loose slippage and low gas. They layer in their own transactions that push the price right to the edge of that tolerance, sometimes involving multi-hop paths or flash loans, leaving the user with maximum legal slippage even if there is no “obvious” sandwich pattern.
2. Bot-targeted slippage abuse
   Here the victim is an MEV bot. The attacker constructs complex transaction sequences that appear to present an arbitrage, but only if the bot ignores parts of the path (for example a hidden transfer or fee). When the bot executes the bundle, it ends up paying the attacker. Several real-world incidents on BNB Chain and other networks have seen bots drained by carefully crafted toxic order-flow.

Best practices and security advice:

For users:

• Keep slippage limits tight, especially on illiquid or meme-heavy pairs.
• Avoid signing blindly-generated trades from unknown Telegram bots or web front-ends that may deliberately set huge tolerances.

For MEV / arbitrage bot authors:

• Fully simulate every path, including fees, rebates and transfers, not just nominal pool prices.
• Add explicit toxicity checks – if the expected profit margin is tiny compared with gas and path complexity, treat it as suspect.
• Include heuristics to avoid interacting with obviously malicious or short-lived pools.

For DEX and router designers:

• Expose explicit user-side controls for slippage, and avoid quietly inflating tolerances “to reduce failed trades”.
• Consider smart-order routers that avoid obviously toxic routes, even if a naive expected-value model says they are marginally profitable.
• Where possible, design liquidity incentives and fee structures that discourage extremely shallow or transient pools whose main purpose is to trap bots and inattentive traders.

Proxy initialisation front-running

Description:
Proxy initialisation front-running is where an attacker races to call the initializer function of a newly-deployed upgradeable proxy before the legitimate deployer does. If successful, the attacker can set themselves as the admin or implementation, gaining effective control over the contract and any assets routed through it.

How it works:
The vulnerable pattern:

1. A developer deploys a proxy contract (for example an ERC-1967 or transparent proxy).
2. The proxy is deployed uninitialised, with an initializer function that anyone can call once.
3. The deployer submits an initialise transaction setting the admin, implementation and core parameters. This transaction sits in the public mempool.
4. An attacker’s bot watches for newly deployed uninitialised proxies and pending initialise calls. When it sees one, it constructs its own initialise transaction with higher priority, pointing the proxy at a malicious implementation or setting themselves as the admin.
5. If the attacker’s transaction is mined first, the proxy is now initialised under their control; any later initialise call from the rightful deployer will revert.

Recent research and live incidents have shown that systematic scanning for uninitialised proxies and racing their initialisation can threaten tens of millions in assets if not mitigated.

Best practices and security advice:

For developers:

• Wherever possible, initialise proxies atomically in the same transaction as deployment (deploy-and-call patterns) so there is no open window for a race.
• Use well-audited libraries (such as widely used upgradeable proxy patterns) and follow their guidance on initialisation; avoid writing your own proxy scaffolding from scratch.
• Ensure the initializer function is protected by modifiers that enforce “only once” semantics and, where feasible, restrict who can call it.

For auditors and security teams:

• Include explicit checks for uninitialised proxies in your review process and continuous monitoring.
• Treat any proxy left uninitialised post-deployment as a critical finding; if you cannot fix it, at least ensure no user funds are routed through it.

Developer notes:

Proxy initialisation front-running sits at the intersection of MEV and access-control. Model your deployment process as an adversarial environment: assume somebody is watching mempool and can call any public function before you. If your upgradeability pattern fails under that assumption, redesign it before you ship.

Further reading

MEV Explained – a16z crypto
https://a16zcrypto.com/posts/article/mev-explained-newsletter/

SoK: Preventing Transaction Reordering Manipulations in Smart Contracts – Heimbach et al. (2022)
https://arxiv.org/abs/2106.01350

Mitigating Blockchain Extractable Value Threats by Transaction Order Management – Zhao et al. (2025, arXiv)
https://arxiv.org/abs/2503.06279

Mitigating Blockchain Extractable Value Threats by Distributed Transaction Sequencing – Zhao et al. (2025, ScienceDirect)
https://www.sciencedirect.com/science/article/pii/S2352864825000409

Mitigating Blockchain Extractable Value Threats by Distributed Transaction Sequencing Strategy – Zhao et al. (2025, ResearchGate)
https://www.researchgate.net/publication/391257209_Mitigating_Blockchain_Extractable_Value_threats_by_Distributed_Transaction_Sequencing_Strategy

What Are Sandwich Attacks in DeFi? – Trust Wallet
https://trustwallet.com/blog/security/what-are-sandwich-attacks-in-defi

ERC-20 Approve Race Condition Vulnerability – SolidityScan report 1
https://solidityscan.com/published-report/block/31e2741c4a0d21d9

ERC-20 Approve Race Condition Vulnerability – SolidityScan report 2
https://solidityscan.com/published-report/block/e4fef6f4e1e80b7a

Immunefi Top 10 Smart Contract Vulnerabilities (incl. Uninitialized Proxy)
https://immunefi.com/immunefi-top-10/

Wormhole Uninitialized Proxy Bugfix Review – Immunefi
https://medium.com/immunefi/wormhole-uninitialized-proxy-bugfix-review-90250c41a43a