Eclipse founder: some misunderstandings about RaaS

Author: Neel Somani, founder of Eclipse, former quantitative researcher at Citadel; translation: Jinse Finance xiaozou

At Eclipse, we are building customizable application-specific rollup infrastructure to support verticals such as Gaming & Social, DePIN, and DeFi.

We've been working on this for 10 months or so, and I feel the need to clear up some misconceptions. Here are some thoughts on application-specific rollups:

1. The existing market division is wrong

**(1)**Rollup Framework is not a charity

Rollup frameworks like OP Stack are code bases that deploy key components of rollups. They won't charge you for code usage, but they need to capture value somehow. To summarize, there are three places where value can be obtained:

Execution: transaction ordering, execution and (zk-rollup) proofs

Settlement: bridge and verify validity proofs or error proofs

· Data Availability: Publish Transaction Order

But only execution is suitable as a business model for the rollup framework:

Settlement: After the Bedrock upgrade, Optimism only pays Ethereum a settlement fee of about $5 per day. The rest of OP Stack's overhead comes from issuing blocks and related fees. Competing settlement protocols may earn even less.

Data Availability: Fragmented DA layers are less risky in securing the network than shared Data Availability (DA) layers such as Celestia. Many rollups don't want to migrate their DA off of Ethereum because that would sacrifice their consistency with Ethereum.

Any market segment should include rollup frameworks in at least one execution-related category, and any product that provides execution services can compete with rollup frameworks.

(2) Isolated rollup as a service (RaaS) is untenable

The naive explanation for RaaS is actually Isolated Sequencer-as-a-Service (iSaaS). These companies don't have their own protocol, but they are deploying an existing open source rollup framework and running a sequencer. OP Stack has a partnership with iSaaS.

The iSaaS business model is to charge some recurring statutory fees in addition to charging a percentage of the sequencer fee. (Additional support services, consulting, or custom feature development do not represent a scalable business model.) To be clear, this would be a direct competitor to shared sequencer networks such as Espresso, Astria, Radius, etc.; but they also have Some fatal flaws.

A big problem with iSaaS is that it doesn't align with the rollup framework. As mentioned above, an optimistic rollup framework like OP Stack has to monetize the sorter fees. (A zk-rollup framework might be able to ignore the orderer fee and only keep the prover fee.)

Other high-level problems with this kind of business are that it is commoditized, easy to enter, and has no network effects, unlike a shared orderer. iSaaS lacks the economies of scale of shared sequencers because each sequencer is isolated.

(3)Op****timistic rollup framework must provide its own S****aaS

In order to perform well, iSaaS may return sequencer fees into an optimistic rollup framework, leaving only recurring fiat fees.

But now both iSaaS and rollup frameworks must be independently profitable. Ideal pricing for large enterprises would be high recurring fiat payments, but low orderer fees. However, iSaaS does not have the flexibility to reduce the orderer fee, because the orderer fee does not belong to them originally, but is passed back to the rollup framework. If the iSaaS does not share revenue with the rollup framework, the rollup framework can deploy its own iSaaS and, since the trust is already established, may penetrate the market more deeply.

The reason there is so much iSaaS popping up is because it seems attractive to less experienced readers. It looks like SaaS, so non-crypto investors may find it easier to extrapolate fiat income. But iSaaS will struggle to compete with rollup frameworks that have their own SaaS with protocol-native revenue and tokens. The latter has more options in terms of pricing, tokens can be used to subsidize promising projects, subsidize customer acquisition costs and fixed running costs (discussed below).

Protocol-native network effects and fixed cost sharing will create stronger unit economics for protocols with higher visibility, making rollup providers somewhat winner-take-all.

(4) ADJUSTED MARKET MAP

Now I can show how I tweaked the graphics in the Messari article, which I thought looked reasonable at the time:

(Messari Market Chart)

(Adjusted Market Chart)

I'm going to rename the "No Code Deployment" category and the Rollup SDK to Rollup Frameworks because many Rollup frameworks don't provide a full SDK to developers. I'd also like to modify this diagram of the Celestia ecosystem:

(Celestia Ecosystem Diagram)

(Adjusted Celestia Ecosystem Diagram)

I will remove RaaS, billing layer and virtual machines. For projects under the Rollup Framework category, they will almost certainly find themselves in another category as well, or they will not be profitable.

2. There is no free lunch: economic and technical constraints

(1) Most apps should not have their own r****ollup

The easiest way to demonstrate the economics of a rollup for a specific application is to look at live rollups: Optimism (after Bedrock upgrade). This is the approach the Optimism team took to make the Dune dashboard.

The following assumes that the gas price on Ethereum is approximately 25 gwei:

· The one-time deployment cost of the OP Stack main network chain is about 1 ETH

· The fixed cost of the OP Stack chain (even if the number of transactions running is 0) is about 0.5 ETH per day

· Variable cost is 7.5 * 10^-5 ETH per transaction

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

This variable cost is low, but not Solana-level low, and the fixed cost can be amortized over many transactions. In a future EIP-4844, we can pretty well assume this cost drops by a factor of 10. Still, let's say an ETH price of $2000 represents a floor of $0.015 per transaction plus some amortized fixed costs.

We might consider 0.00001 ETH (approximately $0.02 at time of writing) as a reasonable transaction token to cover this fixed cost, so we would need 50,000 transactions per day for a particular application rollup to be worthwhile. Before EIP-4844, it was around $0.17 per transaction, and optimistically, after EIP-4844, it was $0.03 per transaction. We may add a small premium, so the (shared) sorter backing chain is economical.

So while something like Opclave is cool (I really like the idea, we're chatting with the Dogan team that we might incorporate this functionality into Eclipse rollup), it doesn't make much sense as a mainnet OP Stack chain . The constraint here is that the OP Stack chain is anchored on Ethereum, whose block space is expensive, and the intent of Optimism is to be consistent with Ethereum.

Given these unit economics, those small DeFi dApps and NFT projects don’t make much sense on their own chains. For these dApps, it might make sense to subsidize gas costs if the long-term unit economics of Ethereum L2 make sense for their dApps, or they might be willing to take the loss on their appchain.

If an app requires too much transaction volume, an Ethereum-pegged rollup won’t work either, as transaction fees of more than $0.01 may be too high. These types of apps will require a novel approach, such as the one Eclipse is building with our highly parallel virtual machines and sovereign rollup architecture.

(2) Customizable rollup must be constrained

As mentioned above, OP Hacks will not be included in Optimism’s Superchain. This makes sense because in order to properly settle or provide state ordering for rollups, we need some invariants to be true. Any modifications will need to be audited before supporting real economic value.

Another good reason to constrain application-specific rollups is to look at Cosmos adoption. The Cosmos SDK is very general, but it never sparked the huge number of different chains you might expect. This may be because the customization process requires too much technical complexity, or more likely because the long tail of the application is well suited to a small number of architectures. Domain-specific templates, on the other hand, can address common pain points across different verticals and provide a repeatable architecture.