# EIP-7732 Amendment: Pipelining without Optionality

Conor McMenamin, Nethermind Research

This note is a checkpoint of a recent design I've been cooking which removes [optionality in EIP-7732](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115). This amendment requires that a beacon proposer of slot `N` include the execution paylod header of slot `N-1`, attestation for slot `N-1`, and (KZG) commitments to the blobs that will be included in slot `N`. Later in slot `N`, the execution payload and blob DA for slot `N` is attested to by a Payload Timeliness Committee (PTC), meaning the proposer for slot `N` only needs to commit to the execution payload for slot `N` in the seconds before this PTC deadline, reducing optionality. As the PTC deadline is for the execution payload and the blob DA, optionality is effectively removed. Pipelining of execution and payload propagation is preserved, by only requiring attestors to re-execute the payload from slot `N` by the attestation deadline, which occurs in slot `N+1`. This provides [Beacon block deadline slot `N`, PTC deadline slot N] for propagating the payloads, and [PTC deadline slot `N`, attestation deadline slot `N+1`] for re-execution by attestors. This is illustrated in the diagram below, with example deadline durations specified -- the exact deadline timings are open to optimization.


# Design Intuition

To give the intuition of why this design should work, I'll go through the key deadlines with some example timings (inline with propagation-execution timelines from existing 7732 proposals) and flow of attesting to a (beacon block, execution block, blob DA) triple for a slot `N`.

- (`Slot N, t_0=0s` after slot `N` starts): **Slot Start**.
- (`Slot N, t_1=1.5s` after slot `N` starts): **Beacon Block Propagation Deadline**: Attestors will attest to this at the attestation deadline. The beacon block contains:
- The execution payload header of slot `N-1`.
- The attestations from slot `N-1`, which attest to the execution payload of slot `N-2`, and the beacon block of slot `N-1`.
- Commitments to the blobs for slot `N` ([flavours of PEPC here](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879), H/T Lin)
- (`Slot N, t_2=6s`): **Attestation Deadline**: Attestors attest to:
- Beacon block for slot `N` timeliness and validity.
- Execution payload for slot `N` validity. See [Open Question](https://hackmd.io/Edm2IAouSOmHBmRvHdju2A#Open-Questions) #1 for more on this.
- (`Slot N, t_3=8.5s`): **PTC Deadline** or **Payload Deadline**: PTC attest to the timeliness and availability of the execution payload and blob DA for slot `N`.
- (`Slot N+1, t_4=13.5s` after slot` N` starts): **Beacon Block Propagation Deadline**.
- (Slot N+1, t_5=18s after slot N starts): **Attestation Deadline**.

## Key Properties

### Pipelining
With the above design, there is:
- `t_3-t_0` for blob propagation, with the final part of this window for execution payload propagation (crossover of propagation windows is part of the original 7732 design too).
- `t_5-t_3` for execution.

As these windows don't crossover for a given slot's execution payload, there is full pipelining of execution and propagation. Importantly, while re-execution is happening for slot `N`'s execution payload, blobs for slot `N+1` can be propagated as their DA does not need to be attested to at the same time as the attestations for slot `N`'s execution payload.

Using the example times provided, this is approximately the same time for propagation and execution as the current 7732 design.

### No Optionality

There is no early commitment of the execution payload, so there is no optionality to be gained on the execution layer.

For the DA "layer", as long as centralized-sequenced L2s dominate the L2 space and MEV is dominant on L1, both of which hold true today, optionality is effectively removed in the above amendmended 7732 design.

Although blobs are being committed `t_3-t_1` before the blobs need to be delivered, blobs are likely not a source of optionality that we need to be concerned about. Almost all blobs are being provided as DA for L2s, and almost all L2s are centrally sequenced -- with the blob contents committed long before the blob arrives on L1. For non-centralized sequenced L2s, there is some optionality. However, these are a minority of blobs today.

# Open Questions

This checkpointed design still has unanswered questions that I haven't had time to tackle:

1. How do we handle an invalid yet timely execution payload included in a beacon block?
i. We allow forking of execution payloads, separate to consensus chain forks. This is very similar to [7886](https://eips.ethereum.org/EIPS/eip-7886#chain-state-tracking) and [Lin's 7732 amendment](https://hackmd.io/@linoscope/pipelining-only-epbs#Comparison-with-Delayed-Execution-EIP-7886).
ii. The cleanest way to handle this would be to invalidate the beacon block. This would give the beacon proposer of slot N+1 only [PTC deadline slot N, Slot N+1 start] to re-execute the execution payload of slot N. With a strict pipelining requirement, this is unacceptable.
2. Are KZG commitments to the blobs for slot N necessary in the beacon block for slot N? My understanding is yes, so the PTC and attestors know what to download e.g. all information to be download must reference these original commitments. This may not be the most efficient way of doing this.
3. Do the original fork-choice weights hold up here?
4. Will the beacon proposer for slot N propagate his or her own blobs, or outsource this through "blob-Boost" -- MEV-Boost for blobs? The more blobs, the higher this requirement becomes for a beacon proposer.

## Motivation

Optionality in the [current implementation of 7732](https://eips.ethereum.org/EIPS/eip-7732), as of 26/08/2025, stands as a potential "[P0 bug](https://x.com/mikeneuder/status/1948911395028041941)"-- critical -- as acknowledged by Mike, one of the original 7732 authors.

In response to this, Lin, my fellow protocol researcher at Nethermind, [proposed an amendment removing the free option from 7732.](https://hackmd.io/@linoscope/pipelining-only-epbs)

## Acknowledgements

Thanks to Lin Oshitani, Ahmad Bitar, and Potuz for their helpful discussions on the topic. Discussions != endorsements.