Arbitrum deployment model
The component boundaries and deployment checks that matter for Arbitrum-style rollups.
Arbitrum-style rollups combine a parent chain, a sequencer, batch posting, validation, execution nodes, and optional bridge or L3 services. ARB-RAAS contains local and test-environment tooling for these workflows, including simple and separated service topologies.
The reference setup is valuable because it makes the role split explicit. A simple configuration can combine sequencing, batch posting, and validation for local testing. A realistic environment separates those duties so that failures, credentials, and scaling decisions do not overlap by default.
Roles to keep separate
| Role | Responsibility | What to test |
|---|---|---|
| Sequencer | Orders transactions and produces the local chain. | Availability, ordering policy, failover, and transaction admission. |
| Batch poster | Commits data or assertions to the parent chain. | Parent-chain funding, submission delay, retries, and confirmation handling. |
| Validator | Verifies assertions and participates in the chain's safety path. | Sync progress, challenge or assertion behavior, and independent data access. |
| RPC node | Serves applications and wallets. | Capacity, lag, method policy, and separation from privileged services. |
| Bridge | Moves assets and messages between parent and child chains. | Finality, message age, custody, pause controls, and reconciliation. |
Promotion from local tooling
The reference scripts can create a local parent chain, child rollup configuration, optional token bridge, and multiple sequencer instances. Those defaults are for a controlled environment. Before promoting any pattern, replace deterministic development identities, local storage, and broad debugging interfaces; record the actual chain parameters and contract addresses; and move persistent state to a tested backup and recovery plan.
Do not infer production readiness from a successful --init flow. Prove that an independent node follows the chain, batches reach the parent chain, a bridge path completes under the intended finality rules, and an operator can recover each service without creating inconsistent state.
Availability and incident checks
Monitor local block production, batch-posting delay, parent-chain confirmation, validator or assertion state, RPC lag, and bridge-message age as distinct signals. A local chain that continues to accept transactions while parent-chain posting or validation is stalled is degraded.
For shared controls, see Optimistic rollups, Bridging assets, and Monitoring.