DEV Community: FRB Research

Uniswap V4 Hooks MEV 2026: Searcher Opportunities and Risks

FRB Research — Sat, 13 Jun 2026 02:04:09 +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.

Pectra & Fusaka Ethereum Upgrade MEV Impact 2026: Searcher Adaptation Guide

FRB Research — Sat, 13 Jun 2026 02:03:10 +0000

Answer first — Pectra and Fusaka are the two Ethereum hard fork upgrades shaping MEV in 2026. Pectra activated in 2025 with three MEV-relevant EIPs: EIP-7251 (raised max effective validator balance to 2,048 ETH, concentrating staking), EIP-7702 (introduced EOA-to-contract delegations, new transaction class), and EIP-7549 (changed attestation aggregation). Fusaka is scheduled for late 2026 with EIP-7594 PeerDAS (data availability sampling, ~8x blob throughput) and scaling improvements. Together they shift Ethereum's economic surface: more concentrated validator MEV, new transaction types to parse, and cheaper blob space that pulls flow toward L2s.

Pectra: What Activated in 2025

Pectra hard-forked Ethereum mainnet in May 2025. Three EIPs matter for MEV:

EIP-7251: Max Effective Balance Raise (32 → 2,048 ETH)

Pre-Pectra: each validator could hold at most 32 ETH staked. A 32k ETH staking entity needed 1,000 validator slots.

Post-Pectra: validators can consolidate up to 2,048 ETH. The same 32k ETH operation needs only 16 validator slots.

MEV consequences:

Concentration: Major staking entities (Lido, Coinbase, Binance staking) consolidated their validators through 2025-2026. Each validator now controls more proposal slots.
Relay relationships: Consolidated validators have stronger, more centralized relationships with MEV builders/relays. Generic searcher strategies face more concentrated counterparties.
MEV-Boost dynamics: Top 5 builders (Beaverbuild, Titan, BuilderNet, rsync-builder, Flashbots) have higher market share post-Pectra.

EIP-7702: EOA Delegations (Smart-EOA-on-Demand)

Pre-Pectra: an EOA could only sign transactions of types 0, 1, 2, 3. To get smart-wallet behavior, a user needed to deploy a smart contract wallet (ERC-4337).

Post-Pectra: an EOA can sign a transaction with a SetCodeListItem — temporarily attaching contract code for that transaction. This enables batching, sponsorship, and session keys without deploying a smart wallet.

MEV consequences:

New transaction type 0x04 that parsers must handle
Multi-action transactions from regular wallets (approve + swap + claim in one tx)
Sponsored bundles: priority fee can be zero with paymaster paying out-of-band
Patient front-running: session keys visible on-chain before submission

EIP-7549: Attestation Aggregation Change

Marginal MEV impact — affects how attestations propagate, not what searchers see in the mempool. Builders adjusted; searchers mostly unaffected.

Fusaka: What Ships Late 2026

EIP-7594 PeerDAS (Data Availability Sampling)

Pre-Fusaka: Ethereum's blob throughput is ~6 blobs per block (~3 MB/min). Post-Fusaka: PeerDAS enables nodes to sample data without holding all blobs, scaling to ~48 blobs per block (~24 MB/min).

MEV consequences:

L2 economics: L2 settlement costs drop 60-80%. Base, Arbitrum, Optimism, zkSync all see fee compression.
L1 flow shift: As L2s become cheaper, more discretionary trading happens there. L1 MEV becomes higher-quality but lower-quantity.
Blob-priced opportunities: Fee market for blob space matures. New MEV-adjacent strategies around blob inclusion timing become viable.

Strategy 1: Adapt Your Parser to 7702

If your MEV bot doesn't parse type 0x04 transactions, you're missing 8-15% of mainnet flow by mid-2026:

Add transaction type 0x04 to your mempool subscriber filters
Parse the SetCodeListItem array — these are the delegation targets
When the delegation target is a known multicall, recursively decode the inner calls
Update your sandwich/back-run logic to account for batched operations

Strategy 2: Reposition for Concentrated Validators

Generic bundle submission to all builders has lower differentiation
Relationship with specific builders matters more
Pure-mempool strategies face higher competition; relay-aware strategies retain edge

Strategy 3: L2 Migration Planning for Fusaka

