Was rejecting EIP-8025 (opt-in execution proofs) correct?
Protocol design · 6 participants · 12 quotes · 2026-10-15 ~ 2026-10-16
The day after ACDC #189 rejected including EIP-8025 (opt-in execution proofs) in Hegotá, a second round of debate broke out over which governance track it should take. donnoh_eth and ivanlitteri criticized the decision as a mistake that discarded ready-made work with no consensus change and therefore no risk, while lightclients countered that early adoption bypasses deliberation and erodes the barrier to inclusion, and that 8025 fits an informational EIP rather than a core EIP to be scheduled into a hard fork.
Background
EIP-8025 (Optional Execution Proofs) is a Draft-stage core EIP proposed by Kevaundray Wedderburn, Justin Drake and others. Altruistic provers generate execution proofs and propagate them over p2p so that consensus layer (CL) nodes can validate execution payloads statelessly without re-executing them. It is a fully opt-in design that does not change consensus validity rules, and is regarded as the first step of the zkEVM roadmap. At ACDC #189 (2026-10-15) it failed to be promoted to CFI because of insufficient CL team support and was marked DFI (declined) for Hegotá. The debate is over whether this feature, which makes no consensus change, should be treated as a core EIP to put on the hard fork schedule or as an informational EIP that does not define protocol behavior.
Why it matters
Once it is settled which governance track a feature with no consensus change should take, every opt-in feature in the zkEVM transition will follow the same path. At the same time, concern that market incentives such as LSTs could push attesters toward statelessness before countermeasures exist is entangled with the governance decision, which affects the pace at which execution proofs mature and validator diversity.
Resolution
At ACDC #189 (2026-10-15), EIP-8025 failed to be promoted to CFI because of insufficient CL team support and was marked DFI (declined) for Hegotá, but the debate over its track classification continued the next day.
Key points
- Should an opt-in feature that does not change consensus rules be put on the hard fork schedule, or is an informational EIP enough?
- Should consequences such as proof cost, bandwidth and limits be deliberated before adopting an EIP, or are they visible only by running on a real testnet?
- Does putting 8025 on the official schedule push attesters toward statelessness through LST market incentives?
For — Discarding ready-made work was a mistake
CPerezz.eth ⟠ 🦀, Kev, Ivan, donnoh.gwei 💗
- Opt-in execution proofs do not change consensus rules and so pose no risk to the network. Client teams' refusal to commit to adopting them is a mistake that throws away the first step of the zkEVM roadmap.
- The results that actually matter, such as proof cost, bandwidth consumption and where things break under real load, are visible only by running it. So it should be run on a testnet rather than rejected on grounds of deliberation.
- Unlike an informational EIP that only describes guidance, 8025 defines a gossip topic, proof format and req/resp protocol that work only if every client implements them identically, so it should go on the hard fork schedule.
Against — It creates spec dependencies and bypasses deliberation
Toni Wahrstätter ⟠, ً
- The consequences of an EIP must be deliberated before it is adopted, and hasty adoption skips that deliberation period and erodes the barrier to including something.
- An opt-in feature with no consensus change fits an informational EIP that does not define protocol behavior, and since the Beacon Chain also launched as an informational EIP, it is not a core EIP to be scheduled into a hard fork.
- If anything, putting 8025 on the hard fork schedule pushes market participants such as LSTs toward stateless attesting before we even know how to respond.