# ethereum-optimism/optimism: the OP Stack monorepo behind OP Mainnet and Base

> The optimism repository is the Go and Rust monorepo for the OP Stack, holding op-node, op-batcher, op-proposer, op-challenger, op-deployer and the contracts-bedrock package. It is infrastructure for chain operators, not a wallet or a dapp SDK.

**ethereum-optimism/optimism** — 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.

- Repository: https://github.com/ethereum-optimism/optimism
- Website: https://optimism.io
- Stars: 6,472 · Forks: 4,043
- Language: Go
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/ethereum-optimism-optimism

## What the optimism repository actually ships

The README states that the repository holds core components of the OP Stack, the software stack maintained by the Optimism Collective that powers OP Mainnet and forms the backbone of chains like Base. That sentence sets the audience: people operating or extending rollup infrastructure, not people writing contracts against it. The directory listing backs this up. op-node is described as the rollup consensus-layer client, op-batcher submits bundles of batches to L1, op-proposer submits L2 output proposals to L1, op-challenger is a dispute game challenge agent, and op-deployer is a CLI tool for deploying and upgrading OP Stack smart contracts. Around those sit operational services such as op-conductor for high-availability sequencing, op-dispute-mon for monitoring dispute games, op-supervisor for cross-chain message safety, and op-interop-mon for interoperability monitoring. If you want to build a dapp, the README sends you to the Optimism Documentation rather than into this tree. That distinction matters more than any feature list, because the repository is a set of long-running services with configuration surfaces, not a library you import and call.

## How the monorepo is laid out: Go services, Rust components, Solidity contracts

Three language ecosystems live side by side. The root go.mod declares module github.com/ethereum-optimism/optimism with go 1.26.0 and toolchain go1.26.6, and pulls in go-ethereum v1.17.0, libp2p, Pebble, Prometheus client libraries, and HashiCorp raft packages for consensus. The rust directory is described as a unified Cargo workspace containing kona (a fault proof program and rollup node in Rust), op-reth (an execution client built on reth), op-revm, and op-alloy. Solidity lives under packages/contracts-bedrock. Two other directories are worth noting for anyone evaluating scope: cannon, an onchain MIPS instruction emulator for fault proofs, and op-e2e, end-to-end testing of all bedrock components in Go. The practical consequence is that a change to consensus behaviour can touch Go services, Rust clients and Solidity contracts at once, and the build tooling reflects that. The root Makefile marks a long list of targets as deprecated, including build, lint-go, op-node-docker and test-unit, and delegates them through justfiles/deprecated.mk. New work is expected to go through just, not make. The justfile also pins OP_STACK_GO_BUILDER to us-docker.pkg.dev/oplabs-tools-artifacts/images/op-stack-go:latest by default, which tells you the project expects container-based builds rather than a bare host toolchain.

## Installing the toolchain and running a first build

The README does not give install commands. It points contributors at CONTRIBUTING.md and its Developer Quick Start section, and points chain operators at the OP Stack Guide at docs.optimism.io/stack/getting-started. What the repository files do show is the expected workflow. The justfile defines a help recipe that lists targets, and an install-git-hooks recipe that sets core.hooksPath to .githooks. Setting up a clone therefore starts like this:

```bash
just install-git-hooks
just --list
```

The first command sets the repository's git hooks path, and the recipe comments describe it as idempotent, so it is safe to run once per clone. The second prints available targets. Note that just is a separate binary from make; the Makefile's own header lists help and build among its deprecated targets, so running make build is not the intended path any more.

Before any of that, check the Go version. The module declares go 1.26.0 and toolchain go1.26.6, so an older local Go will either fail or silently download the declared toolchain. The justfile also defines OP_STACK_GO_BUILDER, defaulting to the op-stack-go image, which is the environment the project's own recipes assume.

One more setup step appears in the justfile: a recipe for updating the superchain-registry submodule, described there as the single canonical SR commit pin, scoped to only that submodule and never a bare git submodule update. The recipe initializes at the pinned commit shallowly when given no ref, and moves the submodule to a tag or commit sha when given one. If your work touches chain configuration, that pin is the thing to read before you assume a registry entry is current.

## Where this repository is the wrong tool

The most common mismatch is treating optimism as an application SDK. The README's own navigation splits the audience: build on OP Mainnet, read the Optimism Documentation; build your own OP Stack chain, read the OP Stack Guide. Neither path is this repository. Cloning it gives you services, contracts and test harnesses, and a Go module that other projects import for shared types, not a client library for moving assets or reading balances.

A second limit is test scope. The justfile documents that Go test runs cover every package except a named exclusion list: op-acceptance-tests, cannon, rust, and op-deployer/pkg/deployer/forge. The reasons are given in the comments. Acceptance tests need a running devnet, cannon runs slow MIPS emulation tests in a dedicated job, rust needs prebuilt Rust binaries, and the forge package fails when forge is on PATH, with an issue reference attached. Fault-proof packages get their own list because they run twice, once in the default Go test job and again with Cannon enabled. So a green local test run does not mean the whole tree was exercised.

