DEV Community: FRB Research

EIP-7702 MEV 2026: How Account Abstraction Reshapes Searcher Strategy

FRB Research — Mon, 08 Jun 2026 07:45:22 +0000

Answer first — EIP-7702 lets any EOA temporarily attach a smart-contract code path for a single transaction (a "delegation"). For MEV in 2026, this means three structural shifts: multi-action transactions from regular wallets (batched approve+swap+claim, harder to front-run), sponsored bundles where a paymaster covers gas (changing the inclusion economics of priority fees), and new attack surface where malicious delegation targets can drain wallets if users sign blindly. Searchers must update their mempool parsers, MEV-share subscriptions, and revert guards to recognize 7702-style transactions, which look different on the wire than legacy EOA calls.

What 7702 Actually Does

In the pre-7702 world, an Ethereum transaction was either:

EOA-originated: A normal user wallet calls a contract directly. One target address. One value transfer or one method call per transaction.
Contract-originated (smart wallet / 4337): A smart-contract wallet (Safe, Argent, Kernel, Biconomy) can batch many operations into one transaction, but needs to be deployed first.

EIP-7702 adds a third path: an EOA can include a SetCodeListItem in the transaction signaling "for the duration of this transaction, treat my account as if it had this contract's code." After execution, the EOA reverts to being a normal externally-owned account.

The practical consequence: batching, gas sponsorship, and session keys without ever deploying a smart wallet.

Why Searchers Care

Three concrete changes to the searcher view of the network:

1. The mempool now contains "multi-action" transactions from regular addresses

Before 7702, when you saw a swap from 0xUser, you could assume it was a single swap. After 7702, the same address could be executing an approve → swap → unwrap → bridge sequence inside one transaction. Your sandwich-and-arb logic needs to parse the delegated code's calldata, not just the top-level method.

If you index transactions by to address, you'll miss 7702 transactions because the to is the user's own EOA — the code runs from a delegation pointer elsewhere. Update your indexer to detect the delegation flag and decode the inner operations.

2. Sponsored bundles change the priority-fee market

A 7702 transaction can include a paymaster signature where a third party pays gas. This means a swap with zero priority fee can still be a valuable inclusion candidate if the paymaster pays the builder a tip out-of-band.

For searchers competing for block space, this means priority fee alone is no longer a reliable ranking signal. Sophisticated builders are already factoring in paymaster reputation and side payments. If your bot only watches base+priority fees, you'll mis-rank profitable 7702 bundles.

3. Session-key transactions enable "patient" front-runs

A 7702 delegation can grant a session key that's valid for many blocks. This enables a new pattern: a user pre-signs a swap "to be executed when conditions X are met," and a searcher submits it at the optimal moment. The signature itself sits in a private mempool or on-chain.

For MEV, this means the front-runnable transaction may be visible long before it's submitted.

New Attack Surface: Delegation Drainers

The biggest 7702-specific risk is users signing a delegation to a malicious contract. A drainer can publish a contract whose code, when delegated to by the user, transfers all approved tokens to the attacker. The user thinks they're signing "a transaction" — but they're signing "be this contract for a block."

If you operate any frontend that requests 7702 signatures:

Show users the delegation target plainly — never bury it in a hex blob.
Limit the delegation duration to a single transaction or a small block window.
Whitelist delegation targets in the wallet UX.

The same logic applies for searchers: a 7702 transaction with an unknown delegation target is high-risk. Treat unknown delegation contracts the same way you'd treat an unverified token — skip the trade.

Sandwich Attacks on 7702 Transactions

A 7702 transaction that batches approve → swap is not safer from sandwich attacks than a standalone swap. Atomic batching prevents the classic "front-run-the-approve-then-front-run-the-swap" pattern, but a single front-back wrap around the entire batched transaction still works at the price-impact level.

What 7702 does change:

Slippage caps are now per-batch instead of per-swap. A 7702 transaction can include conditional logic ("revert if final balance < X") that legacy EOAs couldn't enforce atomically.
MEV-share private orderflow integrations now have a richer signal — instead of opaque calldata, the relay can share "user wants this batch of operations" with searchers.

How 7702 Compares to ERC-4337

Dimension	ERC-4337 (smart accounts)	EIP-7702 (delegation)
Deployment	Requires wallet contract deploy	No deploy — EOA delegates
Cost overhead	~70k gas extra per UserOp	~5k gas per delegation
Batching	Native via UserOperation	Via delegated code
Session keys	Yes (validator-defined)	Yes (delegation-defined)
Sponsorship	Via Paymaster	Via paymaster signature
Mempool format	Alt-mempool (4337 bundlers)	Standard mempool
Wallet UX migration	New wallet required	Existing EOA reused

4337 and 7702 are complementary. 4337 stays for users who want permanent smart wallets; 7702 wins for legacy EOA users who want occasional smart-contract behavior without migrating.

For MEV bots, both must be indexed in 2026. A searcher ignoring 7702 traffic will miss roughly 8–15% of inclusion-worthy transactions on mainnet by mid-2026.

Updating Your Searcher Stack For 7702

Practical checklist:

Mempool decoder: Add type=0x04 (the 7702 transaction type) parsing. Decode the SetCodeListItem array.
Calldata parser: When the delegation target is a known multicall contract, recursively decode the inner calls.
Profitability model: Account for sponsored gas — the priority fee may be zero but the side payment to the builder makes the bundle valuable.
Revert guard: If your bundle sandwich-arbs a 7702 transaction, verify the slippage condition inside the user's batched logic holds at your simulated final state.
Delegation target whitelist: Maintain a list of trusted delegation contracts. Skip transactions delegating to unknown targets.

Bottom Line

EIP-7702 isn't a tactical tweak — it's a structural change to what transactions look like on Ethereum. Bots written against pre-7702 mempool assumptions will progressively underperform as 7702 adoption grows. The window to retool simulation, parsing, and ranking logic is early-to-mid 2026.

The flip side: generic arb bots will need months to adapt. Searchers who upgrade in the first quarter will capture outsized share of 7702-specific opportunities.

Full post + FAQ at ai-frb.com. FRB Agent is a non-custodial desktop MEV agent for Windows — download free.

Uniswap V4 Hooks MEV 2026: Searcher Opportunities and Risks

FRB Research — Sat, 16 May 2026 01:07:44 +0000

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

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.

What Hooks Actually Change

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:

Callback	When It Fires	MEV Relevance
`beforeInitialize`	Pool creation	Low (one-shot)
`afterInitialize`	Pool creation	Low
`beforeAddLiquidity`	LP deposit	Medium — gates JIT
`afterAddLiquidity`	After deposit	Medium
`beforeRemoveLiquidity`	LP withdraw	Low
`afterRemoveLiquidity`	After withdraw	Low
`beforeSwap`	Before swap math	High — fee/route logic
`afterSwap`	After swap math	High — donations, rebalancing
`beforeDonate`	Donation hook	Low
`afterDonate`	Donation hook	Medium

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.

Opportunity 1: Custom-Curve Arbitrage

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:

Discover the hook contract behind each pool you care about
Either decompile the hook logic or simulate via eth_call on each tick
Add the gas overhead of the hook callback (5k–80k extra gas) to your profit threshold

Realistic 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.

Opportunity 2: Dynamic Fee Races

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.

Opportunity 3: JIT-via-Hook Liquidity

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:

Pools with internal JIT hooks are harder to JIT-attack — the hook already takes the LP fee. Don't waste gas competing.
Pools without internal JIT still allow classic V3-style JIT, but you must check the hook flags first (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.

Risk 1: Hook Reentrancy Traps

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:

Whitelist hooks. Never swap through a hook contract you haven't verified is on a maintained allowlist (Uniswap Labs publishes one; community lists exist for hooks they don't bless).
Cap loss per pool. Per-pool max-loss limits in your bundle's revert guard catch hook drain attempts.
Gas-bomb detection. If a hook's beforeSwap consumes >200k gas in simulation, treat it as hostile and exclude the pool.

Risk 2: Asymmetric Gas Costs

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.

Risk 3: Simulation Drift

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:

Subscribe to the hook contract's events for upgrade signals
Re-simulate every 100 blocks against a recent on-chain swap to detect drift
Auto-pause any pool whose simulator-vs-actual delta exceeds 25 bps for three consecutive trades

How V4 Hooks Compare With V3 MEV

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.

Hook-Aware Bundling Pattern

A robust V4 bundle structure for arb:

Static call simulate swap(poolKey, params) against forked state at current block
Read hook flags and re-simulate if hook flags include beforeSwap
Compute expected output minus all gas (including callback overhead)
If profit > threshold, submit bundle through your private relay
Include a per-pool revert guard checking actual output ≥ 98% of simulated

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.

What FRB Agent Supports

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.

Realistic Returns On V4 Hook Arb

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

Quiet month (low volatility, few new hook pools): 1.5–3% return
Active month (new pools launching, oracle resets): 5–12% return
Volatility spike month: highly variable, can be 15–25% or negative

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.