Title: Value accrual for Rollup frameworks and RaaS (are they going to ZERO?)

Author: StackrLabs

Compiled by: Yvonne, MarsBit

If the future is an on-chain economy composed of thousands of Rollups, then we are undoubtedly on the right timeline. From the Optimism stack and Polygon chain development kits to Caldera and Stackr, a variety of Rollup frameworks and Rollup as a Service (RaaS) providers have emerged in the market over the past few months. These frameworks provide modular (often open-source) codebases for different components of Rollup, allowing developers to pick and choose from customizable options at every layer of the stack.

But how do these providers accrue value? Neel Somani (founder of Eclipse) recently gave a talk at the modular summit titled "RaaS solutions are going to zero."

In this blog post, we will analyze some of his arguments and explore the complex dynamics of value accrual for Rollup frameworks and RaaS providers. From individual layers to Superchain, we will uncover the hidden mechanisms behind how Rollup frameworks and RaaS providers create and capture value.

Rollup vs Rollup Framework vs RaaS

A Rollup is an application that executes off-chain and publishes execution data to another blockchain. In this way, they can leverage the security properties of the main chain. A Rollup application can either be a single state transition function or an independent blockchain whose canonical state is maintained by a set of nodes.

A Rollup framework is a pre-built codebase that implements the fundamental components of a Rollup. Developers can use these existing codebases (often packaged as SDKs) and customize them according to their specific needs, rather than building a Rollup from scratch. Examples of open-source Rollup frameworks include OP Stack and Arbitrum Orbit.

Rollup as a Service (or RaaS protocols) are no-code wrappers built on top of existing Rollup frameworks. Developers can quickly deploy a Rollup from scratch by selecting custom features from a dropdown menu. RaaS companies typically sort the deployed Rollups and offer additional consulting services.

Flow of Funds

To understand the flow of value in and out of the entire stack, it is essential to grasp the architecture of Rollups and the interactions between different layers. The Rollup stack roughly consists of three layers:

1. Execution - This layer executes transactions by applying state transition functions (STF) on the existing state of the Rollup. The responsibilities of execution nodes vary widely, from issuing transaction commands and executing transactions to publishing transactions on L1 and creating fraud/validity proofs, depending on the "centralization" level of the Rollup.

The execution layer is the "user-facing" layer where funds enter the Rollup stack. Users need to pay transaction fees (gas), which typically represent the difference between various costs that the execution layer must cover (to be detailed later). This layer can also extract additional value from users by sorting transactions in certain ways (also known as MEV: Maximum Extractable Value).

2. Settlement - This includes validating validity/fraud proofs and "defining" the canonical state of the Rollup (in the case of smart contract Rollups). Settlement is usually managed by a unified high-security layer (like Ethereum). Rollup frameworks can also build their own settlement layers.

Since validation costs are generally low, settlement is not a high-value stack layer. Optimism only pays about $5 in settlement fees to Ethereum daily. The costs of a competitive settlement layer can be even lower (as emphasized in the article "Rollups-as-a-Service Are Going To Zero").

3. Data Availability - DA includes broadcasting sorted transaction data to other parts of the network (sometimes referred to as data publishing). It ensures that anyone can reconstruct the Rollup state without permission by simply applying the broadcasted transaction data to a previously finalized state.

DA costs constitute a significant portion of all Rollup costs. Publishing data on highly secure layers like Ethereum can be quite expensive. Protocols like Celestia, Avail, and EigenDA are actively developing cheaper and faster DA alternatives. Rollup frameworks may also consider building their own DA layers, but decentralized DA incurs high onboarding costs and complicates interoperability.

It may be helpful to view the execution layer as a B2C model and the settlement and DA layers as B2B models:

The execution layer purchases block space from the DA layer and sells its execution services directly to end users (customers), while purchasing validation and bridging services from the settlement layer; The DA layer sells block space to the execution layer; The settlement layer provides settlement services to the execution layer.

In a competitive market environment, most value capture comes directly from the execution layer of the stack, so it makes sense to further break down and analyze its value flow independently.

Execution Layer: B2C Economic Model

The execution layer generates revenue by charging users a fee for each transaction and pays operational costs to other businesses (layers) in the stack.

Revenue: The incoming value can be categorized as follows:

Gas fees paid by end users for each transaction; Intra-domain MEV; Cross-domain MEV (if the framework provides sorting for multiple Rollups on the same DA layer, otherwise it may be difficult to extract).

MEV depends on transaction flow (the "extractable" value of each group of transactions varies) and is often difficult to predict in advance. Therefore, the gas fees charged to users typically have a margin over the overall predictable costs.

Costs: The value outflow of the execution layer is as follows:

Node operating expenses Execution (computational) costs Proof (validity/fraud proof) costs Data publishing costs (which vary based on congestion on the DA layer)

Typically, all responsibilities of the execution layer are borne by a centralized sorting node. This single node receives all revenue from users and is responsible for paying DA and settlement fees. In other cases, different nodes can be set up to take on different responsibilities:

Sorters sort transactions and publish data on the DA layer. They "earn" the transaction fees paid by users and cover sorting overhead and data publishing costs. Sorting tasks can also be performed by a pre-selected group of sorters or decentralized sorters like Espresso. Sorters are also responsible for publishing state changes to the settlement layer and paying settlement costs.

Prover nodes are responsible for generating proofs. They can be a centralized prover or a decentralized group of proving nodes. Their costs include the overhead of generating proofs. Depending on the setup, provers either "sell" the proofs to sorters or publish them directly to the settlement layer.

