# 7732 - Late Payload Commitment It feels like we've been endlessly discussing various slot restructuring designs. Unfortunately, I have one more design to offer. Apologies in advance. ## Where we Stand After months of exploring different designs, the best available option appears to be [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) with a small modification for [dual-deadline PTC](https://notes.ethereum.org/@anderselowsson/Dual-deadlinePTCvote). The only unknown at this point, is whether [builder withhold timing games](https://notes.ethereum.org/w_UoFg8pQyGgQurpPaRD8A#3-Toxic-Withholding-Strategies) are a serious threat to protocol stability. This class of attacks, which we may call *reveal timing games* rather than the *commit timing games* we are used to, is possible in **any design where there is a time delta between the moment transactions are committed to, and the moment all components of the block are revealed.** Right now this topic is under-researched, and we are currently exploring it. If payload reveal timing games are found to pose unacceptable stability risks — and if mitigating them introduces prohibitive trade-offs — I propose this alternative which mitigates these attacks while preserving most of the positive properties of EIP-7732. ## Specification - A Small Shift in the Design In standard 7732, the proposer signs a [commitment to the execution payload](https://github.com/ethereum/consensus-specs/blob/v1.6.0-alpha.3/specs/_features/eip7732/beacon-chain.md#executionpayloadheader) which is then [included in the beacon block](https://github.com/ethereum/consensus-specs/blob/v1.6.0-alpha.3/specs/_features/eip7732/beacon-chain.md#beaconblockbody). The full [execution payload](https://github.com/ethereum/consensus-specs/blob/v1.6.0-alpha.3/specs/_features/eip7732/beacon-chain.md#executionpayloadenvelope) and all associated blobs are then revealed later by the builder, no later than the PTC deadline. We can eliminate reveal timing games by simply **moving the commitment to the execution payload from the beacon block to the execution payload itself.** To be specific, the `BeaconBlockBody` in slot `N` would contain [everything it contains in standard 7732](https://github.com/ethereum/consensus-specs/blob/v1.6.0-alpha.3/specs/_features/eip7732/beacon-chain.md#beaconblockbody) *except* the [`block_hash` in the `ExecutionPayloadHeader`](https://github.com/ethereum/consensus-specs/blob/v1.6.0-alpha.3/specs/_features/eip7732/beacon-chain.md#executionpayloadheader). The `BeaconBlock` therefore forces the chain to come to consensus on what happened in the slot `N-1`, but it makes no commitment about the execution payload in slot `N`. By moving the commitment to the execution payload, we allow the auction to take place *later in the slot*. One consequence of this is that builder safety can then only be achieved with trusted relays. So in essence, this design sacrifices the on-chain trustless payment option to protect the protocol against reveal timing games. In this design, slot anatomy becomes the follwoing: ![](https://notes.ethereum.org/_uploads/rkaXuenLlx.png) where the proposer will commit to the payload at **some optimal time $\lambda$** that achieves maximal MEV extraction. The protocol only requires that the execution payload and blobs are revealed by the PTC deadline, **allowing $\lambda$ to change depending on how we scale gas and blob limits**. Unlike other designs, this design **maintains the other advantages of EPBS** including maximal pipelining because attestation aggregation happens in parallel with block/blob broadcast & execution. ## Types of Proposer Commitments There are two kinds of commitments the proposer could make under this scheme: 1. Payload hash (block auction) 2. Builder pubkey (slot auction) ### Block Auction Incentives and Trust Assumptions If the proposer commits to a payload hash, then there is still an incentive to play reveal timing games since there is a gap between the time that the transactions in the payload are committed to, and the time that the final component of the block is revealed. To prevent this we would have to **trust relays to not collude with the builder and perform reveal timing games.** We have this trust assumption today, but the additional time that comes from this proposal may push us into a regime where reveal timing games are more viable (since today relays would only have about 1 second to make the decision). Note that we have roughly the same trust assumption on relays with similar incentives in standard [EIP-7886](https://eips.ethereum.org/EIPS/eip-7886) as well. Also note that the relay can prevent the builder from performing reveal timing games without the relay's collusion by inspecting the kzg hashes of every blob transaction and **requiring the payload to only include blob transactions for which the relay has the full blob in custody**. In other words, the relay must prevent the builder from including private blob transactions in their block. If we accept that we can trust the relays to not play reveal timing games, we can also trust the relays to reveal the payload as soon as they have a signed commitment from the proposer. With block auctions, relays have little incentive to withhold the payload (unless they're providing execution preconf services). If we can trust them to reveal the payload in a timely way, this would decrease the post-state information monopoly, which is one of the goals of [the dual-deadline PTC design](https://notes.ethereum.org/@anderselowsson/Dual-deadlinePTCvote) with EIP-7732. ### Slot Auction Incentives and Trust Assumptions If the proposer instead commits to a slot, then in principle, there is no longer an incentive for the builder to play reveal timing games. But since the payload can now change very late in the slot, there is renewed incentive for the builder/relay to hold on to the payload as long as possible, increasing the post-state information monopoly issue.
Last changed by  
 
