RaaS: The Key Ingredient to a Rollup-Centric Roadmap

Introduction

One category of company we’ve been studying very closely at Reverie are Rollup-as-a-Service providers (“RaaS”). Simply put, RaaS providers help application developers launch rollups as quickly as possible by selling “off-the-shelf” products like sequencing, indexing, and analytics.

There’s a lot of meat to this category, so we wanted to write a piece that covers some of our observations on it. 

More specifically, we’ll give a quick overview of the products RaaS providers are selling, how they differentiate against each other, how they make money, and finally, share some internal Reverie opinions on RaaS businesses.

RaaS Service/Product Offering

While the RaaS service/product offering is still very much emergent, we’ve noticed most RaaS providers sell a similar bundle of services and products. From my conversations with RaaS founders, the bundle looks a little like this.

Services 

• Similar to playbooks used by traditional B2B companies, RaaS providers often start by selling services (side note: it’s amazing how well the traditional “service to product” playbook works in crypto).
• As part of the service offering, RaaS providers typically serve the role of a tech consultant, helping you evaluate rollup stacks (e.g., OP Stack, Arbitrum Orbit) and decide which stack is the best fit for your application. 
• This service component is very valuable, so it’s worth expanding on. The primary customer to RaaS providers are startups who want to launch applications on their own dedicated rollup. To them, the most important thing is building the app and growing users — spending months of developer time to get up to speed on rollup frameworks is not something they want to spend time on, nor is it something they should spend time on. Since RaaS providers’ entire business is based on understanding rollup frameworks and building developer tooling around them, they are perfectly positioned to help startups evaluate the framework options available to them.
• For example, they may help startups answer questions like what are the tradeoffs between different frameworks and DA layers? Are there customizations that would improve the rollups' application? What are the tradeoffs associated with increased customization (e.g., added complexity for integrations)? Offering guidance that is informed by experience with live customers could save months of development time for application teams.    

Infrastructure Products

• Sequencer: operating a sequencer is high stakes work — if it goes down, your rollup becomes unusable, making your users very unhappy. RaaS providers offer hosted sequencing that is highly reliable by way of redundancy measures. If there’s an issue with your sequencer, they can make sure that there is a quick failover process in place so that your rollup can continue operating with minimal downtime. You also have the added complexity of needing to pay DA costs on layer 1 while the offsetting sequencer fees accumulate on your rollup. For smart contract rollups on Ethereum, the 7-day withdrawal period means that you’ll always need to have at least a week’s worth of ETH on hand to pay DA costs. RaaS providers can help you manage these complexities, and some will even go so far as to front the liquidity you need on layer 1 for DA costs. 
• RPC’s: unreliable RPC endpoints also lead to poor UX as we saw with the Optimism and Arbitrum airdrops. If users are overloading your RPC node with transactions, large queries, or contract calls, RaaS providers can ensure that new nodes are automatically spun up to meet demand. 

Developer Tools

• Internal Tools: since RaaS customers are operators of both the rollup and the application, it’s particularly important that they have access to security infrastructure to help them protect the multi-sig keys used to facilitate software upgrades. Some providers also offer a control panel that gives a view into analytics, activity monitoring, and alerts to let you know if anything is wrong. 
• Other Tools: it's hard to capture everything in this category, but at a bare minimum, rollup operators need data indexing tools to query onchain information, standardized interfaces to perform actions such as token minting and burns or other transactions, and the ability to access offchain oracles.
• User Facing Tools: at the very least, rollup users will need a way to bridge to your rollup, a variety of wallet options (including account abstraction infrastructure), and a blockchain explorer to match the experience of apps on layer 1’s.   

RaaS GTM Strategies

There are at least a half a dozen RaaS providers in the market today, and it’s probably fair to say all of them are competing for startups (for the most part). One observation we’ve had is that RaaS providers generally take one of three GTM approaches to differentiate their offering.

Vertical Integration (e.g., Eclipse)

