Rollup-as-a-Service (RaaS)

What Is Rollup-as-a-Service?

Rollup-as-a-Service (RaaS) is a managed infrastructure model where third-party providers handle the deployment, operation, and maintenance of custom rollup chains on behalf of their clients. Rather than assembling a blockchain engineering team to build and run a rollup from scratch, teams select a framework, configure parameters like gas tokens and governance rules, and let the RaaS provider handle sequencer operation, data availability posting, and node infrastructure.

The concept mirrors the evolution of cloud computing: just as AWS let companies skip building data centers, RaaS providers let projects skip building blockchain infrastructure. The underlying rollup still inherits security from its settlement layer (typically Ethereum), but the operational complexity is abstracted away. This has made dedicated rollups accessible to teams that previously would have deployed on a shared Layer 1 or general-purpose Layer 2.

The RaaS market emerged alongside the modular blockchain thesis, which separates execution, settlement, consensus, and data availability into independent layers. By treating each layer as a pluggable component, RaaS providers can offer mix-and-match configurations: an OP Stack execution layer posting data to Celestia and settling on Ethereum, for example.

How It Works

A RaaS deployment follows a modular architecture where each layer of the rollup stack can be independently configured. The provider manages the integration between these layers and handles ongoing operations.

Core Components

Every RaaS deployment involves four primary layers:

1. Execution layer: the virtual machine that processes transactions. Most RaaS providers offer EVM-compatible execution through OP Stack or Arbitrum Nitro, though some support WASM runtimes via Arbitrum Stylus
2. Settlement layer: where the rollup posts state commitments and resolves disputes. Ethereum is the dominant settlement layer, though Arbitrum Orbit chains must settle to Ethereum or an Ethereum-derived chain
3. Data availability layer: where transaction data is published so anyone can reconstruct the rollup state. Options include Ethereum calldata, EIP-4844 blobs, or dedicated DA layers like Celestia, EigenDA, and Avail
4. Sequencer: the component that orders transactions and produces blocks. RaaS providers typically run centralized sequencers with high uptime guarantees, though shared sequencer and decentralized sequencer designs are emerging

Deployment Flow

A typical RaaS deployment follows these steps:

1. Select a rollup framework (OP Stack, Arbitrum Orbit, ZK Stack, or Polygon CDK)
2. Choose a data availability layer based on cost and security requirements
3. Configure chain parameters: chain ID, block time, gas token, and governance model
4. Deploy through the provider's dashboard or API, which provisions sequencer nodes, bridge contracts, and RPC endpoints
5. Connect ecosystem tooling: block explorers, indexers, oracles, and wallets

Providers like Caldera and Conduit report that this process can complete in under 30 minutes for optimistic rollup configurations, compared to the six to nine months a team might spend building equivalent infrastructure from scratch.

Framework Comparison

The choice of rollup framework is the most consequential decision in a RaaS deployment:

No single RaaS provider currently supports all four frameworks. Framework choice constrains which providers are available and which ecosystem tools are compatible.

Major RaaS Providers

Several providers have established themselves in the RaaS market, each with different framework support and operational focus:

• Caldera: supports Arbitrum Orbit, OP Stack, Polygon CDK, and ZK Stack deployments. Known for reliability in gaming and DeFi workloads
• Conduit: self-service platform focused on OP Stack and Arbitrum Nitro chains, with built-in monitoring, logs, and transaction tracing
• AltLayer: offers both persistent rollups and ephemeral "Flash" rollups designed for temporary high-traffic events. Supports optimistic and ZK frameworks with planned expansion to additional VMs
• Gelato: no-code deployment interface with managed RPC services. Supports Arbitrum Orbit and OP Stack with auto-scaling infrastructure

Use Cases

Application-Specific Chains

Projects with high transaction volumes or specialized execution requirements can launch dedicated app-chains through RaaS providers. A gaming studio, for example, might deploy an Arbitrum Orbit chain with custom gas tokens that players earn in-game. The chain handles game transactions without competing for block space on a shared Layer 2, delivering predictable fees and throughput.

DeFi Protocol Isolation

DeFi protocols can use RaaS to isolate their execution environment, gaining control over transaction ordering to mitigate MEV extraction. dYdX's move from a ZK-rollup to a Cosmos app-chain demonstrated this motivation, though RaaS makes similar isolation achievable without building a standalone chain from the ground up.

Enterprise and Permissioned Deployments

