Optimism Monorepo: The OP Stack's Go and Rust Core, Assessed for Adopters
Optimism is Ethereum, scaled. Optimism is a project dedicated to scaling Ethereum's technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems.
At a glance
- What is it?
- The ethereum-optimism/optimism repository contains the OP Stack's rollup consensus client, batcher, proposer, fault proof emulator, and a growing Rust workspace. This review covers what the code actually does, how to run the key components, and where the trade-offs lie for teams building on or contributing to the stack.
- Who is it for?
- 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.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
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, an onchain MIPS instruction emulator used for fault proofs, 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 emulates MIPS instructions onchain, and op-challenger, which acts as a challenge agent in dispute games. The README also mentions op-supervisor, a service to monitor chains and determine cross-chain message safety, which points to the interoperability features. This separation of concerns means each component can be run independently, but it also means running a full node requires multiple processes. The README does not provide a single command to start everything; instead, you must assemble the pieces according to the OP Stack Guide.
Getting Started: Commands and Configuration
The README points to CONTRIBUTING.md for a Developer Quick Start, but the provided material does not include the exact commands. 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 a local development environment can be spun up with some command, though the README does not specify it. 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. Without that, the only concrete command-level guidance is the release tags: op-node/v1.19.5, op-batcher/v1.16.13, and op-supernode/v1.0.1 as of the last push. You can clone the repository and build these binaries with Go, but the README does not give the exact go build command. 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 marks op-reth-test-engine as a minimal execution-layer engine that is WIP, which signals that the Rust execution client is not yet production-ready. 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. The OP Stack relies on fault proofs and a challenge period, which means withdrawals are delayed, whereas zk-rollups offer faster finality. The README does not mention these alternatives, but the architectural differences are evident from the component list. If you want to minimize trust assumptions and have lower withdrawal latency, a zk-based stack may be a better fit. 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-08-20 and recent releases for op-supernode, op-node, and op-batcher. 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. The README does not mention any contributor license agreements, but the CONTRIBUTING.md file likely covers that. 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, op-reth are present but the README marks op-reth-test-engine as WIP), and the specific release tags for op-node, op-batcher, and op-supernode. 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.
Community notes