OpenZeppelin
As the premier crypto cybersecurity technology and services company, we’ve built OpenZeppelin Contracts with our best security practices.
PoC required
KYC required
Rewards by Threat Level
Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.3. This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.
The rewards stated here are additive to any existing bug bounty programs hosted by projects that are currently using OpenZeppelin contracts.
Bounty rewards are given according to an impact/likelihood matrix for assessing threat levels. Each issue is assessed considering the likelihood of the vulnerability being successfully exploited and the expected impact in scope to a single instance of the affected smart contract. Note that, as can be seen in the matrix, if the impact is Critical then the threat is always Critical, for other impacts the maximum reduction is one level only if the likelihood is low, and if the likelihood is high then the threat is increased one level above the impact.
Proof of Concept (PoC) Requirements
A PoC compliant with Immunefi PoC Guidelines and Rules is required for the following severity levels:
- Smart Contract: Critical
- Smart Contract: High
Bugs introduced by a release candidate version and reported during the review period, the dates for which will be declared by OpenZeppelin on each release, will receive a 50% bonus.
Payouts are handled by the OpenZeppelin team directly and are denominated in USD. However, payouts are done in ETH or USDC.
Program Overview
As the premier crypto cybersecurity technology and services company, we’ve built OpenZeppelin Contracts with our best security practices. We are committed to ensuring the utmost security in our community-vetted smart contracts, and our bounty program provides rewards of up to $25,000 USD for reporting critical vulnerabilities in our smart contracts library. This bug bounty program is focused on OpenZeppelin Contracts and mainly intends to prevent:
- Loss of funds by freezing another user’s funds, or theft of another user’s funds
- Permanent denial of service (smart contract is made unable to operate)
- Access control bypass, including privilege escalation
- Smart contract not behaving as intended
This is an overlay bug bounty program for OpenZeppelin’s Contracts library. A vulnerability in an OpenZeppelin contract would likely affect many other projects and could trigger various other bounties. This program would be potentially additive to those cases.
OpenZeppelin may issue GHSA/CVEs for reported vulnerabilities and will offer to credit issue reports in those public reports.
Responsible Publication
OpenZeppelin adheres to category 1 - Transparent. This Policy determines what information researchers are allowed to make public from their submitted bug reports. For more information about the category selected, please refer to our Responsible Publication page.
Primacy of Impact vs Primacy of Rules
OpenZeppelin adheres to the Primacy of Rules, which means that the whole bug bounty program is run strictly under the terms and conditions stated within this page.
Known Issue Assurance
OpenZeppelin commits to providing Known Issue Assurance to bug submissions through their program. This means that OpenZeppelin will either disclose known issues publicly, or at the very least, privately via a self-reported bug submission.
In a potential scenario of a mediation, this allows for a more objective and streamlined process, in order to prove that an issue is known. Otherwise, assuming the bug report is valid, it would result in the report being considered as in-scope, and due a reward.
Previous Audits
OpenZeppelin’s completed audit reports can be found at OpenZeppelin Contracts’ Security Center while previous security advisories are available at GHSA/CVEs. OpenZeppelin will offer to credit issue reports in those public reports. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.
Feasibility Limitations
OpenZeppelin will assess likelihood depending on the complexity of the steps involved in its execution and the exposure created by the vulnerability, as well as impact depending on the assets or systems at risk, capped to the worst-case impacted instance using the affected code.
OpenZeppelin will evaluate the vulnerability of the affected code considering whether the issue arises directly from the library code while used as provided or if it requires a custom user implementation. Determining the likelihood of exploit on custom implementations will depend on how likely a library user is to make such an implementation and how common is the pattern leading to it.
For example, if a data structure can be cleared by any caller of a smart contract, its likelihood will be high if it holds user balances, although, if the vulnerability allows overriding non-critical values such as an already executed governor proposal flag, its likelihood will be low but can escalate to medium if it comes with side effects that increase the incentives of exploitation (e.g. proposal re-execution).
Similarly, if an instance of an AccessManager can be made unusable, its impact will be high but could be lowered to medium if the attacker requires special permissions in the system, and finally, it will be considered low if the contract is frozen only during 1 block before a threshold is met.
The final threat level will be decided based on the matrix above. For a vulnerability with low impact, if its likelihood is high because the cost of exploiting a single instance is negligible, then its final threat level will be medium severity.
Immunefi Standard Badge
By adhering to Immunefi’s best practice recommendations, OpenZeppelin has satisfied the requirements for the Immunefi Standard Badge.
KYC Requirements
OpenZeppelin’s bug bounty program requires an invoice to be submitted and a KYC screen to be performed prior to OpenZeppelin providing a bug bounty reward. Once a payout is confirmed, a member of OpenZeppelin will reach out to you directly to collect the necessary information, including:
- Full Legal Name
- Email Address
- Mailing Address
- Wallet Address (Ethereum Mainnet Only)
KYC required
The submission of KYC information is a requirement for payout processing.
Prohibited Activities
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty
- Any other actions prohibited by the Immunefi Rules
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity. Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.