Pre-Fusaka, L2 fees on Base/Arbitrum are 5-15 cents per swap. Post-Fusaka, expect 1-3 cents.

Retail flow migrates to L2 (already trending; accelerates post-Fusaka)
L1 keeps high-value flow but with thinner overall volume
L2 arb economics improve: lower fees mean more profitable arb at smaller spreads

If you're 70% L1 and 30% L2 in mid-2026, you may want 50/50 by year-end.

Strategy 4: Sponsored-Bundle Awareness

EIP-7702 enables paymaster-sponsored bundles where the priority fee is zero. Your bundle-ranking logic needs to account for:

Side payments to builders (off-chain or via paymaster mechanisms)
True economic value of inclusion vs the visible fee
Mempool transactions with apparent low priority that may actually be valuable

Risks for Searchers Post-Pectra

Reduced solo-validator opportunity surface: With validator concentration, the "small validators not on top relays" surface area shrank.

Increased operational complexity: Handling 7702 traffic adds parsing, simulation, and bundle-building complexity.

Concentration risk: If top 5 builders capture 90% of MEV value, censorship and gatekeeping risk grows. Operators without builder relationships face structural disadvantage.

Bottom Line

Pectra rewired Ethereum's validator economics and added EIP-7702 as a new transaction class. MEV bots that didn't adapt to 7702 by mid-2026 missed material flow. Fusaka in late 2026 will rebalance the L1-vs-L2 economic surface further.

The professional MEV operators in 2026 invested early in 7702 parsing and builder relationships post-Pectra. The structural advantage of using a maintained agent grows each upgrade cycle.

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

LRT Arbitrage 2026: eETH, ezETH, rsETH Searcher Playbook

FRB Research — Sat, 13 Jun 2026 02:02:21 +0000

Answer first — LRT (Liquid Restaking Token) arbitrage in 2026 captures spreads between LRTs like weETH, ezETH, rsETH, pufETH and their underlying ETH/stETH. With $30B+ TVL across the LRT ecosystem and frequent peg drift during yield rebalancing events, the arb pays consistently for searchers running atomic bundles on Curve, Uniswap V3, Balancer, and Pendle pools. The playbook is structurally similar to stablecoin depeg arb but with LRT-specific risks: AVS slashing exposure, sequential withdrawal queues, and correlation between LRT depegs and systemic restaking stress.

The 2026 LRT Landscape

Five LRT protocols dominate the market:

Protocol	Token	TVL (May 2026)	Backing
ether.fi	weETH	~$10B	EigenLayer restaked ETH
Renzo	ezETH	~$3B	EigenLayer + Symbiotic
Kelp DAO	rsETH	~$1.5B	EigenLayer
Puffer	pufETH	~$1B	EigenLayer + native restaking
Swell	rswETH	~$800M	EigenLayer

Together with smaller LRTs, total LRT TVL exceeds $30B. The market is liquid enough for atomic arbitrage to clear profitably but fragmented enough that pricing inefficiencies persist for seconds-to-minutes.

Where The Spread Actually Comes From

LRT peg drift has predictable causes:

1. Yield reset events

LRTs distribute restaking yield periodically. The moment before/after a yield update, the LRT trades at a slightly stale price vs. the new NAV. Arb closes the gap.

2. Large mint/redemption flows

A whale minting $100M worth of ezETH compresses the price marginally vs ETH on Curve. The next 30 seconds offer arb back to par.

3. Cross-DEX route congestion

weETH/ETH price on Curve may diverge from the same pair on Balancer or Uniswap V3 during gas-fee spikes. Atomic bundles capture the cross-venue spread.

4. Sentiment-driven depegs

Negative news on EigenLayer or a specific AVS triggers panic selling of one LRT. The depeg can be 1-3% briefly. This is the dangerous one — see Risk section.

Strategy 1: Cross-DEX Atomic Arbitrage

The bread-and-butter LRT arb. Standard atomic pattern:

Monitor weETH/ETH price across Curve, Uniswap V3, Balancer, Pendle
When spread > gas + 0.1% threshold, build atomic bundle: buy cheap side, sell expensive side
Submit through Flashbots private relay
Capture spread minus gas

Realistic per-trade profit on weETH/ezETH/rsETH:

Quiet hours: $5-$50/trade, 10-30 opportunities/day
Active flow: $50-$500/trade, 30-100 opportunities/day
Reset events (oracle/yield updates): $200-$2,000/trade, 2-8 opportunities

The competitive moat is fast simulation against the actual LRT pool math (Curve's stable invariant, Uni V3's tick math) for the current block state.

Strategy 2: LRT-to-LRT Triangular Arbitrage

LRTs don't always move together. When weETH appreciates 0.2% but ezETH stays flat, the implied weETH/ezETH cross-rate diverges from observed market.

The bundle:

Sell weETH for ETH
Buy ezETH with ETH
Sell ezETH for weETH (or original equivalent)

If the final balance exceeds the starting balance net of fees, the triangle was profitable.

Strategy 3: Pendle PT/YT Arbitrage

Pendle splits LRTs into Principal Tokens (PT) and Yield Tokens (YT). Periodic mispricing between PT + YT vs the underlying LRT creates arb:

weETH price ≠ PT-weETH price + YT-weETH price

When the equation breaks, atomic arb between Pendle and Curve closes the gap. Fewer searchers run Pendle-aware bots — better win rates than generic cross-DEX arb.

Strategy 4: Redemption Arbitrage (Non-Atomic)

When an LRT trades meaningfully below par for hours:

Buy LRT at discount on DEX (e.g. ezETH at 0.985 ETH)
Queue redemption with the protocol
Wait 1-7 days for withdrawal
Receive ETH at par

Risks during the holding period:

ETH price moves (USD-denominated profit may differ)
LRT could depeg further
Withdrawal queue could extend

This is a portfolio strategy, not a searcher strategy. Only viable when the depeg is large enough (>0.5%) to clear protocol risk premium.

Risk 1: AVS Slashing Cascade

The biggest unique LRT risk: an AVS on EigenLayer gets slashed, the loss propagates to the underlying restaked ETH, and the LRT's NAV drops. Multiple LRTs are exposed to the same set of AVSs.

If you're holding LRT inventory for redemption arb during a slashing event, your "depeg arbitrage" turns into "buying the dip on a permanent capital impairment."

Defense:

Never hold a single LRT >30% of working capital
Monitor AVS slashing events on EigenLayer's dashboards
Pause LRT arbitrage during major slashing events for at least 72 hours

Risk 2: Smart Contract Risk Stack

LRT arb stacks multiple contract risks: the LRT protocol, the underlying EigenLayer/Symbiotic layer, the DEX pool, and any router contract in the path. Whitelist LRTs whose protocols have been audited and are >6 months in production.

Risk 3: Liquidity Concentration

LRT liquidity is shallower than ETH/USDC. The arb size cap is usually $50k-$200k per trade — beyond that, slippage eats the spread.

Realistic Returns

Indicative early-2026 monthly returns for a solo searcher with $50k working capital:

Quiet month: 1.5-3%
Active month (multiple yield resets, normal flows): 4-9%
Volatility-spike month: 6-15% gross, with larger drawdown tail risk

The strategy is in a sweet spot in 2026: large enough TVL to support real size, competitive but not saturated.

Infrastructure Requirements

To compete in LRT arbitrage:

Low-latency mainnet RPC with mempool access
Fork simulator that handles Curve stable invariant + Uni V3 tick math + Pendle's implied-yield AMM
Per-protocol monitoring: AVS slashing dashboards, withdrawal queue depths, yield rebalance schedules
Flashbots private relay for bundle submission

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

How to Detect MEV in Your Trades 2026: A Practical Guide

FRB Research — Sat, 13 Jun 2026 02:01:28 +0000

Answer first — To detect MEV against your own trades in 2026, follow a four-step forensic process: (1) pull the transaction receipt and identify the block; (2) inspect adjacent transactions in the same block for matching pool/matching tokens; (3) compare your effective price to the pool's pre-trade quote; (4) attribute the slippage to MEV (sandwich/back-run) vs natural price impact vs ordering luck. Tools that make this fast: EigenPhi, MEV-Inspect-py, Etherscan's MEV labels, and Libmev. For Solana: Eclipse and Jito-Explorer. Most retail traders discover they're being sandwiched on 5–20% of their swaps once they actually look.

Why Bother Detecting

Three reasons:

Routing changes. If Aggregator A leaks 12 bps per swap on average and Aggregator B leaks 3 bps, you switch.
Behavioral changes. If you're being sandwiched mostly on trades > $5,000, you split orders or use a private mempool.
Real loss accounting. MEV is a real, quantifiable trading cost. Most people underestimate it because they never measure it.

Step 1: Pull The Transaction Receipt

Find your trade's transaction hash. From the receipt, you need:

The block number
The transaction index within the block (your position in the ordering)
The pool address you swapped against
The token amounts you swapped (in and out)
The gas paid and the priority fee paid

On Etherscan, all of this is on the transaction detail page. Programmatically: eth_getTransactionByHash + eth_getTransactionReceipt.

Step 2: Inspect Adjacent Transactions

Look at the transactions in the same block, ordered by index. Two patterns indicate MEV:

Pattern A: Sandwich (Front-Run / Back-Run)

If you see:

Transaction (your index - 1): A swap on the same pool in the same direction as yours
Transaction (your index + 1): A swap on the same pool in the opposite direction

That's a classic sandwich. The front-run pushed the price up before your fill, your trade filled at the worse price, and the back-run captured the imbalance.

Pattern B: Back-Run (No Front-Run)

If you see no front-run, but a same-pool opposite-direction swap immediately after yours — that's a pure back-run. Less damaging to you (doesn't change your fill price), but indicates your trade was visible in the mempool.

Pattern C: JIT Liquidity

If you see IncreaseLiquidity then DecreaseLiquidity on the same pool with very small intervening swap count — that's JIT (just-in-time) liquidity. A searcher added liquidity, captured your trade's fee, and removed it.

Step 3: Compare Effective Price To Pool Quote

Independent of pattern detection, do a price comparison:

Note the pool reserves (or tick state for V3) at block N-1
Compute the expected output of your trade against those reserves
Compare to your actual output from the receipt

Formula:

mev_loss_bps = (expected_output - actual_output) / expected_output * 10000 - expected_price_impact_bps

If mev_loss_bps > 5–10 and you can match the front-run/back-run pattern, you've been sandwiched.

Step 4: Attribute The Slippage

Source	Detection
Natural price impact	Predicted by AMM math from your trade size
Other-trade ordering	Another (non-malicious) user filled before you
MEV (sandwich / back-run / JIT)	Matches the patterns in step 2

Most real-world slippage on retail swaps is a mix. The MEV component is typically 3–25 bps for small public-mempool swaps, larger for big swaps and long-tail tokens.

Tools That Do The Heavy Lifting

EigenPhi

Best-in-class MEV analytics. Paste a transaction hash → labeled breakdown: sandwich front-run, victim, back-run, profit captured. Works for Ethereum mainnet, several L2s, and BNB Chain.

MEV-Inspect-py (Flashbots)

Open-source library that classifies MEV-extraction patterns from block data. Best for running your own analysis on your trading history. Requires a full node or archive RPC.

Etherscan's MEV labels

Etherscan tags known MEV bot addresses and shows MEV-extracted value in the block detail view. Quick and accessible.

Libmev

Open-source library and dashboard. Good for self-hosted analysts who want a Web UI without paying for EigenPhi's enterprise tier.

Solana-specific: Jito-Explorer + Eclipse

For Solana trades, Jito's bundle explorer shows tipped transactions and bundle composition. Eclipse offers MEV analytics with sandwich detection on major DEX programs.

Quick-Look Workflow (5 minutes)

Copy your transaction hash
Paste into EigenPhi (free tier covers most retail-size trades)
Look at the "Victim Loss" field — that's your MEV cost in USD
If significant, check whether the trade went through a public mempool. If yes, your routing leaked.

What Detection Tells You About Routing

Patterns you'll see repeatedly:

Public-mempool swaps on long-tail tokens: MEV leakage ranges 15–80 bps. Routing through aggregators with private orderflow (1inch Fusion, CoW, Paraswap Delta) typically cuts this to <3 bps.
Large swaps on blue-chip pairs: Even on major pairs, swaps above ~$50k consistently leak 5–20 bps to back-running.
Small swaps: For <$500 trades, gas costs dominate and MEV loss is usually <$0.50.

What To Do With The Data

Action 1: Change Routing

