Optimism MEV: Fees, Endpoints & Execution Tips

Answer first — Optimism MEV in 2026 is dominated by two cost dynamics that are different from Ethereum mainnet. First, OP Stack chains pay for L1 data through EIP-4844 blobs (since the Ecotone upgrade), so calldata cost no longer scales with raw L1 gas — but blob fees can still spike during heavy posting periods. Second, Optimism uses a centralised sequencer; there is no Flashbots-style bundle relay, so priority is a function of priority fee plus latency to the sequencer endpoint, not a bid in a separate auction. To execute reliably you need three things: an honest fee model that includes both the L2 execution fee and the L1 data fee, a low-latency endpoint (private commercial RPC or your own op-node), and atomicity packed into a single transaction so partial fills cannot strand capital between legs.

Mastery path

• Arbitrum playbook: private bundles
• Base MEV strategies (2026)
• Optimism execution playbook
• Lowest-latency Reth RPC for MEV

Optimism's fee model in 2026

Every Optimism transaction pays two fees: an L2 execution fee (priced like normal EIP-1559 gas) and an L1 data fee (the cost of posting that transaction's data to Ethereum mainnet). The second one is what trips up MEV operators who price trades like they're on Ethereum.

Three upgrades changed this materially over the last 18 months:

• Bedrock (mid-2023) introduced the modern fee market with separate L2 and L1 components.
• Ecotone (March 2024) moved L1 data posting onto EIP-4844 blobs, dropping the typical L1 portion of the fee by roughly an order of magnitude versus the calldata era.
• Holocene / Granite (2024–2025) refined fee parameter exposure and made the L1 base-fee scalar dynamic, so spikes in blob demand pass through to L2 fees within a few minutes.

Practical implication: the L1 portion of an Optimism fee is no longer "small and stable." Blob demand is bursty, and during heavy posting (rollups competing for blob space) the L1 component of an OP Stack fee can briefly double or triple. A trade that was profitable when you queued it can be unprofitable by the time you sign and send.

The fix is to query the L1 fee component via eth_getL1Fee (or the equivalent precompile path on your stack) immediately before signing — never trust a value cached more than a few seconds.

Endpoint landscape

Optimism does not have an Ethereum-style public mempool with full peer broadcasting, but the sequencer accepts transactions over standard JSON-RPC and gossips them to other op-nodes. A well-connected op-node will see incoming transactions before they're sequenced into a block — so backruns work, but the latency window is short.

If you're running meaningful volume, an op-node co-located in the sequencer's region pays for itself fast — both because of the latency edge and because you avoid commercial RPC rate limits during a volatility spike. Below that volume, a tier-2 commercial RPC is the rational choice; benchmark candidates with the WSS latency test from your actual deployment region.

What about "private bundles" on Optimism?

Optimism does not have a Flashbots-style relay you can submit eth_sendBundle to. Atomicity has to come from packing your route into a single transaction that calls a custom executor contract — that contract reverts on partial failure, so the whole thing either lands or doesn't. This is the same pattern as on Arbitrum.

Two practical tools for "private-flavoured" submission:

• Private RPC endpoints that don't rebroadcast your transaction to the public peer-to-peer layer until it's been included by the sequencer. Most commercial Optimism RPCs offer this as a paid feature.
• Intent-style submission through any relay that has Optimism support. Adoption has been slower than on mainnet — verify the relay actually has searchers active on Optimism before relying on it.

Pre-trade simulation

The closest equivalent to eth_callBundle on Optimism is forking an op-node with Anvil/Foundry (anvil --fork-url <op-rpc>) and replaying the candidate transaction against current state. This catches:

• Reverts from L1-data-fee underestimation (the most common silent failure on OP Stack).
• Slippage from cross-DEX path changes between simulation and signing.
• Gas-oracle drift if the L1 base fee moves between simulate and send.

The FRB Agent runs this fork-replay step for every candidate Optimism send before any private key is used to sign.

Runbook: shipping an Optimism backrun

1. Subscribe to the op-node WSS feed for incoming transactions. Confirm steady cadence; reconnect if staleness exceeds ~500 ms.
2. Detect the target tx and compute the backrun path against current pool state.
3. Re-query the L1 fee component with eth_getL1Fee against the exact transaction you're about to sign — not against an earlier estimate.
4. Simulate against an op-fork at the current head. Reject if simulated profit doesn't clear (L2 gas + L1 data fee + priority fee + safety margin).
5. Submit through your private RPC at a priority fee that's competitive against other backrunners in the same window. Optimism has 2-second blocks — your window is short.
6. Confirm inclusion within 2 blocks. If the transaction has not landed by then, kill the path. Don't retry against state that's already moved.
7. Log realised PnL vs simulated PnL. A consistent gap suggests your fee model is stale; tune it.

Common failure modes

• Stale L1-fee scalar. During blob demand spikes, the L2 fee shifts faster than most caches refresh. If your RPC client is caching scalars, you'll under-pay and get out-priced.
• Sequencer outage. Optimism's sequencer has had outages. Have a fallback through the L1 deposit / forced-inclusion path for trades you absolutely must land — accepting much slower confirmation and higher cost in exchange for censorship resistance.
• Two-leg races. If your strategy has two sends that must land in order, encode both into one executor-contract call. Otherwise the second leg can sequence behind someone else's tx and revert.
• Bridging confusion. A transaction "confirmed" on Optimism is L2-final, not L1-final. For settlement-sensitive flows, wait for the L1 challenge window (~7 days under standard withdrawals) or use a fast-bridge with its own trust assumptions.

When the right answer is "don't trade Optimism right now"

Two conditions where the chain is temporarily uneconomic:

• Extreme blob demand — when the L1 portion of an OP Stack fee approaches L2 execution cost, your margin of safety collapses. Watch blob fees on mainnet alongside Optimism's L1 scalar; if both are spiking, sit out.
• Sequencer instability — the status page shows current health. During degraded periods, inclusion latency balloons and your simulation goes stale before the tx lands.

References

• Optimism developer documentation: fees
• Ecotone upgrade overview (EIP-4844 on OP Stack)
• Running an op-node