• Rollup frameworks and RaaS sell related and tightly coupled products, so vertical integration is a natural fit. Aside from the economic incentives, there are strategic reasons why RaaS operators and frameworks would both pursue a vertically integrated offering.
• From the perspective of the framework, a RaaS offering would allow them to get closer to the customer. With this proximity, they can create a tighter feedback loop to inform product decisions. It might even make sense to extend RaaS support to third-party frameworks and pull in the best components for their product offering.
• Similar to any emerging and hyper-competitive technology category, a big challenge for rollup frameworks is finding a monetization strategy that won't impede adoption. A RaaS product is the most straightforward way to achieve both objectives. The RaaS solution can bolster adoption of the framework by solving important pain points. At the same time, the opt-in nature of RaaS allows you to monetize in a way that doesn’t put any burden on customers that chose to operate their own rollup.
• The main challenge with this approach is resource constraints. Building a RaaS business in parallel to building a rollup framework may turn out to be biting off more than you can chew.

Framework-Aligned (e.g., Conduit)

• A framework-aligned RaaS provider will tie themselves to a specific framework like OP or Arbitrum. By aligning with an existing framework, the RaaS provider can gain a huge distribution advantage. 
• For example, by aligning with Optimism, Conduit was able to piggyback off of Optimism’s brand and become the default option for startups that choose Optimism as their framework. Other providers such as Slush are aligning themselves with emerging rollup frameworks like Starknet to gain a distribution advantage in another ecosystem.
• Along with a boost to distribution, this approach allows you to throw all resources at building one, truly great product. Consider a recent case study in which Aevo switched their RaaS solution to Conduit. They did this because Conduit was running on the newest version of Optimism, and this greatly improved their product. By focusing on a single framework, Conduit can guarantee that customers are always running on the latest version of the codebase.   
• The downside is that a single framework is unlikely to support all use cases, so you may limit your market to some degree (before expanding to support additional frameworks at least).       

Framework Agnostic (e.g., Caldera)

• A framework agnostic RaaS provider supports a wide range of rollup frameworks (e.g., OP, Arbitrum) with their RaaS products and services.
• If a framework agnostic provider is able to become the first touch point for startups, you could see how the underlying frameworks could become just another technology decision rather than a signal of brand alignment which we see today. 
• The framework agnostic approach allows RaaS providers to give customers more options during onboarding. And by operating multiple frameworks in production, they can see which components are most valuable and incorporate these learnings into the guidance they provide to new customers. 
• Similar to the vertically integrated approach, the challenge with this is mainly related to resource constraints. Each framework requires significant investment to support, and trying to support too many frameworks could lead to half-baked offerings.    

RaaS Business Models

At the moment, it’s looking like RaaS providers have two sources of revenue — (i) sequencing fees, and (ii) infrastructure and tooling. From what we’ve seen, the services component is typically provided for free.

Sequencing Fees

• RaaS providers run sequencers which order transactions for apps. In return, they charge a fee for performing the service.
• We’ve seen two ways RaaS providers charge sequencing fees: a revenue-share component where the application shares a percentage of revenue it receives from the transaction fees end-users pay to use its app and a simple monthly SaaS fee for hosting a sequencer.
• The fee dynamics are interesting to think about, so let’s do a quick aside on this point. For the RaaS provider, there’s a fixed cost to running a sequencer as well as a variable cost that scales with the number of transactions. And as referenced above, some also take on the risk of fronting DA costs for their customers on Ethereum. In an ideal world, as a RaaS provider, you can charge both a monthly SaaS fee to cover your fixed operating cost as well as a revenue share component to cover your variable costs and capture upside on applications that are taking off. This latter point is critical — if you can’t capture upside from the growth of your customers, the economics of running a sequencer product don’t look great. If you have the capital, then fronting these DA costs on your customer’s behalf could make it easier to justify this revenue share component.
• That said, whether RaaS providers will be able to charge a revenue-share component in the steady state will depend on the leverage applications have over RaaS providers. And today, it’s too early to say who holds the pricing leverage. (Gun to the head though, similar to how things work in the payments industry, our sense is large applications will have pricing leverage over RaaS providers while small applications won’t).

