Sign in Subscribe
Ethereum

ePBS and your MEV rewards: what Glamsterdam changes for Ethereum stakers

Glamsterdam moves Ethereum’s block-building auction into the protocol. Here’s how ePBS changes where your execution rewards come from, how they’re paid, and what to ask your operator.

stakefish

stakefish

— 8 min read
Share
Banner: Glamsterdam ePBS and MEV, over the Amsterdam skyline with a glowing ETH diamond

Your Ethereum staking rewards come from two places. Consensus layer rewards are new ETH the protocol issues for attesting and proposing. Execution layer rewards are the priority fees and MEV a validator earns when it proposes a block.

Since the Merge in 2022, most of that execution layer income has flowed through an auction that runs outside the protocol, through MEV-Boost and a small set of relays (mevboost.pics).

Glamsterdam changes that. Its headline upgrade, enshrined proposer-builder separation (EIP-7732), moves the auction into Ethereum itself.

Here’s what changes for where your execution rewards come from, how they get paid, the new risks to price in, and the questions to ask your operator before mainnet.

Glamsterdam is live on Sepolia, is scheduled for Hoodi on October 26, 2026, and has no mainnet date yet (EF). For the full upgrade, read our companion post, Glamsterdam explained.

How the auction works today

Most validators don’t build their own blocks. They outsource it to specialized builders who compete to assemble the most valuable block.

Today’s flow looks like this:

  • Builders send blocks and bids to relays.
  • A relay checks the block, holds the full contents, and shows the proposer only the header and the bid.
  • The proposer signs the header for the best bid.
  • The relay releases the full block to the network.
  • The builder pays the proposer, in most cases with a transfer inside the block to the validator’s fee recipient address.

This works, and it has worked since 2022. But it rests on three things the protocol doesn’t enforce:

  • The relay reports bids honestly. The proposer can’t verify the bid on its own before signing.
  • The relay stays online and releases the block. If it doesn’t, the slot is missed.
  • The builder pays. Payment is a convention backed by relay checks, not a protocol rule.

When something goes wrong at any of those points, the validator wears the cost.

How the auction works under ePBS

ePBS splits the job of choosing the block from the job of building it, and puts the handoff on-chain.

  • Builders join the protocol. A builder registers by depositing ETH through an execution layer request (EIP-8282). The minimum is 1 ETH. Builders sit in their own registry, outside the validator entry and exit queues. A builder becomes active once the epoch of its deposit is finalized (Gloas beacon chain spec).
  • Proposers publish their preferences. Ahead of each slot it will propose, a validator can broadcast its fee recipient and target gas limit. Under the Gloas validator spec, a validator that skips this step won’t accept trustless bids for that slot.
  • Builders bid in the open. Signed bids travel over Ethereum’s peer-to-peer network. Each bid commits to a payload and a payment.
  • The proposer commits, then the builder reveals. The proposer picks a bid and includes it in the beacon block. The builder then publishes the full payload.
  • A committee checks timeliness. A Payload Timeliness Committee (PTC) of 512 validators attests whether the payload and its blob data arrived on time. Their deadline is 75% of the way into the slot (PAYLOAD_ATTESTATION_DUE_BPS in the validator guide).

Proposers can still build their own blocks. A self-built bid carries a value of zero (validator guide).

Diagram: today the builder bids through a relay, the proposer signs the header and the builder pays inside the block; under ePBS the proposer shares preferences, staked builders bid over P2P, the proposer commits, the builder reveals, and a 512-validator committee checks timeliness
The block auction today vs under ePBS. Sources: EIP-7732, Gloas validator guide, Gloas builder guide.

How you get paid changes

This is the part that matters most for your rewards reporting.

Payment comes from the builder’s stake

When the proposer accepts a bid, the protocol records a pending payment against the builder’s balance (Gloas beacon chain spec). The builder must hold enough to cover the bid and everything else it owes.

Payment arrives as a withdrawal, not a transfer

Under ePBS, the builder’s payment lands at the proposer’s fee recipient as an execution layer withdrawal. It doesn’t arrive as a transaction inside the block (Gloas beacon chain spec, BuilderPendingWithdrawal). Any reward tracker that looks for a builder’s transfer at the end of a block will miss it.

Payment is enforced, even if the builder withholds

If the builder never reveals its payload, the proposer can still get paid. The EIP-7732 design treats this as “proposer unconditional payment.” In the spec, it applies when the proposer’s beacon block gathers enough timely attestations: at least 60% of the stake assigned to that slot (BUILDER_PAYMENT_THRESHOLD 6/10 in the Gloas beacon chain spec).

In the normal case, the payment settles once the next block builds on the revealed payload. When a payload is withheld, it settles later, during end-of-epoch processing.

Three slot outcomes under ePBS: full (payload revealed, proposer paid), empty (payload withheld, proposer paid if 60% of slot stake voted on time), skipped (no block, no payment)
Three slot outcomes under ePBS. Sources: EIP-7732, Gloas beacon chain spec.

