## Decoupling `ExecutionPayload` validity from Data Availability

by [mike neuder](https://x.com/mikeneuder) – *Oct 2, 2025.*
$\cdot$
**tl;dr;** The pipelining benefits of ePBS give rise to the "free option problem." Dual-deadline ePBS, which allows the blob download to be amortized over a much larger portion of the slot, also exposes a correspondingly long free option on the `ExecutionPayload` itself. If we decouple the validity of the `ExecutionPayload` from the data availability check on the blobs, we can retain the benefits of dual-deadline ePBS without exposing the long free option. This compromise might be the correct way to balance the efficiency of the slot time utilization and the stability of the block-/blob-space.
$\cdot$

#### 📄 Related articles and notes

| Description | |
|-------------|------|
| Cristoph et al.'s "Free Option" | [link](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115) |
| Cristoph et al.'s "Free Option II" | [link](https://collective.flashbots.net/t/the-free-option-problem-in-epbs-part-ii/5145/) |
| Anders' "Dual Deadline" | [link](https://notes.ethereum.org/@anderselowsson/Dual-deadlinePTCvote) |
| Potuz's "Case for ePBS" | [link](https://hackmd.io/@potuz/Bkcwd5hG1x) |
| Terence's "Delayed Execution" | [link](https://ethresear.ch/t/advantage-of-pipelining-consensus-and-execution-delayed-execution/19668) |
| Toni's "Slot Restructuring" | [link](https://ethresear.ch/t/slot-restructuring-design-considerations-and-trade-offs/22687) |
| Conor's "ePBS Ammendment" | [link](https://hackmd.io/Edm2IAouSOmHBmRvHdju2A) |
| Lin's "Pipelining only ePBS" | [link](https://hackmd.io/@linoscope/pipelining-only-epbs) |
| Lion's "Case Against ePBS" | [link](https://blog.sigmaprime.io/glamsterdam-eip7732.html) |
| Mark's "Glamsterdam's hidden gem" | [link](https://notes.ethereum.org/@0YxgBRfbR0OTJbu2fDpY2Q/BkyjpOJEgg#Glamsterdam%E2%80%99s-Hidden-Gem-EIP-7732) |

$\cdot$

#### 🔗 Specs and protocol docs

| Description | |
|-------------|------|
| Deneb `on_block` | [link](https://ethereum.github.io/consensus-specs/specs/deneb/fork-choice/#on_block) |
| Electra `BeaconBlock` | [link](https://ethereum.github.io/consensus-specs/specs/electra/beacon-chain/#beaconblockbody) |
| Gloas `on_execution_payload` | [link](https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/fork-choice.md#new-on_execution_payload) |

---

### 1. Preliminaries

To understand the problem we are trying to solve, we start by examining the slot structure today, with a special focus on the *objects* of interest for our discussion. The figure below shows **today's block and blob validation.**


We focus only on the *attestation deadline*, which occurs four seconds into the slot. At this timestamp, the attesting committee runs the fork-choice rule to determine what they will vote for as head. Notice the following:
1. *The `BeaconBlock` contains the full `ExecutionPayload`* – see the `execution_payload` field of [specs](https://ethereum.github.io/consensus-specs/specs/electra/beacon-chain/#beaconblockbody). The payload is the list of transactions that constitute the execution layer block.
2. *The `BeaconBlock` contains a commitment to the blobs* – see the `blob_kzg_commitments` field of the [specs](https://ethereum.github.io/consensus-specs/specs/electra/beacon-chain/#beaconblockbody). The blobs are gossiped separately from the rest of the block.
3. *The full `BeaconBlock` **and the corresponding blobs** must be downloaded at `t=4` for the attester to consider the block valid.* You can see this in the definition of the fork-choice rule. See `on_block` in the [specs](https://ethereum.github.io/consensus-specs/specs/deneb/fork-choice/#on_block), which is the handler that determines if a block is considered for attestation. Line 26 dictates that the `is_data_available` check must succeed.[^0]

[^0]: Also note that the execution of the `ExecutionPayload` happens in the `state_transition` call in Line 32, so the block also must be finished executing before it is considered attestable. Since this article focuses specifically on network latency and not execution latency, we won't discuss the actual execution further.

This picture also demonstrates why "[slot restructuring](https://ethresear.ch/t/slot-restructuring-design-considerations-and-trade-offs/22687)" has become an important topic when considering scaling upgrades. The eight seconds after the attestation deadline, but before the start of the next slot, is probably too long for the propagation and aggregation of attestations that need to be done before the next proposer.

ePBS aims to enact a version of this slot restructuring. The figure below shows **the "[dual-deadline](https://notes.ethereum.org/@anderselowsson/Dual-deadlinePTCvote)" voting for the Payload-Timeliness Committee (abbr. PTC) ePBS design**.[^1]


The `ExecutionPayload` is now fully detached from the `BeaconBlock`, just like the blobs. Indeed, this is why ePBS is sometimes (jokingly?) referred to as "execution payload-block separation" rather than the original "enshrined Proposer-Builder Separation."[^2] Notice the following.
1. *The attestation deadline is shifted earlier, and the `BeaconBlock` only contains **commitments** to the `ExecutionPayload` and Blob contents*. The attestation deadline at `t=1.5` serves as a vote on the consensus layer block, but doesn't require seeing the actual contents of the execution layer block or the blobs.
2. *The payload deadline applies only to the PTC committee members, who will vote on whether they observed the payload by `t=4`.* This gives 2.5 seconds for the propagation of the `ExecutionPayload` and the contents of the payload **must match the commitment made in the `BeaconBlock`**. (This is where the "free option" comes in, because the builder of the `ExecutionPayload` could selectively choose whether or not to reveal the actual block – more on this below.)
3. *The blob deadline also only applies to the PTC committee members, who will vote on whether they observed the blobs by `t=10`*. This second deadline is motivated by a two facts: (1) the `ExecutionPayload` needs to be executed and/or proved before the subsequent proposer, so having it come earlier makes sense (see [Potuz](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115/2)), (2) blobs don't have any execution requirements and are also large objects, meaning they benefit from amortization over a larger share of the slot.

[^1]: AFAICT, the dual-deadline is a proposal and not necessarily what would be enshrined in 7322. However, it does seem like the natural evolution of trying to make the best use of the slot; as Potuz noted [here](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115/2), "data processing is only about broadcasting it, validation is free, thus, we want to set the deadline for its availability as late as the end of the slot."

[^2]: FWIW, I think the acronym overloading was a very bad decision and probably *slowed* down the progress towards this EIP – Mark also alluded to this in point 1 [here](https://notes.ethereum.org/@0YxgBRfbR0OTJbu2fDpY2Q/BkyjpOJEgg#Why-did-it-take-so-long-to-come-to-this-conclusion).

The decoupling of the `ExecutionPayload` from the `BeaconBlock` and the addition of the PTC committee voting on two pieces of data allows for this nice flexibility around how the slot is used. Of course, this isn't the end of the story. The so-called "free option" problem, as named by the Cristoph et al. [post](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115), arises from exactly the pre-commitment that allowed us to restructure the slot.

The figure below highlights the **free-option problem as it arises in the dual-deadline version of ePBS.**


This is the same figure, just with two additional timestamps at `t=3.5` and `t=8`, showing the first and second free option timestamps, respectively. I used the timestamps from the [Free-Option post](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115), which correspond to values of 0.5s and 2s for payload and blob latency, respectively. A few notes:
1. *The first free option arises from withholding the `ExecutionPayload`.* The latency here is quite short, however, and the free option may only be about 2 seconds. As noted in the second [Free Option](https://collective.flashbots.net/t/the-free-option-problem-in-epbs-part-ii/5145#p-10417-shorter-option-time-window-and-penalties-3) post, "reducing [the duration] from 8s to 2s reduces the average exercise probability by more than 77% and the average option value by 88%." In other words, the "short" free option is not that valuable empirically.
2. *The second free option arises from withholding blob data.* If the builder included a commitment to a private blob, then they can wait until much later in the slot before deciding whether to publish the private blob and thus make the whole block valid (or withhold it and thus make the whole block invalid).
3. *The coupling of the `ExecutionPayload` to the data availability check is what allows this second option to be exercised.* Essentially, the builders use a private blob as their ticket to revert the entire `ExecutionPayload` if they would like to later in the slot.

This paints a bleaker picture for ePBS with the dual-deadline design, because exposing the 8s free option significantly increases the value of that option, as described empirically in the [second free option post](https://collective.flashbots.net/t/the-free-option-problem-in-epbs-part-ii/5145/1).

As Potuz pointed out [here](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115/2), "any system that has these different deadlines, the builder will have an option to withhold some private data."[^3] There is a fundamental tension between allowing builders to commit to data before consensus is reached that the data is available. However, in the name of decoupling parts of consensus, the following section proposes removing the dependence on the blob availability from the execution of the `ExecutionPayload`.

[^3]: Lin also notes this in his [post](https://hackmd.io/Edm2IAouSOmHBmRvHdju2A), "both the free-option problem and better blob propagation stem from the same 'commit early, propagate later' timing structure."

### 2. Proposal

Stating the proposal simply: **in dual-deadline ePBS, remove the dependency of the `ExecutionPayload` from the data availability check.** Under this design, as long as PTC members vote that the `ExecutionPayload` was present, the execution takes place and the L1 state updates regardless of the presence or absence of the blobs. This proposal rests on the following claims.

> **Claim 1:** Downloading blobs is the most important step to amortize over a longer fraction of the slot.[^4]

Indeed, this is the motivation for the dual-deadline ePBS pitch in the first place, and it makes intuitive sense. Again, quoting Potuz's [comment](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115/2), "The data processing is only about broadcasting it, validation is free, thus, we want to set the deadline for its availability as late as the end of the slot. The payload does not have this luxury: it needs to be executed today and it needs to be ZK proven in the future. Thus, the optimal deadline for the payload is some time before the slot."

[^4]: There is some subtlety here. Only private blobs (those that haven't hit the public mempool) should need to be downloaded *after* the `BeaconBlock` is published. For lots more on this discussion, see [here](https://hackmd.io/@mikeneuder/blob-gossip-and-validation#2-Blob-gossip-and-validation-pre-PeerDAS).

Thus, the dual-deadline version of ePBS *does* seem like a potentially important upgrade to make maximal use of the slot time.

> **Claim 2:** Blobs are generally not MEV-carrying.[^5]

[^5]: For more discussion on why this is and likely will remain true, see [here](https://ethresear.ch/t/on-the-future-of-the-blob-mempool/22613#p-54994-h-3-broader-considerations-7).

This is a helpful fact because it means the value of committing to a blob and then choosing not to reveal it is probably relatively low, *when only considering the blob's inclusion on the L1 in isolation.* For example, a centrally sequenced L2 submitting a blob probably will not have a strong desire to revert the blob after time has passed, because they are still entirely in control of the sequencing for the L2. This leads naturally to the final claim.

> **Claim 3:** The validity of the `ExecutionPayload` shouldn't depend on the availability of the blobs.

This coupling is precisely what allows the builders to keep a private blob to preserve the option of reverting their `ExecutionPayload` after 8s has elapsed. Instead, we could enable the PTC members to indicate that the `ExecutionPayload` was available and valid *even if the blobs are missing*, and the payload would still execute and update the L1 state. In this world, the builders only have the 2s option to revert the `ExecutionPayload`, which is much less valuable.

In short, this design is a compromise.
- The free option to not reveal the `ExecutionPayload` still exists and is 2s.
- The blob download is still amortized over 8.5s.
- Withholding blobs *no longer reverts an `ExecutionPayload`*, thus the long free option only applies to the contents of the blobs and not the L1 block.
- The free option over the valuable L1 execution state is short; the free option over the less valuable blob state is long.

This set of tradeoffs might be worth making when balancing scaling and stability of block- and blob-space.