How Will ePBS Change ETH Reward Reporting for Institutional Stakers?

Ethereum’s Glamsterdam upgrade is scheduled to include enshrined proposer-builder separation (EIP-7732), commonly known as ePBS.

‍

For Blockdaemon customers, all protocol upgrades and staking infrastructure are fully managed. However, customers may need to review how their internal systems report ETH staking rewards, especially where execution-layer and consensus-layer rewards are tracked separately.

‍

Why ePBS matters for institutional reward reporting

‍

ETH staking rewards are commonly reported across two categories:

‍

‍

Today, execution-layer reward reporting often reflects the MEV-Boost and relay model. Validators use MEV-Boost to connect to builders through third-party relays. Builders assemble execution payloads, relays coordinate delivery, and validators propose the block.

‍

ePBS moves more of that proposer-builder exchange into Ethereum itself. EIP-7732 introduces protocol mechanics for builder commitments, payload delivery, and proposer payments. Ethereum.org notes that ePBS removes the need for middleware such as MEV-Boost for the core payload-payment exchange, although off-protocol tools may still be used for more advanced features.

‍

The reporting distinction is that execution-layer rewards will still exist, but the path by which they are produced, labelled, and reconciled may change.

‍

What changes with ePBS? 

‍

ePBS does not remove the distinction between consensus-layer and execution-layer rewards.

‍

Consensus-layer rewards remain tied to validator participation and protocol duties. Execution-layer rewards remain tied to execution payload value, including priority fees and MEV-related value.

‍

What may change is the infrastructure behind execution-layer rewards. Today, many reports refer to MEV-Boost, relays, builder bids, or payload delivery. With ePBS, some of that logic becomes protocol-native.

‍

That may affect:

‍

• How execution-layer rewards are labelled
• Whether MEV-related rewards appear under the same fields
• How internal systems describe builder payments
• How rewards are reconciled across provider, custodian, and internal records
• How reporting distinguishes MEV-Boost-derived rewards from protocol-native ePBS rewards

‍

What customers may need to review

‍

Customer-side review is most relevant where internal reporting systems depend on today’s MEV-Boost and relay assumptions.

That may include:

‍

• Dashboards that split execution-layer and consensus-layer rewards
• Accounting reports that classify priority fees, MEV, or builder payments
• Internal labels that reference MEV-Boost or relays
• Data pipelines that depend on current payload delivery fields
• Reconciliation workflows across wallets, custodians, and staking reports

‍

The change is not necessarily about new reward categories. Rather, it is about how execution-layer rewards are sourced, described, and matched across systems after ePBS.

‍

Conclusion 

‍

Blockdaemon will manage the infrastructure side of ePBS across our Ethereum staking platform. That includes client readiness, validator updates, MEV configuration, relay dependencies, builder market monitoring, and post-upgrade reward behaviour.

‍

Customers do not need to manage validator-level changes through Blockdaemon’s staking platform. The customer-facing impact is more likely to be reporting alignment, especially where systems separate consensus-layer rewards from execution-layer rewards or reference today’s MEV-Boost and relay model.

‍

This is because ePBS moves more of Ethereum’s proposer-builder market into the protocol. For institutional stakers, that may reduce reliance on third-party relays over time and change how execution-layer rewards are surfaced.

‍

To discuss your staking reporting, book a call with the Blockdaemon team today.