ethDreamer
136

Read more

Slot Restructuring Tradeoff Matrix

Property 7732 Block Auction Single Deadline PTC 7732 Block Auction Dual Deadline PTC Payload Block Separation noPTC EIP-7886 EIP-7886 + PTC 7732 Slot Auction Single Deadline PTC 7732 Slot Auction Dual Deadline PTC Max Scaling / Lowest Latencies

7/20/2025
In Defense of Trustless Builder Payments

There is a common mental model for EIP-7732 which splits the proposal into three main components: Payload-Block Separation PTC Committee Trustless Builder Payments At this stage in the discussion, many core-developers are on board with the first two components. See my earlier writing if you would like to understand why. Some core-developers are more concerned about trustless builder payments and would advocate for this to be removed from Glamsterdam. As far as I can tell, there are a few main criticisms of the on-chain trustless builder payment mechanism:

7/19/2025
Dubious Math Around Builder Reveal Timing Games

The Problem at Hand An under-researched topic has emerged in the discussion of EIP-7732 around builders playing reveal timing games to exercise an option. Here's an example to illustrate the basic idea: Suppose at time $t=0$ three things happen: The builder places a trade to sell $Q$ ETH on a DEX at price $P_0$ at the top of their block. The builder's block is chosen by the proposer. The builder places a trade to buy $Q$ ETH on a CEX at a price $P < P_0$ to pocket the arbitrage. Suppose at time $t = Δt$ later two things happen:

7/18/2025
Glamsterdam's Hidden Gem: EIP-7732

Before last week's Berlinterop, I would never have expected that I would be recommending EIP-7732: Enshrined Proposer-Builder Separation as the network's highest priority, worthy of taking the spot as Glamsterdam's headliner. Enshrined Proposer Builder Separation (ePBS) was originally designed primarily to enable a trust-free (no off-chain relay requirement) exchange between proposers and builders. This motivation took a major hit years ago when researchers realized that it isn't possible to completely eliminate the incentive to use out of protocol software/relays. Yet another complication arose when we considered possible futures in which proposers want to make alternative agreements with builders (for example slot auctions) that the enshrined mechanism doesn't support. In such a future, these proposers would necessarily go out-of-protocol to make these agreements, seemingly undermining the whole purpose of ePBS. The last thing we wanted to do as core devs is to spend a significant amount of engineering resources to bring this market on-chain, only to have most proposers use out-of-protocol software anyway. No solution to these concerns has been found in the years since they were originally raised. So then why in the world would I recommend EIP-7732 as Glamsterdam's headliner? Because to my surprise, it turns out that EIP-7732 has a number of properties which best position Ethereum for our three strategic initiatives: Scale L1: higher gas limits & L1-zkEVM Scale L2: more blobs Improve UX: lower latencies, faster finality, pre-confs This becomes particularly clear if one takes a slightly longer view of Ethereum for more than one fork down the road. If we do EIP-7732 (and maybe also FOCIL) in Glamsterdam, then we can do shorter slots in H*. 7732 enables us to have shorter slots than any alternative proposal. And for a given slot time we can have more blobs, and bigger blocks than any alternative proposal. And by doing it in this order (7732 first), we can achieve this vision faster and with less technical debt than any other ordering.

6/24/2025
Read more from ethDreamer
Published on HackMD