Third, the repository is large and multi-language. If your only goal is to read the OP Stack specification, the README points to the separate ethereum-optimism/specs repository, which is a far smaller thing to review than this tree.

## How op-deployer differs from deploying with a general framework

If you are deploying an OP Stack chain, the closest alternative in practice is to use a general-purpose contract deployment framework such as Foundry against the contracts-bedrock package directly. The difference in approach is what each one knows about. A general framework deploys whatever contracts you hand it, in whatever order you script, and leaves chain wiring to you. op-deployer is described in the directory listing as a CLI tool for deploying and upgrading OP Stack smart contracts, which means the sequencing and upgrade paths for the stack's contract set are the tool's problem rather than your script's. The trade-off is the usual one for opinionated tooling: you get the stack's expected deployment order and upgrade handling, and you give up the freedom to assemble a non-standard contract set without fighting the tool. For a standard chain, that is a good trade. For a heavily modified stack, a manual Foundry deployment may be less friction. The repository does not document which of these the Optimism Collective recommends for third-party chains; the OP Stack Guide is where that decision is made.

## Maintenance cadence, release tags and upgrade cost

The repository is not archived, and the last push was on 2026-08-20. Releases are cut per component rather than as one monorepo version: the recent list shows op-supernode/v1.0.1, op-node/v1.19.5 and op-batcher/v1.16.13, all dated 2026-08-20. That naming scheme is the upgrade story. You do not upgrade "optimism"; you upgrade op-node, or op-batcher, or op-supernode, and you can be on different versions of each. The README's Development and Release Process section separates production releases from the development branch, and the default branch is develop, so a clone tracks work in progress unless you check out a release tag.

The cost of tracking develop is real. The Makefile's deprecated-target list shows the project renaming and retiring its own build entry points, and the justfile comments reference an open issue where a test package fails depending on whether forge is on PATH. Neither is a defect in the software, but both mean build scripts and CI configuration copied from an older guide may not survive a rebase. Pin to release tags for anything you operate.

The licence is MIT, declared in the repository and in the README's License section. MIT is permissive, so modification and redistribution are broadly allowed, but the README also links a separate security policy in the ethereum-optimism/.github repository and an Immunefi bug bounty program, which means vulnerability reports have their own channel rather than the issue tracker. If you run this software and find a security problem, that policy is the document that governs disclosure, not the repository's issues. This is a description of what the repository states, not legal advice; read the LICENSE file and the security policy yourself.

## Conclusion

Adopt this repository if you are running or extending OP Stack infrastructure: an op-node, an op-batcher, an op-proposer, or a chain you deploy with op-deployer. Do not clone it expecting an application SDK, a wallet integration or a quick way to bridge assets; the README points builders at docs.optimism.io and chain operators at the OP Stack Guide instead. Before committing, verify the Go toolchain in go.mod against your build image, confirm whether the superchain-registry submodule is required for your target network, and decide whether you are pinning to a release tag such as op-node/v1.19.5 or tracking develop.

## FAQ

### What is the ethereum-optimism/optimism repository?

It is the monorepo holding core components of the OP Stack, the software stack that powers OP Mainnet and forms the backbone of chains like Base. It contains Go services such as op-node, op-batcher and op-proposer, a Rust workspace, and the contracts-bedrock Solidity package.

### What does the OP Stack consist of in this repository?

The README lists op-node as the rollup consensus-layer client, op-batcher as the L2 batch submitter, op-proposer as the L2 output submitter, op-challenger as the dispute game challenge agent, and op-deployer as the CLI for deploying and upgrading OP Stack contracts. Cannon, op-conductor, op-supervisor and op-dispute-mon are also in the tree.

### Is the optimism repository actively maintained?

The repository is not archived and the last push was on 2026-08-20, with component releases op-supernode/v1.0.1, op-node/v1.19.5 and op-batcher/v1.16.13 dated the same day. The default branch is develop.

### What licence does ethereum-optimism/optimism use?

The repository is MIT licensed, as stated in the README's License section and the LICENSE file. Security issues have a separate policy document in the ethereum-optimism/.github repository plus an Immunefi bug bounty program, rather than the regular issue tracker.

### Can I use ethereum-optimism/optimism to build a dapp on OP Mainnet?

The README directs people who want to build on top of OP Mainnet to the Optimism Documentation at docs.optimism.io instead. This repository holds the stack's services, contracts and test harnesses, not an application SDK.

## Sources

- [Official documentation](https://optimism.io)
- [Official README](https://github.com/ethereum-optimism/optimism#readme)
- [Project repository](https://github.com/ethereum-optimism/optimism)
- [Release notes](https://github.com/ethereum-optimism/optimism/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ethereum-optimism-optimism