Rollups can also have other full nodes (or full validating light nodes) to execute all transaction batches and maintain the canonical state of the Rollup. These full nodes may not necessarily generate any direct revenue but can indirectly capture value by holding the native gas tokens of the Rollup.

The above is a rough distinction of the responsibilities of different nodes. As for which node takes on which tasks, it depends on the architectural setup of the Rollup team. For simplicity, in this article, we will stick to a centralized sorter setup, where a single node performs all necessary execution tasks.

So the question arises: if the execution layer brings the most value, which participant in the stack is best positioned to capture that value?

Anyone who runs a sorting node and performs various activities related to it!

This could be the Rollup team itself. Alternatively, as mentioned at the beginning of the article, RaaS providers often handle sorting for the Rollups they deploy. In fact, this constitutes a significant portion of RaaS provider revenue.

How do RaaS providers make money?

RaaS can capture value in three main areas:

Sorter Hosting: RaaS providers are responsible for running sorters and conducting related activities. This is a division of labor where the promotion team brings innovation (the applications they are building), while RaaS providers handle everything else. Sorters sort transactions, publish data on L1, and create proofs when necessary.

Additional Infrastructure: Block explorers, bridges, etc.

Dedicated Support: Providing consulting and collaboration on infrastructure decisions (how to sort, MEV, etc.) + other technical support.

RaaS is similar to traditional B2B SaaS businesses, where companies can charge customers a flat fee or a mixed tiered fee based on the services purchased and usage (e.g., the number of end-user transactions on the Rollup).

RaaS can also offer integration with shared sorters like Espresso. However, in this case, they would lose sorting revenue, which is a major part of RaaS profits. Therefore, these partnerships require shared sorters and RaaS providers to contractually share profits.

But if RaaS is a wrapper built on top of existing Rollup frameworks, must it also share revenue with them?

Not necessarily.

So far, most of the Rollup frameworks released are open-source and do not allow building on top of them. RaaS providers can use the frameworks without permission to build no-code wrappers on top of them, with no obligation to share any profits with the underlying frameworks.

Can they enter into contractual agreements with Rollup frameworks to share profits?

Yes, but if they do:

They will lose part of their own profits; Another competing RaaS may choose not to share profits with the Rollup framework and dominate the economics in the long run.

Thus, from a game-theoretic perspective, for RaaS providers to survive, the rational decision is not to share profits with the underlying frameworks.

So if RaaS providers do not share profits, how do Rollup frameworks accrue value?

If anyone can freely use open-source frameworks to build a Rollup system, is it economically viable to develop open-source Rollup frameworks?

The answer is not so simple. For a Rollup framework to have "economic viability," it must generate sustainable long-term value. Idan Levin shared a great mental model for thinking about how to achieve this. Let’s expand on that model here. Rollup frameworks can accrue value in three main ways:

Indirect Value Accrual: If the framework is good, more and more teams will use it. This will attract developers and more attention to the ecosystem, helping the framework team further develop tools and create a positive reinforcement loop for the entire system.

Semi-Direct Value Accrual: Some companies built on the framework may be incentivized to share revenue with the framework network. For example, Base currently has an agreement with OP Stack to share part of the sorting fees with Optimism.

Why do they have the incentive to do this?

Because Base lacks the necessary developer ecosystem to keep up with the growth and development of the OP framework. Imagine if the OP framework completely changed one of its modules; they could choose not to provide developer support to Base to keep up with those changes.

Additionally, being part of a "Superchain" also provides network effects, such as cross-Rollup composability, which could be beneficial for chains like Base (and this may require sharing revenue with Optimism).

One point to note is that the incentive mechanisms for Rollups and Rollup frameworks may not always align. At any time, a Rollup can choose to go its own way, customize the framework, and abolish any revenue-sharing agreements.

3. Direct Value Accrual: Rollups built using the same framework (like OP Stack) can have gas as a native token (like OP), and all MEV in the network will belong to the framework team. Additionally, the team can also "extract" some supplementary direct value:

Establishing their own RaaS - frameworks can choose to compete in the RaaS space and offer their own sorter hosting and consulting services. If many frameworks start doing this, the RaaS business model will become difficult to sustain in the long run. This is because frameworks can leverage their reputation and position in the market to compete with any external RaaS providers built on top of them.

Leveraging composability between Rollups: Anyone can build a Rollup by using the framework as is or modifying it. However, to gain network effects and achieve interoperability with other startups built on the same framework, the framework may need to adhere to certain defined standards.

This is the chain rule of OP Stack. To be part of the Superchain, certain rules must be followed. These rules are defined by the OP governance body. For example, one of these rules might be that all Rollups in the Superchain must use OP as the gas token. This could also evolve to include MEV share rules, such as X% of cross-chain MEV revenue returning to the OP treasury.

The Superchain framework team can leverage the above three components to customize the "value capture" mechanism according to their goals and ambitions. To enable them to capture any direct value, there are several options (not exhaustive):

Deploy their own Rollup; Deploy their own RaaS; Manage framework standards through composability.

Conclusion

The rapid development of Rollup frameworks and Rollup as a Service (RaaS) providers in the blockchain space raises questions about their value accrual. While the execution layer captures most of the value, Rollup frameworks can gain indirect value through adoption and enhancement. Some Rollup frameworks may even share revenue, creating semi-direct value accrual. Furthermore, by deploying their own Rollups and leveraging composability between Rollups, frameworks can directly capture value. As the ecosystem evolves, achieving the right balance between competition and collaboration will be crucial for the sustainability of Rollup frameworks and RaaS providers.