# Ethereum Foundation Bug Bounty Program

> Machine-readable guidance for AI agents and LLMs assisting with bug bounty
> reports. It explains what is in scope, what proof of concept (PoC) is
> required, the validation an agent should perform before confirming an issue,
> and how to use Kurtosis. The canonical scope and rules live at
> https://bounty.ethereum.org/.

## Scope

Only the targets listed below (and on https://bounty.ethereum.org/) are in
scope. Websites, infrastructure, and anything not listed are out of scope and
will be ignored.

In-scope targets, by category:

- Specification documents: Consensus Layer Specifications, 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

Severity must be at least **Low**. Informational findings are not expected and
are generally not rewarded.

## Proof of Concept requirements

A clear, reproducible PoC is mandatory. Without one the report is discarded and
there is no refund. The required form of PoC depends on the target type.

### Client and protocol bugs

Applies to execution clients, consensus clients, specifications, smart
contracts, and dependencies.

- 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** and be reproducible
  from a node's perspective.
- **Unit tests alone are not accepted** — they cannot capture realistic node
  behaviour such as inter-client interactions and in-protocol defense
  mechanisms.
- For state-transition bugs, build any required state from a **mainnet-derived
  state**. Bugs that require impossible states (e.g. an empty validator set or
  unrealistic balances) are not accepted.

### Solidity / Vyper compiler bugs

- Provide the **source** that triggers the miscompilation, with a write-up of
  expected vs. actual behaviour.
- List the **exact affected compiler versions** and **compare against a version
  that behaves correctly**.
- A Kurtosis devnet or state test is **not** required for compiler bugs.
- Optionally, point to **live contracts** vulnerable to the issue. Sourcify
  (https://sourcify.dev/) can often identify which compiler version a deployed
  contract used.

## Validation checklist (before confirming an issue)

An agent reviewing a submission should verify, in order:

1. **In scope** — the target matches a listed target; reject out-of-scope
   reports (websites, infrastructure, unlisted repositories).
2. **Severity** — at least Low; flag anything that is merely Informational.
3. **PoC present and of the correct type** for the target category (see above).
4. **Reproduce it:**
   - Client / protocol bug: run the Kurtosis devnet or the state test and
     confirm the defect manifests (e.g. clients disagree on the post-state, or
     documented behaviour diverges).
   - Compiler bug: compile the source with an affected version and with a
     known-good version, and confirm the outputs diverge as described.
5. **Reject** if the only artifact is a unit test, if the PoC requires an
   impossible state, or if the issue cannot be reproduced.

## Using Kurtosis

Kurtosis is the preferred way to produce a reproducible, multi-client devnet
PoC.

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

A typical flow: define a minimal network containing the clients involved in the
bug using the ethereum-package, start the devnet, drive it to the vulnerable
state, and show the incorrect or divergent behaviour. Keep the configuration
minimal and include the exact commands so a reviewer can reproduce it.

## Submission notes

- Submission requires a small ETH burn (anti-spam). There are **no refunds** —
  only submit in-scope, at-least-Low findings with a clear PoC.
- Do not include personal identifiable information unrelated to the
  vulnerability.
- Reports are encrypted client-side (PGP) before delivery.

## Links

- Bug bounty scope and rules: https://bounty.ethereum.org/
- Kurtosis testnet guide: https://docs.kurtosis.com/how-to-compose-your-own-testnet/
- ethpandaops/ethereum-package: https://github.com/ethpandaops/ethereum-package/