Optimism Monorepo: The OP Stack's Go and Rust Core, Assessed for Adopters

What the OP Stack Monorepo Actually Contains

The repository is not a single product but a collection of services and libraries that together form the OP Stack. The README lists over twenty directories, each with a distinct role. The core L2 components are op-node, the rollup consensus-layer client, op-batcher, which submits batches of L2 transactions to L1, and op-proposer, which submits output proposals to L1. Around these sit supporting services: op-conductor for sequencer high availability, op-challenger for dispute game challenges, and op-dispute-mon for monitoring those games. There is also cannon, a MIPS fault-proof virtual machine with off-chain execution and on-chain single-step verification, and contracts-bedrock, the smart contracts package. The repository also contains a rust directory with a Cargo workspace that includes kona, a state-transition program and rollup node in Rust, and op-reth, an execution client built on reth. This is a broad codebase, and the README makes clear it is designed to power multiple chains, not just OP Mainnet.

How the Rollup Components Fit Together

The data flow is visible from the directory descriptions. op-batcher takes L2 transactions and submits them as batches to L1, which is how the rollup gets its data availability. op-proposer submits output proposals to L1, which are commitments to the L2 state. op-node is the consensus client that derives the L2 chain from L1 data, and it likely coordinates with an execution client like op-geth or op-reth. The fault proof system involves cannon, which produces execution traces and proofs off-chain for single-step verification on-chain, and op-challenger, which acts as a challenge agent in dispute games. This separation of concerns means each component can be run independently, but it also means running a full node requires multiple processes. The README points chain builders to the OP Stack Guide.

Getting Started: Commands and Configuration

The README points to CONTRIBUTING.md for a Developer Quick Start. It does list the directory structure, which gives clues. The op-deployer is a CLI tool for deploying and upgrading OP Stack smart contracts, so that is likely the entry point for setting up a new chain. op-up provides deployment and management utilities. op-devstack is a flexible test frontend for integration and acceptance testing, which suggests it can be used for local integration testing. For running a node, op-node has its own release tags, and the op-batcher and op-proposer are separate binaries. The docs directory contains public documentation for docs.optimism.io, which is where the actual commands live. The most recent release tags are op-contracts/v9.0.0-rc.1, op-deployer/v0.9.0-dev-test.2, and op-proposer/v1.17.0. The clear takeaway is that the setup is not a one-liner; it requires following the external documentation.

The Rust Components: A Parallel Implementation in Progress

The rust directory is a notable part of the repository. It contains a unified Cargo workspace with kona, described as the OP Stack state-transition (fault proof) program and rollup node in Rust, and op-reth, an execution client built on reth. There is also op-alloy, which provides OP Stack types and providers for the alloy ecosystem, and op-revm, a fork of revm. The README describes op-reth-test-engine as a minimal execution-layer engine the Go action tests run against. This is a significant point for adopters: the Go implementation is the mature path, while the Rust components are an active effort to provide alternatives. The presence of two implementations means more maintenance burden for the project, but it also gives the ecosystem choice. If you are considering using kona for a fault proof program, verify its current status against the develop branch, because the README does not state its maturity level.

Limitations and Cases Where This Repository Is the Wrong Tool

The most obvious limitation is complexity. The monorepo contains dozens of services, each with its own configuration and deployment model. For a team that just wants to spin up a test L2 chain, this is heavy. The README lists op-alt-da as an alternative Data Availability mode in beta, which indicates that the standard DA path is tied to Ethereum L1, and using alternative DA requires beta-level code. Another limitation is the dependency on the OP Stack Specs repository for detailed specifications; the README does not contain the protocol details itself, so you must consult a separate repo. The fault proof system is intricate, and while cannon is present, running a full dispute game requires op-challenger and op-dispute-mon, which adds operational overhead. If you need a simple, single-binary rollup, this repository is not that. The README also notes that the project operates on the principle of impact=profit, which is a governance philosophy, not a technical feature; that may not align with every organization's goals.

Alternatives: Comparing the OP Stack to Other Rollup Frameworks

The primary alternative to the OP Stack is the Arbitrum Nitro stack, which takes a different architectural approach. Arbitrum Nitro uses Geth as its execution layer and compiles the ArbOS system into the node, whereas the OP Stack separates the execution client (op-geth or op-reth) from the consensus client (op-node). This separation gives OP Stack chains more flexibility to swap execution clients, but it also means more moving parts. Another alternative is Polygon's CDK, which is based on the Polygon zkEVM and uses zero-knowledge proofs rather than optimistic fault proofs. Optimistic systems use a challenge period for withdrawals, while validity-proof systems use a different verification mechanism. Actual settlement and withdrawal latency, as well as trust assumptions, depend on the chain’s proof implementation, configuration and operational status; compare those details for the specific deployments. If you want a modular stack with multiple client implementations, the OP Stack is designed for that.

Maintenance, Upgrades, and License Considerations

The repository is actively maintained, with the last push on 2026-11-02 and recent releases for op-contracts, op-deployer, and op-proposer. The README describes a development and release process with a develop branch and production releases, which suggests a structured cadence. The license is MIT, which is permissive and allows commercial use, modification, and redistribution, with the requirement to include the original copyright notice. For operators, the upgrade cost is tied to the multi-service nature: each component has its own version, so upgrading a chain means coordinating releases across op-node, op-batcher, op-proposer, and possibly op-conductor and op-challenger. The repository includes op-acceptance-tests and op-e2e, which are test suites, but running them requires a full test environment. The docs directory contains audits and post-mortems, which is a positive sign for transparency, but it also means you should review those before a production deployment. The security policy is external, and the Immunefi bounty offers up to $2,000,042 for critical vulnerabilities, which indicates the project takes security seriously, but it also implies there are known risks worth bountying.

The Bottom Line for Adopters

The ethereum-optimism/optimism repository is the reference implementation for the OP Stack, and it is the right choice if you are building a production L2 chain that needs the full set of rollup services. The Go components are the stable path, and the Rust workspace is a forward-looking effort that you should treat as experimental until the README or release notes say otherwise. The main cost is operational complexity: you are running multiple services, each with its own configuration. If you are an application developer building on OP Mainnet, you do not need this repository at all; you only need the documentation. If you are a protocol developer, this is where the code lives. Before adopting, verify the current release tags and the state of the develop branch, because the project moves fast. The MIT license is friendly, but the real constraint is the need to keep up with upstream changes to stay compatible with the broader OP Stack ecosystem. This repository is not a toy; it is a serious infrastructure codebase, and it should be treated as such.

Editorial conclusion

Adopt this repository if you are building an OP Stack based L2 chain and need the canonical implementation of the rollup node, batcher, proposer, and fault proof system. It is also the right place to contribute if your goal is to improve the core protocol. Do not adopt it if you only need a simple L2 for a demo; the monorepo's complexity and multi-service architecture are overkill. Before committing, verify the current state of the develop branch, the Rust components' maturity (kona and op-reth are present in the rust workspace), and the specific release tags for the components you run. Check the OP Stack Specs repository for the latest protocol details, and review the Security Policy and Immunefi bounty scope if you plan to run this in production. The repository is under active development with frequent releases, so pin your dependencies to tagged versions and track the development and release process documentation.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes