What are Rollups

The execution, settlement, data availability, and proof responsibilities that define a rollup.

A rollup executes transactions in its own environment, then commits the resulting state to a settlement layer. The settlement layer does not need to repeat every transaction, but it needs enough information to decide whether the rollup state is valid and to let users recover their assets under the stated security model. Ethereum's rollup scaling documentation is a useful baseline for this distinction.

The four responsibilities

Responsibility	Question to answer	Typical owner
Execution	Where are transactions ordered and executed?	Sequencer and execution nodes.
Settlement	Which layer accepts state commitments and resolves disputes?	Rollup contracts and governance.
Data availability	Can anyone obtain the transaction data needed to reconstruct state?	Settlement layer, DA layer, or the rollup operator.
Proof or challenge	How is an invalid state transition rejected?	Fraud-proof participants or proof-verifier contracts.

What changes for operators

A rollup has more moving parts than a standalone RPC node. The operational boundary commonly includes a sequencer, batch submitter, execution nodes, proposer or verifier services, bridge contracts, a database, observability, and key custody. A healthy process is not enough: the chain can appear live while batches are not settling, data is unavailable, or withdrawals are blocked.

Before deployment, write down the trust assumptions for transaction ordering, upgrades, data publication, bridge administration, and emergency controls. Those assumptions determine the service-level objectives and incident procedures that users need. For example, the OP Stack component model separates sequencing, data availability, derivation, and execution into distinct layers; other stacks may package those responsibilities differently.

A transaction lifecycle

The exact protocol differs by stack, but the lifecycle normally has these checkpoints:

A user submits a transaction to an RPC endpoint or sequencer.
The sequencer admits, orders, and executes it against the current rollup state.
The resulting block or batch is persisted and made available to indexers and users.
The batch data is published to the selected availability layer.
A batch commitment, fraud-proof window, or validity proof is submitted to the settlement layer.
The settlement layer accepts or rejects the transition according to its rules.
Bridges and indexers observe finality before reporting a deposit, withdrawal, or application state as complete.

An incident can occur at any checkpoint. A chain that keeps producing local blocks while step four or five is stalled is not fully healthy, even though its RPC endpoint still responds.

Control-plane versus data-plane ownership

Separate the services that process user traffic from the authorities that can change the chain:

Boundary	Data-plane responsibility	Control-plane responsibility
Sequencing	Accept and order transactions.	Change ordering policy, rate limits, and sequencer membership.
Settlement	Submit and verify commitments.	Upgrade contracts, configure finality, and fund submission wallets.
Data availability	Publish and retrieve batch data.	Change providers, retention, and fallback policy.
Bridge	Relay deposits and withdrawals.	Upgrade, pause, or change guardian and liquidity controls.

Use different credentials and approval paths for those boundaries. An application operator who can restart an RPC node should not automatically have authority to upgrade the bridge or alter settlement contracts.

Launch acceptance criteria

Before treating a rollup as available, demonstrate a complete user path: submit a transaction, observe execution, publish the corresponding data, settle it, index it, deposit through the bridge, and complete a withdrawal under the expected finality policy. Capture the timings for each stage. Those measurements become the initial baseline for alerts and user-facing status communication.