Optimism is a low-cost and lightning-fast Ethereum L2 blockchain.

What is Optimism?

Optimism is a low-cost and lightning-fast Ethereum L2 blockchain, but it's also so much more than that.

Optimism is the technical foundation for the Optimism Collective, a band of communities, companies, and citizens united by a mutually beneficial pact to adhere to the axiom of impact=profit — the principle that positive impact to the collective should be rewarded with profit to the individual. We're trying to solve some of the most critical coordination failures facing the crypto ecosystem today. We're particularly focused on creating a sustainable funding stream for the public goods and infrastructure upon which the ecosystem so heavily relies but has so far been unable to adequately reward. We'd love for you to check out The Optimistic Vision to understand more about why we do what we do.

Documentation

If you want to build on top of Optimism, take a look at the extensive documentation on the Optimism Community Hub. If you want to build Optimism, check out the Protocol Specs.

Community

General discussion happens most frequently on the Optimism discord. Governance discussion can also be found on the Optimism Governance Forum.

Contributing

Read through CONTRIBUTING.md for a general overview of our contribution process. Use the Developer Quick Start to get your development environment set up to start working on the Optimism Monorepo. Then check out our list of good first issues to find something fun to work on!

Security Policy and Vulnerability Reporting

Please refer to our canonical Security Policy document for detailed information about how to report vulnerabilities in this codebase. Bounty hunters are encouraged to check out our Immunefi bug bounty program. We offer up to $2,000,042 for in-scope critical vulnerabilities and we pay our maximum bug bounty rewards.

The Bedrock Upgrade

Optimism is currently preparing for its next major upgrade called Bedrock. Bedrock significantly revamps how Optimism works under the hood and will help make Optimism the fastest, cheapest, and most reliable rollup yet. You can find detailed specifications for the Bedrock upgrade within the specs folder in this repository.

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.

Directory Structure

~~ Production ~~
├── packages
│   ├── common-ts: Common tools for building apps in TypeScript
│   ├── contracts: L1 and L2 smart contracts for Optimism
│   ├── contracts-periphery: Peripheral contracts for Optimism
│   ├── core-utils: Low-level utilities that make building Optimism easier
│   ├── data-transport-layer: Service for indexing Optimism-related L1 data
│   ├── drippie-mon: Service for monitoring Drippie instances
│   ├── fault-detector: Service for detecting Sequencer faults
│   ├── message-relayer: Tool for automatically relaying L1<>L2 messages in development
│   ├── replica-healthcheck: Service for monitoring the health of a replica node
│   └── sdk: provides a set of tools for interacting with Optimism
├── batch-submitter: Service for submitting batches of transactions and results to L1
├── bss-core: Core batch-submitter logic and utilities
├── gas-oracle: Service for updating L1 gas prices on L2
├── indexer: indexes and syncs transactions
├── infra/op-replica: Deployment examples and resources for running an Optimism replica
├── integration-tests: Various integration tests for the Optimism network
├── l2geth: Optimism client software, a fork of geth v1.9.10  (deprecated for BEDROCK upgrade)
├── l2geth-exporter: A prometheus exporter to collect/serve metrics from an L2 geth node
├── op-exporter: A prometheus exporter to collect/serve metrics from an Optimism node
├── proxyd: Configurable RPC request router and proxy
├── technical-documents: audits and post-mortem documents

~~ BEDROCK upgrade - Not production-ready yet, part of next major upgrade ~~
├── packages
│   └── contracts-bedrock: Bedrock smart contracts. To be merged with ./packages/contracts.
├── op-bindings: Go bindings for Bedrock smart contracts.
├── op-batcher: L2-Batch Submitter, submits bundles of batches to L1
├── op-e2e: End-to-End testing of all bedrock components in Go
├── op-node: rollup consensus-layer client.
├── op-proposer: L2-Output Submitter, submits proposals to L1
├── ops-bedrock: Bedrock devnet work
└── specs: Specs of the rollup starting at the Bedrock upgrade

Branching Model

Active Branches

Branch	Status
master	Accepts PRs from develop when we intend to deploy to mainnet.
develop	Accepts PRs that are compatible with master OR from release/X.X.X branches.
release/X.X.X	Accepts PRs for all changes, particularly those not backwards compatible with develop and master.

Overview

We generally follow this Git branching model. Please read the linked post if you're planning to make frequent PRs into this repository (e.g., people working at/with Optimism).

Production branch

Our production branch is master. The master branch contains the code for our latest "stable" releases. Updates from master always come from the develop branch. We only ever update the master branch when we intend to deploy code within the develop to the Optimism mainnet. Our update process takes the form of a PR merging the develop branch into the master branch.

Development branch

Our primary development branch is develop. develop contains the most up-to-date software that remains backwards compatible with our latest experimental network deployments. If you're making a backwards compatible change, please direct your pull request towards develop.

Changes to contracts within packages/contracts/contracts 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

Branches marked release/X.X.X are release candidate branches. Changes that are not backwards compatible and all changes to contracts within packages/contracts/contracts 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.

Releases

Changesets

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 yarn 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 with in changeset files will be automatically included in the changelog of the package.

Triggering Releases

Releases can be triggered using the following process:

1. Create a PR that merges the develop branch into the master branch.
2. Wait for the auto-generated Version Packages PR to be opened (may take several minutes).
3. Change the base branch of the auto-generated Version Packages PR from master to develop and merge into develop.
4. Create a second PR to merge the develop branch into the master branch.

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 develop and 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.

License

Code forked from go-ethereum under the name l2geth is licensed under the GNU GPLv3 in accordance with the original license.

All other files within this repository are licensed under the MIT License unless stated otherwise.