How to Launch a Production Rollup Network

Deploying a production rollup involves more than running a testnet. It requires selecting a stack, configuring a sequencer, and establishing a robust data availability layer. The primary decision is choosing between a ZK-Rollup (like zkSync Era or Starknet) or an Optimistic Rollup (like Optimism or Arbitrum). ZK-Rollups offer faster finality with validity proofs but have more complex proving systems. Optimistic Rollups rely on a fraud-proof challenge window (typically 7 days) but are generally easier to implement and have more mature tooling.

Your technical stack is defined by your execution client, proving system (for ZK), and data availability solution. For execution, you can fork the OP Stack (used by Optimism) or Arbitrum Nitro, or use a framework like Rollkit. Data availability is critical: using Ethereum for data (as a Layer 2) is the most secure but expensive. Alternatives include EigenDA, Celestia, or Avail for lower-cost, high-throughput data publishing. You must also configure your bridge contracts for asset deposits/withdrawals and a sequencer to order transactions.

A production deployment follows a multi-stage process. Start with a local development network using tools like Foundry or Hardhat to test your rollup's smart contracts and chain logic. Next, launch a public testnet on a network like Sepolia or Goerli to allow external developers to experiment. This phase tests network stability, tooling compatibility, and the cross-chain bridge. Finally, after rigorous security audits and testnet refinement, you can proceed to mainnet launch. A phased rollout, often starting with a whitelist of known developers, helps mitigate initial risks.

Operational readiness is non-negotiable. You need a high-availability sequencer setup, often with a fallback mechanism or a decentralized sequencer set. Establish monitoring for key metrics: transaction throughput (TPS), block production latency, gas costs on L1, and bridge finality times. Tools like Prometheus and Grafana are standard. You must also plan for upgrades; rollups use proxy patterns or specific upgrade mechanisms (like the Optimism Colosseum) to modify contracts post-deployment, requiring a security council or decentralized governance process.

The endpoint for users and developers is the RPC node. You need to run and expose archival and full nodes. Services like Alchemy, Infura, and QuickNode offer managed rollup RPCs, or you can self-host using the node software from your chosen stack (e.g., op-geth for OP Stack). Ensure your node software is configured for JSON-RPC and WebSocket connections and can handle the expected load. Documentation for your network's specific API methods and chain ID is essential for developer onboarding.

Finally, launching is the beginning. A successful production rollup requires ongoing maintenance: managing protocol upgrades, responding to chain halts, engaging with the validator/decentralized sequencer community, and curating the ecosystem. Budget for recurring costs, primarily L1 gas for data publishing and sequencer infrastructure. By understanding these components—stack selection, staged deployment, operations, and node services—you can launch a rollup network capable of supporting serious applications.

Before writing any code, you must define the core parameters of your rollup. This includes selecting a virtual machine (VM) like the EVM, SVM, or a custom WASM environment, which dictates developer compatibility and smart contract logic. You must also decide on a data availability (DA) solution, such as Ethereum calldata, Celestia, EigenDA, or Avail. This choice directly impacts security, transaction costs, and network throughput. Finally, establish the sequencer model—will it be a single, permissioned operator initially, or a decentralized set from day one? Each decision creates trade-offs between speed, cost, and decentralization.

A production rollup requires a robust technical stack. The core component is the rollup client (e.g., an OP Stack, Arbitrum Nitro, or Polygon CDK instance), which executes transactions and produces blocks. You will need a sequencer node to order transactions and a verifier/prover (for ZK-rollups) to generate validity proofs. Infrastructure for data availability publishing and bridge contracts on the parent chain (L1) is mandatory. All components must be configured for high availability, with load balancing, automated failover, and comprehensive monitoring using tools like Prometheus and Grafana.

Economic design is critical for sustainable operation. You must configure the fee market and gas token, typically the native L1 asset (e.g., ETH) or a custom token. Design a mechanism for sequencer revenue and prover incentives in ZK-rollups to ensure liveness. Plan the initial token distribution and treasury management for funding ongoing development, security audits, and grant programs. A clear economic model aligns incentives for users, sequencers, and future validators.

Security cannot be an afterthought. A production launch necessitates multiple independent smart contract audits from firms like Trail of Bits, OpenZeppelin, or Spearbit for your bridge, rollup contracts, and any novel precompiles. Establish a bug bounty program on platforms like Immunefi before mainnet launch. You must also plan for upgradeability and governance, often implemented via a Timelock contract and a multisig wallet, to manage future protocol improvements while ensuring user funds are protected.

Finally, prepare the operational runway for mainnet. This includes setting up public RPC endpoints, creating a block explorer (forking Blockscout or Etherscan), and integrating with major wallets (MetaMask, Rabby) and oracles (Chainlink, Pyth). Develop comprehensive documentation for developers and end-users. Plan a phased launch: start with a testnet (potentially incentivized), move to a guardian-controlled mainnet beta where the team can pause the network, and finally transition to a decentralized, unstoppable rollup after sufficient stability and security validation.

The sequencer node is the centralized coordinator of an Optimistic Rollup. It receives user transactions, orders them into batches, and submits compressed data to the L1 (Ethereum) for final settlement. For a production deployment, you need to configure the node for high availability, secure key management, and reliable L1 interaction. This guide uses the OP Stack's op-node as the reference implementation, but the principles apply to other rollup frameworks like Arbitrum Nitro and Polygon CDK.

First, set up your environment. You'll need a machine with at least 4 CPU cores, 16GB RAM, and 500GB of fast SSD storage. Install Go 1.21+ and clone the op-node repository. The core configuration is defined in a rollup.json file, which specifies the L1 and L2 RPC endpoints, the chain ID, and the address of the L2OutputOracle and other smart contracts on Ethereum. You must also configure the sequencer's private key securely, using a hardware wallet or a managed secret service like HashiCorp Vault for production, never a plaintext file.

Next, configure the connection to the L1. The sequencer must connect to a high-availability Ethereum RPC provider (e.g., Alchemy, Infura, or your own Geth/Erigon node) to read the latest L1 state and submit batch data. Set the --l1 flag to this RPC endpoint. You also need to run a L2 execution client (a modified Geth instance, often called the op-geth) that the sequencer will use to execute transactions. The op-node communicates with this client via its engine API (JWT-authenticated JSON-RPC) to propose new blocks.

To launch the node, use the command: ./op-node [...] --l1=<YOUR_L1_RPC> --l2=http://localhost:8551 --l2.jwt-secret=/path/to/jwt.hex --sequencer. The --sequencer flag enables its transaction sequencing duties. You must also run a batch submitter service (op-batcher) alongside it. This service periodically takes batches of L2 transactions from the sequencer, compresses them, and posts them to the BatchInbox contract on L1. Configure its submission interval and fee parameters based on your network's desired latency and cost profile.

For fault tolerance, deploy multiple sequencer nodes behind a load balancer in an active-passive configuration. Only the active sequencer should have the signing key enabled. Use health checks and a consensus mechanism (like a simple leader election with etcd) to manage failover. Monitor key metrics: transaction pool depth, batch submission success rate, L1 gas costs, and L2 block production latency. Set up alerts for any deviation from baseline to ensure network stability and user experience.

Finally, remember that while the sequencer provides fast pre-confirmations, the only canonical state is settled on Ethereum. Users and applications should always verify the inclusion and finality of their transactions on L1. As the network operator, you are responsible for the sequencer's liveness and censorship resistance. Transparent operation and clear service-level agreements (SLAs) are critical for building trust with your rollup's users and developers.

The data availability layer is the system that guarantees transaction data is published and accessible for verification. For an Optimistic Rollup, this data allows anyone to reconstruct the chain state and submit fraud proofs. For a ZK-Rollup, it provides the public inputs needed for validity proof verification. Choosing where to post this data—on-chain to Ethereum L1, off-chain to a dedicated DA network, or using a hybrid model—is your first critical decision. Each choice involves trade-offs between security, cost, and throughput that define your rollup's properties.

For maximum security, posting data on-chain to Ethereum via calldata or blobs is the standard. Configure your rollup node's batch submitter to send compressed batch data to a dedicated smart contract on L1. The key parameters to set are the batch inbox address, gas limit for submissions, and confirmation wait time. Using EIP-4844 blob transactions is now essential for cost efficiency, reducing data posting costs by over 90% compared to legacy calldata. Your node must be configured to use a blob-capable RPC endpoint and manage the 18-day blob storage window.

If higher throughput is required, consider an external DA layer like Celestia, EigenDA, or Avail. Configuration involves setting up a light client or a dedicated bridge relayer that commits data roots to your rollup's L1 contract. You must specify the DA chain's RPC URL, the data submission format, and the dispute period for data availability challenges. This model shifts trust assumptions, so audit the DA layer's cryptoeconomic security and liveliness guarantees. Ensure your node can fall back to Ethereum L1 in case the external DA layer experiences downtime.

Integration with your sequencer is the final step. The sequencer must be configured to output batch data in the exact format your chosen DA layer expects. For a custom setup, you'll write the logic that: 1) Compresses transaction batches, 2) Posts them to the DA layer, 3) Records the data root or commitment on L1, and 4) Emits an event that triggers your L2 nodes to fetch and process the new data. This pipeline must be robust against reorgs and have monitoring for failed submissions.

Production readiness requires rigorous testing. Run a testnet that mirrors your DA configuration, simulating mainnet conditions. Key tests include: Stress tests for high transaction volume, Fault injection to simulate DA layer failures, and Cost analysis under varying gas prices. Use tools like the OP Stack's Batch Submitter or Arbitrum's nitro as reference implementations. Your configuration is complete when any honest actor can independently verify the chain's state using only the data published to your chosen availability layer.

Launching a production rollup network requires deploying two critical smart contracts on Ethereum L1: the bridge and the portal. The bridge contract manages the trustless transfer of assets between the L1 and your L2, while the portal contract serves as the primary entry point for users to deposit and withdraw funds. These contracts are typically deployed using a custom Deployer script, often written in Foundry or Hardhat, which handles the complex dependency order and initialization logic. The process is deterministic, ensuring the same contract addresses are generated on any network.

Before deployment, you must configure your network's parameters in the deployment script. Key values include the final system owner address (which gains admin control), the portal guardian address (for emergency pauses), and the L2 output oracle proposer and challenger addresses for fault proofs. The system owner is a critical security role, often assigned to a multi-signature wallet. These parameters are immutable after deployment, so careful planning is essential. The script will also set the initial L2 genesis block hash, anchoring your rollup's state.

The deployment sequence is crucial. First, the L2OutputOracle contract is deployed to post state commitments to L1. Next, the OptimismPortal contract is deployed, which depends on the oracle's address. Finally, the L1StandardBridge contract is deployed, linking to the portal. The deployer script uses CREATE2 with a deterministic salt to calculate addresses in advance, which is vital for configuring your L2 node software. After deployment, you must initialize each contract by calling specific setup functions, like initialize on the bridge to set the address of its paired L2 counterpart.

Post-deployment, you must verify the contracts on a block explorer like Etherscan. Using the --verify flag in Foundry or a similar plugin in Hardhat automates this process by uploading the source code. Verification is non-negotiable for transparency and security. Subsequently, you need to configure your rollup node (op-node for OP Stack, batcher/proposer for Arbitrum Nitro) with the newly deployed L1 contract addresses. The node uses these to listen for deposits, submit batches, and verify outputs. Failure to correctly sync these addresses will prevent your network from operating.

A final, critical step is transferring ownership of the system contracts to a secure multi-signature wallet and renouncing any deployer admin keys. The SystemConfig contract controls parameters like the batch sender address and gas configuration, and its ownership must be secured. You should also conduct a series of integration tests: perform a test deposit via the portal, confirm the transaction is relayed to L2, and execute a withdrawal back to L1. Tools like the Optimism Portal interface can be forked for initial testing. Only after full verification and testing should the network be considered live.

Launching a production ZK rollup requires a robust prover infrastructure capable of generating validity proofs for thousands of transactions per second. The prover is the computational engine that executes batched transactions and produces a zero-knowledge proof (like a zk-SNARK or zk-STARK), which is then verified on the base layer (e.g., Ethereum). For production, you must choose a proving system—such as Plonky2, Halo2, or STARKs—based on your needs for proof size, verification cost, and trusted setup requirements. A trusted setup ceremony is mandatory for SNARK-based systems to generate the initial proving and verification keys securely.

The hardware requirements for a production prover are significant. You will need high-performance servers with multiple GPUs (like NVIDIA A100 or H100) or specialized FPGA/ASIC accelerators to handle the parallelizable arithmetic operations in proof generation. For a network like zkSync Era, a single proof for a large batch can require minutes of computation on this hardware. Infrastructure must be designed for high availability with load balancing, automated failover, and monitoring using tools like Prometheus and Grafana. Provers are often deployed in a clustered configuration to handle peak loads and ensure continuous uptime.

Software configuration involves setting up your node software, such as a modified version of zkEVM or a custom zkVM. Key parameters to tune include the batch size (transaction count per proof), proof timeout thresholds, and gas limit per batch. You must integrate with a sequencer node that orders transactions and a data availability layer (like Ethereum calldata or a dedicated DA chain). The prover continuously pulls batches from the sequencer, generates proofs, and posts them to the verification contract. Here is a simplified flow in pseudocode:

codeCopy
loop {
  batch = sequencer.getNextBatch();
  proof = prover.generateProof(batch);
  verifierContract.submitProof(proof, batch.rootHash);
}

Security and economic considerations are critical. The prover operator typically must stake a bond (e.g., in ETH or the rollup's native token) as a security deposit, which can be slashed for malicious behavior like submitting invalid proofs. Key management for the prover's signing key must use hardware security modules (HSMs) or secure cloud KMS solutions. You should also implement circuit fraud proofs or a multi-prover system for additional safety. Monitoring for proof generation time, success rate, and hardware health is essential to meet service level agreements (SLAs) and avoid downtime that halts network finality.

To launch, follow a staged process: 1) Deploy your verification smart contract to the base chain, 2) Run a testnet with incentivized validators, 3) Conduct security audits on your entire stack (circuits, node software, contracts), 4) Gradually increase mainnet transaction caps while monitoring performance. Resources like zkSync's documentation, Polygon zkEVM's prover repo, and StarkWare's performance guides provide concrete benchmarks and configurations. The end goal is a system where users experience fast, low-cost transactions, with the security guarantee that all state transitions are cryptographically verified on Ethereum.