MEV on rollups is not an accident. It is the direct outcome of how sequencers order transactions, how searchers compete for opportunities, and how latency determines who wins and loses. The rollup environment magnifies these forces because blockspace is cheaper and transaction confirmation is faster compared to Ethereum L1.

The result is a constant tension. Users expect responsive systems, while searchers exploit tight latency windows to extract value. Sequencers sit in the middle, responsible for ordering, inclusion, and often policy enforcement. This is where fairness begins to break down.

Roles and Flow

Key players / roles:

• Users submitting regular transactions (DEX trades, swaps, liquidity operations, bridging, etc.).
• MEV searchers / arbitrage bots who monitor state and try to detect profitable MEV opportunities: arbitrage, cyclic arbitrage, back‐running, etc.
• Sequencers: responsible for ordering transactions submitted to rollups. They set policies: how transactions are included, ordering priority, private vs public mempools, tie-breakers, etc.
• Builders / block producers in some designs or upcoming policy variants: they may choose inside which set to order, or receive tips / bids, etc.

Flow roughly:

1. User (or searcher) sends transaction / probe to sequencer (or to public gateway).
2. Sequencer orders the transaction (with possible delay, batch, priority fee, etc.).
3. Sequenced block or batch is posted to L1 for data / state finality (depending on rollup).
4. MEV is extracted if ordering or latency favours searchers (fast arrival, private paths, etc.).

Breakdown of MEV Types & Latency Context

From the literature:

• In Optimistic MEV in Ethereum L2s (Q1 2025) the key categories are cyclic arbitrage (interaction / probe vs success vs revert). On Base / Optimism, speculative probes (which may not execute trade) dominate. On Arbitrum, more of the cyclic arbitrage attempts succeed.
• Liquidations are rare in MEV on L2s compared with arbitrage and cyclic arbitrage. Sandwich attacks are less frequent.

Latency surfaces:

• Inclusion delay and time to finality differ across rollups. For example for OP Stack chains (like Base, Optimism), once transaction data is in a block and posted to Ethereum, “safe” state is within 5-10 minutes after submission. Finalization (irreversibility under Ethereum consensus assumptions) is typically ~20-30 minutes.
• For Arbitrum, block times are shorter; soft finality (receipt to user) may happen in 1-2 seconds; L2 block intervals are higher frequency than OP stack in many cases, posted possibly multiple times per second. But to get “final” state on L1 via fraud proofs or challenge periods, full finality takes longer.

These latency differences matter: searchers care about low inclusion delay from their sending of a transaction to when it is sequenced (ordered) AND about how deterministic and irreversible the ordering is. If there is opportunity for reordering or delay, searchers exploit.

Transaction ordering is not a neutral process. The rules that sequencers apply—whether first come first served, priority fee auctions, or private mempools—directly shape which users get fair execution and which ones pay hidden costs. On rollups, where a single sequencer typically controls the ordering, these rules can feel opaque or inconsistent.

This matters because ordering policies effectively decide how MEV is distributed. A centralized sequencer may lean toward efficiency, censorship, or profitability, while decentralized alternatives promise more neutrality but often struggle with coordination overhead.

Sequencer Ordering Policies, Tie-breakers, Fee Priority, Private Flow

• Arbitrum’s policy: The policy is called FBA-FCFS (Fee Bidding Auction blended with First-Come First-Served). Under this policy:
  • Transactions arriving in short intervals (“chunks”) are sorted by tip (per-gas priority fee) within that chunk. Those with higher tip go first.
  • Ties (same tip) are broken by receive-order (i.e. FCFS).
  • Arbitrum has proposed or adopted “Timeboost”, which gives an “express lane” for some transactions (those paying priority fee / tip) to get earlier sequencing. Non-express transactions may be delayed by a proposed amount (200ms in some designs) and then sequenced after non-express delay plus block time.
• Base and Optimism (OP Stack): These rollups tend to allow priority gas auctions (PGAs) or ordering mechanisms that allow users / searchers to bid for earlier ordering inside a block. Thus the ordering is not purely FCFS. This reduces, in theory, the leverage of raw latency (colocation, networking) because high tip can compensate. However latency still plays a role.
• Private orderflow vs public mempool: Many rollups have private mempools or do not expose public mempools fully. This means searchers or private orderflow (builders or searchers connected to sequencers) can submit transactions that are not visible to all until inclusion. That gives advantage in reacting quickly, front-running or backrunning, or sandwiching if allowed. Arbitrum’s policy documentation assumes private transaction visibility and trust in the sequencer not to misuse it.

Share of Private Order-flow, Builder/Searcher Integrations

• While precise shares vary and are not always public, the studies indicate that in Base and Optimism, speculative MEV bots send many interaction/probe transactions that are visible (or intentionally opaque until included) to searchers. These bots send many transactions that revert or don’t execute trade, but probe state. That suggests a mix of public flow and private / direct searcher-to-sequencer flow.