Enterprises that need blockchain infrastructure but require compliance controls can deploy permissioned rollups through RaaS. These chains can restrict validator sets, implement KYC-gated access, or customize governance rules while still settling to a public Layer 1 for transparency and auditability.

Sovereign Rollups

Sovereign rollups use a data availability layer for data publishing but handle their own settlement and consensus. RaaS providers can deploy sovereign configurations where the rollup community maintains full control over upgrade paths and fork decisions, trading Ethereum's settlement security for governance independence.

Sovereignty vs. Shared Security

The central tension in RaaS deployments is between sovereignty and shared security. A rollup that settles to Ethereum inherits its economic security: billions of dollars in staked ETH backing the validity of rollup state transitions. This means the rollup does not need to bootstrap its own validator set or worry about 51% attacks at the rollup level.

The tradeoff is reduced autonomy. The rollup's upgrade path, dispute resolution mechanism, and finality timeline are constrained by the settlement layer's design. Optimistic rollups inherit a 7-day challenge window for withdrawals. ZK-rollups achieve faster finality but pay higher computational costs for proof generation.

Sovereign rollups flip this tradeoff: they gain full governance control at the cost of needing to define and enforce their own security model. This is analogous to the difference between running an application on a managed cloud platform versus operating your own servers.

The Bitcoin L2 Alternative

While the Ethereum ecosystem has converged on rollups as its primary scaling strategy, Bitcoin's Layer 2 landscape takes a fundamentally different approach. Rather than each application launching its own chain, Bitcoin L2 solutions provide shared infrastructure that all applications can use.

Spark, for example, scales Bitcoin by moving UTXO ownership off-chain through threshold signature key rotation, allowing instant transfers and stablecoin support without requiring applications to deploy or manage their own chains. Lightning Network uses payment channels for the same goal: a shared, open protocol that any wallet or application can connect to.

This shared-infrastructure model avoids several problems that RaaS-deployed rollups face:

• No liquidity fragmentation: all applications on Spark or Lightning share the same liquidity pool, rather than each chain having isolated assets that require bridges to move between them
• No sequencer centralization: Spark uses distributed operators with threshold signing, and users retain the ability to unilaterally exit to Bitcoin Layer 1 at any time
• No bridge risk: users on Spark hold native Bitcoin (or stablecoins issued on Spark) rather than wrapped representations that depend on bridge security

The tradeoff is flexibility: RaaS-deployed rollups offer fully programmable execution environments with custom virtual machines, while Bitcoin L2s are more constrained in their programmability. For teams that need EVM-compatible smart contracts or custom gas tokens, a RaaS rollup may be the right choice. For teams building payments, stablecoin transfers, or Bitcoin-native financial applications, shared L2 infrastructure avoids the overhead and fragmentation costs of launching a dedicated chain. See the Bitcoin Layer 2 comparison and the rollup vs. state channel tradeoffs research for a deeper analysis.

Risks and Considerations

Sequencer Centralization

Most RaaS-deployed rollups rely on centralized sequencers operated by the provider. If the sequencer goes down, the chain halts. If the sequencer censors transactions, users must wait for a forced inclusion mechanism on the settlement layer (where one exists). Decentralized sequencer designs are in development but not yet widely deployed in production.

Liquidity Fragmentation

Every new rollup is an isolated execution environment with its own token balances and liquidity pools. Moving assets between rollups requires bridges, which introduce latency, fees, and security risk. Cross-rollup composability remains an unsolved problem at scale. As more teams launch dedicated chains through RaaS, the fragmentation deepens.

Bridge Security

Rollup bridges are high-value targets. Canonical bridges between a rollup and its settlement layer are generally secured by the rollup's own proof system, but third-party bridges between rollups have been the source of billions of dollars in exploits across the industry. A RaaS-deployed chain is only as useful as its connectivity to the broader ecosystem, and that connectivity introduces attack surface. See the L2 bridge security taxonomy for a detailed breakdown.

Vendor Lock-In

While rollup frameworks are open-source, the operational layer (monitoring, alerting, sequencer management, RPC infrastructure) is proprietary to each RaaS provider. Migrating from one provider to another or bringing operations in-house requires significant engineering effort. Teams should evaluate exit paths before committing to a provider.

Cost Sustainability

Running a rollup incurs ongoing costs: data availability posting, gas for settlement transactions, sequencer infrastructure, and RaaS provider fees. A rollup needs sufficient transaction volume to cover these costs. Low-traffic chains risk becoming economically unsustainable, a concern explored in detail in rollup economics.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.