Optimism is Ethereum, scaled.
What is Optimism?
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. The Optimism Collective builds open-source software for running L2 blockchains and aims to address key governance and economic challenges in the wider cryptocurrency ecosystem. Optimism operates on the principle of impact=profit, the idea that individuals who positively impact the Collective should be proportionally rewarded with profit. Change the incentives and you change the world.
In this repository, you'll find numerous core components of the OP Stack, the decentralized software stack maintained by the Optimism Collective that powers Optimism and forms the backbone of blockchains like OP Mainnet and Base. Designed to be "aggressively open source," the OP Stack encourages you to explore, modify, extend, and test the code as needed. Although not all elements of the OP Stack are contained here, many of its essential components can be found within this repository. By collaborating on free, open software and shared standards, the Optimism Collective aims to prevent siloed software development and rapidly accelerate the development of the Ethereum ecosystem. Come contribute, build the future, and redefine power, together.
- If you want to build on top of OP Mainnet, refer to the Optimism Community Hub
- If you want to build your own OP Stack based blockchain, refer to the OP Stack docs
- If you want to contribute to the OP Stack, check out the Protocol Specs
Read through CONTRIBUTING.md for a general overview of the contributing process for this repository. Use the Developer Quick Start to get your development environment set up to start working on the Optimism Monorepo. Then check out the list of Good First Issues to find something fun to work on!
Security Policy and Vulnerability Reporting
Please refer to the canonical Security Policy document for detailed information about how to report vulnerabilities in this codebase. Bounty hunters are encouraged to check out the Optimism Immunefi bug bounty program. The Optimism Immunefi program offers up to $2,000,042 for in-scope critical vulnerabilities.
The Bedrock Upgrade
Please note that a significant number of packages and folders within this repository are part of the Bedrock upgrade and are NOT currently running in production. Refer to the Directory Structure section below to understand which packages are currently running in production and which are intended for use as part of the Bedrock upgrade.
├── docs: A collection of documents including audits and post-mortems ├── op-bindings: Go bindings for Bedrock smart contracts. ├── op-batcher: L2-Batch Submitter, submits bundles of batches to L1 ├── op-bootnode: Standalone op-node discovery bootnode ├── op-chain-ops: State surgery utilities ├── op-challenger: Dispute game challenge agent ├── op-e2e: End-to-End testing of all bedrock components in Go ├── op-exporter: Prometheus exporter client ├── op-heartbeat: Heartbeat monitor service ├── op-node: rollup consensus-layer client ├── op-preimage: Go bindings for Preimage Oracle ├── op-program: Fault proof program ├── op-proposer: L2-Output Submitter, submits proposals to L1 ├── op-service: Common codebase utilities ├── op-wheel: Database utilities ├── ops-bedrock: Bedrock devnet work ├── packages │ ├── chain-mon: Chain monitoring services │ ├── common-ts: Common tools for building apps in TypeScript │ ├── contracts-ts: ABI and Address constants │ ├── contracts-bedrock: Bedrock smart contracts │ ├── core-utils: Low-level utilities that make building Optimism easier │ └── sdk: provides a set of tools for interacting with Optimism ├── proxyd: Configurable RPC request router and proxy └── specs: Specs of the rollup starting at the Bedrock upgrade
|master||Accepts PRs from
|develop||Accepts PRs that are compatible with
|release/X.X.X||Accepts PRs for all changes, particularly those not backwards compatible with
This repository generally follows this Git branching model. Please read the linked post if you're planning to make frequent PRs into this repository.
The production branch is
master branch contains the code for latest "stable" releases.
master always come from the
The primary development branch is
develop contains the most up-to-date software that remains backwards compatible with the latest experimental network deployments.
If you're making a backwards compatible change, please direct your pull request towards
Changes to contracts within
packages/contracts-bedrock/src are usually NOT considered backwards compatible and SHOULD be made against a release candidate branch.
Some exceptions to this rule exist for cases in which we absolutely must deploy some new contract after a release candidate branch has already been fully deployed.
If you're changing or adding a contract and you're unsure about which branch to make a PR into, default to using the latest release candidate branch.
See below for info about release candidate branches.
Release candidate branches
release/X.X.X are release candidate branches.
Changes that are not backwards compatible and all changes to contracts within
packages/contracts-bedrock/src MUST be directed towards a release candidate branch.
Release candidates are merged into
develop and then into
master once they've been fully deployed.
We may sometimes have more than one active
release/X.X.X branch if we're in the middle of a deployment.
See table in the Active Branches section above to find the right branch to target.
We use changesets to mark packages for new releases.
When merging commits to the
develop branch you MUST include a changeset file if your change would require that a new version of a package be released.
To add a changeset, run the command
pnpm changeset in the root of this monorepo.
You will be presented with a small prompt to select the packages to be released, the scope of the release (major, minor, or patch), and the reason for the release.
Comments within changeset files will be automatically included in the changelog of the package.
Releases can be triggered using the following process:
- Create a PR that merges the
developbranch into the
- Wait for the auto-generated
Version PackagesPR to be opened (may take several minutes).
- Change the base branch of the auto-generated
Version PackagesPR from
developand merge into
- Create a second PR to merge the
developbranch into the
After merging the second PR into the
master branch, packages will be automatically released to their respective locations according to the set of changeset files in the
develop branch at the start of the process.
Please carry this process out exactly as listed to avoid
master falling out of sync.
NOTE: PRs containing changeset files merged into
develop during the release process can cause issues with changesets that can require manual intervention to fix.
It's strongly recommended to avoid merging PRs into develop during an active release.
All other files within this repository are licensed under the MIT License unless stated otherwise.