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 is an Ethereum client written in Go. Areas that typically are in scope are:

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.

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

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 is also not yet production ready, and has very limited bounty scope.

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 is an impementation of an Ethereum node in C++. This client is included, but any issues found will have rather low Impact rating since its 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 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.

This category includes:

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.

Mist is a Dapp browser that connects users to the blockchain. The scope of bounty submissions includes, but are not limited to:

Privilege escalation issues.

Flaws breaking into the victims filesystem.

Flaws compromising any information outside each website scope (e.g. localStorage leaks, cross-website interaction).

Flaws affecting Mist that were already made publicly available by the vendors (e.g. Electron, Chromium, v8) may or may not be accepted by us.

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:

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

LLL is not included in the bug bounty.

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.

This category includes:

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.

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.

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

Read the original:

Ethereum Bounty Program