Infrastructure, Tooling, and More

• RaaS providers can charge SaaS fees for a wide range of critical infrastructure services. By owning the customer relationship, they have an edge over incumbent providers to capture the highest value services and offer discounts for bundling (e.g., use our RPC service instead of Alchemy’s, and we’ll offer you discounts on other services). It’s also likely that RaaS providers have cost advantages over incumbents, as their architecture allows them to easily extend support to new chains as they launch.  

• Due to resource constraints, RaaS providers typically need to partner with outside companies in order to address all the needs of its customers. For example, Conduit recently rolled out their integrations program, and Caldera has announced numerous similar partnerships. The RaaS’s position as a distribution channel for these partners lends itself well to establishing a marketplace or reseller business model, very similar to that of AWS and its third-party “plug-ins.”

Miscellaneous Thoughts

There were a few more things I wanted to discuss that didn’t fit neatly into the earlier sections, so I thought to throw them all in this grab-bag section.

RaaS vs Frameworks 

While RaaS providers and the frameworks are on relatively friendly terms today, it seems to me that they will inevitably compete, particularly to capture the sequencing market. If competition does heat up, I’d argue that RaaS providers are best positioned to reap the benefits. Some reasons for why: 

• As we’ve begun to see already, the majority of these startups go directly to RaaS providers to outsource the complexities of deploying a rollup. If this continues, RaaS providers will own the top of the funnel, and as a consequence of that, the customer relationship. If things do play out this way, RaaS providers may be in the position of making the underlying frameworks as merely a technology choice to facilitate various use cases. 

That said, it’s also possible the frameworks will fight back against the RaaS providers. On that vein, here are some open questions we’re discussing at the Reverie offices:

• Is it possible the frameworks will be able to charge apps for using their framework? (While the network effects around framework adoption are powerful, my sense is the framework in and of itself will be very difficult to monetize. That said, it’s still an interesting question to think about). 
• Each framework the RaaS providers supports requires a significant investment on their part (primarily development time). On that point, it’s unlikely that one RaaS provider will be able to support every single framework in the market and design customized products around it. Is it then possible for the frameworks to compete with RaaS providers by providing critical services that they know solve unique pain points of their stack and are difficult for RaaS players to provide? For example, ZK rollup frameworks could offer better pricing on proofs by aggregating demand from rollups and routing to a network of proving systems and operators. 

Cross-rollup MEV

• The current consensus thinking seems to be that rollups will have significant MEV, and that cross-rollup MEV will be a honeypot. From this assumption, it is easy to understand why most think that shared sequencers are best positioned to capture this value. I think the assumption here is still a very open question, and I’d even go so far as to push back on the assumed outcome. 

• If cross-chain MEV does prove to be a large part of the market, RaaS providers will have to decide whether to integrate shared sequencer partners or launch their own shared sequencer offerings. Let’s assume for a second that in the future, RaaS providers will be running sequencers for the majority of new rollups and that this service represents the lion’s share of their revenue (and also provides a view into the mempool of every rollup that uses their services). In that world, I think it's far more likely that RaaS providers launch their own shared sequencer product rather than partner with an outside vendor.
  

• Moreover, RaaS providers could leverage their view over all these mempools to provide an order flow auction, and leverage their control over the sequencers to offer top of block auctions for settlement. This would give searchers the ability to see valuable transactions, fill them, and settle on their supported chains simultaneously. 

Conclusion 

There are tons of other interesting questions about RaaS providers, but for the sake of brevity, we’ll end things here. If there’s one thing that’s clear to us, it’s that RaaS providers are an incredibly exciting category of business in crypto. It’s a category we’re watching very closely.

If you’re building a RaaS or related company, we’d love to chat.

Many thanks to Andrew Huang, Neel Somani, Rachid Flih, Cem Ozer, xPara, and Dino for reviewing earlier versions of this post.