Open for submissions
Clients featured in the bounties
Our bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, proof of stake, etc) and protocol/implementation compliance to network security and consensus integrity. Classical client security as well as security of cryptographic primitives are also part of the program. When in doubt, send an email to email@example.com and ask us.
The Ethereum Specifications detail the design rationale for the Execution Layer and Consensus Layer.
Execution Layer Specifications
It might be helpful to check out the following annotations:
Types of bugs
- Safety/finality-breaking bugs
- Denial of service (DOS) vectors
- Inconsistencies in assumptions, like situations where honest validators can be slashed
- Calculation or parameter inconsistencies
Clients run the Ethereum Network, and they need to follow the logic set out in the specification and be secure against potential attacks. The bugs we want to find are related to the implementation of the protocol.
Currently execution layer clients (Besu, Erigon, Geth and Nethermind) and consensus layer clients (Lighthouse, Lodestar, Nimbus, Teku and Prysm) are included in the Bug Bounty Program. More clients may be added as they complete audits and become production ready.
Types of bugs
- Spec non-compliance issues
- Unexpected crashes, RCE or denial of service (DOS) vulnerabilities
- Any issues causing irreparable consensus splits from the rest of the network
See the Solidity SECURITY.MD for more details about what is included in this scope.
Solidity does not hold security guarantees regarding compilation of untrusted input – and we do not issue rewards for crashes of the solc compiler on maliciously generated data.
Out of scope
Only the targets listed under in-scope are part of the Bug Bounty Program. This means that for example our infrastructure; such as webpages, dns, email etc, are not part of the bounty-scope. ERC20 contract bugs are typically not included in the bounty scope. However, we can help reach out to affected parties, such as authors or exchanges in such cases. ENS is maintained by the ENS foundation, and is not part of the bounty scope.
Submit a bug
For each valid bug you find you’ll earn rewards. The quantity of rewards awarded will vary depending on Severity. The severity is calculated according to the OWASP risk rating model based on Impact on the Ethereum Network and Likelihood. View OWASP method
The EF will also provide rewards based on:
Quality of description: Higher rewards are paid for clear, well-written submissions.
Quality of reproducibility: A Proof of Concept (POC) must be included to be eligible for rewards. Please include test code, scripts and detailed instructions. The easier it is for us to reproduce and verify the vulnerability, the higher the reward.
Quality of fix, if included: Higher rewards are paid for submissions with clear description of how to fix the issue.
Up to 2,000 USD
Up to 1,000 points
- Low impact, medium likelihood
- Medium impact, low likelihood
Up to 10,000 USD
Up to 5,000 points
- High impact, low likelihood
- Medium impact, medium likelihood
- Low impact, high likelihood
Up to 50,000 USD
Up to 10,000 points
- High impact, medium likelihood
- Medium impact, high likelihood
Up to 250,000 USD
Up to 25,000 points
- High impact, high likelihood
Bug hunting rules
The bug bounty program is an experimental and discretionary rewards program for our active Ethereum community to encourage and reward those who are helping to improve the platform. It is not a competition. You should know that we can cancel the program at any time, and awards are at the sole discretion of Ethereum Foundation bug bounty panel. In addition, we are not able to issue awards to individuals who are on sanctions lists or who are in countries on sanctions lists (e.g. North Korea, Iran, etc). Local laws require us to ask for proof of your identity. You are responsible for all taxes. All awards are subject to applicable law. Finally, your testing must not violate any law or compromise any data that is not yours and must take place on local running testnets.
- Issues without a POC or that have already been submitted by another user or are already known to spec and client maintainers are not eligible for bounty rewards.
- Public disclosure of a vulnerability makes it ineligible for a bounty.
- Employees and contractors of the Ethereum Foundation or client teams in scope of the bounty program may participate in the program only in the accrual of points and will not receive monetary rewards.
- Ethereum bounty program considers a number of variables in determining rewards. Determinations of eligibility, score and all terms related to an award are at the sole and final discretion of the Ethereum Foundation bug bounty panel.
Execution Layer Bug Bounty leaderboard
Find execution layer bugs to get added to this leaderboard
Consensus Layer Bug Bounty leaderboard
Find consensus layer bugs to get added to this leaderboard
Frequently asked questions
What should a good vulnerability submission look like?
See a real example of a quality vulnerability submission.
Is the bug bounty program is time limited?
How are bounties paid out?
Rewards are paid out in ETH or DAI.
Can I donate my reward to charity?
I reported an issue / vulnerability but have not received a response!
Please allow a few days for someone to respond to your submission.
I want to be anonymous / I do not want my name on the leader board.
You can do this, but it might make you ineligble for rewards.
What are the points in the leaderboard?
Every found vulnerability / issue is assigned a score
Do you have a PGP key?
Yes. Expand for details.
Email us: firstname.lastname@example.org