# Enshrined PBS (ePBS): The Road to Trustless Ethereum

In the current Ethereum landscape before Glamsterdam, the relationship between proposers and builders depends entirely on a trusted third party. This critical interaction is facilitated by **Relays**, which are trusted, third-party intermediaries that serve as the glue for the [MEV-Boost](https://github.com/flashbots/mev-boost) ecosystem. Relays perform the act of protecting builders from having their complex MEV strategies stolen by proposers, while simultaneously shielding proposers from attacks where a builder might fail to deliver a promised payload.

However, in a distributed architecture like Ethereum, relying on out-of-protocol intermediaries introduces a centralization risk that complicates the network's liveliness and censorship-resistance guarantees.

[Enshrined PBS](https://eips.ethereum.org/EIPS/eip-7732) represents the protocol's move to internalize this market logic. By integrating the auction mechanism directly into the Consensus Layer, ePBS seeks to replace reputation-based trust with protocol enforced-rules. This shift transforms the proposer-builder relationship from an off-chain negotiation into a transparent, in-protocol state transition, removing the middleman.

## The Problem: The End of the Relay Era

To understand where we are moving in the update, we first need to look at where we stand. Today, the vast majority of Ethereum blocks are produced through MEV-Boost, a sidecar application which implements the Proposer-Builder Separation (PBS) market outside the protocol. While MEV-Boost successfully democratized MEV rewards for solo stakers, it did so by introducing a critical dependency of a **trusted relay**.

### Lack of Trust

- **Lack of Trust in Proposers:** Builders cannot simply hand over their execution payloads, because a proposer could unbundle the transactions, steal the MEV and propose the block themselves.
- **Lack of Trust in Builders:** Proposers cannot simply give a pre-signed header to the builders, because the builder might withhold the block or collaborate with the next proposer, causing the current proposer to miss their slot and rewards.

### The Relay as an Intermediary

The relay solves this by acting as an escrow. It holds the builder's payload secretly, reveals only the bid to the proposer and arranges the final block once the proposer signs.

While this approach works, but it has significant drawbacks:

- **Centralization Risk:** A small number of relays process the majority of the Ethereum's transactions. If these relays fail or are pressurized to censor, the network's decentralization is compromised.
- **Complexity:** Maintaining out-of-protocol software creates extra coordination problems for developers and increases the overhead of node operators.

### The ePBS solution

ePBS aims to move this interaction from a private server into the Beacon State. By turning the relay's functions into protocol-level constraints, we can guarantee safety for both the proposers and the builders without needing a middleman.

## Payload Timeliness Committee(PTC)

In a network without relay to vouch for the builder, it needs a decentralized way to determine if the builder fulfilled their part of the bargain. The **Payload Timeliness Committee(PTC)** is a group of 512 validators, reshuffled every slot, that acts as the final the network's decentralized arbiter.

### The `9s` Pulse

The PTC's role is time-critical. At the `9s` mark of the slot, they look at their local view of the network and cast a vote based on what they see. It is a three-way signal:

- `PAYLOAD_PRESENT`: The builder revealed the full payload before the `6s` mark and the data in it is valid.
- `PAYLOAD_WITHHELD`: The builder sent a specialized withheld message. This usually happens when the builder sees a weak CL block and chooses to protect their MEV from a potential reorg.
- `PAYLOAD_ABSENT`: No block or message was sent by the builder.

### Influencing the Fork-Choice

The power of PTC lies in how their votes interact with the LMD-GHOST fork-choice rule. Their attestations allow the network to distinguish between an Empty and Full block. If the signal is `PAYLOAD_PRESENT`, the block gains a **Reveal Boost**. This signals to the next proposer to build on top of this block. On the other hand, if the signal is `PAYLOAD_WITHHELD`, a **Withholding Boost** is applied to the parent block. This creates a mechanism of protocol-enforced reorg, ensuring that the weak CL block is discarded and the builder isn't forced to pay for a slot that the network didn't support.

### Aligning Incentives

Proposers are incentivized to include PTC attestations in their blocks and the PTC members are awarded when their votes are consistent with the final state of the chain. If they vote a for a payload to be present, but the chain determines it was absent, they lose a small portion of their attestation reward.

## Anatomy of a Slot

The most significant change in ePBS is the restructuring of the Ethereum slot. In the pre-ePBS world, consensus and execution are gossiped together. In ePBS, we unbundle these components, transforming the 12-second slot into a precisely timed sequence of reveal and verification events.

### The Decoupled Timeline

To remove the relay, the protocol must act as an escrow. This requires a multi-stage pipeline where data is revealed incrementally to ensure neither the proposer nor the builder can cheat the other.

- `T = 0s`: The slot begins with the proposer broadcasting a **Signed Beacon Block**. This block does not contain actual execution transactions. Instead, include a **Signed Execution Payload Header**. This is a cryptographic commitment to a builder's bid, including the bid value and the parent block hash.
- `T = 3s`: Validators observe the network for the Beacon block. The attestation committee votes on the presence and validity of the CL block. This process is fast as there are no heavy execution transactions or blobs to verify yet.
- `T = 6s`: Two heavy operations are performed in this period:
- The builder, seeing the CL block's support, decided whether to reveal or withhold **Execution Payload Envelope** which contains actual transactions and blob data.
- Aggregators collect the individual 3s votes and broadcast them to the network.
- `T = 9s`: A new committee, **Payload Timeliness Committee(PTC)** votes on the timely reveal or withholding of the Execution Payload Envelope.

### The Three Outcomes of a Slot

Because consensus and execution are decoupled, we now track three different possibilities:

- **Full Slot:** Both the Beacon block and the Execution Payload were revealed timely and are valid.
- **Empty Slot:** The Beacon block was revealed, but the Execution Payload was missing or late. The proposer is still paid, but no transactions occur.
- **Missed Slot:** The proposer failed to broadcast even the Beacon block.

### The `6s` Bottleneck

Maintaining the `12s` slot time is a deliberate design constraint to prevent breaking applications and tooling. However, this creates a tight window, by the `6s` mark, the network must handle the simultaneous gossip of aggregated attestations and the heavy execution payload. If the network is congested, the payload may arrive after the `9s` deadline, turning a potentially profitable slot into an Empty slot.

## The Free Option Problem

When a proposer commits to a builder's bid by signing the Execution Payload Header, the builder now holds what is effectively a free option. They can observe the network after the CL block lands, checking whether the slot is strong, whether a reorg is likely, whether market conditions have shifted, and then decide whether revealing the payload is still profitable. If conditions have turned against them, they can simply withhold. The proposer has already committed but the builder has not.

This is not a flaw that ePBS fully eliminates, but it is one it deliberately accounts for. The `PAYLOAD_WITHHELD` signal and the `Withholding Boost` exist precisely to make this option non-trivial to exercise. Withholding applies a protocol-enforced reorg on the parent block, meaning the builder sacrifices the slot's finality and risks their own reputation on-chain. The PTC's slashing of inconsistent votes further tightens the window for opportunistic behaviour. The free option still exists in ePBS, but it comes with a measurable, protocol-level cost.

## Unconditional Payment

One of the major reason proposers still rely on the relays is the guarantee of the payment. In a tradition auction, if the builder fails to produce a block, the proposers loses their slot revenue. ePBS eliminates this risk by the use of Unconditional Payment.

### The Commitment is the Payment

In ePBS, the payment logic is moved from the execution layer to the consensus layer. This mechanism works as follows:

- As soon as the proposer signs a Signed Execution Payload Header and includes it in their Beacon Block, the protocol considers the contract signed.
- During the consensus state transition, the protocol checks the builder's balance. If the builder has the funds, the bid amount is immediately deducted from the builder's stake.
- The proposer is credited regardless of whether the builder actually reveals the transactions later in the slot.

### Builders as first class citizens

To make the entire process trustless, ePBS introduces builders as a formal entity with the Beacon state. Instead of being anonymous actors, builders are staked participants identified by BLS addresses.

- **Staked Assets:** By requiring builders to have capital in the Beacon chain, the protocol can verify liquidity before a proposer commits to a bid.
- **Capital Efficiency:** By allowing builders to utilize the maximum **Effective Balance**, they can maintain large balances to bid on high-MEV blocks while still earning staking interest. This prevents the idle capital problem that would otherwise plague high-volume builders.

### The Deposit Churn

To make builders first-class citizens of the Beacon State, ePBS requires them to maintain a staked balance. But this introduces a subtle risk, a well-capitalized builder could submit an astronomically large bid in a single slot, causing a sudden and destabilizing shift in the network's economic weight. The deposit churn mechanism exists to prevent exactly this.

The churn works by imposing a rate limit on how quickly large capital movements can be processed. For standard bids that fall within normal operating ranges, payment is effectively immediate. However, for bids that exceed the threshold, the payment is not settled instantly. Instead, it is queued through the same churn pipeline used for new validator deposits, spreading the capital movement across multiple slots.

## Forward Inclusion Lists

A core tension in any PBS design is the trade-off between efficiency and neutrality. When we allow specialized builders to construct blocks, we give them the power to choose which transactions are included and which are ignored. To combat potential builder-level censorship, ePBS introduces **Forward Inclusion Lists(IL)**.

### The Proposer's Mandate

Inclusion lists allow the proposer to exert authority over the builder. The mechanism works as:

- Proposer `N` observes the mempool and identifies transactions that are being unfairly ignored. They compile these into an inclusion list.
- This IL is broadcasted along side the Beacon block for slot `N`.
- The builder for the following slot `N+1` is protocol-bound to include the transactions from IL. If the builder fails to satisfy the IL, their execution payload is considered invalid by the network.

To keep the EL efficient, it only receives the information it strictly needs for validation. While the CL tracks the complete inclusion list, EL only receives a list of addresses.

### The Empty Slot Reset

There is an one-to-one correspondence between the ILs and the full blocks. If slot `N` results in an empty slot, the inclusion list requirement does not stack or create a backlog. Instead, the protocol ignores any new inclusion list submitted by a proposer whose parent slot was empty. This ensures that the IL queue never threatens the liveliness of the chain.

## Conclusion

The Relay Era was not a failure, it was a solution that brought MEV democratization to solo stakers at a scale the protocol could not yet support natively. But every block routed through a third-party relay depended on reputation rather than rules. ePBS closes that gap by moving the entire proposer-builder interaction from a private handshake into a transparent, protocol-enforced state transition.

For a solo staker, this means relay-free operation and guaranteed slot revenue the moment they sign a header. For a DApp developer, it means a credible, on-chain guarantee that their users' transactions cannot be silently censored. ePBS does not merely patch the relay problem, it asks a more fundamental question: if a rule can be enforced by the protocol, why should it ever be enforced by trust? Ethereum's answer, with ePBS, is that it shouldn't.