Custom Rollup Development (Optimistic/ZK) - From Concept to Mainnet

We develop custom rollup solutions based on OP Stack, Arbitrum Orbit, or ZK Stack — from concept to mainnet. Clients often face a dilemma: which stack to choose? Optimistic Rollup offers full EVM compatibility and low complexity, but transaction finality on L1 takes up to 7 days due to the challenge window. ZK Rollup ensures finality in minutes, but proof generation requires GPU clusters and strains the budget. Our experience shows that the right architectural choice saves months of development and hundreds of thousands of dollars.

Our team has 10+ years of experience in blockchain development and has implemented over 15 rollup projects for DeFi, gaming, and infrastructure. We help you decide: evaluate the load, security requirements, and DA, and suggest the optimal stack. Contact us for an initial consultation — we'll evaluate your project.

Which Rollup Stack to Choose: Optimistic or ZK?

Optimistic Rollup considers transactions correct by default. If someone believes a transaction is fraudulent, they submit a fraud proof within the challenge window (usually 7 days). If the fraud proof is accepted, the transaction is reversed, the challenger receives a reward, and the sequencer loses its stake.

ZK Rollup publishes a cryptographic validity proof along with the transaction batch. L1 verifies the proof through a smart contract. If the proof passes, the transactions are guaranteed correct without trusting the sequencer.

For most application-specific rollup tasks, the choice is OP Stack or Arbitrum Orbit. ZK stack is justified when: fast finality is needed, specific privacy requirements exist, or the rollup is for custom ZK logic.

What's Included in Turnkey Rollup Development?

• Requirements audit and stack selection — load analysis, DA determination (calldata, EIP-4844 blobs, external DA), and decentralization level.
• Architecture and design — L1/L2 interaction scheme, bridge design, sequencer choice (centralized at launch with escape hatch).
• Testnet deployment — local devnet via kurtosis, RPC setup, explorer (Blockscout).
• L1 contract deployment — setup of DisputeGameFactory, OptimismPortal, L1CrossDomainMessenger (for OP Stack) and their verification.
• L2 infrastructure setup — sequencer, batcher, proposer, monitoring (Grafana/Prometheus).
• Bridge integration — custom or standard (ThirdWeb, Connext).
• Security — contract audit, dispute window configuration, bug bounty program.
• Mainnet launch — gradual migration, monitoring, operator documentation.

OP Stack: Deploying an Optimistic Rollup

OP Stack is a framework from Optimism for creating your own L2/L3 chains (superchain). OP Stack documentation

How to Deploy an OP Stack Rollup in 5 Steps

1. Install kurtosis and set up a local devnet.
2. Create a configuration file with network_id and additional services.
3. Run the devnet and test basic transactions.
4. Deploy L1 contracts via forge script.
5. Set up L2 infrastructure and bridges.

OP Stack Components

L1 (Ethereum) ← → op-batcher (publishes tx data to L1) op-proposer (publishes state roots to L1) L2: op-geth (modified geth, execution engine) op-node (consensus/derivation layer, reads L1 data) 

Requirements for Development/Testnet

L1 node (or Sepolia RPC endpoint from Alchemy/Infura) L2 server: 8 CPU, 16 GB RAM, 500 GB SSD 

Deploying OP Stack via optimism-package

# Install kurtosis (orchestration tool) curl -s https://raw.githubusercontent.com/kurtosis-tech/kurtosis/main/install.sh | bash # Run full OP Stack locally kurtosis run github.com/ethpandaops/optimism-package \ --args-file local-config.yaml 

Configuration local-config.yaml:

optimism_package: chains: - participants: - el_type: op-geth cl_type: op-node network_params: network_id: "42069" seconds_per_slot: 2 name: "my-rollup" additional_services: - blockscout # explorer - prometheus_grafana 

Production Deploy: L1 Contracts

git clone https://github.com/ethereum-optimism/optimism cd optimism pnpm install pnpm build export L1_RPC_URL="https://eth-sepolia.g.alchemy.com/v2/YOUR_KEY" export PRIVATE_KEY="0x..." cd packages/contracts-bedrock forge script scripts/Deploy.s.sol:Deploy \ --rpc-url $L1_RPC_URL \ --private-key $PRIVATE_KEY \ --broadcast \ --verify 

After deployment, the deployments/ directory is saved with contract addresses — they are needed for L2 configuration.

Arbitrum Orbit: An Alternative for L2/L3

Arbitrum Orbit allows creating an L2 (relative to Ethereum) or L3 (relative to Arbitrum One/Nova) chain. Setup via orbit-setup-script (configure chain ID, owner, validators). Orbit gives a choice: AnyTrust (data availability through DAC committee, cheaper) or Rollup (data on L1, more secure).

ZK Rollup: ZK Stack (zkSync)

For ZK rollup, ZK Stack from Matter Labs is used. Initialize via zkstack CLI, then create the chain and deploy L1 contracts. In production mode, a real prover (Boojum) with GPU (A100/H100) is required.

Why Is ZK Rollup More Expensive? Cost of Proof Generation

For ZK rollup production deployment, the most expensive component is the prover. Options:

• Own prover cluster — GPU: 1x NVIDIA A100 80GB → ~100–200 TPS; CPU: 64-core AMD EPYC → 10–20x slower.
• Outsourced proving — Gevulot, Lagrange, Fermah (proof marketplace).
• Validium mode — data off-chain in DAC, cheaper but lower security.

The cost of developing a custom rollup depends on the stack and scope of work — contact us for an accurate estimate.

Data Availability: Choosing Between Calldata, Blobs, and External DA

A rollup must publish transaction data so that anyone can recalculate the state. Options:

• Ethereum calldata — maximum security, most expensive. After EIP-4844 (blobs), 10–100x cheaper.
• EIP-4844 Blobs — with Dencun upgrade, rollups publish data as blob transactions. Blobs are stored for 18 days, costing an order of magnitude less than calldata.
• Celestia / EigenDA / Avail — external DA layers. Even cheaper, but require trust in a separate network.

For a new rollup: using EIP-4844 blobs as DA offers an optimal balance of cost and security for the coming years.

Sequencer: Centralization and Steps Toward Decentralization

All production rollups today have a centralized sequencer — it's an honest trade-off for performance. Current state:

• Arbitrum — working on BoLD (Bounded Liquidity Delay) for permissionless validation.
• Optimism — Bedrock + fault proofs (Cannon), moving toward a decentralized sequencer.
• zkSync — centralized sequencer, roadmap to shared sequencing.

For a custom rollup: a centralized sequencer at launch is fine — the key is an escape hatch mechanism (ability to withdraw funds without sequencer consent directly via L1).

Development Phases

Realistic timeline from start to production mainnet: 2–4 months for Optimistic (OP Stack/Orbit), 4–6+ months for ZK with real proofs.

Monitoring and Operational Security

const l1Block = await l1Provider.getBlockNumber() const latestBatch = await l2Bridge.latestBatchIndex() // If gap grows — batcher is not publishing data const pendingWithdrawals = await portal.pendingWithdrawals() if (pendingWithdrawals > THRESHOLD) { alert('Withdrawal queue growing, check proposer') } 

For a production rollup, 24/7 monitoring with alerts is mandatory: sequencer state, batcher lag, proposer health, bridge balance, and dispute window for Optimistic rollup.