OP Stack deployment model
Run OP Stack services as a coordinated initialization, execution, batch-publication, settlement, and bridge system.
An OP Stack rollup is a system of cooperating services, not a single node. OP-RAAS contains code for chain and bridge initialization, OP Stack runtime services, explorer support, and bridge workflows.
Deployment stages
| Stage | Outcome | Do not proceed until |
|---|---|---|
| Initialize | Reviewed chain configuration and deployment records exist. | L1 contracts, chain identifiers, ownership, and configuration artifacts are recorded. |
| Run | Execution, sequencing, and L2 node services are operating. | The L2 is producing blocks and independent nodes can follow it. |
| Publish | Batches are reaching L1 through the configured batch path. | Submission succeeds, fees are funded, and delays remain within the policy. |
| Verify | Proposals or fault-proof services follow the intended safety model. | The configured mechanism is monitored and a degraded path is understood. |
| Bridge and explore | Users can inspect and move assets with clear finality conditions. | Deposits, withdrawals, indexing, and incident messaging have been exercised. |
Service boundaries
Keep chain initialization separate from runtime operations. Initialization creates contracts and chain configuration that define the network; runtime services consume that configuration. Preserve the exact generated artifacts and review every change through an explicit release process.
The sequencer and batcher are separate dependencies. The sequencer decides local transaction order and produces L2 blocks. The batcher publishes L2 transaction data to L1. A healthy sequencer does not prove publication is working, so monitor L1 submission success, pending channels or batches, fee-wallet balance, and the delay between local execution and L1 visibility.
Launch and recovery tests
- Build a known image set and record the chain configuration, contract addresses, and version matrix.
- Start the L2 services and verify an independent node derives the same safe state.
- Submit transactions through the intended RPC path and trace them through batch publication to L1.
- Pause or degrade the publication path in a test environment and verify the documented sequencer and user-communication policy.
- Complete a bridge deposit and withdrawal under the actual finality and proof conditions.
- Rehearse recovery of each stateful component without regenerating chain configuration or reusing a privileged key in the wrong role.
For the proof and finality model, see Optimistic rollups. For batch retention and recovery, see Data availability.