Security Policy and Bug Bounty Program
This page describes general best practices for reporting bugs and provides specific reporting guidelines for OP Stack and OP Mainnet code contained within the ethereum-optimism (opens in a new tab) GitHub organization.
How NOT to disclose a vulnerability
Do not disclose vulnerabilities publicly or by executing them against a production network. If you do, will you not only be putting users at risk, but you will forfeit your right to a reward. Always follow the appropriate reporting pathways as described below.
- Do not disclose the vulnerability publicly, for example by filing a public ticket.
- Do not test the vulnerability on a publicly available network, either the testnet or the mainnet.
Optimism Bug Bounty Program
Optimism takes security seriously and as such, we have a massive bug bounty program. We don't just talk about it either! We have given out one of the largest bounty payouts ever (opens in a new tab)! You can read more about that bug here (opens in a new tab). Below are the various bug bounty programs we have, as well as how to reach out to us if your bug is not covered by an existing bounty.
Main Bounty Page
Optimism has a very detailed Bug Bounty Page on Immunefi (opens in a new tab). In the listing you can find all the information relating to assets in scope, reporting, and the payout process.
Bedrock Audit Contest
With our upcoming launch of Bedrock we have launched a Sherlock audit contest (opens in a new tab).
Unscoped Bugs
If you think you have found a significant bug or vulnerabilities in OP Stack smart contracts, infrastructure, etc., even if that component is not covered by an existing bug bounty, please report it to via the Optimism Mainnet Immunefi program (opens in a new tab). The impact of any and all reported issues will be considered and the program has previously rewarded security researchers for bugs not within its stated scope.
Reporting Other Vulnerabilities
For vulnerabilities in any websites, email servers, or other non-critical infrastructure within the OP Stack, please email OP Labs (opens in a new tab) at security@oplabs.co and include detailed instructions for confirming and reproducing the vulnerability.
Vulnerability Disclosure
Each OP Stack component maintainer may determine its own process for vulnerability disclosure. However, the following describes a recommended process for disclosure that is currently in use by OP Labs (opens in a new tab).
In the event that an OP Stack component maintainer learns of a critical security vulnerability, the maintainer reserves the right to silently fix it without immediately publicly disclosing the existence of nature of the vulnerability.
In such a scenario, the disclosure process used by OP Labs (opens in a new tab) is as follows:
- Silently fix the vulnerability and include the fix in release X.
- After 4-8 weeks, disclose that release X contained a security fix.
- After an additional 4-8 weeks, publish details of the vulnerability, along with credit to the reporter (with express permission from the reporter).
Rights of Maintainers
Alongside this policy, maintainers also reserve the right to:
- Bypass this policy and publish details on a shorter timeline.
- Directly notify a subset of downstream users prior to making a public announcement.
This policy is based the Geth (opens in a new tab) team’s silent patch policy (opens in a new tab).