Uniswap V4 Hooks MEV 2026: Searcher Opportunities and Risks

Cross-posted from— the canonical version lives on the FRB Research blog. This DEV.to mirror exists so the dev community can engage in comments.[ai-frb.com]

Answer first — Uniswap V4 hooks turn each pool into a programmable contract with custom logic at swap, modify-liquidity, and donate boundaries. For searchers, this creates three new opportunity categories — custom-curve arbitrage between hook-altered prices and reference AMMs, dynamic-fee front-of-block races where hook fee logic can be predicted, and JIT-style liquidity hooks that legally extract value via beforeSwap/afterSwap callbacks. It also introduces new risks: hook reentrancy traps, asymmetric gas costs, and pool-specific simulation requirements that break "universal" arb bots designed for V2/V3 invariants.

A V4 pool isn't just x * y = k

with a fee tier. It's a PoolKey

plus a deployed IHooks

contract that can interpose logic at up to ten callback points:

The two that matter for searchers are beforeSwap

and afterSwap

. These let a pool implement dynamic fees, custom pricing curves, or per-swap rebalancing — all of which create exploitable asymmetries vs. plain V3 quotes.

V4 hooks can replace the constant-product price calculation entirely. A pool might use a TWAMM curve, a constant-sum stable curve, or a fully oracle-priced curve. When that pool's effective price deviates from the rest of the market, an arb opportunity opens.

The constraint: you cannot price V4 hook pools off-chain using V3 math. Every simulation must invoke the hook's beforeSwap

to get the real quote. This means:

eth_call

on each tickRealistic per-trade arb sizes on hook-altered pools in early 2026: $30–$2,000, with much higher variance than V3. Pools with untested custom curves tend to mispriced for hours before anyone notices, then close once one good searcher writes the simulator.

A common hook pattern is volatility-adjusted dynamic fees — the hook reads a volatility oracle in beforeSwap

and raises fees during turbulence. This creates two MEV plays:

Play A — front-run the fee hike. If the oracle is on-chain and you can predict its next update (e.g. Uniswap's own observation queue), you can route a large swap one block before the hike at the lower fee.

Play B — back-run the fee normalization. When volatility drops and the hook lowers fees, the first trade after the fee change captures unusual elasticity. Watch the oracle's "decay" function and queue a bundle that fires immediately after.

Both require per-pool fee-prediction logic. Generic bots that assume a static 5/30/100 bps tier will mis-price these pools by 10–50 bps consistently. See How Fast MEV Bots Execute for the latency budget this implies.

V3 JIT (just-in-time) liquidity required searchers to wrap a swap with mint and burn in the same block. V4 hooks let a pool internalize JIT — the hook itself adds and removes liquidity around incoming swaps, capturing the LP fees.

For an external searcher, this changes the strategy: hasPermission(BEFORE_ADD_LIQUIDITY_FLAG)

) to know whether your mint will trigger extra callbacks.The on-chain check is one storage read. Skip pools where internal JIT is active and focus capital on the half of the market without it. See JIT Liquidity Strategy Explained for the underlying mechanic.

V4's singleton design means all pools share state in the PoolManager

. A malicious hook can call back into the manager during your swap and front-run your own bundle from inside the callback. This isn't theoretical — early V4 audits flagged several hook patterns that allow exactly this.

Defensive rules:

beforeSwap

consumes >200k gas in simulation, treat it as hostile and exclude the pool.Hook callbacks make gas cost a function of the pool, not the swap size. A simple swap through a complex hook can cost 250k gas; the same swap through a no-hook pool costs 95k. If your arb model assumes uniform gas, your "profitable" trades will lose money on hook-heavy paths.

Track per-pool gas cost over a rolling window of executed swaps. Update your profitability threshold per pool, not per chain. The bots that survive 2026 V4 trading will have per-pool unit economics.

The biggest operational risk: your off-chain simulator can drift from on-chain reality if a hook upgrades. Some hooks are upgradeable proxies. A silent upgrade can change the pricing curve mid-day and your bot will keep submitting bundles based on stale logic.

Mitigation:

| Dimension | Uniswap V3 | Uniswap V4 + Hooks |

|---|---|---|
| Pricing math | Universal (concentrated liquidity) | Pool-specific (custom curves) |

| Fee logic | Static tiers (1, 5, 30, 100 bps) | Dynamic per-swap | | Gas cost | Predictable | Pool-dependent (95k–280k) | | JIT viability | Always | Depends on hook flags | | Sim complexity | Off-chain math | On-chain simulation required | | Profitable bot type | Generic invariant solver | Per-pool specialist |

The shift is from invariant solvers to per-pool specialists. Searchers who tooled up early on hook-aware simulation are extracting outsized share because most existing bots have not adapted.

A robust V4 bundle structure for arb:

swap(poolKey, params) against forked state at current blockbeforeSwap

The third step — accurate gas inclusion — is where most non-specialist bots lose money on V4. See Profitability Gas Budget Calculator for the calculation framework.

FRB Agent supports Uniswap V4 swaps on Ethereum mainnet, Base, Arbitrum, Optimism, and Polygon through its multi-chain DEX router. The simulation layer auto-detects hook contracts and applies per-pool gas adjustment when building atomic-arbitrage bundles. Hook whitelisting is configurable per chain in the dashboard — the default ships with Uniswap Labs' published hook list and the user can extend it.

What the agent does not do: decompile arbitrary unknown hooks. If a pool's hook is not on the whitelist, the agent skips it. This is by design — running blind through unverified hooks is the fastest way to lose your inventory to a malicious pool.

Indicative early-2026 monthly returns for a $30k inventory solo searcher running V4-hook-aware arb across mainnet + Base + Arbitrum:

These are illustrative, not promises. The distribution skews more positive than V3 arb because the simulator competition is thinner — but a single hook-misclassification incident can wipe a month. See the FRB risk disclosure for the full risk model.

Originally published on the FRB Research blog. Discuss MEV strategy with the team at ai-frb.com.