BOUNTY SCOPE

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, 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 bounty@ethereum.org and ask us.

Here is some guidance on what we are typically interested in hearing about:

Geth security

Geth is an Ethereum client written in Go. Areas that typically are in scope are:

Consensus protocol compliance: are there any flaws that would make Geth deviate from consensus? This are includes EVM operations, precompiles, block validation etc.

Account management flaws: flaws which would put end-user accounts at risk.

DoS issues: flaws that makes Geth crash or perform very slowly. Includes suboptimal EVM operation, failure to handle attacks on the protocol stack



Some areas of Geth are ‘experimental’, and not yet enabled by default. Yes, these are also included, but the ‘Impact’ of issues in the areas below will be counted as low.

LES

The LES (light clients) parts of Geth are twofold: server and client. For LES, we are interested in

LES Server or Client: RCE-type of vulnerabilities

LES Server: DoS vulnerabilities

Swarm

Swarm is not yet production ready, and has very limited bounty scope. We are always interested in RCE-types of vulnerabilities, but not (yet) DoS via swarm protocols.

Whisper

Whisper is also not yet production ready, and has very limited bounty scope.

RCE-types of vulnerabilities.

Cryptographic flaws which would break the Whisper protocol confidentiality. For example, if an multi-node adversary can recover plaintext, or identify a particular sender of encrypted messages

Not included: DoS via whisper protocol

EthereumJ/Harmony

EthereumJ EthereumJ is a pure-Java implementation of the Ethereum protocol, and the basis of Harmony – a full Ethereum client. EthereumJ/Harmony is not included in the bounty program, since there are still too many known issues, and not a full mainnet client yet.

Aleth

Aleth is an impementation of an Ethereum node in C++. This client is included, but any issues found will have rather low Impact rating since it’s not commonly used. Typically, we would be interested in consensus or p2p DoS issues, but not so much e.g. DoS via RPC attacks.

Py-evm/Trinity

Py-evm is a python implementation of the Ethereum Virtual Machine, and the basis for Trinity. The Trinity client is currently in an alpha release stage and is not suitable for mission critical production use cases. Both of these components are included in the bounty scope, but any issues reported will have a lowered Impact since there are already known issues and they are not considered production release.

Solidity language security

This category includes:

Incorrect behaviour of the Solidity code generator or optimizer, which could cause unintended functionality (bugs) in the generated contract code.

Here is an example of a submitted Solidity bug.

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.

Vyper language security

The Vyper language is a new, experimental programming language for the EVM. It is still beta software, and as such is not expected to be bug-free.

Vyper is included in the bug bounty, but due to it still being under development, the Impact of bugs found will be downgraded accordingly.

Typical bugs that could qualify are:

Flaws that produce bytecode which is clearly erroneous, as in ‘not what the programmer intended’

Semantic flaws, where a programmer might very easily make an error, e.g. due to misleading syntax or keywords

As with Solidity, crashes of the Vyper compiler in the face of malicious input is not included in the bounty program.

LLL language security

LLL is not included in the bug bounty.

Pyethereum/Pyethapp

Pyethereum is a legacy Ethereum implementation, and the basis for the Pyethapp python client implementation. Both of these are now deprecated, in favour of py-evm/Trinity, and not not in scope of the bounty program.

ENS security

This category includes:

Flaws making it possible to gain unauthorized access to, or prevent the authorized withdrawal of, funds locked in Deeds.

Flaws making it possible to interfere with, or make modifications to, an ENS-domain belonging to another user.

Flaws in the auction that affect the legitimacy of auction results.

Here is an example of a bug in the initial ENS registrar that would have allowed people to bid during the reveal period, thus affecting the legitimacy of auction results.

Other clients/things

Clients not developed by the Ethereum Foundation would typically not be covered by the bounty program. For Parity, please visit their bounty program.

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.

Ethereum.org infrastructure

Our infrastructure; such as webpages, dns, email etc, are not part of the bounty-scope.