What it means for you

  • Ask how your operator’s reporting captures builder payments that arrive as withdrawals.
  • Ask how empty slots appear in your reports, and whether the builder payment for those slots settled.
  • Expect a small change in timing. Payment no longer lands in the same block in every case.

What happens to relays and MEV-Boost

Relays become optional. They don’t disappear.

ePBS gives proposers a trustless path, but the protocol still allows bids from “other off-protocol means” (validator guide). The spec includes a field for trusted payments made on the execution layer, outside the protocol’s guarantees. Bids that use it aren’t broadcast on the public bid network (builder guide).

In practice, that leaves operators with choices:

  • Take trustless bids only, from staked builders over the peer-to-peer network.
  • Keep relays in the mix, on their own or through sidecar software, for features the core protocol doesn’t cover.
  • Accept trusted payments from specific counterparties, which brings back today’s trust assumptions for those bids.

The Ethereum Foundation lists Commit-Boost 0.12.0-rc1 as Hoodi-ready tooling. If your operator runs a sidecar, ask whether its version supports Glamsterdam.

The right mix is an operator decision with real trade-offs. More bid sources can mean more competition for your block. Every trusted source is a counterparty.

New risks to price in

ePBS removes some risks and adds others.

  • Empty slots. A builder can win a bid and then withhold its payload. The beacon block still lands, but no transactions are executed in that slot. If the quorum was met, the proposer still gets the bid value.
  • The “free option.” Because the builder reveals after the proposer commits, a builder can walk away if prices move against it. The EIP flags this as a known trade-off of the design.
  • Cheap builder identities on test networks. Test ETH has no value, so spinning up many builders and bids costs little. Core developers flagged this for devnets on the September 17 consensus call ahead of Sepolia. Client circuit breakers fall back to local block building when payloads go missing, but developers noted that not every client can single out one misbehaving builder. Ask your operator how their setup handles repeated withholding.
  • A new committee duty. Validators picked for the PTC sign an extra attestation. A missed duty is a missed reward.
  • More slot outcomes to model. Every slot is now full, empty, or skipped. Short-window reward comparisons were already noisy. This adds one more source of variance.

What doesn’t change

  • MEV still exists. Builders still compete on how much value they can capture, and their bids still reflect that. The fork changes the plumbing, not the size of the opportunity.
  • Builder concentration isn’t solved. ePBS changes how builders interact with the protocol, not how many of them win. Censorship resistance gets its own fix in the next fork: FOCIL (EIP-7805) is scheduled for Hegotá (Forkcast).
  • MEV isn’t burned. A proposal to burn execution rewards under ePBS (EIP-8375) was declined for Hegotá (Forkcast, September 17, 2026). Execution rewards continue to flow to proposers.
  • Proposal luck still dominates. Execution rewards are lumpy. A small number of blocks carry outsized value, so who proposes when still drives most of the difference between validators over short periods.
  • Consensus layer rewards are untouched. ePBS doesn’t change issuance.

Higher gas limits, made possible by block-level access lists, could grow the fee pool over time. That depends on demand, and the fork doesn’t promise it.

What this means for stakefish stakers

stakefish pools execution layer rewards from all of our Ethereum validators in the MAX MEV smoothing pool, then distributes them to stakers through a smart contract (Ethereum staking guide). That evens out the proposal luck that makes execution rewards so lumpy.

Under ePBS, builder payments go to the fee recipient each validator announces. Our validators direct execution rewards to the smoothing pool today.

Ahead of mainnet, we’ll publish operational guidance covering how we’ll source bids, how we’ll handle relays, and how empty slots and withdrawal-based payments will show up in your reporting.

Questions to ask your operator

  • Which bid sources will you use at activation: trustless peer-to-peer bids, relays, or both?
  • Will you accept trusted, off-protocol payments? From whom, and why?
  • How will your reporting capture builder payments that arrive as withdrawals?
  • How will you report empty slots, and confirm the builder payment settled?
  • What happens if a builder repeatedly withholds payloads from your validators?
  • What gas limit will your validators target after the fork?
  • Are your client and sidecar versions Glamsterdam-ready on Hoodi?

Stake Ethereum with stakefish

stakefish charges 0% on consensus layer rewards and 50% on execution layer rewards, which flow through our MAX MEV smoothing pool. We publish our blended commission. See how our commission works.

Sources

Facts checked October 20, 2026.

Building staking into a platform? The stakefish Multi-Chain Staking API and SDK cover Ethereum, Solana and more. Read the API docs.

Stake now at: stake.fish/stake

About stakefish

Founded in 2018 by Ethereum and Bitcoin veterans, stakefish is the leading validator for Proof of Stake blockchains. With support for 20+ networks, we combine institutional‑grade infrastructure with intuitive dashboards, transparent reporting, and a spotless slashing record so individuals and institutions alike can stake confidently while strengthening decentralized networks.

Visit our website 🐠 | Telegram | X | YouTube | LinkedIn

Read more