Each asset in scope listed above points to the latest changes which is the source of truth of what’s in scope.

If a bug in the specifications results in an impact on client implementations, the relevant impact should be selected from the Blockchain/DLT impacts list. If an impact of the specification bug cannot be identified, you are encouraged to submit it under the Low severity “A bug in specifications with no direct impact on client implementations”, at which point it will be evaluated and may have its severity increased at the discretion of the Ethereum Foundation.

For compiler impacts, only those issues which affect runtime logic will be considered as in scope. If a bug is the result of an anti-pattern of the language, enabling experimental features, or use of inline assembly, it may be downgraded or considered out of scope. If there are no affected applications, a vulnerability may be downgraded due to feasibility limitations of exploitability. Compiler bugs should be tested against the latest release version. Bugs which are not known issues which impact previous versions may be considered if an on-chain impact can be demonstrated.

Proof of Concept (PoC) Requirements

A PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.

Whitehat Educational Resources & Technical Info Architecture documents:

Consensus client diversity will be calculated as an average of the following three data sources provided in https://clientdiversity.org/

• Sigma Prime's Blockprint
• Miga Labs
• Rated.Network

Execution client diversity will be calculated as an average of the following three data sources:

• https://clientdiversity.org/
• https://ethernodes.org/
• https://explorer.rated.network/network?network=mainnet&timeWindow=1d&rewardsMetric=average&geoDistType=all&hostDistType=all&soloProDist=stake

Is this an upgrade of an existing system? If so, which? And what are the main differences?

The Ethereum Protocol is in scope, however, only the clients and codebases which are listed in the assets table above qualify for this program. The specifications of the consensus layer and execution layer are in scope, please see the following resource to understand how to find and report a bug in the specification documents.

Where do you suspect there may be bugs? Useful aspects of this question are:

• Which parts of the code are you most concerned about?

  • We are most concerned about code related to consensus, validators, cryptography, networking (libp2p, devp2p)
  • Bugs concerning the following mechanisms:
    • beacon-chain.md files: Any bugs that may cause the beacon chain to stop or consensus failure.
    • fork-choice.md files: This logic is likely the most complicated and requires a more sophisticated attack vector or fuzzing to detect potential bugs. Note that there are some known but too costly attacks. For example, accountable safety guarantees that no conflicting finalization can happen without 1/3 of the validator set being flashable.
    • p2p-interface.md files: These docs are primarily written in English words instead of executable and tested Python code. Networking experts can refer to these documents to find DOS attack vectors.
  • Bugs are mostly found in typing issues, such as:
    • Receiving a U256 instance in a variable expecting a Uint
    • Getting a Bytes20 in a Bytes slot
  • Edge case behavior that deviates from "true" Ethereum can also cause issues, including:
    • Opcode behavior at extremes (e.g., blockhash at 255/256 depth)
    • Precompiles decoding their arguments differently
  • Cryptography is a complex area where ensuring that libraries are correctly implemented and match mainnet behavior is crucial.
  • Discrepancies between the optimized and non-optimized modules may also be a valuable source of bugs.

• What attack vectors are you most concerned about? Which part(s) of the system do you want whitehats to attempt to break the most?

  • Specifically for the specifications:
    • Incorrect behavior is biggest attack vector, eg. What happens if a theoretical new Ethereum client follows the specification to the letter?
    • We are interested in cases when the chosen algorithm may not be suitable for a production client, or when simplifying assumptions (e.g., no re-orgs) are impractical in real-world scenarios.

• Are there any assumed invariants that you want whitehats to attempt to break?

  • We use many Python assertions (assert) to explicitly indicate the invariants in the markdown files.
  • We use SSZ typing to determine the domain of variables.

What external dependencies are there?

• A functioning Ethereum execution client (geth, reth, etc.) to provide blocks
• https://github.com/ethereum/execution-specs/blob/1e9a6e518adab7ae55ebddb15d72f91041240c8a/setup.cfg#L113-L117
• https://github.com/ethereum/execution-specs/blob/1e9a6e518adab7ae55ebddb15d72f91041240c8a/setup.cfg#L152-L180

Where might whitehats confuse out-of-scope code to be in-scope?

• docc and its plugins are completely out of scope.
• Anything under src/ethereum_spec_tools is likely out of scope, but bug reports are still appreciated.
• Attacks that require manually making the JSON-RPC publicly available are not in scope for the execution layer or consensus layer. It is known that there are multiple attack vectors (DDoS) and it is not intended to make it public unless multiple layers of protection are in place.
• The JSON RPC is out of scope. Users are told not to expose the JSON RPC to the public as they are a well known attack vector.

Are there any unusual points about your protocol that may confuse whitehats?

• For the specifications, correctness and readability trump everything else, including performance.
• We use int64 FAR FUTURE EPOCH: 2**64 - 1 as a stab of the epoch time that is unlikely to reach. When testing the variables' bounds, we should consider the probability of occurrence when determining the impact.
• The Electra specs and “features” specs (under https://github.com/ethereum/consensus-specs/tree/dev/specs/_features folder) are still in development, so they are not in the scope.
• The deposit contract only accepts deposits. To withdraw funds, a validator must exit their node or do work. Learn more here.
• We use Python SSZ implementation remerkleable a lot in pyspec. The bugs caused by remerkleable are not considered in scope as pyspec itself is not a product. Bugs must be considered in the context of client implementations.

What is the test suite setup information?

Please see each respective node software’s documentation regarding test suite setup.

What qualifies as a hard fork of the network?

A hard fork is the case when a potential attack’s damage is proven to be irreversible, and the only possible fix is splitting the network on a hard fork. It is a radical change to a network’s protocol that makes previously invalid blocks and transactions valid, or vice-versa. This means nodes (clients) that do not update to the new protocol will no longer be able to participate in or validate the same blockchain as the updated nodes.

If a hard fork is required for the uncle chain to fix consensus for those clients and continue building on the canonical chain, it does not qualify as critical, as the canonical chain remains unchanged and does not require a hard fork. The issue caused should have the downstream effect of clients needing to deploy patches to continue building blocks on the canonical chain.

Previous Audits & Public Disclosure of Known Issues

Bug reports covering previously discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk.

Ethereum’s completed audit reports can be found at https://github.com/ethereum/public-disclosures. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.

There may be other findings tracked in these repositories’ GitHub issues which are not exhaustively listed here. Whitehat’s are responsible for ensuring a vulnerability is not publicly disclosed in the respective clients known issues list or any previous audits.

For reports related to the Solidity Compiler, rewards will not be issued for crashes of the solc compiler on maliciously generated data.