Ethereum is a decentralized blockchain that exists whenever there are connected computers running software following the Ethereum protocol and adding to the Ethereum blockchain.

Ethereum Protocol Attackathon Academy

Learn about the basics of Ethereum, a decentralized platform that enables smart contracts and decentralized applications (dApps) to be built and run without any downtime, fraud, control, or interference.

Introduction to Ethereum

Explore what Ether (ETH) is, its role in the Ethereum network, and how it powers transactions and smart contracts within the ecosystem.

Understanding Ether

Understand the different types of accounts in Ethereum, including externally owned accounts (EOAs) and contract accounts, and how they interact with the blockchain.

Exploring Ethereum Accounts

Delve into the mechanics of transactions on the Ethereum network, including how they are created, signed, and executed.

Understanding Transactions

Discover the structure and function of blocks in the Ethereum blockchain, including how they store transaction data and help maintain network security.

What Are Ethereum Blocks?

Learn about the different components that make up an Ethereum node, the role of nodes and clients, and how they contribute to the network's operation.

Components of a Node: Nodes and Clients

Get an overview of the cryptographic techniques used in Ethereum, including digital signatures, which ensure the integrity and authenticity of transactions.

Introduction to Cryptography and Signatures

Explore the data structure known as the Merkle-Patricia Trie, which is used by Ethereum to store key-value pairs in a secure and efficient manner.

Understanding Merkle-Patricia Trie

Learn about Ethereum Improvement Proposals (EIPs), the process by which changes and upgrades to the Ethereum network are proposed, discussed, and implemented.

What is an Ethereum Improvement Proposal (EIP)?

Understand the Proof-of-Stake (PoS) consensus mechanism, how it differs from Proof-of-Work (PoW), and its benefits for the Ethereum network.

Proof-of-Stake Consensus Mechanism

Discover how blocks are proposed and validated in a Proof-of-Stake system, including the roles of validators and attestations.

How Block Proposals Work in Proof-of-Stake

Get to know the Beacon Chain, its role in Ethereum 2.0, and how it helps manage and coordinate the Proof-of-Stake network.

An Introduction to the Beacon Chain

Explore the Ethereum Virtual Machine (EVM), the runtime environment for smart contracts on Ethereum, and its importance in executing decentralized applications.

What is the Ethereum Virtual Machine (EVM)?

Learn about the architecture of an Ethereum node, including its components and how they work together to maintain the blockchain.

Ethereum Node Architecture Explained

A visual guide to the Engine API, which helps developers interact with and build on the Ethereum network more efficiently.

Engine API: A Visual Guide

Delve into the networking layer of Ethereum, which ensures secure and reliable communication between nodes in the decentralized network.

Understanding Ethereum's Networking Layer

Ethereum 101

An in-depth look at the cryptographic principles and methods that underpin the security and functionality of the Ethereum blockchain.

Foundational Cryptography in Ethereum

Cryptography

A comprehensive examination of the Beacon Chain, detailing its structure, functionality, and significance in the Ethereum 2.0 upgrade.

In-Depth Look into the Beacon Chain

Understand the Gasper finality mechanism used in Ethereum's Proof-of-Stake consensus, ensuring blocks are finalized and part of the canonical chain.

Overview of the Gasper Finality Mechanism

Learn about weak subjectivity in the context of Proof-of-Stake, including its implications for network security and validator responsibilities.

Understanding Weak Subjectivity in Proof-of-Stake

Discover the concept of attestations in Ethereum, how they are used in the consensus process, and their importance in maintaining network integrity.

What Are Attestations in Ethereum?

Explore the system of rewards and penalties for validators in Ethereum's Proof-of-Stake mechanism, incentivizing honest behavior and network participation.

Rewards and Penalties in Proof-of-Stake

Learn about the various attack vectors in a Proof-of-Stake system and the defensive measures in place to protect the network.

Proof-of-Stake: Attack and Defense Mechanisms

An overview of the Ethereum consensus specification, detailing the rules and protocols that ensure the blockchain's consistency and security.

Ethereum Consensus Specification

A deep dive into the Casper finality mechanism, which helps achieve consensus in Ethereum's Proof-of-Stake network.

In-Depth Look at Casper Finality Mechanism

Consensus Layer

The first part of an in-depth exploration of the Ethereum Virtual Machine (EVM), covering its architecture and functionality.

EVM Deep Dive Part 1

The second part of the exploration of the EVM, focusing on advanced topics and deeper technical details.

EVM Deep Dive Part 2

Learn about gas and fees in Ethereum, how they work, and their role in incentivizing miners and validators to process transactions.

Understanding Gas and Fees

An in-depth look at EVM opcodes, the low-level instructions executed by the Ethereum Virtual Machine.

Exploring EVM Opcodes

Execution Layer

Understand optimistic rollups, a layer 2 scaling solution for Ethereum that aims to increase transaction throughput and reduce costs.

Introduction to Optimistic Rollups

Start with an overview of the Dencun upgrade, outlining the changes and improvements in the upcoming Cancun-Deneb hard fork on Ethereum. This includes a detailed exploration of two Cancun-specific execution layer upgrades: EIP-6780 and EIP-5656.

Dencun Upgrade Part 1

Examine key upgrades focused on staking and validators, specifically EIP-7044 and EIP-7045.

Dencun Upgrade Part 2

Explore EIP-4788, an upgrade aimed at reducing trust assumptions in staking pools and restaking arrangements.

Dencun Upgrade Part 3

Understand EIP-7514, which will modify the validator churn limit, and EIP-1153, which introduces transient storage opcodes to the EVM execution layer.

Dencun Upgrade Part 4

Discover EIP-4844, also known as “proto-danksharding,” which will significantly reduce the cost of posting L2 rollup data to the Ethereum mainnet using “blobs.”

Dencun Upgrade Part 5

An introduction to Dank Sharding, a proposed scaling solution for Ethereum that aims to increase the network's capacity and efficiency.

Introduction to Dank Sharding

Frequently asked questions about Dank Sharding, providing answers and clarifications about this scaling solution.

Dank Sharding FAQ

Explore Verkle Trees, a new cryptographic data structure proposed for Ethereum to improve scalability and efficiency.

Understanding Verkle Trees

Dencun

A beginner's guide to Solidity, Ethereum's programming language for writing smart contracts, including basic concepts and examples.

Solidity 101: Introduction to Smart Contracts

Learn how to analyze the compilation output of Solidity contracts, understanding the generated bytecode and its implications.

Analyzing Compilation Output in Solidity

Understand how state variables are laid out in Ethereum's storage, affecting gas costs and contract interactions.

Layout of State Variables in Storage

Discover how state variables are organized in memory during contract execution, impacting performance and efficiency.

Layout of State Variables in Memory

Explore how state variables are managed in calldata, a data location used for function arguments in Solidity contracts.

Layout of State Variables in Calldata

Learn about the Solidity optimizer, a tool that improves the efficiency of compiled smart contract code, reducing gas costs.

Understanding the Solidity Optimizer

An overview of SMTChecker and formal verification tools in Solidity, used to ensure the correctness and security of smart contracts.

SMTChecker and Formal Verification

Solidity Compiler

Explore the official Vyper documentation, offering in-depth guides, syntax explanations, and best practices for writing secure and efficient Ethereum smart contracts using the Vyper language.

Vyper Documentation

Learn about the process by which Vyper source code is transformed into Ethereum bytecode, enabling the deployment of smart contracts to the blockchain and providing insights into the bytecode structure.

How Vyper Compiles into Bytecode

Delve into jump tables in Vyper, an advanced technique used to optimize contract execution by improving the efficiency of conditional branching, leading to reduced gas costs and streamlined logic.

A Guide to Vyper Jump Tables

Review notable vulnerabilities discovered in the Vyper compiler over time, and gain insights into how these issues have shaped the current security practices in Vyper development.

Past Compiler Vulnerabilities

Vyper Compiler

An overview of Attacknet, a tool and testing methodology for subjecting blockchain devnets to simulated network and side channel attacks.

Attacknet: Chaos Testing Blockchain Nodes

Documentation on the execution-spec-tests framework used to help uncover issues in the execution layer.

How to PoC execution layer bugs

Documentation on using PySpec to run tests for the Ethereum consensus layer.

How to PoC consensus bugs

A step-by-step guide on how to set up and install the Solidity compiler, including building from source.

Setting Up and Installing the Solidity Compiler

Instructions on how to run PoC tests for the Solidity compiler, helping to identify and fix potential issues.

How to run Solidity Compiler Tests

Instructions on how to run PoC tests for the Vyper compiler, helping to identify and fix potential issues.

How to run Vyper Compiler Tests

A compilation of instructions on how to run PoC tests for individual client software.

How to run Client Tests

Running a Proof of Concept (PoC)

Public disclosures related to the consensus layer of Ethereum, detailing identified issues and their resolutions.

Consensus Layer Public Disclosures Part 1

The second part of public disclosures for the consensus layer, providing updates on new findings and fixes.

Consensus Layer Public Disclosures Part 2

Public disclosures for the execution layer of Ethereum, covering known vulnerabilities and their mitigations.

Execution Layer Public Disclosures Part 1

The second part of public disclosures for the execution layer, discussing additional vulnerabilities and fixes.

Execution Layer Public Disclosures Part 2

A compiled list of known issues from client and language teams, providing insights into current limitations and bugs.

Further Known Issues

Audits & Known Issues

An analysis of client diversity in the Ethereum network, examining the distribution of different clients and their impact on the network's security and decentralization.

Client Diversity

A comprehensive guide to the terminology used in the Ethereum ecosystem, helping newcomers understand key concepts and jargon.

Ethereum Terminology Guide

The Ethereum white paper which outlines the vision, principles, and technical foundation of Ethereum.

The Ethereum White Paper

A detailed technical specification of Ethereum, known as the Yellow Paper, which provides an in-depth look at the protocol's mechanics and architecture.

The Ethereum Yellow Paper

All further resources will be available via the following Slite page.

Further Resources

Technical FAQ

Attackathons are education-based bug hunting competitions where security researchers compete over a reward pool by submitting impactful bugs in the project's code. Here’s how they work:

**Before the Attackathon**<br/> Immunefi works with the project to host a security-focused education period, providing top tier education and support to security researchers.

**During the Attackathon**<br/> Security researchers experience the optimal hunting conditions, with direct project support, responsiveness, and duplicate rewards.

**After the Attackathon**<br/> Immunefi spotlights the security accomplishments, with a custom leaderboard, Attackathon Findings Report, Bug Fix Reviews, and NFT awards.

Ultimately, Attackathons serve to secure projects, develop their security ecosystem, and create new opportunities for security researchers.

What's an Attackathon?

Specification - Deposit Contract Specification

__KYC Requirement__

Immunefi will be requesting KYC information in order to pay for successful bug submissions to whitehats who earn $500 USD or more. The following information will be required:
- Full name 
- Date of birth
- Proof of address (either a redacted bank statement with address or a recent utility bill)
- Copy of Passport or other Government issued ID

__Eligibility Criteria__ 

Security researchers who wish to participate must adhere to the rules of engagement set forth in this program and cannot be:
- On OFACs SDN list 
- From a restricted country or territory: North Korea, Iran, Cuba, Syria, certain regions of Ukraine (Crimea, Donetsk and Luhansk), West Bank and Gaza regions of Israel, Venezuela, Afghanistan
- Official contributor, both past or present
- Employees and/or individuals closely associated with the project 
- Security auditors that directly or indirectly participated in the audit review, or who work for the company which did the audit review
- Employees and contractors of the Ethereum Foundation may participate in the program only in the accrual of points and will not receive monetary rewards. Client teams may participate in finding vulnerabilities in other client team’s projects, however employees and contractors of individual client teams who self report vulnerabilities will only result in accrual of points and will not receive monetary rewards

__Asset Accuracy Assurance__

Bugs found on assets incorrectly listed in-scope will be considered valid and be rewarded.

__Private Known Issues Reward Policy__

Private known issues, meaning known issues that were not publicly disclosed or disclosed to Immunefi, are valid for a reward at one severity lower than what they’re confirmed as. However, bug reports that are private known issues do not unlock reward pool tiers. For example, a High bug that ended up being a private known issue, would be paid as a Medium and would not qualify for unlocking the $500k tier of the reward pool for this Attackathon.

__Primacy of Impact vs Primacy of Rules__

Ethereum Foundation adheres to the Primacy of Impact for the following impacts:
- Blockchain/DLT - Critical
- Blockchain/DLT - High
- Smart Contract - Critical

Primacy of Impact means that the impact is prioritized rather than a specific asset. This encourages security researchers to report on all bugs with an in-scope impact, even if the affected assets are not in scope. For more information, please see [Best Practices: Primacy of Impact](https://immunefisupport.zendesk.com/hc/en-us/articles/12340245635089-Best-Practices-Primacy-of-Impact).

When submitting a report on Immunefi’s dashboard, the security researcher should select the Primacy of Impact asset placeholder. If the team behind this project has multiple programs, those other programs are not covered under Primacy of Impact for this program. Instead, check if those other projects have a bug bounty program on Immunefi.

If the project has any testnet and/or mock files, those will not be covered under Primacy of Impact.

All other impacts are considered under the Primacy of Rules, which means that they are bound by the terms and conditions set within this program.

__Responsible Publication__

After the Attackathon concludes, whitehats may only publish more info on the fixed and paid bug reports that appear on the [Immunefi Audit Competitions Gitbook](https://reports.immunefi.com). Reports closed as invalid are also okay to publish after this time. This rule is to prevent premature publication of any bugs that will take considerable time to fix. 

Immunefi will also publish a leaderboard of the participants and their earnings.

__Feasibility Limitations__

The project may receive reports that are valid (the bug and attack vector are real) and that cite assets and impacts in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence should not be used as reasons for downgrading a bug's severity.

Therefore, Immunefi has developed a set of [feasibility limitation standards](https://immunefisupport.zendesk.com/hc/en-us/articles/16913132495377-Feasibility-Limitation-Standards) which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.

__Immunefi Standard Badge__

By adhering to Immunefi’s best practice recommendations, Ethereum has satisfied the requirements for the [Immunefi Standard Badge](https://immunefisupport.zendesk.com/hc/en-us/articles/9522048467857-Immunefi-Standard-Badge).

anatomist

CertiK

Franfran

Blobism

Omik

troy_ar

br0nz3p1ck4x3

Pig46940

cheems

csludo

impermanentW

a3yip6

[redacted]

https://drive.google.com/file/d/15lCy1jza9MsnDooWmponwdaTq_EjV2-m/view?usp=sharing

Ethereum is a decentralized blockchain that exists whenver there are connected computers running software following the Ethereum protocol and adding to the Ethereum Blockchain. 

Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

Unintended permanent chain split affecting greater than or equal to 25% of the network, requiring hard fork (network partition requiring hard fork)

Permanent freezing of funds

Direct loss of funds

Permanent freezing of funds (fix requires hardfork)

Network not being able to confirm new transactions (total network shutdown)

Shutdown of greater than or equal to 33% of network processing nodes without brute force actions, but does not shut down the network

Temporary freezing of network transactions by delaying one block by 500% or more of the average block time of the preceding 24 hours beyond standard difficulty adjustments affecting greater than or equal to 25% of the network

Temporary freezing of network transactions by delaying one block by 500% or more of the average block time of the preceding 24 hours beyond standard difficulty adjustments affecting less than 25% of the network

bug in the respective layer 0/1/2 network code that results in unintended smart contract behavior with no concrete funds at direct risk

Causing greater than or equal to 25% of network processing nodes to process transactions from the mempool beyond set parameters (e.g. prevents processing transactions from the mempool)

Increasing greater than or equal to 25% of network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours

Shutdown of greater than or equal to 10% or equal to but less than 33% of network processing nodes without brute force actions, but does not shut down the network

Unintended chain split affecting greater than or equal to 25% of the network (Network partition)

Causing less than 25% of network processing nodes to process transactions from the mempool beyond set parameters (e.g. prevents processing transactions from the mempool)

Unintended chain split affecting less than 25% of the network (Network partition)

Increasing less than 25% of network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours

Modification of transaction fees outside of design parameters

Shutdown of less than 10% of network processing nodes without brute force actions, but does not shut down the network

(Specifications) A bug in specifications with no direct impact on client implementations

(Compiler) Elimination of security checks

(Compiler) Incorrect bytecode generation leading to incorrect behavior

(Compiler) Memory-Related errors

(Compiler) Encoding errors

(Compiler) Semantic analysis errors

(Compiler) Exception handling errors

(Compiler) Syntactic analysis errors

(Compiler) Optimization errors

(Compiler) Unexpected behavior

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](https://immunefisupport.zendesk.com/hc/en-us/articles/9946217628561-Proof-of-Concept-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://clientdiversity.org/)
- [https://ethernodes.org/](https://ethernodes.org/)
- [https://explorer.rated.network/network?network=mainnet&timeWindow=1d&rewardsMetric=average&geoDistType=all&hostDistType=all&soloProDist=stake](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](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) 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#L113-L117)
- [https://github.com/ethereum/execution-specs/blob/1e9a6e518adab7ae55ebddb15d72f91041240c8a/setup.cfg#L152-L180](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](https://github.com/protolambda/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](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](https://immunefi.slite.com/app/docs/npGhR5rBwFfnTi).

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

The following reward terms are a summary, for the full details read our [Ethereum Attackathon Reward Terms](https://immunefisupport.zendesk.com/hc/en-us/articles/30287460669841-Ethereum-Protocol-Attackathon-Reward-Terms).

The reward pool size varies based on the severity of bugs found:
- If one or more Low severity bugs are found the reward pool will be **$250,000 USD**
- If one or more Medium severity bugs are found the reward pool will be **$500,000 USD**
- If one or more High severity bugs are found the reward pool will be **$900,000 USD**
- If one or more Critical severity bugs are found the reward pool will be **$1,500,000 USD**

Private known issues are considered valid.

**Duplicates are not valid for this Attackathon.**

Private known issues will unlock higher reward pools as though they were one severity level lower. For example, a Critical severity bug which was a private known issue would unlock the  reward pool conditional on a High severity bug being found.

The severity level of private known issues remains unchanged and SRs earn their portion of the reward pool and position on the leaderboard according to this unchanged severity level.

Public known issues are invalid as normal.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi [Vulnerability Severity Classification System V2.3](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/).

__Reward Payment Terms__

Payouts are handled by the Immunefi team directly and are denominated in USD. However, payments are done in ETH

Rewards will be distributed all at once based on Immunefi’s distribution formula after the event has concluded and the final bug reports have been resolved.

__Insight Rewards Payment Terms__

Insight Rewards: Portion of the Rewards Pool

- The "Insight" severity was introduced on Audit Competition & Attackathon programs to recognize contributions that extend beyond identifying immediate vulnerabilities. Currently, it's not an option to select the Insight severity when submitting a report. However, our team or program will designate it accordingly if applicable. "Insights" underscores our commitment to valuing all types of contributions that contribute to a more secure environment and will always be rewarded. [View more information about Insights](https://immunefisupport.zendesk.com/hc/en-us/articles/13333032674961-Severity-Classification-System?utm_source=immunefi).

NAME	EARNINGS	TOTAL VALID BUGS	MEDIUM/LOW	INSIGHTS
1	$148,677	9	9	3
2	$146,250	7	7	0
3	$90,801	6	6	14
4	$33,750	3	3	0
5	$33,750	3	3	0
6	$16,590	1	1	3
7	$15,134	1	1	2
8	$4,369	0	0	3
9	$2,913	0	0	2
10	$2,427	0	0	1
11	$2,427	0	0	1
12	$1,456	0	0	1
13	$1,456	0	0	1
14	$0	3	3	3
15	$0	0	0	1

Attackathon | Ethereum Protocol

Unicorn Sponsors

Panda Sponsors

Blobfish Sponsors

Attackathon | Ethereum Protocol

Status

Status