• Builder/searcher integration: Rollups using PGA or priority gas auctions more resemble builder/searcher models. Users or searchers bid for in-block ordering. The Base and Optimism rollups see much of the MEV extractors using these mechanisms. Arbitrum is introducing express lanes and Timeboost to approximate this model.

Latency is the hidden force that often determines who captures MEV. Even when ordering policies try to reduce pure latency advantages, narrow windows and tight time budgets favour those who are extremely optimized (colocated, direct connections, low jitter, etc.).

Measured Differences: Colocated / Whitelisted vs Public Gateways

• Empirical measurement (from rollup research and forum/project proposals) shows that express lanes or whitelisted / priority paths to sequencers can reduce transmission / inclusion delay by 100-200 milliseconds (or more) compared to public gateways. These latency improvements can translate into measurable differences in arbitrage success, especially in fast arbitrage or cyclic arbitrage contexts where price changes happen quickly. For example, Arbitrum’s Timeboost proposal uses a non-express delay of ~200ms for transactions not in the express lane. Transactions in express lane are sequenced immediately, or with minimal delay (block time) plus whatever minimal internal latency exists.
• In OP-Stack rollups with block intervals / posting durations, small delays of even a few hundred milliseconds can cost a searcher the arbitrage opportunity because someone else (with better latency or bid) gets there first. The “Optimistic MEV” paper shows that for Base and Optimism, many speculative probes are submitted which fail or revert; success rates are low. That is evidence that many searchers lose due to delay or ordering.

Recommended Auction Rounds / Batch Durations for Preconfirmations

• Some communities propose batch intervals or “preconfirmation” mechanisms to give users some guarantee of ordering fairness. For example, designs with 3-4 second rounds have been discussed in ethresear.ch threads on based preconfirmations. These would balance UX (how fast users see their transaction appear) with decentralization and anti-latency arms race. Shorter rounds reduce latency race advantage but increase overhead. Longer rounds slow UX.
• The “Based Preconfirmations with Multi-Round MEV Boost” proposal discusses multi-round auctions or intervals, so that transactions are grouped in rounds (e.g. 3-4 seconds) before ordering and block inclusion is finalized / sequenced. We do not have full production data yet, but simulations and early tests show these reduce variance in ordering and reduce advantage from small latency improvements.

Fairness in blockchain does not have a single definition. Some argue it means “first come, first served”, others argue it means maximizing welfare or protecting uninformed traders. Each approach comes with trade-offs, especially when measured against MEV capture.

For rollups, “fair” ordering is more than a technical question. It is also a governance choice. Deciding whose interests to prioritize: users, searchers, sequencers, or protocols? This determines what fairness means in practice.

Models and Limits

Below are some ordering models, with trade-offs:

Comparative Metrics

Studies have measured some of these trade-offs:

• The paper “Optimistic MEV in Ethereum Layer 2s” shows that Base and Optimism have significantly more speculative MEV (interaction / probe transactions) compared to Arbitrum — this is a sign that many attempts fail, likely because ordering or latency disadvantage causes searchers to lose or revert.
• The designing of Timeboost in Arbitrum includes measurable parameters: non-express delay (200 ms), express lane availability, block times (block interval ~250 ms for Arbitrum One/Nova), maximum delay budget etc. These affect ordering uncertainty and delay.
• On verification and proof sizes: designs like VRF proofs impose some gas or computation overhead; these often are acceptable in many designs but must be balanced. The literature indicates that using random permutation or VRF‐based ordering adds constraint on throughput; overhead may reduce throughput by some percentage, depending on implementation. Specific proof sizes depend on the randomness scheme. (Exact metrics are still being refined in research, not yet all in deployed rollups).

Sequencers do not centralize out of malice. They centralize because latency-sensitive systems reward low coordination costs and single points of control. One operator can move faster, extract MEV more efficiently, and deliver smoother user experience.

The pressure is structural. Even rollups with decentralization roadmaps face the challenge that shared or distributed sequencing often lags in responsiveness. That delay is enough to shift incentives back toward centralized operators.

Incentives and Operational Realities

• Efficiency: a single sequencer is easier to manage operationally. Lower coordination overhead. Less complexity in consensus, less delay in deciding on ordering. For nascent rollups or for minimizing operational risk, a centralized sequencer is attractive.
• Latency advantages: centralized sequencer allows establishing fast paths (colocation, private connections, express lanes). These are easier to build when the system is not decentralized. When you have multiple sequencers, coordination and network synchronicity become harder. Those who can afford infrastructure get huge advantage. To avoid losing searcher volume / MEV revenue, rollups may default to centralized or permissioned sequencers.
• Orderflow consolidation: As MEV becomes a non-trivial component of revenue streams, projects may prefer to capture that value in protocol or sequencer operator rather than allow it to fragment among many small players. This tends to push toward centralization of orderflow and of sequencer control. Roadmaps sometimes note converting policy or architecture toward shared sequencer later, but in the near term centralized control is easier. Base, for example, has central sequencing today and decentralization is in roadmap.
• Also searcher competition pressures require minimal latency, so searchers will tend to locate infrastructure to minimize delay to the (central) sequencer. This creates geographic centralization, network paths optimizations, etc. Over time this concentrates advantage in a few searchers or operators.

