Ethereum Foundation Bug Bounty Program

For compiler bugs, a Kurtosis devnet or state test is not required. Instead, provide the following:

• The source code that triggers the miscompilation.
• A write-up comparing the expected vs. actual behavior.
• The exact affected compiler versions and a comparison against a version that behaves correctly.
• (Optional) Links to live vulnerable contracts; Sourcify (https://sourcify.dev/) can be used to identify the compiler version of deployed contracts.

For bugs related to execution/consensus clients, specifications, smart contracts, and dependencies, a clear and reproducible PoC is mandatory. Unit tests alone are not accepted.

Requirements:

• Provide a Kurtosis-based PoC that spins up a local devnet, or a reproducible state test (EVM / goevmlab).
• The PoC must demonstrate the vulnerability end-to-end from a node's perspective.
• For state-transition bugs, use a mainnet-derived state. Bugs requiring impossible states (e.g., empty validator sets or unrealistic balances) are not accepted.

When submitting a report, keep the following constraints in mind:

• Anti-Spam: Submission requires a small ETH burn. There are no refunds, so only submit in-scope, at-least-Low findings with a clear PoC.
• Privacy: Do not include personal identifiable information (PII) unrelated to the vulnerability.
• Security: Reports are encrypted client-side using PGP before delivery.

Kurtosis is the preferred tool for creating reproducible, multi-client devnet PoCs. The recommended workflow is to define a minimal network using the ethereum-package, start the devnet, drive it to the vulnerable state, and demonstrate the incorrect behavior.

Resources:

• Kurtosis Testnet Guide: https://docs.kurtosis.com/how-to-compose-your-own-testnet/
• Ethereum Package (ethpandaops): https://github.com/ethpandaops/ethereum-package/

Reviewers and agents should verify submissions in the following order:

1. Scope: Ensure the target is on the approved list. Reject websites or infrastructure.
2. Severity: Ensure it is at least 'Low'. Flag informational findings.
3. PoC Type: Verify the PoC matches the target category (Kurtosis/state test for clients; source code for compilers).
4. Reproduction:
   • For client/protocol bugs: Run the Kurtosis devnet or state test to confirm the defect (e.g., client disagreement on post-state).
   • For compiler bugs: Compile source with both affected and known-good versions to confirm divergent outputs.
5. Rejection Criteria: Reject if the only artifact is a unit test, if the PoC requires an impossible state, or if the issue cannot be reproduced.

Only the following targets are in scope for the Ethereum Foundation Bug Bounty Program. Websites, infrastructure, and unlisted repositories are out of scope. Findings must have a severity of at least 'Low'; informational findings are generally not rewarded.

In-scope targets:

• Specification documents: Consensus Layer and Execution Layer Specifications
• Execution layer clients: Besu, Erigon, Geth, Nethermind, Reth
• Consensus layer clients: Grandine, Lighthouse, Lodestar, Nimbus, Prysm, Teku
• Language compilers: Solidity, Vyper
• Smart contracts: Beacon Chain Deposit Contract
• Dependencies: C-KZG-4844, Go-KZG-4844