Rollups-as-a-Service Are Going To Zero

Long live Rollups-as-a-Service.

This blog post is adapted from a presentation that I gave at Modular Summit.

At Eclipse, we're building customizable app-specific rollup infrastructure to support verticals like gaming & social, DePIN, and DeFi.

Since we've been working on this for ~10 months, I feel compelled to push back on misconceptions in the space. Here are some thoughts about app-specific rollups:

Existing market segmentations have it wrong.

Rollup frameworks aren't charities.

Rollup frameworks like OP Stack are codebases that implement the key components of a rollup. They're not going to charge you to use their code, but they need to capture value somehow. At a high level, there are three places to capture value:

1. Execution: sequencing transactions, executing, and (for a zk-rollup) proving
2. Settlement: bridging and verifying validity proofs or fault proofs
3. Data availability: publishing the order of transactions

But only execution is suitable as the rollup framework's business model:

• Settlement: Post-Bedrock, Optimism only pays ~$5 a day to Ethereum for settlement. The rest of the OP Stack costs are from posting blocks and the associated overhead. A competitive settlement layer would likely earn even less.
• Data availability: A fragmented DA layer will have less stake securing the network compared to a shared DA layer such as Celestia. Many rollups don't want to move their DA off of Ethereum anyway because they would sacrifice their Ethereum-alignment.

Any market segmentation should also include rollup frameworks in at least one category related to execution, and any product that offers execution is competitive with the rollup framework.

Isolated Rollups-as-a-Service aren't defensible.

The naive interpretation of RaaS is actually isolated Sequencers-as-a-Service (iSaaS). These are companies who have no protocol of their own, but they're deploying existing open-source rollup frameworks and running a sequencer. OP Stack has a partnership with an iSaaS.

The business model for iSaaS is to charge some recurring fiat amount in addition to some percent of sequencer fees. (Additional support services, consulting, or custom feature development don't represent scalable business models.) To be clear, this would be a direct competitor to shared sequencer networks such as Espresso, Astria, Radius, and more; but they have some fatal disadvantages.

A big problem with iSaaS is that it is at odds with the rollup framework. As described above, an optimistic rollup framework like OP Stack has to monetize via sequencer fees. (A zk-rollup framework might be okay with neglecting the sequencer fees and keeping only prover fees.)

Other high-level problems with such a business are that it is commoditized, easy to enter, and there are no network effects, unlike a shared sequencer. iSaaS lacks the economies of scale of a shared sequencer since each sequencer is isolated.

Optimistic rollup frameworks must offer their own sequencer-as-a-service.

To play nice, the iSaaS might return sequencer fees to the optimistic rollup framework, keeping only the recurring fiat payment for itself.

But now the iSaaS and the rollup framework must both independently be profitable. For a large enterprise, the ideal pricing would be a high recurring fiat payment but low sequencer fee. But the iSaaS doesn't have the flexibility to decrease sequencer fees, since the sequencer fees aren't theirs to begin with; they're passed back to the rollup framework. If the iSaaS doesn't share revenue with the rollup framework, the rollup framework can deploy their own iSaaS and likely more deeply penetrate the market due to established trust.

The reason why so many iSaaS are popping up is because it seems attractive to the unsophisticated reader. It looks like SaaS, so a non-crypto investor might find it easier to reason about the fiat revenue. But iSaaS will have difficulty competing with a rollup framework with its own sequencer-as-a-service, which has protocol native revenue and a token. The latter has more optionality in pricing, and the token can be used to subsidize customer acquisition costs and fixed costs of running a chain (described below) for promising projects, which pays itself off as protocol native revenue.

Protocol-native network effects and amortized fixed costs will create stronger unit economics for protocols with traction, making rollup providers somewhat winner-takes-all.

Refined Market Maps

Now I can show how I'd adjust the graphic in this Messari piece, which I thought looked reasonable at the time:

I'd rename the No Code Deployment category, and I would rename Rollup SDKs to Rollup Frameworks, because many rollup frameworks don't provide a full SDK to developers. I would also modify this Celestia ecosystem diagram:

I'd remove Rollups-as-a-Service, Settlement Layers, and Virtual Machines. And for projects in the Rollup Framework bucket, they will almost certainly have to find themselves in another category as well, because otherwise they can't monetize.

No Free Lunch: Economic and Technical Limits

Most apps should not have their own rollup.

The easiest way to demonstrate the economics of app-specific rollups is by looking at a live rollup: Optimism (post-Bedrock). Props to the Optimism team for making this Dune dashboard.

The following assumes a ~25 gwei gas price on Ethereum:

1. One-time cost of deployment for an OP Stack mainnet chain: ~1 ETH
2. Fixed cost of an OP Stack chain, even if 0 transactions are run: ~0.5 ETH a day
3. Variable cost: 7.5 * 10^-5 ETH per transaction

To get the fixed cost, I took the average overhead cost per transaction and multiplied by the number of transactions run that day, and confirmed it by running an OP Stack chain on mainnet.

This variable cost is cheap but not quite Solana-level cheap, and the fixed cost can get amortized over many transactions. In the future with EIP-4844, we might generously assume this cost to come down by 10x. Still, assuming a $2,000 ETH price this represents something like a $0.015 lower bound per transaction plus some amortized fixed cost.

We might consider something like .00001 ETH (~$0.02 at the time of writing) as a reasonable transaction markup to cover this fixed cost, so we need 50,000 transactions per day for an app-specific rollup to make sense. The price for each transaction is roughly $0.17 before EIP-4844, and optimistically $0.03 after. We might add a small premium so it's economical for a (shared) sequencer to support the chain.

So as cool as something like Opclave is (I really like the idea, we're chatting with Dogan's team and we might incorporate this feature into Eclipse rollups), it doesn't make sense as a mainnet OP Stack chain. The constraint here is that the OP Stack chains are anchored to Ethereum which has expensive blockspace, and Optimism is intent on Ethereum-alignment.

With these unit economics in mind, dApps that don't make a lot of sense for their own chain are small DeFi dApps and NFT projects. What might make sense for these dApps is to subsidize the cost for gas if the long run unit economics of an Ethereum L2 make sense for their dApp, or they could be willing to take a loss on their app chain.

If an app requires too much transaction volume, then an Ethereum-anchored rollup doesn't work either, because a transaction fee greater than $0.01 is likely too high. These kinds of apps would require a novel approach such as what Eclipse is building with our highly parallelized virtual machine and sovereign rollup architecture.

Customizable rollups must be constrained.

Source: Introduction to OP Stack Hacks

As mentioned in the screenshot above, OP Hacks won't be included as part of Optimism's Superchain. That makes sense because in order to properly settle or provide stateful sequencing for the rollup, we need some invariants to hold true. Any modifications also need an audit before supporting real economic value.

Another good reason to constrain app-specific rollups is by looking at the adoption of Cosmos. The Cosmos SDK is incredibly generic and yet it never inspired the plethora of diverse chains that you might expect. This could be because customization requires too much technical sophistication, or more likely because the long tail of applications is well-suited by a handful of architectures. On the other hand, sector-specific templates can solve popular pain points for different verticals and provide repeatable architectures.

I'm interested to get the community's thoughts. Feel free to reach out via Twitter @neelsalami or @EclipseFND.