Rollup-as-a-Service: where your own L2 network breaks
A custom L2 network looks like full control: your own transaction processing node, your own execution rules, an independent bandwidth lane.
In practice, control comes with operational responsibility — for availability, for the bridge, for state preservation, and for noticing a failure before users do.
The first point of failure is the transaction processing node. While it is up, the network accepts operations and assembles blocks; during a restart, desynchronization with the main network, or disk overflow, intake stops, and the queue accumulates with no signs of recovery.
A hot standby requires separate state synchronization, and without it, every failure is a full L2 network outage.
The second is the bridge and the withdrawal procedure. Withdrawal delay, contract upgrades, confirmation depth, and liquidity on the recipient side live in separate logic that cannot be tested on the main network without risk.
A failure here does not bring down the network, but it blocks funds — the most user-visible class of failures.
The third is the data availability layer and storage. If the publishing node lags or the archive is not replicated, state can no longer be restored from an external source, and rollback turns into manual assembly.
Monitoring usually appears last: there are no metrics for block height, lag, and resource consumption, and users report the failure.
Rollup-as-a-Service is precisely the transfer of these roles to a managed environment: platforms like Conduit and Caldera reduce L2 deployment to configuration rather than building infrastructure from scratch.
Below, we break down the rollup failure points in order — and how they are addressed on the service side.
What a managed rollup provides: availability, withdrawal time, and failures
A managed rollup is a connected topology of a sequencer, batcher, prover node, and replicas, deployed from ready-made templates rather than assembled manually for a specific project.
The Conduit platform describes the network with a declarative manifest: node version, fee policy, gas limits, and replica composition are set by config, so the configuration is reproduced one-to-one in a test environment and in production.
Release time for updates is reduced from days to hours: parameter changes go through the same config as the initial installation, and a trial deployment in an isolated environment shows the effect before enabling it for live users. Regressions are caught before rollout, and rollback to the previous configuration takes minutes.
L2 availability relies on replicas and automatic restart: nodes distribute load among themselves; if one goes down, traffic shifts to the others without dropping sessions.
Under a transaction peak, the network does not drop access points, and gas costs rise predictably — without “stuck” transactions for users.
Withdrawals from L2 no longer depend on manual operations: state root publication intervals and challenge window parameters are configured so that requests are processed at a steady pace, not in batches after an engineer intervenes.
A separate class of failures — indexer desynchronization, disk overflow on a node, sequencer loss during an update — goes away because standard monitoring tracks these states and a template scenario resolves them, rather than troubleshooting from scratch.
Rollup-as-a-Service, a custom L2, or a hybrid: comparing modes
These modes should be compared not by who rents the hardware, but by who holds the keys to the sequencer, prover, and bridge nodes. That is what determines time to mainnet, update speed, and who handles an incident at three in the morning.
| Mode | When it fits | Limitations |
|---|---|---|
| Fully custom L2 | Full control over transaction processing and data is needed; internal regulations prohibit hosting nodes externally | You maintain the sequencer, prover, and bridge nodes yourself; updates and fault tolerance are your responsibility |
| Managed deployment via Rollup-as-a-Service | Fast launch and predictable operations are needed without your own support team | Key nodes are with the provider; it sets the update policy and some parameters |
| Hybrid rollup scheme | Your own processing node is under control, while tooling, monitoring, and bridge nodes are on the managed side | The junction of responsibility zones: you need your own metrics and an agreed update procedure |
The limitations of self-deployment show up not at launch but in the second or third month: the client and configurations have to be updated without stopping the network, and for rollback you must keep fresh state snapshots and a synchronized node. A private rollup adds restricted access to nodes and separate key issuance on top of that.
Separately, keep in mind that changing modes does not transfer state: contract addresses are portable, but the state root and bridges are not, so switching between options is done as launching a new network with asset migration. We will work out which mode suits your task and what it will mean for operations.
L2 implementation: from environment audit to handover to operations
L2 implementation is not installing a single component but rebuilding the environment, so the work proceeds sequentially: each next stage relies on data from the previous one.
If you skip the audit and deploy the network immediately, inconsistencies surface under load — where changing the architecture is most expensive. Below is the order in which we guide a project from the first infrastructure walkthrough to handover to the client’s team.
- Environment audit. We inventory the services that will read and write state, nodes, key stores, current limits, and failure points. The output is a dependency map and a list of bottlenecks that must be removed before deployment.
- Scheme design. We define the network profile for the task: throughput, fee model, method of publishing data to the base layer, roles, and access. We fix what we take as a ready-made Rollup-as-a-Service layer — for example, Conduit — and what we build ourselves.
- Setup and deployment. We bring up the network, nodes, and auxiliary services, and enable monitoring, logs, and alerts on key metrics: block height, transaction inclusion delay, queue depth.
- Integration with the existing environment. We connect indexers, wallets, internal services, and bridges, and run end-to-end scenarios on a test network with real data formats.
- L2 load testing. We apply a profile close to peak: transaction bursts, failure of an individual node, client reconnection. We record recovery time and system behavior at the limit.
- Handover to operations. We hand over configurations, diagrams, update and rollback procedures, and train the client’s team. After that, the network lives on their side, and we connect for support.
What remains with the client: diagrams, access, and procedures
The project does not end with the launch of the main network: after handover, the client has a set of materials with which its engineers operate the network without us. Below is what exactly is transferred to your side along with administrative rights.
- Network diagram — node topology, their roles, failure points, and traffic routes between components.
- Access policies — role matrix: who changes what, where signing keys are stored, and how they are rotated.
- Deployment configurations — files describing the network, with fixed current values and a changelog.
- L2 documentation — architecture, purpose of each component, bridge and fee logic, written for your team.
- Operations procedures — scheduled updates, maintenance windows, on-call and incident escalation order.
- Recovery procedures — state backups, post-failure bring-up scenarios, and rollback to the previous version.
- Metric dashboards and alerts — a set of thresholds that trigger a signal for the on-call engineer before the problem is visible to users.
Everything is in your repository and your infrastructure, administrative rights are with your side, and all that remains with us is access on request.
Such a kit allows you to change the operations contractor without rebuilding the network from scratch — the receiving team gets up to speed from diagrams and procedures, not from chat messages.
Case study: how an L2 stopped going down under peak load
We had before us an L2 environment with one sequencer, assembled manually: nodes in a single zone, manual restarts, transaction retries at the wallet’s discretion.
At peaks, the queue grew faster than it was processed: the successful transaction rate dropped to 92%, and users saw stuck operations. Withdrawals through the bridge took from several hours to a day — proofs were collected manually, and finalization was waited on.
The problem was not in the code but in how the environment was assembled — improving it from the inside made no sense.
We moved the L2 to a managed scheme via Rollup-as-a-Service: nodes were distributed across several zones, the sequencer got autoscaling, and we added health checks, a retry policy, and alerts on queue growth. The provider — Conduit — took over orchestration, while monitoring and access remained with us.
Result in metrics: successful transaction rate at peaks — from 92% to 99.8%; withdrawals — from hours to minutes, with the manual step removed from the process; the number of incidents fell severalfold.
Instead of weekly on-call shifts, only occasional alerts remain, which are closed out according to the procedure.
A separate effect is predictable degradation. Previously, failure came suddenly and affected everyone at once; now load growth is visible in advance via queue metrics, and the environment scales up before users notice.
How does a managed rollup differ from a custom network?
In a custom network, the team holds the entire stack: sequencer, execution and consensus clients, access nodes, bridges, and updates.
A managed rollup is structured differently — the operator deploys and maintains the infrastructure, while the team retains administrative rights over the network: contract upgrade keys, gas policy parameters, and access to the bridge.
Who manages the nodes is visible from the division of responsibilities.
The operator maintains availability of the sequencer and access points, monitors state synchronization, runs client updates, investigates discrepancies, and is on call for failures — at Conduit and similar platforms, this is separated into a dedicated observability environment with a fixed response time.
On the client’s side remains what defines the product: contract logic, who publishes transactions and under what conditions, withdrawal rules, limits, and access lists.
The operator cannot change your contracts or dispose of the bridge — this is exactly where the responsibility boundary runs, and it is fixed before launch.
Switching to a managed scheme does not mean a new network. Contract addresses, transaction history, balances, and issued assets are preserved — what changes is who holds the nodes and is responsible for availability.
Therefore, the transition is planned for a low-load window, with a tested rollback scenario to the previous environment and state reconciliation on both sides.
In practice, the question comes down to one thing: whether you keep infrastructure on-call yourself or hand it to the operator while retaining control over network logic. Describe your current environment — we will come back with an assessment and a transition plan.
Technical doubts before launching L2: bridge, data, control
An environment on Rollup-as-a-Service comes up in a matter of days, but before launch the client’s technical team raises the same questions: how to withdraw funds back, who is responsible for data preservation, and what will happen to access to the environment after the work is handed over.
Below are short answers; exact parameters depend on the chosen architecture and are fixed in the diagram before assembly.
How is the bridge between networks structured?
The canonical bridge is a contract on the main network: it locks the asset, waits for confirmation of state correctness, and issues an equivalent inside L2. Deposits take minutes; withdrawals take from hours to several days because the state must be proven.
Third-party fast bridges provide instant withdrawal but add a trusted party; we show this fork in the diagram before assembly so the choice is informed.
Where is L2 data stored and who manages the environment?
Data is published to the main network, so history cannot be quietly rewritten — state is always restored from it.
Access rights are separated by role: contract upgrades, asset issuance, and treasury operate on different keys and multisig, while administrative rights remain with the client from day one. Our team holds only operational access during the work, and it is revoked at handover.
Environment maintenance is a separate plan item: node updates, monitoring of transaction processing order and storage growth, and reconciliation of discrepancies between L2 and the main network. Procedures and documentation are handed over together with the environment.Let’s discuss the task: we’ll select an L2 deployment mode
To come back with an assessment and implementation plan rather than general considerations, we need inputs for your scenario. Some of them are usually already formulated by the team — we will clarify the rest during the review.
Below is what covers the essentials when selecting an L2 deployment mode — from managed Rollup-as-a-Service to a custom environment.
- Network type and proof model: optimistic or zero-knowledge proof — this determines node composition and withdrawal time to the main network.
- Load profile: how many transactions per second must be sustained at peak, and what volume of state and archive is expected in a year.
- Component composition: a dedicated transaction ordering node, proof generator, bridge for asset transfers, public read node.
- Hosting environment: your own servers or cloud, fault tolerance and geographic distribution requirements.
- Token for paying fees and rules for distributing them among network participants.
- Access and roles: who owns administrative keys, how rights are divided between teams, and whether multisig control is needed.
- Observability and procedures: meaningful metrics, history retention depth, and the order of version updates and rollbacks.
Describe the task in free form and attach these inputs. We will come back with an assessment, an implementation plan, and a breakdown of options: where a ready-made platform is sufficient, and where a custom environment with full control over updates and keys is justified.