From Transaction Fees to MEV: A Deep Dive into Rollup Monetization Design
TechFlow Selected TechFlow Selected
From Transaction Fees to MEV: A Deep Dive into Rollup Monetization Design
Transaction fees are a simple and effective business model, and one of the main selling points of Rollups for Ethereum scaling is low fees.
Navigating Web3 tides with focused insightsAuthor: Jiawei, IOSG Ventures
Is Rollup a good investment category among the many infrastructure options?
The investment thesis for Rollups has evolved—from early narratives around ZK vs. OP, to later practical comparisons of TPS and user experience, to building moats around derivative tooling like OP Stack. The answer to this question may vary depending on the stage of industry development.
But ultimately, we need to answer: Is Rollup a profitable business? What does Rollup economics look like? This article attempts to explore the business model of Rollups and the design space for monetization.
Barry Whitehat first proposed the concept of Rollup on the Ethereum Research forum. In the early days of Rollup’s conceptual phase, we collectively referred to those operating Rollups as Relayers or Operators. As infrastructure matured, this role was broken down into multiple entities: Sequencers responsible for transaction ordering and writing to DA, Challengers who raise disputes, and Provers who generate proofs. When discussing Rollup economics, we can largely begin with these roles.
Source: IOSG
This article mainly discusses several aspects of Rollup monetization:
-
Origins, composition, and profitability of transaction fees;
-
MEV under decentralized sequencers and its monetization;
-
Monetization potential based on Fault Proof and Validity Proof.
Transaction Fee
Similar to other chains, users must pay transaction fees when sending transactions on a Rollup.
From the Sequencer's perspective, this cost mainly consists of two components: execution cost and security cost.
Execution Cost
Source: John Adler
Rollup's execution cost inherits from Ethereum’s model. Abstractly, every Ethereum node runs a replicated state machine. As shown in the figure above, nodes download and store transaction data, perform computation, read/write memory and storage—these operations correspond to physical resource consumption. Gas serves as a unified pricing unit to measure the resources implied behind these operations.
Similarly, operating a Rollup node incurs certain execution costs, which form the basis of the transaction fees paid by Rollup users. Due to slight differences in EVM equivalence and Rollup design, different Rollups have slightly varying pricing models (e.g., zkSync Era offers native account abstraction, where some operations may require more gas compared to EOAs), but overall they follow Ethereum’s gas model.
Source: Dune Analytics @springzhang
In addition to the above execution cost, congestion fees and minimum transaction fees should also be considered.
-
Congestion fee. Reflected in the dynamic balance between gas price and network traffic. For example, during Arbitrum Odyssey, surging network traffic caused gas prices to spike significantly.
-
Minimum transaction fee. To prevent spam and DoS attacks on blockchains with extremely low fees, it is necessary to set a floor for transaction fees. Currently, it is 0.1 gwei on Arbitrum One and 0.01 gwei on Arbitrum Nova. The value depends on network design (e.g., 0.001 gwei on Optimism).
Security Cost
Source: Celestia Forum @adeets_22
Security cost refers to data availability (DA) cost—the guarantee that Rollups achieve Ethereum-level security by ensuring anyone can reconstruct the Rollup state from data published on Ethereum L1 (this discussion focuses on Ethereum L1, though other DA solutions exist). DA costs contributed to Ethereum L1 constitute the majority of total Rollup costs. In May this year, Arbitrum submitted approximately 3,927 MB of data to Ethereum and paid 4,856 ETH, resulting in a DA cost of about 1.24 ETH/MB. (Calculated at S3 Standard $0.023 per GB and ETH priced at $1,800, Ethereum’s DA storage cost is roughly one hundred million times that of AWS.)
Due to the high cost of on-chain DA, all Rollups employ data compression techniques. Arbitrum and Optimism Bedrock use open-source compression libraries Brotli and zlib respectively to compress data posted to Ethereum L1. StarkNet and zkSync Era compress data by publishing State Diff (the difference between previous and new states) instead of full data. (P.S.: The Optimism Bedrock upgrade adopted multiple methods to further reduce transaction costs; more metrics are available here.)
Source: IOSG
Looking ahead, Ethereum L1’s high DA cost will be greatly alleviated after the Dencun Upgrade introduces EIP-4844. Moreover, the “security cost” discussed here actually implies different levels of security. Beyond Ethereum L1-guaranteed DA, solutions like DAC, Celestia, and EigenDA offer various trade-offs between “security and cost,” providing diverse choices for DA demand. High-value, low-frequency DeFi applications prioritize security, while high-frequency, relatively low-value applications (e.g., gaming) may prioritize cost-efficiency—each finds its fit.
Source: Dune Analytics @optimismfnd
In summary, from a simple Sequencer perspective: Sequencers collect transaction fees from users and pay DA fees to Ethereum. Thus, a Sequencer’s profit can be calculated accordingly. Most Sequencers today are operated by Rollup teams. If we ignore token issuance revenue, inflation, and related details, Rollup income can be roughly estimated this way.
Source: Token Terminal
Source: IOSG
Take Optimism as an example: over the past 30 days, it generated around $20k in daily profit. According to Token Terminal, Optimism has earned approximately $10.9M since launch.
MEV
MEV is a key way for Rollups to build business models. Discussing MEV under a centralized single Sequencer isn’t very meaningful, so we’ll start with decentralized sequencers before exploring Rollup MEV economics.
Decentralized Sequencer (DS)
To date, Arbitrum ($5.87B), Optimism ($2.14B), and zkSync Era ($649M) rely on centralized Sequencers/Operators for transaction ordering and batch submission.
Decentralization is complex—introducing multiple participants requires careful refinement. A phased approach makes sense. From perspectives of security, competitive landscape, and developer resources, using a centralized Sequencer early in a project’s lifecycle is reasonable. However, centralized Sequencers have two clear drawbacks (common to most centralization approaches):
-
Transaction censorship: censoring specific user transactions, including ransom attacks, etc. To mitigate this, Arbitrum and Optimism offer forced inclusion options—for instance, any Arbitrum user can call the forceInclusion method to ensure transaction inclusion; StarkEx implements an Escape Hatch mechanism for partial censorship resistance.
-
Liveness guarantee: Can the Sequencer remain consistently online? A single point of failure (e.g., hardware crash or software misconfiguration) could bring down the entire network. Though unlikely, such events would cause widespread disruption.
Source: Taiko
Currently, Sequencers effectively play both the Builder and Proposer roles on Ethereum L1—responsible for transaction ordering and batch submission. Implementing DS resembles retracing Ethereum’s PBS path.
Typically, Rollups have several options for achieving DS:
-
Leader election/rotation + local block building, akin to non-PBS scenarios on Ethereum L1. Vitalik outlined several election/rotation methods in his An Incomplete Guide to Rollups: Sequencer auctions, PoS-based random selection, DPoS voting, etc. Based on Ethereum’s experience, PBS is clearly the superior solution.
-
Leader election/rotation + open block-building market, similar to Ethereum’s Enshrined PBS or Proposers using MEV-Boost.
-
Specific mechanisms like FCFS (First Come First Serve). FCFS leads to latency races, similar to colocation in traditional HFT. Arbitrum currently uses FCFS and is researching variants like Time-Boost, which allows paying priority fees to speed up transactions by up to 0.5 seconds—a two-dimensional trade-off between latency and fee.
Rollup teams can either internally build DS or consider outsourcing sequencing:
-
Projects like Espresso/Astria offer DS/SS services;
-
Flashbots is building SUAVE, a cross-domain universal encrypted mempool;
-
Justin Drake’s Based Rollup leverages L1 consensus directly, allowing Ethereum L1 Proposers to include Rollup blocks in L1 blocks, inheriting equivalent decentralization and liveness guarantees.
There are trade-offs between internal development and outsourcing, which this article will discuss later.
Rollup MEV under DS Context
Source: odos.xyz/arbitrage
With an open block-building DS market, the current MEV supply chain on Ethereum would replicate on Rollups. Intradomain MEV refers to MEV occurring within a Rollup, not much different from Ethereum L1 MEV—examples include sandwich attacks on DEXs or cross-DEX arbitrage. Since Rollups haven’t yet implemented DS, the diagram uses Ethereum L1 cross-DEX arbitrage as an illustration.
More interesting might be Cross-domain MEV. We divide cross-domain MEV into general cross-domain MEV and Shared Sequencer (SS)-based cross-domain MEV.
-
General Cross-domain MEV
Source: odos.xyz/arbitrage
General cross-domain MEV occurs between Ethereum L1 and Rollups, or between Rollups. Under DS, each domain has its own MEV pipeline involving different roles. The above figure illustrates cross-domain arbitrage.
On the Searcher side, cross-domain MEV involves complex execution risk, because domains differ in confirmation time and finality, making it uncertain whether transactions will be included as intended. Primev is building a communication network allowing Searchers to submit bids to multiple Builders across domains to obtain pre-confirmation guarantees, enabling quantification and management of execution risk.
Cross-domain MEV shows centralizing tendencies. As Flashbots pointed out, Builders capable of building blocks across multiple chains have a significant advantage over single-chain Builders in capturing cross-domain MEV, leading easily to centralization. This is a topic we’ll face in the coming years under the Rollup-centric roadmap.
-
MEV under SS
If multiple Rollups share the same SS, the situation changes.
Source: IOSG
One characteristic of SS is enabling atomic arbitrage across Rollups. Previously, when a Searcher submitted Transaction 1 and Transaction 2 separately, there was no guarantee both would be included as expected (e.g., in the next block). With SS, the Searcher can submit a bundle like the one shown above—both transactions execute only if both conditions are met; otherwise, neither executes (assuming transactions aren’t invalid). This reduces Searcher execution risk.
Ideally, SS achieves "the whole greater than the sum of parts." Information from a single Rollup might be worthless alone, but when shared sequencing enables combinations across Rollups, even "useless information" can be utilized for positive-sum outcomes.
Despite these benefits, sequencing involves complex business dynamics. Therefore, I believe SS won’t be adopted soon by top-tier Rollups, but may first be tested and validated among long-tail app-specific Rollups, or offered as an option in Rollup-as-a-Service platforms for developers.
Rollup Economics Around MEV
Source: IOSG
After DS implementation, the focus returns to how to build economic models and capture value around MEV.
Earlier, we discussed Rollup costs. These stem from DA resources and the physical resources required to operate a Rollup. These finite resources create scarcity in block space. MEV reflects control over this scarcity. Rollups can price this control.
Fuel Network argues that an optimized token model should fairly capture the value of block space. Having users pay transaction fees in Rollup tokens is one way to capture value (i.e., giving the token utility), but adds friction for users. Fuel’s idea is to tokenize block space scarcity—but specifically, tokenize the right to collect fees within block space. This is from the block producer and MEV perspective, without affecting end users.
Corresponding to the DS options above, I see the following design space:
-
MEV Auction (MEVA): Sequencers bid in auctions for the right to order transactions in specific blocks or time windows. The winning bid becomes Rollup revenue.
-
PoS: Stake Rollup tokens to be randomly selected as Sequencer; higher stake increases probability. Note that Rollup security still relies on Validity/Fault Proof and Ethereum—not PoS-based economic security. PoS is merely a leader selection mechanism. Token staking provides value capture, reflecting block space scarcity through lock-up.
-
SS: Compared to the above, SS is a novel and open-ended topic. Assuming a Rollup outsources sequencing to an SS, it relinquishes rights to capture intradomain MEV—though gains network effects across domains, creating positive-sum outcomes. Alternatively, a Rollup could choose to retain MEV internally, either capturing it directly or tokenizing intradomain MEV.
Therefore, I believe SS should redistribute captured cross-domain MEV among its constituent Rollups in some form. In a competitive environment where multiple SS providers vie for Rollup clients, such redistribution incentives become crucial. In this case, redistributed MEV could serve as Rollup revenue.
Fault Proof
(The community suggests renaming Fraud Proof to Fault Proof, as even honest parties may submit incorrect state transitions due to software misconfigurations. "Fraud" implies malicious intent, which is inaccurate.)
The typical Fault Proof design allows challengers to dispute state transitions during a challenge period. Once verified correct, the malicious actor is slashed, and the challenger receives part of the penalty as reward. Remaining slashed funds may be burned; if the slashed asset is the Rollup’s token, this acts as compensation to all token holders (not just victims). Both Arbitrum and Optimism Cannon currently use interactive fault proofs.
On Arbitrum, those monitoring state transitions and raising challenges are called Validators, while passive observers are Watchtower Validators. The key difference is that only Validators can formally challenge, while Watchtowers can issue warnings via any channel (e.g., community or social media). Becoming a Validator requires whitelisting; Watchtowers are permissionless.
Arbitrum may eventually decentralize the Validator (challenger) role. But challengers only require a 1-of-N trust assumption—one honest challenger suffices for network security. Thus, decentralizing challengers mainly satisfies decentralization goals. Beyond rewarding challengers with part of slashed funds, there’s little economic design space—it’s more about redundancy.
Prover Network/Market
Source: Figment Capital
Figment Capital distinguishes between Prover Network and Prover Market: a Prover Network is a collection of provers serving a single application (e.g., Scroll); a Prover Market is an open market where multiple apps (e.g., Scroll, Succinct) can submit proof requests. Their article comprehensively covers decentralized provers, so this piece won’t repeat it.
Prover Network
Scroll proposed the idea of a decentralized prover two years ago.
Source: Scroll
Provers (called Rollers by Scroll) must stake tokens to gain initial reputation, proportional to their stake. When a proof is needed, the Sequencer randomly selects multiple provers by reputation to generate a proof within time T—if invalid, they’re fined; if valid but late, their reputation drops; if valid and on time, they may earn rewards.
The introduction of time limit T, rather than simply rewarding the fastest, avoids winner-takes-all dynamics—as long as they finish within T, both the fastest and slightly slower provers have equal chance of reward. This encourages fast provers to parallelize proof generation for other blocks to maximize profit.
Prover Market
Source: =nil;
=nil; offers generalized services for circuit building and proof markets. Developers building circuits and provers generating proofs each receive part of the revenue.
As an open market, =nil; resembles a spot market with two sides: proof requesters and proof producers. Requesters post buy orders, producers post sell orders. Order parameters include Statement (e.g., Mina or Solana state proof circuits), cost, timeout, and proof generation time.
=nil; also uses a reputation system—provers failing to generate proofs on time or producing incorrect ones face rating reductions or slashing.
Both Scroll and =nil; use staking-slashing and reputation systems, differing only in target demand groups. The former serves ZKRollups directly; the latter supports multiple ZK applications. These represent internal vs. outsourced prover models.
Closing Thoughts
Based on the above discussion, I offer the following views:
-
Transaction fees are a simple and effective business model, but low fees are a primary selling point of Rollups for scaling Ethereum—so they won’t heavily optimize here. With EIP-4844 adoption and maturation of various DA solutions (Celestia, EigenDA, etc.), Rollup transaction fees will drop further—good news for users.
-
Regarding Rollups, I believe mainstream Rollups will gradually adopt DS over the next two to three years, while long-tail Rollups may move faster. MEV, as a subtler business model, will become a major source of revenue growth. If DS is built in-house, it ties closely to tokenomics design; if using DS & SS, fair MEV distribution becomes critical for both Rollups and DS/SS projects. Rollup MEV importance is currently severely underestimated.
-
Decentralization is often gradual, with varying degrees. Whether for Sequencers or Provers, there are mainly two options: internal development or outsourcing. The former offers broader design space, primarily built on staking-slashing crypto-economic primitives, with mature mechanisms available. I suspect the latter may rely on DA-like payment models.
DS mechanism design is likely more complex than Prover systems, which are relatively straightforward. It’s hard to judge whether a Sequencer’s transaction sequence is correct or not, whereas mathematical proofs are deterministic and measurable (e.g., time, cost). DS considerations are more rooted in MEV economics.
How Rollups choose between these two paths depends on their stage—capital efficiency, developer resources, etc. For early-stage Rollups, including app-specific ones, outsourcing decentralization (via DS & SS or EigenLayer) for rapid bootstrapping may be optimal. More mature Rollups, with ample resources, will increasingly focus on token value capture and ecosystem integration to build moats and flywheel effects.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
IOSG Ventures
