📢 Gate Square Exclusive: #PUBLIC Creative Contest# Is Now Live!
Join Gate Launchpool Round 297 — PublicAI (PUBLIC) and share your post on Gate Square for a chance to win from a 4,000 $PUBLIC prize pool
🎨 Event Period
Aug 18, 2025, 10:00 – Aug 22, 2025, 16:00 (UTC)
📌 How to Participate
Post original content on Gate Square related to PublicAI (PUBLIC) or the ongoing Launchpool event
Content must be at least 100 words (analysis, tutorials, creative graphics, reviews, etc.)
Add hashtag: #PUBLIC Creative Contest#
Include screenshots of your Launchpool participation (e.g., staking record, reward
IOSG Ventures: An article discussing Rollup’s monetization design
Original author: Jiawei, IOSG Ventures
Is Rollup a good investment class in infrastructure?
Rollup’s investment logic ranges from the early ZK/OP narrative dispute, to the later practice of TPS and user experience competition, and then to the moat built around derivative tools such as OP Stack. For this issue, it may be at different stages of industry development. There are different answers.
But at the end of the day, what we need to answer is, is Rollup a profitable business? What are the economics of Rollup? This article attempts to study and discuss Rollup's business model and its Monetization design space.
Barry Whitehat first proposed the concept of Rollup in the Ethereum Research forum. When the concept of Rollup was in its infancy, we collectively called the role of Rollup as Relayer or Operator. With the refinement of infrastructure development, this role is decomposed into multiple entities: Sequencer is responsible for sorting transactions and writing to DA, Challenger is responsible for proposing challenges, and Prover is responsible for generating proofs. When we discuss the Rollup economy, we can basically sort out from these entities.
Source: IOSG
This article mainly discusses several aspects of Rollup Monetization:
Transaction Fee
Similar to other chains, users who send transactions in Rollup need to pay transaction fees.
From the perspective of Sequencer, this transaction cost mainly covers two parts of expenditure: execution overhead and security overhead.
Execution Cost (ution Cost)
Source: John Adler
Rollup's execution overhead is inherited from Ethereum's model. In the abstract, each Ethereum node runs a replicated state machine. As shown in the figure above, nodes download and store transaction data, perform calculations, read and write memory and storage, and these operations correspond to physical resource consumption and consumption. Gas, as a unified resource pricing unit, is used to measure the resources behind these operations.
The same is true when it is extended to Rollup. Operating a Rollup node will generate a certain amount of execution overhead, which is the origin of the transaction fee paid by Rollup users. Due to subtle differences in EVM equivalence and different Rollup designs, different Rollups have slightly different prices for execution overhead (for example, zkSync Era provides native account abstraction, and some operations may require more Gas than EOA), but Generally, the Gas model of Ethereum is used.
Source: Dune Analytics @springzhang
In addition to the execution overhead described above, congestion charges and minimum transaction fees should also be considered.
Security Cost
Source: Celestia Forum @adeets_ 22
The security overhead is the data availability (DA) cost we are discussing. DA is the guarantee that Rollup is equivalent to the security of Ethereum, ensuring that everyone can rebuild the state of Rollup based on the data published on Ethereum L1 (here we are talking about Ethereum Fang L1, of course there are other DA schemes). The DA cost contributed to Ethereum L1 occupies the vast majority of the total cost of Rollup. In May of this year, Arbitrum submitted about 3,927 MB of data to Ethereum, and paid 4,856 ETH for it, and the DA cost was about 1.24 ETH/MB. (Based on the S 3 Standard price of $0.023 per GB and the ETH price of $1800, the DA storage cost of Ethereum is about 100 million times that of AWS).
Since DA on the chain is very expensive, each Rollup adopts a data compression method. Arbitrum and Optimism Bedrock use open source data compression libraries Broti and zlib respectively to compress data published to Ethereum L1. StarkNet and zkSync Era compress data by publishing a State Diff (the difference between the previous state and the new state) instead of the entire data. (PS: The Optimism Bedrock upgrade also adopts various methods to compress transaction costs, here we can see more data indicators).
Source: IOSG
It is worth looking forward to that the high DA cost of Ethereum L1 will be greatly alleviated after Decun Upgrade introduces EIP-4844. Also, the "security overhead" discussed here actually implies different levels of security. In addition to the DA guaranteed by Ethereum L1, solutions such as DAC, Celestia, and EigenDA provide a variety of "security-cost" trade-offs, providing a variety of options for the DA demand side. Some low-frequency, high-value DeFi applications need more security guarantees, while some high-frequency, relatively low-value applications (such as games) can pay more attention to cost; each takes what it needs.
Source: Dune Analytics @optimismfnd
To sum up, simply look at it from the perspective of Sequencer: Sequencer collects transaction fees from the user side and pays DA fees to Ethereum. Then Sequencer's profit can be calculated as above. At present, most Sequencers are operated by the Rollup team. If a series of details such as token issuance income and inflation are ignored, Rollup's income can also be roughly measured in this way.
Source: Token Terminal
Source: IOSG
Taking Optimism as an example, in the past 30 days, Optimism's daily profit is about 20k US dollars. According to the data from Token Terminal, Optimism’s profit since its launch is about 10.9 M USD.
MEV
MEV is an important way Rollup builds its business model. It doesn't make much sense to talk about MEV in the context of a centralized single sequencer, so we'll start with a decentralized sequencer and then explore Rollup's MEV economy.
Decentralized Sequencer (DS)
As of now, Arbitrum ($5.87 b), Optimism ($2.14 B), and zkSync Era ($649 M) rely on a centralized Sequencer/Operator for transaction sorting, batch submission, and other operations.
Decentralization is a complicated matter. The process of introducing multiple participants needs to be carefully polished, and it is not necessary to complete it in one step. From the perspective of security, competition situation, and developer resources, it makes sense to adopt a centralized Sequencer early in the project. However, the centralized Sequencer has at least two obvious flaws (which are also the flaws of most centralized methods).
Source: Taiko
Currently, Sequencer actually plays the role of Builder and Proposer on Ethereum L1: it is responsible for both transaction sequencing and submitting Batches - the process of implementing DS is a bit like taking the old path of Ethereum PBS.
To implement DS, Rollup usually has several options.
The Rollup team can use the above options to build DS internally, or consider outsourcing Sequencing:
Choosing to build in-house or outsource has some trade-offs, which are discussed further later in this article.
Rollup MEV in DS context
Source: odos.xyz/arbitrage
If we have a DS market with open block construction, then the MEV supply chain on Ethereum will be reproduced on Rollup. Among them, Intradomain MEV (Intradomain MEV) refers to the MEV that occurs inside Rollup, which is not much different from the MEV of Ethereum L1. For example, sandwich attacks in DEX, cross-DEX arbitrage, etc. Because Rollup has not yet implemented DS, the above figure uses the cross-DEX arbitrage on Ethereum L1 as an example.
More interesting may be cross-domain MEV (Cross-domain MEV). We divide cross-domain MEV into common cross-domain MEV and cross-domain MEV under Shared Sequencer (SS).
Source: odos.xyz/arbitrage
Ordinary cross-domain MEV happens between Ethereum L1 and Rollup, Rollup and Rollup. In the context of DS, each domain has its own MEV pipeline, covering different roles. The image above is an example of cross-domain arbitrage.
On the Searcher side, cross-domain MEV involves complex execution risks, because different domains have different confirmation times and finality, and it is impossible to determine whether the transaction will be included as desired. To this end, Primev is building a communication network where Searchers can submit bids to multiple Builders in multiple domains to obtain pre-confirmation guarantees for their Bundles. This way Searcher can quantify and manage their execution risk.
There is a trend of centralization in cross-domain MEV. As pointed out by Flashbots, a Builder that builds blocks on multiple chains at the same time has a greater advantage in cross-domain MEV than a Builder that builds blocks on only one chain, thus easily leading to centralization. Under the Rollup-centric Roadmap, this is a topic that needs to be faced in the next few years.
The situation is different if multiple Rollups use the same SS.
Source: IOSG
One of the characteristics of SS is that it can realize cross-Rollup atomic arbitrage. Originally, when Searcher submitted transaction 1 and transaction 2 separately, it was not sure whether the two transactions would be included as it expected (for example, included just in the next block). With SS, Searcher can submit a Bundle similar to the above figure, and execute it only when transaction 1 and transaction 2 can be satisfied at the same time, otherwise neither transaction will be executed (of course, the transaction that needs to be satisfied is not an invalid transaction). This implementation reduces the execution risk of Searcher.
Ideally, SS will achieve "the whole is greater than the sum of its parts". For example, the information covered by a transaction may not be valuable on a single Rollup, but it can be arranged and combined with transactions on other Rollups when multiple Rollups share sorting, so as to make full use of some "invalid information" and realize positive sum games.
Although there are many benefits, Sequencing involves complex business issues. Therefore, the author believes that SS will not be adopted by the head Rollup in the short term, but may be implemented and verified first in the long-tail App-specific Rollup, or as a Rollup-as- The options of the a-Service project are provided for developers to use.
Rollup economy around MEV
Source: IOSG
After DS is implemented, the question returns to how to build economic models and value capture mechanisms around MEV.
Above we discussed the overhead of Rollup. The source of this overhead is the DA resources and the physical resources to operate the Rollup itself. These limited resources constitute the scarcity of block space. MEV reflects dominance over the scarcity of block space. Rollup can price that dominance.
Fuel Network believes that an optimized token model should reasonably capture the value of the block space. Users use Rollup tokens to pay transaction fees, which is one of the ways of value capture (ie endowed with token Utility). But this also introduces additional user-side friction. The idea of Fuel is also to tokenize the scarcity of block space, but what is tokenized is "the right to charge fees in the block space." This is from the perspective of block producers and MEV, and does not affect end users.
Corresponding to the above options of DS, the author thinks that there may be the following design space:
*MEV Auction (MEVA). Sequencer participates in the auction to determine the transaction ordering rights of a specific block, or a block within a specific time. The auction bids serve as Rollup's revenue.
Therefore, the author believes that SS should somehow redistribute the captured MEVs among its various domains. This redistribution incentive is especially important in situations where multiple SSs compete for their Rollup clients. In this case, the redistributed MEV can serve as Rollup's income.
Fault Proof
(The community proposed to change the name of Fraud Proof to Fault Proof, because even honest parties may submit wrong state transitions due to software configuration errors and other reasons. The word "fraud" actually implies evil motives, so the description is not accurate enough)
The general design of fraud proofs is that during the challenge period, people (called challengers) can challenge the state transition; once the challenge is verified as correct, the perpetrators will be confiscated, and the challenger will get part of the confiscated funds as a reward. The remaining forfeited funds may be destroyed, and if the forfeited funds are Rollup tokens, this is considered a compensation for all token holders (not for the victims of the attack). Both Arbitrum and Optimism Cannon currently employ interactive fraud proofs.
The party that observes state transitions and proposes challenges on Arbitrum is called a validator, and the party that observes state transitions is called observers (Watchtower Validators). The main difference between the two is that the former can pose a challenge, while the latter can warn in any way (for example, through the community or social media). Becoming a validator requires whitelist permissions. Observers do not need permission.
Arbitrum may decentralize the role of validators (aka challengers) in the future. But actually the challenger only needs 1 of N trust assumptions, one honest challenger is enough for the network. Therefore, the author believes that decentralized challengers only meet the requirements of decentralization. Except for the above-mentioned challengers getting part of the confiscated funds, there is not much room for design in economics, and it is more likely to be due to design Redundancy considerations.
Prover Network/Market
Source: Figment Capital
Figment Capital made a conceptual distinction between Prover Network and Prover Market in its article: Prover Network is a collection of Prover that only provides services for a single application (such as Scroll). The Prover Market is an open market where multiple applications (such as Scroll, Succinct) can submit proof requests to the market. This article has already summarized all aspects of Decentralized Prover, so this article will not add too much ink.
Prover Network
Scroll came up with the idea of a decentralized Prover two years ago.
Source: Scroll
Prover (Scroll is called Roller) needs to pledge tokens to obtain an initial reputation, which is proportional to the pledged tokens. When the network needs to generate proofs, the Sequencer randomly selects multiple Provers according to their reputations, and requires them to generate proofs within time T—if the proofs are invalid, they will be fined; if the proofs are valid but later than time T, their reputation will be reduced; if If the proof is valid and within time T, there is a chance to get a reward.
The introduction of a time-limited T design, rather than simply using "fastest" to measure, is to avoid the winner-take-all situation of the fastest Prover, because as long as it can be completed within time T, the fastest Prover and the slower Prover Prover has the same probability of getting the reward. This mechanism encourages the fastest Provers to generate proofs for other blocks in parallel to maximize profits.
Prover Market
Source: =nil;
=nil; Provides generalized services for building circuits and proving the market. The developer who builds the circuit and the Prover who generates the proof each get a portion of the revenue.
As an open market, =nil; is similar to the spot market, with two roles: proof requesters and proof producers. The former can issue buy orders, and the latter can issue sell orders. The parameters of the pending order include Statement (such as Mina or Solana's state proof circuit), cost, order timeout period and proof generation time.
=nil; A similar reputation system is also adopted, and the Prover who fails to generate proofs on time or generates wrong proofs will be reduced in rating or even fined.
Scroll and =nil; both adopt the design of staking-slashing and reputation system, the difference is that they target different demand-side groups. The former serves ZKRollup itself, and the latter serves multiple ZK applications. These two examples correspond to the two forms of internal construction Prover and outsourcing Prover respectively.
Closing Thoughts
Based on the above discussion, the author puts forward several points of view: