Ethereum Launches $2 Million Attackathon to Crowdsource Protocol Security

The event, dubbed "Attackathon," targets the full protocol codebase and is positioned as the largest crowdsourced security audit of the chain to date.

Execution Surface

The competition opens with a technical walkthrough of Ethereum's code, ensuring participants enter with a shared baseline of the protocol's internals before they begin searching for attack vectors. Researchers operate under defined rules; only impactful, rule-compliant reports pay out. Immunefi, the host platform, compiles the post-event findings into a public report.

EPS contributed $500,000 to the prize pool. The remaining $1.5 million is open to sponsorship, with a stated target deadline of August 1. The model repeats at every hard fork covering changes to the codebase, making Attackathon a recurring security gate rather than a one-off event. For scale, Immunefi-listed bounties typically range from tens to hundreds of thousands of dollars; LayerZero's program reaches $15 million, the upper benchmark for protocol-scale bug hunts.

Attack Vectors Worth Tracking

The audit window spans consensus, execution, and cross-component interactions. State transition logic, validator behavior, and any new opcode or precompile introduced by the fork sit inside the attack surface. Cross-layer assumptions — where rollup stacks depend on L1 invariants — historically surface as the highest-impact findings. EPS will publish the compiled report post-event, giving the developer community a direct read on which code paths the audit hit hardest.

For smart contract developers building on the stack, the practical signal is straightforward: any code paths the audit touches are about to receive concentrated external scrutiny. Contracts relying on assumptions about fork timing, mempool behavior, or base-layer gas semantics need re-validation against the upcoming changes. Audit teams running concurrent reviews should align their scope with the EIP set scheduled for the fork rather than against the previous fork's behavior.

Local Verification Checklist

• Re-check integrations against the hard fork's EIP set, not against the last stable baseline.
• Audit state-machine logic against new execution-layer changes before mainnet exposure.
• Treat consensus-layer timing assumptions as in-scope until Immunefi's report clears them.
• Review any custom precompile, opcode, or blob interaction before deploying against the new base layer.
• Document L1 invariant dependencies so L2 and bridge teams can map against the published findings.