Case Studies

• Arbitrum: FCFS policy, private mempool, no public exposure of all in‐flight transactions; Timeboost proposal to adjust ordering, but still under centralized sequencer. The express lane / non-express delay mechanisms give hand to those who can pay or have infrastructure advantage.
• Base / Optimism: These use priority fee / PGA in ordering inside blocks; but still operate centralized sequencing. The searcher competition and block fullness on Base and Optimism, with many speculative probes, shows that centralized sequencer + fast block frequency + bidding model creates high load and high “race” pressure among searchers.
• Shared Sequencer promises: Projects like Espresso, Astria aim to share sequencing among rollups. These are not yet fully mature in deployment; there are trade-offs (governance, DA / data publication, latency) that slow adoption.

Given these challenges, what designs, trade-offs, and mitigations help reduce unfairness while preserving reasonable latency?

Designs and Trade-offs

• Batch auctions / priority bidding / express/non-express lanes: these allow users / searchers to signal that they care about ordering. The Arbitrum Timeboost proposal is a concrete example: users can pay a priority fee to get into an express lane; non-express transactions pay a delay (200 ms more or less) before being sequenced. This reduces pure latency advantage (so that somebody who is slightly geographically closer doesn’t get the transaction first automatically), but preserves a path for users who value getting earlier ordering.
• Encrypted / commit-reveal flow: hiding transaction contents until a commit phase can reduce front-running / sandwich attacks. Also reduces advantage of probes or searchers seeing others’ planned transactions before deciding their own. Pilots of such designs show measurable reductions in certain kinds of MEV (esp sandwich / front-running). The architecture to mitigate MEV blog by dydx shows the effect of encrypted or anonymized orderflow.
• Preconfirmation rounds: designs that allow small windows (e.g. 3-4 seconds) to collect transactions, then order them in some fair manner (by bid, by arrival, by randomization, or hybrid). These rounds tolerate small latency differences and reduce the race to be first. They degrade raw speed somewhat, but improve fairness among users. Some proposals for “based preconfirmations” include multi-round MEV boost and rounds with a few seconds duration.

• Random permutation / VRF ordering inside blocks or batches: after grouping transactions, randomizing within a batch can reduce ordering predictability. Some designs include verifiable proofs. The overheads include gas cost, proof size, verification, and possible UX delays. These designs are still in research / experimental phases.

Protocol level metrics & monitoring: Enforce inclusion delay targets (p50 / p95), monitor reordering distances, measure MEV dispersion across searchers, reliability of preconfirmation or express lane mechanisms. Protocols that publish these metrics allow stakeholders to verify fairness and identify drift.

Here are metrics a rollup should track (and perhaps report quarterly) to assess MEV / fairness vs latency:

• Inclusion delay targets for transactions: e.g. median (p50) and 95th percentile (p95) time from user sending transaction to sequencer ordering, and also time to L2 block posting / L1 posting (if relevant).
• Maximum reordering distance: how far transactions are reordered compared to arrival order (or priority bids), measured in number of positions or time.
• MEV dispersion across searchers: whether MEV profits are concentrated in very few searchers (suggesting latency / privilege advantage) or reasonably spread.

Preconfirmation / express lane reliability rates: fraction of rounds or batches where express/non-express or priority lane mechanisms worked as intended; also measure whether delays introduced harm UX or cause too many failed / delayed transactions.

Here’s a rough guide: depending on your fairness and latency goals, use this to decide whether to use FCFS, PGA, hybrid/express lanes, or shared / decentralized sequencers.

Rollups are scaling Ethereum, but they are inheriting the hardest trade-offs from the base layer. Fairness and latency are not technical footnotes, they are design constraints. Centralized sequencers dominate today because they deliver speed, but they do so at the cost of neutrality.

MEV on rollups is already widespread. Arbitrage dominates, while liquidations and sandwiching are less frequent but still present. The path forward is not about removing MEV but about deciding how much centralization is acceptable, and what forms of ordering are legitimate.

Shared sequencer networks and fair ordering mechanisms may provide alternatives, but the trade-offs are unavoidable. In the end, every rollup must choose between responsiveness, decentralization, and fairness and that choice will define who benefits most from Ethereum’s scaling future.