Switch to a private-orderflow aggregator (1inch Fusion, CoW, Paraswap Delta) or submit through a private relay.

Action 2: Use Private Mempool

For sniper-style trades, submit through Flashbots Protect, MEV-Share, or your chain's equivalent.

Action 3: Split And Time Trades

For large trades, split into chunks below the threshold where MEV becomes cost-effective for searchers (~$5,000-$10,000 on mainnet).

Bottom Line

If you've never measured MEV against your own trades, you're almost certainly losing more than you think. The tools take 5 minutes to learn. Most retail traders cut their MEV exposure by 60–90% within a month of starting to measure — the act of looking changes the routing decisions.

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

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.

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

Opportunity 1: Custom-Curve Arbitrage

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

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:

Opportunity 3: JIT-via-Hook Liquidity

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.

Risk 1: Hook Reentrancy Traps

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

Risk 3: Simulation Drift

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

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

DEV Community: FRB Research

Uniswap V4 Hooks MEV 2026: Searcher Opportunities and Risks

What Hooks Actually Change

Opportunity 1: Custom-Curve Arbitrage

Opportunity 2: Dynamic Fee Races

Opportunity 3: JIT-via-Hook Liquidity

Risk 1: Hook Reentrancy Traps

Risk 2: Asymmetric Gas Costs

Risk 3: Simulation Drift

How V4 Hooks Compare With V3 MEV

Hook-Aware Bundling Pattern

What FRB Agent Supports

Realistic Returns On V4 Hook Arb

Further Reading

Pectra & Fusaka Ethereum Upgrade MEV Impact 2026: Searcher Adaptation Guide

Pectra: What Activated in 2025

EIP-7251: Max Effective Balance Raise (32 → 2,048 ETH)

EIP-7702: EOA Delegations (Smart-EOA-on-Demand)

EIP-7549: Attestation Aggregation Change

Fusaka: What Ships Late 2026

EIP-7594 PeerDAS (Data Availability Sampling)

Strategy 1: Adapt Your Parser to 7702

Strategy 2: Reposition for Concentrated Validators

Strategy 3: L2 Migration Planning for Fusaka

Strategy 4: Sponsored-Bundle Awareness

Risks for Searchers Post-Pectra

Bottom Line

LRT Arbitrage 2026: eETH, ezETH, rsETH Searcher Playbook

The 2026 LRT Landscape

Where The Spread Actually Comes From

1. Yield reset events

2. Large mint/redemption flows

3. Cross-DEX route congestion

4. Sentiment-driven depegs

Strategy 1: Cross-DEX Atomic Arbitrage

Strategy 2: LRT-to-LRT Triangular Arbitrage

Strategy 3: Pendle PT/YT Arbitrage

Strategy 4: Redemption Arbitrage (Non-Atomic)

Risk 1: AVS Slashing Cascade

Risk 2: Smart Contract Risk Stack

Risk 3: Liquidity Concentration

Realistic Returns

Infrastructure Requirements

How to Detect MEV in Your Trades 2026: A Practical Guide

Why Bother Detecting

Step 1: Pull The Transaction Receipt

Step 2: Inspect Adjacent Transactions

Pattern A: Sandwich (Front-Run / Back-Run)

Pattern B: Back-Run (No Front-Run)

Pattern C: JIT Liquidity

Step 3: Compare Effective Price To Pool Quote

Step 4: Attribute The Slippage

Tools That Do The Heavy Lifting

EigenPhi

MEV-Inspect-py (Flashbots)

Etherscan's MEV labels

Libmev

Solana-specific: Jito-Explorer + Eclipse

Quick-Look Workflow (5 minutes)

What Detection Tells You About Routing

What To Do With The Data

Action 1: Change Routing

Action 2: Use Private Mempool

Action 3: Split And Time Trades

Bottom Line

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

What 7702 Actually Does

Why Searchers Care

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

2. Sponsored bundles change the priority-fee market

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

New Attack Surface: Delegation Drainers

Sandwich Attacks on 7702 Transactions

How 7702 Compares to ERC-4337

Updating Your Searcher Stack For 7702

Bottom Line

Uniswap V4 Hooks MEV 2026: Searcher Opportunities and Risks

What Hooks Actually Change

Opportunity 1: Custom-Curve Arbitrage

Opportunity 2: Dynamic Fee Races