ePBS, distilled

[mikeneuder]

ePBS, distilled

by mike – august 24, 2026.
.
Thanks to potuz, Terence, Kubi, gd, Apriori, and Christian (ultra sound relay) for comments and review. Review does not necessarily imply agreement with the conjectures.
.
Links to relevant specifications.

Name	Link	Description
Builder spec: Gloas Builder	link	How builders and relays can register in-protocol and communicate bids with proposers.
Builder spec: Gloas Validator	link	How proposers should get bids from registered builders and relays.
Consensus spec: Gloas Beacon chain	link	Updates to the functioning of the beacon chain.
Consensus spec: Gloas Builder	link	How default in-protocol builders should participate.
Consensus spec: Gloas Validator	link	Updates to the default validator behavior.

\cdot

Enshrined Proposer-Builder Separation (abbr. ePBS) is complicated; it was already complicated three years ago. A good amount has changed since then, and given EIP-7732’s scheduled inclusion as a headlining EIP in the upcoming Glamsterdam hardfork, it felt like a good time to revisit the topic. The goal of this post is to distill ePBS in its current form to the most relevant changes and how those changes stand to impact Ethereum’s MEV market.

Section 1 recalls how MEV-boost implements PBS today. Section 2 works through the key features of ePBS, building towards the full flow of block production and consensus. Section 3 is my opinion on how relay, builder, and proposer behavior could evolve under ePBS. Section 4 touches on a few additional considerations/features of ePBS and concludes.

1. MEV-boost refresher

By point of comparison, we start with a very brief MEV-boost refresher, which is how about 90% of Ethereum blocks are built today. The figure below shows the flow of bids and blocks, and is annotated below.

1. The relay publishes a stream of highest bids, which builders subscribe to.
2. Builders submit bids to the relay.
3. The proposer asks the relay for the winning bid.
4. The relay returns the winning bid.
5. The proposer signs the winning bid, terminating the auction.
6. The relay publishes the block on behalf of the proposer.

Notes:

• Ascending-price auction, with an unknown termination. This auction format is a direct consequence of the getHeader API not being authenticated. As such, anyone (and most importantly, builders competing in the auction themselves) can call the relay to get the current winning bid (or equivalently can listen to the highest-bid stream) and use that information to adjust their bidding strategy. The proposer terminates the auction by submitting a signed bid.
• Relay publication. With the signed bid, the relay has the data to construct the full block, which it publishes on behalf of the proposer.

2. Key features of ePBS

In MEV-boost, the relay serves as a trusted third party to facilitate the fair exchange of the block building rights from the proposer to the builder. As described in Relays in a post-ePBS world, the core guarantees made by the relay are:

1. Ensuring the builder’s block is published only if it will become canonical.^[1]
2. Ensuring the proposer is paid accurately based on the winning bid.

In ePBS, these guarantees are facilitated by the protocol. Before walking through the entire flow, we need to define some relevant terminology.

• Beacon block: The object published by the proposer (called BeaconBlockBody in the spec). Prior to ePBS, the beacon block had the full list of transactions (i.e., the main “block” in the sense that it updates the state of the chain) in it, but now it just contains a signed bid (called SignedExecutionPayloadBid in the spec). Besides the block hash of the winning bid, the beacon block only contains consensus layer data (e.g., attestations, validator exits, etc.).
• Execution payload: The object published by the builder (called the SignedExecutionPayloadEnvelope in the spec). This is the “real block” in that it contains the actual list of transactions and updates the chain state.
• Staked builders: Participants who are registered to publish bids and execution payloads. If builders want to participate in the in-protocol mechanism, they are required to post a deposit of at least 1 ETH to be registered as a builder with an active builder_index. This stake is deposited from the execution layer to the consensus layer, and can be debited to pay for trustless payments.
• Payload-Timeliness Committee (abbr. PTC): The committee of validators that explicitly votes for the availability of the execution payload and the blobs that are referenced in the beacon block. This committee is much smaller (512 members) than a full attestation committee (currently around 30,000 members) and only votes a binary yes/no on the availability of the payload and the blobs (see PayloadAttestationMessage in the spec).
• Slot anatomy: With the new consensus participants of staked builders and payload-timeliness committee members comes a new set of deadlines that define the flow of a slot. Today’s slot is relatively simple with just two deadlines.
  
  
  
  The block (which currently is the beacon block and the execution payload combined as a single object) is supposed to be published at the start of the slot. Attesters are supposed to vote four seconds later. The following deadlines define slots under ePBS.
  
  
  
  The beacon block (without the execution payload) is supposed to be published at the beginning of the slot. The full attestation committee now votes on the beacon block three seconds later. At t=6, the builder is supposed to have published the execution payload (the actual block) once they are confident that the beacon block has sufficient fork-choice weight. Three seconds later at t=9, the payload timeliness committee members are supposed to vote on the execution payload according to their view at t=6 and blob availability according to their view at t=9. This asymmetry compresses the builder’s timeline for publishing the execution payload (for more discussion, see Builder exposure in Section 4).
• Trustless payments: A payment flow by which the winning builder’s bid can be debited from their in-protocol balance (which they deposited to become a registered builder). If the value field of ExecutionPayloadBid is set (spec), this is how the payment is processed. The balance will be credited to the proposer’s withdrawal address.
• Trusted payments: A payment flow by which the proposer chooses to accept execution layer payments (e.g., a native ETH transfer to the proposer’s fee recipient address) from the builder, which is how bid payments are handled today in MEV-boost. That is, instead of debiting the builder balance in the consensus layer, the payment is a normal transaction that directly pays the proposer onchain. This payment flow is trusted because the proposer won’t be able to see and verify the builder’s block to ensure the payment is included as a transaction (relays facilitate this trust today by ensuring payments are accurate). If the execution_payment field of ExecutionPayloadBid is set (spec), then the payment is processed in this manner. The largest such payment that a proposer will accept can be configured per-builder through the max_execution_payment in the spec.
• Self-building: The proposer can, of course, still self-build their own execution block (or claim they are self-building, while still receiving the block by any other means). Proposers signal this intent to the protocol by setting a special builder index and a value of 0 for the bid.
• Authenticated bid requests: The specification allows for builders to require the proposer to authenticate bid requests for their slot (by signing a message with the correct proposer key). This is verified in verify_request_auth_signature in the spec. This is listed as optional, and builders can instead continue allowing anyone to perform the bid request.

The figure below stitches all these pieces into a sequence diagram for an ePBS slot; the annotations follow.

1. Builders and relays register as in-protocol builders by depositing into the consensus layer.
2. The proposer sends a bid request to all the builders and relays that it is connected to. The proposer must configure their client to know which endpoint to request bids from. These bid requests may be authenticated, meaning only the proposer can call the API.
3. Builders and relays will submit signed bids to the proposer.
4. The proposer publishes the beacon block, which contains consensus operations and the signed bid, but no transactions.
5. The attesting committee for the slot observes the timeliness and validity of the beacon block.
6. The attesting committee votes.
7. The winning builder/relay observes the attestation weight of the beacon block that contains the winning bid.
8. The winning builder/relay publishes the execution payload (the transactions).
9. The payload timeliness committee members observe for the timeliness of both the execution payload and the availability of the blobs referenced.
10. The payload timeliness committee members vote.

Notes:

• Builder protection. Circling back to our relay guarantees that need to be provided in-protocol. First, “ensuring the builder’s block is published only if it will become canonical.” This is handled by the attesting committee and the payload timeliness committee. The winning builder/relay observes the set of attestations for the beacon block before determining if they should publish the execution payload. Further, assuming the payload timeliness committee is majority honest, publishing the payload in time will result in it becoming canonical as the committee will confirm its receipt.
• Proposer protection. Second, “ensuring the proposer is paid accurately based on the winning bid.” This is handled through the two payment mechanisms described above. The trustless payments are guaranteed and handled by the consensus layer accounting, while the trusted payments are reputation-based and handled directly onchain (as they are today).
• P2P bids. While there is a specification for gossiping builder bids over the P2P network (see validate_execution_payload_bid_gossip in the spec), there are several obvious reasons why this will not be the normal flow of bids from builders to proposers (see Conjecture 4 below); thus, we elide it from the main flow.
• Direct call configuration. The flow detailed above requires that each proposer can directly call a set of relays and builders to request bids. In other words, they will configure their clients to call a set of HTTPS endpoints rather than listening to gossiped bids. This exact configuration is done today in MEV-boost when proposers decide which relays to connect to to get bids from.

3. Conjectured proposer, builder, and relay behavior in ePBS

Clearly, there is a lot changing with ePBS. The operative question becomes: given this new set of rules, what behavior should we expect from proposers, builders, and relays? The following conjectures are how I think the MEV market structure will evolve. Some of these conjectures are similar to Titan’s article Builders and Relays in ePBS and Ultra sound’s view on the post-ePBS block building pipeline, so check out these discussions as well.

• Conjecture 1: Relays will sign up as in-protocol builders. Besides serving as a trusted third party, relays also play an important aggregation and auctioneer role today.^[2] By sourcing blocks from many different builders, relays provide access to a much broader set of blocks while only requiring proposers to configure a single endpoint. On the builder side, relays provide a clean abstraction layer. The builders can focus on constructing profitable blocks, while the relays handle the proposer relationships and the block publication itself. Lastly, most proposers have already configured the relay URLs through their usage of MEV-boost. This configuration will translate nicely to continuing to source bids from these known relays in ePBS. For these reasons, I think relays are very well-positioned to register as in-protocol builders and continue providing these services to both the proposers and the builders.^[3]
• Conjecture 2: Builders will strongly prefer to use trusted payments over trustless payments. The trustless versus trusted payment flow has always been a bit contentious in the ePBS design discussions. From my point of view, I see no reason why the builders would use trustless payments, nor any reason for proposers to require them to. First, consider the following table that shows the distribution of MEV over the first 6 months of 2026.

  percentile	number of slots	MEV (in ETH)	% of total MEV
  top 0.0001%	1	568.4	1.40
  top 0.001%	14	2,497.0	6.16
  top 0.01%	141	5,595.4	13.79
  top 0.1%	1,409	10,337.2	25.48
  top 1%	14,093	16,562.8	40.83
  top 10%	140,927	26,135.9	64.43
  top 100%	1,409,269	40,566.6	100.00

  This demonstrates how remarkably concentrated MEV is among the highest-paying slots. For example, the top 0.1% of slots account for 25% of the total MEV paid out during this period. As such, the most important blocks for builders to compete for will have MEV values in the hundreds of ETH. Builders won't want to keep that much capital sitting idle in the consensus layer. The process of continually shuffling capital from the execution layer into the consensus layer to pay the proposers for trustless bids just seems capital inefficient and unnecessarily complex from the builder's point of view. Instead, they will much prefer using the simpler execution layer payments flow (i.e., just sending an ETH transfer to the proposer's address onchain), which is how MEV payments are made today. It is also worth noting that builders take on a larger risk by using trusted payments, which require the payment to go through unconditionally. On high-value blocks, this risk may be large enough to meaningfully cause builders to shade their bids to protect against the downside risk of the block not becoming canonical but the payment being made. In the long run, trusted payments are better for proposers, who will maximize their yield by ensuring the builders are safe to bid as aggressively as possible.
• Conjecture 3: Proposers will be fine using trusted payments. From the proposer’s perspective, getting the largest possible MEV payments is their main objective. Since proposers already have years of operational experience and trust established sourcing bids and payments from existing relays and builders, continuing to do so under an ePBS regime makes sense for them too. Also, it is highly likely that the highest value bids are trusted (for the capital efficiency reason mentioned in Conjecture 2), so proposers will be forced to use trusted bids as a means of offering a competitive yield for the stake they manage. Since direct connections to in-protocol builders are expected, the proposers will have to curate a list of trusted endpoints in the same way that they choose which relays to connect to today. As such, I expect proposers to directly connect to a small number of dominant builders and relays who have relational and reputational capital, and to use the trusted payments flow within that set.
• Conjecture 4: P2P bids will not be relevant. As mentioned above, there is a specification for gossiping bids over the P2P network. I think these bids will not be relevant. First, and most obviously, bids are extremely latency sensitive. Sending them over a gossip network, where there may be many hops between the bidder and the proposer, incurs a significant overhead and makes P2P bids uncompetitive with those sourced from direct connections with builders and relays. Second, the P2P layer isn’t equipped to handle the volume of bids that are normally made during a slot. As such, the rules for gossiping bids are extremely stringent (e.g., only gossip a single bid for each builder per slot, whereas currently builders are used to bidding thousands of times in each auction). Lastly, P2P bid payments are required to be fully trustless (e.g., they have no trusted payment component). From Conjectures 2 & 3 above, I expect trusted payments to be the dominant payment scheme used, which further weakens the case for competitive P2P bids.
• Conjecture 5: Proposers will not configure a per-builder max_execution_payment. In the spec, proposers are allowed to configure a max acceptable execution-layer (trusted) payment from each builder. While in theory this could be used to set different trust thresholds (of the form: “I trust Titan up to 100 ETH, but Quasar only up to 50 ETH”), I don’t expect proposers to configure this for a few reasons. First, it is a lot of work; I think validators normally will want to “set it and forget it” in terms of configuration. Quantifying the amount of economic trust you have in each builder is a non-obvious task, and making the builder use a combination of trusted and trustless payments to fund a bid is extremely kludgy. Second, it caps the upside of a potential block, which the table above shows can be extremely high. If only a single builder can build a 100 ETH block during the proposer’s slot, but the proposer capped the trusted payment for that builder at 50 ETH, then the proposer effectively hard-capped the amount they can get paid, which is not rational. Either you trust the builder, or you don’t; I don’t think validators will be in the business of quantifying the amount of financial trust they put in each specific builder.
• Conjecture 6: Builders/relays are going to authenticate bid requests. An understated fact of ePBS is that it can fully change the auction format being run.^[4] Today’s relays mostly run an ascending price auction where the proposer and all competing builders/relays have a view on every relay’s highest bid (though this is changing with features like bid adjustments from ultrasound). Further, the largest three relays today provide a WebSocket stream that publishes the highest bid on the relay in realtime. Builders listen to this stream to decide on their respective bidding strategies. With the direct connections between proposers and in-protocol builders in ePBS, there is a natural authentication flow built into requesting bids. I believe builders and relays will use this authentication flow to ensure that only the proposer is able to fetch a bid. It is also possible that relays stop publishing the top bid stream, thus moving from an open auction to a blind auction. Ultra sound argues that the better solution is to keep the auction open, but acknowledges that a builder with a direct connection to the proposer can leverage this information asymmetry to bid more competitively without revealing information. To start, I expect the auctions to remain open, as that is what the large players favor presently. Still, intuitively, it seems that relays and builders that share more information by having public access to their bid value will be at a disadvantage to relays and builders that share less information. Note that a blind version of the auction makes the price discovery of MEV more opaque. If bids moved from public to private, the visibility into the pricing and bidding dynamics of builders/relays is greatly reduced. Of course, things are made more complicated by the fact that the proposer can take a signed bid from one builder and share it with a different builder to solicit a better bid (a lot of these dynamics depend on who has more leverage in the builder-proposer relationship). I am excited to see how the game plays out when the fork happens, and I think there is interesting theoretical and empirical work around the optimal way to participate in this auction as both a builder and a proposer.

The future is hard to predict, so we will see how these conjectures age. This exercise aimed at understanding what will happen once ePBS goes live, given the path-dependence of four years of MEV-boost and the evolution of Ethereum’s MEV markets. My main takeaways are similar to Titan’s from last year. Namely, I think the proposer, builder, relay relationships will continue to be largely trust-based between established entities, and I think smaller builders will have a harder time breaking into the market as a result.

4. Additional considerations

There are other parts of the ePBS story that are worth noting before we close. I list them here because they are secondary (IMO) to the impact on the MEV market dynamics, but they are important context for understanding the goals and design of ePBS.

• Delayed execution and pipelining. Around this time last year, when the Glamsterdam hard fork EIPs were being selected, ePBS was reframed around its delayed execution feature rather than its original goals of protocolizing the MEV markets. In fact, even the ePBS acronym was repurposed to “execution payload, block separation” (link).^[5] Since this is ostensibly one of the core benefits of ePBS as it is understood today, it makes sense to cover it briefly here (for more literature, see here). To understand the changes, it is helpful to look at the slot anatomy.
  
  
  
  In today’s slots, the first four seconds of the slot are where most of the action happens. The proposer publishes the block, and the attesters have to download the block, confirm the blob availability, and execute the block before making their vote at the attestation deadline at t=4. Under ePBS, there is a new set of deadlines and rules about them.
  
  
  
  First, the block is split into the beacon block and execution payload. The attesting committee now votes one second earlier at t=3, but they only have to download the smaller beacon block (which has no transactions) and verify the consensus data. The beacon block specifies a winning bid and corresponding builder, who observes the attestations to the beacon block and is supposed to publish their block before t=6. The payload timeliness committee is set to act three seconds later at t=9, but even then, they aren’t required to execute the transactions; they exclusively vote on the presence of the payload (by t=6) and blobs (by t=9). By the time the next slot rolls around at t=12, that proposer will decide if they extend the block based on the payload’s validity (i.e., they actually have to execute the transactions by this point). This gives them a much longer window to execute the block than exists today. While all of this sounds great for scaling, there is no free lunch, as outlined in the following bullets.
• Slot deadlines and the free option problem. My main issue with ePBS in its current form is the free option problem. There is a lot written on this, so I won’t rehash it here. However, it is extremely concerning to me that the option is most valuable (thus most likely to be exercised, resulting in missed slots) during the periods of highest market volatility. Client teams are hoping to mitigate this risk with aggressive circuit breaking and corresponding deny-listing of builders who withhold payloads, but as discussed in the following bullets, there may be legitimate reasons to refuse to publish a payload. This tension is notable, and it will be interesting to see what the community settles on as fair expectations of the builders.
• Fork-choice implications. The pipelining benefits described above change Ethereum’s consensus mechanism significantly.^[6] There are a few really interesting subtleties here. First, notice that the type of vote that the attesting committee and the payload timeliness committee make are fundamentally different. The attesting committee votes for a specific block (out of many possible candidates); the timeliness committee only votes on the availability of a specific block. Secondly, the fact that the timeliness committee isn’t required to verify the correctness of the block does make their role easier, but also does require careful handling of situations where the payload was present but invalid (e.g., a block can be present but not update the chain; this is akin to consensus-execution separation being implemented by other chains). Thirdly, there is a case when a builder can honestly refuse to publish the payload because the attestation weight of the beacon block is weak (i.e., they are worried that their published execution payload may not become canonical). Currently, the spec dictates that the trustless builder payment is only processed on an empty slot (where the beacon block is present but no execution payload is published) if the block received more than 6/10 of the possible attestation weight. Taken together, all of this greatly changes Ethereum’s consensus mechanisms, and a more formal theoretical treatment of the resulting mechanisms’ guarantees and incentives is worthwhile.
• Builder exposure: A careful reading of the payload-timeliness committee votes details that they are to vote on the availability of the execution payload according to their local view at t=6 and the availability of the blobs referenced in the block according to their local view at t=9. This asymmetry is notable, in that it forces the builder to act extremely early in publishing the execution payload. Consider a proposer who publishes their beacon block at t=2.7. Some subset of attesters will see it on time (before t=3) and thus vote for it; some will not see it on time and vote against it. Now the builder has to start gathering their view of the attestations as they are gossiped in the t in [3,6] interval, but the builder also must get the execution payload published such that it is delivered to a sufficient number of the payload timeliness committee before t=6. That is, the builder has a much tighter window of time to form their view of the attestation weight on the beacon block before publishing their payload. The justification for this tight deadline is that builders are sophisticated entities and thus capable of being well-connected and publishing quickly, but it bears mentioning that this makes their role even more complex and forces them to shoulder more risk of payloads being published without becoming canonical.

ePBS has had a long journey, and it will be exciting to watch how things evolve when it goes live in the Glamsterdam hardfork.

Thanks for reading!

---

1. Of course, this is not strictly guaranteed in that the status of the winning block depends on how late in the slot it was published, and this risk will persist in ePBS. ↩︎

2. Relays also offer auxiliary services like optimistic block validation, block merging, etc., which also benefit builders and proposers. ↩︎

3. Looking back at our 2023 discussion of why to enshrine PBS, I think the focus on the relays as “bad” for Ethereum was a bit of a red herring. We also understood that relays would have an important role to play even in a post-ePBS world at that time. With hindsight, it is clear that relays provide valuable services for both builders and proposers and will continue to exist in some form. It is also true, however, that because there was never a good solution found for relay funding, the vertical integration of builders and relays (and the resulting erosion of the neutrality of the relay) is probably the inevitable endgame. ↩︎

4. There is an academic paper about this, “From PBS to ePBS: the Microstructure of Block Building”, but I haven’t read it carefully enough to say how plausible the conclusions are. ↩︎

5. I think this reuse of the acronym was misleading and moved the goalposts of ePBS to not be about MEV and relays, but instead to be about a completely different topic, but whatever. ↩︎

6. Just take a look at the Glamsterdam fork-choice spec. ↩︎

[jvranek]

@mikeneuder

P2P bids will not be relevant.

agree they wouldn’t be relevant in supplying competitive bids but I think of p2p bids as a useful floor, the thinking is:

• in PBS, relays are liveness-critical for private order flow that the local building fallback can’t satisfy
• p2p bids are a new fallback that can serve some private order flow
• this floor lets the mev market experiment more

[jtraglia]

Hey Mike, great post

@mikeneuder

As such, the rules for gossiping bids are extremely stringent (e.g., only gossip a single bid for each builder per slot, whereas currently builders are used to bidding thousands of times in each auction)

Yes, a builder (the protocol entity) may only submit a single bid per slot, but builders (the person/organization) may operate multiple builders with different pubkeys. I expect builders will do this to submit many bids. I consider this to be a form of spam prevention; if you want to submit 1000 bids for the same slot, you will have to stake 1000 ETH.

@mikeneuder

As mentioned above, there is a specification for gossiping bids over the P2P network. I think these bids will not be relevant. First, and most obviously, bids are extremely latency sensitive. Sending them over a gossip network, where there may be many hops between the bidder and the proposer, incurs a significant overhead and makes P2P bids uncompetitive with those sourced from direct connections with builders and relays.

You are correct that P2P bids will be less competitive than direct bids, primarily due to latency. But there are ways to reduce latency. I expect sophisticated builders to operate a single beacon node which is connected to a large portion of the network; i.e., 1k+ peers. Such a node would be able to broadcast their bid with fewer hops and maybe, if they are peered with the proposer, no hops at all.

@mikeneuder

From Conjectures 2 & 3 above, I expect trusted payments to be the dominant payment scheme used, which further weakens the case for competitive P2P bids.

According to https://mevboost.pics, ~11% of the network does not use MEV-Boost. In time, I expect there to be a healthy amount of competition within the P2P bidding market, for proposers that will not connect directly to builders. This is an untapped resource from which builders may profit; P2P bids which are more profitable than the proposer’s locally built payload will be accepted by default.

[jvranek]

@mikeneuder

Proposers will be fine using trusted payments

@jtraglia

You are correct that P2P bids will be less competitive than direct bids, primarily due to latency.

I think the main counterargument is latency is just one factor, there’s also

• cost of capital to maintain stake to send p2p bids in general (also applies to a cap on the tail end bids)
• no bid cancellations
• risk of unconditionally paying if for whatever reason your payload isn’t delivered in time

Similar reasons to Mike’s conjecture 3 for trustless vs trusted bids (they apply to trustless p2p and trustless direct bids where latency is the main variable changed)