- by Shivanshu Madan
If the future consists of an onchain economy of thousands of rollups, we’re definitely on the right timeline in the present. From the Optimism stack and Polygon chain development kit to Caldera and Stackr, recent months have seen a variety of Rollup frameworks and Rollups-as-a-Service (RaaS) providers hit the market. These frameworks offer modular (often open-source) codebases for the different components of a rollup, allowing developers to pick and choose from a variety of custom options for each layer of the stack.
In this blog post, we analyze some of his arguments and also explore the intricate dynamics of value accrual for rollup frameworks and RaaS providers. From the individual layers to Superchains, we unravel the hidden mechanisms behind the value creation and capture by rollup frameworks and RaaS providers.
Rollups are applications that perform offchain execution and post the execution data on another (host) blockchain. By doing so, they derive the security properties of the host chain. The rollup application itself could be just a single State transition function, or it could be a separate Blockchain for which canonical state is maintained by a group of nodes
A rollup framework is a pre-built codebase that implements the essential components of a rollup. Instead of building a rollup from scratch, developers can use these existing codebases (often packaged as SDKs) and customize them to their specific needs. Examples of open-source rollup frameworks include OP Stack and Arbitrum Orbit.
Rollups-as-a-Service, or RaaS protocols, are no-code wrappers built on top of existing rollup frameworks. They enable developers to quickly deploy a rollup from scratch by selecting custom features from drop-down menus. RaaS companies often handle the sequencing of the deployed rollups and offer additional consulting services.
To understand how the value flows in and out of the entire stack, it is important to first understand the architecture of a rollup and how the different layers interact with each other. There are broadly 3 layers that constitute a rollup stack:
1. Execution - This layer executes the transactions by applying the State Transition Function (STF) on the existing state of the rollup. Depending on how ‘centralized’ the rollup is, an execution node could own a range of responsibilities from ordering transactions and executing them to posting them on L1 and creating fraud/validity proofs.
The execution layer is the ‘user-facing’ layer, where the money enters the rollup stack. Users are charged a transaction fee (gas) which is usually a margin over the various costs that the execution layer has to pay (more on this later). This layer can also extract additional value from the users by ordering transactions in certain ways (also known as MEV: Maximal Extractable Value).
2. Settlement - This includes verifying the 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 build their own settlement layer as well.
Settlement isn’t a very high-value-capture layer of the stack as verification costs are usually meager. Optimism only pays ~$5 a day to Ethereum for settlement. A competitive settlement layer would cost even less. (as also highlighted in Rollups-as-a-Service Are Going To Zero)
3. Data Availability - DA includes broadcasting the ordered transaction data to the rest of the network (also sometimes called Data Publishing). It ensures that anyone can permissionlessly reconstruct the rollup state by simply applying the broadcasted transaction data to some previously finalized state.
DA costs form a major portion of all rollup costs. Posting data on a highly-secure layer like Ethereum can be quite expensive. Cheaper and faster DA alternatives are being actively developed by protocols like Celestia, Avail, and EigenDA. Rollup frameworks could also consider building their own DA layer, but a fragmented DA has high bootstrapping costs and makes interoperability more complex.
It might help to think of the Execution layer as a B2C model and Settlement and DA layers as B2B models:
Execution layer buys block space from the DA layer and sells its execution services directly to the end user (customer). It also buys verification & bridging services from the Settlement layer
DA layer sells block space to another business - the Execution layer
Settlement layer provides settlement services to another business - the Execution layer
In such a setup in competitive markets, the majority of value capture happens directly from the end user in the execution layer of the stack, so it makes sense to break it down further and analyze its value flows independently.
The execution layer generates revenue by charging users for each transaction and pays operational costs to the other businesses (layers) in the stack.
Revenue: The incoming value can be categorized as follows:
Gas costs paid by end users per transaction
Cross-domain MEV* (*If the framework provides sequencing for multiple rollups on the same DA layer. Could be tough to extract otherwise)
MEV depends on the transaction flow (the “extractable” value will be different for each set of transactions) and is often hard to predict in advance. The gas costs charged to the users are then usually a margin over the combined predictable costs.
Costs: The value outflows from the execution layer are the following:
Node operational overhead
Execution (compute) costs
Proving (validity/fraud proofs) costs
Data posting costs (variable based on congestion on the DA layer)
Often, all the execution layer responsibilities are borne by one centralized sequencer node. This single node accrues all the revenue from the users and is responsible for paying the DA and Settlement costs. At other times, the setup can have different nodes for different responsibilities:
Sequencers order transactions and post data on the DA layer. They ‘earn’ the transaction fees paid by users and pay sequencing overhead and data posting costs. Sequencing can also be done by a pre-selected set of sequencers or decentralized sequencers like Espresso. Sequencers are also responsible for posting state changes to the Settlement layer and paying the settlement costs
Prover nodes are responsible for generating proofs. It can be a central prover or a decentralized set of proving nodes. Their costs comprise the proof-generation overhead. Depending on the setup, provers either ‘sell’ the proofs to the sequencer, or post it to the settlement layer directly
Rollups can also have other full nodes (or full-verifying light nodes) that execute all transaction batches and maintain the canonical state of the rollup. These full nodes don’t necessarily accrue any direct revenue but indirectly capture value by holding the rollup’s native gas token
The above is a broad differentiation of the responsibilities of different nodes. Which node takes up which tasks can differ based on how the rollup team architectures their setup. For the sake of simplicity in this blog, we will stick to a centralized sequencer setup where one node performs all the required execution tasks.
The question then is: If the execution layer drives the most value, which participant in the stack is best positioned to capture it?
Anyone who runs the sequencing node and performs the various activities associated with it!
This can be the rollup team themselves. Or, as mentioned at the beginning of the article, RaaS providers often handle the sequencing for the rollups deployed using them. In fact, this is the majority portion of revenue for the RaaS providers.
There are 3 major areas a RaaS can capture value:
Sequencer Hosting: The RaaS provider runs the sequencer and associated activities for the rollup. It's a division of labor where the rollup team brings the innovation (the app they are building) and the RaaS provider does everything else. The sequencer orders transactions, posts data on L1, and creates proofs if/when required
Additional Infra: Block explorers, bridges, etc.
Dedicated Support: Consulting and partnering on infra decisions (how to sequence, MEV, etc.) + other technical support
RaaS is similar to a traditional B2B SaaS business where the business can charge their customers a flat fee or a hybrid-tiered fee based on the services bought and the usage (number of end-user transactions for a rollup, for example).
RaaS could also provide an integration with a shared sequencer like Espresso. However, in this case, they would lose out on the sequencer revenue, which makes up a major portion of RaaS’s profits. These partnerships therefore require contractual profit sharing between the shared sequencer and RaaS provider.
But if RaaS is a wrapper built on top of an existing rollup framework, it must share revenue with them as well, right?
Well, not necessarily.
Most of the rollup frameworks released so far have been open-source and permissionless to build upon. RaaS providers can use the framework permissionlessly to build a no-code wrapper on top of it and aren’t obligated to share any profits with the underlying framework.
Can they have a contractual agreement with the rollup framework to share profits?
They can, but if they do so:
They lose out on some of their own profits
Another competitor RaaS could choose not to share profits with the rollup framework and would be economically dominant in the long term
Therefore, game theoretically, for RaaS provider to survive, the rational decision is to NOT share profits with the underlying framework.
If anyone can permissionlessly build a rollup using the open-source framework, is it even an economically viable decision to develop an open-source rollup framework in the first place?
The answer is not so straightforward. For a rollup framework to be ‘economically viable’, it needs to generate sustainable, long-term value. Idan Levin shared a good mental model to think about how this can be done. Let’s expand on that model here. There are 3 major ways rollup frameworks can accrue value:
Indirect value accrual: If the framework is good, more and more teams will use it. This will attract developer eyes and more mindshare to the ecosystem. Attracting mindshare is always a net positive as it will help the framework team in developing the tools further. Any enhancements that any of the teams make can be incorporated into the OG framework. This creates a positive reinforcement loop for the entire system.
Semi-direct value accrual: Some rollups building on top of the framework might be incentivized to share revenue with the framework network. For example, Base currently has an agreement with OP Stack where they share part of the sequencing fee with Optimism.
Why are they incentivized to do so?
Because Base doesn’t have the necessary developer ecosystem to keep up with the growth and development of the OP framework. Imagine if the OP framework changes one of the modules completely, they could choose not to provide the developer support to Base to keep up with the changes.
In addition, being a part of the ‘Superchain’ provides network effects like cross-rollup composability that chains like Base could find useful (and this could have a requirement to share revenue with Optimism)
One important caveat here is that the incentives of rollups and rollup frameworks might not always be aligned. At any point, the rollup could choose to follow its own path by customizing the framework and scrapping any revenue share agreements.
3. Direct value accrual: Through the framework’s own rollup (e.g., Optimism mainnet) built using the same framework (e.g., OP Stack). The gas could be in the native token (e.g., OP) and all the MEV from this rollup would accrue to the framework team. In addition, the team could also ‘extract’ some supplementary direct value:
Building their own RaaS - The framework could choose to compete in the RaaS space and provide its own Sequencer hosting + consulting services. If a lot of frameworks start doing this, this could make the RaaS business model unsustainable in the long term. This is because the framework could leverage its credibility and position in the market to outcompete any external RaaS providers built on top of it.
Inter-rollup composability as leverage: Anyone can build a rollup by using the framework as it is or modifying it. However, to gain network effects and interoperability with other rollups built on the same framework, the framework may require adherence to certain defined standards.
This is what OP Stack does with the Law of Chains. To be a part of the Superchain, you have to follow certain rules. These rules are defined by the OP governance. For example, one of these rules could be that all rollups in Superchain have to use OP as the gas token. This could also evolve to include MEV share laws, for e.g., X% of cross-chain MEV revenue would go back to the OP treasury.
The rollup framework teams can play with the above 3 segments to tailor their ‘value capture’ mechanism to their goals and ambitions. For them to accrue any direct value, a few (non-exhaustive) options could be:
Deploying own rollup
Deploying own RaaS
Leveraging composability to govern standards for the framework
The rapid development of rollup frameworks and Rollups-as-a-Service (RaaS) providers in the blockchain space has sparked questions about their value accrual. While the execution layer captures the lion's share of value, rollup frameworks can gain indirect value through adoption and enhancements. Some rollups may even share revenue, creating a semi-direct value accrual. Furthermore, by deploying their own rollups and leveraging inter-rollup composability, frameworks can directly capture value. As the ecosystem evolves, striking the right balance between competition and collaboration will be vital for the sustainable growth of rollup frameworks and RaaS providers.
At Stackr, we're exploring the best ways to build a transparent and sustainable business that opens the gates of crypto to the Web2 world. As we grind towards shipping our rollup framework, we are also experimenting and evaluating the various ways of accruing value to our customers and partners. If you have ideas, thoughts, or arguments, we would love to hear from you!
Reach out to us via Twitter or drop an email at gm[at]stackrlabs.xyz.